esphome
BMI270 on the M5stack Atom S3R
Describe the problem you have/What new integration you would like I would like to be able to get data via I2C from the BMI270 sensor. We currently only have the BMI160 (https://esphome.io/components/sensor/bmi160.html) and the BMI270 may be similar.
Please describe your use case for this integration and alternatives you've tried:
Tried the BMI160 component but get Communication with BMI160 failed!
Additional context There is a component here: https://components.espressif.com/components/espressif2022/bmi270/versions/1.1.0?language=en and it is being used on the Atom S3R: https://docs.m5stack.com/en/core/AtomS3R. Documentation from Bosch here: https://www.bosch-sensortec.com/products/motion-sensors/imus/bmi270/
I am unsure on how the BMM150 works that is integrated in the particular device and how it behaves together with the BMI270.
The I2C address is 0x68
My apologies I forgot to mention I am wanting to use it in combination with the M5stack IMU Pro Mini unit that includes BMI270, BMM150, and BMP280 sensors.
https://shop.m5stack.com/products/6-dof-imu-pro-mini-unit-bmi270-bmm150-bmp280
The BMI270 is documented pretty well here: https://github.com/boschsensortec/BMI270_SensorAPI/blob/master/bmi270_context.c as well as adapted here: https://github.com/m5stack/M5Unified/blob/master/src/utility/imu/BMI270_Class.hpp (The stacked BMM150 is also well defined in the M5Unified library).
I got everything working in esphome leveraging the M5Unified library, but natively would be better without the dependency.
+1 for this feature, I have a AtomS3R and the BMI270 support would be useful.
+1 for this feature, I have a AtomS3R and the BMI270 support would be useful.
Leveraging the M5Unified library I have it working flawlessly with an external component. Problem is, that once you use the M5Unified library other stuff stops working (e.g. you can't use the display), since M5 does a lot of initialization in their code that isn't compatible with other esphome stuff.
That's why I'm trying to implement this natively, but it is quite complicated given the complicated sensor. Working on it 😉
@DennisGaida I plan on using this with just an M5 stamp s3 - perhaps the M5Unified library will work for that...
That said, I came across this in my searching - and will review it as well if I have to:
https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/bmi270-vs-bmi160-PCC4Jiu8I2R9hWK
Yeah it's all open source, I am currently reverse engineering what the M5Unified library is doing, specifically this: https://github.com/m5stack/M5Unified/blob/master/src/utility/imu/BMI270_Class.cpp - it is "just" a matter of removing the extra stuff M5 is doing.
Once I get a bit more cleaner version of everything I'll publish - the M5Unified version leveraging their library (breaking some esphome-native things such as display), and the native version with custom components.
If it is of any help there is this code: https://github.com/kkuphal/m5stick-esphome-magnetometer-water-meter/tree/main
I'm done with the esphome implementation and will upload to GH next week. Not happy yet in how to integrate the BMI270 and the BMM150 since they are stacked on top of each other with the Atom S3R and probably not other devices, but will publish a working version for the Atom S3R and if people tell me how to adjust for other M5 devices I can surely add that.
I'm done with the esphome implementation and will upload to GH next week. Not happy yet in how to integrate the BMI270 and the BMM150 since they are stacked on top of each other with the Atom S3R and probably not other devices, but will publish a working version for the Atom S3R and if people tell me how to adjust for other M5 devices I can surely add that.
Did you create a PR to share your work?
@lboue yeah you know how it is... I really didn't find the time to clean stuff up but I have been running the S3R happily since 8 month already.
Everything is working in this repo https://github.com/DennisGaida/m5stack-atoms3r-components, but clean it is not and also not possible to add as a PR to esphome as there are some unknowns such as should I create two sensors (BMI270 & BMM150) or a compound sensor or both etc.
In the repo you'll find multiple components (most of them are just commented out in the .yaml) and they are all working, i.e. the gyro, acceleration, the display and everything else (the temperature sensor on the IMM150 is working but doesn't make sense since the chip is wrapped in plastic and is generating some heat - the temperature means nothing 😉 )
The repo in its current state I use as a MS Teams status monitor or busylight, i.e. it shows whether I am in a call or not, so I am currently not using the mag/gyro and acceleration part of the M5Stack S3R.
@DennisGaida It seems that for Arduino, the library contains both, so why not do the same? Do you think you can publish your component directly in the main ESPHome code? If you try, you'll get comments to help you with the review.
Thanks for creating this @DennisGaida ! I've just gone to use it to read the IMU on the Arduino Nesso N1 (a collaboration between Arduino and M5Stack) but it doesn't have the BMM150; so my suggestion to your question about whether those two devices should be bundled or not - preferably not!
Are there any specific things you're doing to combine results from both sensors such that separating them into distinct components would be problematic?
Are there any specific things you're doing to combine results from both sensors such that separating them into distinct components would be problematic?
No, not at all. But since I only reverse engineered the code from the M5stack libraries, I didn't particularly take care to separate the two sensors properly. But very good input - this means the sensors should definitely be separated since they do come without each other. I was just happy that everything works, so that's the state of things we are now.
(Awesome you are trying out the Nesso N1, saw this the other day and it looks enticing also including the LoRa networking stack)