2022.4: Groups! Groups! Groups!

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. :rofl:

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. :man_shrugging:
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 :slight_smile:

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