Page 36 of 47 FirstFirst ... 26313233343536373839404146 ... LastLast
Results 351 to 360 of 470

Thread: Decoded - EvoHome API access to control remotely.

  1. #351
    Automated Home Jr Member
    Join Date
    Jun 2017
    Posts
    48

    Default

    Quote Originally Posted by dty View Post
    Richard, what are you doing that graphing in?
    I just wrote a simple control using the Windows GDI+ API calls, it takes a collection of data point structures that contain a data array and the colour in which you want to draw the plot, it then draws them inside a defined rectangle.

  2. #352
    Automated Home Ninja
    Join Date
    Aug 2016
    Posts
    489

    Default

    Quote Originally Posted by RichardP View Post
    I just wrote a simple control using the Windows GDI+ API calls, it takes a collection of data point structures that contain a data array and the colour in which you want to draw the plot, it then draws them inside a defined rectangle.
    That's a shame. I was hoping it was a proper platform that I could push my data into.

  3. #353
    Automated Home Legend
    Join Date
    Jul 2014
    Posts
    1,054

    Default

    I find emoncms.org a pretty good platform.

  4. #354
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    147

    Default

    Hi Richard,

    You might be interested to learn that I did a rewrite of the library. The new version does no longer have a dependency on json-c. It is replaced by jsoncpp which is included in the source files and should not have any memory leaking issues. Obviously syntaxes are different, but once you get used to it is actually a lot simpler to work with as well.

    Gordon

  5. #355
    Automated Home Jr Member
    Join Date
    Jun 2017
    Posts
    48

    Default

    Quote Originally Posted by gordonb3 View Post
    Hi Richard,

    You might be interested to learn that I did a rewrite of the library. The new version does no longer have a dependency on json-c. It is replaced by jsoncpp which is included in the source files and should not have any memory leaking issues. Obviously syntaxes are different, but once you get used to it is actually a lot simpler to work with as well.

    Gordon
    I've had a quick look but not tried it yet. Looks much better. I like the fact that it does not call 'exit' when things don't go quite to plan too, that caused me a couple of issues in a long running app when the internet goes down!

  6. #356
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    147

    Default

    Yeah... That was kind of inspired by the idea of creating an application that would do a single run, like the Python scripts from the start of this thread.

    You may like to note that if you run this from an application that stays resident it is not necessary to log in every time, which kind of reminds me that login() should be public. It is sufficient to rerun get_status() to fetch updates. You should be aware however that there is a maximum alive time for each session and you will need to login again after an hour (Better still to discard the session yourself before that happens). In theory you could then still re-use installationInfo and or schedule information, but with the in core Domoticz version I like to renew that as well after login.

  7. #357
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    147

    Default

    Richard,

    Just noticed your output has the half degree resolution on temperatures. You may like to build and run the current evo-demo from the project folder for an example how to improve that.

  8. #358
    Automated Home Jr Member
    Join Date
    Jun 2017
    Posts
    48

    Default

    Gordon,

    Thanks for the pointers.

    I know that the session times out and I've coded to automatically reconnect on any failure to obtain data.

    I also know that the old API gives higher temperature resolution, I'll get round to using that when I've got things working a little better.

    I'm currently getting random crashes in the application, more often on startup and sometimes just at any time. This happens more on the tablet that I actually use and which runs the app which does not have a debugger on it (it only has 32Gb flash storage). I've added a debug log so I can see where it's crashing, and on startup it's almost always at some point in getting the status, more specifically getting the status of the 2nd location. On my development machine it crashes much less frequently and in much more random locations. Last night it crashed in the middle of the draw routine that's basically unchanged for 3 years. My guess would be that there is a memory overwrite. The first location has 5 zones, the second had 9 zones and dhw. Often the crash occurs reading the information for zone 6 on the 2nd location. That sounds like the location 2 data is using storage that's the size of location 1s data.

    I want to switch to your C++ version, but I need to port over a couple of routines I added to get the dhw temperature and the zone names and temperatures.

  9. #359
    Automated Home Jr Member
    Join Date
    Jun 2017
    Posts
    48

    Default

    I've now converted to the C++ version, so far it's looking much more stable - touch wood, no crashes yet on either development machine or the tablet. Took a bit of getting my head round how it works, but it appears to be actually very simple to use.

    I made a couple of minor changes to the evohomeclient, not sure if you want to do anything with them.

    I added methods for returning the dhw temperature, zone temperature and zone name, I need to add some more to get the set point etc.

    Code:
    float EvohomeClient::dhw_temp(int location, int gateway, int temperatureControlSystem)
    {
    	EvohomeClient::temperatureControlSystem *tcs = &locations[location].gateways[gateway].temperatureControlSystems[temperatureControlSystem];
    	return dhw_temp(tcs);
    }
    
    float EvohomeClient::dhw_temp(EvohomeClient::temperatureControlSystem *tcs)
    {
    	float temp = (*tcs->status)["dhw"]["temperatureStatus"]["temperature"].asFloat();
    	return(temp);
    }
    
    float EvohomeClient::zone_temp(int location, int gateway, int temperatureControlSystem, int zone)
    {
    	EvohomeClient::zone *z = &locations[location].gateways[gateway].temperatureControlSystems[temperatureControlSystem].zones[zone];
    	return zone_temp(z);
    }
    
    float EvohomeClient::zone_temp(EvohomeClient::zone *z)
    {
    	float temp = (*z->status)["temperatureStatus"]["temperature"].asFloat();
    	return(temp);
    }
    
    std::string EvohomeClient::zone_name(int location, int gateway, int temperatureControlSystem, int zone)
    {
    	EvohomeClient::zone *z = &locations[location].gateways[gateway].temperatureControlSystems[temperatureControlSystem].zones[zone];
    	return zone_name(z);
    }
    
    std::string EvohomeClient::zone_name(EvohomeClient::zone *z)
    {
    	std::string temp = (*z->status)["name"].asString();
    	return(temp);
    }
    I made a couple of changes due to compiler warnings, the sprintf calls were changed to sprintf_s and two local variables 'j_day' were initialised as in theory (but probably not practice) they could be used without having been initialised.

  10. #360
    Automated Home Jr Member
    Join Date
    Jun 2017
    Posts
    48

    Default

    Current view on the monitoring tablet PC. Currently the plot colour changes entirely based on current temperature from blue 'cold' to red 'hot'. I might experiment with just changing the portion of the plot that's within range, might look a bit messy though. Changing the entire plot makes it easy to see at a glance what the current status is.


Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •