Xiaomi Mi Plants Monitor Flower

What is the range of these sensors? The server running HA is a room/floor away from most of my plants. I could add a BT adapter to the media center raspi, and send updates via mqtt (that would really make me wish for a proper distributed HA solution).

Depends a bit on the quality of your BTLE hardware. 1 wall might still work, but I can get a signal through 2 walls.
I will try to pimp the antenna of my NUC and Raspberry Pi.

My basil is now Twitter-enabled :wink:
https://twitter.com/danielspflanzen

Configuration here:
https://www.open-homeautomation.com/2016/08/31/let-your-plant-twitter-if-it-needs-to-be-watered/

It’s just a few very simple automation rules combined with the Twitter notify module.

5 Likes

@homeha: This is spinning out of control :wink:

HAHAH!

I love it. looks like you are remembering to water them :smiley:

@openha
i cloned your repo but am not having success with the miflora platform.

hass.log

16-09-09 01:28:34 miflora.miflora_poller: Waiting for 80 seconds before retrying
16-09-09 01:28:34 miflora.miflora_poller: Lock released
16-09-09 01:28:34 homeassistant.components.sensor.miflora: Polling error [Errno Could not read data from Mi Flora sensor %s] C4:7C:8D:60:BF:D1

16-09-09 01:06:47 homeassistant.loader: Loaded sensor.miflora from homeassistant.components.sensor.miflora
16-09-09 01:09:04 homeassistant.components.sensor.miflora: Polling error [Errno Could not read data from Mi Flora sensor %s] C4:7C:8D:60:BF:D1

hass outputs following to the terminal:

Send: 0x0d 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Send: 0x0d 0x00 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Recv: 0x14 0x01 0x00 0x01 0x02 0x53 0x06 0x22 0x04 0x04 0x51 0x01 0x02 0x1c 0x03 0x00 0x00 0x00 0x00 0x00 0x00 

and also this:

connect error: Transport endpoint is not connected (107)

does this ring any bells?

This looks like your PC can’t read from the sensor. Does “hcitool lescan” show the sensor?
If yes, you might still be connected with the Smartphone app to the sensor. Stop the App on your Smartphone.

You can simply try to read from command line:
gatttool --device=MAC_ADDRESS --char-read -a 0x35

it started working :slight_smile:
i hope this will be included in 0.28

i dont suppose you have instructions on how to install and use it?

What miflora files am i supposed to put where?

Does anyone have any idea what it means by ‘fertility’ ? How would the sensor even measure that?

From my understanding, it the Xiaomi measures conductivity in the soil. I did some shallow research on this a while back and what I gathered was that it was a known quick, but efficient, test amongst farmers to check soil conductivity to ensure that their crops would grow as expected. If the value was to low, they would apply more fertilizers.

Looks great. I just ordered one.

Yes, the “fertility” is just the conductivity. Therefore I have renamed it here.

@openha - i have three running, but the light sensors aren’t that great.

I grabbed a copy of the component from your github repo, and added it as a custom component. I think there was something wrong that i had to fiddle to get it work, and i was wondering if there are some improvements / fixes?

my lux levels are somewhere between 0 and 32 lux, which seems quite low…

any help would be great.

cheers,

I’ve never had this problem. Check with the iPhone/Android app what is displayed there.

Mhh. It’s not working for me. When I try to read the data I get:
pi@raspberrypi:~ $ gatttool --device=C4:7C:8D:60:BC:F6 --char-read -a 0x35 Characteristic value/descriptor: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Any ideas? Did they change the handle?

[quote=“mxtra, post:22, topic:3388, full:true”]
Mhh. It’s not working for me. When I try to read the data I get: pi@raspberrypi:~ $ gatttool --device=C4:7C:8D:60:BC:F6 --char-read -a 0x35Characteristic value/descriptor: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[/quote]
I have exactly the same problem, I think this happend after the Xiaomi-app updated the sensor firmware from 2.62 and 2.64 to 2.66 :frowning:

The Xiaomi-app still works an gets all sensor values!

I didn’t found any other handle, that might correspondent the needed values, but I didn’t checked all possible handlers.

So any idea how to get this running again?

BTW: During my investigations I found out where to get sensor firmware version and battery level:

Handle 0x38 gives me on three different sensors:
64 13 32 2e 36 2e 36
57 13 32 2e 36 2e 36
4f 13 32 2e 36 2e 36

If I look in the app, I can see, that the first byte is the battery-level, I get 100%, 87% and 79%.

I think this handle also returns the firmware version in the last 5 bytes as plain ASCII: “2.6.6”. In an other example it has “32 2e 36 2e 32” what would be “2.6.2” the initial firmware version!

Kind regards,

thgha

During the last days I logged every 10 min some other handles and wrote the results into a logfile. I have done this for three different sensors.

First all the “easy” ones, they do not change at all and are the same on all three sensors, while 0x03 is the name “Flower care” in ASCII:

0x02: Characteristic value/descriptor: 02 03 00 00 2a 
0x03: Characteristic value/descriptor: 46 6c 6f 77 65 72 20 63 61 72 65 
0x04: Characteristic value/descriptor: 02 05 00 01 2a 
0x05: Characteristic value/descriptor: 00 00 
0x06: Characteristic value/descriptor: 0a 07 00 02 2a 
0x07: Characteristic value/descriptor: 00 
0x08: Characteristic value/descriptor: 02 09 00 04 2a 
0x09: Characteristic value/descriptor: 0a 00 14 00 00 00 f4 01 
0x0e: Characteristic value/descriptor: 01 00 ff ff
0x15: Characteristic value/descriptor: 98 00 
0x1d: Characteristic value/descriptor: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x2f: Characteristic value/descriptor: 00 
0x31: Characteristic value/descriptor: fb 34 9b 5f 80 00 00 80 00 10 00 00 04 12 00 00
0x32: Characteristic value/descriptor: 0a 33 00 fb 34 9b 5f 80 00 00 80 00 10 00 00 00 1a 00 00
0x33: Characteristic value/descriptor: 00 00
0x34: Characteristic value/descriptor: 1a 35 00 fb 34 9b 5f 80 00 00 80 00 10 00 00 01 1a 00 00
0x37: Characteristic value/descriptor: 02 38 00 fb 34 9b 5f 80 00 00 80 00 10 00 00 02 1a 00 00
0x3c: Characteristic value/descriptor: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x3e: Characteristic value/descriptor: 00 00 00

Then there are two handles that stay the same, but are different on every sensor, I didn’t checked it, but probably s.th. like MAC, serial etc:

0x17: Characteristic value/descriptor: 18 f6 45 03 a2 13 97 bb a1 2c
      Characteristic value/descriptor: d6 85 2f 13 06 19 c6 c1 cb 3a
      Characteristic value/descriptor: 06 5d 64 8f b7 7b 85 79 42 d7 
0x1f: Characteristic value/descriptor: 29 d9 77 2e 97 49 a3 8a 9f 25 56 13
      Characteristic value/descriptor: e7 aa 1d 3e 33 43 f2 f0 f5 33 ff 49
      Characteristic value/descriptor: 37 72 56 a2 82 21 b1 48 7c de 09 68 

Then we have our values, 0x35 is empty in my case, 0x38 has battery-level and firmware version:

0x35: Characteristic value/descriptor: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x38: Characteristic value/descriptor: 52 13 32 2e 36 2e 36

By now, I do not think that they changed the handler for the above values, but may be you have so send a command or what ever, to get them.

Normaly, handle 0x35 should have values like the following:

Characteristic value/descriptor: d0 00 00 01 02 00 00 2f 6b 01 00 00 00 00 00 00
Characteristic value/descriptor: c9 00 00 23 01 00 00 19 42 01 00 00 00 00 00 00
Characteristic value/descriptor: cf 00 00 0d 00 00 00 1c f2 01 00 00 00 00 00 00
Characteristic value/descriptor: cb 00 00 00 00 00 00 1c 3c 02 00 00 00 00 00 00
Characteristic value/descriptor: e7 00 00 00 00 00 00 2a 00 02 00 00 00 00 00 00
Characteristic value/descriptor: ec 00 00 34 00 00 00 02 00 00 00 00 00 00 00 00
Characteristic value/descriptor: cb 00 00 00 00 00 00 1c 3c 02 00 00 00 00 00 00
Characteristic value/descriptor: cb 00 00 00 00 00 00 1c 3c 02 00 00 00 00 00 00
Characteristic value/descriptor: ec 00 00 34 00 00 00 02 00 00 00 00 00 00 00 00
Characteristic value/descriptor: cb 00 00 00 00 00 00 1c 37 02 00 00 00 00 00 00
Characteristic value/descriptor: cb 00 00 00 00 00 00 1c 3c 02 00 00 00 00 00 00

Next one is the handler 0x41, I’m quite sure, that this is a counter or s.th. similar, because it constantly increases it’s value (three or four bytes, MSB is on the right:

0x41:
14.10.2016,01:20:51 Characteristic value/descriptor: ab 0b 21 00
...
16.10.2016,22:30:01 Characteristic value/descriptor: 50 d1 24 00
0x41:
14.10.2016,01:20:51 Characteristic value/descriptor: 5c fa 03 00
...
16.10.2016,22:30:01 Characteristic value/descriptor: 31 c2 07 00
0x41:
14.10.2016,01:20:51 Characteristic value/descriptor: 3e f5 03 00
...
16.10.2016,22:30:01 Characteristic value/descriptor: 4c c0 07 00

OK and finally the is handler 0x12, no idea what this one is doing, it keeps it value for some hours, then changes, the value on all three sensors is different, only once for round about 12 hours, all three sensors had the same value: “ff ff ff ff”.

0x12:
14.10.2016,01:20:51 Characteristic value/descriptor: fa 1d 15 fb
...
14.10.2016,12:37:01 Characteristic value/descriptor: fa 1d 15 fb 
14.10.2016,12:47:01 connect error: Transport endpoint is not connected (107)
14.10.2016,12:57:01 Characteristic value/descriptor: 64 cb 3b 94 
...
15.10.2016,14:57:01 Characteristic value/descriptor: 64 cb 3b 94 
15.10.2016,15:07:01 Characteristic value/descriptor: 0f 49 7a f9
...
15.10.2016,22:07:01 Characteristic value/descriptor: 0f 49 7a f9 
15.10.2016,22:17:01 connect error: Transport endpoint is not connected (107)
15.10.2016,22:27:02 connect error: Transport endpoint is not connected (107)
15.10.2016,22:37:01 connect error: Transport endpoint is not connected (107)
15.10.2016,22:47:01 Characteristic value/descriptor: ff ff ff ff
...
16.10.2016,11:37:01 Characteristic value/descriptor: ff ff ff ff 
16.10.2016,11:47:01 Characteristic value/descriptor: 6b ea 4f 76 
16.10.2016,11:57:01 connect error: Transport endpoint is not connected (107)
16.10.2016,12:07:01 connect error: Transport endpoint is not connected (107)
16.10.2016,12:17:01 Characteristic value/descriptor: a2 20 c7 ef
...
16.10.2016,21:30:01 Characteristic value/descriptor: a2 20 c7 ef 
0x12: --------------------------------------
14.10.2016,01:20:51 Characteristic value/descriptor: 91 e5 20 c8
...
14.10.2016,12:47:01 Characteristic value/descriptor: 91 e5 20 c8 
14.10.2016,12:57:01 Characteristic value/descriptor: e5 30 75 59 
...
15.10.2016,14:57:01 Characteristic value/descriptor: e5 30 75 59 
15.10.2016,15:07:01 Characteristic value/descriptor: ab c5 59 60
...
15.10.2016,22:07:01 Characteristic value/descriptor: ab c5 59 60 
15.10.2016,22:17:01 Characteristic value/descriptor: ff ff ff ff
...
connect error: Transport endpoint is not connected (107)
16.10.2016,11:37:01 Characteristic value/descriptor: ff ff ff ff 
16.10.2016,11:47:01 Characteristic value/descriptor: b0 79 22 2a
...
16.10.2016,20:30:01 Characteristic value/descriptor: b0 79 22 2a
0x12: --------------------------------------
14.10.2016,01:20:51 Characteristic value/descriptor: fe a9 a1 08 
...
14.10.2016,12:47:01 Characteristic value/descriptor: fe a9 a1 08 
14.10.2016,12:57:01 Characteristic value/descriptor: 1e 78 b4 4e 
...
15.10.2016,14:57:01 Characteristic value/descriptor: 1e 78 b4 4e 
15.10.2016,15:07:01 Characteristic value/descriptor: fa e7 7f 45 
...
15.10.2016,22:17:01 Characteristic value/descriptor: fa e7 7f 45 
15.10.2016,22:27:02 Characteristic value/descriptor: ff ff ff ff 
...
16.10.2016,11:07:01 Characteristic value/descriptor: ff ff ff ff 
16.10.2016,11:17:01 connect error: Transport endpoint is not connected (107)
16.10.2016,11:27:02 connect error: Transport endpoint is not connected (107)
16.10.2016,11:37:01 connect error: Transport endpoint is not connected (107)
16.10.2016,11:47:01 Characteristic value/descriptor: b9 48 39 bd 
...
16.10.2016,20:30:01 Characteristic value/descriptor: b9 48 39 bd

Hi all,

so some more I checked:

Getting the handle 0x35 with the gatttool still works in my environment if I use a sensor that still is on firmware 2.6.2!

I sniffed the BT-traffic and saved it to a file, to look at it with Wireshark, unfortunately I’m far away of being en expert here.
But what I have seen was, that handle 0x38 still works with a simple “char-read”, while 0x35 works with a “notification”:

37	1.868963	localhost ()	HhccPlan_95:6a ()	ATT	12	Sent Read Request, Handle: 0x0038 (Unknown)
...
39	2.111094	HhccPlan_95:6a ()	localhost ()	ATT	17	Rcvd Read Response, Handle: 0x0038 (Unknown)
-> 63:13:32:2e:36:2e:36
...
43	2.359261	HhccPlan_95:6a ()	localhost ()	ATT	28	Rcvd Handle Value Notification, Handle: 0x0035 (Unknown)
-> 60:95:6a:27:38:b6:10:e0:d5:e5:db:fb:4d:03:b3:da
...
50	2.854152	HhccPlan_95:6a ()	localhost ()	ATT	28	Rcvd Handle Value Notification, Handle: 0x0035 (Unknown)
-> c0:00:00:4a:00:00:00:1c:a8:00:02:3c:00:fb:34:9b

Unfortunately I have no idea, how to initiate this notification :frowning:

Anybody with an idea outside there? Anybody who has some experience with reading a BT-dump?

If needed, I can provide the dumps here, they are less than 4KB in size.

Thanks a lot,

kind regards thgha