Can I SYSLOG which leak sensor tripped when having multiple sensors?

Plugins & Plugin Development Reactor
#1

I have 12 water leak sensors. Vera native messaging is good about sending a notification on which sensor tripped, however, I would like to syslog which sensor tripped as well.

The only way I can currently think (think==danger!) to do this is by creating a separate group condition for each sensor that is TRUE when tripped equals 1.

Then create the activity for each separate sensor’s TRUE group condition that:

  1. Sends the static syslog message for that sensor containing it’s hard coded name eg: {“Master Bed Sink Leak”} for example.
  2. Closes the main water valve
  3. Shuts the power to the well pump.

For 12 sensors that’s a bit of repetitive condition / activity creation. Not the end of the world, but just more to go wrong fat finger wise.

So, what I would like to do is something along the lines of having one OR condition that contains all of the leak sensors, and when a sensor is tripped, the TRUE activity would:

  1. Send a more dynamic syslog message for the tripped sensor containing it’s name value as a variable eg: { TrippedSensor+ " Leak Detected"} for example.
  2. Closes the main water valve
  3. Shuts the power to the well pump.

Where “TrippedSensor” is the variable that holds the tripped sensors name.

Is this or something like this possible keeping race conditions mind (for multiple trips)?

Thank you in advance for any guidance.
-bh

#2

Once you start using them they do tend to multiply, don’t they?

Here’s a method a few people (including me) use for similar problems. These are expressions, set up on the Expressions tab. Start with this:

monitored_sensors expression list(123,456,789)

Inside the list() function, place the comma-separated list of sensor device numbers you want to watch. This creates an array of the sensors to be monitored. Onward…

Add a tripped_sensors expression:

iterate( monitored_sensors, if( getstate( _, "urn:micasaverde-com:serviceId:SecuritySensor1", "Tripped" ) ~= "0", _, null ) )

This iterates over the array, seeing if each sensor is tripped. The expression returns a new array of only the tripped sensors. Then:

tripped_names expression: iterate( tripped_sensors, getattribute( _, "name" ) or _ )

Finally, in your syslog notification, set the message to { "Leak detected at " + join( tripped_names, ", " ) }

Since you’re doing all the work in the expressions, there’s no point duplicating it in the Conditions (detecting if there’s a leak), make these changes:

Add another expression, call it “leak_detected” with expression len(tripped_sensors) > 0. Then replace all of your Device State conditions that test the leak detectors with one Expression Value condition: leak_detected is TRUE. Bonus doing it this way: in future, if you add or remove sensors, you only need to change the monitored_sensors expression.

Here’s what mine looks like. Slightly different variable names, but you should see the same structure in it (use the instructions above as a guide, not this image).

image
image1161×246 19.6 KB

1 Like
#3

That is some extraordinarily high-end Reactor-ing right there, folks! :smiley:

Nicely played.

NOTE: Minor edit to name of ‘leak_detected’ var name (underscore was missing).

#4

Yes, they indeed multiply :slight_smile: Grinning ear to ear here because this is exactly what I was looking for! This is nice and clean and also satisfies any race conditions I was getting worried about while I was mulling this around.

One quick question if you don’t mind. Out of curiosity, what is the cycle time for each iteration of an array in this environment ?

Thanks !!!
-bh

1 Like
#5

No cycle time. Each device mentioned is “watched”, so Luup sends a notification to the ReactorSensor when any of the devices changes state. The re-evaluation of the expressions is then done. Basically, it responds instantly to a change, but otherwise, it’s not doing unnecessary chopping without any cutting.

1 Like
#6

Ah, OK I think I’ve got it. When I see ‘watch’ I think of a process that’s running doing work (cpu cycles). This more of an ‘on change, do x’ thing built into the existing environment which is far more efficient.

Sorry for the questions, but the more I learn how things are working in the black boxes, the less questions I need to ask and the more questions I can hopefully answer in the future.

Thanks again for the great plugin and your time,
-bh

1 Like
#7

This probably can go without saying but for the benefit of others, in addition to the above instructions I added a Condition WHERE expression: leak_detected ‘is TRUE’, and it works like a charm.

@rigpapa Something I noticed that was kind of scary. One of the 12 leak sensors (Forteezz WWA-02AA) didn’t have a ‘Tripped’ variable so the value returned for ‘Tripped’ was null which had ‘leak_detected’ be TRUE.

The scary part being, when I manually tripped the sensor the “Tripped” variable showed up again in that particular sensor like it decided to go away at some point but re-appear when I tripped it. Currently it is back in the expected 0 state. Is that an expected action of sensors and how they operate or possibly a sensor problem?

For now I turned OFF auto configure for that sensor and as well as the others incase that’s what is causing that condition. I’m just curious if you or anyone has seen this type of condition before?

Thanks
-bh

#8

I don’t have any experience with the Fortrezz stuff; I’ve never used it. I don’t think it would be unusual for that variable to be absent on a new sensor that has just been installed and never before tripped. Do you have any other subsystems, code or scenes that try to set or reset the device state?

#9

I don’t have any experience with the Fortrezz stuff; I’ve never used it.

It might be best to stay away from this model anyway. I’ve had them for several years and I have other weirdness going on them them since perhaps they are combo Temperature and Leak sensors. Like out of the blue they started reporting energy usage, one shows 1400W when they aren’t even an energy measurement capable device. I haven’t had the time nor energy (no punn intended) to chase this down. I’m slowly phasing them out. What are you using for flood / leak detection if I can ask? I recently picked up and am testing a Dome DMWS1.

I don’t think it would be unusual for that variable to be absent on a new sensor that has just been installed and never before tripped. Do you have any other subsystems, code or scenes that try to set or reset the device state?

I am not, and I can also say that the ‘lasttrip’ variable was present and populated with a stardate when ‘tripped’ wasn’t present at all. I always trip the new sensors to make sure they are firing off the scene shutting down well pumps and the like, I could have missed one but then I would think that ‘lasttrip’ would be null.

No worries, I’m not going to get wrapped around the axle over it. I’ll just monitor it and see what’s going on. For now at least I’ll just use the Reactor for Syslog and let the scene do the job of shutting down the well pump and main valve. Mostly because ‘Wife_at_home is True’ and trying to explain how an unexpected null value shut her water off mid shower would probably end poorly with a seg fault or similar condition :slight_smile:

-bh

#10

OK. Well… if you’re comfortable assuming the absence of the Tripped variable is not bad news that needs your attention, you can modify the tripped_sensors expression as follows:

iterate( monitored_sensors, if( ( getstate( _, "urn:micasaverde-com:serviceId:SecuritySensor1", "Tripped" ) or "0" ) ~= "0", _, null ) )
1 Like
#11

Oh geez I hope you didn’t think I was complaining about Reactor. It is important for me to know when this null condition exists so I plan on using Reactor to help me figure it out. Once I figure it out what’s happening I’m going to ditch the scene and put everything into Reactor.

Thanks again for all of your help!!
-bh

#12

Not at all! Just trying to help smooth the process within the way things seem to be working…

2 Likes
#13