Yapay zekâ tarafından English dilinden çevrildi ·
Güneş enerjisi santralinde bir uç kutuda çalışan bir Go servisimiz var; invertörleri okuyor ve MQTT üzerinden QoS 1 ile Hermetry’ye yayınlıyor. Bağlantı, günde birkaç kez, genellikle 30 sn ile birkaç dakika arasında kopan bir 4G yönlendirici.Zihnimdeki model, yıllar önce kendi Mosquitto’umuzu çalıştırırken oluşmuştu: broker QoS 1 mesajlarını diske kalıcı olarak yazar, istemci clean session = false ile yeniden bağlanır ve kuyruğa alınmış her şey teslim edilir. Bu yüzden istemcide CleanSession değerini false yaptım ve Hermetry’nin her iki yönde de bizim için veri tuttuğunu varsaydım.Bir kopmadan sonraki geçmişe baktığımda, tam olarak kesinti süresi uzunluğunda boşluklar görüyorum. Hermetry’nin broker’ı mesajları kalıcı olarak saklamıyor mu? Açmam gereken bir ayar var mı, yoksa tamponlama benim sorumluluğum mu?Şimdiye kadar kontrol ettiklerim: cihazın Log sekmesi, beklendiği gibi keepalive_timeout ile bağlantı kopmasını ve birkaç dakika sonra yeniden bağlanmayı gösteriyor. İstemci loglarımız ise kesinti sırasındaki yayınların hatasız döndüğünü söylüyor; bu da broker’ın mesajları aldığını düşünmemi sağladı. Invertör okumaları her 30 saniyede bir, invertörün kendi saatinden (NTP ile senkronize) alınan bir ts ile {“ts”: …, “values”: {…}} biçiminde gönderiliyor. Geçmişin eksiksiz olması gerekiyor çünkü saha sahibi aylık faturayı buradan kesiyor; bu yüzden günde birkaç dakikanın eksik olması gerçekten paraya mal oluyor.
We run a Go service on an edge box at a solar site that reads inverters and publishes to Hermetry over MQTT with QoS 1. Link is a 4G router that drops a few times a day, usually for 30 s to a few minutes.
My mental model came from running our own Mosquitto years ago: the broker persists QoS 1 to disk, client reconnects with clean session = false, everything queued gets delivered. So I set CleanSession false on the client and assumed Hermetry holds things for us both ways.
Looking at the history after a drop I see gaps of exactly the outage length. Is Hermetry’s broker not persisting? Do I need to switch some setting on, or is the buffer my job?
What I checked so far: the device’s Log tab shows the disconnect with keepalive_timeout and a reconnect a few minutes later, as expected. Our client logs say the publishes during the outage returned without error, which is what made me think the broker had them. Inverter readings are every 30 s with a ts we take from the inverter’s own clock (NTP synced), sent as {“ts”: …, “values”: {…}}. We need the history to be complete because the site owner bills from it monthly, so a few minutes missing per day actually costs money.
Yapay zekâ tarafından English dilinden çevrildi ·
Tam kesinti süresi kadar olan boşluklar, aracının mesajları kaybettiğinden çok, kesinti sırasında hiç yayın yapılmadığına benziyor. İstemciniz bağlantı kesilmişken bile mesajları kuyruğa alıyor mu?
Gaps of exactly the outage length sounds like nothing was published at all during the outage, not like the broker lost them. Is your client even queuing while disconnected?
Yapay zekâ tarafından English dilinden çevrildi ·
İyi nokta. Paho Go, varsayılan bellek içi depoyla çalışıyor. Çevrimdışıyken mesajları kuyruğa aldığını varsaymıştım.
Good point. Paho Go with the default in-memory store. I’d assumed it queues while offline.
Yapay zekâ tarafından English dilinden çevrildi ·
Yönetim tarafından bakınca: entegratörümüz boşluklarla ilgili aynı şeyi söyledi, sonunda cihaza depolama ekledilər. Ayrıntıları veremem, üzgünüm.
From the management side: our integrator told us the same thing about gaps, they ended up adding storage on the box. Can’t tell you the details, sorry.
Yapay zekâ tarafından English dilinden çevrildi ·
Hermetry’de Clean session false ayarı zaten işe yaramaz. Belgelerde bunun clean session olarak sunulduğundan oldukça eminim.
Clean session false won’t help on Hermetry anyway. I’m fairly sure the docs say it’s served as a clean session.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Evet. Paho bellek deposu bağlantı kesildiğinde her şeyi atıyordu, yani Maria’nın tahmini de tam isabetliydi. Yayımcının önüne bir bbolt dosyası koydum, PUBACK alındığında siliyor, ayrıca 5 dakika boyunca 4G anteni çekerek test ettim: yeniden bağlandıktan yaklaşık 20 sn sonra birikmiş veriler doğru zaman damgalarıyla geçmişte göründü. Bir işe yaramadığı için CleanSession=false satırını da kaldırdım.
Yep. The Paho memory store was throwing everything away on disconnect, so Maria’s guess was spot on too. Put a bbolt file in front of the publisher, delete on PUBACK, and pulled the 4G antenna for 5 minutes as a test: backlog showed up in history with the right timestamps about 20 s after reconnect. Removed the CleanSession=false line as well since it did nothing.
Yapay zekâ tarafından English dilinden çevrildi ·
Eklemek istediğim bir şey: yerel depolamaya bir üst sınır koyun. Bir keresinde bir saha 9 days boyunca çevrimdışı kaldı ve disk doldu. Saklama süresinden eski okumalar zaten reddediliyor.
One thing to add: cap the local store. We had a site offline for 9 days once and the disk filled up. Readings older than your retention get refused anyway.
- 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.