Jump to content

Leak Sensors - A (Suggested) Complete Program Package


belias

Recommended Posts

Posted

Thanks for the replies...

 

Prior to receiving them I decided to delete the sensor and then reinstall it.  After this I was able to see the Wet got to ON when I wet the device whereas before I wasn't able to do so!

 

I will try the suggestion to place it near the PLM for the next day or so and see what happens.

Posted

Since you chose to Delete and readd the Current State for Heartbeat is null unless the Set button was tapped.   If Heartbeat is null the Leak Sensor can remain in its current location as the Heartbeat will change to On (or Off depending on firmware) when the first Heartbeat message is received.

  • 1 month later...
Posted

Thank you very much for this program.

 

I do however have a question since I can not figure it out.  I used you program to monitor a single leak sensor and everything worked well.  I was so happy with it that I added an additional 2 leak sensors to monitor. Since then the Status Code in the system seems to add up every 24 hours instead of resetting to 0. As of last night this is the message I got:

 

=========================================================

A problem has been detected with a leak sensor. Details below:

Sump Pump: 6
Laundry Drain: 14
Basement : 14


---Status Key---
1 = Heartbeat OK (normal status)
2 = Heartbeat missed
3 = Heartbeat check program not running
9 = Leak detected
----------------

Note 1: It may take up to 36 hours for a "heartbeat missed" signal to clear

Note 2: Status Code 3 indicates the "Variable Control 2" program is not running for some reason.

============================================================

 

I have deleted everything and started from scratch and I am still having the same problem.  What am I missing?

 

Regards

Posted

No.. I have looked and I am using = in the program.

 

Laundry - Variable Control 2 - [iD 0016][Parent 000A]
 
If
        Control 'Leak Sensors / Leak Laundry-Heartbeat' is switched On
     Or Control 'Leak Sensors / Leak Laundry-Heartbeat' is switched Off
 
Then
        $sLeakLaundry  = 1
        Wait  25 hours 
        $sLeakLaundry  = 2
 
Else
   - No Actions - (To add one, press 'Action')
  • 3 months later...
Posted

I have implemented this program, if I test the sensors by shorting the contacts for 5 seconds, I get notifications, I have older models so they correctly clear back to dry when no longer wet and I see all these updates.  The problem I have is heartbeats.  Some of my sensors are not in locations I frequent (which is why I have them).  If I look in my ISY I see Heartbeat for all sensors marked on, but they all end up in state 2 (heartbeat missed).

 

If I look in the log I see exactly one heartbeat entry per device after a reboot of the ISY, then a second never shows.  I have 6 sensors deployed, and the first heartbeat is never missed.

 

Thoughts?  Does it get ignored because the Heartbeat value never clears?  I would really like to know if a battery has died or what.  Thanks!

Posted (edited)

The setting of Heartbeat node during ISY startup is not from communicating with the Leak Sensor because battery devices cannot be queried.  The Heartbeat node issues an On or Off command every 24 hours approx, Leak Sensor time.  Could be 15 minutes after rebooting ISY or 24 hours.  Again, it is the 24 hours the Leak Sensor is keeping track of, not the ISY.  

 

Can you post your Program being used?

 

Could be the Leak Sensor is not in good range of a Dual Band device or the coupling of the 120v legs has an issue.

 

The check of Heartbeat node is done with "If Control" so getting two of the same command does not matter.  Using "If Status" would have that problem.

Edited by LeeG
  • Like 1
Posted

LeeG,

 

I had Status, not Control, I didn't even notice the difference, looking at the posted programs over and over.  I expect this to work,  thanks, I'll have to look into it.

  • 1 month later...
Posted

Finally got around to getting a leak sensor now that my ISY is up and running. Thanks for this excellent work, so far so good. More sensors will be added soon :).

Posted

Love this programming - thank you!

 

I have one LS that has been sending a "wet" signal daily between 1 and 3 PM - not sure why.  I modified the variable control 1 program for that sensor to the following:

 

Boys Bath - Variable Control 1 - [iD 0010][Parent 000B]

 
If
        Status  'Boys Bathroom Leak Detector-D / Boys Bathroom Leak Detector-W' is On
 
Then
        Wait  3 seconds
        $sLeakBoysBath  = 9
 
Else
        Wait  10 seconds
        $sLeakBoysBath  = 1
 
Since the mod, no false positives.  Am I setting myself up for failure or will the "wait 3 seconds" delay on the "$sLeakBoysBath  = 9" just keep the LS jittering from pinging me for false alarms?
 
I'm also wondering if my "heart beats" are working.  Is there an easy way to get a weekly summary email with a "number of heart beats missed" info?  Might help with identifying LS that have dying batteries...
 
Thanks again for the fantastic programming - makes the LS actually helpful!
Posted (edited)

 

Love this programming - thank you!

 

I have one LS that has been sending a "wet" signal daily between 1 and 3 PM - not sure why.  I modified the variable control 1 program for that sensor to the following:

 

Boys Bath - Variable Control 1 - [iD 0010][Parent 000B]

 
If
        Status  'Boys Bathroom Leak Detector-D / Boys Bathroom Leak Detector-W' is On
 
Then
        Wait  3 seconds
        $sLeakBoysBath  = 9
 
Else
        Wait  10 seconds
        $sLeakBoysBath  = 1
 
Since the mod, no false positives.  Am I setting myself up for failure or will the "wait 3 seconds" delay on the "$sLeakBoysBath  = 9" just keep the LS jittering from pinging me for false alarms?
 
I'm also wondering if my "heart beats" are working.  Is there an easy way to get a weekly summary email with a "number of heart beats missed" info?  Might help with identifying LS that have dying batteries...
 
Thanks again for the fantastic programming - makes the LS actually helpful!

 

You can't use a Status to detect a LS heartbeat. It may never change and status only detects  change in status.

 

Here's what happens On...On...On....On....On.... Do you ever see an Off? Then the status would never change.

 

 

Use "control", as it detects the command whether the status changes or not.

 

Also put the "OR....is switched Off" back into the If section. Some LS produce both alternating so "On" only comes every 48 hours.

 

Also put the 25 hour Wait back in or the detection system doesn't work at all.

 

Go back and re-read the programs.

 

Think of status as how the device was left, control/switch as the command that changes things whether they change or not.

Edited by larryllix
Posted

Ok, I think I understand it now.  I guess I'm just nervous that one of these little devices fails and I never know because I don't trust the machine.  Sorry for being "that new guy."  -Matt

Posted

Ok, I think I understand it now.  I guess I'm just nervous that one of these little devices fails and I never know because I don't trust the machine.  Sorry for being "that new guy."  -Matt

I have four LS units and none have failed yet in the last or so I got my first one. Insteon device are very reliable once you get over the initial quality assurance phase (month or so)

 

What does fail is programming that is not fully tested. I think we are all guilty of that occasionally. Even when tested there is some sneak thing that can happen down the road that you never thought of but...

 

    consider what would happen if you didn't install the LS in the first place. I have been lucky with only a few leaks that wet my basement and the floor in the laundry room.

 

I can write programs to protect things fairly reliably now and trust myself but it's the little side effects that get caused, like resetting the alarm system I wrote for it, not being able to reset the alarms, reset the water back on, alarm lights getting stuck on etc.. etc.. Those things become harder to test. Time will heal this after real life events but you can be far away and be embarrassed when your house lights all flash for an hour and the neighbours come with guns. :)

Posted

 Sorry for being "that new guy."  -Matt

 

Hey Matt,

 

"That new guy" is partially what this forum is all about!

 

 

Jon...

  • 5 months later...
Posted

I checked out the thread on the new leak sensors, and it looks like the major change is that the new version does not update the node status when the sensor goes from wet to dry.  The issue (if I understand it correctly) is that this creates the situation where everything can look fine in the program (Status = 1; no emails) even though the sensor could be stuck in a Wet condition (and unable to report a new leak).

 

I took a look at the programs, and came up with the following thoughts on a modification.  I don't have the new version of the leak sensors, so it will be up to someone else to test and report back.  Open for suggestions on how to streamline this as well...

 

 

"Change Log"

1.  If a heartbeat signal is received and the sensor is reporting "wet", the status will remain at 9 (causing future emails to be sent)

2.  If a heartbeat signal is missed and the sensor is reporting "wet", the status will change to 2 (heartbeat missed; causing future emails)

3.  This preserves the functionality of the Variable Control 3 program (regardless of wet / dry) to ensure that Variable Control 2 is running correctly

4.  The modified program should work with old and/or new sensors

 

Program Modifications (untested)

 

1.  Variable Control 2 is split into 2 separate programs:

 

Variable Control 2a

If
(
Control 'Leak Sensors / Kitchen Sink-Heartbeat' is switched On
Or Control 'Leak Sensors / Kitchen Sink-Heartbeat' is switched Off
)
And Status 'Leak Sensors / Kitchen Sink-Wet' is not On

Then
$sLeakKitchenSink = 1
Wait 25 hours
$sLeakKitchenSink = 2

Else
- No Actions - (To add one, press 'Action')

Variable Control 2b

If
(
Control 'Leak Sensors / Kitchen Sink-Heartbeat' is switched On
Or Control 'Leak Sensors / Kitchen Sink-Heartbeat' is switched Off
)
And Status 'Leak Sensors / Kitchen Sink-Wet' is On

Then
Wait 25 hours
$sLeakKitchenSink = 2

Else
- No Actions - (To add one, press 'Action')

2. Modify Variable Control 3

If
(
$sLeakKitchenSink is 1
And Time is Last Run Time for 'KitchenSink - Variable Control 2a' + 26 hours
)
Or (
$sLeakKitchenSink is 9
And Time is Last Run Time for 'KitchenSink - Variable Control 2b' + 26 hours
)

Then
Wait 5 seconds
$sLeakKitchenSink = 3

Else
- No Actions - (To add one, press 'Action')

That's it...please report back any findings and I will update the original post if it works properly.

 

Thanks.

 

- Brian

 

Has anyone been running with this modified version of the programs?  I've been using the original version since they were posted and forgot the new sensors acted differently, and just installed a bunch of them in our lake house.  Then I realized they worked differently so I read the entire thread again and found this update.  I will update my programs, but we are leaving soon so I won't have much time to test.

 

Probably should add a note on the OP that there are issues with new sensors and to see the later post.

 

Also, Michel mentioned adding this to the wiki, but I couldn't find it there?

  • 4 months later...
Posted (edited)

Belias Wet Sensor Program Flow
v1.04/17jan17

This is simply to OVERVIEW the Belias program... to help understand what is going on.
It's more of a "birds eye" view, to grasp the concepts before DIGGING IN.  
It can be a bit overwhelming when you first get into ISY programming, so I hope this
helps a newbie (like i was), to get "over the hump"... it's not hard after you grasp it.
HAVE FUN!


TERMS:
PGMx = Programs below
HB = Heartbeat
SV = State Variable ;ONE for EACH SENSOR (4 in my case)
  (EG "sLeak01BsmtEnt", "sLeak02Laundry", "sLeak03SumpRm", "sLeak04BsmtOffice")
IV = Integer Variable ;ONE for WHOLE program (for STARTUP detection)
  (EG "iStartup")
1 = HB ok
2 = HB Missed
3 = HB Check Program NOT RUNNING
9 = LEAK DETECTED

REMINDERS / NOTES:
-Interrupt driven means ANY program can run ANYTIME it is evaluated TRUE!
  (So it hops out from its current "wait" state, and starts over, for example!)
-When a SV value changes, it forces a re-evaluation of any programs using it
  (When an IV value changes, it does NOT cause any interrupts to occur anywhere!)
-This is the MODIFIED version of Belias' for newer Leak Sensors (so all sensors work)
-In PGM1, put lines to run PGM2a of each sensor (Not PGM2b) (Not mentioned in forum)

======= ======= LOGIC FLOW ======= =======
Note: PGMS1-3 below are ONE PER SENSOR (So 4 of each for 4 sensors)...

  ...(PGM0 is not duplicated, only ONE needed)

PGM0: "LEAK STARTUP" ;Ran when ISY first boots, and IV = 0
(Tests IV 'iStartup', if 0 (JUST WAKING UP)... then...)
  (Runs THEN of every VariableControl2a program (one for each sensor))
(Otherwise IV=1 (ISY already awake), so this PGM1 doesn't even get ran at all))

PGM1: "VARIABLE CONTROL 1"
  IF this Leak Sensors "WET" node is set to ON (yuk! LEAK!)...
  Set SV to 9 (yuk! BAD!)
  Otherwise, chill for 10 seconds, and if all ok, set SV = 1 (10 seconds prevents "flapping")

PGM2a: "VARIABLE CONTROL 2a"
(Upon getting HB,  AND if sensor WET is NOT 'ON' (Thus NO LEAK))...
  (Sets SV to 1(All ok), waits 25hrs for HB, if not received, then sets SV to 2 (HB Missed!)
  (So SV should always be at 1(ok), unless wet or HB missed)
  ...IF 25 Hours pass, it sets SV to 2 (HB MISSED)
  ...Which then gets noticed by PGM5 below

PGM2b: "VARIABLE CONTROL 2b"
(Upon getting HB,  AND if sensor WET-STATUS=ON (yuk! LEAK!))...
  (LEAVES SV at CURRENT VALUE (NO CHANGE)
  (waits 25hrs for HB, then sets SV to 2 "HB MISSED")
  (note: the WET-STATUS=ON "COULD" still be from last wet sensed event...
  (...then reset button needs to be pushed to CLEAR the alarm)

PGM3: "MODIFY VARIABLE CONTROL 3" ;Keeps an eye that above 2a/2b's are RUNNING!
IF State Variable = 1 (all normal, or so it appears!)
  AND if last runtime of 2a/2b above is MORE that 26hours (should be 25 hours max!)
  THEN set StateVariable to 3 to indicate it has been too long!
---or---
IF State Variable = 9 (LEAK DETECTED!)
  AND if last runtime of 2a/2b above is MORE that 26hours (should be 25 hours max!)
  THEN set StateVariable to 3 to indicate it has been too long!

======= ======= COMMUNICATIONS ======= =======
Note: PGMS4-5 below are ONE only (not one per sensor)...

PGM4: "LEAK SENSOR ACTIVATION"  ;WET sensed!!
IF StateVariable is set to "9"(yuk! LEAK!) then
  Send notification to LIST with content CONTENT

PGM5: "LEAK SENSOR PROBLEM" ;Something OTHER than "WET sensed"
IF TIME 9AM or 6PM (If problem, send out alerts at both 9am and 6pm)...
  And if ANY problems (StateVariable is NOT "1")
  Then send notification to LIST with content CONTENT"LeakSensorProblem"







 

Edited by johnstonf
Posted (edited)

Belias Wet Sensor Program Flow

v1.03/17jan17

This is simply to OVERVIEW the Belias program... to help understand what is going on.

It's more of a "birds eye" view, to grasp the concepts before DIGGING IN.

It can be a bit overwhelming when you first get into ISY programming, so I hope this

helps a newbie (like i was), to get "over the hump"... it's not hard after you grasp it.

<snippage>

 

I take it you got it working and tested OK then!

 

That is the way I started verbatim. Then I started changing names to something understandable and more sane.

After that more mods happenned. LOL

 

I still find most of it unreadable without hours of studying.

 

Nice!

Edited by larryllix
Posted

I take it you got it working and tested OK then!

 

That is the way I started verbatim. Then I started changing names to something understandable and more sane.

After that more mods happenned. LOL

 

I still find most of it unreadable without hours of studying.

 

Nice!

 

After hours of wasted time on the 'other' program... threw it out, and started over...

Now at least have a working program!

totally agree!...

NOT the nicest thing to look at (but works!)

I'd like to look at yours, and make mine more readable.

Thanks!

Fred

Posted

After hours of wasted time on the 'other' program... threw it out, and started over...

Now at least have a working program!

totally agree!...

NOT the nicest thing to look at (but works!)

I'd like to look at yours, and make mine more readable.

Thanks!

Fred

I sent a complete package over PM to you when you initially posted about LS monitoring not functioning correctly.

Posted (edited)

Oh man,

 

I was so interested in your PM, i totally missed the "attachment" lol!

 

Thanks!

 

I'll let the one i set up last night settle in, and then make changes based on yours.

 

Fred

Edited by johnstonf
Posted

Oh man,

 

I was so interested in your PM, i totally missed the "attachment" lol!

 

Thanks!

 

I'll let the one i set up last night settle in, and then make changes based on yours.

 

Fred

The method I use is to drop all your programs into a folder and disable it with

If 1 is not 1...etc..

That gets them out of the way until proven lesser than what you are doing.

 

The usual way is to copy each program and disable all the originals.

 

Of course you know what may come....delete all your experimentation and re-enable the originals, if it happening for you.

BTW; Mine may be confusing for you at first. When I label things, I have learned from experience to make the labels meaningful.

 

Like not calling a program "Failure" and having it run True while no failure is happening. Looking at these from a distance on MobiLinc Pro I hate seeing all my BattLow programs running True, when they should be called BattOK. You should see a lot of  logic reversals, due to my Canadian persnickettyness.. LOL

Posted

The method I use is to drop all your programs into a folder and disable it with

If 1 is not 1...etc..

That gets them out of the way until proven lesser than what you are doing.

 

The usual way is to copy each program and disable all the originals.

 

Of course you know what may come....delete all your experimentation and re-enable the originals, if it happening for you.

BTW; Mine may be confusing for you at first. When I label things, I have learned from experience to make the labels meaningful.

 

Like not calling a program "Failure" and having it run True while no failure is happening. Looking at these from a distance on MobiLinc Pro I hate seeing all my BattLow programs running True, when they should be called BattOK. You should see a lot of  logic reversals, due to my Canadian persnickettyness.. LOL

i like your logic to make things naturally logical!

  (just need to get my head around reversing the logic, etc)

  (I use mobilinc also (on Android))

 

i'm not familiar with your first 3 lines:

The method I use is to drop all your programs into a folder and disable it with

If 1 is not 1...etc..

That gets them out of the way until proven lesser than what you are doing.

 

-Wouldn't the programs then stop (be disbled) until i either enable them again or replace them?

-What to you mean using if 1 is not 1 (I know it's short for false, but not how you use it... put all into then to programatically disable?)

  (is this a quick way to disable while testing NEW, and then reverse the logic to re-enable them?)

/f

Posted

i like your logic to make things naturally logical!

  (just need to get my head around reversing the logic, etc)

  (I use mobilinc also (on Android))

 

i'm not familiar with your first 3 lines:

The method I use is to drop all your programs into a folder and disable it with

If 1 is not 1...etc..

That gets them out of the way until proven lesser than what you are doing.

 

-Wouldn't the programs then stop (be disbled) until i either enable them again or replace them?

-What to you mean using if 1 is not 1 (I know it's short for false, but not how you use it... put all into then to programatically disable?)

  (is this a quick way to disable while testing NEW, and then reverse the logic to re-enable them?)

/f

Yeah, that's the idea.

Not only to get the old programs out of the way, but turn them off while you develop new ones, without interference.

 

If it doesn't work, or you are finished for that session, do the same with the new ones and turn the old ones back on for the night until the next development session by removing the condition or making it

"If 1 is 1"

Posted

Great ideas, thanks for the tips!

 

 

 

Yeah, that's the idea.

Not only to get the old programs out of the way, but turn them off while you develop new ones, without interference.

 

If it doesn't work, or you are finished for that session, do the same with the new ones and turn the old ones back on for the night until the next development session by removing the condition or making it

"If 1 is 1"

  • Like 1
Guest
This topic is now closed to further replies.

×
×
  • Create New...