I now have an error, “Honeywell[211] : Startup Lua Failed”. I had this error with the first version you posted today. I deleted it and while trying to troubleshoot it, you posted the newer version with less variables. Then I tried again and still have the error.
This version now checks for dkjson (UI7) and if not present looks for json-dm (UI5). Hopefully this resolves the issue.
Everything looks good so far. I will keep an eye on everything to see how it plays with the ping sensors. I now have good access to my logs, so I should be able to provide debug information if the ping sensors fail.
[quote=“Colorado-Al, post:471, topic:185402”]Regarding humidity, I have a few humidity sensors and they all create a basic child device that just shows humidity and is not configurable.
Would be great to help with running humidifier on demand. I could certainly just buy 2 more sensors, however would be nice to just get the reading from the thermostat. If the info is included in what you’ve already provided, then I’m sure I can create a child device from it.[/quote]
I don’t know if you ever got what you needed here, but as Mikee mentioned, you can indeed read the indoor humidity from the thermostats with this plugin. It is not a “child device” as you mentioned your other devices are and thus will not have a “dashboard display” like those devices. But using this plugin with the Honeywell thermostats, there is a variable called “IndoorHumidity” which can be read & used by PLEG for any logic that you would want.
@backkriHere is the updated plugin. I verified I can set the temp on both of my thermos. You should not need to set your device Ids manually, they should be found on login.
Great!
All the room thermostats of my Evohome system now appear correctly with this version 
Without need indeed to configure ID’s manually, and with correct temperature reading.
Once I have more time, I will look into the parameters (have no fan or cooling mode) and the way to change the setpoints (for now, when i switch to heating mode and change the setpoint, the setpoint is sent to the system but directly afterwards the display changes to off again in Vera) and the way to make the change in setpoint temporary (for the moment, the change is permanent in the Evohome although setting says TEMPORARY). I will read the 33 pages in this post to better understand how I should use this app (when I have more time later :P).
Glad to hear it is mostly working.
Post 1 and 2 have most of the info ,JoeyD did a great job of documenting this. I have tried to preserve all of the user facing aspects of the plugin while adding support for Lyric and Evohome.
I did make the setpoints permanent as I am confused as to how to get the “until” time from the vera user. The UI allows you to change the setpoint up or down but has no provision for hold time. I have tried to add things to the thermostat display but it is internally hard coded. The bottom line is the API seems to want the hold time explicitly set and I don’t know how to get this value. The API for the US does not have a hold time, just hold until the next scheduled change.
I am testing with US thermostats. I don’t know if these are the same as yours. I will need a log file captured with LogEnable and TraceEnable to help figure out why you can set the temp (advanced properties of the TCC device, the one you log into). The log will contain your passwords so please edit it before posting to remove them.
About the mode behavior: I think I understand now that this does not reflect the thermostat status, but simply the internal Vera state: if setpoint is higher than actual => heating. Otherwise the thermostat goes to off.
About the log files: I am afraid I have the same issue as lingerba with the second part (also use Putty):
If you have ssh access you can type 'grep HNYWL_TCC /var/log/cmh/LuaUPnP.log > res.txt'. Then exit back you your host machine and run 'scp root@:res.txt .' and enter you password. You can then sanitize this file and send it.
In my installation, I use these:
[url=https://www.waakzaamwonen.com/kleuren-evotouch-bedieningspaneel-exclusief-wand-of-tafel-standaard-p-758.html]https://www.waakzaamwonen.com/kleuren-evotouch-bedieningspaneel-exclusief-wand-of-tafel-standaard-p-758.html[/url] central unit
[url=https://www.waakzaamwonen.com/rfg100-internet-gateway-voor-toegang-tot-evohome-systeem-met-smartphone-p-766.html]https://www.waakzaamwonen.com/rfg100-internet-gateway-voor-toegang-tot-evohome-systeem-met-smartphone-p-766.html[/url] gateway
Combined with HR80 valves and DT92 as temperature sensor. But main communication goes trough gateway to central Evohome unit.
You can use CudaNet’s instructions in post #366 to install Info Viewer. Once you have this installed access to logs is much easier.
Just installed this plugin… I put in my credentials, and it doesn’t find my Therms… I get ‘Honeywell TCC Authorization passed, but no devices were found.’ I can log in manually and see my devices… Any ideas?
Which interface are you using ?
If you are using the version of the app from the app store it doesn’t work. Please read through this thread. You can download a beta copy to use while @Mikee continues to work on a fix.
@mikee - Great job! Are you planning on getting the new VeraPlus? I’d like to but may wait until we have definite support for these devices.
Happy new years everyone ! I’m back and hoping everyone had a great time off with friends and family…
@Mikee,
Awesome progress on the plugin ! Have you slept at all ?? It seems the plugin now supports most/if not all the stats from Honeywell, it’s time for an official Honeywell forum.
I was able to successfully install your latest package (many threads back) on my openLuup system (developed by Akbooer). Install was nice and clean, plugin practically set itself up … Nice ! The stats displayed and operate beautifully in AltUI. I did this late Saturday night when I got back into town. I noticed this morning that the system (openLuup/AltUI) did freeze on what appears to have been a refresh of the stats. Both the AltUI and openLuup logs stopped on the same entry (refresh of stats 1-8). Unfortunately I didn’t have the enhanced logs enabled via the plugin so I can’t say why. I’ll try to catch up on some updates you’ve posted or I’ll just hold off until you post the latest package. Until then I’ve enabled the detailed logs and hope to catch anything lingering out there.
Glad to have you back. I have been trying to reproduce the issues lingerba is having with the ping sensors, yes it seems things just stop. I suspect it is a network issue so If it can be reproduced on OpenLuup it may help isolate it. I just can’t get it to fail here. I’ll try to setup openluup, I downloaded it but did not set it up yet.
I remember Lingerba mentioning an issue with the ping sensor. Hmm, network related issue. Odd to say the least. If it’s network shouldn’t we simply see it time out. openLuup and AltUI (in debug mode) along with the trace logs from your plugin should (hopefully) produce some results we can work from here.
I’m here to help, just let me know what you need…
[quote=“mikee, post:494, topic:185402”]@CudaNet
Glad to have you back. I have been trying to reproduce the issues lingerba is having with the ping sensors, yes it seems things just stop. I suspect it is a network issue so If it can be reproduced on OpenLuup it may help isolate it. I just can’t get it to fail here. I’ll try to setup openluup, I downloaded it but did not set it up yet.[/quote]
Tonight I’m going to load this plugin on my openLuup test server (rPi2) with nothing else running (no other plugins/scenes/etc.). Hopefully that will remove any doubt that others might not be playing well together and allow us to isolate the root cause.
You can use CudaNet's instructions in post #366 to install Info Viewer. Once you have this installed access to logs is much easier.
Info Viewer was already installed. The pattern function was new to me. I attached a log file while I was changing the setpoint (in the end the mode turned to off automatically).
For your information: since I installed the app (and / or enabled logging) the number of LUA restarts increased to 5 or 6 / day (before this was very limited).
Thanks backkri. Yes, clearly there is a problem with the plugin. lingerba and CudaNet are helping to isolate it. I can’t seem to get it to fail here. I’ll go thru the log and see what I can find.
Just an FYI, plugin installed on my test system (latest openLuup and AltUI). Nothing else installed and it’s not bridged to an actual Vera. All log traces/HTTP and AltUI debug enabled. Going to let it run and see what we catch.
Thanks CudaNet. I installed it on my OpenLuup setup as well and it is running. I had/have some trouble getting it setup. I now have 4 sets of thermo devices and can’t delete them but it is running so hopefully we’ll see something.
In the mean time I ran the plugin instrumented with collectgarbage(“count”) and collectgarbage(“collect”) calls sprinkled about. I found that the main plugin code is about 150K bytes, each interface is 20Kish and the libraries I load are 30-95K for a total of about 370Kbytes when done. Seems small to me when I have 15M free but when I instrumented the Info Viewer it uses 120K bytes total. I modified the plugin to only load the interface it is using and reduced the usage by 100K. I am also running with a collectgarbage(“collect”) after each refresh. Typically there is about 500K bytes in use but it has been up to 1Mbytes before running garbage collection. I don’t think this should be necessary but perhaps. Any guidance in this area would be greatly appreciated.