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/
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
Top Comments