Theoi-Meteoroi
commented
6 years ago Version 5.25 - installed the tarball on Jessie. Unzip, untar and run the install script Smooth experience. I'm using MH-z16 (uart) BME280 TMP007 TSL2561
Getting some odd low values on CO2 now (calibration needed?) but otherwise find the framework stable. I have isolated the I2C components with 9548 and 9545 muxes. Found some possible file handle leakage when attempting to use a TSL2591 - eventually caused daemon to fail with too many open files on that i2c bus.
I saw notes about cycling power on some devices (DHT, AM2315). Indeed, I found the AM2315 a bit twitchy, in my case I seemed to get valid data but consistently fail crc check. I've ordered two more from china for testing to make sure I don't just have a flaky sample. In other projects, I have used the SHT31 with no issue, but I like the housing the AM2315 has. That I get data but fail the crc may get me to hook up the bus pirate, if the problem persists on my second proto hardware I'm starting to build.
Reading some of the trouble reports, I wonder if everyone knows about terminating ic2 properly and just how much capacitance in the cable you can get away with before it all goes just so wrong.
awesome project. I'm learning the codebase so I can add sensors not yet supported.
I'd be willing to assist with documenting, schematics and such. Prolly should mention power cycling some of those old sensors as plan A.
I was able to get most of the sensors to be tested with loops and from sensor info obtained from info() of each sensor class, in the latest mycodo_dev branch commit (e335b75), however there are a few sensors that I could not get some tests to pass from test_all_sensors.py. I believe there are different reasons for each:
RaspberryPiCPUTemp and RaspberryPiGPUTemp (raspi.py) and RaspberryPiCPULoad (raspi_cpuload.py):
I was testing these on my Pi, so it appeared there were actual values instead of the 0.00 (or injected value) it was expecting.
DHT11Sensor (dht11.py), DHT22Sensor (dht22.py), and HTU21DSensor (htu21d.py):
It seems the pigpio module was causing the errors, but I'm not sure.
K30Sensor (k30.py):
I had to remove the K30Sensor class from being tested in commit 6f7168f to get the Travis CI test to pass. The error is: No module named GPIO. perplexing is this module is indeed installed with pip.
Perhaps sensor tests being conducted this way is not a good solution? It certainly does compact the code at the expense of readability and being able to test all sensors (which just may be a limitation of my testing knowledge).