flubbed the version control again

  We got the data we needed for St Columba’s – more on that gradually – but one part of what we did was still a failure – we didn’t capture any readings above 50C on the radiators, even though we know very well, from the thermal imager if nothing else, that they were hotter than that.  Since we’ve seen that one before, as Iain said to me, this smells very much like a version control problem.   Still, since for us one of the most important skills to share is how to debug these things, I’m checking everything in order, “by the book”.

a href=”http://www.heathack.org/wp-content/uploads/2017/03/receiver-works.png”>

The first thing to do is check that the sensor location is actually sending readings above 50C, and the receiver is picking them up.  So the first step is turning on two sensor locations, one on something above 50C and one below, and then plugging the receiver direct into a laptop so we can watch the debug messages in a serial monitor.  It’s overkill for this, but I tend to use the one in the Arduino IDE.  We’re getting both sets of readings, so the Arduino considers these good readings.

The next step is booting up the Pi and using a web browser to check the demo page on the web server that it runs.  That can be found (when you’re on the same local network as the Pi) by using the address HOSTNAME.local.  Here, again, we can see temperatures above 50C.  And then we go to EmonCms, and see that none of the readings above 50C are there.

The culprit  is the pi – it’s filtering out temperatures above 50C as unlikely air temperatures in Scotland.  When we first set up, we hadn’t realised that pipe temperatures   were going to be quite so important.
From emoncms.js, here are the currently allowable ranges.   It should be 84 for temperature; that’s higher than the boiler feeds we encounter, and less than the 85 the DS18B20 uses as a code instead of a proper reading.

  // names and ranges for sensor types in numerical order from zero.
// min and max = 0 means allow all values
var sensorTypes = {
 0: { name: "test", min: 0, max: 0 },
 1: { name: "temperature", min: -20, max: 50 },
 2: { name: "humidity", min: 0, max: 100 },
 3: { name: "light", min: 0, max: 255 },
 4: { name: "movement", min: 0, max: 0 },
 5: { name: "pressure", min: 0, max: 0 },
 6: { name: "sound", min: 0, max: 0 },
 7: { name: "lowbatt", min: 0, max: 0 }

I had thought we’d incorporated that in Tim’s codebase, but no, I’ve been making the change by hand when I make new pi images to clone.  I just forgot this time.  So one of my near term goals is to get the code base in order, preferably with my little alpha projects up there too.  I’ve learned how to use git already, anyway.  That’ll let us stop playing Whac-a-Mole – great in the arcade, not so good in the rest of life.

Apart from that, I do know one thing that will make deployment easier.  At the moment, we’re using FTDI Jeenodes with adapters (their programmers, the “USB BUB”) for receivers, and the electrical connectivity for that is a bit fragile.  They’re very convenient for programming the Jeenodes, but not as reliable for uninterrupted, long-term service – which is fair enough, especially for amateur solderers!  I should get in a couple more of the Jeelinks.  They work as receivers, and have a robust case, even though they aren’t really useful for other purposes.  Alternatively, we could go half-way between robust and flexible, and use the Jeenode USB models.  Since they use a standard USB cable, they’ll stand up to more flexing and general abuse.  We could do with understanding the sequence of events that happens after the pi loses access to the receiver for a while.  I don’t think that’s fatal, but some things are taking quite a while at times (for instance, getting a local web page up even after the heathackhub service stops), and I think it’s to do with this.  We may be better off deploying with the more modern Pis we have rather than my usual Model B, because the electrics are reputed to be that much more stable.  However, I’m no expert, so these are just the things I’m thinking of looking into.

Leave a Reply

Your email address will not be published. Required fields are marked *