Make device database persistent about hassio-zigbee2mqtt HOT 13 CLOSED

No worries! Ok, I've modified the add-on to use the ZIGBEE2MQTT_DATA environment variable now that the functionality has been merged into zigbee2mqtt. I'll wait to close this until we've tested it out.

from hassio-zigbee2mqtt.

Working on this persistence issue in zigbee2mqtt#39.

In addition to the database, the configuration file also needed to be persisted. So at that point, Koenkk suggested just making the entire data directory location configurable. This would be nice because we could specify the location within the mounted /share directory, and nothing else will really need to be done.

from hassio-zigbee2mqtt.

We should limit the times configuration.yaml is moved around to avoid problems

Not sure I understand this concern. The file should never be moved, should just stay in whatever data directory is specified (in the add-on’s case, probably something like /share/zigbee2mqtt/). The copying I mention is a one-time thing, in case the user has failed to create a configuration file, that allows the addon to start with the default config rather than fail.

from hassio-zigbee2mqtt.

Can you describe what you mean by the device database? Sorry if I'm missing something obvious here, but is this referring to how devices are persisted in configuration.yaml?

from hassio-zigbee2mqtt.

We need to extract: https://github.com/Koenkk/zigbee2mqtt/blob/master/lib/zigbee.js#L8 as a configuration so you can pass it as option from the addon.
And store it in a shared folder outside of the container.

from hassio-zigbee2mqtt.

Got it. So that’s going to require changes to zigbee2mqtt, correct?

from hassio-zigbee2mqtt.

Either that or a very ugly hack to parse that js file 😸

from hassio-zigbee2mqtt.

@Koenkk do you think you could help with making https://github.com/Koenkk/zigbee2mqtt/blob/master/lib/zigbee.js#L8 extracted inside configuration.yaml ?

 dbPath: `${__dirname}/../data/database.db`

from hassio-zigbee2mqtt.

I've raised: Koenkk/zigbee2mqtt#34 as it seems there might also be a problem running two instances on zigbee2mqtt with two CC2531 on different devices.

from hassio-zigbee2mqtt.

I don't think the configuration needs to be persisted. The way I see it is that "friendly names" section has to be persisted, but I don't think that should be in the same file as the rest of the configuration we set at start time.

from hassio-zigbee2mqtt.

Well with this approach, we wouldn’t necessarily be writing the configuration file at start time, but instead the file could be created in the mounted share dir ahead of time. Or, if the file doesn’t exist, it will be copied in from the container, and then can be edited.

"friendly names" section has to be persisted, but I don't think that should be in the same file as the rest of the configuration we set at start time.

Maybe so, but that’ll take changes in the zigbee2mqtt library. This approach handles persisting the database, logging files, and (if indeed necessary) the configuration file.

from hassio-zigbee2mqtt.

We should limit the times configuration.yaml is moved around to avoid problems. I agree that for the moment it can work like this.

I think writing the configuration with values from options.json at start time removes any unpredictable results. One of they key functionalities (starting pairing mode or not) will be using this method for now until an mqtt command could be implemented.

from hassio-zigbee2mqtt.

I think all extra copying I saw disappeared 👍 My bad for not checking latest code again.

from hassio-zigbee2mqtt.