Wednesday, 15 June 2016

The Physical Web. Yeah, thats a good idea.

In the last week I've discovered the Physical Web from google, and I'm sold on the idea. Apart from the "what's around here" geeky stuff, it's a great idea for sensible 'distant' digital signage. For example, $dayjob is at the Pawsey Supercomputing Centre, but we don't plaster our URL over the visitor area - what if guests could be gently prompted to the right URL by beacon?

Again tonight (while watching WASO play the Indiana Jones score) I noticed a set of three A3 posters explaining to users of another part of the conference centre how to connect to wifi and download <exhibit> app. This isn't even Scott Jensen's complaint of a 'dos prompt on the browser' - it's more a dig out the index card from the library, then go to the dos prompt...


Saturday, 21 May 2016

All around the water tank, waiting for the rain...

Having the luxury of mains water means that I don't really care in fanatical detail about the state of the dam water levels for Perth (except that "it's lower than it should really be"). However with our new place being entirely dependant on rainwater collection off the roof into storage tanks, I'd like to know the levels of the various tanks (and therefore the volume remaining).
So, what's available - simplest is knocking on the side of the tank and guessing from the sound how full. Not terribly reliable or hi-tech, but is cheap. Dipstick also cheap, but requires removing filter cover. Next up are external gauges - Our tank supplier stocks the Yaktek Levetator, but that's not really any good when I'm not on site. Hence, it's time to investigate the electronic options:

This thread on whirlpool mentions the Electrosense Aquagauge, but at $265 each plus telemetry thats not cheap. The Jaycar ultrasonic one may be OK, but as it doesn't have a serial / usb  output from the display, I'd need to hack up something to parse the RF (as others have done). So datasheet hunting time:

The MaxBotix series looks like it's pretty much ideal - 1mm resolution, 5m max range, weather resistant. Annoyingly I can't see it cheaper than the ~100 USD on the manufacturer site (sparkfun et al. only have the MB7360 not the MB7369), but at least there's a local supplier.  A slightly different model (MB7060) is being used by the flood network.

Next up is trying to work out how to connect them - My options are:

  • Wired - Etherten or possibly something as simple as serial-ethernet adaptor
  • Wireless - wemos / ESP8266 for wifi (power hungry?)
  • Wireless - rfm type TX/RX setup to basestation
  • lora - nice but possibly expensive as I'd need a gateway.
I suspect this particular blog entry will get updated as things progress..

Friday, 1 April 2016

Traffic Light status IoT device

Following on from an all-too-regular "Is the lasercutter working?" mail thread at our local hackerspace, I've decided to come up with a nice simple IoT 'traffic light' device.


Plan is to use KISS principles and have 3 big pushbuttons (Red, Amber, Green) that light up (and stay lit) so that the next person knows if machine needs maintenance/ misbehaving slightly / all good.


Using something like an ESP8266 module (hello Wemos D1), this could trivially publish the status to a broker, and then be acted on elsewhere - updating status on website etc

Next up, finding a local supplier of parts to start a prototype at the next Arduino-U night.

Saturday, 23 January 2016

Growatt inverter monitoring with Raspberry Pi

At home we have a small (2.5KW - 10*250w panels) PV system to try and offset our daytime electricity usage. This is connected to a 'Growatt' inverter that handily has both RS485 (wierd 2 pin plugs) and RS232 (9 pin D connector buried under a screwplate) outputs.

With the firmware on ours (installed Sept 2013) it supports modbus-rtu over serial 9600 8N1.

I had done some initial digging and experimentation (as announced on Whirlpool) but never really got sensible values out.When my guruplug (via a long USB to serial adaptor) finally died and I shelved the whole thing. With the completion of the structured wiring though I finally got round to reconnecting it and starting again.

Blue serial cable attached to structured wiring.
Small D9 Gender changer, + cisco console cable (all hail fleabay) gives a nice neat look on the outside, and in the garage I have another console cable plugged into the relevant patch outlet and a cheap usb-serial adaptor in a Raspberry Pi (which also has a GPS module connected, acting as a PPS NTP master)

Anyway, in the intervening time, someone had worked on my hacky scripts and wrapped the posting to PVoutput in an exec(curl) call -- first up I ripped that out and swapped for python requests.

I then went through the growatt modbus guide and made sure that it correctly calculated high and low byte values where these are split. The resulting script can be found on github,  and todays output can be seen on pvoutput. - a couple of charts are duplicated below.
Todays output v insolation prediction
As you can see, we had a couple of clouds going overhead today, so only generated 13KWh  vs 13.7 yesterday. Also the pvoutput fields are somewhat vague - 'Voltage' I've chosen to upload the array DC voltage rather than the grid AC volts (actually, I upload that and the grid frequency as extended data), and 'temperature' - I'd ideally like to have the panel temperatures, but upload the inverter temp so I can see if it's getting toasty. These can be seen on the 'all info' plot below

The observant of you will notice that the Etoday figure was slow to take off - this is because I didn't RTFM and discover that it's uploaded in watts, not kW...

Update 2016-02-08

If you pulled an early version of my code, please grab a new version - I realised the total lifetime generated (and any other 2*2word values) were off as I was doing thing[1]<<8+thing[2] and it should be thing[1]<<16+thing[2]. Ahem. 

The new version also just runs once in the background rather than being called from a cron entry every 5 mins, - it still publishes every 5 mins to pvoutput, but publishes all the messages (in json format) onto my message broker (MQTT) so I can draw a spiffy html5 canvas + websockets graph of whatever I fancy from 

solar/json {"Status": "Normal", "Etotal": 8705.3, "Tinverter": 46.1, "Pac1": 305.1, "ttotal": 32957749.5, "Vac1": 242.1, "PV1Curr": 1.1, "Etoday": 14.4, "Iac1": 1.3, "Pac": 305.1, "Ppv": 339.0, "Fac": 50.02, "PV1Watt": 339.0, "Vpv1": 303.8}

It also monitors the status, and if it changes to 'Fault' it'll look up the fault code and send an alert via pushover. 



Sunday, 6 September 2015

Publishing DHT22 data via MQTT with an ESP8266

Some time ago I picked up a couple of ESP-01 modules with the intention of using them as wireless temperature/humidity sensors coupled with a DHT22.

Initial investigations took place at the Perth Artifactory "Arduino-U" evenings - I managed to put on a nodemcu lua firmware and found a few (varying) dht22 libraries. however I couldn't ever manage to get it to consistently publish the information to my message broker - it'd do one or two and then lock up. I dug it out again recently and decided to have another go - especially as Pete Scargill seemed to be having success with them (running native C).

So trying to 'revert' to a newer espressif release turned out to be non-trivial - installing the relevant toolchain needs multiple bits. I gave up and noticed that there was a newer (0.9.6-dev_20150704) nodemcu release, so I gave that a try.

First discovery - There's native support for the dht sensors in the firmware, so to get the current values all you need is a
print(dht.read(4)) 
So, I trivially modified the example mqtt.client from the docs and uploaded it with luatool. I'd already set my wifi parameters by hand, so it was connecting to the network at power on automatically. Once I was happy that my 'pub.lua' was publishing OK, I added a trivial init.lua (also available on the gist)

Some points to note from that gist:

  • IP address of broker is hard coded. The nodemcu example uses a non standard port - be aware if you copy n paste
  • Although I have a last will, there's no status setting on successful connect. needs fixing.
  • I'd rather have temp / humidity as two separate topics, but I merged them into one json string to avoid having to worry about mqtt publishing concurrently (used to be fragile on the esp8266)
  • I publish every 5s (tmr.alarm) - 2s is the min recommended for the dht22
so I now see a pretty
sensors/ESP-10264640/json { "temp": 16.8, "humidity": 53.4 }
every 5 s ("mosquitto_sub -h broker -t '#' -v" makes for great sanity checking), which is great but not terribly pretty. Thankfully I have a websocket enabled mosquitto broker running, so I'd already dabbled at some html display. so I took jpmens' dial example and altered it to one of the other gauge styles. and lo...

Sunday, 14 June 2015

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.




Thursday, 10 July 2014

Fedora Catchup

The couple of packages I maintain in Fedora have been sitting stable for so long that I've not really had much to do with Fedora recently (that, and getting a mac laptop for $work), but I've just discovered https://badges.fedoraproject.org/ so it's now time to claim a few extras (oh, and push an update to PyEphem while I'm at it...)