A Brief History of Everything Wireless Blog: Back to the Hardware part 2: Smart Home v1.0

Back to the Hardware part 2: Smart Home v1.0

2024-01-04 [Petri]

This the the second part of my "Back to the Hardware"-saga. The first part can be found here.

We had entered the age of the microcontroller.

Instead of having peripheral functions and memory provided by individual chips, these functionalities were integrated on the same piece of silicon as the processor itself.

They could be programmed and re-programmed electrically without any fancy UV light setups, using simple programming circuitry that did serial "bit-banging" data transfer to and from the chip via a couple of pins.

They were also cheap enough for tinkerers like me to purchase, and due to their use of the CMOS process instead of the old TTL, they did not consume more than few tens of milliamps of power when running at full speed, or almost nothing if put in a special "sleep until something happens" mode.

I grew to love the Microchip PIC series. There were LOTS of different models already in the early days, and today there are thousands, some of which would run circles around the PCs of the 1980s in terms of their processing capacity, still costing only a couple of euros.

Their internal processor architecture was horrific, being similar to the early Intel chips but to the power of two, together with less available resources like memory and registers. They had segments, segment register management, and all sorts of programmer-unfriendly things that would bite you hard if you didn’t get everything just right. RAM and EEPROM memory sizes were also in just tens of bytes and few kilobytes, but with the in-built I2C and SPI buses you could add cheap external memory chips if you needed more storage.

But due to all this segmentation, it was a nightmare to use assembler code for programming these things.

Luckily you did not have to.

The salvation to this dilemma came in the form of a semi-decent Integrated Development Environment (IDE) that allowed you to use the C language for programming, thereby hiding all this segmented monstrosity away from sight.

For the most part. You still had to remember to take all the limitations of the underlying hardware into account.

Even though you programmed in C, you could still drop to assembly level at any time, but mainly you only used that for things like tight timing loops where you had to know the exact execution time of a code segment, and your requirements were too tight for the internal timers.

Did I say timers? Yes, the other benefit of these new generation chips was that they were super flexible: not only did you have the communication support for the aforementioned I2C and SPI protocols, but the pins could be re-assigned to a set of additional functions that were provided by the on-board peripherals, like timers, analog/digital converters, I/O pins, internal and external interrupts, etc.

Practically every chip manufacturer now has these microcontrollers in their product line, giving us all of the cheap gizmos with "inbuilt intelligence", from toys to toasters, as they can cost as little as 10 cents a piece.

Recently I saw a video of someone making a 16-core "supercluster" board with the new RISC V-microcontrollers, where the actual chips still only cost a total of €2.

The stealthily advancing RISC V-revolution is worth another blog entry later on...

The C-language IDE had a price, but at this time I was working in R&D for an employer with very deep pockets and openness to research new capabilities on the market, so investing in this programming comfort with the help from the employer was not an issue: you said "I would like to test X because of Y", and next week it arrived at your desk.

Commercial programmers that "etched" the code to the memory inside the chip and supported a multitude of different models of these processors were also widely available and easy to use.

These chips were not only cheap, they were also very fast, being able to execute millions of assembler-level instructions per second. So they could be used to shift a lot of processing from the former analog circuitry with discrete components to real-time software realm, thus replacing a handful of components that were needed in the earlier designs.

In one application in my own "tinkering phase", I managed to be able to measure the momentary power consumption of my house by doing constant analog-to-digital conversion from a photo sensor that was attached over the blinking LED of the electronic power meter, and thus totally isolated from the mains voltage circuitry itself.

The number of blinks per second was directly proportional to the kilowatts consumed in real time, and my program detected a rising and falling flanks coming from the input, did the initial maths regarding the milliseconds between the pulses, and sent that over to my main "house management server" that was running Linux.

No other complex hardware or direct interfacing to the electricity meter was needed, just a resistor and a photo sensor connected to the A/D input pin, and a busy loop with slope-detecting logic.

It was grassroots Edge Computing with "ETL on the edge".

And it worked well. My electric bills matched the claimed real-time usage almost down to the kilowatt-hour, and it was nice to see the momentary and daily statistics of your electricity consumption on the home automation control display.

I had several PIC-based "nodes" in my "smart home": naturally one of the first "useful" additions for a Finn was a sauna thermometer with local LED display, also sending the temp info to the main computer, which then used it to give an audible signal in the house when the sauna was ready for a visit.

Another example was getting a notification sound across the house when mail arrived at the mailbox that by the Finnish law needed to reside by the road. Another was controlling the relays for the centralized air conditioning unit, based on the feedback from movement sensors.

Hence all sorts of nifty home automation stuff that you can today buy off the shelf was hand-made by me at a time when the terms "Internet of Things" (IoT) or "Home Automation" were not even born yet.

A funny event happened with the aforementioned, modulated infrared beam-based mailbox detector that was positioned so that it triggered when any mail dropped into the mailbox:

One evening I started getting false indications, and after it happened the third time, I took a flashlight and investigated the innards of the mailbox in detail: maybe the sensor had gotten loose and wind caused it to wibrate?

No, the reason for errors turned out to be a spider that most likely sensed the low-intensity infrared emitter heat in the cold, Finnish autumn night, and decided to warm its hairy butt right in front of it.

I gave it a new universe to explore inside my semi-warm garage instead.

What lacked due to excessive cost at the time was wireless connectivity: Nokia had just come out with the first WiFi access points, which I was testing at my home, but there were no cheap chips to use in the microcontroller space.

So I had to wire all things with various serial interfaces, all of which were then concentrated to my Linux server through an adapter kit that worked as a gateway between the clients. Luckily, the newly-built house had plenty of spare wiring tubes in place to accommodate all of the wiring.

I named the control system "Musti", as per a common name for a dog in Finland, and a versatile "house control panel" was provided by an old Thinkpad laptop embedded to the wall next to the entrance, as seen in the attached picture.

Additional nice touch was the event handling of the doorbell knob: when someone pressed the doorbell, the panel display automatically switched to display the video feed from the camera by the door. So while you approached the door, you always saw who was behind the door before opening it.

As the camera interface had two inputs, I installed another camera to watch the gauge that showed the level of oil in the tank that was feeding the furnace in the house, and processed one still image per hour from that camera into a simple indicator icon on the display's top right edge.

The attached picture shows a snapshot of the interface.

No touch screens were available at the time, so I made a small touchpad from A/D converters and 3 mm screws that emulated a mouse when I put my finger across the "sensor" screws. With a PIC inside again, of course, turning the resistance changes caused by my fingers into mouse movements for the laptop.

Naturally, as it was using a browser for displaying the info, you could access it from any computer in the house, not only from the embedded "main controller". So you could turn the sauna on from wherever, or see who was ringing the door bell.

It all worked very nicely. I even had audible warnings when there was a potential of Aurora Borealis due to intensive solar radiation, and another notification for any impending Iridium flares,.

Both naturally only if the rain sensor was dry at the time, indicating the possibility of clear skies.

The rain sensor info was also used to start melting newly rained snow from my entrance steps if the temperature was not too cold, but only if sauna was not on, in order to keep the overall power consumption within the limits of my agreement with the energy supplier.

That was all happening already in 2002.

Then I moved to Brazil and as I was living alone, I did not need much automation in a two-bedroom flat. My electronics interests were mostly put on hold.

But a new, intriguing trend had arrived, and I spent a lot of time with it while in Brazil: 3D-printing.

The story continues here.

Permalink: https://bhoew.com/blog/en/144

Show latest Earlier entries