demirhanaydin / node-mi-flora

Node package for Xiaomi Mi Flora Plant Sensor
53 stars 21 forks source link

What firmware version tested with? #5

Open ghost opened 7 years ago

ghost commented 7 years ago

Tested with v2.8.6 In index.js, there is: const DEFAULT_DEVICE_NAME = 'Flower mate'; But the Mi Flora's are called 'Flower care'

After changing this in index.js it finds the flora's, but the readings are odd:

miflora enabling realtime +544ms miflora data: <Buffer aa bb cc dd ee ff 99 88 77 66 00 00 00 00 00 00> +44ms miflora temperature: 4804.2 °C +6ms miflora Light: 2583686877 lux +1ms miflora moisture: 39304 % +0ms miflora fertility: 26231 µS/cm +0ms data DeviceData { deviceId: 'c47c8d61fcf3', temperature: 4804.2, lux: 2583686877, moisture: 39304, fertility: 26231 } miflora firmware data: <Buffer 64 1d 32 2e 38 2e 36> +67ms firmware { deviceId: 'c47c8d61fcf3', batteryLevel: 100, firmwareVersion: '2.8.6' }

demirhanaydin commented 7 years ago

At the time when I've started to write the library, the firmware was 2.6.2. But I've upgraded mine to 2.8.6 right now and tested the library. As you said, they changed the default name from 'flower mate' to 'flower care'. Other than that it seems nothing changed significantly. Which node version you're using currently? Also, could you compare the result with your flower care app?

My v2.8.6 results;

data DeviceData {
  deviceId: '111111',
  temperature: 21.6,
  lux: 74,
  moisture: 8,
  fertility: 143 }
  miflora firmware data: <Buffer 5f 1d 32 2e 38 2e 36> +42ms
firmware { deviceId: '111111',
  batteryLevel: 95,
  firmwareVersion: '2.8.6' }

As a quick note; you can connect to your mi flora with passing the mac address instead of using default device name. Even though it's not documented, the only thing you need to do is just passing the mac address to constructor let flora = new MiFlora('xx:xx:xx:xx:4c:39'); Add debug line into the discover function under this line if you wanna see your device's mac address debug('device mac address: ', peripheral.address);

ghost commented 7 years ago

I am on noble@^1.7.0. Just tried again, and still odd readings.. however, they are the same as yesterday. Could it be it reads some buffer that is not updated? the miflora data: are 00 00 00

miflora enabling realtime +391ms miflora data: <Buffer aa bb cc dd ee ff 99 88 77 66 00 00 00 00 00 00> +42ms miflora temperature: 4804.2 °C +11ms miflora Light: 2583686877 lux +1ms miflora moisture: 39304 % +0ms miflora fertility: 26231 µS/cm +1ms data DeviceData { deviceId: 'c47c8d62a7de', temperature: 4804.2, lux: 2583686877, moisture: 39304, fertility: 26231 } miflora firmware data: <Buffer 64 1d 32 2e 38 2e 36> +61ms firmware { deviceId: 'c47c8d62a7de', batteryLevel: 100, firmwareVersion: '2.8.6' }

Just a sidenote, I am running node-flower-power that also uses noble once every 2 hrs on this Pi as well to read out other plant sensors by Parrot. I tried a reboot, but did not work.

demirhanaydin commented 7 years ago

The data which noble provided looks weird. Not sure what causes this because firmware data looks fine. Would you please try to test it standalone? Here is how you can test; write a script that uses noble to take data from your device and debug it with the code below. Or you can use Gatttool in your pi to connect the device and read the data from specified characteristic directly. If you're not familiar with gatttool, take a look at this https://github.com/pcborenstein/bluezDoc/wiki/hcitool-and-gatttool-example#gatttool

function parseData(raw) {
  let prepared = raw.replace(/ /g,"");
  let data = Buffer.from(prepared, 'hex');

  let temperature = data.readUInt16LE(0) / 10;
  let lux = data.readUInt32LE(3);
  let moisture = data.readUInt16BE(6);
  let fertility = data.readUInt16LE(8);

  console.log('temperature: %s °C', temperature);
  console.log('Light: %s lux', lux);
  console.log('moisture: %s %', moisture);
  console.log('fertility: %s µS/cm', fertility);
}

// data from your debug output
parseData('aa bb cc dd ee ff 99 88 77 66 00 00 00 00 00 00');
// my device's data
parseData('dd 00 00 63 01 00 00 08 90 00 02 3c 00 fb 34 9b');
ghost commented 7 years ago

pi@PlantCare:~ $ gatttool --device=c4:7c:8d:61:fc:f3 --char-read -a 0x35 Characteristic value/descriptor: aa bb cc dd ee ff 99 88 77 66 00 00 00 00 00 00

same Result.

There seems to be a change since firmware 2.6.6 as in the python miflora poller I see this part:

if firmware_version >= "2.6.6": write_ble(self._mac, "0x33", "A01F") self._cache = read_ble(self._mac, "0x35", retries=self.retries, timeout=self.ble_timeout, adapter=self._adapter) self._check_data()

Never versions needs a write to another register first.

demirhanaydin commented 7 years ago

This shouldn't be the case because it enables the realtime value with this which does the same thing that you shared.

ghost commented 7 years ago

Others are having the same weird values: https://community.home-assistant.io/t/xiaomi-mi-plants-monitor-flower/3388/84

I wish I had not updated the firmware when I got them ;)

chdid commented 7 years ago

Same problem. I replace characteristic.write(REALTIME_META_VALUE, true); by characteristic.write(REALTIME_META_VALUE, false);

And all is OK !

bepitulaz commented 6 years ago

I got the same problem with the firmware version 3.1.8. @chdid solution is working for me. I also change the device name to Flower care, since I have 3 new Xiaomi Flora and all of their names are Flower care. So, I think that's the name of the newer device.