[Bug]: HHCCJCY10 only updates once an hour

[MassiPi]

What happened?

Hello,
just added two soil moisture sensors to my home assistant installation. I know the embedded Xiaomi BLE integration shows values only once an hour, so i installed this BLE passive monitor to see values every minute.
This is not happening since i still see values updated only once an hour and i have no idea why.
I tried changing the "period" setting down to 1 second, no change.

Sensor type

HHCCJCY10 soil moisture sensor

Relevant log output

No relevant log

[Ernst79]

I have no idea, but as a first test, you could enable debug logging for the Bluetooth integration at debug level and check how often you receive a BLE advertisement of the sensor. If you only receive one message an hour, the issue is on the sensor side, not on the receiving side (and that's my guess). If that is the case, try to see if adding it to the official app makes a difference. I know some sensors start broadcasting more frequent when added to the original app.

[MassiPi]

Hello Ernst :)
good try, let me understand how to enable debug and let's see :)
I'm not as convinced as you, since:

• the device in the documentation is reported as reporting every minute
• this onlin review seems to confirm this https://smarthomescene.com/reviews/xiaomi-miflora-plant-sensor-tuya-version-hhccjcy10-review/
• mainly, if i restart HA the device starts as "unknown", but very soon (yes, before one minute :)) it gets the value (i assume because it broadcasts something, but HA shows only one value per hour)

Thanks!

[Ernst79]

Could be that HA restores the state after a restart.

But it is strange that you receive data only once an hour, I agree. But it is strange that both BLE monitor and the core Xiaomi-ble integration only show data updates once an hour. That makes me think that it is something on the sensor side. Xiaomi-BLE and BLE monitor use different mechanisms to get the data. Please note that using them both at the same time could cause issues. If you use them both, make sure they both use either active scanning or passive scanning, as long as both use the same scanning mode.

You can use the logging of either the Bluetooth integration or from BLE monitor. Just enable debug logging (see https://www.home-assistant.io/integrations/logger/) at debug level for one of the integrations. After an hour, open the logbook of HA, copy it to a txt file and post it here, along with the MAC address of the sensor. I can check the logs for you, no problem.

[MassiPi]

in the log indeed it seems the sensor itself is not reporting that much.
But honestly i think i'm missing something in configuration,
Reason one and two: what i already wrote above, this sensor seems known to report every minute!
Reason three, when connected to the app it seems to report even more frequently, almost instantly, so it seems to be possible.
I tried tracking the sensor (and i have a lot of log) and also with active scan, but the behaviour is always the same
should i care of the basic "bluetooth" integration config? should i do something with xiaomi BLE integration to avoid overlapping?
i also tried with a brand new battery but nothing different..

[Ernst79]

Try a BLE sniffer on your phone first, just to check if the sensor is really not broadcasting every minute

[MassiPi]

I see a lot of traffic using a BLE sniffer on my phone, so the sensors are indeed doing something, but in HA logs i see messages only now and then..
i mean, i can survive having soil moisture once an hour, but since when i open the app i can see seconds (!!!) update, it means there is a way to ask the sensor to send values.
Do you know if there is a way to sniff BLE traffic with windows?

Did you here ( #809 (comment) ) concluded that "hourly update" was a matter of signal? That's strange, i have this behaviour having sensors side by side with the raspberry..

[Ernst79]

@ACrazyConcept seems to have similar issues. @ACrazyConcept did you ever got a response fro HHCC?

[MassiPi]

i left one sensor outside, in the soil, and put the other phisically on the raspberry, keeping SSD and skyconnect as far as possible.
RSSI are -79db for the outside sensor and -28 for the sensor on the raspberry
i get the very same behavior lol

BUT

maybe the problem is a little bit bigger, even if i can't understand if it's related with the extension itself or hardware related (raspberry hardware, i mean). Please let me explain.
As you suggested me, i tried with a BLE sniffer on my phone. ("BLE Scan data viewer)
It is full of logs of this kind of messages, that are exactly what you used to implement the sensor (2 sensor, 4 examples):

11:1C  
02 01 06 03 02 50 FD 0F 16 50 FD 49 00 00 08 4C 69 77 31 95 A1 1C C8 17 FF D0 07 00 00 01 00 F9 49 9C 85 07 00 00 AE 9B FD 13 09 C9 77 33 3F 05 09 54 59
11:66  
02 01 06 03 02 50 FD 0F 16 50 FD 49 00 00 08 B4 71 A8 B5 1B D9 4D D5 17 1F D0 07 00 00 01 00 57 DD B2 A0 9B D3 CB 9C 2C 65 9A 71 40 43 D8 CA 05 09 54 59
11:1C  
02 01 06 03 02 50 FD 0C 16 50 FD 12 00 C6 00 00 3F 4B 03 73 17 FF D0 07 00 00 01 00 F9 49 9C 85 07 00 00 AE 9B FD 13 09 C9 77 33 3F 05 09 54 59
11:66  
02 01 06 03 02 50 FD 0C 16 50 FD 1A 00 D3 00 00 36 30 03 5B 17 FF D0 07 00 00 01 00 57 DD B2 A0 9B D3 CB 9C 2C 65 9A 71 40 43 D8 CA 05 09 54 59

Full i mean that every sensor updates values every 10-20 seconds

But my point if that i can't see these message in the HA log, both of the standard bluetooth extension or of the passive bluetooth integration

So i can understand that if the system can't see the messages, it can't work them :)
But at this point the real question is.. why can it see one message per hour?

Any idea on how to debug this further?

Edit to add: the timing of the message i see in the sniffer seems coherent with the timings that were reported here ( #809 (comment) ), where was this log coming from?

Second edit: let me make an educated guess: are we filtering packets to have unique "packet ID"? are we sure the sensor can't use the same packet ID to send multiple values?

[Ernst79]

yes, that is the big question. Unfortunately, I don't have a clear answer.

The sensor seems to broadcast every 10-20 seconds, so no problem on the sensor side.
The problem seems to be on the receiving side.

Do you have other Bluetooth sensors? Are these working as expected?

The logs were from @ACrazyConcept

Yes, we are filtering to have unique packet ID's.

packet_id = data[4:13].hex()

But this is basically all data, so if one of the values changes, it should update all sensor data.

[MassiPi]

Probably i found something :)
i was looking my log and what you described here #809 (comment)
Length were not convincing me, so i looked at your hhcc.py and just added some more logging if length is not 13.

2023-10-15 21:05:03.701 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -28, MAC: DC:23:4D:E5:11:1C, ADV: 0f1650fd490000084c69773195a11cc8
2023-10-15 21:05:04.323 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -66, MAC: DC:23:4D:E5:11:66, ADV: 0f1650fd49000008b471a8b51bd94dd5
2023-10-15 21:05:05.329 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -61, MAC: DC:23:4D:E5:11:66, ADV: 0f1650fd49000008b471a8b51bd94dd5
2023-10-15 21:05:05.712 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -28, MAC: DC:23:4D:E5:11:1C, ADV: 0f1650fd490000084c69773195a11cc8
2023-10-15 21:05:06.334 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -69, MAC: DC:23:4D:E5:11:66, ADV: 0f1650fd49000008b471a8b51bd94dd5
2023-10-15 21:05:07.336 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -68, MAC: DC:23:4D:E5:11:66, ADV: 0f1650fd49000008b471a8b51bd94dd5
2023-10-15 21:05:08.336 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -61, MAC: DC:23:4D:E5:11:66, ADV: 0f1650fd49000008b471a8b51bd94dd5
2023-10-15 21:05:09.701 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -28, MAC: DC:23:4D:E5:11:1C, ADV: 0f1650fd490000084c69773195a11cc8
2023-10-15 21:05:10.329 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -67, MAC: DC:23:4D:E5:11:66, ADV: 0f1650fd49000008b471a8b51bd94dd5
2023-10-15 21:05:11.336 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -62, MAC: DC:23:4D:E5:11:66, ADV: 0f1650fd49000008b471a8b51bd94dd5
2023-10-15 21:05:11.708 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -28, MAC: DC:23:4D:E5:11:1C, ADV: 0f1650fd490000084c69773195a11cc8
2023-10-15 21:05:15.315 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -68, MAC: DC:23:4D:E5:11:66, ADV: 0f1650fd49000008b471a8b51bd94dd5
2023-10-15 21:05:17.325 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -69, MAC: DC:23:4D:E5:11:66, ADV: 0f1650fd49000008b471a8b51bd94dd5
2023-10-15 21:05:21.321 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -64, MAC: DC:23:4D:E5:11:66, ADV: 0f1650fd49000008b471a8b51bd94dd5
2023-10-15 21:05:22.332 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -68, MAC: DC:23:4D:E5:11:66, ADV: 0f1650fd49000008b471a8b51bd94dd5
2023-10-15 21:05:23.334 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -64, MAC: DC:23:4D:E5:11:66, ADV: 0f1650fd49000008b471a8b51bd94dd5
2023-10-15 21:05:28.321 WARNING (Thread-5) [custom_components.ble_monitor.ble_parser.hhcc] Wrong len waiting for HHCC packet: len 16, RSSI: -69, MAC: DC:23:4D:E5:11:66, ADV: 0f1650fd49000008b471a8b51bd94dd5

seems promising :)

[Ernst79]

Interesting. When I added this sensor, the data starting with 0F was the same in all messages, but not in your data, I’ll try to analyze it later.

[MassiPi]

wait i'm still digging :)
what i saw is that when a 0c arrives, that it's followed by a 0f, so for all where 0f there had to be the same 0c.
indeed it seems that 0f values do not change (dunno what it is used for, the above log is related with 2 different sensors), but ok so we receive also all 0c values (just pure debugging..)
The point they are not shown seems to be they are always the same O_O
I tried opening the app, looked for values to change and gone back to the log. No change in values. This is because when the app is open sensors do not advertise (!!). Probably they talk on pure BT with the app.
As soon as the app is closed, sensors start to advertise again and, as soon as values change, the value is in home assistant.
Honestly, it seems there is nothing wrong in your wonderful integration, it seems the sensor advertises new values every hour when not controlled by the app, so the "passive" part is correctly managed (static values are advertised every 10 seconds or so).
so probably this sensor could be actively read, but passively this is it. Let's hope this will save a little bit of battery, even if it seems it saves READING power, but not TRANSMITTING power
Now the question would be to understand why someone reports more frequent updates, i can't honestly imagine that.
Thanks Ernst, you are great :)

[ACrazyConcept]

@ACrazyConcept seems to have similar issues. @ACrazyConcept did you ever got a response fro HHCC?

Well, they suggested I use Tuya platform Bluetooth Hub...
I have not used these sensors since then because of this limitation.
But if more people contact them maybe they will come around. sw@hhcc.io