Yapay zekâ tarafından English dilinden çevrildi ·
Muhtemelen aptalca bir soru ama anlatayım. Sokak dolaplarındaki (enerji ölçümü, pilot projenin parçası) ESP32 kontrolcülerimiz Hermetry’ye v1/telemetry üzerinden QoS 1 ile veri yayınlıyor, token ile giriş yapılıyor, sorunsuz çalışıyor; okumalar her dakika panoda görünüyor.
Eklemek istediğim iki şey var:
1. Her dolabın da v1/telemetry konusuna abone olmasını istiyorum; gönderdiği verinin gerçekten ulaştığını doğrulayabilsin (bir meslektaşımın fikri, “yankı kontrolü” dedi)
2. Depodaki küçük bir e-kağıt ekran ünitesinin 3 numaralı dolabın telemetrisine abone olmasını istiyorum; böylece ekip hiçbir şeye giriş yapmadan kWh değerini görebilsin
İkisi de çalışmıyor. Abone olma çağrısı true dönüyor, PubSubClient’tan hata yok, bağlantı açık kalıyor ama hiçbir şey gelmiyor. v1/telemetry/# ve # de denedim, aynı sonuç. Bir istemci yayınladığı konuya abone olamaz mı? Yoksa konuyu yanlış mı yazdım?
client.subscribe("v1/telemetry", 1); // returns true
client.publish("v1/telemetry", "{"kwh":1203.4}");
// callback never firesEkran da Hermetry’de kendi cihazı ve tokenı olan aynı ESP32 kartı, eğer önemliyse.
Probably a dumb one but here goes. We have ESP32 controllers in street cabinets (energy metering, part of a pilot project) publishing to Hermetry on v1/telemetry, QoS 1, token login, works fine, readings show up on the board every minute.
Two things I wanted to add:
1. have each cabinet subscribe to v1/telemetry too, so it can confirm what it sent actually landed (a colleague’s idea, he called it an “echo check”)
2. have a little e-ink display unit in the depot subscribe to cabinet 3’s telemetry so the lads can see the kWh without logging into anything
Neither works. The subscribe call returns true, no error from PubSubClient, connection stays up, but nothing ever arrives on either. Tried v1/telemetry/# and # as well, same story. Is a client just not allowed to subscribe to a topic it publishes to? Or have I got the topic wrong?
client.subscribe("v1/telemetry", 1); // returns true
client.publish("v1/telemetry", "{"kwh":1203.4}");
// callback never firesDisplay is the same ESP32 board with its own device and token in Hermetry, if that matters.
Yapay zekâ tarafından English dilinden çevrildi ·
Takipteyim. MQTT’nin herkesin her şeyi gördüğü bir grup sohbeti gibi olduğunu varsaydım?
Following. I assumed MQTT was like a group chat where everyone sees everything?
Yapay zekâ tarafından English dilinden çevrildi ·
Düz bir broker üzerinde görebiliyor. Depodaki bir Pi üzerinde Mosquitto çalıştırıp dolapların oraya da yayın yapmasını sağlayabilirsiniz. Yalnız biraz karmaşık olur, iki farklı yere gönderim yapmak gerekir.
On a plain broker it is. You could run Mosquitto on a Pi in the depot and have the cabinets publish there as well. Bit messy though, two places to send to.
Yapay zekâ tarafından English dilinden çevrildi ·
Bu sizin konunuz değil. Hermetry, bir cihazın yalnızca kendi aşağı yön (downlink) konularına abone olmasına izin verir: v1/attributes/set, v1/attributes/res/+, v1/rpc/req/+, v1/rpc/up/res/+ ve v1/cert (ayrıca ağ geçitleri için gw konuları). Bir cihaz asla başka bir cihazın mesajlarını almaz ve kendi yukarı yön (uplink) mesajlarını görmez. Tablo MQTT topics and payload reference sayfasındadır. İlk projemde ben de aynı şeye takılmıştım.
1 numaralı konu için hiç yankıya ihtiyacınız yok. PUBACK onayın kendisidir: Hermetry, mesajı güvenli şekilde kuyruğa aldıktan ve yayımladığınız sırayla işledikten sonra bunu gönderir. Okumayı, PUBACK’i gelene kadar tamponunuzda tutun, ardından silin. Oturum bundan önce kapanırsa, yeniden bağlandıktan sonra tekrar gönderin; aynı anahtar ve zaman damgasına sahip yinelenen mesajlar yine de yalnızca bir kez saklanır.
2 numaralı konu için ekranın MQTT’yi hiç dinlemesine gerek yok. Ona bir API anahtarı verin ve birkaç dakikada bir en son değeri REST üzerinden okusun:
GET https://<your host>/tenant/<tenantId>/api/telemetry/latest?kind=iot_device&entityId=<cabinet3 id>&keys=kwh
Authorization: Bearer sk_live_...Anahtarı yalnızca okuma yetkili yapın (telemetri okuma yeterlidir), deponun genel adresini anahtarın IP izin listesine ekleyin ve son kullanma tarihine dikkat edin: varsayılan 90 gün, en fazla bir yıl. Bu yüzden anahtar yenileme için bir hatırlatıcı ekleyin. Ardından ekranın cihazını da silebilirsiniz, buna ihtiyacı yok.
It’s not your topic. Hermetry only lets a device subscribe to its own downlink topics: v1/attributes/set, v1/attributes/res/+, v1/rpc/req/+, v1/rpc/up/res/+ and v1/cert (plus the gw ones for gateways). A device never gets another device’s messages and never sees its own uplinks. The table is on MQTT topics and payload reference. Bit me too on my first project.
For 1 you don’t need an echo at all. The PUBACK is the confirmation: Hermetry only sends it once the message is safely queued, and in the order you published. Keep the reading in your buffer until its PUBACK arrives, drop it then. If the session dies before that, send it again after reconnect, duplicates with the same key and timestamp are stored once anyway.
For 2 the display shouldn’t be listening on MQTT at all. Give it an API key and let it read the latest value over REST every few minutes:
GET https://<your host>/tenant/<tenantId>/api/telemetry/latest?kind=iot_device&entityId=<cabinet3 id>&keys=kwh
Authorization: Bearer sk_live_...Make the key read only (telemetry read is enough), put the depot’s public address in the key’s IP allowlist, and note the expiry: 90 days by default, a year at most, so put a reminder in for the rotation. Then you can delete the display’s device too, it doesn’t need one.
Yapay zekâ tarafından English dilinden çevrildi ·
Polling yapmak, sadece subscribe olmaktan daha ağır olmaz mı?
wouldn’t polling be heavier than just subscribing?
Yapay zekâ tarafından English dilinden çevrildi ·
Tek bir cihazdan beş dakikada bir mi? Hayır. Ayrıca okumalar mesaj kotasına dahil edilmez; kota, cihazların gönderdiği telemetri ve öznitelikler içindir.
Once every 5 minutes from one box? No. And reads don’t count toward the message quota, that’s telemetry and attributes the devices send.
Yapay zekâ tarafından English dilinden çevrildi ·
Çözüldü, teşekkürler Eric. Echo aboneliğini kaldırdım, artık kabin tamponlanmış okumayı silmeden önce PUBACK bekliyor. Ekran her 5 dakikada bir GET yapıyor. İlk çağrı reddedildi ve biraz paniğe kapıldım; meğer anahtarı test organizasyonunda kendi oturumumla oluşturmuşum, bu yüzden yoldaki tenant id anahtarla eşleşmiyormuş. Doğru organizasyonda yeni bir anahtar oluşturdum ve hemen çalıştı.
Sorted, thanks Eric. Ripped out the echo subscribe, the cabinet now waits for the PUBACK before dropping the buffered reading. The display does the GET every 5 min. The first call got refused and I panicked a bit, turned out I’d made the key under my own login on the test organisation, so the tenant id in the path didn’t match the key. Made a fresh one on the right organisation and it came straight up.
- 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.