Have I got the following logic correct for conditions to turn on stair light (untrip is to turn off after 30min delay) but not to trigger if stair light is already on
Although a screen grab seems easy, and it can be helpful to newcomers because they can see/create the same on their own screens, this is one of those situations where I would prefer to see a Logic Summary, because the answer to your question really requires that I see both the conditions and the activities (which the LS provides, in addition to a lot of other useful info). Making a Logic Summary is also a one-step process, where screen capture of long condition lists and activities end up being several screen grabs and a lot more work.
Onward… (if I go into too much obvious detail here, it’s to help newcomers understand)
Your single-condition subgroup at the bottom draws my eye, so let’s look at that first. The condition within checks to see if the light is on (true when on). You’ve put that condition in its own group with a NOT+AND, so the group itself will be the inverse of the condition (false when the condition is true/light is on, true when the condition is false/light is off). This will work, but you could do this without a single-condition subgroup by simply having the condition’s check be “equals 0” (the “off” value) or using the IS FALSE operator. This would simplify the logic for this one element.
In any case, that last condition (the group) will be false when the light is (already) on. The root group contains that condition, plus the conditions that the house mode is home or night, the garage multi-sensor is tripped (presumably to detect motion?), and it’s between sunset and sunrise (i.e. it’s night). The root group uses the AND operator, so all conditions have to be true for the RS to trip. Therefore, the RS will be tripped when:
- The house mode is Home or Night, AND
- The sensor is tripped, AND
- It’s between sunset and sunrise, AND
- The stair light is NOT on;
When the above four conditions are all met together, the RS will be tripped, and the trip activity runs. If any of them becomes false, the untrip activity runs.
So this part of the logic makes sense. Without seeing your activities, though, I can’t be sure it will respond in the way you describe and that meets your goal (again, that’s why I prefer the Logic Summary). You mentioned, however, “untrip is to turn off after 30 min delay”–so I suspect the first action in your untrip activity is a delay of 1800 seconds, followed by turning the light off. You would then need to have the trip activity turn the light on. Seems legit. That’s certainly one way to do it. Good job!
Also, I recommend you click those group names and give them sensible, human-readable names. Naming the groups well can function as a hint/documentation and make things much more clear in the future.
What would I do differently? Given our new capabilities in 3.0, I would create a subgroup and name it “Light On”, and move all four conditions in that subgroup. I would then clear all existing activities, and make the “Light On is TRUE” activity turn on the light. Then, I would add another top-level group (child of root) called “Light Off”, with the condition “Multisensor Tripped IS FALSE” and the option “sustained for 1800 seconds”. I would then make the “Light Off is TRUE” activity turn the light off (only; no delay needed–the condition itself provides it). Doing this, the tripped/untripped state of the ReactorSensor becomes irrelevant, and you are using group activities assigned to your two groups to carry on the work that needs to be done at the right time. This is edging you into the concept of modular logic that 3.0 makes possible.
As before, but especially now with the the new logic structure capabilities, there will be more than one way to solve a problem. I will try to resist saying that there is a “right” way in these cases, but if there are any pitfalls to the approach that I notice, or opportunities to simplify it and make good use of new features, I will mention them. And we’ve got some really smart people in this community, and I’d love to see/read what they catch and suggest as well.
Probably in plain sight but how do I produce a logic summary?
In the Tools tab, there a Logic Summary link in the Troubleshooting section.
*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
Version: 3.0 config 301 cdata 19082 ui 19125 pluginDevice 747
System: Vera version 1.7.4453 on Sercomm G450; loadtime 1557266738; systemReady 1557266767; Lua 5.1
Local time: 2019-05-08T08:06:32+1000; DST=0
House mode: plugin 1; system 1; tracking on
Sun data: { “stamp”: 2019128, “civdawn”: 1557258742, “nautdawn”: 1557257066, “sunset”: 1557299523, “nautdusk”: 1557302664, “latitude”: -27.4679, “astrodusk”: 1557304320, “longitude”: 153.028, “civdusk”: 1557300988, “astrodawn”: 1557255409, “sunrise”: 1557260206 }
Geofence: not running
Power: ?, battery level ?
Stair Light Trigger (#758)
Version 19082.1557216008 05/07/19 18:00:08
Message/status: Not tripped
Condition group “grp16837ad65f8” (AND) false as of 17:49:32
&-T-housemode in 1,3 [3 => 1 at 06:03:01; T/T as of 04-14.13:37:08/04-14.13:37:08]
&-F-service Garage MultiSensor (220) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1 [1 => 0 at 06:45:13; F/F as of 06:45:13/06:45:13]
&-F-sun bet sunset+0,sunrise+0 [1557266680 => 1557266763 at 08:06:03; F/F as of 06:16:00/06:16:00]
&-T-group “grpctpkwy3” (NOT AND) TRUE as of 19:33:45
| &-F-service Stair Light (52) urn:upnp-org:serviceId:SwitchPower1/Status = 1 (match case) [1 => 0 at 19:33:45; F/F as of 19:33:45/19:33:45]
Activity root.false
Device 52 (Stair Light) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=0 )
Activity root.true
Device 52 (Stair Light) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue=1 )
Events
05/08/19 08:06:02 start:
Well, I didn’t mean for you to generate one now. 
I meant for the future. Also, when posting the summary, watch the formatting (which you see is broken here). The first line of the summary tells you what you need to know to preserve the formatting.