BT_Sentry : OpenHAB

This is the 9th of my Blogs for the Bluetooth Unleashed Design Challenge

The other posts are here :-

Concept

The idea is to detect the bluetooth transmitted from the vehicle and signal other Home Automation functions.

If the vehicle is known then it can open the garage door, and inform the home owner that xx is home.

Hardware

The detection point needs to be at the start of the driveway, and because there is no power source, this will need to be low power with solar charging.

The PSOC range seems a very good fit, but because of the timeline and my need to upskill, the inital design will be Arduino based and some form of RF transmitter/transceiver.

Adding a vehicle detection loop or beam is necessary to ensure those vehicles without bluetooth will also trigger the system.

OpenHAB

This week I spent some time searching through my files that I used during the Forget Me Not Design Challenge

It became apparent that I failed to record some aspects of the setup.

It's still on an SD card somewhere ... but exactly where ??

I also become aware of how quickly I forgot everything I learnt about OpenHAB during the challenge.

Luckily fvan documented his setup.

[CaTS] ForgetMeNot - Week 4: Arduino-OpenHAB communication

Frederick was another contestant and he helped me, and others out during the challenge, and deservedly won.

While the general concepts are similar, OpenHAB has gone thru a few changes.

When we used it, there were some 'unpolished' aspects, and it seems that many of these have become 'polished' and hence easier to use.

I suggest landing here https://www.openhab.org/docs/ which will give a reasonable view of how it works.

I say reasonable because I downloaded it directly into the Raspberry Pi (see BT_Sentry : Software  ) but when I started it, and selected Standard, it wanted to go online and download various extras.

I had moved forward, and hence my Pi was offline on it's new network, and there was no feedback that it couldn't get the files.

Sadly the browser window just had this spinning circle thing, with no comments, hints or error messages.

I had to do some searching to find out that you could download the necessary .kar files and do it offline.

It is detailed here https://www.openhab.org/docs/installation/linux.html#manual-installation

My advice is to download the necessary files from here https://www.openhab.org/download/

https://bintray.com/openhab/mvn/download_file?file_path=org%2Fopenhab%2Fdistro%2Fopenhab%2F2.3.0%2Fopenhab-2.3.0.zip

https://bintray.com/openhab/mvn/download_file?file_path=org%2Fopenhab%2Fdistro%2Fopenhab-addons%2F2.3.0%2Fopenhab-addons…

https://bintray.com/openhab/mvn/download_file?file_path=org%2Fopenhab%2Fdistro%2Fopenhab-addons-legacy%2F2.3.0%2Fopenhab…

I grabbed the three files shown above, and copied them into the /tmp directory, then ran the commands below to extract them where they belong.

cd /tmp
sudo unzip openhab-download.zip -d /opt/openhab2
rm openhab-download.zip

Once installed you can run it by

sudo systemctl start openhab2.service
sudo systemctl status openhab2.service

sudo systemctl daemon-reload
sudo systemctl enable openhab2.service

As it says wait 15 minutes (or maybe sooner on the Raspberry Pi 3 B+)

If you browse to http://<raspberry pi address>:8080 then you should see this screen.

Happily this was much more than I had before.

Unfortunately my joy may be short lived, as I had issues with the spinning symbol when tryign to add some other addons.

I then had to backtrack and give the Raspberry Pi access to the internet.

OpenHAB - addons

There are differences depending on what version you've choosen (Simple, Standard, Expert, Demo)

I choose Standard, however I then downloaded the files, so I'm not 100% sure which one I have ....

In order to get serial data into OpenHAB (via the Raspberry Pi) we need to provide an opening.

I seems that on our new Hero Board (Raspberry Pi 3 B+), they stole the uart serial port for Bluetooth.

However a bit of seaching I found this post explaining it all.

https://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/

You need to enble it first

You'll need to reboot it

You should see an entry for Serial0 as shown above.

By modifying the /etc/default/openhab2 file, we can add the serial port as a EXTRA-JAVA_OPTS

EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0"

Rather than copying individual .jar files, it seems the "polishing" has made it a click and select option.

Under Paper UI (see picture further up) you select the add-ons you want. https://www.openhab.org/docs/tutorial/uis.html#the-paper-ui

It's still a WIP, but much easier than before.

I scrolled down until I found Serial and clicked install.

For OpenHAB to act on the data coming in the serial port, it needs to know what it is, so we add it under Bindings as a string.

String Arduino "Arduino [%s]" (arduino) {serial="/dev/ttyS0"}

Once we have the mechanism to receive, and the means to use the data, we need to know what to do with the information.

This is done in rules.

At this point I'm still finding my way around OpenHAB2, so until I do, it's a bit hit and miss.

However there are some aspects that will need attention, or at least understanding how they need to be configured.

Back in this update BT_Sentry : Data Transmission, I indicated you really need to plan what you're sending, and where it will get used.

Sending either the MAC address or all zeros, simplifies the message and logging.

Multiple MAC address'es are sent as second or third messages.

I've also decided that the battery voltage could be useful, so a three digit string representing the voltage should be allocated in the data structure.

Because OpenHAB is able to record and chart, I have decided that I can also send the temperature.

While it will increase the current consumption, it will provide a 'heartbeat' that gives me confidence it is still working.

So now the content of my data is:-  ID, Voltage, Temperature, MAC address.

I've indicated that I will be using the Moteino and an RFM69 Transceiver module. (similar to this below)

However the RFM69 library has limits   

https://github.com/LowPowerLab/RFM69

and it appears it you use encryption, then it is limited to 61 bytes each transmission.

Anyone that plays with coding will eventually find they have run out of memory, so this guide gives the size of the different variable types.

https://playground.arduino.cc/Code/DatatypePractices

So we have the content, but we also need the structure.

Sometimes the encapsulation/overhead of data becomes greater than the actual content, so the full structure is necessary to ensure we stay within the limits.

//struct for wireless data transmission  
typedef struct {    
  int             NodeID;         //node ID (1x, 2x, 3x);  1x = Misc, 2x = Inside, 3x = outside  
  int             DeviceID;       //sensor ID (2, 3, 4, 5)  
  unsigned long   Uptime;           //uptime in ms  
  float           Batt_volt;      // Battery voltage 
  float           Temp;           // Temperature   (note this is the Temp plus 20 to get it past negative values)
  String          MAC;            // MAC address
 } Payload;

The Node ID and ID is simply in case I decide to incorporate more sensors around the place, and it will mean I can filter the incoming data easily.

While I was checking the library constraints, it occurred to me that adding 20 to the temperature reading got me out of negative values, without going past 99.99 degC.

My calculation of the data size is :-

  int             NodeID;             // 2 bytes 
  int             deviceID;           // 2 bytes
  unsigned long   Uptime;               // 4 bytes
  float           Batt_volt;          // 4 bytes
  float           Temp;               // 4 bytes
  string          MAC;                // 12 bytes

Total   28 bytes

So I'm well within the 61 byte limit.

As you can see NodeID, DeviceID and Time are encapsulation/overhead and add 8 bytes

As I said earlier, each MAC address will be treated as a seperate message, so while I could add more than one MAC, it's not worth it to detect the 5 or 6 known cars that I need to detect.

The receiver sketch will format the data into a message that we can split in the rule, and then use it appropriately.

Luckily all the pins I want are next to each other. (5v, Gnd, Rx, Tx)

So a simple 4 pin plug at the RPi end, and 4 connections on the Moteino end allows me to connect them together.

Time

While I'm writing this, I'm also looking at my list of things to complete.

The individual components are more or less sorted, although some require the final enclosure.

I'm not exactly where I want to be, but with my added delays and days stolen, it is where I'm at.

What is concerning me is gluing it all together.

In my head, this bit does this, and passes the data to here, and this bit does that with it. .... etc.

That might be okay as a concept, but it isn't going to work in the real world, so I need to start sorting out the glue for joining it together.

It's lucky that I've taken a few days off and hopefully I can glue it all together next week.

In the meantime it is time to publish this blog, and get cracking with the glue.

Mark