Raspberry pi, 1wire protocol and stability

After we installed a new boiler and a 10 port manifold to control our (waterborne) I needed to find out which heating loop from the manifold went where without spending weeks on my knees turning loops on and off manually, and then wandering around barefoot to find out which part of the floor was affected.

So I decided to put temperature sensors on every loop and a few other strategic points in the heating system.

So far I have 16 temperature sensors (DS18B20 sensors) controlled by 2 Raspberry pi Zero’s.


Why 2 Raspberry pi Zeros? – Well I ran into problems when I went above 10 sensors on the first raspberry Pi Zero, and decided to see if I could solve this part of the puzzle – as (for all I knew) there was a software or bandwidth limit stopping me at 10 sensors.

The DS18B20 uses a rather ingenious protocol called 1Wire, which enables a “multi drop” configuration of sensors originating from one set of wires. It can be run with 2 wires (parasitic power) or 3 wires (plus, round and data wires). I went for the last one – as using parasitic power sensed one step too far for me. So I used a breadboard attached to the Raspberry pi to make it easier to experiment.


I have had quite a few problems with this – even though the circuit is simple :


I’m using a bit more of a “star” configuration, as each sensor has approx 1m of cable connected to it.

I had a number of problems where the Raspberry Pi’s stopped working at “random” intervals – and lot of experiments with resistor values, swapping of power supplies and so on did not sort the problem out.

The solution to the problem (for me in this particular case) turned out to be the wireless connection to the LAN, as soon as I put a access point close to the Raspberry Pi;s – all stability issues of this type went away!

(More about the setup later)

Ruby in a Python (IOT) world

For someone who likes to write all their IOT code in Ruby, and has a lot of really useful libraries already, it’s getting harder when you experiment in IOT. It looks like Python has taken over almost everything.

And when you buy a shield (HAT/PHAT) for a raspberry Pi the drivers are almost always delivered in Python – especially from good suppliers like Adafruit and Pimoroni.

A good example is my “Scroll Phat HD” board for the raspberry Pi Zero W – it’s a really useful and good way of displaying small amounts of data – as you can scroll the text sideways very easily with their libraries with very little additional code, if you are using Python.


A Scroll Phat HD in all it’s glory.

This was until I found pycall – giving me a easy way to use Python libraries directly from Ruby.


and it works! Here is a short code example for using the Scroll PHAT HD python library

require 'pycall/import'
include PyCall::Import
pyimport 'scrollphathd', as: 'scroll'
width = 17

puts "loaded libraries ready to call scroll"
# First clear the display
streng = "This is a long string"
scroll.write_string(streng + " ", x=width, y=0)
teller = 0
while teller < (streng.length) do

It could not be simpler – and of course I run it all directly on the Raspberry PI. Now I can both have the best of both worlds.

reliably detecting the presence of IOS devices on your network

One of the challenges in having a good home automation system is how to detect the presence of people in the house. I’ve had many tries on doing this, among them:


– Movement sensors.

These work – but for a big house you need a lot of movement sensors if you are going to have good coverage, and they do not work in practice in our house.

– iBeacons

Generally need to track a Bluetooth device, and unless you can get every household member to carry a bluetooth device, this is unworkable. The best idea would be to use a ibeacon running one a mobile phone, but these would include installing software on every household members mobile phone, not workable in practice. The option is to detect each phones bluetooth interface, but this is again not applicable for IOS devices (more about that later) – or without reducing battery life when the phone is outside the range of your house. The range is also very short, and means that you would need (potentially) a lot of receivers.

– Check for the presence of mobile phones.

You can unfortunately not ping IOS devices after that have entered deep sleep, nor use ARP to detect them.


As our household is run on iPhones the last has been a problem – until I found a reference to how to wake up a IOS device from deep sleep by sending packets to port 5353 (mDNS port) to wake it up, and the use ARP to check for the presence on the network.

This is a excellent way of doing detection, as the only downside is that it will lead to more battery usage (as deep sleep reduces the devices power consumption drastically). And of course it was very clear that a way to do this had to exist – otherwise you would not get alerts/messages/emails wen the IOS device was in deep sleep.


How to do this in practice

After installing hping3 (I did this on a Raspberry Pi by using arp-get install hping3) i made a very short shell script


sudo hping3 -2 -c 10 -p 5353 -i u1 $1  2> /dev/null 1>/dev/null

arp -an | egrep -w $1


it works (though not perfectly) as it wakes up the IOS devices, and responds like this when it finds a device



? ( at b4:f0:ab:c5:62:dc [ether] on eth0


and for a device that is asleep 



? ( at <incomplete> on eth0





justBoom amplifier on a Raspberry Pi Zero – with music from iTunes on a Macintosh

We have a lot of speakers around the house, and have over the years had various solutions to let us centralise as much as possible of the storage into one place, and still be able to listen to all the music in different rooms and places.

We are predominantly a Apple household, so it is no surprise that we store all of our music in iTunes, and also use Apple Music quite a bit.

We now have a decent solution with the combination of

– iTunes running off one server

– Using a combination of AirPlay and Chromecast (courtesy of AirFoil) to send the music digitally around the house.

– And Airplay running through some Raspberry Pi zeros directly to attached speakers.

– Controlling it all from any of the Macs/iPads/iPhones

Our loudspeakers are among others:

– Quad Electrostatics running from a Analogue Amplifier (with a REL Subwoofer for extra bass) via a AppleTV as a DAC

– JBL monitors driven my JustBoom amplifier Phats on top of Raspberry Pi zeros

– Soundbars running off Apple TV’s

– Google Home speakers

– Headphones directly from IOS devices

– Speakers on our treadmill driven by a iPad

Airfoil and Airfoil satellite

Airfoil runs off a central server, with Airfoil satellite running on Mac’s and IOS devices, plus a open source version running off Raspberry Pi Zeros.

On the Mac it looks like this


This gives every Mac and IOS device the ability to control which devices are fed sound from the central server, and the volume.


The Raspberry pi zero has drivers from JustBoom installed, and a good controller (Alsamixer) controlling some of the basic parameters of the JustBoom amplifier through a rather neat terminal based interface (which means the RPI can run headless, and letting it be controlled from anywhere. Just by typing “alsamixer” on the command line of a terminal session.


The source for the Linux version of Airfoil satellite can be download directly from Rogue Amoebas website and run from the command line.

And the sound is not bad as long as it’s not driven too hard – and as long as a decent power supply is used, and connected directly to the PHAT board, ie. not using the 5V from the Usb interface.

The networked Max! thermostat works

As can be seen from the graph the new thermostat seems to work as it should. And the controlling software (FHEM) now runs off a Raspberry Pi.


The red line is the set point temperature

The violet (?) line is how many percent the radiator actuator is open.

The green line is the room temperature as measured by the thermostat.

Btw. this is from today (Sunday) – and it was down to freezing last night.

Another radiation counter for the Raspberry Pi

I’ve just built my first radiation counter for a Raspberry Pi – and intend to add this to the house monitoring system. At the moment it’s warming up – I will have further information soon.


But while I was waiting for it to warm up I found the following on another Radiation counter I may try to get hold of as well :


PiGI Module

PiGI V1.0 Prototype Board

The Raspberry Pi is a perfect platform to be a cheap but very versatile geiger counter. It can be connected to a TV/Monitor to display a nice graphical interface, it can play the nostalgic tak, tak, taktaktak sound via audio output and it can also serve as an autonomous geiger counter sensor node (even solar powered) collecting and sharing real-time and historic data. All you need is:

  • A Raspberry Pi
  • PiGI Module
  • Geiger-Müller Tube

The PiGI is designed & built as a simple open-source plug and play module for the Raspberry Pi to transform it into a cheap and hackable multi purpose geiger counter. It generates the necessary high voltage (up to 1000V) the GM tubes require to operate (typically 400-600V for beta/gamma GMTs).

Some pancake sensors (mostly used for alpha radiation) require an even higher voltage, theoretically the circuit should cover it. However, that’s untested, only a LND712 (new, see picture) and two old Phillips tubes (Frieseke&Hoepfner FHZ74/76) could be tested, due to limited prototyping resources.

For every impulse the geiger tube registers the PiGI pulls a GPIO Pin of the Pi to ground (falling edge detection). On the Pi runs just a little daemon called counterd which waits for an interrupt to register the count and notify the display/audio/data-storage/network handler. That’s why it can also easily be connected to any other embedded/micro controller system like:

  • Arduinos
  • ATMegas
  • PICs
  • Spark-Cores
  • Other embedded Linux ARM/MIPS systems with GPIO Inputs (Netus G20 etc.)

HOWTOs can/will be provided, drop a comment if you need one for connections/pull-up configuration.