Page 37 of 47 FirstFirst ... 273233343536373839404142 ... LastLast
Results 361 to 370 of 461

Thread: Decoded - EvoHome API access to control remotely.

  1. #361
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    Felt reluctant to add such functions to the base library. Particularly using member functions like asFloat(), asInt() etc because I discovered the program can end with messages that it cannot represent the value in the requested format. Returning string seems to be the most stable method and then you can use standard functions to convert to any other format if needed.

    No problem with changing to sprintf_s. Of course I can't do that because that's Windows only

    Just looked at those j_day variables. I can see where the compiler might trip on them but those are in fact unreachable points if j_day is not initialized.

    PS the project was always C++.
    Last edited by gordonb3; 23rd June 2017 at 04:23 PM.

  2. #362
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    Quote Originally Posted by RichardP View Post
    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).
    Had some other reports about crashes. Also in the precompiled versions which are running correctly on my site. I have a suspicion that it was related to the size of the installation and the cause appears to be that the json-c implementation would write objects to non reserved memory. If I'm right you'll probably see a 0xc00000fd in the crash logs. The jsoncpp implementation handles this differently.

  3. #363
    Automated Home Jr Member
    Join Date
    Jun 2017
    Posts
    48

    Default

    Could be that the crashes were due to the size of the 2nd Location, 9 zones plus dhw, I guess that's quite large. Still no crashes with jsoncpp.

    Could you put a #define in for sprintf_s based on if _WIN32 is defined?

    I can easily put any new methods in a derived class, so I won't have to touch the base, or just add some directly to my app. Just seemed a little strange that there are no methods to get those values in the base library.

    Thanks for the tip about strings, again it's easy enough to return a string and then parse it for the value.

  4. #364
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    It's something of a historic argument. I had used the Python library for some time and somehow the structure of it seemed to make sense. Unlike the reference project I wanted a sort of random access to the individual objects though, so every struct that is related to such an object contains all the IDs from the upper levels and a link to where the object is located inside the master json objects 'locationInfo' and 'status'. And then of course there is 'schedule' which is a separate json object for each zone.

    From that point on it did not make much sense to make specific individual values available through dedicated functions because it will depend on the implementation which values people would be interested in. So while it is possible for me to add such functions for temperature and name, this would no doubt lead to questions why there is no function for value X.

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

    Default

    Simple solution, just add a method to return every item in the structure!

    Seriously, it's very easy to create a wrapper so it's not an issue. I'm just very grateful that it exists at all!

  6. #366
    Automated Home Jr Member
    Join Date
    Jun 2017
    Posts
    48

    Default

    Small request. Could you throw on the evohomeclient constructor if the login fails? Currently there does not seem to be an elegant way of detecting that the login has failed, especially as the account_info map is private.

  7. #367
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    Ahead of you there, although it may not apply to the version you downloaded. You can now also call the constructor without parameters and then run the login method which returns a boolean value. I actually overlooked that the account_info map was still there - a bit pointless because it only has one member (userId) and also string-string maps don't have a very good reputation with regards to memory management.

    I also rewrote some of the webclient code so I could move the curl dependency away from the header files (this include turned out to be the cause for strange compile time errors with another project), which I also cleaned from other non essential includes. Other changes are to the demo apps which are at present the closest form of documentation that exists with the project.

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

    Default

    OK, sounds good.

    Another small request. In webclient there are still two calls to exit. One is on failure to initiate libcurl, which is possibly OK, the second is on web_send_receive_data failing to connect, that's definitely NOT OK! If the internet goes down, the app exits.

    Ideally both of these would either return failure codes or throw.

  9. #369
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    Noted. The second one already returned an empty string btw. But I guess using throw would be the better method to allow unexpected events to be handled by the main application.

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

    Default

    I'm pretty pleased with the progress I'm making now, I've not started on the control side but the display side is good enough to be providing useful information.

    I think as has been mentioned elsewhere in the thread, there appear to be some fundamental bits of information that the Evohome controller either does know or must know that are missing from the data returned by the calls in evohomeclient. I don't know if this is because they can't be obtained, no one knows how to obtain them yet or if the controller does not push them to the totalconnectcomfort site.

    If anyone from Honeywell is reading this, these bit's of information would be very useful :

    1) dhw set temperature. As this is not often changed I can just set a parameter to be the same as the set value, it would just be nice to have it read directly.
    2) Zone heat demand, or even just location heat demand. Location heat demand could be a Boolean, but Zone heat demand could reflect the degree to which a radiator valve is open.
    3) Something to indicate when optimisation is in effect.
    4) Something to indicate when various room states are active, for example 'Window Open' has been detected or override from a radiator valve (which is currently not shown by the controller).
    5) A list of sensors for each zone.
    6) Signal strength and battery indicators of each sensor.
    7) A way of pulling this data over a local network so as not to rely on the Honeywell web site being available or even an internet connection.

    My only other observation so far is that the reporting interval of dhw seems to be quite slow. As we have a device to put excess power from the solar PV into the how water, it can heat up when the Evohome is not heating it. It would appear that the update frequency can be as long as one hour, jumping several degrees, although sometimes it's less.

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
  •