EyeOnWater

EyeOnWater Logo

EyeOnWater is a third party app and service that many small water companies in the US use for monitoring one’s usage and alerting for potential leaks. This add-on scrapes the website for the water meter readings and any alarms that may be active. The data on EyeOnWater is updated once or twice a day so this binding is not suitable for real time monitoring.

NOTE: This binding was mostly implemented through the use of AI. While I reviewed the code manually it is primarily the work of AI.

## Supported Things
This binding supports the following thing types:

  • bridge: Represents the EyeOnWater account connection. It handles authentication, cookie-based session persistence, and schedules background polling.

  • meter: Represents a physical water meter registered under the EyeOnWater account.

## Discovery

Meters associated with your account are automatically discovered and placed into your openHAB Inbox once an EyeOnWater Account Bridge is added and goes ONLINE.

The discovery service queries the EyeOnWater REST API to retrieve all physical meters, automatically mapping their unique meter_uuid and meter_id parameters.

## Thing Configuration

### EyeOnWater Account Bridge (bridge)

To configure the bridge, the following parameters are available:

Parameter Type Required Default Description
username Text Yes The email address or username for your EyeOnWater account
password Text Yes The password for your EyeOnWater account
hostname Text Yes eyeonwater.com EyeOnWater hostname (e.g., eyeonwater.com or eyeonwater.ca)
refreshInterval Integer No `15` Polling frequency in minutes (minimum of 5)
preferNewSearch Boolean No `true` Enable to use the modern search API instead of scraping the legacy dashboard

### EyeOnWater Water Meter (meter)

To manually configure a water meter, the following parameters are available:

Parameter Type Required Description
meterUuid Text Yes The internal unique identifier (UUID) of the meter
meterId Text Yes The physical serial number / ID of the meter

## Channels

The meter thing type exposes the following channels:

Channel ID Item Type Label Description
reading Number:Volume Water Reading The latest total volume consumption reading
leak-flow-rate Number:VolumetricFlowRate Leak Flow Rate Active water leak rate, if any, detected by the meter
leak-alert Switch Leak Alert ON if an active water leak has been detected
low-battery Switch Low Battery Alert ON if the meter battery is running low
reverse-flow Switch Reverse Flow Alert ON if reverse water flow is detected
last-read-time DateTime Last Read Time Exact timestamp of the latest water meter reading

## Full Example

### eyeonwater.things File Configuration

Bridge eyeonwater:bridge:myaccount \[ username="user@example.com", password="secretpassword", hostname="eyeonwater.com", refreshInterval=15 \] {
    Thing meter mymeter \[ meterUuid="abcdef12-3456-7890-abcd-ef1234567890", meterId="12345678" \]
}

### eyeonwater.items File Configuration

Number:Volume          WaterMeterReading   "Water Meter Reading \[%.2f gal\]" <water> { channel="eyeonwater:meter:myaccount:mymeter:reading" }
Number:VolumetricFlowRate  WaterLeakFlowRate   "Water Leak Flow Rate \[%.2f gal/min\]" <water> { channel="eyeonwater:meter:myaccount:mymeter:leak-flow-rate" }
Switch                 WaterLeakAlert      "Water Leak Alert \[%s\]" <alarm> { channel="eyeonwater:meter:myaccount:mymeter:leak-alert" }
Switch                 WaterLowBattery     "Water Meter Low Battery \[%s\]" <battery> { channel="eyeonwater:meter:myaccount:mymeter:low-battery" }
Switch                 WaterReverseFlow    "Water Reverse Flow Alert \[%s\]" <alarm> { channel="eyeonwater:meter:myaccount:mymeter:reverse-flow" }
DateTime               WaterLastReadTime   "Water Last Read Time \[%1-%1-%1 %1:%1:%1\]" <time> { channel="eyeonwater:meter:myaccount:mymeter:last-read-time" }

Changelog

-0.2: A few more changes. None address behavior. All are code quality/coding standards changes requyested by the maintainers.

  • 0.1: Lots of changes mostly dealing with Thing life cycle and edge cases. Basic functionality remains the same.
  • initial release

Resources

https://github.com/rkoshak/openhab-addons/releases/download/eyeonwater/org.openhab.binding.eyeonwater-5.3.0-SNAPSHOT.jar

nice. scrape cadence note is useful. once or twice a day fits how those portals usually refresh anyway.

curious how brittle the cookie/session keep-alive is when they rotate auth. did you hit any forced re-login during testing?

Not really. Once connected it seems to stay connected without complaint. Since installing the add-on again early yesterday afternoon after posting it here, the debug logs just show it polling every fifteen minutes (which is way faster than needed but useful for debugging and testing) without fail. I can’t say how long the auth lasts though because I’ve been making changes all week so I’ve not had a lot of time to just let it run for a long period of time. But the auth seems to last at least a day.

Nice work on this. I like that you’ve been upfront about the polling limitations, since that seems important for anyone considering using it for leak monitoring.

The fact that the session has stayed connected for at least a day is encouraging too. I’d be interested to see how it behaves over a longer period, especially if the EyeOnWater authentication changes or the service has an outage.

I could definitely see this being useful in an openHAB setup for keeping an eye on overall water usage and getting an alert when something unusual shows up. The leak-flow-rate and reverse-flow channels in particular seem like they could be handy for automations.

I let it run unrestarted over the weekend and there seemed to be no problems. The maintainers had me change from using standard HTTPClient to using Jetty’s HTTPClient in the mean time which probably invalidates this whole test anyway. But in general even if it disconnected once per hour, the binding would just reauthenticate. This is considered normal by the binding so that’s only logged at the debug level.

Overall this whole exercise was an attempt to see ho hard it is to create an OH binding even with the support of AI. And the easiest part was authenticating with EyeOnWater and scraping the web page. All the stuff that deals with the openHAB Thing lifecycle management, multithreading restirctions, etc is way more complicated. It shouldn’t be that way.