Zigbee sıcaklık sensörlerini bir Pi üzerinden Hermetry'ye ayrı cihazlar olarak almak
Yapay zekâ tarafından English dilinden çevrildi ·
Backend geliştiricisiyim, donanımla en fazla hobi düzeyinde ilgileniyorum. Ofisimizin sunucu odası ile akü odasının çevresine sekiz küçük Xiaomi Zigbee sıcaklık/nem sensörü yerleştirdim. Bunlar, zigbee2mqtt çalıştıran bir Raspberry Pi 4 üzerindeki Sonoff Zigbee 3.0 USB dongle (CC2652P) ile eşleşiyor ve yerel bir mosquitto’ya yayın yapıyor. Bu kısım çalışıyor, zigbee2mqtt/rack_a_top gibi konuları görebiliyorum.Sonra bir mosquitto köprüsü ile bunları Hermetry’ye almaya çalıştım; zigbee2mqtt/# konusunu tek bir cihaz token’ı ile brokera yönlendirdim. İki sorun var. Varsayılan ayarlarla hiçbir veri gelmedi ve oturum kapatılana kadar cihaz günlüğünde reddedilen konuların yığını oluştu. Sonra profili Özel konular olarak değiştirdim, bu sefer çalıştı; ancak sekiz sensörün tamamı zigbee2mqtt.rack_a_top.temperature gibi anahtarlarla TEK bir cihaza düşüyor ve bu da alarmları ve paneli karmaşık hale getiriyor.Sekiz cihaz istiyorum. Sekiz token ve sekiz köprü gerekir mi? Bu doğru gelmiyor.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Hayır, sekiz token ve sekiz köprüye ihtiyacınız yok. Hermetry’nin bu kurulum için modeli Bir ağ geçidinin arkasında. Kaynaklar, "kendi edge bilgisayarınızın arkasındaki sensörler" durumunu tipik bir örnek olarak listeliyor ve zigbee2mqtt kullanan Pi’niz tam olarak bu durumdadır.
Nasıl çalışır
- Pi, Hermetry’ye tek bir ağ geçidi cihazı olarak, kendi tek kimlik bilgisiyle giriş yapar (erişim token’ı da uygundur).
- Alt cihazları için verileri **
v1/gw/*konularında** bildirir. Normal bir cihazdaki özel konular bunu yapmaz. - Hermetry, ağ geçidi bir alt cihaz için ilk kez veri bildirdiğinde o alt cihazı oluşturur.
rack_a_topve diğerlerini, her birini elle eklemeden sekiz ayrı cihaz olarak alırsınız. - Her alt cihaz normal bir cihazdır: kendi profili, telemetrisi, öznitelikleri, alarmları ve panoları vardır. Ayrıca her birini odasına (sunucu odası veya batarya odası) yerleştirebilirsiniz, böylece durum ve alarm sayıları oda bazında toplanır.
- Alt cihazların kendi kimlik bilgisi yoktur. Verilerini ağ geçidi iletir.
Neyi değiştirmelisiniz
- Pi’nin bağlandığı cihazı bir ağ geçidi yapın. Bir cihaz kaydında "ağ geçidi olup olmadığı" özelliği vardır ve Cihazlar listesinde bir Gateway rozeti ile filtresi görünür. Buradaki kaynaklar bunun nerede ayarlanacağını söylemiyor.
- Pi’den yayımladıklarınızı
v1/gw/*konularına ve veri biçimine uygun hale getirin. Düz birzigbee2mqtt/#yönlendirmesi, zigbee2mqtt’nin kendi konu adlarını korur. Saf bir köprü yeniden adlandırması yerine Pi üzerinde küçük bir çeviri adımına ihtiyacınız olabilir. Yalnızca bir köprünün yeterli olup olmadığı, elimdeki materyalde gösterilmeyen veri biçimine bağlıdır. - Profili Özel konulardan geri çevirin, böylece her şey
zigbee2mqtt.rack_a_top.temperaturegibi anahtarlara düzleştirilmek yerine ağ geçidi konuları kullanılır.
Aklınızda bulundurun
- Cihaz limiti: hem ağ geçidi hem de her alt cihaz planınızın cihaz limitine dahildir; bu durumda toplam 9.
- Çevrimiçi durumu: ağ geçidinin alt cihazları için bu, ağ geçidinin bağlantı ve bağlantı kesme mesajlarından gelir.
Kesin v1/gw/* konu adları, veri biçimi ve alt cihazların profillerini nasıl aldığı, Bir ağ geçidi arkasındaki cihazlar dokümantasyon sayfasında yer alır. Elimdeki kaynaklar yalnızca bunun adını veriyor ve bu ayrıntıları vermiyor, bu yüzden çeviriyi yazmadan önce o sayfayı kontrol edin.
Kaynaklar
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
Belgelerden ve çözülmüş konulardan YZ tarafından yazıldı. Sorununuzu çözdüyse çözüm olarak işaretleyin; çözmediyse ekip sizinle ilgilenecek.
- Bu konuyu yanıtlamak için giriş yapmış olmalısınız.
Sohbete katılın
Soru sormak ve yanıtlamak, yararlı gönderileri beğenmek ve sorununuzu çözen yanıtı işaretlemek için oturum açın. Her katkı puan ve seviye kazandırır.

