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

[aussiebum71]

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]

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]

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]

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

[ferrarid61]

The calibration attribute is exposed by zigbee

I tryed and it works. Is it possible to send this command via HA automation?

[photomoose]

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]

@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]

@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]

@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]

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]

@kolkoo I'm working on temperature calibration next.

[photomoose]

Next up is Frost Protection, coming later today.

[photomoose]

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]

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]

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]

@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]

@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]

@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]

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:

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]

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]

@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]

@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]

After digging a bit deeper, i found that all states arrive in Mosquitto.
I found that Issue home-assistant/core#103414 (comment) 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]

• 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]

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

[Antroxin]

I've updated two out of seven of my TRVs to 1.1.4 (two of them have been stopped in the middle). Now I've noticed that v1.1.4 has been reverted to v1.1.1. How can I revert those two TRVs to the v1.1.1?

[jj-uk]

I can also confirm that a factory reset seems to fix the issue, in my very limited testing this morning. (Remove battery, hold down top button, then replace battery).

Looks like it stays on v1.1.4 after reset, as shown here in the eWeLink app. However, it is still shown as v1.1.1 in Z2M, but no further updates are shown for it. The Z2M logs report:

Received Zigbee message from 'Kitchen Radiator', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":0,"fileVersion":4356,"imageType":8199,"manufacturerCode":4742}' from endpoint 1 with groupID 0

File version 4356 is indeed v1.1.4 so there might be a UI/config issue in Z2M with the true firmware version (I'll do some digging later). It is reported as v1.1.4 in eWeLink.

RPReplay_Final1709280950.MP4

This video appears to show correct operation.

So a factory reset is needed to resolve issues?
Are you able to check the offset calibration now works?

@Antroxin Try a factory reset first before reverting. See if that fixes it for you to.

[GTunney]

I've just factory reset mine, it is still showing in Z2M as 1.1.4 but can confirm now that it correctly displays heating status and the valve is operating in the correct order.

Haven't tested the offset just yet.

[Ratzupaltuf]

I can confirm the issues after updating to version 1.1.4 and I also can confirm the factory reset brings back the device fully working. Thank you for sharing this idea @triggertreyy, you saved my day...

[s0ullight]

local_temperature_calibration behavior seems to be improved with 1.1.4
Upon updating the value I receive a short burst of messages. local_temprature stays unchanged until the last message and then correctly updates.

[photomoose]

Looks like @Koenkk has reverted the update so it is not available anymore. Not sure where we go from here.

[s0ullight]

The firmware is still out there for those who want it. Meanwhile Sonoff should clarify what's going on. My wild guess is someone got their hands on an unreleased firmware image.

[lolcatnip]

Interesting that on eWeLink Forum thread there is screen with options to set valve opening and closing degree. Is it something new or it was already available on dev branch?

[photomoose]

There's an open PR for valve opening percentage:

Koenkk/zigbee-herdsman-converters#7130

[photomoose]

This might be the reason why some of you are experiencing valve opening issues with v1.1.4. It looks like this firmware supports valve opening percentage configuration, but the UI to configure it isn't yet merged into Z2M. Perhaps those percentages are initialised to 0% or some other unexpected number?

[lolcatnip]

I didn't use that feature, and my TRV was also not functioning properly after update.

[Koenkk]

Meanwhile Sonoff should clarify what's going on. My wild guess is someone got their hands on an unreleased firmware image.

It's actually a SONOFF employee who created the PR (Koenkk/zigbee-OTA#450) and then asked me via mail to revert it. I'm awaiting further instructions from them.

[photomoose]

I didn't use that feature, and my TRV was also not functioning properly after update.

I'm only speculating here - I haven't seen the firmware code, so everything I write here could be wrong - but it's entirely possible that, seeing as the new firmware allows the valve position to be configured, the default position when the TRV starts for the first time could be initialised to 0%, whereby it waits for a command from eWeLink or Z2M to set the position, regardless of whether you use the feature or not. Possibly a bug or possibly a dependency on the UIs (eWeLink/Z2M) requiring to be updated first before you can use the firmware.

[jamesonuk]

Meanwhile Sonoff should clarify what's going on. My wild guess is someone got their hands on an unreleased firmware image.

It's actually a SONOFF employee who created the PR (Koenkk/zigbee-OTA#450) and then asked me via mail to revert it. I'm awaiting further instructions from them.

I suspect is is circular and in response to people saying they have had issues...
https://forum.ewelink.cc/t/trvzb-firmware-update-1-1-4-big-problem/29029/18

seems several people have reported it is working after doing a reset of the device as above (probably same people?)

If I get time this evening I will look at updating a non critical valve and, applying PR to see valve values and seeing what I can find.

[elmystico]

Overall this is quite promising. I didn't upgrade yet just because my z2m network has poor connections and I wait for usb extension cable delivery :-)

[GTunney]

Has anybody found a way to downgrade yet?

Twice now 2 nights in a row I’ve woke up absolutely sweating and the TRV in my room has “In” on it and then proceeds to “Ad” once pressed despite already being reset to factory and set up in Z2M.

[podkilla]

For me the device completely stopped working after upgrading to 1.1.4
I can set the temperature but the device doesnt do anything. Heating stays off no matter what i set.

[triggertreyy]

Yeah it seems like the offset bug with the jumping offset set temp is solved. But the offset is still not working like it should. I set the temp offset temp to the right temp in the room and a day later the offset temp is at +7 so the valve is thinking the room is at 25....

[sobrarbe]

After so many tests with the Sonoff TRVs and the calibration. I chose to use Better Thermostat and the truth is that it is luxurious and regulates with the real temperature of an external sensor in the room and acts on the Sonoff TRV. The truth is that since I integrated it into HA, they are fine and perfect and I don't have to fight with the calibration and it is much more reliable when taking the temperature from an external sensor in the same room.

[firebowl]

But it also works with the Blueprint Advanced Heating Control. Simply specify an external temperature sensor and the Sonoff TRVs take its temperature as an offset.

[triggertreyy]

After so many tests with the Sonoff TRVs and the calibration. I chose to use Better Thermostat and the truth is that it is luxurious and regulates with the real temperature of an external sensor in the room and acts on the Sonoff TRV. The truth is that since I integrated it into HA, they are fine and perfect and I don't have to fight with the calibration and it is much more reliable when taking the temperature from an external sensor in the same room.

BT is for me also not working... it shows that it is heating but when u check the radiator it is cold also the valve is on idle at Z2M overview

[sobrarbe]

and do you have it configured correctly? I have 6 Sonoff TRVs and they work perfectly with it.......... Before, with the calibration and the sensor of the TRV itself it was impossible for it to work. When it was heating it read 27 degrees and the room was at 21, I calibrated it and when it cooled the radiators it read 7 degrees less. It was a disaster, that's why it's better that it works with external sensors and not with the sonoff trv's own

[firebowl]

No one doubts that radiator thermostats work better if they receive the temperature as an offset from an external sensor. But you don't necessarily have to use BT for this.

[triggertreyy]

and do you have it configured correctly? I have 6 Sonoff TRVs and they work perfectly with it.......... Before, with the calibration and the sensor of the TRV itself it was impossible for it to work. When it was heating it read 27 degrees and the room was at 21, I calibrated it and when it cooled the radiators it read 7 degrees less. It was a disaster, that's why it's better that it works with external sensors and not with the sonoff trv's own

What is " configured right" exactly for you?:) i set it to offset and normal. And add the external sensor etc.

[Mille77]

I'm using external Sensor, Target Temp. and All Time Based and it works fine on 3 Devices.

[benkoechlin]

I'm using external Sensor, Target Temp. and All Time Based and it works fine on 3 Devices.

how do you SET the temperature from an external sensor? directly to local_temperature?
Using zigbee2mqtt and tried to adapt a automation from my Aqara TRVs but without any luck.

[jamesonuk]

Can I suggest discussion around configuring the devices and how people are using them continues in #21693 so that the discussion around the actual issue that was raised here and 1.1.4 firmware is not lost.

@Koenkk perhaps it might be an idea to close this issue as I think all the attributes mentioned in the original issue are now available? There is a PR for the new valve settings in 1.1.4 firmware and perhaps we can create an issue for problems with 1.1.4 firmware??

[Mille77]

I'm using external Sensor, Target Temp. and All Time Based and it works fine on 3 Devices.

how do you SET the temperature from an external sensor? directly to local_temperature? Using zigbee2mqtt and tried to adapt a automation from my Aqara TRVs but without any luck.

With Better Thermostat. A few comments above, you can also see the pictures of how it should be configured.

[jamesonuk]

perhaps we can create an issue for problems with 1.1.4 firmware??

Created #21694 can people use that to track discussion of the 1.1.4 firmware and #21693 for discussion around how people have configured the devices ?