2.7.2

[Koenkk]

Happy new year all! 🎆

Feel free to discuss the 2.7.2 release here!

[Naudnaud25]

Hello
Probleme with the:
#11057 TZ-ZT01_GA4 Tuya Temperature & humidity Sensor with external probe
Only the internal sensor is working
I have a Null value in Battery.

I using it with a external converter defore this update.
Thx

[FrycuFr]

All schedule setings for TRVZB SONOFF (Zigbee thermostatic radiator valve) was gone ...

[morlie]

I found same behaviour as well. It seems it's related to that PR #30226

What is the expected system behaviour?

• MQTT-Path zigbee2mqtt/FRIENDLY_NAME/set {weekly_schedule: xxx} completely gone? So we cannot set a weekly profile in one mqtt publish message?
• In the status the daily schedule is not read. Only null is shown "weekly_schedule_friday": null,"

I'm managing my weekprofiles in Node-Red I need to do some re-coding. I would like to know what's the final setup. At least, the daily schedules should be filled correctly and not just showing NULL. Currently NULL is reflected as none in Home Assistant as well.

[GigiPompieru]

What seems strange to me is that, even if in the Exposes tab things have now changed, as well as in the device page in HA, when going to state, the json looks the same as before:

    "weekly_schedule": {
        "friday": "00:00/16 07:00/19 10:00/16 10:00/16 17:00/19 23:00/16",
        "monday": "00:00/16 07:00/19 10:00/16 10:00/16 17:00/19 23:00/16",
        "saturday": "00:00/16 07:00/19 10:00/19 10:00/19 10:00/19 23:00/16",
        "sunday": "00:00/16 07:00/19 10:00/19 10:00/19 10:00/19 23:00/16",
        "thursday": "00:00/16 07:00/19 10:00/16 10:00/16 17:00/19 23:00/16",
        "tuesday": "00:00/16 07:00/19 10:00/16 10:00/16 17:00/19 23:00/16",
        "wednesday": "00:00/16 07:00/19 10:00/16 10:00/16 17:00/19 23:00/16"
    }

While according to this it should have a different format:

    "weekly_schedule_friday": "00:00/16 06:30/19 17:00/20 21:30/17 21:30/17 21:30/17",
    "weekly_schedule_monday": "00:00/16 06:30/19 17:00/20 21:30/17 21:30/17 21:30/17",
    "weekly_schedule_saturday": "00:00/16 06:30/19 17:00/20 21:30/17 21:30/17 21:30/17",
    "weekly_schedule_sunday": "00:00/16 06:30/19 17:00/20 21:30/17 21:30/17 21:30/17",
    "weekly_schedule_thursday": "00:00/16 06:30/19 17:00/20 21:30/17 21:30/17 21:30/17",
    "weekly_schedule_tuesday": "00:00/16 06:30/19 17:00/20 21:30/17 21:30/17 21:30/17",
    "weekly_schedule_wednesday": "00:00/16 06:30/19 17:00/20 21:30/17 21:30/17 21:30/17"

It might be that it would change after actually setting up a schedule, which I don't use.

[Sanidnl]

Happy new year all.

I don't know if I can ask here about a problem...?

I would to ask if some body can help me about a not compatible dinrail dimmer with power measuring.
A have connected it to HA and can turn on the wal the lights on but doesn't synchronized wit HA, also the power consumption is about 3000w. How can a make ik compatible with HA?
Prosuct I use is:
https://nordtronic.com/shop/din-dimmer-zigbee-1349p.html

A have also belo product and it words fine:
https://nordtronic.com/shop/box-dimmer-zigbee-712p.html

[PasekJ]

Hello New Year!
After updating Zigbee2MQTT from version 2.7.1-1 to 2.7.2-1, communication with the coordinator stops working, Logs report a communication error. My settings in configuration.yaml are
serial:
port: tcp://192.168.x.x:8888
adapter: zstack
My coordinator is Sonoff Zigbee Bridge Pro (CC2652)
Thank you for your work!

[AJFproduction]

Hello, I have a strange behaviour with Frient Electricity Meter Interface 2, P1 since 2.7.2 update.
The Energy - Sum of consumed energy reported value is wrong; seems max max value.

[HomeDriveLevo]

Hi, after updating to version 2.7.2-1, the "power-on behavior" entity disappears. When I roll back to the previous version, the entity reappears. I have two of these devices (1 gang switch module, model: TS0001_switch_module, manufacturer: Tuya), and both are experiencing the exact same issue.

[diegocruz-rgb]

Happy 2026!!!!

[iammalefic]

Hello everyone, and a happy new year.
After this update, Niko Double connectable switch,10A [552-721X2], Firmware ID 313-688-00 (20211012), L2 stoped sending any payload in decoupled mode.
L1 still works as before, i.e this is the payload after pressing the button:

{
    "action": "single_left",
    "action_reporting": null,
    "led_enable": true,
    "led_enable_l1": null,
    "led_enable_l2": null,
    "led_state": "OFF",
    "led_state_l1": null,
    "led_state_l2": null,
    "led_sync_mode_l1": "On",
    "led_sync_mode_l2": "On",
    "linkquality": 124,
    "operation_mode": "decoupled",
    "state_l1": "OFF",
    "state_l2": "OFF",
    "update": {
        "installed_version": 289079302,
        "latest_version": 289079302,
        "state": "idle"
    }
}

In control_relay mode, one of the switches does send the payload of L2 and the other one does not.
I tried factory reset and returning the switches to the system, but without a change. Maybe I should have removed them from Z2M first?
I have two of these and both worked fine with automations based on reported action in decoupled mode.
A small observation: in the device's settings in zigbee2mqtt, action reporting always reverts to "?". That goes for all Niko swithes and dimmers.

Hope this helps in any way.

Edit: I reverted to the previous version and all is fine again.