Suppress duplicate received message frames - #321
Draft
pfmos wants to merge 1 commit into
Draft
Conversation
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
meshcore_messageevents and duplicate logbook entriesmeshcore_messagefire 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 channelApproach
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.CONTACT_MSG_RECVandCHANNEL_MSG_RECVare deduped. Adverts, telemetry and status frames pass through untouched._ha_dedup_installedso 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:
pubkey_prefix/channel_idx/sender_timestamp/textfrom the parser. If those differ on some frame types the signature silently degrades to a weaker match.dispatchis 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.