Announcement

Collapse
No announcement yet.

Location Isolation with ESP32 Bluetooth Low Energy

Collapse
X
 
  • 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.

    Comment


      #32
      Michael,

      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.

      Tom

      Comment


        #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.

        Comment


          #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.

          Comment


            #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.

            Comment


              #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.

              Comment


                #37
                Just found this project, looks really interesting.
                Earlier this year i started looking at Find3 - https://github.com/schollz/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.

                Comment


                  #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.

                  Comment


                    #39
                    hi Michael,

                    I curious to know if you did pursue with thios with raspberry pi?

                    I am now using this plugin ( via the jeedom hs3 plugin) https://jeedom.github.io/plugin-blea/en_US/index
                    You will need to transalte this in english with google.


                    The idea of this plugin is to monitor ble devices. And you can use others raspberry pi/ linux pc as ''entenna''. My main use is to detect if a device is present or not ( ex. my keys with a Tile pro ( bluetooth tracker) on them). When any of the entenna detect the bl;e devcie , it is shown as ''present'' with a value of 1. When any of the entanna havent seen the b;le device since a while ( user configurable ) it is show as not present with a value of 0. The main problem with jeedom is that all value of device a cached into ram... so when the the jeedom machine restart .. it is possible that some plugin takes a empty '''' string an interprete this as a value oif zero.

                    anyways


                    The plugin works pretty well, exept for when the jeedom machine is restarted.

                    I would like to be able to send thoses data ( only presence detection) myself to my hs3 machine via mosquitto_sub.
                    Then i guess i could elaborate a logic in hs3 after that .

                    I am also curious if you did some research about this topic normal ble dongle on linux , using the data from hci0 scan?



                    one last thing, the bluetooth dongle is praysed by the jeedom community, it provides more range and you can change the enttanna for 9dbi one or 12.

                    Comment


                      #40
                      I curious to know if you did pursue with thios with raspberry pi?
                      I do not recall who was trying to use the RPi, but I did do an implementation on RPi of the same API used for ESP32. From mcsMQTT/HS perspective it is transparent if the end node is a RPi or ESP32 so a mixture could be used. It was posted at https://forums.homeseer.com/forum/li...eacon-tracking

                      The RPi does make for a better BLE client which I suspect is due to the independent antennae between WiFi and BLE vs. ESP32 which shares one. The RPi CPU has more throughput than the ESP32 so that could contribute as well.

                      I took a look at the mcsMQTT manual and did not see any update based upon the RPi and BLE. I normally document the projects there. Likely it did not have any following so never took the effort. Actually very little interest overall and I did not migrate BLE to the HS4 version of mcsMQTT. I believe multiple ESP32/RPi running to support close-location identification is too much complexity for the typical HS user. It was a good learning experience project, but not something that is for the mass market.

                      Comment


                        #41
                        Thanks Michael!

                        Comment


                          #42
                          Hey Michael and all. I am very interested in this as well. I dove into this project: https://espresense.com/ and picked up a bunch of these (https://shop.m5stack.com/products/at...evelopment-kit) and placed them around my house. This project was primarily designed for HomeAssistant so I don't have access to the HA side of things. I can see all my ESP devices via MQTT Explorer and beacons reported, but I'm unable to see my Android phones without the help of a Beacon App. Additionally, there isn't any user-defined tags that are broadcasts, so I can only use the Beacon with one Android Phone (I'm able to see Eddystone-UID and AltBeacon). With this limitation I can theoretically only track two Android phones. I have one IPhone in the house, and that one can be tracked without a beacon app. I'm unable to see iBeacons broadcast from the app.

                          Maybe this project will help your efforts?

                          Crossing fingers.

                          Comment

                          Working...
                          X