Hey everyone,
I’m struggling to see if anyone is having the same issue as me? OpenHAB 2.4.0 Stable running Evohome 2.4.0 binding but get the following error when I try to login (UK Evohome User). I’ve tried this on both my Pi and running a local instance on my Windows 10 Machine:
2019-09-08 19:06:50.838 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.evohome.handler.EvohomeAccountBridgeHandler.checkInstallationInfoHasDuplicateIds(EvohomeAccountBridgeHandler.java:156) ~[?:?]
at org.openhab.binding.evohome.handler.EvohomeAccountBridgeHandler.lambda$0(EvohomeAccountBridgeHandler.java:86) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[?:?]
at java.util.concurrent.FutureTask.run(Unknown Source) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:?]
at java.lang.Thread.run(Unknown Source) [?:?]
The Evohome Thing stays in status “INITIALIZING”. Any ideas?
In my instance, EvoHome fails to operate correctly when installed via PaperUI. I uninstalled the binding via PaperUI and manually put the binding in the /addons folder then added the Things via PaperUI…and success!
I have also reported that something is wrong with the embedded version. Earlier it was not possible to install. I use 2.5.0M3 on windows10 and binding works well. I have text file setup.
Im consideting buying the evohome system, but i dont want to be stuck with the cloud stuff, so it would be really good if the binding supports local control. My question is, does it?
evoHome is a cloud solution.
You can control rooms from OH via the plugin but it still relies on internet and the evoHome api.
There is, but I cannot find the link now, a hand-rolled solution which transmitts to the HR92 and makes them open and close. You could use this to remove the evohome cloud options but it’s a bit of a hack.
If you rather not do that then have a look at the many other direct options like Max! or Tado or many of the plain electric solutions.
Heya guys, it’s been a while since I checked here Let me try and answer some of the questions here:
@smar: Nice! Great that you can send commands to the HCI80 as well. As for me, I don’t have a HCI80 nor do I have budget to buy one anytime soon. So unless I get one sponsored/borrowed, it would be pretty hard to integrate it into my binding. If I would have one, I’d be willing to integrate it into the binding gladly. Conversely; if someone wants to implement it theirselves you could always create a PR for that feature. It doesn’t need to be all my code
@lsiepel I think that it would be very possible to integrate it, but, like stated above don’t own that hardware myself so that would be my greatest hurdle.
@mossc001, @kovacsi2899 OH2.4 does not work. You need to use the version on my github for that (see opening post). OH2.5 works out of the box.
@domofl, @CDriver evohome, without a HCI80, is indeed a cloud solution. The HCI80 is not supported from the binding, for the reasons mentioned above. Ergo, the current evohome 2.0 binding relies on the cloud platform (and availability) in order to work.
Not sure if it was clear from my previous posts, but you can use an arduino with a CC1101 radio card instead of an HGI80. Cost for parts is less than £6 from ebay etc.
Got any links or examples for this? That would be cool.
Point is though, the binding still goes via the cloud.
Hand cranking your own solution allows you to use OH > MQTT > arduino > radio > trv.
If paired to the base I expect it’ll cause confusion.
Not sure what you mean by this. evohome continues to use its normal controller. The (fake) HGI80 is simply another device on the evohome radio network that can send/receive radio messages.
Hi,
Having same issue here. Upgraded to 2.5 and now I get an authentication failed for EvoHome. Can you explain what you did to resolve? I’ml not an IT Linux expert at all so some details would be appreciated.
Txs!
Luc.
neither am i
check the date command and see if its the same as your local time.
If not, you have to set your timezone correctly, or else the ssl certificate will fail when logging into evohome.
Hi All,
Today after upgrading to OH 2.5, my evohome config was not working anymore and EvoHome account configuration in Paper UI was throwing the “Authentication failed” again. Good thing is that I found a very easy way to resolve it:
a. Goto : Configuration>Things>evohome Account
i. Edit username to a dummy one and save
ii. Edit again to right username (email address) and password and save again.
b. Check if authentication worked
oh, yeah, I forgot about that one! However, when you have full control over all traffic, what benefit would you have from the binding? You could just as well use MQTT or likewise so set up everything, or am I missing something?
The main benefit would be the auto-discovery of things, unless the MQTT HA/Homie discovery is implemented. Another (small) benefit would be that users have the option to switch between the two methods, in case one is down, from a single solution.
Ok, then I understand what you are saying. For me it would make more sense if the 'home-brew HCI-80" would actually implement the full features from the HCI-80. Then one could choose the “easy-way-out” of buying one, or the more fun way of rolling your own.
Thanks for this it works really well.
When I have used the integration on SmartThings any set point is set until the next switchpoint, rather than it being permanent.
Is there anyway of achieving this functionality with this binding?
It is a useful failsafe, if for any reason EvoHome does not receive the command from HA to cancel any setpoint override at some point the schedule will cut in and restore it at some point in the schedule.
For example in my house the setpoints all revert at 23:00 on the EvoHome controller itself.
Yes, that’s a fair point. My understanding is that they are functionally equivalent, except that the HCI-80 has improved radio reception and picks up some messages that don’t get through to the home-brew.
Anyway, your current binding is working well with the web api, and as you say, it is not that much of an issue to use the hardware solution via mqtt, and so may be not worth the effort in integrating.
Let me try and answer some of the questions here: