Replies: 35 comments 97 replies
-
|
I'd like to remove the |
Beta Was this translation helpful? Give feedback.
-
|
@mundschenk-at Actually, what I do not understand is how would you select such entity in a blueprint. I have made some blueprints (the community was really helpful) some months ago. The |
Beta Was this translation helpful? Give feedback.
-
|
@chris-1243 The HA |
Beta Was this translation helpful? Give feedback.
-
|
@mundschenk-at Ok.... Now I see why I am stuck... I wanted to anticipate this change. I did not see you PR. Many thanks for your time and answer. It will be a minor change |
Beta Was this translation helpful? Give feedback.
-
|
I had all legacy options I've filed a few new blueprints for devices such as https://community.home-assistant.io/t/aqara-wireless-switch-wxkg11lm-via-zigbee2mqtt-device-trigger/808126 - unfortunately, I don't know of any way to run upgrade paths in blueprints, so I think users will have to recreate automations (or edit the YAML) when upgrading. |
Beta Was this translation helpful? Give feedback.
-
|
You can edit the blueprints on the file level (e.g. with the |
Beta Was this translation helpful? Give feedback.
-
|
My suggestion is to remove |
Beta Was this translation helpful? Give feedback.
-
|
added! |
Beta Was this translation helpful? Give feedback.
-
|
I'd also like to remove the duplicate 
|
Beta Was this translation helpful? Give feedback.
-
|
Also added! |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
So what's the timeframe for 2.0.0 approximately? (I am asking if I should do a larger clean-up PR for Home Assistant discovery instead of adding Also, wouldn't it be easier if there was a |
Beta Was this translation helpful? Give feedback.
-
|
Lets aim before EOY |
Beta Was this translation helpful? Give feedback.
-
|
It would be great to add to dev console in UI writing and reading numeric (non-standard) cluster attributes. 
Maybe it's not for z2m but for the frontend repo. |
Beta Was this translation helpful? Give feedback.
-
|
How about implementing a tool to translate a valid 1.xx configuration to a valid 2.0 configuration? Possibly with some instructions for porting actually incompatible features, but only when present. The thing I liked about this project was its stability (only since the last 10 or so 1.xy releases). Why would you ruin your (until this decision) great reputation? Software can always be made to be backwards compatible and it's not like that's hard to accomplish (every design patterns book even explains how to do that). It's just not a "cool" thing. Software has utility when it does work and you don't need to track its development. Every second people need to care about you making things "better", is lost productivity. Why are you breaking APIs and existing configurations again (that would want to upgrade to version 2)? |
Beta Was this translation helpful? Give feedback.
-
|
Not every change can be done without breaking, some wrong decisions were made in the past which have to be corrected at some time. |
Beta Was this translation helpful? Give feedback.
-
|
It's literally not a constructive comment. You are just saying something is a fact, without proof. The only valid reason to some extent is that "You don't want to", since I have no rights. (Pretending to act as if you answered the question is just annoying. ) There's nothing to discuss anymore, though. If you had wanted to answer the question, you would have done so the first time. Thanks for the time of stability for as long as it lasted. |
Beta Was this translation helpful? Give feedback.
-
|
@hacscred What kind of hysterics? All breaking changes will be described in the migration guide, legacy parameters can be removed automatically without user intervention. Some small things will have to be fixed manually, but this is the first time in several years for this project. Breaking changes always happen during development to improve the code base and further improve the product itself. Even Home Assistant breaks something in every release (look at any release notes at the end). In the end, no one is stopping you from staying on 1.x.x and migate to a new version whenever it’s convenient for you. |
Beta Was this translation helpful? Give feedback.
-
|
@hacscred From GitHub history, I assume your are not a software developer yourself. That's alright, your concerns are valid nonetheless, and backwards compatibility is something most developers strife for, because it makes life easier for everyone, up to a point. But no, keeping backwards compatibility is not always "not like that's hard to accomplish", and it does come with a maintenance cost. As @Koenkk wrote, sometimes decisions prove to be unwise in retrospect, sometimes the environment (e.g. Home Assistant) has evolved since the original implementation and things have to change. In a lot of these cases, the original functionality has been deprecated for a long time, which means that there is an alternative, preferred way to do things and that notice has been given that the original functionality will be removed at some point in the future. So it's not like this completely out of the blue. As @Drafteed noted, you don't have to change immediately to the new version. Also the necessary changes to your configuration will likely not be as big as it might seem from the technical roadmap if you mainly use Z2M with Home Assistant and directly by MQTT. One point I'd like to add, regarding "I have no rights": You are not a customer. You don't pay developers (@Koenkk and other contributors) to cater to your specific requirements. So yes, you don't have the right to demand a certain outcome. |
Beta Was this translation helpful? Give feedback.
-
|
@mundschenk-at Everything you said is wrong and misguided. Please apologize. @Drafteed Do you ever say something that's not redundant? |
Beta Was this translation helpful? Give feedback.
-
|
I am in favor of breaking change for 2.0 and major updates. It is not always possible or desirable to keep old stuff. I have a question about the 1.x z2m.
Is there a policy for z2m ? |
Beta Was this translation helpful? Give feedback.
-
|
My idea is: frozen and not touched anymore (because of time reasons) |
Beta Was this translation helpful? Give feedback.
-
What are those supposed to be replaced by ? I read here that actions are replaced by event, but how would it work with devices like old Ikea remotes, as i don't see events implemented yet ? |
Beta Was this translation helpful? Give feedback.
-
|
You can use my guide in the HA community: |
Beta Was this translation helpful? Give feedback.
-
|
By device triggers: https://www.zigbee2mqtt.io/guide/usage/integrations/home_assistant.html#via-mqtt-device-trigger-recommended |
Beta Was this translation helpful? Give feedback.
-
|
Ok then i'm already ok, thanks. Since i doubted about that, i may not be the only one to do so, it would be good idea to mention the device trigger doc while talking about this "deprecation". |
Beta Was this translation helpful? Give feedback.
-
|
The wiki states that the Home Assistant event entity will be the standard and recommended way with 2.0.0 Is this correct? |
Beta Was this translation helpful? Give feedback.
-
|
Hello
I think device_id is less convincing/readable than entity_id. Isn't there such a use case? Regards |
Beta Was this translation helpful? Give feedback.
-
|
So with Z2M 2.0 , will it be true that I cannot enable permit join via MQTT, wait up to 5 mins for a device to join, interview and configure then disable permit join via MQTT ? |
Beta Was this translation helpful? Give feedback.
-
|
Too proscriptive for me. I wonder how many others will discover just how short 4 minutes is when you're running around a building trying to activate a sensor and check the result! |
Beta Was this translation helpful? Give feedback.
-
|
What's removed is the |
Beta Was this translation helpful? Give feedback.
-
|
One more question on detail, will 'permit join timeout' kill an existing interview/configure if in progress ? |
Beta Was this translation helpful? Give feedback.
-
|
Interview and configure are extra steps specific to Z2M that are not part of the ZigBee join, hence not affected by the permit join status. |
Beta Was this translation helpful? Give feedback.
-
Carry your phone with you as you travel around the building. Trigger the permit join and check the result from the z2m Frontend on the phone when you standing next to the sensor. |
Beta Was this translation helpful? Give feedback.
-
|
I've been enjoying Zigbee2MQTT for years now. Many thanks for maintaining such a great product so diligently. Hats off from me. |
Beta Was this translation helpful? Give feedback.
-
|
I look at the proposed changelist and everything is really promising @Koenkk, but one thing i want to put up for discussion, and that is the removal of I myself, and assume a lot of people use other automation platform, for example Node-RED. The HA-NR integration is greate, device triggers also added so basically this change should not be a prolem, right? Sadly, it is, generally as device triggers work, you cannot target multiple device with one selector, in the past I wrote a lot of common subflow/function that use the generic state triggers and filters entities by regex, because I use consistent naming for my entities, not really need to deploy 100s of device triggers just use, for example this regex: Can we at least shift the deprecation of this action/click entities because i assume that i not the only one that has such a use-case. |
Beta Was this translation helpful? Give feedback.
-
|
@mundschenk-at let's try to do at least 1.X release with the event support before releasing 2.X |
Beta Was this translation helpful? Give feedback.
-
|
It would be really nice, thank you. 🤲 |
Beta Was this translation helpful? Give feedback.
-
Yes, this would be a great idea. This would allow time to the community to see if there is any problem and anticipate the change👍 For sure, I would love to able to test already as some of my HA blueprints are a nightmare to change with a MQTT trigger without errors...🥴 |
Beta Was this translation helpful? Give feedback.
-
|
@chris-1243 We are still hashing out some details, but I've opened a documentation PR where you can see how it will work. |
Beta Was this translation helpful? Give feedback.
-
|
I had a look. Thanks for your effort. I hope you may provide a I will need to crash some automations to understand more precisely (some blueprint I made...🤫) |
Beta Was this translation helpful? Give feedback.
-
|
I may have missed this elsewhere, but I think it's worth coming up with a plan for the What if:
|
Beta Was this translation helpful? Give feedback.
-
|
This will also be a bad experience. First you will need to switch to Probably the best solution would be to display warnings (in logs, in release notes, etc.) about upcoming breaking changes when using legacy functionality, such as legacy sensors. Like in Home Assistant, which displays deprecated messages in logs for several months and generates a system issue. |
Beta Was this translation helpful? Give feedback.
-
|
I have been using Zigbee2mqtt for years. Many thanks and my respect for your great work. |
Beta Was this translation helpful? Give feedback.
-
|
You can already do that, just set a different |
Beta Was this translation helpful? Give feedback.
-
|
It would be good if some of the changes can be brought forward into v1 to enable people to migrate their configs off legacy sooner - e.g. introduce the change to update sensors alongside the current setup. |
Beta Was this translation helpful? Give feedback.
-
|
Have a look to this thread. It is expected👍 |
Beta Was this translation helpful? Give feedback.
-
|
This is probably the bottom of your list of priorities, but can we see some UI/UX improvements? thanks |
Beta Was this translation helpful? Give feedback.
-
|
Not for 2.0, the frontend is maintained in a separate project (not by me) |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I would like to add the settings provided in the "How to get prepared" section to my Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
The integration settings page is mostly only for We've added an automatic migration system for settings in 2.0.0 that will take care of swapping anything that needs to be and will write a log file for any settings that require your attention. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @Nerivec The link seems to be broken - nonetheless, what is the upgrade path you would recommend? My network is fairly recent, I think less than 3 years old. Cheers! |
Beta Was this translation helpful? Give feedback.
-
|
Might be this one? |
Beta Was this translation helpful? Give feedback.
-
|
Koenkk merged the changes in dev branch so the link got moved to the one above. I suggest you identify any possible feature in the first post here that you might be using on HA side, then see about using the newer "way". Once you've done that, or if you don't have anything like that, the rest of the migration should be pretty much just upgrading as usual once 2.0.0 is available. Then you can check the migration log mentioned in the docs page above, that Z2M will create for you, to make sure you didn't miss anything related to configuration. |
Beta Was this translation helpful? Give feedback.
-
|
Keep up the great work! I have added the mentioned code in the Configuration.Yaml. Invalid config device_options (Show logs) Do i need to ignore these for now or am i doing something wrong? |
Beta Was this translation helpful? Give feedback.
-
|
Please don’t put this in the HomeAssistant configuration.yaml, there is one for Z2M. |
Beta Was this translation helpful? Give feedback.
-
|
Are there an UI changes? i couldnt see any? |
Beta Was this translation helpful? Give feedback.
-
|
2.0.0 is mostly about cleaning up legacy features, that have been deprecated for a while, to free Z2M for future growth 😉
|
Beta Was this translation helpful? Give feedback.
-
|
My z2m 2.0 upgrade experience Docker install here with Sonoff Dongle E and latest 7.4.5 firmware using ember stack. I edited configuration.yaml with the legacy and device keypairs as instructed and spun up the container using the 1.42.0 latest-dev docker image (z2m 2.0). I have 24 devices with 8 Hue lights and 16 endpoints which include Philips, Lutron, Tuya and Aqara devices. All devices remained paired and functional but I eventually figured out I had to delete and recreate all my z2m groups (Hue lights). The groups were showing in z2m but they were not responding to their mqtt topics. Recreating the groups was a little flaky (I sometimes had to back out of the "groups" config page and come back to it for it to refresh) but I eventually recreated without too much trouble by noting the names and members, deleting them all, restarting the container and then recreating them and then restarting HA. They work now as before. Another issue I encountered was with the "warn" log level which apparently was substituted for the "warning" log level I had in effect. Z2m refused to boot with the "warn" log level specified (it threw an error saying "warn" was not a valid option). I changed it to "info" in the yaml and then booted ok. I then changed it back to the original "warning" (which is still a gui option) and it also booted and works as expected. All good now but the zombie groups issue had me scratching my head for a while. |
Beta Was this translation helpful? Give feedback.
-
|
This is not expected behaviors. Can you open an issue instead (with logs) to avoid crowding this thread with too many posts? |
Beta Was this translation helpful? Give feedback.
-
|
I switched to 1.42.0 Dev and all things started and runs well. But I don't find any hints regaridng using extensions. Same problem with logger.info
Sorry for my bad english. |
Beta Was this translation helpful? Give feedback.
-
|
Please see #25014 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for all the amazing work on this amazing software! Cleaning up always feels nice. I want to try out 2.0.0, so I let docker pull the latest-dev, but the frontend still shows 1.42.0-dev as Zigbee2MQTT version. Am I doing something wrong or is 1.42.0 actually 2.0.0 in disguise? EDIT |
Beta Was this translation helpful? Give feedback.
-
|
Indeed new versions are only applied at release time. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, got it. Thanks for confirming! |
Beta Was this translation helpful? Give feedback.
-
|
Super excited about a new release! =). Hit a couple of issues below - not sure if they're known, or I missed them somewhere. Main issue currently is that it doesn't seem to want to pair with a IKEA TRADFRI LED Driver. I've just created a fresh zigbee2mqtt 2.0 (dev) install via Docker, using a TCP-based Zigbee gateway (Zigstar UZG-01). Here is my Docker Compose file ( And here is the When I first tried to start it up the containers - the zigbee2mqtt container has an error about finding the TCP adapter - it seems I needed to explicitly set Anyhow, I fixed that by explictly setting However, the zigbee2mqtt container then seemed to restart a few times with that error, and it cleared on its own without any user intervention. Curious what that means? I then had a small issue with the MQTT server (set to Finally, zigbee2mqtt was up, and I could access the frontend 😀. I then tried to pair a IKEA Tradfri LED Driver 20W - however, this seemed to fail with it being "unsupported":
Here are the zigbee2mqtt container logs from around that time: |
Beta Was this translation helpful? Give feedback.
-
|
You set advanced:
pan_id: GENERATE
ext_pan_id: GENERATE
network_key: GENERATE
channel: 25 # pick one, preferably 11, 15, 20, or 25, different from the other network |
Beta Was this translation helpful? Give feedback.
-
|
Aha - whoops, I had only set I don't actually have another currently running Zigbee network (at least I thought I didn't) - the UZG-01 is one I was using previously as a coordinator, with a different host running Zigbee2MQTT. I'd wiped the UZG-01 (or thought I had), and also the zigbee2mqtt host, and hence thought I was creating a new network. However, if end devices (e.g. IKEA Tradfri LED river) were previously part of a Zigbee network - would that cause issues, and mean I needed to force regenerate a new pan_id? Anyhow, I just set all three ( LogsI then restarted the container, and got some error about failing to start the bridge: LogsAnyhow, I restarted the container again, and this time it worked =), and I was able to successfully pair the IKEA LED Driver: Logs |
Beta Was this translation helpful? Give feedback.
-
Are you able to reproduce this? If yes, could you provide the debug logs? See this on how to enable debug logging. |
Beta Was this translation helpful? Give feedback.
-
|
Aha - ok - I've set up debug logging now: After enabling debug logging, I then tried to add a IKEA Styrbar remote to zigbee2mqtt, which had previously failed to join with:
However, I also tried to check for an OTA on the IKEA Styrbar, which failed with an error - and there are hopefully useful debug log messages there. LogsAccording to the latest IKEA release notes, the Styrbar is meant to have a new version 1.27.2 (released 8th August 2024) - but zigbee2mqtt doesn't seem to push this? I'll update if I manage to get any other debug logs from other devices to fail to pair. |
Beta Was this translation helpful? Give feedback.
-
|
Actually, the error Koenkk asked about was the second one (a very weird one): Which apparently happened when you started the container? But then didn't happen again? |
Beta Was this translation helpful? Give feedback.
-
|
I just update the edge version to 2.0.0.
or it seems always following the reporting of some devices
the reporting seems to be every minute while before was every 2 hours. Beside this, everything works as expected. |
Beta Was this translation helpful? Give feedback.
-
|
Could you provide the debug log of this? See this on how to enable debug logging. |
Beta Was this translation helpful? Give feedback.
-
|
i guess you are talking about the EventBus error. |
Beta Was this translation helpful? Give feedback.
-
|
Same problem here, about the EventBus error. |
Beta Was this translation helpful? Give feedback.
-
|
In my case, I'm using the DiyRuz Geiger, that publishes Cyrillic (?) characters in the sensor type, maybe that's the issue: |
Beta Was this translation helpful? Give feedback.
-
|
Let's continue in #25133 |
Beta Was this translation helpful? Give feedback.
-
|
In the “How to get prepared” section above it is mentioned to add code to configuration.yaml, since this has burned me before can you clarify which configuration.yaml is to be modified? I’m sure it’s obvious to many but since the same file name is used in many places a path would be very useful to make sure mistakes are not made. |
Beta Was this translation helpful? Give feedback.
-
|
As we are talking about Z2M (and not HomeAssistant etc) it’s about the z2m configuration.yaml. |
Beta Was this translation helpful? Give feedback.
-
|
And there is the problem, what’s obvious to you isn’t to people without your knowledge. I got burned the first time because I only knew of the one configuration.yaml file, had no idea there was another one in another directory. Clarity up front instead of assumptions of knowledge reduce frustration and mistakes. I and my crew wrote many instructions for others to follow and I made sure that we all did not shorthand the documentation because not all who followed had our knowledge. |
Beta Was this translation helpful? Give feedback.
-
|
I mean, that’s some kind of basic knowledge how GitHub works. We are in the z2m repo, talking about z2m patches. There is a different repo for the z2m HA integration. From my personal point of view, these kind of basic knowledge is something ppl should be aware of when they are seeking for support. Don’t get me wrong, it’s not that ppl are not allowed to ask. But this question was asked multiple times and I wonder how ppl found the way into this repo when they use the HA addon only. |
Beta Was this translation helpful? Give feedback.
-
|
I am not a developer, I am a user of home assistant, I installed the Zigbe2mqtt addon by watching a youtube video showing me how. I was guide to github by clicking on the link on the update popup in HA "1.42.0". On the github page there was a link to "here" which said I could find breaking changes. Then I was told to make sure to have the following in your configuration.yaml. Where in your basic knowledge of github does it become obvious to casual users of HA that there are multiple files named configuration.yaml and you should know which we are telling you to modify. I get it, in my field I had knowledge of things that were obvious to me but when I wrote a document telling someone how to impement or update an application I could not assume they would know what was obvious to me. Especially in the case that my lack of clarity got me a support call at 2 am. The simple statement that the question has been asked multiple times should make it clear that a simple path in the original document would have clarified the issue from the start. |
Beta Was this translation helpful? Give feedback.
-
|
First off thanks to whomever for adding the info showing which configuration.yaml to modify in the original discussion message. Second for others who may struggle with the impact of these breaking changes I found that none of my Node-Red projects worked any more if they were successfully reading a zigbee2mqtt "sensor._action" or "sensor._click" enitity created previously with a "trigger: state" node. This is documented above, however the "sensor.*_event" entity is as yet unusable (so I assume from what I am reading) therefore I spent a good part of a day finding a workaround and thought I would share it. Another node exists called "mqtt in", this can read the mqtt topic directly and outputs a message that contains all the data transmitted from the device. From here I was able to modify the switch nodes that recieved the previous message with the "message.payload.action" property to get the same information I had before for my use cases. In fact it seems to now be more stable and faster than it was before, that could easily be my imagination though. If any of the more knowlegable sees a flaw in what I have posted or if anyone needs more information on this please reply. PS. many of my Aquara buttons had to be reconnected after the changes and updates. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, All post talk about HA integration but nothing for another domotic soft. I'm on Jeedom via a plugin ( ZigbeeLinker) What could be broken with the v2.0 ? |
Beta Was this translation helpful? Give feedback.
-
|
HA has an extension built into Z2M which is getting some changes. |
Beta Was this translation helpful? Give feedback.
-
|
Permanent log flooding screenshot
|
Beta Was this translation helpful? Give feedback.
-
|
This is being tracked here #25133 |
Beta Was this translation helpful? Give feedback.
-
|
The problem I'm seeing with activated experimental events is that when Z2M restarts, the events are triggered again. For example, I press the button to turn the lights on/off (event: single) and when Z2M restarts (e.g., changing the configuration), etc., the action is triggered again, i.e. the light turns on again. The solution is probably to not send events at startup. |
Beta Was this translation helpful? Give feedback.
-
for some reason it is reset in Z2M, but it is still active in HA and in the MQTT topic
|
Beta Was this translation helpful? Give feedback.
-
|
It might be just the HA state engine behavior then. You almost always have to treat the transition from |
Beta Was this translation helpful? Give feedback.
-
|
At this point, the point is that the event state will not change in any way (i.e., the change cannot be captured in any way), it will simply be called again, as if I had physically pressed the button. |
Beta Was this translation helpful? Give feedback.
-
|
So the state does not actually change (i.e. it's the same timestamp as before becoming |
Beta Was this translation helpful? Give feedback.
-
|
simply do not trigger the automation if the from or to state are unknown/unavailable, that solved for mw; i suggest you to modify you automation as follow: |
Beta Was this translation helpful? Give feedback.
-
|
Since last dev (1.42.0-dev commit: 1dde41f7eafe2ecfc55fa1d10a7963c211294043), it seems the Z2M debug log HA log This does not happen in standard 1.42.0 |
Beta Was this translation helpful? Give feedback.
-
|
Could you make a new issue containing a debug log where you set it in color temp mode -> xy mode -> color temp mode. |
Beta Was this translation helpful? Give feedback.
-
|
For the new issue, no problem. I am just stuck on how to set the |
Beta Was this translation helpful? Give feedback.
-
|
You cannot set the |
Beta Was this translation helpful? Give feedback.
-
|
Issue opened... #25193 |
Beta Was this translation helpful? Give feedback.
-
|
Since the legacy action sensor covers some use cases which are not covered by the MQTT device trigger (e.g. #25003) and the event entities are still experimental, it has been decided to not remove the legacy action sensor in 2.0.0. It will be added back in #25192 |
Beta Was this translation helpful? Give feedback.
-
|
As an FYI, I was having some issues with my network and not sure what was causing it, so I changed my docker from "latest-dev" to "latest". When the December 1 "latest" release started up, it started removing all my devices from the groups and when it was done my groups were empty. I believe this is from the 2.0.0 way of groups versus how it was before. I think we need to make sure people are very aware to not rollback to a previous version after the 2.0.0 migration. |
Beta Was this translation helpful? Give feedback.
and others
-
This discussion contains a list of breaking changes for Zigbee2MQTT 2.0.0.
Tip
Most of the breaking changes are about removing legacy features that have been deprecated for years (replaced & improved since), and as such, automatically disabled for newer networks.
How to get prepared?
In order to get the minimal amount of breaking changes when upgrading from 1.x.x to 2.0.0, make sure you have the following in your Zigbee2MQTT
configuration.yaml:Important
Check you current
configuration.yaml, it is likely that some of these values are already present, and set tofalse, if your network is recent enough (past few years). The breaking changes marked with: Only breaking when legacy is enabled can be ignored if your configuration already has these values set tofalse.Breaking changes
General
USB adapter discovery error (No valid USB adapter found), see Z2M 2.0.0: `USB adapter discovery error (No valid USB adapter found)` #24364 how to fix this.Bare-metal installations (no Docker/Home Assistant add-on)
configuration.yamlfrom repo, this will result in the following error when updating:mv data/configuration.yaml data/configuration.yaml.bak ./update.sh # (update as you usually do) mv data/configuration.yaml.bak data/configuration.yamlpnpmis now used instead ofnpm, the installation instructions andupdate.shscript has been updated accordingly. For existing installations you need to executenpm install -g pnpmbefore updating.Home Assistant
update_stateandupdate_availableentities have been removed (succeeded by theupdateentities).homeassistantproperty, useexposesinstead.sensor/selectforselect/number/buttonentities, the full list of removed entities per model can be found here.homeassistant.legacy_triggerssetting). This means allsensor.*_clickentities are removed. Use the MQTT device trigger instead.sensor.*_actionentities). It's recommended to use the MQTT device trigger instead. In case you really need the action sensors, add the following to yourconfiguration.yaml.homeassistant.legacy_entity_attributessetting) has been removed. This means that entities discovered by Zigbee2MQTT will no longer have entity attributes (Home Assistant entity attributes are accessed via e.g.states.binary_sensor.my_sensor.attributes).Device specific
child_lockon/off values have been changed fromtrue/falsetoLOCK/UNLOCK.illuminance_luxtoilluminance, this breaks in two ways:illuminance_luxhas been removed and the value ofilluminancechanges. This affects the following devices: 83633205, MOSZB-140, MOSZB-153, EFEKTA_iAQ3, EFEKTA_PWS_Max, EFEKTA_PWS_MaxPro, EFEKTA_eON29wz, EFEKTA_eFlower_Pro, EFEKTA_iAQ, E2134, POK004, POK011, ROB_200-070-0, HK-SENSOR-4IN1-A, AU-A1ZBPIRS, RADON TriTech ZB, TS0601_illuminance_temperature_humidity_sensor_1, TS0202_3, S-LUX-ZB, TS0222_light, THE01860A, TS0222, LCZ030, MIR-HE200-TY, XFY-CGQ-ZIGB, TS0601_smart_human_presence_sensor_1, Y1_IN, ZY-M100-S_1, ZY-M100-S_2, WZ-M100, ZG-205ZL, ZG-204ZM, YXZBRB58, ZY-M100-24G, ZY-M100-24GV2, ZY-M100-24GV3, MTG075-ZB-RL, RT_ZCZ03Z, ZY-M100-S_3, ZG-205Z, 8750001213, HSE2927E, ZB003-X, 07502L, JS-MC-SENSOR-ZB, KK-ES-J01W, KMPCIL_RES005, RTCGQ11LM, RTCGQ12LM, b-parasite, 7A-SS-ZABC-H0, 5AA-SS-ZA-H0, RTCGQ14LM, RTCGQ15LM, ZNCLBL01LM, GZCGQ01LM, GZCGQ11LM, 07047L, 9290012607, 9290019758, 9290030675, 9290030674, 545D6306, CCT595011, ZSS-ZK-THL, 4512770, TERNCY-PP01, MBD-S, CTM_MBD_Dim, 3RSNL02043Z, WB-MSW-ZIGBEE v.3, MS100, USM-300ZB, PIR313-E.switchexpose andactionvalues have been changed, see the device docs for the new values.device_options.legacy. These breaking changes below can be ignored if you havedevice_options.legacy: falsein yourconfiguration.yaml:button_*properties.duration,rate,brightnessandtransition.duration.step_size,transition_timeand the following actions:play_pause,skip_forward,skip_backward,rotate_*.rotate_*actions.button_*properties and removedsingleaction.singleaction.left,rightandbothaction (including the*_longand*_doubleactions).to_side,from_side,angle.angle.repeat,useranddata.duration.step_size,transition_timeandskip_*actions.actionvalues have been changed, see the device docs for the new values.keypad_lockoutvalue changedsetpoint_change_source,setpoint_change_source_timestamp,remote_sensingandcontrol_sequence_of_operationvalues are now mapped values (string) instead of a number.operation,setpoint_change_source,setpoint_change_source_timestamp,remote_sensingandcontrol_sequence_of_operationvalues are now mapped values (string) instead of a number.directionandnumberweekly_schedulepayload.action, removeddurationandcounter.click.External converters and extensions
external_converterssetting is no longer used. Instead all external converters insidedata/external_convertersdirectory are now automatically loaded. Make sure to move all your external converters to this directory.data/external_extensionsinstead ofdata/extension. Make sure to rename yourdata/extensiondirectory (if present) todata/external_extensions.MQTT api
update_availableproperty from the device state has been removed (useupdate.stateinstead).updateAvailabletoupdate_availableinzigbee2mqtt/bridge/response/device/ota_update/check.zigbee2mqtt/bridge/request/device/bind,zigbee2mqtt/bridge/request/group/members/add,zigbee2mqtt/bridge/request/group/members/removeandbridge/request/device/configure_reporting, the endpoint has been moved to theendpointproperty and cannot be set via thedevice/fromproperty anymore.zigbee2mqtt/bridge/request/configMQTT API, this includes the following MQTT topics:zigbee2mqtt/bridge/request/config/last_seenzigbee2mqtt/bridge/request/config/elapsedzigbee2mqtt/bridge/request/config/log_levelzigbee2mqtt/bridge/request/config/homeassistantdatapayload in the response is now always empty when there is anerror, this affectszigbee2mqtt/bridge/response/device/configureandzigbee2mqtt/bridge/response/device/ota_update/*.permit_join_timeouthas been removed fromzigbee2mqtt/bridge/info, it has been replaced bypermit_join_endwhich represents the Unix timestamp when permit joining will end.advanced.legacy_apisetting), this includes the following MQTT topics:zigbee2mqtt/bridge/logzigbee2mqtt/bridge/(bind|unbind)zigbee2mqtt/bridge/group/*zigbee2mqtt/bridge/networkmap/*zigbee2mqtt/bridge/ota_updatezigbee2mqtt/bridge/device/DEVICE_FRIENDLY_NAME/get_group_membershipzigbee2mqtt/bridge/config/*zigbee2mqtt/bridge/configureRemoved features and settings
Important
The new configuration update system will automatically (re)move deprecated settings the first time you start Z2M after updating to 2.0.0. Make sure to check the
data/migration-1.x.x-to-2.0.0.logafter startup. See the docs for more info.advanced.reportsetting).advanced.soft_reset_timeoutsetting).devices.IEEE_ADDR.options.retrieve_statesetting).availability_timeout,availability_blocklist,availability_passlist,availability_blacklist,availability_whitelistandadvanced.legacy_availability_payload(see availability docs for the new settings).advanced.legacy_availability_payload,zigbee2mqtt/bridge/statewill now always be a JSON object ({"state":"online"}or{"state":"offline"}).permit_joinsetting has been removed, use the frontend or MQTT to permit joining.configuration.yaml(groups.devicessetting). This will not impact current group members; however, you will no longer be able to add or remove devices from a group through theconfiguration.yaml.ota.ikea_ota_use_test_urloption has been removed.advanced.homeassistant_discovery_topicis now inhomeassistant.discovery_topicadvanced.homeassistant_status_topicis now inhomeassistant.status_topicadvanced.baudrateis now inserial.baudrateadvanced.rtsctsis now inserial.rtsctsexperimental.transmit_poweris now inadvanced.transmit_powerexperimental.outputis now inadvanced.outputwhitelistis now inpasslistbanis now inblocklistexperimentalsection no longer existsPull requests
retrieve_statezigbee2mqtt.io#3075readAfterWriteTimezigbee-herdsman-converters#8089configuration.yamlzigbee2mqtt.io#3104configuration.yaml#24338illuminance_luxzigbee-herdsman-converters#8304maximum_packet_sizeMQTT setting zigbee2mqtt.io#3228datain response is always empty onerror#24971sensor/selectforselect/number/buttonentities #25026permit_join_timeout#25082Beta Was this translation helpful? Give feedback.
All reactions