Blog entries tagged with "home automation"

I have written before about how I use a Zigbee dongle (the now discontinued RAVEn from Rainforest Automation) to get power consumption information from my smart meter. A bit over two years ago I also wrote about how it appeared that a failing power supply was interfering with the Zigbee connection and also confusing my UPS.

I think that my logic still holds for the UPS issues, but now I think I was wrong about it interfering with Zigbee…

Things improved when I rewrote my script to use a proper serial port library and then improved even more when I started to use that library correctly. However recently I noticed that there were still some gaps appearing in the power usage data, so I had another look.

My first action was to further cleanup my script so it both made more sense and to also report on more messages. I was only caring about InstantaneousDemand which is sent every 8 seconds, but it also often sends CurrentSummationDelivered and ConnectionStatus which I was ignoring.

Once I started logging ConnectionStatus I thought I might be seeing a pattern. At the times (for an hour or so every few days) that I stopped getting InstantaneousDemand messages, all that it was getting were ConnectionStatus messages, and the LinkStrength values were around 60 or 70, not the 100 it normally way.

So was something still interfering?

I couldn’t spot a regular pattern in the dropouts so I had no idea what possible interference there might be. The information about the RAVEn and other smart meter in-home displays mentions that placement of the device is important as Zigbee is low power. I had the RAVEn plugged into the back of my linux box which placed it about 10 metres from the smart meter with walls, furniture and the metal case in between. So what if I simply moved the RAVEn closer?

I had a long USB extension cable so it didn’t take long to relocate the RAVEn to be about 4 metres closer and not directly behind a metal box. After a week in this position I found that there was still the occasional reconnection, but nothing like the hours of no InstantaneousDemand messages that I was seeing before.

I could have just left the USB extension cable in place, but I didn’t like how it looked and didn’t want to add it to the mess of cables under the desk.

The RAVEn is a USB device that provides a USB serial port, on that port are XML messages. My script takes those XML messages and writes them to MQTT as JSON. Is there something else that I could plug the RAVEn into to do this, something that I can place close to the smart meter?

I’m a fan of using ESP8266 devices in the D1 mini form factor for my current home automation. Could I use one of these to build a RAVEn to MQTT bridge over wifi? Maybe, but with some caveats and possibly some effort and delay waiting for parts.

Other Arduino based options seemed just has hard so I turned to the old Raspberry Pi I had sitting around. I had previously used this to test out Kodi so I instead loaded up Raspberry Pi OS Lite and quickly found that I could transfer my existing perl script over, tweak it a little bit, and have it working.

The next hurdle with this as a solution was that it used wired ethernet and I don’t have wired ethernet in the room near the smart meter, I would need wifi if I wanted to have the RAVEn as close as possible.

What would it take to add wifi to this Pi? A USB wifi adapter can be used, but which one and how much would that cost? Would a cheap $8 adapter work, or would I have to get a $50 adapter? As well as not working, it might take a while for a cheap adapter to be delivered.

What about a newer Pi that included wifi? The Pi 3 B+ that I am using for Kodi has wifi even though I am using it on a wired connection, but that also costs towards the $60 mark, and seems to be out of stock.

Hold on, what about a Pi 3 model A+? This is smaller and cheaper than a B+, it also has wifi and the single USB port is fine for my single RAVEn. An online order and a few days later it arrived and was quick to get functional:

I needed a case for protection and liked the exposed look of the slim case from Core Electronics.

This has been running like this for about 36 hours now, taped the wall which puts it about 1 metre from the actual smart meter. Time will tell if this solves the reliabilty issues, but it is looking promising.

Of course this does seem like a bit of an overkill to use a whole Pi for this simple task. I might consider a Pi Zero, but I would need the W version (for wifi) and when you include the USB OTG cable the price is getting closer to that of the A+, and these are sold out everywhere I checked…

The final thing I want to mention today is that after I cleaned up my script I also wrote up some documentation and pushed it up to GitHub:

• popcorncx/raven-mqtt: Takes the XML messages from a RAVEn and writes them to MQTT

Just don’t yet look at my other repos as all you will see are two that were created seven years ago, only one of which has any code pushed to it. One of the items buried on my todo list is to clean up and push some of the other things I have written for my home automation setup…

On days when it is cold enough for my central heating to be needed in the morning but then it warms up for the afternoon I will leave my laundry door (and sometimes the front door) open (there are screen doors as well) to allow for plenty of fresh air. However I didn’t want the central heating to come on while the door was open as that would be a waste of energy.

Before I hooked my heating into my home automation I acheived this by flicking the HEAT/OFF switch on the thermostat, and for the initial implementation of my Arduino based controller it was easy to disconnect the relay was it was only connected with an alligator clip. However I recently mounted this controller to the wall in a more permanent way:

I couldn’t just pull the power on it as I still wanted the temperature readings, and altering the schedule in Google Calendar wasn’t that convenient, so with all the extra time I am now spending at home I decided to implement one of the things from my todo list: a sensor on the back door.

Some time back I had picked up some magnetic reed switches (like used in an alarm system) and it was straightforward to connect that up to one of the digital inputs on the D1 mini to read the state. It was a little bit more work to work out what and when to sent MQTT messages but that was easy to reverse engineer from the MQTT Binary Sensor config for Home Assistant.

I could now stand at the door with my phone, opening and closing it, and seeing the state change in the Home Assistant interface.

Though knowing if the door is open is only one part of the puzzle, I need to interact with the thermostat component.

I had two automations to drive the thermostat from the calendar:

• when a heating event starts THEN turn on the thermostat component and set the target temperature
• when a heating event ends THEN turn off the component and set the target temperature to zero

I altered these and added new automations to end up with:

• when heating event starts AND door is closed THEN turn on thermostat
• if door open for 5 minutes AND thermostat is on THEN turn off thermostat
• if door closed for 5 minutes AND thermostat off AND during heating event THEN turn on thermostat
• when heating event ends THEN turn off thermostat

This seems to be working. I put in the 5 minutes condition as I only want it to be when I have deliberately left the door open, not if I open it briefly, eg to put something in the bin. I think I might be able to combine the automations into only two, but I will leave that for later.

I also plan to have a proper outdoor temperature sensor so that I can have it notify me if the temperature is dropping and I have left the door open, or also if the temperature has risen enough that I might want to open the door.

But first I will cross a different item off my todo list, one that involves two microswitches and my garage door…

Around my house I now have three not a clock devices, in addition to one in my bedroom and another in the kitchen, the newest one in my study.

I mentioned in the earlier post how I retained the power connector so I could easily reuse the 5V power supply that the clock came with. I also left the circuit board for the buttons attached, partially to keep the buttons in place but also for potential future use.

In putting together the third one for my study I decided to see if it was possible to connect up the buttons. Spoiler: it is.

There are nine buttons that are connected by three wires. Looking closer I found that there is a common connection and then the buttons in two groups as resistor ladders, where each button corresponds to a different resistance.

The D1 mini only has a single analogue pin so I was initially concerned that I would only be able to connect half of the buttons, but after some experimentation I found that I could connect one group directly to the analogue pin and then the other group via a resistor. I don’t know what the resistances are, just that in the 0-1024 range of the analogue pin I was getting a decent spread of values.

The analogue values were not quite stable, fluctuating a bit, so in my logic I declared a set of ranges that mapped to each button. From this logical button state (nine buttons plus no button) I applied some de-bounce logic and had the arduino send an MQTT message when a button was pressed:

home/study/button POWER
home/study/button TUNEDOWN
home/study/button TUNEUP
home/study/button MEM
home/study/button SET
home/study/button VOLDOWN
home/study/button SNOOZE
home/study/button VOLUP

This worked, but wasn’t quite right as sometimes the button press didn’t seem to be registered and there would be MQTT connection issues. So it was registering the button, but it was failing sending the message. After some research I found that this was due to a limitation of the ESP8266. It is a nice small and cheap controller, but that single analoge input is also shared with the wifi chip, by constantly reading the analogue input I was causing the wifi to drop out.

The recommendation I found was to introduce a delay into reading the analogue input. So instead of reading the analogue input every time through the loop(), it will only check again after a specified interval. My debounce logic required the button to maintain the same state for 50ms, so I put in a read interval of 10ms and it worked perfectly.

Now a button is only part of a solution, what would I be controlling? Right now I don’t really have anything I want to control, in the future I plan to automate the tilt of my window blinds, but to prove the concept I added automations to home assistant to control the radio:

- alias: Button play radio
  trigger:
    - platform: mqtt
      topic: home/+/button
      payload: "POWER"
  action:
  - service: script.radio_play
- alias: Button stop radio
  trigger:
    - platform: mqtt
      topic: home/+/button
      payload: "SNOOZE"
  action:
  - service: script.radio_stop

This worked and as I have three devices with these buttons, so instead of tying the automation to a specific device I used the + wildcard so it would trigger on any of them.

Next I need to get around to building things (such as the blinds controller) that can be triggered…

Up until yesterday the last change I made to my script that pulls usage information from my smart meter was to make it use a serial port library. At the time I grabbed the example and apart from adding in a hack to remove the null characters I was getting it worked fine.

Inspired by some things at LCA2020 last week I decided that I would change how I was getting the usage data.

The adapter I am using appears as a serial port and while you can send commands, if you just read from the serial port it will output an InstantaneousDemand XML payload every few seconds. The script I was using would connect to the serial port and read until it got one of these payloads (erroring if it didn’t see one in 30 seconds), writing the data to MQTT for Home Assistant to pick up.

This didn’t seem to be the best way, it sometimes wasn’t able to open or read from the serial port (one hung process could give hours of errors) and it was also skipping over information.

My replacement version would instead run as a daemon, connecting to the serial port once and then publishing MQTT messages whenever an InstantaneousDemand payload appears on the serial port. I still had it die if no payload had been seen for 30 seconds, but it would be restarted as I set it up as a service.

This was working quite nicely for a few hours, but then I noticed the load value was high, checking with top I found that this process was taking 100% of CPU. This wasn’t right…

Upon checking the documentation for Device::SerialPort I found that while I had used examples from the SYNOPSIS section, there was a full EXAMPLE that was much better.

• In my loop I was trying to read() a single byte each time, instead I should be reading more bytes. The example used 255, so I went with that.
• I wasn’t checking the count of bytes returned from read(), this explained the null data I had been seeing. I was reading when no data was available, if the count was zero there was no data.
• There is a timeout value that controls how long the read will wait before returning zero data. If not set then the loop in my code would be calling read() as fast as it could, setting this to one second meant it was handled within the serial port library.

After making these small changes (aka using the library correctly) the CPU usage of this process dropped to nothing. While it wasn’t actually impacting the performance, it is good to do things properly.

Something else I an trying with this process is setting an MQTT Last Will and Testament message. This is a message that you set up when connecting to your MQTT server, but it will only get sent if there is an ungraceful disconnect. Coupled with a startup message I can get a notification when the process is starting and a notification if the process crashes. Time will tell how useful this will be, but it is interesting to learn about.

Power and internet comes into my home above my bedroom window. There have been a few times I have been laying in bed watching the cables whip around in the wind, wondering what damage that could be causing and how long the cables should last. This has in part been answered for me as the power cable (likely from when this place was built around fifty years ago) has now been replaced.

Tonight’s events possibly started around 8PM when I started to make some dinner, with one thing on the stove I started another in the microwave, at which point the kitchen lights dimmed (more than ever before) and in my study the UPS started to beep. For a while I had been tracking under voltage in my power because often the UPS would be boosting from battery, this time the voltage had dropped enough that the UPS was still able to boost, but also wanted to start shutting things down. Luckily I was done with the stove and microwave, once they were off the voltage was back to ok levels and the UPS was happy.

After I ate my dinner I started to check my logs and research who to contact about this, then my phone rang. It was my neighbour from the other unit asking if my power was on, because hers was not. This was unexpected as our units are semi-detached, we share the same power cable and the meters are in the same box. But then my power also went out.

Heading outside to talk we saw that the streetlights were on and that other houses in the street still had power. In the meter box I saw that both of our meters were on, so had our power been turned off remotely?

United Energy is my electricity distributor, nothing was listed on their outage page and as I was looking for a faults number to call I received a call. It was someone from United Energy to tell me that my power had been switched off as they had detected a fault. They asked some questions around if I had noticed any issues (I said I had) and told me that a work crew had already been requested and should be there some time that evening.

About an hour later the crew arrived, two people, one in a van and the other in a bucket truck. There were not the friendliest of people (they did have a job to do after all) but from what I could gather they identified the cable as old so would be the likely issue. An hour later they had replaced the cable and run some tests, my power was now back on and they were gone.

I mentioned that I was checking my logs, so what logs do I have?

After I resolved the issue of my UPS shutting down every few weeks I noticed that something was happening to cause the fans in the UPS to come on. The UPS is connected via USB to my linux box but all I was logging was the power output every five minutes. Adding the UPS component into Home Assistant gave me a nice view (and history) of a number of values:

I set up an automation to notify me (via Pushover) whenever the status changed. Over time I was able to see that the UPS was detecting a drop in input voltage, so was using the batteries to boost back up to a normal level. This would typically happen if I used two large applicances at the same time (eg washing machine and stove), but also at other times as well. It was on my todo list to find out what the acceptable voltage range was and probably get it looked at.

So what was the voltage doing tonight? This:

A few things can be seen:

• Around 230V before 5PM when I wasn’t home
• Initial drop to around 210V as I put my hot water on boost, then sitting around 220V
• Big drop to 200V and then as low as 180V around 8PM
• No data when the power was off
• Back to 233-239V once I turned everything back on

I will continue to monitor the UPS status with the expectation that I should not (or at least rarely) get notified about undervoltage again.

The final thing I want to say now is that this has been an interesting coincidence. The reason I needed to boost my hot water was because it had been turned off all week while I was at LCA2020 where the overall theme was security and privacy. The specific coincidence I am thinking of is that there was one talk about the smart meters (I hadn’t realised that outside Victoria the rollout was still ongoing and contentious) and I was part of a couple of discussions about their advantages and disadvantages. In this case the remote detection of a fault and quick rectification was a good thing.

We know when you are sleeping: The Rise of Energy Smart Meters – Rachel Bunder (LCA 2020)

Many years ago I started monitoring the power consumption of my house via a ZigBee dongle that communicates with my smart meter. The quick and dirty solution I did at the time stayed in place for a long time, until it started to play up…

The first symptom I noticed was that my script would hang, in itself not that bad, except that I was calling it directly from MRTG… which would cause the entire MRTG polling loop to hang, so I wouldn’t get any monitoring. In response I split the script, one to read the usage to write to a log, and another (called by MRTG) to read the latest entry in the log.

The reading script would still get stuck, so I added a generous timeout and stopped thinking about it. Until I thought it would be a good idea to also drop the usage data onto MQTT for Home Assistant to grab. Nothing wrong with this, except that I upped the frequency from once every five minutes to every minute. Sometimes it would fail for hours, sending an email with the error every minute…

I initially noticed the increase in timeouts around the same time that I upgraded the hardware in my linux box and did a fresh install of Ubuntu. Due to default permission changes I found that I could no longer simply cat the serial port, I needed to connect using Device::SerialPort, so I was thinking that there was something wrong with the usb-serial chipset or the driver.

That was until a few weeks ago, when I upgraded the hardware in my Windows desktop.

For a long time I have been aware of a slight ticking sound coming from that computer, you know the sound of a fan slightly hitting something or being slightly off balance?

The new build went great and although I didn’t really need the upgrade it let me do an upgrade that was required, to my parent’s computer. As I was handing down parts I thought that I could replace the power supply fan instead of buying a whole new power supply, so I powered it up and heard the same noise…

… coming through my speakers.

Oh, this is not a bad fan, this is a failing power supply.

So what does serial port problems in one computer have to do with a bad power supply in another one? Probably nothing, but since replacing that power supply I haven’t had a single timeout error, it is as stable as when I first picked up the adapter. I guess it is possible that the power supply was generating interference at around 2.4GHz…

Another thing I didn’t think was related was that the UPS that these two computers run from had started to shut down. Not in any graceful manner, but with a sudden power off followed by a loud continuous beep. I suppose it is also possible that a bad power supply could also trip the UPS…

As is becoming a habit, January for me means attending linux.conf.au which this time around was held in Christchurch, New Zealand.

The theme this year was “The Linux of Things” and rather than paraphrase the definition I will simply quote part of it:

“Building on the role that Linux plays in our everyday lives, we will address IoT-related opportunities and concerns from the purely technical through environmental, health, privacy, security and more.”

Those who know or follow me should immediately spot that that this is strongly aligned with my recent enthusiasm for home automation. I lost count of how many conversations I had with people about what I had done and what they had done, then there were a number of relevant talks that added more information into the mix. It is a lot to think about…

A few of the bigger takeaways are:

• Home Assistant is good for automation and displaying recent history, but store long term history elsewhere.
• Use what you are comfortable with. For others this may mean off the shelf devices, but for me this means I will continue building simple functionality into arduinos.
• What you actually do is also highly personalised. Just because someone triggers the aircon in their office to turn on when they make their first cup of coffee doesn’t mean that you have to as well.
• Always learn from what other people have done, and just as importantly share what you have done so others can learn from you.

That last point isn’t really new or home automation related, it is part of the philsophy underpinning open source itself, so not surprising that it came up (a lot) at an open source conference ;)

As is also becoming a habit, I am not going to travel to another country just for one week, in a similar way that I followed up Hobart 2017 with a road trip, I am also following up Christchurch 2019 with a road trip:

I will need to hold off (for now) the planning a road trip from the Gold Coast, because that is where LCA will be in 2020…

Once I had my central heating controlled by Home Assistant based on a schedule in Google Calendar I started to think about how I could also control my stereo that I use as my alarm clock. This 25 cd stacker double tape desk stereo (purchase from Brashs gives an idea of how long I have had it) was the final clock in my house (I’m considering my car stereo to be out in the garage) that I would need to adjust for daylight saving.

My first thought was to find a manually tuned radio that I could just control the power of via a relay. I was able to find a few cheap radios, but they all had electronic tuners, so you couldn’t just kill the power. I also didn’t want to use an old radio, because it wouldn’t be as nice.

Next I started looking into playing back the infrared codes from the remote control for my stereo. This looked promising, but I was starting to like the idea of getting rid of the reasonably large stereo.

I briefly looked into a radio tuner module controlled by the Arduino. This would give me the ability to remotely tune to different stations, but it would also need some form of powered speakers that turned of/off at the same time.

Another option was a network speaker and I considered some cheap wifi speakers, but dismissed them when I found that nobody had integrated with them, I also didn’t find anything good said about the phone app they use for control. Also on the network speaker approach were options like a Sonos or a Google Assistant speaker. These are a lot more expensive and require cloud integration that I didn’t like.

The solution I went with was a network speaker somewhere in the middle, a speaker with integrated Chromecast. These have been discontinued in favour of more expensive models with Google Assistant, (I was able to find a new one on ebay for a very reasonable price) but with the advantage over a cheap speaker of there being a Google Cast component in Home Assistant.

Once setup on my wifi network it was again fairly straightforward to create automations to trigger playback from a network URL, the tricky part turned out to be finding the streaming URL for the radio station I wanted. If you go to there website the stream is provided by iheartradio which I couldn’t get to work, but I found a different source for the same station from the website of the radio network.

This has been working well (and I reclaimed space where the old stereo used to sit) but it does feel a bit wrong to change from receiving a broadcast over the air to downloading a network stream, it goes against one of my goals of not relying on internet/cloud services, although it can be rightly pointed out that using Google Calendar for the schedule already violates that goal…

After achieving my first long term goal of a clock that I do not need to adjust for Daylight Saving, I moved onto remote control of my central heating. Thanks to some Home Assistant components this came together quite easily.

I have gas ducted central heating with a controller mounted in a central location. You could say I didn’t need to change a thing as it was already “smart”:

Yeah, nah…

This is what is referred to as a 5+2 programmable thermostat, there are two sets of schedules, one for the five days of the week and another for the two days of the weekend. The interface between this thermostat and the heating unit itself a pair of wires carrying around 25VAC, close the circuit to turn the unit on, this would be done instead by a relay connected to an Arduino.

On the user interface side I was planning to use a Google Calendar as I could put in events to represent the schedule and I could already manipulate it from my phone the the web interface which covers off remote access. The regular schedule would be in as repeating events, but I could adjust them as needed if I knew I wasn’t going to be home until later than usual.

My original plan had been to write something that would query the google calendar and push that information to the thermostat Arduino which would compare the target temperature against the current temperature and set the state of the relay appropriately. This approached changed when I saw that there was a Generic Thermostat component in Home Assistant that would handle the logic of being a thermostat. I wouldn’t need to implement that on an Arduino, it could just be a dumb relay control for Home Assistant to turn on or off. As Home Assistant can use any type of switch component for this and I was already basing things around MQTT I looked at the MQTT Switch component.

I don’t really know how a switch should be implemented, but from the desired behaviour it was easy to work out that the Arduino would listen on a topic for a state (OFF/ON) and ideally it would publish the new (or current) state on another topic. An additional thing I added was a failsafe, the relay would timeout after five minutes, if something went wrong (eg wireless went down or Home Assistant crashed) I didn’t want the heating to run forever.

I did encounter one snag with the relay shield that I had, it was hardwired to have the relay on pin D1, but that was one of the default I2C pins. While I wasn’t using one of the I2C displays in this situation, I was trying to share code between my devices. Later versions of this relay shield let you configure which pin it uses, so in my case my I pulled out the D1 pin (I had already soldered it up) and ran a wire around to another pin.

Adding the switch logic to the Arudino sketch didn’t take long, nor did adding the configuration to Home Assistant, so it wasn’t long until I has it connected up for testing:

This worked well, so I moved onto implementing the scheduling aspect using the Google Calendar Event component and automations.

Despite parts of the documentation not matching the implmentation (I need to follow that up, possibly asking on the forum or even submitting a patch…) it wasn’t long until I had automations configured to set the target temperature when a calendar event started, and to then turn off the thermostat when the event ended.

It was now a waiting game as I needed to let the automations trigger over time, and I also needed the weather to cooperate. Fortunately I am in Melbourne where despite it almost being summer we had a week or so of cool enough weather for this to happen:

I was quite happy with this, just in time for summer to really kick in and I no longer have a need for central heating… but that does give me time to sort out a proper mounting and power supply. I was initially thinking about finding some kind of unobtrusive box to mount on the wall, but the idea of featuring the electronics (such as a Tripler Base mounted to a blank plate) is growing on me…

Do you see this thing that looks a lot like a bedside clock? While it may be displaying the current time, it is not really a clock…

To explain what I mean I need to go back a few weeks to when I was inspired to finally do something with the various electronic components I have collected over the years (five years since I plugged in a DS1820 sensor) for home automation. After some tinkering and relying heavily on the examples that come with the libraries I had this going:

On this breadboard is a D1 mini microcontroller, a DHT22 temperature and humidity sensor, and a 4-Digit 7-Segment Display from Adafruit. It is fantastic that other people have done the hard work of sorting out the libraries for the board (with wifi), the sensor and the display. Everything I have done with these is based on the examples provided.

What is happening in this photo is that it is alternating between displaying the temperature and the humidity, but over the following few weeks I continued to tinker until I had it publishing the temperature (and humidity) over wifi to an MQTT server in order to get the data into Home Assistant which displayed this:

Yes there are two data sources, because I had five (more on the way!) of these microcontrollers and they are cheap and simple enough to scatter around the house. They are easy to run from a USB charger, so anywhere I have a powerpoint I can have a device. I now have a lot more configured in Home Assistant and I am feeding in data from other sources, but they will be posts of their own, for I need to get back to explaining why this is not a clock.

Apart from adjusting to the time change, my biggest annoyance with daylight saving is the clocks that need to be manually changed. It is a lot easier these days as phones/computers/etc will automatically update, but I still have a few clocks that need to be adjusted.

My bedside clock is one of these and while I know you can buy a clock that adjusts automatically, when I last looked (it has been a while) I didn’t like the look of them and they were too expensive. So this was going to be my first project and at first I was going to make it a clock that would use time protocols to get the correct time, but you still needed to deal with timezones and other things.

So why not make it dumb? I have a linux box that is always on (where I am running services such as Home Assistant) and it has already dealt with the timezone and DST changes. Every minute it could publish what it thought was the current local time, something as simple as cron running a bash script:

#!/bin/sh
DATE=`date +%H:%M`
mosquitto_pub -h localhost -t home/localtime -m $DATE

The requirements for the “not a clock” are pretty simple:

• Connect to wifi and the MQTT server, subscribe to the home/localtime topic
• Every 60 seconds publish temperature/humidity to MQTT (for Home Assistant to collect)
• Whenever a message arrives on the home/localtime topic, output to the LED display

Making enclosures is probably what I will have the hardest time with (do I buy a 3d printer?) and until this evening I had bare electronics hanging from the wall in four locations around my house. With the need to be able to see the LED display I had the idea of using a clock radio as the enclosure. I decided against gutting my working clock radio so over the weekend I stopped by the local Kmart where I found a clock radio for the lofty price of $15:

(I’m showing the silver model as the picture gives a better idea of what it is, the black model is just a black obelisk, it also comes in rose pink if that suits your colour scheme)

It is not designed to be opened up so some force was required, but after removing the internals and the strategic application of tape and hot glue I have what is in the top picture. I have the temperature sensor taped to the side because I think it wouldn’t get the best reading being inside the case, limited airflow and some heat from the electronics could skew the reading.

An unexpected bonus of this specific radio (and it makes sense from an electrical certification point of view) is that it runs from 5 volts and comes with a small power supply. I retained the socket for this and wired it up to the D1 mini instead of using a USB power adapter. I also kept the board for the buttons on the top of the clock, in the future it might be nice to use them to as a trigger for some action…

I have a lot more to say about Home Assistant, including how I am testing out control of my central heating (just in time for summer…) using a D1 mini equiped with a relay. I have also realised that the remaining clock I have to manually adjust for daylight saving is my stereo, the 25 cd stacker double tape desk stereo that I use as my alarm to play the radio… is there a wifi speaker in my future?

When I recently started monitoring temperature it involved a USB to RS-232 adapter connected to my Linux box. A few weeks later I plugged in a USB device to monitor power usage.

Temperature was via /dev/ttyUSB0 and power was via /dev/ttyUSB1. Until an unscheduled reboot at which point they swapped around as that was the order the devices are detected at boot, not the order in which they were plugged in.

A quick search led me to discover that you can write rules for udev to give devices persistent names.

Relying heavily on Writing udev rules I muddled through enough to end up with these rules:

SUBSYSTEM=="tty", ATTRS{product}=="USB2.0-Serial", SYMLINK+="digitemp"
SUBSYSTEM=="tty", ATTRS{product}=="RFA-Z106*", SYMLINK+="raven"

The generic RS-232 adapter now comes up under /dev/digitemp and the Raven comes up under /dev/raven. Now my monitoring will survive a reboot.

While some people are heavily against smart meters, I am not concerned. In fact when I received the initial notification about the installation my first thought was about the possibility of playing with new technology.

When they finally installed the meter it coincided with a co-worker getting solar panels installed which led to a number of conversations about ways to monitor power generation and consumption. Based upon previous research I had done I knew that other people in Melbourne had had success with Rainforest Automation devices which use the ZigBee Smart Energy wireless protocol to connect to the smart meter.

My co-worker opted for the EAGLE as his solar panels also connected over ethernet, while I opted for the (cheaper) RAVEn which is a USB dongle.

Once the devices arrived I had to wait a few more days until my smart meter was completely setup, but then it was a simple matter of entering the address and install code from the RAVEn into the online portal for the smart meter. After a quick test with the windows app, I plugged it into my Linux box to see it come up as a serial port.

It was nice to simply run cat /dev/ttyUSB1 and see it output an XML fragment reporting the instantaneous demand every few seconds.

The documentation for the XML API showed me how to send commands and how to convert the hex values to decimal and how to apply the multiplier and divisor. It didn’t take long to wrap this in a script to be called by MRTG:

Events visible in this sample include:

• Hot water turning on at 11PM AEST and topping up a couple of times
• Fan and light while getting ready for work
• Fridge cycling on during the day
• Use of oven to cook dinner
• Lights and other usage when I am at home

Due to complications with having off-peak electric hot water (aka a ‘controlled load’) I do not get summation values, instead that is just a graph of the instantaneous load. So while it doesn’t give true usage, it is a good enough indicator.

Currently this graph is available to anyone who knows the URL, and while it can let someone determine when I am or am not at home, the easier way to do that would be to go into my backyard and look through a window.

Ten years ago I purchased a couple of DS18S20 1-Wire temperature sensors to monitor the outdoor temperature, the ambient room temperature and the temperature inside my computers. Along with the sensors themselves I got a RS-232 to 1-Wire adapter and a DS1820 mounted on a demo board.

While I did connect them up and used DigiTemp to prove that the adapter and sensors worked. I didn’t get much further, until two months ago when I decided it was about time to do something related to home automation, the result being this:

producing this:

After a failed attempt at using an old serial port header to connect the RS-232 adapter I splurged on an entire $6 to get a bright pink USB to RS-232 adapter. The remainder of the hardware pictured is the DS9097U-009 adapter and the demp DS1820 mounted at the end of an RJ11 cable.

The software side consists of the digitemp package, a wrapper to pull the temperature from the digitemp output, and my existing MRTG setup.

Since then this setup has been logging the temperature every five minutes. It was interesting to be able to see my central heating come on at 5pm and cycling to maintain a target temperature of 20°C until 11:45pm. The above snapshot shows the central heating coming on yesterday, but not on the current day.

Despite this now being in use for almost two months, my plan is to incorporate the sensors into something more sophisticated, for example an Arduino based ethernet connected thermostat for my central heating. This is not a new idea, there are just a couple of examples floating around to use for inspiration.