If this is your first visit, be sure to check out the FAQ. You must register before you can post. Your first post will be checked for appropriate content
(SPAM) - please allow a bit of time for that. After that, you'll be able to post at will!

As a project manager I believe in bringing stake holders together. Maybe we can have a productive collaborative discussion on what would be great to see implemented. I’d love to see a solution where the ESP’s all talk to each other and a plug-in on homeseer that can maintain it all. Maybe even a graphical depiction of the property and where the devices are. Maybe it could work in tandem with ip monitoring. Maybe in conjunction with the arduino plugin using the extra pins and power of the esp32. I was going to use an ESP8266 for the alarm in my garage but would be putting an esp32 out there for this application anyway. There’s even an esp32 camera dev board out there now. Lots of possibilities. To start, I wasn’t to keep tags in my vehicle and a receiver that picks them up and tells homeseer. Honestly there’s an opportunity for an overall occupancy plugin that does it all and more integrating Bayesian math like what’s on homeseer. Have at it devs.

Comment

MattL0 & risquare
This thread was started with a request to try the ESP32 as a BLE scanner. I believe the objectives of that thread was accomplished with the prototype work I did and related discussion. There were tangent discussion about the merits of BLE scanning, Happy Bubbles, Kalman filters and others.

One of the tangents that I found interesting to pursue is the implementation of position determination via BLE that would have effective use within HS. Anything I do in this area will be oriented to the capabilities provided or will be provided in mcsMQTT. Yes, there is a protocol component of MQTT that any MQTT plugin will be able to address. How a user integrates MQTT protocol is very specific to the plugin being used. The only thing that I can support with the integration is how to set it up in mcsMQTT.

I started MQTT with Tasmota. When I developed mcsMQTT I added provision that made integration between Tasmota and HS easier. When I started with zigbee2mqtt I found that that there are application-level features that could be added to mcsMQTT that made the integration with HS much more convenient. I expect to make the BLE scanning implementation compliant with MQTT protocol, but at the same time I can envision where things can be done in mcsMQTT that adds a layer of value beyond a simple conduit between MQTT and HS. How the integration occurs can only be done in the context of a specific plugin. It would be confusing to anybody using other MQTT plugins.

By spawning a new thread I am not shutting down this thread. If there is something the Big5 developers are doing with respect to BLE then this seems like a good place to capture it. If there is a BLE scanner in the marketplace that uses REST or something like Happy Bubbles that uses MQTT is something that is going to be pursued then again this is an appropriate place to continue the discussion of how Big5 would be setup to perform the integration. I suspect, however, that any specific discussion would open a new thread to address the specifics of that discussion.

I am using mcsMQTT as a segue to pursue things that I find interesting and sharing that interest with other Homeseer users. It is a learning experience for me. I get my rewards from the learning and sharing with others. There is no commercial interest. If the Big5 team desires to take the lead on this subject then I would be happy to support that effort, just as I did with the prototype which I fully shared.

Comment

Great. Thanks for sharing the results of your hard work. Few quick questions if you don’t mind.

1. Will it work with one receiver ESP32 per room if someone is willing to trade accuracy for simplicity? While ESP32 is inexpensive the installation, maintenance, management and control of 3 receivers per room can become a challenge.
2. Can iPhone be an acceptable beacon?
3. Does your software comply with MQTT standard incl Mosquito broker standard ports etc?
4. Are you going to provide all the code and libraries for ESP32 in .zip ?
5. Are you going to disclose the format of the MQTT messages?

Thanks,

Ivan

Comment

1. My testing is one floor with beacons near the corners. They seem to have a range of about 30-40 ft and my house is about 50 x 60 so detection is typically 3 of the 4 scanners.
2. Don't have iPhone
3. It talks standard MQTT. Since it is a redundant system with interchange of data between each ESP32 it would be hard to use without a front-end that is provided by mcsMQTT to organize all the data into information.
4.The source for ESP32 will be available
5. It it described in the manual segment I posted. It is JSON encoded and uses the pattern setup by Tasmota. There are some other topics that are not yet described but they will be.

Comment

1. Is there a typo? Did you mean scanners near the corners? Beacons are supposed to be in your pocket or the person's you want to track around the house. The scanners are supposed to be stationary in strategic places. So back to the original question. How many scanners ( I called them receivers in the original question) are needed. Take your home for example. If you are to track people within your home how many scanners will you need to cover the whole house plus reasonable outdoors coverage.

2. Say "smart phone" They all have BT don't they and you use BT for tracking correct?

3. I'm sure mcsMQTT is a great plug-in. I hear good things about it. Also very well documented. However in my case having two MQTTplug-ins is confusing for me. Can you explain what kind of processing is needed. Also the modern trends are to push the intelligence to the edge. So why bother HS3 (or mcsMQTT) with that. Can't ESP32 do that work and simply report upstream "John is in the kitchen" , well for easier processing by HS3 it may look like that 01=55 where 01 is the code assigned to John and 55 the code assigned to kitchen.

4. Thanks. I've done several ESP32 projects programmed by others. Unfortunately I'm not that familiar with the Arduino libraries and I typically fail when I try to compile just a piece of code. I always get errors about missing things. That's why packing your code with all ancillary libraries and necessary stuff will be essential for me and folks like me who are not proficient in Arduino.

5. Thanks. Looking forward to it.

Thanks,

Ivan

Comment

3. I'm sure mcsMQTT is a great plug-in. I hear good things about it. Also very well documented. However in my case having two MQTTplug-ins is confusing for me. Can you explain what kind of processing is needed. Also the modern trends are to push the intelligence to the edge. So why bother HS3 (or mcsMQTT) with that. Can't ESP32 do that work and simply report upstream "John is in the kitchen" , well for easier processing by HS3 it may look like that 01=55 where 01 is the code assigned to John and 55 the code assigned to kitchen.

Seems Michael was correct about it being confusing. I know my head is spinning.

1 like

Comment

1. You need to figure out your placement based upon the size of the area you are trying to cover. The algorithm I use provides evaluation based upon proximity to one, two, or three+ scanners/receivers. My beacons seem to have a range of about 30 feet. If all you want is if the beacon is somewhere within a 30 ft radius then one receiver/scanner placed in the middle of the area will give you 30 ft coverage. If you want better location information then you need to have two receivers/scanners within a 30 ft range. In this case you will have better location info if the beacon is somewhere between the two and your total coverage will be greater because you have 30 ft from each receiver/scanner. Extend this discussion to trilateration to get actual X/Y location and again your overall coverage increases but quality of location will only be where the beacon is within range of three.

2. I am using beacons for my testing. I have not tried any other bluetooth-compatible devices. My general understanding is that a phone only advertises its bluetooth address when it is put into pairing mode. After a pairing is completed then it is able to connect at a later time, but a bluetooth device can only have a single pairing. I am not an expert on this. This project is my first venture into bluetooth other than my AV receiver pairing to a Fire table for streaming music.

3. I suggest you look at the pdf and the screenshots I posted in the other thread I referenced. It contains the context and detail you are asking. In the end you are getting getting a report of the X/Y coordinates of every beacon which was graphically displayed in the other thread's screenshot. Beacons report via MAC address. Don't you prefer to see a friendly name in the MQTT topic for a beacon? How do you tell the ESP32 what that friendly name is? You could do it within HS, but in the spirit of offloading to the ESP32 then the ESP32 needs to be told friendly names.

You will find several spurious MAC addresses reported and over time this will fill the ESP32 allocated memory of 50 beacons. It will also result in many beacons being reported that just loads the network with no value. Don't you want to tell the ESP32 which are good and which should be ignored? Different beacons have different transmit power. The ESP32 needs to be told the power level of the beacon so it can make a good evaluation of relative distance. These are just some examples of the management functions that are necessary for the user to interact. mcsMQTT provides a point and click approach to doing this. It could also be done with a set of script-like functions that would be used by Big5. The pdf provides the definiition of all the topics available/needed to communicate with the ESP32.

With a redundant system it is important that each element of the system has the same information so the same location decisions can be made. It is hard to look at a volume of data to assess what each ESP32 is seeing unless it is organized in a manner that make any variance visible. Stuff happens as not everything will be perfect for one reason or another. One needs tools to understand what is what.

4. I use PlatformIO and VSCode for the ESP32 development. What I will zip-up is the same set of files that I started from Tasmota GitHub including the changes I made for the bluetooth function. I believe almost everybody will be using the pre-compiled binary. There will be no need to modify source code.