Skip to content

Suppress duplicate received message frames - #321

Draft
pfmos wants to merge 1 commit into
meshcore-dev:mainfrom
pfmos:fix/dedup-received-messages
Draft

Suppress duplicate received message frames#321
pfmos wants to merge 1 commit into
meshcore-dev:mainfrom
pfmos:fix/dedup-received-messages

Conversation

@pfmos

@pfmos pfmos commented Aug 4, 2026

Copy link
Copy Markdown

Draft — opening for direction rather than as a merge candidate. Fixes #320.

Problem

Some firmware delivers the same message frame more than once when a second companion client is connected: once as a live push, and again from the device's sync history because the per-client watermark was not advanced.

Root cause on the firmware side is traced here: ALLFATHER-BV/meshcomod#42 — the watermark advance is gated on the broadcast succeeding to every connected client, so one transient write failure means no client's watermark advances.

That fix belongs upstream, but I think the integration is worth hardening regardless: it currently processes whatever arrives, so any firmware that delivers a frame twice produces duplicates here.

Impact today

  • Duplicate meshcore_message events and duplicate logbook entries
  • Automations triggering on meshcore_message fire twice per message. In my case that includes a bot that replies over LoRa, so a duplicate has a real cost in airtime on a shared channel
  • MeshCore Chat's message store fills at twice the expected rate

Approach

Entities, the logbook and user automations each subscribe to the SDK dispatcher independently, so there's no existing single point to filter at. This wraps dispatcher.dispatch() after connect, which is the one place that covers every subscriber.

  • Only CONTACT_MSG_RECV and CHANNEL_MSG_RECV are deduped. Adverts, telemetry and status frames pass through untouched.
  • Signature is (event type, pubkey prefix, channel index, sender timestamp, text).
  • Bounded LRU, 256 entries, 30 second window — so a genuine repeat of identical text from the same sender after 30s still comes through.
  • Guarded with _ha_dedup_installed so a reconnect doesn't stack wrappers.

Please review carefully

I can't run this against real hardware, so two things need checking by someone who can:

  1. Payload key names — I inferred pubkey_prefix / channel_idx / sender_timestamp / text from the parser. If those differ on some frame types the signature silently degrades to a weaker match.
  2. Wrapping dispatch is a monkeypatch. It works, but you may prefer this as a first-class filter hook in the dispatcher, or pushed upstream into meshcore-py so every consumer benefits. Happy to rework it either way.

Observed on meshcore-ha v2.9.0 / HA 2026.7.4, Heltec V3 running meshcomod, duplicates arriving 80–200 ms apart.

Some firmware delivers the same message frame more than once when a second
companion client is connected: once as a live push, and again from the
device's sync history because the per-client watermark was not advanced.

Entities, the logbook and any automation listening for meshcore_message
subscribe to the dispatcher independently, so each duplicate frame produced
a duplicate of every downstream effect - including automations that transmit
over LoRa, which costs airtime on a shared channel.

Filter at dispatch, which is the single point covering all subscribers.
Only CONTACT_MSG_RECV and CHANNEL_MSG_RECV are deduped; adverts, telemetry
and status frames pass through untouched. Bounded LRU of 256 signatures
over a 30 second window.

Refs meshcore-dev#320
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Received messages are not deduplicated — duplicates when another companion client is connected

1 participant