Von English mit KI übersetzt ·
Langjähriger Leser, erster Beitrag. Wir ersetzen ein selbst entwickeltes Broker-Setup durch Hermetry für etwa 300 Umspannwerk-Monitore (ESP32-basiert, eigene Firmware). Im alten Setup hat jede Einheit nach grid/<site_id>/<unit_id>/telemetry veröffentlicht, und wir hatten eine große ACL-Datei, damit jede Einheit nur in ihren eigenen Zweig schreiben kann. Diese ACL-Datei war eine ständige Quelle von Ärger: Jeder neue Standort bedeutete eine Änderung und einen Broker-Neustart.Beim Lesen der Hermetry-Dokumentation sehe ich überall v1/telemetry und nichts zu geräteindividuellen Topics. Das heißt entweder, dass es einfacher ist, als ich denke, oder dass mir eine Seite fehlt. Bevor wir die neue Firmware schreiben: Müssen wir irgendwo 300 Topics konfigurieren, oder veröffentlicht einfach jedes Gerät auf dasselbe Topic? Und falls alle dasselbe Topic verwenden, was verhindert dann, dass Einheit 17 Daten als Einheit 18 schreibt?Außerdem möchte ich die Site-ID irgendwo behalten, da unsere Berichte danach gruppiert werden.
Long-time reader, first post. We’re replacing a home-grown broker setup with Hermetry for about 300 substation monitors (ESP32-based, our own firmware). In the old setup every unit published to grid/<site_id>/<unit_id>/telemetry and we kept a big ACL file so each unit could only write its own branch. That ACL file was a constant source of grief, every new site meant a change and a broker reload.
Reading the Hermetry docs I see v1/telemetry everywhere and nothing about per-device topics, which either means it’s simpler than I think or I’m missing a page. Before we write the new firmware: do we need to configure 300 topics somewhere, or does each device just publish to the same topic? And if they all use the same topic, what stops unit 17 from writing data as unit 18?
Would also like to keep the site id somewhere since our reports group by it.
Von English mit KI übersetzt ·
Ich denke, dafür kann man im Geräteprofil eigene Topics festlegen? Ich habe beim Einrichten meines eigenen irgendwo die Option „Custom topics“ gesehen.
I think you set custom topics in the device profile for that? I saw a „Custom topics“ option somewhere when I was setting up mine.
Von English mit KI übersetzt ·
Anschließend an diesen Beitrag: Wir bekommen im nächsten Quartal 40 Thermostate und ich hatte dieselbe Frage.
Following this, we have 40 thermostats coming next quarter and I had the same question.
Von English mit KI übersetzt ·
Keine Topics pro Gerät nötig. Alle 300 veröffentlichen auf dasselbe v1/telemetry. Hermetry erkennt anhand der Zugangsdaten, mit denen sich das Gerät angemeldet hat, wer spricht, das Token ist also faktisch die Adresse. Gerät 17 kann nicht als 18 schreiben, weil es die Zugangsdaten von 18 nicht besitzt, und ein Gerät kann nur seine eigenen Downlink-Topics abonnieren (v1/attributes/set, v1/rpc/req/+ und so weiter), sieht also ebenfalls nie Nachrichten anderer Geräte. Keine ACL-Datei zu pflegen.Kevin hat recht, dass es Custom-Topics gibt, aber die sind für Firmware gedacht, die man nicht ändern kann: Das Profil behandelt dann jedes Topic außerhalb von v1/ als Telemetrie des jeweiligen Geräts. Die Grenzwerte dabei sind Topic-Tiefe 8, Länge 128 und 50 verschiedene Topics pro Gerät. Mit „Prefix keys with the topic“ wird aus grid/s12/temp ein Schlüssel wie grid.s12.temp. Da du neue Firmware schreibst, lass all das weg.Für die Standort-ID würde ich ein Attribut des Geräts verwenden statt eines Teils des Topics. Sie ändert sich nicht minütlich, gehört also nicht in die Telemetrie.Referenz mit der vollständigen Topic-Tabelle: MQTT topics and payload reference. Eine praktische Sache aus meiner eigenen Umstellung: Gib jeder Einheit ein eigenes Zugangsdatum. Zwei Geräte mit demselben Token werfen sich ständig gegenseitig raus.
No per-device topics needed. All 300 publish to the same v1/telemetry. Hermetry knows who’s talking from the credential the device logged in with, so the token is effectively the address. Unit 17 can’t write as unit 18 because it doesn’t have 18’s credential, and a device can only subscribe to its own downlink topics (v1/attributes/set, v1/rpc/req/+ and so on), so it never sees another device’s messages either. No ACL file to keep.
Kevin’s not wrong that Custom topics exist, but they’re for firmware you can’t change: the profile then takes any topic outside v1/ as telemetry of that device. Limits there are topic depth 8, length 128 and 50 distinct topics per device, and with „Prefix keys with the topic“ grid/s12/temp becomes a key like grid.s12.temp. Since you’re writing new firmware, skip all of that.
For the site id I’d make it an attribute of the device instead of part of the topic. It doesn’t change every minute so it doesn’t belong in telemetry.
Reference with the full topic table: MQTT topics and payload reference. One practical thing from when I moved my own stuff: give every unit its own credential. Two devices sharing one token keep kicking each other off.
Von English mit KI übersetzt ·
Das ist deutlich weniger Arbeit, als ich eingeplant hatte. Das Prototyp-Gerät veröffentlicht mit eigenem Token auf v1/telemetry, die Site-ID ist jetzt ein Attribut, und unser Reportskript liest sie von dort. Die ACL-Datei loszuwerden ist das Beste, was diesem Projekt passieren konnte.
That’s a lot less work than I’d budgeted. Prototype unit is publishing to v1/telemetry with its own token, site id is now an attribute and our report script reads it from there. Killing the ACL file is the best thing to happen to this project.
Von English mit KI übersetzt ·
ah ok, also sind eigene Topics der Ausweg für die Legacy-Firmware. Ich hatte das durcheinandergebracht, danke.
ah ok, so custom topics are the legacy-firmware escape hatch. I’d mixed those up, thanks.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Mitdiskutieren
Melde dich an, um Fragen zu stellen und zu beantworten, hilfreiche Beiträge mit „Gefällt mir“ zu markieren und die Antwort zu kennzeichnen, die dein Problem gelöst hat. Jeder Beitrag bringt Punkte und Stufen.