Replies: 182 comments 633 replies
-
|
I'd like to remove the |
Beta Was this translation helpful? Give feedback.
-
|
@D3SL We understand you are frustrated, but replying to every other comment in this thread with the same boilerplate text does not help anyone in the slightest. Please re-enable the legacy action sensors by adding |
Beta Was this translation helpful? Give feedback.
-
I've only replied once in this thread. There are also multiple other threads in parallel to this one where people are separately discussing the same issue, a testament to how severe and widespread of an issue this is. Keep in mind those of us who are already posting here are not only the early updaters but the most technical ones as well, and we're finding ourselves blindsided and crippled by this. A large plurality if not outright majority of Z2M users likely come from the home assistant addon and are not developers with github accounts like those of us posting here are. How do you think this is going for them? As I've said in separate threads: What concerns me more than the way this was handled is the way the fallout is being handled. The outright denigration and scorn being heaped on people who were already technical enough to find their way here for help and answers is deeply concerning, and very reminiscent of the abuse that drove the History Explorer Card developer out of the HA community entirely. It's a very disturbing trend in the overall HA ecosystem. |
Beta Was this translation helpful? Give feedback.
-
|
I meant the whole discussion topic. Replying with the some text does not help. This is an open-source project and most of the workload falls onto the shoulders of a single person, who still has a day job. Literally filling his inbox with walls of angry text does not help at all in this situation. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to chime in at my own peril. First: Thanks for all your hard work and dedication. I can only imagine the countless iterations on the backend, the long hours, the unthanked "overtime". Thank you for being willing to do all that, and please know there a huge number of people who will never sign up for github just to say thanks, but would likely mean it quite sincerely if they had a path to show their appreciation Second: I do recognize my feelings in @D3SL's comments overall, feels like maybe we got a beta through no malicious intent (you're in good company, HACS and Nabu each had a very rough start to the year, all will continue to bigger and better). That said, I was able to rebuild to a good save point, everything for me clearly broken on version 2+, but what I've not see stated clearly: what even are features and benefits? Of late, new release notes seem to simply reference the new version number (eg notes for 2.x, congratulations, no upgrades to 2x}. As one of the ignorant horde, I've been updating because newer = better. I'm not jumping ship here by any stretch, but it was eye opening enough to not blindly update anymore, this was definitely not a fun weekend for many. Rough, but not insurmountable. Took me years to justify smart home functions to family, not giving up now :) Third: I recognize just how hard it can be to look back to when you were mastering any subject, and I do 100% believe you all have expert level skills and focus, but maybe no longer a filter of what's a deepcut vs truly obvious (eg some recent support says to simply update "configuration.yaml" without clarifying which one, guess where I and many others went first... now assume you're wrong, now assume researching more only to find people still fighting abouts tabs vs spaces, or camelCase or whatever) This third line is not a criticism, simply an observation because I feel I see a thread of people's feelings getting hurt "I didn't mean anything by commenting 'simply," without defining simple to whom. Everything is simple with explicit instructions and a matching skillset, miss either of those requirements and the sky is the limit for frustration I do presume a lot here, but I have always pictured this project being open and welcoming to users of all skill levels. That said, I am at a point I'd love to offer what limited help I can, whether that's near release beta testing (I can at least let you know if I broke my own system with lack of knowledge while at the same time protecting myself with a backup [as a human I sometimes don't wait the 4 minutes to make a backup, especially if I really trust the source, I know, stupid but human])) or somehow helping with communications Fourth: If you're newer to HA/Z2M/any of it and reading this: things breaking is normal, you'll find that they almost always get fixed, and in the meantime backups are key, I personally think still worth moving forward with whatever brought you here, there's a lot to gain, but sadly no one can ever promise no bad days, no matter how skilled Fifth: If in doubt, please re-read First thought Update: Thanks @mundschenk-at for quick response and tips. Just like with firmware, maybe I don't update if not broken and no other compelling reason |
Beta Was this translation helpful? Give feedback.
-
|
@j-and-am There is no distinct beta version per se, but @Koenkk does monthly releases, so normally the changes are not as big as with 2.0.0. If you are using the HA add-on, you can switch to the Personally, I am on a version of 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.
-
|
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 a developer and a data analyst. I was completely blindsided by this. Nothing in the changelogs of the home assistant add-on adequately made it clear that literally every single automation I have with zigbee buttons and switches was going to get bricked. If I were to implement a change like this in an R package the standard would be to actively and even intrusively warn the user every time they used something planned for deprecation.
Home Assistant has indeed evolved greatly. It's now more user friendly than ever and is increasingly not a niche tool solely for highly technical hobbyists.
I had many automations tied to zigbee buttons that were trivial to set up with And even that took me a while to figure out because all the mentions of "mqtt" had me going to the "device" entry for these buttons in the MQTT integration... where there's nothing for the action. At all. I program data pipelines in python all day for a living and I spent an hour confused and am now balking at the expected fix. I'm willing to bet a large plurality if not outright majority of users are not nearly as technical as we are and came through the home assistant add-on. All they know is that every button they have is now a paperweight and there's no comprehensive way to fix it.
Nobody is demanding anything. They're simply saying that bricking people's entire houses without remotely adequate warning and no option to replace a trivial call to And as a developer whose published packages people depend on at my day job I agree. I'm rolling back to <2.0 until I can find a replacement. |
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.
-
|
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.
-
Using device IDs carries some distinct disadvantages when creating a network of automations, as every change of hardware now has to be followed up by a change to a potentially large number of automations. In my setup, I have been using semantic entity names like ‘.[]’ e.g. ‘fan.lounge_ceiling’ or ‘light.kitchen_counter’. These are often addressed from several automations and scripts. Using device IDs breaks this. (And i have strong feelings about that.) @devs, this project has been and is outstanding. And this change - while technologically warranted, I’m sure - needs some work. Home acceptance factors around a great part of the user base have dropped. And who is this project for, without our families having functioning lights? (Rhetorical question, I know of cool, non-home projects where it’s being used) |
Beta Was this translation helpful? Give feedback.
-
|
I couldn't agree more, |
Beta Was this translation helpful? Give feedback.
-
|
I also agree, using |
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.
-
|
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.
-
Great idea - for this you only need to allow phones (which belong into an unprivileged network) to access the otherwise tightly fenced automation vlan. why not just put all crap into a flat network while you're at it... Making those 254seconds the default would have been fine and a sensible decision - flat out preventing any other timeout and breaking permit_join for many people that have an infrastructure that spans over larger areas (and hence multiple z2m instances and zigbee clusters) is just ignorant. We run zigbee networks for various automation tasks in 4 buildings on 3 different sites. In the main site alone it can easily take me 10 minutes to get from my desk to some places in the other building to then install and start pairing a device. The other sites are several kms away and I can't always rely on reaching someone there just in time, so usually I send new devices there with instructions where & how to place/install and how to start pairing; having permit_join active until someone there finds the time to perform the task and the devices show up via mqtt. For now I reverted all related commits that broke permit_join in a forked repository, but I really hope (expect) this will be reverted upstram or at least refined so one can set (much higher) timeouts... |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like you should be running some commercial software. |
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.
-
|
I'd like to suggest an improvement to this post based on an issue I ran into. The post has this note:
Then later it has a section:
I had ignored that section since my config had |
Beta Was this translation helpful? Give feedback.
-
|
Why do I have to use device_id instead of a human-readable mnemonic name in the trigger associated with the button, as it was before?This approach makes debugging and replacing hardware more difficult. |
Beta Was this translation helpful? Give feedback.
-
|
Hello to everybody. What's wrong?? Thanks in advance. |
Beta Was this translation helpful? Give feedback.
-
|
indeed wrong path. |
Beta Was this translation helpful? Give feedback.
-
|
same erro here, so it just needs to create a external_converters directory within zigbee2mqtt directory and place the JS file there? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot! Now it's working!!! |
Beta Was this translation helpful? Give feedback.
-
|
So I finally got some time to revisit this update and after going through everything with a fine toothcomb I seem to be up and running with V2.0 I have some clarity needed about the legacy actions however I use Home Assistant (with NodeRed for my automations) Before I upgraded I checked a number of my flows in NodeRed and realised that I do use the legacy action, so I included However, given this will be retired eventually I want to move away from it - the problem is, the devices I use it with appear to have no other options I can use! The primary ones are Xiaomi Buttons and as you can see, if I were not to have action I wouldn't have anything I could utilise in Node Red or Home Assistant... So I'm really confused - how do I safely remove the legacy action, while still being able to use this device?! |
Beta Was this translation helpful? Give feedback.
-
|
Personally I'd suggest looking into the benefits of using mqtt. It's a different approach than to depend on the creation of entities but it's also really flexible and allows to create extremely dynamic automations. I've written about it in a neighbour discussion: The downside of this: You have to rename the friendly names of devices you want to use this way - and therefore also have to change their implementation inside Home Assistant. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reply here but there are a number of steps/questions that opens up for me...
Overall, just very confused - thankfully the legacy is working but I just want to continue with non-legacy using devices as they were before |
Beta Was this translation helpful? Give feedback.
-
|
No problem, I'm just showing how I prefer it personally ;-) To 1. Listening for zigbee2mqtt-events is easy: Just use a
To 2. yes then it's as simple as listening for the zigbee-events and just connecting a switch-node to it that simply reacts to the events found out by (1). To 3 & 4: Listening for mqtt events does not influence the state of the zigbee devices in the HA dashboard. It's just a "more basic but also more flexible" way of creating automations. As the author of z2m states, the legacy flag won't be removed that early, so it's probably safe to use it for a long time. The alternative is to use the new action events but personally I would wait with that until the dust of the 2.0 update has settled and a real successor for the actions is found ;-) |
Beta Was this translation helpful? Give feedback.
-
|
I have just upgraded to v2.0.0 and my experience in Docker hasn't been too smooth. I configure Z2M via environment variables not sure where I am going wrong, or if this is a bug but, old (and therefore invalid) configuration options linger in the configuration.yaml file even though the associated environment variable has been removed. Example: Also, none of the configuration options in the O/P seem to work via the environment variable approach. Here is my new .env file: vs my configuration.yaml: homeassistant: true
mqtt:
base_topic: zigbee2mqtt
server: mqtt://emqx:1883
user: Zigbee2MQTT
password: SuperSecretPassword
serial:
port: >-
/dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_f8b96b29c712ec11902e23c7bd930c07-if00-port0
advanced:
network_key:
- 202
- 112
- 238
- 152
- 21
- 43
- 250
- 248
- 37
- 158
- 142
- 150
- 143
- 221
- 214
- 86
pan_id: 64298
ext_pan_id:
- 249
- 134
- 182
- 114
- 23
- 189
- 108
- 247
frontend:
enabled: true
port: 8099
url: http://192.168.1.70:8099
device_options: {}
version: 4As it stands, I have a working (roughly) version of Z2M, but I have had to add the configuration options manually |
Beta Was this translation helpful? Give feedback.
-
|
Another rather annoying problem: That means:
This caused a lot of manual work to fix everything. |
Beta Was this translation helpful? Give feedback.
-
|
I had this problem for my two Xiaomi Mi Light sensors where the light entity was reset to original. Everything else looks to have remained as I had configured it... |
Beta Was this translation helpful? Give feedback.
-
|
may a hint here as im prolly missing something here as all my HA devices are non functional at all after updating so, i updated z2m to v2, adjusted the yaml configuration like this (turned off legacy)
docker up and running and on z2m webui all looking ok, also sensors and switches are working
but on HA side ... all devices are "off" and "greyed" out like non existent ...
restarted mosquitto, checked the HA settings in terms of Birth message topic, looking all ok ... so i assume there must be something else todo which i may miss from the 1st topic message here, may in HA, may in mosquitto, .. ? when i enable legacy, all devices are immediately here and working in HA, but as legacy will be EOL someday i thought lets do the switch now ... and dont wait until day X ;) for any tips, thanks ahead |
Beta Was this translation helpful? Give feedback.
-
that was done already like posted in my question ... thanks again
in terms this was meant ...
|
Beta Was this translation helpful? Give feedback.
-
|
so may the general question ... besides what i ve done to switch to common mode instead legacy, there shouldnt be any other master things todo ... like editing mosquitto in some way, like complete reset HA ... like ... cause when i read up there it should ve been easy to switch, may some actors or blueprints would need some changes but generally it should "just work usually" ... correct then ? if so ... then i would be out of ideas for now ;) thanks again for taking time to give advices |
Beta Was this translation helpful? Give feedback.
-
|
I remember before 2.0.0 there was an info regarding some legacy options and homeassistant. Sorry, I read this 2 months ago and while turning off one of those options, you had to completely restart HA. I started my migration on 1.42.0 and turned off all HA legacy options as requested. Both Z2M and HA were restarted and everything went fine...except the automations based on the legacy_action_sensor which was to be expected and some devices attributes. From 1.42.0 to 2.0.0 no problem at all nor any particular issues. Z2M did the migration as expected. I do run everything on Docker (HA, Z2M, mosquitto). For me, it was a stop, remove and start the containers |
Beta Was this translation helpful? Give feedback.
-
here too, all in dockers, i did now another run like suggested with full restarts (actually i did remove, install) of mosquitto and HA from the mosquitto log i see both are connected. thats the z2mqtt docker thats HA result is sadly the same, sample switches ... all zigbee's are greyed out (working ones are wifi) sample device setting page from a zigbee power plug ... so for now i will revert to legacy again as im out of ideas ... but then it seems i didnt miss any important stuff when i understand your message, it should work but in my setup it actually does not, whatever i may have different wise ... thanks again anyway for the infos, was worth another try ;) |
Beta Was this translation helpful? Give feedback.
-
thanks for pushing, i figured it now ... and yes, simple ... when i just change the config like described none device worked as expected, but digging deeper in HA, HA tells mosquitto doesnt provide this device anymore ... so checking webui's etc ... i see this box wasnt ticked
even the config yaml says ...
so, ticking the box also in the z2m webui ... it works now as described ... thanks for pushing which made me look another time deeper ;) |
Beta Was this translation helpful? Give feedback.
-
|
i was waiting a few weeks for the upgrade to 2.0.0 after the fail with v1.42.0-1 that removed all of my devices in a minor release, just to find out that the section labeled as "Only breaking when legacy is enabled" actually works in the completely opposite way, it's a breaking change only when the legacy mode is turned off, so by default it creates a breaking change why "this will screw up all your zigbee buttons" isn't the huge bold red header on top of the release notes, but instead is just buried deep intro some breaking changes discussion i know that this isn't a product we pay for, and if we don't like how it works we can just stop using it, instead of yapping there, but it's not about the software itself, it's about simply informing people about important stuff, instead we get "Remove legacy" and a link to a PR that simply list what was removed, and a question about what does this even mean left without any answer while this most likely it's enough for people that are contributing to the codebase, probably 99.9999999999% of people using this code aren't contributing and never will be, because we just want to turn on and off light in our houses while laying on the couch update: i'm going back to 1.x, it breaks more stuff than just buttons, in my case the climate related stuff, so home heating doesn't work anymore, it's too cold to spend time on debuging that |
Beta Was this translation helpful? Give feedback.
-
|
Just like you I've recently updateg z2m from v1.42.0-1 version. Before that I carefully read all changes and comments from users and the only problem with my 40+ devices including buttons, cube etc. was changed name for lumminace sensors. |
Beta Was this translation helpful? Give feedback.
-
|
To be fair, MQTT device triggers have been the recommended option for more that 3 years now |
Beta Was this translation helpful? Give feedback.
-
|
oh yeah, something buried down in the add-on docs definitely should be more important than the thing the whole home assistant is built around, the entities |
Beta Was this translation helpful? Give feedback.
-
|
Honestly, I think you got it all backwards. The "The breaking changes marked with: Only breaking when legacy is enabled can be ignored if your configuration already has these values set to false." remark is correct. Only if you were using legacy features will you be impacted. That's what it means. To avoid the impact, the obvious thing to do (but maybe that should made more explicit), is to work on getting rid of all uses of legacy features in your 1.4 setup. Only after that is all working, without relying on legacy features, then upgrade to v2, which has dropped support for many of those legacy features. |
Beta Was this translation helpful? Give feedback.
-
|
@palves except I wasn't using legacy features, I was using default features, available freely in 1.x without any flags or custom configurations, that in 2.x became marked as "legacy" while what you are trying to imply, is like I was purposely using legacy features in 1.x also the "release notes" are not explaining in any way what suggested pre-upgrade |
Beta Was this translation helpful? Give feedback.
-
|
Commit 60c37c1 causes problems with Home Assistant < 2024.8: Probably worth mentioning minimum required Home Assistant version. |
Beta Was this translation helpful? Give feedback.
-
|
The minimum version (min 2024.9) is mentionned in the release notes |
Beta Was this translation helpful? Give feedback.
-
|
Looks like I totally missed that by coming straight here. Thanks! Wouldn't hurt if it was in this post as well. |
Beta Was this translation helpful? Give feedback.
-
|
With all the restarting and pulling of containers in Portainer, I somehow managed to change the IP address of my Mosquito, so double check that! Here's my working |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I'm a bit unsure of this. I was going to do the upgrade but then read the bit about breaking changes Do you mean literally the configuration.yaml file or the configuration in the Zigbee2MQTT add-on section which has 3 parts filled in [ie socat, mqtt and serial]? I originally just put that block in the configuration.yaml file but when I ran the Check Configuration it came back with warnings I'm running on Generic x86-64 and have a flashed Sonoff 3.0 USB adapter that's been running fine for 3 years or so. 60 odd devices on Zigbee. Edit: I've just found another configuration.yaml file in the subdirectory zigbee2mqtt! Is that where I should add that block of stuff? Edit: Edit: I've done the upgrade following the instructions above and for the USB device and it all seems to be working now. I did get a few problems along the way and the addition to the configuration.yaml file as above seems to have been reduced to Don't know how! |
Beta Was this translation helpful? Give feedback.
-
|
It's the Zigbbe2MQTT confirmation file NOT the Home Assistant config file. In the Add On Configuration, click on the three dots across from the Options heading. This will give you the raw YAML file. Add the extra bits required at the bottom of this and save it. |
Beta Was this translation helpful? Give feedback.
-
|
I have slzb-06m configured with adapter ember. |
Beta Was this translation helpful? Give feedback.
-
|
Does there appear an error somewhere, maybe if you restart Zigbee2mqtt after your logs? Here's an issue where some people report failed starts that don't show real errors: It seems the issue has to to with some weird combination of the controller and special thermostats. In this case the "Danfoss Ally" or some clone of it (like Popp or Hive) |
Beta Was this translation helpful? Give feedback.
-
|
I am so happy not using Home Assistant but Domoticz. Update to 2.0 completed successfully, no errors, no issues. :) |
Beta Was this translation helpful? Give feedback.
-
|
So are we supposed be using or There seems to be conflicting information |
Beta Was this translation helpful? Give feedback.
-
|
I'm no expert, but it seems to me that you're definitely adding the following (plus the other settings mentioned at the top of this thread) and the following is an obsolete thing -- I don't see any explicit instruction to do anything about it. |
Beta Was this translation helpful? Give feedback.
-
|
Will triggers like this, based on an MQTT device's "friendly name" still work in 2.0? triggers:
- trigger: mqtt
topic: zigbee2mqtt/Bedroom Lamp Switches/action
payload: 1_doubleThank you. |
Beta Was this translation helpful? Give feedback.
-
|
Yes this should still work. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. Is it somehow worse than the proposed use of "device triggers"? It seems much nicer because it isn't encumbered with an inflexible and unreadable - trigger: device
domain: mqtt
device_id: ad44cabee4c646f493814306aa6446e1
type: action
subtype: arrow_left_click |
Beta Was this translation helpful? Give feedback.
-
|
Personally I'm a big fan of it due to its great flexibility. I have written down a small example of my usage with Node Red here: But this kind of MQTT handling could maybe also be done in ha automations with some tinkering. |
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 (before updating to 2.0.0)?
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:Also it is recommended to explicitly add a
serial.adapterto yourconfiguration.yaml, see #24364 for more info.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.zstackis no longer the default foradaptersetting. If Zigbee2MQTT fails to start saying the adapter could not be discovered, it means your adapter uses an identification not currently recognized by Zigbee2MQTT, make sure to specify theadaptersetting if that's the case.Bare-metal installations (no Docker/Home Assistant add-on)
configuration.yamlfrom repo, this will result in the following error when updating:git checkout data/configuration.example.yaml 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../update.shscript, make sure you pull changes from git withgit pull --no-rebase(after stopping Zigbee2MQTT).pnpm run clean, then start Zigbee2MQTT again.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.hass/statusHome Assistant status topic anymore,homeassistant/statusis used instead (ifhomeassistant.status_topicis not set in your Z2Mconfiguration.yaml). Double check that Home Assistant is using this status topic by going to: HA -> Settings -> Devices & services -> MQTT -> Configure -> Re-configure MQTT -> Next; the Birth message topic should behomeassistant/status.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. Home Assistant users might have to manually enable this sensor via Home Assistant. 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.illuminance_luxvalues, enable theilluminance_rawoption device specific settings (will be available from Z2M 2.1.0)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-to-2.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#25082homeassistant.status_topictohomeassistant/status#25286Beta Was this translation helpful? Give feedback.
All reactions