I have done some poking, some searching and now I am reaching out. The idea is to have a group of temperature sensors (UNDEF_Temperature), if one of the members of this group goes UNDEF for any reason the group will output the value UNDEF otherwise it will output anything else like MAX,MIN,etc.
I can make a switch item (UNDEF_Temperature_Switch) and rules to drive the switch but I feel this is not eligant and an unessasary convolution?
Rules
When : the state of a member of an item group UNDEF_Temperature is updated to UNDEF
Then : Update the state of UNDEF_Temperature_Switch to OFF
When : a member of UNDEF_Temperature changed from UNDEF
Then : Update the state of UNDEF_Temperature_Switch to ON
I always appreciate any insite or suggestions, thanks in advance
I don’t think you can get there from here using Group aggregation functions. You’ll need to use the Switch and rules.
As implemented, MIN, MAX, SUM, and AVG ignore Items whose state is NULL or UNDEF by design. That’s often the desired behavior for many use cases.
But you can have another Group:Number Item with an aggregation function along the lines of COUNT(UNDEF) (I’m not 100% sure that’s supported in the UI so you might need to use a .items file or import the Item text config option.). If that Group Item is anything but 0 you know one or more is UNDEF. That doesn’t help if you care about NULL and UNDEF though. You’ll need a rule for that.
I’d probably just use a Rule or test how many members are UNDEF inline in a rule.
@rlkoshak as always thank you for your knowledge! If it is yourself saying you would just use a rule then I can put my thoughts to rest and move to the next challenge. I might have a play down the line and keep this thread updated with any findings.
Thanks again!
It’s quite a fun challenge. You’re working against the system here.
By design, the Group aggregation functions are mostly going to ignore UNDEF inputs. That’s desirable behaviour, e.g. ignore broken temperature sensor for calculating an average.
And the meaning of a Group state UNDEF would normally be that it has found it impossible to perform the requested aggregation - a maths SUM of stringy Items, say. But that’s after ignoring UNDEF and NULL members.
You might get away with a logic function - in theory, a Switch type Group with OR(“UNDEF”, OFF) might do it - or it might stick to the ignore-UNDEF strategy.
Keep in mind I’m lazy and don’t like to fight against the system. I tend to follow the path of least resistance. And unlike some users, I don’t see creating rules as some sort of moral failing. You’d be surprised the lengths some users will go to avoid writing a simple rule.
I feel like I have extracted the full amount of fun from this one
It totally makes sense to ignore UNDEF for calculations in “normal” operations.
I did have a dabble with different group genres but nothing acted as desired, I might come back to it one day but for now, I have bigger fish to fry. I appreciate the message @rossko57 !
