russellhq commented 4 years ago

Bug Report

What happened

zigbee2mqtt crashes when my zigbee adapter (CC2530 board with CC2591 connected to Wemos D1 Mini running ESP Easy Serial Server) restarts or loses WiFi connection.

What did you expect to happen

zigbee2mqtt to wait for adapter to come back online.

How to reproduce it (minimal and precise)

Reboot ESP Easy from web interface or restart WiFi access point the Wemos is connected to

Debug Info

zigbee2mqtt version: zigbee2mqtt version 1.12.0 (commit #840b9d9) CC253X firmware version:

zigbee2mqtt:error 2020-04-11 08:39:10: Adapter disconnected, stopping
zigbee2mqtt:info  2020-04-11 08:39:10: MQTT publish: topic 'zigbee2mqtt/big_light_switch/availability', payload 'offline'
zigbee2mqtt:info  2020-04-11 08:39:10: MQTT publish: topic 'zigbee2mqtt/big_light/availability', payload 'offline'
zigbee2mqtt:info  2020-04-11 08:39:10: MQTT publish: topic 'zigbee2mqtt/kitchen_light/availability', payload 'offline'
zigbee2mqtt:info  2020-04-11 08:39:10: MQTT publish: topic 'zigbee2mqtt/ikea_hall_light/availability', payload 'offline'
zigbee2mqtt:info  2020-04-11 08:39:10: MQTT publish: topic 'zigbee2mqtt/ikea_landing_light/availability', payload 'offline'
zigbee2mqtt:info  2020-04-11 08:39:10: MQTT publish: topic 'zigbee2mqtt/bens_lamp/availability', payload 'offline'
zigbee2mqtt:info  2020-04-11 08:39:10: MQTT publish: topic 'zigbee2mqtt/bens_room_light/availability', payload 'offline'
zigbee2mqtt:info  2020-04-11 08:39:10: MQTT publish: topic 'zigbee2mqtt/bedroom_light/availability', payload 'offline'
zigbee2mqtt:info  2020-04-11 08:39:10: MQTT publish: topic 'zigbee2mqtt/ikea_remote/availability', payload 'offline'
zigbee2mqtt:info  2020-04-11 08:39:10: MQTT publish: topic 'zigbee2mqtt/aqara_hall_sensor/availability', payload 'offline'
zigbee2mqtt:debug 2020-04-11 08:39:10: Saving state to file /opt/zigbee2mqtt/data/state.json
zigbee2mqtt:info  2020-04-11 08:39:10: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload 'offline'
zigbee2mqtt:info  2020-04-11 08:39:10: Disconnecting from MQTT server
(node:20344) UnhandledPromiseRejectionWarning: Error: AREQ - AF - dataConfirm after 5000ms
    at Timeout._onTimeout (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)
    at listOnTimeout (internal/timers.js:549:17)
    at processTimers (internal/timers.js:492:7)
(node:20344) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:20344) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
(node:20344) UnhandledPromiseRejectionWarning: Error: AREQ - AF - dataConfirm after 5000ms
    at Timeout._onTimeout (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)
    at listOnTimeout (internal/timers.js:549:17)
    at processTimers (internal/timers.js:492:7)
(node:20344) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:20344) UnhandledPromiseRejectionWarning: Error: Timeout - 57017 - 3 - 2 - 0 - 1 after 6000ms
    at Timeout._onTimeout (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/utils/waitress.js:44:24)
    at listOnTimeout (internal/timers.js:549:17)
    at processTimers (internal/timers.js:492:7)
(node:20344) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 3)
zigbee2mqtt:error 2020-04-11 08:39:16: Failed to ping 'kitchen_light'
zigbee2mqtt:error 2020-04-11 08:39:16: Failed to ping 'ikea_landing_light'
zigbee2mqtt:error 2020-04-11 08:39:16: Failed to ping 'bens_lamp'
zigbee2mqtt:error 2020-04-11 08:39:16: Failed to ping 'bens_room_light'
zigbee2mqtt:error 2020-04-11 08:39:16: Failed to ping 'bedroom_light'
zigbee2mqtt:error 2020-04-11 08:39:16: Failed to stop zigbee
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! zigbee2mqtt@1.12.0 start: `node index.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the zigbee2mqtt@1.12.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /home/pi/.npm/_logs/2020-04-11T07_39_16_523Z-debug.log

swissbyte commented 4 years ago

I dont think that disconnecting during usage is a typical use-case. But if implementing a "try-again" algorithm is easy, then this would be nice.

Koenkk commented 4 years ago

I agree with @swissbyte

@russellhq I recommend to setup a supervisor to automatically restart zigbee2mqtt when it crashes.

russellhq commented 4 years ago

@swissbyte , @Koenkk , I've now set up z2m as a service which restarts whenever z2m crashes. Would still be handy if z2m handled disconnects. Because I use a wemos running esp easy to create a wireless serial connection, if I make any changes in esp easy which need a restart, it kills z2m.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

sjorge commented 4 years ago

I think a similar crash happens when you reset them ZNC via mqtt. So some sort of better handling around this would still be nice to have.