So I’ve bought this TRV.
The pairing went succesfully, however I don’t see most of the attributes:
If I should attach some debug logs - what else should I do? Start the logs and re-pair the device?
Here’s what’s supposed to be there (presumably) Moes BRT-100 TRV does not respond to temperature change request - #5 by Rofo
What are the +2 entities not shown?
RSSI and LQI
You might have to re-pair it. It seems as if the interview did not work right between it and your Zigbee controller.
The thing is that 2 out of 3 TRVs have this issue. However I didn’t even attempt to pair the 3rd one…
What are you expecting to see? Edit: just reread your post and see what you are expecting. I endorse suggestion of re-pairing. And/or a new battery.
Assuming you have the quirk installed, when you expand the zigbee info panel do you see it running?
If not, then that could be why you aren’t seeing the entities you are expecting.
Ok… first, grab this file:
https://github.com/zigpy/zha-device-handlers/files/9844752/ts0601_trv_beca.py.zip
Next, setup your HA to use local quirks as follows:
The steps as I understand them:
/config/custom_zha_quirks
zha:
custom_quirks_path: /config/custom_zha_quirks/
If you don’t know how to create folders in your HA install, then I recommend you use a file editor like ‘studio code editor’ which you can search for and download from system → Addons. (You can also use this to edit your configuration.yaml file)
If you find the quirk doesn’t run correctly, or throws errors in your installation, let me know, as I seem to recall I had to edit mine after an HA update broke it recently, and I’m not sure if the link I gave you above, has that fix in it.
UPDATE:
You also have to unzip the file in the link above, and I have checked and that file still has the problem in it. To fix this is very easy
Once you have extracted the .py file from the zip, open it with a text editor and search for this line:
attr_name = self.attributes[record.attrid][0]
It should be in the file twice.
Change those two lines for
attr_name = self.attributes[record.attrid].name
Save the editted .py file and then put this into the folder in step 3
Yeah, I’ve read that but stopped at the “I think I know what I’m doing” stage 
Unexpected exception importing custom quirk 'ts0601_trv_beca'
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/zhaquirks/__init__.py", line 460, in setup
spec.loader.exec_module(module)
File "<frozen importlib._bootstrap_external>", line 940, in exec_module
File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
File "/config/zha_quirks/ts0601_trv_beca.py", line 68, in <module>
class BecaManufCluster(TuyaManufClusterAttributes):
File "/usr/local/lib/python3.11/site-packages/zigpy/zcl/__init__.py", line 165, in __init_subclass__
raise TypeError(f"Duplicate definitions exist for {duplicates}")
TypeError: Duplicate definitions exist for ['boost_duration_seconds']
I see this error (both the original version of the file and the “fixed” version gives this error.
UPDATE:
UPDATE2:
used this file and seems there are no errors in the logs. Will re-pair the devices once I’m back home and report my findings
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/zigpy_znp/zigbee/application.py", line 617, in on_af_message
self.packet_received(
File "/usr/local/lib/python3.11/site-packages/zigpy/application.py", line 1006, in packet_received
self.handle_message(
File "/usr/local/lib/python3.11/site-packages/zigpy/application.py", line 522, in handle_message
return sender.handle_message(
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/zigpy/device.py", line 367, in handle_message
self.endpoints[src_ep].handle_message(
File "/usr/local/lib/python3.11/site-packages/zigpy/endpoint.py", line 235, in handle_message
handler(hdr, args, dst_addressing=dst_addressing)
File "/usr/local/lib/python3.11/site-packages/zigpy/zcl/__init__.py", line 424, in handle_message
self.handle_cluster_request(hdr, args, dst_addressing=dst_addressing)
File "/usr/local/lib/python3.11/site-packages/zhaquirks/tuya/__init__.py", line 494, in handle_cluster_request
zvalue = ztype(tuya_data)
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/zigpy/types/basic.py", line 94, in __new__
raise ValueError(
ValueError: -1 is not an unsigned 32 bit integer
Looks like the file from the repo didn’t help either 
UPDATE:
Looks like this one worked.
Ah yes, Now I remember another fix I had to do!
Glad you got it working in the end 
@Rofo by the way, do you have one of these?
I see that the valve opening is a “read only” value and does not do anything if I change it (even in temporary manual mode in the thermostat)
The valve moves roughly in correspondence with the delta between the target and actual temperature (1°=25%, 2°=50%, 3°=75%, 4°=100%)
Is there a way to somehow change those bindings? Or to manually control the opening percentage?
I have three of these, and I don’t believe you can manually change the valve state using the slider, even though the quirk suggests you can. You can make the valve open or close by setting the target temperature higher or lower than the current temperature as you have discovered, and you’ll hear the motor moving, but the Valve State as recorded by the quirk, doesn’t seem to change reliably either, so I would not use it as a basis of any automations.
I believe the mapping of the valve state to the variance of the temperature is controlled by the device itself, and as such, you can’t do anything about this, unless you do some clever scripting to trick the TRV by manipulating for example, the temperature offset.
I use the TRV in conjunction with an aqara temperature sensor, and the generic thermostat integration, and I’ve never really noticed that mapping to be an issue. That might be because I set the TRV’s temperature offset to -9, so it always thinks its much colder than it is, so when the generic thermostat turns it on, its probably always going to 100%
Hm, how do you “turn it on”?
I see three switch entities (one of which is disabled), but none of them actually does anything.
I’m only getting the valve to move if the TRV thermostat setting is changed. So the only way now I see is to have a “real” custom thermostat which will trigger a change in the TRV thermostat to either 5C (off) or 30C(on).
Is that how you’ve done it?
Thats exactly how I’ve done it.
I setup an input boolean to act as the switch for the generic thermostat (because the TRV doesn’t have one), and then use an automation to monitor when that boolean changes state and turn the TRV on/off.
The two working switches are (iirc), the child lock feature, and a valve recalibration test. Once you figure out which is which, rename them so you remember for next time!
Oh well, that’s a really janky solution (no offence, I’ve come up with the same one 
)
I haven’t found any info on how to do it more elegantly, but I hope if someone finds a way - it will be posted somewhere here
UPDATE:
I’ve decided to try out Better Thermostat. Will see how’s it gonna work once we have a lower temp here. Strange that I can’t pick offset calibration, but that’s a BT porblem.
@Rofo By the way, do you know what this input sensor means? It’s constantly on for me.
That sensor, I’m not sure what its for, but i have the same issue.
Better thermostat is no better than generic thermostat, infact I think its potentially worse, as I remember it does not have any hot or cold tolerance settings, and it can potentially keep spamming the TRV with temperature adjustments, reducing its flash memory life span.