Custom component: Saver

Share your Projects! Custom Integrations
42

Yes, just one way of configuration should be used

43

ok, it’s fine now.
all saved entities are saved on saver.save and well restored.
saver.save_2 is still displayed but not used.

perhaps add a comment on https://github.com/PiotrMachowski/Home-Assistant-custom-components-Saver to warn : never add in the YAML if using UI (but maybe i’m too noob … :wink: )

thanks.

44

Saver v2.0.0

Now supports restoring states without manual scripts!

45

Hello,

I try to solve something similar what was mentioned here earlier: store multiple versions of an entity state permanently

It is clear the default HA Scene does not support permanent storage and the Saver does not support multiple stored states of the same entity.

As a workaround I tried to put a single light entity into several Light Groups (with Helpers) and store the state of the Light Groups. The result is promising.

example:

  • lightGroup1 is created to contain entityA
  • lightGroup2 is created to contain entityA
  • save_state of lightGroup1 → OK
  • save_state of lightGroup2 → OK
  • restore_state of lightGroup1 → OK
  • restore_state of lightGroup2 → not OK, it restores lightGroup1

So the states and the attributes are stored properly in the saver.saver entity.
The saved values can be retrieved correctly by the saver_entity function.

Unfortunately the restore_state action restores the firstly saved Light Group state. Likely it uses different method to identify the proper record then the saver_entity function.

Questions:
Can it be a feasible solution or I missed something fundamental?
Do you have the possibility to improve the restore_state to cover this use-case?

46

That’s a very specific case, but I thought it would work as well. Can you create a GitHub issue (for me to not forget about it)? Also please mention there what functionalities does your light have (On-off/brightness/color/…)

47

Thanks for the quick return.
The issue is created: Restore proper state of Light Groups · Issue #53 · PiotrMachowski/Home-Assistant-custom-components-Saver · GitHub

The lights are complex lights, including color, brightens, etc. That part seems to work properly, the attributes are restored fully and correctly when the “good” data record is selected.

1 Like
48

Thanks for this nice add-on.

I wanted to start using it for variables and one is an array.

Normally I can access special fields via e.g. {{ variable.list[0].name_a }}

But after storeing it into the saver variable it seems to store the whole as a string and I am not so familiar with yaml so far.

Is there a chance to access the same field like {{ saver_ variable(“variable.list[0].name_a”) }} ?

Sorry if this is too simple but expected no big yaml writing after announcing the GUI usage for variables here and want to make no usage error.

49

Have you tried {{ saver_variable("variable").list[0].name_a }} approach? If it doesn’t work then you can try playing with from_json and to_json

1 Like
50

Hello Piotr,

thanks for the reply, but HA is really somehow strange in programming options and return values in comparison to NodeRed or Homematic.

No,

{{ saver_variable("variable").list[0].name_a }} is not working.

Solutions I found are:
{{ (saver_variable("variable") | replace(''','"') | from_json).list[0].name_a }}

or

{% set hallo = saver_variable("variable") | replace(''','"') | from_json %}
{{ hallo.list[0].name_a }}

Thanks Joerg

1 Like
51

I think if you adjust data before saving with | to_json then | replace(''','"') part won't be necessary plus it would handle more data types

52

there is a misunderstanding. I made it not so difficult as you expect.
I simply used this from a function delivering a "response":

action: saver.set_variable
metadata: {}
data:
  name: variable
  value: "{{ response }}"

no "to_jason" was used!

This caused also my first expectation, that I can access the data without a re-formatting part.
But as described a working
response.list[0].name_a is not the same like saver_variable("variable").list[0].name_a
as the saver variable format is destroyed to a string.

53

Yeah, but with current approach saving e.g. True/False or data with quotes inside might fail. You can use the following approach instead.

Saving:

action: saver.set_variable
metadata: {}
data:
  name: variable
  value: "{{ response | to_json }}"

Reading:

{{ (saver_variable("variable") | from_json).list[0].name_a }}

{% set hallo = saver_variable("variable") | from_json %}
{{ hallo.list[0].name_a }}
1 Like
54

Thank you.
I understand: it is more robust with the defined conversion function and saves the character replacement.

Just for documentation the "saver"-variable content:

The difference is:
before:

variable: >-
{'list': [{'xxxx': 1234, 'name_a': 318, 'yyyy':'aaaa'}]}

using to_json:

variable: >-
{"list":[{"xxxx":1234,"name_a":318,"yyyy":"aaaa"}]}