|
Post by doxidad on Feb 9, 2019 13:26:44 GMT -8
Still reading random BIG negative numbers with 315. Went back to 314 with changes I made.
|
|
|
Post by doxidad on Jan 29, 2019 13:18:39 GMT -8
Gee that shouldn't have affected anything. Basically moved stuff around. Sorry it made things difficult for you
|
|
|
Post by doxidad on Jan 25, 2019 15:20:27 GMT -8
I now have the Barometric trend working - REALLY! It's a 2 line fix. It can probably be massaged a bit but this works.
HERE'S WHAT TO DO:
FIND: sampleWeather()
#state.pastBarometricReading = state.currentBarometricPressure <--- COMMENT THIS LINE OUT with a #
FIND: state.currentBarometricPressure = bmp180SeaLevel
ADD THIS LINE ABOVE IT: state.pastBarometricReading = state.currentBarometricPressure
SO IT LOOKS LIKE THIS:
state.pasBarometricReading = state.currentBarometricPressure state.currentBarometricPressure = bmp180SeaLevel
That's it - trending should now work - remember the check is done only every 15 minutes so don't expect an immediate change.
|
|
|
Post by doxidad on Jan 23, 2019 7:24:01 GMT -8
I noticed that the indicator for Barometric Trend "B Trend" never changes when the barometer falls. Looking back at the past week's logs and barometric.trend is always TRUE. We've had a few low pressures go through here where the barometer dropped from in to 30s into the 29s. I found the problem why the the barometric trend LED doesn't change. The code copies the current pressure into the past pressure. this makes the current and past always the same. Move the line that is after the sampleWeather() call to before the call and you now will compare the past and current in the barometricTrend() routine. Original Code... sampleWeather() state.pastBarometricReading = state.currentBarometricPressure
New Code...
state.pastBarometricReading = state.currentBarometricPressure
sampleWeather()
This actually looked like it worked for a while - IT DOES NOT. Sorry for the bad info.
|
|
|
Post by doxidad on Jan 22, 2019 4:39:41 GMT -8
I noticed that the indicator for Barometric Trend "B Trend" never changes when the barometer falls. Looking back at the past week's logs and barometric.trend is always TRUE. We've had a few low pressures go through here where the barometer dropped from in to 30s into the 29s. I found the problem why the the barometric trend LED doesn't change. The code copies the current pressure into the past pressure. this makes the current and past always the same. Move the line that is after the sampleWeather() call to before the call and you now will compare the past and current in the barometricTrend() routine. Original Code... sampleWeather() state.pastBarometricReading = state.currentBarometricPressure
New Code...
state.pastBarometricReading = state.currentBarometricPressure
sampleWeather()
|
|
|
Post by doxidad on Jan 22, 2019 4:27:33 GMT -8
|
|
|
Post by doxidad on Jan 21, 2019 12:02:31 GMT -8
|
|
|
Post by doxidad on Jan 13, 2019 7:50:05 GMT -8
Hmm... I get lightning, startup, and rain.
|
|
|
Post by doxidad on Jan 12, 2019 11:25:02 GMT -8
I noticed that the indicator for Barometric Trend "B Trend" never changes when the barometer falls.
Looking back at the past week's logs and barometric.trend is always TRUE.
We've had a few low pressures go through here where the barometer dropped from in to 30s into the 29s.
|
|
|
Post by doxidad on Jan 5, 2019 15:39:11 GMT -8
Peter, To fix the battery gauge - in update Blynk.py look for the statement that formats V56. Remove the '%' from the format statement and it will work. Evidently the gauge widget just wants a pure number in the text.
|
|
|
Post by doxidad on Jan 3, 2019 2:39:03 GMT -8
BP,
Something for you to consider on future releases.
The column TimeStamp is used in the queries in the graphing routines.
Example: SELECT TimeStamp, bmp180SeaLevel, as3935LastInterrupt, as3935LastDistance FROM WeatherData where now() - interval 240 hour < TimeStamp
On a database with ~140,000 rows this takes .55 seconds on a Pi 3B
With an index on this column the query takes .09 seconds.
This can be done with the following for each table after creation.
ALTER TABLE `WeatherData` ADD KEY `TimeStamp` (`TimeStamp`);
|
|
|
Post by doxidad on Dec 28, 2018 7:10:10 GMT -8
Peter, I noticed that the AM2315 craps out when the graphing routines run. I commented out the apscheduler entry for graphing and I now have the longest run without AM2315 failure. I have been seeing the failure anywhere from 15 minutes after startup to a couple of hours after startup. Without the graphing routines, it has run for over 24 hrs without a failure. This could mean that the graphing routines were causing the problem or just that the failure hasn't happened. Time will tell. If you aren't using the graphs for anything you might give this a try.
Hope this helps (and is the problem) TR
|
|
|
Post by doxidad on Dec 18, 2018 13:09:28 GMT -8
Any progress on AM2315 stuff?
|
|
|
Post by doxidad on Dec 3, 2018 7:05:57 GMT -8
BP -
1- normally the AM2315 is detected but not always 2- normally the AM2315 is detected but not always 3- the AM2315 is detected.
The lost of the AM2315 usually happens within an a couple of minutes up to 2 hours. I did have one case over the weekend that I got 5 hours before the error occurred.
|
|
|
Post by doxidad on Dec 1, 2018 8:23:41 GMT -8
I'm seeing this
Started @07:23
Last AM2315 entry AM2315 Stats: (g,br,bc) (49, 0, 6)
Then ---
Tick! The time is: 2018-12-01 07:51:03.205498 ----------------- Sample and Display ----------------- ------Patting The Dog------- ----------------- Weather Sampling ----------------- ----------------- 'NoneType' object has no attribute '__getitem__' File "/usr/local/lib/python2.7/dist-packages/apscheduler/executors/base.py", line 125, in run_job retval = job.func(*job.args, **job.kwargs) File "/home/pi/SDL_Pi_GroveWeatherPi/GroveWeatherPi.py", line 1263, in sampleAndDisplay sampleWeather() File "/home/pi/SDL_Pi_GroveWeatherPi/GroveWeatherPi.py", line 1107, in sampleWeather ToutsideHumidity, ToutsideTemperature, crc_check = am2315.read_humidity_temperature_crc() File "./SDL_Pi_AM2315/AM2315.py", line 136, in read_humidity_temperature_crc self._read_data() File "./SDL_Pi_AM2315/AM2315.py", line 97, in _read_data self.humidity = ((tmp[2] << 8) | tmp[3]) / 10.0
------Patting The Dog------- ------Patting The Dog------- ------Patting The Dog------- ------Patting The Dog------- ------Patting The Dog------- Tick! The time is: 2018-12-01 07:52:03.205891
Right after this happens daemon.log starts filling up with these errors every 30 seconds
Dec 1 07:52:03 wpi rc.local[309]: WARNING:apscheduler.scheduler:Execution of job "sampleAndDisplay (trigger: interval[0:00:30], next run at: 2018-12-01 07:52:03 EST)" skipped: maximum number of running instances reached (1)
is lock not getting released somewhere and blocking?
|
|