This is the 3rd of my Blogs for the Bluetooth Unleashed Design Challenge
The other posts are here :-
| Link to other posts |
|---|
| BT_Sentry Introduction |
| BT_Sentry : Zero Emission Detection |
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.
Data
According to Wikipedia the term data has been around since 1640.
https://en.wikipedia.org/wiki/Data
The first English use of the word "data" is from the 1640s.
Using the word "data" to mean "transmittable and storable computer information" was first done in 1946. The expression "data processing" was first used in 1954.[4]
The Latin word data is the plural of datum, "(thing) given," neuter past participle of dare "to give".[4] Data may be used as a plural noun in this sense, with some writers -- usually scientific writers -- in the 20th century using datum in the singular and data for plural. However, in non-specialist, everyday writing, "data" is most commonly used in the singular, as a mass noun (like "information", "sand" or "rain").[5]
I'm fairly confident that they weren't using computers, microcontrollers or anything remotely resembling this Design Challenge back in 1640 
So when I refer to 'data', I'm meaning the 1946 version.
There are several different pieces of data, used by different parts of the system, in order for BT_Sentry to operate as I intend.
At the gateway we have a detection system, and hopefully capture a Bluetooth MAC Address.
For the Camera Location, we have detection and an image.
BT_Sentry will record and process the data, and then generate additional data.
It will send data to the Garage Door, External Lights, Smartphone or Owner Notification depending on the data received.
So it's important that for these parts to operate correctly, we establish a data structure.
Once we've determined what each part needs, then the software can manipulate the information to satisfy each parts need.
What, Where, When, Who
Many years ago I had the pleasure of taking a course, and part of this was understanding the What, Where, When, and importantly Who of messages.
While the focus of the course was different to this, the principles of the above still apply (IMO).
'What' is the data we are sending. The receiving end needs to know what it is getting and if it has everything, so it can use it appropriately.
'Who' is the source in this application. You could argue that who and where are interchangable, and if it wasn't M2M, then you'd be right.
'When' determines if the data is realtime or can it be delayed.
For the gateway detection it has to be realtime, but the images are stored and therefore need timestamping to provide relevance.
In many situations we want to know the status of things, so a 'heartbeat' may be appropriate if the data isn't constant.
'Where' will the data be used. It could be that we use it in several places or just one, but it is helpful to know during the design phase.
It may seem obvious that we send the MAC address from the gateway to the Camera location, but do we need to send that further, or can we remove it?
Do we store it with the camera images in case it is useful later, and what if we have multiple BT MAC address'es (ie vehicle plus phone/s).
What if we have a legimate visitor one day and the same BT MAC appears later ... when it isn't legitimate.
Being able to pull the log might yeld other information.
So as you can see, it's not exactly cut and dried.
Sentry
This is located at the gateway and detects an incoming vehicle. If it has a BT emission, then capture the MAC address.
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.
The intention is to use a 433MHz link to the camera location, but it could be useful to have an acknowledgement that it arrived.
Cyclops
This is the camera location which receives the MAC address and passes it via the serial port.
Effectively it is acting as a protocol converter for the data.
Movement detection is also at the camera location.
This is primarily to determine when someone leaves, but it will also capture the arrival.
The 'who' location and timestamp is added to the logs and from this we can determine the exact sequence of events.
The current intention is to have the central processing here.
It will control the camera, and each image will use some of the data either on the image, or as part of the file naming convention.
Using WiFi, it will send out the various messages to the other components.
OD Lights
This receives a simple ON or OFF via NodeRED, and controls the relay.
Multiple units could receive the same ON/OFF data to control the various outdoor lights.
There is no feedback required, as the system should know the last state.
Portal
This is the garage door. It receives a simple ON or OFF via NodeRED, and controls the relay top open or close the door.
At this point I don't have a door controller, but it may require 2 units, one to open and one to close.
There is no feedback required, as the system should know the last state.
Smartphone
The system will send out a notification to a smartphone.
I've looked at some of the free SMS services, and sadly none worked.
The two major Telcos have a mechanism, but it requires registration and there is some cost.
I haven't found the solution ... yet, but a fallback could be via IFTTT.
This will require using WIFI and access to the Internet.
There is no feedback required.
Owner Notification
The system will send out a notification to a connected device inside the home.
This will require using WIFI.
There is no feedback required.
Planning
I've said it before that IMO Engineering is 90% planning and 10% doing.
This post is mostly planning, but it is essential to understand the various parts and how they interact.
I was hoping to include the hardware for the gateway (Sentry), but it seems to be on a very slow boat from china.
I have downloaded a very useful app nRF Connect by Nordic and used it to snoop BT emissions.
From the quick checks, the MAC address is prominent, so it gives me hope that most devices should show up.
It also seems that iToy devices turn on BT regardless of whether you want it or not, so if you're concerned about battery life, you might want to check yours.
SO that outlines what data structure need to be constructed, and luckily some of it is already sorted. 
My PSOC BLE kit arrived as suggested by Jan Cumps here ...
I just need to power it up, checks some things and move to the next part ... the supply.
Mark
Top Comments