Re: [weewx-user] Uploading missing data to Weather Underground

[Louis De Lange]

I tried this method of updating today as well.  Jan 29 and 30 simply fails. Jan 
31 appears to upload missing data successfully, but the data never shows up at 
on WU.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c5dae3e2-9f58-49c4-9f97-14e0ca6fee2c%40googlegroups.com.

[weewx-user] Re: MQTT for remote site and min data transfer - MQTT Driver as input to weewx

[Louis De Lange]

Time to revisit this old post as I finally spent some time with morrowwm's 
wxMesh driver to make slight modifications required for this use case.  

It has been working well for the last week and I am making it available in 
case it may be useful for someone else.  If there is sufficient interest I 
will clean it up and upload it to weewx-wiki as a separate driver.

The following is a description from the driver comment section describing 
how it works.  

# Original driver created by morrowwm
# This is a specific modification for the use case of a station in a remote 
location
# where bandwidth and data allowance is limited and a lightweight data 
transfer protocol
# such as MQTT is required.
#
# The system requires a local (at the weather station) instance of weewx to 
collect data,
# archive locally and publish complete archive records to MQTT broker on a 
remote server.
# The remote server runs a remote instance of weewx that receives the 
complete archive
# records by subsribing to MQTT topic on the remote server, archives 
remotely and uploads
# generated webpages to the webserver.
#
# The local instance of weewx publishes the data to the MQTT broker using 
mwall's 
# weewx-mqtt uploader with the following settings
# 
#server_url = mqtt://:@:1883/
#topic = weather
#unit_system = US
#binding = archive
#aggregation = aggregate
#append_units_label = false
#
# MQTT broker set up as described in this excellent guide by Pat O'Brien
# https://obrienlabs.net/how-to-setup-your-own-mqtt-broker/
#
## The units must be weewx.US:
#   degree_F, inHg, inch, inch_per_hour, mile_per_hour
#
# To use this driver, put this file in the weewx user directory, then make
# the following changes to weewx.conf:
#
# [Station]
# station_type = wxMesh
# [wxMesh]
# host = localhost   # MQTT broker hostname
# username =   # MQTT broker user name. Assumption is 
your broker requires authentication
# password = "password"
# topic = weather/+  # topic
# driver = user.wxMesh
#
# Since the subscribed topic already uses weewx standard labels no labell 
mapping is required.
#
# This driver has not been tested for use with Python 3

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/4cda152e-1ab0-483d-9423-7e4faf2d0f87%40googlegroups.com.
#!/usr/bin/python
#
# weewx driver that reads data from MQTT subscription
#
# Original driver created by morrowwm
# This is a specific modification for the use case of a station in a remote location
# where bandwidth and data allowance is limited and a lightweight data transfer protocol
# such as MQTT is required.
#
# The system requires a local (at the weather station) instance of weewx to collect data,
# archive locally and publish complete archive records to MQTT broker on a remote server.
# The remote server runs a remote instance of weewx that receives the complete archive
# records by subsribing to MQTT topic on the remote server, archives remotely and uploads
# generated webpages to the webserver.
#
# The local instance of weewx publishes the data to the MQTT broker using mwall's 
# weewx-mqtt uploader with the following settings
# 
#server_url = mqtt://:@:1883/
#topic = weather
#unit_system = US
#binding = archive
#aggregation = aggregate
#append_units_label = false
#
# MQTT broker set up as described in this excellent guide by Pat O'Brien
# https://obrienlabs.net/how-to-setup-your-own-mqtt-broker/
#
## The units must be weewx.US:
#   degree_F, inHg, inch, inch_per_hour, mile_per_hour
#
# To use this driver, put this file in the weewx user directory, then make
# the following changes to weewx.conf:
#
# [Station]
# station_type = wxMesh
# [wxMesh]
# host = localhost   # MQTT broker hostname
# username =   # MQTT broker user name. Assumption is your broker requires authentication
# password = "password"
# topic = weather/+  # topic
# driver = user.wxMesh
#
# Since the subscribed topic already uses weewx standard labels no labell mapping is required.
#
# This driver has not been tested for use with Python 3

# This program is free software: you can redistribute it and/or modify it under
# the terms of the GNU General Public License as published by the Free Software
# Foundation, either version 3 of the License, or any later version.
#
# This program is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
# FOR A PARTICULAR PURPOSE.
#
# See http://www.gnu.org/licenses/

from __future__ import with_statement
import syslog
import time
import Queue
import paho.mqtt.client as mqtt

[weewx-user] Re: One more option for Build Your Own enthusiasts

[Louis De Lange]

George,

At the time when I completed that project the tutorial on the BC-Robotics 
website was written in Python 2.7 so I used all the 2.7 libraries in my 
code.  With some research you should be able to convert the original code 
to work with python 3 libraries.

Sorry, I have not updated anything because if it works why break it.

LDL

On Saturday, 23 November 2019 13:06:57 UTC-8, George Nimrodel wrote:
>
> Hey Louis,
>
> I'm trying to do exactly what you've done with the difference that I have 
> weewx running on the RPi and I'm using only the BME280 for temperature in a 
> separate enclosure.
>
> I'm having a bit of a trouble with your code. I keep getting errors 
> regarding the libraries.
>
> I've noticed that you are not using the python 3 libraries from the 
> tutorial.
>
> I would appreciate it if you could tell me which steps you took that are 
> not included in the tutorial in order for your code to work.
>
> Any other pointers would also be appreciated
>
> Thank in advance!
>
> On Wednesday, December 12, 2018 at 5:53:25 AM UTC+2, Louis De Lange wrote:
>>
>> I recently came across a really excellent solution for putting together 
>> your own weather station on the cheap with high quality sensors - and most 
>> importantly a very useful weather HAT to use with a Raspberry PI to connect 
>> all the sensors.
>>
>> It comes complete with a 4 part step by step tutorial to assemble the 
>> whole station, and basic code to upload the data to and online service - 
>> see link below:
>>
>> https://www.bc-robotics.com/tutorials/raspberry-pi-weather-station-part-1/
>>
>> I completed my own installation based on the instructions in the tutorial 
>> and my station running on weewx is active at the link below
>>
>> http://peachlandweather.ca/mystation/
>>
>> For the outdoor portion I used a Raspberry Pi Zero W, with the weather 
>> HAT.  Weewx is running indoors in a FreeBSD jail, using a stock Interceptor 
>> driver.  I modified the basic upload code provided in the tutorial quite 
>> extensively to generate upload loops that matched the Observer URLs 
>> supported by the Interceptor driver, and also to produce derived 
>> observations not included in the original code.
>>
>> The upload code is attached for anyone who might be interested in trying 
>> to assemble their own.
>>
>> I   tested the results from using the station against my Vantage Pro 2 
>> and so far it seems to be pretty close - for less than 20% of the cost of a 
>> Vantage Pro.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/db1a607e-3fb0-4ed1-974e-0930406e7e6a%40googlegroups.com.

Re: [weewx-user] Re: Barometric pressure correction the right way

[Louis De Lange]

I do not recall where I came across the fact that it is temperature 
compensated. At some point I thought perhaps the indoor sensor was trying 
to provide a barometer reading and I placed it outside in a sheltered area, 
and imported it into weewx as barometer and still it was all over the 
place.  Recently I build a constant temperature box and placed the sensor 
inside, and for the first time it followed my local airport altimeter 
exactly.  

  Conclusion - garbage.

I ended up building a BYOD station which I am very happy with

On Wednesday, 1 May 2019 12:00:25 UTC-7, V. Kelly Bellis wrote:
>
> @Louis De Lange, thanks for mentioning this. By any chance, do you recall 
> where you read that FineOffset was using indoortemp for pressure 
> calculations?
>
> On Sunday, January 14, 2018 at 2:35:33 PM UTC-5, Louis De Lange wrote:
>>
>> As a previous owner of a Fine Offset station I can confirm that I noticed 
>> this same behavior.  Living in Canada where our homes are heated, I could 
>> clearly see the altimeter reading (my station did not support barometer 
>> correction to sea level) seesaw with the furnace operating and shutting 
>> down.  
>>
>> *Reading up on the issue it appeared that the Fine Offset hardware was 
>> doing a temperature correction internal to the indoor unit*, but that 
>> quick changes to the indoor temperature threw the reading off.  There is no 
>> way that you can correct for that with calibration - it is a flaw in the 
>> hardware.  
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Strange notches in barometer graph

[Louis De Lange]

In my BYO station I noticed strange notches in the barometer graph that I 
cannot explain 

Since barometer is calculated by weewx in this case I am trying to 
understand the cause, I cannot imagine that the formula for calculating 
barometer from pressure will cause this.  If anyone has any idea what the 
cause might be I would appreciate some insight.  Below is a screen grab of 
the barometer and altimeter plot.  Note the altimeter is smooth when the 
big downward notch is evident in the barometer plot, starting around 1am.  
Since barometer depends on temperature I also include the outTemp plot for 
comparison.  At the time there was no sudden change in temperature that 
could affect barometer.

Note that I am on Weewx 3.8.2 with Interceptor Driver.  As the station is 
BYO, all derived variables are calculated - the station only reports 
pressure and weewx calculates altimeter and barometer.

[image: barometer.JPG]

[image: outtemp.JPG]
  


-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: One more option for Build Your Own enthusiasts

[Louis De Lange]

Pat, one more thing that's is really useful is that the weather board has an 
extra RJ11 connector with 3 spare analog input channels that can me used for 
additional sensors such as solar, etc.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: One more option for Build Your Own enthusiasts

[Louis De Lange]

On Wednesday, 12 December 2018 08:24:48 UTC-8, P Simmons wrote:
 

> Please define "pretty close".
> Thanks!
>
 
Check it out for yourself on the website below.  

The only thing that is slightly off is the humidity and this is due to the 
mounting of the sensor in a box that allows the temperature inside the box 
to be about 2 - 3 Celsius higher than the true outdoor temp.  When I take 
the lid off the box and expose the sensor to the proper outdoor 
temperature, the humidity reading is within 1% of the Vantage reading, with 
no calibration.  I have a new Stevenson screen on order to improve the 
sensor location, so that should fix the humidity issue.  I could fix it 
through calibration but I prefer to do it properly.

Reference Weather Station - Vantage Pro 2
www.peachlandweather.ca 

New homebrew station
www.peachlandweather.ca/mystation

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] One more option for Build Your Own enthusiasts

[Louis De Lange]

I recently came across a really excellent solution for putting together 
your own weather station on the cheap with high quality sensors - and most 
importantly a very useful weather HAT to use with a Raspberry PI to connect 
all the sensors.

It comes complete with a 4 part step by step tutorial to assemble the whole 
station, and basic code to upload the data to and online service - see link 
below:

https://www.bc-robotics.com/tutorials/raspberry-pi-weather-station-part-1/

I completed my own installation based on the instructions in the tutorial 
and my station running on weewx is active at the link below

http://peachlandweather.ca/mystation/

For the outdoor portion I used a Raspberry Pi Zero W, with the weather 
HAT.  Weewx is running indoors in a FreeBSD jail, using a stock Interceptor 
driver.  I modified the basic upload code provided in the tutorial quite 
extensively to generate upload loops that matched the Observer URLs 
supported by the Interceptor driver, and also to produce derived 
observations not included in the original code.

The upload code is attached for anyone who might be interested in trying to 
assemble their own.

I   tested the results from using the station against my Vantage Pro 2 and 
so far it seems to be pretty close - for less than 20% of the cost of a 
Vantage Pro.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
#!/usr/bin/python

import time
import datetime
from w1thermsensor import W1ThermSensor
from Adafruit_BME280 import *
import Adafruit_ADS1x15
import RPi.GPIO as GPIO
import requests
import syslog
import pickle
 
ds18b20 = W1ThermSensor()
bme = BME280(t_mode=BME280_OSAMPLE_8, p_mode=BME280_OSAMPLE_8, h_mode=BME280_OSAMPLE_8)
adc = Adafruit_ADS1x15.ADS1115()

## Settings to control operation of weather station
 
interval = 15  #How long we want to wait between loops (seconds)
loglevel = 0   #Set to 0 for no log entries, set to 1 for basic log info and 2 for all log info
upload_url = "http://192.168.0.29;  #IP address or URL to upload data, inlcude port number if not standard
filename = "/home/pi/dailyrainfile"
 
## Init settings for variable - do not adjust

windTick = 0   #Used to count the number of times the wind speed input is triggered
rainTick = 0   #Used to count the number of times the rain input is triggered
ticktimenow = None   # Used to calculate the wind gust be determining the shortest time between windTicks 
mindeltatime = None  # Used to calculate the wind gust be determining the shortest time between windTicks
looptimenow = time.time()  #Used to calculate the wind gust be determining the shortest time between windTicks

#load previous saved dailyrain value
try:
infile = open(filename,'rb')
saved_dailyrain = pickle.load(infile)
infile.close()
dailyrain = saved_dailyrain
syslog.syslog("Loading of saved dailyrain state success. Initialise dailyrain to %s" % dailyrain) 
except:
syslog.syslog("Loading of saved dailyrain state failed. Initialise dailyrain to zero")
dailyrain = 0

#Set GPIO pins to use BCM pin numbers
GPIO.setmode(GPIO.BCM)
 
#Set digital pin 17 to an input and enable the pullup 
GPIO.setup(17, GPIO.IN, pull_up_down=GPIO.PUD_UP)
 
#Set digital pin 23 to an input and enable the pullup 
GPIO.setup(23, GPIO.IN, pull_up_down=GPIO.PUD_UP)
 
#Event to detect wind (4 ticks per revolution)
GPIO.add_event_detect(17, GPIO.BOTH) 

def windtrig(self):
global windTick
windTick += 1
global ticktimenow
if ticktimenow is None:
ticktimenow = time.time()
else:
ticktimelast = ticktimenow
ticktimenow = time.time()
tickdelta = ticktimenow - ticktimelast
#print 'Delta time:' , tickdelta, 'Seconds'
global mindeltatime
if mindeltatime is None:
mindeltatime = tickdelta
else:
if tickdelta < mindeltatime:
mindeltatime = tickdelta
#print 'Min Delta Time:' , mindeltatime, 'Seconds'
 
GPIO.add_event_callback(17, windtrig)
 
#Event to detect rainfall tick
GPIO.add_event_detect(23, GPIO.FALLING)
def raintrig(self):
global rainTick
rainTick += 1
 
GPIO.add_event_callback(23, raintrig)
 
#Function to determine the start of day timestamp
def startOfDay(time_ts):
"""Calculate the unix epoch time for the start of a (local time) day.

time_ts: A timestamp somewhere in the day for which the start-of-day
is desired.

returns: The timestamp for the start-of-day (00:00) in unix epoch time.

"""
_time_tt = time.localtime(time_ts)
_bod_ts = time.mktime((_time_tt.tm_year,
_time_tt.tm_mon,
_time_tt.tm_mday,
0, 0, 0, 0, 0, -1))
return 

Re: [weewx-user] Re: How to sent 'live' data to custom URL?

[Louis De Lange]

Richard, 

The fog is lifting...

On your own server, do you have the ability to adapt to receive the 
standard GET or POST payload formats that services such as WU use?  Or does 
the payload need to be in specific format that you cannot change?

LdL

On Saturday, 27 October 2018 13:57:41 UTC-7, Richard wrote:
>
> Hi Louis,
>
> Sorry for the ambiguity. 
> At the moment I use LightsoftWeatherCenter to sent our weather data to: 
> WU, CWOP and my own server. 
> This server in his turn collects data from multiple stations and creates a 
> websocket push service for my clients (other websites) to subscribe to, to 
> get local weather data.  Works like a charm :)
>
> This server runs an public endpoint on a url which excepts the weather 
> data  as a payload. Which then gets queued to get processed, async stored 
> and broadcasted etc etc
>
> So I need WeeWX to post a request to this public endpoint. (besides  
> updating WU and CWOP) :)
>
> Hope this clarifies my needs
>
> Best regards
> Richard
>
>
>
> Op za 27 okt. 2018 om 22:45 schreef Louis De Lange  >:
>
>> Richard,
>>
>> To really provide you with the best advice we need to understand a bit 
>> better what you want to do.
>>
>> I am not familiar with LWC so I am not sure how this fits into the 
>> picture.
>>
>> From your description below it sound like you are trying to upload to WU 
>> and CWOP at a minimum - this can be done directly from weewx.  Are you 
>> trying to do any other uploads?  What else are you doing with your data?
>>
>> LdL
>>
>> On Saturday, 27 October 2018 10:59:43 UTC-7, Richard wrote:
>>>
>>> Hi Thomas and Louis,
>>>
>>> Thank you for your swift responses!
>>>
>>> I'm not very familiar with coding in Python, so Louis' approach sounds 
>>> more likely to fit my python skills ;)
>>>
>>> As a background: At the moment we have a Vantage Vue connected to a Mac 
>>> Mini running LWC. LWC is responsible to call an URL with the weather data 
>>> as a query parameter. It was running properly for at least 4 years now; but 
>>> now it's not that stable anymore. Besides the (headless) mac mini is 
>>> offcourse complete overkill to just transfer the weatherdata to our servers 
>>> :) (It used to have more jobs; but the were migrated to the cloud :)
>>>
>>> Just a couple of additional questions:
>>> - At the moment we share the data with CWOP and Wunderground; those 
>>> other services listed in [stdRESTful] share the same config, so they all 
>>> could be used as a private service?
>>> - How is the data transfered to the service? As a POST or GET request? 
>>> And how is it built?
>>>
>>> Thanks (again) for you answers! 
>>>
>>> Best regards
>>> Richard
>>>
>>>
>>> Op za 27 okt. 2018 om 16:50 schreef Thomas Keffer :
>>>
>>>> Very clever, Louis!
>>>>
>>>> I don't like the WU protocol very much, as it breaks all kinds of rules 
>>>> about how to design a proper RESTful service. In particular, it uses an 
>>>> HTTP GET, when it should really use a POST.
>>>>
>>>> -tk
>>>>
>>>> On Sat, Oct 27, 2018 at 6:38 AM Louis De Lange  
>>>> wrote:
>>>>
>>>>> Richard,
>>>>>
>>>>> If you read through the restx.py file that controls all of the restx 
>>>>> services such wunderground uploads you will notice a number of parameters 
>>>>> that can be specified, such as post_interval and server_url.  When you 
>>>>> read 
>>>>> through the user guide you might notice that these specific parameters 
>>>>> are 
>>>>> documented for use with CWOP upload, not WU - but they also work for WU 
>>>>> upload if you specify them in the [[Wunderground]] section of 
>>>>> [StdRESTful]  
>>>>> in you weex.conf file.  Another useful parameter is post_interval as it 
>>>>> allows you to send an upload at the intervals you want, not every time 
>>>>> you 
>>>>> receive a loop packet.
>>>>>
>>>>> Below is an example of a [[Winderground]] config segment is use to 
>>>>> upload to my own remote server - and on the receiving end I use mwall's 
>>>>> interceptor driver to receive and decode it.
>>>>>
>>>>> [[Wunderground]]
>>>>> # This section is for configuring posts to the Weather 
&g

[weewx-user] Re: How to sent 'live' data to custom URL?

[Louis De Lange]

Richard,

If you read through the restx.py file that controls all of the restx 
services such wunderground uploads you will notice a number of parameters 
that can be specified, such as post_interval and server_url.  When you read 
through the user guide you might notice that these specific parameters are 
documented for use with CWOP upload, not WU - but they also work for WU 
upload if you specify them in the [[Wunderground]] section of [StdRESTful]  
in you weex.conf file.  Another useful parameter is post_interval as it 
allows you to send an upload at the intervals you want, not every time you 
receive a loop packet.

Below is an example of a [[Winderground]] config segment is use to upload 
to my own remote server - and on the receiving end I use mwall's 
interceptor driver to receive and decode it.

[[Wunderground]]
# This section is for configuring posts to the Weather Underground.

# If you wish to do this, set the option 'enable' to true,
# and specify a station (e.g., 'KORHOODR3') and password.
# To guard against parsing errors, put the password in quotes.
enable = true
station = MAKESOMETHINGUP
password = anthingIwant

# Set the following to True to have weewx use the WU "Rapidfire"
# protocol. Not all hardware can support it. See the User's Guide.
rapidfire = true

post_interval = 40
log_success = false
log_failure = true
server_url = http://"insert_your_own_url_here;
max_tries = 2
post_indoor_observations = true

Why do this? I came up with this approach to receive loop data at my remote 
cabin, and upload it to my home server running another instance of weewx - 
all this to minimize the data transfer via cellular modem from the remote 
site.

Or you can just follow Tom's suggestions that was posted just before mine 
:-)

Louis  
 

On Saturday, 27 October 2018 06:06:06 UTC-7, Richard wrote:
>
> I'm looking for a way to hit an url with weatherdata on the receive of 
> each loop packet.
>
> If I look at the user guide, i can see the [StdRESTful] section and was 
> thinking I need to configure something here.
> But I can't see a 'default' extension. Am i missing something?
>
> The rapidfire/wunderground extension sounds what I need, but only need to 
> sent it to my URL instead of wunderground' :)
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: MQTT for remote site and min data transfer - MQTT Driver as input to weewx

[Louis De Lange]

Pat,

Thank you for the insight.  I already understood most of what you 
described, but your point that the data should be on weather/loop worked.  

So changing that now the loop is activated when data arrives, but I am 
getting an error about data type for dateTime.  

  File "/usr/bin/weewxd", line 64, in 
weewx.engine.main(options, args)
  File "/usr/share/weewx/weewx/engine.py", line 877, in main
engine.run()
  File "/usr/share/weewx/weewx/engine.py", line 191, in run
self.dispatchEvent(weewx.Event(weewx.NEW_LOOP_PACKET, packet=packet))
  File "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
callback(event)
  File "/usr/share/weewx/weewx/wxservices.py", line 45, in new_loop_packet
self.calc.do_calculations(event.packet, 'loop')
  File "/usr/share/weewx/weewx/wxservices.py", line 191, in do_calculations
getattr(self, 'calc_' + obs)(data_us, data_type)
  File "/usr/share/weewx/weewx/wxservices.py", line 300, in calc_maxSolarRad
data['dateTime'], self.atc)
KeyError: 'dateTime'


I suspect the driver reads it in as a REAL number, not an integer.  I'll 
dig into that a bit further and report back.

 

On Saturday, 8 September 2018 15:53:02 UTC-7, Pat wrote:
>
> Hi Louis, I don't have any specific experience with wxMesh, but maybe I 
> can help a little with MQTT. 
>
> In general, the # in a topic ID means "I want to see everything in this 
> topic". This is good for debugging, but typically bad practice for anything 
> else. For example if my broker is available to the public and anonymous 
> users can publish (hopefully you're using an ACL if your broker is publicly 
> available!), then they can post to weather/hello, or weather/mywebsite, 
> etc. and your driver will ingest everything on weather because you're 
> subscribed to weather/#. 
>
> Depending on your weewx.conf configuration, your data is probably on 
> weather/loop. Try to subscribe to that in your mosquitto_sub client to 
> verify. 
>
> Also, my guess would be you want aggregate since that will put all 
> observations in 1 published message, as opposed to individual topics like 
> weather/outTemp, weather/humidity, weather/barometer, etc. 
>
> Hope this helps a little bit. 
>
>
> On Saturday, September 8, 2018 at 5:51:02 PM UTC-4, Louis De Lange wrote:
>>
>> I  have a remote site that I want to connect to my home network using 
>> MQTT and utilize minimal data transfer.  
>>
>> The plan is to have weewx on one Raspberry Pi Zero at the remote site 
>> receiving the data from the weather station, archive it and publish to a 
>> MQTT broker using mwall's MQTT uploader.   The MQTT broker will be 
>> Mosquitto running on my home network.  Finally, I want to have another 
>> instance of weewx running on a raspberry pi on my home network using Bill 
>> Morrow's MQTT driver as input.
>>
>> Right now I am trying to test the arrangement using multiple PI's on my 
>> home network in a simulation.  
>>
>> I am able to successfully publish the data from my local station to the 
>> MQTT broker running on a different PI, and subscribe to it  with mosquitto 
>> tool mosquitto-sub - so we know publishing works..
>>
>> Where things fall apart is that I cannot get Bill Morrow's MQTT driver 
>> tor work.  Weewx starts OK, but it just waits for an archive loop and 
>> nothing else happens.
>>
>> The following is the log output from starting weewx.
>>
>> Sep 08 14:37:12 testpi systemd[1]: Starting LSB: weewx weather system...
>> Sep 08 14:37:13 testpi weewx[21197]: engine: Initializing weewx version 
>> 3.8.2
>> Sep 08 14:37:13 testpi weewx[21197]: engine: Using Python 2.7.13 
>> (default, Nov 24 2017, 17:33:09)
>>  [GCC 6.3.0 20170516]
>> Sep 08 14:37:13 testpi weewx[21197]: engine: Platform 
>> Linux-4.14.50+-armv6l-with-debian-9.4
>> Sep 08 14:37:13 testpi weewx[21197]: engine: Locale is 'en_CA.UTF-8'
>> Sep 08 14:37:13 testpi weewx[21197]: engine: pid file is 
>> /var/run/weewx.pid
>> Sep 08 14:37:13 testpi weewx[21186]: Starting weewx weather system: weewx.
>> Sep 08 14:37:13 testpi systemd[1]: Started LSB: weewx weather system.
>> Sep 08 14:37:13 testpi weewx[21201]: engine: Using configuration file 
>> /etc/weewx/weewx.conf
>> Sep 08 14:37:13 testpi weewx[21201]: engine: Loading station type wxMesh 
>> (user.wxMesh)
>> Sep 08 14:37:14 testpi weewx[21201]: wxMesh: MQTT host is localhost
>> Sep 08 14:37:14 testpi weewx[21201]: wxMesh: MQTT topic is weather
>> Sep 08 14:37:14 testpi weewx[21201]: wxMesh: MQTT client is wxclient
>> Sep 08 14:37:14 testpi weewx

[weewx-user] MQTT for remote site and min data transfer - MQTT Driver as input to weewx

[Louis De Lange]

I  have a remote site that I want to connect to my home network using MQTT 
and utilize minimal data transfer.  

The plan is to have weewx on one Raspberry Pi Zero at the remote site 
receiving the data from the weather station, archive it and publish to a 
MQTT broker using mwall's MQTT uploader.   The MQTT broker will be 
Mosquitto running on my home network.  Finally, I want to have another 
instance of weewx running on a raspberry pi on my home network using Bill 
Morrow's MQTT driver as input.

Right now I am trying to test the arrangement using multiple PI's on my 
home network in a simulation.  

I am able to successfully publish the data from my local station to the 
MQTT broker running on a different PI, and subscribe to it  with mosquitto 
tool mosquitto-sub - so we know publishing works..

Where things fall apart is that I cannot get Bill Morrow's MQTT driver tor 
work.  Weewx starts OK, but it just waits for an archive loop and nothing 
else happens.

The following is the log output from starting weewx.

Sep 08 14:37:12 testpi systemd[1]: Starting LSB: weewx weather system...
Sep 08 14:37:13 testpi weewx[21197]: engine: Initializing weewx version 
3.8.2
Sep 08 14:37:13 testpi weewx[21197]: engine: Using Python 2.7.13 (default, 
Nov 24 2017, 17:33:09)
 [GCC 6.3.0 20170516]
Sep 08 14:37:13 testpi weewx[21197]: engine: Platform 
Linux-4.14.50+-armv6l-with-debian-9.4
Sep 08 14:37:13 testpi weewx[21197]: engine: Locale is 'en_CA.UTF-8'
Sep 08 14:37:13 testpi weewx[21197]: engine: pid file is /var/run/weewx.pid
Sep 08 14:37:13 testpi weewx[21186]: Starting weewx weather system: weewx.
Sep 08 14:37:13 testpi systemd[1]: Started LSB: weewx weather system.
Sep 08 14:37:13 testpi weewx[21201]: engine: Using configuration file 
/etc/weewx/weewx.conf
Sep 08 14:37:13 testpi weewx[21201]: engine: Loading station type wxMesh 
(user.wxMesh)
Sep 08 14:37:14 testpi weewx[21201]: wxMesh: MQTT host is localhost
Sep 08 14:37:14 testpi weewx[21201]: wxMesh: MQTT topic is weather
Sep 08 14:37:14 testpi weewx[21201]: wxMesh: MQTT client is wxclient
Sep 08 14:37:14 testpi weewx[21201]: wxMesh: polling interval is 1.0
Sep 08 14:37:14 testpi weewx[21201]: wxMesh: label map is {'dateTime': 
'dateTime', 'outTemp': 'outTemp', 'outHumidity': 'outHumidity', 'inTemp': 
'inTemp', 'i
Sep 08 14:37:14 testpi weewx[21201]: engine: StdConvert target unit is 0x1
Sep 08 14:37:14 testpi weewx[21201]: wxcalculate: The following values will 
be calculated: barometer=prefer_hardware, windchill=prefer_hardware, 
dewpoint=pre
Sep 08 14:37:14 testpi weewx[21201]: wxcalculate: The following algorithms 
will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
Sep 08 14:37:14 testpi weewx[21201]: engine: Archive will use data binding 
wx_binding
Sep 08 14:37:14 testpi weewx[21201]: engine: Record generation will be 
attempted in 'hardware'
Sep 08 14:37:14 testpi weewx[21201]: engine: Using archive interval of 300 
seconds (specified in weewx configuration)
Sep 08 14:37:14 testpi weewx[21201]: engine: Using binding 'wx_binding' to 
database 'weewx.sdb'
Sep 08 14:37:14 testpi weewx[21201]: manager: Starting backfill of daily 
summaries
Sep 08 14:37:14 testpi weewx[21201]: restx: StationRegistry: Registration 
not requested.
Sep 08 14:37:14 testpi weewx[21201]: restx: Wunderground: Posting not 
enabled.
Sep 08 14:37:14 testpi weewx[21201]: restx: PWSweather: Posting not enabled.
Sep 08 14:37:14 testpi weewx[21201]: restx: CWOP: Posting not enabled.
Sep 08 14:37:14 testpi weewx[21201]: restx: WOW: Posting not enabled.
Sep 08 14:37:14 testpi weewx[21201]: restx: AWEKAS: Posting not enabled.
Sep 08 14:37:14 testpi weewx[21201]: restx: MQTT: service version is 0.18
Sep 08 14:37:14 testpi weewx[21201]: engine: Starting up weewx version 3.8.2
Sep 08 14:37:14 testpi weewx[21201]: engine: Starting main packet loop.



The following is the wxMesh section of the weewx.conf file.  

[wxMesh]
driver = user.wxMesh

# MQTT specifics
host = localhost# MQTT broker hostname
username = XXX# MQTT broker user name. Assumption is your 
broker requires authentication
password = 
topic = weather# topic is all weather (indoor and outdoor, e.g.)

poll_interval = 1

[[label_map]]
dateTime = dateTime
outTemp = outTemp
outHumidity = outHumidity
inTemp = inTemp
inHumidity = inHumidity
barometer = barometer


I am not sure about the following things in the wxMesh section of the 
weewx.conf file

1. Is the topic "weather" correct?  When I subscribe to the feed using 
mosquitto-sub the correct syntax is "weather/#"
2. In the MQTT uploader  I can select "individual" or "aggregate" records 
to upload.  What does the MQTT input driver expect?


Any help from Bill or anyone else would be appreciated.

Louis  

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this 

[weewx-user] Re: How to use the .years iterator

[Louis De Lange]

Gary,

Good point about the time to complete the reports, I will keep that in 
mind.  

At this stage with 2 years of data my report cycle takes only a few 
seconds, but with more data it will eventually become a problem.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: How to use the .years iterator

[Louis De Lange]

Gary,

I just want to confirm that you suggested approach with alltime works, and 
further I can iterate a *year.months* loop within an *alltime.years* loop.

For the benefit of anyone else, the code to print the avg temperature for 
every month in the database is as follows:

  #for $year in $alltime.years
#for $mth in $year.months
  #if $mth.outTemp.count.raw
  $mth.dateTime.format("%Y 
%m")$mth.outTemp.avg
  #end if
#end for
  #end for

  Thank you for your help

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Potential bug in template iterator

[Louis De Lange]

Gary how did you know that ?! - It works !  Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Potential bug in template iterator

[Louis De Lange]

I have created my own html template and I am playing around with adding 
some stuff that require the use of the template iterator - I asked a 
related but different question about that yesterday.

I just noticed that calling any $month tag before I invoke *#for month in 
year.months* iterator the the *$month* tag get filled as expected.  If  I 
invoke the iterator first then any following *$month* tags are returned as 
empty or N/A.

Example

  

  Avg Temp This 
Month:$month.outTemp.avg
  #for $month in $year.months
#if $month.outTemp.count.raw
$month.dateTime.format("%Y 
%m")$month.outTemp.avg
#end if
  #end for

  

Produces the following output



If I change it to 
  

  Avg Temp This 
Month:$month.outTemp.avg
  #for $month in $year.months
#if $month.outTemp.count.raw
$month.dateTime.format("%Y 
%m")$month.outTemp.avg
#end if
  #end for
  Avg Temp This 
Month:$month.outTemp.avg

  

I get the following result



Is this a bug, a feature or something else?

Thanks in advance

Louis


-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] How to use the .years iterator

[Louis De Lange]

In a template  am trying to create a table showing the average temperature 
for the month to date and then a historical list of the avg temp for all 
months in the datebase.

I tried doing this with the iterators and I note the following example in 
the customization guide

#for $month in $year.months
$month.dateTime.format("%B"): Min, max temperatures: $month.outTemp.min 
$month.outTemp.max#end for


This intuitively makes sense, but lets say I want to iterate this same 
iteration loop over all the years in the database.  I can quite figure out 
how to use the .years iteration loop

#for $year in .years

What would replace the 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] How to add literal .txt to end of variable

[Louis De Lange]

Thanks Tom,

Backslash escape character did not work but following the cheetah manual 
and enclosing the variable in brackets did.  

$monthYear

Might be useful for other people too.

On Sunday, 18 February 2018 18:35:18 UTC-8, Tom Keffer wrote:
>
> Try putting a backslash in front of any special characters. You probably 
> just need it for the dollar sign.
>
>  $monthYear
>
> The guide to Cheetah syntax is located here 
> . If you're going 
> to work with Cheetah much, it's well worth going through. There are lots of 
> goodies in there!
>
> -tk
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] How to add literal .txt to end of variable

[Louis De Lange]

Busy redoing my website template with MaterializeCSS framework.

To correctly create the dropdown for the various NOAA summaries I have to 
create an href tag as follows:

 $monthYear

Without the .txt suffix the NOAA-$monthYear tag works fine, but as soon as 
I add .txt to make NOAA-$monthYear.txt it is interpreted as a formatting 
code and cheetah falls over because it 
"cannot find 'txt' while searching for 'monthYear.txt'"

As long as whatever follows $monthYear is not a period it works.

How can I convince cheetah to put a .txt suffix after $monthYear?

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: % vs {} string formatting

[Louis De Lange]

Thanks Gary.  Works like a charm, simple.

On Sunday, 28 January 2018 12:48:00 UTC-8, gjr80 wrote:
>
> Hi,
>
> Why not do it directly in your template rather than via weeWX dot codes? I 
> think $$ should produce a literal $ in a cheetah template. Maybe something 
> like:
>
> $$$day.energyCost.sum.nolabel()
>
> to display
>
> $32.50
>
> Gary
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Barometric pressure correction the right way

[Louis De Lange]

As a previous owner of a Fine Offset station I can confirm that I noticed 
this same behavior.  Living in Canada where our homes are heated, I could 
clearly see the altimeter reading (my station did not support barometer 
correction to sea level) seesaw with the furnace operating and shutting 
down.  

Reading up on the issue it appeared that the Fine Offset hardware was doing 
a temperature correction internal to the indoor unit, but that quick 
changes to the indoor temperature threw the reading off.  There is no way 
that you can correct for that with calibration - it is a flaw in the 
hardware.  

This and other quirks in the Fine Offset hardware eventually drove me to 
buy a Vantage Pro and be done with it.  If you are a stickler for accuracy 
you will save yourself o lot of frustration by getting a Vantage Pro

On Sunday, 14 January 2018 07:17:31 UTC-8, Greg Troxel wrote:
>
>
> Andrew Milner  writes: 
>
> > I ask the question because whenever I put the heating on I see a change 
> to 
> > the barometer readings on my graphs which implies to me that the 
> pressure 
> > is changed (it appears to fall as the temperature rises).  My console is 
>
> This seems like a sign of trouble.  I see no effect on pressure readings 
> due to inside temperature changes or heating system on/off (with a 
> Vantage Pro 2), and I wouldn't expect any.  (I just looked at last 
> night's data, and the heating system behavior is obvious from inside 
> temperature.) 
>
> > 2/3 up the wall (too high to even read, but good for sensor reception!) 
> and 
> > so warms quite rapidly as the hot air from the heating rises making the 
> > pressure change quite noticeable.  I have always put it down to being a 
> > quirk of FineOffset and have ignored barometer changes which appeared to 
> be 
>
> That is a good theory :-) 
>
> > indoor temperature change related. However the variation does lead on to 
> my 
> > conclusions re compensating indoor pressure readings to match outdoor 
> > temperatures.  Maybe I need to investigate this more and try and 
> correlate 
> > 'pressure' to indoor temperature directly ...  I suspect it may be 
> > related to temperature differentials between temperature inside the 
> > pressure sensor and temperature outside the sensor ie if the temperature 
> is 
> > uniform all is fine but when there is a difference the pressure reading 
> is 
> > erroneous 
>
> There are two things to understand about your situation. 
>
> One is if the inside pressure and the outside pressure are actually 
> different.  This seems very unlikely.  Surely someone on this list has 
> set up pressure sensors in and out and compared them - hopefully they'll 
> admit to that and share results :-) 
>
> The other is which device is doing the reduction to sea level pressure 
> and if it is doing it correctly.  This is about the weight of the air 
> and is related to the outside temperature only.  It seems this is done 
> by weewx. 
>
> https://github.com/weewx/weewx/wiki/Barometer,-pressure,-and-altimeter 
>
> So I don't understand why you are having trouble.  I would look at the 
> raw station pressure data.  If that is changing correlated with the 
> heating system, then either it really is changing or your station is 
> behaving funny. 
>
> It might help to post graphs of computed baromtric pressure and inside 
> and outside temperate, along with barometric presssure reported by a 
> nearby station. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] MySQL server has gone away

[Louis De Lange]

Tom, 

I can monitor for the  "(2006, 'MySQL server has gone away')" error with 
the try statement.  Perhaps I can use that to restart the connection to the 
mysql server, as long as I know the command to use?  This way you dont have 
to change the driver.  



On Thursday, 1 June 2017 05:46:43 UTC-7, Tom Keffer wrote:

​That would require a rewrite of the MySQL driver. It also introduces a 
> problem: if the retries are tried in the driver, it will cause weewx to 
> block in the driver until the database server comes back online. So, the 
> retries would have to be limited to 60 seconds or so at the most.
>
> Let me think about this.
>
> Posted as issue #259 .
>
> -tk
>
> ​
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] MySQL server has gone away

[Louis De Lange]

While there seem to be great excitement for the new meteotemplate uploader, 
I previously wrote a service that updates my meteotemplate database 
directly without an intermediate php script.  In the service i use a 
."getSql("INSERT INTO" statement.  This works really well and I even 
resolved the dayrain issue that is now being discussed on another thread.

There is one annoying bug and I dont know how to solve it.  My 
meteotemplate install is located on a different server than weewx.  It can 
sometimes happen that the meteotemplate server is temporarily unavailable. 
 To overcome this scenario I use a "try" statement when inserting SQL data, 
so that it will just skip the upload attempt if the MySQL server is not 
available.  The bug is that the mysql insert command continue to fail after 
the meteotemplate server becomes available again, and the only way to 
correct it is to restart weewx. 

The fail message is "Error (2006, 'MySQL server has gone away')" and it 
continues to be displayed after the meteotemplate server is back on line.

Any ideas how to resolve this will be appreciated.

Louis


-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Compiling on OpenWRT router for WMR200 Tips

[Louis De Lange]

On Tuesday, 14 March 2017 14:25:11 UTC-7, Hayden Thring wrote:
>
> thanks, was wondering about doing it too, just not sure where to go, so 
> thanks.
>

Hayden,

On what router are you running weewx?  How much flash memory and how much 
ram do you have.  I considered installing weewx on OpenWRT but stopped when 
I read that you cant install python on anything with less than 50MB free 
flash memory.

Louis   

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Version 3.7.1

[Louis De Lange]

Just upgraded two separate systems to 3.7.1 with no problems whatsoever - 
one running a Fine Offset Observer with MySQL on FreeBSD and one running a 
Vantage Pro with SQLite on Arch Linux on a Seagate Goflex Home ARM5. 

When a new release comes out and it seems like there are lots of problems 
it is always good to report the successes.

Excellent job developers and thanks for your efforts.

Louis

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Why there are records double the archive_interval apart?

[Louis De Lange]

It's a wunderground thing.  Your log will say that records have been 
uploaded correctly, but they are mysteriously missing.

Use the utility wunderfixer that comes with weewx to fill in the missing 
data.

On Thursday, 16 March 2017 14:22:14 UTC-7, Theophanis Kontogiannis wrote:
>
> Hello all.
>
> I have weewx 3.7
>
> Config file:  http://pastebin.com/0RP9c9vW
>
> I start weewx every 0 and 30 minutes via crontab
> I stop weewx every 6 and 36 minutes via crontab
>
> The log file of the last two runs:  http://pastebin.com/KuFJwyU0
>
> The problem is that persistently on every iteration, there registered 
> records that are 10 minutes apart then 5 minutes apart.
>
> To be more clear, read the the tabular data here:  
> https://www.wunderground.com/personal-weather-station/dashboard?ID=IPAPAGOS4#history
>
> Example extract (in red the strange entries):
>
> 9:51 PM 7.6 °C 4 °C 78 % North 0 kph 1.1 kph 1017.2 hPa 0 mm 0 mm
> 10:01 PM 7.5 °C 4.1 °C 79 % North 0 kph 1.1 kph 1017.2 hPa 0 mm 0 mm
> 10:11 PM 7.6 °C 4.6 °C 81 % North 0 kph 1.1 kph 1017.2 hPa 0 mm 0 mm
> 10:16 PM 7.8 °C 4.7 °C 81 % North 0 kph 2.6 kph 1017.2 hPa 0 mm 0 mm
> 10:21 PM 8.1 °C 4.8 °C 80 % SE 2.6 kph 5 kph 1017.2 hPa 0 mm 0 mm
> 10:31 PM 8.4 °C 4.8 °C 78 % East 1.1 kph 2.6 kph 1016.8 hPa 0 mm 0 mm
> 10:41 PM 8.4 °C 4.2 °C 75 % East 1.1 kph 3.5 kph 1017.2 hPa 0 mm 0 mm
> 10:46 PM 8.3 °C 4.1 °C 75 % North 1.1 kph 3.5 kph 1017.2 hPa 0 mm 0 mm
> 10:51 PM 8.3 °C 4.1 °C 75 % NE 1.1 kph 3.5 kph 1017.2 hPa 0 mm 0 mm
> 11:01 PM 8.3 °C 3.9 °C 74 % SE 1.1 kph 3.5 kph 1017.2 hPa 0 mm 0 mm
>
>
> I do not know how to debug this, or what might cause it, so I am asking 
> the ecosystem's kind help on that.
>
> BR
> Theo
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Out of memory Error - Raspberry Pi

[Louis De Lange]

On Tuesday, 28 February 2017 07:50:50 UTC-8, vince wrote:
>
>
> I run weewx on a computer with 128MB RAM, if that helps any.
>
> One thing to watch for is the forecast extension, which can use a 'lot' of 
> memory (or it did for me), but weewx plus a couple skins is very light 
> typically. 
>

I second that - I run weewx (with forecasting module) on an ARM5 processor 
with 128MB memory and weewx uses less than 50% of the available memory.  

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: 3rd Party Database Access

[Louis De Lange]

On Monday, 23 January 2017 15:20:59 UTC-8, Louis De Lange wrote:
>
> This is a question about writing records to 3rd party databases such as 
> Meteotemplate.  
>
> In addition to WeeWX I have a site running Meteotemplate with it's own 
> MySQL database.  The normal way of filling the Meteotemplate database is 
> through clientraw.txt or realtime.txt and cron jobs, but I decided to write 
> a service that automatically populates the Meteotemplate database on each 
> archive period of WeeWX.  
>
>
> So the next thing I want to do is to create a manual entry point into the 
meteotemplate.py script to compare the weewx database and the meteotemplate 
database and backfill any missing data in the meteotemplate database. 
 Following the database access instructions in the customization guide and 
stealing from other sources I came up with the following script at the end 
of my meteotemplate.py update script:
 
# simple interface for manual database backfill and diagnostics
#
# cd /home/weewx
# PYTHONPATH=bin python bin/user/meteotemplate.py

if __name__ == "__main__":
usage = """%prog"""

def main():
print "This is a test for command line access"
db_manager = weewx.manager.open_manager_with_config(config_dict, 
data_binding='wx_binding')
# SQL Query to get all weewx timestamps since a specific time:
db_manager.getSql("SELECT dateTime FROM %s "\
  "WHERE dateTime>?" % db_manager.table_name, 
(1484899200))
main()

When I execute this snippet from the command line I get the following:

  File "bin/user/meteotemplate.py", line 168, in main
db_manager = weewx.manager.open_manager_with_config(config_dict, 
data_binding='wx_binding')
NameError: global name 'config_dict' is not defined

I know that I need to somehow initialize and import config_dict but I am 
not sure how to do that outside of class definitions. Any of the examples 
I've looked at creates a subclass of something where config_dict is 
defined, but I don't think I can do that in the 'main()' script.

Can anyone point me in the right direction?

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] 3rd Party Database Access

[Louis De Lange]

On Monday, 23 January 2017 16:25:26 UTC-8, Louis De Lange wrote:
>
>
>
> On Monday, 23 January 2017 15:37:18 UTC-8, Tom Keffer wrote:
>>
>> On Mon, Jan 23, 2017 at 3:20 PM, Louis De Lange <kilo...@gmail.com> 
>> wrote:
>>
>>>
>>> 1.   The meteotemplate database uses a type datetime primary key, rather 
>>> than unix epoch.  I could not get addRecord to work in that circumstance so 
>>> I ended up using a getsql function to write the record to meteotemplate.
>>>
>>>
>> One option would be to augment the record with the datetime object that 
>> Meteotemplate needs. Then dateTime just gets carried along for the ride. 
>> Or, maybe I'm misunderstanding your architecture.
>>
>
> I tried doing just this, but then the day calcs failed when the DateTime 
> type was text.  However, after changing the manager to class Manager the 
> day summaries wont be filled and I can see that this will work. 
>  
>
>> ​
>>
>>> 2.   I had to add a usUnit column to the meteotemplate database because 
>>> weewx does a unit check and wont allow to post a new record unless the 
>>> usUnits column match.  This is not a big deal, but is there a way around 
>>> that?  In particular, the individual records in the meteotemplate database 
>>> can be any combination of units - which makes a single unit indicator 
>>> irrelevant, apart from making the database write possible
>>>
>>
>> You could subclass Manager, overriding function _check_unit_system​() so 
>> it does not do the check, or does some other check.
>>
>
> This can be my next project to figure out how to do this...
>
>  
>
>>  
>>
>>>
>>> 3.   The  standard db_manager = 
>>> self.engine.db_binder.get_manager(data_binding='name_of_binding', 
>>> initialize=True)   function insists on adding day summary tables, and 
>>> when I set initialize to false and delete the unnecessary tables it 
>>> gives an error that the tables are missing.  Is there a way to eliminate 
>>> the creation of the day summary tables?
>>>
>>
>> ​Yes. Use class Manager, rather than DaySummaryManager.
>>
>
> Works!  Thanks. 
>
>
>> Hope this helps.
>>
>> -tk​
>>
>>
Just to close the loop on this discussion and help anyone else.

3.  I changed the manager to class Manager and that solved the issue of the 
day summary tables being added.

2.  I subclassed Manager ( and changed manager again to my new subclass 
MeteotemplateManager).  But since I am using a direct database call getsql, 
modifying function _check_unit_system​() did not work as it was not the 
problem.  The troublesome function was _sync() which was being called every 
time a manager was initialized.  I modified _sync() so that it wont try to 
find the database units and now the meteotemplate database operates without 
a dummy usUnits column.

1.  I could not get the call to addRecord to work, but I am OK with that - 
since this is a non-weewx database I think I prefer the straight getsql 
approach. 
 

Thanks for the help on this, Tom.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: 3rd Party Database Access

[Louis De Lange]

On Monday, 23 January 2017 16:12:33 UTC-8, mwall wrote:
>
> louis,
>
> it sounds like you have 'direct deposit' to meteotemplate under control, 
> but here is a different approach: a meteotemplate uploader:
>
> https://github.com/matthewwall/weewx-meteotemplate
>
> it is based on this discussion:
>
> http://www.wxforum.net/index.php?topic=31018.0
>
> you'll have to check with jachym to see what the status is of the 
> meteotemplate upload.php component.
>
> m
>

I originally contemplated this method as well, but then decided to go for 
the direct deposit (as you call it) method.  It works well - I may add some 
configuration options to it and release it as an extension.  
 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] 3rd Party Database Access

[Louis De Lange]

On Monday, 23 January 2017 15:37:18 UTC-8, Tom Keffer wrote:
>
> On Mon, Jan 23, 2017 at 3:20 PM, Louis De Lange <kilo...@gmail.com 
> > wrote:
>
>>
>> 1.   The meteotemplate database uses a type datetime primary key, rather 
>> than unix epoch.  I could not get addRecord to work in that circumstance so 
>> I ended up using a getsql function to write the record to meteotemplate.
>>
>>
> One option would be to augment the record with the datetime object that 
> Meteotemplate needs. Then dateTime just gets carried along for the ride. 
> Or, maybe I'm misunderstanding your architecture.
>

I tried doing just this, but then the day calcs failed when the DateTime 
type was text.  However, after changing the manager to class Manager the 
day summaries wont be filled and I can see that this will work. 
 

> ​
>
>> 2.   I had to add a usUnit column to the meteotemplate database because 
>> weewx does a unit check and wont allow to post a new record unless the 
>> usUnits column match.  This is not a big deal, but is there a way around 
>> that?  In particular, the individual records in the meteotemplate database 
>> can be any combination of units - which makes a single unit indicator 
>> irrelevant, apart from making the database write possible
>>
>
> You could subclass Manager, overriding function _check_unit_system​() so 
> it does not do the check, or does some other check.
>

This can be my next project to figure out how to do this...

 

>  
>
>>
>> 3.   The  standard db_manager = 
>> self.engine.db_binder.get_manager(data_binding='name_of_binding', 
>> initialize=True)   function insists on adding day summary tables, and 
>> when I set initialize to false and delete the unnecessary tables it 
>> gives an error that the tables are missing.  Is there a way to eliminate 
>> the creation of the day summary tables?
>>
>
> ​Yes. Use class Manager, rather than DaySummaryManager.
>

Works!  Thanks. 


> Hope this helps.
>
> -tk​
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] 3rd Party Database Access

[Louis De Lange]

This is a question about writing records to 3rd party databases such as 
Meteotemplate.  

In addition to WeeWX I have a site running Meteotemplate with it's own 
MySQL database.  The normal way of filling the Meteotemplate database is 
through clientraw.txt or realtime.txt and cron jobs, but I decided to write 
a service that automatically populates the Meteotemplate database on each 
archive period of WeeWX.  

This is all working but I had to do a few workarounds be able to write to 
the database and I am wondering if there are better ways to do it.

1.   The meteotemplate database uses a type datetime primary key, rather 
than unix epoch.  I could not get addRecord to work in that circumstance so 
I ended up using a getsql function to write the record to meteotemplate.

2.   I had to add a usUnit column to the meteotemplate database because 
weewx does a unit check and wont allow to post a new record unless the 
usUnits column match.  This is not a big deal, but is there a way around 
that?  In particular, the individual records in the meteotemplate database 
can be any combination of units - which makes a single unit indicator 
irrelevant, apart from making the database write possible

3.   The  standard db_manager = 
self.engine.db_binder.get_manager(data_binding='name_of_binding', 
initialize=True)   function insists on adding day summary tables, and when 
I set initialize to false and delete the unnecessary tables it gives an 
error that the tables are missing.  Is there a way to eliminate the 
creation of the day summary tables?

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Help with using weewx.tags

[Louis De Lange]

Tom,

Absolutely agree about saving the incremental data, which is what I am 
really after.  

The reason I am also saving the cumulative data and using the last saved 
record to calculate the current incremental value is to limit an error that 
will be present if my server goes offline for a few days - on a restart 
there would be a bunch of incremental values missing that will affect the 
accuracy of longer term summations.  It happened last summer that the 
server went offline for a week while I was on vacation.

Perhaps there is a better way to do it, and I am happy to learn - but this 
is why I went down that rabbit hole.

On Wednesday, 11 January 2017 16:14:26 UTC-8, Tom Keffer wrote:
>
> Good. For the future: this is why it's better to store the amount 
> accumulated during the archive period for extensive quantities like rain 
> and energy, rather than the cumulative value. This way, you can just do a 
> simple sum over the desired time period to get total energy consumption.
>
> But, if you have the cumulative value in Python, why are you messing 
> around with RecordBinders and the like? Why not just calculate the delta 
> and include it in the archive record like any other quantity?
>
> -tk
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Help with using weewx.tags

[Louis De Lange]

This question is more related to python programming than using weewx, but I 
cant find a solution - so I hope that Tom and the other gurus can point me 
in the right direction.

I am writing a function to capture power consumption from the utility 
meter.  As part of that I am storing the cumulative energy reading for each 
archive period in the archive.  

To get the incremental energy reading between archive periods I read the 
last archive record of the cumulative energy with the "latest" function in 
weewx.tags.  Reading and printing the latest archive record of cumulative 
energy works fine - here is a snippet of the code to do that (thanks to 
Tom's answers to previous threads)

  # Create a RecordBinder, bound to the database and timestamp
  rb = weewx.tags.RecordBinder(db_lookup, timestamp)
  print "The last cumulative electrical energy record =", 
rb.latest().cumEnergy

When I try to subtract the value for rb.latest().cumEnergy from the current 
cumulative energy reading just obtained from the meter, I get a type error.

Then I added the following code to try and figure out what the out type of 
rb.latest().cumEnergy 
is

  last_cum_energy = rb.latest().cumEnergy
  print type(last_cum_energy)

This does not help because the output of the last print command is




I tried doing a float modification, but that does not work.

Any help to turn the output of the function into something I can do 
arithmetic with will be appreciated.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Weewx-wd StackedWindRose fails on import PIL modules

[Louis De Lange]

Gary,

Thanks for that.  I changed it to windSpeed and it worked!  

Now the really perplexing thing - my station provides gust data (even 
though it appears in 4km/h increments).  I know windGust is in the database 
and to prove it I ran a query shown below listing the dateTime, windSpeed 
and windGust columns.  Bottom line - windSpeed plots fine, windGust does 
not.

sqlite> SELECT dateTime, windSpeed, windGust FROM archive WHERE (dateTime > 
1481742000);
1481742300|1.38086956521739|7.38
1481742600|0.7729167|7.38
1481742900|1.17652173913043|4.92
1481743200|1.117917|7.38
1481743500|0.116521739130435|2.46
1481743800|0.223043478260869|4.92
1481744100|0.09291667|2.46
1481744400|0.2420833|4.92
1481744700|0.375454545454546|4.92
1481745000|0.0467|2.46
1481745300|0.01875|2.46
1481745600|0.0778260869565217|2.46
1481745900|0.845652173913043|4.92
1481746200|1.425833|7.38
1481746500|0.456956521739131|4.92

Louis


On Wednesday, 14 December 2016 11:42:14 UTC-8, gjr80 wrote:
>
> Louis,
>
> Does your station provide windGust data? The windSpeed/WindGust plot you 
> included seems a little unusual.in terms of windGust. One thing I did 
> realise after I tidied up the code yesterday was that the windrose defaults 
> to plotting windGust. This is problematic as not all stations provide 
> windGust data. You may have to change the windrose to plot windSpeed. The 
> easiest way to do this is to edit skin.conf in the StackedWindRose skin, 
> locate [ImageStackedWindRoseGenerator] near the bottom of the file. Change 
> windGust to windSpeed. Save skin.conf and the windrose 
> should use windSped next time it generates. No need to stop/start weewx.
>
> Gary
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Weewx-wd StackedWindRose fails on import PIL modules

[Louis De Lange]

Gary

Thanks for the fix (1.0.2).  I applied the fix and now the units on the 
generated image shows up as km/h.  Unfortunately the wind rose still show 
all wind speeds as zero, when in fact I have been seeing light wind all 
day.  See attached the current images as reference.

I wish I could provide more feedback, but the log is clear.


On Tuesday, 13 December 2016 17:08:37 UTC-8, gjr80 wrote:
>
> Well on first look it looks like the overrides in weewx.conf are not 
> being picked up, looking closer at the stacked windrose generator code I 
> can see that the overrides are being picked up but the generator never does 
> any conversion of the raw wind speed data from the database. In terms of 
> effects, this means the windrose would always use the speed units that are 
> used in the weewx database (for most this is mph). Not sure how I missed 
> this, that generator was written over 2 years ago and I distinctly remember 
> testing the units - perhaps it coincided with changing database units on my 
> then test system - I do remember doing that a few times. No matter. 
>
> To fix the issue just move aside your current 
> bin/user/imageStackedWindRose3.py then download the latest version of the 
> file from bitbucket. Easiest approach to downloading is probably using wget 
> - this command should do it:
>
> $ wget -P /var/tmp https://
> bitbucket.org/ozgreg/weewx-wd/raw/bc5c32cd97e5ec7f81ea8f83eb0edb2f241eaa3f/bin/user/imageStackedWindRose3.py
>
> Note this file has the import Image/ImageDraw fix from a few days ago so 
> that issue should not give you any more grief. Thanks for pointing out the 
> issues.
>
> Gary
>
>
> On Wednesday, 14 December 2016 03:11:47 UTC+10, Louis De Lange wrote:
>>
>>
>>
>> On Sunday, 11 December 2016 18:52:27 UTC-8, gjr80 wrote:
>>>
>>> Thanks, I thought that one had come up before and had been fixed, 
>>> apparently not. I have commited a fix to the weewx-WD bitbucket repo and 
>>> will release a 1.0.2 version this week sometime. Oh, and by the way the fix 
>>> is the same as is used by weewx in bin/weeplot/genplot.py:
>>>
>>> try:
>>> from PIL import Image, ImageDraw
>>> except ImportError:
>>> import Image, ImageDraw
>>>
>>> Gary
>>>
>>>
>> Gary,
>>
>> Next problem - according to the log the wdStackedWindRose report runs 
>> without any error.
>>
>> Dec 13 08:51:46 goflexhome weewx[25754]: reportengine: Running report 
>> wdStackedWindRose
>> Dec 13 08:51:46 goflexhome weewx[25754]: reportengine: Found configuration 
>> file /home/weewx/skins/StackedWindRose/skin.conf for report wdStackedWindRose
>> Dec 13 08:51:46 goflexhome weewx[25754]: imageStackedWindRose: Generated 1 
>> images for wdStackedWindRose in 0.25 seconds
>>
>>
>> The image daywindrose.png is created, but it shows all winds to be zero - 
>> also, it shows the units to be mph rather than kmph as configured.  
>>
>>
>> See the generated image and the regular weewx wind vector image attached for 
>> comparison.
>>
>>
>> The clip from my weewx.conf file below show the unit overrides to kmph.
>>
>>
>> [[wdStackedWindRose]]
>>
>> HTML_ROOT = public_html/WD
>>
>> skin = StackedWindRose
>>
>> [[[Units]]]
>>
>> TimeFormats
>>
>> date_time_f = %d/%m/%Y %H:%M
>>
>> date_f = %d/%m/%Y
>>
>> Groups
>>
>> group_speed = km_per_hour
>>
>> [[wdStackedWindRose]]
>> HTML_ROOT = public_html/WD
>> skin = StackedWindRose
>> [[[Units]]]
>> TimeFormats
>> date_time_f = %d/%m/%Y %H:%M
>> date_f = %d/%m/%Y
>> Groups
>> group_speed = km_per_hour
>>
>> group_speed2 = km_per_hour2 
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Weewx-wd StackedWindRose fails on import PIL modules

[Louis De Lange]

Correction on previous post - the StackedWindRose segment in the weewx.conf 
file only occurs once - I copied the text twice by mistake on posting.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Weewx-wd StackedWindRose fails on import PIL modules

[Louis De Lange]

I have a strange issue with the wdStackedWindRose template and would 
appreciate enlightenment. 

I get the following in the log:

*Dec 11 09:01:30 goflexhome weewx[22115]: reportengine: Unable to 
instantiate generator 
user.imageStackedWindRose3.ImageStackedWindRoseGenerator*
*Dec 11 09:01:30 goflexhome weewx[22115]:   No module named 
Image*
*Dec 11 09:01:30 goflexhome weewx[22115]:   Traceback (most 
recent call last):*
*Dec 11 09:01:30 goflexhome weewx[22115]: File 
"/home/weewx/bin/weewx/reportengine.py", line 220, in run*
*Dec 11 09:01:30 goflexhome weewx[22115]:   obj = 
weeutil.weeutil._get_object(generator)(*
*Dec 11 09:01:30 goflexhome weewx[22115]: File 
"/home/weewx/bin/weeutil/weeutil.py", line 1015, in _get_object*
*Dec 11 09:01:30 goflexhome weewx[22115]:   mod = 
__import__(module)*
*Dec 11 09:01:30 goflexhome weewx[22115]: File 
"/home/weewx/bin/user/imageStackedWindRose3.py", line 35, in *
*Dec 11 09:01:30 goflexhome weewx[22115]:   import Image*
*Dec 11 09:01:30 goflexhome weewx[22115]:   ImportError: No 
module named Image*
*Dec 11 09:01:30 goflexhome weewx[22115]:   Generator ignored*

So I followed Tom's Pillow troubleshooting guide in the Wiki and I have all 
the modules installed.  When I change the imageStackedWindRose3.py to use 

*"from PIL import Image*
*from PIL import ImageDraw"*

it works fine.  

Any idea why that is?

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: forecast extension version 3.2.0

[Louis De Lange]

On Saturday, 10 December 2016 18:59:27 UTC-8, mwall wrote:
>
> On Saturday, December 10, 2016 at 9:27:02 PM UTC-5, Louis De Lange wrote:
>>
>> It was absolutely a matter of formatting.  With the right formatting I 
>> can round to whole numbers of rain or snow.
>>
>> I would prefer to display rain in mm and snow in cm, but there is only 
>> one group unit for precipitation.
>>
>
> dot code to the rescue!  as gary pointed out, you can use the dot code to 
> do cm for snow and mm for rain.
>
> and you can also use the dot code to make the precision for mm different 
> than the precision for cm.
>
> for example, one decimal place for cm, no decimal places for mm:
>
> $period.qpf.cm.nolabel('%.1f', ' ')
>
> $period.qsf.mm.nolabel('%.0f', ' ')
>
> qpf is for rain, qsf is for snow (names are based on NWS conventions).
>
> hope that helps!
>
> m 
>

Thanks guys, this is exactly the right solution.

 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: forecast extension version 3.2.0

[Louis De Lange]

Thanks for a really great tool, and in general thanks for all the support 
you and Tom and others are providing.

I am currently using version 3.08, and it has an issue that the forecast 
quantities for rain or snow are in US units.  

Although I can change the display units to metric, the forecast shows up 
with really weird quantities that are obviously related to the US units in 
the base data.  For example, today's forecast (WU source, btw) shows 3.3mm 
preciptation, or 33.02mm of snow.

Is this issue solved in the new version?  

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: FO USB

[Louis De Lange]

I was not suggesting using FreeBSD - I simply mentioned that using it might 
contribute to overall system stability.

My point was that FO supplies some of their stations with the Observer receiver 
module (and accompanying indoor pressure sensor). There is no indoor console 
required and hence no USB lockups. 

I don't know if someone has tried to operate any of console stations with an 
observer, but if it is possible it would be stable solution.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: StdArchive and archive_delay

[Louis De Lange]

1.  I cant find a version number on the download zip file or the 
interceptor.py file - I can tell you that I downloaded the driver on July 
25, 2016
2.  I am using Weather logger V2.1.9 firmware, so I send the data directly 
to the same port that Interceptor is configured to monitor
3.  It does send at regular intervals as the log file shows, although the 
interval seems to vary a bit around the published 16 seconds


On Monday, 5 September 2016 17:42:57 UTC-7, mwall wrote:
>
>
> which version of the interceptor driver are you using?
>
> how are you sending data to the interceptor driver?  direct from the 
> observer?  via a cgi relay?  using ncat or tcpdump or other sniffing tool?
>
> your observer should be sending data at regular intervals.  but if you're 
> sniffing there could be delays.  or there could be delays in the way the 
> socket server in the interceptor driver is handling the data.
>
> the genLoopPackets method should not be blocking.  the socket server posts 
> data to a queue, and the genLoopPackets method simply checks the queue to 
> see if there are any data.
>
> for the observer, the interceptor driver *should* be using the station 
> time, not the computer time, for the packet timestamps.  (see the code for 
> the Observer.Parser.parse method)
>
> (it looks like it is time for me to split the interceptor driver into 4 
> different drivers.  when i wrote it, i was hoping there was more in common 
> between the hardware from fineoffset, lacrosse, oregonscientific, and 
> acurite.  it turns out that there are almost as many specializations and 
> commonalities, even though they all say that they do the same thing on the 
> tin.)
>
> m 
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: StdArchive and archive_delay

[Louis De Lange]

1.I cant find a version number on the download zip file or the 
interceptor.py file - I can tell you that I downloaded the driver on July 
25, 2016

2. 

On Monday, 5 September 2016 17:42:57 UTC-7, mwall wrote:
>
>
> which version of the interceptor driver are you using?
>
> how are you sending data to the interceptor driver?  direct from the 
> observer?  via a cgi relay?  using ncat or tcpdump or other sniffing tool?
>
> your observer should be sending data at regular intervals.  but if you're 
> sniffing there could be delays.  or there could be delays in the way the 
> socket server in the interceptor driver is handling the data.
>
> the genLoopPackets method should not be blocking.  the socket server posts 
> data to a queue, and the genLoopPackets method simply checks the queue to 
> see if there are any data.
>
> for the observer, the interceptor driver *should* be using the station 
> time, not the computer time, for the packet timestamps.  (see the code for 
> the Observer.Parser.parse method)
>
> (it looks like it is time for me to split the interceptor driver into 4 
> different drivers.  when i wrote it, i was hoping there was more in common 
> between the hardware from fineoffset, lacrosse, oregonscientific, and 
> acurite.  it turns out that there are almost as many specializations and 
> commonalities, even though they all say that they do the same thing on the 
> tin.)
>
> m 
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.