Drayton Wiser Thermostat Binding

The last items on my current TODO list are now complete. In this update, open window detection and room/hotwater scheduling have been added.

The schedule channel has been given the id masterSchedule as it refers to the raw JSON schedule on a per room/hot water basis. If the JSON for the room schedule looks like this when queried:

{
    "id": 1,
    "Monday": {
        "SetPoints": [
            {
                "Time": 600,
                "DegreesC": 200
            },
            {
                "Time": 830,
                "DegreesC": 160
            },
            {
                "Time": 1230,
                "DegreesC": 200
            },
            {
                "Time": 2200,
                "DegreesC": 170
            }
        ]
    },
...SNIP...
    "Type": "Heating",
    "CurrentSetpoint": 160,
    "NextEventTime": 750,
    "NextEventSetpoint": 200
}

This is what should be sent as an update to that channel:

{
    "Monday": {
        "SetPoints": [
            {
                "Time": 600,
                "DegreesC": 200
            },
            {
                "Time": 830,
                "DegreesC": 160
            },
            {
                "Time": 1230,
                "DegreesC": 200
            },
            {
                "Time": 2200,
                "DegreesC": 170
            }
        ]
    },
...SNIP...
}

It appears that the API does support PATCHing individual schedule items, i.e. http://HEATHUB_URL/data/domain/Schedule/1/Monday/SetPoints/0/Time so theoretically it would be possible to configure the entire heating schedule from openhab, and creating a sitemap for this would be trivial, however that would require a lot more channels for each room (8 times, 8 setpoints per day = 112 channels), unless anyone knows of a better way.

1 Like

Given that my system still hasn’t updated it’s firmware to support device locking, I think I’m just going to request a review of the PR as it stands now.
Extra functionality can probably be added before the PR is merged, or it can be done as part of a new PR.

This showed up in the Android app changelog this morning

- Support for Smart Plugs (coming soon)

My range extenders now appear as owon smart plugs in app as well, just with no extra options.

I’m going to be buying some more thermostats soon so might get a smart plug at the same time. That’ll replace the 433Mhz socket I have now and be locally controlled (the reason I’ve not gone TP-Link)

So my heathub updated it’s firmware and pushed out an update to all my devices, so I can see device lock in the all app now. The range extender appears under its own section called smart plugs on the devices page now, so I wonder if the API responses are any different.

Rather disturbingly, I can tell exactly when my TRVs updated themselves as all of them show an instantaneous multi-degree drop in temperature, which doesn’t really recover. I wonder if the update has changed a calibration constant, but it was bad enough that it actually triggered the heating to come on in some rooms, even though it was roasting in there.
Sadly this update has exposed a bug in the binding as well as after a while many TRVs had stopped getting updates :disappointed:

I’ve just pushed a few updates to the binding after doing some extensive investigation today with lots of debug tracing.
I finally believe the weird “stop updating” bug is fixed. The problem was that on occasion the heathub would just fail to respond to a request from the binding. This isn’t a problem in itself, however what was a problem was that the default timeout for responses was so large as to be effectively pointless. This meant that the binding was waiting for the heathub to respond to it’s request before triggering the next update. This was partially mitigated by the binding having a pool of 3 possible connections to use, but once the heathub refused to respond 3 times, the binding just stopped requesting more updates. The solution was to set a timeout of 5 seconds. If the heathub hasn’t responded the binding just ignores it and tries again at the next configured interval.

Also included are some fixes that stop the binding falling over with the latest wiser firmware.

This brings me to my latest find: Drayton have changed the JSON response for some items, which means that the signal rssi, lqi and battery voltage don’t work in the binding as I need to alter how they are being obtained. I should be able to add device locking channels now though, and a bunch more interesting stuff has appeared on the smart plug endpoint. I even managed to trigger the smart plug to turn off by switching it from manual to auto (i.e scheduled) mode. :grin:

Device RSSI and LQI are back now, and I’ve added device locking channels to the TRV and Thermostat things.

I’ve been digging into the new JSON data, and it looks like the away mode set point is now persisted on the controller, which is nice. You also seem to be able to set whether away mode turns the hot water channel off or not. Individual rooms seem to be able to ignore away mode, and you seem to be able to set the smart plugs to always be off in away mode.
Interestingly the smart plug schedules are reported as “HotWater” type schedules in the JSON response.

Finally, £41.99 seems a bit steep for the smart plug doesn’t it?

Awesome stuff Andrew! I’ve currently got a broken OH instance so need to fix that and then I’ll grab the latest version.

£42 is a bit steep for me. Is it the same as the one you were sent by Drayton? Think I’ll stick to the 433Mhz plugs that I’m using at the moment. A range extender would be useful though so maybe I’ll get one in the future.

No, the ones they’ve sent me are basically these: http://www.owon-smart.com/products/WSP403-HA-ZigBee-HA-Smart-Plug_26.html
I can’t find a reseller of them in the UK though.

Out of interest, which plugs have you got at the moment (and what coordinator are you using)?

I’ve extracted the source from the latest Android app, and I think I now know how to remotely trigger the smart plugs even though this isn’t exposed in the app yet. There are some hidden properties on the smartplug object which you can only set by passing it in as JSON key/value rather than just giving the value to the appropriate endpoint.

Interesting, shame that plug isn’t available over here (even though UK is obviously an option).

I’m using these which I got from Maplin (RIP). To control them I have an ESP8266 running MQTT to listen for the trigger from OpenHAB and uses the RCSwitch library to turn them on. Cost a lot less than £42 for three switches!

After pulling apart the Android app code, I’m fairly certain that the new smart plugs are actually rebadged versions of this: http://www.heimantech.com/product/143.html

Again, I can’t find a UK reseller, and judging by the smartthings forum, it’s almost impossible to find ZigBee UK sockets for sale anywhere except for some of the smartthings branded stuff (so, just as expensive).

Last night I wired up the smart plug thing in the binding with the appropriate channels, and it can switch the plug on/off successfully. I discovered that I needed to rebind the plug to the hub after the firmware update in order for it to be recognised correctly.

I still need to do some work to add debouncing to the switch channel as it can take up to 5 seconds for the hub to update the state correctly. I’m not sure if there is a “framework” way of handling this.

1 Like

Just had a reply from Drayton about my sudden change in TRV temperature:

Nice of them to tell us about that :roll_eyes:

Thanks for all your effort on this Andrew, it’s very useful. I’ve linked it up to InfluxDB and Grafana which has given some interesting insight into how the wiser actually works.

Slightly off topic, but have you looked at the temperatures being recorded by your TRVs since the upgrade? I’ve got Grafana charting the TRV temperatures along with what my room thermostats read. Previously, with the heating off, the lines in the same room were approximately parallel (ie. slight temperature difference but when it changed it changed by about the same amount). With the heating on the TRV might read up to 5C more than the stat, not great, but as you might expect when they’re next to a hot radiator. Since the upgrade they’re completely out of whack, room thermostat varying by 5C in a day and TRV by less than 1 (the room was noticably hotter / colder). Anyone seeing similar?

Actually yes, and I was thinking about sending a second email to support mentioning the discrepancy that now exists. I really can’t see how they think the new behaviour is an improvement.
I only have 1 room that has both a thermostat and a TRV, so I only have 1 set of data, but here it is:

Pre-update, minor heating activity right at start:
pre-update

Mid-update, no heating activity (recording broke after the update for a while):
post-update

As you can see, previously they tracked almost identically, now I see a ~2C difference in the temps.

Out of interest what firmware versions do you have on your thermostats and TRVs? Mine are 2371 and 6001 respectively.

Snap - you can see the upgrade go in about 12:00 on 14/06:


(The flat line on 12/6 12:00 to 13/06 08:00 is the plugin crashing which you appear to have fixed - thanks!)

I have two room thermostat firmware versions:
0401010100002371 and
0401000000002371

All my TRVs are now on 0201000000006001.

I’ll raise something with support to. I’ve not had cause to switch the heating on but could imagine they’ve tried to calibrate it for the over readings due to the TRV being near a radiator.

Is this still the latest jar @andrew-schofield? https://github.com/openhab/openhab2-addons/pull/3168

I’ve just downloaded it but still not seeing TRV Voltages. If I check Karaf it says the version is 2.3.0.201804232150, which I guess is from April?

Ah, no it looks like I need to update it for the 2.4.0 target. I’ll try and do that later this evening.

1 Like

Done. Updated download link in PR, direct link here: https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.draytonwiser/2.4.0-SNAPSHOT/org.openhab.binding.draytonwiser-2.4.0-SNAPSHOT.jar

I’ve not pushed the changes to enable smart plugs yet, as I still need to think about the debounce code for them. Additionally, I think I may need to think about a throttled http client to talk to the heat hub, as if you send too many requests in a short space of time it seems to start sending duff responses back (when you start seeing jetty errors in the log complaining about CHUNK_SIZE or CHUNKED_CONTENT, I’m fairly certain this is the cause).

1 Like

And it works! Great stuff as always @andrew-schofield :slight_smile:

I’m still in two minds about the sockets. It is a lot of money. I could get 10 Sonoff’s for that

1 Like

(Getting very off topic) Response from Drayton is that the TRV temperature sensors have been optimised in the latest release to read more accurately when next to a hot radiator, hence the under-reading in summer. They are “still working on optimising this”.

I’m not really sure what to think of this. I guess a way of optimising this would have been to include multiple sensors within the TRV so that a nearby heat gradient could be detected (and factored out), resulting in a more expensive device. They might also look at historic TRV demand to estimate whether it’s next to a hot or cold radiator.

Today one room has varied between 19-23 on the TRV vs 21-28 on the room stat, quite a significant difference which I suppose is not important for heating purposes, but might be if you need to know if a room is too hot.

Also my Android has just updated with release notes mentioning underfloor heating support (in certain countries). Has anyone spotted these devices (and anything in the JSON data from the hub)?