[weewx-user] Re: Removed an erroneous daily rainfall reading from the database and now its back after reboot

[gjr80]

Hi,

The only way that something historical would be pulled from the console and 
placed in the archive would be if WeeWX was doing a catchup on startup, and 
then WeeWX would only catchup records timestamped after the most recent 
record in your archive and the catchup would only occur if your station had 
a logger/memory and supported a catchup. Catching up back to 2013 I would 
suggest is beyond all of the stations currently supported by WeeWX. Most 
likely what has happened is that the data appeared to be deleted but in 
fact it was not and when you subsequently made copies of your database you 
just copied a database that included the erroneous data. 

I would suggest repeating the process this time screen capturing everything 
you do (and the responses as well). The broad process I would use is:

1. backup your database
2. query your database to find the erroneous data
3. run your update query to remove the erroneous data
4. query your database again to confirm you have indeed removed the 
erroneous data
5. if you wish make another backup/shuffle your databases
6. drop then rebuild your daily summaries
(6.5 if really paranoid query your database again to confirm the erroneous 
data has been removed from the archive and the rain daily summary table 
archive_rain_day)
7. run wee_reports or start WeeWX normally and wait for the reports to be 
generated

If the data is still there post all of your commands and the responses.

Gary

On Saturday, 4 April 2020 01:20:20 UTC+10, Muireadach O Connor wrote:
>
> Hi guys,
>
> I'm struggling to understand what I'm doing wrong here.
>
> I want to remove a daily reading of 134mm rain from February 2013 as its 
> bothering me in my records page. I had cleaned the rain gauge that day and 
> never got around to correcting it.
> I'd previously amended a max rainRate figure from the database without too 
> much issue so thought this would be the same but its proving much more 
> troublesome.
>
> I removed it using :
>
> update archive set rain=NULL where rain > 4; (db in imperial)
>
> Next made a  new copy of this new database
>
> Then..
>
> sudo wee_database --drop-daily
> sudo wee_database weewx.conf --rebuild-daily
>
> then ran :
>
> wee_reports --config=/etc/weewx/weewx.conf
>
> However the records webpage on my pi (reports folder) in still showed the 
> old value in there.
>
> At this stage I figured maybe its cached in memory so stopped the WeeWX 
> service and restarted the raspberry pi
>
> Now the old value is back in the database again (/shakes fist at cloud)
> I've looked at my amended copy and the latest one and the old maximum 
> daily reading is definitely back and definitely was removed.
>
> I'm guessing this is being pulled from the console somehow, should I have 
> cleared it also there also before restarting?
> If not, anyone any ideas how to fix this?
>
>

-- 
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/5e1015fb-a912-459b-a14c-c7182b3d9302%40googlegroups.com.

[weewx-user] Re: how to get german letters and fortatting into highcharts?

[gjr80]

Some answers below.

Gary

On Saturday, 4 April 2020 00:58:44 UTC+10, Astrid wrote:

> Hello!
>
> I am using weewx 3.9.2 and highcharts.
> It is working very well. :)
>
> How can I get german letters into week.json.tmpl?
>
> Instead of
>
> "windplot": {"series":
> {"windSpeed": {"name": "Windstaerke", "data": $windSpeedWeekjson},
> "windGust": {"name": "Boeen", "data": $windGustWeekjson}},
> "units": "$unit.label.windSpeed"#slurp
>
> I want to get 
>
> "windplot": {"series":
> {"windSpeed": {"name": "Windst*ä*rke", "data": $windSpeedWeekjson},
> "windGust": {"name": "B*ö*en", "data": $windGustWeekjson}},
> "units": "$unit.label.windSpeed"#slurp
>
> if I write it as above into week.json.tmpl, then week.json will
> not be created.
>
> The templates were never developed with language support in mind; however, 
it should be easy enough to add. In the templates 
skins/Highcharts/json/week.json.tmpl and 
skins/Highcharts/json/year.json.tmpl insert the highlighted line near the 
top of the files as indicated:

##errorCatcher Echo
#encoding UTF-8
##

Save the files and on the next report cycle your German characters should 
render fine. I don't have time to do an extensive checking of that 
extension just now so I cannot guarantee this will not cause some other 
issue elsewhere, let me know if it does.
 

> And how can I change in highchartplot the text from "hamburger"-menu,
> where now is standing "Chart context menu"?
>

The highcharts extension makes no changes to the chart hamburger menu, so 
anything you want to chnage you will need to refer to the Highcharts API 
. 


> Some parts I already get changed by putting into plots.js:
>
> var highchartsOptions = Highcharts.setOptions({
>   lang: {
> loading: 'Lade...',
> months: ['Jan', 'Feb', 'Mar', 'Apr', 'Mai', 'Jun', 'Jul', 
> 'Aug', 'Sep', 'Okt', 'Nov', 'Dez'],
> weekdays: ['Mo', 'Di', 'Mi', 'Do', 'Fr', 'Sa', 'So'],
> shortMonths: ['Jan', 'Feb', 'Mar', 'Apr', 'Mai', 'Jun', 'Jul', 
> 'Aug', 'Sep', 'Okt', 'Nov', 'Dez'],
> exportButtonTitle: "Exportieren",
> printButtonTitle: "Drucken",
> rangeSelectorFrom: "von",
> rangeSelectorTo: "bis",
> rangeSelectorZoom: "Zeitraum",
> downloadPNG: 'Download als png',
> downloadJPEG: 'Downlaod als jpeg',
> downloadPDF: 'Download als pdf',
> downloadSVG: 'Download als svg',
> resetZoom: "Reset",
> resetZoomTitle: "Reset",
> thousandsSep: ",",
> decimalPoint: '.'
> }
>   }
> );
>

OK, so those changes will change the language displayed for each item.
 

>
> But there is left in "Chart Context Menu" (this itself):
> "View in fullscreen" and "Print chart"
>

You want to change 'View in fullscreen' and 'Print chart' to German? If so 
you shoudl use the viewFullscreen 
 and 
exitFullscreen options in your lang setting above.
 

>
> and in the charts, where on the right top corner can be input
> the date "from" and the date "to", that in can be done in
> german notation dd.mm.?
>

Do you want to chnage the format of the dates in the From and To boxes? If 
so you need to change the inputDateFormat and inputEditDateFormat options 
in the theme.js file included with the highcharts extension. inputDateFormat 
sets the format displayed in each box and inputEditDateFormat sets the 
format displayed when editing each box.
 

>
> Regards, Astrid
>
>
>

-- 
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/4490e078-65f9-4c86-9f3b-c06fb0f3f5ec%40googlegroups.com.

Re: [weewx-user] Re: Add additional rain gauge via second data source

[engolling]

Hello, 
I have finally found the problem.
Seemingly the image generator is not case sensitive with the signal names.
The input signal was named 'rain_RG11'.

The unit group system IS case sensitive because in my plugin I linked
weewx.units.obs_group_dict['Rain_RG11'] = 'group_rain'

And so I got a graph but with no units on the y-axis and no conversion.

Regards,
engolling

Am Freitag, 22. November 2019 00:01:00 UTC+1 schrieb engolling:
>
> Hello,
>
> I checked my image generation settings again and I also tried to check the 
> imagegenerator.py file but I did not find any reason why the conversion to 
> "mm" is not applied or at least the native database unit "cm" is not 
> applies.
>
> I would be glad, if someone can give me a hint where this could come from 
> and what is the best way to debug.
>
> Regards,
> engolling
>
> Am Dienstag, 5. November 2019 22:18:59 UTC+1 schrieb engolling:
>>
>> Hello to all,
>>
>> I got another question. The import of additional rain works fine now.
>> So if a add the following tag to my template: 
>> $day.Rain_RG11.sum
>> I get the correct value in my preselected unit. (Database is metric and 
>> my default unit for group_rain is "mm")
>>
>> I'm also generating two graphs with the following code:
>> [[[dayrain]]]
>> # Make sure the y-axis increment is at least 0.02 for the 
>> rain plot
>> yscale = None, None, 0.02
>> plot_type = bar
>> rain
>> aggregate_type = sum
>> aggregate_interval = 3600
>> label = Niederschlag (Stundenwerte)
>> [[[dayrain_RG11]]]
>> # Make sure the y-axis increment is at least 0.02 for the 
>> rain plot
>> yscale = None, None, 0.02
>> plot_type = bar
>> rain_RG11
>> aggregate_type = sum
>> aggregate_interval = 3600
>> label = Niederschlag (Stundenwerte)
>>
>> Here I get the following images (do not look at the actual bar values - 
>> they are not representative and result due to testing):
>>
>> My self added rain source generates correct values but it does not 
>> display the unit and the values which are plotted are seeming to be in the 
>> native unit [cm] as it is stored in the database.
>> Does anybody has an idea what could be the matter here? Tags are working 
>> fine, but not the image generation.
>>
>> Thanks in advance for your answers.
>>
>> Regards,
>> engolling
>>
>>
>> Am Dienstag, 28. Mai 2019 00:20:07 UTC+2 schrieb gjr80:
>>>
>>> On Tuesday, 28 May 2019 06:52:22 UTC+10, engolling wrote:

 So I started off with the noob variant...
 https://github.com/menachers/WeatherDuino/tree/master/WeeWx_Plugin

>>>
>>> That looks like it will work, but be aware that if the record you are 
>>> augmenting is in anything other than US customary units no conversion will 
>>> be applied (this may be fine given your current setup but who knows how it 
>>> may change in the future). Nothing to worry about if you are going to 
>>> rewrite the code anyway.
>>>  
>>>
 I will change it to the sophisticated procedure you proposed. 
 As I got you right
 # express our rainfall value as a ValueTuple
 rainfall_vt = weewx.units.ValueTuple(rainfall, 'mm', 'group_rain')
 I have to generate a tuple with the variable holding the actual value, 
 followed by the unit of the signal as it can be found in the units.py dict 
 and ending with the unit group which it belongs to.

>>>
>>> Correct. The ValueTuple is the basis of the WeeWX system for unit 
>>> conversion; it brings together the value, the units used and the unit group 
>>> to which it belongs. When WeeWX needs to convert the value to some other 
>>> units or to the units used in a particular unit system (US, Metric or 
>>> MetricWX) the ValueTuple has the core information used to determine how to 
>>> do the conversion. You might want to look at the class ValueTuple in 
>>> bin/weewx/units.py 
>>> . 
>>> the other good thing about ValueTuple based conversion is that it will 
>>> handle the case where the data value is None - note how in the simple 
>>> approach I outlined we had to take care of the case where the data value 
>>> may be None. 
>>>
>>> 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/c7e114a4-904d-44f1-a173-e8d8d0932c24%40googlegroups.com.

Re: [weewx-user] Re: Changes with Belchertown skin & DarkSky

[Pat]

Everytime I get a minute to sit down and open the laptop and read up on 
what's available, I change my mind. I'm back on the OpenWeatherMap thought 
now because of the localization and languages it offers. 

On Friday, April 3, 2020 at 4:47:42 PM UTC-4, gary@gmail.com wrote:
>
> If units aren’t an issue, then in the infamous words of Alfred E. Neuman, 
> what, me worry?
>
>  
>
>  
>
> *From:* weewx...@googlegroups.com   > *On Behalf Of *steeple ian
> *Sent:* Friday, April 3, 2020 11:37 AM
> *To:* weewx...@googlegroups.com 
> *Subject:* Re: [weewx-user] Re: Changes with Belchertown skin & DarkSky
>
>  
>
> Gary,
>
>  
>
> Ok have a look here: -
>
>  
>
> https://claydonsweather.org.uk
>
>  
>
> The base units are set in weewx.conf to METRICWX. The json data from WU is 
> coming as US, DarkSky as METRIC. The skin is displaying U.K. units which is 
> Metric with mph. Click on the F button too right and watch what happens to 
> the units including those of the forecasts. Go to the menu accessed by 
> clicking top left. You will see toggles for various unit systems. The data 
> does not change, it is just converted on the fly. So I don’t see units 
> being an issue.
>
> Ian
>
>  
>
> On Fri, 3 Apr 2020 at 16:05, G Hammer > 
> wrote:
>
> Metric is not used in the US would be the problem.
>
>  
>
>  
>
> On Fri, Apr 3, 2020, 10:37 AM steeple ian  > wrote:
>
> Quote from yr.no website: -
>
>  
> *"A new Yr API is on the way!*
>
> We are working on a new and modern API, that we plan to release some time 
> in the winter 2019. Make sure you visit this site to keep posted!"
>
> I am not sure why metric only is so much of a problem anyway, but maybe 
> that will be fixed in the new API anyway.
>
> From a personal point of view, I use forecasting services from YR DarkSky, 
> WU, and UK Metoffice. I know it can be subjective but for my location YR is 
> by far the most accurate.
>
> Ian
>
>  
>
> On Fri, Apr 3, 2020 at 3:17 PM Pat > 
> wrote:
>
> yr.no isn't commercially owned, so the theory is they won't get bought 
> out or go away. They're owned by the Norwegian Broadcasting Corporation 
> and the Norwegian Meteorological Institute. That said, it's only in 
> metric, does not have weather alerts and is in XML format only. 
>
>  
>
> The pro is that they don't seem at risk of being purchased and going away. 
> The con is it may not be a good fit for how the skin is being used. 
>
>
>
> On Friday, April 3, 2020 at 10:01:39 AM UTC-4, G Hammer wrote:
>
> I'd say OWM, simply because I see no way to get anything except metric/C 
> from yr.no
>
> On Thursday, April 2, 2020 at 9:11:43 PM UTC-4, Pat wrote:
>
> I'm sure the Belchertown skin could benefit from the forecasts plugin, but 
> Belchertown does more than that. It shows weather alerts for your location 
> as well as current conditions. The forecasting plugin doesn't provide those 
> 2 bits. For that you need a service, and if you're getting info from the 
> service (in my opinion), one stop shop for it (get the forecast too). 
>
>  
>
> As for maintaining a plugin base for each region/location, that's not 
> something I can develop or support right now. The JSON would have to be 
> formatted exactly for each service in order to support the current way of 
> updates. Again, this is a simple task for 1 provider who has all this data 
> for worldwide regions
>
>  
>
> I understand that OWM could become the next DarkSky but I think it's the 
> best option for what we have right now. The free tier should be able to 
> provide enough data to replace DarkSky. 
>
>  
>
> It's just a matter of time on my end.
>
>  
>
>
> On Thursday, April 2, 2020 at 6:38:28 PM UTC-4, William Burton wrote:
>
> Hello,
>
> On Thursday, April 2, 2020 at 4:34:46 PM UTC-4, Wes Witt wrote:
>
> how about implementing a design that allows for weather forecast 
> extensions/plugins. then regional plugins can be built and allow the user 
> to choose the weather forecast service that is best for them. this way you 
> don't need a single service that works for everyone. it can be very 
> difficult to find a service that works everywhere and if you can find one 
> it may result in a low bar terms of quality and features from the service.
>
>  
>
> I was thinking the exact same thing as it doesn't make sense for every 
> skin author to have to implement forecasting from scratch. There are many 
> API's and there won't be one that works for everyone everywhere.
>
>  
>
> The weewx-forecast extension (
> https://github.com/matthewwall/weewx-forecast), already handles the 
> following weather forecasting services:
>
>  
>
>   US National Weather Service (NWS)
>
>   the weather underground (WU)
>
>   open weathermap (OWM)
>
>   UK Met Office (UKMO)
>
>   Aeris Weather
>
>   World Weather Online (WWO)
>
>   Dark Sky (DS)
>
>   Zambretti
>
>  
>
> The extension also handles tide predictions using xtide.
>
>  
>
> My thought was to enhance the weewx-forecast extension to:
>
> · Output a generic JSON file 

RE: [weewx-user] Re: Changes with Belchertown skin & DarkSky

[gary.hammer]

If units aren’t an issue, then in the infamous words of Alfred E. Neuman, what, 
me worry?

 

 

From: weewx-user@googlegroups.com  On Behalf Of 
steeple ian
Sent: Friday, April 3, 2020 11:37 AM
To: weewx-user@googlegroups.com
Subject: Re: [weewx-user] Re: Changes with Belchertown skin & DarkSky

 

Gary,

 

Ok have a look here: -

 

https://claydonsweather.org.uk

 

The base units are set in weewx.conf to METRICWX. The json data from WU is 
coming as US, DarkSky as METRIC. The skin is displaying U.K. units which is 
Metric with mph. Click on the F button too right and watch what happens to the 
units including those of the forecasts. Go to the menu accessed by clicking top 
left. You will see toggles for various unit systems. The data does not change, 
it is just converted on the fly. So I don’t see units being an issue.

Ian

 

On Fri, 3 Apr 2020 at 16:05, G Hammer mailto:gary.ham...@gmail.com> > wrote:

Metric is not used in the US would be the problem.

 

 

On Fri, Apr 3, 2020, 10:37 AM steeple ian mailto:steeple...@gmail.com> > wrote:

Quote from yr.no   website: -

 


"A new Yr API is on the way!


We are working on a new and modern API, that we plan to release some time in 
the winter 2019. Make sure you visit this site to keep posted!"

I am not sure why metric only is so much of a problem anyway, but maybe that 
will be fixed in the new API anyway.

>From a personal point of view, I use forecasting services from YR DarkSky, WU, 
>and UK Metoffice. I know it can be subjective but for my location YR is by far 
>the most accurate.

Ian

 

On Fri, Apr 3, 2020 at 3:17 PM Pat mailto:p...@obrienphoto.net> > wrote:

yr.no   isn't commercially owned, so the theory is they won't get 
bought out or go away. They're owned by the Norwegian Broadcasting Corporation 
and the Norwegian Meteorological Institute. That said, it's only in metric, 
does not have weather alerts and is in XML format only. 

 

The pro is that they don't seem at risk of being purchased and going away. The 
con is it may not be a good fit for how the skin is being used. 



On Friday, April 3, 2020 at 10:01:39 AM UTC-4, G Hammer wrote:

I'd say OWM, simply because I see no way to get anything except metric/C from 
yr.no  

On Thursday, April 2, 2020 at 9:11:43 PM UTC-4, Pat wrote:

I'm sure the Belchertown skin could benefit from the forecasts plugin, but 
Belchertown does more than that. It shows weather alerts for your location as 
well as current conditions. The forecasting plugin doesn't provide those 2 
bits. For that you need a service, and if you're getting info from the service 
(in my opinion), one stop shop for it (get the forecast too). 

 

As for maintaining a plugin base for each region/location, that's not something 
I can develop or support right now. The JSON would have to be formatted exactly 
for each service in order to support the current way of updates. Again, this is 
a simple task for 1 provider who has all this data for worldwide regions

 

I understand that OWM could become the next DarkSky but I think it's the best 
option for what we have right now. The free tier should be able to provide 
enough data to replace DarkSky. 

 

It's just a matter of time on my end.

 


On Thursday, April 2, 2020 at 6:38:28 PM UTC-4, William Burton wrote:

Hello,

On Thursday, April 2, 2020 at 4:34:46 PM UTC-4, Wes Witt wrote:

how about implementing a design that allows for weather forecast 
extensions/plugins. then regional plugins can be built and allow the user to 
choose the weather forecast service that is best for them. this way you don't 
need a single service that works for everyone. it can be very difficult to find 
a service that works everywhere and if you can find one it may result in a low 
bar terms of quality and features from the service.

 

I was thinking the exact same thing as it doesn't make sense for every skin 
author to have to implement forecasting from scratch. There are many API's and 
there won't be one that works for everyone everywhere.

 

The weewx-forecast extension (https://github.com/matthewwall/weewx-forecast), 
already handles the following weather forecasting services:

 

  US National Weather Service (NWS)
  the weather underground (WU)
  open weathermap (OWM)
  UK Met Office (UKMO)
  Aeris Weather
  World Weather Online (WWO)
  Dark Sky (DS)
  Zambretti
 
The extension also handles tide predictions using xtide.
 
My thought was to enhance the weewx-forecast extension to:
* Output a generic JSON file that can be loaded via Ajax into a theme. As much 
as possible, the JSON would be generated in a manner that's consistent across 
different API implementations to make it easier to incorporate into a skin.
* Output one or more include files that can be included into other skins.
Skins like Belchertown can incorporate this output using either method as 
appropriate. The end result is it would be far easier for skin maintainers to 
expand 

[weewx-user] Re: problems with wee_import from csv

[gjr80]

Since you used the —log option you will find the log entries in the file 
log1.log. Since you did not provide an explicit path the file will likely be in 
the directory you were in when you ran the wee_import command. If you omit the 
—log option then wee_import log entries are placed in the same log file as used 
by WeeWX.

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/51f7d0d5-82ee-4978-bcc1-3dafafa760dd%40googlegroups.com.

Re: [weewx-user] Modifying pyephem Date format on Celestial page?

[Thomas Keffer]

Hello, Pete

See section [[TimeFormats]]
 in the
Customizing Guide. In particular, options ephem_day and ephem_year.

On Fri, Apr 3, 2020 at 9:38 AM pbartko  wrote:

> Longtime weewx user, but just reinstalled weewx 3.9.2 on Raspberry pi due
> to hardware failure on my previous server.  I'm using the Seasons skin and
> installed pyephem.
>
> Everything is working well, but I can not figure out one thing.  How to
> change the date format of the Solstice, Equinox, Full moon and New moon?
> I'm in the US and we always try to be confusing by having things like our
> dates different the the rest of the world.  I'd like the those dates to be
> in MM/DD/ format instead of DD/MM/ format.  I was able to modify
> the report generator and image generator to change the date formats, but
> I'm stumped with the Celestial data from pyephem.
>
> site is here: http://www.boxhillweather.com
>
>
> Thanks
>
> Pete
>
> --
> 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/4e1f9a72-b163-4293-ae33-9c14c6da7751%40googlegroups.com
> 
> .
>

-- 
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/CAPq0zEA5sKchP%2BvoS2wNggLORFEL3WJVbmAFhKRABNOP1knXBQ%40mail.gmail.com.

[weewx-user] Re: how to insert additional data (cpu temp) into skins?

[Vetti52]

As with most of the HAT devices, it is connected directly onto the gpio 
pins. So the CPU is almost completely covered by the board. No chance to 
get it fixed that way.
https://phoscon.de/de/raspbee




Thanks anyway.
Peter  

Am Freitag, 3. April 2020 09:29:23 UTC+2 schrieb Mike Revitt:
>
> Don't know the ZigBee gateway and hard to tell from the pictures what it 
> needs.
>
> But the Flicr case is very similar to most cases, but with the Flicr the 
> case is the heat sink, so instead of attaching the standard heat sink to 
> the CPU module you attach the case via a rectangular extrusion that matches 
> the size of the CPU and goes vertically to the top of the case.
>
> Unfortunately I can't send photos or anything as mine is assembled and the 
> downsize is I can't get to the mother board now as it is attached to the 
> lid. which is an obvious drawback if you want to be able to plug things in 
> etc. I guess that as long as you have a supply of double sided thermal tape 
> you could remove the case and reattach it when required though.
>
> On Thursday, April 2, 2020 at 7:49:30 PM UTC+1, Vetti52 wrote:
>>
>> Looks pretty nice, Mike!
>>
>> do you know, if there is enough room inside the flirc case for a hat 
>> module? My RPi4 also serves as a ZigBee gateway. The zigbee thing is a hat 
>> mounted module board. All of the RPi4 cooling cases, I tried, do not have 
>> enough space for this HAT board. 
>>
>> BTW, after using your solution, the CPU temp is monitored at 54 °C. It 
>> was at ybut 60 °C, but is lower since the latest kernel update. In 
>> comparison to the output of "cat /sys/class/thermal/thermal_zone0/temp", 
>> the values vary less then 2 degrees, but they almost always vary. Maybe an 
>> academic question...
>>
>> Thanks so far!
>>
>> Peter
>>
>> Am Samstag, 28. März 2020 15:46:21 UTC+1 schrieb Mike Revitt:
>>>
>>> Can't find the CPU frequency code, but while I am looking I thought you 
>>> might find this interesting, this is the CPU temperature graph from my 
>>> Raspberry Pi.
>>>
>>> On the left is the temperature from the standard case, on the right is 
>>> the temperature after I get a Flirc case, This case not only looks really 
>>> cool but my Raspberry Pi now runs 20 degrees cooler. I am using a Raspberry 
>>> Pi 4 by the way which runs 10 degrees hotter than my 3+.
>>>
>>> https://flirc.tv/more/raspberry-pi-4-case for product data
>>>
>>> https://www.amazon.co.uk/gp/product/B07WG4DW52/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8=1
>>>  
>>> if you want to buy one in the UK
>>>
>>>
>>> [image: daytemp.png]
>>>
>>>
>>> On Thursday, March 26, 2020 at 5:45:52 PM UTC, Meteo Oberwallis wrote:

 Am Donnerstag, 26. März 2020 17:42:14 UTC+1 schrieb Mike Revitt: 
 > O have worked out how to get the CPU frequency which sort of helps, 
 but would need to look into this 
 > 
 > On Thursday, March 26, 2020 at 4:09:05 PM UTC, Meteo Oberwallis 
 wrote:Hello. 
 > Is it also possible to read out the CPU load from the Raspberry and 
 write it to the database? 

 Sounds good ;-) 
>>>
>>>

-- 
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/c7e51be6-9c30-4edc-b872-18261b1bd5bd%40googlegroups.com.

Re: [weewx-user] Re: how to insert additional data (cpu temp) into skins?

[Vetti52]

Hi, Gary!
I posted the error above. Here once again:
Mar 24 21:04:59 raspbee weewx[618]: File 
"/usr/share/weewx/user/cputemp.py", line 19, in AddCpuTemp
Mar 24 21:04:59 raspbee weewx[618]:   if 
event.record['usUnits'] == weewx.US:
Mar 24 21:04:59 raspbee weewx[618]:   NameError: name 'event' is 
not defined
Mar 24 21:04:59 raspbee weewx[618]:   Exiting.

so far I can see, python is looking for name 'event', which is not defined. 
However, I think, that this is due to a wrong identation, which happend 
after simply pasting the part of Thomas listing into Mike's cputemp.py 
listing. Althoug this is only a faint idea, as I am not good in python, 
sorry. But, maybe, you see the background and can explain, how to get 
closer to this kind of errors and how to avoid them. 

Thanks anyway!
Peter

Am Donnerstag, 2. April 2020 22:51:40 UTC+2 schrieb gjr80:
>
> Can you post the error you are getting. It should be fairly self evident 
> what the issue is.
>
> 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/0d3cf6b6-7706-41a9-9ab7-114536e72643%40googlegroups.com.

Re: [weewx-user] Re: how to insert additional data (cpu temp) into skins?

[Vetti52]

Hi, Mike!

just replaced your "old" version with this one. And - of course - it works 
without any errors. Thanks a lot.

Am Freitag, 3. April 2020 09:22:24 UTC+2 schrieb Mike Revitt:
>
> Hi Peter,
>
> This is the file I use
>
>
>
> On Thursday, April 2, 2020 at 8:03:04 PM UTC+1, Vetti52 wrote:
>>
>> Hi, Gary!
>>
>> Sorry for the delay, but somehow I was occupied too much by my efforts to 
>> introduce an Unifi Security Gateway into my network. And, well, it is still 
>> under construction. Don't want to loose another hour of data in my Weewx 
>> database.
>>
>> I moved back to the listing of Mike. But just replacing the line 
>>
>> event.record['extraTemp1'] = ( cpu.temperature * 1.8 ) + 32
>>
>> by the solution of Thomas turns the syntax wrong. Although I am an 
>> absolute newbie in python, I know, that wrong indentation could make things 
>> mess up. So I am fine with the listing of Mike. Maybe it is useful to 
>> present a complete listing, easily transferable by copy/paste, for people 
>> like me.
>>
>> Thanks!
>> Peter
>>
>>
>>
>>
>> Am Dienstag, 24. März 2020 22:19:34 UTC+1 schrieb gjr80:
>>>
>>> Hi,
>>>
>>> Most likely cause is that you have entered some code in the wrong place. 
>>> Can you post the entire contents of your /usr/share/weewx/user/cputemp.py ?
>>>
>>> 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/c10cd88d-2803-4c5a-a88f-4fc056bf04e4%40googlegroups.com.

[weewx-user] Re: problems with wee_import from csv

[Astrid]

Hello!

I'm afraid, that my happyness was to early...

Now I have the csv without blanks.
I want now to get back some missing data of a special date
to my weewx-db.

I stopped weewxd, make a copy of sdb, let run:

wee_import --import-config=mycsv.conf --log=log1.log
Starting wee_import...
A CSV import from source file '/var/tmp/data.csv' has been requested.
Using database binding 'wx_binding', which is bound to database 'weewx.sdb'
Destination table 'archive' unit system is '0x01' (US).
Missing derived observations will be calculated.
All WeeWX UV fields will be set to None.
All WeeWX radiation fields will be set to None.
Starting import ...
1439 records identified for import.
Proceeding will save all imported records in the WeeWX archive.
Are you sure you want to proceed (y/n)? y
Records processed: 1439; Unique records: 1439; Last timestamp: 2020-04-01 
23:59:00 CEST (1585778340)
Finished import. 1439 raw records resulted in 1439 unique records being 
processed in 30.68 seconds.
Those records with a timestamp already in the archive will not have been
imported. Confirm successful import in the WeeWX log file.

But if I rerun the reports, the data is still missing in my plots. :(

And where can I find the logging-information?

Regards, Astrid

-- 
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/66243a6f-75bb-4348-9493-ac1afdcc8867%40googlegroups.com.

[weewx-user] Re: problems with wee_import from csv

[Astrid]

Thanx, but no blank line after header has been there.

Regards, Astrid

-- 
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/1e133cf5-3b59-491b-a0bb-ee5973c22d27%40googlegroups.com.

[weewx-user] Re: problems with wee_import from csv

[Astrid]

Hello!

I now can find it out now...
Blanks seems to be forbidden in csv...

With this, it works.

mydatetime,myouttemp,myouthumidity,mydewpoint,mybarometer,mywindspeed,mywindgust,mywinddir,myheatindex
1585692060,33.08,65,22.64,30.330773774365,4.60312,4.60312,315,33.08
1585692120,33.08,65,22.64,30.330773774365,4.60312,4.60312,315,33.08
1585692180,33.08,65,22.64,30.330773774365,4.60312,4.60312,315,33.08
1585692240,33.08,65,22.64,30.330773774365,4.60312,4.60312,315,33.08
1585692300,32.9,65,22.46,30.3337271116361,4.60312,4.60312,315,32.9
1585692360,32.9,65,22.46,30.3337271116361,4.60312,4.60312,315,32.9
1585692420,32.9,65,22.46,30.330773774365,4.60312,4.60312,315,32.9
1585692480,32.9,65,22.46,30.330773774365,4.60312,4.60312,315,32.9

Perhaps you can give a special hint in documentation of wee_import,
that blanks are forbidden?

Regards, Astrid


-- 
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/70320769-177c-4c4e-8b11-93bc503f0a47%40googlegroups.com.

[weewx-user] Re: problems with wee_import from csv

[Andrew Milner]

does your csv file have a blank line after the header line which should be 
deleted?


On Friday, 3 April 2020 17:24:00 UTC+3, Astrid wrote:
>
> Hello!
>
> Thanx. Yes at the dewpoint was a typo, agh to me...
>
> This is my (shorten, but same errormessages for _all_ fields... :( )
>
> mydatetime, myouttemp, myouthumidity, mydewpoint, mybarometer, 
> mywindspeed, mywindgust, mywinddir, myheatindex
> 1585692060, 33.08, 65, 22.64, 30.330773774365, 4.60312, 4.60312, 315, 33.08
> 1585692120, 33.08, 65, 22.64, 30.330773774365, 4.60312, 4.60312, 315, 33.08
> 1585692180, 33.08, 65, 22.64, 30.330773774365, 4.60312, 4.60312, 315, 33.08
> 1585692240, 33.08, 65, 22.64, 30.330773774365, 4.60312, 4.60312, 315, 33.08
> 1585692300, 32.9, 65, 22.46, 30.3337271116361, 4.60312, 4.60312, 315, 32.9
> 1585692360, 32.9, 65, 22.46, 30.3337271116361, 4.60312, 4.60312, 315, 32.9
> 1585692420, 32.9, 65, 22.46, 30.330773774365, 4.60312, 4.60312, 315, 32.9
> 1585692480, 32.9, 65, 22.46, 30.330773774365, 4.60312, 4.60312, 315, 32.9
>
> and this my conf:
>
> # EXAMPLE CONFIGURATION FILE FOR IMPORTING FROM CSV FILES
> #
> # Copyright (c) 2009-2016 Tom Keffer  and Gary 
> Roderick.
> # See the file LICENSE.txt for your rights.
>
>
> ##
>
> # Specify the source. Available options are:
> #   CSV - import obs from a single CSV format file
> #   WU - import obs from a Weather Underground PWS history
> #   Cumulus - import obs from a one or more Cumulus monthly log files
> # Format is:
> #   source = (CSV | WU | Cumulus)
> source = CSV
>
>
> ##
>
> [CSV]
> # Parameters used when importing from a CSV file
>
> # Path and name of our CSV source file. Format is:
> #   file = full path and filename
> file = /var/tmp/data.csv
>
> # If there is no mapped interval field how will the interval field be
> # determined for the imported records. Available options are:
> #   derive - Derive the interval field from the timestamp of successive
> #records. This setting is best used when the imported 
> records
> #are equally spaced in time and there are no missing 
> records.
> #   conf   - Use the interval setting from weewx.conf. This setting is
> #best used if the records to be imported have been 
> produced by
> #WeeWX using the same archive interval as set in 
> weewx.conf on
> #this machine.
> #   x  - Use a fixed interval of x minutes for every record. This
> #setting is best used if the records to be imported are
> #equally based in time but there are some missing records.
> #
> # Note: If there is a mapped interval field then this setting will be
> #   ignored.
> # Format is:
> #   interval = (derive | conf | x)
> interval = derive
>
> # Should the [StdQC] max/min limits in weewx.conf be applied to the
> # imported data. This may be useful if the source has extreme values 
> that
> # are clearly incorrect for some observations. Available options are:
> #   True  - weewx.conf [StdQC] max/min limits are applied.
> #   False - weewx.conf [StdQC] max/min limits are not applied.
> # Format is:
> #   qc = (True | False)
> qc = True
>
> # Should any missing derived observations be calculated from the 
> imported
> # data if possible. Available options are:
> #   True  - Any missing derived observations are calculated.
> #   False - Any missing derived observations are not calculated.
> # Format is:
> #   calc_missing = (True | False)
> calc_missing = True
>
> # Specify how imported data fields that contain invalid data (eg a 
> numeric
> # field containing non-numeric data) are handled. Available options 
> are:
> #   True  - The invalid data is ignored, the WeeWX target field is set 
> to
> #   None and the import continues.
> #   False - The import is halted.
> # Format is:
> #   ignore_invalid_data = (True | False)
> # Default is True.
> ignore_invalid_data = True
>
> # Imported records are written to archive in transactions of tranche
> # records at a time. Increase for faster throughput, decrease to reduce
> # memory requirements. Format is:
> #   tranche = x
> # where x is an integer
> tranche = 250
>
> # Specify whether a UV sensor was used to produce any UV observations.
> # Available options are:
> #   True  - UV sensor was used and UV data will be imported.
> #   False - UV sensor was not used and any UV data will not be 
> imported.
> #   UV fields will be set to None/NULL.
> # For a CSV import UV_sensor should be set to False if a UV sensor was
> # NOT present when the import data was created. Otherwise it may be 
> set to
> # True or omitted. Format 

Re: [weewx-user] Re: Changes with Belchertown skin & DarkSky

[Xant]

Correction: YR.no 48hrs meteogram.

-- 
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/3094dae4-2a5b-4bdc-bd41-347b3cfe3f4d%40googlegroups.com.

Re: [weewx-user] Re: Changes with Belchertown skin & DarkSky

[Xant]

Dark Sky API

William: "That's true if one already has a DarkSky API key"
U... apologies as I missed this important "detail", as to say let's go 
till end-of-2021. Just trying to give all some peace of mind and let the 
industry to settle.
But it is true. DarkSky cutting the cord... let's continue research.


YR.no API

Still have my vote for Belchertown API


   - Not commercially owned (NRK, Norwegian Broadcasting Corporation and 
   Norwegian Meteorological Institute)
   - long time providing Global data (not just Norwegian); many reports US 
   weather data to be accurate
   - metric system data only, but don't see this much of an issue; as 
   posted by Pat, "more work upfront, but the skin can convert units"
   - G Hammer: "A new Yr API is on the way!"; don't expect new Yr API to 
   provide anything other than metric, as its own website doesn't have 
   conversion option either
   - Free... no restrictions, plenty of accurate Global data
   - Pat: "Another appeal for yr.no in my reading is that for yr.no is no 
   API key is needed, no developer account - "it just works".
   - Yr.no let embed in many ways (Java, PHP, XML); even provides nice 
   3days Meteogram (metrics only, 
   though); 
https://www.yr.no/place/United_States/Massachusetts/Belchertown/data.html

[image: Screenshot_2020-04-03 Yr - varsel eksternt.png]


YR no Alerts

Alerts indeed a great feature of DarkSky API, and thanks to Pat for 
providing in Belchertown. Although YR.no provides plenty of wx info, it 
seems indeed that it doesn't provides alerts.
Considering that YR still my pick (besides no alerts), and current lack of 
consolidated API source, proposing a (temporary) hybrid solution as NOAA 
does provides weather alerts for US through API or CAP (CAP is an XML-based 
information standard used to facilitate emergency information sharing and 
data exchange); https://www.weather.gov/documentation/services-web-alerts


Xant

-- 
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/fd432768-c797-4bf4-8311-24d7066168b0%40googlegroups.com.

[weewx-user] Modifying pyephem Date format on Celestial page?

[pbartko]

Longtime weewx user, but just reinstalled weewx 3.9.2 on Raspberry pi due 
to hardware failure on my previous server.  I'm using the Seasons skin and 
installed pyephem.

Everything is working well, but I can not figure out one thing.  How to 
change the date format of the Solstice, Equinox, Full moon and New moon?  
I'm in the US and we always try to be confusing by having things like our 
dates different the the rest of the world.  I'd like the those dates to be 
in MM/DD/ format instead of DD/MM/ format.  I was able to modify 
the report generator and image generator to change the date formats, but 
I'm stumped with the Celestial data from pyephem.

site is here: http://www.boxhillweather.com


Thanks

Pete

-- 
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/4e1f9a72-b163-4293-ae33-9c14c6da7751%40googlegroups.com.

Re: [weewx-user] Changes with Belchertown skin & DarkSky

[Alex Rodriguez]

If we already have an API key with DarkSky, are you thinking we would be able 
to keep DarkSky and switch whenever we want?

Congrats on the baby!

> On Apr 3, 2020, at 11:28 AM, Pat  wrote:
> 
> It's more work upfront but the skin can convert units.
> 
> If weather alerts are gone (which so far looks like they will be when DarkSky 
> goes away), then I am leaning back to yr.no. Another appeal for yr.no in my 
> reading is that for yr.no is no API key is needed, no developer account - "it 
> just works". Just need to put some credits on the about page. 
> 
> 
> On Friday, April 3, 2020 at 11:05:49 AM UTC-4, G Hammer wrote:
> Metric is not used in the US would be the problem.
> 
> 
> On Fri, Apr 3, 2020, 10:37 AM steeple ian > wrote:
> Quote from yr.no  website: -
> 
> "A new Yr API is on the way!
> 
> We are working on a new and modern API, that we plan to release some time in 
> the winter 2019. Make sure you visit this site to keep posted!"
> 
> I am not sure why metric only is so much of a problem anyway, but maybe that 
> will be fixed in the new API anyway.
> 
> From a personal point of view, I use forecasting services from YR DarkSky, 
> WU, and UK Metoffice. I know it can be subjective but for my location YR is 
> by far the most accurate.
> 
> Ian
> 
> 
> On Fri, Apr 3, 2020 at 3:17 PM Pat > wrote:
> yr.no  isn't commercially owned, so the theory is they won't 
> get bought out or go away. They're owned by the Norwegian Broadcasting 
> Corporation and the Norwegian Meteorological Institute. That said, it's only 
> in metric, does not have weather alerts and is in XML format only. 
> 
> The pro is that they don't seem at risk of being purchased and going away. 
> The con is it may not be a good fit for how the skin is being used. 
> 
> 
> On Friday, April 3, 2020 at 10:01:39 AM UTC-4, G Hammer wrote:
> I'd say OWM, simply because I see no way to get anything except metric/C from 
> yr.no 
> 
> On Thursday, April 2, 2020 at 9:11:43 PM UTC-4, Pat wrote:
> I'm sure the Belchertown skin could benefit from the forecasts plugin, but 
> Belchertown does more than that. It shows weather alerts for your location as 
> well as current conditions. The forecasting plugin doesn't provide those 2 
> bits. For that you need a service, and if you're getting info from the 
> service (in my opinion), one stop shop for it (get the forecast too). 
> 
> As for maintaining a plugin base for each region/location, that's not 
> something I can develop or support right now. The JSON would have to be 
> formatted exactly for each service in order to support the current way of 
> updates. Again, this is a simple task for 1 provider who has all this data 
> for worldwide regions
> 
> I understand that OWM could become the next DarkSky but I think it's the best 
> option for what we have right now. The free tier should be able to provide 
> enough data to replace DarkSky. 
> 
> It's just a matter of time on my end.
> 
> 
> On Thursday, April 2, 2020 at 6:38:28 PM UTC-4, William Burton wrote:
> Hello,
> 
> On Thursday, April 2, 2020 at 4:34:46 PM UTC-4, Wes Witt wrote:
> how about implementing a design that allows for weather forecast 
> extensions/plugins. then regional plugins can be built and allow the user to 
> choose the weather forecast service that is best for them. this way you don't 
> need a single service that works for everyone. it can be very difficult to 
> find a service that works everywhere and if you can find one it may result in 
> a low bar terms of quality and features from the service.
> 
> I was thinking the exact same thing as it doesn't make sense for every skin 
> author to have to implement forecasting from scratch. There are many API's 
> and there won't be one that works for everyone everywhere.
> 
> The weewx-forecast extension (https://github.com/matthewwall/weewx-forecast 
> ), already handles the 
> following weather forecasting services:
> 
>   US National Weather Service (NWS)
>   the weather underground (WU)
>   open weathermap (OWM)
>   UK Met Office (UKMO)
>   Aeris Weather
>   World Weather Online (WWO)
>   Dark Sky (DS)
>   Zambretti
> 
> The extension also handles tide predictions using xtide.
> 
> My thought was to enhance the weewx-forecast extension to:
> Output a generic JSON file that can be loaded via Ajax into a theme. As much 
> as possible, the JSON would be generated in a manner that's consistent across 
> different API implementations to make it easier to incorporate into a skin.
> Output one or more include files that can be included into other skins.
> Skins like Belchertown can incorporate this output using either method as 
> appropriate. The end result is it would be far easier for skin maintainers to 
> expand forecasting options.
> 
> The benefit to this approach is the ability to support many more options for 
> forecasting more widely. However, a small drawback is users of 

Re: [weewx-user] Re: Changes with Belchertown skin & DarkSky

[steeple ian]

Gary,

Ok have a look here: -

https://claydonsweather.org.uk

The base units are set in weewx.conf to METRICWX. The json data from WU is
coming as US, DarkSky as METRIC. The skin is displaying U.K. units which is
Metric with mph. Click on the F button too right and watch what happens to
the units including those of the forecasts. Go to the menu accessed by
clicking top left. You will see toggles for various unit systems. The data
does not change, it is just converted on the fly. So I don’t see units
being an issue.
Ian

On Fri, 3 Apr 2020 at 16:05, G Hammer  wrote:

> Metric is not used in the US would be the problem.
>
>
> On Fri, Apr 3, 2020, 10:37 AM steeple ian  wrote:
>
>> Quote from yr.no website: -
>>
>> *"A new Yr API is on the way!*
>>
>> We are working on a new and modern API, that we plan to release some time
>> in the winter 2019. Make sure you visit this site to keep posted!"
>>
>> I am not sure why metric only is so much of a problem anyway, but maybe
>> that will be fixed in the new API anyway.
>>
>> From a personal point of view, I use forecasting services from YR
>> DarkSky, WU, and UK Metoffice. I know it can be subjective but for my
>> location YR is by far the most accurate.
>>
>> Ian
>>
>> On Fri, Apr 3, 2020 at 3:17 PM Pat  wrote:
>>
>>> yr.no isn't commercially owned, so the theory is they won't get bought
>>> out or go away. They're owned by the Norwegian Broadcasting Corporation
>>> and the Norwegian Meteorological Institute. That said, it's only in
>>> metric, does not have weather alerts and is in XML format only.
>>>
>>> The pro is that they don't seem at risk of being purchased and going
>>> away. The con is it may not be a good fit for how the skin is being used.
>>>
>>>
>>> On Friday, April 3, 2020 at 10:01:39 AM UTC-4, G Hammer wrote:

 I'd say OWM, simply because I see no way to get anything except
 metric/C from yr.no

 On Thursday, April 2, 2020 at 9:11:43 PM UTC-4, Pat wrote:
>
> I'm sure the Belchertown skin could benefit from the forecasts plugin,
> but Belchertown does more than that. It shows weather alerts for your
> location as well as current conditions. The forecasting plugin doesn't
> provide those 2 bits. For that you need a service, and if you're getting
> info from the service (in my opinion), one stop shop for it (get the
> forecast too).
>
> As for maintaining a plugin base for each region/location, that's not
> something I can develop or support right now. The JSON would have to be
> formatted exactly for each service in order to support the current way of
> updates. Again, this is a simple task for 1 provider who has all this data
> for worldwide regions
>
> I understand that OWM could become the next DarkSky but I think it's
> the best option for what we have right now. The free tier should be able 
> to
> provide enough data to replace DarkSky.
>
> It's just a matter of time on my end.
>
>
> On Thursday, April 2, 2020 at 6:38:28 PM UTC-4, William Burton wrote:
>>
>> Hello,
>>
>> On Thursday, April 2, 2020 at 4:34:46 PM UTC-4, Wes Witt wrote:
>>>
>>> how about implementing a design that allows for weather forecast
>>> extensions/plugins. then regional plugins can be built and allow the 
>>> user
>>> to choose the weather forecast service that is best for them. this way 
>>> you
>>> don't need a single service that works for everyone. it can be very
>>> difficult to find a service that works everywhere and if you can find 
>>> one
>>> it may result in a low bar terms of quality and features from the 
>>> service.
>>>
>>
>> I was thinking the exact same thing as it doesn't make sense for
>> every skin author to have to implement forecasting from scratch. There 
>> are
>> many API's and there won't be one that works for everyone everywhere.
>>
>> The weewx-forecast extension (
>> https://github.com/matthewwall/weewx-forecast), already handles the
>> following weather forecasting services:
>>
>>   US National Weather Service (NWS)
>>   the weather underground (WU)
>>   open weathermap (OWM)
>>   UK Met Office (UKMO)
>>   Aeris Weather
>>   World Weather Online (WWO)
>>   Dark Sky (DS)
>>   Zambretti
>>
>> The extension also handles tide predictions using xtide.
>>
>>
>> My thought was to enhance the weewx-forecast extension to:
>>
>>
>>- Output a generic JSON file that can be loaded via Ajax into a 
>> theme. As much as possible, the JSON would be generated in a manner 
>> that's consistent across different API implementations to make it easier 
>> to incorporate into a skin.
>>- Output one or more include files that can be included into other 
>> skins.
>>
>> Skins like Belchertown can incorporate this output using either method 
>> as 

Re: [weewx-user] Re: Changes with Belchertown skin & DarkSky

[Pat]

It's more work upfront but the skin can convert units.

If weather alerts are gone (which so far looks like they will be when 
DarkSky goes away), then I am leaning back to yr.no. Another appeal for 
yr.no in my reading is that for yr.no is no API key is needed, no developer 
account - "it just works". Just need to put some credits on the about page. 


On Friday, April 3, 2020 at 11:05:49 AM UTC-4, G Hammer wrote:
>
> Metric is not used in the US would be the problem.
>
>
> On Fri, Apr 3, 2020, 10:37 AM steeple ian  > wrote:
>
>> Quote from yr.no website: -
>>
>> *"A new Yr API is on the way!* 
>>
>> We are working on a new and modern API, that we plan to release some time 
>> in the winter 2019. Make sure you visit this site to keep posted!"
>>
>> I am not sure why metric only is so much of a problem anyway, but maybe 
>> that will be fixed in the new API anyway.
>>
>> From a personal point of view, I use forecasting services from YR 
>> DarkSky, WU, and UK Metoffice. I know it can be subjective but for my 
>> location YR is by far the most accurate.
>>
>> Ian
>>
>> On Fri, Apr 3, 2020 at 3:17 PM Pat > 
>> wrote:
>>
>>> yr.no isn't commercially owned, so the theory is they won't get bought 
>>> out or go away. They're owned by the Norwegian Broadcasting Corporation 
>>> and the Norwegian Meteorological Institute. That said, it's only in 
>>> metric, does not have weather alerts and is in XML format only. 
>>>
>>> The pro is that they don't seem at risk of being purchased and going 
>>> away. The con is it may not be a good fit for how the skin is being used. 
>>>
>>>
>>> On Friday, April 3, 2020 at 10:01:39 AM UTC-4, G Hammer wrote:

 I'd say OWM, simply because I see no way to get anything except 
 metric/C from yr.no

 On Thursday, April 2, 2020 at 9:11:43 PM UTC-4, Pat wrote:
>
> I'm sure the Belchertown skin could benefit from the forecasts plugin, 
> but Belchertown does more than that. It shows weather alerts for your 
> location as well as current conditions. The forecasting plugin doesn't 
> provide those 2 bits. For that you need a service, and if you're getting 
> info from the service (in my opinion), one stop shop for it (get the 
> forecast too). 
>
> As for maintaining a plugin base for each region/location, that's not 
> something I can develop or support right now. The JSON would have to be 
> formatted exactly for each service in order to support the current way of 
> updates. Again, this is a simple task for 1 provider who has all this 
> data 
> for worldwide regions
>
> I understand that OWM could become the next DarkSky but I think it's 
> the best option for what we have right now. The free tier should be able 
> to 
> provide enough data to replace DarkSky. 
>
> It's just a matter of time on my end.
>
>
> On Thursday, April 2, 2020 at 6:38:28 PM UTC-4, William Burton wrote:
>>
>> Hello,
>>
>> On Thursday, April 2, 2020 at 4:34:46 PM UTC-4, Wes Witt wrote:
>>>
>>> how about implementing a design that allows for weather forecast 
>>> extensions/plugins. then regional plugins can be built and allow the 
>>> user 
>>> to choose the weather forecast service that is best for them. this way 
>>> you 
>>> don't need a single service that works for everyone. it can be very 
>>> difficult to find a service that works everywhere and if you can find 
>>> one 
>>> it may result in a low bar terms of quality and features from the 
>>> service.
>>>
>>
>> I was thinking the exact same thing as it doesn't make sense for 
>> every skin author to have to implement forecasting from scratch. There 
>> are 
>> many API's and there won't be one that works for everyone everywhere.
>>
>> The weewx-forecast extension (
>> https://github.com/matthewwall/weewx-forecast), already handles the 
>> following weather forecasting services:
>>
>>   US National Weather Service (NWS)
>>   the weather underground (WU)
>>   open weathermap (OWM)
>>   UK Met Office (UKMO)
>>   Aeris Weather
>>   World Weather Online (WWO)
>>   Dark Sky (DS)
>>   Zambretti
>>
>> The extension also handles tide predictions using xtide.
>>
>>
>> My thought was to enhance the weewx-forecast extension to:
>>
>>
>>- Output a generic JSON file that can be loaded via Ajax into a 
>> theme. As much as possible, the JSON would be generated in a manner 
>> that's consistent across different API implementations to make it easier 
>> to incorporate into a skin.
>>- Output one or more include files that can be included into other 
>> skins.
>>
>> Skins like Belchertown can incorporate this output using either method 
>> as appropriate. The end result is it would be far easier for skin 
>> maintainers to expand forecasting 

[weewx-user] Removed an erroneous daily rainfall reading from the database and now its back after reboot

[Muireadach O Connor]

Hi guys,

I'm struggling to understand what I'm doing wrong here.

I want to remove a daily reading of 134mm rain from February 2013 as its 
bothering me in my records page. I had cleaned the rain gauge that day and 
never got around to correcting it.
I'd previously amended a max rainRate figure from the database without too 
much issue so thought this would be the same but its proving much more 
troublesome.

I removed it using :

update archive set rain=NULL where rain > 4; (db in imperial)

Next made a  new copy of this new database

Then..

sudo wee_database --drop-daily
sudo wee_database weewx.conf --rebuild-daily

then ran :

wee_reports --config=/etc/weewx/weewx.conf

However the records webpage on my pi (reports folder) in still showed the 
old value in there.

At this stage I figured maybe its cached in memory so stopped the WeeWX 
service and restarted the raspberry pi

Now the old value is back in the database again (/shakes fist at cloud)
I've looked at my amended copy and the latest one and the old maximum daily 
reading is definitely back and definitely was removed.

I'm guessing this is being pulled from the console somehow, should I have 
cleared it also there also before restarting?
If not, anyone any ideas how to fix this?

-- 
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/b37f6984-4bc0-4e1f-be92-4e8db76be4a2%40googlegroups.com.

Re: [weewx-user] Re: Changes with Belchertown skin & DarkSky

[G Hammer]

Metric is not used in the US would be the problem.


On Fri, Apr 3, 2020, 10:37 AM steeple ian  wrote:

> Quote from yr.no website: -
>
> *"A new Yr API is on the way!*
>
> We are working on a new and modern API, that we plan to release some time
> in the winter 2019. Make sure you visit this site to keep posted!"
>
> I am not sure why metric only is so much of a problem anyway, but maybe
> that will be fixed in the new API anyway.
>
> From a personal point of view, I use forecasting services from YR DarkSky,
> WU, and UK Metoffice. I know it can be subjective but for my location YR is
> by far the most accurate.
>
> Ian
>
> On Fri, Apr 3, 2020 at 3:17 PM Pat  wrote:
>
>> yr.no isn't commercially owned, so the theory is they won't get bought
>> out or go away. They're owned by the Norwegian Broadcasting Corporation
>> and the Norwegian Meteorological Institute. That said, it's only in
>> metric, does not have weather alerts and is in XML format only.
>>
>> The pro is that they don't seem at risk of being purchased and going
>> away. The con is it may not be a good fit for how the skin is being used.
>>
>>
>> On Friday, April 3, 2020 at 10:01:39 AM UTC-4, G Hammer wrote:
>>>
>>> I'd say OWM, simply because I see no way to get anything except metric/C
>>> from yr.no
>>>
>>> On Thursday, April 2, 2020 at 9:11:43 PM UTC-4, Pat wrote:

 I'm sure the Belchertown skin could benefit from the forecasts plugin,
 but Belchertown does more than that. It shows weather alerts for your
 location as well as current conditions. The forecasting plugin doesn't
 provide those 2 bits. For that you need a service, and if you're getting
 info from the service (in my opinion), one stop shop for it (get the
 forecast too).

 As for maintaining a plugin base for each region/location, that's not
 something I can develop or support right now. The JSON would have to be
 formatted exactly for each service in order to support the current way of
 updates. Again, this is a simple task for 1 provider who has all this data
 for worldwide regions

 I understand that OWM could become the next DarkSky but I think it's
 the best option for what we have right now. The free tier should be able to
 provide enough data to replace DarkSky.

 It's just a matter of time on my end.


 On Thursday, April 2, 2020 at 6:38:28 PM UTC-4, William Burton wrote:
>
> Hello,
>
> On Thursday, April 2, 2020 at 4:34:46 PM UTC-4, Wes Witt wrote:
>>
>> how about implementing a design that allows for weather forecast
>> extensions/plugins. then regional plugins can be built and allow the user
>> to choose the weather forecast service that is best for them. this way 
>> you
>> don't need a single service that works for everyone. it can be very
>> difficult to find a service that works everywhere and if you can find one
>> it may result in a low bar terms of quality and features from the 
>> service.
>>
>
> I was thinking the exact same thing as it doesn't make sense for every
> skin author to have to implement forecasting from scratch. There are many
> API's and there won't be one that works for everyone everywhere.
>
> The weewx-forecast extension (
> https://github.com/matthewwall/weewx-forecast), already handles the
> following weather forecasting services:
>
>   US National Weather Service (NWS)
>   the weather underground (WU)
>   open weathermap (OWM)
>   UK Met Office (UKMO)
>   Aeris Weather
>   World Weather Online (WWO)
>   Dark Sky (DS)
>   Zambretti
>
> The extension also handles tide predictions using xtide.
>
>
> My thought was to enhance the weewx-forecast extension to:
>
>
>- Output a generic JSON file that can be loaded via Ajax into a theme. 
> As much as possible, the JSON would be generated in a manner that's 
> consistent across different API implementations to make it easier to 
> incorporate into a skin.
>- Output one or more include files that can be included into other 
> skins.
>
> Skins like Belchertown can incorporate this output using either method as 
> appropriate. The end result is it would be far easier for skin 
> maintainers to expand forecasting options.
>
> The benefit to this approach is the ability to support many more options 
> for forecasting more widely. However, a small drawback is users of WeeWX 
> will have to install another extension and configure it in addition to 
> the selected skin.
>
> -Bill
>
> --
>> 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
>> 

[weewx-user] how to get german letters and fortatting into highcharts?

[Astrid]

Hello!

I am using weewx 3.9.2 and highcharts.
It is working very well. :)

How can I get german letters into week.json.tmpl?

Instead of

"windplot": {"series":
{"windSpeed": {"name": "Windstaerke", "data": $windSpeedWeekjson},
"windGust": {"name": "Boeen", "data": $windGustWeekjson}},
"units": "$unit.label.windSpeed"#slurp

I want to get 

"windplot": {"series":
{"windSpeed": {"name": "Windst*ä*rke", "data": $windSpeedWeekjson},
"windGust": {"name": "B*ö*en", "data": $windGustWeekjson}},
"units": "$unit.label.windSpeed"#slurp

if I write it as above into week.json.tmpl, then week.json will
not be created.

And how can I change in highchartplot the text from "hamburger"-menu,
where now is standing "Chart context menu"?

Some parts I already get changed by putting into plots.js:

var highchartsOptions = Highcharts.setOptions({
  lang: {
loading: 'Lade...',
months: ['Jan', 'Feb', 'Mar', 'Apr', 'Mai', 'Jun', 'Jul', 
'Aug', 'Sep', 'Okt', 'Nov', 'Dez'],
weekdays: ['Mo', 'Di', 'Mi', 'Do', 'Fr', 'Sa', 'So'],
shortMonths: ['Jan', 'Feb', 'Mar', 'Apr', 'Mai', 'Jun', 'Jul', 
'Aug', 'Sep', 'Okt', 'Nov', 'Dez'],
exportButtonTitle: "Exportieren",
printButtonTitle: "Drucken",
rangeSelectorFrom: "von",
rangeSelectorTo: "bis",
rangeSelectorZoom: "Zeitraum",
downloadPNG: 'Download als png',
downloadJPEG: 'Downlaod als jpeg',
downloadPDF: 'Download als pdf',
downloadSVG: 'Download als svg',
resetZoom: "Reset",
resetZoomTitle: "Reset",
thousandsSep: ",",
decimalPoint: '.'
}
  }
);

But there is left in "Chart Context Menu" (this itself):
"View in fullscreen" and "Print chart"

and in the charts, where on the right top corner can be input
the date "from" and the date "to", that in can be done in
german notation dd.mm.?

Regards, Astrid


-- 
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/cb4a0212-33e3-4a5c-a777-bfff7bddf58f%40googlegroups.com.

Re: [weewx-user] Re: Changes with Belchertown skin & DarkSky

[Greg Troxel]

Pat  writes:

> The pro is that they don't seem at risk of being purchased and going away. 
> The con is it may not be a good fit for how the skin is being used. 

Two thoughts:

  The situation seems ripe for someone, outside the weewx project, to
  make an API that fronts for all national APIs, so that this aggregated
  API can be consumed by projects.  Basically a library, to do this work
  once.   Easier suggested than accomplished, and may have terms of
  service problems, so could end up being a library.

  Home Assistant has weather integrations.  Besides getting one's own
  weewx data in via mqtt, there are a number of integrations for various
  providers.  I'm using the NWS one, which suits me because I'm in the
  US and their policies seem good.  But there seem to also be services
  with global data.  HA seems like a good source for inspiration and
  knowledge of how to use APIs.
  Some URLS:
https://www.home-assistant.io/integrations/#weather
https://www.home-assistant.io/integrations/metoffice/
https://www.metoffice.gov.uk/services/data
https://www.home-assistant.io/integrations/met/
https://www.met.no/en/free-meteorological-data

-- 
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/rmiy2rciq73.fsf%40s1.lexort.com.

Re: [weewx-user] Re: Changes with Belchertown skin & DarkSky

[steeple ian]

Quote from yr.no website: -

*"A new Yr API is on the way!*

We are working on a new and modern API, that we plan to release some time
in the winter 2019. Make sure you visit this site to keep posted!"

I am not sure why metric only is so much of a problem anyway, but maybe
that will be fixed in the new API anyway.

>From a personal point of view, I use forecasting services from YR DarkSky,
WU, and UK Metoffice. I know it can be subjective but for my location YR is
by far the most accurate.

Ian

On Fri, Apr 3, 2020 at 3:17 PM Pat  wrote:

> yr.no isn't commercially owned, so the theory is they won't get bought
> out or go away. They're owned by the Norwegian Broadcasting Corporation
> and the Norwegian Meteorological Institute. That said, it's only in
> metric, does not have weather alerts and is in XML format only.
>
> The pro is that they don't seem at risk of being purchased and going away.
> The con is it may not be a good fit for how the skin is being used.
>
>
> On Friday, April 3, 2020 at 10:01:39 AM UTC-4, G Hammer wrote:
>>
>> I'd say OWM, simply because I see no way to get anything except metric/C
>> from yr.no
>>
>> On Thursday, April 2, 2020 at 9:11:43 PM UTC-4, Pat wrote:
>>>
>>> I'm sure the Belchertown skin could benefit from the forecasts plugin,
>>> but Belchertown does more than that. It shows weather alerts for your
>>> location as well as current conditions. The forecasting plugin doesn't
>>> provide those 2 bits. For that you need a service, and if you're getting
>>> info from the service (in my opinion), one stop shop for it (get the
>>> forecast too).
>>>
>>> As for maintaining a plugin base for each region/location, that's not
>>> something I can develop or support right now. The JSON would have to be
>>> formatted exactly for each service in order to support the current way of
>>> updates. Again, this is a simple task for 1 provider who has all this data
>>> for worldwide regions
>>>
>>> I understand that OWM could become the next DarkSky but I think it's the
>>> best option for what we have right now. The free tier should be able to
>>> provide enough data to replace DarkSky.
>>>
>>> It's just a matter of time on my end.
>>>
>>>
>>> On Thursday, April 2, 2020 at 6:38:28 PM UTC-4, William Burton wrote:

 Hello,

 On Thursday, April 2, 2020 at 4:34:46 PM UTC-4, Wes Witt wrote:
>
> how about implementing a design that allows for weather forecast
> extensions/plugins. then regional plugins can be built and allow the user
> to choose the weather forecast service that is best for them. this way you
> don't need a single service that works for everyone. it can be very
> difficult to find a service that works everywhere and if you can find one
> it may result in a low bar terms of quality and features from the service.
>

 I was thinking the exact same thing as it doesn't make sense for every
 skin author to have to implement forecasting from scratch. There are many
 API's and there won't be one that works for everyone everywhere.

 The weewx-forecast extension (
 https://github.com/matthewwall/weewx-forecast), already handles the
 following weather forecasting services:

   US National Weather Service (NWS)
   the weather underground (WU)
   open weathermap (OWM)
   UK Met Office (UKMO)
   Aeris Weather
   World Weather Online (WWO)
   Dark Sky (DS)
   Zambretti

 The extension also handles tide predictions using xtide.


 My thought was to enhance the weewx-forecast extension to:


- Output a generic JSON file that can be loaded via Ajax into a theme. 
 As much as possible, the JSON would be generated in a manner that's 
 consistent across different API implementations to make it easier to 
 incorporate into a skin.
- Output one or more include files that can be included into other 
 skins.

 Skins like Belchertown can incorporate this output using either method as 
 appropriate. The end result is it would be far easier for skin maintainers 
 to expand forecasting options.

 The benefit to this approach is the ability to support many more options 
 for forecasting more widely. However, a small drawback is users of WeeWX 
 will have to install another extension and configure it in addition to the 
 selected skin.

 -Bill

 --
> 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/716c235d-a99c-454c-b31b-276e22b79829%40googlegroups.com
> 
> .
>

-- 
You received this message 

[weewx-user] Re: Changes with Belchertown skin & DarkSky

[Pat]

Actually looks like OWM doesn't provide weather alerts in the same fashion 
as DarkSky. Instead you have to create a trigger, then poll that trigger 
for changes. It's not end-user friendly as it is at DarkSky. 

So I may have to deprecate weather alerts and only offer current conditions 
and forecasts. 


On Friday, April 3, 2020 at 10:17:06 AM UTC-4, Pat wrote:
>
> yr.no isn't commercially owned, so the theory is they won't get bought 
> out or go away. They're owned by the Norwegian Broadcasting Corporation 
> and the Norwegian Meteorological Institute. That said, it's only in 
> metric, does not have weather alerts and is in XML format only. 
>
> The pro is that they don't seem at risk of being purchased and going away. 
> The con is it may not be a good fit for how the skin is being used. 
>
>
> On Friday, April 3, 2020 at 10:01:39 AM UTC-4, G Hammer wrote:
>>
>> I'd say OWM, simply because I see no way to get anything except metric/C 
>> from yr.no
>>
>> On Thursday, April 2, 2020 at 9:11:43 PM UTC-4, Pat wrote:
>>>
>>> I'm sure the Belchertown skin could benefit from the forecasts plugin, 
>>> but Belchertown does more than that. It shows weather alerts for your 
>>> location as well as current conditions. The forecasting plugin doesn't 
>>> provide those 2 bits. For that you need a service, and if you're getting 
>>> info from the service (in my opinion), one stop shop for it (get the 
>>> forecast too). 
>>>
>>> As for maintaining a plugin base for each region/location, that's not 
>>> something I can develop or support right now. The JSON would have to be 
>>> formatted exactly for each service in order to support the current way of 
>>> updates. Again, this is a simple task for 1 provider who has all this data 
>>> for worldwide regions
>>>
>>> I understand that OWM could become the next DarkSky but I think it's the 
>>> best option for what we have right now. The free tier should be able to 
>>> provide enough data to replace DarkSky. 
>>>
>>> It's just a matter of time on my end.
>>>
>>>
>>> On Thursday, April 2, 2020 at 6:38:28 PM UTC-4, William Burton wrote:

 Hello,

 On Thursday, April 2, 2020 at 4:34:46 PM UTC-4, Wes Witt wrote:
>
> how about implementing a design that allows for weather forecast 
> extensions/plugins. then regional plugins can be built and allow the user 
> to choose the weather forecast service that is best for them. this way 
> you 
> don't need a single service that works for everyone. it can be very 
> difficult to find a service that works everywhere and if you can find one 
> it may result in a low bar terms of quality and features from the service.
>

 I was thinking the exact same thing as it doesn't make sense for every 
 skin author to have to implement forecasting from scratch. There are many 
 API's and there won't be one that works for everyone everywhere.

 The weewx-forecast extension (
 https://github.com/matthewwall/weewx-forecast), already handles the 
 following weather forecasting services:

   US National Weather Service (NWS)
   the weather underground (WU)
   open weathermap (OWM)
   UK Met Office (UKMO)
   Aeris Weather
   World Weather Online (WWO)
   Dark Sky (DS)
   Zambretti

 The extension also handles tide predictions using xtide.


 My thought was to enhance the weewx-forecast extension to:


- Output a generic JSON file that can be loaded via Ajax into a theme. 
 As much as possible, the JSON would be generated in a manner that's 
 consistent across different API implementations to make it easier to 
 incorporate into a skin.
- Output one or more include files that can be included into other 
 skins.

 Skins like Belchertown can incorporate this output using either method as 
 appropriate. The end result is it would be far easier for skin maintainers 
 to expand forecasting options.

 The benefit to this approach is the ability to support many more options 
 for forecasting more widely. However, a small drawback is users of WeeWX 
 will have to install another extension and configure it in addition to the 
 selected skin.

 -Bill



-- 
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/b5bd029e-bfdf-46e5-9da2-a8f141a5d4de%40googlegroups.com.

[weewx-user] Re: problems with wee_import from csv

[Astrid]

Hello!

Thanx. Yes at the dewpoint was a typo, agh to me...

This is my (shorten, but same errormessages for _all_ fields... :( )

mydatetime, myouttemp, myouthumidity, mydewpoint, mybarometer, mywindspeed, 
mywindgust, mywinddir, myheatindex
1585692060, 33.08, 65, 22.64, 30.330773774365, 4.60312, 4.60312, 315, 33.08
1585692120, 33.08, 65, 22.64, 30.330773774365, 4.60312, 4.60312, 315, 33.08
1585692180, 33.08, 65, 22.64, 30.330773774365, 4.60312, 4.60312, 315, 33.08
1585692240, 33.08, 65, 22.64, 30.330773774365, 4.60312, 4.60312, 315, 33.08
1585692300, 32.9, 65, 22.46, 30.3337271116361, 4.60312, 4.60312, 315, 32.9
1585692360, 32.9, 65, 22.46, 30.3337271116361, 4.60312, 4.60312, 315, 32.9
1585692420, 32.9, 65, 22.46, 30.330773774365, 4.60312, 4.60312, 315, 32.9
1585692480, 32.9, 65, 22.46, 30.330773774365, 4.60312, 4.60312, 315, 32.9

and this my conf:

# EXAMPLE CONFIGURATION FILE FOR IMPORTING FROM CSV FILES
#
# Copyright (c) 2009-2016 Tom Keffer  and Gary Roderick.
# See the file LICENSE.txt for your rights.

##

# Specify the source. Available options are:
#   CSV - import obs from a single CSV format file
#   WU - import obs from a Weather Underground PWS history
#   Cumulus - import obs from a one or more Cumulus monthly log files
# Format is:
#   source = (CSV | WU | Cumulus)
source = CSV

##

[CSV]
# Parameters used when importing from a CSV file

# Path and name of our CSV source file. Format is:
#   file = full path and filename
file = /var/tmp/data.csv

# If there is no mapped interval field how will the interval field be
# determined for the imported records. Available options are:
#   derive - Derive the interval field from the timestamp of successive
#records. This setting is best used when the imported 
records
#are equally spaced in time and there are no missing 
records.
#   conf   - Use the interval setting from weewx.conf. This setting is
#best used if the records to be imported have been produced 
by
#WeeWX using the same archive interval as set in weewx.conf 
on
#this machine.
#   x  - Use a fixed interval of x minutes for every record. This
#setting is best used if the records to be imported are
#equally based in time but there are some missing records.
#
# Note: If there is a mapped interval field then this setting will be
#   ignored.
# Format is:
#   interval = (derive | conf | x)
interval = derive

# Should the [StdQC] max/min limits in weewx.conf be applied to the
# imported data. This may be useful if the source has extreme values 
that
# are clearly incorrect for some observations. Available options are:
#   True  - weewx.conf [StdQC] max/min limits are applied.
#   False - weewx.conf [StdQC] max/min limits are not applied.
# Format is:
#   qc = (True | False)
qc = True

# Should any missing derived observations be calculated from the 
imported
# data if possible. Available options are:
#   True  - Any missing derived observations are calculated.
#   False - Any missing derived observations are not calculated.
# Format is:
#   calc_missing = (True | False)
calc_missing = True

# Specify how imported data fields that contain invalid data (eg a 
numeric
# field containing non-numeric data) are handled. Available options are:
#   True  - The invalid data is ignored, the WeeWX target field is set 
to
#   None and the import continues.
#   False - The import is halted.
# Format is:
#   ignore_invalid_data = (True | False)
# Default is True.
ignore_invalid_data = True

# Imported records are written to archive in transactions of tranche
# records at a time. Increase for faster throughput, decrease to reduce
# memory requirements. Format is:
#   tranche = x
# where x is an integer
tranche = 250

# Specify whether a UV sensor was used to produce any UV observations.
# Available options are:
#   True  - UV sensor was used and UV data will be imported.
#   False - UV sensor was not used and any UV data will not be imported.
#   UV fields will be set to None/NULL.
# For a CSV import UV_sensor should be set to False if a UV sensor was
# NOT present when the import data was created. Otherwise it may be set 
to
# True or omitted. Format is:
#   UV_sensor = (True | False)
UV_sensor = False

# Specify whether a solar radiation sensor was used to produce any solar
# radiation observations. Available options are:
#   True  - Solar radiation sensor was used and solar radiation data 
will
#   be imported.
#   False - Solar radiation sensor was not used and any solar 

[weewx-user] Re: Changes with Belchertown skin & DarkSky

[Pat]

yr.no isn't commercially owned, so the theory is they won't get bought out 
or go away. They're owned by the Norwegian Broadcasting Corporation and the 
Norwegian Meteorological Institute. That said, it's only in metric, does 
not have weather alerts and is in XML format only. 

The pro is that they don't seem at risk of being purchased and going away. 
The con is it may not be a good fit for how the skin is being used. 


On Friday, April 3, 2020 at 10:01:39 AM UTC-4, G Hammer wrote:
>
> I'd say OWM, simply because I see no way to get anything except metric/C 
> from yr.no
>
> On Thursday, April 2, 2020 at 9:11:43 PM UTC-4, Pat wrote:
>>
>> I'm sure the Belchertown skin could benefit from the forecasts plugin, 
>> but Belchertown does more than that. It shows weather alerts for your 
>> location as well as current conditions. The forecasting plugin doesn't 
>> provide those 2 bits. For that you need a service, and if you're getting 
>> info from the service (in my opinion), one stop shop for it (get the 
>> forecast too). 
>>
>> As for maintaining a plugin base for each region/location, that's not 
>> something I can develop or support right now. The JSON would have to be 
>> formatted exactly for each service in order to support the current way of 
>> updates. Again, this is a simple task for 1 provider who has all this data 
>> for worldwide regions
>>
>> I understand that OWM could become the next DarkSky but I think it's the 
>> best option for what we have right now. The free tier should be able to 
>> provide enough data to replace DarkSky. 
>>
>> It's just a matter of time on my end.
>>
>>
>> On Thursday, April 2, 2020 at 6:38:28 PM UTC-4, William Burton wrote:
>>>
>>> Hello,
>>>
>>> On Thursday, April 2, 2020 at 4:34:46 PM UTC-4, Wes Witt wrote:

 how about implementing a design that allows for weather forecast 
 extensions/plugins. then regional plugins can be built and allow the user 
 to choose the weather forecast service that is best for them. this way you 
 don't need a single service that works for everyone. it can be very 
 difficult to find a service that works everywhere and if you can find one 
 it may result in a low bar terms of quality and features from the service.

>>>
>>> I was thinking the exact same thing as it doesn't make sense for every 
>>> skin author to have to implement forecasting from scratch. There are many 
>>> API's and there won't be one that works for everyone everywhere.
>>>
>>> The weewx-forecast extension (
>>> https://github.com/matthewwall/weewx-forecast), already handles the 
>>> following weather forecasting services:
>>>
>>>   US National Weather Service (NWS)
>>>   the weather underground (WU)
>>>   open weathermap (OWM)
>>>   UK Met Office (UKMO)
>>>   Aeris Weather
>>>   World Weather Online (WWO)
>>>   Dark Sky (DS)
>>>   Zambretti
>>>
>>> The extension also handles tide predictions using xtide.
>>>
>>>
>>> My thought was to enhance the weewx-forecast extension to:
>>>
>>>
>>>- Output a generic JSON file that can be loaded via Ajax into a theme. 
>>> As much as possible, the JSON would be generated in a manner that's 
>>> consistent across different API implementations to make it easier to 
>>> incorporate into a skin.
>>>- Output one or more include files that can be included into other skins.
>>>
>>> Skins like Belchertown can incorporate this output using either method as 
>>> appropriate. The end result is it would be far easier for skin maintainers 
>>> to expand forecasting options.
>>>
>>> The benefit to this approach is the ability to support many more options 
>>> for forecasting more widely. However, a small drawback is users of WeeWX 
>>> will have to install another extension and configure it in addition to the 
>>> selected skin.
>>>
>>> -Bill
>>>
>>>

-- 
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/716c235d-a99c-454c-b31b-276e22b79829%40googlegroups.com.

[weewx-user] Re: Changes with Belchertown skin & DarkSky

[G Hammer]

I'd say OWM, simply because I see no way to get anything except metric/C 
from yr.no

On Thursday, April 2, 2020 at 9:11:43 PM UTC-4, Pat wrote:
>
> I'm sure the Belchertown skin could benefit from the forecasts plugin, but 
> Belchertown does more than that. It shows weather alerts for your location 
> as well as current conditions. The forecasting plugin doesn't provide those 
> 2 bits. For that you need a service, and if you're getting info from the 
> service (in my opinion), one stop shop for it (get the forecast too). 
>
> As for maintaining a plugin base for each region/location, that's not 
> something I can develop or support right now. The JSON would have to be 
> formatted exactly for each service in order to support the current way of 
> updates. Again, this is a simple task for 1 provider who has all this data 
> for worldwide regions
>
> I understand that OWM could become the next DarkSky but I think it's the 
> best option for what we have right now. The free tier should be able to 
> provide enough data to replace DarkSky. 
>
> It's just a matter of time on my end.
>
>
> On Thursday, April 2, 2020 at 6:38:28 PM UTC-4, William Burton wrote:
>>
>> Hello,
>>
>> On Thursday, April 2, 2020 at 4:34:46 PM UTC-4, Wes Witt wrote:
>>>
>>> how about implementing a design that allows for weather forecast 
>>> extensions/plugins. then regional plugins can be built and allow the user 
>>> to choose the weather forecast service that is best for them. this way you 
>>> don't need a single service that works for everyone. it can be very 
>>> difficult to find a service that works everywhere and if you can find one 
>>> it may result in a low bar terms of quality and features from the service.
>>>
>>
>> I was thinking the exact same thing as it doesn't make sense for every 
>> skin author to have to implement forecasting from scratch. There are many 
>> API's and there won't be one that works for everyone everywhere.
>>
>> The weewx-forecast extension (
>> https://github.com/matthewwall/weewx-forecast), already handles the 
>> following weather forecasting services:
>>
>>   US National Weather Service (NWS)
>>   the weather underground (WU)
>>   open weathermap (OWM)
>>   UK Met Office (UKMO)
>>   Aeris Weather
>>   World Weather Online (WWO)
>>   Dark Sky (DS)
>>   Zambretti
>>
>> The extension also handles tide predictions using xtide.
>>
>>
>> My thought was to enhance the weewx-forecast extension to:
>>
>>
>>- Output a generic JSON file that can be loaded via Ajax into a theme. As 
>> much as possible, the JSON would be generated in a manner that's consistent 
>> across different API implementations to make it easier to incorporate into a 
>> skin.
>>- Output one or more include files that can be included into other skins.
>>
>> Skins like Belchertown can incorporate this output using either method as 
>> appropriate. The end result is it would be far easier for skin maintainers 
>> to expand forecasting options.
>>
>> The benefit to this approach is the ability to support many more options for 
>> forecasting more widely. However, a small drawback is users of WeeWX will 
>> have to install another extension and configure it in addition to the 
>> selected skin.
>>
>> -Bill
>>
>>

-- 
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/2cc9aa30-5803-46db-b3cd-157988b575ab%40googlegroups.com.

[weewx-user] problems with wee_import from csv

[gjr80]

Hi,

You need to double check the field names in the first line of your data file 
against the import field names in the field map in your import config file. 
They must match exactly. In your data file you have ‘mydewpoint’ but in your 
field map you have ‘mydewPoint’. Make sure you check the other two problem 
fields. If you cannot find the problem please post a copy of your data file and 
import config file.

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/a90c7e8f-9383-4319-83ad-846349339431%40googlegroups.com.

[weewx-user] problems with wee_import from csv

[Astrid]

Hello!

I am using weewx 3.9.2 and set
it up a few weeks ago.
Now all is working very well, but some
strugling in between.

So I now want to fill some missing values
in the weewx-db with getting it from a csv-file.

This are the first lines of /var/tmp/data.csv

mydateTime, myoutTemp, myoutHumidity, mydewpoint, mybarometer, mywindSpeed, 
mywindGust, mywindDir, myheatindex
1585692060, 33.08, 65, 22.64, 30.330773774365, 4.60312, 4.60312, 315, 33.08
1585692120, 33.08, 65, 22.64, 30.330773774365, 4.60312, 4.60312, 315, 33.08
1585692180, 33.08, 65, 22.64, 30.330773774365, 4.60312, 4.60312, 315, 33.08
1585692240, 33.08, 65, 22.64, 30.330773774365, 4.60312, 4.60312, 315, 33.08

I stop weewx-daemon and then:

wee_import --import-config=mycsv.conf --dry-run --log=-

But it does not work and I do not know, why? :(

This appears for all fields:

wee_import --import-config=mycsv.conf --dry-run --log=-
Starting wee_import...
A CSV import from source file '/var/tmp/data.csv' has been requested.
Using database binding 'wx_binding', which is bound to database 'weewx.sdb'
Destination table 'archive' unit system is '0x01' (US).
Missing derived observations will be calculated.
All WeeWX UV fields will be set to None.
All WeeWX radiation fields will be set to None.
This is a dry run, imported data will not be saved to archive.
Warning: Import field 'myheatindex' is mapped to WeeWX field 'heatindex'
 but the import field could not be found.
 WeeWX field 'heatindex' will be set to 'None'.
Warning: Import field 'mybarometer' is mapped to WeeWX field 'barometer'
 but the import field could not be found.
 WeeWX field 'barometer' will be set to 'None'.
Warning: Import field 'mydewPoint' is mapped to WeeWX field 'dewpoint'
 but the import field could not be found.

In my conf I give such line as:

[[FieldMap]]
dateTime= mydateTime, unix_epoch
usUnits =
interval=
barometer   = mybarometer, inHg
pressure=
altimeter   =
inTemp  =
outTemp = myoutTemp, degree_F
inHumidity  =
outHumidity = myoutHumidity, percent
windSpeed   = mywindSpeed, mile_per_hour
windDir = mywindDir, degree_compass
windGust= mywindGust, mile_per_hour
windGustDir = 
rainRate= 
rain= 
dewpoint= mydewPoint, degree_F
windchill   =
heatindex   = myheatindex, degree_F
ET  =
radiation   =
UV  =

How I can get it work?

Regards, Astrid

-- 
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/24cf92f2-0c6c-4ce3-98f0-8832c12da2a4%40googlegroups.com.

[weewx-user] Re: how to get run highcharts with weewx?

[Astrid]

Hello!

Thanx, I do not understand this too..
But no matter longer more, now I know, that
I have to look at http://www and not in /var/www.

Thank you very much.

Regards, Astrid

-- 
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/afbb85bd-254f-426f-9c71-dc179085f795%40googlegroups.com.

[weewx-user] Wlink HTTP Error 403: Forbidden

[Joel Öhman]

Hello!

I have been trying to get weewx running with wlink on my raspberry Pi 3 and 
collect the data from my Vantage 2 pro plus.
I have done a setup.py installation and i have done the weewx and wlink 
installation according to the instructions.
My problem is that i only get the wlink reading once an hour, the loop data 
does not work.

tail -f /var/log/syslog
Apr  3 10:41:50 raspberrypi systemd[1]: Stopping LSB: weewx weather 
system...
Apr  3 10:41:50 raspberrypi weewx[3060]: engine: Received signal TERM (15).
Apr  3 10:41:50 raspberrypi weewx[3060]: engine: Main loop exiting. 
Shutting engine down.
Apr  3 10:41:50 raspberrypi weewx[3060]: engine: Shutting down StdReport 
thread
Apr  3 10:41:50 raspberrypi weewx[3060]: engine: StdReport thread has been 
terminated
Apr  3 10:41:50 raspberrypi weewx[3060]: engine: Terminating weewx version 
3.9.2
Apr  3 10:41:50 raspberrypi weewx[3060]:   Traceback (most recent 
call last):
Apr  3 10:41:50 raspberrypi weewx[3060]: File 
"/home/weewx/bin/weewx/engine.py", line 894, in main
Apr  3 10:41:50 raspberrypi weewx[3060]:   engine.run()
Apr  3 10:41:50 raspberrypi weewx[3060]: File 
"/home/weewx/bin/weewx/engine.py", line 188, in run
Apr  3 10:41:50 raspberrypi weewx[3060]:   for packet in 
self.console.genLoopPackets():
Apr  3 10:41:50 raspberrypi weewx[3060]: File 
"/home/weewx/bin/user/wlink.py", line 141, in genLoopPackets
Apr  3 10:41:50 raspberrypi weewx[3060]:   
"?view=main=0=2" % self.username)
Apr  3 10:41:50 raspberrypi weewx[3060]: File 
"/home/weewx/bin/user/wlink.py", line 184, in get_data
Apr  3 10:41:50 raspberrypi weewx[3060]:   
time.sleep(self.retry_wait)
Apr  3 10:41:50 raspberrypi weewx[3060]: File 
"/home/weewx/bin/weewx/engine.py", line 812, in sigTERMhandler
Apr  3 10:41:50 raspberrypi weewx[3060]:   raise Terminate
Apr  3 10:41:50 raspberrypi weewx[3060]:   Terminate
Apr  3 10:41:56 raspberrypi weewx[3997]: Stopping weewx weather system: 
weewx..
Apr  3 10:41:56 raspberrypi systemd[1]: Stopped LSB: weewx weather system.
Apr  3 10:41:56 raspberrypi systemd[1]: Starting LSB: weewx weather 
system...
Apr  3 10:41:56 raspberrypi weewx[4040]: engine: Initializing weewx version 
3.9.2
Apr  3 10:41:56 raspberrypi weewx[4040]: engine: Using Python 2.7.13 
(default, Nov 24 2017, 17:33:09) #012[GCC 6.3.0 20170516]
Apr  3 10:41:56 raspberrypi weewx[4040]: engine: Platform 
Linux-4.9.80-v7+-armv7l-with-debian-9.3
Apr  3 10:41:56 raspberrypi weewx[4040]: engine: Locale is 'fi_FI.UTF-8'
Apr  3 10:41:56 raspberrypi weewx[4040]: engine: pid file is 
/var/run/weewx.pid
Apr  3 10:41:56 raspberrypi weewx[4028]: Starting weewx weather system: 
weewx.
Apr  3 10:41:56 raspberrypi systemd[1]: Started LSB: weewx weather system.
Apr  3 10:41:56 raspberrypi weewx[4044]: engine: Using configuration file 
/home/weewx/weewx.conf
Apr  3 10:41:56 raspberrypi weewx[4044]: engine: Debug is 1
Apr  3 10:41:56 raspberrypi weewx[4044]: engine: Initializing engine
Apr  3 10:41:56 raspberrypi weewx[4044]: engine: Loading station type 
WeatherLink (user.wlink)
Apr  3 10:41:56 raspberrypi weewx[4044]: wlink: version is 0.14
Apr  3 10:41:56 raspberrypi weewx[4044]: wlink: expecting HTML format 'B'
Apr  3 10:41:56 raspberrypi weewx[4044]: wlink: polling interval is 60.0
Apr  3 10:41:56 raspberrypi weewx[4044]: wlink: rain bucket type is 1 (0.2 
mm)
Apr  3 10:41:56 raspberrypi weewx[4044]: engine: Loading service 
weewx.engine.StdTimeSynch
Apr  3 10:41:56 raspberrypi weewx[4044]: engine: Finished loading service 
weewx.engine.StdTimeSynch
Apr  3 10:41:56 raspberrypi weewx[4044]: engine: Loading service 
weewx.engine.StdConvert
Apr  3 10:41:56 raspberrypi weewx[4044]: engine: StdConvert target unit is 
0x1
Apr  3 10:41:56 raspberrypi weewx[4044]: engine: Finished loading service 
weewx.engine.StdConvert
Apr  3 10:41:56 raspberrypi weewx[4044]: engine: Loading service 
weewx.engine.StdCalibrate
Apr  3 10:41:57 raspberrypi weewx[4044]: engine: Finished loading service 
weewx.engine.StdCalibrate
Apr  3 10:41:57 raspberrypi weewx[4044]: engine: Loading service 
weewx.engine.StdQC
Apr  3 10:41:57 raspberrypi weewx[4044]: engine: Finished loading service 
weewx.engine.StdQC
Apr  3 10:41:57 raspberrypi weewx[4044]: engine: Loading service 
weewx.wxservices.StdWXCalculate
Apr  3 10:41:57 raspberrypi weewx[4044]: wxcalculate: The following values 
will be calculated: barometer=prefer_hardware, windchill=prefer_hardware, 
dewpoint=prefer_hardware, appTemp=prefer_hardware, 
rainRate=prefer_hardware, windrun=prefer_hardware, 
heatindex=prefer_hardware, maxSolarRad=prefer_hardware, 
humidex=prefer_hardware, pressure=prefer_hardware, 
inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, 
cloudbase=prefer_hardware
Apr  3 10:41:57 raspberrypi weewx[4044]: wxcalculate: The following 
algorithms will be used for calculations: altimeter=aaNOAA, 

[weewx-user] Re: how to insert additional data (cpu temp) into skins?

[Mike Revitt]

Don't know the ZigBee gateway and hard to tell from the pictures what it 
needs.

But the Flicr case is very similar to most cases, but with the Flicr the 
case is the heat sink, so instead of attaching the standard heat sink to 
the CPU module you attach the case via a rectangular extrusion that matches 
the size of the CPU and goes vertically to the top of the case.

Unfortunately I can't send photos or anything as mine is assembled and the 
downsize is I can't get to the mother board now as it is attached to the 
lid. which is an obvious drawback if you want to be able to plug things in 
etc. I guess that as long as you have a supply of double sided thermal tape 
you could remove the case and reattach it when required though.

On Thursday, April 2, 2020 at 7:49:30 PM UTC+1, Vetti52 wrote:
>
> Looks pretty nice, Mike!
>
> do you know, if there is enough room inside the flirc case for a hat 
> module? My RPi4 also serves as a ZigBee gateway. The zigbee thing is a hat 
> mounted module board. All of the RPi4 cooling cases, I tried, do not have 
> enough space for this HAT board. 
>
> BTW, after using your solution, the CPU temp is monitored at 54 °C. It was 
> at ybut 60 °C, but is lower since the latest kernel update. In comparison 
> to the output of "cat /sys/class/thermal/thermal_zone0/temp", the values 
> vary less then 2 degrees, but they almost always vary. Maybe an academic 
> question...
>
> Thanks so far!
>
> Peter
>
> Am Samstag, 28. März 2020 15:46:21 UTC+1 schrieb Mike Revitt:
>>
>> Can't find the CPU frequency code, but while I am looking I thought you 
>> might find this interesting, this is the CPU temperature graph from my 
>> Raspberry Pi.
>>
>> On the left is the temperature from the standard case, on the right is 
>> the temperature after I get a Flirc case, This case not only looks really 
>> cool but my Raspberry Pi now runs 20 degrees cooler. I am using a Raspberry 
>> Pi 4 by the way which runs 10 degrees hotter than my 3+.
>>
>> https://flirc.tv/more/raspberry-pi-4-case for product data
>>
>> https://www.amazon.co.uk/gp/product/B07WG4DW52/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8=1
>>  
>> if you want to buy one in the UK
>>
>>
>> [image: daytemp.png]
>>
>>
>> On Thursday, March 26, 2020 at 5:45:52 PM UTC, Meteo Oberwallis wrote:
>>>
>>> Am Donnerstag, 26. März 2020 17:42:14 UTC+1 schrieb Mike Revitt: 
>>> > O have worked out how to get the CPU frequency which sort of helps, 
>>> but would need to look into this 
>>> > 
>>> > On Thursday, March 26, 2020 at 4:09:05 PM UTC, Meteo Oberwallis 
>>> wrote:Hello. 
>>> > Is it also possible to read out the CPU load from the Raspberry and 
>>> write it to the database? 
>>>
>>> Sounds good ;-) 
>>
>>

-- 
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/c03a1796-4dc9-43df-a4f1-7b2d42531d33%40googlegroups.com.

[weewx-user] Re: Changes with Belchertown skin & DarkSky

[William Burton]

Hello,

On Thursday, April 2, 2020 at 9:52:14 PM UTC-4, Xant wrote:
>
>
> I always honor Tom, Pat and Matthew Wall time and work towards WeeWX 
> endeavour.
>

Agreed!


> DarkSky has been a good resource and nice graphics. Now sold ("Good for 
> them, Bad for everybody else").
>
> There are alternatives. And as Pat correctly pointed out, the 
> "replacement" needs to be of Global perspective (I guess this eliminates 
> some of the obvious "gov" choices).
>
>- OpenWeather: a good possible alternative, but besides the catchy 
>name, is not much that "open" (and charge for some); it might suffice for 
>usual WeeWX applications, but it makes me uncomfortable to have 
> constraints 
>regarding data access, and future developments (
>https://openweathermap.org/price)
>- YR.no: considering Global perspective, still my pick... completely 
>free, excellent service and reliable
>
> As far as supporting yr.no, if you look on the contributors page at 
https://hjelp.yr.no/hc/en-us/articles/206550249, they are almost entirely 
Norwegian weather sources. So for anyone running WeeWX in Norway, I'm sure 
this would be welcomed. So how does yr.no have a global perspective?
 

> But an extra note... let's NOT get too crazy about this right now... the 
> DarkSky API still goes aaalll the way towards end-of-2021. We ALL have MUCH 
> to think nowadays other than this (quarantine and all).
>

That's true if one already has an API key, but for anyone who plans to 
bring a site online and doesn't already have an API key, forecasting would 
have to be disabled in the skin.  


> Pat said: "Maybe it's a good thing I haven't released 1.1 yet!". 
>
> If changing API is easily done (and you really really bored at home), then 
> do it.
>
> Otherwise... Pat, you have a newborn, and the whole World (literally) at 
> stand still. Nobody (I mean nobody) now have a current "plan", and all is 
> on hold. End-of-2021 seems really really far considering WeeWX, 
> Belchertown and API perspective.
>
> Let's move-on for now get some peace-of-mind and release 1.1 (as is 
> with current API), and let's talk back again on this sometime in 2021!
>

Agreed. The only thing before releasing 1.1 is to do some more testing with 
forecasting disabled in both light and dark modes.

-Bill


> ClearSkies!
> Xant
>

-- 
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/22a6f849-f4ad-4d40-8455-92d2402c8372%40googlegroups.com.

Re: [weewx-user] Re: how to insert additional data (cpu temp) into skins?

[Mike Revitt]

Hi Peter,

This is the file I use



On Thursday, April 2, 2020 at 8:03:04 PM UTC+1, Vetti52 wrote:
>
> Hi, Gary!
>
> Sorry for the delay, but somehow I was occupied too much by my efforts to 
> introduce an Unifi Security Gateway into my network. And, well, it is still 
> under construction. Don't want to loose another hour of data in my Weewx 
> database.
>
> I moved back to the listing of Mike. But just replacing the line 
>
> event.record['extraTemp1'] = ( cpu.temperature * 1.8 ) + 32
>
> by the solution of Thomas turns the syntax wrong. Although I am an 
> absolute newbie in python, I know, that wrong indentation could make things 
> mess up. So I am fine with the listing of Mike. Maybe it is useful to 
> present a complete listing, easily transferable by copy/paste, for people 
> like me.
>
> Thanks!
> Peter
>
>
>
>
> Am Dienstag, 24. März 2020 22:19:34 UTC+1 schrieb gjr80:
>>
>> Hi,
>>
>> Most likely cause is that you have entered some code in the wrong place. 
>> Can you post the entire contents of your /usr/share/weewx/user/cputemp.py ?
>>
>> 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/b2edd6fb-5f48-4815-a6b7-4c489de464f6%40googlegroups.com.
#Copyright (c) 2009-2020 Mike Revitt 
#See the file LICENSE.txt for your rights.
"""Gets the CPU temperature on a Rasberry Pi"""

import  weewx
fromweewx.engineimport  StdService
fromgpiozeroimport  CPUTemperature

class AddCpuTemp(StdService):

def __init__(self, engine, config_dict):

  # Initialize my superclass first:
  super(AddCpuTemp, self).__init__(engine, config_dict)

  # Bind to any new archive record events:
  self.bind(weewx.NEW_ARCHIVE_RECORD, self.new_archive_record)

def new_archive_record(self, event):

cpu = CPUTemperature()

if event.record['usUnits'] == weewx.US:
event.record['extraTemp1'] = ( cpu.temperature * 1.8 ) + 32
else:
event.record['extraTemp1'] = cpu.temperature

[weewx-user] Re: Changes with Belchertown skin & DarkSky

[Mike Revitt]

Spotted the same news and I have found a few, but they are all based on 
Dark Sky. I think we are going to have to wait for the industry to settle 
down a bit first :-(

The best I have found so far is https://weatherwidget.io 


On Tuesday, March 31, 2020 at 7:03:49 PM UTC+1, Pat wrote:
>
> Hi everyone, I'm a bit tied up and offline with the birth of my new 
> daughter, but I got news today that DarkSky has been acquired by Apple. For 
> existing API users, API will remain online until 2021, but they are not 
> accepting any new sign ups. 
>
> That's the sad reality of using free hosted services - they can be shut 
> down without a moments notice. 
>
> I'll research a new method for local conditions and forecasts. If anyone 
> knows of any that are free and has a public API, please let me know! 
>
> ( Maybe it's a good thing I haven't released 1.1 yet! ) 
>

-- 
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/04ed9a50-6a93-450b-b9e3-b8ccb3ab3b2c%40googlegroups.com.