I’ve added “nextTransition” which works, as does the holding climate ref, albeit it only displays anything when its on hold.
Do you think its possible to add a change to “heating / cooling /off” mode action as well as a temperature up / down button? This binding seems to be working better than the ecobee app for day to day use so far!
One other thing, using the windows designer I was using before the action bundle - V1.8 nightly build from 12/8/15 works well apart from it doesn’t understand the ecobee action commands, and now that I’ve edited a couple of them won’t open the rule file. Using the one I downloaded recently results in many errors showing up in the code at random, so I’ve reverted to the earlier one, using notepad++ to edit the rule file with the ecobee actions in it. Should I start a separate thread about this?
Glad you have things working. You can change the heat/cool/auto/off modes by sending the proper command or update to an item bound to settings.hvacMode.
You can use a sitemap Setpoint and a rule to send off ecobeeSetHold action calls for up/down temperature holds.
You have to have openHAB 1.7.1 runtime or nightly plus nightly binding/action bundles for Ecobee (or more recent than what you are using) for openHAB Designer to recognise the Ecobee actions. If updating all of these to after their merged PRs for showing actions in Designer doesn’t work for you, then yes please open a new topic.
settings.hvacmode added and working - thanks yet again! The sitemap Setpoint may take a little longer to develop so I’ll keep it at the back of my mind for now.
On a different subject, how does one get a binding developed? I have Sensibo devices controlling my other HeatPumps and when they open up their API I’d like to get them included. Currently I use IFTTT to connect to them but its limited in what it can do. Unfortunately I don’t have the programming knowledge to develop the binding myself.
It depends on what kind of API Sensibo exposes. Ideally, you could use the HTTP or other “generic” binding, but what they expose may not work that way. If a true binding is needed, if i were you I would post a new topic here and perhaps other places to see if there is interest from a Sensibo user to develop a binding. But if the API is not yet available, it’s still hypothetical about what’s needed and what’s possible.
I’ve requested an access code so will report back once I’ve got one.
Moving onto Ecobee, it failed this morning the first time I sent it a command, then when I discovered nothing had happened I sent it again and it went through. Is this likely just something it does and I need to put in a check for hold status change and add send again logic if it doesn’t? Looking at the log times I think the command either was ignored when it was sent and no error was given or it disappeared into a hole OR after a minutes timeout the binding returned an error? Presumably sending the same command twice won’t have any adverse effects if I only do it when I suspect it hasn’t worked?
2015-09-08 07:19:07.314 [INFO ] [hab.model.script.HouseHeatpump] - received command wakeup - I DON’T THINK THIS ONE DID ANYTHING
2015-09-08 07:20:01.037 [WARN ] [g.openhab.io.net.http.HttpUtil] - Method failed: HTTP/1.1 500 Internal Server Error
2015-09-08 07:20:01.041 [ERROR] [.ecobee.internal.EcobeeBinding] - Authentication failed. Unexpected error. Contact support.
2015-09-08 07:20:29.434 [INFO ] [hab.model.script.HouseHeatpump] - received command wakeup - THIS ONE WORKED
Very, very rarely I’ve seen “Authentication failed. Unexpected error. Contact support” on a regular poll and it recovers on the next poll. Maybe 2-3 times total. If you set the binding to DEBUG or (better yet TRACE) logging level and try again, there might be more context to see if there is anything in the binding or action bundle to address this. Hopefully this can be reproduced.
The message “Method failed: HTTP/1.1 500 Internal Server Error” occurs when tokens expire and need to be refreshed, so that’s usually normal.
You could also check to see if the ecobeeSetHold action returns true (success) or false (failed).
How can I turn on TRACE exactly for only the ecobee binding? Presumably something in logback, but what (newbie alert!)? I’ll then run it for a few hours and look to see what I can find.
I’ve taken a look at the trace log and discovered it was querying the ecobee servers every minute when I should have been every 3 minutes. Since changing that the communication error causing stack dumps have come down from 28 in 16 hours to 1 in 10 hours so that looks like one problem held over from V1.7 that I may have fixed, although the 10 hours have coincided with the middle of the night in the Northern Hemisphere, so I need a few more hours before I can be sure.
The automatic profile changing rules are now almost perfected too Further updates in a few hours.
Several hours on and sadly the stack dumps haven’t completely gone away. Part of the problem it seems is due to server load, and some happened when commands were issued. Would you like to take a look at the logfile post 3min polling?
What stack traces in which log file? Do you think that they may signal a bug in the binding, as opposed to network or API server issues? If the former, please share the stack traces that you are concerned about. Thanks!
The stack traces in the full logging I turned on for the binding recently.
I’ve just taken a look at the recent stack traces - 9 in 11 hours and think they may just be communication failures, most happened in the middle of the night here so they are likely nothing to do with the action bundle. The binding seems well behaved, and the action bundle seems to be working well controlling the stat.I guess I’ll have to live with the communication failures!
Hopefully Ecobee improves the network or server-side issues so API calls come back more quickly. I think they have sold so many units that their services might be under heavy load (just a wild guess).
Ironically its been playing up for the last hour of so. I thought I’d broken it as I’d restored the Pi from an image taken earlier in the day and I did eventually end up reauthorising the App.
However just now it has taken 23 seconds from clicking hold on the ecobee web page to when it stopped showing the update bars, then it was around 1:30 from hold press to it showing in the webpage, then finally at 3:25 the thermostat reflected the update. During the last few updates the binding has timed out every time with it taking 10 seconds from querying message to stack dump.
How long can you make the timeout take? With the performance right now it needs to be measured in minutes!!!
Can it be anything that is set that is below the the polling time? I’ll then set it ridiculously high and see at what point it stops working. I was amazed that the setting I did from the web actually went through at all, but it did, and it took me 8 minutes to reauthorize the app! I think when it had the huge slowdown they were either doing something on their servers that was causing a massive disk queue or they were being attacked.
Mine has gone back into timing out every time and the last successful communication was a full retrieve that took 12 seconds which is pretty close to the 15 second timeout. Its timed out on the last 4 cycles.
OK, I’m testing a change to add ecobee:timeout to openhab.cfg. If it seems to improve matters, I will share a JAR to you and you can tell me if it helps.
