ESPresense
Integration with ESPHome
Is your feature request related to a problem? Please describe. Is there any way to have this project play more nicely with ESPHome? I find that I want two ESP32's in each room because of features on both of these projects. There is likely interest on the other side as well.
Describe the solution you'd like Perhaps ESPHome compatibility built into this project such that various sensors and outputs can be interacted with through the ESPHome ecosystem? Or an official plugin for ESPHome from the contributors of this project?
Describe alternatives you've considered 2 ESP32s in one room.
Additional context None
I'm hoping to add ESPresence-enabled ESP32's to my home for pet/asset tracking as well as ESPHome-enabled ESP32's for temp + humidity monitoring and PIR motion detection. Using two ESP32's per room for this would be wasteful, so I too would love to see this added.
I'm hoping to add ESPresence-enabled ESP32's to my home for pet/asset tracking as well as ESPHome-enabled ESP32's for temp + humidity monitoring and PIR motion detection. Using two ESP32's per room for this would be wasteful, so I too would love to see this added.
That's exactly the reason I implemented temp + humidity + pir + radar sensor support into ESPresence. :) https://github.com/ESPresense/ESPresense/pull/54 https://github.com/ESPresense/ESPresense/pull/48
coming this week:
- lux sensor
If you need other sensors, just let us know.
That's exactly the reason I implemented temp + humidity + pir + radar sensor support into ESPresence. :)
@corgan2222 Awesome, is there any documentation you can refer me to in order to learn more? I wasn't able to find any mention of this functionality in the ESPresense docs.
Though this is a fantastic addition to this project, ESPHome still has a considerable benefit of its huge catalog of supported sensor types, and its flexible configuration approach. So I'll certainly plan to make use of your recently added functionality, but I'll still keep this feature request open to hopefully encourage some more discussion on the topic and see if deeper integration might be possible.
PS. The DHT11 and DHT22 are some of the most popular temperature sensors out there, but they're not widely regarded as the most accurate (here is one random article outlining some comparisons). Would be great to see BMP280 / BME280 support added here as a holdover ;)
That's exactly the reason I implemented temp + humidity + pir + radar sensor support into ESPresence. :) #54 #48
coming this week:
- lux sensor
If you need other sensors, just let us know.
Thanks very much for the context. @travipross has touched on most of my follow up comments already.
I really appreciate that you've implemented those sensors to hold us through in leiu of ESPHome integration. Though I'd still love to see ESPhome integrate with ESPresense someday (or vice-versa) to reduce the amount of recurring development required for sensor integration.
That's exactly the reason I implemented temp + humidity + pir + radar sensor support into ESPresence. :)
@corgan2222 Awesome, is there any documentation you can refer me to in order to learn more? I wasn't able to find any mention of this functionality in the ESPresense docs.
Though this is a fantastic addition to this project, ESPHome still has a considerable benefit of its huge catalog of supported sensor types, and its flexible configuration approach. So I'll certainly plan to make use of your recently added functionality, but I'll still keep this feature request open to hopefully encourage some more discussion on the topic and see if deeper integration might be possible.
PS. The DHT11 and DHT22 are some of the most popular temperature sensors out there, but they're not widely regarded as the most accurate (here is one random article outlining some comparisons). Would be great to see BMP280 / BME280 support added here as a holdover ;)
ATM there are only these both push-request where you can find some infos. But I have planned to write some kind of documentation this week. I have to look, if i have some of these BMP280 / BME280 somewhere in my boxes.
I have zero knowledge about how ESPHome works and how hard is it, to implement ESPresense into it. Every time i tried to do something with it, I wanted to toss it out of the window. So I personally don't have plans to spend time on this. Actually its @DTTerastar project, maybe he wants to take a look.
But I can absolutely understand your needs to have only one device in each room, what can do everything. That was the reason to implement the sensors in the first place.
I think it will be difficult to do all the things we do inside of ESPHome. It will definitely need to be paired down. It is totally worth trying to do in a fork, but i'm not up for it at the moment.
I'm hoping to add ESPresence-enabled ESP32's to my home for pet/asset tracking as well as ESPHome-enabled ESP32's for temp + humidity monitoring and PIR motion detection. Using two ESP32's per room for this would be wasteful, so I too would love to see this added.
That's exactly the reason I implemented temp + humidity + pir + radar sensor support into ESPresence. :) #54 #48
coming this week:
- lux sensor
If you need other sensors, just let us know.
With PIR, lux, DHT and this... it's literally the perfect multi sensor. Just need a decent 3d printer model and a place to run power. Gotta smash the poll times on these cool sensors, no time for batteries. :)
I already have loads of zigbee motion, lux, and temp sensors... I do agree that FAST motion is something that Zigbee doesn't fully do well. I got the radar sensors, need to hook them up and see if they are better than pir.
I am in no way religious on which great development project to use, but would also love to only have one device per room running. Currently I heavily rely on esphome reading my Xiaomi BT humidity/temperature sensors (LYWSDCGQ and similar) as well as serving as an iBeacon (to trigger OwnTracks). Any chance this could be added to espresence?
Adding more querying and broadcasting will effect the amount of time we can spend listening for advertisements. It's all a fine balancing act. I would like to add iBeacon transmitting, but I don't want to add so much stuff that the core features are affected.
@corgan2222 Another vote for the addition of BME280 to this amazing project. If it helps, at the moment I am using ESP32-mqtt-room (PlatformIO) installed in ESP32 devices around the house for room detection, and I added a BME280 to one of them, this is the part added to report the temperature of the sensor (happy to share the entire code if needed):
#include <Adafruit_BME280.h>
Adafruit_BME280 bme; // I2C
bool sendBME280() {
if (debug) mqttClient.publish(debugTopic, 0, 0, "sendBME280 start");
StaticJsonDocument<256> BME280;
BME280["temperature"] = bme.readTemperature();
BME280["humidity"] = bme.readHumidity();
BME280["pressure"] = bme.readPressure() / 100.0F;
char BME280MessageBuffer[258];
serializeJson(BME280, BME280MessageBuffer);
if (mqttClient.publish(temperatureTopic, 0, 0, BME280MessageBuffer) == true) {
Serial.println("BME280 info sent");
if (debug) mqttClient.publish(debugTopic, 0, 0, "sendBME280 end");
return true;
} else {
Serial.println("Error sending BME280 info");
mqttClient.publish(errorTopic, 0, 0, "Error sending BME280 info");
if (debug) mqttClient.publish(debugTopic, 0, 0, "sendBME280 end");
return false;
}
}
Part added to the setup function:
// default settings
BME280_status = bme.begin();
// You can also pass in a Wire library object like &Wire2
// status = bme.begin(0x76, &Wire2)
if (!BME280_status) {
Serial.println("Could not find a valid BME280 sensor, check wiring, address, sensor ID!");
Serial.print("SensorID was: 0x"); Serial.println(bme.sensorID(),16);
Serial.print(" ID of 0xFF probably means a bad address, a BMP 180 or BMP 085\n");
Serial.print(" ID of 0x56-0x58 represents a BMP 280,\n");
Serial.print(" ID of 0x60 represents a BME 280.\n");
Serial.print(" ID of 0x61 represents a BME 680.\n");
//while (1) delay(10);
}
bme.setSampling(Adafruit_BME280::MODE_NORMAL,
Adafruit_BME280::SAMPLING_X16, // temperature
Adafruit_BME280::SAMPLING_X16, // pressure
Adafruit_BME280::SAMPLING_X16, // humidity
Adafruit_BME280::FILTER_X16,
//Adafruit_BME280::FILTER_OFF,
Adafruit_BME280::STANDBY_MS_0_5 );
This one: https://www.amazon.de/Hojffuue-Temperatur-Feuchtigkeit-AtmosphhRischer-Barometrisch/dp/B09CYCT4CN/ref=sr_1_1_sspa?adgrpid=72630429073 ?
This one: https://www.amazon.de/Hojffuue-Temperatur-Feuchtigkeit-AtmosphhRischer-Barometrisch/dp/B09CYCT4CN/ref=sr_1_1_sspa?adgrpid=72630429073 ?
No, that is the BMP280, the one I have is the BME280: https://www.amazon.de/BME280-Feuchte-Temperatur-Atmosph%C3%A4rendruck-Sensor-Modul-mit-IIC-Arduino/dp/B09CYXS3GX
I think the main difference between them is the BMP280 can only measure temperature and air pressure, while the BME280 can measure humidity in addition to temperature and air pressure, but I guess the same code should work with both of them (obviously removing the humidity part for the BMP280)
Ah, ok, I see. Didn't realize the BME/P difference. Here in Germany the single sensor is with €15 quite expensive compared with the BMP280. There is one for only €5 but can't deliver here. Will look on Ali later.
Ok, I guess you need the sensor to be able to test it, but just in case if you want to add the code before you receive the sensor, I am happy to test it for you
I have looked to do custom boards with BMP280, but it's a pain as looks like either have to buy a break out board (like from Adafruit and others), or know a distributor in China willing to sell them. If you don't care about pressure, check out the SHT40 as well.
I have the lux sensor working great. The DHT22 is not. I see it on the setup page, but is it working?
Never mind, I changed power from 5 to 3.3V and its working. The specs say 3-5V is ok...
I'm hoping to add ESPresence-enabled ESP32's to my home for pet/asset tracking as well as ESPHome-enabled ESP32's for temp + humidity monitoring and PIR motion detection. Using two ESP32's per room for this would be wasteful, so I too would love to see this added.
That's exactly the reason I implemented temp + humidity + pir + radar sensor support into ESPresence. :) #54 #48 coming this week:
- lux sensor
If you need other sensors, just let us know.
With PIR, lux, DHT and this... it's literally the perfect multi sensor. Just need a decent 3d printer model and a place to run power. Gotta smash the poll times on these cool sensors, no time for batteries. :)
If you are looking for a great plugin case, I use these
https://www.polycase.com/plug-in-wall-plug-enclosures
If you are looking for a great plugin case, I use these
https://www.polycase.com/plug-in-wall-plug-enclosures
I have searched for this kind of plug/enclosure for Europe 220v, but couldn't find it. If you see the kind of plug for 220v, please let us know.
@travipross @FM-17 @corgan2222 given that BLE presence tracker exists on ESPHome: https://esphome.io/components/binary_sensor/ble_presence.html This is all about adding support for rooms to send MQTT specific messages? or may be the ESPHome already does that? I need to give it a try
@cpainchaud ESPresense also does MAC fingerprinting (which is necessary for devices that show up with variable MAC addresses) and adds a kalman filter (which should greatly improve accuracy).
As far as I can tell, ESPHome doesn't do any of that, so it would work less effectively and on a lesser number of devices.
I have to admit, from a security standpoint, ESPHome long term may be a safer place to be? Right now there's really no password protection or ssl, right? So anyone on the network can connect and make changes to ESPresense. What "keeps me up at night" is that the auto-update ability is awesome and I've been lazy and left it enabled, but if someone compromises an account for github and pushes a nefarious build, the devices will just run with it? My other option is to leave it disabled, then having to go to each device individually to update vs a push from Home Assistant. Just some things to think about that may or may not be warranted.
I love ESPresense, but I think in terms of management, unless the ESPresense team wants to write management abilities and deal with security, ESPhome could be a good place for it to be long term replacing or complimenting the limited ESPHome BLE abilities it currently has? Not looking to start a philosophical battle as truly appreciate the work the work the team here is doing, but just my .02.
While I use ESPHome, I do not think integration is worthwhile. ESPresence is so simple to deploy and manage. There is no need to add the complexity of ESPHome. ESP32 devices are so cheap that trying to create a platform that does everything is not needed.
While I use ESPHome, I do not think integration is worthwhile. ESPresence is so simple to deploy and manage. There is no need to add the complexity of ESPHome. ESP32 devices are so cheap that trying to create a platform that does everything is not needed.
I can see that but not sure I fully agree, I've got quite a few ESPHome devices around the house, and super simple to set them up and arguably takes less time as I don't need to connect via Wifi to configure them after being programmed (just create config, plug it in, upload and done). You end up with a device that's easy to manage, update, and "secure" (well relatively speaking.)
I'd actually argue the opposite is happening with feature creep in ESPresense as it's adding features like sensors and such which is making it more like ESPHome every time. This could be the goal of the project long term? I don't know. What worries me what will happen is there's going to be more and more "Can you support this sensor?" and ESPresense is going end up with kind of an unweildy interface losing what it was meant for and the developers are going to burn out trying to recreate what's already out there.
FWIW I am the kind of person that likes to DIY with a feeling of "I have to do this myself" and create and program for embedded boards (I've rolled quite a few custom boards in my day from PICs to Atmega board thru to the ESP32-S2). However starting to realizing things like ESPHome, Tasmota and Espurna eliminate the need for 1000s of variations on the same exact theme and eliminate projects dying because developers get burnt out trying to make everyone happy trying to add everything.
no need to add the complexity of ESPHome
@mjcumming Perhaps you're correct that it doesn't make sense to see all of ESPHome's functionality duplicated in this project. This project does one thing very well, while ESPHome has an enormous catalog of features that work very well, plus it includes a number of other features including encryption via native API instead of MQTT, Password protected OTA updates , a management dashboard interface, and many others.
Like @mloebl, I don't want to diminish any of the work of the devs on this project, as they've created some fantastic functionality. I just wonder if that functionality would be best ported over to be compatible with an already well-established ecosystem for ESP devices, one with an already large community of enthusiastic users and developers.
The MAC fingerprinting and kalman filtering in this project would make the ESPHome BLE component a suitable replacement, allowing users to have the best of both worlds.
Also:
ESP32 devices are so cheap
Though this may be true for a small number of devices, the cost adds up for enclosures, power supplies, cords, etc once you start duplicating devices in each room. I personally want to have an ESP in each room/area of my home which adds up to about 8 ESPs + accessories. If I wish to use any sensors in each of those units from ESPHome that aren't currently supported by ESPresense, then I'm immediately up to 16 ESPs + accessories. Just on principle, I think it'd be great to see one device do it all.
I completely agree with @travipross, combining the best of both worlds by adding the extra features of ESPresence into ESPHome would be the prefect solution to avoid duplication of devices in each room (unless for some reason this is impossible). If I was one of the ESPresence developers I would try to do this rather than burn myself out by trying to add hundreds of ESPHome features/sensors into ESPresence.
Good discussion - pros and cons with both approaches. The simplicity of this project, with web-based programming of the ESP is a great feature. Adding a few simple sensors for lux, temp, etc is an added bonus. ESP Home is much more complex and intimidating.
I think the real win for this project is developing the logic for better device location determination through training with a network of ESP BT sensors.
Good discussion - pros and cons with both approaches. The simplicity of this project, with web-based programming of the ESP is a great feature. Adding a few simple sensors for lux, temp, etc is an added bonus. ESP Home is much more complex and intimidating.
I think the real win for this project is developing the logic for better device location determination through training with a network of ESP BT sensors.
Totally agree, I think as mentioned above, the best case scenario would be if we could have both the update to ESPHome and a standalone ESPresense using the same code base for the BLE Detection.
To be completely honest, I much prefer how ESPresense handles trackers at the MQTT level and sending any found devices than when I last looked into ESPHome as it required it at the device level it looked like (so you add a whitelist of MAC addresses at each ESPHome device.) However I really miss the central ability of management I get with ESPHome. I am being greedy I guess and want both :D
I completely agree with the idea that ESPresense has advantages over ESPhome, this was likely the motivation for suggesting their collaboration initially. It is a shame that the two cannot coexist on one ESP32 though, as I'd love to make use of ESPresense's accuracy without sacrificing any of the ESPHome features im currently using.
On the other hand, simplicity is nice, why change what is already working for some?
Sure, ESPHome is modular and therefore only as complex as you make it, but not all users want to spend an additional two hours climbing the learning curve just to gain some flexibility. Similarly, its not realistic to expect those who appreciate ESPresense's simplicity to maintain a fork of it while the main branch becomes cog in a much larger, more comprehensive system.
ESPresense was fun to experiment with, I'm going to miss it after switching back. I just hope that when ESPHome does implement similar functionality, it's done in collaboration with the amazing ESPresense developers, as I'd hate to see such great work be overshadowed by an inferior implementation.