Hassio-zigbee2mqtt: Add-on fails to start after update (any version after 1.14.4)

[Karolis92]

zigbee2mqtt add-on version (if edge, please report commit hash):
1.14.4

Operating environment (HassOS, Virtual Machine, Device/platform running Hass.io):
RPI3 HassOS 4.12

Description of problem:
After update 1.14.3 to 1.14.4, addon does not start anymore, with PR #353 bunch of new stuff was added to config, but no info in changelog about breaking changes

Your entire configuration from the frontend (with sensitive fields redacted):

data_path: /share/zigbee2mqtt
external_converters: []
devices: devices.yaml
groups: groups.yaml
homeassistant: true
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: '_redacted_'
  user: _redacted_
  password: '_redacted_'
serial:
  port: /dev/ttyACM0
  disable_led: true
advanced:
  pan_id: _redacted_
  ext_pan_id_string: '_redacted_'
  last_seen: ISO_8601_local
  log_level: warn
  channel: 25
  network_key:
    - _redacted_
    -  _<...>_
    - _redacted_
  availability_blacklist: []
device_options: {}
blocklist: []
passlist: []
queue: {}
experimental: {}
socat:
  enabled: false
  master: 'pty,raw,echo=0,link=/dev/ttyZ2M,mode=777'
  slave: 'tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5'
  restartdelay: 1
  initialdelay: 1
  options: '-d -d'
  log: false
ban: []
whitelist: []

Your logs from Hass.io

[Karolis92]

I'm not sure how HassOS addon system works, it maybe it takes config schema from github, but image form docker hub, because last image I see is pushed 11 days ago. But PR with thee changes was merged 5 days ago.
When I try to start addon I get message that availability_blocklist is missing , but it's was not in 1.14.4 yet

[robbinonline]

Same error here, it looks like it have something to do with the config layout

[Wollenyy]

What is the solution? After update I've run out of sensors, it doesn't start zigbee2mqtt, error "missing option avaibality_blocklist in advanced" . Thank you

[projectraam]

I "solved" it by

1. Taking a backup of my config
2. Using reset to default
3. Merged the old and the new, so it followed the correct structure and then used that in the config.

I could then start the add on, but it's now completely unstable. It fails on missing network route, sometimes the devices are responding instantly, sometimes slow (10-20 seconds delay) and sometimes nothing happends.

[damomay]

I had the same issue a few day ago after the update. I was able to sort out the config file and make it run but also found it completely unstable with some switches working then not working then the whole zigbee network crashed and nothing worked I ended rolling back to the previous version using my last snapshot and all is good once again

[lovelylain]

https://www.zigbee2mqtt.io/information/configuration.html
Sorry it's my fault, according to the information here,
ban, whitelist, availability_blacklist, availability_whitelist are deprecated,
please use blocklist, passlist, availability_blocklist, availability_passlist instead.

[Karolis92]

I restored default config, addon started. Then merged with my old config, it started, but now all of the divices are gone and will need to repair.
I'm not sure I want to go same way anymore as this addon only introduces one more place to fail. Will figure if host z2m somwhere independently without this middle-man addon or maybe try out ZHA

[projectraam]

Could the official release be reverted back to version 1.14.3 until a stable version 1.14.5 could be released? I can’t figure out what in version 1.14.4 that’s causing the instability.

[Naguz]

Mine refused to start after update due to a missing "availability_blocklist" option. I tried adding it, but it refused me to save my config in the webui due to some error which seemed to imply my whole config file format was invalid. Unfortunately I did not copy the error, as I noticed this bug report and restored to a snapshot (no time to debug ATM).

This is definitely either a breaking change or a bug, and should be pulled ASAP until either the bug is fixed, or a release note with info about the breaking change and new configuration file format is added, whichever is the problem.

[Karolis92]

I guess it's not the 1.14.4 that causes problems, it's probably because home assitant reads config from 'master' branch of repo which was changed after 1.14.4 release. Maybe repo needs 'develop' branch where develpment is done and keep master at release state.

[tomekpur]

Here are the changes in the config that helped me out:

Change

availability_blacklist: []

to

availability_blocklist: []
availability_passlist: []

Remove

ban: []
whitelist: []

[GuusK]

Posting here because it seems that this is caused in the same way.

zigbee2mqtt add-on version (if edge, please report commit hash): 1.14.4

Operating environment (HassOS, Virtual Machine, Device/platform running Hass.io): HassOS 4.13, home assistant 0.114.4

Description of problem:
I've had it working with a few Osram Smart+plugs on version 1.14.1. Updated to 1.14.4 and now it doesn't start. When it does start, it shows me the following:

Failed to start addon - configruation validation faled!
Missing option availability_passlist in advanced.

When I go to configuration and add availability_passlist: [] to advanced, it isn't able to save with the following error Failed to save addon configuration, not a valid value for dictionary value @ data['options']. and then a listing of my settings. Changing availability_blacklist into availability_blocklist doesn't help. But having both (as empty lists) allows the addon to start and allowed my to have the smart plugs working again. This is against documentation as found on zigbee2mqtt.io

Please note that this is my working configuration. Deleting either availability_blocklist: [] or availability_passlist: [] will not allow me to save the config.

data_path: /share/zigbee2mqtt
external_converters: []
devices: devices.yaml
groups: groups.yaml
homeassistant: true
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://core-mosquitto'
  user:   # Omitted for security
  password:   # Omitted for security
serial:
  port: /dev/ttyACM0
advanced:
  pan_id: 6754
  channel: 11
  network_key:
  # Omitted for security
  availability_blocklist: []
  availability_passlist: []
device_options: {}
blocklist: []
passlist: []
queue: {}
experimental: {}
socat:
  enabled: false
  master: 'pty,raw,echo=0,link=/dev/ttyZ2M,mode=777'
  slave: 'tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5'
  restartdelay: 1
  initialdelay: 1
  options: '-d -d'
  log: false
ban: []
whitelist: []

There are no logs for this in HassOS logs for Supervisor, Core or Host

Also found the old (non-starting) config:

data_path: /share/zigbee2mqtt
external_converters: []
devices: devices.yaml
groups: groups.yaml
homeassistant: true
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://core-mosquitto'
  user:   # Omitted for security
  password:   # Omitted for security
serial:
  port: /dev/ttyACM0
advanced:
  pan_id: 6754
  channel: 11
  network_key:
  # omitted for security
  availability_blacklist: []
device_options: {}
blocklist: []
passlist: []
queue: {}
experimental: {}
socat:
  enabled: false
  master: 'pty,raw,echo=0,link=/dev/ttyZ2M,mode=777'
  slave: 'tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5'
  restartdelay: 1
  initialdelay: 1
  options: '-d -d'
  log: false
ban: []
whitelist: []

[lovelylain]

@GuusK According to Zigbee2mqtt's configuration document, ban, whitelist, availability_blacklist, availability_whitelist are deprecated, they are replaced by blocklist, passlist, availability_blocklist, availability_passlist.
HomeAssitant’s add-on must exist for array and dictionary type options even if you don’t need to set them, so even if you don’t need them, you must also set availability_blocklist:[] and availability_passlist: []. According to the documentation, if availability_passlist is not empty, availability_blocklist will be ignore.

[ciotlosm]

It took me a while to make it work, but I was able to update and start the addon by correcting the config with the right settings mentioned above.

Things to look out for: Even if you add and modify the settings mentioned there, there are some that are added automatically and you just need to delete the old ones. Example:

ban: []
whitelist: []

[GuusK]

@lovelylain It is true that those configs are deprecated. And if everything stayed the same and that was the issue, changing availability_blacklist into availability_blocklist should have fixed it. However, that was not the case.

The documentation you've linked states both availability_blocklist and availability_passlist as optional so my train of thought was that they don't have to be present (as is the case for other optional configuration options). So the documentation maybe should be updated to reflect that they should be present but can be left empty.

Other than that, this config change probably should not have been a patch version update according to semver, but that's probably more an issue for zigbee2mqtt itself.

[ciotlosm]

@GuusK I think keeping docs up to date is always a problem in projects. Would be great to get people to submit doc updates when they notice problems.

Other than that, this config change probably should not have been a patch version update according to semver, but that's probably more an issue for zigbee2mqtt itself.

I totally agree with versioning that should be more consistent when doing breaking changes.

[danielwelch]

@GuusK all reasonable arguments. Unfortunately a lot of these issues are just related to the quirks of how Home Assistant handles configuration, which @lovelylain spelled out nicely above. "Old" config options tend to show back up on updates/re-installs because of how Home Assistant saves / handles your configuration.

I used to maintain a list of variables in the early days of this add-on. But as zigbee2mqtt configuration grew more complex and involved more levels of nesting, this got harder to maintain. So we decided to just make the add-on configuration match the zigbee2mqtt configuration, with exceptions called out in the README (although there are some debug/advanced options available that are not called out, maybe they should be).

This project also does not follow semver. Another decision made in the early days of zigbee2mqtt, when breaking changes were common in zigbee2mqtt. Again, the way home assistant handles and requires things of your configuration, the definition of "breaking changes" is expanded.

[lovelylain]

@GuusK The configuration file you see in addon is different from that of zigbee2mqtt itself. Addon has its own constraint rules. The options dictionary contains all available options and their default value. The schema looks like options but describes how we should validate the user input. If you want make an option optional, put ? to the end of data type, otherwise it will be a required value. There is no optional array or dictionary option in home assistant addon configuration. So despite availability_blocklist is optional in zigbee2mqtt, in order to support it in addon, we must add availability_blocklist: ["str?"] to schema, and add availability_blocklist: [] to options.

[Karolis92]

@danielwelch the current problem is that after 1.14.4 release config was changed, but hass dosn't take it by tag or any other indicator, it just takes latest one. These changes that were made was not even relesed with 1.14.4. Having develop branch would solve this. As main master could be kept at latest release state.

[Naguz]

I guess it's not the 1.14.4 that causes problems, it's probably because home assitant reads config from 'master' branch of repo which was changed after 1.14.4 release. Maybe repo needs 'develop' branch where develpment is done and keep master at release state.

Based on the explanations here, that makes sense. However, updating an addon should never cause breaking changes without this being explicitly stated in the release notes. Breaking changes is a huge no-no.

[danielwelch]

@Karolis92 I may be misunderstanding the initial issue here, but it seems like the issue was that the “required” empty arrays were not included, and that adding those (and removing deprecated ones) fixed peoples issues. However, I agree that keeping master to reflect latest release would solve other problems (and is certainly what Home Assistant wants you to do).

Regardless, the CHANGELOG needs to be better maintained during updates. Spelling out some of these updates would’ve avoided a lot of trouble for people.

[Karolis92]

@danielwelch problem is that if you update (install) some days after the release, home assistant takes the config.json in state that it is in master branch at the installation moment. So if development is happening, some things may be not in same state as was intended when doing release. So changes can be breaking, not fully tested and undocumented.
In this case that happened, people who updated later, got newer config, with new options required and no documentation on that.

Now people who updated just after release uses one config option, but people who will install now will have to use different config options, but addon version will be 1.14.1 for both users

[danielwelch]

Got it, I didn’t have the timeline down for what happened in this particular case. This is definitely a problem and there essentially should be no changes to stable config on master outside of a release. Definitely need another branch for development.

[bobslaede]

Next time maybe allow both config names... Not a fun update 😵😐🙂

[danielwelch]

I'm not really interested in supporting all old zigbee2mqtt config options in perpetuity. Particularly in the early days, we tried this, everything got bloated and difficult to maintain (as well as confusing for new users) due to rapid changes in zigbee2mqtt, decided to cut things down/consolidate and issue a breaking change warning... repeat cycle... etc. Granted, the zigbee2mqtt pace of change with respect to its configuration has slowed, but still. Main thing is these changes need to be called out as breaking (and that they should never go on master prior to a release).

[MRobi1]

Definitely a rough update. I had no issues on 1.14.4 but updated today to 1.14.4.1 and add-on wouldn't start.
Followed the advice from @tomekpur and got the add-on going again. Initially nothing would respond at all. I'm about 8hrs in and about 90% of my devices are responding again.

Zigbee2MQTTAssisstant is a whole other story. It's throwing fits. Everything shows it's been unresponsive for between 2-4 weeks and can't get it to build a network map at all.

[bobslaede]

@danielwelch renaming stuff in the config wouldn't be too bad, if you wrote a small script as part of the startup process, to fix our configs. I had automatic updates turned on (off now!) and I got a bit of a surprise when all of a sudden, nothing worked.
Preferably do a major version update when you have breaking changes, or do it incrementally with a minor version update, and support both config options for a while. Mark the old ones as obsolete in the README.

HA would probably have updated automatically even if it was a major version change, but that would be my problem, or HA's. Not yours.

Best option would probably be major version change, and script included to fix the config :)

Have a great day :)

[Karolis92]

I doubt addon has direct access to config an abbility to change it. It get's some json file with options, but that is derived from config enter by user in UI.

Would be nice to get direct access to that yaml tho... Then no mapping would need to be done from json object :D

[ciotlosm]

@MRobi1 1.14.4.1 did not have any breaking changes or changes to zigbee2mqtt version of config. You probably just didn't restart 1.14.4 to observe the problem.
The problem with devices responding slow has nothing to do with zigbee2mqtt add-on and especially not with 1.14.4 to 1.14.4.1 update, as that has no changes to zigbee2mqtt version and codebase.
I have been observing the above issue Zigbee2MQTTAssisstant for a few versions now, showing devices as unresponsive (even if I can actually control them from the HA ui). I hope in the future we get a more lightweight mqtt command wrapper for z2m without state that gets more accurate data.

@danielwelch maybe it's worth adding the details from @tomekpur to the Readme.md top and do another minor release, so people understand what the problem was and what they need to do to fix directly from the UI. If you're ok with this I could prepare the text changes and do a PR.

[rbron01]

SOLUTION:
You can still use your config if you make the changes like this

1. Update the plugin and let it install
2. Goto the Configuration Tab

1. Make the following Changes:

Remove:
--------

ban: []
whitelist: []

Add:
----

advanced:
  availability_blocklist: []
  availability_passlist: []

1. Press Save and Press on the Reboot Plugin and everything is working again

[danielwelch]

@ciotlosm I'm ok with that if you want to add some warning text, or something similar, and do another release.

@bobslaede I think in a perfect world, I'd love to stick to semver, or at least limit breaking changes per semver, but that's not easy with this project as it is intertwined so strongly with zigbee2mqtt. When zigbee2mqtt releases a breaking change from 1.13 to 1.14, the maintainer of zigbee2mqtt is bombarded with requests from add-on users for an add-on update. So he understandably bumps the zigbee2mqtt version within the add-on config and puts out a release, without making config changes or CHANGELOG updates. Now users understandably wonder why option X isn't supported in the add-on despite the version update. So that requires a W.X.Y.Z update to support the new feature. Problems arise from releases without changelog updates, explicit warnings about breaking changes, etc. that we've discussed above. We've implemented a script to fix things in the past, and even a backup script when we completely reworked the config, but I don't think anyone is going to volunteer to write a script / modify the run script every time there's a deprecated zigbee2mqtt option. Now, if there was functionality in HA auto-update that respected things like major version changes (if there is I'm unaware), I'd rethink the approach to versioning.

@Karolis92 In the ultimate form of irony, we started off this add-on by just letting people modify a configuration.yaml directly, but users (especially new users) didn't like it as people wanted to configure everything from the UI. We went that direction because it seemed to (and still seems to) be the way HA is going. We kind of also figured people who would want to edit files directly via ssh or whatever would be comfortable interpreting the add-on config.json schema and options.

[ciotlosm]

@danielwelch If the changelog is always taken from the repo, I think that can be added there and no need for a release.

@bobslaede I agree with @danielwelch that it costs too much and adds complexity to try and keep scripts to fix things for all types of upgrades (some users jump 2-3 versions) and in many cases those are needed just for 1 version skip. If this project had many active developers it might have been possible, but currently it does not. @danielwelch has done an amazing job keeping it running.

There are things that can be done to improve some things for config.json that are being discussed, but for breaking changes I think best that can be done is to document them properly in the CHANGELOG. We can't bloat README.md with all the various breaking changes, and users should read the CHANGELOG. Considering the nature of zigbee2mqtt we should maybe advertise to disable auto-update on the plugin. I don't think Home Assistant has any special "Update only if minor or patch version changes" type of mechanism.

@Karolis92 @danielwelch Even myself have been enjoying the UI setup for z2m. I was able to redo my whole house setup using my phone only to setup, pair, rename, group and get the perfect UI for all my zigbee devices. I remember the days when you have to do a lot of ssh and manual yaml file setup to get even the most basic building blocks. While I agree the flexibility there was nice and it is still nice to know what's behind, on many occasions you just want to be done fast and have more time for beers 😃 🍻

[ciotlosm]

@ronniebee try solution proposed in comment: https://github.com/danielwelch/hassio-zigbee2mqtt/issues/384#issuecomment-693650970

[ronniebee]

@ronniebee try solution proposed in comment: #384 (comment)

That worked!! thx.....

[coolduke666]

have the same problem BUT mine didn't start even after I have resetted the config to default. so the config should be correct .I also tried to reinstall the addon without any luck. have no idea how to proceed :(

external_converters: []
devices: devices.yaml
groups: groups.yaml
homeassistant: true
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://core-mosquitto'
  user: '!secret mqtt_user'
  password: '!secret mqtt_password'
serial:
  port: /dev/ttyACM1
advanced:
  log_level: info
  pan_id: 6754
  channel: 11
  network_key:
    - 1
    - 3
    - 5
    - 7
    - 9
    - 11
    - 13
    - 15
    - 0
    - 2
    - 4
    - 6
    - 8
    - 10
    - 12
    - 13
  availability_blocklist: []
  availability_passlist: []
device_options: {}
blocklist: []
passlist: []
queue: {}
experimental: {}
socat:
  enabled: false
  master: 'pty,raw,echo=0,link=/dev/ttyZ2M,mode=777'
  slave: 'tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5'
  restartdelay: 1
  initialdelay: 1
  options: '-d -d'
  log: false

[ciotlosm]

@coolduke666 can you post the error?

[coolduke666]

Zigbee2MQTT:info  2020-09-20 09:33:18: Starting Zigbee2MQTT version 1.14.4 (commit #unknown)
Zigbee2MQTT:info  2020-09-20 09:33:18: Starting zigbee-herdsman...
Zigbee2MQTT:error 2020-09-20 09:33:30: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2020-09-20 09:33:30: Failed to start zigbee
Zigbee2MQTT:error 2020-09-20 09:33:30: Exiting...
Zigbee2MQTT:error 2020-09-20 09:33:30: Error: AREQ - ZDO - simpleDescRsp after 10000ms
    at Timeout._onTimeout (/zigbee2mqtt-1.14.4/node_modules/zigbee-herdsman/dist/utils/waitress.js:46:35)
    at listOnTimeout (internal/timers.js:549:17)
    at processTimers (internal/timers.js:492:7)
npm
 ERR! code ELIFECYCLE
npm ERR! errno 1
npm 
ERR! [email protected] start: `node index.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] start script.
npm ERR!
 This is probably not a problem with npm. There is likely additional logging output above.

here from the homeassistant log:

20-09-20 07:00:42 ERROR (MainThread) [supervisor.addons.addon] Add-on 7ad98f9c_zigbee2mqtt has invalid options: Missing option availability_blocklist in advanced. Got {'data_path': '/share/zigbee2mqtt', 'external_converters': [], 'devices': 'devices.yaml', 'groups': 'groups.yaml', 'homeassistant': True, 'permit_join': False, 'mqtt': {'base_topic': 'zigbee2mqtt', 'server': 'mqtt://core-mosquitto', 'user': '!secret mqtt_user', 'password': '!secret mqtt_password'}, 'serial': {'port': '/dev/ttyACM1', 'disable_led': True}, 'advanced': {'pan_id': 6754, 'channel': 11, 'network_key': [1, 3, 5, 7, 9, 11, 13, 15, 0, 2, 4, 6, 8, 10, 12, 13], 'availability_blacklist':...

but the config option "availability_blocklist" is definitely in the config...

[ciotlosm]

@coolduke666
For Error: AREQ - ZDO - simpleDescRsp after 10000ms try rebooting / removing and reattaching the USB stick / pressing the reset button on the stick and if nothing works, you will have to re-flash your z2m stick.

For the second error, your config still contains availability_blacklist. Please follow instructions from https://github.com/danielwelch/hassio-zigbee2mqtt/issues/384#issuecomment-693650970 to fix it.

[coolduke666]

this is my config from the add-on config tab:

data_path: /share/zigbee2mqtt
external_converters: []
devices: devices.yaml
groups: groups.yaml
homeassistant: true
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://core-mosquitto'
  user: my_user
  password: my_password
serial:
  port: /dev/ttyACM1
advanced:
  log_level: info
  pan_id: 6754
  channel: 11
  network_key:
    - 1
    - 3
    - 5
    - 7
    - 9
    - 11
    - 13
    - 15
    - 0
    - 2
    - 4
    - 6
    - 8
    - 10
    - 12
    - 13
  availability_blocklist: []
  availability_passlist: []
device_options: {}
blocklist: []
passlist: []
queue: {}
experimental: {}
socat:
  enabled: false
  master: 'pty,raw,echo=0,link=/dev/ttyZ2M,mode=777'
  slave: 'tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5'
  restartdelay: 1
  initialdelay: 1
  options: '-d -d'
  log: false

[coolduke666]

looks to me like the add-on doesn't use the config with is shown in the add-on config tab. instead it is using some other configfile. but I have no clue, why and where to find this depeciated config file.

[ciotlosm]

@coolduke666 the error is probably older, and your config now works, but the problem you have is with z2m not connecting to your stick: Error: AREQ - ZDO - simpleDescRsp after 10000ms. If your config was still broken, you would not have been able to get to that message.

[coolduke666]

hey ho... reseting the cc2531 did the trick - big thanks for you help 🥇

[bjschuit]

I had the same problem with all versions after 1.14.1, so I had to restore to older versions. Just tried with 1.14.4.1 and now it works. However, I do not get log output in Home Assistant. After some time the error Failed to get addon logs, Bad Gateway appears. Again, if I restore back to before 1.14.1 (I think) it all works flawlessly. My config (after latest update) is:

data_path: /share/zigbee2mqtt
external_converters: []
devices: devices.yaml
groups: groups.yaml
homeassistant: true
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://core-mosquitto'
  user: bjmqtt
  password: bjmqtt
serial:
  port: /dev/ttyACM0
advanced:
  pan_id: 6754
  channel: 20
  network_key:
[all 16 there]
  availability_blacklist: []
device_options: {}
blocklist: []
passlist: []
queue: {}
experimental: {}
socat:
  enabled: false
  master: 'pty,raw,echo=0,link=/dev/ttyZ2M,mode=777'
  slave: 'tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5'
  restartdelay: 1
  initialdelay: 1
  options: '-d -d'
  log: false
ban: []
whitelist: []

[ciotlosm]

@bjschuit can you please open a new issue with all the details please?

• current HA version
• current supervisor version
  etc.

Also , try a full reboot of your HA as the Failed to get addon logs, Bad Gateway looks closer to Supervisor API problem.

[bjschuit]

I stand corrected. The latest version that works is 1.14.2.
Version 1.14.3 wouldn't start, as it gave a configuration error missing option avaibality_blocklist in advanced. That error is gone in 1.14.4.1, but I get no logs and no Zigbee device is working.

When I revert back to 1.14.2, everything works perfectly fine again.

This is with both HA 0.114.4 and latest 0.115.2.
Supervisor version is 245.

I noticed the same errors as before now when I looked at the supervisor version:

20-09-21 07:12:02 ERROR (MainThread) [supervisor.addons.addon] Add-on 7ad98f9c_zigbee2mqtt has invalid options: Missing option availability_passlist in advanced. Got {'data_path': '/share/zigbee2mqtt', 'external_converters': [], 'devices': 'devices.yaml', 'groups': 'groups.yaml', 'homeassistant': True, 'permit_join': False, 'mqtt': {'base_topic': 'zigbee2mqtt', 'server': 'mqtt://core-mosquitto', 'user': '@@@', 'password': '@@@'}, 'serial': {'port': '/dev/ttyACM0'}, 'advanced': {'pan_id': @@@, 'channel': 20, 'network_key': [@@@], 'availability_blacklist': []}, 'device_options': {}, 'blocklist': [], 'p...
20-09-21 07:12:02 ERROR (MainThread) [supervisor.misc.tasks] Watchdog 7ad98f9c_zigbee2mqtt reanimation failed with 
20-09-21 07:12:32 WARNING (MainThread) [supervisor.misc.tasks] Watchdog found a problem with 7ad98f9c_zigbee2mqtt!

I'm gonna try to fix the config (again), maybe I did something wrong in the past. The automatic changing of the configuration however does not work fool-proof I see.

Edit:
Still no luck. I do not even see the container being created. So something is off, but I can't figure out what. I've tried to change the config the whole time but it didn't work.

[ciotlosm]

@bjschuit did you try the exact steps in https://github.com/danielwelch/hassio-zigbee2mqtt/issues/384#issuecomment-693650970 ? Your error seems to be the config problem by looking at your above posted logs

[bjschuit]

Thanks for your quick response and the reference. After another look, I saw that I totally overlooked blacklist -> blocklist. I changed it and now it works. Sorry for the inconvenience.

[baldfox]

`` Zigbee2MQTT:info 2020-09-20 09:33:18: Starting Zigbee2MQTT version 1.14.4 (commit #unknown) Zigbee2MQTT:info 2020-09-20 09:33:18: Starting zigbee-herdsman... Zigbee2MQTT:error 2020-09-20 09:33:30: Error while starting zigbee-herdsman Zigbee2MQTT:error 2020-09-20 09:33:30: Failed to start zigbee Zigbee2MQTT:error 2020-09-20 09:33:30: Exiting... Zigbee2MQTT:error 2020-09-20 09:33:30: Error: AREQ - ZDO - simpleDescRsp after 10000ms at Timeout._onTimeout (/zigbee2mqtt-1.14.4/node_modules/zigbee-herdsman/dist/utils/waitress.js:46:35) at listOnTimeout (internal/timers.js:549:17) at processTimers (internal/timers.js:492:7) npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! [email protected] start:node index.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] start script.
npm ERR!
This is probably not a problem with npm. There is likely additional logging output above.

Did you fix this in the end? I too am having the issue with this error. I chose to default the config also.

[oldfart101]

I found the best way. Shut down the Pi. Remove USB. Power on. Insert USB.
Works for me every time.
Restart doesn't work, reboot sometimes works.

[baldfox]

Ok will give that a go... I've tried the usual add-on, edge, rebooted the host god knows how many times. Defaulted my config (bar the mqtt details) and cannot get rid of this error:

Zigbee2MQTT:error 2020-09-22 15:37:13: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
    at ZStackAdapter.<anonymous> (/zigbee2mqtt-1.14.4/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:90:31)
    at Generator.throw (<anonymous>)
    at rejected (/zigbee2mqtt-1.14.4/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:25:65)

It's killing me!

[baldfox]

I found the best way. Shut down the Pi. Remove USB. Power on. Insert USB.
Works for me every time.
Restart doesn't work, reboot sometimes works.

No joys unfortunately, still returns me this error:

Zigbee2MQTT:info  2020-09-22 15:49:33: Logging to console and directory: '/share/zigbee2mqtt/log/2020-09-22.15-49-33' filename: log.txt
Zigbee2MQTT:info  2020-09-22 15:49:33: Starting Zigbee2MQTT version 1.14.4 (commit #1.14.4)
Zigbee2MQTT:info  2020-09-22 15:49:33: Starting zigbee-herdsman...
Zigbee2MQTT:error 2020-09-22 15:49:58: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2020-09-22 15:49:58: Failed to start zigbee
Zigbee2MQTT:error 2020-09-22 15:49:58: Exiting...
Zigbee2MQTT:error 2020-09-22 15:49:58: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
    at ZStackAdapter.<anonymous> (/zigbee2mqtt-1.14.4/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:90:31)
    at Generator.throw (<anonymous>)
    at rejected (/zigbee2mqtt-1.14.4/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:25:65)

[ciotlosm]

@baldfox check out https://github.com/danielwelch/hassio-zigbee2mqtt/issues/398#issuecomment-696166580

[baldfox]

@baldfox check out #398 (comment)

Thank you for that. I had a spare cc2531 lying around so flashed that and swapped it in and Z2M is working again.
I've managed to reflash the original cc2531 so will try that again and see if that works as before.

[megavolts]

Running on CC26x2R1, I run into similar problem with zigbee2mqtt failing to start, below the only log I was able to pull out of docker, before it restart by itself.

info  2020-09-24 20:05:57: Logging to console and directory: '/app/data/log/2020-09-24.20-05-57' filename: log.txt
info  2020-09-24 20:05:58: Starting Zigbee2MQTT version 1.14.4-dev (commit #64a7840)
info  2020-09-24 20:05:58: Starting zigbee-herdsman...
error 2020-09-24 20:07:08: Error while starting zigbee-herdsman

I fiddled around, and found that z2m failed to start if I add any advanced configuration like setting the channel or availability_timeout.

homeassistant: true permit_join: true mqtt: base_topic: zigbee2mqtt server: '192.168.1.2' user: **** password: **** serial: port: /dev/ttyACM0

[ciotlosm]

@megavolts can you please open a new issue for that? This issue should be related to the change from blacklist to blocklist and similar. That way we don't pollute this and are able to focus on fixing any potential issues that you discovered.

I also have CC26X2R1 (zzh!) adapter and I have availability_timeout channel set, so the problem is somewhere else.

[scutaru]

hey ho... reseting the cc2531 did the trick - big thanks for you help 1st_place_medal

It worked for me too, but only for 1 or 2 days. After that, it started showing the same error.

_Zigbee2MQTT:info  2020-09-25 13:30:35: Starting Zigbee2MQTT version 1.14.4 (commit #1.14.4)
Zigbee2MQTT:info  2020-09-25 13:30:35: Starting zigbee-herdsman...
Zigbee2MQTT:error 2020-09-25 13:31:15: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2020-09-25 13:31:15: Failed to start zigbee
Zigbee2MQTT:error 2020-09-25 13:31:15: Exiting...
Zigbee2MQTT:error 2020-09-25 13:31:15: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
    at ZStackAdapter.<anonymous> (/zigbee2mqtt-1.14.4/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:90:31)
    at Generator.throw (<anonymous>)
    at rejected (/zigbee2mqtt-1.14.4/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:25:65)_

[ciotlosm]

Closing this issue as people are posting problems that are unrelated to initial problem.
@scutaru your issue is not with the add-on, but with communication between adapter and z2m. Read through https://github.com/Koenkk/zigbee2mqtt/issues/2997 maybe you find more details and a solution.