_TZE200_uiyqstza does not work

[Kampfgnom]

Hi! 👋

Since last year I've got two _TZE200_i48qyn9s and they're working fine. I thought I'd buy more of those, but the new ones that arrived today are _TZE200_uiyqstza and they don't work with the same quirk.

I admit that I didn't yet have the time to try to fix the problem myself, but I think at least I got you the logs of when I pair the device.

_TZE200_uiyqstza.txt

I think this is similar to https://github.com/jacekk015/zha_quirks/issues/11

Thanks for everything and I'll try to help with this as good as I can.

[jacekk015]

Did you downloaded and used latest version of quirk??

ts0601_trv_maxsmart.py

[Kampfgnom]

Thanks for the swift reply 👍

I am very certain that I have the latest version of the quirk, yes. Is there anything in the logs that makes you think otherwise?

(maybe some background on me: I'm currently a Backend Engineering Architect at a big-ish IoT company with >15 year of experience in my field. Python is not my first language, but I've seen my share. Just so you know that I'll probably not bore you with beginner-mistakes like copying Github HTML 😅 and that you can ask difficult things if required).

[Kampfgnom]

I began looking into it a bit. Remember that I have no idea what I'm doing, sorry. Maybe I'm just wasting time 🤷

The endpoint information of my device does indeed not match the Maxsmart definition: endpoint=1, profile=260, device_type=81, device_version=1, input_clusters=[4, 5, 61184, 0], output_clusters=[25, 10].

It looks very similar to the Saswell quirk, so I just went ahead and added _TZE200_uiyqstza to the saswell MODEL_INFO.

That doesn't work either though. Trying more stuff.

[MattWestb]

The device signature is from the Zigbee module only the manufacture and model its getting from the MCU and so if the manufacture is changing the Zigbee module but have the same firmware in the MCU must one new device class being made and for matching the signature but the rest shall being the same. It was the same with first gen devices was having different Zigbee modules but the same MCU.

[jacekk015]

@Kampfgnom Re-download newest ts0601_trv_maxsmart.py quirk from my repo. Maybe it will not work properly, but it should start to talk now with HA by Zigbee. Restart HA after quirk replace. Remove _TZE200_uiyqstza TRV and pair like a new. Wait 10 minutes minimum and post logs again.

[Kampfgnom]

I fixed the one obvious thing: DEVICE_TYPE: zha.DeviceType.SMART_PLUG.

The device now pairs, but does not finish and is not yet usable. Here are logs:

_TZE200_uiyqstza-20221026.txt

[jacekk015]

It keeps asking for time request. Probably special initialization is needed. Try updated quirk.

[Kampfgnom]

That's a step forward, thanks!

The device is now configured and it reads the initial values, partially at least.

It doesn't receive updated values and it cannot set values though.

_TZE200_uiyqstza-20221026T1350.txt

[jacekk015]

Re-download and try. Still got set_time with errors from TRV. I've made an exception for that TRV which normally worked - but I've never had problems with set_time command. Try, post the logs, and drop a screenshot from device if possible. On Win10 you can do shortcut Shift + Win + S - mark the area and click on Github post window and do Ctrl+v [paste]. I will paste and upload automagically.

[Kampfgnom]

Now the configuration itself does not finish and the device does not have entities at first.

After a HA restart it has entities. Some entities show correct values (e.g. 17°C), other's don't. The thermostat instance does not work. Setting values does not work.

I collected logs when I added the device and also for after the restart:

_TZE200_uiyqstza-20231030T1738.txt

_TZE200_uiyqstza-20231030T1738_after_restart.txt

Here's an iOS screenshot, after the restart, because it includes the values (why aren't they shown in the browser?):

.txt)

I finally have some time to look into it myself. I'll play around a bit. If you have any pointers as to what to try, maybe we can reduce the feedback cycle times because I manage to get something done on my own?

Thanks for everything so far 👍

[jacekk015]

After replacing quirk file you ALWAYS need to do restart. And then re-pair. New quirk code is ONLY loaded at the HA start/restart. Doing anything without restart is useless.

[Kampfgnom]

Sorry! That's what happens when you mess around with this stuff while your toddler is also trying to get your attention. I had installed a version where I changed some things myself.

Now I'm running your https://github.com/jacekk015/zha_quirks/commit/3931d162043991acef484f623e5f8db876c850a8 and most things already work 👍

Pairing:

_TZE200_uiyqstza-20231031T1530_pairing.txt

Setting temperature from HA UI, does not work:

_TZE200_uiyqstza-20231031T1530_set_temperature.txt

Changing the temperature on the TRV, reports back to HA successfully:

_TZE200_uiyqstza-20231031T1530_trv_change_temperature.txt

iOS UI:

[Kampfgnom]

I begin to understand some things. Setting is_manufacturer_specific=False makes setting the temperature work 🙂

        0x0000: foundation.ZCLCommandDef(
            "set_data",
            {"param": TuyaManufCluster.Command},
            False,
            is_manufacturer_specific=False,
        ),

I played around with the TRV a bit and now everything seems to work as expected. I will test-drive it for a while and report back whether now everything is working.

---

Do you accept donations somehow? Or would you like to suggest an organization or individual you would like me to donate to in your place? :)

[jacekk015]

begin to understand some things. Setting is_manufacturer_specific=False makes setting the temperature work 🙂

Yes and no. Chinese friends probably don't like standards. On pairing your device presented manufacturer ID=4417

Oct 31 14:23:26 homeassistant homeassistant[576]: 2023-10-31 15:23:26.930 INFO (MainThread) [zigpy.device] [0x37dd] Got Node Descriptor: NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4417, maximum_buffer_size=66, maximum_incoming_transfer_size=66, server_mask=10752, maximum_outgoing_transfer_size=66, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)

So ZHA/HA remember's that and on every next command send back to TRV uses that manufacturer ID. Why not? That what normally is_manufacturer_specific=True does - it's a standard. But if that works that way then some TRV's, for different commands, barks back with: UNSUP_MANUF_CLUSTER_COMMAND

Oct 31 14:25:32 homeassistant homeassistant[576]: 2023-10-31 15:25:32.632 DEBUG (MainThread) [zhaquirks.tuya] [0x37dd:1:0x0201] Mapping standard occupied_heating_setpoint (0x0012) with value 2000 to custom {617: 40}
Oct 31 14:25:32 homeassistant homeassistant[576]: 2023-10-31 15:25:32.633 DEBUG (MainThread) [zigpy.zcl] [0x37DD:1:0xef00] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=True, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False), manufacturer=4417, tsn=76, command_id=0, *direction=<Direction.Server_to_Client: 0>)
Oct 31 14:25:32 homeassistant homeassistant[576]: 2023-10-31 15:25:32.634 DEBUG (MainThread) [zigpy.zcl] [0x37DD:1:0xef00] Sending request: set_data(param=Command(status=0, tsn=76, command_id=617, function=0, data=40))
Oct 31 14:25:32 homeassistant homeassistant[576]: 2023-10-31 15:25:32.814 DEBUG (MainThread) [zigpy.application] Received a packet: ZigbeePacket(src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x37DD), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=1, source_route=None, extended_timeout=False, tsn=0, profile_id=260, cluster_id=61184, data=Serialized[b'\x18L\x0b\x00\x83'], tx_options=<TransmitOptions.NONE: 0>, radius=28, non_member_radius=0, lqi=36, rssi=None)
Oct 31 14:25:32 homeassistant homeassistant[576]: 2023-10-31 15:25:32.815 DEBUG (MainThread) [zigpy.zcl] [0x37DD:1:0xef00] Received ZCL frame: b'\x18L\x0b\x00\x83'
Oct 31 14:25:32 homeassistant homeassistant[576]: 2023-10-31 15:25:32.816 DEBUG (MainThread) [zigpy.zcl] [0x37DD:1:0xef00] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True), tsn=76, command_id=11, *direction=<Direction.Client_to_Server: 1>)
Oct 31 14:25:32 homeassistant homeassistant[576]: 2023-10-31 15:25:32.817 DEBUG (MainThread) [zigpy.zcl] [0x37DD:1:0xef00] Decoded ZCL frame: Silvercrest3ManufCluster:Default_Response(command_id=0, status=<Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>)
Oct 31 14:25:32 homeassistant homeassistant[576]: 2023-10-31 15:25:32.818 DEBUG (MainThread) [zigpy.zcl] [0x37DD:1:0xef00] Received command 0x0B (TSN 76): Default_Response(command_id=0, status=<Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>)

That's because if you send data to TRV, like request to change Temp, you send a manufacturer ID, which that TRV presented to you on the pairing process. But now Chinese firmware in the TRV says nope - I don't like that manufacturer ID. Below you have manufacturer=4417

Oct 31 14:25:32 homeassistant homeassistant[576]: 2023-10-31 15:25:32.633 DEBUG (MainThread) [zigpy.zcl] [0x37DD:1:0xef00] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=True, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False), manufacturer=4417, tsn=76, command_id=0, *direction=<Direction.Server_to_Client: 0>)

That's why we override those commands and do then: is_manufacturer_specific=False Probably the reason is that those are clones of the clones and no one care about that. They're Zigbee gateways probably totally omit anything with manufacturer ID so it just works for them.

[Kampfgnom]

My four _TZE200_uiyqstza have been running nicely since last week.

For future reference, they're called "Wesmartify Essentials Heizkörperthermostat Zigbee (120144)" and I got them from here:

https://www.pollin.de/p/essentials-heizkoerper-thermostat-zigbee-590612

via

https://www.idealo.de/preisvergleich/OffersOfProduct/200684364_-essentials-heizkoerperthermostat-zigbee-120144-wesmartify.html

All the features I need are in place 👍 I'm running https://github.com/KartoffelToby/better_thermostat I have several automations which set the target temperature. It might not be fully feature complete, but my use case is fulfilled.

Thanks again for everything 🙂