Yapay zekâ tarafından English dilinden çevrildi ·
Kevin haklı, ama bu işin yarısı. Bir rüzgar sahasında aynı sorunla karşılaştık.Hermetry’nin MQTT sürümü 3.1.1 ve clean session değeri false olan bir CONNECT, temiz oturum olarak işleniyor. Çevrimdışıyken bir cihaz için kalıcı olarak gönderilmiş komutlar dışında hiçbir şey kuyruğa alınmıyor. Dolayısıyla telemetri için her iki yönde de devam ettirilecek bir oturum durumu yok.Hermetry’nin verdiği garanti gelen yön için geçerli: PUBACK, mesaj kendi tarafında güvenle kuyruğa alındıktan sonra gönderiliyor. Kuyruğa alınamazsa PUBACK gelmez, oturum kapanır ve istemcinin yeniden bağlandıktan sonra tekrar göndermesi bekleniyor. Aynı cihaz, anahtar ve zaman damgasına sahip yinelenen mesajlar bir kez saklanıyor, bu yüzden yeniden gönderim güvenli.Dolayısıyla tampon sizin sorumluluğunuzda ve izlenecek desen şu:
- Her okumayı, kendi ts değeri ms cinsinden olacak şekilde yerel bir depoya yazın (biz bir SQLite dosyası kullanıyoruz).
- Depodan yayınlayın ve bir satırı yalnızca PUBACK’i geldiğinde silin.
- Yeniden bağlandıktan sonra: abone olun, paylaşılan öznitelikleri isteyin, ardından canlı veriden önce birikmiş verileri gönderin.
Birikmiş verileri, doğru zamanlarda görünmesi için {ts, values} dizileri halinde gönderin. Profilde, tüm kayıtları bir dakikadan eski olan mesajlar için ayrı bir Saniyede yeniden oynatılan mesaj sınırı var, bu yüzden uzun bir birikim bir süre içinde boşalır. Hepsi aynı anda görünmezse panik yapmayın.Onay bölümü için MQTT sayfası bir kez okunmaya değer.
Kevin’s right, and that’s half of it. We hit the same thing on a wind site.
Hermetry’s MQTT is 3.1.1 and a CONNECT with clean session false is served as clean. Nothing is queued for a device while it’s offline, apart from commands that were sent as persistent. So no session state to resume, in either direction for telemetry.
What Hermetry does promise is on the way in: the PUBACK goes out only after the message is safely queued on their side. If it can’t be queued you get no PUBACK and the session closes, and the client is expected to resend after reconnecting. Duplicates of the same device, key and timestamp are stored once, so resending is safe.
So the buffer is yours, and the pattern is:
- Write every reading to a local store (we use a SQLite file) with its own ts in ms.
- Publish from the store, delete a row only when its PUBACK arrives.
- After reconnect: subscribe, ask for shared attributes, then send the backlog before live data.
Send the backlog as arrays of {ts, values} so it lands at the right times. The profile has a separate Replay messages per second limit for messages whose records are all older than a minute, so a long backlog drains over a while. Don’t panic when it doesn’t all appear at once.
The MQTT page has the acknowledgement section, worth reading once.