Ah, that easy 
Brilliant, thanks.
Just to update everyone, the pull request for this binding had now been merged, so should be available when 2.5.8 comes out. Many thanks to @hilbrand for helping get this over the line.
2 Likes
Is there a way we can apply a schedule to a room from OpenHAB? I’m sure I remember seeing the schedules in some text format (json?) in the past but having recently come back to this binding (great to see its now all sorted and included), they appear to be gone?
Use case is being able to flick a virtual switch to indicate guests staying in a particular room and (among other things) setting the heating schedule as required from the constant 15*C it is on normally.
At the moment sadly not, no. I had to remove the previous implementation from the binding as you’re not “allowed” to expose channels of just json.
That’s disappointing and confusing as it could be useful to have the scheduling in the same place as the controlling.
(PS - I love the binding you’ve built and really appreciate the time and effort that you’ve put in)
I’ve just got into MQTT and the MQTT binding allows setting up of “customised channels” where you specify the MQTT topic and the JSONPATH transformation to get out (and in) the value that is required for the channel.
Its weird that this is “allowed” but not your implementation.
You could think about this another way. If you’re programming a schedule to set up a constant 15C, why not just use manual mode to set the 15C constant temperature, and then configure a schedule for when the room is in use. Leave it in manual mode by default, and then turn manual mode off when you do want to use the room. Manual mode settings on a room appear to be restored after away mode being activated and deactivated.
Thanks for the suggestion.
Sounds like a good idea actually, in place of full blown schedule control. Will give it a go this week.
That’s exactly how I manage our guest room, works well.
Great suggestion. Been trying to write a rule to turn on the heating in the office when I’m working from home. Now I have manual mode linked to presence detection on the work laptop I can increase the temperature if it’s still too cold.
I’m having some troubles with the Room SetPoint.
If I try to change the setpoint for a room from an item it just resets back to the scheduled value after a moment. I can see the commands in the events.log but then it just changes back.
I just updated to 2.5.10, deleted the things, re-added them from PaperUI and it’s the same.
I discovered something that may be a clue, in the PaperUI Thing for each room there are two icons for setpoint, one that says “Set Point” and below it one that says “Dining Set Point” both can be adjusted. The one that says just “Set Point” works correctly and the “Dining Set Point” updates to reflect the value set, oh and the radiator fires up too. The “Dining Set Point” one behaves the same as the item in Basic UI and the IOS App, it updates and then after a moment goes back to the original value.
The other clue is if I go to Configuration>Things>Dining in PaperUI there’s a channel for Set Point (which is where I got the channel for the item) but if I try to unlink it says it unlinked but the icon doesn’t change, if I try to link again I get a 404 error. All my rooms behave the same, not only the Dining room.
If I unlink or link other channels in the Room Thing they all work as expected only Set Point misbehaves like this, well that I’ve found anyway.
So looks to me like the channel is misconfigured or mangled in some way but as it is discovered automatically I can’t see any way to change it.
Help…
Edit: I tried “show more” in the Thing and there isn’t a second Set Point in there waiting to be linked only the one.
So I resolved (not exactly fixed) my own problem.
I had created items for all the channels I wanted in items/heating.items and this has worked for more than a year, I have data to compare this winter with last.
It seems the problem was caused by my manually created items clashing in some way with ones that PaperUI created, set in simple mode. I didn’t even know PaperUI created items as in simple mode they are hidden.
So now it works, I wanted to turn up the heating in the living room when we sit down to watch TV or a movie so it could be set lower at other times. I now have a scene switch that does all the lights and adjusts the setpoint, adjusts it back at the end all operated by Harmony Hub through Hue emulation.
So the remaining issue is I have >12months of data with the short sensible names I gave my items which I have had to delete as they don’t properly work (can’t change setpoint). Seems I had the automatic items all along so at least I can still graph last year against this.
It’s dificult to see what I did wrong in my text file items as the view in PaperUI is different. I’d really rather have the text file config, it’s so much easier to maintain.
Any ideas how I can debug this? Can anyone post a working setpoint item that I can crib from?
I need to fix this before there’s too big a hole in my data!
Oh and this is what my items looked like in case someone can tell me what I did wrong:
// Number Heating_Lounge_Temp "Lounge Temperature [%.1f C]" { channel="draytonwiser:room:WiserHeat02DC85:lounge:currentTemperature" }
// Number Heating_Lounge_Humidity "Lounge Humidity [%.1f %%]" { channel="draytonwiser:room:WiserHeat02DC85:lounge:currentHumidity" }
// Number Heating_Lounge_SetPoint "Lounge Set Point [%.1f C]" { channel="draytonwiser:room:WiserHeat02DC85:lounge:currentSetPoint" }If your ‘simple’ items have the same names as the text based items then you’ll need to delete these first before you add the text file (they won’t delete after adding the text file - will just get a conflict error)
Thanks, that makes sense, explains the conflict, looking at the notes for this binding my items are fine, a lot like the example ones.
Currently I switched to using the items that PaperUI created, seems they have been there all along as I can still graph them from last year or more. I tried to use the habpanel widget that someone created and the naming is all wrong to work with the simplemode items. Maybe it’s better to change the habpanel widget to work with the autogenerated items, can’t be that hard.
A friend is just installing a Wiser system and I know he’s going to want me to set up openhab for him, so good to get a better understanding of all this.
So did the text based items not work?
The only thing I can think of is the channel is incorrect if not.
While your getting to grips the best thing is to go to the thing that the item will link to and copy the applicable channel:
Like this:
//Heating
Group LoungeThermostat "Lounge Thermostat" {alexa="Endpoint.Thermostat"}
Number:Temperature LoungeTemperature "Lounge Temperature [%.1f 簞C]" (LoungeThermostat) {channel="draytonwiser:room:1adff779:WiserRoomLounge:currentTemperature",alexa="TemperatureSensor.temperature"}
Number:Temperature LoungeSetPoint "Lounge Set Point [%.1f 簞C]" (LoungeThermostat) {channel="draytonwiser:room:1adff779:WiserRoomLounge:currentSetPoint",alexa="ThermostatController.targetSetpoint"}
Number:Dimensionless LoungeHeatDemand "Lounge Demand" {channel="draytonwiser:room:1adff779:WiserRoomLounge:currentDemand"}
Switch LoungeRequesting "Lounge Requesting Heat" (LoungeThermostat) {channel="draytonwiser:room:1adff779:WiserRoomLounge:heatRequest",alexa="ThermostatController.thermostatMode"}
Switch LoungeManualMode "Lounge Manual Mode" {channel="draytonwiser:room:1adff779:WiserRoomLounge:manualModeState"}
Number LoungeBoostDuration "Lounge Boost Duration" {channel="draytonwiser:room:1adff779:WiserRoomLounge:roomBoostDuration"}
Switch LoungeIsBoosted "Lounge Is Boosted" {channel="draytonwiser:room:1adff779:WiserRoomLounge:roomBoosted"}
Number LoungeBoostRemaining "Lounge Boost Remaining" {channel="draytonwiser:room:1adff779:WiserRoomLounge:roomBoostRemaining"}
Switch LoungeOpenWindow "Lounge Open Window" {channel="draytonwiser:room:1adff779:WiserRoomLounge:windowStateDetection"}
Contact LoungeWindowState "Lounge Window State" {channel="draytonwiser:room:1adff779:WiserRoomLounge:windowState"}
String LoungeSchedule "Lounge Schedule"
Hi,
Is it possible to monitor the state of the pump, flame (boiler flame), heating valve and hot water valve please? We have noticed that sometimes with the hot water, the hot water valve opens and the boiler heats up but the pump does not start. Unfortunately this creates a dangerous situation at which point the boiler thermal cutout activates. This never happens with the heating channel, only the hot water channel.
Many thanks
Hi GM,
Whilst the Drayton Wiser device can communicate with your boiler using the OpenTherm protocol, which is capable of providing boiler status information back to the thermostat (as opposed to the conventional on/off wiring), I haven’t seen in the API any reporting of boiler activity which it might be informed of by OpenTherm. OpenTherm implementations vary quite wildly between boiler and thermostat manufacturers and a lot of the information is not mandatory within the spec.
I’m not a qualified heating engineer, but even if your boiler is wired using OpenTherm, I don’t believe that OpenTherm (or the Wiser) controls pump activity separately from valve / flame. My understanding is it simply providers for the thermostat to be able to request heat at a specific temperature. I’d expect that the pump / valve / flame activity is managed within your boiler’s controller. No matter what the issue is I’d suggest you get a qualified engineer to have a look at your setup if you think it is dangerous.
James
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.
1 Like