Traduit de English par IA ·
Intégrateur ici. Un client a environ 300 contrôleurs de pompes sur le terrain, des cartes ESP32-S3 avec notre propre firmware, tous connectés en MQTT à Hermetry. Nous devons modifier quelques paramètres à distance, site par site : l’intervalle de rapport, une zone morte sur la lecture de pression et le serveur NTP (certains sites bloquent les pools publics).Deux approches sont sur la table en interne :
- une commande, par exemple
cfg.set, avec les paramètres en JSON, qui répond ok/erreur - des attributs partagés que l’appareil applique
Ce qui m’importe : savoir avec certitude qu’un appareil a appliqué une valeur, et ne pas perdre les changements pour les appareils hors ligne. Certains sites ruraux se déconnectent pendant deux ou trois jours d’affilée.Le firmware lit déjà une configuration JSON en mémoire flash au démarrage, donc appliquer les valeurs n’est pas le plus difficile. Les appareils envoient un rapport toutes les 60 s et se trouvent derrière un mélange de routeurs LTE et de Wi-Fi de site. Pour quelle approche Hermetry a-t-il été conçu, et existe-t-il une vue souhaité-vs-rapporté ?
Integrator here. A customer has about 300 pump controllers in the field, ESP32-S3 boards running our own firmware, all on MQTT to Hermetry. We need to change a few settings remotely, per site: the reporting interval, a deadband on the pressure reading, and the NTP server (some sites block the public pools).
Two approaches on the table internally:
- a command, say
cfg.set, with the settings as JSON params, answered with ok/error - shared attributes that the device applies
What I care about: knowing for certain that a given unit has applied a value, and not losing changes for units that are offline. Some rural sites drop off for two or three days at a time.
The firmware already reads a JSON config from flash at boot, so applying the values is not the hard part. The units report every 60 s and sit behind a mix of LTE routers and site Wi-Fi. Which way is Hermetry built for, and is there anything like a desired-vs-reported view?
Traduit de English par IA ·
Étudiant ici, je suis curieux : pourquoi cela aurait-il de l’importance ? Une commande contenant les paramètres me paraît plus simple.
Student here, curious: why would it matter? A command with the settings in it sounds simpler to me.
Traduit de English par IA ·
Les commandes envoyées à un appareil hors ligne ne sont mises en attente que si vous les envoyez en mode persistant, et elles abandonnent au bout de 7 jours maximum. Les attributs représentent un état, les commandes sont des actions. Je privilégierais les attributs.
Commands to an offline unit only wait if you send them persistent, and that gives up after 7 days at most. Attributes are state, commands are actions. I’d go attributes.
Traduit de English par IA ·
Nous l’avons fait avec des commandes sur un parc plus petit, et c’était un vrai désordre à chaque fois qu’un appareil en manquait une. Personne ne pouvait dire quels appareils avaient quel intervalle.
We did it with commands on a smaller fleet and it was a mess every time a unit missed one. Nobody could tell which units had which interval.
Traduit de English par IA ·
Utilisez les attributs partagés cfg.*, c’est exactement à cela qu’ils servent, et vous obtenez la vue valeur souhaitée / valeur remontée sans effort supplémentaire.Déclarez les clés dans l’onglet Configuration keys du profil (type, libellé, limites), puis définissez-les comme attributs partagés : cfg.telemetry.interval_s, cfg.pressure.deadband_bar, cfg.ntp.server. L’appareil reçoit les modifications sur v1/attributes/set, les applique et renvoie la valeur appliquée comme attribut client avec la même clé. Hermetry compare les deux et affiche pour chaque clé, dans l’onglet Attributes, les statuts In sync, Pending, Rejected ou Drifted.Côté appareil, après chaque connexion :
SUBSCRIBE v1/attributes/set
PUBLISH v1/attributes/req/1 {"sharedKeys": "cfg.*"}
# réponse sur v1/attributes/res/1 -> tout appliquer -> renvoyer :
PUBLISH v1/attributes {"cfg.telemetry.interval_s": 300, "cfg.pressure.deadband_bar": 0.05}La requête envoyée après la connexion couvre vos sites isolés : un appareil resté hors ligne pendant trois jours demande toutes les clés cfg.* à son retour et rattrape son retard. Si un appareil ne peut pas appliquer une valeur, il la signale dans cfg_rejected, par exemple {"cfg_rejected": {"cfg.ntp.server": "apply_failed"}}, et la ligne affiche Rejected avec la raison. Appliquez les messages de manière idempotente, un message peut arriver deux fois.Pour 300 appareils, écrivez les valeurs avec l’API (POST …/attributes/shared, jusqu’à 100 clés par appel) dans une boucle sur la liste des appareils. Les écrans Baseline et tâches en masse sont destinés aux appareils qui publient un manifeste de réglages (appareils sous licence) ; avec votre propre firmware, cfg.* est la voie à suivre. La page Attributes contient le tableau des statuts.
Use cfg.* shared attributes, that’s exactly what they’re for, and you get the desired-vs-reported view for free.
Declare the keys on the profile’s Configuration keys tab (type, label, limits), then set them as shared attributes: cfg.telemetry.interval_s, cfg.pressure.deadband_bar, cfg.ntp.server. The device gets changes on v1/attributes/set, applies them, and reports the applied value back as a client attribute with the same key. Hermetry compares the two and shows In sync, Pending, Rejected or Drifted per key on the Attributes tab.
Device side, after every connect:
SUBSCRIBE v1/attributes/set
PUBLISH v1/attributes/req/1 {"sharedKeys": "cfg.*"}
# answer on v1/attributes/res/1 -> apply everything -> report back:
PUBLISH v1/attributes {"cfg.telemetry.interval_s": 300, "cfg.pressure.deadband_bar": 0.05}The request after connect is what covers your rural sites: a unit that was offline for three days asks for all cfg.* keys when it comes back and catches up. If a unit can’t apply something, report it in cfg_rejected, e.g. {"cfg_rejected": {"cfg.ntp.server": "apply_failed"}}, and the row shows Rejected with the reason. Apply idempotently, a message can arrive twice.
For 300 units, write the values with the API (POST …/attributes/shared, up to 100 keys per call) in a loop over the device list. The baseline and bulk-job screens are for devices that publish a settings manifest (licensed devices), so with your own firmware cfg.* is the route. Attributes page has the status table.
- 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.