Drayton Wiser Thermostat Binding

There was no additional information in the log, I checked a couple of times. The good news is, so far the hub is not going offline. I know this is early days …

Spoken too soon!!!

@Spav I’m not seeing this in my logs at all. I’m using OH 2.5.5 and the 2.4.0 version of the binding. My items are manually configured and I don’t see this issue.
image

I’ve not been heavy into OpenHAB for a while due to some building work at home. I’m now looking to set things up so will take another look.

Unrelated question: Did anybody ever get the plugs working?

Hi Rob, I have been working with @hilbrand today and have received a couple of updates from him for the wiser binding. I have to say that the snapshot from 16:00 today is looking a lot better. It seems that some of the issues came from the fact that my system did not report humidity. I am now on OH2.5.5 and 2.5.6 snapshot from today.

1 Like

In the updated binding I made a number of internal changes to make it more robust. The problems found with @Spav were mostly related to the refactoring. I expect it should work now, expect for the offline issue, which likely related to the interaction of openHAB with the thermostat.
If more people test this version and report it’s working I can work on getting this binding added so it will be available by default, So please do test the latest version and if you find anything please report.

It has been running most of the day now, with 120 second polling. As @hilbrand suggests this does feel like a interaction issue. The disconnects are still in the log but I have had just 2, since the last upload late this afternoon.

After trawling the logs from last night, there are no Drayton wiser messages in the openhab.log after a 20:20 yesterday evening. In the events.log there are a couple of significant messages one where the bridge went off line had three attempts and came back on with no drama and this this one where the bridge went off line and on the second attempt seemed to throw an exception message.

2020-06-12 23:50:46.755 [hingStatusInfoChangedEvent] - 'draytonwiser:heathub:WiserHeat02851D' changed from OFFLINE (COMMUNICATION_ERROR): No data received to
OFFLINE (COMMUNICATION_ERROR): java.net.NoRouteToHostException: No route to host

On the third attempt the log is interesting, to me this looks like the message has reported a COMMUNICATION ERROR and an exception but the message has been received as there are clean updates in the processing.

2020-06-12 23:51:47.019 [hingStatusInfoChangedEvent] - 'draytonwiser:heathub:WiserHeat02851D' changed from OFFLINE (COMMUNICATION_ERROR): java.net.NoRouteToHo
stException: No route to host to ONLINE
2020-06-12 23:51:47.025 [hingStatusInfoChangedEvent] - 'draytonwiser:boiler-controller:e7f3164c' changed from OFFLINE (BRIDGE_OFFLINE) to UNKNOWN
2020-06-12 23:51:47.033 [hingStatusInfoChangedEvent] - 'draytonwiser:room:692c25a1' changed from OFFLINE (BRIDGE_OFFLINE) to UNKNOWN
2020-06-12 23:51:47.037 [hingStatusInfoChangedEvent] - 'draytonwiser:itrv:0ea99a73' changed from OFFLINE (BRIDGE_OFFLINE) to UNKNOWN
2020-06-12 23:51:47.043 [hingStatusInfoChangedEvent] - 'draytonwiser:hotwater:854baf69' changed from OFFLINE (BRIDGE_OFFLINE) to UNKNOWN
2020-06-12 23:51:47.055 [vent.ItemStateChangedEvent] - BoilerController_SignalStrength changed from 1 to 0
2020-06-12 23:51:47.061 [hingStatusInfoChangedEvent] - 'draytonwiser:boiler-controller:e7f3164c' changed from UNKNOWN to ONLINE
2020-06-12 23:51:47.098 [hingStatusInfoChangedEvent] - 'draytonwiser:room:692c25a1' changed from UNKNOWN to ONLINE
2020-06-12 23:51:47.103 [vent.ItemStateChangedEvent] - ITRV_Temperature changed from 23.0 °C to 22.9 °C
2020-06-12 23:51:47.104 [hingStatusInfoChangedEvent] - 'draytonwiser:hotwater:854baf69' changed from UNKNOWN to ONLINE
2020-06-12 23:51:47.123 [hingStatusInfoChangedEvent] - 'draytonwiser:itrv:0ea99a73' changed from UNKNOWN to ONLINE

One thought is that OH is not waiting long enough for the reply and the hub is being really slow at this point (busy?), the reply being received may be from a previous request??? just a thought.

There is nothing in the openhab.log at the same time and since this point the logs are clean with no drops. It certainly is looking a lot better now.

More information…
Since I have left the paperUI open and fronttail running, this now seems to happen more frequently. Two seen in the last hour.

2020-06-13 13:27:42.505 [hingStatusInfoChangedEvent] - 'draytonwiser:heathub:WiserHeat02851D' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): java.io.EOFException: HttpConnectionOverHTTP@1faa6b9::SocketChannelEndPoint@7f261{/192.168.1.15:80<->/192.168.1.16:46496,ISHUT,fill=-,flush=-,to=12/0}{io=0/0,kio=0,kro=1}->HttpConnectionOverHTTP@1faa6b9(l:/192.168.1.16:46496 <-> r:/192.168.1.15:80,closed=false)=>HttpChannelOverHTTP@2229fa(exchange=HttpExchange@4b2e42 req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@1ccd3fa(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@fa458{s=START}],recv=HttpReceiverOverHTTP@195239a(rsp=IDLE,failure=null)[HttpParser{s=CLOSED,0 of -1}]]

Next test is I will close the UI and fronttail and check back in a few more hours.

I don’t often swing by here much nowadays, but…
I originally installed OH back in Feb 2019 when I first got my Wiser system.
So, earlier on I backed up my system (openhabian-config), wrote out a new SD card with the latest OH R-Pi image, booted the R-Pi and made a restore (openhabian-config) and also dropped in the latest xxx.kar file from hilbrand and rebooted.
Interestingly, everything came up and I don’t seem to have any errors… (early days and famous last words etc!).

Now, if someone could make an improvement on the HABpanel for Wiser, that’d be toasty :wink:

I have 8 rooms / 9 TRV’s and the panel is a bit big with all of that on the screen.

Nigel

I’m rebuilding my OH setup and having trouble manually adding a Smart Socket. If I find it through the discovery it’s fine, but I’d rather use config files (I’m old school like that).

In my things:

Bridge draytonwiser:heathub:HeatHub [ networkAddress="192.168.3.32", refresh=60, secret="MyVerySecretSecret", awaySetPoint=10 ]
{
        boiler-controller       controller      "Controller"
        room                    livingroom      "Living Room"           [ name="Living Room" ]
    room                    bathroom        "Bathroom"              [ name="Bathroom" ]
    room                    bedroom         "Bedroom"               [ name="Bedroom" ]
    room                    spareroom       "Spare Room"            [ name="Spare Room" ]
    room                    kitchen         "kitchen"               [ name="Kitchen" 
    smart-plug              lampplug        "Living Room - Plug"    [ serialNumber="00XXSERIAL", name="Lamp socket" ]
}

And item:

    Switch  livingroom_lampplug     "Lamp"          { channel="draytonwiser:smart-plug:HeatHub:lampplug:plugOutputState" }

It looks like it’s the things configuration is wrong. When I add it through discovery I need to add the name as well as the serial number, although looking through the code that isn’t required.

Are you able to take a look @hilbrand?

It expects plugName instead of name. But doesnt seem logical to make it a required property or a property at all. Maybe it’s better to remove it. It also looks the readme is missing the description of the things parameters.

It’s working with plugName :smiley: Let me know if you decide to remove the plugName parameter and I can update the readme

@Rob_Pope we have now removed the plugName parameter from the binding as it isn’t necessary. @hilbrand and I have been working on getting this finally over the line (mostly thanks to the refactor he did to make it compatible with the new build system), as far as I can tell from using it locally (configured through paper UI), everything now works again and the weird thread pooling issues have finally been resolved.

A little note on the smart plug name issue, originally when I cobbled together the smart plug support I intended on using the plugName as the identifying parameter because (at least on the gen 1 repeater plugs I have) you can’t see the serial number. However to simplify discovery the serial number was still being used and I never updated it. Therefore we’ve just removed the plugName, which makes the code even simpler because all the devices now share a common codebase.

If you have one of the newer smart plugs (the little square ones, rather than the big repeater ones) do they have a serial number sticker on them somewhere?

I’m not sure if I’ve got the new or old version, but it doesn’t have a serial number on the unit itself

OK, that’s helpful to know. The solution for smart plugs is probably to use the discovery function in paperui to find the serial number (or peek at the json if you’re technically inclined) if you want to configure everything with .things files.

For reference that’s the only style of plug they’ve ever sold.
If you requested a free range extender back when they first launched the wiser system, they sent you one of these (or in my case, 2):

To start with they were just dumb range extenders, although the soft button on the side (glowing red in the picture) did activate a relay to toggle the socket on and off, however when the hub firmware was updated to add smart plug support, these plugs magically gained smart functionality (if you remove and re-join them) :slight_smile:

Been happy with my wiser system and the binding. Only thing I’ve noticed is openhab (refreshing I’m assuming) does kill trv battery life quickly. Thank god I have rechargeable’s

1 Like

I’ve had the binding since before I added TRVs to the system. Did you notice a reduction in battery life after you connected to OpenHAB or is the TRV battery life just poor anyway?

In my impression the battery life is poor if the TRV has a poor signal. It seems that if the signal is low or needs to keep reconnecting it uses the battery faster. I have three TRVs at the front of the house which connect to a plug/range extender. This sometimes falls off the network itself and then they are all knocked out. Even with the range extender the signal is weak. My impression is that these are running down faster, I’m changing the batterys at least every 6 months.

Quick question: is it necessary to add the Wiser things manually to expose all of the channels?
I ask because I added the things via PaperUI and then items via files but I do not see any battery voltage channel in PaperUI for the TRVs, only Battery level. Am I missing something?

Yes you miss something :smile:


courtesy to @wborn: [SOLVED] Milestone 4 - SystemInfo Issues