You’ll have to take my word for it, but these clocks are all showing the correct time, even after the change from British Summer Time to GMT. I didn’t actually stay up last night to watch them correct themselves, but it looks like I didn’t need to…
I solved my Heroku problem from yesterday. I’d added some new .env setting values but not copied them into the Heroku application. So when the app woke up on the server it instantly fell over because lots of things were not set properly. The app was soon working fine, but it did have one problem. Heroku turns an application off if it has not been used for a while. This is usually fine. It will be started next time someone visits the site. However, at the moment my app also monitors MQTT and registers devices when they connect, so I need to have it running all the time. You can stop an inactive app from being switched off, but this involves spending money on a paid service which, being a Yorkshireman, I’m not keen on.
Instead I thought I’d try hosting the application on Azure, where I have some credits (not that I expect it to cost a lot). I followed this tutorial (or at least the second half of it) and in no time at all I had something that didn’t work. Oh well. The error was interesting. Azure didn’t know where to start. I was a bit confused because exactly the same code was running fine on Heroku. It turns out that I needed to add a start element to the settings in package.json:
"scripts": {
"devStart": "nodemon server.js",
"start":"node server.js"
},I think that Heroku just finds the nearest .js file and runs it to start an application if one is not specified, whereas Azure is a bit more careful. Anyhoo, after this I now have a management interface for all my devices.
This is the control panel for one of my little boxes. I can modify the device settings, see when it was last connected and send it commands to do stuff.
It really is incredibly easy to make your own node applications and deploy them like this. If you don’t care about app timeouts you can build and deploy something entirely for free. The integration of the process in to Visual Studio is very impressive.
I put the app onto a paid subscription (around 10 pounds a month) and then twiddled the application settings to make it always on. Great fun.
I had a bug in my random number generator which was interesting. I’d used the wrong variable name at one point in the code and I was getting “the wrong kind of random” values generated. It’s fixed now, and my Connected Little Box devices will now properly synchronise their random light displays, as you can see above.
Spent a lot of the day building Name in Lights devices. I’ve got quite a few now. If you want one of your own, send me a note and I’ll see what I can do.
Here we have two Connected Little Boxes using an MQTT server to play the Two Button Game.
I really think we should press the red button……
I’ve just released the latest version of the Connected Little Boxes software. You can load it into your device here.
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.
I’ve spent most of today fixing bugs in my software. I didn’t find them myself. Brian fell over them when he was kind enough to have a go with the latest Connected Little Boxes version. I actually quite like fixing bugs. Every one I fix makes the program better.
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.
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"}
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.
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.
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.
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.
Apparently it is a good thing if your software behaviour lines up with the documentation. So I’ve spent a lot of today making sure that this is the case for Connected Little Boxes.
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.
The lecture is tonight. You can find our more, tune in and donate here.
Update: The video is now available. Enjoy.
If you pick up the April edition of HackSpace magazine and take a look at page 94 you’ll find a description of my Connected Little Boxes and how you can make them. You can find out more here.
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.
I’ve taken the first step in making a Connected Little Box that is a coin slot mechanism. I’ve designed and printed the box for it.
The case took 14 hours to print but I think it came out quite well. Next step is to fit the microcontroller and get the software going.
Rob Miles is technology author and educator who spent many years as a lecturer in Computer Science at the University of Hull. He is also a Microsoft Developer Technologies MVP. He is into technology, teaching and photography. He is the author of the World Famous C# Yellow Book and almost as handsome as he thinks he is.
