fetchInterval seems to be broken for values < 1

FlorianWendelborn commented 8 years ago

Description

fetchInterval pulls far more often than twice per second. Resulting data is corrupted. My guess is that you're using an integer for that, and only allow seconds. Then the program automatically rounds it down, to make it fit into int.

My Code

import {Sensor} from 'raspi-sensors';
import io from './socket';

const DHT22 = new Sensor({
    type: 'DHT22',
    pin: 8
});

let state = {
    temperature: null,
    humidity: null
}

const send = (err, data) => {
    if (!err) {
        if (data.type === 'Temperature') {
            state.temperature = data.value.toFixed(2);
        } else if (data.type === 'Humidity') {
            state.humidity = data.value.toFixed(2);
            io.to('authenticated').emit('data', state);
            console.log(new Date());
        }
    } else {
        console.error(err);
    }
}

DHT22.fetch(send);
DHT22.fetchInterval(send, 0.5);

Log output

Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)
Thu Mar 17 2016 13:57:59 GMT+0000 (UTC)

Software

➜  server git:(master) ✗ npm -v
2.14.7
➜  server git:(master) ✗ node -v
v4.2.1
➜  server git:(master) ✗ npm list | grep raspi-sensors
├── raspi-sensors@0.2.7
➜  server git:(master) ✗ uname -a
Linux raspberrypi 4.1.19-v7+ #853 SMP Wed Mar 9 18:09:16 GMT 2016 armv7l GNU/Linux

Hardware

Raspberry Pi 3

Vuzi commented 8 years ago

You're right, I cast the number to an integer in C++, and expect an unsigned integer in the scheduler. So putting any decimal number truncate it.

Secondly the DHT22 can only be read every two seconds, that's why you may have error (because the checksum don't match), or even strange/corrupted data like 0°C.

I think I should have added a way to check frequences based on a sensor to avoid that type of issue, I'll look into it.

FlorianWendelborn commented 8 years ago

Given that you include a note about that in the README, you could also buffer the last reading and if a program attempts to read it again within too few time it just delivers the old result.

Vuzi / raspi-sensors