No worries, although latching conditions can take a bit of head-scratching, I’ll readily admit.
First off, the docs give you five conditions under which a latched condition or group will reset, but the most fundamental, and the one that is resetting your latch, is that if the latched condition/group is in and AND group (yours is, the root group is an AND group in this ReactorSensor), then when the root group goes false, the latch is automatically reset.
Your RS has a lot going on, but if we boil down to simple example case, hopefully what is happening will get more clear: Let’s say you have a group “TOP” with two subgroups “IN1” and “IN2”, like this:
TOP – AND group
- IN1 – group
- IN2 – group w/latching output
When IN1 and IN2 go true at the same time, the output of TOP will be true. Since IN2 is latching, if its underlying conditions later go false, the group itself remains latched true, and so as long as IN1 also remains true, TOP will remain true. So basically, once everything goes true, anything IN2 does becomes irrelevant to the output; it always stays true. Until…
When IN1 goes false, however, then the AND condition of the parent group is no longer met and it goes false, and when it does, the latch on IN2 is reset.
So what is happening in your RS is that “Rear Pump Used” is your IN2 living inside the root AND group “Backup Pump Active,” and you’ve got about two dozen IN1 groups. Any of those “IN1” groups being false means the root is false and the latch on Rear Pump Used (IN2) doesn’t stay latched. Basically, the structure of your RS will pretty much never allow the latch to work; it doesn’t seem like all children of root being true at the same time is even a likely scenario.
There are two easy fixes without too much disruption of your logic (choose one).
- It seems like the
Tripped state of this ReactorSensor is not really useful, since the groups that drive it do a bunch of different things. Make the root group NUL instead of AND. This will break the AND requirement for automatic latch resetting with respect to the parent group; it won’t affect the operation of any of the other groups. Once done, then only explicit reset action on the latch state will work.
- Wrap the Rear Pump Used group (just that one) in a NUL group. If you add a new group at the bottom to the root, make it NUL, then drag Rear Pump Used into it, it won’t disrupt the other references to that group in the other groups or activities. You can then drag the new NUL group (which now hold Rear Pump Used) up before “Reset latch on rear” to put it back in the right order. Once wrapped, you again have no parent AND state to honor, so the automatic resetting of the latch cannot occur; it must be done explicitly.
I also noticed in your RunLua actions:
1: luup.variable_set("urn:schemas-micasaverde-com:device:FloodSensor1", "Tripped", "0", 275)
2: luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1", "ArmedTripped", 0,275)
3: luup.variable_set("urn:schemas-micasaverde-com:device:SecuritySensor:1","Tripped",0,275)
4: luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1", "Tripped", 0, 275)
Lines 1 and 3 have invalid service IDs. they look like most of a device type (but it’s not entirely that, either). Likes 2 and 4 are correct, and should be all you need. This code appears in two places, so you have two activities to fix.
