I am attempting to use the state of a helper as an entity id:
platform: state
entity_id: "{{ states('sensor.incident_1') }}"
attribute: status
I chuck the above in the yaml editor and the header of the trigger displays:
Error in describing trigger: Cannot read properties of undefined (reading ‘entity_id’)
I have checked the output in the dev tools template tab and it is showing the correct value. I copy and paste that value into the dev tool states tab and it displays the correct entity. The entity name matches exactly.
Maybe you can help though. I have very limited coding experience.
I am pulling geo.location data from a nsw_rural_fire_service feed. Which comes form the nsw rural fire service API by way of an integration entered into configuration.yaml.
The way the integration works is that it pulls each incident within a radius in as geo.location.super_specific_name_of_the_incident. The incident name is the location of the fire and therefore completely random and unpredictable. This makes it difficult to use for automations.
I am creating an automated fire sprinkler system to trigger off various things. Some of those things are the attributes in an incident - like distance and lat/long, but not knowing what the incident will be named is difficult. And I gave up on wildcards because it seemed like there was no way to do that.
So. I created a helper which outputs a list of those incidents.
Then created a bunch of other helpers which clean and split that list into individual helpers (incident_1, incident_2, incident_3 etc), therefore giving me a bunch of helpers that output the specific entity name (eg. “geo_location.nsw_fire_service_feed_advice_shannons_flat_rd_shannons_flat”).
I was hoping to use that output as the entity name in an automation.
Do you (or anyone here) have any ideas how to achieve this? There’s probably a really obvious solution.
Have you looked into the Geolocation trigger, I’m pretty sure NSW rural fires is supported.
If that won’t work for you, it may be possible to construct a Template trigger that would work, but you would need to share a bit more about the goal and specifics of the automation.
Sure. The background is to create a sub AUD$500 Automated sprinkler system for a house in a flame zone, all zigbee using zha so automations run locally and aren’t dependent on WAN. Remote controllable and observable by cams, but when the internet goes, the fallback is local automations (it has UPS).
This to be retrofitted on existing fire sprinkler systems that require people to stay later to activate at the right time (and risk death). All using open source and components people can purchase themselves and not have to spend $50k for the privilege of not dying in an emergency.
I currently have a workable solution. Which is splitting the feed into 3 entity namespaces. One for ‘advice’ (lowest risk), one for ‘watch and act’ (more risk) and one for ‘emergency warning’ (immediate risk). And probably buying some temp sensors to measure the perimeter for non-weather temperature rises.
It currently triggers off ‘emergency warning’ if a new emergency entity enters a fairly tight radius. That sends an actionable notification to either kick off the sprinklers, cancel the sprinklers or if no input is received, start a timer before the system starts operating autonomously.
This is clunky so i wanted to refine it. And refine the automations to maximise the use of water (which comes from a tank). I have maximised it somewhat by having the sprinklers turn on and off in pre determined intervals, not just run full bore until empty.
You don’t want it triggering for a fire to the north of you with a southerly wind blowing. You want it triggering for a fire to the north with a northerly wind blowing. That’s where using attributes comes in because “geo_location.nsw_fire_service_feed_advice_shannons_flat_rd_shannons_flat” has location attributes. And also attributes on the status (eg. Out of control, under control, being controlled).
I am just playing around with possibilities for refinement at this stage while keeping the cost low and accessible.
I should add: I am not selling this (this kinda came across as a “pitch” lol). I will have it installed on someone else’s guinea pig house this weekend. But definitely want people to know what can be done if they buy a couple of zigbee servos, an old pc and a skyconnect at quite a low cost. And there’s a bit of interest in the town i am doing it in.
For future reference you can only use templates in or under these keys in the backend (automations and scripts):
data:
target:
service:
value_template:
Even less in the frontend (dashboards): markdown card
There are a few other special cases that are outlined in the docs. In general if the documentation for an option does not mention it supports templates, then it doesn’t.
The first is what i was after. I wanted the attribute value of the entity id which equals the state value of sensor.incident_1
Now i can automate off the attributes of a dynamic and wildly unpredictable entity id. And the way i have the helpers set up, they’ll automatically update.