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.
Following. I assumed MQTT was like a group chat where everyone sees everything?
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.
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.
wouldn’t polling be heavier than just subscribing?
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.
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.
- You must be logged in to reply to this topic.
Join the conversation
Sign in to ask and answer, like helpful posts and mark the reply that solved your problem. Every contribution earns points and levels.