Device misbehaving/ignoring Reactor logic

Yep, the original URL provided an incomplete list.

<scene name="Fountain (4) has been turned OFF" notification_only="46" modeStatus="0" id="65" 
<scene name="Fountain is OFF" notification_only="22" modeStatus="0" users="1052345" id="53" 
<scene name="Fountain is ON" notification_only="22" modeStatus="0" users="1052345" id="54"

@rigpapa, found something interesting. Tonight the fountain shut off at 21:30 ET like it should. Eight minutes later, it popped back on again.

Logs:

06	08/18/20 21:38:30.228	Device_Variable::m_szValue_set device: 46 service: urn:upnp-org:serviceId:SwitchPower1 variable: e[35;1mStatuse[0m was: 0 now: 1 #hooks: 4 upnp: 0 skip: 0 v:0x11ea3b0/NONE duplicate:0 <0x765d2520>
07	08/18/20 21:38:30.229	Event::Evaluate 70 Fountain OFF scene Fountain OFF is false repeat 0/1 <0x765d2520>
07	08/18/20 21:38:30.229	Event::Evaluate 71 Fountain ON scene Fountain ON is true users:1052345 allow:1 <0x765d2520>
08	08/18/20 21:38:30.229	Scene::RunScene running 243 Fountain ON <0x765d2520>
04	08/18/20 21:38:30.249	<Job ID="1787" Name="pollnode #28 1 cmds" Device="46" Created="2020-08-18 21:38:30" Started="2020-08-18 21:38:30" Completed="2020-08-18 21:38:30" Duration="0.147058000" Runtime="0.145207000" Status="Successful" LastNote="" Node="28" NodeType="ZWaveNonDimmableLight" NodeDescription="Fountain (4)"/> <0x765d2520>
02	08/18/20 21:38:30.251	e[33;1mDevice_Basic::AddPoll 46 poll list full, deleting old onee[0m <0x765d2520>
06	08/18/20 21:38:30.253	Device_Variable::m_szValue_set device: 46 service: urn:micasaverde-com:serviceId:HaDevice1 variable: e[35;1mPollRatingse[0m was: 5.00 now: 5.00 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:1 <0x765d2520>
06	08/18/20 21:38:30.253	Device_Variable::m_szValue_set device: 46 service: urn:micasaverde-com:serviceId:ZWaveNetwork1 variable: e[35;1mLastPollSuccesse[0m was: 1597800280 now: 1597801110 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x765d2520>
06	08/18/20 21:38:30.254	Device_Variable::m_szValue_set device: 46 service: urn:micasaverde-com:serviceId:ZWaveNetwork1 variable: e[35;1mConsecutivePollFailse[0m was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:1 <0x765d2520>

and… from my scenes list…

<scene name="Fountain ON" notification_only="46" modeStatus="0" users="1052345" id="243" room="0" Timestamp="1597591298" last_run="1597801110">
<triggers>
<trigger device="46" name="Fountain ON" enabled="1" template="1" users="1052345" last_eval="1" last_run="1597801110">
<arguments>
<argument id="1" value="1"/>
</arguments>
</trigger>
</triggers>
</scene>
</scenes>

Yet in the Reactor logs (as expected), nothing.

        2020-08-18 21:34:50: Condition condlnb2m0o successfully sustained for at least 1500 seconds (actual 6011)
        2020-08-18 21:34:50: Sensor update completed; 0.048s
        2020-08-18 21:39:39: Device SiteSensor - Ambient (#156) urn:toggledbits-com:serviceId:SiteSensor1/Value3 changed from "0" to "1.1"
        2020-08-18 21:39:39: Sensor update starting
        2020-08-18 21:39:39: Condition condlnb2m0o successfully sustained for at least 1500 seconds (actual 6300)
        2020-08-18 21:39:39: Sensor update completed; 0.019s

If I’m reading this right, the system is using a device notification as a scene that ends up triggering the fountain.

So, I want notifications when the fountain goes on/off but using Reactor to do so ends up with me getting notifications every time the Reactor device checks the criteria and ensures it’s on or off as it runs
.

The scene is used for native Vera notifications. That’s how notifications are implemented in Vera, through scenes. There’s nothing in the scene to suggest it is turning the fountain on. So whatever is turning the fountain on remains a mystery. Your log snippet doesn’t have enough history/context to determine what/how; the first line you included just shows the status registering as on.

1 Like

I sent you the log that I pulled the snippet from.

I’d suggest you look for ZWave associations or any other external stimulus/control. The log shows only that the switch is changing status (see 21:38:30.228) and there is no other control from Vera evident. It just changes. Vera is polling it at that moment, and the device is reporting that it’s on. That may be a clue. If the device is a type/model that has additional configuration settings, then you should look at the values of those as well. You might also simply exclude the switch, factory reset it, and then re-include it. You can fix the then-broken device associations in your Reactor configs using the Device Repair tool that will appear on the Tools tab of any affected ReactorSensor. Other than that, I’m out of ideas, and it isn’t Reactor misbehaving, so I’m leaving it here.