Traducido del English por IA ·
Use los atributos compartidos cfg.*, que es exactamente para lo que sirven, y obtiene la vista deseado frente a reportado sin esfuerzo adicional.Declare las claves en la pestaña Configuration keys del perfil (tipo, etiqueta, límites) y luego establézcalas como atributos compartidos: cfg.telemetry.interval_s, cfg.pressure.deadband_bar, cfg.ntp.server. El dispositivo recibe los cambios en v1/attributes/set, los aplica y devuelve el valor aplicado como atributo de cliente con la misma clave. Hermetry compara ambos valores y muestra por clave, en la pestaña Attributes, los estados In sync, Pending, Rejected o Drifted.Lado del dispositivo, después de cada conexión:
SUBSCRIBE v1/attributes/set
PUBLISH v1/attributes/req/1 {"sharedKeys": "cfg.*"}
# respuesta en v1/attributes/res/1 -> aplicar todo -> reportar:
PUBLISH v1/attributes {"cfg.telemetry.interval_s": 300, "cfg.pressure.deadband_bar": 0.05}La solicitud tras la conexión es lo que cubre sus sitios rurales: una unidad que estuvo desconectada tres días pide todas las claves cfg.* al volver y se pone al día. Si una unidad no puede aplicar algo, debe reportarlo en cfg_rejected, por ejemplo {"cfg_rejected": {"cfg.ntp.server": "apply_failed"}}, y la fila muestra Rejected con el motivo. Aplique los cambios de forma idempotente, ya que un mensaje puede llegar dos veces.Para 300 unidades, escriba los valores con la API (POST …/attributes/shared, hasta 100 claves por llamada) en un bucle sobre la lista de dispositivos. Las pantallas de línea base y de trabajos masivos son para dispositivos que publican un manifiesto de ajustes (dispositivos con licencia); con su propio firmware, cfg.* es la vía adecuada. La página Attributes contiene la tabla de estados.
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.