The Desk Clock Lives Again… sort of…

Well, all the parts arrived — well, those I ordered, at least — and sat around for a week or two until I had the opportunity to assemble it.  So it's together … ish … and hanging on my wall.  The "ish" part…  This is what happens when you indecisively and experimentally add and remove parts over a year and a half or so, without really expecting it to become a reality any time soon, and then suddenly decide, "you know, I'm going to make this a thing."

Being a low-priority "I'd like to get around to doing this some time" project, I wasn't necessarily paying the closest attention to details, and a lot of things were left in the "to check later" basket, which was more of a mental note thing, than a proper tracked project thing — and it's not hard to figure out how that will end.  Sooo…  here's the round-up (and I'm making a proper check-list now):

• The cutout I added for the EtherTen's Ethernet port, was about 1mm too low, requiring me to take a file to the PCB.  I've now raised the top edge of the cut out, and lowered the bottom edge slightly just for a touch extra clearance, and I'm mighty glad I'd moved the track that was originally wrapped fairly snugly around the cut-out.  Still…  All things considered, not too bad for a tape measure measurement.
• The RGB LED component I used, was a standard library footprint.  I remember thinking, "you know, common ground on pin 1 doesn't quite seem right... I'll have to check that later."  But I'd only put the component on the schematic to test out an idea — mainly to check whether I have enough ųC pins for it — and I hadn't actually decided to actually include it yet, the one on the original breadboard version was a little over-poweringly bright at times, so making sure it was the right part to what I might be using some time down the track, wasn't real high on the priorities.  Unfortunately, of course, I didn't check the footprint.  So my RGB LED, is presently a GB LED — turning the red segment off provides a false ground (back through the ųC) for the other two segments, at twice the resistance (which actually looks quite okay, and is plenty bright enough as is).  Needs some further experimentation.
• The Clock display also seems to have developed a fault in the past week or four — which I don't think is actually my fault, for a change; I thought it was just a couple wires had come loose on the breadboard again, that was making a few digits fail, but, it was something more.  One of the LEDs is leaking when reverse biased, and the driver chip is failing.  I'm not sure which failed first, but there's definitely faults in both; when I transplanted the Clock display onto a breadboard and tested it manually, all the segments worked properly, but I noticed connecting power across the commons for digit 3, and one of the others, would cause that other digits D segment to light dimly, which leads me to think digit 3's D segment is permitting reverse current flow.  I surmise from that, that it's doing nasty things to the driver chip, causing it to progressively fail, leading to the gradually increasing dead segments over the past couple weeks.  I have one more driver, but only the one display, and not sure which of the two caused the initial problem, but knowing the display certainly has a problem, I'm loathe to plug in my other driver to test the theory — and so since I'm going to need to rev the board anyhow, I'd rather hunt down a replacement display, and keep the second chip for the new board.

Conclusion at it's present state: I need callipers, and definitely need to keep a proper TODO list.  Really, most of the problems stemmed from those two.  I've been poking at this project in very brief stints, over several years, and it was only a fairly whimsical project to begin with, that has suffered scope and feature creep almost every time I've touched it — typically, playing with some random thought or idea was the reason for touching it again to begin with.  The bigger problems, footprints I had to design, the schematic layout itself, were all fine, and the general concept seems to work as intended.  So on the whole, the board layout was a significant success, and a rev 2 was pretty much expected, as this entire thing is mostly experimental.



On the software side, it's sending room temperature, light level data, and button presses, over MQTT.  The RGB LED glows blue during "daylight" hours, and turns off at night, which is something of an inbuilt test of the light sensor.  I did have the green segment blinking once per second, based off the clock chip's 1Hz output (which drives the internal time keeping), but that got annoying — which is a thing, I'm really not sure I want the LED there at all — though I might keep it purely as a network addressable indicator, even if I don't give it a purpose within the clock itself.  I've removed the clock display driving code, because there's presently no display attached, though I'll have to re-activate that just so it takes up it's slab of space…  And I need to fit the external temperature sensor — going to need an extension cord for that, too.  And of course the entire menu system is going to have to wait until there's a display for it to use, and even then I'm very dubious it's going to fit on the device at all, so that may well end up being offloaded to the server in any case — sounds like fun either way.



The current TODO list basically goes:

• Fit the external temperature sensor (with extension), and get it sending data.
• Decide whether I really want that RGB LED there or not…
• Experiment some more with the light sensor to improve it's sensitivity range.
• Get the proper push buttons for it… the current ones are under-sized.
• Order new displays — the one I'm using is remarkably difficult to find in a colour I like.
• Re-activate the display driving code…
• Finish the coding — need to see if everything will even fit!

In the meantime, my present automation infrastructure, is lacking in actual infrastructure, so I'm in the process of fixing that.  Once I have that updated and better integrated, I'll put that light sensor data to use turning off my lamp when it's not needed, and actually storing the temperature and light data so I can draw pretty graphs and what-not — although I'm fairly certain Hass.io and the likes have components for doing just that, but still, you learn more if you do it yourself first, and that's what this entire project is about, after all — migrating to Hass.io or it's ilk, will be an adventure in it's own right, and there's a plenty long enough TODO list already.

A final note…  I also need a cleaner project management system.  With a single project potentially spanning KiCad board designs, Arduino firmware, R.Pi based scripting, and potentially online components hosted on my GAE project, along with general notes and reference materials… having the separate bits living within their own little environments is, troublesome.

A little automation…

Okay, so a bit of time has passed, and my room has just a little bit of automation going on…  Nothing particularly impressive, and still so much to do, but piece by piece…

Firstly, there's a Sonoff Wifi switch on the bed-side lamp.  It's hooked up to a rather crappy Python automation script, but it is none the less "automated", somewhat.  However, as I wasn't able to find an API for the Sonoff, and I haven't yet been brave enough to try re-flashing it with something like Tasmota, the only way I could find to control it was to use IFTTT as an intermediary — so a quick bash script lets me turn it on or off, issuing web requests to IFTTT, which in turn communicates with the device's server, and then back down to the device — that's probably quite literally doing a lap around the globe, just to send a simple on/off signal about 1.5m.  It's on the list of things to fix.

Also, several months back I pulled out a 1m strip of RGB LED's — 60 5V APA102C's — which I've had for about a year, but hadn't taken out of their sealed package.  Hooked those up to an EtherTen (Arduino Uno, with built in Ethernet from Freetronics), and laid the strip along underneath my monitors.  Right now as I type this sentence, it's displaying a fairly standard sweeping dot sequence.  These are nice LED's, because they're 4-wire SPI-style, but… they don't do dim.  At all.  You try to dim them past about medium, and they just get annoyingly flickery, and any colour other than pure red, green, or blue, breaks down — as it is in the sweep pattern, when it's showing a non-pure colour, you get pixels in the tail that are showing just one of the component colours, making it stand out occasionally, albeit briefly with the relatively fast fade.

Initially, it was a regular Arduino Uno, running a simple demo program that cycled through a set of demo patterns.  But I decided I wanted control over it, so it was fairly quickly swapped for the EtherTen with a very crude web server.  This allowed me to manually change the pattern, brightness, and I'd added the ability to turn it on and off (fading in and out).  That was then followed quickly by a Raspberry Pi, and the introduction of MQTT, with a cron script bumping the pattern every 10 minutes.  The MQTT server offers a very basic web server, which allowed the creation of a basic web interface — you can find plenty of examples of doing so online, which was an excellent way to get started.  Up to this point, it's mostly just running example and tutorial code off the web.

But then, as always, I decided to make it my own — it's undergone major reworking since, as I struggled against the tight confines of the Uno core (32KB Program, 2KB RAM), while also adding extra features like being able to reserve LED's from either end and set them independent of the running pattern, as a means to show indicators.  There's also a pixel clock overlaid on top of the pattern — red dot for hours, green dot for minutes, and blue dot for seconds.  So the basic set of patterns (there's a couple extras of my own), are still mostly the code you see all over the place, but I've tweaked some of them a little, plus I had to re-work them all a little to support the indicator feature (the pattern down-sizes to fit the unreserved space).  The rest of the code, however, has been ripped out and replaced utterly.  There's more I want to do yet, starting with replacing the current hue shifting, with colour palettes — the stock ones, a couple extras of my own, and support for a custom — and expanding the indicator support to add fading (ran out of space to implement that).  Though that's on the back-burner at the moment, it works, and there's other things that need doing.

Speaking of which, as I said, it's being driven by a script on a Raspberry Pi running the MQTT server, and I presently control it though script commands over SSH terminal — it's very much still a work in progress.  There's also a script that turns off the light if I leave the house, and turns it back on when I come back, though it needs light level awareness, which is planned to be sourced from my desk clock.  I'm also planning to transition to something like Hass.io on the second R.Pi, and depreciate my rather gruesome and not particularly well meshed Python and bash scripts.

Also coming, I plan to replace having to control it by SSH (or even web, once I decide to sort out Hass.io), with a satellite Arduino Uno (I'll have one spare when I swap the one from my desk clock, with the spare EtherTen), with power and RS-485 data, and maybe an LCD — I haven't used an LCD for anything yet.  There's also the bedroom window — that winder most definitely needs to be automated.  Cue the hunt for an electronic window winder…  To the TODO list…!