Were you running a 0.115.0 Beta ?
no, heavily awaiting that, but there’s no beta live yet?
Yeah I didn’t think so (wasn’t sure)
So how/what were you testing ?
I was thinking that.
Let’s hope the release notes are up to the job 
Speaking of which, I used top be able to find them before they were live but now I can’t.
Can someone point me in the right direction.
I like to be prepared 
1 Like
They get released with the beta, which has been pushed back. See:
1 Like
I have a template sensor defined to work with the Alexa Media Player integration to get the last device which was used. It looks like this currently:
last_alexa_device:
value_template: >-
{{ states.media_player
| selectattr('attributes.last_called','eq',True)
| map(attribute='entity_id') | first }}
entity_id:
- media_player.bedroom
- media_player.computer_room
- media_player.kitchen
Would the new template parsing work with this without entity_id or would I be better with something like this?
last_alexa_device:
value_template: >-
{{ [states.media_player.bedroom,
states.media_player.computer_room,
states.media_player.kitchen]
| selectattr('attributes.last_called','eq',True)
| map(attribute='entity_id') | first }}
Until bdraco supplies the definitive answer, here’s my guess:
First version gets listeners assigned to every media_player you have based on states.media_player (and assumes you remove entity_id, because it’s deprecated).
Second version gets three listeners assigned, one for each of the identifiable entities.
from my understanding of what @bdraco said, the template now searches for accessed state object instead of regex string parsing. So if your template access a state object, that state objects entity_id is added to the listeners.
Yeah, I think you’re correct.
And in @Mariusthvdb’s case, his weekday changes will only update during the weekdays and his weekend changes will only update during the weekend. So he should use the rewritten macro. Unless new listeners are dynamically added (and never removed). Then his template will work after a full week has passed.
@klogg’s should work all the time.
If it works the way I described, it means it’s very generous in how it interprets/identifies entities but also means it’s equally generous in how many listeners it assigns.
I’m sort of hoping to be corrected on this point because if your template begins with states.sensor it will get listeners for all sensors in your system. That’s overly generous, especially if the rest of the template narrows it down to just a handful of sensors that you actually want to monitor.
really sorry but I completely missed that… will need some close eyes what has fundamentally changed in your new macro, but will add it now and restart. So you say I dont need the entity_ids now? Since they are explicitly named in the macro I presume?
thanks again!
It does make those count sensors super easy and makes the 0.104 group_all removal crap a simple 1 liner fix.
S H I T
Don’t quote me just yet. That’s just my guess and it’s not based on firsthand experience or examination of the code.
You’ll need to access all the entities every shot if you want them as listeners. Your current template only access weekend entities on the weekend and weekday entities on the weekdays.
No, I understood that.
But … That is ONE possible interpretation of the statements made so …
Will await clarification
We live in interesting times …
yes, just tested: even with the new macro, I need all entity_ids listed for the large timestamp sensor to update and trigger updating the other sensors correctly.
The way I understand it (although I may be mistaken) with the current system, if you have any entities listed under entity_id you need to have them all listed as it overrides the automatic parsing, so does it work if you remove all the entities?
You’d possibly also need to reference states(‘sensor.time’) somewhere in the template as well.
If you iterate states.sensor, you will get a listener for all sensors on the system, and for the creation of new sensors. That’s not as bad as it sounds since we now have indexed listeners as of 0.113. Before 0.113, everything would listen for the state change events and then filter them out when they fired. We do a bit of optimization to avoid re-render templates that it doesn’t affect, but if the template iterates all the sensors it has to listen for all sensor state changes.
1 Like