ciaran55
@ciaranwalsh55 · Joined June 2025
Smart-city engineer · energy
- Topics
- 9
- Replies
- 68
- Points
- 0
Forum Replies Created
Class C is what we needed for the street light controllers. How long after the last uplink does a downlink still go out straight away?
Do this kind of work for a council, so a few things.
Whatever Hermetry City adds, I found no doc page for it, so I can’t tell you. Everything you described works with ordinary devices, profiles, alarms and a dashboard.
Power: the path lights already have power at the top of the post. Lots of posts have a photocell socket, and sensor nodes made for those sockets take their power from it. That covers light status and anything mounted on the post. Bins and planters: battery sensors, reading a few times a day.
Radio: LoRaWAN suits bins and planters. The network server uses your gateway’s frequency plan, so in the US get a 915 MHz gateway and sensors on the same plan, see Regions and frequency plans. Where the hotel’s Wi-Fi reaches, Wi-Fi sensors are fine too. Battery Wi-Fi sensors should wake, send over HTTPS and sleep, give them a profile with the Recent message online rule.
Then a threshold rule on battery and a Device offline rule on each profile, so you hear about a dead sensor before a guest complains about the bin.
That was it. They were all placed under the region, one level too high. Moved them and the markers went green.
Every site on my Sites board is Unknown with grey markers. The devices are online and sending, I can see them on the device list.
Commands to an offline unit only wait if you send them persistent, and that gives up after 7 days at most. Attributes are state, commands are actions. I’d go attributes.
+1 on sending a total. If you ever need consumption per hour, the history API and charts can work it out from the counter.
Try picocom instead of PuTTY? I always found PuTTY weird on serial.
Calm look was the first thing I switched on for our network screen. The duty operators said the old overview looked like a Christmas tree.
That explains it. Plotted obs_cond over a week: it shoots up exactly in the long flat-level periods. Gave k a process noise 1e-6 of q_in’s and switched to log(k). k now creeps slowly and only moves during pump cycles, q_in looks plausible against the rain gauge. Thanks Brian, and Rahul for the nudge.
Fair questions, they confused me as well when I started.
The input deliberately draws a few mA when it’s on. An input that only “measured voltage” with a very high impedance would see 15 V picked up on a long cable next to a motor lead and call it ON. By needing 3 mA, a weak induced voltage can’t hold it up. That’s what the type 1/3 classes in IEC 61131-2 define: voltage and current ranges for ON and OFF.
It also matters for 2-wire sensors. A 2-wire prox still leaks a little current when it’s off. If that leakage is above what the input accepts as OFF, the input never turns off. Type 3 inputs are designed to tolerate that leakage, type 1 inputs may not be.
Your wiring: “sinking” input means current flows into the input and out to 0 V, so it needs a device that sources +24 V into it. That’s a PNP sensor or a dry contact between +24 V and the input. An NPN sensor pulls the input towards 0 V, so on a sinking input it does nothing. Options: buy PNP versions of the prox sensors (easiest), or use an interposing relay.
The door contact and float switch are dry contacts: wire them from +24 V to the input. 3 mA through a reed contact is fine.
On the Hermetry side send the states as 0/1 numbers so they can be charted and alarmed on.
Look at your setup(): node2 never gets the pre/post transmission callbacks. So when node2 sends, nobody switches the MAX485 into transmit, the request never leaves the Arduino, and meter 2 never answers. Hence 0xE2.
node2.begin(2, Serial1);
node2.preTransmission(preTx);
node2.postTransmission(postTx);Calling node.begin(2, Serial1) before each read with one object works too, the callbacks stay set. I’d still keep two objects, it reads better.
Also add a short pause between the two reads, 20 to 50 ms. Some meters need a moment after answering before the bus is quiet again.
When you send to Hermetry, if the Mega (or the ESP next to it) is the gateway, put both meters in one message as two children:
v1/gw/telemetry
{"Meter 1": {"values": {"kw": 3.41, "kwh": 1203.4}},
"Meter 2": {"values": {"kw": 0.87, "kwh": 455.1}}}That was it. AP2112 module with 470 µF on the ESP, no reboots since Monday, and the keepalive_timeouts are gone from the Log tab. I had the divider already. Scoped the old 3.3 V rail out of curiosity: it dipped to 2.6 V on every connect.
Fit it. Same part, same package. In TI’s naming the letters after the part number are the package code, and the final R is only the packing. DW is the wide-body SOIC-16 (7.5 mm body), D is the narrow SOIC (on this part the 8-pin one). The trailing R means tape and reel, usually 2000 pieces, no R means tube. If you look at the orderable parts table at the very end of the datasheet (“Package option addendum”), both rows show the same package and pin count, only “Package qty” differs.
Temperature grade on TI parts is in the part number body or a Q1 suffix for automotive, not those letters.
Don’t swap to the D version though. The wide body is there for creepage across the isolation barrier, the narrow 8-pin one has a lower isolation rating and a different pinout anyway. Check the TVS diodes on A/B while you have it open, if the transceiver died they probably took a hit too.
Roughly, yes Aisha, and that’s where Kevin’s problem comes from.
LoRa sends a chirp, a tone that sweeps across the 125 kHz channel. A symbol is one chirp; where in the sweep it starts encodes the data. The spreading factor says how many bits one symbol carries: SF7 carries 7 bits and has 2^7 = 128 chips (steps) per sweep, SF12 carries 12 bits with 4096 chips. Each step up roughly doubles the time on air, and the receiver gets more time to pull a weak signal out of the noise, so range goes up.
In LoRaWAN those are data rates. EU868: DR5 is SF7, DR0 is SF12. Far devices need DR0 to DR2, and at those rates the most application payload you can send is 51 bytes. DR3 allows 115, DR4 and DR5 222. Your 58-byte frame physically can’t go out at the slow rates, so as soon as the tracker drops to SF10 or below, the stack refuses or the frame is lost, and nothing reaches the frames log. Your 11-byte sensor fits at DR0.
Two fixes. Pack the payload under 51 bytes: lat/lng as scaled int32 instead of floats or text, battery as one byte. And for trackers, turn ADR off on their profile, the network server adjusts on the last 20 uplinks and a moving device changes faster than that; set the data rate in firmware by distance instead. Table on Regions and frequency plans.
And turn on Values in the legend (min/max) so you can read the swing amplitude off it while you tune.