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…!
Showing posts with label Arduino. Show all posts
Showing posts with label Arduino. Show all posts
Sunday, 6 January 2019
Wednesday, 21 November 2018
A clock, for my desk, revisited…
So, back when I was a wee kid, I wanted to make the obligatory LED
clock — back then, it wasn't ųC's, it was decade counters and 7400
series logic gates. Never did actually make it, though… So when I got
my first Arduino, the desk clock (with a few extras) was the first thing
I made after the obligatory learn-to-Arduino style Blinky. But as I
mentioned in an earlier post, it died a sad, sad, death.
I've done my non-Arduino Blinky, too, nice little (7)555 on a board, got me a taste of KiCad and SMT. Now it's time to resurrect my DeskClock project; this time, I'm planning to make it an Arduino shield, much the same as before, but with an actual real time clock module thrown in for bonus points. (Next version, I think, will be an all-in-one, maybe I'll add a buzzer there for an alarm option, maybe the external temperature sensor I was considering adding also, so many things…)
Now, onto the project. So I've got me that nice blue 4-digit 7-segment clock display, and a simple MAX7219 display driver. The driver's not really what I want, I want (at least) per-digit brightness, the 7219 only does global brightness, but it's what I've got, so I'm going to see if I can make it do what I want, see if I can flip the digits on and off quick enough to pretend. Though from an initial poke, I gotta say I'm a little dubious… Still, current step is to get the display running, then try it and see. But there appears to be a small problem, it seems my common-cathode display, mayhaps isn't. Started with a simple library and demo program on the Arduino, with just the MAX7219 and the display wired up, and nada. Well, not exactly nada, all the digits were on, all the time. Seems kind of obvious now, but after poking at it for a bit, and verifying that the program is spitting out the data it's supposed to be, I think my common-cathode display might actually be a common-anode one, or if I'm lucky, perhaps the documentation I found just has the anodes and cathodes backwards — I would have noticed that when I was building my clock the first time around, but I was just experimenting and playing with it at the time, and wasn't particularly keeping notes. (This is why project diaries are good — they save you from wasting time later on.)
(… later …)
Well, it turns out the display is indeed common-anode. Still, that wasn't going to stop me. A little confusing wiring, and some tricky coding to transpose the bits, and it's displaying digits just fine — little annoying I can't use the display trim to render just the four digits, but it works just fine. Added an RTC module (so it doesn't slip a minute a day like it used to), and stepped it up to two buttons this time, and it's been running quite happily on my shelf for the past couple months.
(… much later …)
Its RTC module is still holding time just fine, though it's hard to read the digits through the tangle of breadboard wires, so it's been sitting there running, but mostly neglected — the interface connected to those buttons is still mostly undone. Well, I've finally decided to push it along again. I've got a spare EtherTen board, and that clock has a temperature sensor stranded on the device and not available to my growing room automation system … I'm sure you know where that's leading.
However, that does change the plan a bit. I'm not quite to the point of designing PCB's with Ethernet just yet, so I've designed a PCB version of the circuit as an Arduino shield, parts and board (finally) ordered, just waiting for it all to arrive. It also raises a fresh problem; my prior little project, very quickly exhausted the ATmega328P's (the chip at the heard of the Arduino Uno) rather meagre code and data resources — so I'm not at all confident that after dropping in the Ethernet library, there'll be enough room left for everything else, and I'm certain it won't fit an NTP client on top. I'm fully expecting it'll fit the basic clock and temperature functions, but I may need to off-load the menu's with their settings — on the upside, since I never designed a buzzer into the PCB, I'll just have to implement the alarm by having a Raspberry Pi play an audio clip.
(… to be continued …)
I've done my non-Arduino Blinky, too, nice little (7)555 on a board, got me a taste of KiCad and SMT. Now it's time to resurrect my DeskClock project; this time, I'm planning to make it an Arduino shield, much the same as before, but with an actual real time clock module thrown in for bonus points. (Next version, I think, will be an all-in-one, maybe I'll add a buzzer there for an alarm option, maybe the external temperature sensor I was considering adding also, so many things…)
Now, onto the project. So I've got me that nice blue 4-digit 7-segment clock display, and a simple MAX7219 display driver. The driver's not really what I want, I want (at least) per-digit brightness, the 7219 only does global brightness, but it's what I've got, so I'm going to see if I can make it do what I want, see if I can flip the digits on and off quick enough to pretend. Though from an initial poke, I gotta say I'm a little dubious… Still, current step is to get the display running, then try it and see. But there appears to be a small problem, it seems my common-cathode display, mayhaps isn't. Started with a simple library and demo program on the Arduino, with just the MAX7219 and the display wired up, and nada. Well, not exactly nada, all the digits were on, all the time. Seems kind of obvious now, but after poking at it for a bit, and verifying that the program is spitting out the data it's supposed to be, I think my common-cathode display might actually be a common-anode one, or if I'm lucky, perhaps the documentation I found just has the anodes and cathodes backwards — I would have noticed that when I was building my clock the first time around, but I was just experimenting and playing with it at the time, and wasn't particularly keeping notes. (This is why project diaries are good — they save you from wasting time later on.)
(… later …)
Well, it turns out the display is indeed common-anode. Still, that wasn't going to stop me. A little confusing wiring, and some tricky coding to transpose the bits, and it's displaying digits just fine — little annoying I can't use the display trim to render just the four digits, but it works just fine. Added an RTC module (so it doesn't slip a minute a day like it used to), and stepped it up to two buttons this time, and it's been running quite happily on my shelf for the past couple months.
(… much later …)
Its RTC module is still holding time just fine, though it's hard to read the digits through the tangle of breadboard wires, so it's been sitting there running, but mostly neglected — the interface connected to those buttons is still mostly undone. Well, I've finally decided to push it along again. I've got a spare EtherTen board, and that clock has a temperature sensor stranded on the device and not available to my growing room automation system … I'm sure you know where that's leading.
However, that does change the plan a bit. I'm not quite to the point of designing PCB's with Ethernet just yet, so I've designed a PCB version of the circuit as an Arduino shield, parts and board (finally) ordered, just waiting for it all to arrive. It also raises a fresh problem; my prior little project, very quickly exhausted the ATmega328P's (the chip at the heard of the Arduino Uno) rather meagre code and data resources — so I'm not at all confident that after dropping in the Ethernet library, there'll be enough room left for everything else, and I'm certain it won't fit an NTP client on top. I'm fully expecting it'll fit the basic clock and temperature functions, but I may need to off-load the menu's with their settings — on the upside, since I never designed a buzzer into the PCB, I'll just have to implement the alarm by having a Raspberry Pi play an audio clip.
(… to be continued …)
Subscribe to:
Posts (Atom)