Re: LAN iof things for the homestead
Posted: Tue Apr 21, 2015 9:19 am
As promised, here is some of the more-stable code for this system. This is the arduino sketch part. Most of this is tested, but the counter stuff was only tested as part of another data aq project, I've not yet seen how it handles water-flow sensors, just geiger counters and the like (works well for those). I'll be testing that today I hope, nice weather for this just now. So consider this a beta. We are doing some interesting stuff I think I documented on an arduino thread elsewhere. We talk via the pi's UART port, with some fancy level converters/boosters such that the pi drives 0-5v levels out - HARD (2 amps!) to the "slaves" which all listen to that line. Coming back the other way, the arduino unos use a 2 transistor inverter and open collector with pullup to drive the pi's UART input line, which means I can put a bunch of arduinos out there as long as they follow our super-simple protocol - speak only when spoken to at your address (which is hard-coded in each slave, this one is ascii '1').
While we've used (invented!) other protocols, it's really doubtful this needs all the fancy space and cycle-eating features those had. We don't need even a full byte of addressing for example, ascii (human readable for debug) will do fine, and we don't need most of that here. We can retry on an error if we like, it doesn't have to be built in. When sampling essentially weather data at once/minute - we can afford to drop the odd sample, not that it's happening (probably would during a direct hit from lightning, though).
The arduino code is designed (and tested) to not lock up almost no matter what - missing or dead sensors for example, but I've not yet implemented a watchdog timer - we'll see if that's needed and put out another version of this if so.
Everything here is static, no possible issue with say, memory leaks. You learn that doing high-9's stuff like I used to do for a living, designing stuff where having to reset it meant a service call, and that didn't even have a power switch (nor does this).
Enjoy! The sketch folder also has the pinouts and command list in a text file.
I'll get the pi stuff up here too - but it's really changing a lot just now, and I'm a little at wits end to describe things like how all the configuration files for common stuff - NGINX, MySQL, and modules required for perl (most of this, it's my favorite glue language) and gnuplot should/can be documented, as it's important, along with some info on the toolsets I'm using that save me time/effort and don't come with the pi as is. For example, the pi comes with a bunch of toys and games - now gone.
It comes assuming it's all going on that fragile and slow SD card. Not here - we have a 64 gb USB3-extreme USB drive partitioned to hold the stuff that gets written a lot (the database for example), have customized those filesystems for less write amplification, and heck, use a ram drive for the things that really do get lots of traffic. It's a system, not just a jumble of parts...and I want it to live decades, not just for a demo. And the USB card doesn't have any magic junk for booting - you can just make a backup with a regular copy. No "imaging" required there. I'll call that a feature, perhaps a major one.
FWIW, on both pi models, faster SD and USB do matter (more on model 2 of course) - even though the pi is only USB2. Many USB2 sticks can't even saturate the USB2 speeds (even though the pi can't either - but most USB2 sticks can't even keep up with the pi, much less the spec), hence the use of USB3 (and the high end of that) for this. Ditto the SD card which is class 10/U3, even faster than the usual class 10 card - and it's a noticeable boost. I'd estimate this pi somewhere between an i3 and i5 intel NUC in performance (at a lot lower price!). This matters because due to the cheap - I can have a hot spare ready to go no matter what and how far into the future it might fail. This would be bucks-wasteful on something like a NUC.
While we've used (invented!) other protocols, it's really doubtful this needs all the fancy space and cycle-eating features those had. We don't need even a full byte of addressing for example, ascii (human readable for debug) will do fine, and we don't need most of that here. We can retry on an error if we like, it doesn't have to be built in. When sampling essentially weather data at once/minute - we can afford to drop the odd sample, not that it's happening (probably would during a direct hit from lightning, though).
The arduino code is designed (and tested) to not lock up almost no matter what - missing or dead sensors for example, but I've not yet implemented a watchdog timer - we'll see if that's needed and put out another version of this if so.
Everything here is static, no possible issue with say, memory leaks. You learn that doing high-9's stuff like I used to do for a living, designing stuff where having to reset it meant a service call, and that didn't even have a power switch (nor does this).
Enjoy! The sketch folder also has the pinouts and command list in a text file.
I'll get the pi stuff up here too - but it's really changing a lot just now, and I'm a little at wits end to describe things like how all the configuration files for common stuff - NGINX, MySQL, and modules required for perl (most of this, it's my favorite glue language) and gnuplot should/can be documented, as it's important, along with some info on the toolsets I'm using that save me time/effort and don't come with the pi as is. For example, the pi comes with a bunch of toys and games - now gone.
It comes assuming it's all going on that fragile and slow SD card. Not here - we have a 64 gb USB3-extreme USB drive partitioned to hold the stuff that gets written a lot (the database for example), have customized those filesystems for less write amplification, and heck, use a ram drive for the things that really do get lots of traffic. It's a system, not just a jumble of parts...and I want it to live decades, not just for a demo. And the USB card doesn't have any magic junk for booting - you can just make a backup with a regular copy. No "imaging" required there. I'll call that a feature, perhaps a major one.
FWIW, on both pi models, faster SD and USB do matter (more on model 2 of course) - even though the pi is only USB2. Many USB2 sticks can't even saturate the USB2 speeds (even though the pi can't either - but most USB2 sticks can't even keep up with the pi, much less the spec), hence the use of USB3 (and the high end of that) for this. Ditto the SD card which is class 10/U3, even faster than the usual class 10 card - and it's a noticeable boost. I'd estimate this pi somewhere between an i3 and i5 intel NUC in performance (at a lot lower price!). This matters because due to the cheap - I can have a hot spare ready to go no matter what and how far into the future it might fail. This would be bucks-wasteful on something like a NUC.