-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What firmware version tested with? #5
Comments
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 |
I am on noble@^1.7.0. miflora enabling realtime +391ms 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. |
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'); |
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":
|
This shouldn't be the case because it enables the realtime value with this which does the same thing that you shared. |
Others are having the same weird values: I wish I had not updated the firmware when I got them ;) |
Same problem. And all is OK ! |
This PR is based on issue demirhanaydin#5. I'm also changing the default name of the device to Flower care. I think the newer device use this name.
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 |
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' }
The text was updated successfully, but these errors were encountered: