We run nearly this at a few small pump stations, so a couple of things from that.

The Pi in the middle is a good call because of your outages. Have it act as a gateway: one device in Hermetry marked “This device is a gateway”, and each room becomes a child device the first time the Pi reports it. Node-RED collects the room messages from Mosquitto, keeps them in a file or a small SQLite table while the internet is down, and then sends them on with their own timestamps:

topic v1/gw/telemetry
{"Room 4": [{"ts": 1793000000000, "values": {"temperature": 22.1, "humidity": 51, "door_open": 0}},
            {"ts": 1793000300000, "values": {"temperature": 22.0, "humidity": 51, "door_open": 1}}]}

Make sure the Pi has the right time (NTP after boot) before you put a ts on anything. A big backlog drains a bit slower because replays have their own rate limit on the profile, that’s normal.

Geyser switching can go through the same Pi. A command sent to a child device comes down to its gateway on v1/gw/rpc, so Node-RED subscribes to that and passes it on to the right room. Or make the geyser controller its own device that connects to Hermetry directly. For a geyser I’d go direct, fewer moving parts.

Gateway topics are described in Devices behind a gateway.

Not fixed, the ESP32 can route I2C to almost any pin through its GPIO matrix. The scanner working proves your wiring is fine.

What happens is that sht4.begin() and ina219.begin() with no arguments call Wire.begin() again inside the library, and a bare Wire.begin() puts the bus back on the default pins 21 and 22. That moves I2C away from your sensors and onto your RS-485 transceiver, which explains the second symptom too.

Give the libraries the bus you already started:

Wire.begin(32, 33);
Wire.setClock(100000);
if (!sht4.begin(&Wire)) Serial.println("SHT40 not found");
if (!ina219.begin(&Wire)) Serial.println("INA219 not found");

Most of the Adafruit libraries take a TwoWire*. If one does not, use Wire1 for the sensors and leave Wire alone.

On pin choice: 34 to 39 are input only, so never SDA or SCL. And stay off the strapping pins 0, 2, 12 and 15 if you can, a pull-up on 12 can stop the board from booting.

I’m on the data side at a water operator, so I see this argument from the people who want dashboards. Our sites run exactly this split and it’s held up for years.

The PLC does control: it scans I/O every few milliseconds whether the network is up or not, its inputs and outputs are made for 24 V field wiring and noisy cabinets, it has certified safety options, and the night-shift technician can open the ladder logic and see why a pump didn’t start. An ESP32 can do the logic, but you’d be building and certifying all of that yourself, then supporting it for 15 years.

Hermetry does monitoring and supervision: history, alarms, dashboards, operators sending a command. Even Hermetry’s own ready-made water solution keeps it that way, the pump stations’ automatic start and stop stays in the station’s controller and the cloud only switches manual mode and pumps on command. See Water site. If the internet drops, a cloud rule can’t stop a conveyor.

Where ESP32s do make sense: extra sensors the PLC doesn’t have, like vibration on a motor, temperatures in a cabinet, energy meters. Cheap, no risk, and they go straight to Hermetry.

Kevin, the cost question is the one to answer with numbers: one hour of downtime on a line versus the price of an S7-1200.