Getting Bludit Working with Lighttpd

Lighttpd is one of the lightweight web servers that is fairly easy to install and get running.  I like it because it seems secure and the configuration files are straight forward and easy to understand.  One drawback is that there doesn't seem to be much support as Nginx and Apache are the more recognized and supported web servers.

If you've stumbled upon this, you are probably looking for a way to get your Bludit install working properly with Lighttpd.  The solution was fairly simple;  There have been a few forum posts and other support posts I found, but all of them seemed to vary just a little and nothing seemed to work properly.  So here is one more solution that will hopefully help.

$HTTP["host"] =~ "(^|\.)YOURSITE.COM$" {
   server.document-root = "/srv/http/location/",
    url.rewrite-once = ( ".*\.(php|txt|json)$" => "/" ),
    url.rewrite-if-not-file  = ( ".*\?(.*)" => "/index.php?$1", "." => "/index.php" )

The highlighted sections are the only things you will have to change.  This is assuming that your configuration is configured properly.

Getting Thing in Order

I am currently getting things in order.   Wordpress wasn't cutting it so I am trying to something new;  A flat file approach with no database.  I will be converting the SQL database from the old site soon, so my content should be online in the near future. 

OpenHab2 Rules to Control Roku

One of the most recent features I've discovered with OpenHab2 is its ability to execute shell commands. With this ability, you can easily send commands to Roku. If you don't know, Roku can be issued commands via HTTP (using their External Control Protocol). So, if you'd like to open apps, hit play/pause or go home, you can simply use curl or wget to issue these commands. You can control this by adding these commands to a rule that corresponds to a switch item. If you make these items "Switchable", then you can control them via Google Assistant.

I had to do a little more work with Google routines so that I could trigger these switches with various different commands. This allows a more natural conversation.

In order to get this working, you need to create the Items and the Rules.

The /etc/openhab2/items/home.items should include these switches. (If you would like to expand your list, just add the switches here.)

Switch          roku_home               "Roku Home"             ["Switchable"]
Switch          roku_playPause          "Roku PlayPause"        ["Switchable"]
Switch          roku_netflix            "Roku Netflix"          ["Switchable"]
Switch          roku_plex               "Roku Plex"             ["Switchable"]
Switch          roku_hbo                "Roku HBO"              ["Switchable"]
Switch          roku_amazon             "Roku Amazon"           ["Switchable"]
Switch          roku_hulu               "Roku Hulu"             ["Switchable"]

At the bottom of your /etc/openhab2/rules/home.rules file, add these rules. Make sure they correspond with the appropriate Item or you will have random things opening.

rule "Roku On"
                Item    roku_home       received command ON
                executeCommandLine("curl -d ''")

rule "Roku PlayPause"
                Item roku_playPause     received command ON
                executeCommandLine("curl -d ''")

rule "Roku Netflix"
                Item roku_netflix       received command ON
                executeCommandLine("curl -d ''")

rule "Roku Amazon"
                Item roku_amazon        received command ON
                executeCommandLine("curl -d ''")

rule "Roku Plex"
                Item roku_plex  received command ON
                executeCommandLine("curl -d ''")

rule "Roku Hulu"
                Item roku_hulu  received command ON
                executeCommandLine("curl -d ''")

rule "Roku HBO"
                Item roku_hbo   received command ON
                executeCommandLine("curl -d ''")

For the list of links, there are two ways to obtain the app ID that you are trying to launch; You can either return the information with curl or wget, or just trust the internet. As stated on Roku's ECP documentation, using the following curl command in a shell will render the app ID. (note: the id attribute that corresponds to the app Title. id 12 is Netflix).

$ curl
<app id="12" type="appl" version="4.1.218">Netflix</app>

The last thing I did was make this easier for me to talk to Google. If you have the Google Home app installed on any of your devices, then you can create routines. Custom routines allow you to add custom commands that trigger events. Below are some screenshots of example routines that I've created. You will have to make sure all of the applicable Google Home/Assistant setup and integrations are in place to utilize this feature. Setting up Google Assistant is a fairly simple process; follow these instructions.

After you've completed this, then you just need to ask Google to "sync my devices" and you are all set. I'd restart the Openhab service to make sure that all changes stick.

Home Automation with OpenHab2 on Arch Linux

Home Assistant is a great automation system for some features, but after a while, it left me wanting more.  Additionally, with all of the updates, I felt like the HA team was really putting a focus on the implementation of Raspberry Pi's and not a "traditional" computer.  While customizations were nice, they left a lot to be desired.

So, I set out to find another solution that would conform to my wants in home automation.  Openhab was really the only other solution.  A great benefit to Openhab was the app interface on Android and iOS and the security.  Additionally, there isn't a charge for "cloud" functionality.

The installation was fairly simple;

$ yaourt -S openhab2

Everything seemed to be set up out of the box and OpenHab documentation was very easy to follow along. Most of the configuration files are located in /etc/openhab2/ and are pretty easy to understand.

There are two basic elements that capture objects within your automation network; Items and Things. Then you have Rules and Sitemaps. Rules are self-explanatory and provide specific automation triggers based on events that occur. Sitemaps are how you display your items (switches, toggles, sliders, etc). The last thing is Bindings which is OpenHab's method of connecting and communicating with devices. For instance, if you want to have support for Samsung TV's, then you would add the samsungtv binding. There are various ways of enabling your things, but the best way I have found is to enable that binding in /etc/openhab2/services/addon.cfg. Things typically won't work until the binding has been enabled.

binding = chromecast, exec, network, ntp, samsungtv, systeminfo, weather1, astro

Things are the actual devices that you want to use, for instance, smart bulbs, smart plugs, televisions, weather sites, astrological tracking, etc. Think of the stuff you purchase. (more here)

Items are the digital version of things and where all of the automation happens. You place items into your sitemaps so that you can manually control your things. If your smart TV is the "thing" then your associated items are the volume, power, input, etc. (more here)

Here are some basic configurations for things and items that are associated with each other.


Thing  tplinksmarthome:hs103:dining_f_lamp "Dining Room Floor Lamp"    @ "First Floor"     [ ipAddress="" ]


Switch     dining_f_lamp   "Dining Room Floor Lamp"        <light>       (devices, lights, diningRoom)   ["Switchable"]  {channel="tplinksmarthome:hs103:dining_f_lamp:switch"}

Looking at the -thing- first, the binding is "tplinksmarthome", the device type is "hs103" and the name is "dining_f_lamp". I have given a digestible name of "Dining Room Floor Lamp" to make it easier to incorporate with Google. After the @ sign, is the location and the ipAddress is pretty self-explanatory.

Now, looking at the Item, I have declared a switch that aligns with the thing. I have mirrored the label name (which is in " "), added it as a light for the icon (which is in < >) and also added it to groups ( which is in ( )). The switchable tag ( in [ ]) makes it viewable by Google so that I can control it with Google Home. Lastly, I have created a binding channel that encapsulates and associates the Item to the Thing as a switch.

The last piece to cover is the Sitemaps. In order to control this new switch in the app of the web interface, you need to add a sitemap and frame to list your items.

sitemap home label="Home" {
    Frame label="Quick Light Controls" {
        Switch  item=dining_f_lamp  label="Dining Room Lamp"

The sitemap is pretty straight forward. One thing to keep in mind, all of your configs must have the same name as sitemap in order to work properly. For instance;
- home.items
- home.things
- home.rules
- home.sitemap
All of these will be part of the initial sitemap labeled "home".

The frame will visually bundle your items together so that you can keep things organized and clean. And, as you can see, the Switch added is the dining_f_lamp (item) and it has a label.

In a nutshell, the configuration is very simple yet leaves room for growth and complexity where needed. In another post, I will start going over astronomical tracking for sunrise and sunset tracking and weather patterns. These two are perfect for the automation aspect.

Subnet Cheat-Sheet

Using the cheat-sheet has really helped cut back on the binary conversion for subnetting. I work in a unique environment where people deal with subnetting all of the time and one of my colleagues showed me a simple way to calculate IP ranges and subnets by using this. It seems like a lot at first, but once you use it a few times, it really becomes simple and makes sense.


      128   192   224   240   248   252   254   255  (Subnet)
      128    64    32    16    8     4     2     1   (Binary)
1 A    1     2     3     4     5     6     7     8   <------
2 B    9    10    11    12    13    14    15    16   CIDR
3 C    17   18    19    20    21    22    23    24
4 D    25   26    27    28    29    30    31    32

So, if I was to look at a random address:

In order to use the chart above, I first have to look at the CIDR.  Find the corresponding top number from the CIDR area in the sheet above.  Since it's /26, it's in the last row, so that tells you it's a D class network.  Following the same logic, find the top number and it's 192.  So this means that your subnet is

Now that you have the subnet, look at the second row.  The value is 64 (which is what you get when you follow /26 up to the second row).  That tells you that your network ranges count by 64.  So, you look see what range the provided address is in... the last octet is .4, so it falls within 0-63 (which is 64 numbers).  Now you have your first two numbers... 0 and 63.  That is the Network Address and the Broadcast.

Finding the range is the easy part... just add one to the Network address and subtract one from the broadcast.  That is 1-62.

So, is a host address within the following:

N (Network Address) -

F (First Host) -

L (Last Host) -

B (Broadcast)

Again, hopefully, this doesn't confuse anyone more than it helps.  Once you practice this a few times, it really starts to make better sense.

Subnetting IPv4... I think

Until recently, I didn't really grasp the importance or relevance of subnetting.  After reading this week's chapter, and watching some videos on YouTube, I realized how it works now and I have a larger understanding of how the IP is restricted based on the subnet (or at least I think I do).  

I had always assumed that the subnet was "another" IP address that you could create many networks from within.  But after this chapter, it has made it more clear to me that the subnet is more of a "locking" mechanism for network addressing.

I get the binary approach, in fact, breaking binary has always been easy for me, it was just the application to subnetting that was confusing.  I think the easiest way for me to remember this now is that the subnet locks the other digits so that your ranges are better defined...

My example is a home network:

IP Address or 


The /27 denotes subnet is locked at 27 characters, so

11111111.11111111.11111111.11100000 or

lining them up helped me determine a few things:

11000000.10101000.00000001.001 00000  (ip)
11111111.11111111.11111111.111 00000  (subnet)

Everything to the left of the break can't change because of the subnet.  So, to find the basic information like network address and broadcast address is as simple as finding the top range and bottom range of the IP. 

Since, in this case, the first 3 digits can't change in the last octet, the address, you just have to work the numbers that can change:

00100000 (or .32) = Network address

00111111 (or .64) = Broadcast address

That would leave you with through for usable addresses.