Files
Mattias Jonsson 308fd14e61 Add water usage to Bresser-Garden, fix truncated 16-bit fields
Follow-up to the initial Bresser SmartHome Garden decoder.

The Water Timer meters the water it delivers. Emit that as water_usage_l
from the 0x04 watering event, and from the 0x02 status report and 0xa1
run response, which both carry the last completed run's figure. The unit
is 0.1 L, checked against the app's own display and a measured volume.
The meter is rated 5-35 L/min and reads true within that band but
under-reads below it, which the doc-comment records so the number is not
taken as exact at drip flow rates.

Three little-endian fields were read one byte wide, silently truncating
any value above 255: the 0x04 run duration (a 360 s run reported 104),
the 0x21 run-command duration, and the water usage itself (a 41.0 L run
reported 15.4 L).

Decode more of the protocol: soil_rssi in the 0x0a relay, the trigger's
third source (the button on the Water Timer itself), and the 0x86 water
limit, which the valve enforces on its own. Give every frame a msg_name
and a full msg_type so consumers can tell frames apart, and report each
frame under the model of its actual transmitter.

Correct the direct-mode description: with "Relay Communication" off the
soil sensor talks straight to the gateway with 0x03, on a different
frequency, so it is not the never-emitted type the header claimed. The
sensor also receives - pairing, config and acks all reach it.

Harden the decode: reject msg_length above 20, since the payload cannot
run past b[30] with the CRC in the last two of the fixed 33 bytes;
require exactly one row; fix the 0x86 plan count to (msg_length - 1) / 7
for the 1-byte header, accepting only the two valid lengths; cast the id
bytes before shifting into the sign bit; and read the soil temperature
as signed. Replace eight copies of the raw-payload hex loop with one
bounded helper.

Rework the doc-comment into a protocol spec: frame envelope, per-message
payload layouts, per-channel frequencies, and an explicit list of what
remains undecoded.
2026-07-27 20:35:16 +02:00
..
2026-07-09 00:49:18 +02:00