Should Controlling the Smart Home be all about Voice?

Let’s face it, controlling your Smart Home can be awkward.  In it’s current state, it depends far too much on either your phone or your voice, and while I love that I can use either to control portions of my home, walking into a dark room and needing to pull my phone from my pocket to turn on the lights the ‘right way’ should probably be considered a step backward, not forward.

Voice is clearly the current trend — mainly because it is flippin’ cool — but I don’t think it’s the ultimate solution.  If my spouse is sleeping when I tip toe into the room, and I want to turn my lamp on to 5% brightness, I sure as hell don’t want to talk to Siri or Alexa.


Which is why my hands-down favorite thing from CES 2018 is the Nanoleaf Remote.  The remote is an amazing display of the creativity that can be applied to control your smart home, and while it’s obviously focused around the Nanoleaf Light Panels – the huge, triangular panels that can be assembled into custom configurations, and glow to any color you can imagine – it’s also a HomeKit controller.  This means that you can assign a ‘side’ to any HomeKit scene, like ‘Wake Up’, ‘Dinner Time’, or ‘Take Out The Garbage’ (you do have a scene for that, right?)

Practically Speaking

I’ll admit that a gigantic 12 sided die might not be a practical home controller for every house, and I’d be hard pressed to find a use for all 12 sides in more than one or two rooms, but this is the kind of product that we needed – this should spark the imagination of companies and (more importantly!) makers everywhere.  It’s now ok to think outside the box when it comes to controlling your home.  Light switches?  Meh, if we have to.  Motion detection?  Sure, in some cases it’s great, but it’s not perfect.

I’m much more interested in imagining how every day objects could start to control our homes.  Have a globe in your office?  Spin it to change make the room brighter.  Want to watch a movie with the family?  Put a model of an old fashioned popcorn machine on the table to trigger your Movie Night scene.  Have a kid who’s a dance fanatic?  Let her change the color of her room’s lighting by hanging up the matching color ballet shoes.

There is an opportunity here to not only make our homes smarter, but to make them more ‘us’ — without needing to train our guests on the proper way to turn off a light.  I, for one, hope more companies take a page out of Nanoleaf’s book, and start to imagine the possibilities — but also that more ‘makers’, and DIY smart home enthusiasts start to really think outside the box, and figure out what would make their home really theirs.

Where has the current crop of smart home controls failed you?  How would you like to control your smart home, if given the opportunity?  I want to know!


Installing Node.js on your Raspberry Pi

Node.js is a common and powerful server environment for JavaScript, and is handy to be able to work with for just about any Raspberry Pi project — it’s also one of those libraries that often requires multiple Google searches to remember how to get it installed, so I’ve consolidated my steps down to a single page.  Hopefully, you’ll only need one search next time!  (and hopefully I’ll remember that I wrote this, so I won’t need any!)

  • Install Node.js – you might have a node installation on your Pi already, but chances are it’s not the one you want.  Instead, grab a fresh one:
    • curl -sL | sudo bash -
    • sudo apt-get install nodejs
    • Verify this worked with node -v and npm -v (as of this writing, I get 9.4.0 and 5.6.0, respectively)
  • Install the Yarn dependency manager, which we’ll use to run our app:
  • Install a few handy packages using apt-get – you might not need these, but I find them necessary for many of my projects
    • sudo apt-get update
    • sudo apt-get install build-essential libavahi-compat-libdnssd-dev git

That’s it – easy, when you have everything in place!

What does your Raspberry Pi do, and how secure is it?

I’ve been tinkering lately.  What that usually means for me, is that a Raspberry Pi or two get pulled out of the drawer, I spend a little time figuring out what the hell I last did with it, and then I start hooking up some wires, led’s, or other randomness to make it blink.

Lately, though, my tinkering has resulted in what I expect to be a permanent addition to my home automation suite (more details later – this article isn’t about that).  This means a few things:  always on, network connected, and home connected.  And here be dragons.

What Can That Thing Do?

Being connected to your home and a network at the same time changes the game – occasionally using your Pi to power an AirPlay speaker or a media library is vastly different than hooking it up to your garage door, door lock, or a security camera. It’s now a potential window into your habits, how you live your life, and could even be used to determine whether you’re home or not – this is all data worth protecting, and paying attention to the security implications of that inexpensive little computer is important.

While Linux is generally considered a secure platform, that security depends on a knowledgable administrator.  When was the last time you checked for OS updates on your PI?  Did you install the updates made available after the recent KRACK WiFi vulnerability was discovered?  Hell, do you still login with the ‘pi’/’raspberry’ default password???

If you have a Pi that’s plugged in all the time acting as a server or a home automation bridge, it’s time to pay attention.

What Do I Need To Do???

Because the Raspberry Pi is a general computing device, there’s no single answer – you’ll need to make some decisions on your own.  Assuming, however, that you’re running a standard Raspian distribution, the following are some things to keep in mind.

Start with Advice from the Source

The Raspberry Pi Foundation itself publishes guidelines on security.  Read it – there’s good stuff here that is all relatively straight forward.

Change your Blasted Password!

This one should be dead obvious, but with Raspbian configured to load straight to the desktop without requiring a login, it’s easy to forget what’s going on behind the scenes.  If someone does manage to gain access to your network, it’s dead simple to write a script that will attempt to ssh pi@<every-ip-address-it-finds> using the default password!

Don’t use the Default Account

The default account is well known – every fresh distribution of Raspian includes it, making it an easy target, even if you do change the password.  After you get rid of the default password, create a new user, and use that one from then on. does indicate that Raspian does depend on the ‘pi’ user to exist, but unfortunately doesn’t explain for what purpose – depending on your needs, it’s worth attempting to delete the user, but be prepared to recreate it if you find that your device is no longer operating.

Keys, Keys, Keys

If you have SSH enabled, you should be using key-based authentication to access your Pi, eliminating the password as a potential attack vector.  This will eliminate any attack vector that doesn’t include an attacker gaining access to your private key, meaning that they first need to access your home computer (you haven’t posted your private key on the Internet anywhere, have you?)

The page listed above has a good overview of how to do this – if you’re new to it, however, it can get a bit technical and confusing, so repeat after me.  “Before touching anything in my ~/.ssh folder, I will read up on what these files mean.”  Said it?  Ok, good – now I fully expect that you won’t accidentally send your private key to a server instead of your public key.  That’s a no-no.

And of course, if you don’t need SSH, then turn it of – one less potential security hole to be concerned with.

Services Available

What services have you added to the PI?  Is there a web server running?  Do you ever send a password to one of these service?  Are you positive that the password isn’t sent in plain text?

This one is all up to you, but knowing what services you’ve installed that may be available to the network, and protecting them appropriately is critical.  Use HTTPS for your web servers.  Install a firewall if you need to.  Do it!

If this Pi has been sitting in the drawer for a while, running the same instance of the OS that you installed with your last project, then it’s worth starting fresh – grab the latest version of Raspbian (the Lite version, if you can), and put it onto the SD card. This way there’s no chance for you to forget about whatever it is you left I stalled on it from last year.

Awesome Capabilities Deserve Security

There are some truly incredible projects that you can put together using the Raspberry Pi, taking your computing skills to the next level, however don’t overlook the security ramifications involved! A little knowledge and attention to detail can help save you time and frustration later!

Getting your Raspberry PI on the Network

Got a new Raspberry Pi 3 or Zero W, complete with WiFi support, but need to get it on the network?  It’s easy — just repeat after me (well, on the PI, that is):

  • Find your nearest keyboard, display, and power supply, and fire that sucker up
  • Type sudo nano /etc/wpa_supplicant/wpa_supplicant.conf
  • Go to the bottom of the file, and add:


ssid=”<your network SSID>”

psk=”<your network password>”


  • Save the file with CTRL-X, followed by Y
  • Type sudo reboot


Bonus Tip:  Having trouble typing those quotes?  Chances are you’re not in the UK — run sudo raspi-config, go into the Localisation Options, and change your keyboard layout (along with timezone, and anything else that’s relevant to your location)

Hmm, this place is sort of familiar…

Wow, it’s been a while – I’ve got a lot of cleaning up to do, but you might just see me start to put some thoughts here again.  It’s been seven or eight years since I’ve done any writing, so I’ll call this all experimental, but I’ve got a few thoughts wrapped up in my head that I might be able to yank out.  What will it looks like?  Who knows – one thing I will say is that it likely won’t be about any upcoming Java standard like my older posts – I had actually forgotten that I used to pay that much attention to that crap :).

Stick around, see what happens, and make sure to leave me a note – it’s always good to know what my audience looks like (I.e. – is there one!? 🙂 )


Java EE 6 – Who’s In?

Been a while since I’ve written anything, so I’ll ease into the waters with this one – it’s been over a year since Java EE 6 was released with some very cool updates that I’ve discussed here and here and here and here and here and here and here and here and here and here and here (dang, I was busy!). So I’m interested in hearing what kind of adoption it’s gotten so far. Anybody?

Now, I know that there still aren’t a lot of servers that support it — let’s see, there’s Glassfish, and then there’s… hmmm… well, I think Resin 4 has been released… JBoss 6 isn’t quite there yet, nor are any of the more expensive products, at least not to my knowledge (I’ll be perfectly honest – I don’t pay much attention to them!)

One that interests me is SIwpas – it’s a Web Profile implementation based on Tomcat, and apparently several other open source products, although I fear it suffers from AAS (Awful Acronym Syndrome!). But the question is, is anyone using it, or the other products? I’d love to know!


BTW – the last time I blogged about JBoss not having a server released after an extended period of time, they released it the very next day – if I were a bettin’ man, I’d put money on JBoss 6 going final tomorrow, but since I’m not, and since no one releases software on a Saturday, I’ll have to go with a firm guess that’ll be out soon!

Thoughts on JSR 330

I’m not sure what to think about JSR-330 — what do you think?

A quick caveat before I begin — I’m playing devils advocate here, so I have no idea if I believe any of the gibberish that I’m about to write 🙂

On one hand, I think it’s Mostly Harmless… CDI/JSR-299 is obviously the default implementation of the spec, and perhaps having a very small portion of the DI capability abstracted so that we have the choice to use another framework if we want isn’t necessarily a bad thing (even if standardizing injection targets isn’t exactly ground breaking value) — after all, if it weren’t for those ‘outside’ framework writers, we might not have gotten EJB 3, and all the improvements that came along with Java EE 5… perhaps JSR 330 is a way to bring those folks inside of the Java EE fold, so it’s not another three years before the standards catch up with the private innovation

On the other hand, is it at all likely that an application would be able to just replace the DI capability of CDI with, say, Spring or Guice, but still use the contexts, interceptors, extensions, etc? After all, Dependency Injection is actually a pretty small part of what the CDI spec provides… Perhaps, if one were to write a CDI Portable Extension that basically vetos all bean discovery, and instead uses one of the other libraries to do the injection, but that seems like a stretch to me…

What seems more likely is that another implementation would simply not use CDI, which can easily be done by not providing a beans.xml file, and using some other mechanism, like the Spring WebApplicationContext — in that case, is there value in what the JSR-330 spec provides? Has the addition of this spec, which provides little value in-and-of itself incorporated too much confusion?

My original instinct was that it’s a good addition to the Java EE fold, but I’ve heard a few voices of opposition (including from those who don’t have a big stake in the outcome)… now I think, perhaps, that I could take it or leave it — I haven’t been convinced that it’s destructive, but I’m also not convinced that it’s worth it 🙂

What do y’all think?