Replies: 16 comments 39 replies
-
|
I'd like to remove the |
Beta Was this translation helpful? Give feedback.
-
|
If my understanding is correct, right now and by setting: it should simulate how it will work in v2.0.0. Any time frame or roadmap for the release of v2.0.0? Could you be a bit more explicit where and how we may implement this solution in a blueprint? It is going to be a huge breaking change for me. I know it is not a HA github as the change is done via Z2M, I am asking (sorry, my knowledge are not that high in that topic...still learning😉). |
Beta Was this translation helpful? Give feedback.
-
|
@chris-1243 That really depends on what blueprints your are using. They might need to be adapted by their creators (and you would need to upload the new version). Now if you are talking about scripts or automations, most likely you would just need to replace |
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.
-
|
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.
-
|
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.
-
|
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.
-
|
Yes, insofar as the new maximum inclusion period will be 254 seconds (slightly more than 4 minutes) in the draft PR. |
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.
-
|
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.
-
|
@Koenkk would renaming an effect for Hue bulbs be considered a bc break? If so, I'd like to get a fix in place now where "prism" is incorrectly called "colorloop". I figured it was worth checking since it's been wrong for a while and users could have automations tied to it. |
Beta Was this translation helpful? Give feedback.
-
This discussion contains a list of breaking changes for Zigbee2MQTT 2.0.0, the list of breaking changes will be updated gradually. Feedback and suggestions are welcome!
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.
Breaking changes
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 thisadvanced.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/configurezigbee2mqtt/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/homeassistantadvanced.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 joiningupdate_availableproperty from the device state has been removed (useupdate.stateinstead)updateAvailabletoupdate_availableinzigbee2mqtt/bridge/response/device/ota_update/checkconfiguration.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.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.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.TODO (not implemented yet)
homeassistant>legacy_triggers-action/clicksensor (already deprecated for a long time)homeassistant>legacy_entity_attributesdevice>xyz>legacylegacydevice option (mostly affectslegacy.ts)settings.schema.jsonfor more option to deprecatePRs
retrieve_statezigbee2mqtt.io#3075readAfterWriteTimezigbee-herdsman-converters#8089configuration.yamlzigbee2mqtt.io#3104configuration.yaml#24338configuration.yamlzigbee2mqtt.io#3104configuration.yaml#24338Beta Was this translation helpful? Give feedback.
All reactions