jason_fw
@jasonwhite18 · Se unió el abril 2025
Embedded developer · logistics
- Temas
- 10
- Respuestas
- 48
- Puntos
- 0
Respuestas de foro creadas
Traducido del English por IA ·
Los webhooks necesitan una URL HTTPS a la que Hermetry pueda acceder desde fuera, así que detrás de NAT nunca llegarán. Necesitarías un túnel o un proxy inverso, y es probable que el departamento de informática de la universidad diga que no.
Webhooks need an HTTPS URL Hermetry can reach from outside, so behind NAT they’ll never land. You’d need a tunnel or a reverse proxy, and uni IT will probably say no.
Traducido del English por IA ·
Tuvimos un patio similar en un sitio logístico y acabamos quitando por completo la función de internet de la malla. La raíz sigue siendo un nodo de malla sencillo (sin modo station, así que el canal no importa) y se comunica por UART a 115200 con un ESP32 junto a ella. El ESP32 está conectado por Ethernet o al Wi-Fi de la planta, tiene la RAM necesaria para TLS y es lo único que Hermetry conoce.Haga del ESP32 un dispositivo gateway en Hermetry (marque This device is a gateway al crearlo) e informe de cada nodo de la malla como hijo en los topics del gateway. Use el id del nodo de la malla o una etiqueta como nombre del hijo y envíe un tipo para que todos caigan en el mismo perfil:
v1/gw/connect {"device": "yard-n07", "type": "yard-temp"}
v1/gw/telemetry {"yard-n07": {"values": {"temp_c": 41.2, "rssi": -71}},
"yard-n03": {"values": {"temp_c": 38.9, "rssi": -64}}}Cree primero un perfil llamado exactamente yard-temp; los hijos lo obtendrán automáticamente y sus reglas de alarma se aplicarán a ese perfil. Omita ts a menos que el ESP32 tenga NTP; la plataforma registrará entonces la hora de llegada.Si más adelante quiere enviar algo a un nodo, un comando para un hijo llega al ESP32 por v1/gw/rpc y el ESP32 lo pasa por UART a la raíz y de ahí a la malla. Referencia: Devices behind a gateway.
We had a similar yard on a logistics site and ended up taking the internet job away from the mesh entirely. The root stays a plain mesh node (no station mode, so channel doesn’t matter) and talks over UART at 115200 to an ESP32 next to it. The ESP32 is on Ethernet or the plant Wi-Fi, has the RAM for TLS, and is the only thing Hermetry knows about.
Make the ESP32 a gateway device in Hermetry (tick This device is a gateway when you create it) and report each mesh node as a child on the gateway topics. Use the mesh node id or a label as the child name and send a type so they all land on one profile:
v1/gw/connect {"device": "yard-n07", "type": "yard-temp"}
v1/gw/telemetry {"yard-n07": {"values": {"temp_c": 41.2, "rssi": -71}},
"yard-n03": {"values": {"temp_c": 38.9, "rssi": -64}}}Create a profile named exactly yard-temp first, then children get it automatically and your alarm rules go on that profile. Leave out ts unless the ESP32 has NTP, the platform will stamp arrival time.
If you later want to send something to a node, a command to a child comes down to the ESP32 on v1/gw/rpc, and the ESP32 passes it over UART to the root and into the mesh. Reference: Devices behind a gateway.
+1 on keeping it hardwired. On our lines the cloud only ever sees the aux contact count, nothing in Hermetry can release or trip anything.