But you do have some plants, don’t you? At least I hope so.
If you send me your paypal mail address, I’ll happily sponsor one MiFlora sensor for you (or the project itself). Or put the sensor on your amazon wish list and send me the link.
If someone else wants to step in, be my guest and order one of the other two sensors for @Magalex.
On a side note: I just checked, and couldn’t find a russian amazon page… I searched google and found some interesting articles about online retail in Russia… You do have a seller for these products, don’t you?
Yes, I have sellers, but I won’t accept the money, because I don’t see the need for it, since it is unlikely that it will speed up the process. I already received LYWSD02 dump. Probably I’ll get the rest while I’m tinkering with it. Thanks for the suggestion!
That’s alright, but I should have made that clearer. It’s not to speed up the project, it’s a simple Thank You for the work you have already done. What comes in the future is for all of us to see!
If you installed the component via HACS, then you can take part in testing, if on the component’s page in HACS enable “Show beta” (a “three dots menu” in the upper right corner of the page).
It would be really nice to have something, like miflora-mqtt-daemon, that you can install on a another, distant Pi as an example, which would send the data through MQTT. That way, you can have those sensors at some distant places.
Unfortunately, it is seems like LYWSD02 sensor does not broadcasts information about the battery. I have BT dumps from two different people with several sensors of this type, and none of them have battery information… In any case, if the sensor suddenly informs about the battery, then you will see this, since the Xiaomi service data format is generally the same for all such sensors, and processed regardless of sensor type
I’m trying to connect MJ_HT_V1 and LYWSD02 for more than two hours with no success It does not work through neither built-in integration (no data), nor via this custom component (no entities created). Any help would be highly appreciated!
I have RPi 4 + ssd + docker + hassio setup and don’t use any other bluetooth integrations. I have just started playing with HA so I don’t have much components/integrations either.
pi@hassio:~ $ apt show bluetooth -a
pi@hassio:~ $ apt show bluetooth -a
Package: bluetooth
Version: 5.50-1+rpt1
Priority: optional
Section: admin
Source: bluez
Maintainer: Debian Bluetooth Maintainers <[email protected]>
Installed-Size: 70.7 kB
Depends: bluez
Suggests: bluez-cups, bluez-obexd
Homepage: http://www.bluez.org
Download-Size: 43.0 kB
APT-Sources: http://archive.raspberrypi.org/debian buster/main armhf Packages
Description: Bluetooth support (metapackage)
This package provides all of the different plugins supported
by the Bluez bluetooth stack.
Package: bluetooth
Version: 5.50-1
Priority: optional
Section: admin
Source: bluez
Maintainer: Debian Bluetooth Maintainers <[email protected]>
Installed-Size: 70.7 kB
Depends: bluez
Suggests: bluez-cups, bluez-obexd
Homepage: http://www.bluez.org
Tag: role::dummy
Download-Size: 42.9 kB
APT-Sources: http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
Description: Bluetooth support (metapackage)
This package provides all of the different plugins supported
by the Bluez bluetooth stack.
pi@hassio:~ $ apt show bluez -a
pi@hassio:~ $ apt show bluez -a
Package: bluez
Version: 5.50-1+rpt1
Priority: optional
Section: admin
Maintainer: Debian Bluetooth Maintainers <[email protected]>
Installed-Size: 3,680 kB
Depends: libasound2 (>= 1.0.17), libc6 (>= 2.28), libdbus-1-3 (>= 1.9.14), libdw1 (>= 0.127), libglib2.0-0 (>= 2.31.8), libreadline7 (>= 6.0), libudev1 (>= 196), kmod, udev, lsb-base, dbus
Suggests: pulseaudio-module-bluetooth
Conflicts: bluez-audio (<= 3.36-3), bluez-utils (<= 3.36-3)
Breaks: udev (<< 170-1)
Replaces: bluez-audio (<= 3.36-3), bluez-input, bluez-network, bluez-serial, bluez-utils (<= 3.36-3), udev (<< 170-1)
Homepage: http://www.bluez.org
Download-Size: 764 kB
APT-Manual-Installed: no
APT-Sources: http://archive.raspberrypi.org/debian buster/main armhf Packages
Description: Bluetooth tools and daemons
This package contains tools and system daemons for using Bluetooth devices.
.
BlueZ is the official Linux Bluetooth protocol stack. It is an Open Source
project distributed under GNU General Public License (GPL).
Package: bluez
Version: 5.50-1+b12
Priority: optional
Section: admin
Source: bluez (5.50-1)
Maintainer: Debian Bluetooth Maintainers <[email protected]>
Installed-Size: 3,681 kB
Depends: libasound2 (>= 1.0.17), libc6 (>= 2.28), libdbus-1-3 (>= 1.9.14), libdw1 (>= 0.127), libglib2.0-0 (>= 2.31.8), libreadline7 (>= 6.0), libudev1 (>= 196), kmod, udev, lsb-base, dbus
Suggests: pulseaudio-module-bluetooth
Conflicts: bluez-audio (<= 3.36-3), bluez-utils (<= 3.36-3)
Breaks: udev (<< 170-1)
Replaces: bluez-audio (<= 3.36-3), bluez-input, bluez-network, bluez-serial, bluez-utils (<= 3.36-3), udev (<< 170-1)
Homepage: http://www.bluez.org
Download-Size: 763 kB
APT-Sources: http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
Description: Bluetooth tools and daemons
This package contains tools and system daemons for using Bluetooth devices.
.
BlueZ is the official Linux Bluetooth protocol stack. It is an Open Source
project distributed under GNU General Public License (GPL).
How far sensors from HA host? (at the time of installation it is worth placing them closer if they are far)
Please check also, that the hcidump utility is installed (required for the custom component to work).
It should also be remembered that the custom component creates entities only upon receipt of data, that is, it takes at least one period (60 seconds by default) - you should wait a few minutes.
It may be worth doing all the points from the installation instructions (including those that are not required for hassio).
I don’t know what else to help… Enable debugging for the component and see the logs:
Thanks for such quick response!
It seems that distance indeed was the key because I have everything already set up like you just said. It was not so obvious to me because I my xiaomi sensor was just 3 meters from RPi and it was visible when running hcitool lescan manually.
I placed one next to each other and it was recognised flawlessly.
Thank you so much!
PS It seems that either BT radio is somehow weak in RPi 4 or because of some interferences (ConBee, WiFi, SSD) it has less range than my RPi Zero.
The custom component has a longer range, since it just listens. If it does not provide the desired range, then it is worth look at options with external bluetooth or device with ESPHome as intermediate (I’m just testing ESPHome on ESP32 - pretty reliable solution for far placed sensors).
I’m testing custom component It stops reading sensor data even if I move it like 1.5-2 meters from the RPi. That is probably caused by interference from other radios.
I am about to play with ESP8266 or Arduino + HM-10 BT module and set up OpenMQTTGateway. I may also go with bt-mqtt-gateway on RPi 1 or RPi Zero that I own. It looks promising and I will definitely need much more range than a few meters
I have also external BT USB dongle from my older RPi, but I’m afraid that it may negatively affect ConBee. That’s why I will probably try to go other solutions that will hopefully work stably as standalone units – “set it and forget it”.
Unfortunately, no. There are dumps, but everything is complicated there… The format is different from what we saw before. Here is a discussion on this.
I confirm this behaviour after moving from rp3 to rp4. Previously sensors were working from tens of meters and now they need to be almost next to raspi
It does not work through neither built-in integration (no data), nor via this custom component (no entities created). Any help would be highly appreciated!