Yapay zekâ tarafından English dilinden çevrildi ·
Entegratör olarak yazıyorum. Bir müşterinin sahada yaklaşık 300 pompa kontrolörü var; kendi firmware’imizi çalıştıran ESP32-S3 kartları, hepsi MQTT üzerinden Hermetry’ye bağlı. Sitelere göre birkaç ayarı uzaktan değiştirmemiz gerekiyor: raporlama aralığı, basınç okumasında bir ölü bant ve NTP sunucusu (bazı siteler genel havuzları engelliyor).Ekipte iki yaklaşım masada:
- Ayarların JSON parametreleri olarak verildiği, ok/hata yanıtı dönen bir komut, örneğin
cfg.set - Cihazın uyguladığı paylaşılan öznitelikler
Benim için önemli olanlar: belirli bir cihazın bir değeri uyguladığını kesin olarak bilmek ve çevrimdışı cihazlar için değişiklikleri kaybetmemek. Bazı kırsal siteler bir seferde iki üç gün bağlantıdan düşüyor.Firmware zaten açılışta flash’tan bir JSON yapılandırması okuyor, yani değerleri uygulamak zor kısım değil. Cihazlar 60 s’de bir rapor veriyor ve LTE yönlendiricileri ile saha Wi-Fi’sinin karışımının arkasında. Hermetry hangi yaklaşım için tasarlanmış ve istenen-ile-raporlanan görünümü gibi bir şey var mı?
Integrator here. A customer has about 300 pump controllers in the field, ESP32-S3 boards running our own firmware, all on MQTT to Hermetry. We need to change a few settings remotely, per site: the reporting interval, a deadband on the pressure reading, and the NTP server (some sites block the public pools).
Two approaches on the table internally:
- a command, say
cfg.set, with the settings as JSON params, answered with ok/error - shared attributes that the device applies
What I care about: knowing for certain that a given unit has applied a value, and not losing changes for units that are offline. Some rural sites drop off for two or three days at a time.
The firmware already reads a JSON config from flash at boot, so applying the values is not the hard part. The units report every 60 s and sit behind a mix of LTE routers and site Wi-Fi. Which way is Hermetry built for, and is there anything like a desired-vs-reported view?
Yapay zekâ tarafından English dilinden çevrildi ·
Burada bir öğrenciyim, merak ettim: bu neden önemli olsun ki? Ayarları içeren bir komut bana daha basit geliyor.
Student here, curious: why would it matter? A command with the settings in it sounds simpler to me.
Yapay zekâ tarafından English dilinden çevrildi ·
Çevrimdışı bir cihaza gönderilen komutlar yalnızca kalıcı olarak gönderilirse beklemeye alınır ve bu da en fazla 7 gün sonra vazgeçilmesine neden olur. Öznitelikler durumdur, komutlar ise eylemlerdir. Ben öznitelikleri tercih ederim.
Commands to an offline unit only wait if you send them persistent, and that gives up after 7 days at most. Attributes are state, commands are actions. I’d go attributes.
Yapay zekâ tarafından English dilinden çevrildi ·
Daha küçük bir filoda bunu komutlarla yaptık ve bir ünite her komutu kaçırdığında bu her seferinde bir karmaşaya dönüştü. Hangi ünitelerin hangi rapor aralığına sahip olduğunu kimse söyleyemiyordu.
We did it with commands on a smaller fleet and it was a mess every time a unit missed one. Nobody could tell which units had which interval.
Yapay zekâ tarafından English dilinden çevrildi ·
cfg.* paylaşımlı öznitelikleri kullanın, tam olarak bunun için tasarlandılar ve istenen ile raporlanan değer karşılaştırmasını ek bir çaba olmadan elde edersiniz.Anahtarları profilin Configuration keys sekmesinde tanımlayın (tür, etiket, sınırlar), ardından bunları paylaşımlı öznitelik olarak ayarlayın: cfg.telemetry.interval_s, cfg.pressure.deadband_bar, cfg.ntp.server. Cihaz değişiklikleri v1/attributes/set üzerinden alır, uygular ve uygulanan değeri aynı anahtarla istemci özniteliği olarak geri bildirir. Hermetry ikisini karşılaştırır ve Attributes sekmesinde her anahtar için In sync, Pending, Rejected veya Drifted durumunu gösterir.Cihaz tarafında, her bağlantıdan sonra:
SUBSCRIBE v1/attributes/set
PUBLISH v1/attributes/req/1 {"sharedKeys": "cfg.*"}
# v1/attributes/res/1 üzerindeki yanıt -> hepsini uygula -> geri bildir:
PUBLISH v1/attributes {"cfg.telemetry.interval_s": 300, "cfg.pressure.deadband_bar": 0.05}Kırsal sahalarınızı kapsayan şey bağlantıdan sonraki istektir: üç gündür çevrimdışı olan bir ünite geri geldiğinde tüm cfg.* anahtarlarını ister ve eksiklerini tamamlar. Bir ünite bir şeyi uygulayamazsa, bunu cfg_rejected içinde bildirin, örneğin {"cfg_rejected": {"cfg.ntp.server": "apply_failed"}}; satırda nedeniyle birlikte Rejected görünür. Uygulamayı idempotent yapın, bir mesaj iki kez gelebilir.300 ünite için, cihaz listesi üzerinde bir döngü içinde değerleri API ile yazın (POST …/attributes/shared, çağrı başına en fazla 100 anahtar). Temel değer ve toplu iş ekranları, ayar manifestosu yayınlayan cihazlar (lisanslı cihazlar) içindir; kendi yazılımınızla çalışan cihazlarda yol cfg.* üzerinden geçer. Durum tablosu için Attributes sayfasına bakın.
Use cfg.* shared attributes, that’s exactly what they’re for, and you get the desired-vs-reported view for free.
Declare the keys on the profile’s Configuration keys tab (type, label, limits), then set them as shared attributes: cfg.telemetry.interval_s, cfg.pressure.deadband_bar, cfg.ntp.server. The device gets changes on v1/attributes/set, applies them, and reports the applied value back as a client attribute with the same key. Hermetry compares the two and shows In sync, Pending, Rejected or Drifted per key on the Attributes tab.
Device side, after every connect:
SUBSCRIBE v1/attributes/set
PUBLISH v1/attributes/req/1 {"sharedKeys": "cfg.*"}
# answer on v1/attributes/res/1 -> apply everything -> report back:
PUBLISH v1/attributes {"cfg.telemetry.interval_s": 300, "cfg.pressure.deadband_bar": 0.05}The request after connect is what covers your rural sites: a unit that was offline for three days asks for all cfg.* keys when it comes back and catches up. If a unit can’t apply something, report it in cfg_rejected, e.g. {"cfg_rejected": {"cfg.ntp.server": "apply_failed"}}, and the row shows Rejected with the reason. Apply idempotently, a message can arrive twice.
For 300 units, write the values with the API (POST …/attributes/shared, up to 100 keys per call) in a loop over the device list. The baseline and bulk-job screens are for devices that publish a settings manifest (licensed devices), so with your own firmware cfg.* is the route. Attributes page has the status table.
- 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.