One of the objectives is to filter anything that has 0
However that addition of state under include does not yield any results. Tried variations but it either shows nothing or all sensors (incl 0). Also tried >1 in case there was some small value.
Any suggestions? It might be caused by how the entities are pulled from the ‘grouped’ sensor? Can it somehow be included in the template under filter?
I don’t know, I don’t see why this wouldn’t work.
When you evaluate this in developer tools {{state_attr("sensor.pwrctrl_use_heating_power", "entities") }} is it also returning the sensor.icehouse_heater_power entity_id?
I suggest you are better of asking this on auto entities topic or issue tracker, as this is not really specifically powercalc related.
Looking at auto entities documentation. It includes both filter.template and include entities, and than excludes any entities indicated with exclude.
So you should probably use exclude.
Unfortunately that does work. I have now tried many things and I can get it to work with non powercalc ‘groups’. Are you sure it’s not related to @Mariusthvdb his post here? Concerning entity_id
I agree, it is not a powercalc-bug, but I got this idea from you, and I think it will be brilliant for everyone using powercalc-groups, so I took a shot and hoped you had a solution
(Hoping it was something basic I’d missed)
I’ll do some more testing, and report to Auto Entities topic if I can’t figure it out
That should be unrelated, it’s only a suggested other way to include entities in the auto entities list, but you don’t have any issues with that. I did have a look into that 2 weeks ago but I cannot change that in powercalc btw because things are hardcoded in HA core.
Anyway back to the topic of excluding 0 watt entities.
I tested this on my installation and it’s working fine. Previously I had 8 entities having 0 watt, after changing the configuration all the 0 watt entities disappeared.
Not sure why this is not working on your installation. I suggest to create an issue on auto entities github when you can’t get the exclude to work properly.
I have several sensors configured exactly the same way and all of them work as expected.
Recently shelly unit controlling garden lights failed and I replaced it with the new one. After some initial issues to restore device’s and entities’ names to original state everything works fine, but this particular Powercalc sensor.
Related entity (light.shelly_garden_lights) exists and properly changes its state. I do not see any errors from Powercalc in log. What could be wrong here?
Thanks but the issue seems to be that if you define the filter as ‘template’ you cannot use the options within that. You can only use the options under ‘include’ (like in your example).
So trying to re-create an include that gives me the same result as the template. Not easy…
So below is already better but the combination of attribute filter ‘power’ combines with integration ‘powercalc’ does only show a small set of the power sensors. Further testing shows it’s the integration: powercalc filter that does not return all powercalc sensors (if I remove other filters).
It seems that sensors created lik below do not get tagged with integration ‘powercalc’ only the ones that are created virtually.
Another drawback is that the powercalc groups do not play nice in auto-entities. You would expect group: sensor.all_powercalc_power to work as a group filter (like it does for instance for lights or media players, but auto-entities does not play nice. @bramski Is there anything you can do about this or is this 100% on auto-entity side?
auto entities looks at entity_id attribute of the group entity, powercalc defined the child entities in entities attribute, so that’s why the group filter not works. I don’t want to change that as lot of users may already depend on that. So there must be a very good reason to do so.
I understand & respect that, but maybe there is a way powercalc could (optional) create another entity eg a a ‘real’ group next to the ‘powercalc’ group? That way you maintain existing functionality but at the same time facilitate new functionality. ‘Real’ groups (and their benefits) are use-full in many cases. posted it on your github.
You can actually create dynamic groups (I did not know of) by calling group.set service like the example below. This will create a ‘real’ group called (in this case) group.test_powercalc which then behaves like a normal group and therefore can also be used by -for instance- auto entities to filter on.
I think these are non-persistent and will need to be called at startup.
It is not good practice for integrations to put much data in the attributes as this needs to be written on every state change, and also quickly adds to the database size.
So I want to adhere to that as much as possible.
