Garden Irrigation, Pt 1

Some more background to my 'home assistant powered irrigation system' -- I'll write up a couple more articles as build progresses - I'm still waiting on some critical parts to arrive, like PVC pipe fittings and an Arduino Mega.

The Grand Plan.
The 2 main garden bed areas need to be automatically watered. The small 'hexagon' area contains 6 raised beds and a small central area. The main veggie patch (still being built. slow progress...) is around 20 beds. Later automation will include more smarts (hooking in my rainfall sensor, some buried gypsum sensors and soil temperature monitoring), but for now, the priority is to save on the 30-60 mins with a hosepipe in the evenings. Oh, and we're on tank (rainwater collection) water, so wastage is bad mmmkay.

The irrigation units themselves won't be 'smart' - All they need to do is send valve (relay) status, and respond to controls. I have an internal MQTT message broker, so a basic arduino + ethernet shield + 8 channel relay board does the small bed, and an arduino mega + ethernet (or an ethermega) + 3 8 channel relay shields the main veggie patch.

Sample arduino code is available on GitHub, (functions? who needs functions...) and yeah, it's not elegant. While it follows the syntax for the home assistant MQTT switch device, some of the defaults aren't the same, so I need to explictitly set them for now in the hass config. such as

switch:
  - platform: mqtt
    name: Hexagon bed 1
    icon: mdi:water
    availability_topic: status/hexIrrigation
    command_topic: control/hexIrrigation/valve1
    payload_on: "1"
    payload_off: "0"
    state_topic: status/hexIrrigation/valve1
    state_on: "On"
    state_off: "Off"

You can see here that I use status/hexIrrigation as LWT (so I know if the controllers on/offline) as well as the the relay state. I'm only using retain on the LWT, not the valves themselves. Power cycling the unit will (should!) reset back to all solenoids off, but I don't yet check and publish this, so hass may get confused if it loses comms. "Fixed in the next release" apparently :-)

I also want to integrate a flow sensor into each unit if possible (suspect I'm running out of digital IO on the small unit) to get an overall volume of water that's gone into the garden - fed, as normal into grafana.

I'll throw in another couple of postings (with pics) as the build progresses. but today I had an audience while working on the fence... (it will be fully netted to keep out the possums, pademelons and our hens)

PSU tinkering, Part 1

As previously blogged, I've got a couple of 12v 88.7A PSUs that I'm trying to control under arduino. Stage 1 complete - It powers up with a trivial bit of code

/* Arduino control for (ex) server PSU 
 * Andrew Elwell <andrew.elwell@gmail.com> August 2016
 * Released under BSD licence
 */

 /* Controls / Pins based on data sheet available at 
  *  https://belfuse.com/resources/PowerSolutions/SFP1050/bcd20031_ab_sfp1050-12bg.pdf
  *  
  *  A6/B4/C4/D4         +3.3 standby (power to arduino)
  *  A3/B1/B3/C1/C3/D3   Return 
  *  B5(SDA) / C5(SCL)   I2C
  *  B6                  Bring low for PS ON
  *  C6                  AC OK (if high)
  *  D6                  PWR OK (if high)
  *  
  */


#include <wire.h>

int ACOK  = 2;
int PSON  = 3;
int PWROK = 4;
int LED   = 13;

void setup() {
  Wire.begin();                // join i2c bus (address optional for master)
  pinMode(ACOK, INPUT);
  pinMode(PSON, OUTPUT);
  pinMode(PWROK, INPUT);
  pinMode(LED,  INPUT);
  
  digitalWrite(PSON,HIGH) ;   // Stay off until ready
}

void loop() {
  if (digitalRead(ACOK) == HIGH) {
    digitalWrite(PSON,LOW) ;
  } 
  if (digitalRead(PWROK) == HIGH) {
    digitalWrite(LED,HIGH) ;
  } 
}

The one gotcha that I needed to get it working was to also bring PS A0 low (I2C address) and suddenly green led and 12v out!

I've got the power

(It's getting, it's getting, it's getting kinda hectic)

So, another "I should really get round to that" project that's worked its way to the top of the desk is repurposing a skip-dived server PSU (or 4) to be more usable.

Exhibit A - One ex-sun 'SPASUNM-03G' PSU, which spits out a fairly chunky 12v at 86.7A

Since these were pulled from a bunch of servers, the output is a less than friendly set of three paired contacts for +12 and another set of three pairs or the ground. It won't start spitting out 12v when you plug a mains lead in as it needs the PS_ON connector bringing low. Power-one seem to gave been bought out by bel, and the datasheet is available here.

Rather than the (sometimes) crude way people have modified these and similar server PSUs over at RC Groups, I thought I'd hook up an arduino and be "smart"

So - Grand Plan (TM)

* Nice big illuminated push button for on/standby

* LCD display to show status (output / alarms / temp)

* No screaming 'fan-at-maximum' setting all the time

This shouldn't be that hard, right? Arduinos can do i2c and I have a bunch of 3.3v ones to hand, so I can drive this off the stby 3.3v (even that's at 3A on this thing)

TO THE SOLDERING IRON! ... to be continued

Satellite Tracking / New rotor controller

(it appears I'm about due for my annual blog post entry). Those of you who follow me on twitter will be aware that I've just acquired an old Kenpro 5400 (this is roughly the same as the Yaesu G5500) Azimuth / Elevation rotator, that I plan to use to track cubesats and play with for ham radio.

On opening the control unit (I wanted to see if there were any other primary taps on the transformer, as it's a 110v controller) it was evident it had been 'altered' in the past. To quote someone on #highaltitude "that wiring job is responsible for a thousand dead kittens",

hence a plan was developed to leave the existing controller as an emergency spare and build a fresh 1U rack version instead. The ideas (such as they are) are on a github gist that I'll keep updated with plans. The rough idea being to have a decent embedded board (probably a beaglebone black as a Raspberry Pi depends on an SD card) controlling the relays for output directly, and reading in the potentiometer values to calc position. Using a more powerful microprocessor than say a pic or atmega (arduino) means I can update TLE's automatically and offload much of the tracking directly to the controller - meaning any SDR receivers can concentrate on the signal alone.

I'm also going to house in a GPS module (most likely another one from upu) so that it doubles as a stratum 1 NTP server as well as having accurate position to calculate passes from.

PoE Network controlled signage

I may have a requirement for several 'remote controlled' illuminated signs. (where remote could be network driven) - These aren't Scrolling LED 'calls in queue' type ones, but more the warning 'Laser on', 'Mic Live', 'Conveyor Running' type ones.

Normally these things seem to be driven directly from some local switchgear or output, but what if you want to gather status centrally , or illuminate the sign depending on some remote sensor (be it a web tsunami alert or the boss' car being picked up on the ANPR at the gate)

Cue a quick hacky prototype: Take one nanode and use the digital outputs to drive a mosfet to switch some cheap LED strips from IKEA. So far so good, but that requires a 12v (since thats what the strips use) supply. The nanode can take that on the screw inputs if you add a heatsink to the reguator, but I'd rather get rid of the PSU alltogether: cue a cheapo 802.3af PoE splitter from TP-Link, and I have the whole lot driveable off one RJ45 cable.

Onwards to software, and it looks like bitlash / restuino look useful (esp if I get the whole lot working with DHCP too).

Anyway, with a range of lighting areas possible (thanks to addressable outputs on the nanode) per display, the option to have a nice facia with multiple 'zones' illuminated is possible. Now to find a nice case...

nanode built!

One successful evening of soldering, and lo, I have a working nanode. Started off nice n basic with the resistors, but overall a pretty simple pcb to assemble:

Plugged it in, and lo, blinky LED. Have since flashed with the EtherShield Drivers and its happily getting an IP address. now for some pachube / twitter / other integration...

Electronic components

Vigilant readers (ha, who am I kidding) will have noticed I've been starting on some ATmega hackery, but I'd like to prototype up without needing to but an arduino (clone) card for each one. So, off to the electronics equivalent Laminated Book Of Dreams (ie, farnell) to stock up on core components.

Discussions have come up with something like the following list, but what else should be added?

* LEDs - Was going to get both a selection single and a couple of RGB ones
* pile of resistors
* capacitors - elecrolytic and ceramic
* Diodes - signal. power, zener
* Voltage regulators
* 2n7000 mosfets
* generic transistors
* couple of atmega chips, crystals etc (core componets of arduinos)
* battery holders
* reset switches
* hookup wire
* breadboard (one decent and one small)

More specific bits I also want are
* rf12 boards
* opto isolator for telemetry input
* moar jeenodes :-)

EDF metering and 'Tele-Info'

Just discovered via some google-fu that we have a Sagem C1000 series meter in the house, which includes

* Interface de télé-information client permettant le raccordement à un système de gestion d'énergie

so, with a bit more googling I discovered that it's 1200 baud, 7 bits one stop. and lo - there's even an arduino shield already made for it!

--- update ---
Have discovered that there are many hacks around to parse this teleinfo - some of which need a licence fee (!!!) and do fancy things like export to bdpv.fr

Sample of the data stream is at http://www.planete-domotique.com/blog/2010/03/30/la-teleinformation-edf

Hardware Hackery

I've just purchased a nanode to be the main part of the energy monitoring in the new house. More details about it are at http://wiki.hackspace.org.uk/wiki/Project:Nanode - I plan to use the nanode as the head unit, perhaps with a somple lcd display, talking to slave nodes (jeenodes or emontx boards) which do the data logging.

more info and construction details when it arrives.

killed

I rarely have a need for bluetooth on my laptop, so mostly have it disabled. however when I was running Fedora 12. I had a nice option somewhere to leave bluetooth disabled and use the kill switch on my HP Compaq 8510p to purely turn off the wifi (advantage is that it also means the LED indicates wifi activity, not just always on)

However since migrating to Ubuntu Lucid 10.04 I can't reenable the bluetooth. All I have in the gnome widget is 'Your computer does not have any Bluetooth adaptors plugged in.' Grrr. Time to boot off a CD methinks and fix this.

In search of Feduntu

I've been a happy Ubuntu user for a while on my HP Compaq 8510p laptop, but a few things recently really started annoying me.

1) regular ubuntu system upgrades don't include openafs-modules for that kernel, which means I have to recompile and install them before I can access cern.ch AFS space.

2) it *really* doesn't work well with the ATI chipset in my laptop - full screen of a video hangs the machine with fglrx (not checked launchpad for bug no)

3) since the last update it takes 2 *seconds* to minimise / maximise / alt-tab with windows. c'mon, this is a dual core machine..... (see bug #351186

4) The fingerprint reader didn't work.

5) ... neither did userfriendly xinerama.

OK, so most of these problems are caused by the video driver (closed source fglrx) but since Fedora 11 came out I thought I'd compare and see what the opposition had (especially useful since I use RHEL clones at work - scientific linux 5 or 4)

Installer -- worked wonderfully *once I'd managed to get the iso onto a USB stick -- I was using unetbootin (on Jaunty) but I hadn't formatted the stick as fat32 -- didn't work with an ext3 formatted stick. The LVM selection was a bit fiddly (I have /boot(sda1) and linuxvg(sda2) and within the VG I have homelv,rootlv and afscachelv (was ext2 as I used XFS for / and /home)

F11 wanted me to migrate from xfs to ext4 for / -- OK not an issue, but its SElinux policy seems screwy wrt the /home

I get home directory does not exist, logging in with HOME=/
but then can immeadiatly cd to $HOME. harumph.

also the Fan runs constantly, so battery life is low, Especially since it suspends as soon as *one* of the batteries goes flat (see bug 220962)

in short, Fedora 11 fixes some of my issues. looks really nice, but just doesn't do what I want (*decent* laptop distro that lets me work for a long time). So I'm afraid I shall revert to Ubuntu over the weekend - it's still buggy for me, but in less critical ways (hopefully a fresh install of 9.04 will blow away any issues of the video driver rather than the upgrades.

Maybe again in Fedora 11.1 ?
Why not windows? well, I *like* using the CLI for most of my work, Putty + gvim + development languages are good but I'd need a virtual machine to test any linux stuff out on laptop. I don't actually have a need of any windows-only software, so why pay the licence.

[OK - tomtom home is the only thing, but thats another story...]

KITT updated?

OK Wishlist time.

I'd like some sort of navigation system for the car. Yes I could buy a tomtom or suchlike, but whats the geek factor in that. Nope, what I'd really like is some sorta carpc. Now that Atom based motherboards are cheap, and SSD flash (certainly in the small storage capacity I'd need) are cheap(ish) this is becoming a sort of sketch plan. I'd still need to get a nice touchscreen and interface knocked up, and have a connection to the car amp (manufacturer fitted nice system)

So in no particular order:
* Touchscreen fitted 'neatly' in car
-- it needs to have big 'bloke sized' buttons on the screen for doing tasks, so I don't have to look away - do you look down at the car radio?
-- some sort of scriptable interface: eg 'upload all tracks since the last upload'
* GPS receiver
-- Datalogging for openstreetmap
-- Navigation (doh!)
-- Geofencing to allow comms when parked at home
* Wifi and or GPRS/HSDPA connectivity
-- limited storage in the car, download $music from home store - treat it as a small player rather than a full rsync copy.
-- kismet anyone?
-- remote upload of tracks
-- download of traffic reports
* OBD connection for datalogging.
-- correlate engine conditions to position - if you're revving the engine is that because you're going up a twisty hill or because you're a numpty.
* Accelerometer (wiimote velcro'd to dashboard?)
-- Get relative acceleration of car, not just position

Oh, and it should be cheap :-)

Power Power Power

'Dear Santa'

Please can you get someone to injection mould a bog standard 4-way british multiplug trailing socket wotsit with a built-in IEC power inlet?

Thus by downrating to say 10A (hey, this is for geek things not space heating) we can have a simple 'travel adaptor' for all those clunky power brick things that you can simply pick up a single cable for $foreign_locality to fit. (or. more usefully, stick inside a rack to handle any transformers)

I'd do some photoshoppage (sorry, Gimpage) but my photo-fu is weak