Drayton Wiser Thermostat Binding


(Rob Pope) #61

I was worried that might be the case. Not sure of the best way round it.

Thanks for your work on this. Do you mind if I test your version out? Is the jar on your github page?


(Andrew Schofield) #62

I think I can confirm this with my wife’s phone. If I alter the away setpoint on my phone, I can check what happens on my wife’s phone.
If it is an app only setting then I think it’ll need to be persisted in openhab somehow.

Edit: confirmed, my wife’s phone still had the default of 16C configured in the app.

Feel free to test out the binding, that’s why it’s on github, although the jar file isn’t in the repo so you’ll need to mvn install it.


(Rob Pope) #63

I should have an hour or so this evening to take a look.

Just a thought, but the away mode setpoint could be stored as a configuration parameter on the heat hub. It feels hacky, but no worse than storing it on the phone


(Andrew Schofield) #64

Sounds like a reasonable solution given it’s more a “set and forget” setting.


(Andrew Schofield) #65

Apparently support have put one in the post for me (free of charge) after I emailed them explaining the poor signal. Given the solid walls in my house I may actually need 2 (given the HeatHub is in the loft).

I wonder what data we’ll be able to pull from them, and also, if the rumours of them being smart plugs are true, can I push the correct data to trigger the switch?

Edit: Here’s a link to the most recent jar file: org.openhab.binding.draytonwiser-2.3.0-20170114.jar


(Rob Pope) #66

I’ve built your binding via mvn and copied the jar over. It found the heat hub, I added the auth token and everything appeared straight away!

I just need to fix my items up and I’ll get some testing done over the next few days.

I’m a fan of text configs rather than karaf. Do you have the format I need to create the things file? I guess it needs I.P address and auth token for the hub, then serial numbers for the devices and names for rooms?


(Andrew Schofield) #67

Great!

I haven’t tried configuring it using items and things files yet, but I guess the heathub needs the IP, authtoken and refresh interval. All other things should just need an “internalID” setting which is the contents of the ID field in the json response.

This is my first real use of OpenHAB so I haven’t really set everything up properly other than in Paper UI.


(Andrew Schofield) #68

My range extender arrived today and I was WFH, so I had a bit of a play.
I appears to be a rebranded OWON WSP402 which s a zigbee range extender and smart plug with consumption monitoring.
Sadly the only property currently exposed via the API is the ID, so no smart switching just yet.
Given I had to go into the loft to get it paired, I tried out a few things to see if you can get the secret from the heathub via a nicer route. Unfortunately I failed. Enabling joining mode (long press setup) doesn’t allow access, and entering setup mode seems to disconnect the hub from the regular network as it launches its own hotspot. This is quite annoying as some of the responses you can get back from the API suggest it has 2 network interfaces (wlan0 and wlan1), but I guess either they are just virtual to the same hardware, or it can only have 1 active at once.


(Rob Pope) #69

I’ve spent far longer than I should have getting the manual config right. I’ve successfully got the HeatHub showing, but struggling with the rooms. This is my config:
image

And how it looks in PaperUI
image

I wonder if it needs the controller? If that doesn’t work I’ll put it to one side for a while

EDIT: It needed the controller
image

Here’s the .things file config, Auth Token removed

Bridge draytonwiser:heathub:HeatHub [ ADDR="192.168.3.6", REFRESH=60, AUTHTOKEN="MySecretPassphrase" ]
{
	controller controller	[ internalID=0 ]
	room livingroom	[ internalID=1 ]
	room bathroom	[ internalID=2 ]
}

(Andrew Schofield) #70

Looks good. Do you think configuration was hard just due to the lack of documentation, or because of “bad design”?

I’ll add the .things snippets to the readme soon along with a .items snippet as well. Tbh I’m not sure why it didn’t work without the controller, as it shouldn’t make any difference I don’t think.


(Rob Pope) #71

It was lack of documentation. I couldn’t find any guides on structuring the bridge in the .things file (I’m positive I’ve seen one before) so used the Hue binding as my inspiration.

I’m having trouble with the setpoint showing as 0C at the moment, I’ll do some more investigation first.


(Andrew Schofield) #72

I’ve created an initial PR for this here https://github.com/openhab/openhab2-addons/pull/3168
Ideally need some data from people with multi-channel systems (i.e. hot water) as well.


(Andrew Schofield) #73

I think I’ve made manual configuration easier with the latest update. I’ve moved away from the somewhat ethereal internalID to the more sensible serialNumber and roomName for devices and rooms respectively. This means you no longer need to poke the API to work out what the device IDs are, as you can just address all your TRVs and Room stats by the more accessible Serial Number (printed on a sticker on each device). Rooms are addressable by their names defined in the Wiser app, in a case insensitive fashion.


(Sajid) #74

Hi guys, I am new to all this OpenHab+Wiser, can anyone point me out to some good guides about how to get the most out of Wiser with the help of OpenHab? I am a newbie!

I have been using other systems in the past few years, I was using EQ-3 MAX systems, that I have just replaced with Wiser to take advantage of the opentherm capabilities of the new boiler.

Thanks!


(Rob Pope) #75

I’d strongly suggest reading this thread as a starting place.

With the binding you have control of rooms as you do in the app and can get data at a device level if you wish. Personally I’d stick with the rooms for temperature reports and maybe monitor battery levels at a device level


(Sajid) #76

thanks will have a look!


(Andrew Schofield) #77

Out of interest is it a combi boiler, or a conventional boiler?


(Sajid) #78

Hi Andrew,

It is a Combi Boiler, and thanks to your great work I have managed to install your bindings into OpenHAB. Now I can see more information about my heating system on OpenHAB, question is how accurate is this information? Below is a screenshot

The heating is off at the moment, and a “Non Wiser” thermostat from the old system is reporting 18.9C, why I see so many different temperatures here? Which one is correct? Channel1 Heat demand shows NaN, is this expected?

This morning I also tried to “change” some of the values like temp set point from PaperUI, does this work for you? It doesn’t for me, keeps reverting back.

Today Wiser Heat app wasn’t working so I called the support team to ask about it, they told me that the cloud was down. I also mentioned that my wiser-hub seems to have poor signal, he asked me how I knew, I was tempted to tell him. I believe it is not good to tell them that we have access to it? Also it seems they have “access” to all the data collected from our home systems, is there anything we can do about it?

Thanks!


(Sajid) #79

Btw, all is from the same room.


(Andrew Schofield) #80

I’m not sure why you have duplicate temperature items in your Paper UI for the room stat and trvs, but that issue aside, the temperature reported by the app is the one for the “room” which as far as I can tell is always the lowest value of all the devices assigned to that room, i.e. in your case the room stat.
The heat demand NaN value should update itself in time, I’ve noticed that occasionally I need to refresh the paper UI page and then let it complete a background update cycle to start getting true values. I think this happens at the moment because I don’t persist any values, so lots of them get initialized with NaNs.

The setpoint issue is one I intend to fix. It does work, its just not obvious that it has worked. Basically the data is pulled from the hub at the refresh interval configured for the hub (default 60 seconds). When you change the setpoint it sends the update, but doesn’t do a full refresh immediately, so when paper UI updates itself it will be pulling old data (i.e. the previous setpoint). When the background update fires, this will update the states and paper UI will catch up.

A workaround for the moment is to decrease the refresh interval (although I think you need to restart the binding for this to take effect). The long term solution is for me to refresh the state data whenever an update is pushed to the hub, which will make the UI appear more responsive.

I’m hoping to find someone with a multichannel controller so I can work out what hot water data we can get via the API, but not to worry.