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.