I’m not sure where this post fits best–mods please relocate if necessary.
Those of us with private wells likely have water pumps that are detected by Sense. My well pump is tracked very accurately and I use Sense to get a rough idea of how much water I’m using, as pump runtime is correlated directly to water usage. Private well systems with conventional pumps use a pressure tank to provide water storage so that the pump doesn’t need to run each time water is used. Modern pressure tanks use a design where the tank is bisected by a rubber bladder. Water stays on one side of the bladder, and pressurized air is added to the other side of the bladder. Over time, the pressurized air migrates through the rubber and is absorbed into the water, requiring the tank to be refilled with compressed air. Eventually, the bladder ruptures and the tank needs to be replaced. Sense is able to detect both of these events (low pressure and broken bladder) by tracking pump runtime. When the bladder is intact and properly pressurized, the pump cycle time is some value greater than 30 seconds, ideally over a minute. As the pressure in the tank decreases, the pump cycle time also decreases. Sense could establish a baseline cycle time, and alert the user when the time reduces below a threshold amount, indicating that the tank needs maintenance.
This would be a helpful alert, as this maintenance is easy to forget and reduces the lifetime of the pump and tank bladder when neglected.
Another way to detect such a problem is to set an alert for the pump if it runs much longer than it should. I ha e this setup for my water heater in case there is a leak somewhere. Even a drip would cause the heater to run longer than normal.
If your pump never runs longer than a couple of minutes then set a custom alert for five minutes, there is your leaky bladder detector and any other leak after the pump.
Unfortunately setting an alert for high pump runtime does not alert to this problem, as the issue appears as low pump runtime instead. As the air pressure decreases, the effective capacity of the water tank decreases, lowering the cycle time.
I"ll second or third this. I actually popped in this morning to request an alert feature for a device that hasn’t been on for a period of time. I’m thinking of my sump pump. I’ve had it fail a couple times over the last 20+ years and, as you can imagine, it’s a real nasty mess. If I could catch it sooner rather than later, that would be significant.
Well pump short cycling would be a useful alert. We have an old galvanized non-bladder pressure tank that needs to be filled with air annually as the air slowly dissolves into the water. With Sense I can watch the pump runtime drop from 58 seconds after recharge to around 30 or lower when it’s time to add more air.
Would also second the request for a device not running. Our chest freezer runs every few hours and is always detected. It’s out in a shed where we might not notice failure for a few days, and it sometimes has up to $1000 worth of food in it. Would be nice to get an alert if it doesn’t run for 12+ hours.
Device not running already exists. Under notifications, you have the option to alert after device has been ON for X time or OFF for Y time.
It think for the purpose of this thread, the first fix would be adding seconds as a time interval in the alerts. Right now its days / hours / minutes.
The second solution / feature would be adding a “On X times in Y time”. So its not just, it ran less than 30 seconds, but it ran 10 times in an hour.
I just set up the freezer alert, “off for 12 hours”, thanks for reminding me that was possible.
For a well pump, the logic really does need to be “on for less than X seconds”; 15 seconds would be a good alert threshold for most pressure tank setups.
Running X times in Y time would be harder to set correctly. It’s possible (but unlikely) for the well pump to run 60 times in an hour in normal operation (during lawn irrigation for example), and still rather unlikely for it to run 60 times in an hour even when it is short-cycling.
As a broader goal, I would be in favor of using your machine learning algorithm to determine “normal” device behavior, and then allowing users to select “alert me when this device is behaving unusually.” This would include long periods of inactivity for cyclic devices like refrigerators, changes in average runtime or in number of starts per day, etc. I imagine it may be easier to write code to detect changes in behavior than to write all of the possible alert logic into the user interface.
This is an excellent point and I’m guessing the Sense geeks are well aware of this logic … that you could build in a bunch of alert conditions and/or hooks to IFTTT or you could wait for the algorithm logic and the dataset to catch up. This is essentially what machine learning is all about and no-doubt Sense geeks struggle with this on a daily basis.
The other inevitable clash of philosophies is Sense-native vs Smart Plug detection. You could even extend that logic (the decision of whether to put something on a smart plug) to the Sense itself: “Sense has detected a potentially critical device, a pressure pump, with a complex electrical signature and recommends installation of a smart plug”. [This, btw, is what I would do in this case @pswired]
By extension … where are my cute little plug-n-play Sense Smart Plugs (or is it a temporary device calibrator?) with a cool orange LED?
I have a well pump too. I have had a leak in an underground supply line. As I look back at sense, my well pump normal usage was 30-50 cycles a day. With the leak, it had gone up to over 400. I suggested that there be an alert for X number of cycles per hour or day. I still thank sense for helping find this leak, but an alert would have helped weeks ago!
You bring up a great point: that “always wired” devices that cycle on and off (or are “always on” or even “always always on”), all establish over time what would seem like a recognizable signature on a larger scale.
I’ll call it the meta-signature. Not that this hasn’t been thought about at length before of course:
Sense is no-doubt working on device failure detection (e.g. wonky fridge compressor; bad HVAC) and these meta-signatures are used in that goal, but it would appear that there are much easier potential methods where meta-signatures can be applied:
A device meta-signature is recognized as Always (always) On at a near-fixed wattage (particularly that device on a smart plug, e.g. a NAS!) and so lends itself to a default OFF alert.
A device is recognized as having an Always On component and then a further longer-period cycle (hourly/daily) … e.g. a fridge/freezer. OFF alert!
A device is recognized as having a long-period cycle that is potentially seasonal: “Hey your radiant floor heat is on in the middle of Summer and battling your AC!”
A device is recognized as having a typical short-period cycle within a long-period cycle triggered by something potentially non-seasonal, e.g. well pump, pool pump, sump pump. “Hey your pump seems to be running for waaaay too long”
Of course, these targets could be treated similarly to the Goals feature, at a device level … but that misses the point of Sense’s (potential) background intelligence. Perhaps a user input device-level Goals feature would be the way to instruct the failure detection, but that would add clutter and confusion and detract from the ideal of Sense just taking care of things by recognizing patterns that humans don’t.
Before we (I) get too excited about the easy implementation of this: Remember that it’s already a very difficult task to reliably do Sense-native device detection so on some level the meta-signature is just added complexity and would seem to only come after the device detection is robust. However, the addition of smart plugs into the Sense system does offer reliable device-level “detection” … and so with that knowledge there is an interim path to a certain level of failure alert autonomy.
AND if you’re thinking “but my device is 240V”: It dawns on me that with my second Sense dedicated to a hot water tank that the Goals actually function in this way so a certain level of failure or reliable frequent-cycling detection is already possible!