Once the Flood sensor and Heavy Duty Smart Switch are installed and learned into the panel, some additional settings have to be enabled on the back end by your dealer for the feature to work correctly. This post above goes over those settings.
Once this is set up on the back end, the switch should report correctly and the Sump Pump card should be visible in your Alarm.com account (provided water management is enabled, which it sounds like it is)
thanks. Looks like something is missing for me.
When I log into my ADC.com account online, I see my water sensors (I have 9 IQ flood sensors, 1 of which is in the sump pump itself), switches showing my Lutron lights and shades and my auto valve shutoff (connected to the flood sensors) and my sump pump switch (Aeotec HDS), and locks etc.
When I log into my adc.com app, I see all the above, plus my Energy usage data tab (associated with the sump pump switch), water sensors tab, and irrigation tab.
In both cases, I don’t specifically see the Sump Pump card or Water Monitoring card as shown in the above post by Jason back in Sept 2017.
Also, when I try to create a Sump Pump Notification in the Standard notifications menu, Sump Pump doesn’t show up.
Just wondering if there is still some back-end integration that is required or something I can do on the user end.
thanks
Just wondering if there is still some back-end integration that is required or something I can do on the user end.
Your service provider would need to associate the Heavy Duty Smart Switch with the Flood Sensor being used to monitor the sump on the back end. This unfortunately cant be done by the end user.
Once the devices are installed/paired with the alarm panel, an Add Sump Pump feature should be available in the service provider’s back end tools.
After that has been enabled , the sump card should show up in your Alarm.com account.
thanks. Dealer did all the necessary back-work and now its fully functional on my end.
Great to hear!
Thought I’d revive this old thread (very useful info and history!), rather than start a brand new one for an almost identical topic. I know that Tyler also posted an excellent (and more recent) thread on this subject here.
While I don’t exactly have a sump pump, I have a grinder pump that is used to process sewage in the basement and pump it up to the sewer line. The main difference is that usage is driven more by normal home water consumption than by environmental conditions, but the failure modes and flood ramifications seem to be comparable. Thus, I was thinking that the applications are similar enough as to justify the same type of monitoring solution, though perhaps opting-out of the “pump is running normally”-type notifications.
Right now I have a grinder pump activated by a control float switch. There is also an alarm float switch, which activates a local alarm. The grinder pump power cable currently connects to a series/piggy-back outlet, which is used for the control float switch, as suggested by these posts. The alarm float switch connects, of course, to the local alarm.
I think that the simplest and least invasive approach would be to just add a flood sensor to the whole arrangement, at the same level as the local alarm float switch. Then, connect power for both the grinder pump and float control switch serially, using the existing piggy-back outlet (just as they are currently powered) to an HDSS.
Some questions:
1.) For my Qolsys IQ2+ panel, I assume that I don’t specifically need the QS5536-840 flood sensor that Tyler called out, but could use the DSC PowerG one for this application, instead? I already have one of these PowerG ones, and would prefer to keep using the same model throughout the house. The only downside to the PowerG variant that I have found is it can only be configured for Group 38 (Reporting), as opposed to the QS5536-840, which appears to also support Group 25 (Non-reporting). Not a huge deal, however, as Reporting would probably be the more appropriate response type for this application anyway.
2.) Any practical feedback on this general approach to sump pump monitoring from other users who have implemented it (xeon, ImpetuousRacer, kcnu, Ben) and had some runtime? Ben, did you ever get a different variation of this solution working, based on using a float switch, rather than a flood sensor? Any recommendations or comments on your experience/application?
3.) If I decide to pick up a compatible Z-wave water valve in the future, can these same “pump failure” conditions be used to do more than just notify/alarm - Can these be used to automatically close the water valve? This is one use case that would make sense using grinder pump, which likely wouldn’t with a traditional sump pump.
The PG9985 should work fine. If you would rather use a float switch or even try to wire into your existing alarm float switch you can connect a normally closed float switch to an S-Line Extended sensor.
Alarm.com launched a smart water valve at CES. That would be the best option although they also support the Fortrezz water valve.
Thanks, Roy, great ideas! So, the PG9985 can be assigned as “Associated Water Sensor” associated on the back end with an HDSS monitoring solution for the Sump Pump monitoring solution depicted here. Just be avoid any potential misunderstanding on my part, can you confirm that the same also true of the S-Line Extended sensor - there would not be a problem assigning it as “Associated Water Sensor”?
Do you know if the S-Line Extended sensor can be configured as non-reporting? While having a reporting water sensor makes sense, I’d want to be careful about potentially using a reporting-only door sensor for this purpose, which could potentially wind up having the police called out for a water issue.
Unfortunately, it appears that my current float switch for the local alarm unit is a Normally Open one, so I’m looking into the possibility of replacing with a Normally Closed one. Answers to the above questions could help steer me back to just using a traditional water sensor (PG9985). I already purchased the HDSS that I’m going to use for this, so just need to finalize a decision as to the most fool-proof water sensing mechanism.
Just be avoid any potential misunderstanding on my part, can you confirm that the same also true of the S-Line Extended sensor - there would not be a problem assigning it as “Associated Water Sensor”?
Yes, you would be able to do that, but we would just need to designate the S-Line extended sensor as a Water Sensor.
By default it would not be selected as a sensor which could be used with the water management tab. We can manually set it as one though if it is a non-reporting sensor, then you can associate it with your Sump Pump.
Do you know if the S-Line Extended sensor can be configured as non-reporting?
Yes it can. Group 25 Local Safety.
Thanks, Jason, I appreciate the answers! One more question (hopefully the last one on this)… I see that the Qolsys QS-7130-840 (8-zone wireless translator) inherently supports Normally Open contacts. Using this would save me the hassle of having to replace my existing Normally Open float switch, without being significantly more expensive.
Could the Qolsys QS-7130-840 be used in an identical manner as we were discussing with the S-Line Extended sensor? That is, configure an associated zone for the N/O loop as non-reporting, and designate it as a Water Sensor on the backend, so that that zone could be used as associated water sensor for the comprehensive sump pump monitoring solution?
In case it matters, I wouldn’t see myself using the remaining zones for any other purpose at this time.
Yes, you should be able to do that, though you would probably want a backup battery, and probably an enclosure for it if you use the battery. The convenience may outweigh the cost, of course that is up to you to decide, but you should be able to get it set up that way.
Thanks, Jason.
OK, so I finally have everything done. I have the grinder pump (and associated float control switch) brought into an HDSS named “Grinder Pump”. This brought it in as a light switch. I disabled Remote Commands, so that it is left on (having this get accidentally turned off be would be really bad). This seems to be working fine.
I then wired in the Normally Open float alarm switch into a Qolsys QS-7120-840 as a Normally Open contact, wiring in a 3.3k Ohm resistor in parallel. When I learned the zone into the panel, I had any number of options, so a brought it in as a Group 38 non-Qolsys water sensor. I named this “Grinder Pump Alarm”.
With functional testing, I see that Grinder Pump Alarm is Inactive (Dry) under normal conditions - perfect. However, when I unplug the grinder pump and then raise the water level in the basin to alarm conditions (causing the float alarm switch to close), rather than read as Active (Wet), it merely shows a Tamper event. Then, when I plug the grinder pump back in and lower the water level in the basin back to normal conditions, I get an End of Tamper.
Are there some back-end adjustments needed for the switch’s closure to drive Active/Wet conditions, rather than Tamper? If not, is something further needed from my end?
Can we proceed with the back-end configuration needed to set up the ADC Sump Pump functionality, based on “Grinder Pump” and “Grinder Pump Alarm”? Thanks!
There’s been some additional odd behavior with this setup. When setting this up and performing functional testing described in my post immediately above, I had tripped the contact at 2:44 PM (which caused the Tamper), and then reset things back to normal at 3:04 PM (which caused the End of Tamper). Since that time I have not played with it any further, and no water has entered the basin.
Suddenly, starting at 5:01 PM, this contact triggered a Pending Alarm. I silenced it, went and checked the basin, and (as expected) found it to be empty (and the float switch open). Wasn’t sure what to think of this…
Then, at 6:01 PM, the same thing happened. Basin still empty. At 7:01 PM, I got another Pending Alarm for the same thing. I had placed the system on test mode for the next week, until I can get things finalized, but this Pending Alarm business every hour on the hour is a whole new wrinkle, and I have no clue what is triggering it.
At this point, I completely powered down the Qolsys QS-7120-840 hardwire translator and avoid further false alarms until we can understand what’s going on. Any help would be greatly appreciated!
It sounds like the sensor is reporting during its supervisory interval, and the status is tamper alarm each time due to the zone type. Triggering the sensor should not cause a tamper.
This is almost certainly a resistance problem.
I then wired in the Normally Open float alarm switch into a Qolsys QS-7120-840 as a Normally Open contact, wiring in a 3.3k Ohm resistor in parallel. When I learned the zone into the panel, I had any number of options, so a brought it in as a Group 38 non-Qolsys water sensor. I named this “Grinder Pump Alarm”.
Is this a new Hardwire 8?
On newer Hardwire 16-F units, Qolsys changed the default behavior of the circuits with regard to resistance. Instead of by default needing to learn in each zone with any resistor between 1-10kohm, it now just looks for 4.7kohm resistance.
Double check the manual that came with the Hardwire 8. Does it indicate the resistance options for the panel?
I bought it new-in-box off of eBay, but I gather it may not be as full-featured as some other models, as I just noticed that this one does not support S-line, like the Qolsys QS-7130-840. If I compare all the latest online manuals (including the 16-F), I see that only the 16-F mentions 4.7k Ohm resistors:
The manual I received with the unit matches the first link exactly.
The only other “odd” thing I can recall in hindsight is that when I learned it in, I did so starting with the switch Closed (it is an N/O contact). Would the state of the contact prior to toggling it when learning it in have any bearing at all? If not, I suppose I can unenroll and try to learn it in again tonight using a 4.7 kOhm resistor while starting off in an Opened state (just to cover both possible basis).
We do not stock the Hardwire 8 currently so I don’t have one to compare on hand, but the pdf for the 8 quick guide linked above is from a 2017 revision. Hopefully it is the most up to date, but just in case, double check the quick guide that came with yours to verify whether it mentions 4.7k resistors.
The only other “odd” thing I can recall in hindsight is that when I learned it in, I did so starting with the switch Closed (it is an N/O contact). Would the state of the contact prior to toggling it when learning it in have any bearing at all?
That would be a problem I believe. Since the Hardwire measures the expected resistance values and must learn in a zone by activating it normally, when activating a NO zone you would need to have it in its rest state, open, then close it to learn it in.
You would need to delete that zone from the panel and reset the memory on the Hardwire 8. Relearn that zone as it would normally activate and you should be good to go.
We can then make any necessary dealer settings adjustments.
So, I checked the quick guide that came with Hardwire 8 wireless translater, and it’s actually even older - from 2015. There was no mention of the 4.7k Ohm resistor, or the UL resistor mode. However, interestingly, the Processor LED blinks at the rate of 8x/sec - just as described for the Hardwire 16-F working in the default/UL resistor mode (as opposed to 1x/sec for the normal 1k-10k Ohm EOL resistor mode).
At any rate, I proceeded as follows:
1.) Unenrolled the sensor
2.) Removed the original 3.3k Ohm resistor and replaced it with a 4.7k Ohm resistor (wired in parallel)
3.) Performed a memory reset on the Hardware 8
4.) Ensured that the N/O float switch was Opened
5.) Learned the sensor into that zone by filling the basin and causing the N/O float switch to Close
Afterwards, the behavior on the Hardware 8 seems consistently normal. The zone LED is always out when the N/O float switch is Open, and lit solid when the N/O float switch is Closed (before the LED would blink and indicate Tamper when Closed). No indications of Tamper at all.
I learned it in as a Water sensor | Other Flood, as I did yesterday. Oddly, despite the Hardware 8’s zone LED indicating properly, general indications on the panel and in the ADC app did not appear to reflect any changes.
Specifically, while N/O float switch is OPEN (normal), I get the following indications:
-Zone LED: Not lit
-ADC App: Indicates “Dry”
-Panel | Home: Closed/Inactive icon
-Panel | Sensor Status: Normal
While N/O float switch is CLOSED (alarm condition), I get the following indications:
-Zone LED: Lit
-ADC App: Indicates “Dry”
-Panel | Home: Closed/Inactive icon
-Panel | Sensor Status: Normal
The panel alarms upon transition, either from opened to closed, or closed to open, which I wouldn’t think is normal.
I haven’t seen any further Tamper alarms. However, at 7:30pm I did get a false flood alarm (basin was dry, and I wasn’t even home). I changed the sensor type from Water | Other Flood to Water | IQ. I haven’t retested yet in this configuration, but I did not get a subsequent alarm at 8:30pm, nor even at 9:30pm. I haven’t functionally tested this configuration yet, and am powering it down the night, just in case of false alarms.
I wonder if the alarm and software indication inconsistencies that I’m currently seeing might just be due to incorrect sensor type configuration that needed to be adjusted (either on my end, or Surety’s end…?). Or perhaps what I have now is correct and merely needs to be retested for confirmation. Please let me know what you think, and next steps. Current sensor’s name is “Grinder Pump Basin”.
Just to verify, did you want to keep it as an alarm-generating sensor type or did you want to set it as a non-reporting type?
If you program it as a flood sensor at the panel, it will generate aux alarms.
If you program it as a door sensor under Sensor Group 25, it will only be used for notifications (no alarms will occur locally), and we can manually select it as a water sensor for you in Alarm.com, allowing you to use the ADC water management features with it.
Either way is fine, but if you do use sensor group 25 we would need to designate it as a water sensor manually.
If you leave it as a flood sensor then that is not needed.
To function as a flood sensor correctly, it sounds like you now have it set to the correct programming values. It should be IQ water, and it should activate an aux alarm when the zone closes, then restore when opened again.
Yes, I’d like to keep it as alarm-generating - at least for now. Since I neglected to get a Hardwire model that performs supervisory functions (should’ve gone with the 16-F!), in the future, I may also add a more traditional water sensor further up in the basin, for extra peace of mind (and then just configure that to report instead).
I powered everything up a couple hours ago and no more false alarms. After seeing your confirmation that I should be using IQ Water, I repeated functional testing. This went better. This time, it only generated an alarm upon closing the contact (did not also generate an alarm upon re-opening the contact/returning to normal conditions).
As before, the zone LED lit upon closure and went out upon opening. The ADC app reporting the sensor in alarm, as expected.
The only things that seemed unusual were panel indications - this continued to show Closed/Inactive icon on the Home screen, and Sensor Status reported Normal. However, this was after I silenced and acknowledged the alarm, but before I re-opened the contact. Just want to confirm that this is expected behavior…? If it is, then let’s please proceed with setting up the sump pump water management feature.
Alright, yes that sounds like it is functioning as I think it should be expected. I believe the IQ Panel will restore the status of the aux alarm sensor after acknowledging the alarm.
We’ve set up the sump pump function for you and you should now be able to view the Sump Pump card from the home page of Alarm.com.