DEV Community

Xingliao Smart Home
Xingliao Smart Home

Posted on

Why a Smart Home Catalog Has No Continuous Water Level Sensor

Search a consumer smart home catalog for "water level sensor" and almost every result is a leak detector: a small puck with two contacts that reports wet or dry. That is not a naming mistake, and it is not a missing product that someone forgot to list. It reflects how these devices are modelled. Home automation deals in events such as a door opened, motion detected, or water present, while level measurement deals in a continuously varying number. The two need different hardware, different data models, and different expectations from the buyer.

The data model is the real constraint

A leak detector is a binary sensor. In ZigBee terms it is an IAS zone or a binary input: it reports an alarm state, clears the alarm, and reports battery and tamper. One bit carries the entire payload. That makes it cheap, battery powered, wireless, and trivial to wire into an automation: if water, then close the valve and send a notification.

A level sensor produces a number that changes every minute: 62 percent, 61.8, 61.5. To be useful it needs calibration, a reference for empty and full, temperature compensation for the speed of sound in ultrasonic units, and a history so the buyer can see a trend. A single bit cannot express that. The gap between the two devices is not sensitivity; it is that one returns a state and the other returns a measurement.

For the practical distinction between the two, and where leak detectors genuinely earn their price, see the Tuya water level sensor guide.

Why the catalog is built around events

Consumer platforms optimise for notifications, not charts. The app has an alert surface, a scene engine, and a device tile; it rarely has a time-series view. Wireless battery devices are designed to sleep for months and wake only to report a change, because continuous sampling would drain a coin cell in days. Everything about the ecosystem, meaning clusters, interface, radio duty cycle, and cloud storage, assumes "something happened" rather than "here is the current value".

Industrial level measurement went the other way. Ultrasonic, pressure, capacitance, and float transmitters output 4-20 mA or 0-10 V, or speak Modbus, and are wired to a controller that logs values. Those signals do not map onto a Smart Life tile without a gateway that converts an analog reading into a percentage attribute and a cloud service willing to store it. That converter exists, but it is a project component, not a retail SKU.

Write the requirement before the part number

The most common sourcing error is an RFQ that says "water level sensor" with no indication of which question it must answer. Decide first:

  • Do you need to know that water has appeared somewhere it should not be? That is leak detection, binary, cheap, and battery powered.
  • Do you need to know how full a tank is right now, within a few percent? That is level measurement, continuous, usually mains powered.
  • Do you need to know the trend, so a pump can be started before the tank empties or a refill scheduled before it overflows? That is measurement plus logging plus control logic, and it is a small control system.

Each step up that list changes the power supply, the mounting, the calibration procedure, and the price by an order of magnitude. An installer who orders the first item for the third requirement will get a device that works perfectly and tells them nothing useful.

Where percent full quietly fails

Even when a converter is present, three things are commonly overlooked. First, the reference: an ultrasonic unit needs the distance from the sensor face to the full mark, and that distance is a property of the installation, not the product. Second, the dead band: most ultrasonic heads cannot read reliably within 20 to 30 cm of the face, so a "100 percent full" reading is often unreachable and the top of the tank must be treated as an alarm zone rather than a measurement. Third, the surface: foam, turbulence from an inlet, condensation on the transducer, and a sloped or irregular tank wall all corrupt the echo.

A leak detector has none of these problems because it does not measure distance. It is less capable and considerably more reliable in a damp, dirty, unattended location. That trade is worth stating honestly rather than presenting a level product as an upgraded leak product.

What a hybrid installation looks like

On a real site the two are complements. Put leak detectors at the floor under the tank, the pump tray, and the pipe joints, meaning the places where an unexpected puddle is the failure. Put a continuous level transmitter on the tank if the process needs the number, and run its 4-20 mA output to a controller or a gateway that exposes a percentage. Let the binary sensors own the alarms and let the transmitter own the readings. Trying to make one device serve both roles produces either an expensive alarm or an unreliable gauge.

The sensors and alarms category shows the event-driven side of that split; reading it alongside a level-transmitter datasheet makes the boundary obvious.

Questions for a supplier

Ask whether the device reports a state or a value, and in what unit. Ask for the measurement range, the dead band near the sensor, the accuracy at the low end rather than the midpoint, and whether calibration survives a power cycle. Ask who stores the history and for how long. Ask what the device does when the cloud is unreachable, since a local alarm that still closes a valve is worth more than a chart that stops updating.

If the answer to "can I see the level" is "you get a notification when it is full", you are looking at a leak detector with a different label. Those are excellent devices, and XingLiao Tech covers the manufacturing side of the category, but they are not a gauge. For custom firmware identity or a private product ID on an OEM run, the OEM/ODM programme is the route, and that is a commercial decision rather than a sensor specification.

Top comments (0)