I’ll try to fill in the blanks tomorrow about the log issue, that way everything I’m testing/doing is on the same machine for consistency 
I’ll also update my items to reflect the string in SetPointStatus rather than the number and see what that does!
Downloaded base OH2 zip file, unzipped it and then copied the addon and my simple config into the directory.
Run from terminal using ./start.sh
This is the openhab.log that gets generated.
openhab.log.pdf (23.0 KB)
Just to reiterate, it doesn’t stop the binding working and doesn’t happen if I stop OH, clear the logs and the restart OH. I assume it’s just Java being Java and once OH is running it isn’t an issue ever again. I’ve ONLY seen it on the latest version as well.
Just for completeness here’s the PaperUI for the lounge:
And the Basic UI via sitemap for the same room
Hi guys, a small personal update. I’ve seen some issues raised on github which tells me that more people start using the binding. I am very excited to seeing this and it motivates me to continue.
However, with a new house, a new client starting up and a pregnant wife I’m afraid that my time is stretched thin for the upcoming weeks. Moreover, I won’t be owning an evohome for a while since I’m selling my current installation with the house. I’ll try to mock the response data in the intermittent time.
For now, please keep testing and creating issues so we can make this a full featured binding!
Regards, Jasper
Jasper,
I’ll do my best to keep breaking it and getting issues raised.
We’ll see you back soon.
Nick
Looks like the binding doesn’t work with the new 2.1 release of OH:
2017-07-12 11:40:08.772 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.evohome-2.1.1-SNAPSHOT-2.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.evohome [9]
Unresolved requirement: Import-Package: com.google.common.collect
at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:392)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1253)[4:org.apache.felix.fileinstall:3.5.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1225)[4:org.apache.felix.fileinstall:3.5.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:512)[4:org.apache.felix.fileinstall:3.5.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:361)[4:org.apache.felix.fileinstall:3.5.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:312)[4:org.apache.felix.fileinstall:3.5.6]Restart OH 2.1 for some reason it will work after a restart.
Looks like i’m getting loads of weird errors with OH 2.1 full stop, network and zwave bindings now not playing ball, but evohome did connect after a restart. Will try a few more things
An initial note to say that i’ve just tried the lastest snapshot (2.1.1) on openhab 2.2 snapshot and I’m truly impressed with it’s “just works” aspect. Absolutely cracking job, i will report bugs as and when I found them.
A thought on an above comment about how best to set the setpoints (given a time is required). I would suggest as a start point the easiest way to do this would be to follow the controllers implementation and automatically override until the next scheduled changed (I assume the webapi allows you to pull the current schedule and find out what the next point is 
)
Other options I can think of would be
I’d also suggest that it’d be really handy to give a minor update SOMEWHERE revealing this new functionality. I spent ages this morning playing with the 1.8 version before accidentally finding the 2.x version when scrolling through the thread. Perhaps either an update to the first post or a new thread.
I tried the binding and it works like a charme! Nice!
Just to be sure: at this point the binding only displays information and is able to set modes (Away, Off, etc). It is not possible to set the temperature of an individule room? Or am I mistaken?
At this point it only displays info on your TRVs and general mode. Setting temperature set points and retrieving hot water information is being looked at by the binding authors.
Ok thanks!
finally got this working!
Still missing something, posted to github, so will post it here too.
im only missing some stuff from the 1.9.0 addon like:
Number Bedroom_Radiator_Current_Temp "Bedroom Radiator Temp [%.1f °C]" { evohome="locationName=LOCATION_NAME,deviceName=DEVICE_NAME,type=THERMOSTAT_TEMPERATURE" }
Number Bedroom_Radiator_Target_Temp "Bedroom Radiator Target Temp [%.1f °C]" { evohome="locationName=LOCATION_NAME,deviceName=DEVICE_NAME,type=THERMOSTAT_SETPOINT_VALUE" }
String Bedroom_Radiator_Mode "Bedroom Radiator Mode [%s]" { evohome="locationName=LOCATION_NAME,deviceName=DEVICE_NAME,type=THERMOSTAT_MODE" }
String Bedroom_Radiator_Set_Status "Bedroom Radiator Set Status [%s]" { evohome="locationName=LOCATION_NAME,deviceName=DEVICE_NAME,type=THERMOSTAT_SETPOINT_STATUS" }
DateTime Bedroom_Radiator_Set_NextTime "Bedroom Radiator Set Time [%1$tT, %1$tF]" { evohome="locationName=LOCATION_NAME,deviceName=DEVICE_NAME,type=THERMOSTAT_SETPOINT_NEXTTIME" }
so the first is evohome:heatingzone:xxxxxxxxx:Bedroom:Temperature
second is evohome:heatingzone:xxxxxxxxx:Bedroom:CurrentSetPoint
and fourth is evohome:heatingzone:xxxxxxxxx:Bedroom:SetPointStatus
so im missing third and last bit, and i saw that it returns “activeFaults” ?
Can that be used to find out if the battery runs low?
Hi. I’ve never seen it send the battery details so I don’t think it can.
anyway i can test that?
I got a message on my evotouch that one unit battery is running low.
got it:
"activeFaults": [
{
"faultType": "TempZoneSensorCommunicationLost",
"since": "2017-12-01T14:23:43"
},
{
"faultType": "TempZoneActuatorCommunicationLost",
"since": "2017-12-01T14:23:43"
}
],
and
"activeFaults": [
{
"faultType": "TempZoneSensorLowBattery",
"since": "2017-12-05T15:42:59"
},
{
"faultType": "TempZoneActuatorLowBattery",
"since": "2017-12-05T15:42:59"
}
],
can you work with that?
I’m trying to find out the right way of entering the thing info. I’ve already figured a few things out, but i can’t get the heatingzone thing working.
I currently have the following config:
Bridge evohome:gateway:xxxxxxx "Honeywell EvoHome" @ "Begane grond" [ username="xxxxxx@xxxxx.com", password="xxxxxxx", applicationId="xxxxxx-xxxx-xxxx-xxxx-xxxxxx", refreshInterval=15000] {
Things:
display Evotouch "Honeywell EvoTouch" @ "Begane grond" [deviceId="xxxxxxx"]
heatingzone Woonkamer "Heating zone Woonkamer" @ "Begane grond" [zoneId="xxxxxxx", locationId="xxxxxxx"]
}
When debug logging is enabled, the following error is displayed:
06-Dec-2017 21:49:49.159 [DEBUG] [.binding.evohome.handler.EvohomeHeatingZoneHandler] - Updating thing[Heating zone Woonkamer] locationId[null] zoneId[null]
06-Dec-2017 21:49:49.161 [DEBUG] [nhab.binding.evohome.handler.EvohomeGatewayHandler] - updateChannels acting up
java.lang.NullPointerException: null
at org.openhab.binding.evohome.internal.api.EvohomeApiClientV2.getHeatingZone(EvohomeApiClientV2.java:283) [12:org.openhab.binding.evohome:2.1.1.201706121242]
at org.openhab.binding.evohome.handler.EvohomeHeatingZoneHandler.update(EvohomeHeatingZoneHandler.java:93) [12:org.openhab.binding.evohome:2.1.1.201706121242]
at org.openhab.binding.evohome.handler.EvohomeGatewayHandler.update(EvohomeGatewayHandler.java:149) [12:org.openhab.binding.evohome:2.1.1.201706121242]
at org.openhab.binding.evohome.handler.EvohomeGatewayHandler.access$3(EvohomeGatewayHandler.java:127) [12:org.openhab.binding.evohome:2.1.1.201706121242]
at org.openhab.binding.evohome.handler.EvohomeGatewayHandler$2.run(EvohomeGatewayHandler.java:122) [12:org.openhab.binding.evohome:2.1.1.201706121242]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Has anyone figured out how to add the heatingzone thing so it works?
Edit: The funny thing is, that the display thing only works, when the ‘faily’ heatingzone thing is added. When the heatingzone thing is removed, the display thing doesn’t work either in the manual configuration.
Using a thing file has been an issue for a while. From memory you can setup the gateway and the display via things, but everything else just freaks.
I originally used the gateway and then PaperUI to search and add each TRV manually.
See issue here
Hi guys,
I’ve been away for a while, but I’m planning to resume working on the binding again on a slow pace.
As requested by @VibroAxe I’ve created a new topic here: Evohome binding 2.0. Please find all new info there.
@Mickroz I created an issue for you here: https://github.com/Nebula83/openhab2-addons/issues/14 please add more details if you can an perhaps propose a way of exposing this. Are you expecting faultType as a String somewhere? Would you like to know the timestamp?
First order of business is supporting configuring via .thing files, since that is required for the PR.
Best regards,
Jasper
Thanks, i will reply on the issue and start following the new topic!