[RELEASE] StreamLabs Smart Home Water Meter Interface

I have created an interface between Classic SmartThings and the StreamLabs Smart Home Water Meter. This is a cloud-to-cloud interface so it consists of a Service Manager (SmartApp) and a Device Handler. The interface provides standard wet/dry water leak notifications when the Water Meter posts a water flow alert. It also provides the ability to control the StreamLabs Home/Away status based on one or more SmartThings modes.

This StreamLabs device does a good job detecting significant leaks anywhere in your house. Mine detects flows down to about 0.3 gallon/minute. This is about an 1/8" stream of water from a faucet. So it won’t help in detecting pin prick pipe leaks but more significant leaks (such as broken ice maker tubing) will probably be detected just fine.

The source is available in my GitHub repository. You will need both the SmartApp code and Device Handler code.

Please review the README.MD file for installation and usage details.

3 Likes

Worth noting that Home Depot currently has the monitor on sale for $170. I haven’t jumped on it yet but I’ve got an eye on it…

Do you have any screen shots of the DH interface? I like that you included wet/dry so it can trigger SHM actions.

FYI- The Device Handler UI looks like:

The configuration page looks like:

1 Like

Thanks. Is the subscription needed for developer API access or will this work with the basic (unpaid) plan?

I do not have a subscription and things obviously work for me. This webpage didn’t even exist when I bought my Water Flow meter and registered for the API key. Note that the page indicates ‘Coming Soon’. I’m hoping that anyone that buys a meter and registers for an API key while things are free will be grandfathered in, but time will tell.

1 Like

First let me say a huge thanks to you for doing this. I’m a new user of StreamLabs, requested the API key last week and received it today.

I just installed your app and DH this afternoon and it’s working great. I am finding some errors in the monthly and yearly totals as compared with the StreamLabs app. I know you mentioned in the readme file they may not exactly sync but from what I can see actually are synching perfectly there’s just some math error in the code displaying incorrect numbers. The error amounts are combinations of the daily, monthly and yearly totals. I’ll work out the details on what I’m seeing and update a little later.

I also wanted to ask if it’s ok to change the polling time down to one minute to obtain a little faster notice of a leak to SmartThings?

After installing your app and looking at the data, it appears the day totals are being added to both the month and year. In other words the day totals exactly match the StreamLabs app but the month and year totals are higher than the StreamLabs by exactly the day amount.

Regarding the polling, I just picked 3 minutes as a reasonable (I thought) trade-off between hitting their server too often and taking too long for an alert. I figured that unless you are away, an alert would take 15 minutes or so anyway so an additional 3 minutes wouldn’t be too bad. StreamLabs didn’t provide any information to say not to poll more often (but I didn’t ask either since I was afraid of their answer.) Starting out, I had thought I would be able to subscribe to the alert and polling wasn’t going to be needed, but as I said in the readme I couldn’t find a way to do this. So feel free to reduce it. I’m guessing you have looked at the code; it is on line 103 of the SmartApp. So the 0/3 would become 0/1 if you wanted a 1 minute poll.

In regards to the water totals, not really sure what the right answer is. You have probably looked at the code and you see I am just displaying whatever the API returns. The API states for the thismonth value: "Total quantity of water units (gallons) since the beginning of the month." We don’t really know what their App displays since I don’t know of a user manual for the App. I am not currently at the location where my device is installed so I can’t do much investigation right at the moment. I’m thinking what might be done is to look at things first thing in the morning, run some water, wait a couple of hours and look at everyone’s totals to come to some conclusion. Also note that StreamLabs reported: “When you use the StreamLabs App, the Monitor reports accumulation and updates the daily usage immediately. The monthly, yearly, monthly comparative, and yearly comparative are cached and recalculated within the hour, so it may take up to an hour for those values to be accurate.”

Yes on line 103. I’ll do some more testing per your suggestion and let you know what I find.

Retired IT but new to ST. I am modifying the SmartApp to close a main water valve upon SL Monitor Alert. Will test and report back. Good first project to learn some new coding.

So I set the SL Monitor in Away from the DH and verified mode in the SL App. Turned on the water and got a push notification from SL App saying water was running in Away mode, but the DH still shows Dry and never changed to wet. Nothing in the Live Log either.

BTW, I’m really pushing StreamLabs to do an official Vendor Integration - we’ll see how eager they are to improve their sales with SmartThings Integration to brag about.

UPDATE: Test was a success. I changed the poll time in the DH from 10 minutes to 3 minutes, set the mode to Away, ran the water, and after about 2 minutes received a push notification (several actually) and the DH went from Dry to Wet and my Dome Home actuator closed my main shutoff valve.

How should we proceed to get these changes implemented since I didn’t check out the code in github?

It isn’t clear how you would like to change my DH or Smartapp/service manager code. It sounds like you have added some code somewhere (I assume the smartapp) that closes your actuator. While that is certainly fine for you to do this in your version, I’m not sure it belongs in a general purpose service manager whose purpose is to be the cloud interface to Streamlabs. I believe the SmartThings paradigm would have that code/functionality in a separate SmartApp. For example, the SmartThings ‘Smart Home Monitor’ Smartapp allows you to monitor your leak detectors (e.g. the Streamlabs DH) and when wet then close an actuator (presumably your Dome actuator DH). So if the Smart Home Monitor is too heavy weight, then you could create your own Smartapp whose sole purpose is to monitor leak detectors and when wet then close a specified actuator. So the DH is an interface to a single type of a device and the Smartapp connects various DHs together. The Service Manager is a special Smartapp to interface to a device’s cloud. You could do this (create a new smartapp) and get some more coding practice. Or maybe I’ve missed what you were saying in your post.

Thanks for explaining that. I hadn’t gotten into the architecture enough yet to realize that your DH creates a ‘virtual’ device that SHM can monitor and then close valves and send messages, etc. I now see that your SM is more for interacting with the SL to set Home/Away and get stats and alerts. So me modifying your SM code was redundant (but a good intro to groovy) and I did get it to control the Dome Home so that was cool.

I have now configured SHM to monitor all leak detectors (of which your DH is one) and to close a valve (my Dome Home) and send me a text. So let me see if I understand correctly: DH creates a virtual device (as if it was a physical leak sensor). The SM polls every 3 minutes and if there is an alarm from SL it sets the device as ‘wet’ which the SHM sees and triggers Valve Close and sends message, etc. according to how it’s configured for Leak Detection.

On another note, I have been pushing SL hard to get officially integrated, so don’t be surprised if they reach out to you about using your code. I would assume that to integrate, they would do an account link using username/password (like other vendors have done e.g TP-Link /Kasa) instead of an API key. I did get 6 months of their Enhanced subscription when I set up an account and activated the Monitor (so I could use the API key) for free so hope they get the integration done in that timeframe as I will not pay for a subscription.

Thanks for creating this. Although pricey, I like the SL Monitor as a non-intrusive flow meter. I think in many cases, the work that Community Members do inspires device vendors to integrate their products into ST, as I hope SL does with their Monitor.

Although I’m really good at plumbing, it was nice to just clamp on a Dome Home actuator and a SL Monitor and be done with it.

FYI: the new Monitor went wonky last night after I installed and this am showed 300gal used and was in alarm state (installed correctly on new clean pipe, etc) so re-calibrated and it seemed OK today. Called to get procedure to reset totals because they don’t provide that function in App (they are considering it) and they can’t reset on their end. You have to remove the location (not the device) from your account and start from scratch re-installing the Monitor. Finally got it back up and running (it’s tempermental about WiFi when setting up). However, the DH quit talking to it even though the SL Location and API key was the same. Couldn’t even remove the SM without first force removing the DH then SM. Reinstalled SM which brought back the DH and everything started working again. So beware if you have to remove the location from your account and set up again to reset totals - it may crash the SmartApp and require a complete re-install. Don’t forget to re-assign the SL device in any automations…

I believe you have the basic paradigm right. I’m not sure I would characterize a ‘Device Handler’ as creating a ‘virtual’ device since it is real. Maybe call it a standardized device or something like that. That is, regardless of the technology involved with a given leak detector, it just boils down to an attribute of wet or dry. So the DH provides a standard interface method to all types of leak detectors.

If StreamLabs did create an interface, you are correct that they should use the account method instead of the API key; the API key seems to be oriented for personal/ non=-commercial use. Unfortunately, I didn’t realize that SmartThings didn’t provide a mechanism to subscribe to events if you use API keys until I was mostly done with my implementation. So that is why I ended up polling. There are mechanisms for subscriptions with an account however. I suppose I could go back & get StreamLabs to allow me an account access and re-code everything to use it- maybe some day.

I also preferred to just have a strap on interface to my plumbing for both leak detection and actuating the valve. I wish the StreamLabs was able to detect smaller leaks however. So I still have a handful of traditional leak detectors in various places.

I had spent a lot of time (far too much) debugging the removal of the Device Handler and SmartApp; it was pretty wonky and at times acted like recursive code. So I’m glad you were able to get them removed.

It was reported to me recently that the Device Handler was registering false leak alerts due to high temperatures near the StreamLabs sensor. Upon investigation, it appears that StreamLabs changed their interface to allow for additional non-leak alerts. Unfortunately they did it in a way that broke my integration; it would have been nice if they alerted developers but that is another story. My SmartApp has now been modified to handle the new API and will only report a leak when the alert is a leak (not the other kind). Hopefully it has been done in a way that would accommodate further changes by StreamLabs, but who knows. My GitHub repository has the new version. The Device Handler didn’t change. So any user should remove the old SmartApp (which will automatically remove the Device Handler) and update to the new SmartApp.

1 Like

Step one worked fine. Step two has me confused. It says go to TERMINAL. What is a treminal, my PC, my phone, Smartthings app? I see nothing called terminal to add me API to

I’m not sure where you are hanging up. Is this a step in the referenced README.MD? I couldn’t find any references to TERMINAL in that and I couldn’t find any references to TERMINAL in this posting either.

First thank you for the timely reply. it is much appreciated.
I did get past that and it set up okay. Everthing seems fine, but get a message “we’re having trouble connecting. Check your network connection and try again later”

I did put the API Key in
Stramslabs location name, I used name I assgiend to the devce “house basement water monitor”
IDE level says “IDE Live Logging Level: Messages withthis level and higher will be logged to the iDE”

I will go through it again tomorrow with a fresh mind.

Great; good luck.
FYI: I assume you are using the new App and not the classic App. The basic functionality works 100% with the new App (wet/dry; home/away control), however the user interface with the device handler is now limited. You can no longer ‘pause’ wet detection, manually change home/away, or view water usage. This is a result of Samsung’s changes in roll-out of the new App. I have been waiting for better guidance on how to update to the new App but IMHO, they have really dropped the ball on this. I’ve been following the postings regarding this, but seem to have a way to go. Their tool to help with the transition is still in Alpha release.

Luckily, the important part of my App/DH still works in regards to leak detections. I’m considering implementing a kludge in the near future and will let people know if successful.

Here is the erro that live logging shows

b654837e-922b-4fab-a623-5b0c08dcbbb2 3:01:58 PM: error groovy.lang.MissingMethodException: No signature of method: script_app_75a3f4d584059c266edad4976187233f18c353948707abc5b58419962e2f9457.logger() is applicable for argument types: (org.codehaus.groovy.runtime.GStringImpl, java.lang.String) values: [StreamLabs SM updated() called- new device with settings: [SL_awayModes:[Night, Home, Away], SL_locName:house basement water monitor, configLoggingLevelIDE:3], …]
Possible solutions: page(), pages(), grep(), image(java.lang.String), image(java.util.Map, java.lang.String), page(java.lang.String, java.lang.String) @line 69 (updated)