[weewx-user] Re: NOAA reports question

[Craig Young]

Yes, it appears to have been some sort of caching issue.  Looks like after 
midnight the display updated.  I can now see all of the monthly NOAA data.  
I have more archive updates to do and will look at the web server cache 
after each one.

Craig

On Monday, October 16, 2023 at 9:23:04 AM UTC+13 Craig Young wrote:

> I am only using one skin, Seasons.  When I delete the files and they get 
> rebuilt they do show the new data on Seasons.  In fact, the NOAA yearly 
> report does have the correct numbers for each month.  The History reports 
> are all correct and do update with the archive load.  It is just the 
> monthly NOAA reports that are not displaying correctly.
> I will check the web server and browser cache next.
>
> Craig
>
> On Sunday, October 15, 2023 at 9:48:56 PM UTC+13 gjr80 wrote:
>
>> The Seasons skin loads the respective NOAA format report file via a call 
>> to small javascript function. No processing of the file is performed other 
>> than reading the posting the content. This html template 
>> <https://github.com/weewx/weewx/blob/master/skins/Seasons/tabular.html.tmpl#L35>
>>  
>> and this javascript 
>> <https://github.com/weewx/weewx/blob/master/skins/Seasons/seasons.js#L164> 
>> refer. 
>>
>> The first two things I would be doing if you have forced regeneration of 
>> all NOAA format files is to check the re-generated files have been uploaded 
>> to your web server and then make sure that your web browser cache is 
>> cleared.
>>
>> Gary
>>
>> On Sunday, 15 October 2023 at 15:24:22 UTC+10 craig.y...@gmail.com wrote:
>>
>>> I have loaded several months of archive data into the DB and everything 
>>> looks okay except  when I look at the NOAA reports.  I removed all files 
>>> from the NOAA folder and it was rebuilt on the next report cycle, and those 
>>> txt files look great.  But in Seasons, when I select a month in the upper 
>>> right (NOAA report) they do not match the txt files.  Are the NOAA txt 
>>> files translated to some other file before displayed in Seasons?  I did 
>>> remove all .png files and it made no difference.
>>> More specifically, the txt files for each month show data for each day, 
>>> as separate lines in the file.  But when displayed in Seasons, I get only a 
>>> couple of days showing data.  Usually at the end of the month.  So the txt 
>>> files show all the data but Seasons only displays a couple of lines.
>>>
>>> Craig
>>>
>>

-- 
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/6448abac-358e-49c5-b181-f1bf41ba62fen%40googlegroups.com.

[weewx-user] Re: NOAA reports question

[Craig Young]

I am only using one skin, Seasons.  When I delete the files and they get 
rebuilt they do show the new data on Seasons.  In fact, the NOAA yearly 
report does have the correct numbers for each month.  The History reports 
are all correct and do update with the archive load.  It is just the 
monthly NOAA reports that are not displaying correctly.
I will check the web server and browser cache next.

Craig

On Sunday, October 15, 2023 at 9:48:56 PM UTC+13 gjr80 wrote:

> The Seasons skin loads the respective NOAA format report file via a call 
> to small javascript function. No processing of the file is performed other 
> than reading the posting the content. This html template 
> 
>  
> and this javascript 
>  
> refer. 
>
> The first two things I would be doing if you have forced regeneration of 
> all NOAA format files is to check the re-generated files have been uploaded 
> to your web server and then make sure that your web browser cache is 
> cleared.
>
> Gary
>
> On Sunday, 15 October 2023 at 15:24:22 UTC+10 craig.y...@gmail.com wrote:
>
>> I have loaded several months of archive data into the DB and everything 
>> looks okay except  when I look at the NOAA reports.  I removed all files 
>> from the NOAA folder and it was rebuilt on the next report cycle, and those 
>> txt files look great.  But in Seasons, when I select a month in the upper 
>> right (NOAA report) they do not match the txt files.  Are the NOAA txt 
>> files translated to some other file before displayed in Seasons?  I did 
>> remove all .png files and it made no difference.
>> More specifically, the txt files for each month show data for each day, 
>> as separate lines in the file.  But when displayed in Seasons, I get only a 
>> couple of days showing data.  Usually at the end of the month.  So the txt 
>> files show all the data but Seasons only displays a couple of lines.
>>
>> Craig
>>
>

-- 
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/2c0bdbb0-126c-4bc0-a501-182309f0d98bn%40googlegroups.com.

[weewx-user] NOAA reports question

[Craig Young]

I have loaded several months of archive data into the DB and everything 
looks okay except  when I look at the NOAA reports.  I removed all files 
from the NOAA folder and it was rebuilt on the next report cycle, and those 
txt files look great.  But in Seasons, when I select a month in the upper 
right (NOAA report) they do not match the txt files.  Are the NOAA txt 
files translated to some other file before displayed in Seasons?  I did 
remove all .png files and it made no difference.
More specifically, the txt files for each month show data for each day, as 
separate lines in the file.  But when displayed in Seasons, I get only a 
couple of days showing data.  Usually at the end of the month.  So the txt 
files show all the data but Seasons only displays a couple of lines.

Craig

-- 
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/a4b27cbe-d62d-4598-b790-0795db4c10a2n%40googlegroups.com.

Re: [weewx-user] "First Light", working, but with some problems

[Craig Young]

I found a solution that results in the DB and WU being updated each minute.
First, I set weewx config back to the original settings:
[StdArchive]
  archive_interval = 60
  archive_delay = 5

Then I changed the driver to output two types of loop packets:
a) if there was no data received from the data logger after 5 seconds then 
a null packet of only 'dateTime' and 'usUnits' was returned to weewx.
b) if data was received within 5 seconds then the full loop packet was 
returned to weewx.
The driver is essentially called every 5 seconds by weewx.  So 1 full loop 
packet is received each minute and this is written to the DB and WU updated.

Problem solved.

Craig


On Monday, October 2, 2023 at 10:09:52 AM UTC+13 Craig Young wrote:

> This also updates the DB and WU every minute:
> [StdArchive]
>   archive_interval = 1
>   archive_delay = 10
>
> I tried archive_interval = 0 but got a divide by zero exception.  I assume 
> that is because the software tried to calculate an average for the archive 
> record by dividing the # of loop records received in that interval by the 
> archive interval in seconds.
> Craig
>
>
> On Monday, October 2, 2023 at 4:31:18 AM UTC+13 Craig Young wrote:
>
>> The "429" error is fixed.  Thanks Karen and Tom.
>> The 2 minute update problem, I changed the driver to poll the hardware 
>> (serial port) every 15 seconds, but the database still updated every 2 
>> minutes.  After playing with several parameters in the driver and 
>> weewx.conf I finally got the database to update every 1 minute and WU to 
>> also update every minute.  To do this I had to make this change:
>> [StdArchive]
>>   archive_interval = 15
>>
>> This resulted in an error message when I started weewx (from SYSLOG):
>> WARNING weewx.engine: Archive delay (15) is unusually long
>>
>> I thought reducing it from 60 sec to 15 sec would get an error of it 
>> being too short.
>>
>> In the Database the records show an interval of 0.25 but they are now 
>> being updated every 1 minute which I assume is because the driver is 
>> sending a loop packet every 1 minute.  So the problem appears to be related 
>> to the archive record interval.  Here is what I think may be happening.  
>> Weewx gets a loop packet and processes it, control is then returned to the 
>> driver.  The driver, 1 minute later, sends another loop packet.  Weewx THEN 
>> begins a 1 minute archive interval and then processes the archive record, 
>> so two minutes later.  I did notice the error message says archive 
>> "delay".  In theory, if I set the delay to 0 then when a loop packet 
>> arrives, once every minute from the driver, then weewx would immediately 
>> write it to the DB and update WU.  Is that correct?
>>
>> Craig
>>
>> On Monday, October 2, 2023 at 1:31:06 AM UTC+13 Tom Keffer wrote:
>>
>>> First, a note on how weewxd works: the driver blocks, waiting for data 
>>> to come in. The program cannot do anything while it is blocked. Once data 
>>> comes in, then it can proceed, emit a LOOP packet, then the rest of the 
>>> program can process it.
>>>
>>> Your fileparse polling interval is 60 seconds. This means that it will 
>>> sleep for 60 seconds before reading new data from the file. Nothing will 
>>> happen until it wakes up. 
>>>
>>> Meanwhile, your archive interval is 60 seconds. This means weewxd will 
>>> take whatever data has accumulated over the previous 60 seconds and use it 
>>> to create an archive record.
>>>
>>> With such a short archive interval and long LOOP polling interval, you 
>>> can see how it's easy for the program to be sleeping, or have nothing 
>>> available at the one minute mark.
>>>
>>> Solution: if you can, have data available more frequently than once 
>>> every 60 seconds. This would allow you to shorten the fileparse polling 
>>> interval. If that's not possible, lengthen the archive interval to at least 
>>> 5 minutes.
>>>
>>> Best yet, do both.
>>>
>>> As for the "429" error, this is happening because your system is trying 
>>> to register too frequently. Almost all weewx stations do this because the 
>>> default registration interval does not work well with the station 
>>> registration. You can ignore it, or tell weewx to do the station 
>>> registration less frequently. In weewx.conf:
>>>
>>> [StdRESTful]
>>> [[StationRegistry]]
>>> register_this_station = false
>>> post_interval = 86400
>>>
>>>
>>>
&g

Re: [weewx-user] "First Light", working, but with some problems

[Craig Young]

This also updates the DB and WU every minute:
[StdArchive]
  archive_interval = 1
  archive_delay = 10

I tried archive_interval = 0 but got a divide by zero exception.  I assume 
that is because the software tried to calculate an average for the archive 
record by dividing the # of loop records received in that interval by the 
archive interval in seconds.
Craig


On Monday, October 2, 2023 at 4:31:18 AM UTC+13 Craig Young wrote:

> The "429" error is fixed.  Thanks Karen and Tom.
> The 2 minute update problem, I changed the driver to poll the hardware 
> (serial port) every 15 seconds, but the database still updated every 2 
> minutes.  After playing with several parameters in the driver and 
> weewx.conf I finally got the database to update every 1 minute and WU to 
> also update every minute.  To do this I had to make this change:
> [StdArchive]
>   archive_interval = 15
>
> This resulted in an error message when I started weewx (from SYSLOG):
> WARNING weewx.engine: Archive delay (15) is unusually long
>
> I thought reducing it from 60 sec to 15 sec would get an error of it being 
> too short.
>
> In the Database the records show an interval of 0.25 but they are now 
> being updated every 1 minute which I assume is because the driver is 
> sending a loop packet every 1 minute.  So the problem appears to be related 
> to the archive record interval.  Here is what I think may be happening.  
> Weewx gets a loop packet and processes it, control is then returned to the 
> driver.  The driver, 1 minute later, sends another loop packet.  Weewx THEN 
> begins a 1 minute archive interval and then processes the archive record, 
> so two minutes later.  I did notice the error message says archive 
> "delay".  In theory, if I set the delay to 0 then when a loop packet 
> arrives, once every minute from the driver, then weewx would immediately 
> write it to the DB and update WU.  Is that correct?
>
> Craig
>
> On Monday, October 2, 2023 at 1:31:06 AM UTC+13 Tom Keffer wrote:
>
>> First, a note on how weewxd works: the driver blocks, waiting for data to 
>> come in. The program cannot do anything while it is blocked. Once data 
>> comes in, then it can proceed, emit a LOOP packet, then the rest of the 
>> program can process it.
>>
>> Your fileparse polling interval is 60 seconds. This means that it will 
>> sleep for 60 seconds before reading new data from the file. Nothing will 
>> happen until it wakes up. 
>>
>> Meanwhile, your archive interval is 60 seconds. This means weewxd will 
>> take whatever data has accumulated over the previous 60 seconds and use it 
>> to create an archive record.
>>
>> With such a short archive interval and long LOOP polling interval, you 
>> can see how it's easy for the program to be sleeping, or have nothing 
>> available at the one minute mark.
>>
>> Solution: if you can, have data available more frequently than once every 
>> 60 seconds. This would allow you to shorten the fileparse polling interval. 
>> If that's not possible, lengthen the archive interval to at least 5 minutes.
>>
>> Best yet, do both.
>>
>> As for the "429" error, this is happening because your system is trying 
>> to register too frequently. Almost all weewx stations do this because the 
>> default registration interval does not work well with the station 
>> registration. You can ignore it, or tell weewx to do the station 
>> registration less frequently. In weewx.conf:
>>
>> [StdRESTful]
>> [[StationRegistry]]
>> register_this_station = false
>> post_interval = 86400
>>
>>
>>
>> Station registration is working fine. 
>>
>> -tk
>>
>> On Sat, Sep 30, 2023 at 8:57 PM Craig Young  wrote:
>>
>>> After writing a new driver for my station and configuring weewx to 
>>> support its  data stream I was able to run weewx live for a few minutes, 
>>> then shut it down to check SYSLOG (debug=2).
>>> There appears to be two problems (see attached syslog excerpt):
>>>
>>> a) The database and reports are updating on two minutes intervals.  The 
>>> config file has this set for 1 minute intervals:
>>> "INFO weewx.engine: Using archive interval of 60 seconds (software 
>>> record generation)"
>>>
>>>  Maybe there is some other setting required?
>>>
>>> b) There are several HTTP ERROR 429: TOO MANY REQUESTS messages.  Not 
>>> sure why this is happening.
>>>
>>> I think I am close to a fully operational system, just need to clean up 
>>> a few things.
>>>

Re: [weewx-user] "First Light", working, but with some problems

[Craig Young]

The "429" error is fixed.  Thanks Karen and Tom.
The 2 minute update problem, I changed the driver to poll the hardware 
(serial port) every 15 seconds, but the database still updated every 2 
minutes.  After playing with several parameters in the driver and 
weewx.conf I finally got the database to update every 1 minute and WU to 
also update every minute.  To do this I had to make this change:
[StdArchive]
  archive_interval = 15

This resulted in an error message when I started weewx (from SYSLOG):
WARNING weewx.engine: Archive delay (15) is unusually long

I thought reducing it from 60 sec to 15 sec would get an error of it being 
too short.

In the Database the records show an interval of 0.25 but they are now being 
updated every 1 minute which I assume is because the driver is sending a 
loop packet every 1 minute.  So the problem appears to be related to the 
archive record interval.  Here is what I think may be happening.  Weewx 
gets a loop packet and processes it, control is then returned to the 
driver.  The driver, 1 minute later, sends another loop packet.  Weewx THEN 
begins a 1 minute archive interval and then processes the archive record, 
so two minutes later.  I did notice the error message says archive 
"delay".  In theory, if I set the delay to 0 then when a loop packet 
arrives, once every minute from the driver, then weewx would immediately 
write it to the DB and update WU.  Is that correct?

Craig

On Monday, October 2, 2023 at 1:31:06 AM UTC+13 Tom Keffer wrote:

> First, a note on how weewxd works: the driver blocks, waiting for data to 
> come in. The program cannot do anything while it is blocked. Once data 
> comes in, then it can proceed, emit a LOOP packet, then the rest of the 
> program can process it.
>
> Your fileparse polling interval is 60 seconds. This means that it will 
> sleep for 60 seconds before reading new data from the file. Nothing will 
> happen until it wakes up. 
>
> Meanwhile, your archive interval is 60 seconds. This means weewxd will 
> take whatever data has accumulated over the previous 60 seconds and use it 
> to create an archive record.
>
> With such a short archive interval and long LOOP polling interval, you can 
> see how it's easy for the program to be sleeping, or have nothing available 
> at the one minute mark.
>
> Solution: if you can, have data available more frequently than once every 
> 60 seconds. This would allow you to shorten the fileparse polling interval. 
> If that's not possible, lengthen the archive interval to at least 5 minutes.
>
> Best yet, do both.
>
> As for the "429" error, this is happening because your system is trying to 
> register too frequently. Almost all weewx stations do this because the 
> default registration interval does not work well with the station 
> registration. You can ignore it, or tell weewx to do the station 
> registration less frequently. In weewx.conf:
>
> [StdRESTful]
> [[StationRegistry]]
> register_this_station = false
> post_interval = 86400
>
>
>
> Station registration is working fine. 
>
> -tk
>
> On Sat, Sep 30, 2023 at 8:57 PM Craig Young  wrote:
>
>> After writing a new driver for my station and configuring weewx to 
>> support its  data stream I was able to run weewx live for a few minutes, 
>> then shut it down to check SYSLOG (debug=2).
>> There appears to be two problems (see attached syslog excerpt):
>>
>> a) The database and reports are updating on two minutes intervals.  The 
>> config file has this set for 1 minute intervals:
>> "INFO weewx.engine: Using archive interval of 60 seconds (software record 
>> generation)"
>>
>>  Maybe there is some other setting required?
>>
>> b) There are several HTTP ERROR 429: TOO MANY REQUESTS messages.  Not 
>> sure why this is happening.
>>
>> I think I am close to a fully operational system, just need to clean up a 
>> few things.
>>
>> Craig
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/b8903053-6813-45e1-a804-aa5b566d7bdan%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/b8903053-6813-45e1-a804-aa5b566d7bdan%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/a1fe83ad-4a22-4393-907a-875566c1c49en%40googlegroups.com.

[weewx-user] "First Light", working, but with some problems

[Craig Young]

After writing a new driver for my station and configuring weewx to support 
its  data stream I was able to run weewx live for a few minutes, then shut 
it down to check SYSLOG (debug=2).
There appears to be two problems (see attached syslog excerpt):

a) The database and reports are updating on two minutes intervals.  The 
config file has this set for 1 minute intervals:
"INFO weewx.engine: Using archive interval of 60 seconds (software record 
generation)"

 Maybe there is some other setting required?

b) There are several HTTP ERROR 429: TOO MANY REQUESTS messages.  Not sure 
why this is happening.

I think I am close to a fully operational system, just need to clean up a 
few things.

Craig

-- 
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/b8903053-6813-45e1-a804-aa5b566d7bdan%40googlegroups.com.
Oct  1 16:18:42 CLOWeatherStation systemd[1]: Starting LSB: weewx weather 
system...
Oct  1 16:18:43 CLOWeatherStation weewx[12853] INFO __main__: Initializing 
weewx version 4.10.2
Oct  1 16:18:43 CLOWeatherStation weewx[12853] INFO __main__: Using Python 
3.7.3 (default, Jun 29 2023, 18:03:57) #012[GCC 8.3.0]
Oct  1 16:18:43 CLOWeatherStation weewx[12853] INFO __main__: Located at 
/bin/python3
Oct  1 16:18:43 CLOWeatherStation weewx[12853] INFO __main__: Platform 
Linux-5.10.103-v7l+-armv7l-with-debian-10.13
Oct  1 16:18:43 CLOWeatherStation weewx[12853] INFO __main__: Locale is 
'en_NZ.UTF-8'
Oct  1 16:18:43 CLOWeatherStation weewx[12853] INFO __main__: Using 
configuration file /etc/weewx/weewx.conf
Oct  1 16:18:43 CLOWeatherStation weewx[12853] INFO __main__: Debug is 2
Oct  1 16:18:43 CLOWeatherStation weewx[12853] INFO __main__: PID file is 
/var/run/weewx.pid
Oct  1 16:18:43 CLOWeatherStation weewx[12857] DEBUG __main__: Initializing 
engine
Oct  1 16:18:43 CLOWeatherStation weewx[12857] INFO weewx.engine: Loading 
station type FileParse (weewx.drivers.fileparse)
Oct  1 16:18:43 CLOWeatherStation weewx[12857] INFO weewx.drivers.fileparse: 
Polling interval is 60.0
Oct  1 16:18:43 CLOWeatherStation weewx[12857] INFO weewx.drivers.fileparse: 
Label map is {'batteryStatus1': 'BattV', 'batteryStatus2': 'PTemp', 
'luminosity': 'SlrFD', 'rain': 'Rain', 'signal3': 'RainDaily', 
'lightning_strike_count': 'Strikes', 'lightning_distance': 'Dist', 'windSpeed': 
'WS', 'windDir': 'WindDir', 'windGust': 'MaxWS', 'outTemp': 'AirT', 'pressure': 
'VP', 'barometer': 'BP', 'outHumidity': 'RH', 'extraTemp1': 'RHT', 'signal1': 
'TiltNS', 'signal2': 'TiltWE', 'signal4': 'PyrgMv', 'signal5': 'PyrgSTRat', 
'signal6': 'PyrgLWi'}
Oct  1 16:18:43 CLOWeatherStation weewx[12857] DEBUG weewx.engine: Loading 
service weewx.engine.StdTimeSynch
Oct  1 16:18:43 CLOWeatherStation weewx[12857] DEBUG weewx.engine: Finished 
loading service weewx.engine.StdTimeSynch
Oct  1 16:18:43 CLOWeatherStation weewx[12857] DEBUG weewx.engine: Loading 
service weewx.engine.StdConvert
Oct  1 16:18:43 CLOWeatherStation weewx[12857] INFO weewx.engine: StdConvert 
target unit is 0x11
Oct  1 16:18:43 CLOWeatherStation weewx[12857] DEBUG weewx.engine: Finished 
loading service weewx.engine.StdConvert
Oct  1 16:18:43 CLOWeatherStation weewx[12857] DEBUG weewx.engine: Loading 
service weewx.engine.StdCalibrate
Oct  1 16:18:43 CLOWeatherStation weewx[12857] DEBUG weewx.engine: Finished 
loading service weewx.engine.StdCalibrate
Oct  1 16:18:43 CLOWeatherStation weewx[12857] DEBUG weewx.engine: Loading 
service weewx.engine.StdQC
Oct  1 16:18:43 CLOWeatherStation weewx[12857] DEBUG weewx.engine: Finished 
loading service weewx.engine.StdQC
Oct  1 16:18:43 CLOWeatherStation weewx[12857] DEBUG weewx.engine: Loading 
service weewx.wxservices.StdWXCalculate
Oct  1 16:18:43 CLOWeatherStation weewx[12857] DEBUG weewx.wxservices: 
Calculations for LOOP packets: {'pressure': 'hardware', 'altimeter': 
'hardware', 'appTemp': 'hardware', 'barometer': 'software', 'cloudbase': 
'hardware', 'dewpoint': 'software', 'ET': 'hardware', 'heatindex': 'hardware', 
'humidex': 'hardware', 'inDewpoint': 'hardware', 'maxSolarRad': 'hardware', 
'rainRate': 'software', 'windchill': 'hardware', 'windrun': 'hardware', 
'windDir': 'software', 'windGustDir': 'software'}
Oct  1 16:18:43 CLOWeatherStation weewx[12857] DEBUG weewx.wxservices: 
Calculations for archive records: {'pressure': 'hardware', 'altimeter': 
'hardware', 'appTemp': 'hardware', 'barometer': 'software', 'cloudbase': 
'hardware', 'dewpoint': 'software', 'ET': 'hardware', 'heatindex': 'hardware', 
'humidex': 'hardware', 'inDewpoint': 'hardware', 'maxSolarRad': 'hardware', 
'rainRate': 'software', 'windchill': 'hardware', 'windrun': 'hardware', 
'windDir': 'software', 'windGustDir': 'software'}
Oct  1 16:18:43 CLOWeatherStation weewx[12857] INFO weewx.wxservices: 

Re: [weewx-user] WUnderground test

[Craig Young]

The data logger is a broadcast type, meaning it outputs the current data 
every 60 seconds (ie, it is not polled by the driver).  If the weewx driver 
fails to get one or more of these data then the data base is not accurate 
and hence any daily totals will be wrong.  For me, the most important data 
is the daily rain amount, for agricultural reasons.  So if the weewx driver 
fails to get one or more records on a day, it will be updated correctly 
with the daily rain on the next successful read, assuming of course the 
driver is not down during the span across midnight.  In which case I can 
download the data from the data logger, run it through a conversion 
program, then add the missing data to the database.  At the moment what I 
am doing is letting weewx calculate the daily rain amount.  But I am also 
display signal3 which is the daily rain from the data logger.  If there is 
a discrepancy then I will notice it and fix it.  I will most likely stay 
with this approach.

Craig

On Sunday, October 1, 2023 at 11:00:50 AM UTC+13 gjr80 wrote:

> Hmm, let me throw a question back at you. Why store dayRain in the 
> database?
>
> The restx uploaders will use dayRain if available in the current archive 
> record otherwise they will manually calculate the value (dayRain does not 
> need to be saved to database for it to be available in the current archive 
> record). Today's rainfall (or for that matter any days rainfall) can be 
> displayed in a report using a tag based on the rain field, again no need 
> for historical dayRain. By all means have your driver pass dayRain 
> through, it will save a few milliseconds or less each restx upload, but I 
> don't see much other use for historical dayRain data.
>
> Gary
>
> On Saturday, 30 September 2023 at 15:16:22 UTC+10 craig.y...@gmail.com 
> wrote:
>
>> Thanks Gary, this helping a lot to understand the intricate details of 
>> weewx.  Given this I will update my driver to pass the daily rain as 
>> 'dayRain' and then store that as a new field in the database for later use.
>>
>> On Saturday, September 30, 2023 at 5:41:12 PM UTC+13 gjr80 wrote:
>>
>>> On Saturday, 30 September 2023 at 13:29:28 UTC+10 craig.y...@gmail.com 
>>> wrote:
>>>
>>> If I set the WU password to an invalid value then any posts from weewx 
>>> to WU will fail, but debug = 2 will show me the URL in the log.  That will 
>>> work for testing and eliminate any erroneous values showing up in the WU 
>>> graphs.
>>>
>>>
>>> You would think you would be pretty safe doing this, though with WU's 
>>> history nothing would surprise me. I would put a dummy station ID in as 
>>> well.
>>>
>>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/63f973c3-4a20-4586-af3e-c1538ac1adf9n%40googlegroups.com.

Re: [weewx-user] WUnderground test

[Craig Young]

Thanks Gary, this helping a lot to understand the intricate details of 
weewx.  Given this I will update my driver to pass the daily rain as 
'dayRain' and then store that as a new field in the database for later use.

On Saturday, September 30, 2023 at 5:41:12 PM UTC+13 gjr80 wrote:

> On Saturday, 30 September 2023 at 13:29:28 UTC+10 craig.y...@gmail.com 
> wrote:
>
> If I set the WU password to an invalid value then any posts from weewx to 
> WU will fail, but debug = 2 will show me the URL in the log.  That will 
> work for testing and eliminate any erroneous values showing up in the WU 
> graphs.
>
>
> You would think you would be pretty safe doing this, though with WU's 
> history nothing would surprise me. I would put a dummy station ID in as 
> well.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/76a8dc3b-a545-441a-ab58-88a6991ffea7n%40googlegroups.com.

Re: [weewx-user] WUnderground test

[Craig Young]

If I set the WU password to an invalid value then any posts from weewx to 
WU will fail, but debug = 2 will show me the URL in the log.  That will 
work for testing and eliminate any erroneous values showing up in the WU 
graphs.

On Saturday, September 30, 2023 at 1:40:12 PM UTC+13 Tom Keffer wrote:

> Thousands of WeeWX stations are posting to the WU, so I'm quite confident 
> that they're doing it correctly.
>
> Nevertheless, if you want to see what it's posting, set debug=2, and it 
> will post the URL in the log.
>
> The mapping from WeeWX fields to WU fields is specified in the dictionary 
> weewx.restx.AmbientThread._FORMATS 
> <https://github.com/weewx/weewx/blob/26bbcc56b5939d3e7e102ba21e9e656074714f67/bin/weewx/restx.py#L862>
>
> On Fri, Sep 29, 2023 at 5:15 PM Craig Young  wrote:
>
>> I am currently sending reports to WU using a different application.  But 
>> I am now switching over to weewx and need to verify that the request being 
>> sent to WU is correct without actually sending it.  I don't want to send a 
>> barometric pressure of 200 and throw off the WU ;historical graphs.
>> Better yet, is there a 'map' which configures which report values are 
>> mapped to which request parameters in the WU request?  If there is a 
>> problem I could then go in and change the mapping and verify the test 
>> output.
>>
>> Craig
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/40c8f749-f62a-4035-a2fc-d8837daf86e5n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/40c8f749-f62a-4035-a2fc-d8837daf86e5n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/7b860588-deea-409f-935c-95be4fac0dc0n%40googlegroups.com.

Re: [weewx-user] WUnderground test

[Craig Young]

>From restx.py:
'dayRain': 'dailyrainin=%.2f',

So the daily rain amount sent to WU is from the value 'dayRain'.  Since 
this is not a database observation type, if I add a 'dayRain' field to the 
database will restx.py use that instead?


On Saturday, September 30, 2023 at 1:40:12 PM UTC+13 Tom Keffer wrote:

> Thousands of WeeWX stations are posting to the WU, so I'm quite confident 
> that they're doing it correctly.
>
> Nevertheless, if you want to see what it's posting, set debug=2, and it 
> will post the URL in the log.
>
> The mapping from WeeWX fields to WU fields is specified in the dictionary 
> weewx.restx.AmbientThread._FORMATS 
> <https://github.com/weewx/weewx/blob/26bbcc56b5939d3e7e102ba21e9e656074714f67/bin/weewx/restx.py#L862>
>
> On Fri, Sep 29, 2023 at 5:15 PM Craig Young  wrote:
>
>> I am currently sending reports to WU using a different application.  But 
>> I am now switching over to weewx and need to verify that the request being 
>> sent to WU is correct without actually sending it.  I don't want to send a 
>> barometric pressure of 200 and throw off the WU ;historical graphs.
>> Better yet, is there a 'map' which configures which report values are 
>> mapped to which request parameters in the WU request?  If there is a 
>> problem I could then go in and change the mapping and verify the test 
>> output.
>>
>> Craig
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/40c8f749-f62a-4035-a2fc-d8837daf86e5n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/40c8f749-f62a-4035-a2fc-d8837daf86e5n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/671f1755-0397-4da8-8ecc-04a2fc3feffan%40googlegroups.com.

Re: [weewx-user] Daily Rain

[Craig Young]

The 'rain' observation value passed in the loop packet is the amount of 
rain accumulated by the sensor since the last loop report.
Sensor: accumulated rain since last loop report) ---> Database: field 'rain'

The 'signal3' observation value passed in the loop packet is the amount of 
rain accumulated by the sensor since midnight (the 'midnight' of the data 
logger).
Sensor: accumulated rain since midnight ---> Database: field 'signal3'

Rain Rate is calculated in software: 
weewx.conf|[StdWXCalculate]|[[Calculations]]|rainRate = software

So on the Seasons report, Current conditions:

Rain Today: 0.0mm
Rain Rate: 0.0 mm/hr

There is a single record in the Database (due to testing and clearing after 
each test).  The fields have:

rain: 0.0
rainRate: 0.0
signal3: 17.87

This is because it was not raining during the testing period, but was 
raining early this morning.  That is why 0 for both rain and rainRate.  But 
signal3 has a value of 17.87 mm, the daily rain accumulated since 
midnight.  So on the seasons report it should look like this:

Rain Today: 17.87 mm
Rain Rate: 0.0 mm/hr

Reading through the documentation I saw several references to the term 
'dayRain'.  So I assumed that was either a constant in weewx or a database 
field, whether hardware or software derived.  I could not find 'dayRain' in 
the database so I posted this query to make sure.  My question then is do I 
make one change to weewx.conf so that all reports will use signal3 as the 
daily rain amount, or do I need to go to each report and change them 
individually.

"Just use $current.signal3"
Do I put this in the weewx.conf file or in the Season skin.conf file?


Craig








On Saturday, September 30, 2023 at 1:57:19 PM UTC+13 gjr80 wrote:

> Given a number of previous threads by the OP related to writing a driver, 
> this could be a report issue or a driver issue. Tom covered off the report 
> issue, but if it is a driver issue then it could be a case of garbage in = 
> garbage out. Your driver should be emitting loop packets and the rain 
> field in each loop packet must be the rainfall seen by the station since 
> the last loop packet. Provided you do this WeeWX will accumulate these loop 
> packet rain values and emit the total rain for the archive period in an 
> archive packet. This is the data you will see stored in the database 
> (appropriately converted given the loop packet unit system and database 
> unit system). Once you know your incoming data is good then I would be 
> worrying about what is appearing in reports.
>
> One other thing, if comparing WeeWX 'day rainfall' to a station provided 
> equivalent remember that WeeWX calculates the 'day rainfall' value from the 
> rain data it has seen on that day, so if you start WeeWX part way through 
> the day and there was rainfall earlier in the day then the WeeWX calculated 
> total will almost certainly be less than the station provided day rainfall 
> value.
>
> Gary
>
> On Saturday, 30 September 2023 at 10:28:27 UTC+10 tke...@gmail.com wrote:
>
>> I don't know exactly what you mean when you say your rain is the "amount 
>> since last report." The field "rain" should be the amount of rain that fell 
>> during the archive period, so perhaps that's what you're already doing.
>>
>> You say, "... the Season report shows the correct rain, as reported by 
>> the station, but sets Rain Today the same as rain." 
>>
>> I'm not sure what you mean by that. The "Rain Today" is the *sum* of 
>> rain since midnight, not the rain during the current archive period. If 
>> what you mean is that it's not the same as what is being emitted by your 
>> hardware as "signal3" (aka "dayRain"), it should be. If not, there's 
>> something wrong in the calculation that derives the field "rain" from 
>> "signal3".
>>
>> Nevertheless, if you want to display exactly what is being emitted by 
>> your hardware, that's simple enough. Just use $current.signal3. But, be 
>> sure your hardware is emitting what you think it's emitting. Is it "rain 
>> since midnight"? Or, "rain over the last 24 hours"? 
>>
>> Final comment: to avoid confusing yourself, why not just use the field 
>> name "dayRain" instead of "signal3"? I know it's not in the database, but 
>> new fields are super easy to add:
>>
>> wee_database --add-column=dayRain
>>
>>
>> -tk
>>
>> On Fri, Sep 29, 2023 at 4:38 PM Craig Young  wrote:
>>
>>> My station (hardware) sends both rain (amount since last report) and 
>>> daily rain (accumulates rain).  Currently I am mapping rain to rain in the 
>>> database and daily rain to s

[weewx-user] WUnderground test

[Craig Young]

I am currently sending reports to WU using a different application.  But I 
am now switching over to weewx and need to verify that the request being 
sent to WU is correct without actually sending it.  I don't want to send a 
barometric pressure of 200 and throw off the WU ;historical graphs.
Better yet, is there a 'map' which configures which report values are 
mapped to which request parameters in the WU request?  If there is a 
problem I could then go in and change the mapping and verify the test 
output.

Craig

-- 
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/40c8f749-f62a-4035-a2fc-d8837daf86e5n%40googlegroups.com.

[weewx-user] Daily Rain

[Craig Young]

My station (hardware) sends both rain (amount since last report) and daily 
rain (accumulates rain).  Currently I am mapping rain to rain in the 
database and daily rain to signal3 in the database because I could not find 
any 'dayRain' field.  When I run weewx the Season report shows the correct 
rain, as reported by the station, but sets Rain Today the same as rain.
If I want the Seasons report to show the correct daily rain (from the 
hardware) where should I place it in the DB and do I need to change 
weewx.conf or skin.conf to use the value?

Craig

-- 
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/05844ab4-75a0-435a-a2dd-d85a5ec95d02n%40googlegroups.com.

Re: [weewx-user] Re: Database Schema: Signals

[Craig Young]

Since I am mostly in the development/test stage I will use another unit for 
now and switch once V5 is released.

Craig

On Tuesday, September 26, 2023 at 6:44:41 PM UTC+13 gjr80 wrote:

> On Tuesday, 26 September 2023 at 14:03:11 UTC+10 craig.y...@gmail.com 
> wrote:
>
> Is group_angle a recent addition and not in my dictionary?
>
>
> Indeed it is, commit 2aba36a 
> 
>  of 
> 26 May refers. I was certain I was looking at master, I must have been 
> looking at one of the V5 branches. No matter, there are a few things you 
> can do. If developing your driver on v4.x you could define group_angle 
> yourself 
> and just make a note to remove the definition once v5 is released and you 
> are using v5, or you could use another unit group in the meantime and again 
> make a note to change in group_angle once v5 is released and you are 
> using v5. Or you could cut your development over to one of the v5 beta 
> releases, though if you are a new WeeWX user it might be easier to continue 
> with v4.x for the time being.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/bb7cf6b6-2634-4795-ac3a-aef4530a52ffn%40googlegroups.com.

Re: [weewx-user] Re: Database Schema: Signals

[Craig Young]

; name is a better fit and the availability of conversion to radians if 
> required. I would use either .format() to change tag formatting in 
> reports or override the default formatting in skin.conf/weewx.conf if I 
> frequently use the field in tags.
>
> Gary
> On Monday, 25 September 2023 at 05:46:48 UTC+10 craig.y...@gmail.com 
> wrote:
>
>> Because tilt can be a negative number I think we have to rule out 
>> group_direction which I think has a range of 0 to 360.  Not sure about 
>> group_angle, do you know if it allows for positive and negative angles?
>>
>> Craig
>>
>> On Saturday, September 23, 2023 at 6:30:28 PM UTC+12 gjr80 wrote:
>>
>>> Remember, unit groups are for picking an appropriate unit for a 
>>> field/observation (including allowing for conversion between applicable 
>>> units) and providing a suitable format and label. Your description brings 
>>> to mind two possible suitable unit groups; group_direction and 
>>> group_angle. Both of these unit groups support fields/observations in 
>>> degrees (degree_compass for group_direction and degree_angle for 
>>> group_angle. Both provide (default) unit labels of the degree symbol, 
>>> both offer similar (default) formats (%03.0f v %02.0f). group_angle 
>>> facilitates unit conversion between degrees and radians, which may or may 
>>> not be something you use now or in the future, group_direction does not 
>>> support this conversion.
>>>
>>> We tend to re-use unit groups where we can, only creating new unit 
>>> groups where there is no other suitable unit group. Remember, default unit 
>>> group formats and labels are only defaults and can be altered or overridden 
>>> in a tag using .format() (eg for tilt you might want to always display 
>>> a sign and format to one decimal place so you might decide to alter the 
>>> default or override the default format using .format() with the format 
>>> string '%+02.1').
>>>
>>> Gary
>>> On Saturday, 23 September 2023 at 14:40:36 UTC+10 craig.y...@gmail.com 
>>> wrote:
>>>
>>>> Signal4 and Signal 5 are sensor tilt measurements in degrees.  For 
>>>> example, if the sensor is tilted 1.5 degrees in the N/S direction the 
>>>> value 
>>>> for Signal4 = 1.5 degrees.  Looking at units.py and defaults.py I see 
>>>> groups for degrees temperature, degrees direction, but not degrees tilt.  
>>>> Should a new group "group-tilt" be added through the driver or should this 
>>>> be added to weewx files to be made available to everyone?
>>>>
>>>> On Saturday, September 23, 2023 at 4:06:25 PM UTC+12 Craig Young wrote:
>>>>
>>>>> I will add the assignments in the driver.
>>>>>
>>>>> On Saturday, September 23, 2023 at 12:38:22 PM UTC+12 Tom Keffer wrote:
>>>>>
>>>>>> Good advice!
>>>>>>
>>>>>> On Fri, Sep 22, 2023 at 5:35 PM gjr80  wrote:
>>>>>>
>>>>>>> The other other variation on Tom's advice to use extensions.py, 
>>>>>>> particularly if you are (still keen on) writing your own driver, is to 
>>>>>>> include the unit group assignments in the driver file. They statements 
>>>>>>> only 
>>>>>>> need to be somewhere where they are executed each time WeeWX starts. If 
>>>>>>> the 
>>>>>>> fields are inextricably linked to the driver having everything in one 
>>>>>>> place 
>>>>>>> can be of benefit. I've used this approach with some of the drivers I 
>>>>>>> have 
>>>>>>> written.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Saturday, 23 September 2023 at 10:11:16 UTC+10 tke...@gmail.com 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Exactly.
>>>>>>>>
>>>>>>>> Or, alternatively, you can assign them to appropriate unit groups 
>>>>>>>> <http://www.weewx.com/docs/customizing.htm#Assigning_a_unit_group> 
>>>>>>>> in the file user/extensions.py:
>>>>>>>>
>>>>>>>> *import weewx.units*
>>>>>>>>
>>>>>>>> *weewx.units.obs_group_dict['signal1'] = 'group_radiation'*
>>>>>>>> *weewx.units.obs_group_dict['signal2'] = 

[weewx-user] Splitting serial port into two virtual ports

[Craig Young]

My weather station outputs a single serial port data stream.  On a Pi I 
have a python program which opens the port and sends the weather data to 
WeatherUnderground.  The next step is to bring up Weewx and connect to the 
incoming datastream and output to Weatherunderground.  But, during the 
testing phase I do not want to interrupt the feed to WU.
Has anyone on the forum here split an incoming physical serial stream into 
two output virtual streams?  I could then leave one virtual stream as the 
WU updates and use the second stream as the input to the Weewx test 
system.  Once the Weewx installation is working successfully I can then 
revert it to use the direct feed from the station.
I have seen a few solutions while scanning the internet but thought I would 
check here first and see what has been successfully used.

Craig

-- 
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/71bc1938-43ff-4989-951f-a8507b9dd5d3n%40googlegroups.com.

Re: [weewx-user] Re: Database Schema: Signals

[Craig Young]

Because tilt can be a negative number I think we have to rule out 
group_direction which I think has a range of 0 to 360.  Not sure about 
group_angle, do you know if it allows for positive and negative angles?

Craig

On Saturday, September 23, 2023 at 6:30:28 PM UTC+12 gjr80 wrote:

> Remember, unit groups are for picking an appropriate unit for a 
> field/observation (including allowing for conversion between applicable 
> units) and providing a suitable format and label. Your description brings 
> to mind two possible suitable unit groups; group_direction and group_angle. 
> Both of these unit groups support fields/observations in degrees (
> degree_compass for group_direction and degree_angle for group_angle. Both 
> provide (default) unit labels of the degree symbol, both offer similar 
> (default) formats (%03.0f v %02.0f). group_angle facilitates unit 
> conversion between degrees and radians, which may or may not be something 
> you use now or in the future, group_direction does not support this 
> conversion.
>
> We tend to re-use unit groups where we can, only creating new unit groups 
> where there is no other suitable unit group. Remember, default unit group 
> formats and labels are only defaults and can be altered or overridden in a 
> tag using .format() (eg for tilt you might want to always display a sign 
> and format to one decimal place so you might decide to alter the default or 
> override the default format using .format() with the format string '%+02.1
> ').
>
> Gary
> On Saturday, 23 September 2023 at 14:40:36 UTC+10 craig.y...@gmail.com 
> wrote:
>
>> Signal4 and Signal 5 are sensor tilt measurements in degrees.  For 
>> example, if the sensor is tilted 1.5 degrees in the N/S direction the value 
>> for Signal4 = 1.5 degrees.  Looking at units.py and defaults.py I see 
>> groups for degrees temperature, degrees direction, but not degrees tilt.  
>> Should a new group "group-tilt" be added through the driver or should this 
>> be added to weewx files to be made available to everyone?
>>
>> On Saturday, September 23, 2023 at 4:06:25 PM UTC+12 Craig Young wrote:
>>
>>> I will add the assignments in the driver.
>>>
>>> On Saturday, September 23, 2023 at 12:38:22 PM UTC+12 Tom Keffer wrote:
>>>
>>>> Good advice!
>>>>
>>>> On Fri, Sep 22, 2023 at 5:35 PM gjr80  wrote:
>>>>
>>>>> The other other variation on Tom's advice to use extensions.py, 
>>>>> particularly if you are (still keen on) writing your own driver, is to 
>>>>> include the unit group assignments in the driver file. They statements 
>>>>> only 
>>>>> need to be somewhere where they are executed each time WeeWX starts. If 
>>>>> the 
>>>>> fields are inextricably linked to the driver having everything in one 
>>>>> place 
>>>>> can be of benefit. I've used this approach with some of the drivers I 
>>>>> have 
>>>>> written.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Saturday, 23 September 2023 at 10:11:16 UTC+10 tke...@gmail.com 
>>>>> wrote:
>>>>>
>>>>>> Exactly.
>>>>>>
>>>>>> Or, alternatively, you can assign them to appropriate unit groups 
>>>>>> <http://www.weewx.com/docs/customizing.htm#Assigning_a_unit_group> 
>>>>>> in the file user/extensions.py:
>>>>>>
>>>>>> *import weewx.units*
>>>>>>
>>>>>> *weewx.units.obs_group_dict['signal1'] = 'group_radiation'*
>>>>>> *weewx.units.obs_group_dict['signal2'] = 'group_temperature'*
>>>>>> *weewx.units.obs_group_dict['signal3'] = 'group_radiation'*
>>>>>>
>>>>>>
>>>>>> Then you would not need to specify a format and label. It would also 
>>>>>> allow you to do things like 
>>>>>>
>>>>>> *The temperature is $current.signal2.degree_C 
>>>>>> ($current.signal2.degree_F)*
>>>>>>
>>>>>>
>>>>>> to publish the temperature in both ºC and ºF.
>>>>>>
>>>>>> -tk
>>>>>>
>>>>>> On Fri, Sep 22, 2023 at 4:38 PM Craig Young  
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks Tom.  Signal1 for my station is the signal voltage from a 
>>>>>>> pyrgometer.  Signal2 is the temperature of the pyrgometer sensor (C) 
>>>>&

Re: [weewx-user] Re: Database Schema: Signals

[Craig Young]

Signal4 and Signal 5 are sensor tilt measurements in degrees.  For example, 
if the sensor is tilted 1.5 degrees in the N/S direction the value for 
Signal4 = 1.5 degrees.  Looking at units.py and defaults.py I see groups 
for degrees temperature, degrees direction, but not degrees tilt.  Should a 
new group "group-tilt" be added through the driver or should this be added 
to weewx files to be made available to everyone?

On Saturday, September 23, 2023 at 4:06:25 PM UTC+12 Craig Young wrote:

> I will add the assignments in the driver.
>
> On Saturday, September 23, 2023 at 12:38:22 PM UTC+12 Tom Keffer wrote:
>
>> Good advice!
>>
>> On Fri, Sep 22, 2023 at 5:35 PM gjr80  wrote:
>>
>>> The other other variation on Tom's advice to use extensions.py, 
>>> particularly if you are (still keen on) writing your own driver, is to 
>>> include the unit group assignments in the driver file. They statements only 
>>> need to be somewhere where they are executed each time WeeWX starts. If the 
>>> fields are inextricably linked to the driver having everything in one place 
>>> can be of benefit. I've used this approach with some of the drivers I have 
>>> written.
>>>
>>> Gary
>>>
>>> On Saturday, 23 September 2023 at 10:11:16 UTC+10 tke...@gmail.com 
>>> wrote:
>>>
>>>> Exactly.
>>>>
>>>> Or, alternatively, you can assign them to appropriate unit groups 
>>>> <http://www.weewx.com/docs/customizing.htm#Assigning_a_unit_group> in 
>>>> the file user/extensions.py:
>>>>
>>>> *import weewx.units*
>>>>
>>>> *weewx.units.obs_group_dict['signal1'] = 'group_radiation'*
>>>> *weewx.units.obs_group_dict['signal2'] = 'group_temperature'*
>>>> *weewx.units.obs_group_dict['signal3'] = 'group_radiation'*
>>>>
>>>>
>>>> Then you would not need to specify a format and label. It would also 
>>>> allow you to do things like 
>>>>
>>>> *The temperature is $current.signal2.degree_C 
>>>> ($current.signal2.degree_F)*
>>>>
>>>>
>>>> to publish the temperature in both ºC and ºF.
>>>>
>>>> -tk
>>>>
>>>> On Fri, Sep 22, 2023 at 4:38 PM Craig Young  
>>>> wrote:
>>>>
>>>>> Thanks Tom.  Signal1 for my station is the signal voltage from a 
>>>>> pyrgometer.  Signal2 is the temperature of the pyrgometer sensor (C) and 
>>>>> Signal3 is the long wave intensity (W/m2) calculated by the datalogger.  
>>>>> So 
>>>>> if I understand correctly, the weewx engine will pass these values 
>>>>> untouched through the various services and add to the DB as real numbers. 
>>>>>  
>>>>> I can then deal with them manually when creating the report.
>>>>>
>>>>> On Saturday, September 23, 2023 at 11:00:54 AM UTC+12 Tom Keffer wrote:
>>>>>
>>>>>> Signals are for ill-defined measurements. 
>>>>>>
>>>>>> Unit groups exist for two reasons:
>>>>>>
>>>>>>1. To pick an appropriate unit for a type of measurement. For 
>>>>>>example, ºC for temperatures.
>>>>>>2. To pick an appropriate format and label.
>>>>>>
>>>>>> Signals don't fit neatly into these reasons. They don't take a unit, 
>>>>>> and it's not obvious what format and what label they should use. So, 
>>>>>> they 
>>>>>> were left out of units.py and defaults.py. 
>>>>>>
>>>>>> You can use the signal types without adding them to a unit group. You 
>>>>>> just won't be able to convert them to a different unit (which they don't 
>>>>>> have anyway), and there will be no automatic formatting and labelling. 
>>>>>> If 
>>>>>> you need a format, use a .format() suffix. If you need a format, just 
>>>>>> add 
>>>>>> it on. For example:
>>>>>>
>>>>>> *$current.signal1.format("%d") widgets*
>>>>>>
>>>>>>
>>>>>> Alternatively, if your signal is actually some kind of counter, you 
>>>>>> could assign them to group_count. Then they would use "%d" for the 
>>>>>> format, 
>>>>>> and an empty string for the label.
>>>&

Re: [weewx-user] Re: Database Schema: Signals

[Craig Young]

I will add the assignments in the driver.

On Saturday, September 23, 2023 at 12:38:22 PM UTC+12 Tom Keffer wrote:

> Good advice!
>
> On Fri, Sep 22, 2023 at 5:35 PM gjr80  wrote:
>
>> The other other variation on Tom's advice to use extensions.py, 
>> particularly if you are (still keen on) writing your own driver, is to 
>> include the unit group assignments in the driver file. They statements only 
>> need to be somewhere where they are executed each time WeeWX starts. If the 
>> fields are inextricably linked to the driver having everything in one place 
>> can be of benefit. I've used this approach with some of the drivers I have 
>> written.
>>
>> Gary
>>
>> On Saturday, 23 September 2023 at 10:11:16 UTC+10 tke...@gmail.com wrote:
>>
>>> Exactly.
>>>
>>> Or, alternatively, you can assign them to appropriate unit groups 
>>> <http://www.weewx.com/docs/customizing.htm#Assigning_a_unit_group> in 
>>> the file user/extensions.py:
>>>
>>> *import weewx.units*
>>>
>>> *weewx.units.obs_group_dict['signal1'] = 'group_radiation'*
>>> *weewx.units.obs_group_dict['signal2'] = 'group_temperature'*
>>> *weewx.units.obs_group_dict['signal3'] = 'group_radiation'*
>>>
>>>
>>> Then you would not need to specify a format and label. It would also 
>>> allow you to do things like 
>>>
>>> *The temperature is $current.signal2.degree_C 
>>> ($current.signal2.degree_F)*
>>>
>>>
>>> to publish the temperature in both ºC and ºF.
>>>
>>> -tk
>>>
>>> On Fri, Sep 22, 2023 at 4:38 PM Craig Young  
>>> wrote:
>>>
>>>> Thanks Tom.  Signal1 for my station is the signal voltage from a 
>>>> pyrgometer.  Signal2 is the temperature of the pyrgometer sensor (C) and 
>>>> Signal3 is the long wave intensity (W/m2) calculated by the datalogger.  
>>>> So 
>>>> if I understand correctly, the weewx engine will pass these values 
>>>> untouched through the various services and add to the DB as real numbers.  
>>>> I can then deal with them manually when creating the report.
>>>>
>>>> On Saturday, September 23, 2023 at 11:00:54 AM UTC+12 Tom Keffer wrote:
>>>>
>>>>> Signals are for ill-defined measurements. 
>>>>>
>>>>> Unit groups exist for two reasons:
>>>>>
>>>>>1. To pick an appropriate unit for a type of measurement. For 
>>>>>example, ºC for temperatures.
>>>>>2. To pick an appropriate format and label.
>>>>>
>>>>> Signals don't fit neatly into these reasons. They don't take a unit, 
>>>>> and it's not obvious what format and what label they should use. So, they 
>>>>> were left out of units.py and defaults.py. 
>>>>>
>>>>> You can use the signal types without adding them to a unit group. You 
>>>>> just won't be able to convert them to a different unit (which they don't 
>>>>> have anyway), and there will be no automatic formatting and labelling. If 
>>>>> you need a format, use a .format() suffix. If you need a format, just add 
>>>>> it on. For example:
>>>>>
>>>>> *$current.signal1.format("%d") widgets*
>>>>>
>>>>>
>>>>> Alternatively, if your signal is actually some kind of counter, you 
>>>>> could assign them to group_count. Then they would use "%d" for the 
>>>>> format, 
>>>>> and an empty string for the label.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Sep 22, 2023 at 3:22 PM Craig Young  
>>>>> wrote:
>>>>>
>>>>>> In the wview_extended.py schema there is a group of types for signals 
>>>>>> (signal1, signal2, .. signal8) and stored in the DB as reals.  I looked 
>>>>>> in 
>>>>>> units.py but did not see signals listed. 
>>>>>>
>>>>>> On Saturday, September 23, 2023 at 9:40:17 AM UTC+12 Craig Young 
>>>>>> wrote:
>>>>>>
>>>>>>> What units group do the observation type Signals fall under?   Or, 
>>>>>>> if I use a signal do I need to update a configuration file to place it 
>>>>>>> into 
>>>>>>> a units group.
>>>>>>>
>>>>>> -- 
>

Re: [weewx-user] Re: Database Schema: Signals

[Craig Young]

Thanks Tom.  Signal1 for my station is the signal voltage from a 
pyrgometer.  Signal2 is the temperature of the pyrgometer sensor (C) and 
Signal3 is the long wave intensity (W/m2) calculated by the datalogger.  So 
if I understand correctly, the weewx engine will pass these values 
untouched through the various services and add to the DB as real numbers.  
I can then deal with them manually when creating the report.

On Saturday, September 23, 2023 at 11:00:54 AM UTC+12 Tom Keffer wrote:

> Signals are for ill-defined measurements. 
>
> Unit groups exist for two reasons:
>
>1. To pick an appropriate unit for a type of measurement. For example, 
>ºC for temperatures.
>2. To pick an appropriate format and label.
>
> Signals don't fit neatly into these reasons. They don't take a unit, and 
> it's not obvious what format and what label they should use. So, they were 
> left out of units.py and defaults.py. 
>
> You can use the signal types without adding them to a unit group. You just 
> won't be able to convert them to a different unit (which they don't have 
> anyway), and there will be no automatic formatting and labelling. If you 
> need a format, use a .format() suffix. If you need a format, just add it 
> on. For example:
>
> *$current.signal1.format("%d") widgets*
>
>
> Alternatively, if your signal is actually some kind of counter, you could 
> assign them to group_count. Then they would use "%d" for the format, and an 
> empty string for the label.
>
>
>
> On Fri, Sep 22, 2023 at 3:22 PM Craig Young  wrote:
>
>> In the wview_extended.py schema there is a group of types for signals 
>> (signal1, signal2, .. signal8) and stored in the DB as reals.  I looked in 
>> units.py but did not see signals listed. 
>>
>> On Saturday, September 23, 2023 at 9:40:17 AM UTC+12 Craig Young wrote:
>>
>>> What units group do the observation type Signals fall under?   Or, if I 
>>> use a signal do I need to update a configuration file to place it into a 
>>> units group.
>>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/b9fa5024-38c9-4d95-8e4b-5c9bb4f0ddb8n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/b9fa5024-38c9-4d95-8e4b-5c9bb4f0ddb8n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/2dd9fe34-ffde-4e8f-aaf6-b205009b76a7n%40googlegroups.com.

[weewx-user] Re: Database Schema: Signals

[Craig Young]

In the wview_extended.py schema there is a group of types for signals 
(signal1, signal2, .. signal8) and stored in the DB as reals.  I looked in 
units.py but did not see signals listed. 

On Saturday, September 23, 2023 at 9:40:17 AM UTC+12 Craig Young wrote:

> What units group do the observation type Signals fall under?   Or, if I 
> use a signal do I need to update a configuration file to place it into a 
> units group.
>

-- 
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/b9fa5024-38c9-4d95-8e4b-5c9bb4f0ddb8n%40googlegroups.com.

[weewx-user] Database Schema: Signals

[Craig Young]

What units group do the observation type Signals fall under?   Or, if I use 
a signal do I need to update a configuration file to place it into a units 
group.

-- 
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/745f8739-29a5-4fce-875a-2c531c89bbf8n%40googlegroups.com.

Re: [weewx-user] Installing new driver, question

[Craig Young]

Thanks Vince, am doing that now and making much better progress.

On Thursday, September 21, 2023 at 2:12:46 PM UTC+12 vince wrote:

> I'd suggest you devote a little time to consult the FAQ (link) 
>  for 
> this and other things new users frequently run into.   It'll help explain 
> this one as well as other things you might run into as you get more 
> familiar with.  Your particular issue has its own page (link) 
>  as it might 
> be the most frequent of the frequently asked questions.
>
>
>

-- 
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/1835fa94-ba90-490b-8013-ed8f4c54e002n%40googlegroups.com.

[weewx-user] Re: Procedure to make changes to an installed driver

[Craig Young]

Thanks Gary, that is an idea I have not thought about .. to take the 
fileparse driver and as you say, just drop my code into it.  I will look at 
this.

Craig

On Wednesday, September 20, 2023 at 4:44:43 PM UTC+12 gjr80 wrote:

> If you have the ability to provide a delimited text file with your obs and 
> timestamp then fileparse will certainly work for you and it will be a 
> straightforward and quick setup. However, if you already have some code to 
> read observations from your station/datalogger you pretty much have all you 
> need for your own driver. In a nutshell, all a driver does is run an 
> infinite loop obtaining data from the station, converting units as 
> required, packaging the data in a python dictionary and passing the 
> dictionary on to WeeWX. The fileparse driver is a good example of a basic 
> driver, you could just remove the code that reads data from a fie and 
> substitute your code or a call to a method that reads data from your 
> station/datalogger. At the very least the data will need to be massaged 
> into a python dictionary (ie a loop packet), but that is easy to do. There 
> will be a few things to watch for, for example: handling units, dealing 
> with missing data and making sure the driver does not block the main WeeWX 
> loop (typically an issue when reading from high latency devices or via a 
> network). You already have code running to read data from the 
> datalogger/station and post to WU, you could potentially have WeeWX reading 
> data direct from your datalogger/station and let WeeWX handle uploading to 
> WU (and other services as well) - that way you are reading data from your 
> datalogger/station once only.
>
> Have a look at the Porting to new hardware section 
> <http://weewx.com/docs/4.10/customizing.htm#porting> in the Customization 
> Guide <http://weewx.com/docs/4.10/customizing.htm>. It's quite a simple 
> process and quite satisfying once complete.
>
> Also, just post back here if have any questions.
>
> Gary
>
> On Wednesday, 20 September 2023 at 11:14:54 UTC+10 craig.y...@gmail.com 
> wrote:
>
>> Maybe it would be better to use the driver: fileparse.py.
>>
>>
>> On Wednesday, September 20, 2023 at 12:18:25 PM UTC+12 Craig Young wrote:
>>
>>> Maybe I should try a new tact.  I have a datalogger which is outputting 
>>> weather data every 15 seconds and is received on the Raspberry Pi through 
>>> the USB0 serial port.  Using CuteCom here is a sample data record:
>>>
>>> <"2023-09-20 
>>> 12:11:30",13.65,24.91,737,0,0,0,0,1.5,167,1.96,18.1,1.52,101.15,0.745,21.3,0.8,-1.1,-14.1105,0.5613659,323.5677>␍␊
>>> I have written the program on the datalogger to do this so I can change 
>>> the data format if needed.
>>>
>>> What I need to do now is import this into weewx.  I assume I need a 
>>> driver (or extension?) to do this but that is where the problems begin.  
>>> This is not for the feint of heart.  I have written tons of software in 
>>> other languages for other applications, but all on windows.  I have a 
>>> Raspberry Pi now running and have written a small python program to use the 
>>> Serial instruction to read the data stream and even post this after 
>>> formatting to wunderground.  So I am not stupid, just a very long learning 
>>> curve to do a simple thing.
>>> I found the TWI.py driver and it looks simple enough to modify for this 
>>> application, but given my inexperience with linux and weewx I see lots of 
>>> problems ahead.
>>>
>>> Is there someone on here who could spend a couple of hours or so on 
>>> Discord or Skype to help me either modify TWI.py or write a new driver for 
>>> weewx?
>>>
>>> Craig
>>> On Wednesday, September 20, 2023 at 10:44:51 AM UTC+12 Craig Young wrote:
>>>
>>>> I have installed and configured a new driver in my weewx installation, 
>>>> TWI.py.  But before I launch weewx I need to make a couple of changes to 
>>>> the driver.  What is the correct method for doing that?  Do I:
>>>> 0: Stop weewx
>>>> 1. Open driver (located in usr folder) with Thonny
>>>> 2. Make the changes and save
>>>> 3. Start weewx
>>>> or do I need to reconfigure it first?
>>>>
>>>>

-- 
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/1650d57d-d608-4e17-a228-0f75ed00c08an%40googlegroups.com.

[weewx-user] Re: Procedure to make changes to an installed driver

[Craig Young]

Maybe it would be better to use the driver: fileparse.py.


On Wednesday, September 20, 2023 at 12:18:25 PM UTC+12 Craig Young wrote:

> Maybe I should try a new tact.  I have a datalogger which is outputting 
> weather data every 15 seconds and is received on the Raspberry Pi through 
> the USB0 serial port.  Using CuteCom here is a sample data record:
>
> <"2023-09-20 
> 12:11:30",13.65,24.91,737,0,0,0,0,1.5,167,1.96,18.1,1.52,101.15,0.745,21.3,0.8,-1.1,-14.1105,0.5613659,323.5677>␍␊
> I have written the program on the datalogger to do this so I can change 
> the data format if needed.
>
> What I need to do now is import this into weewx.  I assume I need a driver 
> (or extension?) to do this but that is where the problems begin.  This is 
> not for the feint of heart.  I have written tons of software in other 
> languages for other applications, but all on windows.  I have a Raspberry 
> Pi now running and have written a small python program to use the Serial 
> instruction to read the data stream and even post this after formatting to 
> wunderground.  So I am not stupid, just a very long learning curve to do a 
> simple thing.
> I found the TWI.py driver and it looks simple enough to modify for this 
> application, but given my inexperience with linux and weewx I see lots of 
> problems ahead.
>
> Is there someone on here who could spend a couple of hours or so on 
> Discord or Skype to help me either modify TWI.py or write a new driver for 
> weewx?
>
> Craig
> On Wednesday, September 20, 2023 at 10:44:51 AM UTC+12 Craig Young wrote:
>
>> I have installed and configured a new driver in my weewx installation, 
>> TWI.py.  But before I launch weewx I need to make a couple of changes to 
>> the driver.  What is the correct method for doing that?  Do I:
>> 0: Stop weewx
>> 1. Open driver (located in usr folder) with Thonny
>> 2. Make the changes and save
>> 3. Start weewx
>> or do I need to reconfigure it first?
>>
>>

-- 
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/319c9890-4b95-4ad2-a57d-7223cf35327dn%40googlegroups.com.

[weewx-user] Re: Procedure to make changes to an installed driver

[Craig Young]

Maybe I should try a new tact.  I have a datalogger which is outputting 
weather data every 15 seconds and is received on the Raspberry Pi through 
the USB0 serial port.  Using CuteCom here is a sample data record:

<"2023-09-20 
12:11:30",13.65,24.91,737,0,0,0,0,1.5,167,1.96,18.1,1.52,101.15,0.745,21.3,0.8,-1.1,-14.1105,0.5613659,323.5677>␍␊
I have written the program on the datalogger to do this so I can change the 
data format if needed.

What I need to do now is import this into weewx.  I assume I need a driver 
(or extension?) to do this but that is where the problems begin.  This is 
not for the feint of heart.  I have written tons of software in other 
languages for other applications, but all on windows.  I have a Raspberry 
Pi now running and have written a small python program to use the Serial 
instruction to read the data stream and even post this after formatting to 
wunderground.  So I am not stupid, just a very long learning curve to do a 
simple thing.
I found the TWI.py driver and it looks simple enough to modify for this 
application, but given my inexperience with linux and weewx I see lots of 
problems ahead.

Is there someone on here who could spend a couple of hours or so on Discord 
or Skype to help me either modify TWI.py or write a new driver for weewx?

Craig
On Wednesday, September 20, 2023 at 10:44:51 AM UTC+12 Craig Young wrote:

> I have installed and configured a new driver in my weewx installation, 
> TWI.py.  But before I launch weewx I need to make a couple of changes to 
> the driver.  What is the correct method for doing that?  Do I:
> 0: Stop weewx
> 1. Open driver (located in usr folder) with Thonny
> 2. Make the changes and save
> 3. Start weewx
> or do I need to reconfigure it first?
>
>

-- 
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/17e924f6-a33d-41f7-a26e-7e6235ad18a6n%40googlegroups.com.

Re: [weewx-user] Installing new driver, question

[Craig Young]

It was not a joke.  I was following the instructions in the driver 
documentation about how to install it.  Most documentation always used 
sudo, this did not, so rather than experiment and screw up my entire 
installation I executed it verbatim.  So simply a matter of not seeing the 
forest for the trees.

On Wednesday, September 20, 2023 at 11:10:21 AM UTC+12 p q wrote:

> Sorry for being short. I thought the link would explain it. I do hope that 
> was a joke.
>
> On Tue, Sep 19, 2023 at 3:46 PM vince  wrote:
>
>> Please tell me you're joking there.  Please.
>>
>> (if not, I'd strongly suggest you do some of the nice free self-paced 
>> Linux courses and tutorials available online.  The edx.org Linux 
>> fundamentals course used to be pretty good).
>>
>> On Tuesday, September 19, 2023 at 3:28:53 PM UTC-7 Craig Young wrote:
>>
>>> I tried "gahh.sudo" and got command not found, then tried "gahh.sudo 
>>> wee_extension --install etc" and also got command not found.  Maybe I am 
>>> doing this wrong?
>>>
>>> On Wednesday, September 20, 2023 at 10:25:17 AM UTC+12 p q wrote:
>>>
>>>> gahh. sudo
>>>>
>>>> On Tue, Sep 19, 2023 at 3:24 PM p q  wrote:
>>>>
>>>>> sudu <https://home.ubalt.edu/abento/linux/terminal/sudonotfedora.html>
>>>>>
>>>>> On Tue, Sep 19, 2023 at 3:21 PM Craig Young  
>>>>> wrote:
>>>>>
>>>>>> I am installing the TWI.py driver and have run into an error:
>>>>>>
>>>>>> pi@CLOWeatherStation:~ $ wee_extension --install weewx-twi.zip
>>>>>> Request to install 'weewx-twi.zip'
>>>>>> Extracting from zip archive weewx-twi.zip
>>>>>> Traceback (most recent call last):
>>>>>>   File "/usr/share/weewx/wee_extension", line 92, in 
>>>>>> main()
>>>>>>   File "/usr/share/weewx/wee_extension", line 84, in main
>>>>>> ext.install_extension(options.install)
>>>>>>   File "/usr/share/weewx/weecfg/extension.py", line 130, in 
>>>>>> install_extension
>>>>>> self.install_from_dir(extension_dir)
>>>>>>   File "/usr/share/weewx/weecfg/extension.py", line 183, in 
>>>>>> install_from_dir
>>>>>> shutil.copy(source_path, destination_path)
>>>>>>   File "/usr/lib/python3.7/shutil.py", line 245, in copy
>>>>>> copyfile(src, dst, follow_symlinks=follow_symlinks)
>>>>>>   File "/usr/lib/python3.7/shutil.py", line 121, in copyfile
>>>>>> with open(dst, 'wb') as fdst:
>>>>>> PermissionError: [Errno 13] Permission denied: 
>>>>>> '/usr/share/weewx/user/twi.py'
>>>>>> pi@CLOWeatherStation:~ $ 
>>>>>>
>>>>>> How do I change permissions? 
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>> -- 
>>>>>> 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+...@googlegroups.com.
>>>>>> To view this discussion on the web visit 
>>>>>> https://groups.google.com/d/msgid/weewx-user/e7d5f0b0-2ca2-43b9-85c4-9f58821563b5n%40googlegroups.com
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/weewx-user/e7d5f0b0-2ca2-43b9-85c4-9f58821563b5n%40googlegroups.com?utm_medium=email_source=footer>
>>>>>> .
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Peter Quinn
>>>>> (415)794-2264 <(415)%20794-2264>
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Peter Quinn
>>>> (415)794-2264 <(415)%20794-2264>
>>>>
>>> -- 
>> 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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/9e349a60-cc35-4d5a-8758-8171c986deb5n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/9e349a60-cc35-4d5a-8758-8171c986deb5n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
> Peter Quinn
> (415)794-2264 <(415)%20794-2264>
>

-- 
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/bd09b0d1-630e-47eb-94e1-87af78745dfbn%40googlegroups.com.

[weewx-user] Procedure to make changes to an installed driver

[Craig Young]

I have installed and configured a new driver in my weewx installation, 
TWI.py.  But before I launch weewx I need to make a couple of changes to 
the driver.  What is the correct method for doing that?  Do I:
0: Stop weewx
1. Open driver (located in usr folder) with Thonny
2. Make the changes and save
3. Start weewx
or do I need to reconfigure it first?

-- 
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/f3d7c929-bad2-42de-80d7-9e45b02980fen%40googlegroups.com.

Re: [weewx-user] Installing new driver, question

[Craig Young]

That worked .. thank you heaps.

On Wednesday, September 20, 2023 at 10:35:31 AM UTC+12 Kidney wrote:

> sudo wee_extension --install weewx-twi.zip
>
> On Sep 19, 2023, at 18:29, Craig Young  wrote:
>
> This is on a raspberry pi ..
>
>
>
> On Wednesday, September 20, 2023 at 10:28:53 AM UTC+12 Craig Young wrote:
>
>> I tried "gahh.sudo" and got command not found, then tried "gahh.sudo 
>> wee_extension --install etc" and also got command not found.  Maybe I am 
>> doing this wrong?
>>
>> On Wednesday, September 20, 2023 at 10:25:17 AM UTC+12 p q wrote:
>>
>>> gahh. sudo
>>>
>>> On Tue, Sep 19, 2023 at 3:24 PM p q  wrote:
>>>
>>>> sudu <https://home.ubalt.edu/abento/linux/terminal/sudonotfedora.html>
>>>>
>>>> On Tue, Sep 19, 2023 at 3:21 PM Craig Young  
>>>> wrote:
>>>>
>>>>> I am installing the TWI.py driver and have run into an error:
>>>>>
>>>>> pi@CLOWeatherStation:~ $ wee_extension --install weewx-twi.zip
>>>>> Request to install 'weewx-twi.zip'
>>>>> Extracting from zip archive weewx-twi.zip
>>>>> Traceback (most recent call last):
>>>>>   File "/usr/share/weewx/wee_extension", line 92, in 
>>>>> main()
>>>>>   File "/usr/share/weewx/wee_extension", line 84, in main
>>>>> ext.install_extension(options.install)
>>>>>   File "/usr/share/weewx/weecfg/extension.py", line 130, in 
>>>>> install_extension
>>>>> self.install_from_dir(extension_dir)
>>>>>   File "/usr/share/weewx/weecfg/extension.py", line 183, in 
>>>>> install_from_dir
>>>>> shutil.copy(source_path, destination_path)
>>>>>   File "/usr/lib/python3.7/shutil.py", line 245, in copy
>>>>> copyfile(src, dst, follow_symlinks=follow_symlinks)
>>>>>   File "/usr/lib/python3.7/shutil.py", line 121, in copyfile
>>>>> with open(dst, 'wb') as fdst:
>>>>> PermissionError: [Errno 13] Permission denied: 
>>>>> '/usr/share/weewx/user/twi.py'
>>>>> pi@CLOWeatherStation:~ $ 
>>>>>
>>>>> How do I change permissions? 
>>>>>
>>>>> Craig
>>>>>
>>>>> -- 
>>>>> 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+...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/weewx-user/e7d5f0b0-2ca2-43b9-85c4-9f58821563b5n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/weewx-user/e7d5f0b0-2ca2-43b9-85c4-9f58821563b5n%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Peter Quinn
>>>> (415)794-2264 <(415)%20794-2264>
>>>>
>>>
>>>
>>> -- 
>>> Peter Quinn
>>> (415)794-2264 <(415)%20794-2264>
>>>
>> -- 
> 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+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/3cfdad79-3599-457d-bd2b-e017955051aen%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/3cfdad79-3599-457d-bd2b-e017955051aen%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
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/438e9bb9-05a4-480b-ac01-80b5d62c0b57n%40googlegroups.com.

Re: [weewx-user] Installing new driver, question

[Craig Young]

This is on a raspberry pi ..

On Wednesday, September 20, 2023 at 10:28:53 AM UTC+12 Craig Young wrote:

> I tried "gahh.sudo" and got command not found, then tried "gahh.sudo 
> wee_extension --install etc" and also got command not found.  Maybe I am 
> doing this wrong?
>
> On Wednesday, September 20, 2023 at 10:25:17 AM UTC+12 p q wrote:
>
>> gahh. sudo
>>
>> On Tue, Sep 19, 2023 at 3:24 PM p q  wrote:
>>
>>> sudu <https://home.ubalt.edu/abento/linux/terminal/sudonotfedora.html>
>>>
>>> On Tue, Sep 19, 2023 at 3:21 PM Craig Young  
>>> wrote:
>>>
>>>> I am installing the TWI.py driver and have run into an error:
>>>>
>>>> pi@CLOWeatherStation:~ $ wee_extension --install weewx-twi.zip
>>>> Request to install 'weewx-twi.zip'
>>>> Extracting from zip archive weewx-twi.zip
>>>> Traceback (most recent call last):
>>>>   File "/usr/share/weewx/wee_extension", line 92, in 
>>>> main()
>>>>   File "/usr/share/weewx/wee_extension", line 84, in main
>>>> ext.install_extension(options.install)
>>>>   File "/usr/share/weewx/weecfg/extension.py", line 130, in 
>>>> install_extension
>>>> self.install_from_dir(extension_dir)
>>>>   File "/usr/share/weewx/weecfg/extension.py", line 183, in 
>>>> install_from_dir
>>>> shutil.copy(source_path, destination_path)
>>>>   File "/usr/lib/python3.7/shutil.py", line 245, in copy
>>>> copyfile(src, dst, follow_symlinks=follow_symlinks)
>>>>   File "/usr/lib/python3.7/shutil.py", line 121, in copyfile
>>>> with open(dst, 'wb') as fdst:
>>>> PermissionError: [Errno 13] Permission denied: 
>>>> '/usr/share/weewx/user/twi.py'
>>>> pi@CLOWeatherStation:~ $ 
>>>>
>>>> How do I change permissions? 
>>>>
>>>> Craig
>>>>
>>>> -- 
>>>> 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+...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/weewx-user/e7d5f0b0-2ca2-43b9-85c4-9f58821563b5n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/weewx-user/e7d5f0b0-2ca2-43b9-85c4-9f58821563b5n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>>
>>> -- 
>>> Peter Quinn
>>> (415)794-2264 <(415)%20794-2264>
>>>
>>
>>
>> -- 
>> Peter Quinn
>> (415)794-2264 <(415)%20794-2264>
>>
>

-- 
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/3cfdad79-3599-457d-bd2b-e017955051aen%40googlegroups.com.

Re: [weewx-user] Installing new driver, question

[Craig Young]

I tried "gahh.sudo" and got command not found, then tried "gahh.sudo 
wee_extension --install etc" and also got command not found.  Maybe I am 
doing this wrong?

On Wednesday, September 20, 2023 at 10:25:17 AM UTC+12 p q wrote:

> gahh. sudo
>
> On Tue, Sep 19, 2023 at 3:24 PM p q  wrote:
>
>> sudu <https://home.ubalt.edu/abento/linux/terminal/sudonotfedora.html>
>>
>> On Tue, Sep 19, 2023 at 3:21 PM Craig Young  wrote:
>>
>>> I am installing the TWI.py driver and have run into an error:
>>>
>>> pi@CLOWeatherStation:~ $ wee_extension --install weewx-twi.zip
>>> Request to install 'weewx-twi.zip'
>>> Extracting from zip archive weewx-twi.zip
>>> Traceback (most recent call last):
>>>   File "/usr/share/weewx/wee_extension", line 92, in 
>>> main()
>>>   File "/usr/share/weewx/wee_extension", line 84, in main
>>> ext.install_extension(options.install)
>>>   File "/usr/share/weewx/weecfg/extension.py", line 130, in 
>>> install_extension
>>> self.install_from_dir(extension_dir)
>>>   File "/usr/share/weewx/weecfg/extension.py", line 183, in 
>>> install_from_dir
>>> shutil.copy(source_path, destination_path)
>>>   File "/usr/lib/python3.7/shutil.py", line 245, in copy
>>> copyfile(src, dst, follow_symlinks=follow_symlinks)
>>>   File "/usr/lib/python3.7/shutil.py", line 121, in copyfile
>>> with open(dst, 'wb') as fdst:
>>> PermissionError: [Errno 13] Permission denied: 
>>> '/usr/share/weewx/user/twi.py'
>>> pi@CLOWeatherStation:~ $ 
>>>
>>> How do I change permissions? 
>>>
>>> Craig
>>>
>>> -- 
>>> 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+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/e7d5f0b0-2ca2-43b9-85c4-9f58821563b5n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/e7d5f0b0-2ca2-43b9-85c4-9f58821563b5n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> -- 
>> Peter Quinn
>> (415)794-2264 <(415)%20794-2264>
>>
>
>
> -- 
> Peter Quinn
> (415)794-2264 <(415)%20794-2264>
>

-- 
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/9bb24d36-56ea-4a2f-99c3-e7fbf4b39105n%40googlegroups.com.

[weewx-user] Installing new driver, question

[Craig Young]

I am installing the TWI.py driver and have run into an error:

pi@CLOWeatherStation:~ $ wee_extension --install weewx-twi.zip
Request to install 'weewx-twi.zip'
Extracting from zip archive weewx-twi.zip
Traceback (most recent call last):
  File "/usr/share/weewx/wee_extension", line 92, in 
main()
  File "/usr/share/weewx/wee_extension", line 84, in main
ext.install_extension(options.install)
  File "/usr/share/weewx/weecfg/extension.py", line 130, in 
install_extension
self.install_from_dir(extension_dir)
  File "/usr/share/weewx/weecfg/extension.py", line 183, in install_from_dir
shutil.copy(source_path, destination_path)
  File "/usr/lib/python3.7/shutil.py", line 245, in copy
copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib/python3.7/shutil.py", line 121, in copyfile
with open(dst, 'wb') as fdst:
PermissionError: [Errno 13] Permission denied: 
'/usr/share/weewx/user/twi.py'
pi@CLOWeatherStation:~ $ 

How do I change permissions? 

Craig

-- 
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/e7d5f0b0-2ca2-43b9-85c4-9f58821563b5n%40googlegroups.com.

[weewx-user] Re: Observation Types

[Craig Young]

Thanks Karen, that is an incredibly useful document. 

Craig

On Thursday, September 14, 2023 at 8:21:08 AM UTC+12 Karen K wrote:

> I would suggest to look into obs_group_dict in 
> /usr/share/weewx/weewx/units.py for a list of pre-defined observation types 
> and their unit groups.
>
>

-- 
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/4817fd96-3951-41b9-9bf6-13323f27addan%40googlegroups.com.

[weewx-user] Re: Observation Types

[Craig Young]

Thanks Matthew, I understand now.  I also did some reading of the 
'customization' section in the wiki and it ties together nicely with what 
you have posted.  So my next step is to setup the database, load all of my 
archive data and then update the driver to match the schema.
Craig

On Wednesday, September 13, 2023 at 11:07:28 PM UTC+12 matthew wall wrote:

> On Wednesday, September 13, 2023 at 6:51:17 AM UTC-4 craig.y...@gmail.com 
> wrote:
>
> Where can I find the list of observation types? 
>
>
> within the driver code, use names that match whatever the hardware uses. 
> then you can map those onto the weewx observation types when you generate a 
> LOOP or ARCHIVE dict.  for example, the hardware documentation might use 
> 'inside_temperature', but the weewx equivalent is 'inTemp'.
>
> the weewx observation types are defined by the database schema. 
> 'wview_extended' is the default schema, but weewx also ships with the 
> legacy 'wview' and 'wview_small' schemas.
>
> https://github.com/weewx/weewx/blob/master/bin/schemas/wview_extended.py
>
> you can see what other drivers have done by browsing the 'Station data' 
> section for each driver in the hardware guide:
>
> http://weewx.com/docs/hardware.htm
>
> for power/solar/battery monitoring, or hardware that emits observations 
> that are not easily mapped to the weather-based schemas, it is typical to 
> ship a bespoke schema with the driver.
>
>  
>

-- 
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/ed0abb3f-cbdd-40ab-a890-de10b9f22d35n%40googlegroups.com.

[weewx-user] Observation Types

[Craig Young]

Where can I find the list of observation types?  I am writing a new driver 
for my hardware and need to map the physical data to the corresponding 
observation types to create the loop packet.

Craig

-- 
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/21db9689-3aa4-4a6b-ba26-6425bcb9e577n%40googlegroups.com.

[weewx-user] Re: User Guide to create a driver

[Craig Young]

Thanks Gary, I will start with that.

On Friday, September 1, 2023 at 8:39:10 AM UTC+12 gjr80 wrote:

> Have a look at the Porting to new hardware 
>  section in 
> the Customization Guide 
> . Perhaps that is what 
> you saw? You might also find some benefit in looking through the Notes 
> for Developers  guide.
>
> In terms of where to do your development/keep your driver - it's entirely 
> up to you. A public GitHub repo is great, makes reversion easy and gives 
> you an offsite backup in case the worst happens. Depending on what you want 
> to do with GitHub it can be a bit daunting at first, but the effort is well 
> worth it. The big plus for others is that users of the same/similar 
> hardware now have access to a driver.
>
> Gary
> On Friday, 1 September 2023 at 06:06:18 UTC+10 craig.y...@gmail.com wrote:
>
>> My weather station (Campbell Scientific CR300 data logger) is not 
>> supported by weewx.  What I can do though is take an existing driver that 
>> closely matches what I need and change it to create a new driver for the 
>> CR300.  I have looked around for a user guide on how to do this and I 
>> thought I had found one a few weeks ago but can't relocate it.  Is there a 
>> recommended User Guide for creating a new driver from an existing driver?  
>> For this project is it better to download the driver source code to my 
>> raspberry pi, modify it and install it locally as a new driver rather than 
>> putting it in the public GitHub repositories.
>>
>> Craig
>>
>

-- 
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/686bd29d-4bf1-432b-9142-83b29b722c3cn%40googlegroups.com.

[weewx-user] User Guide to create a driver

[Craig Young]

My weather station (Campbell Scientific CR300 data logger) is not supported 
by weewx.  What I can do though is take an existing driver that closely 
matches what I need and change it to create a new driver for the CR300.  I 
have looked around for a user guide on how to do this and I thought I had 
found one a few weeks ago but can't relocate it.  Is there a recommended 
User Guide for creating a new driver from an existing driver?  For this 
project is it better to download the driver source code to my raspberry pi, 
modify it and install it locally as a new driver rather than putting it in 
the public GitHub repositories.

Craig

-- 
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/7ec4912a-6624-45ed-9d13-c2e1b496f2bfn%40googlegroups.com.

Re: [weewx-user] Longitude setting incorrect

[Craig Young]

I got it fixed by rebooting the pi.  Now it shows E longitude.  Does that 
mean I need to do this each time I change the conf file?

On Friday, August 25, 2023 at 11:11:54 AM UTC+12 Tom Keffer wrote:

> Humor me. Show the [Station] section. 
>
> Also, make sure that the file you are editing is the file that WeeWX is 
> actually using. You can tell which configuration file is actually being 
> used by checking the log. Shortly after startup, weewxd will log the path 
> to the configuration file.
>
> Trust me. This will turn out to be a simple problem.
>
> On Thu, Aug 24, 2023 at 3:37 PM Craig Young  wrote:
>
>> In the conf file the number is positive.  The documentation states "-" is 
>> W.  When I installed the software I had a "-" in front of longitude.  I 
>> changed this in the conf file to positive by removing the "-" and saved.  
>> So I now have a positive number in conf file but a W on the GUI panel.
>>
>>
>> On Friday, August 25, 2023 at 10:34:40 AM UTC+12 Craig Young wrote:
>>
>>> Here is the screenshot
>>>
>>> On Friday, August 25, 2023 at 10:21:01 AM UTC+12 Tom Keffer wrote:
>>>
>>>> On Thu, Aug 24, 2023 at 2:11 PM Craig Young  
>>>> wrote:
>>>>
>>>>> I opened and edited conf file and it does indeed show positive on the 
>>>>> browser, but still displays W as the longitude.
>>>>>
>>>>
>>>> Not following. What do you mean by "show positive on the browser"?
>>>>
>>>> Perhaps you can post your [Station] section?
>>>>
>>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/9f8eda34-f998-478f-be42-1b4506035931n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/9f8eda34-f998-478f-be42-1b4506035931n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/7b91358f-f66c-4f2f-8559-80be254eb8d2n%40googlegroups.com.

Re: [weewx-user] Longitude setting incorrect

[Craig Young]

In the conf file the number is positive.  The documentation states "-" is 
W.  When I installed the software I had a "-" in front of longitude.  I 
changed this in the conf file to positive by removing the "-" and saved.  
So I now have a positive number in conf file but a W on the GUI panel.


On Friday, August 25, 2023 at 10:34:40 AM UTC+12 Craig Young wrote:

> Here is the screenshot
>
> On Friday, August 25, 2023 at 10:21:01 AM UTC+12 Tom Keffer wrote:
>
>> On Thu, Aug 24, 2023 at 2:11 PM Craig Young  wrote:
>>
>>> I opened and edited conf file and it does indeed show positive on the 
>>> browser, but still displays W as the longitude.
>>>
>>
>> Not following. What do you mean by "show positive on the browser"?
>>
>> Perhaps you can post your [Station] section?
>>
>

-- 
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/9f8eda34-f998-478f-be42-1b4506035931n%40googlegroups.com.

Re: [weewx-user] Longitude setting incorrect

[Craig Young]

Here is the screenshot

On Friday, August 25, 2023 at 10:21:01 AM UTC+12 Tom Keffer wrote:

> On Thu, Aug 24, 2023 at 2:11 PM Craig Young  wrote:
>
>> I opened and edited conf file and it does indeed show positive on the 
>> browser, but still displays W as the longitude.
>>
>
> Not following. What do you mean by "show positive on the browser"?
>
> Perhaps you can post your [Station] section?
>

-- 
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/37dead25-befe-46b3-ba49-fe593ae2b201n%40googlegroups.com.

[weewx-user] Re: Longitude setting incorrect

[Craig Young]

In addition, I did stop the service, edited conf file, saved conf file and 
the restarted service.

Craig

On Friday, August 25, 2023 at 9:11:07 AM UTC+12 Craig Young wrote:

> New installation on Raspberry PI.  All is working, am using the simulator 
> to start with.  The longitude is 175 E but is always showing up in the 
> browser as 175 W.  The documentation says "-" is for W longitude.  I opened 
> and edited conf file and it does indeed show positive on the browser, but 
> still displays W as the longitude.
>
> How do I change this?
>
> Craig
>

-- 
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/3d335582-fe2c-473b-a318-b65c2d955665n%40googlegroups.com.

[weewx-user] Longitude setting incorrect

[Craig Young]

New installation on Raspberry PI.  All is working, am using the simulator 
to start with.  The longitude is 175 E but is always showing up in the 
browser as 175 W.  The documentation says "-" is for W longitude.  I opened 
and edited conf file and it does indeed show positive on the browser, but 
still displays W as the longitude.

How do I change this?

Craig

-- 
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/2b8b4d22-65de-4f1c-85f0-6d8207a547f6n%40googlegroups.com.

Re: [weewx-user] Campbell Scientific CR300 data logger

[Craig Young]

Exactly what I was looking for.  I can send UDP packets to simulate the 
WeatherFlow device and use the existing driver.  The WF API documentation 
is perfect .. I will duplicate that in my controller.  Thanks Vince.
Craig

On Monday, April 24, 2023 at 4:03:47 AM UTC+12 vince wrote:

> You didn't say which os you're using, but one option would be to generate 
> the same input that other drivers already use, and simply reuse an existing 
> weewx driver designed for a different vendor.
>
> For example - the WeatherFlow UDP driver listens for broadcasts that meet 
> the published WeatherFlow UDP API (basically you want to simply broadcast 
> JSON-formatted data).   If you could emit your data the same way and stick 
> with the WF UDP API format, you could just use that existing driver to get 
> your data into weewx with no weewx coding required.
>
> I have a super-minimal simulator tool in python (link) 
>  that you could perhaps use as 
> a starting point for one way to emit the expected UDP.  The WF API is 
> (here)  if you 
> wanted to see what that vendor's station broadcasts.  If you can get your 
> data out of your logger and broadcast UDP meeting their API, you probably 
> could connect the dots.
>
> Just a thought.  I'm sure you could follow similar paths to reuse other 
> weewx drivers.
>
>

-- 
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/770cbcc1-7fae-4498-a517-8e6dcc9e3861n%40googlegroups.com.

Re: [weewx-user] Campbell Scientific CR300 data logger

[Craig Young]

I update about every 15 seconds.  The one second was to shorten the time 
between when the data file is updated and when weewx reads it.  But I will 
look at the intake-strategies document and see what is available.


On Sunday, April 23, 2023 at 2:39:31 PM UTC+12 vince wrote:

> Start with https://github.com/weewx/weewx/wiki/intake-strategies but 
> short answer is sure.  If you can get the data in any format it is possible 
> to get it into weewx via a variety of methods.   You might also poke around 
> https://github.com/weewx/weewx/wiki#extensions-to-weewx for too many 
> examples to get into in a reply.
>
> Once/second is a bit quick however.  Does your data need to be that 
> real-time ?
>
> On Saturday, April 22, 2023 at 7:28:19 PM UTC-7 Craig Young wrote:
>
>> By any chance can weewx read from a data file?  I could write the 
>> incoming real time data to the file as a one line record and then weewx 
>> would read this, say once a second or so.
>>
>>
>> On Sunday, April 23, 2023 at 1:56:52 PM UTC+12 DR wrote:
>>
>>> Craig, I don't know of a driver for the Campbell dataloggers.
>>>
>>>
>>> I wish there were one, I have a very dependable station (CR3000) that 
>>> I'd like to interface.  Right now it is filling the native tables, and a 
>>> Weather Display driver using pakbus is pulling those values from that table 
>>> and handing them off to Weather Display, so I know 'something' could be 
>>> made to work.
>>>
>>>
>>> I am using a Texas Weather Instruments which, with the help of someone 
>>> who knows Python a lot better than me, helped to get running.  It basically 
>>> sends a send data command and then a data string gets sent from the TWI, 
>>> which the driver then parses and loads into a packet and hands off to 
>>> WeeWx.  I'm assuming that it can be adapted to other devices.
>>>
>>> I am trying to learn Python well enough to write or modify a driver and 
>>> the learning curve for this old FORTRAN and ALGOL guy is steeper than I 
>>> thought it would be, but I am getting closer.  Things like synchronization 
>>> with an incoming unrequested stream and how packets are formed and sent 
>>> seem to by my next steps.
>>>
>>> I wish I could say that within a few months I'd have a polished working 
>>> driver, but with many other demands on my free time, progress is slow.
>>>
>>> If  you've got a program on your PC that pulls in the live data stream 
>>> you are perhaps in a much better place to write a routine to emulate that 
>>> process and then look at how, for instance, the TWI driver forms a packet 
>>> to hand off to WeeWx.  
>>>
>>>
>>> I'm hoping you could use that little info to plan on how to get a 
>>> working driver that you might share with the rest of us.  My encouragement 
>>> to make it work is all I can give you otherwise, but sounds like you are 
>>> pretty close.
>>>
>>> The MQTT recommendation is something you might look at, too.   I know 
>>> little about that.  I am grateful to those who have furnished so much 
>>> already.  Dale
>>>
>>>
>>> On 4/22/2023 8:04 PM, p q wrote:
>>>
>>> I don't know the answer to the primary question. 
>>>
>>> As to recommended protocols, I'd choose MQTT.
>>>
>>> On Sat, Apr 22, 2023 at 5:53 PM Craig Young  
>>> wrote:
>>>
>>>> Is there a driver for the CR300 data logger?  If not, I have a PC 
>>>> connected to the data logger, collecting the live data stream which I can 
>>>> reformat and send as either RS232 or UDP/IP packets to weewx in any 
>>>> format.  Would need a recommendation on which protocol to use.  But 
>>>> hopefully, there is already a driver for the CR300 or a 'generic' driver.
>>>>
>>>> Craig
>>>> -- 
>>>> 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+...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/weewx-user/03d49dbf-648c-4810-bc60-237abe5ec828n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/weewx-user/03d49dbf-648c-4810-bc60-237abe5ec828n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>>
>>> -- 
>

Re: [weewx-user] Campbell Scientific CR300 data logger

[Craig Young]

By any chance can weewx read from a data file?  I could write the incoming 
real time data to the file as a one line record and then weewx would read 
this, say once a second or so.


On Sunday, April 23, 2023 at 1:56:52 PM UTC+12 DR wrote:

> Craig, I don't know of a driver for the Campbell dataloggers.
>
>
> I wish there were one, I have a very dependable station (CR3000) that I'd 
> like to interface.  Right now it is filling the native tables, and a 
> Weather Display driver using pakbus is pulling those values from that table 
> and handing them off to Weather Display, so I know 'something' could be 
> made to work.
>
>
> I am using a Texas Weather Instruments which, with the help of someone who 
> knows Python a lot better than me, helped to get running.  It basically 
> sends a send data command and then a data string gets sent from the TWI, 
> which the driver then parses and loads into a packet and hands off to 
> WeeWx.  I'm assuming that it can be adapted to other devices.
>
> I am trying to learn Python well enough to write or modify a driver and 
> the learning curve for this old FORTRAN and ALGOL guy is steeper than I 
> thought it would be, but I am getting closer.  Things like synchronization 
> with an incoming unrequested stream and how packets are formed and sent 
> seem to by my next steps.
>
> I wish I could say that within a few months I'd have a polished working 
> driver, but with many other demands on my free time, progress is slow.
>
> If  you've got a program on your PC that pulls in the live data stream you 
> are perhaps in a much better place to write a routine to emulate that 
> process and then look at how, for instance, the TWI driver forms a packet 
> to hand off to WeeWx.  
>
>
> I'm hoping you could use that little info to plan on how to get a working 
> driver that you might share with the rest of us.  My encouragement to make 
> it work is all I can give you otherwise, but sounds like you are pretty 
> close.
>
> The MQTT recommendation is something you might look at, too.   I know 
> little about that.  I am grateful to those who have furnished so much 
> already.  Dale
>
>
> On 4/22/2023 8:04 PM, p q wrote:
>
> I don't know the answer to the primary question. 
>
> As to recommended protocols, I'd choose MQTT.
>
> On Sat, Apr 22, 2023 at 5:53 PM Craig Young  wrote:
>
>> Is there a driver for the CR300 data logger?  If not, I have a PC 
>> connected to the data logger, collecting the live data stream which I can 
>> reformat and send as either RS232 or UDP/IP packets to weewx in any 
>> format.  Would need a recommendation on which protocol to use.  But 
>> hopefully, there is already a driver for the CR300 or a 'generic' driver.
>>
>> Craig
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/03d49dbf-648c-4810-bc60-237abe5ec828n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/03d49dbf-648c-4810-bc60-237abe5ec828n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
> Peter Quinn
> (415)794-2264 <(415)%20794-2264>
> -- 
> 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+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/CAA1SM22-7QQ_GPRJHG1j%2Be5U99aKMzh3-VS0YKGU4Ob2KDSywg%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/weewx-user/CAA1SM22-7QQ_GPRJHG1j%2Be5U99aKMzh3-VS0YKGU4Ob2KDSywg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>

-- 
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/99592c0e-762c-4b0f-83b7-cedf1465abecn%40googlegroups.com.

[weewx-user] Campbell Scientific CR300 data logger

[Craig Young]

Is there a driver for the CR300 data logger?  If not, I have a PC connected 
to the data logger, collecting the live data stream which I can reformat 
and send as either RS232 or UDP/IP packets to weewx in any format.  Would 
need a recommendation on which protocol to use.  But hopefully, there is 
already a driver for the CR300 or a 'generic' driver.

Craig

-- 
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/03d49dbf-648c-4810-bc60-237abe5ec828n%40googlegroups.com.