HOME AUTOMATION: OpenHAB2 Serial Binding on Raspberry Pi

I have always wanted to enable my home automation setup with per-room presence detection. With this in mind I purchased and installed an ELK/NESS home alarm with automation capability.

I haven't been able to find any decent OpenHAB binding for the alarm, and after recently giving up on getting my M1XEP serial to network box for my alarm working I've decided to try my hand at rolling my own serial solution. Here I'll discuss how I got the serial configuration up and running.

Installation

Install the binding from the configuration GUI

I'm using a USB to Serial adapter, but other serial devices should also show up as serial devices if they have been recognised by the kernel. You can check this with the command:

 dmesg  

Or to view messages relating to the serial port configuration use the command:

 dmesg | grep tty

This should tell you what port was assigned to your USB to Serial adapter, in my case ttyUSB0

Check which users have access to the serial port with the command:

 ll /dev/ttyUSB0  

Output should look something like:

 crw-rw---- 1 root dialout 188, 0 Mar 27 10:03 /dev/ttyUSB0  

You may need to add the default user to the dialout group:

 sudo adduser openhabian dialout  

It's a good time to check the serial connection to make sure it's working as expected. You can use the GNU screen command to view the serial port from the command line:

 screen /dev/ttyUSB0 115200  

The screen command won't exit with the typical commands like CTRL-X or CRTL-Z, to exit the screen command enter 'CTRL-a' then press '\', then hit 'Y' to exit the screen.

Now that we have the binding installed and confirmed the serial port is working as expected we can continue with the OpenHAB setup

OpenHAB2 Configuration 

I created and 'alarm.items' file to store alarm related configuration info:

 Switch AlarmUpdate "Alarm Update" { serial="/dev/ttyUSB0@115200" }  
 String AlarmMessage "Alarm Message" { serial="/dev/ttyUSB0@115200" }  

and a 'alarm.rules' file with the following:

 ule "Interpret Alarm Command"  
 when  
     Item AlarmMessage received update  
 then  
     logDebug("alarm", "Alarm message updated")  
 end  
   

Check everything is working with the command:

 tail -f /var/log/openhab2/openhab.log -f /var/log/openhab2/events.log  

And you should see log messages like the following:

 2017-03-27 12:08:27.946 [ItemStateChangedEvent   ] - AlarmMessage changed from 0AZC007200C9  
 1EAS000000001111111100000000000E  
 0CAM000000007F  
  to 16XK2708212270117011006C  

Now that the serial binding is working we can move on to interpreting the data!

HOME AUTOMATION: MiLight/LimitlessLED/Easybulb OpenHAB Configuration

I've been thinking about wireless lighting control for a while now and tested out the space with the MiLight wireless controlled light bulbs.

My initial use case was focused around bulb dimming and while I realise I could have achieved this with a simple dimmer switch costing around 20 bucks from Bunnings, the cost of hiring an Electrician to come to wire a single switch would easily run be over $100. I know some people take to doing this themselves but you need to remember this is illegal in Australia.

The Research

The majority of my house is fitted with modern downlights that use the GU10 socket. This is a pretty common fitting type so the number of options is quite large. Here are a few of the options I considered:

• MiLight/LimitlessLED/Easybulb - 15USD and around 10USD for a bridge
• Phillips Hue - 4 wireless bulbs and a bridge at $399 or $89 per bulb
• LiFX GU10 WiFi bulbs - 4 wireless downlights at $120 or $40 per bulb

As my main use case was brightness control I went for the MiLight bulbs that I bought from the LimitlessLED website.

While the cheapest, the MiLight bulbs have downside of no publishing their state when the lights are turned on.

This may not sound like a big deal, but after having used the bulbs in my home automation setup I can say that this limitation is quite annoying as there is no easy way to manage the state of the bulbs in your home automation setup. Unless you can see the lights left on you don't really know what state they are in, so the only useful feature when you are away is the blanket "All Off". It's not the worst but it's definitely not ideal.

The MiLight bulbs are not Wi-Fi, they use the a 2.4GHz wireless protocol that requires a Wi-Fi bridge to connect it to your home network. There are a few limitations with these Wi-Fi bridges and some folks have developed their own bridges that overcome these limitations, but I'm going to be sticking with the standard as the OpenHAB MiLight binding has been designed to work with this device.

Setting Up Your MiLight Bridge

Follow the MiLight instructions to set up your bridge to control the bulb groups in your house using the Android or iOS apps. Here are a few tips:

• If you are using the Android app I've noticed it works much better on an old phone in airplane mode. The app experience on Android Nougat is horrible
• Make sure you assign a static IP for your Wi-Fi bridge on your router
• Once you have taught the bridge your light groups make a note so your don't forget which group was associated with each channel of the bridge
• Each bridge can only control 4 groups of WW/CW and 4 groups of RGB/W bulbs
• Each bridge has an "All Off" channel. Think about how many bridges you might want to make this function useful. In my setup I have 1 bridge per floor.

MiLight Wi-Fi Bridge with OpenHAB

I follow these steps to get my MiLight bulbs set up with my OpenHAB installation:

• Navigate to the PaperUI page of your OpenHAB installation to configure you devices

PaperUI Configuration

• Install the MiLight add-on 

MiLight Add-on

• Navigate to the inbox and search for new devices
• At this point you will see a number of devices listed under the MiLight services in the inbox 
• 4 channels of WW/CW
• 4 channels of RGB/W
• 1 channel of WW/CW all off
• 1 channel of RGB/W all off 

MiLight Bridge Channel

Now we need to add the devices be previously taught the Wi-Fi bridge in the setup step. This is done by clicking the check icon on the device we want to add, then follow the steps to add the device.

I followed the advice in the OpenHAB instructions and set the system to enable "Item Linking" to make the addition of Things easier.

Item Linking configuration

Once you have added the devices you plan to use the next thing to do is check they are working as expected via the configuration panel.

Testing Things in configuration panel

If your device's aren't working at this point you'll need to go back to the bridge setup step and make sure everything is working there. 

OpenHAB .items Configuration

With the devices now added as Things in your OpenHAB installation we need to add the bulbs as a .items file to get them running with our user interface.
Navigate to the items folder of the OpenHAB installation folder and create a new .items file:

 cd /etc/openhab2/items/  
 sudo nano lights.items  

Here we will add the devices we wish to use with our user interface. The MiLight binding gives some examples of how to configure the devices, but for quick reference this is how it's done.

• Get the unique ID of the device you want to add from the Things banner of the Configuration panel. You need to click the Thing and view the available channels

Click the Thing you want to add to the .items file

Copy the channel you want to use

• Add the ID to the item and give it a unique name. Here is an example:

 Switch Light_GF_Laundry_OnOff        {channel="milight:whiteLed:ACCF23508A5A:1:ledbrightness"}
 Switch Light_GF_Laundry_NightMode    {channel="milight:whiteLed:ACCF23508A5A:1:lednightmode"}
 Dimmer Light_GF_Laundry_Temperature  {channel="milight:whiteLed:ACCF23508A5A:1:ledtemperature"}
 Dimmer Light_GF_Laundry_Brightness   {channel="milight:whiteLed:ACCF23508A5A:1:ledbrightness"}

• Repeat this process for all the devices you want to add, then move on to the sitemap

Note: the MiLight binding does not expose and on/off state for the bulbs, rather you need to define a switch for the brightness to control the on/off and a dimmer for the brightness adjustment both using the same channel

OpenHAB Sitemap Configuration

With the devices added to your items file now we can add them to your sitemap. This is the file that outlays the user interface for user interaction with the OpenHAB setup.

Navigate to the OpenHAB installation directory and then to the sitemap directory. If you are coming from a fresh installation you probably won't have anything in here other than a readme.txt file so you will also need to create a default.sitemap file.

 cd /etc/openhab2/sitemaps/  
 sudo nano default.sitemap  

We will start with a basic working sitemap to test the functions of the devices we just added.

 sitemap default label="Test Layout" {  
     Frame label="Laundry" {  
         Switch item=Light_GF_Laundry_OnOff label="On/Off"  
         Slider item=Light_GF_Laundry_Brightness label="Brightness"  
         Switch item=Light_GF_Laundry_NightMode label="Night Mode"  
     }  
 }  

And here is the output:

HOME AUTOMATION: Teptron move control from Linux

UPDATE: this method does not appear to work with the latest Teptron Move firmware. The developer of csrmesh is looking in to the problem but there is no current solution for controlling the Teptron Move from anything other than the app.

My biggest pain point with the Teptron Move automated blinds device at the moment is the lack of app updates and any functionality other than just simply commanding the blinds from my phone. Because of this I have basically removed the devices from my blinds. You can read more about my issues with the device in an old post.

I recently started to think about how I could potentially expose the CSR bluetooth mesh that the Move uses to my wireless network. This would allow me to get the automation I'm looking for out of my OpenHAB controller. I came across a project on GitHub claiming to have reverse engineered the CSRMesh protocol for the Teptron Move and decided to give it a shot.

I did a little more digging and found some posts on the domoticz forums talking about how to integrate the linux script with the domoticz home automation solution to automated the Move units, so I decided to investigate the possibility of integrating the devices with my OpenHAB system.

Installing The Script

Git is not installed on the Ubuntu image for the Pine64. Install with the following commands:

 apt-get install git  

If it's the first time using git on your machine you need to:

• Generate an rsa key 
• Follow the Github instructions to add the rsa key to you github account

I also found this article useful to debug my problem.

If you don't follow these steps you will get the error:

 Permission denied (publickey).  
 fatal: Could not read from remote repository.  

Now create a new directory clone the csrmesh repository into that directory:

 mkdir Downloads  
 cd Downloads  
 git clone git@github.com:nkaminski/csrmesh.git  

Build and install the project:

 python setup.py build  
 sudo python setup.py install  

The script also needs the bluez software installed:

 sudo apt-get installed bluez  

If you are trouble getting your bluetooth running on an Raspberry Pi 3 with OpenHABian I have explained how I did it in an older post.

Bluetooth Setup

If your device doesn't support Bluetooth natively you will need to do some work with a USB Bluetooth adapter to get connected  to the Move units.

Insert the USB adapter in to the Pine64 and run the following command to check the device was recognised:

 dmesg  

 If the device was recognised by the linux kernel you should see an output something like this

 [449253.083342] input: Logitech Logitech BT Mini-Receiver as /devices/soc.0/1c1b000.ohci1-controller/usb4/4-1/4-1.2/4-1.2:1.0/input/input5  
 [449253.083769] hid-generic 0003:046D:C71B.0001: input: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-sunxi-ohci-1.2/input0  
 [449253.159418] usb 4-1.3: new full-speed USB device number 4 using sunxi-ohci  
 [449253.303636] input: Logitech Logitech BT Mini-Receiver as /devices/soc.0/1c1b000.ohci1-controller/usb4/4-1/4-1.3/4-1.3:1.0/input/input6  
 [449253.304398] hid-generic 0003:046D:C71C.0002: input,hiddev0: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-sunxi-ohci-1.3/input0  
 [449253.581549] usb 4-1.1: new full-speed USB device number 5 using sunxi-ohci  
 [449253.750067] usbcore: registered new interface driver btusb  
 [449253.875233] Bluetooth: BNEP (Ethernet Emulation) ver 1.3  
 [449253.875245] Bluetooth: BNEP filters: protocol multicast  
 [449253.875282] Bluetooth: BNEP socket layer initialized  
 [470188.654809] sunxi-bt bt.28: set block: 0  
 [470188.654971] sunxi-bt bt.28: check bluetooth io_regulator voltage: 1800000  
 [470193.118153] sunxi-bt bt.28: block state already is 0  

We can now run one of the bluez commands to check if the bluetooth adapter was recognised and is available for us:

 hcitool dev  

If everything is in order with your setup you should see an output like the one below and you can continue on to the next section:

 ubuntu@pine64:~$ hcitool dev  
 Devices:  
     hci0  00:1F:20:51:CC:AA  

If you don't see any devices listed then you will have to do some work to enable the Bluetooth adapter. You should have a utility installed called rfkill that is used to enable and disable wireless devices. If it's not installed you can install it with the command:

 sudo apt-get install rfkill  

Run the following command to see your connection status:

 ubuntu@pine64:~$ rfkill list  
 0: sunxi-bt: Bluetooth  
     Soft blocked: Yes  
     Hard blocked: no  
 1: phy0: Wireless LAN  
     Soft blocked: no  
     Hard blocked: no  
 2: phy1: Wireless LAN  
     Soft blocked: no  
     Hard blocked: no  
 3: hci0: Bluetooth  
     Soft blocked: Yes  
     Hard blocked: no  

The following command will remove the soft block on the Bluetooth adapter:

 sudo rfkill unblock bluetooth  

Now run the "rfkill list" command again and you should see the soft block has been removed.

Success! The Bluetooth output has been enabled and we should be able to see available Bluetooth devices if we run the hcitool dev command again. We can confirm the device is working by scanning for available Bluetooth devices:

 hcitool scan  

The above command will scan for regular Bluetooth devices but will not be able to to see Low Energy (BLE) devices. In order to scan the available BLE devices we need to run the command:

 sudo hcitool lescan

Testing The Script

Typically we would do a hcitool scan to get a devices MAC address, but the csrmesh network doesn't allow us to do this (at least in my setup). I've connected to the CSRMesh network from my Windows laptop and used that connection to gather the device address to include in the script.
The address I grabbed from my PC was: BTHLE\Dev_43c55b040006

The Github documentation tells us to format the command in the following way:

 ./bin/csrmesh-cli move --pin 8888 --dest 43:c5:5b:04:00:06 --objid 1 --position 255  

You need to make sure you are running this command from within the csrmesh folder that was cloned earlier. If everything worked you should see your Move unit move to the set position and the output:

 Running: gatttool -b 43:c5:5b:04:00:06 --char-write-req -a 0x0021 -n 0fe2bd00809bb9d83b76b48585673a77b747ff  
 Characteristic value was written successfully  

Note: The only gotcha here is the pin for the Move units. Here you will need to remember the password you set to the CSRMesh network when you first set up your move unit. If like me you have forgotten this, perform a factory reset on the unit by removing the battery, hold down the stop key then re-insert the battery. The notification light on the bottom of the device should be on solid. Keep holding the stop key for at least 5 seconds at which point the device should be reset. In my experience you don't get any feedback that it has performed the reset. With the device having been factory reset you can restart the Android app and enter a new password.

The next step here is to now enable the device for use with OpenHAB.


UPDATE:
I've written a post on how to get this script working with openHAB here

HOME AUTOMATION: OpenHAB2 on the Raspberry Pi 3

After spending a bunch of time messing with the Pine64 getting it up and running and installing OpenHAB2, I accidentally unplugged power while the device was on and it caused my installation to no longer boot :-( This is not the first time some minor error has cause my device to stop booting but it's going to be the last, I'm moving to a Rapsberry Pi 3.

While the Raspberry Pi is not immune to this type of issue, I already use a Raspberry Pi 1 and have lost power while the system is up over 100 times and I've only ever corrupted one SD card over the last four years. I realise this is not something I can guarantee, but the Pine64 has been nothing but a hassle since it was delivered.

Installing OpenHAB2

Instead of going through the pain of a manual install and configuration of OpenHAB like I had to with my Pine64 I've decided to go with OpenHABian. This image is supposed to be a self configuring installation of OpenHAB on the Raspberry Pi.

As usual I didn't bother to read the instructions and so decided that something must be wrong with the installation when it didn't respond to SSH connection request after I turned it on. I found out the hard way that it takes around 45 minutes for first boot! Not what I was expecting. Once I let it run through the first boot procedure I was able to SSH in with:
    username: openhabian
    password: openhabian

Once the image has booted for the first time I ran the script:

 sudo openhabian-config  

From here I installed all of the packages required for OpenHAB, including OpenHAB2!

OpenHABian on the RPi 3

Bluetooth

By default the bluetooth does not work on the OpenHABian minimal installation, if you try to scan for bluetooth adapters you will get errors like "no default adapter".

I was able to enable the bluetooth on the Raspberry Pi 3 doing the following:

 openhabian@openHABianPi:~$ sudo apt-get install bluetooth bluez blueman  
 openhabian@openHABianPi:~$ sudo reboot  
 openhabian@openHABianPi:~$ hcitool dev  
 Devices:  
     hci0  B8:27:EB:15:64:58  

HOME AUTOMATION: OpenHAB2 on the Pine64

I "bought" a Pine64 Pro with a WiFi/Bluetooth adapter on Kickstarter that I had originally planned to use as the home automation server to replace my RPi 1, but I was never really committed to the installation as the early builds for the Pine64 were pretty unstable.

Things have developed and become more stable since then and with the recent release of OpenHAB2 it seemed like the right time to jump back in.

Installation

I tried a few different builds to get the Bluetooth adapter working with no luck, there seem to be a lot of people complaining about the lack of support for the Bluetooth device on the forums. Because of that I decided to just stick with the most stable build of Linux for the Pine64, which at the time of writing is the Ubuntu image, and use a USB Bluetooth adapter if I needed to integrate Bluetooth in to my OpenHAB installation.

It's worth noting that there is an OpenHAB image for the Pine64 but I was never able to get this to boot so I abandoned it and started with a Ubuntu image.

I downloaded and unzipped the image using 7zip and used Win32 Disk Imager to write the image to the SD card.

I plugged my device into the internet via ethernet for first boot so I could SSH in without having to set up the WiFi network.
Login to your router and find the IP address of your Pine64. Alternatively you could use an app for your phone like Fing Network Discovery Tool to find the device IP address.

I use Putty to SSH in to my devices from my Windows machine. It's a nice little tool that allows a few different connection types including SSH and Serial and ability to save sessions for frequently used devices.
While there is no location for a username you can add one to the saved session by typing the username in to the host name box as follows:

 ubuntu@192.168.1.151  

PuTTY Saved Session

The default password for the Ubuntu image is 'ubuntu'.


Reboot your device with the command:

 sudo shutdown -r now  

Install Java with the following commands:

 echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu xenial main" | sudo tee /etc/apt/sources.list.d/webupd8team-java.list  
 echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu xenial main" | sudo tee -a /etc/apt/sources.list.d/webupd8team-java.list  
 sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys EEA14886  
 sudo apt-get update  
 sudo apt-get install oracle-java8-installer oracle-java8-set-default  

Now that Java is installed we can install the OpenHAB2 official release:

 wget -qO - 'https://bintray.com/user/downloadSubjectPublicKey?username=openhab' | sudo apt-key add -  
 echo 'deb http://dl.bintray.com/openhab/apt-repo2 stable main' | sudo tee /etc/apt/sources.list.d/openhab2.list  
 sudo apt-get update  
 sudo apt-get install openhab2  

Start OpenHAB and add it to startup with the following commands:

 sudo systemctl start openhab2.service  
 sudo systemctl status openhab2.service  
 sudo systemctl daemon-reload  
 sudo systemctl enable openhab2.service  

If everything installed and started correctly you should be able to navigate to the page:

 http://YOUR.DEVICE.IP:8080  

From here you should be able to follow the beginners guide to get your device going.

If you get stuck and need to work out what is happening with you OpenHAB installation you can view the log file with this command:

 tail -f /var/log/openhab2/openhab.log -f /var/log/openhab2/events.log  

HOME AUTOMATION: Mounting network storage device on Raspberry Pi

I run a NAS storage device to serve up media content as well as a place to backup photos and videos.
I've found it really handy to be able to connect to my network storage from my Raspberry Pi but it took me a while to work out the right configuration for my setup. Here are the steps I followed:

Raspberry Pi 1 Configuration:

Install the cifs-utils package. This is the package we need to connect the the network drive

 sudo apt-get install cifs-utils  

Make a directory where you would like to mount the network storage:

 sudo mkdir /home/pi/NAS  

We are going to use two files to do the network drive mounting, the first file will store the network drive and mounting information and the second will hold the login credentials information:

1. /etc/fstab - network drive information
2. /root/.servercred - hidden file with network credential information

The cifs-utils package creates a file named fstab that holds the network drive information.
Edit the fstab file and add the network location and password:

 sudo nano /etc/fstab  

To begin with you file should look something like this:

 proc           /proc      proc  defaults         0    0  
 /dev/mmcblk0p1 /boot      vfat  defaults         0    2  
 /dev/mmcblk0p2 /          ext4  defaults,noatime 0    1  
 # a swapfile is not a swap partition, so no using swapon|off from here on, use dphys-swapfile swap[on|off] for that  

Add the following line to the bottom of the fstab file:

 proc           /proc      proc  defaults         0    0  
 /dev/mmcblk0p1 /boot      vfat  defaults         0    2  
 /dev/mmcblk0p2 /          ext4  defaults,noatime 0    1  
 # a swapfile is not a swap partition, so no using swapon|off from here on, use dphys-swapfile swap[on|off] for that  
   
 //192.168.1.100/ /home/pi/NAS cifs credentials=/root/.servercred,sec=ntlmv2,iocharset=utf8,file_mode=0777,dir_mode=0777 0  

Hit ctrl-x to exit nano, then type y and hit enter to save the file.
Now we need to create the server credential information:

 sudo nano /root/.servercred  

Add your username and password to this file (including network homegroup)

 username=KLIMOVSKI\andrew  
 password=1234abcd  

If you get the error "sudo: nano: command not found" the you will need to install nano:

 sudo apt-get install nano  

Finally, attempt to mount the network drive by typing:

 sudo mount -a  

If everything worked the command should execute and you should not see any output. You can now test the network drive by navigating to the directory we created earlier.