The binding is working with OH3, but a bit temperamental and some rooms/TRVs have a comms error saying “The value must be between 0 and 100”
This is all I’m seeing in openhab.log:
2020-12-26 17:22:20.684 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'draytonwiser:room:WiserHeat028321:bathroom' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Value must be between 0 and 100
Will see if I can do some more digging
That’s a bit weird. I upgraded my setup from 2.5 to 3.0 about a week ago, and haven’t noticed anything going awry.
From that log message, its not obvious which channel is having the problem? I’m assuming it’s heat demand if it’s moaning about the range 0-100.
I’m seeing a similar COMMs error on OH2 too.
@5f78e33f': java.net.NoRouteToHostException: No route to host
org.openhab.binding.draytonwiser.internal.api.DraytonWiserApiException: java.net.NoRouteToHostException: No route to host
at org.openhab.binding.draytonwiser.internal.api.DraytonWiserApi.sendMessageToHeatHub(DraytonWiserApi.java:225) ~[?:?]
at org.openhab.binding.draytonwiser.internal.api.DraytonWiserApi.setRoomManualMode(DraytonWiserApi.java:94) ~[?:?]
at org.openhab.binding.draytonwiser.internal.handler.RoomHandler.setManualMode(RoomHandler.java:160) ~[?:?]
at org.openhab.binding.draytonwiser.internal.handler.RoomHandler.handleCommand(RoomHandler.java:70) ~[?:?]
at org.openhab.binding.draytonwiser.internal.handler.DraytonWiserThingHandler.handleCommand(DraytonWiserThingHandler.java:82) ~[?:?]
at sun.reflect.GeneratedMethodAccessor752.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_252]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_252]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy11041.handleCommand(Unknown Source) [?:?]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:74) [bundleFile:?]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at sun.reflect.GeneratedMethodAccessor751.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_252]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_252]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
Network issue? But it’s only affecting one room 
Do you see this in your OH3 logs too?
map. It has to be fixed by the bindings developer.
at java.base/java.lang.Thread.getStackTrace(Thread.java:1607)
at org.openhab.core.config.discovery.DiscoveryResultBuilder$1.run(DiscoveryResultBuilder.java:181)
at org.openhab.core.config.discovery.DiscoveryResultBuilder$1.run(DiscoveryResultBuilder.java:1)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.openhab.core.config.discovery.DiscoveryResultBuilder.getStackTrace(DiscoveryResultBuilder.java:178)
at org.openhab.core.config.discovery.DiscoveryResultBuilder.build(DiscoveryResultBuilder.java:157)
at org.openhab.binding.draytonwiser.internal.discovery.DraytonWiserMDNSDiscoveryParticipant.createResult(DraytonWiserMDNSDiscoveryParticipant.java:75)
at org.openhab.core.config.discovery.mdns.internal.MDNSDiscoveryService.considerService(MDNSDiscoveryService.java:214)
at org.openhab.core.config.discovery.mdns.internal.MDNSDiscoveryService.serviceAdded(MDNSDiscoveryService.java:185)
at javax.jmdns.impl.ListenerStatus$ServiceListenerStatus.serviceAdded(ListenerStatus.java:62)
at javax.jmdns.impl.JmDNSImpl$4.run(JmDNSImpl.java:1324)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Not sure about the network issue, unless you somehow have 2 copies of the binding maybe, pointing at different IPs, but I’m clutching at straws.
I see the same error about networkAddress property on early openhab startup. It doesn’t appear to break things, but I’ll try and fix it. I found another report of the same type of error, and there was a PR to fix it, so hopefully that will help.
I just started looking at adding some extra features to the binding, namely “Comfort Mode” and how to implement scheduling.
I’ve also discovered some undocumented functionality on the smart plugs, in that they can monitor power usage both instantaneously and cumulative consumption in W and Wh respectively.
It also looks like we might be getting support for smart bulbs at some point, because the compatibility matrix on the hub now lists “lights” alongside the other features already available.
Comfort mode has just been merged into openhab:main, so should be available in the next release: [draytonwiser] Add comfort mode option to boiler controller by andrew-schofield · Pull Request #9649 · openhab/openhab-addons · GitHub
Thanks Andrew,
Great spot on the power metering - I couldn’t wait to use it so I’ve implemented it myself and logged a PR. It’ll be interesting to see what other devices Drayton come out with, an underfloor heating controller’s been promised for a while (it was in the app release notes), and support told me it was going to be for wet systems, looks like it’s available in Germany).
I was wondering - is there a reason there’s a channel for “Zigbee Connected”? Would it make sense to use that for setting the thing Status to offline, e.g. when a device is out of range, or a smart plug is powered off or trv/roomstat battery flat? From what I can see it’s offline when "DisplayedSignalStrength": "NoSignal", or RSSI/LQI are null.
Finally I’m on OH3, and seeing the error logged about Representation property 'networkAddress' of discovery result for thing, but it seems benign, and I’ve not spotted any other issues.
Hi,
Really liking the binding, and openhab, but are there any plans on being able to update schedules? I see from this long thread there was some problem with implementing this functionality a few months ago.
My use case is that between my wife, daughter, and myself, and our working/school patterns, there are a number of different heating configurations (or heating scenes, if you like) that I’d like to be able to have pre-configured and deployed accordingly. For example, if it’s just me working from home the office needs to be heated but the rest of the house can be “off”. However, if it’s a day my wife is home as well then it’s the office and sitting room. If my daughter is on school holidays then that’s also her bedroom, but if my wife is at work then it’s just the office and my daughters bedroom.
We’ve all been on holiday, at home 
, this week and it’s been a continual battle overriding the schedule every day. The holiday is long enough to be annoying, but not long enough to warrant going through the schedule and adjusting everything.
The way I saw it working would be to create schedules for each “heating scene” that would contain the times/temps for each room. I would then trigger the schedule update to the relevant “heating scene” via a virtual switch (possibly automate further with schedules etc but haven’t looked in to what openhab can do here).
Am I barking up the wrong tree? Is there a solution I’m missing? Any help would be appreciated.
I have a very basic implementation of this as it’s usually just me WFH.
Using presence detection via the Ubiquiti binding, if it spots that my work laptop’s MAC is on the network it will set the temperature in the spare room where I work to 21C. When the laptop turns off it reverts back to the normal schedule.
Could you implement presence detection using laptops/phones within certain days & times to override the schedule?
or just have a dummy String/number that sets everything how you want…
You can then set up rules when dummy item changed, have a map for the String/number on your sitemap etc.
Choice is yours really.
Hi Rob,
I implemented the binding and i sucessfully integrated the heat hub and thermostat. Thank you for your work it works very well.
In the Wiser app it is now possible to integrate other device like roller shutter and Odace light. Do you plan to integrate these devices in the binding?
It looks like the continent has beaten us in the UK again. There’s no option for lighting or shutters in the app at the moment. I’ve heard underfloor heating is on the way too.
I’ve not touched the code in a while, but I don’t see why they can’t be added once the json schema is known.
Might not have new lights on our heating system but we got the covid jab 
Did something Drayton end just change on the battery level side?
Literally half hour ago all my battery levels went UNDEF - all other channels working and when I opened app got asked if I’d like to enable notifications for battery levels which seems a coincidence
Haven’t checked logs yet as not by a pc.
Strange… one just came back…
Wonder if there’s something being done their end.
Possibly, I had an email today saying they’re updating the TRV firmware so they operate quieter and batteries last longer.
The fact one is still working makes me think it’s a comms issue. Have they reappeared yet?
They’re constantly dropping off / reappearing (just battery levels), normally once or twice per day. I haven’t had a chance to check logs atm as so busy at work. Not sure if it’s a wiser issue or a 3.x issue as started after I upgraded from 2.5.x but also when I got the first email from wiser regarding changes which included battery levels.
Continuing the discussion from Drayton Wiser Thermostat Binding:
Hello, I’ve upgraded to OH3 from 2. I can see my Wiser binding is version 3.1.0 All my items are still defined in text files since the upgrade.
I’m getting fairly constant disconnects from the Heat Hub, between every 1-10minutes. My wifi could be an issue as the signal at the controller is poor but I didn’t previously experience this volume of issues in OH2.
For version 2 it was recommended to not use the binding from the market place. What is the recommended version of the binding to use with OH3?
The errors on the HeatHub are repetition of the following:
2021-09-30 12:12:41.451 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'draytonwiser:heathub:WiserHeat02DBC0' changed from OFFLINE (COMMUNICATION_ERROR): No data received to OFFLINE (COMMUNICATION_ERROR): java.io.EOFException: HttpConnectionOverHTTP@1758023::SocketChannelEndPoint@4b449c{l=/192.168.1.29:35902,r=/192.168.1.18:80,ISHUT,fill=-,flush=-,to=0/0}{io=0/0,kio=0,kro=1}->HttpConnectionOverHTTP@1758023(l:/192.168.1.29:35902 <-> r:/192.168.1.18:80,closed=false)=>HttpChannelOverHTTP@104213a(exchange=HttpExchange@1a48213{req=HttpRequest[GET /data/domain/ HTTP/1.1]@257d9c[TERMINATED/null] res=HttpResponse[HTTP/1.1 200 OK]@8cbb20[PENDING/null]})[send=HttpSenderOverHTTP@2d52ba(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@124fc76{s=START}],recv=HttpReceiverOverHTTP@aabf13(rsp=CONTENT,failure=null)[HttpParser{s=CLOSED,2748 of -1}]]
2021-09-30 12:13:42.865 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'draytonwiser:heathub:WiserHeat02DBC0' changed from OFFLINE (COMMUNICATION_ERROR): java.io.EOFException: HttpConnectionOverHTTP@1758023::SocketChannelEndPoint@4b449c{l=/192.168.1.29:35902,r=/192.168.1.18:80,ISHUT,fill=-,flush=-,to=0/0}{io=0/0,kio=0,kro=1}->HttpConnectionOverHTTP@1758023(l:/192.168.1.29:35902 <-> r:/192.168.1.18:80,closed=false)=>HttpChannelOverHTTP@104213a(exchange=HttpExchange@1a48213{req=HttpRequest[GET /data/domain/ HTTP/1.1]@257d9c[TERMINATED/null] res=HttpResponse[HTTP/1.1 200 OK]@8cbb20[PENDING/null]})[send=HttpSenderOverHTTP@2d52ba(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@124fc76{s=START}],recv=HttpReceiverOverHTTP@aabf13(rsp=CONTENT,failure=null)[HttpParser{s=CLOSED,2748 of -1}]] to ONLINE
Managed to resolve this. I removed all the text based items and readded from the OH3 UI. Since doing that I’m not getting the frequent disconnect messages in the log. The system is online in the wiser app whenever i check it unlike previously.
It seems like the openhab configuration also has the ability to destabilise the Wiser system if there’s something in there which is not quite right.
I’ve just installed the Drayton Wiser 2 system. I’m using OpenHab 3. I’ve installed the add-in from the openhab local webpage.
I connected to the Heat Hub using it’s local network and then accessed 192.168.8.1/secret from my phone browser.
I have the secret code which is very long. (I’ve verified it using a capture app on my phone)
I tried to set up a heat Hub Thing and pasted the secret into the auth Token field on the create form, but I’m getting an authorisation error - "HTTP protocol violation: Authentication challenge without WWW-Authenticate header.
Here’s the code for my thing:
UID: draytonwiser:heathub:ebf05057bf
label: HeatHub
thingTypeUID: draytonwiser:heathub
configuration:
refresh: 10
awaySetPoint: 16
secret: RbvaPjpxoeifkJAygW6JgECSnya6dDBK/KuPQYJNVXuGnZmZatqAAOZJFKyMDbgidDxfWRBcZhRXRtyWHCPmxcwKU95dPWpMZljnASA3jKnF7HxVpixYHEv/Am/Su8Np"
networkAddress: 192.168.1.115
Any pointers?
There’s a double quote on the end of your key, is that definitely part of your secret?
Duhhh, That was it. The capture string was put into quotes - I spotted the first one and missed the last one. Thanks…