[FEATURE] Persist Bridge/Accessory/Service state

[Shaquu]

I looked a little and it looks like there is many lines of code which try to load accessories or services from prepared data but it's actually never saved (if I am not wrong...)!!!

node.debug("Looking for accessory with UUID '" + accessoryInformation.UUID + "'...");

    for (let i in bridge.bridgedAccessories) {

node.debug("Looking for service with UUID '" + serviceInformation.UUID + "'...");

    for (let i in accessory.services) {

There is a ready method to load accessories from directory in HAP-nodejs/AccessoryLoader.js/loadDirectory.

Now have to look if save/load is needed or we should just remove unnecessary code from our plugin which tries to find existing accessories.

[sjorge]

Having the accessories remember the last state they were in would be a great addition.

Currently I do this by using a persistent node in front of them to save a copy of the last command and to restore it at startup. Which works fine too, but it could be cleaner :)

[sjorge]

Is this something that will eventually be tacked? If so I will leave my horrible persistant nodes in place.
While driving today I though of a way better way to do it, but having that option as a toggle on the homekit service, would of course still be 100x better :) (Thanks for all the work so far BTW!)

[Shaquu]

Thanks for a thanks :) Next release should be about fixing many problems and adding feature to save accessories per bridge. It’s good to comment right now how do you see it so I can plan better how to make it.

…

Wiadomość napisana przez Jorge Schrauwen ***@***.***> w dniu 10.03.2019, o godz. 14:24: Is this something that will eventually be tacked? If so I will leave my horrible persistant nodes in place. While driving today I though of a way better way to do it, but having that option as a toggle on the homekit service, would of course still be 100x better :) (Thanks for all the work so far BTW!) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[crxporter]

Could this be the right place to talk about initial and restore on restart values?

Examples:
Set my presence switch is on at reboot
Set valve type irrigation
Reset thermostat to my preferred setting

And so on.

[Shaquu]

Yup, it’s time for that. Setting initial values should be another text area in node editor in my opinion.

…

Wiadomość napisana przez crxporter ***@***.***> w dniu 10.03.2019, o godz. 19:21: Could this be the right place to talk about initial and restore on restart values? Examples: Set my presence switch is on at reboot Set valve type irrigation Reset thermostat to my preferred setting And so on. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[sjorge]

I see two 'clean' solutions for this.

Option 1, add a checkbox called persist to the service node.
When this is set, the values are store everytime they are update (or once every minute or something on change) and restore at startup.

Option 2, have a table where you can set characteristics and either set a value or restore for that characteristic. If a value is provided, that will be the value after startup. If it is set to restore the last value will be restored on startup. (Of course that also means all characteristic with restore set should be saved when they are updated.) See node-red-dashboard-ui's form node for an example of such a table.

Option 2 is definitely the most flexible! As you can pick a default value or tell it to restore a value per-characteristic. However Option 1 is way easier to implement and is probably sufficient for most cases.

[sjorge]

I guess option 2 would replace the current textbox to set default values. (Keeping this backwards compatibly should be possible if you parse the json in that field and use that as a basis to display the table.

{"MotionDetect": true} would then map to a MotionDetect characteristics with default value of 'true'

{"MotionDetect": false, "StatusTamper": restore} would then map to to a MotionDetect characteristics with default value of 'false' and StatusTamper set to 'restore'. But a table is cleaner to update.

This also has a small bonus, as the list of Characteristics and there value types is know, you can display that in the table when adding/removing new characteristics.

[crxporter]

I guess option 2 would replace the current textbox to set default values

Recent discoveries have revealed that the current text box doesn't SET values it just tells HomeKit to expect those values.

See discussion around here

[sjorge]

Well that would make it even easier to keep backwards compatibility!