Traducido del English por IA ·
Lector desde hace tiempo, primera publicación. Estamos reemplazando una configuración de broker casera por Hermetry para unos 300 monitores de subestaciones (basados en ESP32, con nuestro propio firmware). En la configuración anterior, cada unidad publicaba en grid/<site_id>/<unit_id>/telemetry y teníamos un archivo ACL grande para que cada unidad solo pudiera escribir en su propia rama. Ese archivo ACL era una fuente constante de problemas: cada nuevo sitio implicaba un cambio y un recargo del broker.Al leer la documentación de Hermetry veo v1/telemetry por todas partes y nada sobre topics por dispositivo, lo que significa que o es más sencillo de lo que creo o me falta una página. Antes de escribir el nuevo firmware: ¿necesitamos configurar 300 topics en algún lugar, o cada dispositivo simplemente publica en el mismo topic? Y si todos usan el mismo topic, ¿qué impide que la unidad 17 escriba datos como si fuera la unidad 18?También me gustaría conservar el id del sitio en algún lugar, ya que nuestros informes agrupan por él.
Long-time reader, first post. We’re replacing a home-grown broker setup with Hermetry for about 300 substation monitors (ESP32-based, our own firmware). In the old setup every unit published to grid/<site_id>/<unit_id>/telemetry and we kept a big ACL file so each unit could only write its own branch. That ACL file was a constant source of grief, every new site meant a change and a broker reload.
Reading the Hermetry docs I see v1/telemetry everywhere and nothing about per-device topics, which either means it’s simpler than I think or I’m missing a page. Before we write the new firmware: do we need to configure 300 topics somewhere, or does each device just publish to the same topic? And if they all use the same topic, what stops unit 17 from writing data as unit 18?
Would also like to keep the site id somewhere since our reports group by it.
Traducido del English por IA ·
Creo que para eso puedes configurar topics personalizados en el perfil del dispositivo. Vi una opción «Custom topics» en algún lugar cuando configuraba el mío.
I think you set custom topics in the device profile for that? I saw a «Custom topics» option somewhere when I was setting up mine.
Traducido del English por IA ·
Siguiendo con este tema, el próximo trimestre recibiremos 40 termostatos y me surge la misma pregunta.
Following this, we have 40 thermostats coming next quarter and I had the same question.
Traducido del English por IA ·
No hacen falta topics por dispositivo. Los 300 publican en el mismo v1/telemetry. Hermetry sabe quién habla por la credencial con la que se conectó el dispositivo, así que el token funciona en la práctica como la dirección. La unidad 17 no puede escribir como la 18 porque no tiene la credencial de la 18, y un dispositivo solo puede suscribirse a sus propios topics de downlink (v1/attributes/set, v1/rpc/req/+ y similares), así que tampoco ve nunca los mensajes de otro dispositivo. No hay ningún archivo ACL que mantener.Kevin no se equivoca al decir que existen los topics Custom, pero están pensados para firmware que no se puede cambiar: el perfil toma entonces cualquier topic fuera de v1/ como telemetría de ese dispositivo. Los límites ahí son profundidad de topic 8, longitud 128 y 50 topics distintos por dispositivo, y con «Prefix keys with the topic», grid/s12/temp se convierte en una clave como grid.s12.temp. Como estás escribiendo firmware nuevo, olvídate de todo eso.Para el id del sitio, lo haría un atributo del dispositivo en lugar de parte del topic. No cambia cada minuto, así que no pertenece a la telemetría.Referencia con la tabla completa de topics: MQTT topics and payload reference. Una cosa práctica de cuando migré mis propios equipos: dale a cada unidad su propia credencial. Dos dispositivos que comparten un token se desconectan constantemente entre sí.
No per-device topics needed. All 300 publish to the same v1/telemetry. Hermetry knows who’s talking from the credential the device logged in with, so the token is effectively the address. Unit 17 can’t write as unit 18 because it doesn’t have 18’s credential, and a device can only subscribe to its own downlink topics (v1/attributes/set, v1/rpc/req/+ and so on), so it never sees another device’s messages either. No ACL file to keep.
Kevin’s not wrong that Custom topics exist, but they’re for firmware you can’t change: the profile then takes any topic outside v1/ as telemetry of that device. Limits there are topic depth 8, length 128 and 50 distinct topics per device, and with «Prefix keys with the topic» grid/s12/temp becomes a key like grid.s12.temp. Since you’re writing new firmware, skip all of that.
For the site id I’d make it an attribute of the device instead of part of the topic. It doesn’t change every minute so it doesn’t belong in telemetry.
Reference with the full topic table: MQTT topics and payload reference. One practical thing from when I moved my own stuff: give every unit its own credential. Two devices sharing one token keep kicking each other off.
Traducido del English por IA ·
Eso es mucho menos trabajo de lo que había presupuestado. La unidad prototipo publica en v1/telemetry con su propio token, el id del sitio ahora es un atributo y nuestro script de informes lo lee de ahí. Eliminar el archivo ACL es lo mejor que le ha pasado a este proyecto.
That’s a lot less work than I’d budgeted. Prototype unit is publishing to v1/telemetry with its own token, site id is now an attribute and our report script reads it from there. Killing the ACL file is the best thing to happen to this project.
Traducido del English por IA ·
ah vale, entonces los topics personalizados son la salida de emergencia para el firmware antiguo. Los había confundido, gracias.
ah ok, so custom topics are the legacy-firmware escape hatch. I’d mixed those up, thanks.
- 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.