Zigbee-Temperatursensoren über einen Pi als eigenständige Geräte in Hermetry einbinden
Von English mit KI übersetzt ·
Backend-Entwickler, Hardware allenfalls als Hobby. Ich habe acht kleine Xiaomi-Zigbee-Temperatur-/Feuchtesensoren im Serverraum unseres Büros und im Batterieraum verteilt. Sie koppeln sich mit einem Sonoff Zigbee 3.0 USB-Dongle (CC2652P) an einem Raspberry Pi 4, auf dem zigbee2mqtt läuft, das an einen lokalen mosquitto veröffentlicht. Dieser Teil funktioniert, ich sehe zigbee2mqtt/rack_a_top usw.Dann habe ich versucht, sie mit einer mosquitto-Bridge in Hermetry zu bekommen, wobei zigbee2mqtt/# mit einem einzigen Geräte-Token an den Broker weitergeleitet wird. Zwei Probleme. Standardmäßig kam nichts an, und im Geräteprotokoll stapelten sich abgelehnte Topics, bis die Sitzung geschlossen wurde. Dann habe ich das Profil auf Benutzerdefinierte Topics umgestellt, und es hat funktioniert, aber alle acht Sensoren landen auf EINEM Gerät mit Schlüsseln wie zigbee2mqtt.rack_a_top.temperature, was Alarme und Dashboard zu einem Durcheinander macht.Ich möchte acht Geräte. Brauche ich acht Token und acht Bridges? Das fühlt sich falsch an.
Backend dev, hardware hobbyist at best. I put eight little Xiaomi Zigbee temp/humidity sensors around our office server room and the battery room. They pair to a Sonoff Zigbee 3.0 USB dongle (CC2652P) on a Raspberry Pi 4 running zigbee2mqtt, which publishes to a local mosquitto. That part works, I can see zigbee2mqtt/rack_a_top etc.
Then I tried to get them into Hermetry with a mosquitto bridge, forwarding zigbee2mqtt/# out to the broker with one device token. Two problems. Out of the box nothing arrived and the device log had a pile of rejected topics until the session was closed. Then I switched the profile to Custom topics and it worked, but all eight sensors land on ONE device as keys like zigbee2mqtt.rack_a_top.temperature, which makes alarms and the dashboard a mess.
I want eight devices. Do I need eight tokens and eight bridges? That feels wrong.
Von English mit KI übersetzt ·
Nein, Sie brauchen nicht acht Tokens und acht Bridges. Hermetrys Modell für diese Konfiguration ist Hinter einem Gateway. Die Quellen führen "Sensoren hinter dem eigenen Edge-Computer" als typischen Fall auf, und Ihr Pi mit zigbee2mqtt ist genau das.
So funktioniert es
- Der Pi meldet sich bei Hermetry als ein Gateway-Gerät mit einer eigenen einzelnen Anmeldung an (ein Zugriffstoken ist ausreichend).
- Er meldet Daten für seine untergeordneten Geräte über die **
v1/gw/*-Topics**. Benutzerdefinierte Topics auf einem normalen Gerät funktionieren dafür nicht. - Hermetry legt jedes untergeordnete Gerät an, sobald das Gateway zum ersten Mal Daten dafür meldet. Sie erhalten
rack_a_topund die anderen als acht separate Geräte, ohne jedes von Hand hinzufügen zu müssen. - Jedes untergeordnete Gerät ist ein gewöhnliches Gerät: mit eigenem Profil, eigener Telemetrie, eigenen Attributen, Alarmen und Dashboards. Sie können jedes auch seinem Raum zuordnen (Serverraum oder Batterieraum), sodass Status und Alarmzahlen pro Raum zusammengefasst werden.
- Untergeordnete Geräte haben keine eigene Anmeldung. Das Gateway übermittelt ihre Daten.
Was zu ändern ist
- Machen Sie das Gerät, mit dem sich der Pi verbindet, zu einem Gateway. Ein Gerätedatensatz hat die Eigenschaft "ob es ein Gateway ist", und die Geräteliste zeigt ein Gateway-Abzeichen und einen Filter. Die Quellen hier sagen nicht, wo sie zu setzen ist.
- Passen Sie an, was der Pi veröffentlicht, sodass es den
v1/gw/*-Topics und dem Payload-Format folgt. Eine einfache Weiterleitung vonzigbee2mqtt/#behält die eigenen Topic-Namen von zigbee2mqtt bei. Möglicherweise brauchen Sie auf dem Pi einen kleinen Übersetzungsschritt statt einer reinen Bridge-Umbenennung. Ob eine Bridge allein genügt, hängt vom Payload-Format ab, das im mir vorliegenden Material nicht gezeigt wird. - Stellen Sie das Profil von benutzerdefinierten Topics zurück, damit die Gateway-Topics verwendet werden, statt alles in Schlüssel wie
zigbee2mqtt.rack_a_top.temperaturezu zerlegen.
Zu beachten
- Geräte-Limit: Sowohl das Gateway als auch jedes untergeordnete Gerät zählen zum Geräte-Limit Ihres Tarifs, hier also insgesamt 9.
- Online-Status: Bei untergeordneten Gateway-Geräten stammt er aus den Verbindungs- und Trennungsmeldungen des Gateways.
Die genauen v1/gw/*-Topic-Namen, das Payload-Format und wie untergeordnete Geräte ihre Profile erhalten, stehen auf der Dokumentationsseite Geräte hinter einem Gateway. Die mir vorliegenden Quellen nennen sie nur und geben diese Details nicht an. Prüfen Sie diese Seite daher, bevor Sie die Übersetzung schreiben.
Quellen
No, you don't need eight tokens and eight bridges. Hermetry's model for this setup is Behind a gateway. The sources list "sensors behind your own edge computer" as a typical case, and your Pi with zigbee2mqtt is exactly that.
How it works
- The Pi logs in to Hermetry as one gateway device, with its own single credential (an access token is fine).
- It reports data for its child devices on the **
v1/gw/*topics**. Custom topics on a normal device won't do this. - Hermetry creates each child device the first time the gateway reports for it. You get
rack_a_topand the others as eight separate devices, without adding each by hand. - Each child is an ordinary device: its own profile, telemetry, attributes, alarms and dashboards. You can also place each one on its room (server room or battery room), so status and alarm counts roll up per room.
- Child devices have no credential of their own. The gateway brings their data.
What to change
- Make the device the Pi connects as a gateway. A device record has a "whether it is a gateway" property, and the Devices list shows a Gateway badge and filter. The sources here don't say where to set it.
- Make what you publish from the Pi follow the
v1/gw/*topics and payload format. A plainzigbee2mqtt/#forward keeps zigbee2mqtt's own topic names. You may need a small translation step on the Pi rather than a pure bridge rename. Whether a bridge alone is enough depends on the payload format, which isn't shown in the material I have. - Switch the profile back from Custom topics, so the gateway topics are used instead of flattening everything into keys like
zigbee2mqtt.rack_a_top.temperature.
Keep in mind
- Device limit: both the gateway and each child count toward your plan's device limit, so 9 in total here.
- Online status: for gateway children it comes from the gateway's connect and disconnect messages.
The exact v1/gw/* topic names, the payload format and how children get their profiles are on the Devices behind a gateway docs page. The sources I have only name it and don't give those details, so check that page before writing the translation.
Sources
Von KI aus der Dokumentation und gelösten Themen erstellt. Wenn sie dein Problem gelöst hat, markiere sie als Lösung; wenn nicht, meldet sich das Team bei dir.
- 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.

