Watou,
Thanks again for your great plugin.
I’m using your plugin to automate many custom features not available in ecobee directly.
For example, I’m keeping my vacation home temp 40F (tstat min temp is limited to 45F).
But this can be dangerous if tstat looses communication with Vera in OFF position.
What would be a good test to notify if this occurs?
To check ecobee device status for valid token and CommFailure?
Thanks,
Theal
[quote=“theal, post:81, topic:174457”]I’m using your plugin to automate many custom features not available in ecobee directly.
For example, I’m keeping my vacation home temp 40F (tstat min temp is limited to 45F).
But this can be dangerous if tstat looses communication with Vera in OFF position.
What would be a good test to notify if this occurs?
To check ecobee device status for valid token and CommFailure?[/quote]
On every poll, the main plugin device will have its “status” variable (using service ID urn:ecobee-com:serviceId:Ecobee1) set to “0” if there is a communication problem (plugin to API) or “1” if there isn’t. It will only set the variable if it changes from its existing value. For good measure, you may also want to check the thermostat device’s “LastUpdate” variable (service ID urn:micasaverde-com:serviceId:HaDevice1) to be sure that it represents a timestamp that is not different from the current timestamp by too many seconds (your choice). Lastly, “CommFailure” will be set to “1” if the API reports that it cannot communicate with the thermostat itself, or “0” if it reports that the thermostat is connected. Together, these ought to give you a high level of confidence that you are getting a reliable status.
watou
Thank you watou,
Adding “LastUpdate” check to API status and CommFailure is a great idea.
Just need to figure out how to compare Epoch GMT time with Vera’s time.
A few question on ecobee3:
The Ecobee plugin is working great for both of my thermostats (primary & weekend home). I have a question (and wasn’t able to find the answer via search)…
I have a “Leaving” scene I use when I leave my weekend home (basically shuts everything down and sets thermostat to more extreme setpoints since the home will be unoccupied for an extended period). When I use the plugin to set those temperature setpoints, that is working fine. And my Ecobee thermostat shows “62-85 and Holding” as you would expect. My question…what mode is that hold? Right now, my Ecobee is configured to ask me what kind of hold should be used whenever I override the temperature (i.e. “Until I’m home”, “Until next schedule Event”, “Until I change it.”). Which of these types of hold is the Plugin temperature set using (I’m hoping it’s the “Until I Change It” which is essentially a true hold). Unfortunately, the Ecobee display doesn’t tell you that - it only tells you its holding, but not until something happens, if that makes sense.
[quote=“Sig, post:85, topic:174457”]The Ecobee plugin is working great for both of my thermostats (primary & weekend home). I have a question (and wasn’t able to find the answer via search)…
I have a “Leaving” scene I use when I leave my weekend home (basically shuts everything down and sets thermostat to more extreme setpoints since the home will be unoccupied for an extended period). When I use the plugin to set those temperature setpoints, that is working fine. And my Ecobee thermostat shows “62-85 and Holding” as you would expect. My question…what mode is that hold? Right now, my Ecobee is configured to ask me what kind of hold should be used whenever I override the temperature (i.e. “Until I’m home”, “Until next schedule Event”, “Until I change it.”). Which of these types of hold is the Plugin temperature set using (I’m hoping it’s the “Until I Change It” which is essentially a true hold). Unfortunately, the Ecobee display doesn’t tell you that - it only tells you its holding, but not until something happens, if that makes sense.[/quote]
Hi @Sig,
The plugin uses the “indefinite” (“Until I change it.”) hold type when changing setpoints, fan mode, etc., meaning it won’t change until you Resume the program or override it with a new hold. Using “indefinite” is hard-coded into the plugin, as opposed to the other hold types of “holdHours”, “nextTransition”, or “dateTime”. Someone who wanted the opposite of what you want, for example to have the hold expire when the schedule transitions to a new climate/comfort setting, would currently have to replace a few “indefinite” strings in I_Ecobee1.xml with “nextTransition” strings.
The configuration to say “always ask” is local to the thermostat itself, and of course the plugin has no way to ask you anyway. 
Regards,
watou
Thanks @watou. That makes complete sense and is what I was hoping for.
Anyone else install the Ecobee3 and have temperature change control? It gives the correct temp and humidity, but I cannot change the temperature in the vera. When I click the up or down arrows, it does nothing. Anyone else have this problem??
I just tried to change the heat setpoint up one degree on my ecobee3 via the plugin and it worked. I verified in the new web portal at ecobee.com. I then cleared the hold and it reverted to the schedule as expected. This was on Vera UI5 1.5.622.
Is the main ecobee device showing a grey or green “bee” logo? A grey one means that your tokens have expired and need to request and enter a new PIN.
I believe that there are remaining issues with UI7. I was given instructions on how to change the icons and make the one plugin work against UI5 or UI7 (by duplicating a number of JSON and XML files and selectively using one set or the other), but none of those instructions dealt with non-working setpoint controls in the UI. I am still awaiting instructions (or a pointer to documentation) that will help me understand how to change the plugin to work in UI7, but I was also told that there are outstanding UI bugs in the firmware for thermostat plugins. I don’t have an ETA.
If you are using and must use UI7, I suggest a mobile app like AutHomation (Android) or many other third-party solutions as a means of interacting with the plugin devices.
Regards,
watou
I don’t see any ‘bee logo’ on the vera.
see attachment.
[quote=“lavoyka”]I don’t see any ‘bee logo’ on the vera.
see attachment.[/quote]
You are on UI7, and I’ve been told that it has UI problems by Vera personnel, and that there will be fixes and further UI7 plugin developer documentation. I interpret all I’ve been told that fixing the setpoint UI problems is not in my control. I’ve been shown how to fix icon display, but I’m holding off on that cosmetic change until I can target a firmware that I know will be acceptable. If anyone has a better set of facts, please let me know. Thanks.
watou
[quote=“watou, post:82, topic:174457”]On every poll, the main plugin device will have its “status” variable (using service ID urn:ecobee-com:serviceId:Ecobee1) set to “0” if there is a communication problem (plugin to API) or “1” if there isn’t. It will only set the variable if it changes from its existing value. For good measure, you may also want to check the thermostat device’s “LastUpdate” variable (service ID urn:micasaverde-com:serviceId:HaDevice1) to be sure that it represents a timestamp that is not different from the current timestamp by too many seconds (your choice). Lastly, “CommFailure” will be set to “1” if the API reports that it cannot communicate with the thermostat itself, or “0” if it reports that the thermostat is connected. Together, these ought to give you a high level of confidence that you are getting a reliable status.
watou[/quote]
watou,
I implemented your suggestions into a custom alarm to monitor Ecobee on-line status and it worked well.
Yesterday my alarm notified me that API was down for a couple hours. Vera status box did not show any errors but urn:ecobee-com:serviceId:Ecobee1 Status was 0 and Vera/Ecobee communication was down. I manually re-registered the plugin with a new PIN and Ecobee was back on-line.
However, today API is down again for 10 hours, also with no error on Vera web interface.
Any insight on what is going wrong?
Thank you,
theal
[quote=“theal”][quote=“watou, post:82, topic:174457”]On every poll, the main plugin device will have its “status” variable (using service ID urn:ecobee-com:serviceId:Ecobee1) set to “0” if there is a communication problem (plugin to API) or “1” if there isn’t. It will only set the variable if it changes from its existing value. For good measure, you may also want to check the thermostat device’s “LastUpdate” variable (service ID urn:micasaverde-com:serviceId:HaDevice1) to be sure that it represents a timestamp that is not different from the current timestamp by too many seconds (your choice). Lastly, “CommFailure” will be set to “1” if the API reports that it cannot communicate with the thermostat itself, or “0” if it reports that the thermostat is connected. Together, these ought to give you a high level of confidence that you are getting a reliable status.
watou[/quote]
watou,
I implemented your suggestions into a custom alarm to monitor Ecobee on-line status and it worked well.
Yesterday my alarm notified me that API was down for a couple hours. Vera status box did not show any errors but urn:ecobee-com:serviceId:Ecobee1 Status was 0 and Vera/Ecobee communication was down. I manually re-registered the plugin with a new PIN and Ecobee was back on-line.
However, today API is down again for 10 hours, also with no error on Vera web interface.
Any insight on what is going wrong?
Thank you,
theal[/quote]
My two instances of the plugin seem to be running fine on firmware 1.5.622. I know of one ugly problem that shows if your LuaUPnP process is often crashing: when the plugin gets refreshed auth tokens, it saves them to device variables, but they aren’t written to disk except every few minutes (I believe so as to avoid wearing out the flash memory). If the process crashes (due to some other issue outside the plugin), then when it restarts, the plugin will try to use the old tokens. On a Vera that doesn’t have a crashing problem, the fresh tokens are written to disk properly and so it will use the correct tokens on restart. Could anything like this be happening in your case?
watou
My two instances of the plugin seem to be running fine on firmware 1.5.622. I know of one ugly problem that shows if your LuaUPnP process is often crashing: when the plugin gets refreshed auth tokens, it saves them to device variables, but they aren't written to disk except every few minutes (I believe so as to avoid wearing out the flash memory). If the process crashes (due to some other issue outside the plugin), then when it restarts, the plugin will try to use the old tokens. On a Vera that doesn't have a crashing problem, the fresh tokens are written to disk properly and so it will use the correct tokens on restart. Could anything like this be happening in your case?watou
I’m running firmware 1.5.622 on VeraLight.
How can I check for LuaUPnP crash?
I did a couple soft reboot and “reload” but that did not help. I’m currently away so I can’t do hard reboot.
I did noticed that during a “reload” there is no notification that Ecobee plugin being initialized. Could this be a problem and how I can troubleshoot this?
[quote=“theal”]I’m running firmware 1.5.622 on VeraLight.
How can I check for LuaUPnP crash?
I did a couple soft reboot and “reload” but that did not help. I’m currently away so I can’t do hard reboot.
I did noticed that during a “reload” there is no notification that Ecobee plugin being initialized. Could this be a problem and how I can troubleshoot this?[/quote]
If the problem was like the one I described, it can be corrected each time by getting and entering a new PIN, which can be done remotely. This would suggest the crashing problem if the token keeps failing.
I think the best thing is to look at the logs to see what is going on, when you are able to collect one right after startup (and scrub any private information). If you add LogLevel 35 to the list in cmh.conf, you will get debug output as well.
There are some tools that can help determine internal metrics like memory, CPU, etc., but there are forum participants who know a lot more than I about them.
watou
@watou, have they exposed the sensors yet, now that they are in their dashboard? Looking forward to taking advantage of those in vera!
I am also looking forward to seeing those exposed in the API, but I don’t believe they are there yet. I follow this thread on their support forum:
http://developer.ecobee.com/api/topics/access-to-ecobee3-sensor-data-via-api
Please ping me if you hear of a positive change in status.
watou
I am also looking forward to seeing those exposed in the API, but I don’t believe they are there yet. I follow this thread on their support forum:
http://developer.ecobee.com/api/topics/access-to-ecobee3-sensor-data-via-api
Please ping me if you hear of a positive change in status.
watou[/quote]
Cool… will do!
One possible workaround for variables losing their value because of a LuaUPnP crash is to save the value in 2 places: in the state variable, and in a file in /tmp (which is in the RAM), as backup. And, when the plugin starts, check if the value from the variable is different than the one in the file. If it is, load the value from the file, and update the state variable. Since the files will be saved in the RAM, they will disappear when the Vera reboots, but that happens a lot less often than a LuaUPnP crash.
Good suggestion; thanks for that idea.
watou
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules