Thanks, yes my house is unoccupied and I am trying to keep it frost-free.
Understand that in an occupied house that it’s more efficient to heat rooms that need it, but when the temperature of the rooms in the house is 8 degrees, what I am more interested is keeping the house frost free, and the latent heat created by just keeping the house frost free could be more effective when all rooms are raised a few degrees
If you let it cool down that much, you need to consider a few other things as well.
When you will start heating, which is far more higher temperature than 8 degrees, you will create a condensing atmosphere what could hurt electronic equipment inside the building. Also you might going to get damp walls and high chance of mold.
Edit: There is an integration for mold indicator built into HA.
Just now the Wiser app says it is 2°C and snowing here. It is sunny and somewhat warmer - Met Office says 7°C.
Given that discrepancy, I’m not sure I would want to use the Wiser measurement in any automations.
Edit: mind you BBC says 4°C so seems there is little consensus on the conditions in my part of the world.
“Given that discrepancy, I’m not sure I would want to use the Wiser measurement in any automations.”
But surely this reading IS used by the hub to determine the heating required. My previous ancient Drayton controller had its own outside thermal probe which measured and used the temperature on my home’s north facing wall. I really would prefer to have that option with the Wiser system (along with ethernet connection) although, in every other respect, I’m very happy with my current 18 TRV, infinitely controllable system.
Home Assistant newbie here, so please be gentle
I’m playing around with the new Electric Heat Switch, but am struggling to get data from the heat probe ( as part of my electric underfloor heating setup) the api seem to support the entities but I’m not able to read any data from those items. I can see the data from the associated room stat, but not all the switch items.
interestingly the diagnostic data suggests the floor sensor isn’t fitted, which might the issue. I’ll be in touch with Drayton about that.
BTW I’m running HA within Docker on Synology NAS. I’m certainly not a coder at all but am highly impressed with the work you guys have done
Ian, welcome to our community. Can you explain a little more with maybe some screenshots. Neither Angelo or I have one of these to test on so it maybe something missing that we can add.
Maybe also post an issue on our github with the diag output.
Hi,
Here’s the data from the diagnostic, which might explain why I’m not see any data from the floor probe. Best thing is that I sort the thing out with Drayton, then get back to you. I’m sure when I first installed it yesterday I saw lots of interesting entities, which are not present when I’ve just now reloaded the Wiser Integration
I think the Switch itself is a work in progress for Drayton generally.
],
“HeatingActuator”: [
{
“id”: 8,
“OutputType”: “Relay”,
“FloorTemperatureSensor”: {
“Offset”: 0,
“SensorType”: “Not_Fitted”,
“Status”: “Normal_Operation”
},
“MeasuredTemperature”: 171,
“OccupiedHeatingSetPoint”: 150,
“CurrentSummationDelivered”: 6116,
“InstantaneousDemand”: 0,
“RoomId”: 8
I live in solid wall house which has no wall insulation, so outside temperature makes a huge different how long it takes to heat rooms. As temperatures starts to drop in UK I’m finding myself keep updating schedule differently in each room which is very annoying!
If setting living room TRVs to 21C resulted in room being 19C, today it struggles to reach 18C. Study being set to 19C used to result in 20.5C, but now I need to change it 17C as wall gets so cold and TRV reads room temperature incorrectly. Even more annoying thing - I have to keep increasing study temperature during the day for actual room temperature stay at 20C
Is the only option to buy HA temperature sensors and keep boosting rooms using HA based on it?
Wiser room thermostat is silly solution - it cost a lot and I have one which got bricked during their automated firmware update and (as I’ve bought it from eBay) they only offered me a 10% discount to buy new one as a solution.
If you dont want to buy roomstats then probably yes. If you look at our recipee section on gihub you will see how to set this up with external sensors. You could also move all your radiators! 
I have the electrical heat switch which I have replaced an existing thermostat with for under floor heating. It isn’t recognising the heat probe that is already there so logged a ticket with Wiser support - they responded with:
"The sensor options for the EHS are rated at:10K Ohm12K Ohm15K Ohm33K Ohm47K Ohm A 3rd party sensors with the resistance above should be compatible. "
So I will be checking the resistance of the existing probe to see if that meets the requirements but not sure if I can replace the probe if it doesn’t though as it’s embedded in the floor.
A firmware update resolved the config issues, with an ability to define the type of floor probe, upper and lower temp limits and a sensor offset. I can’t see these being surfaced within HA so whether they’re exposed through the api, i’d certainly be interest and happy to test.
The issue for me is the insistence on the room stat , who’s reading in an electric UFH environment can be affected by other things, drafts, radiators etc. To my thinking the control of the floor should be based on the floor temp, not air temp.
So if the Upper limit could be exposed and set via a control it should be possible to use that to set a target temperature rather than the one in the room stat. In other words you’d set the target temp on the room stat to something silly, say 30c ( current average around 17c) then set the Floor Sensor Upper limit (MaximumTemperature) to a target temp, then monitor MeasuredTemperature . I can effect that manually by amending the device settings within the Wiser Device so it ought to be possible within HA, if the data is exposed. The alternative would be to set the Upper Limit in the app to something reasonable then simply use Wiser or HA to turn the Room Stat on or off.
The section of the diagnostics now reads. This suggests to me at least that data is exposed to HA, just not available in the entity section.
HeatingActuator": [
{
“id”: 8,
“OutputType”: “Relay”,
“FloorTemperatureSensor”: {
“MinimumTemperature”: 70,
“MaximumTemperature”: 260,
“Offset”: 0,
“SensorType”: “NTC_10K”,
“MeasuredTemperature”: 241,
“Status”: “Normal_Operation”
},
“MeasuredTemperature”: 176,
“OccupiedHeatingSetPoint”: 150,
“CurrentSummationDelivered”: 10006,
“InstantaneousDemand”: 0,
“RoomId”: 8
Ian,
The FloorTemperatureSensor section is currently not in the api, but can be added. I will need a full diagnostics output (it is anonymised so not sensitive data in it) to be able to put in our mock server to ensure this works. Can you raise an issue on our github and post there.
I assume the min/max, floor probe type and offset can be changed in the app? Can you also (in the github issue) provide the ranges/options available for these settings.
Are you able to change the OccupiedHeatingSetPoint in the Wiser app or is this the setpoint from the Roomstat?
Can I ask how you managed to get the firmware update for the electrical heat switch?
I’m trying to reproduce the History Graph Card for my Wiser climate entities created by this integration using the Mini Graph card.
Out of the box the History card has an entry that shows when the heating was on (the orange line/fill below)
Also, looking at the attributes I’m not sure what they all mean - particularly what is the difference between temperature and current_temperature, and what is the difference between displayed_setpoint and current_schedule_temp?
The heating bars is a function of the climate card, however, you can use is_heating attribute instead. Temperature is target temp - HA choice not ours! Display_setpoint is also current target temp but can be from schedule, boost, override, away etc, scheduled_temp is just what the schedule is currently set to, not necessarily what is active per previous.
All, quick question…
I have a TRV where the LEDs are slowly flashing in groups of 5 pulses. Left Red, Middle Green, Right Blue. Can anyone say what this means as it doesn’t appear to be in the table of LED options?
The valve seems to be working, reporting 40% battery.
Resolved myself. Seems the identify switch was on, so it was identifying itself. Don’t know how the switch got turned on, but turning it off stopped the flashing!
Thanks - that clarifies. The graph on the climate card ultimately looks a lot better than what I managed to figure out with the mini-graph card:
I can live with what the climate card allows. If only I could do something about the axis and legend label styles.
Here is an interesting article on cost and health implications of turning down the thermostat - comments are quite good too.
Anyone know if something changed with the wiser system in the last week or so? I’ve been having trouble with ours - rooms being much hotter than they should be (and the rads are hot).
Went into the bedroom the other night and it was sweltering… checked the wall stat and it was reading 22.5 but the setpoint was 19… and the rad was hot.
Just went in another room and the same, it was 22 but the setpoint is currently 17.5 as the room is not used… again the rad is hot…
There are fresh batteries in both of the troublesome trvs, no offline alerts or anything from the wiser app, yet it’s like they called for heat then went offline and just kept heating?
When I had the issue with the trv in the bedroom I hit identify in the app and the LEDs did not flash… which is what makes me think it was offline, yet the app didn’t report it was 
I deleted the trv and repaired and then it would identify ok, but also had the same behaviour on that trv a day or two later… oddly it’s the closest one to the hub!
