How to Know Where Your Pi Is (AKA – Configuring Static IPs)

If you’re using your Raspberry Pi as a server of some sort, it might be useful to give it a static IP address — you’ll probably be able to go without this for a long time (years, in my case!), but one day you’ll have a power outage, and when your router comes back up, you’ll find that… well, you’ll find that you can’t find anything!  This is where a static IP address can come in handy.


A few notes before we get started:

  • There are alternatives to using static IP’s that you might want to look into, including:
    • Not actually caring — DHCP-assigned IP addresses might be just fine for what you’re doing.  If other devices on your network aren’t referring to the IP address of your Pi, you probably don’t need to worry about it
    • Local DNS — if you’re savvy enough to run a local DNS server, you can refer to the Pi by name – i.e.,  This is certainly preferable to static IP’s, but not everyone will be equipped to do this
  • These instructions can change with the version of Raspian (or whatever OS) you’re running — the instructions below work on the Stretch version of Raspian
  • You’ll need to make sure whatever IP you assign is off limits in your DHCP server.  This is most likely going to be your router, and most routers have a way to set aside a range of IP’s that it will not hand out via DHCP – unfortunately, every router is configured differently, so you’ll need to figure that out first.
    • Warning:  Not doing this first means you’re running the risk of having two devices on the network with the same IP, which will cause…. problems.  Make sure you don’t skip this step!
  • Just in case you should be ready with a keyboard and a display – whenever you change the network configuration of your Pi, it’s possible that you’ll break it, leaving a direct login the only way of getting in!

Ready?  Ok, let’s go!

What You’ll Need

A few things you’ll need first:

  • A specific IP selected for your Pi that your DHCP server will not assign to another device (see above)
  • The ‘Interface Name’ of the network interface you plan to assign the static IP to — if you’re using Ethernet, this will likely start with ‘eth’, while your WiFi interface will likely start with ‘wlan’.
  • The IP address of your router
  • The IP address of the DNS server your Pi uses (probably the same as your router)
  • SSH access to your Pi

Let’s Do This!

For the purposes of these instructions, we’re going to assume the following:

  • Static IP address to assign:
  • Interface Name:  wlan0
  • IP address of our router:
  • IP address of our DNS Server:
  • Username and password for our Pi:  Yeah, sorry, no…

SSH into your Pi, and run:

sudo nano /etc/dhcpcd.conf

This file configures DHCP on our Pi, and toward the bottom you should find a section with an Example static IP configuration, and a few commented out lines.

Uncomment the lines, and configure them like so:

interface wlan0

static ip_address=

static routers=

static domain_name_servers=

Reboot the PI with sudo reboot, and verify that it worked – now all you need to do is update all of your other devices to point to your new-and-improved IP address!

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?


CDI and Declarative Transactions…

Ok, so since I’m already on the books for declaring that CDI/JSR-299 will become the dominant framework of the Java EE standards, while pushing EJB 3 off to the side, let’s start to figure out how this could work… I don’t think too many people would argue that the number one reason for using EJB 3.x Session beans are the Declarative Transaction support — that is, being able to create and commit a new Transaction around a method call by annotating it with @TransactionAttribute(TransactionAttributeType.REQUIRED) — and compared to the boilerplate code that needs to be put in place to do it programatically, it is indeed a pretty nice feature…

So how can this be done in CDI? Simple — with Interceptors… CDI actually reuses the interceptor support from EJB 3, but it takes it a step further — it allows you to use a custom annotation to bind your code to the interceptor definition in a pretty slick way… but first, consider the following interceptor, which might be the most basic implementation of Declarative Transactions:

//import removed...

@RequiredTx @Interceptor
public class RequiredTransactionInterceptor implements Serializable {
private UserTransaction utx;

public Object openIfNoTransaction(InvocationContext ic) throws Throwable {
boolean startedTransaction = false;
if(utx.getStatus() != Status.STATUS_ACTIVE) {
startedTransaction = true;

Object ret = null;
try {
ret = ic.proceed();

} catch(Throwable t) {

throw t;

return ret;

You’ll notice that most of this looks familiar — we’re not implementing any particular Interface, we can use any old name for our wrap-around method, we use the @AroundInvoke annotation to indicate which method is to be used for intercepting, and how it’s used, etc. The only thing new here comes on the first line — the dual annotations of @RequiredTx and @Interceptor… so far this is wicked easy!

So what the heck are those annotations? Well, the @Interceptor annotation is part of the javax.interceptor package, and was added as part of the CDI spec — clever how they snuck a new annotation in but didn’t put it under any CDI-specific package, eh?

The other annotation is one of my own, and when used in concert with @Interceptor, it acts as the ‘binding definition’ of the interceptor — you can then put the @RequiredTx annotation on any method or class of any CDI bean, and it will be as if you’ve annotated an EJB with ‘@Interceptors(RequiredTransactionInterceptor.class)’, only not as wordy (and why would you write a transactional interceptor that mimics the EJB usage, and then use it on an EJB?)

Without further ado, the definition of our annotation:

//more imports removed...

@Target({ElementType.METHOD, ElementType.TYPE})
public @interface RequiredTx {

Not much here — the only thing you may not have seen before is that InterceptorBinding annotation, which simply declares that this annotation is used to bind an interceptor to a method or class… simple — but how is it used? This is the cool part — just annotate any old CDI bean with this, and you’re good to go — like this:

//yep -- no imports here either...

public class UserGetterer {
public User loadUser() {
\\Do some fancy JPA loadin' here

Load that up in your webapp, point your fancy JSF 2.0 preRenderView event to “#{userGetterer.loadUser()}”, and voila — you are loading your data in a transaction… sweet!

Doh — almost forgot
What’s that? It didn’t work? Crap… oh wait, one last thing — we need to enable our interceptor… This part is easy to forget, but easy to do — you need to add an element to your beans.xml… (you did add the beans.xml file, right?)… try this:


Yeah, I know — it feels kind of like we’re exposing your implementation detail by asking the user to enable the interceptor instead of the annotation… kind of annoying, but I can deal with it… another thing to note is that if you pack your interceptors into a shareable library file, all other library files in your application will still need to do this, even if you enable it in your .jar file — that’s because there’s no concept of a global interceptor in CDI, but to be safe, each library is forced to enable all interceptors in use, so that they can enforce the ordering of interceptors in a very intuitive manner… I can accept this reasoning simply because they have defined it, rather than letting it be an undefined mess, so again, it’s more of annoyance for me — hopefully there will be other options in the future… (Note – due to a bug in the current version of Weld, Glassfish and JBoss will both have a problem with this — the work around at the moment is to include all of your definitions in one library file, or your .war file directly)

Sum It Up
So there you have it — a bare minimum implementation of Declarative Transaction support for CDI that can be applied to both classes or methods in less than 40 lines of code… easy, and very reusable! It would be similarly easy to implement for the other EJB TransactionAttributeTypes (SUPPORTS, REQUIRES_NEW, etc), although there is some coordination to be done to support putting one annotation on a class and another on a method without having them tripping over each other…

All in all, it provides a very straight forward programming model that is at least as clean as the EJB 3.0 model — cleaner in many ways, actually, as you’ll have @RequiredTx instead of @Interceptors(RequiredTransactionInterceptor.class), better context management with @RequestScoped, @SessionScoped and @ConversationScoped instead of just @Stateful, and much better integration with JSF… Plus, you’ll have the benefit of being able to customize it if you need to, adding support for things like timeouts, isolation levels, or custom logging… very nice, indeed!


CDI/JSR-299 preparing to marginalize EJB… again…

Whew, it’s been a while since I’ve started looking at what’s new in Java EE 6, partially because I’ve been fiddling with the newest addition to the Java EE portfolio — JSR-299, aka CDI, f/k/a Web Beans, and this one could be big… Let’s start with a bang — CDI will eventually push EJB to obscurity… yeah, big statement, I know, but here’s why I believe this will happen:

  • CDI has the potential, I believe, to provide all of the most commonly used services that the EJB spec provides, and let’s face it, this mean transactions, timers, asynchronous process with MDB’s, and now Singleton Startup beans. It does not mean remoting, instance pooling, and most certainly not any of the old CORBA crap 🙂 — also note that I’m not referring to JPA here at all, now that it has been removed from the EJB spec (as it should be!)
  • The CDI spec comes in at 98 pages.
  • The EJB 3.1 spec (PFD version), comes in at 618 pages — yikes!
  • The CDI spec is far more flexible than the EJB spec, allows for more interesting and transparent customizations, and is built specifically to support extensions.
  • CDI’s mechanisms for injection (which it inherits from JSR-330, thanks to Rod and Bob!), is more consistent, inclusive and unified than EJB’s/JEE 5’s.
  • CDI’s inclusion of Stereotypes provides an awesome mechanism to create a lightweight framework, without directly exposing any CDI api to the end user.
  • CDI’s context support is very extensive, and is far more complete and useful than EJB’s Stateless and Stateful beans. Plus, it finally gives us a standard between Request and Session scoped.
  • CDI’s integration with JSF is far better than EJB’s (ever had a manually remove a Managed Bean from scope because its’ Stateful bean has completed its’ lifecycle? Come on!).
  • CDI’s event mechanism provides for extensibility and easy, lightweight asynchronous processing.
  • There’s no such thing as CDI Lite 🙂

That’s not a short list, and admittedly, it’s very early to make claims like this… after all, the spec has just finally been approved, we have yet to fully see the quality of the implementations (three that I know about, Weld, CanDI and OpenWebBeans — hey, how come they got to keep the name!?), we have yet to see how the closed-source vendors will handle it, etc., but when it comes down to it, the CDI spec is simply better suited for POJO-style development, using Object Oriented core design principals, and it was designed specifically with this in mind… Contrast this with EJB, which has over a decade of cruft to carry along with it, and actually prevents the use of OO techniques altogether (historically more-so than today, but it’s still an issue), and I think the future becomes fairly clear… All-in-all, I see it as great news for the Java EE platform…

One final caveat, though — EJB has risen from the ashes before, specifically with the 3.0 version… if the vendors still feel the need to continue to push EJB, then who knows what we’ll see 🙂