No announcement yet.

Location Isolation with ESP32 Bluetooth Low Energy

  • Filter
  • Time
  • Show
Clear All
new posts

  • Location Isolation with ESP32 Bluetooth Low Energy

    A discussion started at on the subject of BLE scanning. I did some prototype work with ESP32 to address the author's question and have decided that the project is interesting enough to continue. The intent of this thread is for discussion on the design characteristics of the project.

    The development will be targeted to ESP32 which has built-in BLE capability. The interface with HS is via MQTT protocol.

    My prototype was a sketch using Arduino IDE. This was fine for a quick and dirty evaluation, but porting it for use by others would require that each user have development capability using Arduino tools. My next step is to continue porting of Tasmota to ESP32 (from ESP8266) so that the documented capabilities provided by Tasmota can be used. This is primarily associated with setup of the SSID, subsequent OTA updates of firmware and general configuration for each user's environment. It would also allow users to use other capabilities of the ESP32 so the installed devices can serve multiple purposes.

    A user installation will consist of one or more ESP32 development boards which sell for $5 from China shipment such as or $10 from USA shipment such as . I do not have either of these specific units with links just provided as examples. I have several ESP32/LoRa modules that I will be using for my development.

    The prototype evaluation scanned for whatever BLE devices that were in my or close neighbor's houses. I did not attempt location determination, but only focused on present/not-present reporting. For this development I ordered two Bluetooth tracking beacons. One based upon Apple and one based upon Android. I should be able to determine if both are compatible.

    Position determination will be based upon the RSSI signal reported by the beacon. There is also a TxPower parameter that can be set on the beacons that may be used at a later time. To assess a reasonable X/Y location at least three ESP32 devices will be installed at strategic locations that provide desired range and separation. My current thinking is to define an arbitrary grid of 100 x 100 and each ESP32 position would be characterized as an X/Y location on this grid. Beacon location would then be calculated with respect to the ESP32 locations so would also fall somewhere on the grid.

    I saw much variation of one form or another in the prototype evaluation in the reported RSSI over time. This implies that filtering will be needed. Kalman filter was discussed in the other thread and this is likely a good final solution. Initially I will be doing a simple weighted average which is in effect a low pass filter. Once the project is determined to be viable then better filtering approach can be implemented to improve stability.

    The prototype ran at one minute samples with thirty second scan per sample to find which BLE devices were advertising. While the ESP32 likley will be powered from USB, I do not know what the duty cycle effects are on battery life of bluetooth devices. For example, will it drain the battery of a nearby smartphone?

    The ESP is a powerful microcontroller so should be able to easily handle the computational burden. My intent is that each ESP32 subscribes to the measurements being made by the other ESP32s. Each will then independently calculate every beacon position. While HS can get information from all ESP32s, the information about beacon location should be identical. In essence this is a redundant system where a fallback could be done by HS should the LWT of the primary ESP32 show it going offline.

    Any discussion that will help this project along and be something useful is welcome.

  • #2
    I can’t wait for this!!


    • #3
      Status report:

      Obtained BlueChart iBeacon and a Fezzycom beacon. I tried to configure each with downloaded apps, but did not have success. Without configuration the ESP32 was able to find them and I could track the RSSI as I moved them. It means that a friendly name provision should exist in Tasmota so the topic will be more user-friendly rather than using the MAC address.

      Got the BLE functionality implemented in Tasmota targeted to ESP32. Currently set so the 7/8 of the time the antenna will be for Wifi and 1/8 will be for BLE scanning. It is interleaved so WiFi functionality should only have a very minor impact.

      Bluetooth libraries are large and exceeded the default Tasmota partitions with a build size of 1.7 MB. Able to re-partition to provide nearly 2 MB for the firmware. This maintains OTA capabilty. Also had issue that took a long time to debug where the sntp initialization would crash the ESP32. Turns out this library required WiFi to be established before trying to initialize sntp. With ESP8266 this was not a criteria.

      Next step is to put the hooks in Tasmota to accept the x/y coordinates of the ESP32. I have the triangulation algorithm and the Kalman filter which both will be straightforward to implement. I think the appropriate place to put the filter is on the RSSI, but another option is to filter the computed beacon x/y. Need to play with it to see which provides better results. Another thought is to consider provisions for beacon motion so the filter will predict where it is suppose to be based upon trajectory. This will be something later if it seems appropriate.

      For mcsMQTT I will try to do a scatter diagram for ESP32 and beacon locations using the charting capability already in mcsMQTT, but nothing has been started on the plugin for this. There may be better charting tools that update points rather than updating charts. Open to info on this.


      • #4
        You’re really on to something here!


        • #5
          Status #2

          I have had some struggles, especially with a new design using C. C is a foreign language to me so time on google and time with print statements occupied 90% of the effort. The good news is that the firmware is fully functional and running under Tasmota. All BLE processing is done in the second core and all other Tasmota functions are done in the first core. This means that from a CPU use perspective of the ESP32 it it pretty much transparent to Tasmota that a BLE function is running so there are no timing considerations for proper operation of Tasmota. Now I am in the tweaking stage.

          I have 2 beacons and deployed 5 ESP32 as scanners. Provisions are made for 10 scanners and 50 beacons. Collecting some data now. I am surprised with all the additional Bluetooth devices that are being discovered. This has prompted me to expand the firmware to provide additional provisions for management of beacons.

          Before I moved on to the second and subsequent ESP32s, I confirmed proper triangulation and kalman filtering test messages that emulate other ESP32's.

          Adding the second ESP32 opened a can of worms that took awhile to resolve. The symptom was that one of the two ESP32s would stop reporting. Tracking it down lead me down to print statements in the pubsub library to see that connection was lost to the broker and it tried to flush the buffer. The wifi libraries flush function caused the ESP32 core to hang. I suspect this is a bug in the library as normally one never gets to this point where is is necessary to try to flush the buffers. Nice to have two cores in this situation to assist with debugging. Turns out the root issue was the same client ID was being given to the broker so it was a positive feedback loop as the second ESP32 started reporting positions and this choked the wifi manager which was running on the primary core.

          I have been updating the manual as I implement the firmware. It is at Section 14.15.1 if anybody would like to comment.

          Next step will be with mcsMQTT plugin to improve the user experience working with the BLE beacon tracking. The two primary things I want to add is a graphic to show scanners and beacons on a grid and a facility to manage beacons similar to the facility I provide to manage MQTT devices in general. I have not uploaded firmware yet and do not expect to until I have a full package developed with both firmware and plugin working together.


          • #6
            Loving this! One thing you could implement is a lookup table to identify device by MAC address. At least it could get users to the point of saying Fitbit vs an Apple TV etc.


            • #7
              Good idea. I looked at the reference and it should be possible to build in access to their API to get the data.

              Attached is some eye candy that I collected during the plugin updates. I have 3 scanners powered and these are shown as yellow squares. My two beacons are correctly located. The Feasycom one is seen by all three scanners so is the largest circle. The BlueCharm one is not seen by the scanner at 90,90 so the smaller circle reflects the lower confidence level.

              Click image for larger version

Name:	plot1.png
Views:	93
Size:	19.2 KB
ID:	1302143


              • #8
                I'm finding this to be profoundly interesting. Has there been any more progress made?
                Originally posted by rprade
                There is no rhyme or reason to the anarchy a defective Z-Wave device can cause


                • #9
                  Considerable progress. The past week have been focusing on the plugin side of things and iterating the ESP32 code as I find better ways for the two pieces to interchange. It really is coming along very well. I think I can have something for others to use next week.

                  Above was an example of the current location chart. I also have a scatter chart for a selected beacon that shows how it moved around in the past 24 hours. I made all the setup and the reporting done by the ESP32's visible and alterable in a consolidated page with snapshots shown below. This has gone beyond what I had first envisioned but it is cool.

                  I also attached the manual that is a work-in-progress for Section 14.15.1. This part describes the ESP32 side of the interface. I have not yet put the plugin side into the manual.

                  Click image for larger version

Name:	b1.PNG
Views:	99
Size:	68.3 KB
ID:	1304216

                  Click image for larger version

Name:	b2.PNG
Views:	100
Size:	314.3 KB
ID:	1304217


                  • #10
                    I can’t wait to start implementing this!!!! So as a project manager I despise scope creep...but...have a question. Are the resources too consumed on the ESP32 as to prevent other functions. I just ask because I’ll have these things across the property and if they can still use the IO pins that would allow for some other functions like controlling LED lights or chimes / alarms. If not it’s cool I can implement with another device just thought it was feasible.


                    • #11
                      Only one of the two general purpose CPUs are being used for bluetooth. Even it is loafing. The other CPU supports all the other Tasmota functions. Since the ESP32 is an order of magnitude faster than the ESP8266 it has much spare on this CPU.

                      For flash I am at 1.74 Mbyte. I have the ESP32 partitioned for two 1.98 MByte segments for application. I should be able to do OTA upload, but I get too-big message when I try. I can do it via USB. I have not looked into the code for OTA to see what it needs to know to recognize the partition size I am using.

                      Of course all of the general purpose IO is unused. I have not tried to apply any of the IO pins for other functionality, but it should be able to be setup in a standard Tasmota manner.


                      • #12
                        I have packaged up all related files at the following locations
               (10 MB) - plugin with BLE Scanning page
               (9 MB) - mcsMQTT plugin manual. Sections 13 (Plugin Configuration) and Section 15.15 (ESP32 firmware and API)
               (1 MB) binary application, bootloader and partition table
               (75 MB) ESP32 source from PlatformIO folders

                        I am not certain of the need to load the partition table on the ESP32. I did not have success when I erased the 4MB flash and started from scratch. I was able to download firmware.bin which is the main ESP32/Tasmota program. I did this only after having already used the PlatformIO IDE to install the bootloader and partition table. Section 13 of the manual describes this. Always able to use the PlatformIO IDE and load via serial. I also did not have success with subsequent OTA. Seems like I did at first, but not able to when I tried more recently. This is not specific to the application, but to the Tasmota and other infrastructure. Tasmota port for ESP32 does not have the timezone implemented. This appears to be a more basic issue with underlying libraries. This does not impact functionality.

                        There has been considerable effort with both the ESP32 and the plugin and each have had multiple iterations as I find ways that I feel would be better. My primary objective was learning with ESP32 development, Tasmota for ESP32, BLE and methodologies for location isolation. It has been many years since I got into the math associated with this project. I ended up doing the trilateration by solving for intersection of circles using simultaneous equations. Some of my results where not as expected so I did an approach that translates and rotates the problem space through the origin so that linear match could be used. When I got same results both ways then I was confident of the implementation.

                        My internet upload speeds on a good day are 200K (a little better than dial-up telephone line) so there may be some difficulty in getting the source uploaded. At this point the first two have been uploaded and the first also contains the manual. I will keep trying for the others, but right now the connection has issues.

                        For those interested at this time look at Section 13 in particular that has getting started paragraphs.


                        • #13
                          I found the correct bootloader file so issues I described in the prior post are resolved. Download of the binary can be fully accomplished with the download tool referenced in the manual. I updated the manual and the zips for the proper procedure and proper files. Again, upload is slow. I did previously get the source uploaded.


                          • #14
                            Very good work. Have a couple of ESP32 boards coming inn, and a couple of Mi Plant sensors, this looks like a perfect match.