My log has many errors from the Ecobee Binding, is there a way of fixing this? Or if its to be expected is there a way of turning off the logging for this binding only?
Error times:
00:20, 00:34, 02:46, 04:43, 05:14, 06:30, 06:46, 07:21, 08:52, 11:23, 11:25, 11:26
Error messages:
2015-08-25 11:26:12.449 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.UnknownHostException: api.ecobee.com
2015-08-25 11:26:12.461 [ERROR] [.ecobee.internal.EcobeeBinding] - Error reading from Ecobee:
org.openhab.binding.ecobee.internal.EcobeeException: Could not get thermostat summary.
at org.openhab.binding.ecobee.internal.messages.AbstractRequest.newException(AbstractRequest.java:57) ~[na:na]
at org.openhab.binding.ecobee.internal.messages.ThermostatSummaryRequest.execute(ThermostatSummaryRequest.java:76) ~[na:na]
at org.openhab.binding.ecobee.internal.EcobeeBinding.readEcobee(EcobeeBinding.java:278) ~[na:na]
at org.openhab.binding.ecobee.internal.EcobeeBinding.execute(EcobeeBinding.java:257) ~[na:na]
at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:156) [org.openhab.core_1.8.0.201508100132.jar:na]
at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:173) [org.openhab.core_1.8.0.201508100132.jar:na]
Caused by: java.lang.NullPointerException: null
at java.io.StringReader.(StringReader.java:50) ~[na:1.8.0]
at org.codehaus.jackson.JsonFactory.createJsonParser(JsonFactory.java:636) ~[na:na]
at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1854) ~[na:na]
at org.openhab.binding.ecobee.internal.messages.ThermostatSummaryRequest.execute(ThermostatSummaryRequest.java:72) ~[na:na]
… 4 common frames omitted
I’ve seen this before, and it means that for some reason, your openHAB server’s ability to resolve the hostname api.ecobee.com to an IP address failed at the time it was attempted. This could be due to a network/Internet/ISP problem that comes and goes, or even a networking problem on the server itself. The binding will recover when (if) the problem clears. In any case, it’s a network-level error that might require network troubleshooting if it persists.
If you don’t want the stacktrace in your log, you could add the %nopex modifier to your logback.xml file to suppress the exception dump.
I have a test version of the binding JAR that moves this often-occurring message to a WARN level and only logs the exception message, not the entire stack trace (unless you have DEBUG level set, in which case you also get the stacktrace). If you would like to replace your current binding JAR with this one and report back, I would appreciate it.
Thanks, addon loaded, will let you know how it gets on.
That’s way better, only messages now are
2015-08-26 09:11:32.280 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
2015-08-26 09:11:32.283 [WARN ] [.ecobee.internal.EcobeeBinding] - Exception reading from Ecobee: Could not get thermostat summary.
My guess is I can manipulate logback.xml fo trim this back to a single line which is perfect.
Thanks for the update!
I’m getting no errors in the log but I’m not getting any data back from Ecobee. Is anyone else having issues. It worked fine yesterday.
My two instances have been experiencing occasional read timeouts, most likely due to network or server capacity issues but I can’t say for sure. This is always logged, however, and always recovers soon thereafter. You may want to make logging verbose as explained (or similar to what is explained) at the bottom of the Ecobee binding wiki page.
For some reason I had to “Remove” the application from MyApps on the ecobee consumer portal, for my thermostat, and then add it again using the PIN from the openhab.log (ecobee log in my case now). As I already had said I did this once before and it was working. I’m guessing there was some issue on ecobee’s end. I’ll see how long this connection lasts. Thanks for your help and ideas. I did add the verbose separate log btw, I’ll be looking at that as well.
Hi George, glad that cleared it up, but I couldn’t tell you why that would have made a difference. If you see a problem that looks like it’s in the binding, please let me know. In the meantime, I have a test JAR that you can use with a new ecobee:timeout config parameter in openhab.cfg, if you are seeing repeated timeouts due to slow responses from the API servers. The default is 10 seconds, but I’ve been using the new parameter set to 20000 (20 seconds) and haven’t seen a timeout since.
Thanks very much, I’ve just installed it will see how it goes. Its the middle of the night in Toronto again and retrieves are taking between 3 and 9 seconds so that 10 second timeout would have been marginal for my location assuming it measured from first command to last item received. I’ve got 11 items in the retrieve now which also will I’m guessing slow things up.
Apparently they did a software update last night which made the system slow to a crawl, I also had to redo my PIN again today, but I think that’s down to restoring an image from a day ago,
Correct. The older image contained only expired tokens, so the only recovery is to enter a new PIN. It’s good to know the system is secure that way!
Please report when you think ecobee:timeout has or should have helped, and thanks.
John
Progress report 18 1/2 hours in, with it set to a 30 second timeout and there’s not been a single stack trace, which is a big improvement.
However please let me perfect my control rules before we call it a total success as last night when I’d turned it off, it later changed itself to Auto, so I need to try and find out where the command came from, the mobile app reported .
“javax.net.ssl.SSLException: Inbound closed before receiving peer’s close_notify: possible truncation attack?” a few seconds later so it could be caused by a communication problem as I get that message when I put the phone to sleep, or if it hasn’t got good coverage.
The unwanted change started with “internalReceiveCommand” so I suspect it came from within Openhab, although I don’t use “auto” in my control rule so it could have been from the client
Thanks for reporting, Kevin. I don’t really follow what you’re describing, but I can wait for an all-clear from you regarding the new ecobee:timeout config parameter if you think it’s not settled that it’s a positive step.
Several hours later and still not a stack dump in sight - I reckon I can give this one the all clear, and the error I received would have come from a communication error with the mobile client, this is a very extensive reliable binding, thanks again for your help.
Now its time to have a play with the Sensibo API…
Glad it’s working, Kevin. I’ve merged the ecobee:timeout feature into the binding, and also changed the default timeout from 10000 to 20000. I’ve also updated the wiki page. This is available in the 1.8 nightly builds going forward.
Thanks, I’ll swap to a nightly over the weekend just to keep current