Tyler, please don’t, eight 120 ohm resistors in parallel load the line to 15 ohm and nothing will talk.

Owen: at 9600 baud a bit lasts about 104 µs. On 30 m of cable a reflection goes up and back in well under a microsecond, so it has died out long before the receiver samples. Termination is about long cables and high baud rates, and you are nowhere near that. That’s David’s answer too.

What you’re missing is biasing. Between frames nobody drives the line, and an unbiased line floats near 0 V differential, so noise looks like start bits. That gives exactly the random, different-meter-each-time errors you see. Many cheap USB dongles have no bias resistors. Put them at the master end: about 680 ohm from A (+) to 5 V and 680 ohm from B (-) to GND. If you later add 120 ohm termination at both ends, bias is no longer optional at all.

Also, in this order:

• Use twisted pair, and run a third wire as signal ground/common. Speaker cable has neither the twist nor the impedance.
• Daisy-chain, no star. Short stubs at each meter.
• In pymodbus, a response timeout of 1 s and one retry, and a short pause between meters.

On the Hermetry side, if a poll fails, send nothing for that meter in that round instead of a 0 or the old value. Then the chart has a small gap rather than a fake reading.

Hardware first. Use an optocoupler: bridge rectifier (or a PC817 with a reverse diode across the LED), 1 kΩ series resistor, 10 µF across the output so the AC ripple doesn’t show up as 50 pulses a second. Transistor side to D5 with INPUT_PULLUP, so the pin goes LOW while it rings. Debounce in code, send ring: 1 on the falling edge, and ring: 0 when it’s quiet again for 2 s.

Then I’d skip the alarm rule. An alarm has a lifecycle (open, acknowledge, clear) and you’d have alarms piling up for every courier. A Rules card rule fits better:

When:  A value changes, device "intercom-d1", value "ring", becomes 1
Then:  Tell people  [x] Members
       Message: "Someone is at the street door"

Members get it in the bell, by push where they’ve set it up (the app, or a browser with push on), and in every chat app they linked under My Profile > Chat apps. So once your admin connects the platform each person links their own account and that’s your phone ping, app or not. Rules card recipients never get e-mail or SMS, for SMS you’d need a flow with a Notify block and phone numbers.

One thing to know: the same notice to the same person is held back for a 10-minute cooldown. Fine for a doorbell mostly, but if two couriers come within 10 minutes the second one only shows up as “(+1)” on the next one. Details: Notifications from rules and flows.

Brian’s right, and you’re also missing the organisation prefix. I set up nearly the same thing for a chiller room last year.

1. API Keys (Developer menu) > New API Key. Under Module permissions give it read-only telemetry, nothing else. Set an IP allowlist to the office’s address, and note the expiry, default is 90 days, a year at most. Put a reminder in the calendar, ours expired on a Saturday.

2. Every management path sits under the tenant:

GET https://<host>/tenant/<tenantId>/api/telemetry/latest?kind=iot_device&entityId=<deviceId>&keys=level_pct
Authorization: Bearer sk_live_...

Answer looks like {“latest”: {“level_pct”: {“ts”: …, “value”: 91.2}}}. Compare the ts with the previous one so you don’t buzz twice on the same reading.

3. Handle 429 and wait the Retry-After seconds. Poll every 30 s or so, the tank doesn’t fill in 5.

The other route, if you want it instant: make the Pi a device itself, have a rule on the tank send it a command when level_pct rises above 90, and let the Pi wait on GET /api/v1/rpc with its own device token. More moving parts, no polling. For a buzzer I’d take the API key. Conventions are on REST API basics.