The valve is indeed there but it seems that it does not work …
At this moment, I dont’ see how to change the valve value.and the value back…
To setup the temperature, I change to “auto” the “HVAC mode on TRV” of the device and set the “current_heating_setpoint”. To stop, I change to “off” the “HVAC mode on TRV” of the device
The “posiiton” seems not working. I tried with “auto” or “heat” mode but without success.
I can set the away temperature on the individual valve, but not on the group. If anyone has any thoughts, please let me know. Perhaps I can figure out a script that cycles through all the valves one by one changing them.
I created a group in the zigbee2mqtt and used it with payload but no luck.
This is really strange because I am not getting an error in the zigbee2mtt log.
The only solution I see is to open an issue in the zigbee2mqtt github.
I stucked with interpreting payloads on my Tuya smart lock and kindly looking forward to 3rd part. I’m very thankful for first and second article and very appriciate for your work. Is there any chances that you will publish 3rd part of this tutorial?
Hi - I’ve got a really basic problem - I can’t get the TRVs in to pairing mode. The instructions start: long press home button, then press “+” button. My problem is that after long-press on home button the “+” button does not light up so I can’t get any further with the pairing process. I’ve got three and they all behave the same,
Not sure this is the right place to ask (as this is more of scripting question), but it does regard these valves, and Murada99 has been helpfu before (thank you!)
I am slowly building out a group of these valves to help control the heating in my house and will probably eventually have about 14
I would love to be able to send settings to all 14 valves simultaneously, rather than having to create 14 separate scripts/automations. As above, it would seem that the groups function of zigbee2mqtt would be helpful, but it does not seem to support these radiator valves currently.
Question:
Is there some way to create a script or automation that can cycle through the list of valves, generating an MQTT.publish call for each of them? I have been focusing on trying to write a script, but not having a lot of luck. I can create a template (below) that generates the list of commands I want to send, but MQTT.publish doesn’t seem to accept a template under data.
{% for state in states.climate %}
topic: zigbee2mqtt/{{ state.name }}/set
payload: '{"away_preset_temperature": 12}'
{% endfor %}
Nor can I find a straightforward way to loop through the list using the scripting language, changing the MQTT.publish topic, as it doesn’t seem to support “for” loops easily. Does anyone have any tips or guidance for me on how to do this? Any and all help is very much appreciated.
When you first plug it in, you have to set the hours and minutes, and then do the initial valve adaptation run. Did that all go correctly? Once that is completed, then you can long hold the home button, navigate to the “wifi” and start the actual pairing.
A super helpful individual named Taras showed me how to write a script to iterate through a whole series of these valves (the question I had asked above).
Hi Joe
Yes I tried:
Power on (i.e. insert batteries and close top)
Wait for boot i.e. all lights to come on then go out
Short press of home button - steady wifi light and “h” and “m” (these last two horizintally aligned)
Long press - nothing changes; “+” does not light up
Someone else has suggested I set the hours and minutes, and then do the initial valve adaptation run before trying to pair - I’m going to try that later today
I would like to make a button card in LoveLace that displays current temperature - but there is no sensor to pull from. Is it possible to create a “virtual” sensor that pull the local temperature from the thermostat - or to solve it somehow else?
I have got two out of three (haven’t tried the third) to connect. The solution was (as Ted suggests) to
physically install the valve on a radiator
get it to do initial valve adaptation
It is then possible (but not that easy!) to get the valve to enter pairing mode - which was just not possible before
LATE UPDATE: My Mijia door sensor seems to communicate via the repeater even when I paired it directly via the Coordinator. I had the idea that this door sensor didn’t support to be reassigned to a repeater after pairing. Seems like I was mistaken. The only issue then would be that you have to temporally move the sensor near the Coordinator for pairing it.
After so many stability problems with zigbee2mqtt I decided to give a try to HASS Zigbee integration.
I don’t know why I didn’t give it a chance before. After one week of using it I can say the integration feels more stable than Zigbee2Mqtt. The TRVs respond 5 times faster.
I had to re-join each of my Zigbee devices again. The UI for the joining process is very easy to use. It auto detect and install the devices for you giving you the change to change the name and area while its still building the manifest of features available for the new found device. I really like it.
But not everything is a garden of roses. Here are the cons:
Only the climate and battery features were detected for these Siterwell TRVs. No Valve detection, Window Open detection, nor Child Lock features were detected. So, make sure to have them already configured in the way you want it with the official app before migrate to HASS Zigbee.
Some Zigbee EndDevices can’t be added through Zigbee repeaters. The HASS Zigbee integration has the option to add new devices throught a Repeater. It worked for one Aquara Door sensor, but it couldn’t find my Mijia door sensors. I don’t know the reason. They were working through this repeater with Zigbee2Mqtt.
Here are the pros:
Seems more stable than Zigbee2Mqtt. Although it only pass a week.
The process and UI to join new devices is just great.
You can control your Zigbee network from HASS directly. No need to use Zigbee2MqttAssistant or create a special Lovelace panel with controls to send mqtt instructions for Zigbee2Mqtt.
Hi Daniel,
Thanks for this feedback.
I’m also thinking about migrating from zigbee2mqtt integration to HA zigbee after many stability issues, but I want to make sure that the zigbee integration is stable before starting a migration of my lovelace entities and automations.
Have you made any changes to your CC2531? New flash?
It’s pretty big difference.
Isn’t it measured with use of most recent Mosquito addon (5.1.1)? It has real performance problems incl disconnecting devices etc.
Personally I would be very careful choosing built-in integration. especially in its early days. Judging by reports found on forum there are too many reliability and compatibility issues (see shelly or zwave integrations). Sometimes I have feeling alpha versions are being rolled out.
I have no many zigbee devices but a lot of wifi. Both go through mqtt. I never would replace it.
I was not using the MQTT integration of HASS. I have both, HASS and Mosquitto running as independent Docker containers.
I recently had problems with Mosquitto when they decided to deploy the version 2 in the “latest” docker tag. I’m sticking to the version 1.6.x because it works well.
I have several Sonoff light switches overridden with the Tasmota firmware that talks with HASS using MQTT. I had no communication problems with those.