Decoded - EvoHome API access to control remotely.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • gordonb3
    Automated Home Ninja
    • Dec 2016
    • 273

    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; 23 June 2017, 03:23 PM.

    Comment

    • gordonb3
      Automated Home Ninja
      • Dec 2016
      • 273

      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.

      Comment

      • RichardP
        Automated Home Jr Member
        • Jun 2017
        • 48

        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.

        Comment

        • gordonb3
          Automated Home Ninja
          • Dec 2016
          • 273

          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.

          Comment

          • RichardP
            Automated Home Jr Member
            • Jun 2017
            • 48

            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!

            Comment

            • RichardP
              Automated Home Jr Member
              • Jun 2017
              • 48

              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.

              Comment

              • gordonb3
                Automated Home Ninja
                • Dec 2016
                • 273

                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.

                Comment

                • RichardP
                  Automated Home Jr Member
                  • Jun 2017
                  • 48

                  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.

                  Comment

                  • gordonb3
                    Automated Home Ninja
                    • Dec 2016
                    • 273

                    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.

                    Comment

                    • RichardP
                      Automated Home Jr Member
                      • Jun 2017
                      • 48

                      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.

                      Comment

                      • DBMandrake
                        Automated Home Legend
                        • Sep 2014
                        • 2361

                        Originally posted by RichardP View Post
                        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).
                        Which model of controller do you have ? The current Wifi model definitely displays when Window Open mode is active in a zone with a window icon on the screen. However you are correct that this information is not passed to the API. All the API sees is that the zone set point is now 5 degrees. Interestingly, it does not appear as a timed or permanent override, but appears as if 5 degrees is the normally scheduled temperature.

                        So if you know the current set point is 5 degrees, the scheduled temperature is not 5 degrees and no timed or permanent override is in effect, you can deduce that the zone is in Window Open mode. This heuristic would fail in Day off mode or Eco mode however.
                        5) A list of sensors for each zone.
                        This isn't even available from the controller at the moment. For example remote temperature sensors like a DTS92 are not even listed in the devices section in system setup.
                        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.
                        I think that's unlikely to happen as it would then expose the evotouch as an attack surface on the network - at the moment it has no open ports and only makes an outgoing connection to honeywell servers, so I suspect its likely to remain this way.
                        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.
                        This is not API or controller related, this is purely down to the battery saving algorithm in the CS92A.

                        I've talked about how it behaves (and misbehaves) at length in a couple of other threads of mine. In short the update frequency from the sensor varies widely depending on the current temperature and its rate of change.

                        When it is within the differential band (between setpoint-differential and setpoint) the sensor updates very frequently - about every 1 degree change and as frequently as about every 30 seconds, if necessary.

                        However outside the differential band (especially below it) the updates are very infrequent, and it will only update if the temperature changes many (5-10 degrees) or drops/rises very rapidly. If the temperature is outside the differential band and is not changing at all or only very slowly, it will only send an update once an hour.

                        As far as I've seen, when the Evotouch does get a temperature update from the CS92A it displays it immediately and updates the API value within seconds as well, so only a change to the programming of the CS92A would do what you're asking - and probably at the expense of greatly shortening the battery life.
                        Last edited by DBMandrake; 25 June 2017, 10:58 PM.

                        Comment

                        • RichardP
                          Automated Home Jr Member
                          • Jun 2017
                          • 48

                          Originally posted by DBMandrake View Post
                          Which model of controller do you have ? The current Wifi model definitely displays when Window Open mode is active in a zone with a window icon on the screen. However you are correct that this information is not passed to the API.
                          Sorry, I was ambiguous in what I said was not displayed. Window Open, Optimisation, Override from the App (presumably override from the API) and override from manual adjustment of a thermostat of from the controller are displayed as an icon in the zone. What's not displayed is if you adjust one of the radiator valves manually.

                          Originally posted by DBMandrake View Post
                          All the API sees is that the zone set point is now 5 degrees. Interestingly, it does not appear as a timed or permanent override, but appears as if 5 degrees is the normally scheduled temperature.

                          So if you know the current set point is 5 degrees, the scheduled temperature is not 5 degrees and no timed or permanent override is in effect, you can deduce that the zone is in Window Open mode. This heuristic would fail in Day off mode or Eco mode however.
                          I've also noticed that when in Optimisation mode at the end of a scheduled on period you get a set point of 5 degrees too, so there are quite a few states that are not individually distinguishable.

                          Originally posted by DBMandrake View Post
                          This isn't even available from the controller at the moment. For example remote temperature sensors like a DTS92 are not even listed in the devices section in system setup.
                          Quite! The controller obviously knows about each device as the number of devices in a zone are shown in the signal strength test.

                          Originally posted by DBMandrake View Post
                          I think that's unlikely to happen as it would then expose the evotouch as an attack surface on the network - at the moment it has no open ports and only makes an outgoing connection to honeywell servers, so I suspect its likely to remain this way.
                          Good point. How about a simple milticast or configured UDP address that's periodically sent data. So no configuration, but monitoring capability only.

                          Originally posted by DBMandrake View Post
                          This is not API or controller related, this is purely down to the battery saving algorithm in the CS92A.

                          I've talked about how it behaves (and misbehaves) at length in a couple of other threads of mine. In short the update frequency from the sensor varies widely depending on the current temperature and its rate of change.

                          When it is within the differential band (between setpoint-differential and setpoint) the sensor updates very frequently - about every 1 degree change and as frequently as about every 30 seconds, if necessary.

                          However outside the differential band (especially below it) the updates are very infrequent, and it will only update if the temperature changes many (5-10 degrees) or drops/rises very rapidly. If the temperature is outside the differential band and is not changing at all or only very slowly, it will only send an update once an hour.
                          Interesting, and that does seem to correspond with what I'm seeing. Updates are about 1 an hour even if the temperature has changed by 5 degrees or so. If the temperature changes by 10 degrees (for example if the bath has been run and the temperature drops quickly) then you usually get an update within 5-10 minutes.

                          Out of interest, why does the CS92A need to have such power saving algorithms when devices like the radiator valves don't?

                          Originally posted by DBMandrake View Post
                          As far as I've seen, when the Evotouch does get a temperature update from the CS92A it displays it immediately and updates the API value within seconds as well, so only a change to the programming of the CS92A would do what you're asking - and probably at the expense of greatly shortening the battery life.
                          Yes, again, that corresponds with my observations.

                          Comment

                          • gordonb3
                            Automated Home Ninja
                            • Dec 2016
                            • 273

                            Dropping in $0.02

                            I'd say the reason for this data not being available in the web portal is because this information is also shielded in the controller. Being able to access this data through the web portal would allow any authorized user to circumvent the password you may or may not have set on the system settings.

                            @Richard:
                            I'm now returning two types of exceptions. Both Class constructors may return a std:runtime_error that is related to a failure to instantiate libcurl. The auto login Class constructor may return a std::invalid_argument if login failed, as will every web accessing method if there was either a connection issue (client side) or the server returned an HTML response instead of json (e.g. maintenance notification).

                            Comment

                            • RichardP
                              Automated Home Jr Member
                              • Jun 2017
                              • 48

                              @Gordon
                              I've just tried the mechanism for getting more accurate temperatures from the V1 API. After some modifications. it's now working.

                              I had to make some modifications because the V1 API is returning the locations in a different order to the V2 API, so either you have to look at all the locations for the Zone ID or first look through the locations for the location ID and then find the Zone ID in that location.

                              I also got an access violation when returning from user_account with the new code, I've not tracked it down but am currently using a bit of a cobbled together combination of versions, with EvohomeClient using the old version of webclient and EvohomeOldClient using the new version of webclient!

                              Comment

                              • gordonb3
                                Automated Home Ninja
                                • Dec 2016
                                • 273

                                Originally posted by RichardP View Post
                                @Gordon
                                I've just tried the mechanism for getting more accurate temperatures from the V1 API. After some modifications. it's now working.

                                I had to make some modifications because the V1 API is returning the locations in a different order to the V2 API, so either you have to look at all the locations for the Zone ID or first look through the locations for the location ID and then find the Zone ID in that location.

                                I also got an access violation when returning from user_account with the new code, I've not tracked it down but am currently using a bit of a cobbled together combination of versions, with EvohomeClient using the old version of webclient and EvohomeOldClient using the new version of webclient!
                                Sounds like a recipe for conflicts all right.

                                I actually never trusted the order in which the web portal returns the zones in the json, even though the results from running the Python scripts seemed to indicate that it was okay to assume so. Somehow I seem to have overlooked that this applies to locations as well.

                                Comment

                                Working...
                                X