:: Re: [DNG] question on programming (…
Kezdőlap
Delete this message
Reply to this message
Szerző: dvalin
Dátum:  
Címzett: dng@lists.dyne.org
Tárgy: Re: [DNG] question on programming (maybe OT???)
On 22.03.24 06:25, o1bigtenor via Dng wrote:

> On Fri, Mar 22, 2024 at 2:44 AM Steve Litt < slitt@??? >


> wrote:


> > What does each temperature sensor output? A voltage? A current? Some


> > sort of packet? Something else?


> >


>


> There are a few different sensors that may be used - - - would depend


> upon location. (Outdoor  sensors  need to be usable to at least -40C


> and some humidity sensors need to be able to handle physical


> condensation levels.)


If the sensors output voltage or current, then some arduinos here and

there could collect the data on their ADC input channels. Though 10 bit,

only about 8 bits are really good, due to offsets, nonlinearities,

quantisation, etc. The MSP430 has a 12bit(?) ADC, but I've no experience

programming it.

> >


> > How many buildings are these congregated in? Are any outside? How close


> > is each to the building housing your main computer?


> >


>


> More than a few. Yes, Area covered is some few acres and distance to


> main computer is in the order of circa 100 m.


You can run RS485 a km over twisted pair, e.g. cat5 cable. Full duplex

over two pairs. At 100m, data rate nudging 1 Mbps ought to be

achievable, enough to track temperature variation, I figure.

My recollection is that RS485 tranceivers tolerate ±7V DC offset between

cable ends, avoiding need to run earth in the cable.

It is possible to run analogue levels over 100 m distance, using 20 mA

current loop converters. Then all the ADC is centralised, i.e. no need

for little arduinos across the acres. But the latter could take other

inputs like door switches - maybe it's important to know if a door has

blown open, and the petunias will freeze in a couple of hours. (Better

than a temp warning after the event.) And multiplexing many sensors into

a digital stream on one cable pair saves a lot of cable installation.

...

> >


> > >So for data - - - do I use web based systems (Django/Python and their


> > >attendant overheads) or something like WxWidgets (similar overheads)


> > >or a SCADA kind of system (Proview) or might it be possible to pull


> > >the data into something like storage (Postgresql database) and then


> > >use something simple like a text based document (I'm not that into


> > >'purdy pitchers') to display values with whatever control logic


> > >running on different ucontrollers. (I used ledger-cli and like the


> > >elegance of that system)?


> >


> > Why not a log file? You can then use very simple Python programs to


> > create reports based on the log file.


> >


>


> That's the third option that I listed.


There is a classic app for presenting lots of distributed real-time data;

SNMP. On linux, that's "net-snmp". Each sensor can be accessed as a

point, or the snmp-walk command walks the tree to scan the lot. As a

tree, there can be a branch for each barn/greenhouse/paddock or

water/temp/humidity/doors if you don't care where they are. ;-)

It's about two decades since I last used it, but ISTR that snmptrap

allows sending of alarms on input excursions beyond limits. (But I'm

nudging 70, so the wetware RAM isn't quite 100% on details now.)

It supports authentication, so different users may be granted different

access rights.

It's easy to install a local instance on a linux box, to play with before

going whole hog. A quick: $ apt-cache search snmp | more

shows more than you probably want. A walk over the entire MIB

(Management Information Base) was pretty brief. Here's the first bit:

$ snmpwalk -v 2c -c public -m ALL localhost .1

SNMPv2-MIB::sysDescr.0 = STRING: Linux dvalin 2.4.13-686 #2 Sun Oct 28 11:57:35 EST 2001 i686

SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-TC::linux

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (680720) 1:53:27.20

SNMPv2-MIB::sysContact.0 = STRING: erik@???

SNMPv2-MIB::sysName.0 = STRING: dvalin

SNMPv2-MIB::sysLocation.0 = STRING: Earth

SNMPv2-MIB::sysORLastChange.0 = Timeticks: (33) 0:00:00.33

The MIB is defined in ASN.1 notation, which you put through the supplied

MIB compiler. Pushing data into the MIB from distributed sensor data

collection clusters looks to be partly done for arduino:

https://www.arduino.cc/reference/en/libraries/snmp/

A bit of googling might reveal more yet.

I have a list of SNMP books, but that file is 22 years old, so maybe of

limited usefulness now.

> >


> > >


> > >Suggestions - - - (yes I know I'm nuts) ideas - - - etc welcome - - -


> > >please?


> >


> > Not nuts at all. This is the first time I've heard of an IoT system


> > that solves an actual problem.


> >


> >


> Commercial (read industrial) control systems are yammering about how


> they're IoT - - - except they always have been - - - grin!


That's "Introduction of Trouble", isn't it? How good is the

authentication? Does it involve more than one protocol and a port or

two? Too many doors makes things harder to defend. (And who wants to

turn up to work to find all the cabbages frozen solid?)

I've designed a little three channel LED lamp dimmer, networked over

RS485, for my off-grid solar powered rural build. Collection of

temperature data was to be next cab off the rank. Because the uC has

only 32 registers, 2kB of codespace, and 128 bytes of RAM, the protocol is

pretty basic DIY. (Why overdo the hardware, when not needed?) I'll have to

finish the networking part of the firmware, but am sidetracked on

whipping up a power diverter for the Hot Water Service to only use

surplus solar power, detectable by the battery inverters shifting the

(off-grid) supply frequency up toward 52.5 Hz to throttle the solar

inverters. Burst fire of whole power cycles, switched on zero crossings,

ought to minimise interference. (You can see why the 3/4 finished

project had to be sidelined, with fun like that to fiddle with.)

The 7 kW EV charger has an automatic mode to also use only surplus solar

power, but it won't engage. Not impressive on a commercial unit of

non-trivial cost. (The BEV runs on 100% fossil-free photons. Crikey,

what a feeling! )

Erik