Von English mit KI übersetzt ·
Wahrscheinlich eine simple Frage, aber hier kommt sie. Wir haben ESP32-Controller in Straßenschränken (Energiemessung, Teil eines Pilotprojekts), die über v1/telemetry mit QoS 1 an Hermetry senden, Token-Anmeldung, läuft problemlos, die Messwerte erscheinen jede Minute im Dashboard.
Zwei Dinge wollte ich ergänzen:
1. Jeder Schrank soll auch v1/telemetry abonnieren, damit er bestätigen kann, dass das Gesendete tatsächlich angekommen ist (Idee eines Kollegen, er nannte es „Echo-Check“)
2. Ein kleines E-Paper-Display im Depot soll die Telemetrie von Schrank 3 abonnieren, damit die Jungs die kWh sehen können, ohne sich irgendwo anzumelden
Beides funktioniert nicht. Der subscribe-Aufruf gibt true zurück, kein Fehler von PubSubClient, die Verbindung bleibt bestehen, aber es kommt nie etwas an. Habe auch v1/telemetry/# und # probiert, gleiches Ergebnis. Darf ein Client kein Thema abonnieren, zu dem er auch selbst publiziert? Oder habe ich das Thema falsch angegeben?
client.subscribe("v1/telemetry", 1); // returns true
client.publish("v1/telemetry", "{"kwh":1203.4}");
// callback never firesDas Display ist dasselbe ESP32-Board mit eigenem Gerät und Token in Hermetry, falls das relevant ist.
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.
Von English mit KI übersetzt ·
Folge dem Thema. Ich bin davon ausgegangen, dass MQTT wie ein Gruppenchat ist, in dem alle alles sehen?
Following. I assumed MQTT was like a group chat where everyone sees everything?
Von English mit KI übersetzt ·
Auf einem einfachen Broker schon. Du könntest Mosquitto auf einem Pi im Depot laufen lassen und die Schaltschränke zusätzlich dorthin publizieren lassen. Etwas unübersichtlich allerdings, zwei Ziele zum Senden.
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.
Von English mit KI übersetzt ·
Das ist nicht Ihr Topic. Hermetry erlaubt einem Gerät nur das Abonnieren seiner eigenen Downlink-Topics: v1/attributes/set, v1/attributes/res/+, v1/rpc/req/+, v1/rpc/up/res/+ und v1/cert (dazu die gw-Topics für Gateways). Ein Gerät erhält nie Nachrichten eines anderen Geräts und sieht nie seine eigenen Uplinks. Die Tabelle steht unter MQTT topics and payload reference. Bei meinem ersten Projekt bin ich auch darüber gestolpert.
Für 1 brauchen Sie überhaupt kein Echo. Die PUBACK ist die Bestätigung: Hermetry sendet sie erst, wenn die Nachricht sicher in der Warteschlange liegt, und in der Reihenfolge, in der Sie veröffentlicht haben. Behalten Sie den Messwert in Ihrem Puffer, bis sein PUBACK eintrifft, und löschen Sie ihn dann. Stirbt die Session vorher, senden Sie ihn nach dem Reconnect erneut; Duplikate mit demselben Schlüssel und Zeitstempel werden ohnehin nur einmal gespeichert.
Für 2 sollte das Display gar nicht per MQTT lauschen. Geben Sie ihm einen API-Schlüssel und lassen Sie es den neuesten Wert alle paar Minuten per REST abrufen:
GET https://<your host>/tenant/<tenantId>/api/telemetry/latest?kind=iot_device&entityId=<cabinet3 id>&keys=kwh
Authorization: Bearer sk_live_...Machen Sie den Schlüssel nur lesend (Telemetrie-Lesezugriff reicht), tragen Sie die öffentliche Adresse des Depots in die IP-Allowlist des Schlüssels ein und beachten Sie das Ablaufdatum: standardmäßig 90 Tage, höchstens ein Jahr. Setzen Sie also eine Erinnerung für die Rotation. Danach können Sie auch das Gerät des Displays löschen, es braucht keins.
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.
Von English mit KI übersetzt ·
Wäre Polling nicht aufwendiger als einfach zu abonnieren?
wouldn’t polling be heavier than just subscribing?
Von English mit KI übersetzt ·
Einmal alle 5 Minuten von einem einzigen Gerät? Nein. Und Lesezugriffe zählen nicht zum Nachrichtenkontingent, das gilt nur für Telemetrie und Attribute, die die Geräte senden.
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.
Von English mit KI übersetzt ·
Erledigt, danke Eric. Ich habe das Echo-Abo entfernt, der Schaltschrank wartet jetzt auf das PUBACK, bevor er den gepufferten Messwert verwirft. Das Display führt alle 5 Minuten den GET aus. Der erste Aufruf wurde abgelehnt und ich bin kurz in Panik geraten, dann stellte sich heraus, dass ich den Schlüssel unter meinem eigenen Login in der Testorganisation erstellt hatte, sodass die Tenant-ID im Pfad nicht zum Schlüssel passte. Ich habe einen neuen Schlüssel in der richtigen Organisation erstellt, und danach lief alles sofort.
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.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Mitdiskutieren
Melde dich an, um Fragen zu stellen und zu beantworten, hilfreiche Beiträge mit „Gefällt mir“ zu markieren und die Antwort zu kennzeichnen, die dein Problem gelöst hat. Jeder Beitrag bringt Punkte und Stufen.