Hellthy

Hey! That's really cool! Thank you for sharing that. It is a little weird to be able to do that with the serial style model name and NOT with the '1pm mini gen 3' style name. That is a pretty minor grievance, tho, in the light of being able to perform that sort at all. There are, however, more pertinent limitations to this methodology. For example: A) I cannot further sub-sort these results using common criteria like 'alphabetically' or 'date added' or 'last edited'. B) There is no multiselect action ability, i.e. search for all '1pm mini gen3', multiselect, and edit $variable as a group. Being able to update firmware of all, or change icon of all, or toggle inversion for all, etc. Thinking more about this, particularly in the context of @tvbshelly's comment in this thread, I'm wondering more about how I should target or limit my observations / suggestions as they relate to functionality that is not present in the Shelly ecosystem, but is either present or easily creatable when I view my Shelly devices in Home Assistant. In other words, does it make sense to encourage Shelly to spend dev time and resources on various UI features that I expect in a typical cloud product? Or should I encourage Shelly to focus on more backend software and hardware features while scratching my UI itch via Home Assistant? I know not everyone is using HA, so, maybe it's not an either/or kind of question. I'm curious if Shelly has a specific stance on the dichotomy, tho. Also....removing a device from a group is a lot of clicks and a bit unintuitive.

A completely reasonable question. My current deployed environment has 29 discrete Shelly devices, presented as 34 in the cloud UI (5 are 2PMs). I think of groups as enabling visibility in addition to action targeting. In this circumstance, to enable a sorting visibility that the UI does not (seem) to permit, I was creating groups by Device Model (one group for my 2PMs, one group for my Plus Plugs, one group for my 1PM MINI gen3s, etc...). As my environment expands, being able to sort and prioritize across a variety of unavailable categorizations might prove valuable in various contexts - troubleshooting, firmware deployment, trend-spotting, etc. Since it can be hard, at the design level, to predict all use cases and to anticipate all visibility and instrumentation requirements, I would love to see the design assumption that groups should be able to be defined based on ANY metadata variable. Eventually, I'd also like to see dynamic groups that are defined by conditions like 'devices that exceed 10 watts, for 5 minutes'.

I see precisely this behavior too. I have three Shelly PM Mini Gen 3 deployed and I can't find any method to add them to a group.