Traducido del English por IA ·
Integrador aquí. Un cliente tiene unos 300 controladores de bombas en campo, placas ESP32-S3 con nuestro propio firmware, todos por MQTT hacia Hermetry. Necesitamos cambiar algunos ajustes de forma remota, por sitio: el intervalo de reporte, una banda muerta en la lectura de presión y el servidor NTP (algunos sitios bloquean los pools públicos).Internamente hay dos enfoques sobre la mesa:
- un comando, por ejemplo
cfg.set, con los ajustes como parámetros JSON, respondido con ok/error - atributos compartidos que el dispositivo aplica
Lo que me importa: saber con certeza que una unidad ha aplicado un valor, y no perder cambios para las unidades que están desconectadas. Algunos sitios rurales se caen durante dos o tres días seguidos.El firmware ya lee una configuración JSON desde flash al arrancar, así que aplicar los valores no es lo difícil. Las unidades reportan cada 60 s y están detrás de una mezcla de routers LTE y Wi-Fi del sitio. ¿Para cuál de los dos enfoques está diseñado Hermetry y existe algo como una vista de deseado frente a reportado?
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?
Traducido del English por IA ·
Soy estudiante y tengo curiosidad: ¿por qué importaría? Un comando con los ajustes dentro me parece más sencillo.
Student here, curious: why would it matter? A command with the settings in it sounds simpler to me.
Traducido del English por IA ·
Los comandos enviados a un equipo fuera de línea solo esperan si los envías como persistentes, y en ese caso se descartan como máximo tras 7 días. Los atributos son estado, los comandos son acciones. Yo iría por los atributos.
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.
Traducido del English por IA ·
Lo hicimos con comandos en una flota más pequeña y era un caos cada vez que una unidad se perdía uno. Nadie podía saber qué unidades tenían qué intervalo.
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.
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.
- Debes estar registrado para responder a este debate.
Únete a la conversación
Inicia sesión para preguntar y responder, dar me gusta a las publicaciones útiles y marcar la respuesta que resolvió tu problema. Cada aportación suma puntos y niveles.