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.