Issue with system_mode and groups on TRV TS0601 _TZE200_rxq4iti9

[jpadie]

hardware: Pi 4B running Bookworm.
Zigbee: SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2

system_mode
setting system_mode to "heat" (or "auto" or "off") via mqtt does not throw an error but does not cause a change of state in the TRV. the state is reported in mqtt correctly but the frontend UI is not updated, the state on the UI is not updated and the device does not change state.
Changing the system_mode via the UI button does work.
nothing looks untoward in the debug logs (in fact no entries relating to the group at all in the logs. log level is set to debug but only info is being logged to console)

groups
adding the TRVs to a group does not work in the UI. no errors are thrown, the device just never gets added (and does not show up in the configuration.yaml either) the cluster seems to be supported.

any thoughts on a workaround please?

[jpadie]

found some logs (I had the wrong journalctl filter).

Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         z2m:mqtt: Received MQTT message on 'rab/zigbee2mqtt/Zone 9/set' with data '{"system_mode":"heat"}'
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         z2m: Publishing 'set' 'system_mode' to 'Zone 9'
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:controller:endpoint: ZCL command 0xa4c138c3c4ad0e2e/1 manuSpecificTuya.dataRequest({"seq":1,"dpValues":[{"dp":2,"datatype":4,"data":[1]}]}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false})
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp:uart: <-- [6350b1a97d312a15b65894a524ab5593499c607f19d06f9874f7cfed8bfc9e3da3ebccdf6be2997e]
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp:uart: <-- DATA (6,3,0): 6350b1a9112a15b65894a524ab5593499c607f19d06f9874f7cfed8bfc9e3da3ebccdf6be2997e
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp:uart: --> ACK  (7)
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp:uart: --> [87009f7e]
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp:uart: <-- ACK (3): 6350b1a9112a15b65894a524ab5593499c607f19d06f9874f7cfed8bfc9e3da3ebccdf6be2997e
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp:ezsp: <== Frame: 129001450000040100ef0101000100002e58b23da1ffff0a098e0200e0020400010104
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp:ezsp: <== 0x45: {"_cls_":"incomingMessageHandler","_id_":69,"_isRequest_":false,"type":0,"apsFrame":{"profileId":260,"sequence":46,"clusterId":61184,"sourceEndpoint":1,"destinationEndpoint":1,"groupId":0,"options":256},"lastHopLqi":88,"lastHopRssi":-78,"sender":41277,"bindingIndex":255,"addressIndex":255,"message":{"type":"Buffer","data":[9,142,2,0,224,2,4,0,1,1]}}
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp: processMessage: {"messageType":0,"apsFrame":{"profileId":260,"sequence":46,"clusterId":61184,"sourceEndpoint":1,"destinationEndpoint":1,"groupId":0,"options":256},"lqi":88,"rssi":-78,"sender":41277,"bindingIndex":255,"addressIndex":255,"message":{"type":"Buffer","data":[9,142,2,0,224,2,4,0,1,1]}}
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:controller: Received payload: clusterID=61184, address=41277, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=88, frame={"header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":142,"commandIdentifier":2},"payload":{"seq":57344,"dpValues":[{"dp":2,"datatype":4,"data":{"type":"Buffer","data":[1]}}]},"command":{"ID":2,"parameters":[{"name":"seq","type":33},{"name":"dpValues","type":1011}],"name":"dataReport"}}
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:controller:endpoint: ZCL command 0xa4c13837fd68d99d/1 manuSpecificTuya.defaultRsp({"cmdId":2,"statusCode":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"transactionSequenceNumber":142,"writeUndiv":false})
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp: sendZclFrameToEndpointInternal 0xa4c13837fd68d99d:41277/1 (0,0,16834), timeout=10000
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         z2m: Received Zigbee message from 'Zone 8', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":4,"dp":2}],"seq":57344}' from endpoint 1 with groupID 0
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp:ezsp: ==> sendUnicast: {"type":0,"indexOrDestination":41277,"apsFrame":{"profileId":260,"sequence":199,"clusterId":61184,"sourceEndpoint":1,"destinationEndpoint":1,"groupId":0,"options":256},"messageTag":200,"message":{"type":"Buffer","data":[16,142,11,2,0]}}
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp:ezsp: ==> {"_cls_":"sendUnicast","_id_":52,"_isRequest_":true,"type":0,"indexOrDestination":41277,"apsFrame":{"profileId":260,"sequence":199,"clusterId":61184,"sourceEndpoint":1,"destinationEndpoint":1,"groupId":0,"options":256},"messageTag":200,"message":{"type":"Buffer","data":[16,142,11,2,0]}}
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp:uart: --> DATA (3,7,0): 1300013400003da1040100ef010100010000c7c805108e0b0200
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp:uart: --> [375121a9602a158ff8904b25455493499d4e276c25cb7705f6c46331fb7e]
Nov 06 11:18:11 OCPi node[729]: [2024-11-06 11:18:11] debug:         zh:ezsp:uart: -?- waiting (4)
Nov 06 

[jpadie]

In fact, it seems to be all commands whether from mqtt or from the UI seem not to work with any of the TRVs attached to the system at the moment.
other devices do work.

the TRVs are about 1m away from the zigbee dongle (functional devices are within a 20m radius).

[spattinson]

I just bough a few of these. I had the older type and thought i bought the same.
Other issues are the setpoint changing to 153.6C This may be happening when mode is changed

The reported temperature has no decimal places. The setpoint seems the same although you can set tenths of a degree in ui it seems to get rounded and home assistant only allows full degree steps. Oddly the default temperatures in the daily schedules all have one decimal place by default. .0 but changing them to say 21.3 does not throw an error

I think with these mode "heat" ignores schedules, "auto" follows them.

Ill do some digging when i have some time. Any advice welcome

[jpadie]

I’ve had to take all ten out of my system, annoyingly. The mode and temperature set-point control is highly inconsistent with only about 5% of changes “getting through” and even then seemingly not be actioned in the hardware. I am back in the same locale next week and plan to take one to bits and attach a sniffer to see what might be going on. But likely will need to go to another solution as this needs to be robust.

…

On 13 Nov 2024, at 16:18, spattinson ***@***.***> wrote: I just bough a few of these. I had the older type and thought i bought the same. Other issues are the setpoint changing to 156 or thereabouts from memory. This may be happening when mode is changed The reported temperature has no decimal places. The setpoint seems the same although you can set tenths of a degree in ui it seems to get rounded and home assistant only allows full degree steps. Oddly the default temperatures in the daily schedules all have one decimal place by default. .0 but changing them to say 21.3 does not throw an error I think with these mode "heat" ignores schedules, "auto" follows them. Ill do some digging when i have some time. Any advice welcome — Reply to this email directly, view it on GitHub <#24659 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF7AJAIPH7G643C65D66N7T2AN3VXAVCNFSM6AAAAABRISHRA6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRUGI3DCMQ>. You are receiving this because you authored the thread.

[spattinson]

I have switched mine to use "heat" only rather than "auto" auto means schedules on device, heat does not.. they seem to work ok like that. A major deficiency is that heat, setpoint and calibration steps are only in full degrees C. This is confirmed by the various marketing pictures in the Tuya app never showing any more precision that full degrees. It is odd that the default schedules all have degree with a trailing .0 when in fact decimals are ignored or possibly trigger the setpoint going to 156C

[jpadie]

I have just got back to the site with the ten trvs and tested one physically. Comms from the device to z2m works more or less ok. Eg I can see the setpoint change with the dial but I cannot always see the mode change with the button. Comms the other way does not work. The physical device appears not to receive or act on any input from Z2M

Looks like the same behaviour on all others.

The ZigBee dongle is far away from any WiFi source and within 100cm of the trvs for testing.

Is there a resource anyone can point me to that can help me decipher the logs to see whether there is more info there?

[antst]

I also struggle with grouping TRVs.
I am trying to group 4 Danfoss TRVs.
I can create group. devices also added to config file.
But

1. it is not exposed to HA
2. I can't control devices via group topic. Nothing happens when I am trying to change setpoint. But also no complains in the logs. Just silently nothing happens. I presume, for non-light devices, groups implementation isn't ready/tested.

[ayasystems]

Muy setpoint is crazy also

[antst]

@Koenkk
If there any chance we can control group of TRVs like a TRV from HA?

EDIT: Don't mind, I check the code for the groups extension. Currently it is highly specific to the light. It needs some serious rework, to support more than that.

[jpadie]

I am doing exactly that with node red and a plugin matter bridge that I wrote (enables bridging to Alexa, Google home etc etc.)On 10 Jan 2025 13:19, Anton Starikov ***@***.***> wrote: @Koenkk If there any chance we can control group of TRVs like a TRV from HA? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>