I like the concept.
Ideally, the integration would offer an action to write to the Object Registry.
I see the practicality, of using the Object Registry to separate data from logic, if multiple automations/scripts need to reference the same data; it prevents data duplication.
However, I am unconvinced of its utility if just one automation/script requires the data. In that case, my preference would be to keep the data within the sole automation/script that needs it. To separate data from logic, it can be stored in the automation's variables.
Based on this screenshot, it appears all of the JSON is composed manually in the editor (without any automated assistance from the editor).
Personally, I don't find writing data structures in JSON to be easier than YAML.
For example, the YAML equivalent of this hairy bit of JSON:
{
"sensor.main_left_remote_a_b": {
"target": "light.main_bedroom",
"controls": {
"DON": {
"action": "light.turn_on"
},
"DOF": {
"action": "light.turn_off"
},
"DFON": {
"action": "light.turn_on",
"data": {
"brightness_pct": 100,
"xy_color": [
0.422,
0.399
],
"transition": 0.1
}
}
}
}
}
is this:
sensor.main_left_remote_a_b:
target: light.main_bedroom
controls:
DON:
action: light.turn_on
DOF:
action: light.turn_off
DFON:
action: light.turn_on
data:
brightness_pct: 100
xy_color:
- 0.422
- 0.399
transition: 0.1
It's arguably simpler to compose because it doesn't need braces, double-quotes, or commas (just correct indentation).
All this to say that an automation can be structured like this where the logic is at the top, the data at the bottom, and the data is easy to modify.
alias: example
triggers:
...
conditions:
...
actions:
...
variables:
registry:
sensor.main_left_remote_a_b:
target: light.main_bedroom
controls:
DON:
action: light.turn_on
DOF:
action: light.turn_off
DFON:
action: light.turn_on
data:
brightness_pct: 100
xy_color:
- 0.422
- 0.399
transition: 0.1
Where several automations need access to shared data, I think your Object Registry fulfills the requirement very well. However, if it's just one automation then, in my opinion, it's easily done with variables alone.
Whether you agree with my opinion or not, I offer you two simplified versions of your automation example.
The first version uses the Object Registry but its logic has been simplified.
Simplified version using Object Registry
alias: ISY Insteon Remote Router
description: >
Routes ISY remote button events to HA actions via the Object Registry. All
mapping config lives in the isy_button_map registry object.
triggers:
- trigger: event
event_type: isy994_control
variables:
source_entity: "{{ trigger.event.data.entity_id | default('') }}"
control: "{{ trigger.event.data.control | default('') }}"
source_labels: "{{ labels(source_entity) if source_entity else [] }}"
conditions:
- condition: template
value_template: |-
{{ source_entity != ''
and control != ''
and 'isy_insteon_remote_button' in source_labels }}
actions:
- action: object_registry.get_data
data:
object_id: isy_button_map
response_variable: button_map
- variables:
mapping: "{{ button_map.get('data', {}) }}"
remote_config: "{{ mapping.get(source_entity, {}) }}"
target_entity: "{{ remote_config.get('target', '') }}"
control_config: "{{ remote_config.get('controls', {}).get(control, {}) }}"
mapped_action: "{{ control_config.get('action', '') }}"
action_data: "{{ control_config.get('data', {}) }}"
- if:
- condition: template
value_template: "{{ mapped_action != '' and target_entity != '' }}"
then:
- action: "{{ mapped_action }}"
target:
entity_id: "{{ target_entity }}"
data: "{{ action_data }}"
else:
- action: persistent_notification.create
data:
title: ISY Router Unhandled
message: >-
No mapping found for control {{ control }} from {{
source_entity }}.
mode: queued
max: 20
The second version uses variables and its logic is even simpler, largely because it doesn't need to retrieve data with an action.
Simplified version using variables
alias: ISY Insteon Remote Router
description: >
Routes ISY remote button events to HA actions via variables.
triggers:
- trigger: event
event_type: isy994_control
variables:
source_entity: "{{ trigger.event.data.entity_id | default('') }}"
control: "{{ trigger.event.data.control | default('') }}"
source_labels: "{{ labels(source_entity) if source_entity else [] }}"
conditions:
- condition: template
value_template: |-
{{ source_entity != ''
and control != ''
and 'isy_insteon_remote_button' in source_labels }}
actions:
- variables:
remote_config: "{{ registry.get(source_entity, {}) }}"
target_entity: "{{ remote_config.get('target', '') }}"
control_config: "{{ remote_config.get('controls', {}).get(control, {}) }}"
mapped_action: "{{ control_config.get('action', '') }}"
action_data: "{{ control_config.get('data', {}) }}"
- if:
- condition: template
value_template: "{{ mapped_action != '' and target_entity != '' }}"
then:
- action: "{{ mapped_action }}"
target:
entity_id: "{{ target_entity }}"
data: "{{ action_data }}"
else:
- action: persistent_notification.create
data:
title: ISY Router Unhandled
message: >-
No mapping found for control {{ control }} from {{
source_entity }}.
mode: queued
max: 20
variables:
registry:
sensor.main_left_remote_a_b:
target: light.main_bedroom
controls:
DON:
action: light.turn_on
DOF:
action: light.turn_off
DFON:
action: light.turn_on
data:
brightness_pct: 100
xy_color:
- 0.422
- 0.399
transition: 0.1
DFOF:
action: light.turn_on
data:
color_temp_kelvin: 2710
brightness: 122
transition: 2
FDUP:
action: hue_dimmer.raise
data:
sweep_time: 8
FDDOWN:
action: hue_dimmer.lower
data:
sweep_time: 8
FDSTOP:
action: hue_dimmer.stop
sensor.main_right_remote_a_b:
target: light.main_bedroom
controls:
DON:
action: light.turn_on
DOF:
action: light.turn_off
DFON:
action: light.turn_on
data:
brightness_pct: 100
xy_color:
- 0.422
- 0.399
transition: 0.1
DFOF:
action: light.turn_on
data:
color_temp_kelvin: 2710
brightness: 122
transition: 2
FDUP:
action: hue_dimmer.raise
data:
sweep_time: 8
FDDOWN:
action: hue_dimmer.lower
data:
sweep_time: 8
FDSTOP:
action: hue_dimmer.stop
sensor.main_bedroom_8btn_switch_c:
target: light.main_bedroom
controls:
DON:
action: light.turn_on
DOF:
action: light.turn_off
DFON:
action: light.turn_on
data:
brightness_pct: 100
xy_color:
- 0.422
- 0.399
transition: 0.1
DFOF:
action: light.turn_on
data:
color_temp_kelvin: 2710
brightness: 122
transition: 2
FDUP:
action: hue_dimmer.raise
data:
sweep_time: 8
FDDOWN:
action: hue_dimmer.lower
data:
sweep_time: 8
FDSTOP:
action: hue_dimmer.stop
sensor.office_remote_b:
target: light.office
controls:
DON:
action: light.turn_on
DOF:
action: light.turn_off
DFON:
action: light.turn_on
data:
brightness_pct: 100
xy_color:
- 0.422
- 0.399
transition: 0.1
DFOF:
action: light.turn_on
data:
color_temp_kelvin: 2710
brightness: 122
transition: 2
FDUP:
action: hue_dimmer.raise
data:
sweep_time: 8
FDDOWN:
action: hue_dimmer.lower
data:
sweep_time: 8
FDSTOP:
action: hue_dimmer.stop
sensor.guest_remote_a:
target: light.guest_bedside
controls:
DON:
action: light.turn_on
DOF:
action: light.turn_off
DFON:
action: light.turn_on
data:
brightness_pct: 100
xy_color:
- 0.422
- 0.399
transition: 0.1
DFOF:
action: light.turn_on
data:
color_temp_kelvin: 2710
brightness: 122
transition: 2
FDUP:
action: hue_dimmer.raise
data:
sweep_time: 8
FDDOWN:
action: hue_dimmer.lower
data:
sweep_time: 8
FDSTOP:
action: hue_dimmer.stop
Naturally this version's overall length is greater because variables contains all of the data (in YAML) that would have been stored in the Object Registry (in JSON).
FWIW, I tested a modified version of the second example on my system and it worked well. I used Developer tools -> Events to simulate isy994_control events and was able to control a light's state and brightness via different control values.
I normally do this using a long-winded choose, with the actions and targets "hard-coded" in its choices, but I like this logic/data approach. In terms of legibility, instead of scrolling through a lengthy choose, I get a compact summary of all controlling events and associated actions for a given light.
target: light.main_bedroom
controls:
DON:
action: light.turn_on
DOF:
action: light.turn_off
DFON:
action: light.turn_on
data:
brightness_pct: 100
xy_color:
- 0.422
- 0.399
transition: 0.1
