Measuring empy space

If you've been following my recent posts on twitter, you'll be aware that I've finally got round to hooking up the MaxBotix rangefinders into our water tanks. So far I've done the main house tank and have sketches and buried duct ready to do the ones that water the garden.

Some more technical details here than I can fit in tweets:
* The sensors themselves sit through the roof of the tank. This involves drilling a 3/4" hole in the top of the tank and inserting the sensor from below, so you won't want to put it more than an arms reach from the access hole. The sensors I purchased have NPR thereads not BSP, so you may want to pick up matching nuts at the same time depending on local availability.
* I mounted some 6-way header pins on the sensor, and soldered the female end onto the cable so that it didn't twist as I tightened it up. All mounted in a 20mm conduit box on the tank.

Inside the shed, I'm just using a clone arduino with a wiznet ethernet shield (ebay/aliexpress) and a very basic sketch using the pulse width measurement from the sensor. As normal, it's available on GitHub for anyone interested. It pushes to an on-site MQTT broker (mosquitto) that's used to gather various sensor metrics and fed into home-assistant, where it also gets archived into InfluxDB for longer term plots

status/housetanksensor online

sensors/housetanks/depthbelowsensor 419

sensors/housetanks/litres 20762

I use the status for LWT messages, and the sensors has the raw air-gap measurement (mm below sensor - range is 300 -> 5000) as well as a calculated volume (see the arduino code for constants and calculation)

Importing into hass is as simple as

  - platform: mqtt

    name: House water tanks volume

    icon: mdi:water-pump

    availability_topic: status/housetanksensor

    unit_of_measurement: l

    state_topic: sensors/housetanks/litres

into the configuration.yaml

Next up, getting the irrigation system working...

The writing's on the wall

For the last couple of jobs I've had, having some sort of status display has proved itself really useful. Things like an overloaded nagios dashboard help to drill down to see what system issues you may have, but on large systems there'll always be some component that's not green (however your service should work around these transparently to the end user).  In a smaller team without 24/7 operations staff and shift handovers, how do you know things aren't on fire when you walk into the office? - I'll ignore the fact that you probably read your email over breakfast.

Concerto

At $job[-1] we put a spare monitor on the office wall and ran concerto on a PC feeding it. The backend at that time was php, and made assumptions such as assuming that short tags were OK - I hacked on a branch to make it more standard with the scientific linux systems we were using at the time. Given this was (is?) a student project out of the Rensselaer Institute ir's hardly suprising as young developers want LATEST SHINY. They then went through a second system effect, rewriting from scratch and completely missing the launch of the raspberry pi, which could have made a killer combination.

The problem is that many browser based clients need the overhead of X11 and all the various hacks to remove mouse cursors and make them more 'kiosky'

info-beamer

Fast forwards a few years and I have mini-magnus on my desk showing status and a set of 3 unused monitors on a wall looking to display some info. A quick bit of research flagged up info-beamer which has been used in production at the CCC events for several years. I've been playing with it for a couple of days now in the standalone pi and hosted variant.

hosted info-beamer

The install of this is very smoothly done. Small zip file download to populate an SD card with the raspberry pi bootloader files and a squashfs  and it self-installs the rest of the distribution from S3 and prompts you to register the node to your info-beamer account (in a similar way to a chromecast).

Florian has made some really nice touches to the setup - little things like setting cec_osd_name if your TV screen uses it, a custom kernel logo, and suppression of all but the player-related boot messages. In a public area, this makes it look a lot more professional than most of the other solutions which show the operating system before launching a player should they reboot. I've only played with a couple of the sample packages, but the install process is slick, if initially confusing terminology between packages, setups and playlists.

I'd love to see this integrated with indico - the meeting software used at CERN. Hint :-)

standalone info-beamer

The personal use player is distributed as a binary executable - I can understand the reasons for that, but it doesn't feel right. It doesn't (yet?) come as a debian package - It should be trivial for me to do myself according to the docs. When that's done, I'll install and run using systemd rather than the daemontools method (which is used by the various syncer scripts used in the hosted version). My concern is that the logging is presently noisy (good for debugging, bad for SD lifetime) 

I'm also planning on managing these R-Pi nodes using Ansible (Puppet is overkill for this as I want something that can bootstrap up a fresh SD card without needing extra daemons running) so I suspect there'll be future blogging on that. 

I've not yet investigated sending values directly to the info-beamer listening port (hoping I can do something with an MQTT subscriber) but pushing json files from various subsystems seems to work well. Obligatory screenshot:

Prototype display testing

Overall, I'm very impressed. Given I'd started learning lua for some nodemcu work I should be able to develop something functional. I've asked the work graphic designer to assist, so hopefully it won't end up "engineer style"

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..

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.

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...

Low-Level hardware hacking

In our 3 shiny new computer rooms (supercompute, IO, Tape - Each with slightly different environmental and cooling requirements), the architects have fitted a single temperature sensor on the back wall. Out of the airflow. This isn't giving us a terribly accurate picture of the supply air going into each rack, and so an alternative DIY method is underway.

A Raspberry Pi in each room (small, low enough power that it can be fed from PoE via a splitter) acts as the local 'head' and grabs the data to send it to a central message broker. From there, we can choose what to do and how to display it.

The sensor hardware consists of: A single DHT22 attached near to the Pi - As useful as these are on an arduino, on a R-Pi they are a bit harder due to the need for timing. The Adafruit interface for these grabs directly from memory address and seems well, a bit hacky. As suggested on IRC, a proper kernel module may be helpful. hint for someone else to complete :-)

The main sensor array is a set of DS18B20 sensors from fleabay (cheap if you're ordering 50 at a time) attached to the sheepwalk i2c interface 'RPI2'. These are then strung around to suit depending on location (ie, for our watercooled racks I'm going to affix the sensors directly to the flow/return lines on the watercooled racks to give us the delta-T across each set of door radiators (The BMS only gives flow/ret temp overall) which when tied to the internal temp sensors in the back of the racks should give us an idea of how well we're shifting the heat away from the machines. All this hardware comes in at less than 100 AUD per room - and some soldering time to make up the sensor chains to suit. To get an idea of the stratification (and therefore how do we position floor tiles relative to the overhead extraction vents) I'm going to put 15-20 sensors on a piece of plastic waste pipe to get a nice vertical profile - cue trip to bunnings (local DIY store) later this weekend.

Software

Hat-tip to the excellent MQTT people - nice n simple to use a python publisher script to send to a mosquitto broker on the lan. From there we can republish to Xively (useless as it doesn't respect timezones in the plotting so I can only see data I sent 8h ago...), Google spreadsheet (in a refactor of the original adafruit idea, and currently to a simple python curses console

Once we go into production and kit is running properly I plan to use the broker for all the machine status info and we'll dispatch accordingly for alarming.

More info and code will appear at https://github.com/ivecops/EnvMon

Radio Scrobbling via MQTT

Since I often listen to the most excellent Soma FM during the day (go support them, it's worth it!) I often wish that I could go and stash some similar tunes to listen to when I'm not online. To do this, I sell my soul to CBS and use last.fm to generate similar / listened to by others recommendations.

Sadly Rhythmnbox doesn't scrobble radio stations (even though the scrobble API has a flag for this
track.scrobble(chosenByUser=0) to indicate that its been chosen by a radio service), despite it updating my 'now listening' status on IM. So, in a geeky overkill solution I decided to save time in the long run and use a pub/sub system with MQTT. Oh, and use some python and twitter along the way...

The design is that I have an MQTT publisher that uses the tritter streaming api (via tweepy) and filters for all the somafm twitter streams that Rusty pushes with BigUrl. This gives me near realtime announcements of the start of the track being played (after some trivial split / strip manipulation)

ie

justcovers       Pat Boone - Enter Sandman  (2012-06-25 07:20:30)
digitalis        Zephyrs - Stand Round Hold Hands (Ulrich  (2012-06-25 07:20:37)
secretagentsoma  Eat Static - Love Truncheon  (2012-06-25 07:21:02)
beatblender      Kerry Chandler (Lazy Dog Ben W - Isis  (2012-06-25 07:21:29)
sonicuniverse    In The Country - Only The Birds Can See Us  (2012-06-25 07:21:29)

..which I can then publish to an internal MQTT broker using mosquitto python bindings.

In a separate process I have a subscriber that I can point to the broker and 'subscribe' to the radio station when I'm listening and it scrobbles that information to last.fm. 

All in, an interesting sunday evening work.