I asked the same thing when we did our first site, so here’s what I learned.

It comes down to the concentrator chip (SX1302/SX1303 family in current gateways, SX1301/1308 in older ones). It isn’t one radio, it’s a baseband that demodulates 8 channels in parallel and on each channel every spreading factor at once. A sensor doesn’t have to “connect” either: it transmits, every gateway in range hears it, done. No association like Wi-Fi. So listening to hundreds of sensors is mostly listening to short bursts that rarely overlap.

The cheap indoor ones use the same chip family. What you give up is the outdoor stuff: enclosure, a good antenna up high, cellular backhaul, GPS.

For Hermetry, check three things before buying:

• A model for your band. Hermetry’s network server follows the gateway’s frequency plan, so the gateway and your sensors just need to be on the same one.
• Basics Station support (LNS). The old UDP packet forwarder isn’t supported.
• It lets you set tc.uri, upload tc.trust and set the token (tc.key). Hermetry doesn’t use CUPS, you configure it once by hand.

On the channels: Hermetry sends the gateway its radio configuration when it connects (on EU868 the 8 channels plus a 250 kHz LoRa channel and an FSK channel), so you don’t set channels yourself.

Keisha, for a warehouse: indoor gateway in the middle, mounted high, and check RSSI/SNR of the furthest sensors in the frames log before you trust coverage. Racking full of metal eats a lot.

Your colleague is half right. Buffering on licensed gateways covers the link going down: they keep readings locally and send them later with their original timestamps, so the history fills in. How much they keep depends on the model, worth asking about the specific one before relying on it. Licensed gateways and Hermetry Edge

But a buffer doesn’t help when the power is off. The gateway is off, and so are your meters’ RS-485 interfaces if they’re on the same supply. There’s nothing to read. So in your hut the UPS is what keeps data flowing, and the buffering is what covers LTE dropouts.

For the charger, I’d not build one. A DIN-rail DC UPS module (24 V or 12 V, takes the battery directly, does float charge and switchover, has a “mains fail” relay output) is about the price of the parts and the time you’d spend. If you do build, Rahul’s numbers are right: about 13.6-13.8 V float at 20 °C, current limited to around 0.1C (0.7 A for 7 Ah), and temperature compensation if the hut gets hot.

Wire the “mains fail” contact to a gateway input and send it as mains_ok. Then an alarm on mains_ok == 0 tells you about the outage itself, and you can make the offline alarm of the meters wait longer than the UPS runtime minus a margin. If you use the Remote sites ready solution, its UPS profile already has keys like ups_a_status and ups_a_charge you could fill.

Kevin A and Maria have both bits. I did nearly the same light controller for our office last year. Parse the JSON with ArduinoJson (it takes the buffer and length, so no null needed), pull the request id off the end of the topic, and answer on v1/rpc/res/ with that id. The “waiting for the device” stays because the board never gets an answer.

#include <ArduinoJson.h>
void callback(char* topic, byte* payload, unsigned int length) {
String t(topic);
String id = t.substring(t.lastIndexOf('/') + 1);   // "17"
StaticJsonDocument<256> doc;
if (deserializeJson(doc, payload, length)) return;
if (doc["method"] == "light.set") {
int level = doc["params"]["level"] | -1;          // -1 if missing
if (level >= 0 && level <= 100) {
analogWrite(D5, map(level, 0, 100, 0, 1023));
client.publish(("v1/rpc/res/" + id).c_str(), "{"ok":true}");
return;
}
}
client.publish(("v1/rpc/res/" + id).c_str(), "{"ok":false}");
}

ESP8266 analogWrite is 0-1023 by default, hence the map. And subscribe to v1/rpc/req/+ after every reconnect, not only in setup, or commands stop after the first Wi-Fi drop.

The topic list is on MQTT topics and payload reference.