[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 [email protected] 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 [email protected] 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!

[crxporter]

I like the table idea - what if each item on the table has two check boxes and a field?

Check box one says "enable this feature" (for example I'm using a dimmable bulb) Check box 2 says "restore on startup?" (enable persistence) The field can hold an initial value (ValveType 1 for irrigation)

It would be REALLY useful to have a list of available characteristics for each item. I'm not sure how difficult that is though to program.

[Shaquu]

So it will be a table :) I am pretty excited for that.

[sjorge]

Something like:

.----------------.---------.---------.--------.
| characteristic | restore | default | action |
+----------------+---------+---------+--------+
| Active         | [x]     | (true)  |    {-} |
| CurrentTemp    | [ ]     | (25     |    {-} |
+----------------+---------+---------+--------+
|                                 #char#  {+} |
'---------------------------------------------'

[ ] is a checkbox {label} is a button (text) is a textbox #list# is a dropdown list

So everything added will be an exported characteristic, so no need for a separate checkbox. This also keeps the interface clean by not displaying a massive list of all characteristics. (Optionally we can even filter the dropdown to only list supported characteristics, but that is taking away a lot of freedom from the user)

If both a default value and restore are set, it will restore the value.

A one-time parsing of the current text field can be done on upgrade were for every entry in the json object you add the corresponding row.

[Shaquu]

It looks like we could merge current Characterisitc Properties to this table. It's not endless JSON - I think we know all values that can get here. Look at this.

So according to this here are acceptable values in Properties:

this.props = props || {
   format: null,
   unit: null,
   minValue: null,
   maxValue: null,
   minStep: null,
   perms: []
 };

Plus:

validValues
validValueRanges
maxLen
maxDataLen

So let's think how to merge them smartly into table. I think actually we will base everything on Characteristic Properties from side of the code so there is no chance to break compatibility. So this:

{
    "CurrentTemperature": {
        "minValue": -100
    }
}

Will become this:

{
    "CurrentTemperature": {
        "minValue": -100,
        "defaultValue": 25,
        "persistState": true
    }
}

If it happen that Homekit or HAP-NodeJS come with values we used above (like defaultValue or persistState) then we will change these to something more unique if required.

[Shaquu]

I have made a working concept here.

[sjorge]

Maybe also add a to colomn that lists the type of the characteristic? As there seem to be a few like book, unint8, ...

[Shaquu]

List for information or choice? If second then we can put value in characteristics properties as in the 0.5

_{Sent with GitHawk}

[sjorge]

List for information or choice? If second then we can put value in characteristics properties as in the 0.5

Sent with GitHawk

Just an informational field that show the correct value from https://github.com/KhaosT/HAP-NodeJS/blob/master/index.d.ts#L269 for the selected characteristics.

[Shaquu]

I see. But how to do it smartly? Remember that user could change characteristic type in properites (I think). So worst situtation is when in properties it's int but we show info that it's string.

[Shaquu]

Okay I added placeholder on default value.

[Shaquu]

Updated concept here

[iRonin]

+1 for this

[iRonin]

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 could you please share more info? I'm new to NR.

[sjorge]

@iRonin I'm using this node https://flows.nodered.org/node/node-red-contrib-persist to store a copy of all the types of input I send to the homekit service

I then trigger the restore of it at startup. It's very ugly and messy, but it works.

[Shaquu]

Cool module but this (literals this...) feature is about something more. It's about persisting background data as well not values only.

[Shaquu]

TODO:

• Check if current concept is enough or if we can improve it.
• Implement persist data config node (like current Bridge node) so we could use the same config for many Service nodes if we want to (read and write of config is actually in node-red node)
• fetch current Charactersitics and other data like types and limits from hap-nodejs when opening Persist Data node

[sjorge]

I think the concept still looks pretty spot on.

[Tyraenor]

Hi guys,

still no persist option? Will it happen? This is really a dealbreaker, as it is not possible to use a switch for state exchange, as it will be reset after a deploy.

[Cyberbeni]

I would also like to have this. I'm currently migrating my window coverings from the homebridge broadlink plugin.

[Shaquu]

@Tyraenor more time required :) Things got complicated in life