search

zigpy / zha-device-handlers

ZHA device handlers bridge the functionality gap created when manufacturers deviate from the ZCL specification, handling deviations and exceptions by parsing custom messages to and from Zigbee devices.
Apache License 2.0
731 stars 673 forks source link

[Device Support Request] TS0601 _TZE200_fhn3negr (Termostat Knob) #938

Closed JoostvdB94 closed 2 years ago

JoostvdB94 commented 3 years ago

Is your feature request related to a problem? Please describe. Bought a thermostat knob in China. It does pair, but does not expose any controls or status.

Describe the solution you'd like I would like to be able to control the target temperature, and read current temperature and battery level

Device signature - this can be acquired by removing the device from ZHA and pairing it again from the add devices screen. Be sure to add the entire content of the log panel after pairing the device to a code block below this line.

{
  "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, *allocate_address=True, *complex_descriptor_available=False, *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, *is_valid=True, *logical_type=<LogicalType.EndDevice: 2>, *user_descriptor_available=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0051",
      "in_clusters": [
        "0x0000",
        "0x0004",
        "0x0005",
        "0x000a",
        "0xef00"
      ],
      "out_clusters": [
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TZE200_fhn3negr",
  "model": "TS0601",
  "class": "zigpy.device.Device"
}

Additional context Product: https://a.aliexpress.com/_BPiRx7 More information is also provided in another Github issue on another project. https://github.com/Koenkk/zigbee-herdsman-converters/issues/1803

Note: I'm using ZHA via a Tasmotized Sonoff ZBBridge

MattWestb commented 3 years ago

Its looks like Z2M under the nale "Alt Moes TRV" have doing all the work for getting the all the functions in place but have not getting one PR for adding it in the Z2M. de(F)CONZ have not trying getting it in the system but is one version of Moes TRV but i think its its not 100% compatible with the "normal" ones.

You can trying adding the model ID in the valve.pv and testing if its working good enough. Look on the last added Moes TRV https://github.com/zigpy/zha-device-handlers/pull/931/commits/20a8ed34ed03814000ae9f561e1ed2a00bd8cf5a and making it look like:

        MODELS_INFO: [
            ("_TZE200_ckud7u2l", "TS0601"),
            ("_TZE200_ywdxldoj", "TS0601"),
            ("_TZE200_cwnjrr72", "TS0601"),
            ("_TZE200_b6wax7g0", "TS0601"),
            ("_TZE200_fhn3negr", "TS0601"),
        ],

And putting you patched valv.py in your local quirk folder, restarting HA and testing if / how its working. If you need help to ding it say and i is helping you.

For more advanced function to work in HA its need some extra patching for the GUI part for Moes TRV but the basic shall working if its similar to the "normal" ones.

JoostvdB94 commented 3 years ago

@MattWestb Thanks for pointing me to this commit and suggesting the change. I've put the extra lines into /config/deps/python3.8/site-packages/zhaquirks/tuya and removed the __pycache__ folder (also in the parent directory /config/deps/python3.8/site-packages/zhaquirks)

(using https://github.com/zigpy/zha-device-handlers#testing-quirks-in-development-in-docker-based-install to point me to the location where valve.py was, and which told me to clean the pycache)

I then restarted the homeassistant container, removed the zigbee device using ZHA and re-paired it. Unfortunately it seems that nothing has changed. Is there anything I may have missed?

MattWestb commented 3 years ago

Is the quirk loaded ?

You can see that on the device card in the info the last line or the signature if you have on line like this but with Moes name Quirk: zhaquirks.tuya.valve.SiterwellGS361_Type1.

Also you shall getting more cluster on the device if its have loading OK.

JoostvdB94 commented 3 years ago

Hmm, looks like the quirk is not loaded. See the following screenshot Screenshot_20210624-170856~2

Do you have any advice on how to ensure nu local changes to the valve.py are reloaded?

MattWestb commented 3 years ago

Then somthing is not matching your device. Look is all is the same under:

    signature = {
        #  endpoint=1 profile=260 device_type=81 device_version=0 input_clusters=[0, 4, 5, 61184]
        #  output_clusters=[10, 25]>
        MODELS_INFO: [
            ("_TZE200_ckud7u2l", "TS0601"),
            ("_TZE200_ywdxldoj", "TS0601"),
            ("_TZE200_cwnjrr72", "TS0601"),
            ("_TZE200_b6wax7g0", "TS0601"),
            ("_TZE200_fhn3negr", "TS0601"),
        ],
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    TuyaManufClusterAttributes.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            }
        },
    }

If endpoints, clusters and profiles is not the same its not being triggered / loaded (you can see it in the HA log if having debug).

You normally dont need repairing the device only restarting HA or getting it trying loading the updated quirk.

MattWestb commented 3 years ago

Its looks like the time cluster[Time.cluster_id] (0x000a / 10) have moved from out to in cluster.

JoostvdB94 commented 3 years ago

After placing Time.cluster_id in the in-cluster and removing it from out cluster it indeed gets recognized and the quirk is mentioned.

When i noticed that this wasn't working, I also placed the Time.cluster_id from the in-cluster to the out-cluster in the replacement part

valve.py now looks like this: image image

Unfortunately, it gives some 'unknown' readings, and controls are unresponsive: image

JoostvdB94 commented 3 years ago

I also noticed that the HY368 usually also has a second cluster address? The snippet that was send is followed by """MoesHY368 Thermostatic radiator valve (2nd cluster signature).""" I do not see another device in my network overview, but may that be of any importance?

MattWestb commented 3 years ago

Then i think its too much that is not working for using it with the "normal Moes" quirk. Need some that can writing one new quirk for it so it can using all the right data points the device is using.

Most tuya TRVs is coming in 2 different versions that is having different Zigbee modules that is having different signature but the same tuya MCU that is doing the "work" and its only having one serial port to the zigbee module = type 1 and 2 for most of them. More info https://github.com/zigpy/zigpy/discussions/653#discussioncomment-314395.

JoostvdB94 commented 3 years ago

I now re-paired the device and collected the logs. It may be useful when creating a new quirk then:

Logger: zigpy.zcl
Source: /usr/local/lib/python3.8/site-packages/zigpy/zcl/__init__.py:91
First occurred: 7:38:57 PM (1 occurrences)
Last logged: 7:38:57 PM

Unknown cluster 61184

and

Logger: homeassistant.components.zha.core.channels.base
Source: components/zha/core/channels/base.py:356
Integration: Zigbee Home Automation (documentation, issues)
First occurred: 7:39:02 PM (2 occurrences)
Last logged: 7:39:02 PM

[0x9A3D:1:0x0006]: 'async_configure' stage failed: 'ConfigureReportingResponseRecord' object is not subscriptable
[0x9A3D:1:0x0001]: 'async_configure' stage failed: 'ConfigureReportingResponseRecord' object is not subscriptable
MattWestb commented 3 years ago

Unknown cluster 61184 = 0xef00 = TuyaManufClusterAttributes.cluster_id so the tuya cluster is not working OK and cant sending / receiving data OK.

JoostvdB94 commented 3 years ago

By the way, was researching another log line: [0x7c3b:1:0x0000] Attribute report received: 65503=��g(��g(��g( I came across another device that looks very similar: https://github.com/zigpy/zha-device-handlers/issues/677 With the same in/out clusters

MattWestb commented 3 years ago

Sorry i was missing that issue :-((

I think the _TZE200_i48qyn9s is the same tuya MCU as _TZE200_fhn3negr if reading Z2M so very likely is working the same way.

I putting on link to the issue from the tuya TRV matrix.

MattWestb commented 3 years ago

Do you have putting up the logging so you can see the tuya attributes ?

logger:
  default: info
  logs:
    zhaquirks: info
    zhaquirks.tuya: debug
JoostvdB94 commented 3 years ago

Sure. I have put the default loglevel on critical so they won't show up in the general log. The logs show the pairing process of the thermostat. (I removed it, and rejoined it again) I've put the log on pastebin here: https://pastebin.com/SG0sD86r

I don't know myself what to look for in the logs.

MattWestb commented 3 years ago

M2 im no code worrier :-(((

The log is not showing all its ended before the device is complete paired / start working normal. Try changing some on the device lite the set point temperature and look if its sending somthing to the coordinator.

JoostvdB94 commented 3 years ago

Ok, the previous pastebin logging was taken without additions to the valve.py, so without a quirk that matched the thermostat. I also made adjustments to the thermostat knob (setting target temperature) but it didn't generate additional logging. (logs are here https://pastebin.com/SG0sD86r)

I've added those additions so that the quirk was loaded again and re-joined the zigbee thermostat. Also, after joining I adjusted the target temperature on the thermostat itself. The logging for rejoin and setting target temperature (increase temperature, decrease temperature, Permanent ON and Permanent OFF), with additions to valve.py can be found here https://pastebin.com/Y7qkicM2

MattWestb commented 3 years ago

Its looks that the TRV is sending attribute nice to the coordinator:

2021-06-24 21:47:11 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Got set time request (command 0x0024)
2021-06-24 21:47:16 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [0, 0, 3, 109] for attribute 0x0276 (command 0x0002)
2021-06-24 21:47:27 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [0, 0, 3, 108] for attribute 0x0276 (command 0x0002)
2021-06-24 21:47:37 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [0, 0, 3, 107] for attribute 0x0276 (command 0x0002)
2021-06-24 21:47:48 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [0, 0, 3, 106] for attribute 0x0276 (command 0x0002)
2021-06-24 21:47:58 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [0, 0, 3, 105] for attribute 0x0276 (command 0x0002)
2021-06-24 21:47:58 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [0, 0, 3, 104] for attribute 0x0276 (command 0x0002)
2021-06-24 21:48:09 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [0, 0, 0, 0] for attribute 0x0210 (command 0x0002)
2021-06-24 21:48:19 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [0, 0, 0, 156] for attribute 0x0218 (command 0x0002)
2021-06-24 21:48:20 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [1] for attribute 0x0402 (command 0x0002)
2021-06-24 21:48:25 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [0] for attribute 0x011e (command 0x0002)
2021-06-24 21:48:35 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [0, 0, 0, 134] for attribute 0x0222 (command 0x0002)
2021-06-24 21:48:46 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [0, 0, 0, 42] for attribute 0x0265 (command 0x0002)
2021-06-24 21:48:56 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [0, 0, 0, 34] for attribute 0x0266 (command 0x0002)
2021-06-24 21:48:56 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [19, 6, 6, 12, 2, 32, 0, 1] for attribute 0x0067 (command 0x0002)
2021-06-24 21:49:02 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [255, 255, 255, 198] for attribute 0x0268 (command 0x0002)
2021-06-24 21:49:12 DEBUG (MainThread) [zhaquirks.tuya] [0xd9a6:1:0xef00] Received value [0, 0, 0, 32] for attribute 0x0269 (command 0x0002)

But im not one tuya hacker so i dont knowing the meaning of them :-(((

I think Z2M have doing much of the matching of the DP but they have not getting it all the way.

jacekk015 commented 2 years ago

This valve is the same as baldisos user. @JoostvdB94 If you want it to work in ZHA please do same steps: https://github.com/zigpy/zha-device-handlers/issues/677#issuecomment-933715002

JoostvdB94 commented 2 years ago

@jacekk015 This certainly helped! I added the moes_3.py to the custom_zha_quirks folder, added the ("_TZE200_fhn3negr", "TS0601"), to the MODELS_INFO section and re-paired the device.

The device now shows

jacekk015 commented 2 years ago

@JoostvdB94 Grab newer DEV version, I've added your model already to MODELS_INFO Thermostat entity should steer now your TRV in Auto and Manual modes. moes_3.py.zip

MattWestb commented 2 years ago

Thanks @jacekk015 you have fixing the preset so it being updated in ZHA then changing it local or the TRV or with cluster commands !!!

I running it on my test Siterwell TRV and its working great :-))

Now its only the switches and reporting of the alarms to ZHA then is one upgrade for the Siterwell TRV quirk getting the missing functions after nearly one year !!

jacekk015 commented 2 years ago

What MODELS_INFO your Siterwell have?? Siterwell have different code in valve.py file.

MattWestb commented 2 years ago

Its already supported (was the first tuya TRV added) but i trying getting all missing functions working and taking away that is not.

  "manufacturer": "_TYST11_kfvq6avy",
  "model": "fvq6avy",
  "class": "valve.SiterwellGS361_Type1"

For getting alarms working i was looking on Aqara magnet but its not one standard device but it looks like "zigbee control bridge" with in put as on/off is making the same "indicator" in ZHA if adding it as your EP3 for vale jammed and window is open alarms / events.

jacekk015 commented 2 years ago

Did you add your manufacturer ID to https://github.com/home-assistant/core/blob/master/homeassistant/components/zha/climate.py#L612 for the Presets to work??

MattWestb commented 2 years ago

Yep and its working great with your version of code in the quirk. Last stand before adding your code https://github.com/zigpy/zha-device-handlers/discussions/1084#discussioncomment-1506933 and i shall updating it then have testing your code little more.

I thinking making one PR for updating climate.py it in HA git shall i do yours in the same ? HA git is needing signing some agreements for accepting PRs and i have doing it so easy doing one PR and getting it accepted but i need timing it with the update of the device quirk for not braking the device.

I was thinking of naming of your devices / quirk, Moes is not the manufacture its only white labeling devices and selling them.

The manufacture is MAXSMART so i think its better naming the type to MAXSMART but if using the moes name in the is not so bad but un logical in my world.

jacekk015 commented 2 years ago

OK, probably we are at the end of the road, or very close. I've added Away data as AnalogOutput fields. There is no support from HASS gui for date and time fields, so every part is in his own field. Fortunately AnalogOutput has Description field so I could add some hint, when you take mouse cursor over entity name, which field is what. That's why I will NOT add support for Schedule settings - imagine: we have 7 days, each has 17 fields for time and temps. We have 7*17 of fields - that's 119 fields/entities !!!! That's madness!

Zrzut ekranu z 2021-10-25 22-05-04

I will finish Window detection and two fields will be added, one for Comfort temp and last for Eco temp. That's probably all.

jacekk015 commented 2 years ago

@JoostvdB94 If we're good with this please close that issue. Thanks!

JoostvdB94 commented 2 years ago

Yes, thank you for the hard work!