Closed ciotlosm closed 6 years ago
I think this should be lower priority as this should not trigger once pairing is turned to false.
I talked to a few colleagues and it might be that using pm2 inside the container might do the trick. It's not worth messing with the control outside of the container because the supervisor in hassio is supposed to take care of the lifecycle of the container.
I will have a bit more time this week to continue with testing, and if all works out I'll get all my sensors moved over. I have 7 more sticks on the way to power my dev instance for more work /testing.
After looking into it I came to the same conclusion. I don’t have much experience with the JS ecosystem but found this and looks like it’d be as easy as changing the start script to something like:
pm2 start npm -- start
Putting this here for my reference:
http://pm2.keymetrics.io/docs/usage/application-declaration/#json-format
May be able to move some of the environment setup/configuration into a pm2 process file, which can be written on start.
@danielwelch i've implemented a simple pm2 implementation in https://github.com/danielwelch/hassio-zigbee2mqtt/pull/21. I've avoided to add the pm2 on debug branch, as then you wish stuff to fail and stop. I think we should not change to move options to pm2 as that should just be a safeguard to keep the process up. Ideally we should not need pm2 in the long run if we get everything else stable.
pm2 usually goes int he background so i used pm2-runtime that is recommended for docker. I'll wait for you to give it a go as well and the close the issue.
There is a bug https://github.com/Koenkk/zigbee2mqtt/issues/29 which seems to be somewhere inside zigbee-shepherd. This causes the process to fail and the addon just stops.
Find a better way of error handling this inside the library to avoid a total crash of the process.