jason_fw
@jasonwhite18 · Nisan 2025 tarihinde katıldı
Embedded developer · logistics
- Konular
- 10
- Yanıtlar
- 48
- Puan
- 0
Oluşturulan forum yanıtları
Yapay zekâ tarafından English dilinden çevrildi ·
Webhook’ların Hermetry’nin dışarıdan erişebileceği bir HTTPS URL’sine ihtiyacı var; NAT arkasında olduklarında bu çağrılar hiçbir zaman ulaşmaz. Bir tünel ya da ters proxy gerekir ve üniversite BT birimi muhtemelen buna hayır diyecektir.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Bir lojistik sahasında benzer bir alanımız vardı ve internet işini tamamen mesh’ten aldık. Kök, düz bir mesh düğümü olarak kalır (station modu yok, bu yüzden kanal önemli değil) ve yanındaki bir ESP32 ile 115200 hızında UART üzerinden haberleşir. ESP32 Ethernet veya tesisin Wi-Fi’sinde çalışır, TLS için yeterli RAM’e sahiptir ve Hermetry’nin bildiği tek şeydir.ESP32’yi Hermetry’de bir gateway cihazı yapın (oluştururken This device is a gateway kutusunu işaretleyin) ve her mesh düğümünü gateway topic’lerinde bir child olarak bildirin. Child adı olarak mesh düğüm kimliğini veya bir etiketi kullanın ve hepsinin tek bir profile düşmesi için bir tip gönderin:
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}}}Önce tam olarak yard-temp adında bir profil oluşturun; böylece child’lar otomatik olarak bu profile dahil olur ve alarm kurallarınızı bu profile eklersiniz. ESP32’nin NTP’si yoksa ts alanını dahil etmeyin; platform geliş zamanını kendisi işaretler.Daha sonra bir düğüme bir şey göndermek isterseniz, child’a yönelik bir komut v1/gw/rpc üzerinden ESP32’ye iner ve ESP32 bunu UART üzerinden köke, oradan da mesh’e iletir. Referans: 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.