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.