Yapay zekâ tarafından English dilinden çevrildi ·
Uzun süredir okuyucuyuz, ilk kez yazıyoruz. Yaklaşık 300 trafo merkezi izleme cihazı için (ESP32 tabanlı, kendi firmware’imiz), kendi geliştirdiğimiz broker kurulumunu Hermetry ile değiştiriyoruz. Eski kurulumda her ünite grid/<site_id>/<unit_id>/telemetry yoluna yayın yapıyordu ve her ünitenin yalnızca kendi dalına yazabilmesi için büyük bir ACL dosyası tutuyorduk. Bu ACL dosyası sürekli bir sorun kaynağıydı; yeni her saha bir değişiklik ve broker yeniden yükleme anlamına geliyordu.Hermetry dokümanlarını okurken her yerde v1/telemetry görüyorum, cihaz başına topic’lerle ilgili hiçbir şey yok. Bu ya düşündüğümden daha basit olduğu ya da bir sayfayı kaçırdığım anlamına geliyor. Yeni firmware’i yazmadan önce: bir yerde 300 topic tanımlamamız gerekiyor mu, yoksa her cihaz aynı topic’e mi yayın yapıyor? Hepsi aynı topic’i kullanıyorsa, 17 numaralı ünitenin 18 numaralı ünite olarak veri yazmasını neyi engelliyor?Ayrıca site id’sini bir yerde tutmak istiyoruz, çünkü raporlarımız buna göre gruplanıyor.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Bunun için cihaz profilinde özel topic’ler ayarlayabileceğini düşünüyorum? Ben kurulum yaparken bir yerde “Custom topics” seçeneğini görmüştüm.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Bunun devamı olarak, önümüzdeki çeyrekte 40 termostat geliyor ve aynı soruyu ben de sormak istedim.
Following this, we have 40 thermostats coming next quarter and I had the same question.
Yapay zekâ tarafından English dilinden çevrildi ·
Cihaz başına topic gerekmiyor. Hepsi aynı v1/telemetry topic’ine yayın yapar. Hermetry, cihazın giriş yaptığı kimlik bilgisinden kimin konuştuğunu bilir, dolayısıyla token fiilen adres görevi görür. 17 numaralı ünite, 18’in kimlik bilgisine sahip olmadığı için 18 adına yazamaz; bir cihaz yalnızca kendi downlink topic’lerine (v1/attributes/set, v1/rpc/req/+ vb.) abone olabilir, bu yüzden başka bir cihazın mesajlarını da hiç görmez. Tutulacak bir ACL dosyası yok.Kevin’in Custom topic’lerin var olduğu konusundaki haklılığı tartışılamaz, ancak bunlar değiştirilemeyen firmware için: profil bu durumda v1/ dışındaki her topic’i o cihazın telemetrisi olarak alır. Buradaki limitler topic derinliği 8, uzunluk 128 ve cihaz başına 50 farklı topic’tir; “Prefix keys with the topic” seçeneğiyle grid/s12/temp, grid.s12.temp gibi bir anahtara dönüşür. Yeni firmware yazdığınız için bunların hepsini atlayın.Saha kimliği için topic’in parçası yapmak yerine cihazın bir özniteliği olarak tanımlamanızı öneririm. Her dakika değişmediği için telemetriye ait değil.Tüm topic tablosunu içeren referans: MQTT topics and payload reference. Kendi cihazlarımı taşırken öğrendiğim pratik bir şey: her ünitenin kendi kimlik bilgisi olsun. Aynı token’ı paylaşan iki cihaz birbirinin bağlantısını sürekli koparır.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Bu, bütçelediğimden çok daha az iş. Prototip cihaz kendi token’ıyla v1/telemetry konusuna yayın yapıyor; site id artık bir öznitelik ve rapor betiğimiz onu oradan okuyor. ACL dosyasını kaldırmak bu proje için başıma gelen en iyi şey.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
ah tamam, yani özel topic’ler eski firmware için bir çıkış yolu. Bunları karıştırmışım, teşekkürler.
ah ok, so custom topics are the legacy-firmware escape hatch. I’d mixed those up, thanks.
- 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.