I got a problem upgrading - propably due to changes in the github structure:
pi@raspberrypi ~/AirPi_Haydn $ sudo bash airpictl.sh ver
[AirPi] Current installed version and latest change:
commit a23f25a9389b4f5f709003508fa684235e9a0655 Author: Haydn Williams <email@example.com> Date: Tue Jan 20 22:24:56 2015 +0000 Change: Added an extra debug message.
[AirPi] See README.md or github.com/haydnw/airpi for details of changes between different versions. [AirPi] Note that upgrading to a newer version will overwrite all existing config files with the defaults, so save yours elsewhere first if you want to preserve them. [AirPi] To upgrade to the latest version, run this command:
pi@raspberrypi ~/AirPi_Haydn $ sudo git pull Your configuration specifies to merge with the ref 'development2' from the remote, but no such ref was fetched.
Ah yes, I renamed the 'development2' branch to 'development' so you'll need to do a complete clone of the latest commit. Use the 'master' branch for something which definitely works; use the 'development' branch if you're feeling brave and want the very latest version but which might contain some bugs. I don't anticipate that the branch names should change again, so this shouldn't happen again in future.
pi314 - Thanks. I'll take a look over the next couple of days.
I did as you suggested with the following results:
Normal run (i.e. no calibration, no gps, no rrd, sampling frequency set to 300 seconds): works but I still get the error message: "WARNING: Can't keep up - requested sample frequency is too fast!"
With calibration on: does not work; DEBUG:__main__: ERROR: Exception during output: 'NoneType' object has no attribute 'calibrate'
With GPS on (GPSC is up and working): does not work; DEBUG:__main__: GPS output (46.943546667, 7.478, 582.3, 'mobile', 'outdoor') Traceback (most recent call last): File "airpi.py", line 1388, in <module> dummy_runs(SETTINGS['DUMMYDURATION']) File "airpi.py", line 1011, in dummy_runs read_gps(i) File "airpi.py", line 1067, in read_gps reading["name"] = sensorplugin.valname AttributeError: 'serial_gps' object has no attribute 'valname'
So it seems that the master branch is not totally without flaw?
Post by ioanpaulpirau on Jul 6, 2015 19:14:22 GMT -5
First of all many thanks and praises for your efforts! I just tested an AirPi 1.4 on a RPI B2 and I found that for the mic I get a no-voltage reading on analog pin 4. I guess this could be a soldering issue.. please let us know what you come across with the 1.4 board (i do hope that it may be the code ). I tested on both the original version from the author and the version from your branch and the results are the same. I like your version more because it has more debug information. Initially if I enabled DHT22, airpi.py kept freezing during sampling, but if I set the pinNumber value to either 1,3,7 or 9, ... (it seems to not freeze with odd numbers) the app doesn't freeze but I get an exception:
"Exception during output: Unknown format code 'f' for object of type 'str'
Do you have any idea why I get this ? It may be due to the AirPi 1.4 different pin layout configuration but also could be something from the code..
I don't know how much effort it takes, but if I may propose an enhancement (this is already used in the Ubidots-version). I could do it myself, but first I need to read through both code-bases.
Automatically add datapoints (instead of filling out all the fields in outputs.cfg. Ubidots requires just an API key)
Okay so I've managed to integrate the "Ubidots"-code into this code. There are some gotcha's:
Needed to rename the existing ubidots.py to ubidots_http.py (as it is using a http client)
For my code, you need to have the Ubidots-library installed (sudo pip install ubidots)
If anybody is interested, I can cleanup the code and publish it somewhere. I don't know what the best way is to do that.
And in the process, I also got a halfway plugin for EmonCMS. The thread mentioned for EmonCMS is a bit old and I needed to revise the code a bit, but it is working. Even with the emoncms.org one, haven't tested the self-hosted one, but shouldn't be a problem.
Last Edit: Jul 8, 2015 16:56:57 GMT -5 by kdv: Added part about EmonCMS
Great news. For Fahrenheit, add a line to the sensor definition in cfg/sensors.cfg:
unit = F
First off, I want to thank you for your code and time!
Any way to convert the Light level output from ohms to LUX? (Light_Level: 71190.48 (Ohms))
Can you have an option for barometric pressure display in inHg as an option like you did with Celsius and Fahrenheit? I found this (but as a novice I will most likely corrupt the code...) If you really need to know what the hPa barometric pressure reading is in inHg, multiple hPa by 0.02953 and round the result to the hundredth decimal place. From: pi.gate.ac.uk/posts/2014/02/25/airpisensors/
A weekly and monthly graph would be neat to have as well to track the monitoring history...