That service doesn’t toggle groups, never has. That service only toggles switches. You should be using homeasssitant.toggle
2 Likes
Holy Cow!! Even after 3 years I learn about things that got added all the time. Thanks @petro, Very cool!!
There you go, never knew that.
just out of curiosity, how did this node red node work for 3 years then sometime between Christmas and now the entity has disappeared.
thanks anyway, at least I know what I’m doing today then, checking all my node red flows. 
Homeassistant services aren’t new. They were in the software when I started back in 2015/16
No clue, that shouldn’t have worked. I don’t use node red
Just a quick update: After all my preparation, I updated to 2022.4.7 today. As of right now, everything looks good. My ZHA network came right back and the database update only took a few seconds. CPU and memory utilization look about the same as before. I’ll keep monitoring, but so far so good…
Except for one little self-inflicted issue I won’t pollute this thread with. But if you want a chuckle, check it out here.
After I updated to 2022.4.7 from 2022.4.5 my Node-RED stopped working (kept getting 502 bad gateway error) anyone else have this happen? I reverted back to 2022.4.5 but got same issue, switched “require_ssl” to false and now it’s working again
Since updating to 2022.4 I have noticed a change in the way expand() works on groups in templates.
Currently, I have the following template sensors (among other similar ones also affected by this change):
- sensor:
- name: "Total Lights On"
unit_of_measurement: "On"
state: >
{{ expand('group.all_lights') | selectattr('state', 'eq', 'on') | list | count }}
- name: "Total Lights"
state: >
{{ expand('group.all_lights') | list | count }}
In my groups config the all_lights group is comprised of switches, lights, and light groups, which looks like this:
all_lights:
name: All Lights
entities:
- light.kitchen_sink
- light.kitchen_table
- light.living_room_lamp
- light.bathroom
- light.nursery
- light.bedroom_lamp
- switch.entrance_lights
- switch.makeup_room
- switch.backdoor_light
- switch.bedroom_fan
- light.office
- light.basement_hallway
- light.laundry_room
- switch.basement_lights
- switch.printer_light
- light.frontyard
- light.backyard
- switch.garage_light
Prior to 2022.4, {{ expand('group.all_lights') | list | count }} would return 18, 1 for each entity in the “all_lights” group.
After 2022.4, {{ expand('group.all_lights') | list | count }} returns 26, 1 for each switch and bulb in the “all_lights” group. It seems to be expanding each group within the group and summing the total.
Is there any workaround or way to get the old functionality back? On my dashboard, I want to see “2 lights on” not “6 lights on” when only my kitchen sink and kitchen table light fixtures are on (each of which contains 3 bulbs).
I’d rather not have to change that group (and several others) to instead be a list of all light switches and 1 bulb from each light group to get the desired functionality back… Suggestions?
1 Like
Good evening to everyone, i use some automations to manage requests via telegram via menu with buttons (inline keyboards) which trigger the event telegram_callback.
Then I get the trigger data via trigger.event.data.user_id which I use to identify the target to send the answer message. below is an example of an automation:
- id: telegram_salon_temperature
alias: telegram_temperature_room
trigger:
- platform: event
event_type: telegram_callback
event_data:
data: / temp_salon_request
action:
- service: telegram_bot.send_message
data_template:
target: '{{trigger.event.data.user_id}}'
message: 'room temperature = {{states (' 'sensor.salone_temperatura' ')}} C'
from version 2022.4.xx, however, I no longer receive the answers from the automation because the data from the event that triggered the automation are no longer collected.
Anyone know how to fix? thanks
Qucik question:
is there now a way to disable long term statistics or exclude them from recorder?
That’s… a confusing question.
Long-term statistics are created from the recorded history of numeric entities. If you exclude an entity from recorder then you won’t get any long-term statistics for it either. Which has always been the case.
Is that the answer you’re looking for? Or are you asking if there’s some way specifically to turn off the long-term statistics feature entirely? If it’s the latter then the answer is no. You’re welcome to make a feature request but you’d definitely have to explain your use case for wanting to do this.
Not quite.
I want to prevent statistics tables and data from being written to the database.
But I do want to log the sensors raw data, so I cannot exclude the sensors all together.
1 Like
So the second one I said basically. There’s no way to do that right now, you’ll have to submit a feature request. But as I said, you’ll definitely need to explain what your use case and what issues having the statistics data causes.
Now that I’ve upgraded to 2022.4 I just want to say the improvements are all brilliant.
I did however have to set up a bunch of stuff again that didn’t get migrated properly, and fixing broken scripts/automations/helpers etc. Definitely wasn’t a smooth transition and was finding broken things to fix for a few days
Use case: purge disabled and raw data collected with cleanly defined include/exclude filters.
=> lots and lots of useless weite cycles and database entries
Feature request: hopeless on such a topic. It will just get smacked down because “the normal user… too much data…”. Feature requests seem quite hopeless in general. 
Otherwise I would also request that in table events, the event stated_changed be removed because this is completely redundant. What’s the point in recording that the state was changed if in table states the actual change is tracked.
=> double the data with no additional information
But thank you for your feedback 
2 Likes
State changed event table is for logbook as the normal states table doesn’t contain information that logbook requires.
Any way of disabling it? I really, really don’t need it.
Exclude the event type
That’s the problem. Did this a while back (and think I posted the question), but if you disable the event type, then you also lose the actual sensor data in state table as it has the same envent type.
So disabling that event type means you collect no more data.
1 Like
I think @AleXSR7001 has a legitimate issue here. There’s an awful lot of data stored in the statistics and related tables, which are useless for anyone who doesn’t use that data. HA ran fine before that was added, and it seems letting the user choose whether or not to use that feature would be appropriate.
I don’t really have a horse in this race. I know how to manage my database and will continue to do so, with or without this enhancement. But I still want HA to be friendly to new users, who may not know they’re going down an unsustainable path until their SD card on their Raspberry Pi is either filled or crashes due to excessive I/O.
2 Likes