Possible Bug With Reaction Groups
-
Not 100% sure this is a bug because I may have an error in my logic but here is the issue I am running into.
I have created 3 dynamic groups, the first group called "battery_35" filters all battery_powered devices that have a battery_level between 11% and 35%. My second dynamic group is called "battery_10" and it filters the same type of devices but only the ones with a battery_level between 1% and 10%. The third group is "battery_dead" and filters the same type of devices as the previous groups, but only the ones that have 0% battery. Refer to my earlier thread about the specifics of the dynamic group if necessary.
My triggers are as follow in the screenshot. Basically if the local expression that spits out the devices that match the criteria for one of three dynamic groups changes and the respective dynamic group is
false, the rule goestrue.
I have 3 reaction groups, all set up basically the same. I have a condition for each group to only trigger the notify action if the variable that contains the low battery device (either 35%, 10% or dead) changes. I have it set this way to prevent multiple notifications of device low battery and to mitigate the need to create 3 different rulesets for each battery level.
The issue occurs here, if say the "name_battery_10" and/or "name_battery_dead" are empty, and the "name_battery_35" changes (ie a device battery is now between 11-35%) the "35% Battery" successfully (and expectedly) triggers and the notification is sent. However at the same time one of the triggers "name_battery_10" or "name_battery_dead" trigger and those notifications are sent, albeit with empty device names since no devices actually met their filters (haven't found a pattern of which trigger group goes triggers). This only happens if the variable values are empty. If all the variables are not empty I do not experience this issue.
I think I could mitigate this by adding the same dynamic group condition that's in the triggers section into the reaction groups but before I do this I want to see if this is a bug or incorrect logic. I have included some logs when this issue occurred I do not see any error besides the dynamic group for "offline devices" which I am still figuring out so please ignore that :).
[latest-22302]2022-11-01T02:48:18.571Z <Rule:INFO> Low Battery (rule-l9vvokiq in Notifications) starting evaluation; because entity-changed Entity#hass>sensor_backyard_gate_battery_level [latest-22302]2022-11-01T02:48:18.705Z <Rule:INFO> Low Battery (rule-l9vvokiq in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-22302]2022-11-01T02:48:18.709Z <Rule:INFO> Low Battery (rule-l9vvokiq in Notifications) evaluation complete [latest-22302]2022-11-01T02:48:18.782Z <DynamicGroupController:ERR> DynamicGroupController#groups filter expression entity.attributes.x_hass.state == 'unknown' || entity.attributes.x_hass.state == 'unavailable' || entity.attributes.x_hass.state == 'none' error with Group#hass>controller_all: [ReferenceError]ReferenceError: Invalid scope in reference to member state of (object)null [latest-22302]2022-11-01T02:48:18.783Z <DynamicGroupController:ERR> DynamicGroupController#groups filter expression entity.attributes.x_hass.state == 'unknown' || entity.attributes.x_hass.state == 'unavailable' || entity.attributes.x_hass.state == 'none' error with System#hass>system: [ReferenceError]ReferenceError: Invalid scope in reference to member state of (object)null [latest-22302]2022-11-01T02:48:19.047Z <Rule:INFO> Low Battery (rule-l9vvokiq in Notifications) starting evaluation; because entity-changed Group#groups>low_battery_35 [latest-22302]2022-11-01T02:48:19.148Z <Rule:INFO> Low Battery (rule-l9vvokiq in Notifications) evaluated; rule state transition from RESET to SET! [latest-22302]2022-11-01T02:48:19.198Z <Rule:INFO> Low Battery (rule-l9vvokiq in Notifications) evaluation complete [latest-22302]2022-11-01T02:48:19.200Z <Engine:INFO> Enqueueing "Low Battery<SET>" (rule-l9vvokiq:S) [latest-22302]2022-11-01T02:48:19.230Z <Rule:INFO> Low Battery (rule-l9vvokiq in Notifications) starting evaluation; because timer-trigger Timer#rule-l9vvokiq [latest-22302]2022-11-01T02:48:19.331Z <Rule:INFO> Low Battery (rule-l9vvokiq in Notifications) evaluated; rule state transition from SET to RESET! [latest-22302]2022-11-01T02:48:19.380Z <Rule:INFO> Low Battery (rule-l9vvokiq in Notifications) evaluation complete [latest-22302]2022-11-01T02:48:19.384Z <Engine:NOTICE> Starting reaction Low Battery<SET> (rule-l9vvokiq:S) [latest-22302]2022-11-01T02:48:19.385Z <Engine:INFO> Low Battery<SET> all actions completed. ``` -
There's a bug here, but probably not what you think: the changes operator should not be allowed in constraints. It's special, in that it's a reactive operator that can only respond once and immediately when a value changes. After it has declared that a value has changed, that test will not succeed again unless and until the value changes again, so its behavior in a constraint is effectively undefined and nondeterministic. Fixed: next build the changes operator will not be listed as an option in constraint context.
Instead of using changes again on your group, why not just test to see if your name list is empty/blank or not?
The group expression errors showing in the log suggest you have a battery-operated device (or whatever matches your selectors) that isn't from Hass (i.e. the
x_hasscapability isn't present on it). You may need to handle this condition in your expression, which may be as simple as using the coalesce operators in your expression so that a missing attribute doesn't generate an error:entity.attributes.x_hass?.state == 'unknown' || entity.attributes.x_hass?.state == 'unavailable' || entity.attributes.x_hass?.state == 'none'Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
There's a bug here, but probably not what you think: the changes operator should not be allowed in constraints. It's special, in that it's a reactive operator that can only respond once and immediately when a value changes. After it has declared that a value has changed, that test will not succeed again unless and until the value changes again, so its behavior in a constraint is effectively undefined and nondeterministic. Fixed: next build the changes operator will not be listed as an option in constraint context.
Instead of using changes again on your group, why not just test to see if your name list is empty/blank or not?
The group expression errors showing in the log suggest you have a battery-operated device (or whatever matches your selectors) that isn't from Hass (i.e. the
x_hasscapability isn't present on it). You may need to handle this condition in your expression, which may be as simple as using the coalesce operators in your expression so that a missing attribute doesn't generate an error:entity.attributes.x_hass?.state == 'unknown' || entity.attributes.x_hass?.state == 'unavailable' || entity.attributes.x_hass?.state == 'none'@toggledbits said in Possible Bug With Reaction Groups:
There's a bug here, but probably not what you think: the changes operator should not be allowed in constraints. It's special, in that it's a reactive operator that can only respond once and immediately when a value changes. After it has declared that a value has changed, that test will not succeed again unless and until the value changes again, so its behavior in a constraint is effectively undefined and nondeterministic. Fixed: next build the changes operator will not be listed as an option in constraint context.
Instead of using changes again on your group, why not just test to see if your name list is empty/blank or not?Sounds good, I was pulling my hair out trying to figure out what was wrong. I swapped it for "is not empty" now it triggers as expected.
@toggledbits said in Possible Bug With Reaction Groups:
The group expression errors showing in the log suggest you have a battery-operated device (or whatever matches your selectors) that isn't from Hass (i.e. the x_hass capability isn't present on it). You may need to handle this condition in your expression, which may be as simple as using the coalesce operators in your expression so that a missing attribute doesn't generate an error:
This seems to have done the trick as well.
I have a question about the time shown stamps shown in the logs, it never matches up with my local time. Its usually a few hours ahead, is there anyway to have that changed to match the time zone MSR is in? It makes debugging a bit easier.
-
@toggledbits said in Possible Bug With Reaction Groups:
There's a bug here, but probably not what you think: the changes operator should not be allowed in constraints. It's special, in that it's a reactive operator that can only respond once and immediately when a value changes. After it has declared that a value has changed, that test will not succeed again unless and until the value changes again, so its behavior in a constraint is effectively undefined and nondeterministic. Fixed: next build the changes operator will not be listed as an option in constraint context.
Instead of using changes again on your group, why not just test to see if your name list is empty/blank or not?Sounds good, I was pulling my hair out trying to figure out what was wrong. I swapped it for "is not empty" now it triggers as expected.
@toggledbits said in Possible Bug With Reaction Groups:
The group expression errors showing in the log suggest you have a battery-operated device (or whatever matches your selectors) that isn't from Hass (i.e. the x_hass capability isn't present on it). You may need to handle this condition in your expression, which may be as simple as using the coalesce operators in your expression so that a missing attribute doesn't generate an error:
This seems to have done the trick as well.
I have a question about the time shown stamps shown in the logs, it never matches up with my local time. Its usually a few hours ahead, is there anyway to have that changed to match the time zone MSR is in? It makes debugging a bit easier.
-
T toggledbits locked this topic on