I’m not sure of what you are after, but I’ll do my best to answer this
So - given that the goal of this thread was to populate an input_select list, the ideal information source to achieve this would be a list of things, AKA an array.
In my case I created a sensor deliberately to provide this list/array - sensor.synoplayers - which is essentially a JSON payload containing a list of available wireless speakers within it.
“for item in states.sensor.synoplayers.attributes.data.players” basically means "for each player in the sensor list, process it and call it ‘item’ ". The rest of the logic ensures that a comma is added unless after the last item in the list.
The result is the JSON style payload we use to set the ‘input_select’ options. The logic takes the source JSON array from my sensor, and uses it to fill the “options” that the input_select.syno_players requires. By specifying {{ item.name }} I am only populating it with the remote speakers names.
payload: >-
{
"entity_id": "input_select.syno_players",
"options": [
{%- for item in states.sensor.synoplayers.attributes.data.players %}
"{{ item.name }}" {% if not loop.last %}, {% endif %}
{%- endfor %}
]
}
thanks!
i realize i might have deviated a little… but thought with a smal adaptation the template could be changed to disclose all attributes of a single entity:
in this case the sensor.control_room_motion_sensor:
so I would be after the template bit of your code, not as much the setting the options part. Along the lines of:
{%- for attributes in states(‘sensor.control_room_motion_sensor.attributes’) %}
“{{ attributes.name, attributes.value }}” {% if not loop.last %}, {% endif %}
{%- endfor %}
{% for attribute in states.sensor.control_room_motion_sensor.attributes %}
{{ attribute }} = {{ states.sensor.control_room_motion_sensor.attributes[attribute] }}
{% endfor %}
was kinda hoping that specifying the entity a second time wouldn’t have to be necessary. this seems somewhat more hard coded, not as templatative as the other loops-construction. Gets the job done though.
cool.
indeed, thank you! great resource.
seems not really easier, but has the advantage of the more flexible template. Will certainly give that further study. on my list: 3, 4, 7, 10 (needs some extra work), 11, 12… wow, this is really great stuff for the dev-toolbox
{{ states | map(attribute=‘domain’) |list | unique | list}}
would you know of a way to list all components used in the setup? They tend to get buried in more then 1 configuration file, a template finding all of them would be way useful. Of course ‘platform’ isnt an attribute of ‘state’, but something similar would be much appreciated.
Unfortunately this method works on a collection of objects - all with similarly named attributes. I can’t see how the method could be made to work the way you want - i.e. cycling through all the attributes in a single object . It looks like Notorious has spelt it all out well though anyway
this is exactly what I am looking for, but I cant get in… in no way I have been able to get the curl command correct yet, or even get into the https://base_address:8123/api/?api_password=My_API_Password
tried both the duckdns (which is forwarded already), or the hassio.local:8123/api
curl: (3) Illegal characters found in URL (which is probably pointing to the password containing characters other than the alphabet, and
curl: (6) Could not resolve host: (and then it shoes my password…)
https://hassio.local:8321/api?api_password=[password] says the same…is the api in effect at all? Maybe a setting somewhere has to be enabled in the configuration ? I dont have that now, since i have the frontend, and that seems to be correct since the rest-api page says:
If you are not using the frontend in your setup then you need to add the api component to your configuration.yaml file.
Don’t think so, not sure what that is… I have tried
hassio.local:8123/api?api_password=[password] and
my_domain.duckdns:8123/api?api_password=[password] and
my_domain.duckdns/api?api_password=[password] (since duckdns.org is port forwarded it thought maybe the explicit :8123 wasn’t necessary?
https://my_domain.duckdns.org/api/config?api_password=[password_encoded] works! in the browser, as does https://hassio.local/api/config?api_password=[password_encoded]
thanks!
havent found my way in yet trying this as a curl command…
Hey @Jer78 this is pretty cool. I know you helped me a couple months back with some sonos groupings before that was really available. I was actually just going back through that thread trying to set it up again, Im curious if your still doing it that way or if there is a cleaner way now?
Id even like to add the ability of grouping rooms using voice. It looks like you need to specify a ‘master’ though when using the sonos_join service. I think that might get in the way, unless I can come up with a sensor and script to do that for me…hmmmm. I will work on this.
