Sonoff TRVZB is missing attributes that can be exposed, yet configurable using a SEND, SET command

aussiebum71 commented 12 months ago

What happened?

The new Sonoff TRV https://www.zigbee2mqtt.io/devices/TRVZB.html is missing some attributes that can be exposed and changed. For instance local_temperature_calibration can be adjusted sending a Zigbee SET command. But it is not showing up in the Exposes page in Zigbee2MQTT. The TRV also has a child lock feature, that can possibly be exposed.

Occupied heating setpoint cannot be set in Auto mode, it defaults to 16 degrees celsius. Not sure what Auto mode does? Should it be ECO mode?

TRVZB firmware verision 1.1.1

What did you expect to happen?

Be able to see local temperature calibration, child lock and other missing, features and attributes in the Expose tab of the device

How to reproduce it (minimal and precise)

Click on the Exposes tab of the TRVZB to see missing attributes

Zigbee2MQTT version

1.33.1-1

Adapter firmware version

20221226

Adapter

Sonoff Zigbee USB zStack3x0

Debug log

No response

infinitedestiny commented 11 months ago

I think it is necessary to expose at least the setpoint relating to AUTO mode. Now it seems to be fixed at 16/19 degrees (it depends by hour range defined somewhere).

photomoose commented 11 months ago

I've done some work to partially expose the child lock functionality which will appear in the next release... I've also received some documentation from Sonof regarding the proprietary cluster information. I'm expecting to receive my Zigbee packet sniffer in the next couple of days, so I will analyse what the app sends via the bridge and try to add more functionality for this device in the upcoming days.

hubi-IT commented 11 months ago

I also asked Sonoff for documentation, I will try to help improve support that devices. I bought 6 pcs.

ferrarid61 commented 11 months ago

The calibration attribute is exposed by zigbee I tryed and it works. Is it possible to send this command via HA automation?

photomoose commented 11 months ago

I am now actively working on this.

Child Lock

Support for child lock functionality was added in release 1.33.2 - note that this version only "reports" the child lock status; it is not possible to set it remotely in this version. I have since completed the work to set it remotely and I will create a PR later tonight so that it can be made available in the next release.

Open Window Detection

I've implemented the reporting and setting of open window detection - I will also push these changes tonight.

Next quick wins are likely to be Frost Protection and Temperature Calibration - I will look into these tonight.

@aussiebum71 With respect to auto mode, the TRV has two modes: manual and auto. Manual is exactly what you'd expect - you manually dial in a temperature by twisting the TRV (or by setting it remotely via Home Assistant / Z2M) and it will stay at that temperature until you manually change it to something else (or a Home Assistant routine changes it etc). Auto mode (indicated with a clock icon on the TRV when you press the button) allows the TRV to automatically change the desired temperature according to a programmed schedule - non Z2M users that use the Sonoff Bridge and eWeLink app can define temperature schedules and program their TRVs to operate automatically. I will look into how this information can be exposed once I've completed the above two items. I imagine such functionality probably isn't essential given we're using Z2M to "manually" set the temperature from the TRV perspective. However, I can see such functionality being useful as a fail safe (i.e. in case Home Assistant or Z2M becomes unavailable, at least the TRV will still operate according the programmed schedule).

@Koenkk could you assign this issue to me, please?

infinitedestiny commented 11 months ago

@photomoose I think that AUTO Mode uses a sort of PID control to modulate the opening value of the valve. In HEAT Mode the valve is just on/off controlled. No way to control partial open.

photomoose commented 11 months ago

@infinitedestiny that could be a possibility, although I imagine that sort of control is internal rather than being operated over Zigbee.

Attached is photo of the schedule that can be set in the app. When in auto mode, the TRV automatically changes its temperature according to the time (the TRV polls the coordinator for the current time every so often).

infinitedestiny commented 11 months ago

@photomoose yes I think that the PID control is internal, but it is useful to partially close the valve when reaching the set point. This helps to reduce the hysteresis. So it could be very useful to have the possibility to change setpoints in AUTO Mode. Another useful thing (but probably this value is not exposed) is to manual control the opening value of the valve, in this way you can use an external PID. I'd like to help, but I'm sorry... I don't have both packet sniffer and sonoff gateway :(...

kolkoo commented 11 months ago

Could you expose the local_temperature_calibration if it is supported by the device as mentioned above? Doing this should allow (hopefully) to use this with "Better Thermostat" and integrate it with a remote temperature sensor as far as I understand. Cheers.

photomoose commented 11 months ago

@kolkoo I'm working on temperature calibration next.

photomoose commented 11 months ago

Next up is Frost Protection, coming later today.

photomoose commented 11 months ago

Now taking a look at weekly schedule functionality. It's definitely supported in the traces I've taken - just testing whether it will work with Z2M natively.

@Koenkk does the existing schedule functionality work in the Z2M frontend? When I enter values, they disappear when moving to the next field.

Koenkk commented 11 months ago

does the existing schedule functionality work in the Z2M frontend? When I enter values, they disappear when moving to the next field.

This should be fixed in z2m 1.33.2

dafunkydan commented 11 months ago

Great Development going on here! Looks like the best is yet to come ;-)

I am missing the running_state: as Entity in Homeassistant. It is already exposed in Z2M 1.33.2. I hope i'm just neither too dumb nor to blind - any chance to get a Hand on that Value?

aussiebum71 commented 11 months ago

@dafunkydan

This is how it's looking in the current DEV branch.running_state is exposed. Battery low could be merged with Battery. Hopefully Sonoff will provide a further firmware update to provide an ECO mode in addition to Manual and Auto. And also an external temperature sync. Then this TRV will rival pretty much most of the Zigbee TRVs on the market, I'll be replacing my Moes TRVs with these, as you're able to query to get most settings and not have to wait for an message update. @photomoose is doing a fantastic job adding these extra attributes, they are also working on exposing the schedules for Auto mode.

photomoose commented 11 months ago

@aussiebum71 I think @dafunkydan is talking about an explicit sensor entity for the running state in Home Assistant, not Z2M.

The TRV is exposed as a "climate" entity in Home Assistant - it's main state is the HVAC mode (off/auto/heat). If you want to get access to the running_state then you will have to query the climate entity's attributes or create a template sensor to expose this. You can see all the available attributes by looking at the climate entity in Developer Tools -> States in Home Assistant:

Here's an example of a binary sensor I created which looks at the hvac_action attribute of each TRV to signal whether any TRV is demanding heat. I then use this in an automation to turn on/off my boiler:

  - binary_sensor:
      - name: "Heating Demand"
        device_class: heat
        state: >
          {% set radiators = [
            states.climate.snug_radiator,
            states.climate.living_room_radiator_left,
            states.climate.living_room_radiator_right,
            states.climate.master_bedroom_radiator,
            states.climate.matilda_radiator,
            states.climate.landing_radiator,
            states.climate.jasper_radiator,
            states.climate.rupert_radiator

          ] %}
          {{ radiators | selectattr('attributes.hvac_action','eq','heating') | list | count > 0 }}

aussiebum71 commented 11 months ago

@photomoose, correct, @dafunkydan can create a value template sensor to extract the running_state. Example below

template:
  - sensor:
      - name: "TRV Heating State"
        state: "{{ state_attr('climate.living_room_trv_door', 'running_state') }}"

dafunkydan commented 11 months ago

Guys you are super kind! I should have written more and/or precise, sorry.

Yes, my Problem is, that not all Values from Z2M are available in HomeAssistant: grafik

Entity or Attribute doesn't matter, as long as it's available somewhere ;-) Comparing with @photomoose s Screenshot, there are some other Attributes missing (probably bc of Dev-Branch?), and some Attributes are individual Entities on my HA (e.g. Battery, Child Lock,...) I am on Z2M 1.33.2, HA 2023.10.5, TRVZB is on FW 1.1.1. It still feels like i am just stupidly overseeing a basic Setting or st...

photomoose commented 11 months ago

Weekly Schedule Functionality

I've been down a bit of a rabbit hole with this one...

Firstly, I've been unable to get Z2M frontend to form the correct payload when configuring the schedule. @Koenkk I have been using Z2M with v0.6.142 of the zigbee2mqtt-frontend package and I've also been using Z2M v1.33.2-1 as a HA Add-on and experience the same issue. When focus changes on the time textboxes, the partially complete payload is sent down the websocket and gets rejected (e.g. the hour is sent without the minute or vice-versa). Not sure if I'm doing something wrong here...

I did, however, manage to successfully send a schedule to the TRV by publishing the correct payload to the MQTT topic (e.g. zigbee2mqtt/[TRV-device]/set) instead of using the UI.

The second problem I encountered was that setting a schedule for today (Wednesday) had no effect on the TRV, but setting a schedule for Monday took effect today, so the schedule from Z2M was incorrect by 2 days. I sniffed the Zigbee packets for the Set Weekly Schedule command that was sent from both Z2M and the Sonoff Bridge and they both looked correct and comparable with each other. A bit more digging, and I discovered a discrepancy with the Read Attributes Response sent by Z2M and the Sonoff Bridge whenever the TRV asks the coordinator to read the Time cluster.

From the ZCL spec:

[The Time] cluster provides a basic interface to a real-time clock. The clock time MAY be read and also written, in order to synchronize the clock (as close as practical) to a time standard. This time standard is the number of seconds since 0 hrs 0 mins 0 sec on 1st January 2000 UTC (Universal Coordinated Time).

The response from Z2M correctly shows the current time and is indeed the number of seconds since 1st Jan 2000:

ZigBee Cluster Library Frame, Command: Read Attributes Response, Seq: 2
    Frame Control Field: Profile-wide (0x18)
    Sequence Number: 2
    Command: Read Attributes Response (0x01)
    Status Record, UTC
        Attribute: Time (0x0000)
        Status: Success (0x00)
        Data Type: UTC Time (0xe2)
        UTC: Nov  8, 2023 14:09:17.000000000 GMT (0x2CDE530D)
    Status Record, Uint32: 752767757
        Attribute: Local Time (0x0007)
        Status: Success (0x00)
        Data Type: 32-Bit Unsigned Integer (0x23)
        Uint32: 752767757 (0x2cde530d)

The response from the Sonoff Bridge, however is 30 years in the future, suggesting that Sonoff has incorrectly implemented the ZCL spec by using a date 30 years prior to 1st Jan 2000 - i.e. the Unix Epoch, 1st Jan 1970:

ZigBee Cluster Library Frame, Command: Read Attributes Response, Seq: 0
    Frame Control Field: Profile-wide (0x18)
    Sequence Number: 0
    Command: Read Attributes Response (0x01)
    Status Record, UTC
        Attribute: Time (0x0000)
        Status: Success (0x00)
        Data Type: UTC Time (0xe2)
        UTC: Nov  7, 2053 14:20:04.000000000 GMT (0x654B9914)
    Status Record, Uint32: 1699456768
        Attribute: Local Time (0x0007)
        Status: Success (0x00)
        Data Type: 32-Bit Unsigned Integer (0x23)
        Uint32: 1699456768 (0x654ba700)

In order for the Sonoff TRVs to work correctly with the Sonoff Bridge, the TRVs must, therefore, also be implemented to incorrectly expect the time response to be number of seconds since the Unix Epoch. If I take the response from Z2M above (UTC: Nov 8, 2023 14:09:17.000000000 GMT (0x2CDE530D)) and assume that to be a Unix timestamp, I get a date exactly 30 years prior to today: 8th November 1993 - this date happened to fall on a Monday, which would explain why setting a schedule for Monday in Z2M worked today whereas setting a schedule for Wednesday did not.

@Koenkk have you seen this time issue before? The issue must apply to all Sonoff devices... I doubt Sonoff would fix the bug on their side (they would need to issue firmware updates for every device that depends on time from the Sonoff Bridge, and then existing user configuration for schedules would be messed up). Alternatively, we could add functionality for zigbee-herdsman to emulate the Sonoff Bridge behaviour for the Time cluster, however I'm not sure whether the device type is known at that level in the code. I guess another question is whether anyone specifically wants the ability to program schedules directly from Z2M....if not, then I guess we can ignore it and choose not to expose it.

photomoose commented 11 months ago

@Koenkk I've thought of another possible workaround for the weekly schedule issue... We know that the Sonoff time implementation is 30 years out - i.e. it thinks the Z2M current time is 946684800 seconds earlier - or 10957 days earlier. Subtracting 10957 days from the current day results in a day of a week two days earlier. This means we could do a somewhat dirty hack in Z2M and create a custom expose for the Sonoff device that maps the days as follows, without having to touch the Z2M implementation for the time cluster:

Z2M Day	ZCL Payload Day
Sunday	Friday
Monday	Saturday
Tuesday	Sunday
Wednesday	Monday
Thursday	Tuesday
Friday	Wednesday
Saturday	Thursday

It would technically be wrong if you look at the packets being sent to the device (and the schedule would be offset by two days if the device was re-paired with the Sonoff Bridge and app, assuming it doesn't get reset when re-paired), but in this case two wrongs would make a right.

What are your thoughts?

photomoose commented 11 months ago

@dafunkydan not sure what's causing your missing attributes, these were available to me before I started this current work. I'm currently on HA 2023.11 and see them all fine, although I am sure they were present in earlier versions. It might be worth trying to delete the device from Z2M and re-pair it again, to see if the "pairing handshake" makes it come back.

dafunkydan commented 11 months ago

After digging a bit deeper, i found that all states arrive in Mosquitto. I found that Issue https://github.com/home-assistant/core/issues/103414#issuecomment-1793848466 with a similar Behavior, mentioning that its a Z2M Problem, beeing fixed in 1.33.3. So that is supposedly the Culprit. Think im gonna wait for the next Update then...

On your elaborations @photomoose i can't contribute anything. This is like magic for me. Really astonshing what you are doing there, thank you so much!

Koenkk commented 11 months ago

You can use this example to send a custom time response
I fixed the frontend schedule issue. Changes will be available in the dev branch in a few hours from now. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html)

photomoose commented 11 months ago

Perfect! I'll get that in tonight/tomorrow then! 👍

photomoose commented 10 months ago

Sonoff have helped me identify further attributes available in their manufacturer-specific cluster. Most of these are diagnostic, but I have seen some of them in my traces and will expose them in the next day or two:

Fault Code
Rapid Heating Temperature (not used, will ignore)
Number of Idle Steps - number of steps used for calibration (number of no-load steps)
Number of Closing Steps - number of steps it takes for the valve to close
Valve Opening Limit Voltage - valve opening limit position voltage value
Valve Closing Limit Voltage - valve closing limit position voltage value
Valve Motor Running Voltage - valve motor operating voltage value
Manual Mode Temperature - set temperature in manual mode (I assume this is the "saved" temperature of manual mode, for when you switch between auto and back to manual, it knows what value to go back to)
Auto Mode Temperature - set temperature in automatic mode (as above, I presume)

TomaszDom commented 10 months ago

in the current stable version of z2m, does anyone else experience this:

1) system mode heat, set heating setpoint > local temperature, running state enters heat until heating setpoint < local temperature, goes to idle 2) next time heating setpoint > local temperature, running state is always idle, never opens the valve until I mess with the temperature again, effectively making the trv useless

photomoose commented 10 months ago

@TomaszDom I think the valves have some leniency in them to prevent them continuously switching on/off as soon as the setpoint is unmet/met. I don't know what the figure is, but could be 1C either side or something.

My TRVs work perfectly - and sure enough the local temperature is just under the setpoint right now. If it drops more, the TRV will eventually come on.

TomaszDom commented 10 months ago

I suppose I've gotten used to the behaviour of TS0601_thermostat trvs, which I am in the process of replacing with this sonoff, it looks like the valve is either fully on or fully off, maybe the new version of z2m will expose a PID-controlled system mode.

photomoose commented 10 months ago

The Sonoff documentation is quite vague on how this TRV functions. I think you're right in saying the valve is either fully on or fully off - I'm not aware otherwise. I have exposed some further [rather useless] attributes about the valve here.

I assume there must be some sort of PID internally - I have exposed a temperature calibration setting allowing you to offset the setpoint by a defined value, but there is no way to actually control the physical position of the valve.

I have exposed the majority of the attributes available (as witnessed in my traces and from what Sonoff has told me).

Schedule functionality probably needs some work, I'm still looking into the complications here.

TomaszDom commented 10 months ago

@photomoose earlier you said that sonoff helped you figure some things out, which is rather unprecedented, maybe you could also ask them about on/off or pid control?

pawol commented 10 months ago

I am almost sure this is next rebrand of GTZ06 from id3.pl aka TRV601 aka _TZE200_z1tyspqw. Previously I saw it in the Z2M as TS0601_thermostat_1 but now the name is changed. Look there.

https://www.zigbee2mqtt.io/devices/TS0601_thermostat_1.html and my ticket https://github.com/Koenkk/zigbee2mqtt/issues/19321

At the moment almost everything is implemented perfectly excluding boost time function only - missing converter message pops up when used.

photomoose commented 10 months ago

@pawol it looks very similar; I will take a look at the existing code and see whether I can send the same payloads to my Sonoff TRVs.

sobrarbe commented 10 months ago

Hi, I just received my sonoff tubes and I just integrated them with zigbee2mqtt 1.33.2-1 perfectly. But I see that the parameters that you mentioned about child lock, open window and valve calibration are missing. Do you know if this data will be added in the next zigbee2mqtt updates? Thank you.

photomoose commented 10 months ago

Hi, I just received my sonoff tubes and I just integrated them with zigbee2mqtt 1.33.2-1 perfectly. But I see that the parameters that you mentioned about child lock, open window and valve calibration are missing. Do you know if this data will be added in the next zigbee2mqtt updates? Thank you.

@sobrarbe Child Lock, Open Window and Temperature Calibration are available in v15.109.0 of zigbee-herdsman-converters; the current release of Z2M uses v15.106.0. The next official release of Z2M should incorporate this functionality.

The features are available now if you're prepared to switch to the dev branch. If you're using Z2M as an add-on in Home Assitant, then you can install the Edge version to get the latest features (see https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html).

sobrarbe commented 10 months ago

@photomoose Thank you very much for your prompt response. As you say and I understand. In the next update of zigbee2mqtt will the improvements that you mention about being able to calibrate temperature and the child and open window locking options be included? If so, I will wait since the option you mentioned is in the zigbee2mqtt development branch. I don't dare to, being a newbie.

photomoose commented 10 months ago

@sobrarbe yes, they will be in the next release - and it looks like a new release of zigbee2mqtt is made available at the beginning of each month, so you've probably only got about a week left to wait.

sobrarbe commented 10 months ago

@photomoose Thank you very much for your great work and for helping with this project. For newbies like me it is still a complicated topic. That's why your great work helps us. Furthermore, the Sonoff valves are very beautiful and it would be a shame if it were not for your help that they would not be able to get the most out of them. I thank you again.

mklooss commented 10 months ago

@photomoose thank for your work :) does the TRVZB does not support partial opening valve or is this a lack of informations about the trv? Sometimes my Gas boiler runs in an security stop, bcz the return temperatur. with normal trv/manual i did not run into this state :/

zigbee2mqtt running here currently in dev branch

photomoose commented 10 months ago

@mklooss I'm not aware of it supporting partial opening; I haven't seen any sort of feature in the eWeLink app. The closest thing I have found are valve opening/closing voltages and the number of steps to close the valve, which will be exposed when I complete #6469 (based on information sent to me from Sonoff). These attributes appear to be read-only. I have no idea how useful they are.

I will have another play to see if I can send it some commands similar to other TRVs.

With regards to the security stop on your boiler....is that because the return temperature is too high? From what I've read, it is advisable to have one or two radiator valves always open to ensure this doesn't happen. (My bathroom radiators do not have smart TRVs for this reason).

jayme-github commented 10 months ago

Did you had any success setting local_temperature_calibration? For me it does not seem to make a difference switching from -4 to 4 for example. The reported local_temperature does not change (e.g. the offset is not applied there) and the TRV does not switch to heating even though it should (according to external thermometers).

jarrodstrachan96 commented 10 months ago

@photomoose Hi, thanks for your great work exposing these settings in Z2QMTT. Are you aware of any way on this TRV to prevent "OFF" system mode? The problem arises when combining with Better Thermostat, that if the TRV's manual control dial is used to turn the TRV to OFF, that the preset target temperatures within Better Thermostat will no longer be in affect, as the device state is OFF.

If you or anybody has any suggestions I'd appreciate it, thanks for the great work.

jchidley commented 10 months ago

Did you had any success setting local_temperature_calibration? For me it does not seem to make a difference switching from -4 to 4 for example. The reported local_temperature does not change (e.g. the offset is not applied there) and the TRV does not switch to heating even though it should (according to external thermometers).

@jayme-github I just tried this on a couple of my TRVZBs by changing the offset to 10 and then changing it back to 0. One TRVZB responded correctly but the other added 10 OK but didn't work when I set the offset back to 0: it used a -10 offset (i.e. a 20 swing). I am on this version: 1.34.0-1

SjoerdSterk commented 10 months ago

Did you had any success setting local_temperature_calibration? For me it does not seem to make a difference switching from -4 to 4 for example. The reported local_temperature does not change (e.g. the offset is not applied there) and the TRV does not switch to heating even though it should (according to external thermometers).

I decided to skip the calibration altogether, and just feed it (on change) the delta between the external temperature and the desired temperature:

{% set temp_current = states('sensor.climate_indoors_bme280_temperature') | float %}
{% set temp_target = states('input_number.livingroom_target_temperature') | float %}
{% set temp_delta = (temp_target - temp_current) | round(1) %}
{% set temp_trv = states('sensor.sonoff_trv_current_temperature2') | float %}
{% set temp_trv_target = (temp_trv + temp_delta) | round(1, 'half', 0) %}

Current temperature: {{ temp_current }}
Target temperature:  {{ temp_target }}
Temperature delta:   {{ temp_delta }}
TRV temperature:     {{ temp_trv }}
TRV target:          {{ temp_trv_target }}

msemik commented 10 months ago

I've used below only one night (using latest-dev docker tag). It worked out amazing. I am impressed with all the work done to improve support for that deivce, great job.

service: number.set_value
data:
  value: >-
    {{ '%0.1f' | format(
    max(min(states('sensor.salon_temperature')| float - 
    state_attr('climate.salon', 'current_temperature') |
    float + state_attr('climate.salon',
    'local_temperature_calibration')| float,7.0),-7.0) )}}
target:
  entity_id: number.salon_local_temperature_calibration

photomoose commented 10 months ago

@jayme-github the calibration should adjust the local temperature, as shown in the screen recording below that I captured a few minutes ago... However, you will notice that when I return the calibration to 0C, the device wrongly reports a local temperature of 9.1C - refreshing the value does not seem to take affect. It's only when I make a few more adjustments to the calibration temperature that the local temperature reverts to being reported correctly.

This might explain why my radiators occasionally seem to be always on when I use Better Thermostat. I will get my sniffer out and investigate what Zigbee messages are being sent between the TRV and Z2M, and will report back here shortly.

@jchidley thanks for pointing this out, I've managed to replicate the swing when I change the calibration values in quick succession. I'm investigating...

https://github.com/Koenkk/zigbee2mqtt/assets/1983638/7e7427e3-2bf8-4e2c-9b93-60cbdc4a43f8

TomaszDom commented 10 months ago

Damn it, I bought them specifically to use with better thermostat and because they were marketed specifically to work great with z2m. Hopefully there will be over the air updates that fix this. I'm tired of creating automations with workarounds that never seem to work consistently. Will OTA via z2m be even possible or do we have to buy their bridge?

sob., 2 gru 2023, 10:48 użytkownik Tom Davis @.***> napisał:

@jayme-github https://github.com/jayme-github the calibration should adjust the local temperature, as shown in the screen recording below that I captured a few minutes ago... However, you will notice that when I return the calibration to 0C, the device wrongly reports a local temperature of 9.1C - refreshing the value does not seem to take affect. It's only when I make a few more adjustments to the calibration temperature that the local temperature reverts to being reported correctly.

This might explain why my radiators occasionally seem to be always on when I use Better Thermostat. I will get my sniffer out and investigate what Zigbee messages are being sent between the TRV and Z2M, and will report back here shortly.

https://github.com/Koenkk/zigbee2mqtt/assets/1983638/7e7427e3-2bf8-4e2c-9b93-60cbdc4a43f8

— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/19269#issuecomment-1837106018, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACHKLNG56YBVLROYCFUUPLTYHL2N7AVCNFSM6AAAAAA55RT2WKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZXGEYDMMBRHA . You are receiving this because you were mentioned.Message ID: @.***>

dktrekkie commented 10 months ago

@jayme-github the calibration should adjust the local temperature, as shown in the screen recording below that I captured a few minutes ago... However, you will notice that when I return the calibration to 0C, the device wrongly reports a local temperature of 9.1C - refreshing the value does not seem to take affect. It's only when I make a few more adjustments to the calibration temperature that the local temperature reverts to being reported correctly.

This might explain why my radiators occasionally seem to be always on when I use Better Thermostat. I will get my sniffer out and investigate what Zigbee messages are being sent between the TRV and Z2M, and will report back here shortly.

@jchidley thanks for pointing this out, I've managed to replicate the swing when I change the calibration values in quick succession. I'm investigating...

Screen.Recording.2023-12-02.at.09.33.07.mov

I have made a strange observation on some of my Sonoff TRVZB's. When I set the calibration the temperature goes all over the place, and therefore I can’t really reliably use the calibration to offset my TRV's. It's not all of them that does this but it looks kind of crazy. This must be a bug in the TRV itself, I guess? Has anyone else seen something like this. I have seen it on two of my 8 TRV's so far:

https://github.com/Koenkk/zigbee2mqtt/assets/141948373/0fb722bf-7bb0-4466-bfc6-e28c36c2a43a

dktrekkie commented 10 months ago

And BTW: The only way I can get it to behave again, is to factory reset the TRV by taking out the battery and holding the button. But afterwards, setting the calibration will eventually fail again.

SjoerdSterk commented 10 months ago

And BTW: The only way I can get it to behave again, is to factory reset the TRV by taking out the battery and holding the button. But afterwards, setting the calibration will eventually fail again.

Same here, with 1 out of 1 TRV's. Which is why I decided to circumvent calibrating and be done with it.

jarrodstrachan96 commented 10 months ago

I've grown tired of my current approach of syncing Zigbee TRVs to an external temp sensor. I've tried a few ways to do this, from various automation blueprints to using Better Thermostat integration. The problem is it's not entirely accurate or reliable, whether using TRV local temperature calibration or TRV Target temperature based calibration.

SO, I've thought about a different approach:

1 Template Switch, we will call "Virtual TRV switch" Switch_On will set the target temperature of the ZIgbee TRV to 35c (the max), to fully open the valve. Switch_Off will set the target temperature of the Zigbee TRV to 5c (to close the valve) Effectively this switch will serve as a binary OPEN (35c target) or CLOSED (5c target) for my TRV

1 Generic Thermostat entity The thermostat heater attribute is set to the Virtual TRV Switch The temperature attribute is set to my external temperature sensor.

If I've overlooked anything or if anybody has a better idea please let me know. But in practice for the last 12 hours it seems to be working flawlessly.

Koenkk / zigbee2mqtt