Drayton Wiser Thermostat Binding

Makes sense.

Do you know where OpenHAB stores the schedules it pulls from the controller?

I configured openHAB to save the schedules to the mapdb database from it in memory copy.

NB I came accross a bug #5206 in mapdb persistence service where the database will keep growing and fill the disk up. To avoid the bug use a mapdb.persist file like this:

Strategies {
    default = everyChange
}
Items {
    Heating_Schedule        : strategy = everyChange, restoreOnStartup
    HS*, HS_Home*, HS_Work* : strategy = everyChange, restoreOnStartup
}

Restarting openHAB will compact the database.

Hi,

Was this causing OpenHAB to crash?

I noticed after getting everything working after about a day OpenHAB would completely crash and not restart!

Luckily I’d made a backup disk image for my RaspPi. I’ve made the changes so let’s see what happens :crossed_fingers:

Hi,

Has anyone actually monitored how many times their hub goes offline?

Since installing OpenHAB I’m shocked, maybe my hub is faulty, I’ve tried different routers etc but am still getting up to 20 disconnections a day.

Drayton have advised me to swap the unit to rule out it being faulty.

Just curious if anyone else has noticed so many disconnections.

If you’ve installed the latest version of the binding from the marketplace then this seems to have a bug that means the bridge looks to constantly lose connection.

I uninstalled the binding through PaperUI and manually installed the previous version from Andrew’s Google drive.

Let me start by saying ‘awesome work’. I went with the wiser system as it works without internet, is from a ‘proper’ heating company and has individual room control.

I’ve had the system running (system 1, 1 thermostat, 5 trv’s) for a few months now using your binding.

I was getting constant disconnects since having it. So today I’ve done some testing and I’ve got to the root of the problem and now no disconnects.

The problem is as follows:
Drayton is set up for all rooms in my house.
I currently have 1 room left to add a trv into but this was added as a thing in the binding and the items setup ready.
This was the cause.
Although the Drayton app functions fine with the room, the binding errors out if there are NO devices present in that room.
Since removing the room from my thing file no more dropouts.

So don’t add rooms (things) for empty rooms. (Drayton app still has the room present)

Maybe this was the cause for some other users of the binding.

Been solid for 2 hours now. (Using the above, not the latest)

I spoke too soon. Was solid for about 6 hours, now back to disconnects every 15/20 mins.
Is this the binding or the hub??
I haven’t had a chance to check in detail (all my effort going into lightwave integration atm).

Does this binding work with the smart plugs?

I have to agree, this is an awesome piece of work.

I have just installed the Wiser controls and so far they seem to be working OK but I thought I would check out the signal strength to see if I might have range trouble when I try to add some new valves/stats further away. It appears that Drayton have removed the signal strength display from both the thermostat screen and the app in an “upgrade” about a year ago. I have tried to connect to the various signal strength channels in the hub and room stat things but the items stay at NULL. Could this be for the same reason?

Hub firmware version 2.36.3
Thermostat firmware version 0.32.0
(App version 3.9.0 b24)

OK solved it. I had the rooms configured as things but not the actual stats, therefore I could get temperature and humidity. I have now added the stats, which do have signal channels.

The theory is yes.

Frustratingly Drayton haven’t put the serial number on the plug as far as I can see so I’ve grabbed it by querying the /domain URL.

My setup is as follows
Things:

{
        controller      controller
        room            livingroom      [roomName="living room"]
        room            bathroom        [roomName="bathroom"]
        room            bedroom         [roomName="bedroom"]
        room            spareroom       [roomName="spare room"]
        itrv            livingroomTRV   [serialNumber="90FD9FFFFEAXXXXX"]
        itrv            bathroomTRV     [serialNumber="90FD9FFFFE6XXXXX"]
        itrv            spareroomTRV    [serialNumber="90FD9FFFFEAXXXXX"]
        itrv            bedroomTRV      [serialNumber="90FD9FFFFE6XXXXX"]
        smart-plug      lampSocket      [serialNumber="000D6F0014BXXXXX"]
}

Items:

Switch  LampPlug   "Lamp Plug"   ["Switchable"]  {channel = "draytonwiser:smart-plug:HeatHub:lampSocket:plugOutputState"}

As far as I can tell that should work, but the state is showing as null. @andrew-schofield - is my item in the correct format?

Hi and thanks for the development of this binding for openhab.

After installing the 2.5 jar the wiser hub was discovered in paper UI and once scanned all things (rooms,trvs etc)were also auto discovered.
At first glance it all works however I am having the following problems with it.
The wiser hub drops off the network a few times a day(setup led goes red) but only if the openhab binding is active, it then comes back online after some time. (I dont have any rooms defined without associated devices as one other user speculated that caused similar problems)
Wiser Things listed in paper UI on occasion flicker between online and offline and correspondingly the log shows lots of entries
changed from OFFLINE (COMMUNICATION_ERROR) to ONLINE
changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)

To the extent that I am getting 20-30 events per second
If I disable individual things and re enable them they generally come back up online and stay stable.
Sometimes a thing will just start spontaneously flip flopping its state several times a second, for example
2019-12-10 09:29:01.333 [vent.ItemStateChangedEvent] - Heating_Dining changed from OFF to ON
2019-12-10 09:29:01.466 [vent.ItemStateChangedEvent] - Heating_Dining changed from ON to OFF
2019-12-10 09:29:01.525 [vent.ItemStateChangedEvent] - Heating_Dining changed from OFF to ON
These type of oscillations are only ended by disabling the thing then re enabling.

Even when there are no such problems occurring and I check the openhab event bus there are around 30 status update messages per second from the hub which seems excessive.

Any ideas on these problems?

My setup
The heat hub is set to update every 60 seconds in paper UI.
I am running the latest stable release of openhabian, v2.4.0 running on a pi3b connected over ethernet
Wiser Hub is on firmware 2.40, 1 room thermostat and 5 trvs
Trv firmware 0.36.1

Thanks

Hi MK,

It appears your setup it virtually identical to mine. I have the same issues and have been running OpenHab since March. I spent hours on the phone to Drayton because I though my hub was faulty, I stopped using OpenHab and the hub is fine so it must be OpenHab causing the issues.

I stop start OpenHab now on the Pi when I need to use it. My hub was disconnecting up to 100 times a day!

Hopefully someone will be able to fix it or tell us what the issue is.

Use the previous version of the binding :+1:

Good advice. There is a bug in the latest version that causes the binding to tie up all of the handlers which affects not only itself but can impact on other bindings too. In my case, it stopped Astro and Network from working.

Can someone help me to get my thermostat humidity to show.

Everything else works fine I have an entry is my items file as;

Number:Humidity Landing_humidity “Humidity [%.0f %%]” (GF_Landing) [“Humidity”] {channel=“draytonwiser:room:HeatHub:Landing:currentHumidity”}
and it appears as a channel in PaperUI for both the room Landing and Landing Thermostat however when I go to make a link there is no entry for anything relating to humidity.

Thanks

Hello everybody,

I want to combine the windowsensor with the wiser-system. I’m looking for an funktion oder methode to set the Setpoint down if the window is open (status= false) and reset to the normal value if the window is closed (status=true).

KR

Kevin

I have a Number item that looks the same as yours.
Number downstairs_humidity “Downstairs Humidity [%.0f %%]” [“Humidity”] {channel=“draytonwiser:room:HeatHub:downstairs:currentHumidity”}

This is what I see in PaperUI.

Although I use text configuration, I often copy the channel reference from PaperUI

Hi All
Hope that this is useful as I managed to get the hub secret without leaving the sofa or changing the hub to an AP or rooting my phone. I installed Packet Capture from the Play Store. Run it with the play1 button at the top and select the Wiser Heat app. Then launch the Wiser App. Go back to the Packet capture and click stop. when you inspect the packets you will find the secret in the GET request.

I saved the request to a file copied it to the PC and then did a cut and paste of the secret into the binding configuration, instantly worked.

I have the same problem. Open HAB was installed in the last week, on the surface all looks well, but I noticed several times when I have walked past the Wiser Hub, it was RED. It is certainly related to the OH being connected. Before I started using OH I had never seen the hub go RED except when the router was being rebooted.

I am wondering if the hub gets defensive when a message exchange does not complete in time and OH is not responding quickly enough and so goes off line and resets the WIFI, this give rise to the entries in the log.

2020-05-25 22:07:11.776 [hingStatusInfoChangedEvent] - 'draytonwiser:room:WiserHeat02851D:hall' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2020-05-25 22:07:11.781 [hingStatusInfoChangedEvent] - 'draytonwiser:boiler-controller:WiserHeat02851D:controller' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2020-05-25 22:07:11.784 [hingStatusInfoChangedEvent] - 'draytonwiser:itrv:WiserHeat02851D:90FD9FFFFEC37F74' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2020-05-25 22:07:11.787 [hingStatusInfoChangedEvent] - 'draytonwiser:hotwater:WiserHeat02851D:controller' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE