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 Projects. Show all posts
Showing posts with label Projects. 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 …)
Sunday, 13 August 2017
I Made A Blinky! — Version 2
So, finally pulled together the pocket cash, and sent off my orders for the necessary bits and bobs.
The second revision of the board (which I introduced here) cost about $8.50 (US$6.50 + a crappy AU$ exchange rate), with some minor layout improvements, space for a push button (because taking the battery out all the time was getting to be a pain), I removed the positive copper fill on the battery side because I considered that a bad idea when the negative terminal of the battery is scraping over the solder mask on every insertion and removal, and a little piece of test art (the profile graphic I use here on this blog).
Removing the positive fill on the battery side I think was good, I had considered moving the negative fill to the back instead, since the negative terminal of the battery gets pressed against the board, but during insertion of the battery it's likely the positive terminal that does the scraping (since it wraps over and around the battery), so although it should be clear once inserted, there could potentially be an issue in the meantime. Just not having a copper fill on that side at all is, I think, the better choice. One big slip-up however, was my misreading of the shop description on the on/off switch I chose; I thought "on/off switch" meant press to turn on, press to turn off. No. It means (it appears) that the internals of the switch have a clicky mechanism that makes a nice solid on state when pressed, and a nice solid off when released, rather than the wishy-washy you get with carbonised rubber on PCB style buttons. Lesson learnt. It's also the minimum of what I need for this project, since that "switch" is simply sitting between the battery and the rest of the circuit — press it, the circuit has power, release it, it doesn't — so being a toggle (what I'd wanted), or a momentary action (what I got), at least the on/off part is right, plus the added bonus that the extra buttons will come in handy for other projects anyhow. Again, if this were a real project where it really mattered, acquiring some samples would have been on the cards, or finding someone who already knew, etc. — but this is pure learning experience ground, it was the first component footprint I've drawn up by hand, and it fit first go, so I still consider it a win.
Components for the board, namely the push buttons and SMT LED's (which I totally forgot to put in the order first time around, so the first board has a big ol' through-hole LED attached sideways), came to about $10 — mostly the push buttons, which were minimum 10 quantity, so I have plenty of spares!
But talking about those LED's, they're the most hideous things to solder! (Even worse than the capacitor.) One fell apart on me, the second one just would not sit straight while I soldered it, and then there's the whole issue of installing it in the right direction — just trying to figure out which end was the cathode was a nightmare in itself; a quick search on the web yielded several marking options, with the caveat that some manufacturers do it the other way around, so mostly useless anyhow. But even then, none of the markings I saw described were on the ones I'd bought, instead they just had a bevelled top edge on one end (and the notch that was suggested as a common marking, well, they had a notch kind of thing at both ends!). I'd tested the board by tacking down a regular LED again, so I knew the board worked, and figured if I could just hold the SMT LED to the pads, I should be able to determine it's orientation. But, that didn't work. Not entirely sure why, whether it just wasn't making contact, or whether my metallic tweezers I have were bridging the terminals, or what, but I couldn't get an indication that way. In the end, I just took a punt, and soldered it down. And after fighting to get that thing soldered down reasonably, it didn't work. Neither, did holding a regular LED over the ends, which seemed rather disturbing (had I accidentally damaged something else on the board?). So all I could do was take it off, and try again with a new LED, hoping that bevelled edge was, at least, the cathode. And it was, and it worked! I now had a working Blinky v2!!! New and (ever so slightly) improved (assuming you don't mind holding down the button)!
That wasn't the end of my purchases, though. Along with those $10 parts, was another $60 in extras, most notably a much needed flux pen, and one of those nifty "helping hands" gizmo's with the little gripper claws and an attached magnifying glass. Awful lot better than taping the board to the tabletop with double-sided tape, as I did the first time around — although next time I might still tape down the helping hands gizmo itself. There's also a lot of other very basic gear I still have to get, like cutters, non-metallic tweezers, a decent soldering iron… but I'll pluck that stuff off my wishlist with each successive purchasing round as I go along. The important part, is that progress was made!
The second revision of the board (which I introduced here) cost about $8.50 (US$6.50 + a crappy AU$ exchange rate), with some minor layout improvements, space for a push button (because taking the battery out all the time was getting to be a pain), I removed the positive copper fill on the battery side because I considered that a bad idea when the negative terminal of the battery is scraping over the solder mask on every insertion and removal, and a little piece of test art (the profile graphic I use here on this blog).
Removing the positive fill on the battery side I think was good, I had considered moving the negative fill to the back instead, since the negative terminal of the battery gets pressed against the board, but during insertion of the battery it's likely the positive terminal that does the scraping (since it wraps over and around the battery), so although it should be clear once inserted, there could potentially be an issue in the meantime. Just not having a copper fill on that side at all is, I think, the better choice. One big slip-up however, was my misreading of the shop description on the on/off switch I chose; I thought "on/off switch" meant press to turn on, press to turn off. No. It means (it appears) that the internals of the switch have a clicky mechanism that makes a nice solid on state when pressed, and a nice solid off when released, rather than the wishy-washy you get with carbonised rubber on PCB style buttons. Lesson learnt. It's also the minimum of what I need for this project, since that "switch" is simply sitting between the battery and the rest of the circuit — press it, the circuit has power, release it, it doesn't — so being a toggle (what I'd wanted), or a momentary action (what I got), at least the on/off part is right, plus the added bonus that the extra buttons will come in handy for other projects anyhow. Again, if this were a real project where it really mattered, acquiring some samples would have been on the cards, or finding someone who already knew, etc. — but this is pure learning experience ground, it was the first component footprint I've drawn up by hand, and it fit first go, so I still consider it a win.
Components for the board, namely the push buttons and SMT LED's (which I totally forgot to put in the order first time around, so the first board has a big ol' through-hole LED attached sideways), came to about $10 — mostly the push buttons, which were minimum 10 quantity, so I have plenty of spares!
But talking about those LED's, they're the most hideous things to solder! (Even worse than the capacitor.) One fell apart on me, the second one just would not sit straight while I soldered it, and then there's the whole issue of installing it in the right direction — just trying to figure out which end was the cathode was a nightmare in itself; a quick search on the web yielded several marking options, with the caveat that some manufacturers do it the other way around, so mostly useless anyhow. But even then, none of the markings I saw described were on the ones I'd bought, instead they just had a bevelled top edge on one end (and the notch that was suggested as a common marking, well, they had a notch kind of thing at both ends!). I'd tested the board by tacking down a regular LED again, so I knew the board worked, and figured if I could just hold the SMT LED to the pads, I should be able to determine it's orientation. But, that didn't work. Not entirely sure why, whether it just wasn't making contact, or whether my metallic tweezers I have were bridging the terminals, or what, but I couldn't get an indication that way. In the end, I just took a punt, and soldered it down. And after fighting to get that thing soldered down reasonably, it didn't work. Neither, did holding a regular LED over the ends, which seemed rather disturbing (had I accidentally damaged something else on the board?). So all I could do was take it off, and try again with a new LED, hoping that bevelled edge was, at least, the cathode. And it was, and it worked! I now had a working Blinky v2!!! New and (ever so slightly) improved (assuming you don't mind holding down the button)!
That wasn't the end of my purchases, though. Along with those $10 parts, was another $60 in extras, most notably a much needed flux pen, and one of those nifty "helping hands" gizmo's with the little gripper claws and an attached magnifying glass. Awful lot better than taping the board to the tabletop with double-sided tape, as I did the first time around — although next time I might still tape down the helping hands gizmo itself. There's also a lot of other very basic gear I still have to get, like cutters, non-metallic tweezers, a decent soldering iron… but I'll pluck that stuff off my wishlist with each successive purchasing round as I go along. The important part, is that progress was made!
Saturday, 27 May 2017
I Made A Blinky!
Okay, so, getting back to Electronics. I decided, last year, to try and dig my way back from the nothingness that's plagued me for over a decade.
A couple months ago I came across the free tutorial Getting To Blinky from Contextual Electronics. Now, I can't afford the fee's he's wanting for the classes, but he has been nice enough to release a few freebies here and there, and I've been wanting to learn KiCad for a while now, so this was perfect.
Following along with the tutorial, I drew up the circuit (making my own version of the 7555 schematic design along the way), flipped that over into the PCB designer (and making another footprint), had the boards made up by OSH Park (who doesn't love purple PCB's!!!), and watched the tutorial episode where Chris realised he goofed up and had to get medieval on the 7555. Thanks Chris. Anyhow… Ordered the components while I waited for the boards (and forgot the LED's), and then left it all sitting here in my desk for several months. Yeah, life, it happens, what can you do.
Then this morning I woke up absolutely determined to put the thing together. Pulled out my crappy cheap soldering iron, perched myself in front of the corner of our TV entertainment unit by the window, with the bits and pieces laid out in front of me; components, tweezers, scissors, solder, de-soldering braid, and my phone, with it's 4x camera zoom in place of a magnifying glass. No flux, no clamp for the board (used double-sided tape to hold it down instead), but it was enough. The solder joints look horrible, and I'm sure there's at least one or two on the IC that are only barely holding on, but after I was done, and I'd cleaned up the bits of packaging and put most of the stuff away, I pulled out a spare coin cell battery and threw it into the holder, and it blinked! To my utter astonishment, the darned thing actually worked! There it was merrily blinking away at me… I Made A Blinky!
So now I have a fully functioning Blinky. After over a decade of feeling like I need to get back into it but never quite getting there, I can't say that enough — as simple and small a start as it is, with so far yet to go to relearn what I've not used in so long, I'm happy. I've learnt to use KiCad (including making custom schematic components, and footprints), order the board through OSH Park, find and purchase the parts required, and managed to assemble it successfully with barely adequate gear (and SMT to boot). Most importantly, I've proven to myself that I can — and that little spark of confidence regained, is what Blinky was all about.
Where to now… Well, first, I'd fixed up the little mistake from the tutorial in the design files, right after having ordered the boards. So I think I'll order up a new set rather than persist with the nasty clipped IC leg hack I had to do with this one. That, and purchase some flux, decent tweezers, a 10x magnifying loupe to check the joints and read part numbers, a clamp to hold the board rather than the horrid double-sided tape, and a hands-free magnifying lens so I can actually see what I'm doing.
Beyond that, I think, it's back to my desk clock with better display driving, an RTC module, and some updates to the firmware I've been planning. Get that going on an Arduino prototyping shield, then off to OSH Park again (what can I say, I like purple!) for a single-board version.
A couple months ago I came across the free tutorial Getting To Blinky from Contextual Electronics. Now, I can't afford the fee's he's wanting for the classes, but he has been nice enough to release a few freebies here and there, and I've been wanting to learn KiCad for a while now, so this was perfect.
Following along with the tutorial, I drew up the circuit (making my own version of the 7555 schematic design along the way), flipped that over into the PCB designer (and making another footprint), had the boards made up by OSH Park (who doesn't love purple PCB's!!!), and watched the tutorial episode where Chris realised he goofed up and had to get medieval on the 7555. Thanks Chris. Anyhow… Ordered the components while I waited for the boards (and forgot the LED's), and then left it all sitting here in my desk for several months. Yeah, life, it happens, what can you do.
Then this morning I woke up absolutely determined to put the thing together. Pulled out my crappy cheap soldering iron, perched myself in front of the corner of our TV entertainment unit by the window, with the bits and pieces laid out in front of me; components, tweezers, scissors, solder, de-soldering braid, and my phone, with it's 4x camera zoom in place of a magnifying glass. No flux, no clamp for the board (used double-sided tape to hold it down instead), but it was enough. The solder joints look horrible, and I'm sure there's at least one or two on the IC that are only barely holding on, but after I was done, and I'd cleaned up the bits of packaging and put most of the stuff away, I pulled out a spare coin cell battery and threw it into the holder, and it blinked! To my utter astonishment, the darned thing actually worked! There it was merrily blinking away at me… I Made A Blinky!
So now I have a fully functioning Blinky. After over a decade of feeling like I need to get back into it but never quite getting there, I can't say that enough — as simple and small a start as it is, with so far yet to go to relearn what I've not used in so long, I'm happy. I've learnt to use KiCad (including making custom schematic components, and footprints), order the board through OSH Park, find and purchase the parts required, and managed to assemble it successfully with barely adequate gear (and SMT to boot). Most importantly, I've proven to myself that I can — and that little spark of confidence regained, is what Blinky was all about.
Where to now… Well, first, I'd fixed up the little mistake from the tutorial in the design files, right after having ordered the boards. So I think I'll order up a new set rather than persist with the nasty clipped IC leg hack I had to do with this one. That, and purchase some flux, decent tweezers, a 10x magnifying loupe to check the joints and read part numbers, a clamp to hold the board rather than the horrid double-sided tape, and a hands-free magnifying lens so I can actually see what I'm doing.
Beyond that, I think, it's back to my desk clock with better display driving, an RTC module, and some updates to the firmware I've been planning. Get that going on an Arduino prototyping shield, then off to OSH Park again (what can I say, I like purple!) for a single-board version.
Monday, 27 March 2017
The problem with personal projects…
I, I have to confess, tend to have a lot of unfinished or broken projects laying about.
I've done the odd bit of work for a friend, even a couple small projects by contract. It's a different issue when you're working for someone else — be it a free, or paid — where the goals are in support of someone else's endeavour, and the reward is the respect of a job well done (with appropriate emphasis on the word done), and a pay-day to back it up.
But when it comes to my own projects … the goal is typically more so to learn something. So I tend to find myself wondering along with only the most vague of plans, and reinventing a whole lot of wheels, partly simply to prove to myself that I can. Though, reinventing some of those wheels are not only about knowing how to do something, but how it actually works — it's one thing to stick a CSRF token in your web forms because your company policy tells you to, it's something else to understand what goes into that token and it's application, because you've implemented it yourself, and done the research into how and when it should (and should not) be used. The risk, of course, is that of having done it incorrectly — but in your own projects, aimed at personal consumption, that's usually a risk well worth taking. And besides, it's not like that same risk isn't there when using someone else's product to do the same job — the industry is littered with issues caused by flaws in well known and regarded standard implementations. Everything from long-standing bugs, brand new latest release bugs, through to intentional backdoors, and even the odd spot of governmental interference. Those implementations do, however, have the benefit of real life usage time, and hopefully the attention of a few experts … unlike your own pet wheel which has, well, you.
So now, while I consider it advantageous to reinvent all the wheels I can for the understanding it gives me — and I do exactly that in my own website, eschewing frameworks for nuts and bolts — there is a downside, too. I spend so much time working at the lower levels building up the foundations, or learning to work with some new tool or functionality, I often don't get to finish the project — usually, simply because it stops being fun, I've learnt what I wanted, something else caught my attention, and/or requires the injection of funds which are needed elsewhere — so it languishes on the hard drive forgotten and unloved for months (or years) at a time.
Of more recent note, I finally decided to put the time in to add a feature to one of my more functional coding projects — one which took me ages to get around to finishing just recently — tearing into it without bothering with the niceties of version control (or even making a backup of the script first – although I could hunt down a past version if I got desperate, thanks to the working folder being on Dropbox), and then didn't finish the update. So it's presently in a non-functional state, again. Well, was fun while it lasted… I used to use revision control regularly through University, and when my main PC was running Linux, keeping a log of changes, and all the rest. So I'm certainly no stranger to it all. I suppose it just doesn't seem quite so handy on the little bits and pieces I do these days, and doesn't seem to fit my Windows flow nearly as well.
In any case, my more recent projects:
I've done the odd bit of work for a friend, even a couple small projects by contract. It's a different issue when you're working for someone else — be it a free, or paid — where the goals are in support of someone else's endeavour, and the reward is the respect of a job well done (with appropriate emphasis on the word done), and a pay-day to back it up.
But when it comes to my own projects … the goal is typically more so to learn something. So I tend to find myself wondering along with only the most vague of plans, and reinventing a whole lot of wheels, partly simply to prove to myself that I can. Though, reinventing some of those wheels are not only about knowing how to do something, but how it actually works — it's one thing to stick a CSRF token in your web forms because your company policy tells you to, it's something else to understand what goes into that token and it's application, because you've implemented it yourself, and done the research into how and when it should (and should not) be used. The risk, of course, is that of having done it incorrectly — but in your own projects, aimed at personal consumption, that's usually a risk well worth taking. And besides, it's not like that same risk isn't there when using someone else's product to do the same job — the industry is littered with issues caused by flaws in well known and regarded standard implementations. Everything from long-standing bugs, brand new latest release bugs, through to intentional backdoors, and even the odd spot of governmental interference. Those implementations do, however, have the benefit of real life usage time, and hopefully the attention of a few experts … unlike your own pet wheel which has, well, you.
So now, while I consider it advantageous to reinvent all the wheels I can for the understanding it gives me — and I do exactly that in my own website, eschewing frameworks for nuts and bolts — there is a downside, too. I spend so much time working at the lower levels building up the foundations, or learning to work with some new tool or functionality, I often don't get to finish the project — usually, simply because it stops being fun, I've learnt what I wanted, something else caught my attention, and/or requires the injection of funds which are needed elsewhere — so it languishes on the hard drive forgotten and unloved for months (or years) at a time.
Of more recent note, I finally decided to put the time in to add a feature to one of my more functional coding projects — one which took me ages to get around to finishing just recently — tearing into it without bothering with the niceties of version control (or even making a backup of the script first – although I could hunt down a past version if I got desperate, thanks to the working folder being on Dropbox), and then didn't finish the update. So it's presently in a non-functional state, again. Well, was fun while it lasted… I used to use revision control regularly through University, and when my main PC was running Linux, keeping a log of changes, and all the rest. So I'm certainly no stranger to it all. I suppose it just doesn't seem quite so handy on the little bits and pieces I do these days, and doesn't seem to fit my Windows flow nearly as well.
In any case, my more recent projects:
- I have a desk clock that got broken over a year ago now, and I've not yet fixed (waiting mostly on the designing of revision 2) — this was working quite well for a time.
- A game I started building to learn OpenGL, but got distracted by building a — still unfinished — UI library (they're surprisingly complex little beasts).
- … and several more …
Arduino, my DeskClock, and a sprinkling of IoT to flavour…
Okay, so I said in my introductory post that I'm a fan of Arduino,
and hope to get back into that side of my hobbies… And though this
isn't the post I was planning to do as number two, I think it should be.
I went to University to learn Home Automation. Basically. Though I didn't realise it until I was already there. I was never into electronics enough to do the whole engineering route, with all that messy analogue stuff — I much preferred the nice clean and crisp digital life. Of course, that's not the reality of electronics, but hopefully you know what I mean. On the flip-side, while programming is definitely a hobby of mine, and I'm reasonably good at it (at least as good as a couple friends of mine who are actually in the industry), I don't enjoy the process as much as I wish I did. My first Arduino Blinky Light project, however, gave me that warm fuzzy glow of success I've been craving all these years! (Well, okay, maybe not quite that glowing, but it was a definite step in the right direction…) And I've gotten ahead of myself again…
During Year 12, my science teacher put a small stack of flyers for various University courses on a table while he talked to us about where we were planning on going next, at the end, he told us to all come and grab a couple of the flyers and have a look through them, see if there's anything we liked. He also picked up one flyer in particular, and handed it to me, specifically. Now this guy I used to call Mr Smiley, because he was always smiling. But this was one of the times when he seemed positively pleased with himself, and as I looked over the flyer, it just clicked. Embedded Systems. Controlling stuff with little computers. It was perfect. And that's what I applied to study.
As you can probably guess, I floundered a little bit on the analogue electronics, I was okay at it, and I passed, but I wasn't fantastic. Digital electronics, though, building up a basic processor from its fundamental components, writing its microcode, through to making it run a simple machine code program using that same microcode, now that was an experience to behold! (Better than sex, even! Sex is messy and awkward, especially on your first time, this was beautiful and clean! …ish…)
Anyhow, my plan was set… I wanted to finish Uni (I had hoped to do it at Uni, preferably as part of my honours year, and/or post-grad, but things didn't work out that way, and I quickly decided I was better off pursuing it later on…), get a job, buy myself a house (…like now), and deck the crap out of it with Home Automation. And not that media centre rubbish, but the real stuff — lights, doors, windows, blinds, aircon, the tea jug, fridge, ovan, washing machine, shower, toilet, you know… all the important things in life. I wanted it all under my control! (Insert evil laughter here.)
Well… As I think I said something about (or at least intended to) in my introductory post, that didn't quite go as planned either. In fact, it's a decade and a half later, and I've done a grand total of two Arduino projects: one blinky lights tutorial through to turning a simple servo, and a desk clock. I will say, it's a pretty snazzy little clock (and totally my own creation, unlike the blinky light); a single 4-digit 7-segment display (with dimming of selected characters — mostly non-edit characters during configuation, and the likes), an RGB LED (which was used purely as a quick temperature indicator), and a single lonesome push button to drive it all. And "it", in that context, was time (HH:MM, or :SS), temperature (in °C, °F, or °K - it had °R available too, if you were desperate enough to turn it on in the configuration, though there's only so much you can do with 7 segments, so I left it off by default), alarm (HH:MM), and a configuration menu (set the time, zero the seconds, set the alarm, set display brightness, select the order you want your temperature measurements to show in, that sort of thing, complete with little 7-segent animated icon things). Oh, and no buzzer — that was intended for version 2, along with improved display driving.
Now… In the meantime, I've been watching — and wincing — at the state of security and privacy in the IoT field, particularly with respect to Home Automation. All these gadgets, often sporting fairly potent processors, and bugger all security. Routers, thermostats, TV's, and all manner of other things being hacked and taken over, sometimes with the hack lying dormant for months, just gathering information by monitoring your network traffic, thermostats just waiting until you seem to have disappeared for a long weekend, or your new smart TV listening in on your conversations, for example. And as much as I love the Arduino platform, totally want to support Arduino and the fantastic job they're doing, especially love the MKR1000, I have to admit, I'm leaning a little more towards birds of a different feather… Sorry Massimo, you've done some awesome stuff, and you were the flag that renewed my interest anew, but you've kind of been left behind a little for me… (Not your fault, you're doing a whole lot of really good stuff that I whole heartedly encourage people to pay attention to, just not so much that swings my particular way, unfortunately.)
And so I finally get back to what I wanted to say… Right now, we seem to be on the cusp of something (well, one more something at any rate). The world has only just woken up to the fact that we need security in our IoT, we can't just assume that no one's going to hack our refrigerator or TV, because these things have cameras and/or microphones on them now, amongst other things, even our internet controlled light globes are spreading malware, and they're within the primary network defence perimeter that is, for most people, their internet modem/router. And we're starting to realise that even the innocuous thermostat stuck to the wall, might just be harbouring a secret foothold that's watching our behaviour, looking around to see what else it can sneak into, or trying to find an opportunity to slip some ransomware onto our computers, and we'd never know this was even happening because it's just a little device with a tiny screen (or maybe no screen at all!) and a couple buttons, that we barely even think about, and which just happens to be exposed on the internet, fetching weather forecasts or vaguely secured firmware updates with default passwords on its internet-facing configuration ports. Oh my…
Now, I'm not an expert in all that, there are people much better at talking about that than me, people whom I listen to myself to keep up to date on these things. So I'm going to get back to me… and as I sit here with my busted Arduino desk clock (the dogs got caught in the power cable and yanked my PC along with the clock sitting atop it all onto the floor one day, and the clock landed up on the bottom of the pile somehow), I can't help feeling a little disturbed trying to figure out how to best go about making sure version 2 has a bit of security as well — because you just know I'm going to want it to have a web interface of some kind. You see, the industry has only recently realised they need to make a move on the issue, and there seems to be a flurry of new products coming out. But as quickly as new products appear, new chips come along as well, and you want them because they have better hardware support, which means you won't be wasting battery power doing so much crypto gruntwork in software, and so forth. But it takes time for the Arduino's of the world to pick up and start using them in new products, and at the same time they're getting too advanced to hack together on a breadboard or a scrap of veroboard you have laying around, and unfortunately, I don't have a budget for buying any of these gadgets… at all. That is, after all, the primary thing that's kept me sliding time and again from electronics back to merely programming. Arduino allowed me to start making moves back into electronics, though I have to admit I often find myself feeling like a noob all over again. Luckily, this old dog does so enjoy the challenge of learning new tricks…
And then, when you do look at adding secure internet connectivity to your IoT device, to make that little light on the wall flash when you get a tweet, there's this huge disconnect. The internet is big, with protocols designed for computers, packet headers, even larger HTTP headers, and compression. Security is hard, with a ton of complex math, manipulating kilobyte keys and those data buffers again. That's lots of processing power, and storage buffers holding your keys and data… To securely turn a light on and off — a task that can be otherwise accomplished by a dinky little 8-bit µC that draws a few µW's of power at most, and less storage than a single good sized cryptography key. Which leads to HUB's. Now, if our IoT devices talk to HUBs, and it's the HUB that does the heavy lifting onto the internet. This works. Except the IoT device is probably using Wifi, that computer protocol that really should have security, which is now being provided only by your router again. And those HUBs — when they exist at all, because people don't want to buy yet another extra piece of hardware — are different for every company, so you need several of them, and each one has to be designed with proper security, because the malware doesn't care about branding! There's a whole world of further discussion just there…
But whether my next steps into the IoT is with the MKR1000, or a feather, one thing is certain… I for one won't be connecting an embedded development board direct to the internet, that doesn't have crypto. Just like it's no longer safe to put a PC online without the protection of both a firewall and a NAT router, it's not safe for an IoT device to go out and play among the intertubes without some serious crypto security, as those many many devices with token efforts at security (all too often, little more than the absolute minimum required to be able to use the relevant buzzwords on the packaging) are starting to discover — mostly at their customers expense.
I went to University to learn Home Automation. Basically. Though I didn't realise it until I was already there. I was never into electronics enough to do the whole engineering route, with all that messy analogue stuff — I much preferred the nice clean and crisp digital life. Of course, that's not the reality of electronics, but hopefully you know what I mean. On the flip-side, while programming is definitely a hobby of mine, and I'm reasonably good at it (at least as good as a couple friends of mine who are actually in the industry), I don't enjoy the process as much as I wish I did. My first Arduino Blinky Light project, however, gave me that warm fuzzy glow of success I've been craving all these years! (Well, okay, maybe not quite that glowing, but it was a definite step in the right direction…) And I've gotten ahead of myself again…
During Year 12, my science teacher put a small stack of flyers for various University courses on a table while he talked to us about where we were planning on going next, at the end, he told us to all come and grab a couple of the flyers and have a look through them, see if there's anything we liked. He also picked up one flyer in particular, and handed it to me, specifically. Now this guy I used to call Mr Smiley, because he was always smiling. But this was one of the times when he seemed positively pleased with himself, and as I looked over the flyer, it just clicked. Embedded Systems. Controlling stuff with little computers. It was perfect. And that's what I applied to study.
As you can probably guess, I floundered a little bit on the analogue electronics, I was okay at it, and I passed, but I wasn't fantastic. Digital electronics, though, building up a basic processor from its fundamental components, writing its microcode, through to making it run a simple machine code program using that same microcode, now that was an experience to behold! (Better than sex, even! Sex is messy and awkward, especially on your first time, this was beautiful and clean! …ish…)
Anyhow, my plan was set… I wanted to finish Uni (I had hoped to do it at Uni, preferably as part of my honours year, and/or post-grad, but things didn't work out that way, and I quickly decided I was better off pursuing it later on…), get a job, buy myself a house (…like now), and deck the crap out of it with Home Automation. And not that media centre rubbish, but the real stuff — lights, doors, windows, blinds, aircon, the tea jug, fridge, ovan, washing machine, shower, toilet, you know… all the important things in life. I wanted it all under my control! (Insert evil laughter here.)
Well… As I think I said something about (or at least intended to) in my introductory post, that didn't quite go as planned either. In fact, it's a decade and a half later, and I've done a grand total of two Arduino projects: one blinky lights tutorial through to turning a simple servo, and a desk clock. I will say, it's a pretty snazzy little clock (and totally my own creation, unlike the blinky light); a single 4-digit 7-segment display (with dimming of selected characters — mostly non-edit characters during configuation, and the likes), an RGB LED (which was used purely as a quick temperature indicator), and a single lonesome push button to drive it all. And "it", in that context, was time (HH:MM, or :SS), temperature (in °C, °F, or °K - it had °R available too, if you were desperate enough to turn it on in the configuration, though there's only so much you can do with 7 segments, so I left it off by default), alarm (HH:MM), and a configuration menu (set the time, zero the seconds, set the alarm, set display brightness, select the order you want your temperature measurements to show in, that sort of thing, complete with little 7-segent animated icon things). Oh, and no buzzer — that was intended for version 2, along with improved display driving.
Now… In the meantime, I've been watching — and wincing — at the state of security and privacy in the IoT field, particularly with respect to Home Automation. All these gadgets, often sporting fairly potent processors, and bugger all security. Routers, thermostats, TV's, and all manner of other things being hacked and taken over, sometimes with the hack lying dormant for months, just gathering information by monitoring your network traffic, thermostats just waiting until you seem to have disappeared for a long weekend, or your new smart TV listening in on your conversations, for example. And as much as I love the Arduino platform, totally want to support Arduino and the fantastic job they're doing, especially love the MKR1000, I have to admit, I'm leaning a little more towards birds of a different feather… Sorry Massimo, you've done some awesome stuff, and you were the flag that renewed my interest anew, but you've kind of been left behind a little for me… (Not your fault, you're doing a whole lot of really good stuff that I whole heartedly encourage people to pay attention to, just not so much that swings my particular way, unfortunately.)
And so I finally get back to what I wanted to say… Right now, we seem to be on the cusp of something (well, one more something at any rate). The world has only just woken up to the fact that we need security in our IoT, we can't just assume that no one's going to hack our refrigerator or TV, because these things have cameras and/or microphones on them now, amongst other things, even our internet controlled light globes are spreading malware, and they're within the primary network defence perimeter that is, for most people, their internet modem/router. And we're starting to realise that even the innocuous thermostat stuck to the wall, might just be harbouring a secret foothold that's watching our behaviour, looking around to see what else it can sneak into, or trying to find an opportunity to slip some ransomware onto our computers, and we'd never know this was even happening because it's just a little device with a tiny screen (or maybe no screen at all!) and a couple buttons, that we barely even think about, and which just happens to be exposed on the internet, fetching weather forecasts or vaguely secured firmware updates with default passwords on its internet-facing configuration ports. Oh my…
Now, I'm not an expert in all that, there are people much better at talking about that than me, people whom I listen to myself to keep up to date on these things. So I'm going to get back to me… and as I sit here with my busted Arduino desk clock (the dogs got caught in the power cable and yanked my PC along with the clock sitting atop it all onto the floor one day, and the clock landed up on the bottom of the pile somehow), I can't help feeling a little disturbed trying to figure out how to best go about making sure version 2 has a bit of security as well — because you just know I'm going to want it to have a web interface of some kind. You see, the industry has only recently realised they need to make a move on the issue, and there seems to be a flurry of new products coming out. But as quickly as new products appear, new chips come along as well, and you want them because they have better hardware support, which means you won't be wasting battery power doing so much crypto gruntwork in software, and so forth. But it takes time for the Arduino's of the world to pick up and start using them in new products, and at the same time they're getting too advanced to hack together on a breadboard or a scrap of veroboard you have laying around, and unfortunately, I don't have a budget for buying any of these gadgets… at all. That is, after all, the primary thing that's kept me sliding time and again from electronics back to merely programming. Arduino allowed me to start making moves back into electronics, though I have to admit I often find myself feeling like a noob all over again. Luckily, this old dog does so enjoy the challenge of learning new tricks…
And then, when you do look at adding secure internet connectivity to your IoT device, to make that little light on the wall flash when you get a tweet, there's this huge disconnect. The internet is big, with protocols designed for computers, packet headers, even larger HTTP headers, and compression. Security is hard, with a ton of complex math, manipulating kilobyte keys and those data buffers again. That's lots of processing power, and storage buffers holding your keys and data… To securely turn a light on and off — a task that can be otherwise accomplished by a dinky little 8-bit µC that draws a few µW's of power at most, and less storage than a single good sized cryptography key. Which leads to HUB's. Now, if our IoT devices talk to HUBs, and it's the HUB that does the heavy lifting onto the internet. This works. Except the IoT device is probably using Wifi, that computer protocol that really should have security, which is now being provided only by your router again. And those HUBs — when they exist at all, because people don't want to buy yet another extra piece of hardware — are different for every company, so you need several of them, and each one has to be designed with proper security, because the malware doesn't care about branding! There's a whole world of further discussion just there…
But whether my next steps into the IoT is with the MKR1000, or a feather, one thing is certain… I for one won't be connecting an embedded development board direct to the internet, that doesn't have crypto. Just like it's no longer safe to put a PC online without the protection of both a firewall and a NAT router, it's not safe for an IoT device to go out and play among the intertubes without some serious crypto security, as those many many devices with token efforts at security (all too often, little more than the absolute minimum required to be able to use the relevant buzzwords on the packaging) are starting to discover — mostly at their customers expense.
Subscribe to:
Posts (Atom)