Blog entries from January, 2020

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)