Device misbehaving/ignoring Reactor logic

I’ve emailed the Logic Report as requested. Issue at a high level:

Fountain is being turned back on even though the Reactor logic shows not all conditions met. This started out happening after nightly shutdown at 21:30 ET (fountain coming back on a few minutes later) and has progressed to it turning off due to high winds and then back on moments later even though Reactor shows a.) countdown period for low wind detection had not expired, and b.) not all criteria being met for turning back on.

The fountain device is not attached any other scene or control in the system.

You’ll need to capture the Logic Summary shortly after the fountain turns on when you don’t expect it. Then examine the “Events” section to see why it turned it on.

I’d sent this to you via email as noted in the instructions.

The time of the report you sent is 9:19am, and you’re reporting the problem occurring at/after 21:30 (9:30pm). The time to make the report is when the fault occurs, otherwise, the event log entries roll off from other activity and the clues are gone.

21:30 ET was an example of other occurrences. The log I sent was from the incident happening this morning wherein the wind speed shut it off (correctly) and the fountain came back on within five minutes instead of 25: after winds were dropped again. Given the API call happens every five minutes PLUS the 25: delay, when the fountain goes off because of wind it should not be turned back on for another half hour even if the very next API call shows wind speeds below the threshold again.

Sorry for the confusion.

There’s no evidence in the event log you sent of Reactor turning the device on. There are only off commands in the log.

And yet it went on.

Maybe a zwave outdoor switch going bad?

I did a restart earlier and it’s been acting perfectly normally. Very confusing little gremlin.

I would look at your LuaUPnP log file and see what other things might be going on around that time. I suppose a failing switch is a possibility, but I always consider it an outlyer. It happens, but not as often as other things.

So this issue persisted. Cross-referencing logs proved oddly fruitless as the fountain continued to fire outside of the established criteria. LuaUPnP log file showed the fountain firing but no indicator why.

I had a sudden epiphany last night.

image

This was set to No change in Home mode (which I took to mean “let Reactor drive, you just follow.”) However, I changed it to Off and today there’s not been a single misfire as yet.

Do you have any activities in your ReactorSensors, or scenes or Lua, that are changing the house mode?

Not associated with the fountain. Home mode is a trigger, but the mode is not being changed.

Lobo home/away is all that changes those modes.

So you have the switch set in Lobo to set the House Mode according to the “My Modes” geofencing settings?

Logo drives House Mode plugin. House Mode plugin is all that changes modes between Home/Away.

OK… and…

  1. What connects Lobo and the House Modes plugin? Reactor logic somewhere? Other?
  2. Why are using the House Modes plugin at all?
  1. two scenes, HOME/AWAY
  2. Fair question - legacy config that I’ve not updated.

I believe the reason I hadn’t replaced it was due to how many scenes are driven off of House Modes plugin.

Fair enough. I think setting those My Modes configs to “Off” could have side-effects, if not immediately then in future, but I’m not sure what else to recommend. I hate those hidden settings; in fact, I think the entire concept of “house mode” is misconceived, and the implementation makes it worse. I don’t use it.

If Vera/Luup is in fact changing the switch state on a house mode change when it shouldn’t be (i.e. when My Modes is set to “No Changes”), that would be a bug for them to fix, and at this stage, I think we both know what the likelihood of that is, especially since we’d probably need to come up with a reproducible test case to lead them to it.

1 Like

You got me thinking now… if I’m using Lobo and the device here status tripped = 1 … that can replace HOME mode. Further, if here status tripped = 0 is a replacement for AWAY mode.

How do you replace NIGHT mode in your personal system?

As an example: I have a ReactorSensor with four groups: Morning, Day, Evening and Night. Each group’s conditions is written such that only one group can be true at any time of day. My other ReactorSensors look at this RS’s groups to determine what to do (e.g. the family room RS turns on a lamp for Morning, and off at Day, on again at Evening, off at Night).

The Morning group is a bit more specialized, too, because it has two subgroups: Weekday and Weekend. So the other RS’s can tell the difference, if necessary, between a weekday morning and a weekend morning.

In my situation, Home/Away is obvious, Vaca is calendar keyword-driven, but Night is a totally manual call. If I go to sleep at 20:00 ET, 23:00 ET, 03:00 ET, I essentially use Alexa devices and a routine to run a scene flipping the system into Night mode. For me, Night time is fluid - not sure how that would work in your set groups.