#finally committed input dictionary
1 messages · Page 1 of 1 (latest)
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" }}
What is a dictionary entity?
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
Usually changes / additions to entity models go through an architecture discussion first.
oh i wasnt aware! But i've added a new component rather than modifying an existing one to avoid any compatibility issues
As far as I can tell you did add a whole new Entity subclass. https://developers.home-assistant.io/docs/core/entity#changing-the-entity-model
Its no problem to vendor it via a custom component (or via HACS).
But to get into core I guess there would need to be support for all core-things like history and frontend etc.
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!
Well, it can't hurt to have a reference implementation if you decide to start an architecture discussion 😉