[weewx-user] Re: Web Server auf dem Raspberry Apache2

[gjr80]

I suspect the additional spaces are artefacts of translating the original 
text in-page. The original text when viewed in a browser or via the email 
notification doesn't show spaces (well not for me).

In any case I suspect the issue is one of paths. The cp command was issued 
from the /home/pi directory and command as issued will try to copy 
/home/pi/util/apache/conf.d/weewx.conf which of course does not exist. You 
will find util/apache/conf.d/weewx.conf is in /home/weewx if installed via 
setup.py. It's a bit more complicated if you installed via deb or rpm, 
there is no util directory but you will find the contents of the util 
directory in /etc/weewx. So you can either change directories or include a 
full path in the cp command as follows:

$ sudo cp /home/weewx/util/apache/conf.d/weewx.conf /etc/apache2/conf.d

for a setup.py install or 

$ sudo cp /etc/weewx/apache/conf.d/weewx.conf /etc/apache2/conf.d

for a deb/rpm install.

Gary

On Wednesday, 29 May 2019 04:30:08 UTC+10, vince wrote:
>
> On Tuesday, May 28, 2019 at 11:16:15 AM UTC-7, Günther Wrana wrote:
>
>> Was habe ich falsch eingegeben oder was muss ich noch tun? 
>>
>
> You have extra space characters in your command.
>
> Try:
> sudo cp util/apache/conf.d/weewx.conf /etc/apache2/conf.d
>
>
>

-- 
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/84e0a4e7-56e4-49cc-91ea-ef3517239a2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: BloomSky SKY2+STORM - No Pressure?

[gjr80]

My apologies, committed the fix but never came back to issue the release. 
Fixed now in release 0.1.1 
.

Gary

On Monday, 27 May 2019 20:17:56 UTC+10, Rick Hewett wrote:
>
> I think I found what was missing. The release of the BloomSky driver I 
> was using came from: 
>
>
> https://github.com/gjr80/weewx-bloomsky/releases/download/v0.1.0/bloomsky-0.1.0.tar.gz
>  
>
> However, the git repository contains a more up-to-date driver that 
> doesn't seem to have made it into the release yet. Getting the latest 
> copy of bloomsky.py from https://github.com/gjr80/weewx-bloomsky and 
> installing it manually has cured the problem. 
>
> On Mon 27 May Rick M0LEP wrote: 
> > I've recently switched my system over to getting data from a BloomSky 
> > SKY2, and all seems to work fine except the pressure, which shows as N/A 
> > (or null) in all the readings I can see in weewx. Looking atthe raw data 
> > from the BloomSky, the pressure is being reported, so I'm guessing 
> > someting in the driver is somehow missing it. Any ideas? 
>
> -- 
> 73, Rick, M0LEP 
>
>

-- 
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/f57fd414-fee0-44e5-bc13-57e4b2726d31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Davis Vantage Pro2 no data

[Andrew Milner]

fitting a RTC is the best solution to make the RPi more like a 'normal' 
computer - especially when used for real world production use.  

On Tuesday, 28 May 2019 22:44:38 UTC+3, John wrote:
>
> The instructions for delaying weewx from starting on the Raspberry Pi 
> until time is synced don't seem to be working with stretch and timesyncd as 
> the network time client.  If I "systemctl disable systemd-timesyncd"  it 
> never updates from the ntp server and weewx spins away with "engine: 
> Waiting for sane time. Current time is  ... "
>
> I have a local ntp server with a battery backed rtc. A raspberry pi with a 
> rtc that is running as my dns/dhcp server, and pi-hole.
>

-- 
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/7855a9aa-feb4-4b8a-816c-6891bbc27751%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Second crash after 11 days

[Steve Meltz]

Thanks Gary...as usual, your fix was spot on!

Steve

On Mon, May 27, 2019 at 11:19 PM gjr80  wrote:

> Steve,
>
> When I look at your gauges just now they are not working, the clue is in
> the scroller message - 'error: Not Found'. This means the gauges.js
> script cannot find gauge-data.txt. I suppose it is possible that when we
> uncommented the SteelSeries skin a few days ago to get your plots back that
> caused your web server gauges.js to be overwritten with the default
> gauges.js (or a version that is not up to date with your latest setup).
> Though if this were the case/cause I would have expected the gauges to stop
> straight away and I remember seeing them working properly after your plots
> came back. No matter, this is clearly a case of gauges.js not finding
> gauge-data.txt. I can see that gauge-data.txt is being updated on your
> web server every few seconds so rtgd is doing its job. The file is located
> in photokinetics.org/Weather/. To fix it, on your WeeWX machine, edit
> skins/SteelSeries/scripts/gauges.js and find the realTimeUrlWeewx setting
> at about line 74, it probably looks like:
>
> realTimeUrlWeewx : 'gauge-data.txt', // *** WeeWX Users: 
> Change to your location of the gauge data file **
>
>
> Try changing the setting to '../gauge-data.txt'. Save the file and the
> restart WeeWX. The next report cycle should seethe modified gauges.js
> uploaded to your server and hopefully the gauges will come on line.
>
> Gary
>
> On Tuesday, 28 May 2019 10:25:26 UTC+10, Steve2Q wrote:
>>
>> Gary...I was away for the weekend, so when I checked in using the Chrome
>> browser on my phone, the Steel Gauges were, and still are, working.
>> However, if I pull up the guages on my desktop or tablet, they are frozen
>> and "offline".  Please take a look at photokinetics.org/Weather and
>> click on the Steel Gauges button at the bottom and see if you observe the
>> same behavior. I tried both Chrome and Firefox on both devices. Thanks.
>>
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/VehicK_KNso/unsubscribe.
> To unsubscribe from this group and all its topics, 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/4b1de92a-fc25-4050-b692-d9dfb54033b2%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAH0o-anu2iS_WCtstwhAq%2BUFDNBPWN1PyWDWH0s-eDxCc0VbQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Weather34 Template for WeeWX - New Major Update

[Jd D]

Hi Ian,
I see the yearly update is there, but all the labels are still dewpoint. 
Maybe best is that I just update the ones I have and correct all the labels 
and comments when I do the other change.
That will save you from doing another update again.
Also there are two branches for this template and is the master the latest 
one? It is the one you updated last.
Thanks Jerry

On Tuesday, May 28, 2019 at 12:34:49 PM UTC-7, steeple ian wrote:
>
> Very strange, I updated them all but seem to have reverted back.
>
> They are all now updated to the correct data field.
>
> Sent from my iPhone
>
> On 28 May 2019, at 20:11, Jd D > 
> wrote:
>
> Hi Ian,
> You have mail.
> Also the monthly and yearly rainfall chart code on git hub still has the 
> dewpoint code in the files instead of the rainfall code.
> Let me know when you push out the updated code so I can grab them and 
> update them with the changes we talk about above.
> Thanks Jerry
>
> On Tuesday, May 28, 2019 at 3:05:18 AM UTC-7, steeple ian wrote:
>>
>> Great, I look forward to seeing it
>>
>> Sent from my iPhone
>>
>> On 28 May 2019, at 07:34, Jd D  wrote:
>>
>> Hi Ian,
>>
>> Using the data itself will make the system more stable since it has a 
>> lower chance of get changed by accident. I already created a javascript 
>> file in js folder so the function does not have to be included in all the 
>> files just the function call. I will update the other graphs and do some 
>> testing and then send these changes to you. Also did you know that adding 
>> zoomEnabled : true allows the user to zoom into the graphs. I use that 
>> option on all my graphs.
>>
>> One other side note I have the latest template working on weewx 3.8.2 So 
>> far only a couple minor changes to the w34stats template and new two line 
>> function in units.py
>> Take care
>> Jerry
>>
>> On Monday, May 27, 2019 at 11:26:02 PM UTC-7, steeple ian wrote:
>>>
>>> Hi Jerry,
>>>
>>> Believe it or not there is a Jake that I am in discussion with on 
>>> weather matters, just not around this forum!
>>>
>>> I thought it might be the case that you are using your CRT for other 
>>> purposes. 
>>>
>>> I am very open to look at more efficient ways of doing things. At the 
>>> moment the process is to mirror how MB does it under the bonnet. The 
>>> guiding principle should be that the user experience is identical and stays 
>>> faithful to the existing visual design, now and in the future. If this can 
>>> be achieved whilst being easy to maintain and speedily react to changes to 
>>> the parent.
>>> It does seem what you are suggesting might benefit the other versions so 
>>> it could be a win-win situation all round.
>>>
>>> So that’s the challenge!
>>>
>>> Regards,
>>> Ian
>>>
>>> Sent from my iPad
>>>
>>> On 28 May 2019, at 03:53, Jd D  wrote:
>>>
>>> Hi Ian,
>>> No problem with the name been called a lot worst in the past. :-)
>>>  I do have a suggestion for the displaying and graphing of different 
>>> units that I have tested. But first I like to explain my reasons for doing 
>>> something different. Right now I am using US units with a device that is 
>>> sending US unit data. To do it the current way (which I still see issues 
>>> with) the system would have to convert the F data in the database to C and 
>>> then back to F when I display it. From a CS point of view these types of 
>>> operations really should be avoided. Also I am using the CRT data for other 
>>> systems which means I would have to convert the data for those systems. To 
>>> me the biggest reason I do not like the current approach is the data is in 
>>> the database with its "native" units. Just by adding $unit.label.outTemp to 
>>> the result template and now I know the units of the data where ever I use 
>>> it. Then all I needed was a three line javascript function to compare the 
>>> units of the data with the units I am displaying and decide if a conversion 
>>> is needed. For me this removes three conversions of the data and works for 
>>> both C and F settings of the template. I can send you what I have if it 
>>> would help understand what I am getting at. I still need to send you my 
>>> other changes but I am making sure I have not missing anything.
>>> Thanks
>>> Jake aka Jerry
>>>
>>> On Monday, May 27, 2019 at 5:43:58 PM UTC-7, steeple ian wrote:

 Whoops,

 Sorry Jerry, this was meant for you not Jake.

 Ian

 On 27 May 2019, at 23:01, steeple ian  wrote:

 Hi Jake,

 I now see what is happening and the reason that you are having to 
 change things when they relate to non metric units.

 The template is designed to receive realtime data in metric units. One 
 of the early roots for this template was based on Cumulus realtime.txt, 
 which by default emits metric units, that is why the CRT extension should 
 be set for METRIC in the weewx.conf file (as per the snippet in the 
 install 
 guide. Unless, of course you are also using 

Re: [weewx-user] Davis Vantage Pro2 no data

[John]

The instructions for delaying weewx from starting on the Raspberry Pi until 
time is synced don't seem to be working with stretch and timesyncd as the 
network time client.  If I "systemctl disable systemd-timesyncd"  it never 
updates from the ntp server and weewx spins away with "engine: Waiting for 
sane time. Current time is  ... "

I have a local ntp server with a battery backed rtc. A raspberry pi with a 
rtc that is running as my dns/dhcp server, and pi-hole.

-- 
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/de3eec47-88ad-4981-88ec-e22a910f4681%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Weather34 Template for WeeWX - New Major Update

[steeple ian]

Very strange, I updated them all but seem to have reverted back.

They are all now updated to the correct data field.

Sent from my iPhone

> On 28 May 2019, at 20:11, Jd D  wrote:
> 
> Hi Ian,
> You have mail.
> Also the monthly and yearly rainfall chart code on git hub still has the 
> dewpoint code in the files instead of the rainfall code.
> Let me know when you push out the updated code so I can grab them and update 
> them with the changes we talk about above.
> Thanks Jerry
> 
>> On Tuesday, May 28, 2019 at 3:05:18 AM UTC-7, steeple ian wrote:
>> Great, I look forward to seeing it
>> 
>> Sent from my iPhone
>> 
>>> On 28 May 2019, at 07:34, Jd D  wrote:
>>> 
>>> Hi Ian,
>>> 
>>> Using the data itself will make the system more stable since it has a lower 
>>> chance of get changed by accident. I already created a javascript file in 
>>> js folder so the function does not have to be included in all the files 
>>> just the function call. I will update the other graphs and do some testing 
>>> and then send these changes to you. Also did you know that adding 
>>> zoomEnabled : true allows the user to zoom into the graphs. I use that 
>>> option on all my graphs.
>>> 
>>> One other side note I have the latest template working on weewx 3.8.2 So 
>>> far only a couple minor changes to the w34stats template and new two line 
>>> function in units.py
>>> Take care
>>> Jerry
>>> 
 On Monday, May 27, 2019 at 11:26:02 PM UTC-7, steeple ian wrote:
 Hi Jerry,
 
 Believe it or not there is a Jake that I am in discussion with on weather 
 matters, just not around this forum!
 
 I thought it might be the case that you are using your CRT for other 
 purposes. 
 
 I am very open to look at more efficient ways of doing things. At the 
 moment the process is to mirror how MB does it under the bonnet. The 
 guiding principle should be that the user experience is identical and 
 stays faithful to the existing visual design, now and in the future. If 
 this can be achieved whilst being easy to maintain and speedily react to 
 changes to the parent.
 It does seem what you are suggesting might benefit the other versions so 
 it could be a win-win situation all round.
 
 So that’s the challenge!
 
 Regards,
 Ian
 
 Sent from my iPad
 
> On 28 May 2019, at 03:53, Jd D  wrote:
> 
> Hi Ian,
> No problem with the name been called a lot worst in the past. :-)
>  I do have a suggestion for the displaying and graphing of different 
> units that I have tested. But first I like to explain my reasons for 
> doing something different. Right now I am using US units with a device 
> that is sending US unit data. To do it the current way (which I still see 
> issues with) the system would have to convert the F data in the database 
> to C and then back to F when I display it. From a CS point of view these 
> types of operations really should be avoided. Also I am using the CRT 
> data for other systems which means I would have to convert the data for 
> those systems. To me the biggest reason I do not like the current 
> approach is the data is in the database with its "native" units. Just by 
> adding $unit.label.outTemp to the result template and now I know the 
> units of the data where ever I use it. Then all I needed was a three line 
> javascript function to compare the units of the data with the units I am 
> displaying and decide if a conversion is needed. For me this removes 
> three conversions of the data and works for both C and F settings of the 
> template. I can send you what I have if it would help understand what I 
> am getting at. I still need to send you my other changes but I am making 
> sure I have not missing anything.
> Thanks
> Jake aka Jerry
> 
>> On Monday, May 27, 2019 at 5:43:58 PM UTC-7, steeple ian wrote:
>> Whoops,
>> 
>> Sorry Jerry, this was meant for you not Jake.
>> 
>> Ian
>> 
>>> On 27 May 2019, at 23:01, steeple ian  wrote:
>>> 
>>> Hi Jake,
>>> 
>>> I now see what is happening and the reason that you are having to 
>>> change things when they relate to non metric units.
>>> 
>>> The template is designed to receive realtime data in metric units. One 
>>> of the early roots for this template was based on Cumulus realtime.txt, 
>>> which by default emits metric units, that is why the CRT extension 
>>> should be set for METRIC in the weewx.conf file (as per the snippet in 
>>> the install guide. Unless, of course you are also using CRT for an 
>>> additional purpose which requires US units). Give it a try with the 
>>> original files and see what happens.
>>> 
>>> I will update the instructions to emphasise this important point.
>>> 
>>> Regarding the dew point graphs appearing instead of rainfall, I did 

Re: [weewx-user] Weather34 Template for WeeWX - New Major Update

[Jd D]

Hi Ian,
You have mail.
Also the monthly and yearly rainfall chart code on git hub still has the 
dewpoint code in the files instead of the rainfall code.
Let me know when you push out the updated code so I can grab them and 
update them with the changes we talk about above.
Thanks Jerry

On Tuesday, May 28, 2019 at 3:05:18 AM UTC-7, steeple ian wrote:
>
> Great, I look forward to seeing it
>
> Sent from my iPhone
>
> On 28 May 2019, at 07:34, Jd D > 
> wrote:
>
> Hi Ian,
>
> Using the data itself will make the system more stable since it has a 
> lower chance of get changed by accident. I already created a javascript 
> file in js folder so the function does not have to be included in all the 
> files just the function call. I will update the other graphs and do some 
> testing and then send these changes to you. Also did you know that adding 
> zoomEnabled : true allows the user to zoom into the graphs. I use that 
> option on all my graphs.
>
> One other side note I have the latest template working on weewx 3.8.2 So 
> far only a couple minor changes to the w34stats template and new two line 
> function in units.py
> Take care
> Jerry
>
> On Monday, May 27, 2019 at 11:26:02 PM UTC-7, steeple ian wrote:
>>
>> Hi Jerry,
>>
>> Believe it or not there is a Jake that I am in discussion with on weather 
>> matters, just not around this forum!
>>
>> I thought it might be the case that you are using your CRT for other 
>> purposes. 
>>
>> I am very open to look at more efficient ways of doing things. At the 
>> moment the process is to mirror how MB does it under the bonnet. The 
>> guiding principle should be that the user experience is identical and stays 
>> faithful to the existing visual design, now and in the future. If this can 
>> be achieved whilst being easy to maintain and speedily react to changes to 
>> the parent.
>> It does seem what you are suggesting might benefit the other versions so 
>> it could be a win-win situation all round.
>>
>> So that’s the challenge!
>>
>> Regards,
>> Ian
>>
>> Sent from my iPad
>>
>> On 28 May 2019, at 03:53, Jd D  wrote:
>>
>> Hi Ian,
>> No problem with the name been called a lot worst in the past. :-)
>>  I do have a suggestion for the displaying and graphing of different 
>> units that I have tested. But first I like to explain my reasons for doing 
>> something different. Right now I am using US units with a device that is 
>> sending US unit data. To do it the current way (which I still see issues 
>> with) the system would have to convert the F data in the database to C and 
>> then back to F when I display it. From a CS point of view these types of 
>> operations really should be avoided. Also I am using the CRT data for other 
>> systems which means I would have to convert the data for those systems. To 
>> me the biggest reason I do not like the current approach is the data is in 
>> the database with its "native" units. Just by adding $unit.label.outTemp to 
>> the result template and now I know the units of the data where ever I use 
>> it. Then all I needed was a three line javascript function to compare the 
>> units of the data with the units I am displaying and decide if a conversion 
>> is needed. For me this removes three conversions of the data and works for 
>> both C and F settings of the template. I can send you what I have if it 
>> would help understand what I am getting at. I still need to send you my 
>> other changes but I am making sure I have not missing anything.
>> Thanks
>> Jake aka Jerry
>>
>> On Monday, May 27, 2019 at 5:43:58 PM UTC-7, steeple ian wrote:
>>>
>>> Whoops,
>>>
>>> Sorry Jerry, this was meant for you not Jake.
>>>
>>> Ian
>>>
>>> On 27 May 2019, at 23:01, steeple ian  wrote:
>>>
>>> Hi Jake,
>>>
>>> I now see what is happening and the reason that you are having to change 
>>> things when they relate to non metric units.
>>>
>>> The template is designed to receive realtime data in metric units. One 
>>> of the early roots for this template was based on Cumulus realtime.txt, 
>>> which by default emits metric units, that is why the CRT extension should 
>>> be set for METRIC in the weewx.conf file (as per the snippet in the install 
>>> guide. Unless, of course you are also using CRT for an additional purpose 
>>> which requires US units). Give it a try with the original files and see 
>>> what happens.
>>>
>>> I will update the instructions to emphasise this important point.
>>>
>>> Regarding the dew point graphs appearing instead of rainfall, I did 
>>> exactly as you suggested. I realised what happened when I was updating the 
>>> charts for another purpose 3 days ago and I fixed them at the same time.
>>>
>>> Regards Ian
>>>
>>> On 27 May 2019, at 19:22, Jd D  wrote:
>>>
>>> Hi Ian,
>>>
>>> It is set to
>>> unit_system = US
>>>
>>> Also a couple chart items.
>>> 1) Yearly and Monthly rainfall charts are dew point charts in your 
>>> release. Looks like something got overwritten or renamed. The file names 
>>> are 

[weewx-user] Re: Web Server auf dem Raspberry Apache2

[vince]

On Tuesday, May 28, 2019 at 11:16:15 AM UTC-7, Günther Wrana wrote:

> Was habe ich falsch eingegeben oder was muss ich noch tun? 
>

You have extra space characters in your command.

Try:
sudo cp util/apache/conf.d/weewx.conf /etc/apache2/conf.d


-- 
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/b47835e8-0951-43d7-b03c-686b1950455c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Web Server auf dem Raspberry Apache2

[Günther Wrana]

Hallo habe alles nach Anleitung gemacht nur das funktioniert nicht warum?


pi@raspberrypi:~ $ sudo apt-get install apache2
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
apache2 ist schon die neueste Version (2.4.25-3+deb9u7).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 70 nicht aktualisiert.
pi@raspberrypi:~ $ sudo cp util/apache/conf.d/weewx.conf /etc/apache2/conf.d
cp: der Aufruf von stat für 'util/apache/conf.d/weewx.conf' ist nicht 
möglich: Datei oder Verzeichnis nicht gefunden


Was habe ich falsch eingegeben oder was muss ich noch tun? 

-- 
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/8ff3776f-c640-4df4-a4cd-01387d9dd9a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Davis Vantage Pro2 no data

[Andrew Milner]

I would recommend you doing the CORRECT solution and installing an RTC on 
your Pi zero.  Weewx relies HEAVILY on accurate time synchronisation 
between weather station and controlling PC - so ensuring your pi EITHER has 
an RTC onboard OR prevents weewx starting until time has been synchronised 
is ESSENTIAL for correct operation.

There are many many users of weewx with Davis stations, and many many of us 
with various models of RPi.  There are also many instances of logger 
corruptions and other anomolies.. so fudging the driver for one situation 
may open a can of worms in another situation - you have been warned!



On Tuesday, 28 May 2019 18:00:09 UTC+3, John wrote:
>
> so looking at the vantage driver it seems that if the weewx host 
> (raspberry pi zero without a RTC) has an incorrect time like after a 
> restart and syncs it's bad (early) time with the vantage console, then 
> records being added to the vantage console will have an earlier timestamp 
> than existing records. when weewx goes to read the records and finds a 
> "decreasing timestamp" it stops reading more records. manually clearing all 
> the records AND setting the correct time is a solution.
>
> I propose changing the vantage driver to avert setting the console time, 
> during a routine sync, earlier than the last record in the console. This 
> should prevent weewx from adjusting the console time until the weewx host 
> has had an opportunity to successfully acquire the time from an external 
> source (ntp server).   I suppose setting the console to a future time could 
> cause a problem, preventing weewx from correcting the console time without 
> first clearing the last (errant) record.
>
>

-- 
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/32f79d61-7d81-4bc0-adab-6d1ad66de99c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Davis Vantage Pro2 no data

[John]

so looking at the vantage driver it seems that if the weewx host (raspberry 
pi zero without a RTC) has an incorrect time like after a restart and syncs 
it's bad (early) time with the vantage console, then records being added to 
the vantage console will have an earlier timestamp than existing records. 
when weewx goes to read the records and finds a "decreasing timestamp" it 
stops reading more records. manually clearing all the records AND setting 
the correct time is a solution.

I propose changing the vantage driver to avert setting the console time, 
during a routine sync, earlier than the last record in the console. This 
should prevent weewx from adjusting the console time until the weewx host 
has had an opportunity to successfully acquire the time from an external 
source (ntp server).   I suppose setting the console to a future time could 
cause a problem, preventing weewx from correcting the console time without 
first clearing the last (errant) record.

-- 
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/066a6494-cd10-465b-86a7-5452386adddb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: RFM95W as alternative to RTL-SDR for Davis Vantage Pro 2

[kobuki]

I need to correct myself. The cabled serial output should be available on 
the RJ11 connector if an ADM3483 TTL-RS422 converter chip is installed on 
the wireless ISS. See this thread on wxforum: 
http://www.wxforum.net/index.php?topic=18656 (see also: 
http://www.wxforum.net/index.php?topic=28530.0)

However, you only need the 3.3V serial output from the MCU on the board (no 
need for the converter chip), which is apparently routed to pin 4 of the 
converter chip pads for easy soldered access. So you can just get normal 
TTL serial data out of there and forward it to your decoding 
appliance/code/weewx driver/whatever remotely. This approach is also 
interesting when trying to use a SIM board not made for a certain region. A 
smart little hack and we have a wifi/lora transmitter... OK, there are a 
few assumptions since I've never tried this, and the OP in the above forum 
thread never left feedback on success or failure. But I think it's worth a 
try.

On Tuesday, May 28, 2019 at 11:02:44 AM UTC+2, kobuki wrote:
>
> That might provide a working solution, if the console port indeed dumps 
> the data packets (I remembered it does, but right now I'm not entirely 
> sure). If it does, it should RS422 signaling. I'm not sure if it can be 
> used to wake up your module without losing the first few data bytes of the 
> 10 for a packet, but if it has uA power modes where it can listen on a 
> serial port, it might be a viable approach. The data packets are identical 
> to the ones used by the radio protocol, and there are interpreters for that 
> in several languages, including C++ for Arduino, python, etc. Maybe the 
> simplest is to relay the packets to the remote station and let it process 
> them.
>
> On Tuesday, May 28, 2019 at 2:45:10 AM UTC+2, John wrote:
>>
>> Maybe hook up to the console connector then.  That would upgrade both my 
>> active station and perhaps salvage the old one as well. Does the console 
>> connector provide a buffer for the data stream so that I could just have 
>> the ULP wake up the ESP32, read out the data buffer, write to the SD, 
>> transmit, and go back to sleep?
>>
>

-- 
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/2707c599-b255-4a17-a485-c714956e911b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: RFM95W as alternative to RTL-SDR for Davis Vantage Pro 2

[kobuki]

That might provide a working solution, if the console port indeed dumps the 
data packets (I remembered it does, but right now I'm not entirely sure). 
If it does, it should RS422 signaling. I'm not sure if it can be used to 
wake up your module without losing the first few data bytes of the 10 for a 
packet, but if it has uA power modes where it can listen on a serial port, 
it might be a viable approach. The data packets are identical to the ones 
used by the radio protocol, and there are interpreters for that in several 
languages, including C++ for Arduino, python, etc. Maybe the simplest is to 
relay the packets to the remote station and let it process them.

On Tuesday, May 28, 2019 at 2:45:10 AM UTC+2, John wrote:
>
> Maybe hook up to the console connector then.  That would upgrade both my 
> active station and perhaps salvage the old one as well. Does the console 
> connector provide a buffer for the data stream so that I could just have 
> the ULP wake up the ESP32, read out the data buffer, write to the SD, 
> transmit, and go back to sleep?
>

-- 
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/8f34e162-c2d3-4cfc-86c5-0c9b5af98729%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: On this date

[Robin]

> Peter,


Thank you. This has finally started to sink in, I am now producing tables 
that show what I want and make sense!

Thank you to everyone that has had input here, you are all superstars.

Regards to all
Robin

-- 
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/74418484-6e3c-4aba-ab9d-6d0a6dadc31e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Weather34 Template for WeeWX - New Major Update

[Jd D]

Hi Ian,

Using the data itself will make the system more stable since it has a lower 
chance of get changed by accident. I already created a javascript file in 
js folder so the function does not have to be included in all the files 
just the function call. I will update the other graphs and do some testing 
and then send these changes to you. Also did you know that adding 
zoomEnabled : true allows the user to zoom into the graphs. I use that 
option on all my graphs.

One other side note I have the latest template working on weewx 3.8.2 So 
far only a couple minor changes to the w34stats template and new two line 
function in units.py
Take care
Jerry

On Monday, May 27, 2019 at 11:26:02 PM UTC-7, steeple ian wrote:
>
> Hi Jerry,
>
> Believe it or not there is a Jake that I am in discussion with on weather 
> matters, just not around this forum!
>
> I thought it might be the case that you are using your CRT for other 
> purposes. 
>
> I am very open to look at more efficient ways of doing things. At the 
> moment the process is to mirror how MB does it under the bonnet. The 
> guiding principle should be that the user experience is identical and stays 
> faithful to the existing visual design, now and in the future. If this can 
> be achieved whilst being easy to maintain and speedily react to changes to 
> the parent.
> It does seem what you are suggesting might benefit the other versions so 
> it could be a win-win situation all round.
>
> So that’s the challenge!
>
> Regards,
> Ian
>
> Sent from my iPad
>
> On 28 May 2019, at 03:53, Jd D > 
> wrote:
>
> Hi Ian,
> No problem with the name been called a lot worst in the past. :-)
>  I do have a suggestion for the displaying and graphing of different units 
> that I have tested. But first I like to explain my reasons for doing 
> something different. Right now I am using US units with a device that is 
> sending US unit data. To do it the current way (which I still see issues 
> with) the system would have to convert the F data in the database to C and 
> then back to F when I display it. From a CS point of view these types of 
> operations really should be avoided. Also I am using the CRT data for other 
> systems which means I would have to convert the data for those systems. To 
> me the biggest reason I do not like the current approach is the data is in 
> the database with its "native" units. Just by adding $unit.label.outTemp to 
> the result template and now I know the units of the data where ever I use 
> it. Then all I needed was a three line javascript function to compare the 
> units of the data with the units I am displaying and decide if a conversion 
> is needed. For me this removes three conversions of the data and works for 
> both C and F settings of the template. I can send you what I have if it 
> would help understand what I am getting at. I still need to send you my 
> other changes but I am making sure I have not missing anything.
> Thanks
> Jake aka Jerry
>
> On Monday, May 27, 2019 at 5:43:58 PM UTC-7, steeple ian wrote:
>>
>> Whoops,
>>
>> Sorry Jerry, this was meant for you not Jake.
>>
>> Ian
>>
>> On 27 May 2019, at 23:01, steeple ian  wrote:
>>
>> Hi Jake,
>>
>> I now see what is happening and the reason that you are having to change 
>> things when they relate to non metric units.
>>
>> The template is designed to receive realtime data in metric units. One of 
>> the early roots for this template was based on Cumulus realtime.txt, which 
>> by default emits metric units, that is why the CRT extension should be set 
>> for METRIC in the weewx.conf file (as per the snippet in the install guide. 
>> Unless, of course you are also using CRT for an additional purpose which 
>> requires US units). Give it a try with the original files and see what 
>> happens.
>>
>> I will update the instructions to emphasise this important point.
>>
>> Regarding the dew point graphs appearing instead of rainfall, I did 
>> exactly as you suggested. I realised what happened when I was updating the 
>> charts for another purpose 3 days ago and I fixed them at the same time.
>>
>> Regards Ian
>>
>> On 27 May 2019, at 19:22, Jd D  wrote:
>>
>> Hi Ian,
>>
>> It is set to
>> unit_system = US
>>
>> Also a couple chart items.
>> 1) Yearly and Monthly rainfall charts are dew point charts in your 
>> release. Looks like something got overwritten or renamed. The file names 
>> are correct just the code inside does not match the file name.
>>
>> 2) Also had to comment out the conv code for the barometer charts so the 
>> charts matched my units inHg.
>>
>> Thanks Jerry
>>
>> On Monday, May 27, 2019 at 11:11:23 AM UTC-7, steeple ian wrote:
>>>
>>> Jerry,
>>>
>>> Can I just check, have you got realtime.txt set for US units or METRIC 
>>> units in your weewx.conf file?
>>>
>>> On Mon, May 27, 2019 at 6:09 PM steeple ian  wrote:
>>>
 Hi Jerry,
 That’s excellent information. I will be very interested to have a copy 
 of the livedata and other file 

Re: [weewx-user] Weather34 Template for WeeWX - New Major Update

[steeple ian]

Hi Jerry,

Believe it or not there is a Jake that I am in discussion with on weather 
matters, just not around this forum!

I thought it might be the case that you are using your CRT for other purposes. 

I am very open to look at more efficient ways of doing things. At the moment 
the process is to mirror how MB does it under the bonnet. The guiding principle 
should be that the user experience is identical and stays faithful to the 
existing visual design, now and in the future. If this can be achieved whilst 
being easy to maintain and speedily react to changes to the parent.
It does seem what you are suggesting might benefit the other versions so it 
could be a win-win situation all round.

So that’s the challenge!

Regards,
Ian

Sent from my iPad

> On 28 May 2019, at 03:53, Jd D  wrote:
> 
> Hi Ian,
> No problem with the name been called a lot worst in the past. :-)
>  I do have a suggestion for the displaying and graphing of different units 
> that I have tested. But first I like to explain my reasons for doing 
> something different. Right now I am using US units with a device that is 
> sending US unit data. To do it the current way (which I still see issues 
> with) the system would have to convert the F data in the database to C and 
> then back to F when I display it. From a CS point of view these types of 
> operations really should be avoided. Also I am using the CRT data for other 
> systems which means I would have to convert the data for those systems. To me 
> the biggest reason I do not like the current approach is the data is in the 
> database with its "native" units. Just by adding $unit.label.outTemp to the 
> result template and now I know the units of the data where ever I use it. 
> Then all I needed was a three line javascript function to compare the units 
> of the data with the units I am displaying and decide if a conversion is 
> needed. For me this removes three conversions of the data and works for both 
> C and F settings of the template. I can send you what I have if it would help 
> understand what I am getting at. I still need to send you my other changes 
> but I am making sure I have not missing anything.
> Thanks
> Jake aka Jerry
> 
>> On Monday, May 27, 2019 at 5:43:58 PM UTC-7, steeple ian wrote:
>> Whoops,
>> 
>> Sorry Jerry, this was meant for you not Jake.
>> 
>> Ian
>> 
>>> On 27 May 2019, at 23:01, steeple ian  wrote:
>>> 
>>> Hi Jake,
>>> 
>>> I now see what is happening and the reason that you are having to change 
>>> things when they relate to non metric units.
>>> 
>>> The template is designed to receive realtime data in metric units. One of 
>>> the early roots for this template was based on Cumulus realtime.txt, which 
>>> by default emits metric units, that is why the CRT extension should be set 
>>> for METRIC in the weewx.conf file (as per the snippet in the install guide. 
>>> Unless, of course you are also using CRT for an additional purpose which 
>>> requires US units). Give it a try with the original files and see what 
>>> happens.
>>> 
>>> I will update the instructions to emphasise this important point.
>>> 
>>> Regarding the dew point graphs appearing instead of rainfall, I did exactly 
>>> as you suggested. I realised what happened when I was updating the charts 
>>> for another purpose 3 days ago and I fixed them at the same time.
>>> 
>>> Regards Ian
>>> 
 On 27 May 2019, at 19:22, Jd D  wrote:
 
 Hi Ian,
 
 It is set to
 unit_system = US
 
 Also a couple chart items.
 1) Yearly and Monthly rainfall charts are dew point charts in your 
 release. Looks like something got overwritten or renamed. The file names 
 are correct just the code inside does not match the file name.
 
 2) Also had to comment out the conv code for the barometer charts so the 
 charts matched my units inHg.
 
 Thanks Jerry
 
> On Monday, May 27, 2019 at 11:11:23 AM UTC-7, steeple ian wrote:
> Jerry,
> 
> Can I just check, have you got realtime.txt set for US units or METRIC 
> units in your weewx.conf file?
> 
>> On Mon, May 27, 2019 at 6:09 PM steeple ian  wrote:
>> Hi Jerry,
>> That’s excellent information. I will be very interested to have a copy 
>> of the livedata and other file changes when you have completed them.
>> Thank you very much,
>> Ian 
>> 
>> Sent from my iPhone
>> 
>>> On 27 May 2019, at 17:53, Jd D  wrote:
>>> 
>>> Hi Ian,
>>> 
>>> Here are a couple more. The following code exists in multiple graphs 
>>> and causes the graphs to be messed up since the data is already 
>>> Fahrenheit . Not sure why this was needed at all. I commented it out to 
>>> fixed the graphs
>>> .//  if ($tempunit == 'F') {
>>> //  $conv = '(9 / 5) + 32';
>>> //  } else {
>>> $conv = '1';
>>> //  }
>>> 
>>> Also in shared.php looks like a cut and paste error deleted