github and update works again
Am i right in thinking that pre-existing groups configured in yaml and working before this update should still be working?
all mine have stopped working. Iâm running core 2022.4.3
in developer states i can see the group
and can operate it from there
but if i try to call the service to toggle the group it wont show the group.christmas_switches entity
all the node red call service nodes that used to use these group entities are no longer showing these entities.
have i done something wrong here?
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