Make device database persistent

[ciotlosm]

No description provided.

[danielwelch]

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?

[ciotlosm]

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.

[danielwelch]

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

[ciotlosm]

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

[ciotlosm]

@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`

[ciotlosm]

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.

[danielwelch]

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.

[ciotlosm]

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.

[danielwelch]

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.

[ciotlosm]

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.

[danielwelch]

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.

[ciotlosm]

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

[danielwelch]

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.