This is the summary 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.
Progress
When I started on this Challenge I was aware that I'd lose one week to a pre-planned vacation, and made allowances.
I prepared the content and set the publish time for while I was away.
I had one other pre-arranged appointment that took a few days away from the challenge as well.
I managed to gain one day back by typing up the content while sitting in a motel room with limited other things to do.
However I ran into a change in personal circumstances shortly after that, and things went downhill.
I had restrictions as to what I could do and lost a day each week and a few hours each day that I could have put into it.
Gateway
I have the hardware configured and have tested the ability to detect the Bluetooth.
BT_Sentry : Bluetooth Sniffing
Strangely this post also cost me three days due to a bug in Jive and the three images being linked rather than a lot of 1's and 0's.
It seems the post got promoted on Google + https://plus.google.com/+element14/posts/bkPN36E7kBo
which was rather nice ... right up until my personal website got suspended for exceeding the 20GB bandwidth by 498%
Eventually we managed to tame it, but it ended up at 136GB data 
Needless to say a new Hosting service, and a few days lost to tracing and fixing the issue, was not in my plans.
The microwave units finally arrived and while these weren't exactly a show stopper they do need testing to see they work as expected.
Because I wasn't there to test them, I wasn't able to sort out a suitable enclosure that doesn't look out of place, or more correctly .... that isn't desirable or suspicious looking.
Longer term I'd like to see if there is the ability to shape the pattern, but that will take a bit of planning and experimenting.
These do seem like a very useful device and could easily replace a PIR for many projects.
Long term the ability to power this is a combination of solar and wind, and I discovered a simple method that should work.
This approach requires a bit more Engineering as the motor is not waterproof.
However the load is such that it shouldn't overheat, so restricting the airflow shouldn't shorten the life due to thermal issues, but will help with the environmental ones.
The ideal solution is to use the PSOC http://www.cypress.com/documentation/development-kitsboards/s6sae101a00sa1002-solar-powered-iot-device-kit
But as I indicated the time to become familiar with PSOC Software wasn't there for this challenge, and I decided before embarking on this to not go down that road.
I believe that it would suit ver 2.0, and it will provide the extra push to get familiar with the PSOC software and the great range of boards on offer.
Indoor notification
When I started on the challenge, I never really had a firm idea of what shape the Indoor Notification unit might take.
I thought something will spring to mind and if not I can always use a Raspberry Pi 3 B+ and touchscreen.
As it progressed, the single unit approach wasn't going to make the cut.
Some of the other Design Challenges and Project14 posts, used ESP8266 in other roles, and I was particularly interested in ntewinkel temperature sender.
Remote (Water) Temperature Monitoring
I could see that this would suit one of my other projects that have been waiting for a biblical flood (I've gone past waiting for a rainy day)
I found a great second use as a clock.
By combining this clock with the detection of a MQTT message, I could have something that was useful and served as an indicator.
The design and low cost allowed multiple units to be deployed.
It also was a possibility for the Door Controller and Outdoor Lights.
Adding a simple relay to one of the GPIO would allow the use of a MQTT message rather than the hassle of NodeRED and reconfiguring a Sonof device.
Unfortunately this took several days to sort out the Broker issues.
BT_Sentry : Connecting to MQTT Broker
I'm happy to say that I do have it working as I want, and I have one more minor tweak (amount of time it stays showing a visitor is there) before I post the final code.
I intend to do that as a seperate blog to make it easier to find for anyone replicating or using it.
I will also do a post for the Door/Light controller using MQTT to provide something someone else can use.
Cyclops
This is my hero board, the Raspberry Pi 3 B+ and is the heart of the operation.
It receives the RF signal from the gateway and then triggers the events required.
Effectively it glues all the pieces together, but at the moment it is nothing more than a couple of containers, waiting to be mixed.
This details the install process, and the differences I had when trying to reference back to the earlier version of OpenHAB.
Hopefully it has made it a little easier for someone wanting to install it.
This details the UV4L which will eventually capture the images.
It's a useful program and has very little lag, and a lot of other features.
The concept is to time stamp the camera images when a known BT MAC address has not been detected.
I have installed these packages and adjusted the settings to stop fighting over the same port.
I still have to adjust the Mosquitto listening port as OpenHAB mqttt is also trying to offer a broker on port 1883.
The glue will be some scripts or settings to interface between the gateway and triggering the image (UV4L).
Both software processes require a bit of work, which could be something between a couple of days and a week.
It is likely that a python script or some rules in openhab2 will glue it together.
I also need to add a microwave detector for visitors exiting the property.
I did indicate that this time around I'd like to better understand OpenHAB to make it more useful longer term.
Having a visitor monitoring system is fine, but why not include some of the other things as well.
So temperature, electric fence, water pump, wind, rain and others are possible enhancements.
The housing is also causing me some grief.
I planned to use an LED light similar to this
However it seems these have gone out of fashion and the latest offerings are the COB style LEDs.
which don't offer the same size or ability to modify to hide the camera.
So I might need to rethink the housing.
Night time is not the issue, as the lights coming on will make it difficult to see.
It's Daytime and something really obvious facing anyone coming down the drive that prompted me to consider the multi LED style light.
In the end a simple black box on the side of the garage may be enough.
Smartphone
My original plans included the ability to send a notification to a smartphone.
In my application, SMS ( text message) was going to be the only solution because we don't have data turned on with our smartphones.
Sadly our phone companies have made that uneconomic, and worse, block it from other countries.
Because the systems I looked at are so different, outlining a method isn't appropriate.
I have seen the odd Design Challenge where a web page was scraped to collect the data, and it may be that this could be used for some service providers rather than an API.
It would also be interesting to see if the Arduino GSM boards could be reconfigured as suggested by ntewinkel
Failure
I don't consider I've failed in this Challenge.
It's certainly not complete. 
I do want to finish but my available time going forward is limited due to other committments, so I can't say when it will be finished.
What I hope is that I've provided enough information for someone to replicate the design and use it for their own purposes.
There are people around here wanting to use BT sniffing to combat some of the crimes being committed using drones to preview properties.
They hope that they can detect the MAC address to provide evidence later.
As we've found out, BLE and the old BT aren't exactly compatible, and there are numerous methods to encourage the 'victim device' to give up it's secrets.
The work on the ESP8266 has helped me to make a few other projects much easier, and some of these will be used to add to OpenHAB.
It's easy to sit here and say "If only I had more time", but this was a relatively short Design Challenge, and the best plans do go south sometimes.
It is what it is, and hindsight is a wonderful thing, but D-Day is here, and this is where my Challenge proposal sits.
Time
These challenges are a huge committment in time.
Trying to work fulltime and then find several hours per day to complete these is taxing on anyone.
In some cases these sorts of projects would never get done in the commercial environment, so for the Challengers to get where they are today speaks about the commttment.
I had some hard thinking before applying for this particular challenge, but it provided the extra push I needed to get some of the other parts off the ground.
As I indicated early on, having something to detect visitors had always been a desire, but the traditional breaking beam/current loop concept just wasn't going to work here.
Using BT to suppliment that was the catalyst to getting involved.
I have appreciated the interest and comments by others following this Challenge.
It has helped to support my decison to get involved, and the suggestions and discussions were very useful.
To Randall and the other element14 staff, thanks for the faith in the application.
I'm sorry the final delivery isn't complete, but as a concept I believe I have proven it will work.
Thanks
Mark
Top Comments