[Device Support Request] Immax 07703L TRV

[stnsmk]

Immax 07703L (https://www.immaxneo.cz/produkty/immax-neo-smart-termostaticka-hlavice-zigbee/) is another variation of Tuya TRV, supposedly similar to ETOP HT-10.

Device signature

{
  "node_descriptor": "NodeDescriptor(byte1=2, byte2=64, mac_capability_flags=128, manufacturer_code=0, maximum_buffer_size=82, maximum_incoming_transfer_size=255, server_mask=11264, maximum_outgoing_transfer_size=255, descriptor_capability_field=0)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0000",
      "in_clusters": [
        "0x0000",
        "0x0003"
      ],
      "out_clusters": [
        "0x0003",
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TYST11_wlosfena",
  "model": "losfena",
  "class": "zigpy.device.Device"
}

Additional context I've had some limited success while trying to implement support deriving from generic Tuya and SiterwellGS361 (tuya/valve.py) but it was very basic due to my limited experience with zigpy/zhaquirks.

[stnsmk]

In an unexpected twist another TRV, visually identical and with identical packaging, purchased from the same retailer just one day later than the previous has different signature:

{
  "node_descriptor": "NodeDescriptor(byte1=2, byte2=64, mac_capability_flags=128, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=0)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0051",
      "in_clusters": [
        "0x0000",
        "0x0004",
        "0x0005",
        "0xef00"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TZE200_wlosfena",
  "model": "TS0601",
  "class": "zigpy.device.Device"
}

This one seems to work fine using "Quirk: zhaquirks.tuya.valve.MoesHY368" except the power readings.

I'll try to clarify the situation with the manufacturer and test both devices a bit more using existing code.

[stnsmk]

After some research it looks like the the first device requires responding to a time request in a way described in this z2m patch: https://github.com/Koenkk/zigbee-herdsman/commit/71c89ce6cae2ce26b3d50ade7281de9d05f3fcc8.

What would be the right way to implement this? Capturing cluster command 0x0024 seems to fit handle_cluster_request, however I'm unsure about the actual reply process.

[Adminiuga]

as long as the quirk has the "time" cluster in the "replacement", the default time cluster does respond to incoming request https://github.com/zigpy/zigpy/blob/97b01815b0c3dd64c2512a99587a56db9318e9d3/zigpy/zcl/clusters/general.py#L507

[stnsmk]

Unfortunately no, it's command 0x0024 in Tuya cluster so Time cluster does not help:

2021-01-04 18:57:54 DEBUG (MainThread) [zigpy.zcl] [0x7dec:1:0xef00] ZCL request 0x0024: b'\x00\x00'
2021-01-04 18:57:54 DEBUG (MainThread) [zigpy.zcl] [0x7dec:1:0xef00] No handler for cluster command 36
2021-01-04 18:57:56 DEBUG (MainThread) [zigpy.zcl] [0x7dec:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=31 command_id=36>                                                                                                                                                     
2021-01-04 18:57:56 WARNING (MainThread) [zigpy.zcl] [0x7dec:1:0xef00] Unknown cluster-specific command 36

However you pointed me in the right direction, I got it working using the implementation similar to Time cluster. Will prepare a PR after some more tests and code cleanup.

Thanks for your help!

[Adminiuga]

Why Tuya?! Why you had to re-invent the wheel? Rhetorical question...

[MattWestb]

@stnsmk The tuya controlling chip is the same (type/manufacturer config) but they have changing the zigbee module. Very likely its only putting the 2 manufacturer names in the quirk and is working if tuya not have making one 5 wheel in there zigbee devices.

[stnsmk]

I guess there is some extra mess added on the manufacturer side as the second device ("_TZE200_wlosfena", "TS0601") indeed worked fine with existing quirk while the first one ("_TYST11_wlosfena", "losfena") mostly refused to cooperate until it got a response to time request. There are some reports of the same behavior out there on the internet by other folks as well.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[MattWestb]

@stnsmk One question is your both TRVs working like it was in January or is the problem with the time fixes with the updated Moes quirk that is added in 27 February then you is putting in your ID in the quirk ? https://github.com/zigpy/zha-device-handlers/pull/726

[stnsmk]

I did not test these devices with it. Unfortunately at that time I did not have second ZHA compatible dongle to use in dev environment and experimenting on a live prod was too inconvenient. So I ended up with two zigbee networks - ZHA as primary and zigbee2mqtt for the less supported devices. Both TRV models work perfectly in z2m and I did not bother testing it further even after I got proper dev setup.

[MattWestb]

I was forgetting your TRV and was looking around and at the same time you was having the time problems many users was having it with Moes devices but after the update in end of February the Moes dont have the problems and i knowing the dev was fixing time and default response in the new implementation so it responding fast then doing changes.

If you have time some time i can helping you doing the changes so you can testing but its start being cold outside so not distorting your working setup :-))

[stnsmk]

Thanks for checking in, I think I'll be able to test it closer to the end of the week.

[MattWestb]

Its looks its start moving with fixing support for this TRVs. Cloud Event is up and running after first try but testing and work is needed for getting all working OK. If like testing look in https://github.com/zigpy/zha-device-handlers/issues/2072 and adding your device MODELS_INFO for getting the quirk loading by the system.