Companion Firmware v1.14.0 – Änderungen im Überblick

Companion v1.14.0 – Änderungen im Überblick

Changelog auf Github: Release Companion Firmware v1.14.0 · meshcore-dev/MeshCore · GitHub

Protokoll-Version

  • FIRMWARE_VER_CODE: 9 → 10

  • Neue Felder im Frame-Protokoll: path_hash_mode in RESP_CODE_DEVICE_INFO (v10+)


1. Wählbare Pfad-Stempel-Größe (Path Hash Mode)

Was ist das?
Wenn ein Paket durch das Mesh wandert, hinterlässt jeder Repeater einen kurzen „Stempel" (Hash), damit der Rückweg bekannt ist. Bisher war dieser Stempel immer 1 Byte groß.

Was ist neu?
Die Companion kann jetzt wählen, ob der Stempel 1, 2 oder 3 Bytes groß sein soll.

Warum ist das nützlich?

  • 1 Byte = 256 verschiedene Stempel → bei vielen Nodes können zwei denselben haben → falsche Zustellung möglich.

  • 2 Bytes = 65.536 verschiedene Stempel → Verwechslungen fast ausgeschlossen.

  • 3 Bytes = über 16 Millionen → für sehr große Netze.

Wie stellt man das ein?
In der App (sofern sie v10 unterstützt) oder per Befehl an die Companion. Drei Stufen: 0, 1 oder 2 (entspricht 1, 2 oder 3 Bytes). Standard ist 0 (1 Byte, wie bisher).

Gilt das für alle Sendungen?
Ja – Adverts, Nachrichten, Gruppen-Chat und alle anderen Flood-Pakete verwenden die eingestellte Größe.

Muss ich die Repeater auch umstellen?
Die Einstellung muss nur am sendenden Gerät (dem Companion) gesetzt werden – Repeater lesen die Hash-Größe automatisch aus dem empfangenen Paket und leiten es entsprechend weiter. Allerdings müssen alle Repeater im Pfad mindestens Firmware v1.14.0 haben, weil ältere Firmware das neue Format nicht versteht. Je nach Zustand des Pakets wird es entweder sofort verworfen oder so falsch interpretiert, dass es unbrauchbar ist – in keinem Fall kommt es korrekt an.

Wird die Einstellung gespeichert?
Ja, sie bleibt nach einem Neustart erhalten.

Empfehlung zur Verwendung von Multibyte Path Hashes

Kurz: Nicht umstellen, solange nicht alle Nodes im Netz auf v1.14.0+ sind.

Warum?

  1. Gemischte Netze sind das Problem. Sobald ein einziger Repeater im Pfad alte Firmware hat, kommen Pakete mit 2- oder 3-Byte-Hashes nicht an. Es gibt keine Fehlermeldung oder Rückfallmechanismus – das Paket ist einfach weg.

  2. Kein Auto-Fallback im Code. Der Sender weiß nicht, ob alle Repeater im Pfad v1.14.0+ haben. Es gibt keinen Mechanismus, der bei Nicht-Zustellung automatisch auf 1-Byte zurückfällt. Auch die Path-Discovery (createPathReturn) übernimmt die Hash-Größe aus dem empfangenen Paket – wenn das originale Flood-Paket nicht ankommt, gibt es keine Discovery.

  3. 1-Byte reicht für die meisten Netze. 256 mögliche Stempel sind nur dann ein Problem, wenn viele Repeater im selben Pfad stehen. Die relevante Kollisionsgröße ist nicht die Gesamtzahl der Nodes, sondern die Anzahl der Hops in einem einzelnen Pfad. Bei typischen Pfaden von 3–5 Hops ist die Kollisionswahrscheinlichkeit bei 1-Byte-Hashes gering.

Wann lohnt sich der Wechsel auf 2 Bytes?

  • Alle Nodes (Repeater, Companion, Room Server, Sensor) im Netz haben v1.14.0+.

  • Pfade mit 10+ Hops sind üblich.

  • Es gibt regelmäßig Zustellprobleme, die auf Hash-Kollisionen zurückzuführen sein könnten.

Wann lohnt sich 3 Bytes?

Praktisch nie. Der Overhead (3× mehr Path-Bytes = mehr Airtime) steht in keinem Verhältnis zum Gewinn gegenüber 2 Bytes. 65.536 verschiedene Stempel bei 2 Bytes reichen für jedes realistische Mesh.


2. Kontaktfilter nach Entfernung (Max Hops)

Was ist das?
Neue Einstellung, die bestimmt, bis zu welcher „Entfernung" (Hop-Anzahl) neue Kontakte automatisch gespeichert werden.

Was ist neu?
Man kann jetzt festlegen:

  • 0: Kein Limit – alle Kontakte werden gespeichert (wie bisher).

  • 1: Nur direkte Nachbarn (0 Hops dazwischen).

  • z.B. 4: Nur Kontakte, die maximal 3 Hops entfernt sind.

Warum ist das nützlich?
Wer in einem großen Netz steht, sieht manchmal hunderte Kontakte, von denen viele viel zu weit weg sind, um zuverlässig erreichbar zu sein. Mit diesem Filter werden nur nahe Kontakte automatisch hinzugefügt. Weit entfernte Kontakte erscheinen trotzdem kurz in der App (als „gesehen"), werden aber nicht dauerhaft gespeichert.

Wie stellt man das ein?
Über die App. Maximum ist 64 (entspricht dem vollen Hop-Bereich des Protokolls).


3. Fehlerbehebungen

Was war kaputt? Was passiert jetzt?
Advert-Pfade wurden falsch an die App übermittelt Pfade mit 2- oder 3-Byte-Stempeln werden jetzt korrekt an die App gesendet. Vorher konnten bei neuen Stempelgrößen falsche Pfaddaten ankommen.
Pfad-Prüfung bei Kontakt-Discovery Die Companion prüft jetzt korrekt, ob ein empfangener Pfad gültig ist – auch bei Multibyte-Stempeln. Vorher konnten gültige Pfade fälschlich abgelehnt werden.
Timeout-Berechnung bei Direktnachrichten Das Timeout für direkt geroutete Nachrichten basiert jetzt auf der Anzahl der Hops im Pfad, nicht auf der Byte-Länge. Vorher konnte ein 2-Byte-Pfad mit 3 Hops als 6 Hops interpretiert werden → unnötig langes Warten auf Bestätigung.
„Pfad vergessen" Fehler Der Wert für „unbekannter Pfad" war inkonsistent. Jetzt wird überall der gleiche Wert (0xFF) verwendet. Kein Einfluss auf die Nutzung, aber stabiler im Hintergrund.

4. Neues Verhalten bei Sendeverzögerungen

Was ist neu?
Wenn die Companion Pakete weiterleitet (im Client-Repeat-Modus), berechnet sie jetzt die Wartezeit vor dem Senden basierend auf der tatsächlichen Paketgröße – inklusive der größeren Pfade bei Multibyte-Stempeln.

Warum ist das nützlich?
Größere Pakete brauchen mehr Sendezeit. Wenn die Wartezeit das nicht berücksichtigt, können sich Pakete im Netz überlappen und sich gegenseitig stören. Jetzt passt die Wartezeit automatisch zur Paketgröße.


5. App-Kommunikation (für App-Entwickler relevant)

Änderung Auswirkung
Geräteinfo enthält Path Hash Mode Wenn die App die Geräteinfos abfragt, enthält die Antwort jetzt ein zusätzliches Byte mit dem aktuellen path_hash_mode. Apps, die das nicht kennen, ignorieren es einfach.
Neuer Befehl: Path Hash Mode setzen Die App kann den path_hash_mode direkt setzen (Werte 0, 1 oder 2). Ungültige Werte werden mit einer Fehlermeldung abgelehnt.
Auto-Add-Konfiguration erweitert Beim Setzen der Auto-Add-Einstellungen kann jetzt ein drittes Byte für max_hops mitgegeben werden. Beim Abfragen wird es ebenfalls mitgeliefert.

6. Abwärtskompatibilität

  • Ältere Apps: Funktionieren weiterhin. Die neuen Bytes in der Geräteinfo und der Auto-Add-Konfiguration werden einfach ignoriert.

  • Ältere Firmware-Versionen im Netz: Pakete mit 1-Byte-Stempeln (Standard) sind voll kompatibel. Pakete mit 2- oder 3-Byte-Stempeln werden von alter Firmware (< v1.14.0) verworfen, weil das neue Encoding nicht erkannt wird.

  • Upgrade: Beim ersten Start nach dem Update steht path_hash_mode auf 0 (1 Byte) und max_hops auf 0 (kein Limit) – genau wie vorher.