@ahpohl Was there a specific reason for removing the battery_level from the hhccjcy01 or was it just a mistake and overlooked?

Does this device broadcast the battery level? If it does, than the battery level was removed by mistake and I do apologise. I do not have such a device for testing.

I also do not have one but others have said it was working before 1.15.0 which is when this was finally released.
Everyone makes mistakes =)

HHCCJCY01 has no battery info since firmware v3.2.1
Devices with older firmware broadcast battery leve. The new ones don't.

https://github.com/custom-components/sensor.mitemp_bt

HHCCJCY01 has no battery info since firmware v3.2.1

Thanks for clarifying. In that case it is better to continue supporting the battery level info for the older firmware.
PR has been merged so issue is fixed in esphome-dev.

Thanks @javicalle

Just to keep original reference: esphome/issues#107 (comment)

Hi all, It seems that these sensor no longer work with esphome, friend and I purchase a few at the beginning of the year that work perfectly which was listed under the HHCCJCY0. We recently purchase new units same make and model but the different was in the mac address with starting digits C4:7C:8D:xx:xx:xx, previous ones were 80:EA:CA:xx:xx:xx. the new unit get detected by the BLE tracker show up as Flower Care but no date is transmitted or seen by esphome. All 4 new units same make model different supplier.

@pablobolomey Could you please enable verbose logging output so I can see what the new HHCCJCY0 sensors are broadcasting. It could be that Xiaomi has changed something in the device firmware which makes it incompatible with esphome. If possible use current esphome-dev so we have the same version.

logger:
  level: VERY_VERBOSE

Hi @ahpohl , I have same sort of problems with Mi Flora ESPHome as @pablobolomey but come to different experience :

I have 5 Mi Floras (Xiaomi_hhccjcy01 devices) with a esp32doit-devkit-v1 connected and they were working fine till recently. One with 80:EA:CA:xx:xx:xx and 4 with C4:7C:8D:xx:xx:xx addresses, also with 2 different firmwares (versions 3.2.2 and 3.2.4).

Working fine although battery didn't last a year (as promised by Mi Flora adds) but only 2-3 months. There my problems start; after battery changes in some of the Mi Flora's, they (some) didn't came back in the ESPHome setup (two with C4:7C:8D:xx:xx:xx addresses). I also could not trace them in the ESPhome log.

Strange thing: I see 4 of my 5 Mi Flora's back in original Android App "Flower Care" and in an open source app "Watchflower". The one with address 80:EA:CA:xx:xx:xx is not available ("Offline") in the apps but is present in ESPHome!! And two others (as told above) not in ESPhome.
But the ones with firmware version 3.2.2 are available in ESPHome and the ones with firmware version 3.2.4 not. Of one Mi Flora I currently cannot see the version number but I thought it was firmware version 3.2.2.
I also suspect (but are not sure) the accompanying app "Flower Care" of pushing an firmware update wihout my knowledge or approval.

In a "BLE Scanner" app I can see all 5 of them alive with some sort of advertising! I drives me nuts!! It looks like a battery change is sometimes lethal for BLE communication, or Mi Flora devices change BLE communication parameters for some reason.

So I also would like to test the ESPHome setup and BLE behaviour further, as I want to expand my range of Mi Flora's and use ESPHome with this (already made an order for Mi Floras before all of this happened).

My question; I tried to reflash my esp32doit-devkit-v1 in ESPHome (dev version) with "logger: level: VERY_VERBOSE" but it gives compile errors. I can use (compile) with level: VERBOSE (and this works) but not with VERY_VERBOSE (compile errors) and no working firmware. Are you sure VERY_VERBOSE works with current dev level?

Other question: would it be helpfull to change some of the "esp32_ble_tracker: scan_parameters:" ? The BLE communication between devices seems to me much more complicated then first expected.

Sorry for my long message, but thanks for any help!

EDIT: The "logger: level: VERY_VERBOSE" does not work in the non dev version also.

Hi, I have the same problem with my Mi Flora also with c4: in the beginning of the MAC.
I can't run logger VERY_VERBOSE when I flash it with this it won't connect to the WiFi.

Still having compile issues with VERY_VERBOSE logging?

Link to esphome-dev documentation preview: https://deploy-preview-777--esphome.netlify.app/components/sensor/xiaomi_ble.html
Minimal Miflora config (I tried it on esphome-dev and it compiles without errors):

esphome:
  name: espressif
  platform: ESP32
  board: nodemcu-32s 

wifi:
  ssid: "your SSID"
  password: "your password"

api:

logger:
  level: VERY_VERBOSE

ota:

esp32_ble_tracker:
  scan_parameters:
    window: 120ms

sensor:
  - platform: xiaomi_hhccjcy01
    mac_address: '94:2B:FF:5C:91:61'
    temperature:
      name: "Xiaomi HHCCJCY01 Temperature"
    moisture:
      name: "Xiaomi HHCCJCY01 Moisture"
    illuminance:
      name: "Xiaomi HHCCJCY01 Illuminance"
    conductivity:
      name: "Xiaomi HHCCJCY01 Soil Conductivity"
    battery_level:
      name: "Xiaomi HHCCJCY01 Battery Level"

For testing purposes you could just add one of the sensors which do not show up anymore and paste the relevant parts of the debug output here. Having just one sensor improves stability with VERBOSE_LOGGING. You could also try to lower the window parameter to 60 or 30 ms and see if that helps improving stability.

Hi! I fix my problem with the MAC of C4:... by upgrading the Firmware to 3.2.1. Than I get it both in the Flower Care and in the HA.

How did you upgrade the firmware Pablo
…

Hi, I use the Flower Care app. The app found the C4 without problem and than you can Hardware settings and Upgrade.

Hi @ahpohl, seems I use a different esp board (DOIT ESP32) , mine here.

Followed your advise so my yaml is:

esphome:
  name: flora_keuken
  platform: ESP32
  board: esp32doit-devkit-v1

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

esp32_ble_tracker: 
    
# Enable logging
logger:
  level: VERY_VERBOSE

# Enable Home Assistant API
api:
  password: !secret api_password

# Enable Over the Air updates
ota:
  password: !secret ota_password

# status_led esphome: warning=slow blink, error=fast blink, normal=off
status_led:
  pin: GPIO2 
  
sensor:
  - platform: xiaomi_hhccjcy01
    mac_address: c4:7c:8d:6b:47:a3
    temperature:
      name: "Calathea Crocata Temperature"
    moisture:
      name: "Calathea Crocata Moisture"
    illuminance:
      name: "Calathea Crocata Illuminance"
    conductivity:
      name: "Calathea Crocata Conductivity"

When I compile this (dev and current version) with VERY_VERBOSE my compile error is this

Without VERY_VERBOSE it compiles and runs without problem.

Didn't try to compile it yet as "board: nodemcu-32s".

EDIT: I tried to compile it with "board: nodecmu-32s" in the .yaml but this gives the same error. Error in the line "compiling/..../esp32-hal-i2c.c.o".

Hi! I fix my problem with the MAC of C4:... by upgrading the Firmware to 3.2.1. Than I get it both in the Flower Care and in the HA.

Mine are firmware versions 3.2.2 and 3.2.4. I see 4 of 5 in Flower Care (no relation to mac address it seems), but I cannot upgrade them using Flower Care > Hardware > Upgrade.

Recently I started using the Watchflower app (in Android) which is open source and doesn't use any cloud service in China. I really like this app as it gives IMHO a better view and less hassle. But of course there is no upgrade possibility.

My experiences with firmware 3.2.4 are so far (they behave flakey) that I really would like to downgrade Mi Floras to 3.2.2 but that seems impossible. I also tried to write the company (for help) on it's email adres (which is in playstore: kefu@) but it doesn't exist (anymore?). So be carefull to upgrade as there is no way back (never found a way to reset the Mi Flora's).

BTW, my Mi Flora's are international ones and bought here.

All this experimentation seems to have awakened the 2 'sleeping' (in ESPHome) Mi Floras more or less.

To add some info... (for insight)

Perhaps this histogram gives some idea about the behaviour. It's a temp. histogram of plants in the same room. You can see that some advertise very often (Cal Roseopicta, Epipremnum), one advertises incendental (Spathiphyllum), some switch from often to incidental (Cal. crocata, Zamioculcas). The last ones where the sleeping ones (disappeared in ESPHome).

I've addes the firmware versions to the names, and the only one with mac 80:ea;ca, others have C4:7C:8D addresses.

It is quite difficult for me to pinpoint what is going on from the data, and it all started after few battery changes (e.g. the Epipremnum, the other battery changes I forgot).

And to add to this is that ESPHome listens passively to the BLE advertisements, but the apps Flower Care and Watchflower do interactions with the devices and request info.

When I compile this (dev and current version) with VERY_VERBOSE my compile error is this

The compilation output looks fine and the firmware file was produced and uploaded correctly. It couldn't connect directly afterwards due to wifi not fully connected yet. Sometimes it will take some time until wifi is connected after firmware upload. To get the debug output later you just do

esphome config.yaml logs

and select the serial console (if connected) or via network. Altenatively, you could use any terminal program (picocom or minicom with 115200 baud) where you are able to dump the output to a file.

The compilation output looks fine and the firmware file was produced and uploaded correctly. It couldn't connect directly afterwards due to wifi not fully connected yet. Sometimes it will take some time until wifi is connected after firmware upload.

Sadly it never starts, an endless queue of "WARNING: Initial connection Failed" follows.
Excuse, you are right, after a minute or so my board came on again. Thanks!

To get the debug output later you just do

esphome config.yaml logs

and select the serial console (if connected) or via network. Altenatively, you could use any terminal program (picocom or minicom with 115200 baud) where you are able to dump the output to a file.

Sorry, I'm not sure how to do that in the ESPHome add-on in HASSIO.
Probably I need to make an ESPHome setup in a docker, isn't it? That I have to postpone to later I'm afraid.

Thanks for the reaction.

Can you guys please move this chat to an issue