There are some Windows PowerShell scripts too written specially for the schedule but can be amended for anything.
Decoded - EvoHome API access to control remotely.
Collapse
X
-
Thanks for the link.
I have never done any HTTP type programming before, although I have 30 years C/C++ experience.
I don't want to use Domoticz, just integrate Evohome data into an existing app that I have that monitors our Solar PV system. I've downloaded the evohomeclient and webclient source and this references curl/curl.h and json-c/json.h. Where can I get these from?
Sorry if that' a stupid question, as I said, I've never done anything like this before.
Comment
-
-
This is obviously way outside my capability.
Following the instructions for building curl gives several warning like this
Crypt32.lib(CRYPT32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in ws2_32.lib(WS2_32.dll); second definition ignored
Crypt32.lib(CRYPT32.dll) : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
followed by an nmake fatal error
Copying libs...
NMAKE : fatal error U1073: don't know how to make '..\src\tool_hugehelp.c'
Stop.
No idea how to build the json-c stuff for Windows either. I'll just crawl back into my hole and forget about it, I've already spent far too much time getting nowhere and it was just a nice to have extra.
Comment
-
-
I think I may have had some issues with this as well.
Reason for choosing curl and json-c is that these are more or less standard libraries in Linux and this is my main target. Windows appears to be something of a different beast though. I think the versions that I managed to get working with VS 2015 is curl 7.51 and json-c 0.11-20130402
Should note that I had to rewrite all the json related stuff when integrating this client into the main Domoticz apllication. I may do the same conversion for this project, which would eliminate the need for json-c. The curl dependency will definitely stay though.
Comment
-
-
Well, I've got a 'little' further after using curl 7.51 which did actually compile.
Compilation creates an executable and a .lib.
I tried including the .lib with the appropriate includes, but I get a load of curl unresolved externals.
I tried running the curl executable with the command line parameters detailed earlier in this thread, but get :
curl: (1) Protocol "'https" not supported or disabled in libcurl
This seems to indicate that I don't have OpenSSL. I do have it but have no idea what to do with it!
For Windows this stuff is a house of cards, open source project, upon open source project, upon open source project.
Comment
-
-
You might be better of setting up Domoticz and then using its data-push functionality to push the data into your other system. At least that way, all the API stuff is dealt with for you, and it's actively maintained (mostly by DanD) so you'll benefit from incremental improvements over time, too.
Comment
-
-
Something of a deja vu. I think the Windows make environment may not default to include any ssl. "not enabled" is probably the key here. Bang my head. I really should have made notes, but I was struggling so much to make that unfamiliar environment work that I simply forgot. I was just happy to have an environment that allowed me to compile the code that I was actually concentrating on.
Comment
-
-
Well, I now have it compiling as part of my original app, but I've not had time to actually run the Evohome bit.
After going back to curl 7.51 I had lots of unresolved externals. This was because the curl include turns off C++ name mangling, but the compilation of the curl library does not. A quick edit of the include from
define CURL_EXTERN extern __declspec(dllimport)
to simply
define CURL_EXTERN extern
fixed that problem.
I also had one unresolved external in the json-c library. For some reason I've not yet ascertained, the two calls to _set_last_err in json_c_set_serialization_double_format could not be resolved. Odd, as there are other calls to this routine in the json-c code. As it's just an error message routine, I commented it out for now.
I'll try and actually connect to the Evohome web site this evening.
Comment
-
-
More progress!
I've successfully created an EvohomeClient object which logs into the system!
Running the full_installation method shows that there are 3 Locations, which is correct.
Each Location has a single Gateway.
Each Gateway has a single Temperature Control System.
The Temperature Control Systems then have the correct number of Zones for that Location (5,9 and 5).
That's as far as I've got so far, but at least it's working!
Things that I'd have thought would be visible by now but are not are :
The Hot Water system, I can't see anything that relates to it.
Location and Zone names, they have IDs but no descriptive name.
The current and set temperature for a zone. I can't see anything obvious that shows how to get this, but I've only spent a few minutes looking so far.
Edit :
I can now see which location has a Hot Water system, but can't see any information about it.
Edit :
I have now extracted the location and zone names from the json object.Last edited by RichardP; 20 June 2017, 05:21 PM.
Comment
-
-
I think the Hot Water system is only visible in status. Don't have such a device myself (I'm on city block heating) so I can't verify this. However I just looked in my main code and I also retrieve zone names from status.
Straight forward app would look something like this:
Code:eclient.login(user,password); eclient.full_installation(); int location = 0; int gateway = 0; int temperatureControlSystem = 0; EvohomeClient::temperatureControlSystem* tcs = &eclient.locations[location].gateways[gateway].temperatureControlSystems[temperatureControlSystem]; eclient.get_status(location);
Comment
-
-
Just found the hot water temp, it's under "dhw" "temperatureStatus" "temperature".
Now I've got the basics working and a very basic understanding of how the json objects work, it should be just a question of reading bits I want for now, control can come later.
Thanks for all your help so far!
Comment
-
-
Steadily making progress, the Evohome planned maintenance this morning did not help.
I found that the evohomeclient object leaks a lot of memory because it does not clean up the json objects that it creates. When finished with an object it should call json_object_put to reduce the reference count and free the memory once it reaches 0.
Comment
-
-
Originally posted by RichardP View PostI found that the evohomeclient object leaks a lot of memory because it does not clean up the json objects that it creates. When finished with an object it should call json_object_put to reduce the reference count and free the memory once it reaches 0.
Comment
-
-
Using this right?
Assume you have a login? (if not apply and it will get done)getconnected.honeywell.com | I work for Honeywell. Any posts I make are purely to help if I can. Any personal views expressed are my own
Comment
-
Comment