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
719 stars 664 forks source link

[Device Support Request] TS0601 _TZE200_a4bpgplm tuya trv #1159

Closed joaoasilva closed 10 months ago

joaoasilva commented 2 years ago

Is your feature request related to a problem? Please describe. Bought this thermostat from AliExpress looking at this https://zigbee.blakadder.com/Haozee_TRV601.html that says it works with ZHA but it doesn't. It's possible to get the temperature and set but most of the stuff doesn't work.

Describe the solution you'd like For it to work ex: window status, schedule, turn on/off.

Someone already converted it successfully to work on HA but I don't understand how can I port that to ZHA here: https://github.com/Koenkk/zigbee-herdsman-converters/blob/245fc8273e3afac8d71ec196d0e3ae71e413cba9/lib/tuya.js#L426

Please help. Thanks

MattWestb commented 2 years ago

Looks like Ritek have made one DP 150 for software version https://github.com/Koenkk/zigbee-herdsman-converters/issues/3190#issue-1030558948 Is it possible reding from the quirks ?

Also its some reason they have making it ;-))

Edit: its look being the version of the Zigbee module then the Z2M user is having 1.09 and @joaoasilva s device is having 1.0.8 in tuya app.

joaoasilva commented 2 years ago

What version of the file should I try? Or should I just use the latest you sent to me? @jacekk015 ?

joaoasilva commented 2 years ago

This is the log: Removed the device, restarted and paired again: 0x3b1 HA.log This is the file I'm using with the climate that @MattWestb sent ts0601_trv_rtitek.py.log

Child lock works Valve state works Set a temperature works Current temperature works Battery works Max and Min when I try to set it goes back to the initial value in Lovelace Boost doesn't work, this device only seems to have schedule, on, off and manual Screenshot 2021-12-03 at 10 01 55 From this modes, only schedule and boost is accepted, the others gives an error. It's in the logs. But Boost doesn't do anything. Screenshot 2021-12-03 at 10 04 12 This is what I see in Lovelace

If you need anything else, please let me know @jacekk015

Thanks for all your hard work, much appreciated 🤗

Edit: I have tried all the options from lovelace, they're in the logs

MattWestb commented 2 years ago

@joaoasilva the preset its one for testing and its having more entries then the device is having and its being fixed then we is knowing all function is working OK and what shall being in it or not.

Looks very nice only need little fine tuning and all is in place !!

jacekk015 commented 2 years ago

@joaoasilva Boost should work. I've mapped it to Boost preset. When you enable Boost a countdown, field where you see 2 minutes, should go down to zero.

joaoasilva commented 2 years ago

@joaoasilva Boost should work. I've mapped it to Boost preset.

It doesn't give an error but doesn't do anything, if the valve is closed it remains closed. In the tuya app there's no boost but only on/off. When I press ON it opens fully to 100%, when I press OFF it closed fully to 0%

joaoasilva commented 2 years ago

Screenshot 2021-12-03 at 10 14 04 I've set boost when I created https://github.com/zigpy/zha-device-handlers/issues/1159#issuecomment-985387654 and more than 10 minutes have passed and still in 2 minutes Also valve it's not open, remains closed and not heating

jacekk015 commented 2 years ago

@joaoasilva You can play with it. Enable/disable boost and search in the logs if attribute 0x0104 is changing from [0] to [1] and back. That was copied from Z2M as a working function.

2021-12-03 09:49:35 DEBUG (MainThread) [zigpy.zcl] [0x3b1f:1:0xef00] ZCL request 0x0002: [Command(status=0, tsn=197, command_id=260, function=0, data=[1, 0])]
2021-12-03 09:49:35 DEBUG (MainThread) [zhaquirks.tuya] [0x3b1f:1:0xef00] Received value [0] for attribute 0x0104 (command 0x0002)
joaoasilva commented 2 years ago

I see it changing in the logs but doesn't do anything unfortunately. Not sure it it helps but changing to ON in tuya developer, the POST payload is as follow: {"commands":[{"code":"mode","value":"on"},{"code":"temp_set","value":170},{"code":"switch_rapid","value":true},{"code":"countdown_rapid","value":10},{"code":"window_check","value":true},{"code":"child_lock","value":false},{"code":"lower_temp","value":80},{"code":"upper_temp","value":300}]}

MattWestb commented 2 years ago

@joaoasilva can you please posting logs then you changing the boost time and on/off from ZHA GUI so @jacekk015 can taking one look in it (sadly hi cant do all things completely blind) an finding if somthing is not working OK. Also if its possible making the same changes local on the TRV so hi can see how ZHA is getting the information or not.

joaoasilva commented 2 years ago

@MattWestb it's in there https://github.com/zigpy/zha-device-handlers/issues/1159#issuecomment-985387654

jamjam9 commented 2 years ago

Cluster attributes of my device

image image image no value for date code.

Device still not working.Video attached of device display after binding to zha. On an unbound device the range is typical 5-25 .

Also trying to set with node red again and doesn't seem to take

2021-12-03 18:47:16 DEBUG (MainThread) [zhaquirks.tuya] [0x3ac5:1:0x0201] Mapping standard occupied_heating_setpoint (0x0012) with value 1500 to custom {514: 15.0} 2021-12-03 18:47:16 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x3AC5:1:0x0201]: wrote {'occupied_heating_setpoint': 1500} attrs, Status: [[WriteAttributesStatusRecord(status=<Status.SUCCESS: 0>)]] 2021-12-03 18:47:16 DEBUG (MainThread) [zigpy.zcl] [0x3ac5:1:0xef00] ZCL deserialize: <ZCLHeader frame_control= manufacturer=4098 tsn=255 command_id=Command.Default_Response> 2021-12-03 18:47:16 DEBUG (MainThread) [zigpy.zcl] [0x3ac5:1:0xef00] ZCL request 0x000b: [0, <Status.SUCCESS: 0>] 2021-12-03 18:47:16 DEBUG (MainThread) [zigpy.zcl] [0x3ac5:1:0xef00] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=100 command_id=2> 2021-12-03 18:47:16 DEBUG (MainThread) [zigpy.zcl] [0x3ac5:1:0xef00] ZCL request 0x0002: [Command(status=0, tsn=65, command_id=514, function=0, data=[4, 0, 0, 0, 25])] 2021-12-03 18:47:16 DEBUG (MainThread) [zhaquirks.tuya] [0x3ac5:1:0xef00] Received value [0, 0, 0, 25] for attribute 0x0202 (command 0x0002) 2021-12-03 18:47:16 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x3AC5:1:0x0201]: Attribute report 'RtiThermostat'[occupied_heating_setpoint] = 2500 2021-12-03 18:47:16 DEBUG (MainThread) [homeassistant.components.zha.entity] climate.radstat2_thermostat: Attribute 'occupied_heating_setpoint' = 2500 update 2021-12-03 18:47:22 DEBUG (MainThread) [zigpy.zcl] [0x3ac5:1:0xef00] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=101 command_id=1> 2021-12-03 18:47:22 DEBUG (MainThread) [zigpy.zcl] [0x3ac5:1:0xef00] ZCL request 0x0001: [Command(status=0, tsn=66, command_id=515, function=0, data=[4, 0, 0, 1, 26])] 2021-12-03 18:47:22 DEBUG (MainThread) [zhaquirks.tuya] [0x3ac5:1:0xef00] Received value [0, 0, 1, 26] for attribute 0x0203 (command 0x0001) 2021-12-03 18:47:22 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x3AC5:1:0x0201]: Attribute report 'RtiThermostat'[local_temp] = 2820 2021-12-03 18:47:22 DEBUG (MainThread) [homeassistant.components.zha.entity] climate.radstat2_thermostat: Attribute 'local_temp' = 2820 update

No errors on the node red injection, but no change to the device

Many thanks for trying

https://user-images.githubusercontent.com/69874141/144657244-a7677dd3-ac25-4ff8-b0f2-98d25bb61093.mp4

image

laurius commented 2 years ago

image image image

Temperature range (min/max) looks the same on mine like in the video, does it maybe have something to do with climate.py i don't have one in my installation (Hassos) and if i add it to custom quirks i get errors because of missing files called by climate.py.

MattWestb commented 2 years ago

The min and max is only setting is in the direction making the min and max in the ZHA GUI. Then the device is also supporting it (my Siter is not) it shall doing the same if sending it to the device and also if set in the device it shall updating ZHA GUI.

Try changing the max in the quirk and reading it from cluster attribute and see if the shanging on the device then trying setting the temperature. Also try setting it higher with cluster attribute command can being interesting.

And thanks for the attribute readings hope getting some for the 602 version 2.

laurius commented 2 years ago

Thanks, i did try to change it in quirk as but didn't find correct places to change on TRV only ZHA GUI/HA entity attribute changed. I will try that again and also take a look at an earlier quirk where min/max was change correctly on TRV but HA entity read value *10. I did change cluster attribute (10°-25° on TRV; 100°-250° in HA): image image

MattWestb commented 2 years ago

You have 2 places with corrections one with *10 and one with / 10 / for min and max. Try changing one of them to 1 or 100. I think its the last and not the first if the sending to the TRV but im not codewarrior.

Then you was setting 25000 on the max attribute was it possible changing the setpoint on the TRV up to 25° ?

MattWestb commented 2 years ago

I was looking in one old quirk so the 10 * / can being changed!!

In the log you can see the the quirk is sending the min 0x020F and max 0x0210 attribute to the TRV. Also what the quirk is sending (saving the attribute) you can see in "Developer Tools" states and under the name of your TRV in the system so you dont need testing the GUI.

jacekk015 commented 2 years ago

Like I wrote earlier I can't serve you all with one file. Thanks to Tuya we have two different acting TRVs with same IDs. There's no technical possibility to know which TRV is connected. At this point a two different quirks need to be created for LED and OLED version

All is mixed up since each of you sent me different LOGS with same ID. Now I'm not even sure which code is written in the file. I need to look at this topic from top to bottom and create two files - one for LED, another for OLED

jamjam9 and joaoasilva has LED version laurius has OLED version

Another BIG problem is that if we assume that both jamjam9 and joaoasilva has same, LED, version then WHY THE HECK they provide different data!!

jamjam9 for 0x0203 room temp is in bytes

2021-12-03 18:47:22 DEBUG (MainThread) [zigpy.zcl] [0x3ac5:1:0xef00] ZCL request 0x0001: [Command(status=0, tsn=66, command_id=515, function=0, data=[4, 0, 0, 1, 26])]
2021-12-03 18:47:22 DEBUG (MainThread) [zhaquirks.tuya] [0x3ac5:1:0xef00] Received value [0, 0, 1, 26] for attribute 0x0203 (command 0x0001)
2021-12-03 18:47:22 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x3AC5:1:0x0201]: Attribute report 'RtiThermostat'[local_temp] = 2820
2021-12-03 18:47:22 DEBUG (MainThread) [homeassistant.components.zha.entity] climate.radstat2_thermostat: Attribute 'local_temp' = 2820 update

joaoasilva for 0x0203 room temp is an INT value !!!

2021-12-03 09:54:06 DEBUG (MainThread) [zigpy.zcl] [0x838e:1:0xef00] ZCL request 0x0001: [Command(status=0, tsn=24, command_id=515, function=0, data=[4, 0, 0, 0, 204])]
2021-12-03 09:54:06 DEBUG (MainThread) [zhaquirks.tuya] [0x838e:1:0xef00] Received value [0, 0, 0, 204] for attribute 0x0203 (command 0x0001)
2021-12-03 09:54:06 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x838E:1:0x0201]: Attribute report 'RtiThermostat'[local_temp] = 2040
2021-12-03 09:54:06 DEBUG (MainThread) [homeassistant.components.zha.entity] climate.living_room_tv_radiator_thermostat: Attribute 'local_temp' = 2040 update

I think jamjam9 has a problem with his TRV since I've already seen his data are changing from INT to BYTE here: https://github.com/zigpy/zha-device-handlers/issues/1159#issuecomment-985043424 If those TRV are the same - how can they provide different data?

joaoasilva commented 2 years ago

I think I did an update on mine from tuya, but I have a tuya gateway to be able to do that. Not sure if it helps?

MattWestb commented 2 years ago

I think all device comments need being tagged with 601 (LED) or 602 (color OLED) (or app_version).

If we can getting 2 working types i was thinking doing one "dummy attribute" the can being written and red by cluster commands and saving 601 or 602 and can being red from the quirk and being used for fixing the min / max and perhaps more things. Or if app_version is different using it for selecting how to treating them from it.

@joaoasilva can your pleas reading the app_verision of your device ? I think its being different then the other 2 reported.

joaoasilva commented 2 years ago

[0x3b1f:1:0x0000] Attribute report received: app_version=72, 65506=31, 65508=0 It's in the logs I've sent earlier :)

jacekk015 commented 2 years ago

@jamjam9 do you have a Tuya gateway do make an update of the firmware of this TRV, like joaoasilva probably did?? Maybe then they will speak with same data, since both of you have LED version. They should behave the same.

jamjam9 commented 2 years ago

no , I may get one though. does it mater what model gateway so long as its tuya certified?

jacekk015 commented 2 years ago

@jamjam9 How many TRVs an which brand do you have? I've downloaded all your people logs - there are thousands of lines. Your logs show that you have many TRVs - am I correct?

Maybe we are looking on the wrong data of wrong TRV. Cannot imagine myself that chineese are so dumb to let clones, same looking, with different hardware., [edit] I see you have Moes, something else more?

jamjam9 commented 2 years ago

I have 1 Moes and 1 601 on the network and 1 standalone. I more in a box and another that's a dud, won't power on properly.

jacekk015 commented 2 years ago

@jamjam9 For now I can only tel after quick analyze that you and joaoasilva have different MCU soft version Yours is 1.0.9 joaoasilva has 1.1.7 So to be sure TRV update would be welcomed.

I'm still analyzing your all commands, there a lot of logs to check. Need some time.

anlu85 commented 2 years ago

Hey Guys! I also pruchased one of the TRV602 thermostats (the one with the OLDE) rebranded as SALCAR. I manages to get in running (more or less...) with the quirk you provided - thank's a lot for it!! For my device the scaling of the min/max/target temperature seens to work... (at least with the latest file, didn't tried the others.)

However, if I can support you on developing the quirk file with anything (configs, logs, tests, ....) please let me know!!

jacekk015 commented 2 years ago

@anlu85 Yes. Reset your TRV to defaults. Enable debug logging - configuration.yaml

logger:
  default: info
  logs:
    homeassistant.components.zha: debug
    zigpy: debug
    zhaquirks: debug

After you put the quirk, restart od HA is needed. Remove and re-pair again this TRV. Wait till 10 minutes - TRV still sends some data after pairing. Put here all big LOG as a text file. Do NOT cut any line.

jacekk015 commented 2 years ago

@jamjam9 Could you do it also like anlu85 Please reset your device to defaults first. After pairing wait those 10 minutes and then put here all logs, I mean all, as a file. I'm started to doubt which values to expect, and after resetting TRV to defaults I will know what values to expect. I wanna compare them in default state, like from factory. Many thanks!

anlu85 commented 2 years ago

Here is the log file (seems to be only one): home-assistant.log

Hope it is the stuff you asked for.

Currently, I have two other Zigbee thermostats configured (_TZE200_c88teujp & an eurotronic). I removed there battery before the restart. I also turned of (hard...) all other zigbee devices (expect of one bulb) - hope that makes it a bit easier to check the logs.

anlu85 commented 2 years ago

Oh, and I removed the device before restarting HA... Hope this is not an issue. If so, let me know and I'll redo it.

anlu85 commented 2 years ago

This is the number section of the device

Setting the Min/Max values seems to work - but the scaling from the device to HA seems to have some issues....

image

jacekk015 commented 2 years ago

All is OK, just need to look at it. You have OLED like laurius. Check after longer time if maybe you have in the logs symbol 0x0296 For now I don't see it in your logs, but those LED version have them.

We have a clones here, that act different and have same ID symbol ;-) So the code don't know how to act. We are searching for differences so I could modify the code according to version LED/OLED

Also from Cluster Manager, on Basic cluster, please check and post here screens of "app_profile_version" values and other attributes.

MattWestb commented 2 years ago

Some of the TRVs have one more attribute that is unknown and cant being red but is reported but looks being different:

2021-12-04 22:23:06 DEBUG (MainThread) [zigpy.zcl] [0xdaea:1:0x0000] Attribute report received: app_version=72, 65506=31, 65508=1

The last (65508 = 0xFFE4) i have seen with 0 and 1 in the logs.

anlu85 commented 2 years ago

Hm, when I try to read out the value of app_profile_version it just hows "None"...

Here are all the readable values of the Basic cluster

app_version (id: 0x0001): 72 hw_version (id: 0x0003): 1 manufacturer (id: 0x0004): _TZE200_a4bpgplm model (id: 0x0005): TS0601 stack_version (id: 0x0002): 0 zcl_version (id: 0x0000): 3

jacekk015 commented 2 years ago

Funny thing: only @anlu85 has for OLED 65508=1

2021-12-04 22:23:06 DEBUG (MainThread) [zigpy.zcl] [0xdaea:1:0x0000] Attribute report received: app_version=72, 65506=31, 65508=1
MattWestb commented 2 years ago

My findings is from his log so its the same line 😄

anlu85 commented 2 years ago

I haven't had the device mounted to an radiator during the factory default and re-pairing. Could it be anything regarding an adaption error? If you like I can try it again while it is mounted.

MattWestb commented 2 years ago

I dont think so then its what the Zigbee module is reporting and the tuya MCU is normally reporting errors with DP commands.

jacekk015 commented 2 years ago

@anlu85 Nope - it's OK

@MattWestb check above logs for 65508 jamjam9 had it also, for a moment 65508=1

2021-11-30 22:00:25 DEBUG (MainThread) [zigpy.zcl] [0xa2a4:1:0x0000] Attribute report received: app_version=72, 65506=31, 65508=1

Now his logs shows 0

2021-12-02 21:12:15 INFO (MainThread) [zigpy.device] [0x1afd] Discovered basic device information for <Device model='TS0601' manuf='_TZE200_a4bpgplm' nwk=0x1AFD ieee=50:32:5f:ff:fe:40:47:2f is_initialized=True>
2021-12-02 21:12:17 DEBUG (MainThread) [zigpy.zcl] [0x1afd:1:0x0000] ZCL request 0x000a: [[Attribute(attrid=1, value=<TypeValue type=uint8_t, value=72>), Attribute(attrid=65506, value=<TypeValue type=uint8_t, value=31>), Attribute(attrid=65508, value=<TypeValue type=uint8_t, value=0>)]]
2021-12-02 21:12:17 DEBUG (MainThread) [zigpy.zcl] [0x1afd:1:0x0000] Attribute report received: app_version=72, 65506=31, 65508=0
MattWestb commented 2 years ago

Can it being that the device is initiated / the MCU is up and running OK thru the tiya MQTT tunneling ? Its still only one status from the Zigbee module is sending and tuya WiFI devices have many status flags in the protocol from the MCU and some can being ported to the Zigbee module.

I think the real MCU firmware version is the only can saying if the devices is identical or not then tuya can having different Zigbee modules with different firmware on them with the same MCU.

jacekk015 commented 2 years ago

OK - I've got all of your 4 data at once at screens. LED and OLED. It start too look to me that they look the same-ish ;-) Probably it was partially me, doing 4 devices coding at one time in other topics, and too many people at once requesting changes here. I've probably lost track of which value is what, because everybody changed all the parameters each time. IMG_8479

That's why I have an ask: @jamjam9 @joaoasilva and @laurius please reset your devices[like @anlu85 did] to default, factory settings, do not change anything and re-pair it last time. The only possibility is to compare those data in factory settings. Please post here ALL logs as a file, from pairing time till 10 minutes after pairing - they are still sending data over time. Otherwise I will lost with it again. Thanks in advance - I think we need 1 hour of coding after all of you sent the LOGs.

anlu85 commented 2 years ago

I had a look on the log files and checked for 0x0296. It didn't appear so far.

jacekk015 commented 2 years ago

@anlu85 @jamjam9 @joaoasilva @laurius Here's the last, I think, version - should work for all of you Repaired all bugs, and added another field which is Software Version. Please test and report back... with LOGs in case of problems. Reminder: After file change HA restart is needed. ts0601_trv_rtitek.py.zip

laurius commented 2 years ago

Here the log with factory default, not with the quirk you posted 10 min ago yet will post this after later. factory reset home-assistant.log pairing log factory reset.txt

laurius commented 2 years ago

Thanks this fixed it, min max scales correctly now and no other scaling issues that i see. Logs: pairing log quirk 05_12_2021.txt quirk 05_12_2021 home-assistant.log

Not sure how the boost is supposed to work so i couldn't test that.

jacekk015 commented 2 years ago

To Boost to work another PR to HA itself is needed. Then your TRV will get Presets list, under Lovelace card, under 3 dots menu. @MattWestb Could make a custom file[like this quirk] for you to manually upload it to your HA. Schedule, Manual, Boost - these are Presets you have enabled.

Now it should mimic something if you click Fire or Off icon on Lovelace card.

laurius commented 2 years ago

@jacekk015 i copied the climate.py file that was posted before so i have the preset boost to select from Lovelace. I have set boost countdown and select boost preset but nothing is happening. Logs of while doing that: quirk 05_12_2021 boost home-assistant.log

jacekk015 commented 2 years ago

@laurius You've cut logs to early. I see boost enabled and BAM. End of the logs. What can I say? You need to wait at least 5-10 minutes so I had data to analyze.

Boost enabled [1]

2021-12-05 13:31:52 DEBUG (MainThread) [zhaquirks.tuya] [0xf4bc:1:0xef00] Received value [1] for attribute 0x0104 (command 0x0002)
laurius commented 2 years ago

@jacekk015 sorry need to be more patient... here the log: quirk 05_12_2021 boost longer waiting home-assistant.log