jason_fw
@jasonwhite18 · Mitglied seit April 2025
Embedded developer · logistics
- Themen
- 10
- Antworten
- 48
- Punkte
- 0
Erstellte Forenantworten
Von English mit KI übersetzt ·
Webhooks benötigen eine HTTPS-URL, die Hermetry von außen erreichen kann. Hinter NAT kommen sie daher nie an. Sie bräuchten einen Tunnel oder einen Reverse Proxy, und die IT der Uni wird wahrscheinlich Nein sagen.
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.
Von English mit KI übersetzt ·
Wir hatten ein ähnliches Gelände auf einem Logistikstandort und haben die Internetanbindung ganz aus dem Mesh herausgenommen. Der Root bleibt ein einfacher Mesh-Knoten (kein Station-Modus, daher spielt der Kanal keine Rolle) und kommuniziert über UART mit 115200 Baud mit einem ESP32 daneben. Der ESP32 hängt an Ethernet oder am WLAN der Anlage, hat genug RAM für TLS und ist das einzige Gerät, das Hermetry kennt.Legen Sie den ESP32 in Hermetry als Gateway-Gerät an (setzen Sie beim Erstellen den Haken bei This device is a gateway) und melden Sie jeden Mesh-Knoten als Child über die Gateway-Topics. Verwenden Sie die Mesh-Knoten-ID oder ein Label als Child-Namen und senden Sie einen Typ, damit alle im selben Profil landen:
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}}}Erstellen Sie zuerst ein Profil mit exakt dem Namen yard-temp. Dann erhalten die Children es automatisch, und Ihre Alarmregeln werden diesem Profil zugeordnet. Lassen Sie ts weg, sofern der ESP32 kein NTP hat; die Plattform vergibt dann den Empfangszeitpunkt.Wenn Sie später einen Befehl an einen Knoten senden möchten, gelangt er für ein Child über v1/gw/rpc zum ESP32, und der ESP32 leitet ihn per UART an den Root und weiter ins Mesh. Referenz: 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.