#finally committed input dictionary

1 messages · Page 1 of 1 (latest)

feral gust
#

Here's a configuration.yaml example

input_dictionary:
  dictionarytest:
    name: test dictionary
    keyvalues: '{ "bedroom": "relax", "living": "bright" }'

Example input for Append service call -

service: input_dictionary.append_dictionary
data:
  keyvalues: '{"key1":"value1", "key2":"value2"}'
target:
  entity_id: input_dictionary.dictionarytest

Example for a "condition trigger" to use one of these key/values in an automation

condition: template
value_template: >-
  {{ (state_attr('input_dictionary.dictionarytest', 'dictionary').bedroom) ==
  "relax" }}
fervent violet
#

What is a dictionary entity?

feral gust
#

can hold custom "Key/Value" pairs.....any value against a key and retrieve it wherever

#

Dictionary can hold as many keys you want....and each key has a value you can assign to it. Reference this later in your scripts/automations

#

my use case is - for each room in my house - i save the current scene active. This is disturbed by motion sensors turning on lights and stuff - and once that's done, i can refer to what the active scene was to restore it

fervent violet
#

Usually changes / additions to entity models go through an architecture discussion first.

feral gust
#

oh i wasnt aware! But i've added a new component rather than modifying an existing one to avoid any compatibility issues

fervent violet
feral gust
#

makes sense - i have history, restore implemented too. All it's missing at the moment is a frontend helper implementation. but i see your point - i clearly jumped a few steps!

fervent violet
#

Well, it can't hurt to have a reference implementation if you decide to start an architecture discussion 😉