I am having the same issue if I select the override from the dropdown at the bottom of the card. If I select the same action from the pop-out card (three dots top right), then there is no error reports. Regardless, the action seems to work fine, just the error is being reported.
1 Like
Looking at the Wiser demand dunction, it was the heating channel which triggered the ‘spurious’ event.
I’m confident it is not associated with the fuel selected function.
I wonder if there is a frost type setting which triggered.
It’s the first time the outside temperature has dropped this low this winter.
Same issue here, using the preset dropdown menu. I’ve hidden the more info button on my thermostat cards, so I have to use the preset dropdown, but any of the boost or advance presets trigger this error message, although the function still works. The Cancel Overrides preset doesn’t trigger it though.
The source is:
Source: components/websocket_api/commands.py:280
so I guess raising it under the HA Core issues on Github is the best place. If there aren’t any issues with the same error logged already I’ll create one on there.
Had a quick look at this and also can get the error logged. I will have a further look into it as to why it is logging an error but still working. Im wondering if the function is being called twice, but sexond time without the preset value.
EDIT: fyi, the error is from our integration and not core HA.
Thanks Mark - ah Ok I’ll close my ticket on github in that case - I wasn’t quite sure where the issue was being generated from. I knew I’d pick the wrong place! I did spot something while searching, that had a similar message about presets not being valid, and some mode validation changes - not sure if it’s helpful/related or completely unrelated - Implement mode validation in Climate entity component by gjohansson-ST · Pull Request #105745 · home-assistant/core · GitHub
This does seem to be a bug/inconsistancy in the new thermostat card. As @DrJohnM61 said, it only does this if using preset off the card. Setting preset from the more info does not cause this error. I will raise it with the frontend repo.
I’ve looked at this more closely and it does seem to have been triggered by an iTRV.
So please ignore my earlier post…
1 Like
Hi,
I got this error using pre-sets in the tile card as well.
Mike
Hi,
After installing the integration I added the TRV temperatures to the graph I had of temperatures in my house, and was surprised to see lots of drop out.
Is this normal?
I plotted the signal strength status and there doesn’t seem to be a correlation to a poor signal and the null values.
My house if not that large, so all the TRV’s are within 10m of the hub, albeit with a few walls and a floor separating some of the TRV’s from the hub.
Do I need to get a few Wiser plug to extend the range?
Also the Wiser Zigbee Network card shows signal strength as a percentage, but I can only see the strength as a text state as an entity, is it possible to get the actual value so I can plot it on the same graph rather than relying on the state timeline since this does not quite match up?
Cheers.
Firstly, no this should not be normal. Do your more info history graphs show the same?
You can get signal strength % from the attributes of the signal sensor. Not sure if these are available in history or whether you need to create template sensor.
I had same thing happening, put a wiser smart switch in bedroom 1 after 1/2 hour powered hub off for 10mins powered back on and most trv migrated to plug.
have fixed ip addresses for most devices and importantl put the zigbee network on channel away from hubs no11 , also turned of smart auto channel on router
Hi guys,
Have started to use the set schedule from string quite a lot but have a question.
When using the below:
Type: Heating
Weekdays:
- Time: {{ timeam }}
Temp: {{ tempam }}
- Time: '15:30'
Temp: {{ temp }}
{% set sunset = as_timestamp(states('sensor.sun_next_setting'))|timestamp_custom('%H') | round %}
{% if sunset >= 21 %}
- Time: '20:00'
Temp: {{ temppm }}
{% else %}
{% set sunset =
as_timestamp(states('sensor.sun_next_setting'))|timestamp_custom('%-H:%M')%}
- Time: '{{ sunset }}'
Temp: {{ temppm }}
{% endif %}
- Time: '23:00'
Temp: 16
Weekends:
- Time: {{ timeam }}
Temp: {{ tempam }}
- Time: '15:30'
Temp: {{ temppm }}
- Time: '23:00'
Temp: 16
I get the following error:
Failed to call service wiser.set_schedule_from_string. Error setting schedule from yaml data - mapping values are not allowed here in “”, line 7, column 11: - Time: ‘16:12’ ^
The {{timeam}} and {{ tempxx }} part works as I have been using them for a while,
Its this part that is causing the error:
{% set sunset = as_timestamp(states('sensor.sun_next_setting'))|timestamp_custom('%H') | round %}
{% if sunset >= 21 %}
- Time: '20:00'
Temp: {{ temppm }}
{% else %}
{% set sunset =
as_timestamp(states('sensor.sun_next_setting'))|timestamp_custom('%-H:%M')%}
- Time: '{{ sunset }}'
Temp: {{ temppm }}
{% endif %}
Any ideas why that might be?
**** EDIT ****
Figured out it was indentation issue, all sorted now
Thanks @msp1974 I had completely forgotten to look at the history, since I’ve tended to put everything in Grafana first.
Looking at the history it does indeed look like the data is there.
And if I look in InfluxDB I can also see all the data, so it must be something stupid I am doing in Grafana (which does not surprise me since I’ve only just scratched the surface of what it can do)
As to the getting the signal strength % from the attributes of the signal sensor… I think that will have to wait until I have levelled up in my HA knowledge first 
Once again, thanks for pointing me in the right direction 
Its very simple, especially with the recent addition of the template helper.
Add a template helper (Settings → Devices and Services → Helpers tab).
Add this as the state parameter and set uom to %. Clearly change the sensor name for your specific room name. Controller_reception_percent is the signal strength of the device seen by the hub. You can also use the device_reception_percent to create a sensor for the devices signal strength from the hub.
{{state_attr('sensor.wiser_itrv_lounge_signal','controller_reception_percent')
1 Like
Does anyone know if the Electrical Heat Switch has energy/power monitoring? I haven’t been able to find that information anywhere.
Additionally, is anyone using it with Under Floor Heating (UFH)? My Dad has recently had Wiser installed for his central heating, replacing a faulty and unreliable Netatmo system, and has a seperate Warmup system, that also seems very unreliable and buggy, controlling his underfloor heating, which he is now also considering replacing.
It would be good to get some insight into how this works with UFH. For example, do you have to use the Wiser remote temperature probe, or can it be used with any UFH manufacturers probe? Unfortunately, rewiring a new probe under the floor is probably out of the question as it’s a stone floor.
Yes it does have energy monitoring. I use it through zigbee2mqtt with an aqara sensor providing the room temperature to the heat switch. Current power is provided but not energy so this must be calculated in HA.
1 Like
The device provide both Power and Energy by the integration
1 Like
I finally decide replacing all my EER53000 with the CCTFR6100 main reason being that the logic of the TRV seemed quite different at least comparing them on the HA interface (z2m) .
While the EER has the capability to calibrate room temperature, that the CCT isn’t, the heating demand , the sampling time for sending the data , and the capability to mantain the setpoint seemed to me more accurate on the CCT (which is also new generation of TRV compared to EER)
I also have a v2 hub (previously not supported by this integration but now happily yes) so i will look forward installing it and testing it.
I will then have a dedicated zigbee network for these devices , and another one for more generic appliances, managed directly from the z2m coordinator on the raspi.
My setup for wiser will be TRVs only on radiators running low temps, and the heating system being on heatpump.
I will not control the heatpump with the boiler rele, i will let it run based on the measurment made on the puffer.
I keep you posted.
I don’t have the heat switch but there’s a manual here:
https://www.draytoncontrols.co.uk/sites/default/files/Wiser%20Electrical%20Heat%20Switch%20Installation%20Guide%20Drayton%20-%2006490327001%20Iss%20F.pdf. It says it supports 3 specific temperature probe models and that others are not recommended. (33kΩ, 15kΩ and 10kΩ). All other UFH thermostats I’ve used have simply allowed me to configure the resistance of the probe. I’m fairly sure all my floors are fitted with 12kΩ sensors so might not be compatible.
Could someone check the configuration menu for the heat switch in the app and see what resistances are shown?
1 Like
I’ve just got round to updating to 2024.1.x, as they have brought in the Show current temperature as primary information option for the new thermostat card, which is my biggest bugbear with 2023.12 solved.
I’m just wondering if anyone has worked out how to use card_mod to modify the colours of the elements of the new thermostat card yet, particularly the central elements of the labels and the temperatures? It will probably save me spending hours reinventing the wheel if anyone has made any progress on this yet that they can share?