Skip to content
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

fetchInterval seems to be broken for values < 1 #2

Open
FlorianWendelborn opened this issue Mar 17, 2016 · 2 comments
Open

fetchInterval seems to be broken for values < 1 #2

FlorianWendelborn opened this issue Mar 17, 2016 · 2 comments

Comments

@FlorianWendelborn
Copy link

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
Copy link
Owner

Vuzi commented Mar 17, 2016

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants