Partly right on the radio half. Contiki-NG does have IPv6 multicast for RPL networks: two engines, SMRF and MPL. You turn one on at build time in the nodes’ project-conf.h and in the border router’s:

/* every node and the border router */
#define UIP_MCAST6_CONF_ENGINE UIP_MCAST6_ENGINE_MPL
/* for SMRF instead you also need storing mode with multicast: */
/* #define UIP_MCAST6_CONF_ENGINE UIP_MCAST6_ENGINE_SMRF */
/* #define RPL_CONF_MOP RPL_MOP_STORING_MULTICAST */

Where he’s right is that the stock rpl-border-router does not forward multicast arriving from the outside network into the mesh. So the multicast has to originate on the border router itself: a small process on that box that, on a command from Hermetry, sends one MPL datagram to a group the nodes joined. It means reflashing all 30 nodes with multicast enabled, which on a cold store install is a site visit.

Honestly, for 30 nodes I’d skip multicast. Have the border router loop over the 30 addresses and send unicast with a retry. 30 small packets on a mesh is nothing, it finishes in seconds, and every node acks so you know who missed it. No reflash.

Then in Hermetry: add a command like sampling.set with a period_s parameter on the gateway’s profile, answer it from that process once all nodes acked, and put two buttons on the QA dashboard. Have the nodes report their current period as a client attribute so QA can see it took.

Had this exact situation with meter boards a contractor did. You can ask the running firmware: the partition API in ESP-IDF works fine from the Arduino core. Push one build to the boards you can reach (the ones from your own batch), or wait until the others are at the depot, that reports the table as client attributes once after connecting:

#include "esp_partition.h"

void reportPartitions() {
  String json = "{";
  esp_partition_iterator_t it =
      esp_partition_find(ESP_PARTITION_TYPE_ANY, ESP_PARTITION_SUBTYPE_ANY, NULL);
  bool first = true;
  while (it != NULL) {
    const esp_partition_t *p = esp_partition_get(it);
    if (!first) json += ",";
    json += ""part." + String(p->label) + "":"" +
            String(p->address, HEX) + "/" + String(p->size) + """;
    first = false;
    it = esp_partition_next(it);
  }
  esp_partition_iterator_release(it);
  json += "}";
  mqtt.publish("v1/attributes", json.c_str());
}

Then the Attributes tab, Client scope, shows part.app0, part.app1, part.otadata and so on per board. What you want to see is two app slots (ota_0 and ota_1, called app0/app1 in the Arduino tables) plus otadata, each at least as big as your image. If you see one app0 of 3 MB and no app1, that’s the “Huge APP” scheme, no OTA possible.

For the boards you can’t get a new build on, emily’s way works at the depot:

esptool.py --port /dev/ttyUSB0 read_flash 0x8000 0xc00 pt.bin
python gen_esp32part.py pt.bin

Boards with the wrong scheme need one USB reflash with a two-slot table. After that OTA works for good.

That’s a counterbalance valve (CBV = counterbalance valve). The check valve lets oil flow freely into the cylinder to lift. Coming down, oil has to push past a relief spring, and the dashed pilot line from the other side helps open it, so the load can’t run away or drop if a hose fails. The arrow across the spring means the setting is adjustable. On a lift table it’s the part that stops the platform falling, so it’s worth showing clearly.

On the drawing: the core symbol set has a check valve in the water network family, it’s in every organisation with the SCADA module. I’d place that, label it “CBV-1 counterbalance” with a text, and you’re honest about what it is. The palette search matches names and common other names, so search “check” rather than the part number.

If you want a proper hydraulic/process valve symbol, the Process library covers pumps and valves and ISA instruments. You can browse it before buying: symbols of a locked library show in the palette with a padlock and a still picture. Just see whether one fits before paying. Details: Symbols and industry packs.

Worth putting your pressure transmitter between the CBV and the cylinder on the drawing too, that’s where a dropping load would show first.

Kevin’s right that HC-12 is the easy way. With bare modules, the piece most people miss is that the Si446x chips don’t have a register map you just poke. You load a configuration blob that Silicon Labs’ WDS tool generates (radio_config.h) for your frequency, modulation and data rate, and send it to the chip at startup.

The library that works for me is RadioHead, driver RH_RF24, which supports Si4460/4461/4463. It ships with a set of ready configurations, so you don’t need WDS unless you want something unusual. Minimal sender:

#include <SPI.h>
#include <RH_RF24.h>
RH_RF24 rf24(10, 2, 9);   // CS, nIRQ, SDN
void setup() {
  Serial.begin(9600);
  if (!rf24.init()) Serial.println("init failed");
  rf24.setFrequency(433.92);
  rf24.setTxPower(0x4f);
}
void loop() {
  uint8_t msg[] = "lvl=182";
  rf24.send(msg, sizeof(msg));
  rf24.waitPacketSent();
  delay(60000);
}

Two traps. SDN is active high, so if you leave it floating the chip sits in shutdown and init fails. And these modules run at 3.3V: a 5V Pro Mini needs level shifting on SPI, or use the 3.3V/8 MHz Pro Mini, which is also better for battery life.

On the Pi end, read the packet and publish lvl as a key the same way you do for your other devices.

Megan’s right. The Personnel tracking page calls Hermetry Safe the dedicated worker-safety product but doesn’t say what it does, so I wouldn’t promise anything from it. The Personnel tracking ready solution is what I’d use, and room-level is exactly what it’s built for. I set it up for a pumping station last year.

The way zones work decides your hardware. Hermetry does not work out zones from positions or radio signals, and it has no geofence polygons. The tracker, or the gateway that hears it, decides which zone the person is in and sends the zone name in the key zone. So the zone logic lives in your hardware: a small BLE transmitter fixed in each room, the worker’s tracker reports the strongest one it hears, and the tracker or the gateway maps that to a zone name like switchgear-2.

The solution’s tracker profile then gives you the rest:

keys:   lat, lng, zone, event, battery, air_temp, light
event:  normal | motion | fall | motionless | sos | press_once
alarms: fall, motionless, sos (Critical), help_call,
        forbidden_zone (zone == the tracker's forbiddenZone attribute),
        battery_low, device_offline (15 min)

The event words must be exactly those, lower case. If your tracker sends something like FALL, translate it in the profile’s root flow. Each tracker gets a server attribute forbiddenZone with one room name, so set it to the switchgear room for everyone without a permit. Only one forbidden zone per tracker out of the box, a second needs an extra rule.

For the map, use the Map card in image mode with the building’s floor plan, positions in pixels. Full description: Personnel tracking.