Yeah, that seems to be controlled by the build runner attached to the pull request unfortunately, I can’t work out if it’s possible to configure it at all.
Any idea what happened here (huge negative temp value):
2018-02-05 21:06:19.693 [vent.ItemStateChangedEvent] - SmartValve31688_Temperature changed from 20.600000381469727 to 20.700000762939453
2018-02-05 21:06:27.633 [vent.ItemStateChangedEvent] - Controller_Channel1RequestingHeat changed from OFF to ON
2018-02-05 21:07:19.457 [vent.ItemStateChangedEvent] - Living_CurrentHeatDemand changed from 86 to 20
2018-02-05 21:07:19.461 [vent.ItemStateChangedEvent] - Living_CurrentlyRequestingHeat changed from OFF to ON
2018-02-05 21:07:19.532 [vent.ItemStateChangedEvent] - Yroom_Temperature changed from 18.799999237060547 to -3276.800048828125
2018-02-05 21:07:19.537 [vent.ItemStateChangedEvent] - Yroom_CurrentHeatDemand changed from 43 to 0
2018-02-05 21:07:19.541 [vent.ItemStateChangedEvent] - Lroom_Temperature changed from 16.5 to -3276.800048828125
2018-02-05 21:07:19.548 [hingStatusInfoChangedEvent] - 'draytonwiser:itrv:WiserHeat028823:90FD9FFFFE518235' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)
2018-02-05 21:07:19.564 [vent.ItemStateChangedEvent] - Sroom_Temperature changed from 17.299999237060547 to -3276.800048828125
2018-02-05 21:07:19.597 [hingStatusInfoChangedEvent] - 'draytonwiser:itrv:WiserHeat028823:90FD9FFFFE509FBF' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)
2018-02-05 21:07:19.603 [hingStatusInfoChangedEvent] - 'draytonwiser:itrv:WiserHeat028823:90FD9FFFFE5182E6' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)
2018-02-05 21:07:19.609 [hingStatusInfoChangedEvent] - 'draytonwiser:itrv:WiserHeat028823:000B57FFFEAA1C45' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)
2018-02-05 21:07:19.654 [hingStatusInfoChangedEvent] - 'draytonwiser:itrv:WiserHeat028823:90FD9FFFFE104335' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)
2018-02-05 21:07:19.669 [hingStatusInfoChangedEvent] - 'draytonwiser:roomstat:WiserHeat028823:000B57FFFEE941B6' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)
2018-02-05 21:07:27.667 [vent.ItemStateChangedEvent] - Controller_Channel1HeatDemand changed from 86 to 20
2018-02-05 21:07:27.677 [vent.ItemStateChangedEvent] - Controller_Channel1RequestingHeat changed from ON to OFF
2018-02-05 21:08:19.494 [vent.ItemStateChangedEvent] - Yroom_Temperature changed from -3276.800048828125 to 19.0
2018-02-05 21:08:19.528 [vent.ItemStateChangedEvent] - Yroom_CurrentHeatDemand changed from 0 to 52
2018-02-05 21:08:19.545 [vent.ItemStateChangedEvent] - Yroom_CurrentlyRequestingHeat changed from OFF to ON
2018-02-05 21:08:19.557 [vent.ItemStateChangedEvent] - Lroom_Temperature changed from -3276.800048828125 to 16.5
2018-02-05 21:08:19.586 [vent.ItemStateChangedEvent] - Sroom_Temperature changed from -3276.800048828125 to 17.299999237060547
I can’t see anything suspicious in the logs, any ideas?
Thanks!
Yeah, it just means that your TRV disconnected from the zigbee network. The temperature value is actually the MinValue of a signed short integer, which I’m going to use as a “Connected/Disconnected” state check. I had the same issue last night with one of my TRVs, I just need to alter the temperature state to return undefined (null) when this happens which will clean up the charts.
Unfortunately it my case it was more of a problem because the TRV had actually fully disconnected and wouldn’t re-join without removing the batteries.
In other news, I did manage to completely replicate your situation where everything stops updating. I think I’ve managed to narrow it down to the following weird situation:
- When the httpclient hits a timeout exception, in certain situations it will fail to recover and never send any more requests.
I don’t know why this happens, it could be a bug in jetty, but that seems unlikely. I’m going to have a dig around in the source code for some other bindings that do regular http requests to see if they handle things differently.
The current code in github also has a “bug” which means that after a while all your things apart from the bridge will appear in the offline state, but will keep updating. It doesn’t affect the reporting/logging, it just appears wrong. I’ve fixed this locally but not pushed my changes yet.
2 Likes
So, I’m still investigating the timeout bug, which I’ve partially replicated again, but in the meantime I’ve fixed the large negative value issue. The rooms should report a null/undefined temperature when the device loses it’s network connection. I’ve also added a new zigbeeConnected item to the roomstat/trv things to track when a device decides to fall off the network.
The README file is now up to date with all supported channels, + some that I hope to include in the near future.
These are essentially:
- Move
awayModeSetPointto a config variable, as it isn’t persisted by the controller - Add the on/off setpoint for hot water
- Add boosting (basically set a number of hours for boost) to rooms and hot water
- Possibly add schedules to room and hot water.
I’d quite like to add schedules as it means if openHAB breaks, my heating can still work as normal (i.e. in auto mode).
Can anyone else think of any other channels that are necessary for this binding to be usable?
1 Like
First of all, thanks again for your hard work!!
What do you mean when you say:
“I’d quite like to add schedules as it means if openHAB breaks, my heating can still work as normal (i.e. in auto mode).”
My heating still works if openHAB is down, as I am using it merely for monitoring. at some point I may manage it from openHAB, but still if you configure it this config data will be stored in the devices?
If opentherm is wired from boiler to WiserHub, can we see anything about the boiler status, ie. pump speed, flow, efficiency?
Thanks!
1 Like
I mean, I’d like to be able to use openHAB to automate the hub schedules (and letting the hub determine when to turn setpoints on and off etc), rather than the full blown solution of letting openHAB do absolutely everything, which requires the rooms to be in manual mode, with openHAB changing the set points itself. In the former scenario, if openHAB breaks for some reason, I know that the hub is still going to keep to a reasonable schedule, whereas in the latter scenario I could end up with everything stuck in the off state.
As it stands, the binding is perfectly usable (I think) in the full openHAB automation sense in terms of features (other than the timeout bug).
What I ideally want to be able to do is have “scenes” whereby I can set a particular room/house schedule. I.e. if either of us in on annual leave we want the house heated during the day, if one of us is on a late shift, we want the house heated in the morning, if we have guests staying we want the spare room heated etc. All this could be automated from a calendar binding, where it just triggers the correct “scene” and sends the required schedule to the hub.
Sadly not based on the json dumps you’ve provided, and my poking of the android app source. There doesn’t appear to be any OpenTherm specific data there. I wonder if it’s something that drayton will open up in the future, the hub is presumably capable of reading the data from the OpenTherm module…
1 Like
I made a change before the weekend which seems to be more stable for me. I set up a raspberry pi on Friday evening and it’s still going strong, so it might be worth a try. Still getting timeout messages in the log, and I suspect it might be a thread safety issue, which I think I can fix.
Thanks for this, I will install and test it soon, however I noticed that now I see another issue which is similar but different (I think), sometimes I have to restart the OS in order to recover the system. Basically I am able to ssh and navigate, but it stops graphing until I reboot it, restarting the openhab service doesn’t work always.
Hopefully we can find a way to have this up and running in a stable way.
1 Like
Interesting, I was about to post the same thing. It looks like my “fix” has just allowed a working system to last a bit longer, mine died overnight last night and stopped updating the charts as well. I tried rebooting, but that didn’t appear to have worked this morning, but I’ll check again tonight.
1 Like
At least I am not alone 
I’m just reading the manual to see what I need to do to bleed a valve and found this. Window detection is operational and just turns off the valve for ten minutes.
With the new IFTTT away mode I cant see any way to change the away temperature - it just goes to 16C. Have I missed something?
Another grumble. If the internet or cloud is down I can’t connect to the hub via the app. This seems contradictory to the FAQs on the Wiser website. Has anyone else found this to be the case? Openhab connects ok of course!
The android app doesn’t appear to have been updated with open window detection yet, although the endpoint is already exposed via the API so it shouldn’t be hard to add it even though I won’t be able check that it’s working.
I’ve been out of the loop recently due to family circumstances, so haven’t made any progress on fixing the weird timeout problems, and I don’t actually know what state my Pi as got itself into.
@ultraviolet you’re right, the website says it should work without internet, and I think it has for me on the odd occasion that my router decides to boot everyone off. When you start the app it seems to fire requests off to the known local IP of the hub, and then to the cloud, so it should normally be able to connect directly to the hub. The android app is still a bit shoddy though and will regularly take ages to to load the room list and/or find the heat hub. I have no idea what it is doing when it is shows these messages on screen.
@ultraviolet I did ask about this to the wiser support team and they said that it should work without internet access, actually they had a cloud outage just the day after I bought my system and I had a call with them and they told me that it should work without internet access, but because of the nature of the outage it was not working at that time.
In my opinion that was a lie, however I didn’t want to argue with them but it is quite awful that without internet access this doesn’t work properly.
Hey Andrew, hopefully your family circumstances were nothing major, but wish you good luck with it.
Take care!
I was affected by the recent outage of the wiser cloud. I contacted support and they walked me through connecting the app directly to the hub. I think I was lucky and got the right support guy as how to do this is currently undocumented.
Basically it involved going through the setup procedure and selecting the local hub instead of the cloud.
I now have an spare phone with with the app configured to connect locally. Just in case there are future outages.
Hey guys,
I’ve just had another go at trying to fix the timeout issue, which I’m now testing locally on my Pi. I haven’t pushed the code to github yet as it may not even work. I’m going to give it a few days to see what happens and report back.
Apologies if I am hijacking a thread…I have wiser system with 3 TRV’s andca range extender, and have been looking for some way to trend what the system is doing…I came across openhab and the work you guys were doing. I followed the instructions, got the secret, installed the addin and discovered all my devices … all in half an hour! BUT… it does not discover any of the TRVs…do I really have to take each valve off and find the sticker with the serial number in it? Have I missed something? Is there any debug output I can look at? Can I test anything for any of you guys? Windows 10. Thanks, Paul
Did you find the secret using something like Postman or SoapUI? If so browse to http//IP_ADDRESS/data/domain/ and you can find the TRV serial codes from there. I’m surprised they’re not found in paper ui though