Traduit de English par IA ·
Sans doute une question bête, mais la voici. Nous avons des contrôleurs ESP32 dans des armoires de rue (mesure d’énergie, dans le cadre d’un projet pilote) qui publient vers Hermetry sur v1/telemetry, QoS 1, authentification par token ; ça fonctionne bien, les relevés apparaissent sur le tableau de bord chaque minute.
Deux choses que je voulais ajouter :
1. que chaque armoire s’abonne aussi à v1/telemetry, pour pouvoir confirmer que ce qu’elle a envoyé est bien arrivé (idée d’un collègue, il appelle ça un « contrôle d’écho »)
2. qu’une petite unité d’affichage e-ink au dépôt s’abonne à la télémétrie de l’armoire 3, pour que l’équipe puisse voir les kWh sans se connecter à quoi que ce soit
Aucune des deux ne fonctionne. L’appel subscribe renvoie true, PubSubClient ne signale aucune erreur, la connexion reste active, mais rien n’arrive jamais. J’ai essayé v1/telemetry/# et #, même résultat. Un client n’a-t-il pas le droit de s’abonner à un topic sur lequel il publie ? Ou ai-je mal écrit le topic ?
client.subscribe("v1/telemetry", 1); // returns true
client.publish("v1/telemetry", "{"kwh":1203.4}");
// callback never firesL’écran est la même carte ESP32, avec son propre appareil et son token dans Hermetry, si cela a de l’importance.
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.
Traduit de English par IA ·
Je suis le sujet. Je pensais que MQTT fonctionnait comme une discussion de groupe où chacun voit tout ?
Following. I assumed MQTT was like a group chat where everyone sees everything?
Traduit de English par IA ·
Sur un broker standard, si. Vous pourriez faire tourner Mosquitto sur un Pi dans le dépôt et faire publier les armoires là-bas aussi. Un peu brouillon quand même, deux destinations d’envoi.
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.
Traduit de English par IA ·
Ce n’est pas votre topic. Hermetry ne permet à un appareil de s’abonner qu’à ses propres topics de liaison descendante : v1/attributes/set, v1/attributes/res/+, v1/rpc/req/+, v1/rpc/up/res/+ et v1/cert (plus les topics gw pour les passerelles). Un appareil ne reçoit jamais les messages d’un autre appareil et ne voit jamais ses propres liaisons montantes. Le tableau se trouve dans MQTT topics and payload reference. Ça m’a aussi piégé sur mon premier projet.
Pour le point 1, vous n’avez pas du tout besoin d’écho. Le PUBACK est la confirmation : Hermetry ne l’envoie qu’une fois le message mis en file d’attente en toute sécurité, et dans l’ordre où vous avez publié. Gardez la mesure dans votre tampon jusqu’à l’arrivée de son PUBACK, puis supprimez-la. Si la session tombe avant, renvoyez-la après la reconnexion : les doublons avec la même clé et le même horodatage ne sont de toute façon stockés qu’une fois.
Pour le point 2, l’afficheur ne devrait pas écouter MQTT du tout. Donnez-lui une clé d’API et laissez-le lire la dernière valeur via REST toutes les quelques minutes :
GET https://<your host>/tenant/<tenantId>/api/telemetry/latest?kind=iot_device&entityId=<cabinet3 id>&keys=kwh
Authorization: Bearer sk_live_...Rendez la clé en lecture seule (la lecture de télémétrie suffit), ajoutez l’adresse publique du dépôt à la liste d’autorisation IP de la clé, et notez l’expiration : 90 jours par défaut, un an au maximum. Pensez donc à programmer un rappel pour la rotation. Vous pouvez ensuite supprimer aussi l’appareil de l’afficheur, il n’en a pas besoin.
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.
Traduit de English par IA ·
Le polling ne serait-il pas plus lourd que simplement s’abonner ?
wouldn’t polling be heavier than just subscribing?
Traduit de English par IA ·
Une fois toutes les 5 minutes depuis un seul boîtier ? Non. Et les lectures ne comptent pas dans le quota de messages, qui concerne uniquement la télémétrie et les attributs envoyés par les appareils.
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.
Traduit de English par IA ·
Problème réglé, merci Eric. J’ai supprimé l’abonnement echo, l’armoire attend maintenant le PUBACK avant d’effacer la mesure mise en mémoire tampon. L’afficheur effectue le GET toutes les 5 min. Le premier appel a été refusé et j’ai un peu paniqué, jusqu’à ce que je constate que j’avais créé la clé sous mon propre login dans l’organisation de test, si bien que l’identifiant de tenant dans le chemin ne correspondait pas à la clé. J’en ai créé une nouvelle dans la bonne organisation et tout a fonctionné immédiatement.
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.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.