No announcement yet.

Location Isolation with ESP32 Bluetooth Low Energy

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    I found a very promising approach using node.js on YouTube. While I have never developed anything in node.js, it is used for zigbee2mqtt, node-red and many others. I followed the YouTube video, but ran into a library install issue that appears to be related to the version npm/node.js that is current. Node.js should provide an easy port to the API used for ESP32 so should be able to mix and match RPi/ESP32 with mcsMQTT. I will see if I find anything else following this thread tomorrow.


    • #32

      Thanks for doing all you do. This is very over my head. Hopefully in a year or so I'll be a little more fluid. I do think long and short range BT have a lot of uses...but since home automation to me is your home responding to you automatically...stable tools for "where" you are in your house as well as arrival / departure sensing are really core/key to everything. I'm continuously amazed that major manufactures have not focused on this as about everything else could really be done with simple timers and hard wiring. That's a bit of an exaggeration. no doubt. However, some of the biggest complaints I've see posted center around things especially like the flakiness of zware arrive sensors. For example, I want my garage to open right when I drive up...not a 1/2 a block away...or sitting there waiting for it to open. I don't want it to open at 2 AM because my zwave arrival sensor disappears wjile I'm sleeping and then comes back. Clearly BT has many applications, but most (really all) reasonably priced approaches today are simply not stable and depend on cell phones and/or wireless TCP/IP and really work perfectly only about 30%-50% of the time. Cell service in my neighborhood sucks which make this even worse. Some of this might be OK for somethings, but for unlocking your house or any security related function it simply isn't.



      • #33
        Extending BLE location monitoring to RPi using nodejs seemed like a very good excuse to learn nodes just as it was to learn ESP32 development. Unfortunately it looks as if the nodejs Bluetooth libraries have been abandoned as many others seem to have the same install issue I have been having. I may try again in the future, but it is not looking very positive as the issue surfaced years ago and it seems to still exist. There was a lot of interest when Bluetooth first became available with RPi, but now the interest seems to have dwindled.


        • #34
          While I gave up on nodejs due to abandoned libraries, I did find libraries that can be used with C on RPi. I can do continuous polling of BLE beacons and report any change in RSSI. I am moving down the path of trying to implement the same business logic that I used in the ESP32 in the RPi. Short of this it should be pretty easy to just do reporting of RSSI/Distance from the RPi. I suspect the same will work with USB dongles as with the BLE built into the RPi.


          • #35
            I have your mqtt plugin but I am not sure mqtt is the most efficient protocol to use. Have you seen the ESP-Now protocol. It is made for stuff like this. 40ms from sleep to transmitting. Hardly any overhead so you could do wireless reveivers and have amazing battery life or much shorter intervals. Once a device is paired to the master it is a persistent connection. The master can be directly connected to the home seer servers and have 20 receivers If you need more receivers add another master. It has CRC and you could pull individual sensors on different frequencies. I love mqtt but this is what this protocol is designed for. 250 byte packet size. Basically a wireless can-bus system. I am not a programmer or I would try to do it myself but I have used ESP-NOW with amazing results. Hopefully this suggestion doesn't annoy you but you did say you were trying different things.


            • #36
              I am familiar with ESP-NOW which is a capability developed Espressif. I had always considered it's benefit to be with battery operation associated with deep sleep so the ESP could be awaken and the WiFi on-time was significantly reduced largely due to reduction in the overhead to establish a connection. I had not considered the application where one server acted as a gateway in a star configuration. This gateway node would then still need to communicate with an application server such as HomeSeer using some other protocol (such as MQTT).

              What I cannot envision is how this becomes integrated into other HA components. All ESP processor products use a single WiFi radio and even the ESP32 shares the Bluetooth and WiFi antenna. Once data has been collected by the ESP-NOW server I do not see how it gets communicated to other parts of the HA environment. I suspect it may be possible to use something like RPi that has both ethernet and Wifi, but then the software would need to be developed to implement the Expressif protocol on the RPi hardware.

              There are other variants of communication protocols that have been developed to satisfy a specific niche. These typically exploit some aspect of a standard protocol to remove a capability and optimize another. When the standard is sacrificed then the breath of application is reduced. These solutions have their place, but they do not replace the predecessor protocol.

              In the general case of low power IOT devices one expects the devices to either lose connection because they are low-cost marginal hardware designs or they intentionally go offline to conserve battery. A system designed needs to consider the Quality Of Service that is being supplied. For example, consider an IOT device that turns on a light and it is important that the light does turn on. The application (e.g. HomeSeer) commands the light to the on state, but the IOT device it not connected at the time the command is sent. The MQTT protocol assures a QOS so that the command is held back until the IOT device has advertised itself as now being awake and connected.


              • #37
                Just found this project, looks really interesting.
                Earlier this year i started looking at Find3 -
                Wondered if you were aware of it, or if any part of it could help or assist this project.

                I've paused work on implementing Find3 for now as i have too much on my plate, but am still interested in this area.


                • #38
                  I was not aware of the project, but did a look at the documentation. The passive approach is common between Find3 and what I have done. Both use RSSI as the primary measurement.

                  There are two primary differences. The obvious is WiFi vs. Bluetooth and this really make little difference for this application.

                  The second is that Find3 translates the set of RSSI into a specific X,Y (or room) as a fingerprint. There is a setup phase where you move the smartphone into each room that is a candidate for tracking and use the set of RSSI measurements from each RPi as the fingerprint for that phone in that room. In my implementation the RSSI is used to trilaterate an X,Y position using an algorithm similar to what is used to isolate earthquake epicenters from multiple seismic station readings. There is no learning phase with this approach.

                  WiFi broadcast intervals are measured in minutes and are variable. Bluetooth scanning intervals are measured in seconds with the RPi being more capable of short intervals than the ESP32. If one's use case is to know when the tracked device is starting to move, is moving or has stopped moving then the faster interval is needed.

                  I know in my household smartphones are usually stationary when in the house at some known location so when time to use it then will remember where it is. Others may carry there phone on-person all the time. Carrying beacons on a keychain or similar has the same issue. For the tracking to work the user behavior has to be that the device is always on-person.

                  The Find3 document does acknowledge IOS MAC spoofing and my experience has been that Android does this as well to protect the user from passive scanning. IOS and Android do this with Bluetooth too. Beacons used with Bluetooth tracking by definition do not spoof their MAC address.

                  Find3 looks to be a nice project, but with fundamentally different approaches to location identification. I do not see how what I have done could be integrated other than having two answers that would then be used by a higher level integration application. For me the BLE tracking effort was done as a learning vehicle for ESP32, Bluetooth, kalman filtering, and location isolation algorithms. It was an excellent learning experience. The need for on-person devices eliminates a practical application for me. For others this constraint will not be a problem.