I spotted it in the Android app. Not all my devices have window open yet, but they do have device lock.
https://photos.app.goo.gl/8HVlufkXahXgMg3f1
I’ll see if I can grab the json later and I’ll send it over
Interesting. It looks like it might be dependent on the firmware version of the TRVs etc. Mine still have an older firmware on them.
Is the screenshot in your original post from the ios changelog, or somewhere else?
The description? That’s from the Drayton Wiser user guide online.
It’s curiously also available on the Room Stats. Notice the new “DeviceLockEnabled” parameter
{
"id": 50904,
"ProductIdentifier": "RoomStat",
"ActiveFirmwareVersion": "0401010100004046",
"Manufacturer": "Schneider",
"ModelIdentifier": "Thermostat",
"HardwareVersion": "1",
"SerialNumber": "000B57FFFEXXXXXX",
"ProductRange": "Wiser Heat",
"ProductModel": "Thermostat",
"ProductFamily": "Wiser Heat",
"OtaImageQueryCount": 0,
"LastOtaImageQueryCount": 1,
"DeviceType": "SleepyEndDevice",
"DeviceLockEnabled": false,
"DisplayedSignalStrength": "Good",
"BatteryVoltage": 29,
"BatteryLevel": "Normal",
"Rssi": -65,
"Lqi": 140
},
{
"id": 49196,
"ProductIdentifier": "iTRV",
"ActiveFirmwareVersion": "0201000000004046",
"Manufacturer": "Schneider",
"ModelIdentifier": "iTRV",
"HardwareVersion": "0",
"SerialNumber": "90FD9FFFFEXXXXXX",
"ProductRange": "Wiser Heat",
"ProductModel": "iTRV",
"ProductFamily": "Wiser Heat",
"OtaImageQueryCount": 0,
"LastOtaImageQueryCount": 1,
"DeviceType": "SleepyEndDevice",
"DeviceLockEnabled": false,
"DisplayedSignalStrength": "Good",
"BatteryVoltage": 26,
"BatteryLevel": "Low",
"Rssi": -65,
"Lqi": 140,
"PendingZigbeeMessageMask": 0
}
Ah ok, looks like I’m going to have to wait for my firmware to update.
I’ve just added some extra items to the roomstat and trv things which expose more usable battery level and signal strength values, so they now work with the qualityofservice and batterylevel dynamic icons, which look much better on a sitemap.
Once the firmware on my devices updates, I’ll take a look at adding device lock and open window detection. Drayton keep adding more features faster than I can add them to the binding at the moment 
1 Like
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 
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. 
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 
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:
Mid-update, no heating activity (recording broke after the update for a while):
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.