AddOn does not start after upgrade to 2.0.0-1 #688
Comments
|
Man i wish people actually start paying attention to atleast have a look at breaking changes section for once. |
|
I do not see any relation of those to a failed reading of the /app/package.json (apparently) included in the docker image. |
Please close the issue once resolved by following instructions. If not then please post you zigbee2mqtt config.yaml file |
|
I checked the recommended settings ("e.g. set xyz_legacy stuff to false") and found all in my current configuration.yaml i then continued checking through the "Home Assistant" Section in the docs but all there apply to post upgrade-and-start issues that are not even reachable for me now. I doubt that the issue is in my config but rather from what I see is that the package.json (which i assume is generated in the addon build and added into the image) is somehow broken (see error message in the log) and it does not at all start in the first place ... it just emits that error message and refuses to start my config (redacted) homeassistant: true
advanced:
network_key:
- XXX
- ...
pan_id: XXX
ext_pan_id:
- XXX
- ...
homeassistant_legacy_entity_attributes: false
homeassistant_legacy_triggers: false
legacy_api: false
legacy_availability_payload: false
log_level: info
last_seen: ISO_8601_local
mqtt:
server: mqtt://XXXXXXXXXXXXX
user: XXXXXXXX
password: XXXXXXXX
frontend:
port: 8099
serial:
port: /dev/ttyACM0
baudrate: 115200
rtscts: false
device_options:
legacy: false
homeassistant:
last_seen:
enabled_by_default: true
devices:
...
permit_join: true
availability: true |
|
Mine doesn't complain about anything, but log lists all devices, prints that state is online and stays there forever. No errors, but also doesn't work, seems like something stuck in starting frontend or so.. |
|
The zigbee2mqtt add-on didn't start yesterday after the 2.x upgrade. I reverted back to 1.42.0 from backup and don't currently have the 2.0.0-1 log. I had 1 legacy config entry missing and added it right now: 'homeassistant_legacy_triggers: false'. I'm still running 1.42.0.' I'll update once I try the upgrade again. /config/zigbee2mqtt/configuration.yaml (truncated) homeassistant: true |
|
I did a bit more research. (still on 1.42.0) So, with legacy triggers turned off my current event nodes will not fire anymore (i.e. entity 'Guest Bedroom Blind Button Action' is dead). I can see these MQTT msg topics (sample button): a sample msg looks like this: Does that mean my only options is to listen to MQTT topic 'homeassistant/device_automation//*' to trigger actions in Node Red? |
|
I went through downgrading to 1.42.0 from a backup and then re-upgraded to 2.0.0-1 and now it works... I did not change anything else on any config file. so for me now this issue could be closed. the other cases that where added in the comments seem to address slightly different issues AFAIS ... mine originally was about some NodeJS tooling complaining about a seemingly defective package.json file... again: this does not happen anymore for me thanks to all contributors to this thread and especially to the maintainers of this addon and zigbee2mqtt in general ! |
Have you looked at 24198? It's a complete long mess of over technical information and comments and nonsense. How about instead of pointing people a thread that spanned months you stop wasting everyone's time and extract the relevant information and actually put It in the release notes? Maybe if you provided clean, clear information SPECIFIC TO THE ADDON, then you'd have a legit reason to complain about people not reading a long-winded thread as much of the data there is not specific to the add-on. |
|
This is another report of this issue. I am using Sonoff Usb 3 Dongle-E flashed to latest 7.4 firmware. HEre's what I see in the add-on logs: [20:07:02] INFO: Preparing to start... and the UI never starts, nothing happens after this, no errors, warnings nothing... I have also tried every possible configuration that I can find to enable more log debug output from the add-on in the configuration yaml UI and nothing seems to work. |
|
Having issues as well, wondering how to revert back to the old version from HAOS UI. |
|
Also having issues and wondering how to revert to an older version from HAOS UI. But I will use the Zigbee2MQTT Edge version first and wait for the update. |
|
Zigbee2MQTT cannot be started with the following error message. It can start normally in the Zigbee2MQTTEdge version, waiting for the new version to solve it, thank you. [12:28:55] INFO: Preparing to start... |
|
By default when updating an add-on a backup is created, I was able to revert to 1.42 that way and disabled auto-update. Add-on is working correctly for now. |
Sorry, I didn't back up the data |
The add-on is just a wrapper for the "plain" Zigbee2MQTT project. That underlying project went from release 1.42.0 to 2.0.0 which introduced some major changes, including some breaking changes that require actions to be taken before upgrading. Both - this issue list and Zigbee2MQTT's issue list - are currently flooded with "issues" that could have been avoided by just reading the release notes. The same should be done before upgrading Home Assistant itself. |
Read Koenkk/zigbee2mqtt#24198, add one line to your configuration. |
So let me get this straight you are not ready to read the so called long document which it isn’t out of sheer laziness .and all the important changes to made before updating has been highlighted right at the start . I don’t know how more concise @Koenkk could have been with the documentation |
Yeah but apparently that is too much to expect I guess . That being said apart from the adapter and legacy config commands some people have still not got the addon to work which would require a separate thread as someone mentioned they rolled back the add on and updated and it started working |
Hard to read, because you didn't use code formatting when copying your configuration.yaml, but at the @promofu This could also be the cause for you. |
yeah, i had the same error in the morning. i only had port: tcp://x.x.x.x:6638 configured till now. adapter: zstack in it, and now it works. |
Someone is making money by going through the release notes on video, what a crazy world ... |
Did you manage to solve this ? I have what looks like the same problem, and none of the fixes i have seen so far seems to solve the problem. |
I also appear to be in this position. No errors in log (info level), all devices listed, with debug level log I can see data eg. Temps from sensors, but web gui will not start. Same with edge. Hoping for some ideas! |
Unfortunately, I didn't.. tried cleaning config, adding legacy disablements, moving files to different location.. to no success. Tried multiple times going back and forth with the same result. |
I read somewhere else that you are supposed to add the legacy config in 1.4.2 and check if it everything works there. The configuration migration procedure will automatically remove the legacy settings as part of the v1 -> v2 migration. This makes kind of sense as the functionality is completely removed form 2.0.0 I tried restoring a backup of 1.4.2-1, which naturally worked, then i added the legacy settings which completely broke the HA integration (all sensors became unavailable). Removing the settings again (still runnign 1.4.2) brought functionality back. So i think the problem is that my config is using some of the legacy functionality, that is completely removed in 2.0.0. The odd thing is that i did not have any .legacy = true settings enabled in my 1.4.2 config. I have no idea how to figure out what cause everything break. |
|
You got to be kidding me. Tried another 2.x update. The add-on is not starting.. [16:48:45] INFO: Preparing to start...
|
|
Modified all the icon setting to 'device_icons/' and it finally started in version 2.0.0-1. Nowhere in Koenkk/zigbee2mqtt#24198 did I find anything about the icon setting. |
Simply, it's not concise at all. This really isn't a good use of time to rathole on this topic right here, but since we're here and clearly people are having issues with 2.0.0, including myself, let's take a closer look at what the actual situation is here. To be clear, I read 21498. That's how I know it's a mess. Here's some constructive criticism. It's very simplistic to say that if people would read the release notes they wouldn't have all of these issue. That assume a lot about the ability for that document to convey the most important information easily, which, it doesn't clearly, for if it would then you'd have less issues here. The issue is that it's a poorly written document that fails to clearly communicate in a way that casual users can understand. It It's not a matter of being lazy, it's a matter of how information is organized and presented. It suffers from a classic problem that arises when a developer who literally knows everything about a product writes a document for people who don't- it's often overly technical, leave out a ton of basic information and is not well organized. Just look at the comments here on this thread to prove the point. There are multiple complaints of missing information, or not being able to figure out what to do. I wasted over 2 hours yesterday trying to get the upgrade to work to no avail and that's after I read the documents several times. Eventually, I gave up and reverted to 1.4.x as many other people here also did. Let's take for another example the confusion around the serial.adapter setting. Yes, the document says, "It is recommended to explicitly add a serial.adatper to your configuration...." Yet, under "General" further down, it says, "Improved adapter discovery. ..... stack is no longer the default for adapter setting. If Z2M fails to start saying the adapter could not be discovered...... make sure to specify the adapter setting if that's the case." This is sending mixed messages... on the one hand it says it's recommended, which means that I can ignore it, yet further down it says that if it fails, I need it. This information should not be spread all over the document, and the entire sentence around "it is recommended" clearly is not true and should have been left out. Period. It's absolutely REQUIRED to add it if if automatic adapter discovery fails. That's what it should say in one simple clean way that can't be missed. So yeah, give the users a terrible user experience (such as confusing, incomplete documentation), but then don't complain if people can't figure out what they're supposed to do. Oh, and another thing that is highly confusing about it.... all of the settings that have the word "legacy" in them are recommended to be false. This is absolutely counterintuitive. If a system is updated that is not backward compatible, it would make logical sense that I should set the settings for legacy behavior to TRUE, not false. Then, further down, it says "only breaking with legacy is enabled" ... when legacy WHAT is enabled? There only half a dozen settings with the word "legacy" in them, so which one is it, or is it just "device_optiosn.legacy"... it's not clear. Now maybe, there are historical reasons for these wacky names, but the people who use this are largely not deeply involved developers who have that history and know the depths of the product. Mostly, they just install it and it works out of the box (as it has for me for years), so it's a bit much to presume people will understand illogically named settings and things like "legacy enabled" when they've literally never had to deal with that before. I could go on.... but the bottom line is that I did read the document found it highly confusing and not clear for a casual users. Yes, I have a long background in professional software engineering, so I'm not an idiot and I know what I"m talking about, but I shouldn't have to read the source code to figure out how to use something. I know enough to know that when I prepare documentation for the public for software products, how it's written matters a lot. |
Not surprising given the poor quality of the release notes. :) |
|
On the zigbee2mqtt configuration page, find the 'serial' section and add a new line as below adapter: zstack let the new contents above your original line as below Save and restart zigbee2mqtt. It works. |
Good on you mate if you want a readymade solution to be spoon fed to you home assistant isn’t for you. I am done arguing |
|
I am also facing the same problem discussed here. Zigbee2MQTT cannot be started. I also tried the solution with changing the port and the adapter name, but the problem remained.The last version that worked is 1.42.0-2. After I correctly wrote the port for the coordinator in the Zigbee2MQTT configuration, I saw that the following error appeared in the log:''Refusing to start because configuration is not valid, found the following errors: Should it be written for each device instead of "data:image/png;base64", "device_icons/png;base64", or just "device_icons"? |
|
Go to your configuration.yaml at /config/zigbee2mqtt devices: |
|
Thanks for the reply, can you please take a screenshot and post it? And shouldn't the path be /config/zigbee2mqtt/devices.yaml? |
|
The sample device definition in my earlier post is working with Zigbee2MQTT 2.0.0-2. |
|
I would like to see a screenshot of the page in the file editor where you have the devices configured. |
|
|
|
Thank you very much for your help! After making the changes in the file editor, Zigbee2MQTT still did not start and now I get the following error: 500 internal server error |
Description of the issue
I upgraded as hinted by HomeAssistant ... now the addon does not start anymore - see log below
Addon version
2.0.0-1
Platform
Core 2025.1.0
Supervisor. 2024.12.3
Operating System. 14.1
Frontend. 20250103.0
Logs of the issue (if applicable)
[15:28:32] INFO: Preparing to start...
[15:28:33] INFO: Socat not enabled
[15:28:33] INFO: Enabled Zigbee2MQTT watchdog with value 'default'
[15:28:34] INFO: Starting Zigbee2MQTT...
node:internal/modules/run_main:91
const type = getNearestParentPackageJSONType(mainPath);
^
Error: Invalid package config /app/package.json.
at shouldUseESMLoader (node:internal/modules/run_main:91:16)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:163:20)
at node:internal/main/run_main_module:36:49 {
code: 'ERR_INVALID_PACKAGE_CONFIG'
}
Node.js v22.11.0
The text was updated successfully, but these errors were encountered: