Traducido del English por IA ·
Probablemente sea una pregunta tonta, pero aquí va. Tenemos controladores ESP32 en armarios de calle (medición de energía, parte de un proyecto piloto) que publican en Hermetry en v1/telemetry, QoS 1, login con token; funciona bien, las lecturas aparecen en el panel cada minuto.
Dos cosas que quería añadir:
1. que cada armario también se suscriba a v1/telemetry, para poder confirmar que lo que envió llegó realmente (idea de un compañero, lo llama «comprobación de eco»)
2. que una pequeña unidad de pantalla e-ink en el depósito se suscriba a la telemetría del armario 3, para que el equipo pueda ver los kWh sin tener que iniciar sesión en nada
Ninguna de las dos funciona. La llamada subscribe devuelve true, PubSubClient no da ningún error, la conexión se mantiene, pero nunca llega nada. Probé v1/telemetry/# y #, lo mismo. ¿Un cliente no puede suscribirse a un tema en el que publica? ¿O me he equivocado con el tema?
client.subscribe("v1/telemetry", 1); // returns true
client.publish("v1/telemetry", "{"kwh":1203.4}");
// callback never firesLa pantalla es la misma placa ESP32 con su propio dispositivo y token en Hermetry, por si eso importa.
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.
Traducido del English por IA ·
Siguiendo el tema. ¿Asumí que MQTT era como un chat grupal donde todos ven todo?
Following. I assumed MQTT was like a group chat where everyone sees everything?
Traducido del English por IA ·
En un broker sencillo sí. Podrías ejecutar Mosquitto en una Pi en el depósito y hacer que los armarios publiquen también allí. Un poco desordenado, eso sí, dos destinos a los que enviar.
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.
Traducido del English por IA ·
Ese no es tu topic. Hermetry solo permite que un dispositivo se suscriba a sus propios topics de downlink: v1/attributes/set, v1/attributes/res/+, v1/rpc/req/+, v1/rpc/up/res/+ y v1/cert (además de los topics gw para gateways). Un dispositivo nunca recibe mensajes de otro dispositivo y nunca ve sus propios uplinks. La tabla está en MQTT topics and payload reference. A mí también me pasó en mi primer proyecto.
Para el punto 1 no necesitas ningún eco. El PUBACK es la confirmación: Hermetry solo lo envía cuando el mensaje está encolado de forma segura, y en el orden en que publicaste. Mantén la lectura en tu buffer hasta que llegue su PUBACK y bórrala entonces. Si la sesión se cae antes, vuelve a enviarla tras reconectar; los duplicados con la misma clave y marca de tiempo se almacenan una sola vez de todos modos.
Para el punto 2, la pantalla no debería escuchar MQTT en absoluto. Dale una clave de API y que lea el último valor por REST cada pocos minutos:
GET https://<your host>/tenant/<tenantId>/api/telemetry/latest?kind=iot_device&entityId=<cabinet3 id>&keys=kwh
Authorization: Bearer sk_live_...Haz que la clave sea solo de lectura (basta con el permiso de lectura de telemetría), pon la dirección pública del depósito en la lista de IP permitidas de la clave y ten en cuenta la caducidad: 90 días por defecto, un año como máximo, así que añade un recordatorio para la rotación. Después puedes eliminar también el dispositivo de la pantalla, no lo necesita.
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.
Traducido del English por IA ·
¿No sería el polling más pesado que simplemente suscribirse?
wouldn’t polling be heavier than just subscribing?
Traducido del English por IA ·
¿Una vez cada 5 minutos desde un solo equipo? No. Y las lecturas no cuentan para la cuota de mensajes, que corresponde a la telemetría y los atributos que envían los dispositivos.
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.
Traducido del English por IA ·
Resuelto, gracias Eric. Quité la suscripción echo; el armario ahora espera el PUBACK antes de descartar la lectura almacenada en búfer. La pantalla hace el GET cada 5 min. La primera llamada fue rechazada y me entró un poco de pánico, pero resultó que había creado la clave con mi propio login en la organización de prueba, así que el id de tenant en la ruta no coincidía con la clave. Creé una nueva en la organización correcta y funcionó enseguida.
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.
- Debes estar registrado para responder a este debate.
Únete a la conversación
Inicia sesión para preguntar y responder, dar me gusta a las publicaciones útiles y marcar la respuesta que resolvió tu problema. Cada aportación suma puntos y niveles.