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.

Another Adafruit.io problem

As of Friday I’ve seen a number of problems in posting data to adafruit.io – and it’s taken a lot of time to debug the problem. In the end it looks like I was sending too much data too fast, adding a delay of 0.2 seconds between postings like this :

data = $aio.feeds(navn).data.send_data(component[1]) # Had a real problem with value: in helper method send_data
                                                                                        # data = aio.feeds(“Test”).data.send_data({value: 5}) goes wrong as per documentation
sleep(0.2) # sleep between updates – otherwise things seems to go wrong
puts “data sent to adafruit”


Adafruit IO changes their REST API

I’ve ben having some weird problems with my software doing calls to the Adafruit API. I’ve spent a fair amount of time trying to find a problem in my own code until I found this in Adafruit’s changeling ;


Adafruit IO Changelog: “Apr 19, 2016 • @jwcooper REST API v2 Deployment on April 21st On Thursday, April 21st we will be deploying Version 2 of our API. This version is quite different from our existing API V1.

IMPORTANT: Your code or sketches will need to be updated if you are using the REST API.

From now until Thursday, you will want to update your code or sketches to change ‘/api/…’ to ‘/api/v1/’ so that you continue using v1 of the API until you are ready to upgrade to the latest version.



I’m using Adafruit’s Ruby gem – but it looks like it’s just a wrapper around the REST Api, so that would explain my problems.

Parsing date and time using Chronic – part 2

This has proven to be  bit more challenging than initially presumed.

To recap – I’m setting up a heating schedule for several zones in our house – all I need to do is to send out setpoint temperatures to the wireless thermostats in each zone at the correct time.

So I decided to define everything in a JSON file, and parse time and dates with Chronic to control everything. So far it all sounds easy, and I came up with something like this :


But I wanted to set all timings using 24 hour time, so in the end I had this :


It looks a bit weird – as the “today” tag should not be needed IMHO, but some of the times (i.e. those that would have been in the “past” – such as “00:01” ended up being interpreted by Chronic as 7 days into the future….

So that explains the “today” tag.

Parsing date and time in chronic

As part of putting together the home automation for our house we need to do a lot of schedules – and at the moment the main focus is for the heating. This involves things like :


and the sensible choice to parse these dates seems to be chronic.

But I hit a small problem – today is Saturday january 2nd of 2016, and things do not work out of the box :


in other words if I tell chronic to parse “Saturday 12:00” I was expecting the returned detesting to be ‘2016-01-02 12:00’ – but instead it gives me next Saturday?

Hm! I need to look into this.

Internet button installment 2

The first cut of code for the Internet button is now up and running. It’s really so far concentrated around 2 buttons and 3 response states :

Button 1 sends out a “button1” event to the Particle Cloud.

Button 3 sends out a “button3” event to the Particle Cloud.

And 3 response states.

State 0 is the “unknown state” set before the Internet button has been sent any state information. Also tied to the function “waiting_for_response” in the Particle Cloud.

 IMG 2320

State 1 – sets all Led’s to red. Tied to function “onccupied” in the buttons firmware – tied to the same name in the Particle Cloud.

IMG 2321

State 2 – sets all Led’s to green. Tied to function “occupied” in the buttons firmware – tied to the same name in the Particle Cloud.

IMG 2322

The Particle cloud advertises the 3 states tied to the specific Internet Button in our house.


This is the first step in understanding how to use the Internet button – and the first cut of the firmware. The buttons can now publish events to the Particle Cloud (which in turn can attache these events to other functions) and set states by calling functions in the buttons firmware from other software. (more about this later).

The good thing about the Internet Button is that it’s completely standalone, with the exception of a power source, currently seen as a USB plug in the pictures.