Connected Little Boxes servo pulse

/

I’ve added a new feature to the Connected Little Boxes software. You can now ask a servo to move to a certain position, stay their for a specified length of time and then move back to its previous position. This makes it much easier to create devices where you want to open a lock or wave a flag.

{"process":"servo","command":"pulseservopos","value":1,"pulselen":2.5}

The command above will move the servo to the end of its travel (the value 1) and hold it there for 2.5 seconds before returning it to its original position.

Web Page Temperature Viewer

/
temp.png

Yesterday I created a command which will let a Connected Little Box send temperature values out of its serial port. Today I made a web page that will receive this data and display the values in large friendly letters.

This works by using the same browser serial libraries as I’m using for the the ESP firmware uploader. It works well. It means that it is now very easy to display serial data on a device by simply visiting a web page. You can find the temperature viewer page here.

Connected Little Boxes can now produce JSON data

/

I’ve added a new feature to Connected Little Boxes. You can now ask a box to send out sensor values as a JSON encoded string. This means that you can hang a box off a serial port and get data from it in a format that is very easy to use. It’s done using the console process and the command is called reportjson:

{"process":"console","command":"reportjson","text":"starting","sensor":"bme280","trigger":"tempsec","attr":"temp"}

The above command tells the Connected Little Box to send out the temperature value from the BME280 sensor every se4cond. The box will then produce a sequence of messages that look like this:

{"temp":"24.0"}

Paying off technical debt..

/

I had plans for today’s Hardware Meetup. I wanted to show off my ESP uploader. However, fate had other ideas. I’ve spent the day paying off technical debt.

You run up technical debt when you think “I’ll fix/document/investigate that later”. I keep a list of my “debts” and try to remember to go back and clear it every now and then. This morning I thought I’d spend ten minutes sorting out a few things. Five hours later I was still at it. Along the way I discovered:

  • the ESP32 random number generator uses WiFi noise as a random seed.

  • you need to download several files into an ESP32 device when you initialise it. These must include the partition table.

  • you can find out the precise commands that are used to deploy a program in PlatformIO by enabling verbose mode for the build process. I’ve done this twice and forgotten how to do it after each time. I really should write that down (which of course is another piece of compound technical debt)

Not withstanding my lack of demo, we did have a very good meetup though.

Browser Based Device Programming

/

Today I managed to take a brand new ESP 8266 device out of a bag, plug it into my PC and then go to a web site using the Edge browser. And from that web site I managed to download a program into the device. I didn’t have to install any software onto my machine. Very pleased with this, it is going to make getting started with Connected Little Boxes much easier.

Angry programming

/

One of the things that I’ve learned over the years is that if you are really, really angry about something the best thing to do is to try and channel that anger into something constructive. I started today very cross about the way that a silly virus is making such a mess of everything. And then I thought I’d channel that into sorting out problems with the code that I’m writing to deploy programs from the browser into ESP devices. It’s not been working properly for a while, and that has been annoying me too.

So today the problem got both barrels of rage. I simply was not going to let it beat me. And fortunately for everyone I managed to get it to work. At the end of today I’ve managed to transfer a stub program from the browser into a device. This is not the same as a “proper” program, it is a chunk of code that forms the bootloader element that will accept the uploader commands. However, It has proved the underlying process can be made to work, so I might have started the day angry, but I’m ending it happy.

Off by one hour errors in eZtime

/

eZtime is a splendid library for Arduino time keeping. I use it in Connected Little Boxes to manage all the clock data. Up until now it has worked perfectly. Then today I noticed that one of my clocks was out by an hour. Not getting the time at all is one thing, but getting a time so precisely incorrect seemed strange. I eventually tracked it down to this call in my program:

homeTimezone.setLocation(clockSensorSettings.timeZone)

This asks eZtime to set the time zone for the given area, which in my case was “Europe/London”. To do this eZtime has to send a message to the time server and get a response. If the network (or server) is busy the response might never come, and that’s what was happening to my code.

The interesting thing about this problem is that I only observed it when I had several devices powered from a distribution board, and turned them all on at once. A sudden cluster of requests for location setting information from lots of devices seemed to result in some devices not getting the proper response and consequently being out by one hour.

The good news is that the setLocation function returns a value indicating whether it succeeded or failed, so I’ve updated the program to retry until it gets the location setting it wants.

Connected Little Boxes now use files to store settings

/
clb storage.png

Maybe not a totally gripping headline, but it works for me. Up until now the setting information (pin assignments, network connection options, MQTT connection details etc) for a Connected Little Box device have been held in EEROM. This meant that the software would work fine on devices that only have very simple storage, but it meant there was only 2K of space for setting storage in the device.

But now that has all gone. All the settings are stored in a little text file inside the ESP32 or ESP8266. Passwords and other sensitive items are stored using my “encrypto-obfuscation” technology which converts them into text that is a bit harder to understand.

This update has also solved another problem. Previously adding a new setting value to a process or a sensor could invalidate the stored values in the memory block. With the use of text based storage that limitation has gone away, so that my planned “over the air” update feature can be used to update the device without needing to have all the settings re-entered.

You can find the latest version of the build on the Connected Little Boxes repository here.

Driven mad by pixels

/
mad maths.png

There’s a scene you see in lots of movies where the camera pans across a selection of crazy drawings and formulae, to imply the emerging madness of some deranged character or other. I feel that I’ve just lived through that. I’ve been trying to make my pixels move over surfaces in my Connected Little Boxes. I don’t want them to “snap” from one pixel to another, I want adjacent pixels to fade up and fade down to give the impression of the light moving. I want it to work in both “1D” (a line of lights) and “2D” (a grid). I’m sure there are off the shelf solutions for this but I want to roll my own. I’ve finally finished it. It was one of those occasions where actually knowing some trigonometry was really useful.

Making device configuration easy with QR codes

/

One of the hardest parts of installing an IoT device is making the initial configuration. The normal way to do this is to have the device start up a WiFi access point which you connect to. This is OK, but browsing for access points is a pain. However, you can now do this with QR codes. It turns out that there is a QR code that most phones understand that can be used to connect them to a WiFi host.

WiFiAP.jpg

The picture above shows how it works. It was produced at the QiFi web site here. I entered the name of my device (in this case CLB-3042d9) and it has generated a QR code I can scan with my iphone camera.

When the phone sees the code it offers to open up a WiFi connection to the device. It might just work with your phone too, otherwise you’ll have to track down a QR code scanner.

Note that I’ve turned off encryption and I’m not using a password. If you want a more secure connection you can change the Encryption settings.

Once I’ve got a connection to the phone, the next thing I need to do is to browse to the configuration site the devices is hosting, which is usually 192.168.4.1 I use another free web site to make a QR code with this address in it. You can find this site here.

WifIP.jpg

The link in the second QR code sends the browser to the settings page for the Connected Little Box. The user can then enter the settings and then reset the device, at which point it will wake up and start working. You can see my “work in progress” setting page below.

clbsettings.png

I’m going to print a label out with the two QR codes and a few lines of instructions that I can stick to each device to make it really easy for people to set them up.

Using Wire.h and SPI.h in Arduino project libraries

/

The Wire.h and SPI.h Arduino libraries are kind of important. They’re used by programs to communicate with devices over the I2C and SPI busses. I hardly ever use them personally, I rely on people much cleverer than me to create libraries that I can use to talk to the hardware I want to use.

I’ve been creating a “Connected Little Boxes” driver for the BME280 environmental sensor (a personal favourite of mine). I’d added the AdaFruit libraries and at that point my program broke. The compiler kept complaining about the Wire.h and SPI.h libraries not being available. Except that they definitely were. I could see them.

I’ve had this before, it is very frustrating. It’s one of those horrible situations where you have to know the “magic” trick to make it work. The magic thing to know is that if any of your libraries use Wire.h or SPI.h you must Include them in the main source file (i.e. the program file that contains your start and loop functions).

#include <SPI.h>
#include <Wire.h>

This makes the linker happy and allows your program to build.

It's still always the power supply

/
printertest.jpg

In a post a while back I surmised that if weird things are happening it is because of a problem with the power supply. It’s still true.

I’ve decided to add a printer to my Connected Little Boxes. I thought it might be fun to be able to print little messages on paper. I dug out my little printer and connected it a Wemos device. I did a tiny test and it worked fine. So I set to and built a printer module into the Connected Little Boxes framework. And it didn’t work. That’s not actually surprising. I’m deeply suspicious of code that works first time. It usually means that I am due a bunch of pain further down the tracks. This time it looked like I was getting all my pain up front, which is fine with me as long as I can fix it.

I did some tests and it looked like a buffer/timing problem. Short strings printed fine. I could print“12345678” but if I tried to print “123456789” it failed. The buffers were all the right size, the logging said the printing had completed OK. The little lights that I had connected to the printer data signals all flickered hopefully. The only thing missing was printed output. Wah.

I did what I usually do when I hit a problem like this. I went and had a cup of tea. I’ve discovered that if you hit a problem where the universe seems to be broken the best thing to do is walk away from it for a while. I’m lucky in that I haven’t actually got a customer waiting impatiently for the product and the printing feature is not the subject of a piece of my coursework that is due in (the other reason for fretting about deadlines).

After my second biscuit I’d figured it out. It was my old nemesis the power supply. The printer I’m using is thermal and prints a line of text all at once. The more you print the more paper it has to heat up and the more power it needs. I was powering it from the USB connection on my PC which can’t deliver much current. In fact, it delivers just enough to print “12345678” and no more.

I tested this by trying to print “1 2 3 4 5 6 7 8”. This is a longer string, but it needs as much heat to print as a shorter one. That printed fine. So I connected a proper power supply and off it went. As much string as you like.

Build a nice place to fail

/
failure.png

When I start work on a project I try very hard to make myself a nice place to work. For the Connected Little Boxes project I’m also making a nice place to fail. When a device goes wrong I want to have an easy way to find out what happens. The latest version of the software sends an MQTT message each time it wakes up giving the reason it was reset.

This will help me determine why a device fails. It should also make it possible for me to build something that tells me automatically when bad things are happening.