Location Isolation with ESP32 Bluetooth Low Energy

[Guest]

That's very good new Michael ! Thanks .

[NAB]

Been following this for a while and it sounds great. A question, though, about the x:y location - how well does it work in a multi-story building where devices and hosts could be located in any room? Would it be more accurate to have the layout in three dimensions in the location grid rather than two?
Looking forward to having a play with it.
NAB

[Michael McSharry]

I had considered adding a Z axis, but at that time thought the complexity detracted from its usefulness. My thinking it would be very difficult to select the correct floor as most points in space would be somewhere between the two floors. This would result in a lack of confidence as the user could not believe the floor selected. The physics of it is also problematic. There are very few obstructions in the vertical direction so beacons above would appear closer than beacons on the same floor.

In my testing with 5 ESP32 and 2 beacons it was often the case that I did not have three-point intersection of the distance radii. This means the calculation was based upon weighted average distance of the ESP32 that at least had visibility. Adding a third axis would make this alternate calculation hard to interpret and suffer from the same floor placement uncertainty.

After you play with it a little then I am open to suggestions.

[NAB]

I had considered adding a Z axis, but at that time thought the complexity detracted from its usefulness.

You're probably right. I was working through the maths in my head and got hopelessly lost! Definitely needs a play before any serious tweaks. All my ESP32's are in use, so I have more coming - the idea that I can have PIR, temperature, humidity, pressure and location all in one box for less than USD10 is really quite appealing.

[Michael McSharry]

I did some research about tracking smartphones with BLE. What I learned is that Android and IOS randomize the advertised MAC address for security. This explains why I was getting many unrecognized MAC addresses over time during my development. What I am going to do is provide provision to group all unrecognized MAC addresses into a single beacon's MAC address. While it will not be possible to detect one person's phone from another, it will be possible to detect if any smartphone is present. The update I made to mcsMQTT.pdf is shown below as well as adding another configuration item to the API.

BLE is often used in smartphones, fitness bands, smartwatches, audio equipment and tracking beacons. The BLE protocol provides a means for one BLE device to request that other BLE devices advertise their MAC address. In the Section 15.15 implementation ESP32 devices will periodically make this request and the ESP32 will then listen for the MAC addresses that are advertised. After signal processing by the ESP32, information on changes in advertised locations are published via MQTT. mcsMQTT will provide the visualization and HS interface for this information.

The BLE MAC address is a crucial element for the tracking beacon and the ability of devices such as fitness bands to recognize what or who is reporting. For smartphones the MAC address presents a security concern so the MAC address being advertised is usually randomized to protect the identification of the smartphone at any given location.

While discrimination of specific smartphones is not possible, it is possible to determine if the MAC address provided is from a valid supplier and if not then assume it is a randomly generated one and is associated with some smartphone. The ESP32 can be configured to group all MAC addresses without a recognized supplier into a single MAC so that presence can be reported. Location information, however, will not be valid for the case of multiple smartphones being present.

[ts1234]

I've been an IT newtork guy for almost 40 years, but I'm way over my head here as this is a little more on the server/PC side. What I'm really looking for is a way to build event triggers for Bluetooth devices that come in/out of range of the Bluetooth USB dongle on my PC. That would be ideal. The little bit of breezing of the PDF makes me think it has to be one of external boards like from Sparkfun. Honestly, I have not absorbed all of that PDF by any means, so please forgive me for asking q's that are likely buried in there already. It is an amazingly well done doc.

1) Can it be set up to read the RSSI values of things in range of my Windows 10 PC USB dongle locally?
2) Or, does it only work with ESP32 boards? (A jump I probably could make but not part of my current toolbox)
3) Either way, could I build event triggers for when devices came in/left ranges based on BT RSSI values?
4) If so, could those triggers also be set up to know the difference between a signal growing weaker and hitting something like -48 vs growing stronger and hitting the same value. IE - Basically, is the remote device coming or going.

THANKS!!!

Tom

Current Date/Time: 8/31/2019 9:42:57 AM

HomeSeer Version: HS3 Standard Edition 3.0.0.548

Operating System: Microsoft Windows 10 Pro - Work Station

System Uptime: 0 Days 1 Hour 5 Minutes 21 Seconds

Number of Devices: 450

Number of Events: 185

Available Threads: 800

HSTouch Enabled: True

Event Threads: 0

Event Trigger Eval Queue: 0

Event Trigger Priority Eval Queue: 0

Device Exec Queue: 0

HSTouch Event Queue: 0

Email Send Queue: 0

In Virtual Machine: No MFG: gigabyte technology co., ltd.

Enabled Plug-Ins

2.0.61.0: BLBackup

2.0.6.0: BLMarantz

2.0.31.0: BLRing

3.0.0.65: EasyTrigger

3.9.610.5: HSBuddy

4.1.5.0: mcsMQTT

3.1.0.17: MeiHarmonyHub

3.0.0.33: Nest

3.0.0.63: PHLocation2

1.0.0.7: Restart

3.0.11.13: weatherXML

3.0.1.262: Z-Wave

[Michael McSharry]

This implementation is with one or more ESP32's so it would not work with a Windows/Linux Bluetooth device sending out the advertise requests.

It does provide a HS Device that contains the RSSI and this RSSI can be Kalman filtered to reduce its noise.

It provides distance that also is processed via Kalman filter.

It also provides a HS Device that contains a position with hysteresis to help with determining stationary vs. moving beacons.

Any of these could be used to determine direction.

It identifies a beacon based upon its advertised MAC-like address. If you are trying to do tracking for smartphones then you will not have success because Android and IOS phones randomize their address for security reasons.

Bluetooth consumes little energy until its turns its transmitters on. When the server pings the BLE devices asking them to advertise themselves then the transmitter needs to be turned on to transmit the advertisement. As the ping interval is decreased the battery life of the devices is also decreased. I have typically been using one minute intervals. In one minute a moving device could change position considerably.

Consider also that signal radiates from a single point so a device moving parallel to the server vs. perpendicular to the server will exhibit different motion characteristics. The use of multiple ESP32 servers reduces this difference because the ESP32 communicate with each other to arrive at the location and change of location over time. While it works with a single ESP32, the design intent is with multiple so trilateration can be used to identify the position of the beacon on a grid.

In a perfect world the RSSI is well-behavied, but the RF world is not perfect. The RF strength is affected by both static and time-dependent factors so expectations should be that there will be variability and cannot be considered to be as accurate as other measurement techniques.

[ts1234]

Thanks for the quick / detailed response!

Guess I'm learning to use ESP32's in the near future! :-)… My current needs are very simple and don't need to map to anything other than arrival and departure. I do that now with things like iBeacons and phone apps today, but want the phone 10000000% out of the equation as it just causes delays and failures. Those triggers are also not nearly as accurate as I need from a timestamp/ event based trigger. I'm looking for to solve several issues that I think I can resolve if everything basically runs locally vs. Internet and Cellular.

I'm sure it's not simple, but please consider adding the local dongle as a future feature request. That said, I'm very exited to find this plugin!

Thanks!

Tom

[ts1234]

Michael,

I don't mean to be a bother, but before I jump off into this project I have a couple quick questions. I'm not that skilled with the protocol and devices yet so I'd like to be clear if what I want to work...will work.

1) If both the "transmitter and receiver" plug into a power source (IE - Not battery dependent) How low can the ping interval be? I would like 5 seconds or less as I want what it controls to seem very responsive.

2) Assuming that the Arduino board is kept in a fixed location and that a remote iBeacon always approaches from the same angle...can I depend on the RSSI value to be exactly/close to being the same value when a particular distance is reached between the ESP32 and the remote beacon (probably a FEASYCOM 500m Long Range Bluetooth Low Energy Waterproof iBeacon)?

Thanks for your time!

Tom

[Michael McSharry]

Seems like what you are trying to do is better suited to Active RFID rather than Bluetooth. I recently did some development to replace the technology that was selling about 15 years ago that is described in Section 16.16.2 of http://mcsSprinklers.com/mcsMQTT.pdf. Active RFID is a RF signal, in this case 433 MHz, that contains a data pattern that is repeated every few seconds. As the transmitting device becomes within range the receiver will detect it and then when it goes out of range the lack of signal will be detected by the receiver.

The pattern that I used consisted of 4 characters. The first three were constant and the last cycled through the alphabet. The first three are used to distinguish one transmitter from another. The last was used to evaluate if the receiver was missing transmissions. As transmissions were missed I knew the transmitter was at the end of detectable range. I little additional processing on the receiver could use the magnitude of the missing transmissions as a signal strength indication.

I have CheaperRFID (old technology) units that had RSSI as well as those that did not. I though the RSSI would be able to improve the algorithm for presence detection, but found it not to be that useful. Nevertheless I got a receiver that was advertised as having RSSI output to evaluate this new CheapestRFID approach. When I received it, there was no pin that had any output other than the data signal.

Today I did a little searching and found one from Sparkfun that actually had a datasheet with a analog output that is a signal strength indication. It may or may not work well, but I am curious as to what it will do. This one is 315 MHz rather than 433 MHz. This will give a little better range and be the same frequency that I have for CheaperRFID.

------------

Thinking more about RSSI, then the same approach should be just as easily done with WiFi as Bluetooth as the RSSI is readily available. Both are at 2.4 GHz so should get the same range (which will be less than the 433 Mhz or 315 Mhz Active RFID). It would be less suited, however, for battery powered devices. This is something I can play with as well to satisfy my curiosity.

------------

To answer your specific questions.
1. I found that ping intervals in the 5 second range would choke the ESP32 program. I do not know exactly why but since it was not practical I did not look more deeply. The advertise request may not always be acknowledged by the tag or acknowledged with the same latency each time. When multiple tags are present then collisions become more of a concern as the request interval decreases. I believe that a single request is actually realized at a set of three or so RF transmissions spread over a random time interval (and I think channel in the Bluetooth 2.4GHz band). This Bluetooth design is explicitly to deal with RF signal collisions.

2. I did not do explicit testing for RSSI/distance vs. motion, but generally my experience is that the RSSI does not change incrementally as distance changes. RF has many ways to get between point A and point B so while the beacon moves the actual signal strength may not change just because of distance. With trilateration from multiple ESP32 receivers there is a better chance that a motion change will be detected.

[ts1234]

Wow! Thanks for taking all that time! Great info!

I'm guessing RFID probably is the answer, but I'm even less knowledgeable about that than BT. :-)

So, I did a little testing of my own after you steered me in the right direction. I do wish I knew what you know as I fear this will end up taking a bit to learn about writing plugins. I have the outdoor version of the Feasycom 500 meter and a BP-109 which claims a 1000 meters I think. In my PC I have a TRENDnet Low Energy Micro Bluetooth 4.0 Class I USB 2.0 with Distance up to 100Meters/330 Feet. TBW-106UB. For this very simple test I loaded the Bluetooth LE Explorer from the MS APP store. I have it set for continuous enumeration and both of the Feasycom's set to around 150-100ms.

I'm actually amazed at how many other BT devices are around including people who walk by on the sidewalk.

I will say that I see RSSI value changes about every second via the app. Of course, this is a i7 processor not an ESP32. At least in initial testing I see fairly constant increases and decreases in RSSI as I move them around. I am trying to stay in the same line/plane as I move them away since angle does seem to have an impact. For my application this would be OK since the approach angle would be fairly constant.

The variation in RSSI seems to keep a value around +/- 5 but does bounce around. I am guessing something like that the smoothing algorithm you mentioned in your doc could handle that easily.

So, this brings up two questions...

One, is there something out there that is basically a more powerful ESP32 board that I could use your current plugin somehow?

Two, is there a primer somewhere I could start to learn how to write plugins myself?

I used to program in C++ years ago before it became object oriented and been in networking and communications for 40 years, so I get abit about protocols. While I swore I'd stay away from tech.... I literally just retired and probably can find some cycles for things like this now. I've seen some code around for reading BT locally on a PC, but have a 1000 miles more to go to learn to take that (once/if I figured that out) and then write the Homeseer side of it.

[Michael McSharry]

The ESP32 power is not the limiting factor, but I suspect its architecture is. It has a single 2.4 GHz antenna that is used for both Wifi and Bluetooth. Since Wifi is its method of interface it needs to keep this part relatively responsive. Something like a RPi with Ethernet for the interface and USB for the Bluetooth should have plenty of horsepower. I do not have experience working with hardware devices on Linux, but you may be able to do it at the Linux rather than source code level such as shown https://raspberry-projects.com/pi/pi...tooth-commands

If I was to go the RPi route then I would not write the HS plugin, but use MQTT as the communication protocol and let mcsMQTT handle interface with Homeseer. This should also be doable at the Linux level by piping the BLE output to mosquitto_pub application. Of course a tighter and more flexible approach would be to develop source code that communicated directly with the devices. You could even follow the API that is documented in mcsMQTT.pdf so that the additional BLE features of mcsMQTT could be utilized. It just depends upon how fancy you want to get. It does seem, however, that just basic info is all you need. Since the RPi has the horsepower it seems most appropriate to maximize its share of the processing and only communicate event-level information to HS.

If you do want to write a plugin, but the Homeseer SDK download provides a template. There are also users that have improved upon the HS template. I have no specific recommendations, but a board search should find some hits.

[ts1234]

Again, thanks for EVERYTHING!

I find it almost funny that one of my jobs was taking care of Sun Microsystems data network for 7 years and yet in that time I never learned UNIX (sigh). It seems far easier to go the RPi route as you state. I'll look over the SDK, but guessing it's not the way I'd go as one of my weakest points has always been ...read the darn manual.

Again,

Thanks for all the help!...especially on Labor Day...

Tom

[Michael McSharry]

I have been poking around and see that RPi has bluetooth built-in, but the same should work with dongles as well. At https://www.raspberrypi.org/forums/v...ic.php?t=47466 is a good discussion of using linux script for bluetooth tracking. The core of it is the hcidump command. I have been playing with it and can get "hcidump lescan" to show the bluetooth devices. If I run "hcidump lescan --duplicates" then it produces a constant stream of output showing the nearby bluetooth devices. This is the continuous scan that you desire.

I was not able to get the beacon to connect which I suspect is normal for a beacon, but to use the rssi hcidump command one needs to be connected. In this same thread I found "sudo btmon |grep RSSI &" to spawn off a process that dumps rssi info from bluetooth. I then setup a whitelist with one beacon and used hcidump with duplicates to repeat the scan. This resulted in the image below.



I then moved the beacon 10 ft away and got RSSI around -90. Another 10 ft and the RSSI only marginally change to -92 or so.

What this shows me is that one should be able to get BLE RSSI info for beacons relatively easily with the drivers built into the OS. More google seaching may even find more complete projects that may be able to be easily adaptable to work with HS.

[ts1234]

That is pretty awesome!!! In my testing I couldn't connect either. I am guessing you'd see a more gradual RSSI value change with some of the long range ones. I'm way over my head here...just starting to load Visual Studio ...and already digging since some of the menus have changed in 2019 it looks like, but can't even find the Homeseer templates or even know if it's ok to run VS2019 or I really need to find the 2017 version. ...Going to have to start reading.