-
Notifications
You must be signed in to change notification settings - Fork 644
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Device Support Request] Improving "TS0601" "_TZE200_b6wax7g0" TRV thermostatic radiator valve #1123
Comments
I can not answering all your question then i dont have the TRV but some i can. |
Thanks for the answers. There is another problem in the thermostat min-max values, they seem to be off by a factor of 10 (at least the max is 300 when it should be 30 maybe.... for the min I don't know if it should be 7°C or 0.7°C) I'm surprised for the 1°C increment (maybe the translation of the values is not optimal, does the values come from the valve in tenth of a degree ?) I also found this page from zigbee2mqtt : BRT-100-TRV |
The min and max setpoint you is setting and reading on the thermostat cluster (0x0201) with attribute 0x0015 and 0x0016. For see what the TRV is sending and ZHA is sending to it you shall configuring in HA:
The set the min and max on the cluster and see what is possible setting on the TRV and what ZHA is is putting in for limits in the GUI. With the 1°C is somthing that is made in the TRVs firmware and is out of our control and cant being fixed in our side. I think your 300.0 °C is because you have setting somthing out of range for the TRV and 7.0°C is standard under limit in ZHA if you not have setting it on the cluster. PR for fixing not good working functions is more then welcome !! |
@Youpimatin if you wanna to move this forward please enable debug logging in configuration.yaml
and the resend pairing log |
I think the fix is working OK but the implementation is little not so elegant and can being better made then making more or less one new device instead for one If / else and changing the setpoing in the quirk. |
The problem is[with temperature] that someone is using uint, which is unsigned int type and try to put a float type in it
Besides I would like to see a full proper DEBUG log, to exclude any mistakes and misunderstandings. |
OK, I thought i was in debug mode for the log, but here is a new attempt :
|
OK - that's still wrong. You need to take it from the LOGS, not pairing window. Also, since you have the TRV in your hand, and wanna to support new elements it would be nice if you play with TRV values and try to find out which attribute is for which function you wanna to have.
If you have options that no one other has we cannot know which attribute is responsible for which function. For example: What works for you now are known[I mean attributes]. Any new function you need to give us a hint which attribute use that function on TRV. We will do the rest.
|
OK, here is the data from the log at the time of pairing (I expurged some obvious off-topic lines) I'll play with functions on the valve and check the log when i'm back home. I can see sometimes the temperature is given with 0.5°C resolution :
|
I've filtered all attributes your TRV has presented[if you didn't cut the log too quick]
|
Nice ! thanks.
|
I've used https://onlinetexttools.com/filter-text |
From my log, I can identify attributes : and maybe : unidentified attributes : |
Do you use newest HomeAssistant version?? I see differences in DEBUG LOGS between yours and mine. Since they declare kind of support so I could just easily match those DPs to attributes. My log:
tsn=24 = DP 24 from Z2M which is current room temp, which is attribute 0x0218 |
@jacekk015 You is having debug for zigpy.zcl that is doing more raw commands but still is I was thinking the |
No I'm not using the latest version of HA, I'm using core-2021.6.6
If it helps by providing more data, I can set the last version of HA to debug (but I will definitely downgrade after to the last good version for me.) |
@MattWestb Funny is that this is wrong. In reality tsn returns for debug a DP tsn=24 local temp
From Z2M [part of it]:
Compare DP with tsn above. Funny but that's true. |
Can being that the "tuya converter" is doing that in the conversion but then it good that is not being used for other devices then its being little crazy like this:
Its one old IKEA Dimmer (the round one with gyro) that is doing on checking to its parent. If the tuya decoder is putting the tsn as tuya DPs then i understand way you is liking it very much but is on the border to sheeting !! And then it shall having I shall doing it on the test network with the TRV and looking little more :-))) Is this TRV sending wrong data or is Zpgpy using it wrong and loosing the preposition of the setpoint ? |
OK - I got the calculation for attribute -> DP Maxsmart Window detect: SITERWELL_TARGET_TEMP_ATTR = 0x0202 Easy :-) |
Not importing but i was playing little with away mode temperature up and down and was getting one log:
Attribute 0x202 is the same then changing the temperature but not the tsn is increasing with the transactions the device is sending. Can being that my TRV is using one old Zigbee module (TYST11) that is doing it "normal Zigbee way" and newer is making it tuya way = tsn = DP that i think it not bad and shall working well then sending different DP but if sending the same DP (changing the temp and the TRV is sending multiple different temperatures with same DP) it can being little strange for the Zigbee network stack and the underlying IEEE network that is using tsn logic for acking frames and reseeding them is they is being lost and double transmitting. If its working with TZE200 then its great but dont forgetting its looks not working with devices that having TYST11 Zigbee modules. tuya is still tuya !! |
You have ZCL request 0x0001: |
Identified attributes :
0x0104 # Boost heating (Received value 0:off / 1:in progress) Unidentified attributes : |
0x205 looks have one temperature and one more data, Away with temperature and date or holiday ? |
You need to specify 0x0401 for modes mapping Schedule, Manual... You have two Window functions. Clarification is needed moesSwindowDetectionFunktion_A2: 8,
|
The 0x0409 is the alarm and the 0x0108 is the enable / disabling the windows detection like on the Siterwell is doing. |
User needs to confirm this. Tricky, because manual says something else? |
I edited, 0x0108 is the mode (function A2 in the manual) No effect on zigbee when I change A3 or A4 |
So 0x0409 could be the window alarm, but pastebin logs shows already [1] there |
0x0401 : I'm pretty happy with what I listed already. It's cold outside, let's go for a window opening detection... |
My problem is not the battery percentage, my problem is the valve state from TRV. |
@witjojo That's the firmware on the TRV. Quirk has nothing to do about it. I don't remember such problems, but only user that has that TRV can confirm that. |
Hello, I have a couple of BRT-100 Moes House TRV's I have installed the beca.py which has exposed a number of entitles which is great thank you manually every works works but when I create a scene to set the temp say 24 degrees and another scene to set at 15 degrees, I cant seem to get the TRV to change the temp setting... any clue as to what I have done wrong or missed |
Ok Scratch the above please - sorry I can just run with an automation and not a scene, that works fine |
What does it mean: doesn't work? |
nvm, disregard my last comment |
Hello everyone, I have recently received the following error message: 2023-07-18 03:14:03.746 ERROR (MainThread) [zhaquirks] Unexpected exception importing custom quirk 'ts0601_trv_beca' Can someone help? |
@witjojo It was fixed already at: |
Hi @jacekk015, as I try to turn on or off any switch in the device I got this error, even if the command is correctly processed on the TRV: ` [547470550976] Failed to turn on: [WriteAttributesStatusRecord(status=<Status.SUCCESS: 0>)] For example, if I turn on child lock switch, I get this error, but the child lock is correctly turned on. Can you please help with this? |
@matlar83 OK - I know where the bug is. Today evening I will correct that. |
Thank you very much! Very appreciated! |
@matlar83 Quirk updated. Replace and restart HA to use new version. |
Seems to work great! thank you |
how I see this error in HomeAssistant logs:
Do you have any idea? |
@jacekk015 hey, I have a similar trace, but the original error message is different:
BetterThermostat tries to change the offset, but apparently can't |
Again - that TRV doesn't have OFF mode. So how you want to turn it OFF???
From Z2M code
Check the paper manual. Is there any info about OFF mode??? |
Hi, I also tested BetterThermostat with this TRV "TS0601" "_TZE200_b6wax7g0". And I also select without OFF mode. I think the problem is not BetterThermostat but the TRV's. Maybe jacekk015 can test BetherThermostat. |
Debug logs please. It's all there. |
Here are the debug logs right after trying to enable the device in BetterThermostat using the offset mode:
The offset mode support for this TRV (all TRV with this attribute name) was added here KartoffelToby/better_thermostat#1047 |
You didn't post log file but only part of the logs. Some my answer is only partially for what I see.
BetterThermostat wanna to set SystemMode to Heat for device that can Heat only. If you check TRV attributes you will see that there's no OFF possibility for that TRV So if BetterThermostat has an option to omit OFF mode it should also omit ON[Heat] mode also. [edit] |
Quirk has been updated. |
Thank you, I'll pass that info to BetterThermostat devs |
Is "Better Thermostat" now working with this TRV's? |
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. |
Hello,
(I didn't know where I should post, so feel free to merge with the relevant subject if there is one in particular, maybe in the discussions, I don't know.)
I bought a dozen of these TRV (on Amazon.fr, Qiumi brand) to install in my house : https://zigbee.blakadder.com/Beca_BRT-100.html
I chose them because I looked at the blackladder page and saw it was supported in ZHA (and Zigbee2MQTT)
In reality it's not the case for all parameters (battery, child lock, window detection)
I used custom_zha_quirk ts0601_trv.py (dated 2021-09-22) "ts0601_trv.MoesHY368_Type1new"
There are 3 entities :
I didn't want to install Tuya app on my phone to check if these others parameters are supported, but if the user manual is correct, on the image shown, you can see :
On the valve, you can also see if it's open or closed (just a LED, it's binary),
in reality I counted a minimum of 5 positions of the motor (maybe 0%, 25%, 50%, 75%, 100%),
this would be really cool if the position was published ! (even more if we could force a position)
Other settings exists in the documentation, you can change or check them in the valve menus :
Pairing log :
Device signature :
I don't kow zigbee, and don't know how I can help, but here is the information I can get.
I can test anything to get more information, or modified quirks ...
I don't mind if it breaks temporarily my house heating (I have only two of these valves installed for now)
The text was updated successfully, but these errors were encountered: