Reactor randomly failing since 7.30

[dJOS]

@rigpapa as I’ve mention previously (and others too iirc), since 7.30 (and on 7.31) I’ve been having random issues with reactor either not firing or not being 100% reliable in firing all activities.

Today I’ve finally been able to capture a nice simple one (therefore ruling out PEBKAC … I hope).

This one is dead simple, turn on a sensor between a specific time period - it had been working for a couple of days.

and the logic summary:

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.4 config 19226 cdata 19082 ui 19237 pluginDevice 120
    System: Vera version 1.7.4903 on Sercomm G450; loadtime 1578782146; systemReady 1578782172; Lua 5.1; JSON dkjson 2.5+LPeg
Local time: 2020-01-12T14:19:24+1100; DST=1; Kilsyth, Victoria Australia
House mode: plugin 1; system 1; tracking on
  Sun data: {"stamp":2020012,"civdawn":1578767919,"nautdawn":1578765640,"sunset":1578822206,"nautdusk":1578826322,"latitude":-37.804519,"astrodusk":1578828865,"longitude":145.331965,"civdusk":1578824042,"astrodawn":1578763097,"sunrise":1578769756}
  Geofence: not running
====================================================================================================================================
WU Forecast Control (#374) tripped
    Version 19082.17 01/11/20 22:30:16
    Message/status: Tripped
    Condition group "Reactor Sensor 50" (AND)  TRUE as of 14:17:47 <root>
      &-T-service WU - Forecast (369) urn:micasaverde-com:serviceId:SecuritySensor1/Armed <> 1 [0 at 14:17:47; T/T as of 14:17:47/14:17:47] <condmnn5qzl>
      &-T-trange bet ,,,5,0,,,,14,25 [1578799067 at 14:17:47; T/T as of 14:17:47/14:17:47] <condmnmzp0s>
    Activity root.false
        Device WU - Forecast (369) action urn:micasaverde-com:serviceId:SecuritySensor1/SetArmed( newArmedValue="0" )
    Activity root.true
        Device WU - Forecast (369) action urn:micasaverde-com:serviceId:SecuritySensor1/SetArmed( newArmedValue="1" )
    Events
        01/12/20 09:36:07 reload: notice=Luup reload
        01/12/20 09:36:07 start: 
        01/12/20 09:36:08 sensorstate: state=true
        01/12/20 09:36:08 startscene: scene=root.true, sceneName=root.true
        01/12/20 09:36:08 runscene: scene=root.true, sceneName=root.true, notice=Deferring scene execution; waiting for system ready.
        01/12/20 09:36:13 runscene: scene=root.true, sceneName=root.true, group=1, notice=Starting scene group 1
        01/12/20 09:36:13 endscene: scene=root.true, sceneName=root.true
        01/12/20 14:17:27 action: action=Restart
        01/12/20 14:17:27 start: 
        01/12/20 14:17:42 action: action=SetEnabled, state=0
        01/12/20 14:17:46 action: action=SetEnabled, state=1
        01/12/20 14:17:46 action: action=Restart
        01/12/20 14:17:46 start: 
        01/12/20 14:17:47 condchange: newState=true, cond=condmnn5qzl
        01/12/20 14:17:47 evalchange: newState=true, cond=condmnn5qzl
        01/12/20 14:17:47 condchange: newState=true, cond=condmnmzp0s
        01/12/20 14:17:47 evalchange: newState=true, cond=condmnmzp0s
        01/12/20 14:17:47 condchange: newState=true, cond=root
        01/12/20 14:17:47 evalchange: newState=true, cond=root
    Devices
        WU - Forecast (369) urn:schemas-toggledbits-com:device:SiteSensor:1 (4/0); parent 0; plugin 8942
```

It was in a tripped state but did not fire the activity until i cycled it.

[rigpapa]

It looks like it was already true/tripped from 9:36 in the morning. It won’t fire the activity again once it’s true/tripped. A false/untripped state has to intervene. The disable/enable wipes the condition state history and starts it over, so that actually didn’t help in this case–there’s now no way to know what the states were at the time it wasn’t doing what you wanted. But it sure likes it was doing what it was told when it was told beforehand. What’s making you think the activity didn’t fire?

Edit: I think I see your confusion here, although I’m not 100% sure… your last statement “it was in a tripped state but did not fire the activity until I cycled it”… there’s nothing in the event log to indicate that it ran the activity after you cycled it, which is consistent with my expectations based on the prior state. The RS was still “tripped” from the 9:36am event, so even if the root group is evaluated to true, because the RS was already tripped, it won’t re-run the activity. The root group is special–it has a historical connection to the tripped state of the ReactorSensor. Had you manually reset the tripped state prior to starting it, it would have run the actions. Had you manually reset the tripped state prior to disable/enable and the condition state clear that occurs, it also would have run the activity. But since it was already tripped, no activity.

Try moving your conditions to a subgroup, and triggering your actions from the subgroup’s “is TRUE” and “is FALSE” activities. Ignore the root group–I’ve recently started recommending this, you may have noted. The “tripped” state of the RS and its connection to the root group is legacy behavior I cannot remove, but it should be considered deprecated.

[dJOS]

@rigpapa

It looks like it was already true/tripped from 9:36 in the morning. It won’t fire the activity again once it’s true/tripped. A false/untripped state has to intervene. The disable/enable wipes the condition state history and starts it over, so that actually didn’t help in this case–there’s now no way to know what the states were at the time it wasn’t doing what you wanted. But it sure likes it was doing what it was told when it was told beforehand. What’s making you think the activity didn’t fire?

It didnt fire because the Sensor never changed to enabled (afaik) and that is backed up by the device “WU - Forecast” showing as “0”. Had it it turned on as it is supposed to, the entire AND statement would be false.

@rigpapa

Edit: I think I see your confusion here, although I’m not 100% sure… your last statement “it was in a tripped state but did not fire the activity until I cycled it”… there’s nothing in the event log to indicate that it ran the activity after you cycled it,

It started working after I captured the logic summary.

@rigpapa

Try moving your conditions to a subgroup, and triggering your actions from the subgroup’s “is TRUE” and “is FALSE” activities. Ignore the root group–I’ve recently started recommending this, you may have noted. The “tripped” state of the RS and its connection to the root group is legacy behavior I cannot remove, but it should be considered deprecated.

Ok I’ll give this a go.

[rigpapa]

OK. Avoid restarting or disabling/enabling the RS. It wipes the state history and makes it much more difficult to see what’s happened. Capture a logic summary if it’s not in the expected state and we’ll go from there.

By the way, Vera house modes enforce changes on Armed, so I’m not sure if that’s entering into it, but just a reminder…

[dJOS]

@rigpapa

By the way, Vera house modes enforce changes on Armed, so I’m not sure if that’s entering into it, but just a reminder…

Yeah I think it was part of the problem - the other part was Im a dumb a$$ and when I moved my logic into a group it works perfectly … and flapped like crazy … cause im an idiot and logically that is what it was programed to do.

I’ve now implemented logic that works.

[rigpapa]

Yes, I noticed, but was focusing on one issue at a time… using “is TRUE” and “is FALSE” together with a state condition on the device you’re manipulating can be hazardous. Glad it’s working out.

[dJOS]

Hmm, Im still having issues with Reactor sensors randomly not working - this one usually works fine but in the past 24 hrs 2 separate parts have tripped but the Activity has not worked.

Yesterday the first part fired (turning on the Downstairs AC) when it should of but did not change the set-point when the temp exceeded 30c (i had to do it manually).

Today the first part has not fired despite all conditions being met. You can see the AC is not in CoolOn mode, but in Off mode.

This logic had been working just fine until 7.3x - the only changes I’ve made recently are to the set-points.

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
       Version: 3.4 config 19226 cdata 19082 ui 19237 pluginDevice 120
        System: Vera version 1.7.4903 on Sercomm G450; loadtime 1578799664; systemReady 1578799690; Lua 5.1; JSON dkjson 2.5+LPeg
    Local time: 2020-01-14T11:22:00+1100; DST=1; Kilsyth, Victoria Australia
    House mode: plugin 1; system 1; tracking on
      Sun data: {"stamp":2020014,"civdawn":1578940849,"nautdawn":1578938584,"sunset":1578994977,"nautdusk":1578999070,"latitude":-37.804519,"astrodusk":1579001589,"longitude":145.331965,"civdusk":1578996805,"astrodawn":1578936065,"sunrise":1578942677}
      Geofence: not running
    ====================================================================================================================================
    Downstairs Cooling (#221) tripped
        Version 19082.148 01/12/20 16:43:29
        Message/status: Tripped
        Condition group "Cooling All" (OR)  TRUE as of 11:16:14 <root>
          |-T-group "Cooling On" (AND)  TRUE as of 11:16:14 <grpdes4yia>
          |     &-T-housemode in 1,2 [3 => 1 at 06:00:00; T/T as of 06:00:00/06:00:00] <condc0v1zdx>
          |     &-T-service WU - Conditions (368) urn:toggledbits-com:serviceId:SiteSensor1/Value2 >= 26 [25 => 26 at 11:16:14; T/T as of 11:16:14/11:16:14] <condc0v09ig>
          |     &-T-service Rumpus Room (354) urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus = Off [coolon => off at 21:17:12; T/T as of 21:17:12/21:17:12] <condc0vqbez>
          |     &-T-service Rumpus Room (354) urn:upnp-org:serviceId:TemperatureSensor1/CurrentTemperature >= 23 [22 => 23 at 10:13:12; T/T as of 10:13:12/10:13:12] <condc0v2fm5>
          |-F-group "Outside Tmp -30" (AND)  false as of 20:01:27 <grpleae6xw>
          |     &-T-housemode in 1,2 [3 => 1 at 06:00:00; T/T as of 06:00:00/06:00:00] <condleaeswf>
          |     &-T-service WU - Conditions (368) urn:toggledbits-com:serviceId:SiteSensor1/Value2 < 30 [25 => 26 at 11:16:14; T/T as of 20:01:14/20:01:14] <condleaf30i>
          |     &-F-service Rumpus Room (354) urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus = CoolOn [coolon => off at 21:17:12; F/F as of 21:17:12/21:17:12] <condleagbj9>
          |     &-T-service Rumpus Room (354) urn:upnp-org:serviceId:TemperatureSetpoint1/CurrentSetpoint <> 23 [23 => 0 at 21:17:23; T/T as of 21:17:23/21:17:23] <condleajhkl>
          |-F-group "Outside Tmp 30+" (AND)  false as of 18:13:10 <grpdes730z>
          |     &-T-housemode in 1,2 [3 => 1 at 06:00:00; T/T as of 06:00:00/06:00:00] <conddes8cgx>
          |     &-F-service WU - Conditions (368) urn:toggledbits-com:serviceId:SiteSensor1/Value2 >= 30 [25 => 26 at 11:16:14; F/F as of 20:01:14/20:01:14] <conddes90bd>
          |     &-T-service WU - Conditions (368) urn:toggledbits-com:serviceId:SiteSensor1/Value2 < 36 [25 => 26 at 11:16:14; T/T as of 01-10.08:09:05/01-10.08:09:05] <conddesbnyi>
          |     &-F-service Rumpus Room (354) urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus = CoolOn [coolon => off at 21:17:12; F/F as of 21:17:12/21:17:12] <conddes9ysx>
          |     &-T-service Rumpus Room (354) urn:upnp-org:serviceId:TemperatureSetpoint1/CurrentSetpoint <> 22 [23 => 0 at 21:17:23; T/T as of 20:01:27/20:01:27] <condkoddyt0>
          |-F-group "Outside Tmp 36+" (AND)  false as of 01-10.08:09:05 <grpdescsml>
          |     &-T-housemode in 1,2 [3 => 1 at 06:00:00; T/T as of 06:00:00/06:00:00] <conddescv6g>
          |     &-F-service WU - Conditions (368) urn:toggledbits-com:serviceId:SiteSensor1/Value2 >= 36 [25 => 26 at 11:16:14; F/F as of 01-10.08:09:05/01-10.08:09:05] <conddesdedp>
          |     &-F-service Rumpus Room (354) urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus = CoolOn [coolon => off at 21:17:12; F/F as of 21:17:12/21:17:12] <conddesed4b>
          |     &-T-service Rumpus Room (354) urn:upnp-org:serviceId:TemperatureSetpoint1/CurrentSetpoint <> 20 [23 => 0 at 21:17:23; T/T as of 01-10.08:09:05/01-10.08:09:05] <condkodf5sm>
          |-F-group "Cooling Off" (OR)  false as of 21:17:12 <grpdesm297>
          |     |-F-group "Normal Off" (AND)  false as of 01-10.16:07:59 <grpdesnrth>
          |     |     &-T-housemode in 1,2 [3 => 1 at 06:00:00; T/T as of 06:00:00/06:00:00] <conddesma3g>
          |     |     &-F-service Rumpus Room (354) urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus = CoolOn [coolon => off at 21:17:12; F/F as of 21:17:12/21:17:12] <conddesmgfi>
          |     |     &-F-service Nest Thermostat DS (7) urn:upnp-org:serviceId:TemperatureSensor1/CurrentTemperature <= 22 [22 => 23 at 11:12:28; F/F as of 11:12:28/11:12:28] <condjknopy4>
          |     |     &-F-service WU - Conditions (368) urn:toggledbits-com:serviceId:SiteSensor1/Value2 <= 21 [25 => 26 at 11:16:14; F/F as of 10:11:14/10:11:14] <conddespwyd>
          |     |-F-group "Night Off" (AND)  false as of 21:17:12 <grpdesnyab>
          |     |     &-F-housemode in 3,4 [3 => 1 at 06:00:00; F/F as of 06:00:00/06:00:00] <conddesrq67>
          |     |     &-F-service Rumpus Room (354) urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus = CoolOn [coolon => off at 21:17:12; F/F as of 21:17:12/21:17:12] <conddess01h>
        Activity grpdescsml.true
            Delay 10 inline
            Device Rumpus Room (354) action urn:upnp-org:serviceId:TemperatureSetpoint1_Cool/SetCurrentSetpoint( NewCurrentSetpoint="20" )
        Activity grpleae6xw.true
            Delay 10 inline
            Device Rumpus Room (354) action urn:upnp-org:serviceId:TemperatureSetpoint1_Cool/SetCurrentSetpoint( NewCurrentSetpoint="23" )
        Activity grpdes4yia.true
            Device Rumpus Room (354) action urn:upnp-org:serviceId:HVAC_UserOperatingMode1/SetModeTarget( NewModeTarget="CoolOn", NewCoolSetpoint="23" )
            Delay 10 inline
            Device Rumpus Room (354) action urn:upnp-org:serviceId:TemperatureSetpoint1_Cool/SetCurrentSetpoint( NewCurrentSetpoint="23" )
        Activity grpdesm297.true
            Delay 10 inline
            Device Rumpus Room (354) action urn:upnp-org:serviceId:HVAC_UserOperatingMode1/SetModeTarget( NewModeTarget="Off" )
            Delay 10 inline
            Device Rumpus Room (354) action urn:upnp-org:serviceId:HVAC_UserOperatingMode1/SetModeTarget( NewModeTarget="Off" )
        Activity grpdes730z.true
            Delay 10 inline
            Device Rumpus Room (354) action urn:upnp-org:serviceId:TemperatureSetpoint1_Cool/SetCurrentSetpoint( NewCurrentSetpoint="22" )
        Events
            01/14/20 06:00:00 condchange: newState=true, cond=conddescv6g, oldState=false
            01/14/20 06:00:00 evalchange: newState=true, cond=conddescv6g, oldState=false
            01/14/20 06:00:00 condchange: newState=true, cond=conddesma3g, oldState=false
            01/14/20 06:00:00 evalchange: newState=true, cond=conddesma3g, oldState=false
            01/14/20 06:00:00 condchange: newState=false, cond=conddesrq67, oldState=true
            01/14/20 06:00:00 evalchange: newState=false, cond=conddesrq67, oldState=true
            01/14/20 06:33:09 devicewatch: device=354, old="23", name=Rumpus Room, var=urn:upnp-org:serviceId:TemperatureSensor1/CurrentTemperature, new="22"
            01/14/20 06:33:09 condchange: newState=false, cond=condc0v2fm5, oldState=true
            01/14/20 06:33:09 evalchange: newState=false, cond=condc0v2fm5, oldState=true
            01/14/20 08:01:14 devicewatch: device=368, old="17", name=WU - Conditions, var=urn:toggledbits-com:serviceId:SiteSensor1/Value2, new="18"
            01/14/20 08:51:15 devicewatch: device=368, old="18", name=WU - Conditions, var=urn:toggledbits-com:serviceId:SiteSensor1/Value2, new="19"
            01/14/20 09:13:10 devicewatch: device=354, old="22", name=Rumpus Room, var=urn:upnp-org:serviceId:TemperatureSensor1/CurrentTemperature, new="23"
            01/14/20 09:13:10 condchange: newState=true, cond=condc0v2fm5, oldState=false
            01/14/20 09:13:10 evalchange: newState=true, cond=condc0v2fm5, oldState=false
            01/14/20 09:21:14 devicewatch: device=368, old="19", name=WU - Conditions, var=urn:toggledbits-com:serviceId:SiteSensor1/Value2, new="20"
            01/14/20 09:23:09 devicewatch: device=354, old="23", name=Rumpus Room, var=urn:upnp-org:serviceId:TemperatureSensor1/CurrentTemperature, new="22"
            01/14/20 09:23:09 condchange: newState=false, cond=condc0v2fm5, oldState=true
            01/14/20 09:23:09 evalchange: newState=false, cond=condc0v2fm5, oldState=true
            01/14/20 09:28:09 devicewatch: device=354, old="22", name=Rumpus Room, var=urn:upnp-org:serviceId:TemperatureSensor1/CurrentTemperature, new="23"
            01/14/20 09:28:09 condchange: newState=true, cond=condc0v2fm5, oldState=false
            01/14/20 09:28:09 evalchange: newState=true, cond=condc0v2fm5, oldState=false
            01/14/20 09:51:14 devicewatch: device=368, old="20", name=WU - Conditions, var=urn:toggledbits-com:serviceId:SiteSensor1/Value2, new="21"
            01/14/20 09:58:09 devicewatch: device=354, old="23", name=Rumpus Room, var=urn:upnp-org:serviceId:TemperatureSensor1/CurrentTemperature, new="22"
            01/14/20 09:58:09 condchange: newState=false, cond=condc0v2fm5, oldState=true
            01/14/20 09:58:09 evalchange: newState=false, cond=condc0v2fm5, oldState=true
            01/14/20 10:11:14 devicewatch: device=368, old="21", name=WU - Conditions, var=urn:toggledbits-com:serviceId:SiteSensor1/Value2, new="22"
            01/14/20 10:11:14 condchange: newState=false, cond=conddespwyd, oldState=true
            01/14/20 10:11:14 evalchange: newState=false, cond=conddespwyd, oldState=true
            01/14/20 10:13:12 devicewatch: device=354, old="22", name=Rumpus Room, var=urn:upnp-org:serviceId:TemperatureSensor1/CurrentTemperature, new="23"
            01/14/20 10:13:12 condchange: newState=true, cond=condc0v2fm5, oldState=false
            01/14/20 10:13:12 evalchange: newState=true, cond=condc0v2fm5, oldState=false
            01/14/20 10:41:15 devicewatch: device=368, old="22", name=WU - Conditions, var=urn:toggledbits-com:serviceId:SiteSensor1/Value2, new="23"
            01/14/20 11:01:14 devicewatch: device=368, old="23", name=WU - Conditions, var=urn:toggledbits-com:serviceId:SiteSensor1/Value2, new="24"
            01/14/20 11:11:14 devicewatch: device=368, old="24", name=WU - Conditions, var=urn:toggledbits-com:serviceId:SiteSensor1/Value2, new="25"
            01/14/20 11:12:28 devicewatch: device=7, old="22", name=Nest Thermostat DS, var=urn:upnp-org:serviceId:TemperatureSensor1/CurrentTemperature, new="23"
            01/14/20 11:12:28 condchange: newState=false, cond=condjknopy4, oldState=true
            01/14/20 11:12:28 evalchange: newState=false, cond=condjknopy4, oldState=true
            01/14/20 11:16:14 devicewatch: device=368, old="25", name=WU - Conditions, var=urn:toggledbits-com:serviceId:SiteSensor1/Value2, new="26"
            01/14/20 11:16:14 condchange: newState=true, cond=condc0v09ig, oldState=false
            01/14/20 11:16:14 evalchange: newState=true, cond=condc0v09ig, oldState=false
            01/14/20 11:16:14 condchange: newState=true, cond=grpdes4yia, oldState=false
            01/14/20 11:16:14 evalchange: newState=true, cond=grpdes4yia, oldState=false
            01/14/20 11:16:14 condchange: newState=true, cond=root, oldState=false
            01/14/20 11:16:14 evalchange: newState=true, cond=root, oldState=false
            01/14/20 11:16:14 startscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true
            01/14/20 11:16:14 runscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true, group=1, notice=Starting scene group 1
            01/14/20 11:16:17 runscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true, group=2, notice=Scene delay until 11:16:27
            01/14/20 11:16:17 sensorstate: state=true
            01/14/20 11:16:27 runscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true, group=2, notice=Starting scene group 2
            01/14/20 11:16:27 endscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true
        Devices
            WU - Conditions (368) urn:schemas-toggledbits-com:device:SiteSensor:1 (4/0); parent 0; plugin 8942
            Honeywell Lyric (353) urn:schemas-micasaverde-com:device:HoneywellLyric:1 (0/-1); parent 0; plugin 8768
            Vera Connect Works W (5) urn:schemas-micasaverde-com:device:VeraConnectWWN:1 (0/-1); parent 0; plugin 8151
            Nest Thermostat DS (7) urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1 (5/1); parent 5; plugin -
            Rumpus Room (354) urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1 (5/1); parent 353; plugin -
    ```

[dJOS]

Ok so I turned off the Reactor Sensor, reset it and turned it back on and viola, it worked as designed.

```
*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.4 config 19226 cdata 19082 ui 19237 pluginDevice 120
    System: Vera version 1.7.4903 on Sercomm G450; loadtime 1578962079; systemReady 1578962104; Lua 5.1; JSON dkjson 2.5+LPeg
Local time: 2020-01-14T11:37:35+1100; DST=1; Kilsyth, Victoria Australia
House mode: plugin 1; system 1; tracking on
  Sun data: {"stamp":2020014,"civdawn":1578940849,"nautdawn":1578938584,"sunset":1578994977,"nautdusk":1578999070,"latitude":-37.804519,"astrodusk":1579001589,"longitude":145.331965,"civdusk":1578996805,"astrodawn":1578936065,"sunrise":1578942677}
  Geofence: not running
====================================================================================================================================
Downstairs Cooling (#221)
    Version 19082.148 01/12/20 16:43:29
    Message/status: Not tripped
    Condition group "Cooling All" (OR)  false as of 11:37:08 <root>
      |-F-group "Cooling On" (AND)  false as of 11:37:08 <grpdes4yia>
      |     &-T-housemode in 1,2 [1 at 11:37:04; T/T as of 11:37:04/11:37:04] <condc0v1zdx>
      |     &-T-service WU - Conditions (368) urn:toggledbits-com:serviceId:SiteSensor1/Value2 >= 26 [27 at 11:37:04; T/T as of 11:37:04/11:37:04] <condc0v09ig>
      |     &-F-service Rumpus Room (354) urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus = Off [off => coolon at 11:37:08; F/F as of 11:37:08/11:37:08] <condc0vqbez>
      |     &-T-service Rumpus Room (354) urn:upnp-org:serviceId:TemperatureSensor1/CurrentTemperature >= 23 [23 at 11:37:04; T/T as of 11:37:04/11:37:04] <condc0v2fm5>
      |-F-group "Outside Tmp -30" (AND)  false as of 11:37:04 <grpleae6xw>
      |     &-T-housemode in 1,2 [1 at 11:37:04; T/T as of 11:37:04/11:37:04] <condleaeswf>
      |     &-T-service WU - Conditions (368) urn:toggledbits-com:serviceId:SiteSensor1/Value2 < 30 [27 at 11:37:04; T/T as of 11:37:04/11:37:04] <condleaf30i>
      |     &-T-service Rumpus Room (354) urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus = CoolOn [off => coolon at 11:37:08; T/T as of 11:37:08/11:37:08] <condleagbj9>
      |     &-F-service Rumpus Room (354) urn:upnp-org:serviceId:TemperatureSetpoint1/CurrentSetpoint <> 23 [0 => 23 at 11:37:08; F/F as of 11:37:08/11:37:08] <condleajhkl>
      |-F-group "Outside Tmp 30+" (AND)  false as of 11:37:04 <grpdes730z>
      |     &-T-housemode in 1,2 [1 at 11:37:04; T/T as of 11:37:04/11:37:04] <conddes8cgx>
      |     &-F-service WU - Conditions (368) urn:toggledbits-com:serviceId:SiteSensor1/Value2 >= 30 [27 at 11:37:04; F/F as of 11:37:04/11:37:04] <conddes90bd>
      |     &-T-service WU - Conditions (368) urn:toggledbits-com:serviceId:SiteSensor1/Value2 < 36 [27 at 11:37:04; T/T as of 11:37:04/11:37:04] <conddesbnyi>
      |     &-T-service Rumpus Room (354) urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus = CoolOn [off => coolon at 11:37:08; T/T as of 11:37:08/11:37:08] <conddes9ysx>
      |     &-T-service Rumpus Room (354) urn:upnp-org:serviceId:TemperatureSetpoint1/CurrentSetpoint <> 22 [0 => 23 at 11:37:08; T/T as of 11:37:04/11:37:04] <condkoddyt0>
      |-F-group "Outside Tmp 36+" (AND)  false as of 11:37:04 <grpdescsml>
      |     &-T-housemode in 1,2 [1 at 11:37:04; T/T as of 11:37:04/11:37:04] <conddescv6g>
      |     &-F-service WU - Conditions (368) urn:toggledbits-com:serviceId:SiteSensor1/Value2 >= 36 [27 at 11:37:04; F/F as of 11:37:04/11:37:04] <conddesdedp>
      |     &-T-service Rumpus Room (354) urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus = CoolOn [off => coolon at 11:37:08; T/T as of 11:37:08/11:37:08] <conddesed4b>
      |     &-T-service Rumpus Room (354) urn:upnp-org:serviceId:TemperatureSetpoint1/CurrentSetpoint <> 20 [0 => 23 at 11:37:08; T/T as of 11:37:04/11:37:04] <condkodf5sm>
      |-F-group "Cooling Off" (OR)  false as of 11:37:04 <grpdesm297>
      |     |-F-group "Normal Off" (AND)  false as of 11:37:04 <grpdesnrth>
      |     |     &-T-housemode in 1,2 [1 at 11:37:04; T/T as of 11:37:04/11:37:04] <conddesma3g>
      |     |     &-T-service Rumpus Room (354) urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus = CoolOn [off => coolon at 11:37:08; T/T as of 11:37:08/11:37:08] <conddesmgfi>
      |     |     &-F-service Nest Thermostat DS (7) urn:upnp-org:serviceId:TemperatureSensor1/CurrentTemperature <= 22 [23 at 11:37:04; F/F as of 11:37:04/11:37:04] <condjknopy4>
      |     |     &-F-service WU - Conditions (368) urn:toggledbits-com:serviceId:SiteSensor1/Value2 <= 21 [27 at 11:37:04; F/F as of 11:37:04/11:37:04] <conddespwyd>
      |     |-F-group "Night Off" (AND)  false as of 11:37:04 <grpdesnyab>
      |     |     &-F-housemode in 3,4 [1 at 11:37:04; F/F as of 11:37:04/11:37:04] <conddesrq67>
      |     |     &-T-service Rumpus Room (354) urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus = CoolOn [off => coolon at 11:37:08; T/T as of 11:37:08/11:37:08] <conddess01h>
    Activity grpdescsml.true
        Delay 10 inline
        Device Rumpus Room (354) action urn:upnp-org:serviceId:TemperatureSetpoint1_Cool/SetCurrentSetpoint( NewCurrentSetpoint="20" )
    Activity grpleae6xw.true
        Delay 10 inline
        Device Rumpus Room (354) action urn:upnp-org:serviceId:TemperatureSetpoint1_Cool/SetCurrentSetpoint( NewCurrentSetpoint="23" )
    Activity grpdes4yia.true
        Device Rumpus Room (354) action urn:upnp-org:serviceId:HVAC_UserOperatingMode1/SetModeTarget( NewModeTarget="CoolOn", NewCoolSetpoint="23" )
        Delay 10 inline
        Device Rumpus Room (354) action urn:upnp-org:serviceId:TemperatureSetpoint1_Cool/SetCurrentSetpoint( NewCurrentSetpoint="23" )
    Activity grpdesm297.true
        Delay 10 inline
        Device Rumpus Room (354) action urn:upnp-org:serviceId:HVAC_UserOperatingMode1/SetModeTarget( NewModeTarget="Off" )
        Delay 10 inline
        Device Rumpus Room (354) action urn:upnp-org:serviceId:HVAC_UserOperatingMode1/SetModeTarget( NewModeTarget="Off" )
    Activity grpdes730z.true
        Delay 10 inline
        Device Rumpus Room (354) action urn:upnp-org:serviceId:TemperatureSetpoint1_Cool/SetCurrentSetpoint( NewCurrentSetpoint="22" )
    Events
        01/14/20 11:37:04 condchange: newState=true, cond=condkodf5sm
        01/14/20 11:37:04 evalchange: newState=true, cond=condkodf5sm
        01/14/20 11:37:04 condchange: newState=false, cond=grpdescsml
        01/14/20 11:37:04 evalchange: newState=false, cond=grpdescsml
        01/14/20 11:37:04 condchange: newState=true, cond=conddesma3g
        01/14/20 11:37:04 evalchange: newState=true, cond=conddesma3g
        01/14/20 11:37:04 condchange: newState=false, cond=conddesmgfi
        01/14/20 11:37:04 evalchange: newState=false, cond=conddesmgfi
        01/14/20 11:37:04 condchange: newState=false, cond=condjknopy4
        01/14/20 11:37:04 evalchange: newState=false, cond=condjknopy4
        01/14/20 11:37:04 condchange: newState=false, cond=conddespwyd
        01/14/20 11:37:04 evalchange: newState=false, cond=conddespwyd
        01/14/20 11:37:04 condchange: newState=false, cond=grpdesnrth
        01/14/20 11:37:04 evalchange: newState=false, cond=grpdesnrth
        01/14/20 11:37:04 condchange: newState=false, cond=conddesrq67
        01/14/20 11:37:04 evalchange: newState=false, cond=conddesrq67
        01/14/20 11:37:04 condchange: newState=false, cond=conddess01h
        01/14/20 11:37:04 evalchange: newState=false, cond=conddess01h
        01/14/20 11:37:04 condchange: newState=false, cond=grpdesnyab
        01/14/20 11:37:04 evalchange: newState=false, cond=grpdesnyab
        01/14/20 11:37:04 condchange: newState=false, cond=grpdesm297
        01/14/20 11:37:04 evalchange: newState=false, cond=grpdesm297
        01/14/20 11:37:04 condchange: newState=true, cond=root
        01/14/20 11:37:04 evalchange: newState=true, cond=root
        01/14/20 11:37:04 startscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true
        01/14/20 11:37:04 runscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true, group=1, notice=Starting scene group 1
        01/14/20 11:37:07 devicewatch: device=354, old="Off", name=Rumpus Room, var=urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus, new="CoolOn"
        01/14/20 11:37:07 devicewatch: device=354, old="0", name=Rumpus Room, var=urn:upnp-org:serviceId:TemperatureSetpoint1/CurrentSetpoint, new="23"
        01/14/20 11:37:07 runscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true, group=2, notice=Scene delay until 11:37:17
        01/14/20 11:37:08 condchange: newState=false, cond=condc0vqbez, oldState=true
        01/14/20 11:37:08 evalchange: newState=false, cond=condc0vqbez, oldState=true
        01/14/20 11:37:08 condchange: newState=false, cond=grpdes4yia, oldState=true
        01/14/20 11:37:08 evalchange: newState=false, cond=grpdes4yia, oldState=true
        01/14/20 11:37:08 condchange: newState=true, cond=condleagbj9, oldState=false
        01/14/20 11:37:08 evalchange: newState=true, cond=condleagbj9, oldState=false
        01/14/20 11:37:08 condchange: newState=false, cond=condleajhkl, oldState=true
        01/14/20 11:37:08 evalchange: newState=false, cond=condleajhkl, oldState=true
        01/14/20 11:37:08 condchange: newState=true, cond=conddes9ysx, oldState=false
        01/14/20 11:37:08 evalchange: newState=true, cond=conddes9ysx, oldState=false
        01/14/20 11:37:08 condchange: newState=true, cond=conddesed4b, oldState=false
        01/14/20 11:37:08 evalchange: newState=true, cond=conddesed4b, oldState=false
        01/14/20 11:37:08 condchange: newState=true, cond=conddesmgfi, oldState=false
        01/14/20 11:37:08 evalchange: newState=true, cond=conddesmgfi, oldState=false
        01/14/20 11:37:08 condchange: newState=true, cond=conddess01h, oldState=false
        01/14/20 11:37:08 evalchange: newState=true, cond=conddess01h, oldState=false
        01/14/20 11:37:08 condchange: newState=false, cond=root, oldState=true
        01/14/20 11:37:08 evalchange: newState=false, cond=root, oldState=true
        01/14/20 11:37:08 sensorstate: state=false
        01/14/20 11:37:17 runscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true, group=2, notice=Starting scene group 2
        01/14/20 11:37:20 endscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true
    Devices
        WU - Conditions (368) urn:schemas-toggledbits-com:device:SiteSensor:1 (4/0); parent 0; plugin 8942
        Honeywell Lyric (353) urn:schemas-micasaverde-com:device:HoneywellLyric:1 (0/-1); parent 0; plugin 8768
        Vera Connect Works W (5) urn:schemas-micasaverde-com:device:VeraConnectWWN:1 (0/-1); parent 0; plugin 8151
        Nest Thermostat DS (7) urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1 (5/1); parent 5; plugin -
        Rumpus Room (354) urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1 (5/1); parent 353; plugin -
```

[rigpapa]

You know everything about your logic and I know nothing, and there’s a lot here. I am not really in a position to makes heads or tails of this and understand why you made the choices you made here. Can you run down in more detail (a) what the overall goal is–the rules for the controlled devices, and (b) how each of your conditions addresses that goal.

BTW, generally when an RS does what you want after a restart, it’s because you have two conditions competing for control–they aren’t interlocked properly. Keep this in mind when telling me the above.

EDIT: Picking at this trying to understand what you’re after here, you said:

Today the first part has not fired despite all conditions being met.

… and your screen shot does in fact show the first group being TRUE. That occured at 11:16:14, you can see in the screen shot–that’s when the condition was met. You can see in the “Events” section of the logic summary that at 11:16:14 is started the activity for that group. So that first part has, in fact, fired. That’s also the end of the logic summary. So it looks like something changed the mode back to Off, but it wasn’t the RS… maybe the thermostat itself…?

…Are you sure you want to be looking at ModeStatus in these conditions? That’s the current operating state of the thermostat, for some controllers–it will, for example, change between “Off” or “InDeadBand” and “CoolOn” depending on whether the thermostat’s temp sensor reads above setpoint or not (for cooling). ModeTarget is the real goal operating mode of the thermostat. Maybe that’s what’s creating the randomness here?

Edit 2: Also I note that in the first group, the fourth condition checks CurrentTemperature, but the three groups after check CurrentSetpoint in their fourth conditions. Is that intentional?

Edit 3: Hmmm… now see this… I think there’s a communication problem with your thermostat… in the 11:16 run of the activity:

01/14/20 11:16:14 runscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true, group=1, notice=Starting scene group 1
01/14/20 11:16:17 runscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true, group=2, notice=Scene delay until 11:16:27
01/14/20 11:16:17 sensorstate: state=true
01/14/20 11:16:27 runscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true, group=2, notice=Starting scene group 2
01/14/20 11:16:27 endscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true

And then when you did the Restart:

01/14/20 11:37:04 startscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true
01/14/20 11:37:04 runscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true, group=1, notice=Starting scene group 1
01/14/20 11:37:07 devicewatch: device=354, old="Off", name=Rumpus Room, var=urn:upnp-org:serviceId:HVAC_UserOperatingMode1/ModeStatus, new="CoolOn"
01/14/20 11:37:07 devicewatch: device=354, old="0", name=Rumpus Room, var=urn:upnp-org:serviceId:TemperatureSetpoint1/CurrentSetpoint, new="23"
01/14/20 11:37:07 runscene: scene=grpdes4yia.true, sceneName=grpdes4yia.true, group=2, notice=Scene delay until 11:37:17

See the difference? In the second snippet, the “devicewatch” entries show the mode changing at the thermostat. There are no devicewatch entries in the first run. This looks to me like it wasn’t successful communicating with the thermostat on the first run, but one thing to try… the “Setpoint” parameter on SetModeTarget=CoolOn for that activity… leave the setpoint blank. Although UPnP says that parameter exists, I’ve never seen it used on Vera–maybe your Lyric is the first, but it may also be that something internal to Vera goofs it up. I’ve only ever seen SetModeTarget used with the target mode parameter only.

I would also look at your LuaUPnP log and find these actions by matching the timestamps from the event log with the UPnP log entries, and see if the Lyric plugin has issued any error messages.

[dJOS]

@rigpapa

You know everything about your logic and I know nothing, and there’s a lot here. I am not really in a position to makes heads or tails of this and understand why you made the choices you made here. Can you run down in more detail (a) what the overall goal is–the rules for the controlled devices, and (b) how each of your conditions addresses that goal.

Quite true, so Basically the concept is this:

Turn on the AC and set it to 23c when the following conditions are met:

>= 26c Outside
>= 23c in the Rumpus Room
House Mode = Home OR Away
AC is not already On

Then there are 3 main sections which ramp the AC Set-point Up or Down depending on the Outside temp - they check the following:

**< 30c Outside:** Set-Point to 23c
< 30c Outside
House Mode = Home OR Away
AC is already On
Setpoint is NOT 23c

**> 30c Outside:** Set-Point to 22c
> 30c Outside
< 36c Outside
House Mode = Home OR Away
AC is already On
Setpoint is NOT 22c

**> 36c Outside:** Set-Point to 20c
>= 36c Outside
House Mode = Home OR Away
AC is already On
Setpoint is NOT 20c

there is also a Cooling-off condition:

< 23c Outside
< 22c in the Rumpus Room
House Mode = Home OR Away
AC is already On 

This has been working really well since last summer - so I assume the logic is sound.

@rigpapa

… and your screen shot does in fact show the first group being TRUE. That occured at 11:16:14, you can see in the screen shot–that’s when the condition was met. You can see in the “Events” section of the logic summary that at 11:16:14 is started the activity for that group. So that first part has, in fact, fired. That’s also the end of the logic summary. So it looks like something changed the mode back to Off, but it wasn’t the RS… maybe the thermostat itself…?

It thinks it fired but the results show it didn’t as the logic is designed to know when something is in the correct state. I was wondering what reactor does to ensure Vera actually follows commands. I checked my Honeywell stat and it never received a command to turn on as best as I can tell.

@rigpapa

…Are you sure you want to be looking at ModeStatus in these conditions? That’s the current operating state of the thermostat, for some controllers–it will, for example, change between “Off” or “InDeadBand” and “CoolOn” depending on whether the thermostat’s temp sensor reads above setpoint or not (for cooling). ModeTarget is the real goal operating mode of the thermostat. Maybe that’s what’s creating the randomness here?

yes, I want to check the current state of the AC controller so I dont send redundant commands and can respond to the actual AC state.

@rigpapa

Edit 2: Also I note that in the first group, the fourth condition checks CurrentTemperature , but the three groups after check CurrentSetpoint in their fourth conditions. Is that intentional?

yes, it is intentional. that is so it can ramp up or down the set-point.

[dJOS]

@rigpapa

Edit 3: Hmmm… now see this… I think there’s a communication problem with your thermostat… in the 11:16 run of the activity:

I wonder if that is a “Vera” problem - these sort of random issues (things not changing state) have been occurring a lot for me since 7.3x.

@rigpapa

See the difference? In the second snippet, the “devicewatch” entries show the mode changing at the thermostat. There are no devicewatch entries in the first run. This looks to me like it wasn’t successful communicating with the thermostat on the first run, but one thing to try… the “Setpoint” parameter on SetModeTarget=CoolOn for that activity… leave the setpoint blank. Although UPnP says that parameter exists, I’ve never seen it used on Vera–maybe your Lyric is the first, but it may also be that something internal to Vera goofs it up. I’ve only ever seen SetModeTarget used with the target mode parameter only.

I’ll give that a try.

@rigpapa

I would also look at your LuaUPnP log and find these actions by matching the timestamps from the event log with the UPnP log entries, and see if the Lyric plugin has issued any error messages.

How do I do this?

[rigpapa]

@dJOS

It thinks it fired but the results show it didn’t as the logic is designed to know when something is in the correct state. I was wondering what reactor does to ensure Vera actually follows commands. I checked my Honeywell stat and it never received a command to turn on as best as I can tell.

Once a group goes true, the activity fires once. It does not fire repeatedly. I think if you look at your LuaUPnP log at around the 11:16 mark, you’ll see Reactor issuing the command to the Lyric. Whether or not the Lyric gets it is out of Reactor’s control.

To get the log: http://your-vera-local-IP/cgi-bin/cmh/log.sh?Device=LuaUPnP

yes, I want to check the current state of the AC controller so I dont send redundant commands and can respond to the actual AC state.

Then you definitely should be checking ModeTarget, not ModeStatus.

[dJOS]

@rigpapa

Then you definitely should be checking ModeTarget , not ModeStatus .

I just checked and that field does not exist on the HoneyWell Lyric.

@rigpapa

Once a group goes true, the activity fires once. It does not fire repeatedly. I think if you look at your LuaUPnP log at around the 11:16 mark, you’ll see Reactor issuing the command to the Lyric. Whether or not the Lyric gets it is out of Reactor’s control.

Understood, I was merely wondering if reactor checked to see if the state changed as instructed.

[dJOS]

@rigpapa

Once a group goes true, the activity fires once. It does not fire repeatedly. I think if you look at your LuaUPnP log at around the 11:16 mark, you’ll see Reactor issuing the command to the Lyric. Whether or not the Lyric gets it is out of Reactor’s control.

To get the log: http://your-vera-local-IP/cgi-bin/cmh/log.sh?Device=LuaUPnP

Argh, looks like the logs rotate (hourly?) and I can see back further than 13:06

[rigpapa]

@dJOS

I was merely wondering if reactor checked to see if the state changed as instructed.

No. That would be a Herculean feat in the Vera world. For starters, not every action modifies states that can be tested, or modifies them in a deterministic way or even in a timeframe that’s relevant. It would take a huge database of knowledge about every kind of device and all of their actions. It doesn’t exist.

EDIT: A couple more things…

1. I just installed the Lyric plugin so I could look at the code. Sure enough, they don’t implement ModeTarget, which isn’t UPnP, but in any case, ModeStatus serves the purpose.
2. The code uses a 20-second timeout when communicating with the remote service. It may not be able to walk and chew gum at the same time, so increase your delays to 20 seconds or more between commands, so that the HTTP requests are serialized/not overlapping.
3. The plugin logs a lot, so capturing the log activity around a missed command would likely be very telling.
4. The access token for the cloud service can expire, and when a command is issued to change the thermostat settings and the cloud service complains that the token is expired, it doesn’t refresh the token and retry the command, it just fails. That is a big hole! I’d bet a fair amount that this what is actually causing comm errors, and it would be somewhat random. The refresh is performed by a timer task, but if it expires between timer task events (which it most certainly does), you’re screwed until the next timer tick–no commands can be issued. Huge bug, actually.

Now… you want a state engine? You can do it, because your logic conditions are specifically testing to see if you are in a certain state, and if not, set that state. To get Reactor to re-issue the actions until the state changes (so that the logic conditions for that group are not met) is this: install Reactor 3.5 stable branch, and then put your condition groups into “pulse” mode with repeats (important: that’s an option you set on the groups for this application, in the options panel). The repeats feature is new in 3.5 so the upgrade is necessary to get it.

What this will do is, while the group’s conditions are true, the group will repeatedly toggle between true and false (pulse with repeat), using the timing you specify (make a wide gap between pulses) Each time it goes true, the activity will be re-run. Presumably, if there’s trouble communicating with the thermostat, eventually one of the re-runs will hit and change state, stopping the pulse train.

But if you do this, you’d better make darn sure your group logic cannot, no way, not ever, overlap, or you will have two or more groups competing for control of the thermostat and repeatedly sending commands–back and forth and back and forth, fighting each other, possibly even at machine speed. Be very cautious.

[dJOS]

@rigpapa

No. That would be a Herculean feat in the Vera world. For starters, not every action modifies states that can be tested, or modifies them in a deterministic way or even in a timeframe that’s relevant. It would take a huge database of knowledge about every kind of device and all of their actions. It doesn’t exist.

Bugger, that was one thing I liked about Home Assistant - it’s a state engine 1st with everything else built on top of that.

[rigpapa]

Just replied to you with a bunch, including a big bug in the Lyric plugin, and how to re-run activities…

[dJOS]

@rigpapa

The code uses a 20-second timeout when communicating with the remote service. It may not be able to walk and chew gum at the same time, so increase your delays to 20 seconds or more between commands, so that the HTTP requests are serialized/not overlapping.

Cheers, i wonder if the Nest Thermostat plugin is similar? I had to put in 20 second gaps between commands to get it reliable some time back.

@rigpapa

The plugin logs a lot,

and I get the logs via the link you provided earlier?

@rigpapa

The access token for the cloud service can expire, and when a command is issued to change the thermostat settings and the cloud service complains that the token is expired, it doesn’t refresh the token and retry the command, it just fails. That is a big hole!

That would be very annoying if correct.

@rigpapa

Now… you want a state engine? You can do it, because your logic conditions are specifically testing to see if you are in a certain state, and if not, set that state. To get Reactor to re-issue the actions until the state changes (so that the logic conditions for that group are not met) is this: install Reactor 3.5 stable branch, and then put your condition groups into “pulse” mode with repeats (important: that’s an option you set on the groups for this application, in the options panel). The repeats feature is new in 3.5 so the upgrade is necessary to get it.

Oh very interesting, cheers I’ll have a play around.

[Catman]

@dJOS

I wonder if that is a “Vera” problem - these sort of random issues (things not changing state) have been occurring a lot for me since 7.3x.

I have seen similar issues as well. Not really dug into them because, well, laziness but certainly has happened.

C

[rigpapa]

Dig in, man. Look at the amount of time that’s been spent on this issue (imagine–you can’t really know, of course, but imagine). Look at the amount of time @rafale77 has spent on Z-Wave issues. It’s exhausting. We need your effort. It takes 10% of the effort for you to diagnose it when the problem is in hand in front of you than it does for us to try to troubleshoot it by remote control. And when you’re done doing it, you’ve probably leveled-up, even if you’re not successful.

Go! If nothing else, the more people try (and talk about it), the greater the chances we’ll find it, if it’s there.