Re: [weewx-user] Weewx und Renkforce WH2315

['michael.k...@gmx.at' via weewx-user]

Jetzt sind wir schon weiter, das sudo hat funktioniert. Jetzt wäre noch 
wichtig zu wissen, welche locale da gesetzt werden soll und ob diese auf 
deinem system verfügbar ist.
Günther Wrana schrieb am Donnerstag, 12. September 2024 um 12:42:49 UTC+2:

> [image: Bildschirmfoto vom 2024-09-12 12-35-40.png]
> Hallo es funktioniert auch mit sudo am Anfang nicht.
> Es hat nur bei der Installation funktioniert das ich eine Station 
> auswählen kann.
> Da meine Wetterstation nicht in der Liste ist habe ich die Simulation 
> gewählt.
> Ich dachte es liegt am Treiber und an der Version von weewx.
> Also habe ich den Raspberry neu installiert und nur weewx installiert und 
> nur versucht den Treiber zu ändern.
> Das kommt dabei raus.
> Ich glaube ich bin zu D... für das ganze.
>
> Danke noch einmal für alles!
> Gütße Günther
>
>
> Hi, it doesn't work with sudo at the beginning either.
> It only worked during the installation that I can select a station. 
> Since my weather station is not in the list, I chose the simulation. 
> I thought it was due to the driver and the version of weewx. 
> So I reinstalled the Raspberry and only installed weewx and only tried to 
> change the driver. 
> This is what comes out of it.
> I think I'm too stupid for the whole thing. 
>
> Thanks again for everything! 
> Gütße Günther
> michael.k...@gmx.at schrieb am Donnerstag, 12. September 2024 um 12:05:47 
> UTC+2:
>
>> Hallo Günther, hast du schon probiert, ein sudo vor diesen Befehl zu 
>> setzen?
>>
>> 32GB@32GB:~/Downloads $ weectl station reconfigure
>>
>> also:
>>
>> 32GB@32GB:~/Downloads $ sudo weectl station reconfigure
>>
>> Von mit Paketinstaller mittels sudo installierten Files in /etc würde 
>> ich annehmen, dass diese nicht dem User gehören, mit dem du weectl ohne 
>> sudo ausführst. Daher fehlt dann auch höchstwahrscheinlich die 
>> Berechtigung, auf diesem Weg /etc/weewx/weewx.conf zu verändern.
>> Günther Wrana schrieb am Donnerstag, 12. September 2024 um 10:49:15 UTC+2:
>>
>>> Hallo wenn ich das ganze System aber neu erstellt habe.
>>> Ich mich dabe an die Vorgaben von folgender Aneitung 
>>> https://weewx.com/docs/5.1/quickstarts/debian/ gehalten habe.
>>> Dann erstehe ich nicht wo das Problem liegt.
>>> Muss ich bei der erstellung eines neuen Raspberry System etawas beachten?
>>> Oder bevor ich weewx installiere?
>>>
>>> Danke für alles!
>>>
>>>
>>> Hello if I have recreated the whole system though.
>>> I have adhered to the specifications of the following 
>>> https://weewx.com/docs/5.1/quickstarts/debian/.
>>> Then I don't see where the problem lies.
>>> Do I have to pay attention to anything when creating a new Raspberry 
>>> system?
>>> Or before I install weewx?
>>>
>>> Thanks for all!
>>>
>>> EdwinZ schrieb am Sonntag, 25. August 2024 um 14:10:33 UTC+2:
>>>
 Hi Guenther, to be this looks more like an access control problem (" 
 Permission denied: '/etc/weewx/weewx.conf"). As since recently WeeWX moved 
 from root to the weewx user, I guess this may be your problem.
 Please read 
 https://github.com/weewx/weewx/wiki/WeeWX-Frequently-Asked-Questions#why-do-i-get-permission-denied
  
 and https://weewx.com/docs/5.1/upgrade/#weewx-runs-as-the-weewx-user

 For me all the files in /etc/weewx are owned by the weewx user and 
 group.

 Hope this helps!
 Edwin
 On Sunday, August 25, 2024 at 10:27:51 AM UTC+2 Günther Wrana wrote:

> Hi, I can't even reconfigure the program with this weectl station 
> reconfigure command.
> So I don't need to try to install other drivers yet. 
> The driver I would need cannot be installed. 
> But thanks for the information.
>
>
> Hallo ich kann das Programm mit diesem Befehl weectl station 
> reconfigure nicht einmal neu konfigurieren.
> Also brauche ich auch noch nicht versuchen andere Treiber zu 
> installieren.
> Den Treiber den ich brauchen würde lässt sich nicht installieren.
> Aber danke für die Informationen.
>
>
>
> Kalli schrieb am Samstag, 24. August 2024 um 17:57:10 UTC+2:
>
> Hello, I have copied the driver data into the intended directories, 
> try that. Unfortunately I don't remember what they were, but I'll take a 
> look.
> Hallo ich habe die Treiber daten in die dafür vorgesehenen 
> Verzeichnisse kopiert , versuche das mal. Ich weis leider nicht mehr 
> welsche das waren, aber ich schaue mal nach.
>
> Am 24.08.2024 um 17:14 schrieb Günther Wrana :
>
> Hello and again it's me, Günther Wrana from Austria, who can't install 
> the driver for the Renkforce Wh2315.
> Does it no longer work the driver or what have I once again not 
> installed correctly.
>
> As you can see below, I installed weewx on my Raspberry and chose the 
> simulation driver.
> I then tried to choose a new driver with the weectl station 
> reconfigure command. 
>
> Even before I tried to install 

Re: [weewx-user] Weewx und Renkforce WH2315

['michael.k...@gmx.at' via weewx-user]

Hallo Günther, hast du schon probiert, ein sudo vor diesen Befehl zu setzen?

32GB@32GB:~/Downloads $ weectl station reconfigure

also:

32GB@32GB:~/Downloads $ sudo weectl station reconfigure

Von mit Paketinstaller mittels sudo installierten Files in /etc würde ich 
annehmen, dass diese nicht dem User gehören, mit dem du weectl ohne sudo 
ausführst. Daher fehlt dann auch höchstwahrscheinlich die Berechtigung, auf 
diesem Weg /etc/weewx/weewx.conf zu verändern.
Günther Wrana schrieb am Donnerstag, 12. September 2024 um 10:49:15 UTC+2:

> Hallo wenn ich das ganze System aber neu erstellt habe.
> Ich mich dabe an die Vorgaben von folgender Aneitung 
> https://weewx.com/docs/5.1/quickstarts/debian/ gehalten habe.
> Dann erstehe ich nicht wo das Problem liegt.
> Muss ich bei der erstellung eines neuen Raspberry System etawas beachten?
> Oder bevor ich weewx installiere?
>
> Danke für alles!
>
>
> Hello if I have recreated the whole system though.
> I have adhered to the specifications of the following 
> https://weewx.com/docs/5.1/quickstarts/debian/.
> Then I don't see where the problem lies.
> Do I have to pay attention to anything when creating a new Raspberry 
> system?
> Or before I install weewx?
>
> Thanks for all!
>
> EdwinZ schrieb am Sonntag, 25. August 2024 um 14:10:33 UTC+2:
>
>> Hi Guenther, to be this looks more like an access control problem (" 
>> Permission denied: '/etc/weewx/weewx.conf"). As since recently WeeWX moved 
>> from root to the weewx user, I guess this may be your problem.
>> Please read 
>> https://github.com/weewx/weewx/wiki/WeeWX-Frequently-Asked-Questions#why-do-i-get-permission-denied
>>  
>> and https://weewx.com/docs/5.1/upgrade/#weewx-runs-as-the-weewx-user
>>
>> For me all the files in /etc/weewx are owned by the weewx user and group.
>>
>> Hope this helps!
>> Edwin
>> On Sunday, August 25, 2024 at 10:27:51 AM UTC+2 Günther Wrana wrote:
>>
>>> Hi, I can't even reconfigure the program with this weectl station 
>>> reconfigure command.
>>> So I don't need to try to install other drivers yet. 
>>> The driver I would need cannot be installed. 
>>> But thanks for the information.
>>>
>>>
>>> Hallo ich kann das Programm mit diesem Befehl weectl station reconfigure 
>>> nicht einmal neu konfigurieren.
>>> Also brauche ich auch noch nicht versuchen andere Treiber zu 
>>> installieren.
>>> Den Treiber den ich brauchen würde lässt sich nicht installieren.
>>> Aber danke für die Informationen.
>>>
>>>
>>>
>>> Kalli schrieb am Samstag, 24. August 2024 um 17:57:10 UTC+2:
>>>
>>> Hello, I have copied the driver data into the intended directories, try 
>>> that. Unfortunately I don't remember what they were, but I'll take a look.
>>> Hallo ich habe die Treiber daten in die dafür vorgesehenen Verzeichnisse 
>>> kopiert , versuche das mal. Ich weis leider nicht mehr welsche das waren, 
>>> aber ich schaue mal nach.
>>>
>>> Am 24.08.2024 um 17:14 schrieb Günther Wrana :
>>>
>>> Hello and again it's me, Günther Wrana from Austria, who can't install 
>>> the driver for the Renkforce Wh2315.
>>> Does it no longer work the driver or what have I once again not 
>>> installed correctly.
>>>
>>> As you can see below, I installed weewx on my Raspberry and chose the 
>>> simulation driver.
>>> I then tried to choose a new driver with the weectl station reconfigure 
>>> command. 
>>>
>>> Even before I tried to install the driver for my Renkforce Wh2315.
>>> Not even that worked, so what's wrong and what's the problem?
>>>
>>> Thanks for the help Günther
>>>
>>>
>>> Hallo und wieder bin es ich Günther Wrana aus Österreich der den Treiber 
>>> für die Renkforce Wh2315 nicht installieren kann.
>>> Funktioniert es nun nicht mehr der Treiber oder was habe ich nun wieder 
>>> einmal nicht richtig installiert.
>>>
>>> Wie Ihr unten sehen könnt habe ich weewx auf meinem Raspberry 
>>> installiert und den Simulation Treiber gewählt.
>>> Ich habe danach mit dem Befehl weectl station reconfigure versucht einen 
>>> neuen Treiber zu wählen.
>>>
>>> Noch bevor ich den Treiber für meine Renkforce Wh2315 zu installieren 
>>> versuch habe.
>>> Nicht einmal das hat funktioniert also was ist falsch und wo liegt das 
>>> Problem?
>>>
>>> Danke für die Hilfe Günther
>>>  
>>>
>>> 32GB@32GB:~/Downloads $ sudo systemctl start weewx
>>> 32GB@32GB:~/Downloads $ sudo systemctl status weewx
>>> ● weewx.service - WeeWX
>>>  Loaded: loaded (/lib/systemd/system/weewx.service; enabled; preset: 
>>> enabled)
>>>  Active: active (running) since Sat 2024-08-24 16:58:57 CEST; 2s ago
>>>Docs: https://weewx.com/docs
>>>Main PID: 4631 (python3)
>>>   Tasks: 1 (limit: 755)
>>> CPU: 784ms
>>>  CGroup: /system.slice/weewx.service
>>>  └─4631 python3 /usr/share/weewx/weewxd.py 
>>> /etc/weewx/weewx.conf
>>>
>>> Aug 24 16:58:58 32GB weewxd[4631]: INFO weewx.restx: CWOP: Posting not 
>>> enabled.
>>> Aug 24 16:58:58 32GB weewxd[4631]: INFO weewx.restx: WOW: Posting not 
>>> enabled.
>>> Aug 24

[weewx-user] Re: How long will an SD card last?

['michael.k...@gmx.at' via weewx-user]

Here is my n=1 study:
With every generation of the Raspberry Pi, from the first onward, up until 
the RPi4, I had been very successful destroying my SD-Cards (also the 
mentioned SanDisk Extreme), USB-Sticks and even SSDs. The SSD lasted a bit 
more than two years. The only time the storage didn't get corrupted, was 
when I mounted / on a nfs file syste on my NAS. But this was only an 
episode of a couple of months, most of the SD cards also survived such a 
time span.

A couple of months ago I abandoned the RPi for a Zotac ZBOX with a data 
center grade SSD. Time will tell, if this choice will last.

paul.ba...@gmail.com schrieb am Dienstag, 3. September 2024 um 23:43:45 
UTC+2:

> My Weewx (5.1) run on a Rpi400 (a RPi4 in the keyboard with 4 GB of 
> memory) for a little more than 3 Years, without any glitch. The loop 
> interval is 300 s, the dB server is mariadb/mysql on the Rpi. In addition 
> and in parallel, I run 4 heavy batch programs (BOINC), so that the RPi is 
> always (very) busy. The mean temperature of the cpu is ~60 centigrad, 
> around 160 F. This is a lot but is very stable over time, avoiding thermal 
> shocks. The SSD (129 GB) is hot too. It is 65 % full. No UPS (but we are in 
> Switzerland with almost no power interruption). 
>
> The archive is 128 MB for 600 K records. It is backuped every day on two 
> other server, not RPi... Further more, the data from the Tenpest weather 
> station are also recorded on an other computer.
>
> From experience, I  found one major difference between various SSD, that 
> is their power consumption. The one in use is a low consumer one.
>
> This system was build to stretch the RPi, may be overstretch, but until 
> now, it runs perfectly. 
>
> Hope this helps other !   regards, Paul
>
>
>
> Le Sunday, September 1, 2024 à 9:23:51 PM UTC+2, Tom Keffer a écrit :
>
>> Almost 10 years ago I started an experiment on how long an SD card can 
>> last in the WeeWX environment. You can see the environment here 
>> .
>>
>> When the experiment started, Squeeze (Debian 6) on an RPi B+ was state of 
>> the art. We've now gone on through 4 new generations of Pi's, and 6 
>> generations of Debian.
>>
>> I'm finally bringing the experiment to a halt today, just short of its 
>> 10th anniversary,  not because the card failed, but because the version of 
>> ssh it uses is so obsolete that my cloud server refuses to accept a 
>> connection any longer.
>>
>> I could install the latest version of Raspberry Pi OS, but I'd like that 
>> corner of my desk back.
>>
>> Conclusion? There is no reason not use an SD card as your primary storage 
>> if you do the following:
>>
>>- Get a good one. I used a SanDisk Extreme Plus, which is still 
>>available.
>>- Buy a big one so the wear-leveling algorithm has lots of space to 
>>work with.
>>- Use a UPS (Uninterruptible Power Supply). This cuts down on 
>>electrical transients.
>>- Run a backup!
>>
>> -tk
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/f8123bb4-64c1-4b81-83ba-c924e349fc03n%40googlegroups.com.

[weewx-user] Re: Disaggregated SDR and WeeWX installations

['michael.k...@gmx.at' via weewx-user]

I've posted these links some days ago, if I understand it correctly, with 
such devices you should be able to receive you sensor signals and forward 
them using MQTT an let weewx receive them with MQTTSubscribe:

https://www.rtl-sdr.com/rtl_433-ported-to-esp32-microcontrollers-with-cc1101-or-sx127x-transceiver-chips/

https://www.lilygo.cc/products/lora3?_pos=1&_sid=0081a9887&_ss=r

Which sounds much more reasonable to me than letting an extra Pi do the 
job, especially if you also take maintenance into account.

bell...@gmail.com schrieb am Donnerstag, 22. August 2024 um 01:22:36 UTC+2:

> I do something similar. But I use the rtl_433 built in MQTT integration 
> and run it as a systemd service.The invocation of rtl_433 looks like this.
> ‘ExecStart=/usr/local/bin/rtl_433 -M utc -F 
> mqtt://localhost:1883,retain=0,devices=rtl_433[/host]/devices[/type][/model][/subtype][/channel][/id]’
>
> Here is an example of subscribing to one of the sensors that I am 
> monitoring.
> ][[topics]]
> ignore = True
> [[[message]]]
> type = individual
> # Freezer
> [[[rtl_433/weather-data/devices/Acurite-606TX/77/temperature_C]]]
> ignore = False
> unit_system = METRIC
> name = extraTemp8
>
> - rich
>
>
> On Wednesday 21 August 2024 at 18:56:36 UTC-4 storm...@gmail.com wrote:
>
> You can publish the sensor data using MQTT using "rtl_433 -F json -M utc | 
> mosquitto_pub -t home/rtl_433 -l"  on one  raspberry pi  and subscribe to 
> the topic on the raspberry pi running Weewx using "WeeWX-MQTTSubscribe".
>
> On Wednesday, August 21, 2024 at 4:32:34 PM UTC-4 Will Marcus wrote:
>
> Anyone know if it's possible to run the SDR capture on a seperate device 
> from the WeeWX Server? I want to run the RTL433 code on a raspberry pi 
> closer to the sensors and then push that to a seperate installation of 
> WeeWX housed on a more stable / beefy platform. I dont fully understand the 
> message bus between the two technologies I guess. 
>
> I've set everything up on the same device before using Mathew Wall's 
> weewx-sdr package but I'm not sure how the driver actually moves the data.
>
> Thanks in advance,
> Will
>
>

-- 
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/ed44d399-985d-4053-a834-a9048db3e70dn%40googlegroups.com.

[weewx-user] Re: Fixing values in rainRate table

['michael.k...@gmx.at' via weewx-user]

> Is there any case where rainRate will be > 0, but rain = 0 for a time 
period?

Yes, if the archive_interval is shorter than the interval used for the rain 
rate calculation, this is always the case after the last archive_interval 
with rain of a single rain event.

> What do  sum, count, wsum, sumtime account for in the rainRate table?

The same as for all other observation types, one thing is making calculate 
statistics faster. When you fix the rainRate values in the archive table, 
you should rebuild the summaries also.

Thomas Carlin schrieb am Samstag, 17. August 2024 um 04:19:44 UTC+2:

> Is there any case where rainRate will be > 0, but rain = 0 for a time 
> period?
>
> What do  sum, count, wsum, sumtime account for in the rainRate table?
>
> I suspect that if these values are off in the archive table, is a safe to 
> assume that they are off in the archive_day_rain table as well?  Should i 
> rebuild the daily summaries as part of this cleanup also?
>
> Thanks,
>
> On Thursday, August 15, 2024 at 9:32:44 PM UTC-6 vince wrote:
>
>> Each will be so fast running a couple commands won’t take long..
>>
>> On Thursday, August 15, 2024 at 7:58:36 PM UTC-7 Thomas Carlin wrote:
>>
>>> I also ran the queries below.  Obviously all the archive records that 
>>> relate to the records in my original post need to be updated, but is it 
>>> safe to assume that all of the records that are in these queries will need 
>>> to be updated as well, or is there a case where rainRate > 0 but rain=0.0?
>>>
>>> sqlite> select count(*) from archive where rainRate > 0 and rain=0.0;
>>> count(*)
>>> 4464
>>> sqlite> select count(*) from archive where rainRate > 0 and rain is NULL;
>>> count(*)
>>> 185
>>> sqlite> select count(*) from archive where rain is NULL;
>>> count(*)
>>> 317
>>>
>>> These are easy, I expect, to fix, i expect.  Simply:
>>> update archive set rain=0.0 where rain is NULL;
>>> update archive set rainRate = 0 where rainRate > 0 AND rain=0.0;
>>>
>>> Is there a better way to fix all these things in one shot?
>>>
>>> Thanks again!
>>>
>>> On Thursday, August 15, 2024 at 8:39:06 PM UTC-6 Thomas Carlin wrote:
>>>
 Hi All! I've been playing with some skin modifications on my weather 
 station again, and found some strange values in a few tables.  Most of 
 them 
 i have been able to clean up without any issue, but I feel like there is 
 more to the rainRate table.  

 I found the following table of values, obviously the min and max are 
 false.  I can't however reason out how, if at all the sum, count, wsum 
 relate to the other values.  

 What is the best way to clear out these bad values?  I am guessing on 
 some of the min values, I already ran an update command before pulling 
 this 
 full list, and because i live dangerously, didn't pull a backup first, but 
 i do know that the first 10 entries are 100 percent accurate.

 sqlite> select * from archive_day_rainRate where max >10;
 dateTime|min|mintime|max|maxtime|sum|count|wsum|sumtime

 1605164400|0.0|1605164402|655.3501|1605188100|2136.40082144|287|640920.246432|86100

 1618898400|0.0|1618898403|655.3501|1618930800|26711.4767995|288|8013443.03985|86400

 1643439600|0.0|1643439601|655.3501|1643465400|2551.68191489362|244|765504.574468086|73200

 1645513200|0.0|1645513203|655.3501|1645584600|31106.9906622517|287|9332097.19867551|86100

 1645599600|0.0|1645599603|655.3501|1645680600|8779.61978259878|288|2633885.93477963|86400
 1662703200|0.0|1662703202|655.3501|1662706200|40020.4846440398 
 <(484)%20644-0398>|288|12006145.3932119|86400

 166815|0.0|1668150004|655.3501|1668153600|8030.40075523906|254|2409120.22657172|76200
 1668754800|655.35|1668817498|655.35|1668817498|655.35|1|196605.0|300
 1668841200|655.35|1668856799|655.35|1668856799|1966.05|3|589815.0|900
 1668927600|655.35|1668940798|655.35|1668940798|2621.4|4|786420.0|1200
 1669014000|655.35|1669023898|655.35|1669023898|3932.1|6|1179630.0|1800
 1669100400|655.35|1669109698|655.35|1669109698|4587.45|7|1376235.0|2100
 1669186800|655.35|1669187699|655.35|1669187699|6553.5|10|1966050.0|3000
 1669273200|655.35|1669278900|655.35|1669278900|7208.85|11|2162655.0|3300
 1669359600|655.35|1669365300|655.35|1669365300|7864.2|12|2359260.0|3600
 1669446000|655.35|1669451697|655.35|1669451697|7208.85|11|2162655.0|3300
 1669532400|655.35|1669536899|655.35|1669536899|9830.25|15|2949075.0|4500
 1669618800|655.35|166962|655.35|166962|9174.9|14|2752470.0|4200
 1669705200|655.35|1669719897|655.35|1669719897|9174.9|14|2752470.0|4200

 1669791600|655.35|1669793098|655.35|1669793098|11140.95|17|3342285.0|5100
 1669878000|655.35|1669879500|655.35|1669879500|13107.0|20|3932100.0|6000
 1669964400|655.35|1669966800|655.35|1669966800|10485.6|16|3145680.0|4800
 16700508

[weewx-user] Re: WH57 and gateway 1100

['michael.k...@gmx.at' via weewx-user]

Something like this could solve your rtl_433 instance "problem": 
https://www.rtl-sdr.com/rtl_433-ported-to-esp32-microcontrollers-with-cc1101-or-sx127x-transceiver-chips/
 
and scan for the WH57's (or other) transmissions. Every single lightning 
detected by the WH57 could then be converted to a MQTT message and be 
received by mqttsubcribe. I'm thinking about buying something like 
this https://www.lilygo.cc/products/lora3?_pos=1&_sid=0081a9887&_ss=r but I 
don't see I have enough spare time to play with it.
Letting this little device do the 433/868/915 to MQTT conversion as a 
standalone device, could make things a lot easier.

michael.k...@gmx.at schrieb am Freitag, 2. August 2024 um 21:41:16 UTC+2:

> What a day, what a coincidence. One Thunderstorm after another:
> Vanilla (left) vs. the above config adaptions (right):
> [image: lightnings.png]
> The more lightnings in an archive_interval, the more difference 
> (obviously!) A storm with some 300+ lightnings detected in one hour would 
> be interesting. Thunderstorm season seems coming to an end at my place, 
> anyway, I'm still convinced it's as close as you can get for the given 
> hardware.
> bell...@gmail.com schrieb am Freitag, 2. August 2024 um 18:40:30 UTC+2:
>
>> Thanks for the real world experience on a 10 second polling interval. 
>> I’ll probably give that a go. 
>> Also, thanks for the URL. Looks like an interesting place to explore.
>> rich
>>
>> On Thursday 1 August 2024 at 08:53:34 UTC-4 michael.k...@gmx.at wrote:
>>
>>> I've set my polling rate to 10s, because the WH90 provides data in about 
>>> that frequency. Works without any hiccups in my setup, but I use GW2000 
>>> hardware.
>>> I could again rant about the fact, that the ecowitt don't emit events 
>>> for such data as lightning strikes, like weatherflow devices do. But 
>>> summing everything up, it wouldn't make that big of a difference, because 
>>> of the already mentioned data quality on the sensor's side in the first 
>>> place.
>>> If one really cares about lightning events in a given radius around the 
>>> station, participating 
>>> https://www.blitzortung.org/de/live_lightning_maps.php would be the way 
>>> to go and then write an extension that extracts the relevant data for the 
>>> individual site in realtime.
>>>
>>> bell...@gmail.com schrieb am Donnerstag, 1. August 2024 um 14:39:45 
>>> UTC+2:
>>>
 I thought about increasing the polling frequency. But I’d want to do 
 some performance benchmarking first. Things like how long does it take to 
 send the request and process it - to give me an idea of a reasonable 
 minimum value. I’d also want to check on the load on the system. And 
 ultimately this would just decrease the possibility of multiple strikes in 
 a loop packet or the first strike “belonging” to the previous archive 
 record.
 I also have played around with SDR. I think I could use rtl_433 and 
 MQTTSubscribe to get the data. But my other sensors are frequency 433 and 
 my ecowitt is 915, so I’d have to run another rtl_433 instance. I may 
 still 
 do it, it could be a good MTTSubscribe wiki page.
 At this time neither idea is worth the effort to me and I’ve already 
 got too many “irons in the fire”…..
 Looking forward to what you learn.
 rich

 On Thursday 1 August 2024 at 01:24:04 UTC-4 michael.k...@gmx.at wrote:

> Hi Rich,
>
> that sounds to me as if your approach is as close as you can get, 
> given that the Ecowitt devices only let you poll data in a given 
> Interval. 
> Also, the WH57 is more a "toy" than a sensor, missing out the vast 
> majority 
> of lightning strikes, and mine is set to the maximum sensitivity (but not 
> indoor), and it often misses lightnings that are within less than 3km. 
> Anyway, as I am running a couple of Ecowitt stations in parallel, I'll 
> configure one of them the way you described here and compare the one to 
> the 
> other. Last night would have delivered good data:
> [image: The weather in AT, Salzburg, Hallein, Rif.png]
>
> bell...@gmail.com schrieb am Donnerstag, 1. August 2024 um 01:52:27 
> UTC+2:
>
>> I finally had some time to experiment with my WH57. Here is what I 
>> ended up doing.
>> I have the driver polling the 1100 every 20 seconds and my archive 
>> interval is 5 minutes.
>>
>> ‘Out of the box’ the number of strikes in an archive interval is 
>> persisted and the distance from the last strike, even if no strikes 
>> occurred in the interval. Like many others, I only wanted the distance 
>> if a 
>> strike occurred. In the [StdCalibrate][[Corrections]] I added the 
>> following.
>> lightning_distance = lightning_distance if lightning_strike_count and 
>> lightning_strike_count > 0 else None
>> This checks that the loop packet field lightning_strike_count has a 
>> value and it is greater th

[weewx-user] Re: WH57 and gateway 1100

['michael.k...@gmx.at' via weewx-user]

What a day, what a coincidence. One Thunderstorm after another:
Vanilla (left) vs. the above config adaptions (right):
[image: lightnings.png]
The more lightnings in an archive_interval, the more difference 
(obviously!) A storm with some 300+ lightnings detected in one hour would 
be interesting. Thunderstorm season seems coming to an end at my place, 
anyway, I'm still convinced it's as close as you can get for the given 
hardware.
bell...@gmail.com schrieb am Freitag, 2. August 2024 um 18:40:30 UTC+2:

> Thanks for the real world experience on a 10 second polling interval. I’ll 
> probably give that a go. 
> Also, thanks for the URL. Looks like an interesting place to explore.
> rich
>
> On Thursday 1 August 2024 at 08:53:34 UTC-4 michael.k...@gmx.at wrote:
>
>> I've set my polling rate to 10s, because the WH90 provides data in about 
>> that frequency. Works without any hiccups in my setup, but I use GW2000 
>> hardware.
>> I could again rant about the fact, that the ecowitt don't emit events for 
>> such data as lightning strikes, like weatherflow devices do. But summing 
>> everything up, it wouldn't make that big of a difference, because of the 
>> already mentioned data quality on the sensor's side in the first place.
>> If one really cares about lightning events in a given radius around the 
>> station, participating 
>> https://www.blitzortung.org/de/live_lightning_maps.php would be the way 
>> to go and then write an extension that extracts the relevant data for the 
>> individual site in realtime.
>>
>> bell...@gmail.com schrieb am Donnerstag, 1. August 2024 um 14:39:45 
>> UTC+2:
>>
>>> I thought about increasing the polling frequency. But I’d want to do 
>>> some performance benchmarking first. Things like how long does it take to 
>>> send the request and process it - to give me an idea of a reasonable 
>>> minimum value. I’d also want to check on the load on the system. And 
>>> ultimately this would just decrease the possibility of multiple strikes in 
>>> a loop packet or the first strike “belonging” to the previous archive 
>>> record.
>>> I also have played around with SDR. I think I could use rtl_433 and 
>>> MQTTSubscribe to get the data. But my other sensors are frequency 433 and 
>>> my ecowitt is 915, so I’d have to run another rtl_433 instance. I may still 
>>> do it, it could be a good MTTSubscribe wiki page.
>>> At this time neither idea is worth the effort to me and I’ve already got 
>>> too many “irons in the fire”…..
>>> Looking forward to what you learn.
>>> rich
>>>
>>> On Thursday 1 August 2024 at 01:24:04 UTC-4 michael.k...@gmx.at wrote:
>>>
 Hi Rich,

 that sounds to me as if your approach is as close as you can get, given 
 that the Ecowitt devices only let you poll data in a given Interval. Also, 
 the WH57 is more a "toy" than a sensor, missing out the vast majority of 
 lightning strikes, and mine is set to the maximum sensitivity (but not 
 indoor), and it often misses lightnings that are within less than 3km. 
 Anyway, as I am running a couple of Ecowitt stations in parallel, I'll 
 configure one of them the way you described here and compare the one to 
 the 
 other. Last night would have delivered good data:
 [image: The weather in AT, Salzburg, Hallein, Rif.png]

 bell...@gmail.com schrieb am Donnerstag, 1. August 2024 um 01:52:27 
 UTC+2:

> I finally had some time to experiment with my WH57. Here is what I 
> ended up doing.
> I have the driver polling the 1100 every 20 seconds and my archive 
> interval is 5 minutes.
>
> ‘Out of the box’ the number of strikes in an archive interval is 
> persisted and the distance from the last strike, even if no strikes 
> occurred in the interval. Like many others, I only wanted the distance if 
> a 
> strike occurred. In the [StdCalibrate][[Corrections]] I added the 
> following.
> lightning_distance = lightning_distance if lightning_strike_count and 
> lightning_strike_count > 0 else None
> This checks that the loop packet field lightning_strike_count has a 
> value and it is greater than 0. Checking that the field has a value is 
> important because the first loop packet after starting WeeWX sets it to 
> None.
>
> Persisting the last strike in an archive interval is nice, but I also 
> wanted to persist the closest. I also figured if I was capturing the last 
> strike, I might as well capture the first strike. I also decided to 
> capture 
> the time of the first and last strike. (Note, without writing some code I 
> could not figure out a way to capture the time of the min (closest) 
> strike.
>
> I also decided that the lightning_distance field would persist the 
> average distance to the strikes in the archive period. I did this for a 
> couple of reasons. First, for more consistent naming conventions. Second, 
> it would easily work wi

[weewx-user] Re: WH57 and gateway 1100

['michael.k...@gmx.at' via weewx-user]

I've set up the new test service after 20:00 CEST(18:00 UTC), so comparing 
only makes sense for data after the change. But more thunderstorms are 
predicted for the coming hours. :)

michael.k...@gmx.at schrieb am Donnerstag, 1. August 2024 um 20:21:55 UTC+2:

> I've set up my test installation with the settings above: 
> https://kainzbauer.net/weather/Test/Rif/en/index.html
>
> You can compare the lightning chart with the "vanilla" installation here: 
> https://kainzbauer.net/weather/Rif/en/index.html
>
> michael.k...@gmx.at schrieb am Donnerstag, 1. August 2024 um 14:53:34 
> UTC+2:
>
>> I've set my polling rate to 10s, because the WH90 provides data in about 
>> that frequency. Works without any hiccups in my setup, but I use GW2000 
>> hardware.
>> I could again rant about the fact, that the ecowitt don't emit events for 
>> such data as lightning strikes, like weatherflow devices do. But summing 
>> everything up, it wouldn't make that big of a difference, because of the 
>> already mentioned data quality on the sensor's side in the first place.
>> If one really cares about lightning events in a given radius around the 
>> station, participating 
>> https://www.blitzortung.org/de/live_lightning_maps.php would be the way 
>> to go and then write an extension that extracts the relevant data for the 
>> individual site in realtime.
>>
>> bell...@gmail.com schrieb am Donnerstag, 1. August 2024 um 14:39:45 
>> UTC+2:
>>
>>> I thought about increasing the polling frequency. But I’d want to do 
>>> some performance benchmarking first. Things like how long does it take to 
>>> send the request and process it - to give me an idea of a reasonable 
>>> minimum value. I’d also want to check on the load on the system. And 
>>> ultimately this would just decrease the possibility of multiple strikes in 
>>> a loop packet or the first strike “belonging” to the previous archive 
>>> record.
>>> I also have played around with SDR. I think I could use rtl_433 and 
>>> MQTTSubscribe to get the data. But my other sensors are frequency 433 and 
>>> my ecowitt is 915, so I’d have to run another rtl_433 instance. I may still 
>>> do it, it could be a good MTTSubscribe wiki page.
>>> At this time neither idea is worth the effort to me and I’ve already got 
>>> too many “irons in the fire”…..
>>> Looking forward to what you learn.
>>> rich
>>>
>>> On Thursday 1 August 2024 at 01:24:04 UTC-4 michael.k...@gmx.at wrote:
>>>
 Hi Rich,

 that sounds to me as if your approach is as close as you can get, given 
 that the Ecowitt devices only let you poll data in a given Interval. Also, 
 the WH57 is more a "toy" than a sensor, missing out the vast majority of 
 lightning strikes, and mine is set to the maximum sensitivity (but not 
 indoor), and it often misses lightnings that are within less than 3km. 
 Anyway, as I am running a couple of Ecowitt stations in parallel, I'll 
 configure one of them the way you described here and compare the one to 
 the 
 other. Last night would have delivered good data:
 [image: The weather in AT, Salzburg, Hallein, Rif.png]

 bell...@gmail.com schrieb am Donnerstag, 1. August 2024 um 01:52:27 
 UTC+2:

> I finally had some time to experiment with my WH57. Here is what I 
> ended up doing.
> I have the driver polling the 1100 every 20 seconds and my archive 
> interval is 5 minutes.
>
> ‘Out of the box’ the number of strikes in an archive interval is 
> persisted and the distance from the last strike, even if no strikes 
> occurred in the interval. Like many others, I only wanted the distance if 
> a 
> strike occurred. In the [StdCalibrate][[Corrections]] I added the 
> following.
> lightning_distance = lightning_distance if lightning_strike_count and 
> lightning_strike_count > 0 else None
> This checks that the loop packet field lightning_strike_count has a 
> value and it is greater than 0. Checking that the field has a value is 
> important because the first loop packet after starting WeeWX sets it to 
> None.
>
> Persisting the last strike in an archive interval is nice, but I also 
> wanted to persist the closest. I also figured if I was capturing the last 
> strike, I might as well capture the first strike. I also decided to 
> capture 
> the time of the first and last strike. (Note, without writing some code I 
> could not figure out a way to capture the time of the min (closest) 
> strike.
>
> I also decided that the lightning_distance field would persist the 
> average distance to the strikes in the archive period. I did this for a 
> couple of reasons. First, for more consistent naming conventions. Second, 
> it would easily work with the Seasons skin. Note, I have no intention of 
> using the additional first, last, and min values in the Seasons skin. I 
> will use my WeeWX-JAS skin to display thes

[weewx-user] Re: WH57 and gateway 1100

['michael.k...@gmx.at' via weewx-user]

I've set up my test installation with the settings above: 
https://kainzbauer.net/weather/Test/Rif/en/index.html

You can compare the lightning chart with the "vanilla" installation 
here: https://kainzbauer.net/weather/Rif/en/index.html

michael.k...@gmx.at schrieb am Donnerstag, 1. August 2024 um 14:53:34 UTC+2:

> I've set my polling rate to 10s, because the WH90 provides data in about 
> that frequency. Works without any hiccups in my setup, but I use GW2000 
> hardware.
> I could again rant about the fact, that the ecowitt don't emit events for 
> such data as lightning strikes, like weatherflow devices do. But summing 
> everything up, it wouldn't make that big of a difference, because of the 
> already mentioned data quality on the sensor's side in the first place.
> If one really cares about lightning events in a given radius around the 
> station, participating 
> https://www.blitzortung.org/de/live_lightning_maps.php would be the way 
> to go and then write an extension that extracts the relevant data for the 
> individual site in realtime.
>
> bell...@gmail.com schrieb am Donnerstag, 1. August 2024 um 14:39:45 UTC+2:
>
>> I thought about increasing the polling frequency. But I’d want to do some 
>> performance benchmarking first. Things like how long does it take to send 
>> the request and process it - to give me an idea of a reasonable minimum 
>> value. I’d also want to check on the load on the system. And ultimately 
>> this would just decrease the possibility of multiple strikes in a loop 
>> packet or the first strike “belonging” to the previous archive record.
>> I also have played around with SDR. I think I could use rtl_433 and 
>> MQTTSubscribe to get the data. But my other sensors are frequency 433 and 
>> my ecowitt is 915, so I’d have to run another rtl_433 instance. I may still 
>> do it, it could be a good MTTSubscribe wiki page.
>> At this time neither idea is worth the effort to me and I’ve already got 
>> too many “irons in the fire”…..
>> Looking forward to what you learn.
>> rich
>>
>> On Thursday 1 August 2024 at 01:24:04 UTC-4 michael.k...@gmx.at wrote:
>>
>>> Hi Rich,
>>>
>>> that sounds to me as if your approach is as close as you can get, given 
>>> that the Ecowitt devices only let you poll data in a given Interval. Also, 
>>> the WH57 is more a "toy" than a sensor, missing out the vast majority of 
>>> lightning strikes, and mine is set to the maximum sensitivity (but not 
>>> indoor), and it often misses lightnings that are within less than 3km. 
>>> Anyway, as I am running a couple of Ecowitt stations in parallel, I'll 
>>> configure one of them the way you described here and compare the one to the 
>>> other. Last night would have delivered good data:
>>> [image: The weather in AT, Salzburg, Hallein, Rif.png]
>>>
>>> bell...@gmail.com schrieb am Donnerstag, 1. August 2024 um 01:52:27 
>>> UTC+2:
>>>
 I finally had some time to experiment with my WH57. Here is what I 
 ended up doing.
 I have the driver polling the 1100 every 20 seconds and my archive 
 interval is 5 minutes.

 ‘Out of the box’ the number of strikes in an archive interval is 
 persisted and the distance from the last strike, even if no strikes 
 occurred in the interval. Like many others, I only wanted the distance if 
 a 
 strike occurred. In the [StdCalibrate][[Corrections]] I added the 
 following.
 lightning_distance = lightning_distance if lightning_strike_count and 
 lightning_strike_count > 0 else None
 This checks that the loop packet field lightning_strike_count has a 
 value and it is greater than 0. Checking that the field has a value is 
 important because the first loop packet after starting WeeWX sets it to 
 None.

 Persisting the last strike in an archive interval is nice, but I also 
 wanted to persist the closest. I also figured if I was capturing the last 
 strike, I might as well capture the first strike. I also decided to 
 capture 
 the time of the first and last strike. (Note, without writing some code I 
 could not figure out a way to capture the time of the min (closest) strike.

 I also decided that the lightning_distance field would persist the 
 average distance to the strikes in the archive period. I did this for a 
 couple of reasons. First, for more consistent naming conventions. Second, 
 it would easily work with the Seasons skin. Note, I have no intention of 
 using the additional first, last, and min values in the Seasons skin. I 
 will use my WeeWX-JAS skin to display these.

 The first thing to do is get the data into these additional fields. I 
 used the [StdCalibrate][[Corrections]] section. I ended up with the 
 following.
 lightning_last_distance = lightning_distance if lightning_strike_count 
 and lightning_strike_count > 0 else None
 lightning_last_det_time = lightning_last_det_time if 
 lightning_strike_

[weewx-user] Re: WH57 and gateway 1100

['michael.k...@gmx.at' via weewx-user]

I've set my polling rate to 10s, because the WH90 provides data in about 
that frequency. Works without any hiccups in my setup, but I use GW2000 
hardware.
I could again rant about the fact, that the ecowitt don't emit events for 
such data as lightning strikes, like weatherflow devices do. But summing 
everything up, it wouldn't make that big of a difference, because of the 
already mentioned data quality on the sensor's side in the first place.
If one really cares about lightning events in a given radius around the 
station, 
participating https://www.blitzortung.org/de/live_lightning_maps.php would 
be the way to go and then write an extension that extracts the relevant 
data for the individual site in realtime.

bell...@gmail.com schrieb am Donnerstag, 1. August 2024 um 14:39:45 UTC+2:

> I thought about increasing the polling frequency. But I’d want to do some 
> performance benchmarking first. Things like how long does it take to send 
> the request and process it - to give me an idea of a reasonable minimum 
> value. I’d also want to check on the load on the system. And ultimately 
> this would just decrease the possibility of multiple strikes in a loop 
> packet or the first strike “belonging” to the previous archive record.
> I also have played around with SDR. I think I could use rtl_433 and 
> MQTTSubscribe to get the data. But my other sensors are frequency 433 and 
> my ecowitt is 915, so I’d have to run another rtl_433 instance. I may still 
> do it, it could be a good MTTSubscribe wiki page.
> At this time neither idea is worth the effort to me and I’ve already got 
> too many “irons in the fire”…..
> Looking forward to what you learn.
> rich
>
> On Thursday 1 August 2024 at 01:24:04 UTC-4 michael.k...@gmx.at wrote:
>
>> Hi Rich,
>>
>> that sounds to me as if your approach is as close as you can get, given 
>> that the Ecowitt devices only let you poll data in a given Interval. Also, 
>> the WH57 is more a "toy" than a sensor, missing out the vast majority of 
>> lightning strikes, and mine is set to the maximum sensitivity (but not 
>> indoor), and it often misses lightnings that are within less than 3km. 
>> Anyway, as I am running a couple of Ecowitt stations in parallel, I'll 
>> configure one of them the way you described here and compare the one to the 
>> other. Last night would have delivered good data:
>> [image: The weather in AT, Salzburg, Hallein, Rif.png]
>>
>> bell...@gmail.com schrieb am Donnerstag, 1. August 2024 um 01:52:27 
>> UTC+2:
>>
>>> I finally had some time to experiment with my WH57. Here is what I ended 
>>> up doing.
>>> I have the driver polling the 1100 every 20 seconds and my archive 
>>> interval is 5 minutes.
>>>
>>> ‘Out of the box’ the number of strikes in an archive interval is 
>>> persisted and the distance from the last strike, even if no strikes 
>>> occurred in the interval. Like many others, I only wanted the distance if a 
>>> strike occurred. In the [StdCalibrate][[Corrections]] I added the following.
>>> lightning_distance = lightning_distance if lightning_strike_count and 
>>> lightning_strike_count > 0 else None
>>> This checks that the loop packet field lightning_strike_count has a 
>>> value and it is greater than 0. Checking that the field has a value is 
>>> important because the first loop packet after starting WeeWX sets it to 
>>> None.
>>>
>>> Persisting the last strike in an archive interval is nice, but I also 
>>> wanted to persist the closest. I also figured if I was capturing the last 
>>> strike, I might as well capture the first strike. I also decided to capture 
>>> the time of the first and last strike. (Note, without writing some code I 
>>> could not figure out a way to capture the time of the min (closest) strike.
>>>
>>> I also decided that the lightning_distance field would persist the 
>>> average distance to the strikes in the archive period. I did this for a 
>>> couple of reasons. First, for more consistent naming conventions. Second, 
>>> it would easily work with the Seasons skin. Note, I have no intention of 
>>> using the additional first, last, and min values in the Seasons skin. I 
>>> will use my WeeWX-JAS skin to display these.
>>>
>>> The first thing to do is get the data into these additional fields. I 
>>> used the [StdCalibrate][[Corrections]] section. I ended up with the 
>>> following.
>>> lightning_last_distance = lightning_distance if lightning_strike_count 
>>> and lightning_strike_count > 0 else None
>>> lightning_last_det_time = lightning_last_det_time if 
>>> lightning_strike_count and lightning_strike_count > 0 else None
>>>
>>> lightning_first_distance = lightning_distance if lightning_strike_count 
>>> and lightning_strike_count > 0 else None
>>> lightning_first_det_time = lightning_last_det_time if 
>>> lightning_strike_count and lightning_strike_count > 0 else None
>>>
>>> lightning_min_distance = lightning_distance if lightning_strike_count 
>>> and lightning_strike_count > 0 else None
>>>
>>>

[weewx-user] Re: WH57 and gateway 1100

['michael.k...@gmx.at' via weewx-user]

Hi Rich,

that sounds to me as if your approach is as close as you can get, given 
that the Ecowitt devices only let you poll data in a given Interval. Also, 
the WH57 is more a "toy" than a sensor, missing out the vast majority of 
lightning strikes, and mine is set to the maximum sensitivity (but not 
indoor), and it often misses lightnings that are within less than 3km. 
Anyway, as I am running a couple of Ecowitt stations in parallel, I'll 
configure one of them the way you described here and compare the one to the 
other. Last night would have delivered good data:
[image: The weather in AT, Salzburg, Hallein, Rif.png]

bell...@gmail.com schrieb am Donnerstag, 1. August 2024 um 01:52:27 UTC+2:

> I finally had some time to experiment with my WH57. Here is what I ended 
> up doing.
> I have the driver polling the 1100 every 20 seconds and my archive 
> interval is 5 minutes.
>
> ‘Out of the box’ the number of strikes in an archive interval is persisted 
> and the distance from the last strike, even if no strikes occurred in the 
> interval. Like many others, I only wanted the distance if a strike 
> occurred. In the [StdCalibrate][[Corrections]] I added the following.
> lightning_distance = lightning_distance if lightning_strike_count and 
> lightning_strike_count > 0 else None
> This checks that the loop packet field lightning_strike_count has a value 
> and it is greater than 0. Checking that the field has a value is important 
> because the first loop packet after starting WeeWX sets it to None.
>
> Persisting the last strike in an archive interval is nice, but I also 
> wanted to persist the closest. I also figured if I was capturing the last 
> strike, I might as well capture the first strike. I also decided to capture 
> the time of the first and last strike. (Note, without writing some code I 
> could not figure out a way to capture the time of the min (closest) strike.
>
> I also decided that the lightning_distance field would persist the average 
> distance to the strikes in the archive period. I did this for a couple of 
> reasons. First, for more consistent naming conventions. Second, it would 
> easily work with the Seasons skin. Note, I have no intention of using the 
> additional first, last, and min values in the Seasons skin. I will use my 
> WeeWX-JAS skin to display these.
>
> The first thing to do is get the data into these additional fields. I used 
> the [StdCalibrate][[Corrections]] section. I ended up with the following.
> lightning_last_distance = lightning_distance if lightning_strike_count and 
> lightning_strike_count > 0 else None
> lightning_last_det_time = lightning_last_det_time if 
> lightning_strike_count and lightning_strike_count > 0 else None
>
> lightning_first_distance = lightning_distance if lightning_strike_count 
> and lightning_strike_count > 0 else None
> lightning_first_det_time = lightning_last_det_time if 
> lightning_strike_count and lightning_strike_count > 0 else None
>
> lightning_min_distance = lightning_distance if lightning_strike_count and 
> lightning_strike_count > 0 else None
>
> lightning_distance = lightning_distance if lightning_strike_count and 
> lightning_strike_count > 0 else None
>
> With these ‘corrections’, WeeWX now accumulates the lightning data into 
> multiple fields. In the loop packet, all of the distance fields have the 
> same value. Same with the time fields. Using the accumulator function, the 
> first, last, and min values can be extracted and put into the archive 
> record.
>
> My [Accumulator] section looks like the following.
> # Additional lightning data, note lightning_last_det_time is below in 
> the GW1000 section
> [[lightning_last_distance]]
> extractor = last
> [[lightning_first_distance]]
> extractor = first
> [[lightning_first_det_time]]
> extractor = first
> [[lightning_min_distance]]
> extractor = min
> # 'override' the setting that GW1000 driver has (I decided to set it 
> here and delete from the GW1000 section)
> [[lightning_distance]]
> extractor = avg
>
> Next, I used weectl database to add the new fields to the database.
>
> Finally I updated the bin/user/extensions.py with the units for the new 
> fields.
> import weewx.units
> weewx.units.obs_group_dict['lightning_last_distance'] = 'group_distance'
> weewx.units.obs_group_dict['lightning_last_det_time'] = 'group_time'
> weewx.units.obs_group_dict['lightning_first_distance'] = 'group_distance'
> weewx.units.obs_group_dict['lightning_first_det_time'] = 'group_time'
> weewx.units.obs_group_dict['lightning_min_distance'] = 'group_distance'
>
> Known limitations.
> If there is more than one strike is in a loop packet interval (20 
> seconds), the loop packet will have the number of strikes and the packet 
> will have the distance to and time of the last strike.
>
> Now to get some real data to experiment with displaying the data…
> rich
>

-- 
You received this message because you are subscrib

Re: [weewx-user] Re: It struck me like a lightning

['michael.k...@gmx.at' via weewx-user]

It was!

I still don't know where exactly, and what, the lightning struck, that 
caused the damage. It was about 100m away. Anyway, it literally burned one 
PoE injector, leaving scorch marks where the enclosure has it's opening for 
resetting, and the wall mount clip, too:

[image: PoE.jpg.jpeg]
Chuck Rhode schrieb am Dienstag, 30. Juli 2024 um 02:56:44 UTC+2:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mon, 29 Jul 2024 11:11:42 -0700 (PDT)
> Karen K  wrote:
>
> > Heftig.
>
> > (I don't know how to say in English.)
>
> It's heavy, man!
>
> - -- 
> .. Be Seeing You,
> .. Chuck Rhode, Sheboygan, WI, USA
> .. Weather: http://LacusVeris.com/WX
> .. 79° — Wind NW 3 mph — Sky partly cloudy.
>
> -BEGIN PGP SIGNATURE-
>
> iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCZqg6IAAKCRBg2/xipKOW
> UrICAJ4szofYNmlXQAhEgYY1jdIE2TuyngCePVBkCJsv1TVaz4vXp6YfIBXqdxg=
> =kWAi
> -END PGP SIGNATURE-
>

-- 
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/76c4cd33-039c-4520-a8d9-a2b8325f7f15n%40googlegroups.com.

[weewx-user] WS28xx - unattended service restarts

['michael.k...@gmx.at' via weewx-user]

Using the WS28xx, after a restart of weewxd, I most often have to push the 
SET-button on the console to sync the console and transceiver.

Reading the docs of the driver, I am not sure, what happens, if I don't 
push the SET-button and wait for the next full hour: will the devices then 
sync, and behave just like when pushing the SET-button, or will it receive 
the next value after another hour?

Is there any other way to get the devices synchronized immediately, other 
than attaching a remote control to the SET-button?

-- 
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/832924fc-239f-43ca-afe5-cd6df4847e1cn%40googlegroups.com.

Re: [weewx-user] Installation of extension fails for pip installed WeeWX but works for apt installed WeeWX

['michael.k...@gmx.at' via weewx-user]

bin/user?

Karen K schrieb am Dienstag, 16. Juli 2024 um 07:58:19 UTC+2:

> The result is: If the virtual environment (venv) is used, weectl must not 
> be invoked by sudo. Without sudo, the correct paths are found. Thank you, 
> Tom, for pointing to this.
>
> Additional question: Where can I place a script that can be invoked by the 
> user from the command line in such an environment? 
>
>

-- 
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/7cc7ba3b-2bc7-48c4-b3bb-3f6373a4a245n%40googlegroups.com.

[weewx-user] Re: weewx.conf - some questions

['michael.k...@gmx.at' via weewx-user]

The above configurations, as is, has no effects. You can specify 
TimeFormats, if you are not pleased with the default ones.

It's always worth to check the 
config: 
https://weewx.com/docs/5.0/custom/custom-reports/?h=timeformats#date-and-time-formats-for-tags
The authors invested a lot of time documenting all the features. Read it, 
you should then be able to answer the above question yourself. If questions 
remain, I'm confident you'll get detailed support here.

Monica Mulholland schrieb am Sonntag, 14. Juli 2024 um 09:32:16 UTC+2:

>  TimeFormats
> # day= %H:%M
> # week   = %H:%M on %A
> # month  = %d-%b-%Y %H:%M
> # year   = %d-%b-%Y %H:%M
> # rainyear   = %d-%b-%Y %H:%M
> # current= %d-%b-%Y %H:%M
> # ephem_day  = %H:%M
> # ephem_year = %d-%b-%Y %H:%M
> # The following line is used to keep the above lines 
> indented
> # properly. It can be ignored.
> unused = unused
>
> This from the weewx.conf in 5.1. Is this correct? In my old weewx.conf:
>
> I see
>
> hour = %H:%M
>
> day = %X
>
> etcwhich seems to make more sense to me than the abovewhat am I 
> missing?
>
>
>

-- 
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/5e4e2bce-2025-4e87-a0b3-7a55bb4dbe5cn%40googlegroups.com.

Re: [weewx-user] WeeWX v5.1 is available

['michael.k...@gmx.at' via weewx-user]

Yes, check https://github.com/weewx/weewx/wiki/Help!-Posting-to-weewx-user

Igor Dobrača schrieb am Samstag, 6. Juli 2024 um 09:46:39 UTC+2:

> After upgrade to 5.1 weewx isn't getting data from Vantage Vue station. 
> Any idea what to check?
>
> Dana petak, 5. srpnja 2024. u 17:31:35 UTC+2 korisnik michael.k...@gmx.at 
> napisao je:
>
>> pip upgrade 
>> 5.0.2 => 5.1.0
>> 5.1.0b4 => 5.1.0
>> both worked without any issues. Thank you!
>>
>> Tom Keffer schrieb am Freitag, 5. Juli 2024 um 01:48:27 UTC+2:
>>
>>> Matthew just pointed out to me that you are using stretch (Debian 9). 
>>> Package installs only work with Debian 10 or later. See the Debian 
>>> Quick Start guide .
>>>
>>> You'll have to either stick with V4, upgrade your Debian, or do a pip 
>>> install.
>>>
>>> On Thu, Jul 4, 2024 at 4:06 PM dunbrokin  wrote:
>>>
 Thank you for thatbut


 pi@WeatherPi:~ $ sudo apt install -y wget gnupg
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 gnupg is already the newest version (2.1.18-8~deb9u4).
 wget is already the newest version (1.18-5+deb9u3).
 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
 pi@WeatherPi:~ $ wget -qO - https://weewx.com/keys.html | \
 > sudo gpg --dearmor --output /etc/apt/trusted.gpg.d/weewx.gpg
 pi@WeatherPi:~ $ echo "deb [arch=all] https://weewx.com/apt/python3 
 buster main" | \
 > sudo tee /etc/apt/sources.list.d/weewx.list
 deb [arch=all] https://weewx.com/apt/python3 buster main

 pi@WeatherPi:~ $ sudo apt update
 Hit:1 http://archive.raspberrypi.org/debian stretch InRelease
 Ign:2 http://raspbian.raspberrypi.org/raspbian stretch InRelease
 Err:3 http://raspbian.raspberrypi.org/raspbian stretch Release 
 
   404  Not Found [IP: 93.93.128.193 80]
 Get:4 https://weewx.com/apt/python3 buster InRelease [4,251 B]
 Get:5 https://weewx.com/apt/python3 buster/main all Packages [5,644 B]
 Reading package lists... Done   
 E: The repository 'http://raspbian.raspberrypi.org/raspbian stretch 
 Release' does no longer have a Release file.
 N: Updating from such a repository can't be done securely, and is 
 therefore disabled by default.
 N: See apt-secure(8) manpage for repository creation and user 
 configuration details.

 pi@WeatherPi:~ $ sudo apt install weewx
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 Some packages could not be installed. This may mean that you have
 requested an impossible situation or if you are using the unstable
 distribution that some required packages have not yet been created
 or been moved out of Incoming.
 The following information may help to resolve the situation:

 The following packages have unmet dependencies:
  weewx : Depends: python3 (>= 3.7) but 3.5.3-1 is to be installed or
   python (>= 3.7) but 2.7.13-2 is to be installed
  Depends: python3-cheetah but it is not installable
 E: Unable to correct problems, you have held broken packages.
 pi@WeatherPi:~ $ 



 On Fri, Jul 5, 2024 at 10:46 AM Tom Keffer  wrote:

> Be sure to see the Upgrade Guide  
> for how to upgrade! 
>
> The major new feature is the ability to specify locales on a 
> report-by-report basis. For example, you can feature both French and UK 
> locales on your website.
>
> Also, a few bug fixes.
>
> Complete change log below
>
> --
>
> 5.1.0 07/04/2024
>
> If option lang is a valid locale, then it will be used to change 
> locale as well as language. If it is not a valid locale, then the user's 
> default locale will be used. For example, if lang=de_DE.utf8, then 
> the German locale will be used. This allows locales to be set on a 
> report-by-report basis. Addresses issue #867 
> .
>
> Allow country codes to be used in addition to a language code. For 
> example, zh_CN would specify Chinese language, mainland China 
> (Simplified Chinese), while zh_TW would specify Chinese language, 
> Taiwan (Traditional Chinese).
>
> Added translation file for Simplified Chinese (zh_CN.conf). Thanks to 
> user Kranz!
>
> Allow the utility weectl import to update old records in addition to 
> importing new records. PR #930 
> .
>
> Include the effective user and group to the log. PR #934 
> .
>
> Allow extra command line options to be passed on to rsync. Fixes 
> issue #95

Re: [weewx-user] WeeWX v5.1 is available

['michael.k...@gmx.at' via weewx-user]

pip upgrade 
5.0.2 => 5.1.0
5.1.0b4 => 5.1.0
both worked without any issues. Thank you!

Tom Keffer schrieb am Freitag, 5. Juli 2024 um 01:48:27 UTC+2:

> Matthew just pointed out to me that you are using stretch (Debian 9). 
> Package installs only work with Debian 10 or later. See the Debian Quick 
> Start guide .
>
> You'll have to either stick with V4, upgrade your Debian, or do a pip 
> install.
>
> On Thu, Jul 4, 2024 at 4:06 PM dunbrokin  wrote:
>
>> Thank you for thatbut
>>
>>
>> pi@WeatherPi:~ $ sudo apt install -y wget gnupg
>> Reading package lists... Done
>> Building dependency tree   
>> Reading state information... Done
>> gnupg is already the newest version (2.1.18-8~deb9u4).
>> wget is already the newest version (1.18-5+deb9u3).
>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> pi@WeatherPi:~ $ wget -qO - https://weewx.com/keys.html | \
>> > sudo gpg --dearmor --output /etc/apt/trusted.gpg.d/weewx.gpg
>> pi@WeatherPi:~ $ echo "deb [arch=all] https://weewx.com/apt/python3 
>> buster main" | \
>> > sudo tee /etc/apt/sources.list.d/weewx.list
>> deb [arch=all] https://weewx.com/apt/python3 buster main
>>
>> pi@WeatherPi:~ $ sudo apt update
>> Hit:1 http://archive.raspberrypi.org/debian stretch InRelease
>> Ign:2 http://raspbian.raspberrypi.org/raspbian stretch InRelease
>> Err:3 http://raspbian.raspberrypi.org/raspbian stretch Release   
>>   
>>   404  Not Found [IP: 93.93.128.193 80]
>> Get:4 https://weewx.com/apt/python3 buster InRelease [4,251 B]
>> Get:5 https://weewx.com/apt/python3 buster/main all Packages [5,644 B]
>> Reading package lists... Done   
>> E: The repository 'http://raspbian.raspberrypi.org/raspbian stretch 
>> Release' does no longer have a Release file.
>> N: Updating from such a repository can't be done securely, and is 
>> therefore disabled by default.
>> N: See apt-secure(8) manpage for repository creation and user 
>> configuration details.
>>
>> pi@WeatherPi:~ $ sudo apt install weewx
>> Reading package lists... Done
>> Building dependency tree   
>> Reading state information... Done
>> Some packages could not be installed. This may mean that you have
>> requested an impossible situation or if you are using the unstable
>> distribution that some required packages have not yet been created
>> or been moved out of Incoming.
>> The following information may help to resolve the situation:
>>
>> The following packages have unmet dependencies:
>>  weewx : Depends: python3 (>= 3.7) but 3.5.3-1 is to be installed or
>>   python (>= 3.7) but 2.7.13-2 is to be installed
>>  Depends: python3-cheetah but it is not installable
>> E: Unable to correct problems, you have held broken packages.
>> pi@WeatherPi:~ $ 
>>
>>
>>
>> On Fri, Jul 5, 2024 at 10:46 AM Tom Keffer  wrote:
>>
>>> Be sure to see the Upgrade Guide  
>>> for how to upgrade! 
>>>
>>> The major new feature is the ability to specify locales on a 
>>> report-by-report basis. For example, you can feature both French and UK 
>>> locales on your website.
>>>
>>> Also, a few bug fixes.
>>>
>>> Complete change log below
>>>
>>> --
>>>
>>> 5.1.0 07/04/2024
>>>
>>> If option lang is a valid locale, then it will be used to change locale 
>>> as well as language. If it is not a valid locale, then the user's default 
>>> locale will be used. For example, if lang=de_DE.utf8, then the German 
>>> locale will be used. This allows locales to be set on a report-by-report 
>>> basis. Addresses issue #867 .
>>>
>>> Allow country codes to be used in addition to a language code. For 
>>> example, zh_CN would specify Chinese language, mainland China 
>>> (Simplified Chinese), while zh_TW would specify Chinese language, 
>>> Taiwan (Traditional Chinese).
>>>
>>> Added translation file for Simplified Chinese (zh_CN.conf). Thanks to 
>>> user Kranz!
>>>
>>> Allow the utility weectl import to update old records in addition to 
>>> importing new records. PR #930 
>>> .
>>>
>>> Include the effective user and group to the log. PR #934 
>>> .
>>>
>>> Allow extra command line options to be passed on to rsync. Fixes issue 
>>> #951 .
>>>
>>> Return False from XTypes function has_data() if the type cannot be 
>>> calculated. Thanks to Rich Bell! PR #929 
>>> .
>>>
>>> Allow calculation of xtype aggregate with missing constituents. Related 
>>> to PR #929 .
>>>
>>> Fix bug in tag $tag.obstype where obstype is an XType that cannot be 
>>> calculated. Related to PR #929 .
>>>
>>> Fix bug that caused the loop_on_init setting in

Re: [weewx-user] External Website not updating.

['michael.k...@gmx.at' via weewx-user]

The FTP server login failed (530 Login authentication failed) for your user 
and password. Either you accidentally changed the credentials in your 
config, or the account expired or the provider changed something else that 
causes this error. Check, if you can log in using your credentials with 
another FTP-client, if that works, double check your credentials in 
weewx.conf. If that doesn't work, ask your provider for the reason you 
cannot login.

Monica Mulholland schrieb am Freitag, 5. Juli 2024 um 05:47:28 UTC+2:

> Apologies! Will do!
>
> On Friday 5 July 2024 at 12:27:41 UTC+12 Tom Keffer wrote:
>
>> You need to let it run for at least an archive interval. Your archive 
>> interval has been set to 10 minutes, and you let it run for only 6 minutes. 
>> Patience!
>>
>>
>>
>> On Thu, Jul 4, 2024 at 5:20 PM Monica Mulholland  
>> wrote:
>>
>>> This is what is in sources.list.nothing in sources.conf
>>>
>>> On Friday 5 July 2024 at 11:35:34 UTC+12 Tom Keffer wrote:
>>>
 Sorry, I blew it. For the IP error, you want to take a look in 
 /etc/apt/sources.conf.

 On Thu, Jul 4, 2024 at 4:20 PM Monica Mulholland  
 wrote:

> Thank you for that!
>
> Presumably I use the last one on the list (why are there twoand 
> why are there so many?...I would have imagined that only the latest one 
> was 
> kept?!?!)
>
> On Friday 5 July 2024 at 11:04:13 UTC+12 Tom Keffer wrote:
>
>> Nothing has changed in WeeWX that would cause this. And, frankly, the 
>> message from your hosting company is completely useless.
>>
>> To diagnose we would need to see the log. See the wiki article *Help! 
>> Posting to weewx-user 
>> * for 
>> instructions on getting a good copy of the log.
>>
>> Security updates of 'stretch' were discontinued about 4 years ago. 
>> That may explain why you are getting the IP not found error. It's also 
>> possible that your /etc/sources.list file uses IP addresses, rather than 
>> domain names, and that address has been retired. In any case, that's a 
>> Debian issue, not a WeeWX issue.
>>
>> -tk
>>
>> On Thu, Jul 4, 2024 at 3:42 PM Monica Mulholland  
>> wrote:
>>
>>> I am running Weewx on a RPi3 and have been for a number of years. It 
>>> recently stopped updating the external website - see attached.
>>>
>>> On investigation, I found that the internal website was working 
>>> perfectly - see attached.
>>>
>>> I complained to my company hosting my website and this is what they 
>>> have to say - see attachment.
>>>
>>> Has anything changed in Weewx that might have caused this.
>>>
>>> As an aside, for the last couple of years I have been getting this 
>>> message when updating my Pi.
>>>
>>> pi@WeatherPi:~ $ sudo apt-get update && sudo apt-get upgrade
>>> Hit:1 http://weewx.com/apt squeeze InRelease
>>> Ign:2 http://raspbian.raspberrypi.org/raspbian stretch InRelease   
>>>   
>>> Hit:3 http://archive.raspberrypi.org/debian stretch InRelease   
>>>  
>>> Err:4 http://raspbian.raspberrypi.org/raspbian stretch Release 
>>> 
>>>   404  Not Found [IP: 93.93.128.193 80]
>>> Reading package lists... Done  
>>> E: The repository 'http://raspbian.raspberrypi.org/raspbian stretch 
>>> Release' does no longer have a Release file.
>>> N: Updating from such a repository can't be done securely, and is 
>>> therefore disabled by default.
>>> N: See apt-secure(8) manpage for repository creation and user 
>>> configuration details.
>>> pi@WeatherPi:~ $ 
>>>
>>> Does this have any bearing? It should not have because I have been 
>>> getting the message for quite a while and the failure to update the 
>>> site 
>>> has only happened recently.
>>>
>>> I am a bit mystified as to what is going on. Any help would be much 
>>> appreciated.
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, 
>>> send an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/86231e99-aea3-4380-8d9a-c5e146aa2a75n%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+...@googlegroups.com.
>
 To view thi

Re: [weewx-user] Ecowitt Gateway Driver, WH57 and lightning data [4]

['michael.k...@gmx.at' via weewx-user]

med and the data stored following a suitable 
>> data model.
>>
>> "As far as I know, there is no such event mechanism from the console to 
>> other devices, messages queues, whatever."
>>
>> There is - in the context of Ecowitt IoT devices.
>> There you can trigger IoT devices based on sensor readings, single or 
>> combined.
>> This general process could be used ...
>>
>> And, there may be something more in the bush - originally meant for the 
>> communication with IoT devices.
>> As I don't know the full API description yet, it's too early to make 
>> reliable statements.
>>
>> I think what would be helpful (at least for me to understand better - 
>> maybe I simply don't get the point ... - maybe it was already all clearly 
>> presented but that portion got cut off from the thread) to have a draft 
>> architecture of what exactly you want to do - not only verbalized but also 
>> drawn in a picture.
>> And then describe for which steps/areas/segments you think you already 
>> have tools/solutions and for what not. 
>> 1. to see the gaps
>> 2. maybe to revise the whole architecture in a target oriented manner
>>
>> and then see what's already available and what needs to be added
>>
>> Having been working as an IT and network architect, I'm not so much into 
>> a Lego block approach but in a more structured approach.
>> Big picture first - and then drill down in a result- and technology-open 
>> mindset
>>
>> A picture is worth 1000 words they say - and in my experience this is 
>> very true
>> On 03.06.2024 17:56, 'michael.k...@gmx.at' via weewx-user wrote:
>>
>> Rainer, the WH57 sends lightning data as the lighning is detected, the 
>> console shows this data immediately. 
>> I observed this mutliple times:
>>
>> You see the lightning out there, the LED of the WH57 flashes red, the 
>> counter on the console goes up, the distance is also updated. If there is a 
>> lightning just a few seconds later, the same game again. Even when polling 
>> the console API in an interval < 79s, you get the lightning data updates 
>> more frequently than 79s.
>>
>>
>> Your information does not fit the observed reality. Whats true is that 
>> you need to store lightning data in a different format, to calculate a 
>> meaningful value for the archive record. Something like the count per 
>> interval and a kind of weighted average for the distance. It exists for the 
>> Tempest, which transmits lightning data using UDP as it detects a 
>> lightning. Apart from the other data which is transmitted in a constant 
>> interval.
>> Rainer Lang schrieb am Montag, 3. Juni 2024 um 17:25:34 UTC+2:
>>
>>> "If there is a possibility to extract a singled detected lightning event 
>>> and 
>>> > it's data with standard devices, is another story. If so, I'd see the 
>>> point 
>>> > of doing so. At least the minimal distance and weighted average 
>>> distance 
>>> > are interesting values to me. I doubt it is possible doing this with 
>>> the 
>>> > "Ecowitt Gateway Driver", I have no idea if it is possible with the 
>>> > interceptor driver and a WH2551, it should be possible using SDR."
>>>
>>> what part of transmitting every 79 seconds has not been understood ?
>>> And the 79 seconds start with the first detected discharge.
>>>
>>> Why would SDR receive more and more often ? Magic SDR ?
>>> SDR is nothing else but a radio receiver as is a console.
>>> Just by changing the console the sensor won't post faster.
>>>
>>> And it's not an Acurite chipset (maybe some Acurite device uses the same 
>>> chip);
>>> it's an AS3935 - before starting wild speculations I would read the 
>>> specifications and see if the chip can be animated to provide data more 
>>> frequently.
>>> Then you can try your luck modifying the sensor firmware if that's 
>>> possible and not limited by the chip itself ...
>>>
>>> And have a look what exactly the chip provides/can provide ...
>>> check if it provides such things like minimal distance, weighted 
>>> distance etc. 
>>> Nice wishlist, but as far as I have understood the specifications, it 
>>> doesn't do that.
>>> Admittedly, I'm not an expert here - somebody else may be able to 
>>> extract more information
>>>
>>> Google can be your friend - look up th

[weewx-user] Re: want to upgrade to 5.0, don't know original install method

['michael.k...@gmx.at' via weewx-user]

"Activate the venv first. Always."

Means: "Activate the specifific venv everytime, you want to run a command 
for the specific installation in the venv, and the venv isn't active."

Mark Hahn schrieb am Dienstag, 25. Juni 2024 um 03:48:26 UTC+2:

> >  What are 'all' the commands you executed ? 
> Are you serious?  I've been working on this for hours.
>
> > You should not need to 'change the location inside that script' if you 
> are following the instructions correctly.   
> I followed the pip install to the letter.  See the commands I listed post 
> before last.
>
> > are you installing v5 pip on a clean no-weewx system ?
> Read the thread.  I took michael.k's suggestion.
>
> >  are you upgrading a v4 setup to v5 pip ?
> Read the thread.  I said "I installed weewx long ago (10 yrs?).  It is 
> version   4.10.2"
>
> >  are you upgrading a v4 dpkg to a v5 pip ?
> The subject of the thread is "want to upgrade to 5.0, don't know original 
> install method"
>
> > People have done hundreds (thousands?) of pip installations by now.
> And none had any problems.
>
> On Monday, June 24, 2024 at 6:14:39 PM UTC-7 vince wrote:
>
>> Mark you're going to have to be much less concise please.   What are 
>> 'all' the commands you executed ?  What does the output look like end to 
>> end ?
>>
>> What exactly are you doing ?
>>
>>- are you installing v5 pip on a clean no-weewx system ?
>>- or are you upgrading a v4 setup to v5 pip ?
>>- or are you upgrading a v4 dpkg to a v5 pip ?
>>
>> You should not need to 'change the location inside that script' if you 
>> are following the instructions correctly.   You have to be doing something 
>> different or missing a step or several.  People have done hundreds 
>> (thousands?) of pip installations by now.
>>
>> Lets take a step back and please tell us where you're starting, what 
>> you've done step-by-step, and what each step's output looked like.
>>
>>
>> On Monday, June 24, 2024 at 5:26:07 PM UTC-7 Mark Hahn wrote:
>>
>>> I did ...
>>> # Create the virtual environment python3 -m venv ~/weewx-venv # 
>>> Activate the WeeWX virtual environment source ~/weewx-venv/bin/activate # 
>>> Install WeeWX into the virtual environment python3 -m pip install weewx
>>>
>>> On Monday, June 24, 2024 at 5:23:27 PM UTC-7 Mark Hahn wrote:
>>>
 >  Activate the venv first
 I followed the pip instructions carefully so I'm 99% sure I did "source 
 ~/weewx-venv/bin/activate".

 On Monday, June 24, 2024 at 5:04:16 PM UTC-7 vince wrote:

> You used pip.  Activate the venv first. Always.
>
> On Monday, June 24, 2024 at 5:01:38 PM UTC-7 Mark Hahn wrote:
>
>> As suggested I did a separate install using pip.  It was very quick.   
>> "weectl device --clear-memory" fixed my davis problem.
>>
>> I decided to run the new 5.0. I copied over the conf file.  I didn't 
>> need to copy the db file.  Weewxd works great.
>>
>> But now I want to run it as a daemon.  The pip install instructions 
>> said to use "sh ~/weewx-data/scripts/setup-daemon.sh".  I couldn't 
>> run this because weewx-data is in the .env folder, not in root.  I went 
>> to 
>> the weewx-data in .env and ran /setup-daemon.sh.  I had to change the 
>> location inside that script to also use weewx-data in .env.
>>
>> The daemon install gave no errors but when I run "systemctl start 
>> weewx" I get this error ...
>>
>> /etc/systemd/system/weewx.service:12: Executable "WEEWX_PYTHON" not 
>> found in path 
>> "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
>>  weewx.service: Unit configuration has fatal error, unit will not be 
>> started.
>>
>> Can anyone tell me how to fix this?  Meanwhile I'll run in not as a 
>> daemon but obviously I've got to fix this.
>> On Monday, June 24, 2024 at 11:49:27 AM UTC-7 michael.k...@gmx.at 
>> wrote:
>>
>>>
>>> I'd recommend you to leave your old installation untouched, install 
>>> weewx5 the pip way in a venv together with your extensions, a copy of 
>>> your 
>>> database and config and see if it works out. When the new installation 
>>> works as desired, just switch.
>>> Mark Hahn schrieb am Montag, 24. Juni 2024 um 20:10:20 UTC+2:
>>>
 I should say that I want to upgrade to get commands like "weectl 
 device --dump".  Are there equivalent commands in  4.10.2?I need 
 those 
 commands to follow instructions in " Troubleshooting the Davis 
 Vantage station" page of wiki.  My other post here about my davis 
 troubles 
 is at https://groups.google.com/g/weewx-user/c/DMByZT6hyFM.

 On Monday, June 24, 2024 at 11:05:06 AM UTC-7 Mark Hahn wrote:

> I installed weewx long ago (10 yrs?).  It is version   4.10.2.  I 
> don't have any idea how I installed it.  The is nothing related to 
> weewx in 
> m

[weewx-user] Re: want to upgrade to 5.0, don't know original install method

['michael.k...@gmx.at' via weewx-user]

"Activate the venv first. Always."

Means: "Activate the specifific venv everytime, you want to run a command 
for the specific installation in the venv."

Mark Hahn schrieb am Dienstag, 25. Juni 2024 um 03:48:26 UTC+2:

> >  What are 'all' the commands you executed ? 
> Are you serious?  I've been working on this for hours.
>
> > You should not need to 'change the location inside that script' if you 
> are following the instructions correctly.   
> I followed the pip install to the letter.  See the commands I listed post 
> before last.
>
> > are you installing v5 pip on a clean no-weewx system ?
> Read the thread.  I took michael.k's suggestion.
>
> >  are you upgrading a v4 setup to v5 pip ?
> Read the thread.  I said "I installed weewx long ago (10 yrs?).  It is 
> version   4.10.2"
>
> >  are you upgrading a v4 dpkg to a v5 pip ?
> The subject of the thread is "want to upgrade to 5.0, don't know original 
> install method"
>
> > People have done hundreds (thousands?) of pip installations by now.
> And none had any problems.
>
> On Monday, June 24, 2024 at 6:14:39 PM UTC-7 vince wrote:
>
>> Mark you're going to have to be much less concise please.   What are 
>> 'all' the commands you executed ?  What does the output look like end to 
>> end ?
>>
>> What exactly are you doing ?
>>
>>- are you installing v5 pip on a clean no-weewx system ?
>>- or are you upgrading a v4 setup to v5 pip ?
>>- or are you upgrading a v4 dpkg to a v5 pip ?
>>
>> You should not need to 'change the location inside that script' if you 
>> are following the instructions correctly.   You have to be doing something 
>> different or missing a step or several.  People have done hundreds 
>> (thousands?) of pip installations by now.
>>
>> Lets take a step back and please tell us where you're starting, what 
>> you've done step-by-step, and what each step's output looked like.
>>
>>
>> On Monday, June 24, 2024 at 5:26:07 PM UTC-7 Mark Hahn wrote:
>>
>>> I did ...
>>> # Create the virtual environment python3 -m venv ~/weewx-venv # 
>>> Activate the WeeWX virtual environment source ~/weewx-venv/bin/activate # 
>>> Install WeeWX into the virtual environment python3 -m pip install weewx
>>>
>>> On Monday, June 24, 2024 at 5:23:27 PM UTC-7 Mark Hahn wrote:
>>>
 >  Activate the venv first
 I followed the pip instructions carefully so I'm 99% sure I did "source 
 ~/weewx-venv/bin/activate".

 On Monday, June 24, 2024 at 5:04:16 PM UTC-7 vince wrote:

> You used pip.  Activate the venv first. Always.
>
> On Monday, June 24, 2024 at 5:01:38 PM UTC-7 Mark Hahn wrote:
>
>> As suggested I did a separate install using pip.  It was very quick.   
>> "weectl device --clear-memory" fixed my davis problem.
>>
>> I decided to run the new 5.0. I copied over the conf file.  I didn't 
>> need to copy the db file.  Weewxd works great.
>>
>> But now I want to run it as a daemon.  The pip install instructions 
>> said to use "sh ~/weewx-data/scripts/setup-daemon.sh".  I couldn't 
>> run this because weewx-data is in the .env folder, not in root.  I went 
>> to 
>> the weewx-data in .env and ran /setup-daemon.sh.  I had to change the 
>> location inside that script to also use weewx-data in .env.
>>
>> The daemon install gave no errors but when I run "systemctl start 
>> weewx" I get this error ...
>>
>> /etc/systemd/system/weewx.service:12: Executable "WEEWX_PYTHON" not 
>> found in path 
>> "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
>>  weewx.service: Unit configuration has fatal error, unit will not be 
>> started.
>>
>> Can anyone tell me how to fix this?  Meanwhile I'll run in not as a 
>> daemon but obviously I've got to fix this.
>> On Monday, June 24, 2024 at 11:49:27 AM UTC-7 michael.k...@gmx.at 
>> wrote:
>>
>>>
>>> I'd recommend you to leave your old installation untouched, install 
>>> weewx5 the pip way in a venv together with your extensions, a copy of 
>>> your 
>>> database and config and see if it works out. When the new installation 
>>> works as desired, just switch.
>>> Mark Hahn schrieb am Montag, 24. Juni 2024 um 20:10:20 UTC+2:
>>>
 I should say that I want to upgrade to get commands like "weectl 
 device --dump".  Are there equivalent commands in  4.10.2?I need 
 those 
 commands to follow instructions in " Troubleshooting the Davis 
 Vantage station" page of wiki.  My other post here about my davis 
 troubles 
 is at https://groups.google.com/g/weewx-user/c/DMByZT6hyFM.

 On Monday, June 24, 2024 at 11:05:06 AM UTC-7 Mark Hahn wrote:

> I installed weewx long ago (10 yrs?).  It is version   4.10.2.  I 
> don't have any idea how I installed it.  The is nothing related to 
> weewx in 
> my /root directory.  The is 

[weewx-user] Re: want to upgrade to 5.0, don't know original install method

['michael.k...@gmx.at' via weewx-user]

I'd recommend you to leave your old installation untouched, install weewx5 
the pip way in a venv together with your extensions, a copy of your 
database and config and see if it works out. When the new installation 
works as desired, just switch.
Mark Hahn schrieb am Montag, 24. Juni 2024 um 20:10:20 UTC+2:

> I should say that I want to upgrade to get commands like "weectl device 
> --dump".  Are there equivalent commands in  4.10.2?I need those 
> commands to follow instructions in " Troubleshooting the Davis Vantage 
> station" page of wiki.  My other post here about my davis troubles is at 
> https://groups.google.com/g/weewx-user/c/DMByZT6hyFM.
>
> On Monday, June 24, 2024 at 11:05:06 AM UTC-7 Mark Hahn wrote:
>
>> I installed weewx long ago (10 yrs?).  It is version   4.10.2.  I don't 
>> have any idea how I installed it.  The is nothing related to weewx in my 
>> /root directory.  The is no weewx directory in /home.
>>
>> Any ideas on how I should upgrade to 5.0?  Also, are there breaking 
>> changes from  4.10.2 to 5.0?
>>
>

-- 
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/e087c666-52a7-45f0-96bc-383beb754536n%40googlegroups.com.

[weewx-user] Re: Upgrading to v5 from v4 - Insufficient privileges claiming USB

['michael.k...@gmx.at' via weewx-user]

Did you install an udev rule?

mike.t...@noworries.plus.com schrieb am Montag, 24. Juni 2024 um 18:01:17 
UTC+2:

> Thanks Michael I've worked through the doc but not found a resolution.
>
> pi the weewx user is in the following groups pi adm dialout cdrom sudo 
> audio video plugdev games users input netdev lpadmin gpio i2c spi
>
> The arm device is as follows;
> (weewx-venv) pi@weepi:/home/weewx $ ls -l /dev/ttyAMA0
> crw-rw 1 root dialout 204, 64 Jun 24 11:10 /dev/ttyAMA0
>
> ps -ef | grep weewx - shows no instances running
>
> If I sudo weewxd then it runs.
> when running with sudo I see an error "unrecognised magic number 5528" in 
> the log
>
> Jun 24 16:57:46 weepi weewx[1345] INFO weewx.manager: Daily summaries up 
> to date
> Jun 24 16:57:47 weepi weewx[1345] ERROR weewx.drivers.fousb: unrecognised 
> magic number 5528
> Jun 24 16:57:47 weepi weewx[1345] DEBUG weewx.drivers.fousb: get 4079 
> records since 2024-06-24 15:52:30
> Jun 24 16:57:47 weepi weewx[1345] INFO weewx.drivers.fousb: synchronising 
> to the weather station (quality=1)
> Jun 24 16:57:48 weepi weewx[1345] DEBUG weewx.drivers.fousb: status 
> {'rain_overflow': 0, 'lost_connection': 0, 'unknown': 0} (0)
> Jun 24 16:58:05 weepi weewx[1345] DEBUG weewx.drivers.fousb: new data
> Jun 24 16:58:05 weepi weewx[1345] DEBUG weewx.drivers.fousb: setting 
> sensor clock 29.5306
> Jun 24 16:58:05 weepi weewx[1345] DEBUG weewx.drivers.fousb: live 
> synchronised
> Jun 24 16:58:05 weepi weewx[1345] DEBUG weewx.drivers.fousb: packet 
> timestamp is 15:58:05
>
> Thanks in advance
> Mike
>
> On Monday, June 24, 2024 at 2:05:37 PM UTC+1 michael.k...@gmx.at wrote:
>
>> Maybe this sections will help you: 
>> https://github.com/weewx/weewx/wiki/Understanding-permissions#how-to-fix-device-permissions
>>
>> mike.t...@noworries.plus.com schrieb am Montag, 24. Juni 2024 um 
>> 14:27:38 UTC+2:
>>
>>> Hi,
>>> I've worked my way through the upgrade steps  following 
>>> https://github.com/weewx/weewx/wiki/v5-upgrade and got to step 4 
>>>  weewxd --config=/home/weewx/weewx.conf
>>>
>>> running as pi I get the error 
>>> weepi weewxd[17081]: CRITICAL weewxd: Unable to load driver: [Errno 13] 
>>> Access denied (insufficient permissions)
>>>
>>> I have changed the file ownership as per step 2 and everything under 
>>> /weewx/home/ looks to have pi as the owner
>>>
>>> if I sudo weewxd if does run without the driver error. I get a different 
>>> error "TypeError: 'NoneType' object is not callable"  but weew is running 
>>> and updating.
>>>
>>> I have to confess I'm I'm not sure where to look to spot the incorrect 
>>> privilege.
>>>
>>> I'm using a RPI4 and Fine Offset weather station.
>>>
>>> Thanks
>>> Mike
>>>
>>> _
>>> Jun 24 13:17:01 weepi CRON[17056]: (root) CMD (   cd / && run-parts 
>>> --report /etc/cron.hourly)
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Initializing weewxd 
>>> version 5.0.2
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Command line: 
>>> /home/pi/weewx-venv/bin/weewxd --config=/home/weewx/weewx.conf
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Using Python 3.7.3 
>>> (default, Jan 22 2021, 20:04:44) #012[GCC 8.3.0]
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Located at 
>>> /home/pi/weewx-venv/bin/python3
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Platform 
>>> Linux-5.10.63-v7l+-armv7l-with-debian-10.11
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Locale: 'en_GB'
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Entry path: 
>>> /home/pi/weewx-venv/lib/python3.7/site-packages/weewxd.py
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: WEEWX_ROOT: /home/weewx
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Configuration file: 
>>> /home/weewx/weewx.conf
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: User module: 
>>> /home/weewx/bin/user
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Debug: 0
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewx.engine: Loading station 
>>> type FineOffsetUSB (weewx.drivers.fousb)
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewx.drivers.fousb: driver 
>>> version is 1.3
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewx.drivers.fousb: polling 
>>> mode is PERIODIC
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewx.drivers.fousb: polling 
>>> interval is 60
>>> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewx.drivers.fousb: found 
>>> station on USB bus= device=
>>> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.drivers.fousb: 
>>> Unable to claim USB interface 0: [Errno 13] Access denied (insufficient 
>>> permissions)
>>> Jun 24 13:17:05 weepi weewxd[17081]: ERROR weewx.engine: Import of 
>>> driver failed: [Errno 13] Access denied (insufficient permissions) (>> 'weewx.WeeWxIOError'>)
>>> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:  
>>>  Traceback (most recent call last):
>>> Jun 24 13:17:05 weepi

[weewx-user] Re: Upgrading to v5 from v4 - Insufficient privileges claiming USB

['michael.k...@gmx.at' via weewx-user]

Maybe this sections will help 
you: 
https://github.com/weewx/weewx/wiki/Understanding-permissions#how-to-fix-device-permissions

mike.t...@noworries.plus.com schrieb am Montag, 24. Juni 2024 um 14:27:38 
UTC+2:

> Hi,
> I've worked my way through the upgrade steps  following 
> https://github.com/weewx/weewx/wiki/v5-upgrade and got to step 4 
>  weewxd --config=/home/weewx/weewx.conf
>
> running as pi I get the error 
> weepi weewxd[17081]: CRITICAL weewxd: Unable to load driver: [Errno 13] 
> Access denied (insufficient permissions)
>
> I have changed the file ownership as per step 2 and everything under 
> /weewx/home/ looks to have pi as the owner
>
> if I sudo weewxd if does run without the driver error. I get a different 
> error "TypeError: 'NoneType' object is not callable"  but weew is running 
> and updating.
>
> I have to confess I'm I'm not sure where to look to spot the incorrect 
> privilege.
>
> I'm using a RPI4 and Fine Offset weather station.
>
> Thanks
> Mike
>
> _
> Jun 24 13:17:01 weepi CRON[17056]: (root) CMD (   cd / && run-parts 
> --report /etc/cron.hourly)
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Initializing weewxd 
> version 5.0.2
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Command line: 
> /home/pi/weewx-venv/bin/weewxd --config=/home/weewx/weewx.conf
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Using Python 3.7.3 
> (default, Jan 22 2021, 20:04:44) #012[GCC 8.3.0]
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Located at 
> /home/pi/weewx-venv/bin/python3
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Platform 
> Linux-5.10.63-v7l+-armv7l-with-debian-10.11
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Locale: 'en_GB'
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Entry path: 
> /home/pi/weewx-venv/lib/python3.7/site-packages/weewxd.py
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: WEEWX_ROOT: /home/weewx
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Configuration file: 
> /home/weewx/weewx.conf
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: User module: 
> /home/weewx/bin/user
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewxd: Debug: 0
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewx.engine: Loading station 
> type FineOffsetUSB (weewx.drivers.fousb)
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewx.drivers.fousb: driver 
> version is 1.3
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewx.drivers.fousb: polling 
> mode is PERIODIC
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewx.drivers.fousb: polling 
> interval is 60
> Jun 24 13:17:05 weepi weewxd[17081]: INFO weewx.drivers.fousb: found 
> station on USB bus= device=
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.drivers.fousb: Unable 
> to claim USB interface 0: [Errno 13] Access denied (insufficient 
> permissions)
> Jun 24 13:17:05 weepi weewxd[17081]: ERROR weewx.engine: Import of driver 
> failed: [Errno 13] Access denied (insufficient permissions) ( 'weewx.WeeWxIOError'>)
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:  
>  Traceback (most recent call last):
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:    
>  File 
> "/home/pi/weewx-venv/lib/python3.7/site-packages/weewx/drivers/fousb.py", 
> line 1036, in openPort
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:  
>  self.devh.claimInterface(self.usb_interface)
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:    
>  File "/home/pi/weewx-venv/lib/python3.7/site-packages/usb/legacy.py", line 
> 232, in claimInterface
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:  
>  util.claim_interface(self.dev, interface)
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:    
>  File "/home/pi/weewx-venv/lib/python3.7/site-packages/usb/util.py", line 
> 207, in claim_interface
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:  
>  device._ctx.managed_claim_interface(device, interface)
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:    
>  File "/home/pi/weewx-venv/lib/python3.7/site-packages/usb/core.py", line 
> 113, in wrapper
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:  
>  return f(self, *args, **kwargs)
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:    
>  File "/home/pi/weewx-venv/lib/python3.7/site-packages/usb/core.py", line 
> 170, in managed_claim_interface
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:  
>  self.managed_open()
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:    
>  File "/home/pi/weewx-venv/lib/python3.7/site-packages/usb/core.py", line 
> 113, in wrapper
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engine:  
>  return f(self, *args, **kwargs)
> Jun 24 13:17:05 weepi weewxd[17081]: CRITICAL weewx.engin

Re: [weewx-user] Re: add missing records, then report and exit

['michael.k...@gmx.at' via weewx-user]

After optimizing the power consumption, consider using an LTO (Lithium 
Titanate Oxid) battery, it should outperform the AGM in every aspect. The 
downside is you need a rather sophisticated battery management and for LTO 
batteries, there isn't really much to find. Depending on how low the 
temperatures really get, LiFePO4 batteries should also do the job, and 
there are lots of BMS on the market. 
vince schrieb am Sonntag, 23. Juni 2024 um 20:10:05 UTC+2:

> Wow - very interesting setup. A lot of questions come to mind:
>
>- what model pi are you running ?
>- have you stripped the os down to the bare minimum number of 
>processes running ?
>- have you stripped down the services weewx runs to the minimum ?
>- what is the power savings you measure by killing weewx ?
>- do any of those changes have measurable impact on power consumption ?
>
> For a pi-only software solution I'd just use bash and cron periodically:
>
>- check if weewx is running or not
>   - if not, start weewx up and await it running the WU upload after 
>   the first archive period
>- watch the weewx log to see if the WU upload has logged that it has 
>completed its upload.  You could do this with a custom rsyslog.conf entry 
>and log only WU stuff to a particular file
>- when the WU log is populated, rotate that logfile (for the next run) 
>and kill weewx and exit
>- (and use cron to periodically start the script of course)
>
> Basically your script would watch for the WU-only logfile to be non-zero 
> size with a particular content in it saying the upload was complete.
>
> For a hardware solution I'd look for a hardware-only way to use an arduino 
> or pi pico to actually power the raspi down completely, but then you'd need 
> a RTC in the weewx pi (another battery needing to work in low power).  One 
> interesting link I found with pointers to some others is 
> https://stfn.pl/blog/34-pico-power-consumption-solar-panels/ if that 
> helps any.  The author there has a lot of links and there are pointers to 
> some adafruit boards that might help if you wanted to try a hardware 
> solution.
>
> FWIW - I fiddled with deepsleep etc. on a pico when they came out but 
> didn't have anything that could measure how little power they sip when deep 
> sleeping.  I do know that a pi itself still draws a lot of power when 
> powered off although you can edit the os setup to minimize this.  See 
> https://www.jeffgeerling.com/blog/2023/reducing-raspberry-pi-5s-power-consumption-140x
>  
> for details. I can confirm his blog solution works on a pi5 and pi4 but 
> never tried it on a pi3 or zero or old model-B so I don't know there.
>
> On Sunday, June 23, 2024 at 9:47:46 AM UTC-7 tguo...@gmail.com wrote:
>
>> Thanks Greg! this should be achievable knowing the code. Would really 
>> help!
>>
>> (had to google it MIB: Management Information Base)
>> On Thursday 20 June 2024 at 14:20:54 UTC-3 Greg Troxel wrote:
>>
>>> Indeed the real goal is important. 
>>>
>>> I can certainly see having weewx have some kind of status output (a MIB 
>>> :) that indicates whether it has successfully processed all the archive 
>>> records and written the database (and run reports), so that a supervisor 
>>> process can shut it down. 
>>>
>>> I do not see most people wanting to spend time on that, so the OP has 
>>> some code to write. 
>>>
>>>

-- 
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/dbb7b0b0-20c5-4a45-b398-991fc2b9c28dn%40googlegroups.com.

[weewx-user] Re: Weewx compatibility questions.

['michael.k...@gmx.at' via weewx-user]

Answer to the first question: no.

There has to be a driver for your station. Is it listed here: 
https://weewx.com/hardware.html?

Mike Book schrieb am Sonntag, 23. Juni 2024 um 20:44:41 UTC+2:

> I'm sure this question has been asked before but I was having difficulity 
> trying to find an answer.
>
> When using weewx does the weather station have to be a weather station 
> with WiFi/Network capabilities? 
>
> I bought a weather station recently and as a HAM operator I was told I 
> could use weewx to get my weather station on APRS. I would like to do it 
> but I'm not understanding how weewx pulls the data. Does it pull it from 
> the network that my device would be connected too? The device I purchased 
> doesn't have network capability so I'm afraid it will not work with weewx. 
> Hopefully someone could answer this.
>
> Thanks
> Mike
>

-- 
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/98eb6e02-a6b8-4ebe-ad63-13576b4afe74n%40googlegroups.com.

Re: [weewx-user] Re: add missing records, then report and exit

['michael.k...@gmx.at' via weewx-user]

You still don't know the problem, but state, there is no such.

I can think of one: 1-3W x 24h = 25 - 72Wh is quite another category of a 
problem to solve, without a grid backed power source, than 5-6 x 5 min x 
1-3W = 0.42 - 1.5Wh would be. One LiFePO4 18650 battery holds about 6Wh, so 
the difference between "always on" and "turning on only when needed" is one 
vs. 24 such batteries for the same running time. Now that's what I call a 
use case. Still, without knowing the problem, my idea of a use case isn't 
any better in terms of a possible solution than stating, that there isn't 
even a problem to solve.

vince schrieb am Donnerstag, 20. Juni 2024 um 19:37:08 UTC+2:

> Here's the problem...
>
>- shutting weewx down does nothing to save power
>- shutting the pi down saves 'almost' nothing because it draws so 
>little
>- the WLL is still on and using power to act as a datalogger in the 
>interim
>- and internet connectivity requires 'some' hardware powered on as well
>- and any hardware solution will cost more than you'd save in power in 
>3+ years probably
>
> So I'm not seeing any use case making any sense at all here to even bother 
> trying to over-optimize the 1-3W a pi draws.
>
> On Thursday, June 20, 2024 at 10:20:54 AM UTC-7 Greg Troxel wrote:
>
>> Indeed the real goal is important. 
>>
>> I can certainly see having weewx have some kind of status output (a MIB 
>> :) that indicates whether it has successfully processed all the archive 
>> records and written the database (and run reports), so that a supervisor 
>> process can shut it down. 
>>
>> I do not see most people wanting to spend time on that, so the OP has 
>> some code to write. 
>>
>>

-- 
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/61082e50-4ec8-4055-abca-632b8e5b2239n%40googlegroups.com.

[weewx-user] Re: add missing records, then report and exit

['michael.k...@gmx.at' via weewx-user]

vince you may have not thought about the problem getting the the needed 
energy there. If there is no grid-based power supply it may be hard to run 
a raspberry pi continuously at that location. Anyway, knowing more about 
the use case could lead to more ideas to solve the real problem.
vince schrieb am Donnerstag, 20. Juni 2024 um 04:56:41 UTC+2:

> Geez how much do you spend for power?  Why would you possibly want to do 
> this ? 
>
> Even at $0.30 per kwh a pi4 would only cost $0.02 per day to just leave it 
> on..,
>
>
> https://www.calculator.net/electricity-calculator.html?appliance=&power=3&powerunit=W&capacity=100&usage=24&usageunit=hpd&price=0.30&x=Calculate
>
> On Wednesday, June 19, 2024 at 6:43:19 PM UTC-7 Tomás wrote:
>
>> Hello, I have a weatherlink and a raspi working with weewx doing a good 
>> job for two years. The raspi is turned on for 5' for5-6 times daily, 
>> downloads the data from the console and reports to wunderground mainly. I'd 
>> like the routine to stop after finished, so I can turn off the raspi as 
>> soon as posible.
>>
>> I have not found through weectl device or database an option to download 
>> only missing records.
>>
>> Is there a way to do this? I could save some more miliamps this way.
>>
>> Thanks!
>>
>

-- 
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/eb3be68b-0bc3-47a0-becd-b89436123e48n%40googlegroups.com.

Re: [weewx-user] Your hardware experience (for running WeeWX, the service)

['michael.k...@gmx.at' via weewx-user]

After one month, a first impression: The zbox runs flawlessly in absolute 
silence (it is fanless), given a SSD is installed. It is drawing about 11W 
of power on average. That's a litte less than triple the power the RPi4, 
but with approximately 10x the computing power. For only running weewx it'd 
be definitely an overkill. The big question: "how long will it run?" Only 
time can answer. For me, it was the right choice so far.


michael.k...@gmx.at schrieb am Freitag, 17. Mai 2024 um 18:53:13 UTC+2:

> Yes, Gen24 with BYD HVM 22.1 and PV Point. I've actually never tested how 
> the UPS (EATON Ellipse PRO 1200) likes the PV Point. I am aware of the 
> Frequencies when in Backup mode. I don't know what full backup solution the 
> electrician would offer, but it would cost €700 including work. The real 
> problem that makes it so much more expensive, is that my distributor box is 
> full, and the solution needs 17 more slots on a DIN rail. A lot of work and 
> a a couple of hundreds for the hardware.
>
> Gábor Szabados schrieb am Freitag, 17. Mai 2024 um 14:46:55 UTC+2:
>
>> As I remember the EU specs is 50Hz +/-1%, so all those look good to me.
>>
>> Regarding the battery and backup socket, I guess that must be a Fronius 
>> Gen24 Plus with a BYD battery, and the socket would be the PV Point. As 
>> just a note, if you don't know it yet, the PV Point socket and the Full 
>> Backup operates at 54Hz. It is not really advertised, but the point of it, 
>> to knock out any other Inverters as they would detect an out-of-spec line 
>> frequency and would shut down.
>>
>> And if you consider the Enwitec backup box, which as you stated would be 
>> more than a 1000 with installation, there is a cheaper box also on the 
>> market by Keno the SH-GEN24-SZR, but still around 1000 without 
>> installation. 
>>
>> I have one, but have not installed it yet, and felt the need recently 
>> when the operator did a 3+ hours maintenance and all the UPS depleted in 
>> the house.
>>
>> On Thu, 16 May 2024, 16:56 Karen K,  wrote:
>>
>>> michael.k...@gmx.at schrieb am Donnerstag, 16. Mai 2024 um 15:46:28 
>>> UTC+2:
>>>
>>> Since the (public) power grid is part of the hardware your local weewx 
>>> installation is running on, this is far from being off-topic. 
>>>
>>>
>>> There are 3 types of UPS available: off-line, stand-by, and on-line. The 
>>> first one is off as long as grid power is available and starts when the 
>>> grid power goes off. The second one is similar, but it is in stand-by. So 
>>> it start faster than the first one. The on-line one separates the grid and 
>>> the output entirely. They are connected by DC only. So this type can 
>>> additionally filter surges etc. The output frequency for the on-line type 
>>> only depends on the internal circuit, while for the off-line and stand-by 
>>> type the output frequency is always the same as the grid frequency.
>>>
>>> I use an on-line UPS and hope that will result in less damage in case of 
>>> over-voltage, surges, and lightning strokes.
>>>
>>> To compare to Cameron's histogram I did one myself, based on 5 minutes 
>>> averages of the grid frequency (NOT the UPS output frequency):
>>>
>>> [image: netzfrequenzhistogramm.png]
>>>
>>> This one has the peak at 50.00 Hz.
>>>
>>> -- 
>>> 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/HBDfW-ayRyI/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/78c65e41-5ac1-4e13-9644-e46beb078147n%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/bdd1bd6e-d637-4bad-bd3e-fb87537a1951n%40googlegroups.com.

[weewx-user] Re: Saving years of archived weather data before upgrading?

['michael.k...@gmx.at' via weewx-user]

You are running weewx, so your weather data is stored in a database as 
configured in weewx.conf. Check you weewx.conf for the settings. If you use 
sqlite, simply copy the existing database (wewwx.sdb) to your new system 
and you can seamlessly continue.
I'm sure there are several migration and upgrade guides, anyway, one 
thing's for sure everything you need to know is in the 
manual: https://weewx.com/docs

barry manilow schrieb am Donnerstag, 6. Juni 2024 um 16:46:05 UTC+2:

> I've been running Weewx on a Pi for several years, and want to upgrade 
> both Raspbian and Weewx, but keep the stored weather data which is archived 
> on Wunderground.
> I've checked the conversations, but can't find anyone who has done this, 
> or even if it's possible.
> Curently on Debian 8 (Jessie) and Weewx 4.10 running a Davis Vantage Vue.
> I want to upgrade to Weewx 5 and Debian 12 (Bookworm.)
> Jessie to Bookworm requires several sequential upgrades, and the 
> recommendation is to do a fresh Bookworm install on a new sd card.
> A fresh install of Weewx on Bookworm would start my Davis weather station 
> from scratch, but I'm sure I'd lose the past 6 years of records.
> Is there any way to do 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/5603c423-d9ae-401f-9270-5b73627c095dn%40googlegroups.com.

[weewx-user] Re: On the first weewx generation cycle the extreme temperatures are not updated

['michael.k...@gmx.at' via weewx-user]

At 00:00 on the current day, you don't have new values for the new day, 
although the day has started, it's duration is 0 so far. The newest, value 
is the last interval of the previous day. From the archive generation's  
point of view, it is still yesterday. So everything OK.

areax99 schrieb am Sonntag, 2. Juni 2024 um 17:24:34 UTC+2:

> i have created this json template
> #encoding UTF-8
> #import datetime
> #errorCatcher Echo
> {
> "current": {
> "datetime": "$current.dateTime",
> "datetime_raw": "$current.dateTime.raw"
> },
> "day": {
> "outTemp": {
> "max": "$day.outTemp.max",
> "max_formatted": "$day.outTemp.max.formatted",
> "maxtime": "$day.outTemp.maxtime",
> "min": "$day.outTemp.min",
> "min_formatted": "$day.outTemp.min.formatted",
> "mintime": "$day.outTemp.mintime"
> }
> },
> "yesterday": {
> "outTemp": {
> "max": "$day($days_ago=1).outTemp.max",
> "max_formatted": "$day($days_ago=1).outTemp.max.formatted",
> "maxtime": "$day($days_ago=1).outTemp.maxtime",
> "min": "$day($days_ago=1).outTemp.min",
> "min_formatted": "$day($days_ago=1).outTemp.min.formatted",
> "mintime": "$day($days_ago=1).outTemp.mintime"
> }
> }
> }
>
> but when weewx performs the first generation of the new day (00:00), the 
> details of the previous day (and new day) are not updated. They are updated 
> only in the next cycle.
> {
> "current": {
> "datetime": "02/06/2024 00:00:00",
> "datetime_raw": "1717279200"
> },
> "day": {
> "outTemp": {
> "max": "25,3 °C",
> "max_formatted": "25,3",
> "maxtime": "11:06:02",
> "min": "18,1 °C",
> "min_formatted": "18,1",
> "mintime": "22:59:06"
> }
> },
> "yesterday": {
> "outTemp": {
> "max": "24,3 °C",
> "max_formatted": "24,3",
> "maxtime": "12:59:41",
> "min": "18,9 °C",
> "min_formatted": "18,9",
> "mintime": "03:22:26"
> }
> }
> }
>
>
> {
> "current": {
> "datetime": "02/06/2024 00:05:00",
> "datetime_raw": "1717279500"
> },
> "day": {
> "outTemp": {
> "max": "18,7 °C",
> "max_formatted": "18,7",
> "maxtime": "00:01:07",
> "min": "18,6 °C",
> "min_formatted": "18,6",
> "mintime": "00:00:04"
> }
> },
> "yesterday": {
> "outTemp": {
> "max": "25,3 °C",
> "max_formatted": "25,3",
> "maxtime": "11:06:02",
> "min": "18,1 °C",
> "min_formatted": "18,1",
> "mintime": "22:59:06"
> }
> }
> }
>
>
> I tried to use $yesterday but it gives me an error.
>
> I have 5.0.2 version
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0780-e3f5-4756-8c1d-a7ac6aa08d2en%40googlegroups.com.

[weewx-user] fuzzy-archer 4.3 is on the way...

['michael.k...@gmx.at' via weewx-user]

...but not finished yet. Give it a try ( 
https://github.com/brewster76/fuzzy-archer/tree/4.3 ) and file any findings 
as an issue: https://github.com/brewster76/fuzzy-archer/issues

If you have a multi-language page, you may be looking forward to WeeWX 
5.1.0, enabling multiple localizations from a single WeeWX installation. 
Example fuzzy-archer 4.3/WeeWX 
5.1.0b4: https://kainzbauer.net/weather/Test/Rif/en


-- 
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/20a3f56d-098c-4060-ab64-a734a52648abn%40googlegroups.com.

Re: [weewx-user] Ecowitt Gateway Driver, WH57 and lightning data [4]

['michael.k...@gmx.at' via weewx-user]

>
> I think what would be helpful (at least for me to understand better - 
> maybe I simply don't get the point ... - maybe it was already all clearly 
> presented but that portion got cut off from the thread) to have a draft 
> architecture of what exactly you want to do - not only verbalized but also 
> drawn in a picture.
> And then describe for which steps/areas/segments you think you already 
> have tools/solutions and for what not. 
> 1. to see the gaps
> 2. maybe to revise the whole architecture in a target oriented manner
>
> and then see what's already available and what needs to be added
>
> Having been working as an IT and network architect, I'm not so much into a 
> Lego block approach but in a more structured approach.
> Big picture first - and then drill down in a result- and technology-open 
> mindset
>
> A picture is worth 1000 words they say - and in my experience this is very 
> true
> On 03.06.2024 17:56, 'michael.k...@gmx.at' via weewx-user wrote:
>
> Rainer, the WH57 sends lightning data as the lighning is detected, the 
> console shows this data immediately. 
> I observed this mutliple times:
>
> You see the lightning out there, the LED of the WH57 flashes red, the 
> counter on the console goes up, the distance is also updated. If there is a 
> lightning just a few seconds later, the same game again. Even when polling 
> the console API in an interval < 79s, you get the lightning data updates 
> more frequently than 79s.
>
>
> Your information does not fit the observed reality. Whats true is that you 
> need to store lightning data in a different format, to calculate a 
> meaningful value for the archive record. Something like the count per 
> interval and a kind of weighted average for the distance. It exists for the 
> Tempest, which transmits lightning data using UDP as it detects a 
> lightning. Apart from the other data which is transmitted in a constant 
> interval.
> Rainer Lang schrieb am Montag, 3. Juni 2024 um 17:25:34 UTC+2:
>
>> "If there is a possibility to extract a singled detected lightning event 
>> and 
>> > it's data with standard devices, is another story. If so, I'd see the 
>> point 
>> > of doing so. At least the minimal distance and weighted average 
>> distance 
>> > are interesting values to me. I doubt it is possible doing this with 
>> the 
>> > "Ecowitt Gateway Driver", I have no idea if it is possible with the 
>> > interceptor driver and a WH2551, it should be possible using SDR."
>>
>> what part of transmitting every 79 seconds has not been understood ?
>> And the 79 seconds start with the first detected discharge.
>>
>> Why would SDR receive more and more often ? Magic SDR ?
>> SDR is nothing else but a radio receiver as is a console.
>> Just by changing the console the sensor won't post faster.
>>
>> And it's not an Acurite chipset (maybe some Acurite device uses the same 
>> chip);
>> it's an AS3935 - before starting wild speculations I would read the 
>> specifications and see if the chip can be animated to provide data more 
>> frequently.
>> Then you can try your luck modifying the sensor firmware if that's 
>> possible and not limited by the chip itself ...
>>
>> And have a look what exactly the chip provides/can provide ...
>> check if it provides such things like minimal distance, weighted distance 
>> etc. 
>> Nice wishlist, but as far as I have understood the specifications, it 
>> doesn't do that.
>> Admittedly, I'm not an expert here - somebody else may be able to extract 
>> more information
>>
>> Google can be your friend - look up the AS3935 specifications/data sheet 
>> etc.
>>
>> But as for the WH57 as manufactured, it will transmit every 79 seconds 
>> 
>>
>> And it has nothing to do with the Ecowitt Gateway driver or any other 
>> driver - you can have it poll every two seconds.
>> But it can get only what the console has available to send. And the 
>> console only has what it receives from what was transmitted.
>>
>> Maybe it would be helpful to understand how weewx works ...
>>
>> Classically the data received from a driver or extension is collected in 
>> a loop where data gets accumulated.
>> That doesn't seem to be what you want. You seem to want every single 
>> data-item to be recorded separately.
>> Then you will also have to write the code which does this and save the 
>> data in a way you can reuse it - i.e. write your own extension.
>> You'd probably need you

[weewx-user] Re: Different instances of WEEWX?

['michael.k...@gmx.at' via weewx-user]

Without your config and a log (at least a full interval) one just can 
guess. I like guessing, so my best guess: you only run one instance and on 
August 6, 2023, you changed something, so it doesn't populate html files to 
the location, where the local webserver retrieves the files from, anymore.

Eric Gammeter schrieb am Montag, 3. Juni 2024 um 15:31:36 UTC+2:

> Hi-  
>
> Seems I have two different instances of WEEWX. 
>
> I have the online WEB instance (www.OakorchardWeather.NET) which is 
> current (date time, data); and I have the other instance at local IP 
> address: 192.168.1.38.  This 2nd instance is dated August 6, 2023.  
> MY situation:  I am trying to troubleshoot why my aeris weather 
> information is not playing the radar timelapse loop on my WEB (main) site; 
> while at the same time the aeris radar timelapse loop *IS* 
> playing/functioning accurately at the local IP address instance.
>
>
>

-- 
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/34055bd5-b86f-45a1-bb0f-f6a37d5e969bn%40googlegroups.com.

Re: [weewx-user] Ecowitt Gateway Driver, WH57 and lightning data [3]

['michael.k...@gmx.at' via weewx-user]

nly what the console has available to send. And the 
>>> console only has what it receives from what was transmitted.
>>>
>>> Maybe it would be helpful to understand how weewx works ...
>>>
>>> Classically the data received from a driver or extension is collected in 
>>> a loop where data gets accumulated.
>>> That doesn't seem to be what you want. You seem to want every single 
>>> data-item to be recorded separately.
>>> Then you will also have to write the code which does this and save the 
>>> data in a way you can reuse it - i.e. write your own extension.
>>> You'd probably need your own separate lightning database for that too.
>>> In the typical way weewx works, collects and archives data that won't 
>>> work as far as I can see.
>>>
>>> By the way - if there are no more discharges within 79 seconds, your 
>>> request above will be fulfilled 😉
>>>
>>> all the sensor related information could have been found and read in the 
>>> Ecowitt WiKi
>>> https://meshka.eu/Ecowitt/dokuwiki
>>>
>>> On 02.06.2024 19:25, 'michael.k...@gmx.at' via weewx-user wrote:
>>>
>>> Probably the only way getting reasonable data is with SDR.
>>>
>>> michael.k...@gmx.at schrieb am Freitag, 25. August 2023 um 07:32:51 
>>> UTC+2:
>>>
>>>> My best guess is that the Sensor reports every 79s "Hello, I'm there" 
>>>> and every detected lightning on top of that, immediately. If you don't 
>>>> live 
>>>> at Catatumbo River mouth, this shouldn't drain the battery too much. Let's 
>>>> see if Rainer Lang knows more Details. 
>>>>
>>>> Greg Troxel schrieb am Freitag, 25. August 2023 um 01:53:48 UTC+2:
>>>>
>>>>> "michael.k...@gmx.at"  writes: 
>>>>>
>>>>> > I am just now in the middle of this Storm with stroboscopic-like 
>>>>> lightning 
>>>>> > flashing. 
>>>>> > 
>>>>> > I recognized my HP2551 is obviously showing lightning strikes in 
>>>>> realtime. 
>>>>> > Every one or the other second. 
>>>>> > 
>>>>> > Then I checked back in the manual and now disagree with gjr80, when 
>>>>> he 
>>>>> > states: 
>>>>> > 
>>>>> > gjr80 schrieb am Mittwoch, 21. Juni 2023 um 22:32:42 UTC+2: 
>>>>> > 
>>>>> > In essence the WH57 reports three things; the number of lightning 
>>>>> strike 
>>>>> > detected today, the time of the last detected lightning strike and 
>>>>> the 
>>>>> > distance of the last lightning strike. This is clearly stated in the 
>>>>> WH57 
>>>>> > manual. 
>>>>> > Gary 
>>>>>
>>>>> This sounds very much like the chip that is in the Acurite 6045M 
>>>>>
>>>>> > If there is a possibility to extract a singled detected lightning 
>>>>> event and 
>>>>> > it's data with standard devices, is another story. If so, I'd see 
>>>>> the point 
>>>>> > of doing so. At least the minimal distance and weighted average 
>>>>> distance 
>>>>> > are interesting values to me. I doubt it is possible doing this with 
>>>>> the 
>>>>> > "Ecowitt Gateway Driver", I have no idea if it is possible with the 
>>>>> > interceptor driver and a WH2551, it should be possible using SDR. 
>>>>>
>>>>> Certainly it would be great to log the bits and study them. The 6045M 
>>>>> only transmits periodically, with a longer period without lightning 
>>>>> and 
>>>>> then faster in 'active mode'. I suspect the chip reports immediately, 
>>>>> and there is a different radio in the WH57. There is no reason why it 
>>>>> couldn't be set up to send promptly, other than battery life. 
>>>>>
>>>> -- 
>>>
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/437ddc4e-27e4-409c-952d-4555f8a855d7n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/437ddc4e-27e4-409c-952d-4555f8a855d7n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/85f7d66f-7b89-4aa5-8e9b-e6d47092ca42n%40googlegroups.com.

Re: [weewx-user] Ecowitt Gateway Driver, WH57 and lightning data [3]

['michael.k...@gmx.at' via weewx-user]

Rainer, the WH57 sends lightning data as the lighning is detected, the 
console shows this data immediately.
I observed this mutliple times:

You see the lightning out there, the LED of the WH57 flashes red, the 
counter on the console goes up, the distance is also updated. If there is a 
lightning just a few seconds later, the same game again. Even when polling 
the console API in an interval < 79s, you get the lightning data updates 
more frequently than 79s.

Wait for the next storm and see. I have no doubt that with SDR you can 
receive these data, as it's sent by the WH57. 

Your information does not fit the observed reality. Whats true is that you 
need to store lightning data in a different format, to calculate a 
meaningful value for the archive record. Something like the count per 
interval and a kind of weighted average for the distance. It exists for the 
Tempest, which transmits lightning data using UDP as it detects a 
lightning. Apart from the other data which is transmitted in a constant 
interval.
Rainer Lang schrieb am Montag, 3. Juni 2024 um 17:25:34 UTC+2:

> "If there is a possibility to extract a singled detected lightning event 
> and 
> > it's data with standard devices, is another story. If so, I'd see the 
> point 
> > of doing so. At least the minimal distance and weighted average distance 
> > are interesting values to me. I doubt it is possible doing this with the 
> > "Ecowitt Gateway Driver", I have no idea if it is possible with the 
> > interceptor driver and a WH2551, it should be possible using SDR."
>
> what part of transmitting every 79 seconds has not been understood ?
> And the 79 seconds start with the first detected discharge.
>
> Why would SDR receive more and more often ? Magic SDR ?
> SDR is nothing else but a radio receiver as is a console.
> Just by changing the console the sensor won't post faster.
>
> And it's not an Acurite chipset (maybe some Acurite device uses the same 
> chip);
> it's an AS3935 - before starting wild speculations I would read the 
> specifications and see if the chip can be animated to provide data more 
> frequently.
> Then you can try your luck modifying the sensor firmware if that's 
> possible and not limited by the chip itself ...
>
> And have a look what exactly the chip provides/can provide ...
> check if it provides such things like minimal distance, weighted distance 
> etc. 
> Nice wishlist, but as far as I have understood the specifications, it 
> doesn't do that.
> Admittedly, I'm not an expert here - somebody else may be able to extract 
> more information
>
> Google can be your friend - look up the AS3935 specifications/data sheet 
> etc.
>
> But as for the WH57 as manufactured, it will transmit every 79 seconds 
>
> And it has nothing to do with the Ecowitt Gateway driver or any other 
> driver - you can have it poll every two seconds.
> But it can get only what the console has available to send. And the 
> console only has what it receives from what was transmitted.
>
> Maybe it would be helpful to understand how weewx works ...
>
> Classically the data received from a driver or extension is collected in a 
> loop where data gets accumulated.
> That doesn't seem to be what you want. You seem to want every single 
> data-item to be recorded separately.
> Then you will also have to write the code which does this and save the 
> data in a way you can reuse it - i.e. write your own extension.
> You'd probably need your own separate lightning database for that too.
> In the typical way weewx works, collects and archives data that won't work 
> as far as I can see.
>
> By the way - if there are no more discharges within 79 seconds, your 
> request above will be fulfilled 😉
>
> all the sensor related information could have been found and read in the 
> Ecowitt WiKi
> https://meshka.eu/Ecowitt/dokuwiki
>
> On 02.06.2024 19:25, 'michael.k...@gmx.at' via weewx-user wrote:
>
> Probably the only way getting reasonable data is with SDR.
>
> michael.k...@gmx.at schrieb am Freitag, 25. August 2023 um 07:32:51 UTC+2:
>
>> My best guess is that the Sensor reports every 79s "Hello, I'm there" and 
>> every detected lightning on top of that, immediately. If you don't live at 
>> Catatumbo River mouth, this shouldn't drain the battery too much. Let's see 
>> if Rainer Lang knows more Details. 
>>
>> Greg Troxel schrieb am Freitag, 25. August 2023 um 01:53:48 UTC+2:
>>
>>> "michael.k...@gmx.at"  writes: 
>>>
>>> > I am just now in the middle of this Storm with stroboscopic-like 
>>> lightning 
>>> > flas

Re: [weewx-user] Ecowitt Gateway Driver, WH57 and lightning data [2]

['michael.k...@gmx.at' via weewx-user]

Probably the only way getting reasonable data is with SDR.

michael.k...@gmx.at schrieb am Freitag, 25. August 2023 um 07:32:51 UTC+2:

> My best guess is that the Sensor reports every 79s "Hello, I'm there" and 
> every detected lightning on top of that, immediately. If you don't live at 
> Catatumbo River mouth, this shouldn't drain the battery too much. Let's see 
> if Rainer Lang knows more Details. 
>
> Greg Troxel schrieb am Freitag, 25. August 2023 um 01:53:48 UTC+2:
>
>> "michael.k...@gmx.at"  writes: 
>>
>> > I am just now in the middle of this Storm with stroboscopic-like 
>> lightning 
>> > flashing. 
>> > 
>> > I recognized my HP2551 is obviously showing lightning strikes in 
>> realtime. 
>> > Every one or the other second. 
>> > 
>> > Then I checked back in the manual and now disagree with gjr80, when he 
>> > states: 
>> > 
>> > gjr80 schrieb am Mittwoch, 21. Juni 2023 um 22:32:42 UTC+2: 
>> > 
>> > In essence the WH57 reports three things; the number of lightning 
>> strike 
>> > detected today, the time of the last detected lightning strike and the 
>> > distance of the last lightning strike. This is clearly stated in the 
>> WH57 
>> > manual. 
>> > Gary 
>>
>> This sounds very much like the chip that is in the Acurite 6045M 
>>
>> > If there is a possibility to extract a singled detected lightning event 
>> and 
>> > it's data with standard devices, is another story. If so, I'd see the 
>> point 
>> > of doing so. At least the minimal distance and weighted average 
>> distance 
>> > are interesting values to me. I doubt it is possible doing this with 
>> the 
>> > "Ecowitt Gateway Driver", I have no idea if it is possible with the 
>> > interceptor driver and a WH2551, it should be possible using SDR. 
>>
>> Certainly it would be great to log the bits and study them. The 6045M 
>> only transmits periodically, with a longer period without lightning and 
>> then faster in 'active mode'. I suspect the chip reports immediately, 
>> and there is a different radio in the WH57. There is no reason why it 
>> couldn't be set up to send promptly, other than battery life. 
>>
>

-- 
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/437ddc4e-27e4-409c-952d-4555f8a855d7n%40googlegroups.com.

[weewx-user] Re: Upgrade from 4.10.2-1 to 5.0.2 - high CPU and external database load.

['michael.k...@gmx.at' via weewx-user]

Belchertown? It is known Belchertown consumes a lot of CPU time when 
certain derived values are not in the database, after a 4 => 5 upgrade. 
Check the group for solutions.

I had maybe something like that a couple weeks ago (without Belchertown), 
it might have startet after I did an apt upgrade (but no weewx upgrade), I 
had to restart the RPi4 every day, after 24h I couldn't even ssh into the 
machine any more. In the logs were messages like "database locked" and 
those "report thread still running" messages. I didn't care too much 
because I upgraded my server hardware and installed everything from scratch 
and don't have any issues any more. I had four weewxd and a lot of other 
stuff running, I never found out, what caused the issues.

Bartosz Francman schrieb am Samstag, 1. Juni 2024 um 15:25:36 UTC+2:

> Hi,
> For several months I have been postponing the upgrade from version 
> 4.10.2-1 to version 5.02. To tell you the truth, I didn't even know that it 
> was a jump from 4.x to 5.x and a few days ago I did an automatic upgrade 
> (sudo apt update & upgrade).
> When asked about saving the configuration file, I left the old version, as 
> everything worked so far.
> My system consists of a RaspberryPi 3B, a Eurochron EFWS 2900 station and 
> a database (MariaDB 10) located on the NAS so as not to write data to the 
> memory card. This system has been operating for 6 years (the first entries 
> in the database are from 2018). So far I haven't had any problems. 
> Everything worked as it should.
> As the weather station only works via WiFi, I had to use the Interceptor 
> controller to read data from the station. And unfortunately, only port 80 
> could be used. It is not possible to configure the station, apart from 
> turning it on and setting access data to 3 weather services.
> Now I will briefly describe the problems with the upgrade.
> Port 80 cannot be used by any user other than root, so I had to change the 
> way weewx runs from the weewx user to the root user. Data began to appear 
> and the script did not end with the lack of access to port 80. I thought 
> that it was not so bad.
> However, I saw that the processes related to weewx were using 100% of the 
> load of two raspberry processors. I found information on this group that it 
> may be a problem with the lack of appropriate columns in the archive table (
> https://groups.google.com/g/weewx-user/c/6rl2FIbqVp4/m/S0Ek9ZVaBwAJ) I 
> did everything according to this post, plus from 
> https://weewx.com/docs/5.0/utilities/weectl-database/#update-a-database 
> update the database and check it. All this took about 2 hours due to the 
> large amount of data I have in this database. By the way, apart from the 
> high CPU load, I noticed that every half a minute there is a very large 
> data read from the database. And it's related to weewx. I thought that 
> rebuilding the database would reduce the CPU load and eliminate the 
> frequent polling, but unfortunately it didn't help. I don't have any very 
> advanced visualizations, just a basic diagram.
> I left it because there is nothing else to do with this raspberry and two 
> out of four processors can be fully loaded. But unfortunately, about two 
> hours after starting the system, I received information from one weather 
> service that I was not sending data to them. I tried to access this 
> raspberry via ssh, but it was impossible. Connection timed out. Although 
> the raspberry was running.
> Only today I sat down to work on it and managed to connect to the 
> raspberry. The last log entries after issuing the sudo systemctl status 
> weewx command are provided below:
>
> pi@raspberry-pi:~ $ sudo systemctl status weewx
> × weewx.service - WeeWX
>  Loaded: loaded (/lib/systemd/system/weewx.service; enabled; preset: 
> enabled)
>  Active: failed (Result: signal) since Sat 2024-06-01 10:36:12 CEST; 
> 1min 2s ago
>Duration: 19h 10min 2.367s
>Docs: https://weewx.com/docs
> Process: 720 ExecStart=weewxd /etc/weewx/weewx.conf (code=killed, 
> signal=KILL)
>Main PID: 720 (code=killed, signal=KILL)
> CPU: 1h 59min 21.575s
>
> maj 31 17:51:09 raspberry-pi weewxd[720]: INFO weewx.restx: PWSWeather: 
> Published record 2024-05-31 17:48:00 CEST (1717170480)
> maj 31 17:51:22 raspberry-pi weewxd[720]: INFO weewx.restx: 
> Wunderground-RF: Published record 2024-05-31 17:48:47 CEST (1717170527)
> maj 31 17:51:28 raspberry-pi weewxd[720]: ERROR weewx.restx: WOW: Failed 
> to publish record 2024-05-31 17:48:00 CEST (1717170480): Failed upload 
> after 3 tries
> maj 31 17:51:28 raspberry-pi weewxd[720]: INFO weewx.restx: 
> Wunderground-RF: Published record 2024-05-31 17:49:19 CEST (1717170559)
> maj 31 17:51:53 raspberry-pi weewxd[720]: INFO weewx.restx: 
> Wunderground-RF: Published record 2024-05-31 17:49:51 CEST (1717170591)
> maj 31 17:52:13 raspberry-pi weewxd[720]: INFO weewx.restx: 
> Wunderground-RF: Published record 2024-05-31 17:50:23 CEST (1717170623)
> maj 

[weewx-user] Re: Problem with bookworm install wee_config appears missing

['michael.k...@gmx.at' via weewx-user]

5.0 did change the utilities. Take a look at

https://www.weewx.com/docs/5.0/utilities/weectl-station/

If you don't like journalctl, you can configure your own weewx logs like 
this (just an example, it will, log to  /home/pi/weewx-data/log/weewxd.log  
):
##

[Logging]
version = 1
disable_existing_loggers = False

# Root logger
[[root]]
level = INFO
handlers = rotate,#console

# Additional loggers would go in the following section. This is useful 
for tailoring logging
# for individual modules.
[[loggers]]

# Definitions of possible logging destinations
[[handlers]]

# Log to a set of rotating files
[[[rotate]]]
level = INFO
formatter = verbose
class = logging.handlers.RotatingFileHandler
filename = /home/pi/weewx-data/log/weewxd.log
maxBytes = 1000
backupCount = 4

# Log to console
#[[[console]]]
#level = DEBUG
#formatter = verbose
#class = logging.StreamHandler
# Alternate choice is 'ext://sys.stderr'
#stream = ext://sys.stdout

# How to format log messages
[[formatters]]
[[[simple]]]
format = %(levelname)s %(message)s
[[[standard]]]
format = {process_name}[%(process)d] %(levelname)s %(name)s: 
%(message)s
[[[verbose]]]
format = %(asctime)s {process_name}[%(process)d] %(levelname)s 
%(name)s: %(message)s
# Format to use for dates and times:
datefmt = %Y-%m-%d %H:%M:%S



William Webb schrieb am Freitag, 31. Mai 2024 um 23:06:40 UTC+2:

> First some background then my question:
>
> I just installed a fresh installation of Weewx 5 on a PI 4 running 
> bookworm .  I uses the apt-get install method. All is nearly well.  I 
> discovered that: 
>
> to look at a real-time system log you need to use: *journalctl -f*
>
> to stop and start you need to use: *sudo service weewx stop*
> * sudo service 
> weewx start*
>
> Files appear to be located in:  */usr/share/weewx/ *and */etc/w*eewx
>
> Strange but okay.  I had to put my wmII.py driver directly in the driver 
> folder.
>
> Now the question:  I can not find wee_config anywhere.  Am I blind?  Is it 
> missing?  I am starting to be sorry that I am using bookworm.  There 
> doesn't appear to be bookworm instructions.
>
> I don't have any hair left to tear out.
> 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/4a2fe000-b062-4320-91c3-1dbc1a025eb7n%40googlegroups.com.

[weewx-user] Re: user "weewx" not being created

['michael.k...@gmx.at' via weewx-user]

With apache2 you can symlink /var/www/html/weewx -> 
/home/bg/weewx-data/public_html/ and browse your site on 
http://ip-of-the-pi/weewx, but you most likely have to change permissions 
to the home of the user "bg" first with sudo chmod a+rx /home/bg

vince schrieb am Mittwoch, 29. Mai 2024 um 22:50:10 UTC+2:

> As I said, V5 pip runs as whatever unprivileged user you ran pip as, so no 
> there is no required username. I installed as ‘pi’ so it runs as ‘pi’.
>
> Any webserver works as long as the unprivileged user weewx runs as can 
> write to the output directory you configured things to write to…and as long 
> as the other unprivileged user yout webserver runs as can read those files. 
>  There are many past threads and wiki and faq discussions of the many ways 
> to set that up
>
> On Wednesday, May 29, 2024 at 1:30:58 PM UTC-7 bgra...@umw.edu wrote:
>
>> Thanks Vince and Tom. I’m still curious. Is group « weewx » necessary to 
>> be present? It wasn’t created with the pip install.
>> Also, I already have Apache2 installed. Can I simlink to that or is it 
>> better to have nginx? Thanks and much appreciated for all the work you have 
>> put into weewx!
>> Cheers,
>> Bob
>>
>>
>> On Tuesday, May 28, 2024 at 6:51:06 PM UTC-4 vince wrote:
>>
>>> If you are doing a pip install, it will install and configure itself as 
>>> the user 'pip' is run as.
>>>
>>> For your other issue it is likely you neglected to add the webserver of 
>>> your choice.  Just do "sudo systemctl add nginx" for one that works.
>>>
>>> On Tuesday, May 28, 2024 at 2:23:35 PM UTC-7 bgra...@umw.edu wrote:
>>>
 Hello,
 I have an RPI5 running bookworm on which I want to setup a test site of 
 weewx 5. I have the latest 4.10.2 which has been running on an Ubuntu 
 machine for 10+ years (grattans.org/wx). Not being a programmer, I'm 
 trying to get things setup before I make the permanent move.

 I have noticed that the user "weewx" has not been created and I'm 
 following direction for a pip install. I have created the primary user 
 "bg" 
 rather than "pi" and wonder if that is a problem?

 The simulator seems to be running and posting to 
 /home/bg/weewx-data/public_html/index.html but I am unable to display the 
 page.

 I'm certain there is something simple I'm not doing here but am rather 
 stuck. Thanks for any suggestions.  Below is a service status.

 Many thanks in advance.
 Bob

 weewx.service - WeeWX weather system
  Loaded: loaded (/etc/systemd/system/weewx.service; enabled; 
 preset: enabled)
  Active: active (running) since Tue 2024-05-28 11:19:23 EDT; 6h ago
Docs: https://weewx.com/docs
Main PID: 1036 (python3)
   Tasks: 1 (limit: 9248)
 CPU: 52.847s
  CGroup: /system.slice/weewx.service
  └─1036 /home/bg/weewx-venv/bin/python3 
 /home/bg/weewx-venv/lib/python3.11/site-packages/weewxd.py 
 /home/bg/weewx-data/weewx.conf

 May 28 17:15:15 RPI5 weewxd[1036]: INFO weewx.manager: Added record 
 2024-05-28 17:15:00 EDT (1716930900) to database 'weewx.sdb'
 May 28 17:15:15 RPI5 weewxd[1036]: INFO weewx.manager: Added record 
 2024-05-28 17:15:00 EDT (1716930900) to daily summary in 'weewx.sdb'
 May 28 17:15:16 RPI5 weewxd[1036]: INFO weewx.cheetahgenerator: 
 Generated 8 files for report SeasonsReport in 0.32 seconds
 May 28 17:15:16 RPI5 weewxd[1036]: INFO weewx.imagegenerator: Generated 
 15 images for report SeasonsReport in 0.21 seconds
 May 28 17:15:16 RPI5 weewxd[1036]: INFO weewx.reportengine: Copied 0 
 files to /home/bg/weewx-data/public_html
 May 28 17:20:15 RPI5 weewxd[1036]: INFO weewx.manager: Added record 
 2024-05-28 17:20:00 EDT (1716931200) to database 'weewx.sdb'
 May 28 17:20:15 RPI5 weewxd[1036]: INFO weewx.manager: Added record 
 2024-05-28 17:20:00 EDT (1716931200) to daily summary in 'weewx.sdb'
 May 28 17:20:16 RPI5 weewxd[1036]: INFO weewx.cheetahgenerator: 
 Generated 8 files for report SeasonsReport in 0.32 seconds
 May 28 17:20:16 RPI5 weewxd[1036]: INFO weewx.imagegenerator: Generated 
 15 images for report SeasonsReport in 0.21 seconds
 May 28 17:20:16 RPI5 weewxd[1036]: INFO weewx.reportengine: Copied 0 
 files to /home/bg/weewx-data/public_html

>>>

-- 
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/6d3764f2-b529-4944-921e-0fc69332687en%40googlegroups.com.

[weewx-user] Re: user "weewx" not being created

['michael.k...@gmx.at' via weewx-user]

With apache2 you can symlink /var/www/weewx -> 
/home/bg/weewx-data/public_html/ and browse your site on 
http://ip-of-the-pi/weewx, but you most likely have to change permissions 
to the home of the user "bg" first with sudo chmod a+rx /home/bg

vince schrieb am Mittwoch, 29. Mai 2024 um 22:50:10 UTC+2:

> As I said, V5 pip runs as whatever unprivileged user you ran pip as, so no 
> there is no required username. I installed as ‘pi’ so it runs as ‘pi’.
>
> Any webserver works as long as the unprivileged user weewx runs as can 
> write to the output directory you configured things to write to…and as long 
> as the other unprivileged user yout webserver runs as can read those files. 
>  There are many past threads and wiki and faq discussions of the many ways 
> to set that up
>
> On Wednesday, May 29, 2024 at 1:30:58 PM UTC-7 bgra...@umw.edu wrote:
>
>> Thanks Vince and Tom. I’m still curious. Is group « weewx » necessary to 
>> be present? It wasn’t created with the pip install.
>> Also, I already have Apache2 installed. Can I simlink to that or is it 
>> better to have nginx? Thanks and much appreciated for all the work you have 
>> put into weewx!
>> Cheers,
>> Bob
>>
>>
>> On Tuesday, May 28, 2024 at 6:51:06 PM UTC-4 vince wrote:
>>
>>> If you are doing a pip install, it will install and configure itself as 
>>> the user 'pip' is run as.
>>>
>>> For your other issue it is likely you neglected to add the webserver of 
>>> your choice.  Just do "sudo systemctl add nginx" for one that works.
>>>
>>> On Tuesday, May 28, 2024 at 2:23:35 PM UTC-7 bgra...@umw.edu wrote:
>>>
 Hello,
 I have an RPI5 running bookworm on which I want to setup a test site of 
 weewx 5. I have the latest 4.10.2 which has been running on an Ubuntu 
 machine for 10+ years (grattans.org/wx). Not being a programmer, I'm 
 trying to get things setup before I make the permanent move.

 I have noticed that the user "weewx" has not been created and I'm 
 following direction for a pip install. I have created the primary user 
 "bg" 
 rather than "pi" and wonder if that is a problem?

 The simulator seems to be running and posting to 
 /home/bg/weewx-data/public_html/index.html but I am unable to display the 
 page.

 I'm certain there is something simple I'm not doing here but am rather 
 stuck. Thanks for any suggestions.  Below is a service status.

 Many thanks in advance.
 Bob

 weewx.service - WeeWX weather system
  Loaded: loaded (/etc/systemd/system/weewx.service; enabled; 
 preset: enabled)
  Active: active (running) since Tue 2024-05-28 11:19:23 EDT; 6h ago
Docs: https://weewx.com/docs
Main PID: 1036 (python3)
   Tasks: 1 (limit: 9248)
 CPU: 52.847s
  CGroup: /system.slice/weewx.service
  └─1036 /home/bg/weewx-venv/bin/python3 
 /home/bg/weewx-venv/lib/python3.11/site-packages/weewxd.py 
 /home/bg/weewx-data/weewx.conf

 May 28 17:15:15 RPI5 weewxd[1036]: INFO weewx.manager: Added record 
 2024-05-28 17:15:00 EDT (1716930900) to database 'weewx.sdb'
 May 28 17:15:15 RPI5 weewxd[1036]: INFO weewx.manager: Added record 
 2024-05-28 17:15:00 EDT (1716930900) to daily summary in 'weewx.sdb'
 May 28 17:15:16 RPI5 weewxd[1036]: INFO weewx.cheetahgenerator: 
 Generated 8 files for report SeasonsReport in 0.32 seconds
 May 28 17:15:16 RPI5 weewxd[1036]: INFO weewx.imagegenerator: Generated 
 15 images for report SeasonsReport in 0.21 seconds
 May 28 17:15:16 RPI5 weewxd[1036]: INFO weewx.reportengine: Copied 0 
 files to /home/bg/weewx-data/public_html
 May 28 17:20:15 RPI5 weewxd[1036]: INFO weewx.manager: Added record 
 2024-05-28 17:20:00 EDT (1716931200) to database 'weewx.sdb'
 May 28 17:20:15 RPI5 weewxd[1036]: INFO weewx.manager: Added record 
 2024-05-28 17:20:00 EDT (1716931200) to daily summary in 'weewx.sdb'
 May 28 17:20:16 RPI5 weewxd[1036]: INFO weewx.cheetahgenerator: 
 Generated 8 files for report SeasonsReport in 0.32 seconds
 May 28 17:20:16 RPI5 weewxd[1036]: INFO weewx.imagegenerator: Generated 
 15 images for report SeasonsReport in 0.21 seconds
 May 28 17:20:16 RPI5 weewxd[1036]: INFO weewx.reportengine: Copied 0 
 files to /home/bg/weewx-data/public_html

>>>

-- 
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/d385452f-af74-4b1b-9f45-64c468acc837n%40googlegroups.com.

Re: [weewx-user] Installing a new template

['michael.k...@gmx.at' via weewx-user]

I don't think it is really spot on, because I just realized that Marco 
means "skin" when he is writing "template". I understood "template" in the 
way a cheetah template (a *.html.tmpl) is meant.

Anyway, the result of utilizing weectl extension install will most likely 
be satisfying for Marco's needs.

Further, fuzzy-archer supports adding new cheetah-templates in a way, that 
this kind of customization will survive an update of the skin to another 
version, which is described in the wiki link.

Tom Keffer schrieb am Mittwoch, 29. Mai 2024 um 14:06:32 UTC+2:

> Marco,
>
> Michael's post is spot on, but you should read the *Upgrade Guide 
> *. It explains what happened to 
> wee_extension.
>
> On Wed, May 29, 2024 at 12:50 AM Marco Citossi  wrote:
>
>> I would like to install a new template.
>> For example this one 
>> https://github.com/brewster76/fuzzy-archer/blob/master/INSTALL
>> Anyway I've installed weewx (now working) in Oracle Linux 8.9 using 
>> Redhat instructions but I don't find utilities like wee_extension.
>> http://weewx.com/docs/5.0/quickstarts/redhat/
>> So how can I install a new template? Should I copy files under 
>> public_html in a new folder e and change the path in weewx.conf?
>> Do you suggest some other clean templates as Sofaskin that is not 
>> supported anymore?
>> Thanks.
>> Marco
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/a21442f9-49c2-4e5b-b605-35a789bd0b8bn%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/f69e659c-e558-4997-ab92-00b7fe7b7ab0n%40googlegroups.com.

[weewx-user] Re: Installing a new template

['michael.k...@gmx.at' via weewx-user]

Hi Marco, for fuzzy-archer, simply follow the instructions on your default 
"about.html" ("Custom pages") or consider checking the 
wiki: https://github.com/brewster76/fuzzy-archer/wiki/Customization#custom-pages

For WeeWX 5 the utility works like this:

weectl extension install 
http://github.com/brewster76/fuzzy-archer/archive/master.zip

(Depending on your installation, some "sudo" might be necessary)

Marco Citossi schrieb am Mittwoch, 29. Mai 2024 um 09:50:01 UTC+2:

> I would like to install a new template.
> For example this one 
> https://github.com/brewster76/fuzzy-archer/blob/master/INSTALL
> Anyway I've installed weewx (now working) in Oracle Linux 8.9 using Redhat 
> instructions but I don't find utilities like wee_extension.
> http://weewx.com/docs/5.0/quickstarts/redhat/
> So how can I install a new template? Should I copy files under public_html 
> in a new folder e and change the path in weewx.conf?
> Do you suggest some other clean templates as Sofaskin that is not 
> supported anymore?
> Thanks.
> Marco
>

-- 
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/3754cbcf-77f4-48fe-9912-8b7cf03657e3n%40googlegroups.com.

[weewx-user] Any users here experiencing this storm in Oklahoma/Texas area today?

['michael.k...@gmx.at' via weewx-user]

It looks massive, for more than 12 hours now, hoping it doesn't cause 
damage.

https://www.wetteronline.de/wetterradar/taxach?wrm=6&wry=47.73,13.07&wrn=VGF4YWNo&wrg=11350&wrp=periodLast12h&wrx=30.45,-94.08&wrt=20240528-0600-2&wro=true

[image: 2024-05-28 20_39_15.png]

-- 
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/09f04ca4-12a8-48c7-b886-f851ee41c08an%40googlegroups.com.

Re: [weewx-user] beta of V5.1.0 is available

['michael.k...@gmx.at' via weewx-user]

Ah! I see.
An I think I've fixed the issue my skin had with the locale. It's late 
here, I'll keep you posted.

Tom Keffer schrieb am Montag, 27. Mai 2024 um 21:40:04 UTC+2:

> Thanks, Michael, for checking the locale feature!
>
> The version number in the configuration file is the version of weewx that 
> created it, not the installed version.
>
> On Mon, May 27, 2024 at 12:36 PM 'michael.k...@gmx.at' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> I did a pip upgrade on my test system, which runs reports in different 
>> languages, results:
>>
>> lang = de_AT.utf8: https://kainzbauer.net/weather/Test/Rif/de/index.html 
>> => no difference
>> lang = en_US.utf8: https://kainzbauer.net/weather/Test/Rif/en/index.html 
>> => now displaying number with "." as decimal separator, etc. Hooray!
>>
>> So the main feature seems to work :)
>>
>> The version in my weewx.conf wasn't updated an still reads 5.0.2, the log 
>> is telling me:
>>
>> 2024-05-27 21:28:36 weewxd[14272] INFO weewxd: Initializing weewxd 
>> version 5.1.0b4
>> 2024-05-27 21:28:36 weewxd[14272] INFO weewxd: Locale:   'de_AT.UTF-8'
>>
>> Tom Keffer schrieb am Montag, 27. Mai 2024 um 01:59:11 UTC+2:
>>
>>> My fault with the instructions. If you're doing a clean installation, 
>>> the problem is that the test PyPi repository has just V5.1.0, but none of 
>>> its requirements, such as Pillow, CT3, etc. To get those, you need the main 
>>> repository.
>>>
>>> So, the instructions for a clean install become:
>>>
>>> *python -m pip install -i https://test.pypi.org/simple/ 
>>> <https://test.pypi.org/simple/> --extra-index-url https://pypi.org/simple 
>>> <https://pypi.org/simple> weewx*
>>>
>>>
>>>
>>> On Sun, May 26, 2024 at 4:26 PM vince  wrote:
>>>
>>>> Thanks.  As I mentioned in email, I had issues there too.  I wound up 
>>>> doing a force (re)install of 5.0.2 then an install (not a --upgrade) which 
>>>> picked up 5.1.0b4 that time.  Pretty odd.
>>>>
>>>> Glad to see logging via syslog shows what version is actually 
>>>> starting...
>>>>
>>>> pi@pi4:/var/log/weewx$ grep "Initializing" weewxd-vp2.log
>>>> May 26 10:17:51 pi4 weewxd-vp2[32270]: INFO __main__: Initializing 
>>>> weewxd version 5.0.2
>>>> May 26 10:25:59 pi4 weewxd-vp2[32469]: INFO __main__: Initializing 
>>>> weewxd version 5.0.2
>>>> May 26 12:08:31 pi4 weewxd-vp2[1217]: INFO __main__: Initializing 
>>>> weewxd-vp2 version 5.1.0b4
>>>>
>>>> The first two are after attempts to upgrade that didn't upgrade for 
>>>> some reason.  The last one was after specifying a version ala "pip 
>>>> install -i https://test.pypi.org/simple/ weewx==5.1.0b4"
>>>>
>>>>
>>>>
>>>> On Sunday, May 26, 2024 at 4:06:05 PM UTC-7 Tom Keffer wrote:
>>>>
>>>>> The logging of loop_on_init and group ownerships both worked for me.
>>>>>
>>>>> Make sure you're actually running v5.1.0. I had some issues doing a 
>>>>> clean install, which, long story short, ended up with me installing 
>>>>> v5.0.2. 
>>>>> I then upgraded.
>>>>>
>>>>> On Sun, May 26, 2024 at 10:51 AM vince  wrote:
>>>>>
>>>>>> Couple things.   In my case I'm upgrading 5.0.2 pip multi but I 'did' 
>>>>>> have a hand-patched weewxd.py to fix the loop_on_init not working issue.
>>>>>>
>>>>>> First - I had to stop all weewx instances before forcing a pip 
>>>>>> upgrade to get the weewxd.py file to actually upgrade by adding the 
>>>>>> --force-reinstall switch to the pip command.  Can't explain that at all 
>>>>>> unless pip has some misfeature under the hood that won't change a file 
>>>>>> later hand-edited in version X that is upgraded in X+1.  Odd.
>>>>>>
>>>>>> Second - what branch is the 5.1.0 beta off of ?  I know there are 
>>>>>> frequently changes made on master and not on development (ugh),  so 
>>>>>> wondering if there's some kind of backmerge massacre or the like that 
>>>>>> happened.   I guess I'm uncertain the changes you 'think' are in the 
>>>>&

Re: [weewx-user] beta of V5.1.0 is available

['michael.k...@gmx.at' via weewx-user]

Lol, the JS parts of my skin doesn't seem to be compatible with the new 
locale feature. Gotta work that out.

michael.k...@gmx.at schrieb am Montag, 27. Mai 2024 um 21:35:59 UTC+2:

> I did a pip upgrade on my test system, which runs reports in different 
> languages, results:
>
> lang = de_AT.utf8: https://kainzbauer.net/weather/Test/Rif/de/index.html 
> => no difference
> lang = en_US.utf8: https://kainzbauer.net/weather/Test/Rif/en/index.html 
> => now displaying number with "." as decimal separator, etc. Hooray!
>
> So the main feature seems to work :)
>
> The version in my weewx.conf wasn't updated an still reads 5.0.2, the log 
> is telling me:
>
> 2024-05-27 21:28:36 weewxd[14272] INFO weewxd: Initializing weewxd version 
> 5.1.0b4
> 2024-05-27 21:28:36 weewxd[14272] INFO weewxd: Locale:   'de_AT.UTF-8'
>
> Tom Keffer schrieb am Montag, 27. Mai 2024 um 01:59:11 UTC+2:
>
>> My fault with the instructions. If you're doing a clean installation, the 
>> problem is that the test PyPi repository has just V5.1.0, but none of its 
>> requirements, such as Pillow, CT3, etc. To get those, you need the main 
>> repository.
>>
>> So, the instructions for a clean install become:
>>
>> *python -m pip install -i https://test.pypi.org/simple/ 
>>  --extra-index-url https://pypi.org/simple 
>>  weewx*
>>
>>
>>
>> On Sun, May 26, 2024 at 4:26 PM vince  wrote:
>>
>>> Thanks.  As I mentioned in email, I had issues there too.  I wound up 
>>> doing a force (re)install of 5.0.2 then an install (not a --upgrade) which 
>>> picked up 5.1.0b4 that time.  Pretty odd.
>>>
>>> Glad to see logging via syslog shows what version is actually starting...
>>>
>>> pi@pi4:/var/log/weewx$ grep "Initializing" weewxd-vp2.log
>>> May 26 10:17:51 pi4 weewxd-vp2[32270]: INFO __main__: Initializing 
>>> weewxd version 5.0.2
>>> May 26 10:25:59 pi4 weewxd-vp2[32469]: INFO __main__: Initializing 
>>> weewxd version 5.0.2
>>> May 26 12:08:31 pi4 weewxd-vp2[1217]: INFO __main__: Initializing 
>>> weewxd-vp2 version 5.1.0b4
>>>
>>> The first two are after attempts to upgrade that didn't upgrade for some 
>>> reason.  The last one was after specifying a version ala "pip install 
>>> -i https://test.pypi.org/simple/ weewx==5.1.0b4"
>>>
>>>
>>>
>>> On Sunday, May 26, 2024 at 4:06:05 PM UTC-7 Tom Keffer wrote:
>>>
 The logging of loop_on_init and group ownerships both worked for me.

 Make sure you're actually running v5.1.0. I had some issues doing a 
 clean install, which, long story short, ended up with me installing 
 v5.0.2. 
 I then upgraded.

 On Sun, May 26, 2024 at 10:51 AM vince  wrote:

> Couple things.   In my case I'm upgrading 5.0.2 pip multi but I 'did' 
> have a hand-patched weewxd.py to fix the loop_on_init not working issue.
>
> First - I had to stop all weewx instances before forcing a pip upgrade 
> to get the weewxd.py file to actually upgrade by adding the 
> --force-reinstall switch to the pip command.  Can't explain that at all 
> unless pip has some misfeature under the hood that won't change a file 
> later hand-edited in version X that is upgraded in X+1.  Odd.
>
> Second - what branch is the 5.1.0 beta off of ?  I know there are 
> frequently changes made on master and not on development (ugh),  so 
> wondering if there's some kind of backmerge massacre or the like that 
> happened.   I guess I'm uncertain the changes you 'think' are in the beta 
> code are really in there.  Might be worth a check.
>
> Some examples:
>
>- no loop_on_init messages are logged (pr 935)
>- no listing of user groups is logged  (pr 934)
>
> Best guess is you had a refactor massacre or merge massacre in 
> https://github.com/weewx/weewx/commit/301872148163052e8860eb371fc7f8627a3ba881#diff-d4000f2ead6f89d7e914b2afed472744a1327c53978ab97a114fb79d7fdfac3a
>  
> but at this point I can't follow which (believed to be in there) changes 
> are actually in the current code on any branch.
>
> On Saturday, May 25, 2024 at 4:05:02 PM UTC-7 Ian Millard wrote:
>
>> Tom,
>>
>> With a pip install, a big tick in the box for the 4 four bullet 
>> points. Everything executed perfectly as far as I can see. The journal 
>> log 
>> is clean with no errors. Language options not tested,
>>
>> Skins, Seasons and weewx-DivumWX Alpha (replacement for 
>> weewx-Weather34)
>> Hardware, Various Ecowitt  and Ecowitt 2000 Hub
>> Driver weewx-gw1000
>> Server Debian 12, Apache2 running on a re-purposed Apple MacMini
>> URLs, https://claydonsweather.org.uk and 
>>https://claydonsweather.org.uk/seasons
>>
>> IM
>>
>>
>> On 25 May 2024, at 23:06, Tom Keffer  wrote:
>>
>> python3 -m pip install weewx --upgrade -i 
>>
>>
>> -- 
> You received this message beca

Re: [weewx-user] beta of V5.1.0 is available

['michael.k...@gmx.at' via weewx-user]

I did a pip upgrade on my test system, which runs reports in different 
languages, results:

lang = de_AT.utf8: https://kainzbauer.net/weather/Test/Rif/de/index.html => 
no difference
lang = en_US.utf8: https://kainzbauer.net/weather/Test/Rif/en/index.html => 
now displaying number with "." as decimal separator, etc. Hooray!

So the main feature seems to work :)

The version in my weewx.conf wasn't updated an still reads 5.0.2, the log 
is telling me:

2024-05-27 21:28:36 weewxd[14272] INFO weewxd: Initializing weewxd version 
5.1.0b4
2024-05-27 21:28:36 weewxd[14272] INFO weewxd: Locale:   'de_AT.UTF-8'

Tom Keffer schrieb am Montag, 27. Mai 2024 um 01:59:11 UTC+2:

> My fault with the instructions. If you're doing a clean installation, the 
> problem is that the test PyPi repository has just V5.1.0, but none of its 
> requirements, such as Pillow, CT3, etc. To get those, you need the main 
> repository.
>
> So, the instructions for a clean install become:
>
> *python -m pip install -i https://test.pypi.org/simple/ 
>  --extra-index-url https://pypi.org/simple 
>  weewx*
>
>
>
> On Sun, May 26, 2024 at 4:26 PM vince  wrote:
>
>> Thanks.  As I mentioned in email, I had issues there too.  I wound up 
>> doing a force (re)install of 5.0.2 then an install (not a --upgrade) which 
>> picked up 5.1.0b4 that time.  Pretty odd.
>>
>> Glad to see logging via syslog shows what version is actually starting...
>>
>> pi@pi4:/var/log/weewx$ grep "Initializing" weewxd-vp2.log
>> May 26 10:17:51 pi4 weewxd-vp2[32270]: INFO __main__: Initializing weewxd 
>> version 5.0.2
>> May 26 10:25:59 pi4 weewxd-vp2[32469]: INFO __main__: Initializing weewxd 
>> version 5.0.2
>> May 26 12:08:31 pi4 weewxd-vp2[1217]: INFO __main__: Initializing 
>> weewxd-vp2 version 5.1.0b4
>>
>> The first two are after attempts to upgrade that didn't upgrade for some 
>> reason.  The last one was after specifying a version ala "pip install -i 
>> https://test.pypi.org/simple/ weewx==5.1.0b4"
>>
>>
>>
>> On Sunday, May 26, 2024 at 4:06:05 PM UTC-7 Tom Keffer wrote:
>>
>>> The logging of loop_on_init and group ownerships both worked for me.
>>>
>>> Make sure you're actually running v5.1.0. I had some issues doing a 
>>> clean install, which, long story short, ended up with me installing v5.0.2. 
>>> I then upgraded.
>>>
>>> On Sun, May 26, 2024 at 10:51 AM vince  wrote:
>>>
 Couple things.   In my case I'm upgrading 5.0.2 pip multi but I 'did' 
 have a hand-patched weewxd.py to fix the loop_on_init not working issue.

 First - I had to stop all weewx instances before forcing a pip upgrade 
 to get the weewxd.py file to actually upgrade by adding the 
 --force-reinstall switch to the pip command.  Can't explain that at all 
 unless pip has some misfeature under the hood that won't change a file 
 later hand-edited in version X that is upgraded in X+1.  Odd.

 Second - what branch is the 5.1.0 beta off of ?  I know there are 
 frequently changes made on master and not on development (ugh),  so 
 wondering if there's some kind of backmerge massacre or the like that 
 happened.   I guess I'm uncertain the changes you 'think' are in the beta 
 code are really in there.  Might be worth a check.

 Some examples:

- no loop_on_init messages are logged (pr 935)
- no listing of user groups is logged  (pr 934)

 Best guess is you had a refactor massacre or merge massacre in 
 https://github.com/weewx/weewx/commit/301872148163052e8860eb371fc7f8627a3ba881#diff-d4000f2ead6f89d7e914b2afed472744a1327c53978ab97a114fb79d7fdfac3a
  
 but at this point I can't follow which (believed to be in there) changes 
 are actually in the current code on any branch.

 On Saturday, May 25, 2024 at 4:05:02 PM UTC-7 Ian Millard wrote:

> Tom,
>
> With a pip install, a big tick in the box for the 4 four bullet 
> points. Everything executed perfectly as far as I can see. The journal 
> log 
> is clean with no errors. Language options not tested,
>
> Skins, Seasons and weewx-DivumWX Alpha (replacement for 
> weewx-Weather34)
> Hardware, Various Ecowitt  and Ecowitt 2000 Hub
> Driver weewx-gw1000
> Server Debian 12, Apache2 running on a re-purposed Apple MacMini
> URLs, https://claydonsweather.org.uk and 
>https://claydonsweather.org.uk/seasons
>
> IM
>
>
> On 25 May 2024, at 23:06, Tom Keffer  wrote:
>
> python3 -m pip install weewx --upgrade -i 
>
>
> -- 
 You received this message because you are subscribed to the Google 
 Groups "weewx-user" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to weewx-user+...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/f652f376-0eb1-450c-988b-1

Re: [weewx-user] Your hardware experience (for running WeeWX, the service)

['michael.k...@gmx.at' via weewx-user]

Yes, Gen24 with BYD HVM 22.1 and PV Point. I've actually never tested how 
the UPS (EATON Ellipse PRO 1200) likes the PV Point. I am aware of the 
Frequencies when in Backup mode. I don't know what full backup solution the 
electrician would offer, but it would cost €700 including work. The real 
problem that makes it so much more expensive, is that my distributor box is 
full, and the solution needs 17 more slots on a DIN rail. A lot of work and 
a a couple of hundreds for the hardware.

Gábor Szabados schrieb am Freitag, 17. Mai 2024 um 14:46:55 UTC+2:

> As I remember the EU specs is 50Hz +/-1%, so all those look good to me.
>
> Regarding the battery and backup socket, I guess that must be a Fronius 
> Gen24 Plus with a BYD battery, and the socket would be the PV Point. As 
> just a note, if you don't know it yet, the PV Point socket and the Full 
> Backup operates at 54Hz. It is not really advertised, but the point of it, 
> to knock out any other Inverters as they would detect an out-of-spec line 
> frequency and would shut down.
>
> And if you consider the Enwitec backup box, which as you stated would be 
> more than a 1000 with installation, there is a cheaper box also on the 
> market by Keno the SH-GEN24-SZR, but still around 1000 without 
> installation. 
>
> I have one, but have not installed it yet, and felt the need recently when 
> the operator did a 3+ hours maintenance and all the UPS depleted in the 
> house.
>
> On Thu, 16 May 2024, 16:56 Karen K,  wrote:
>
>> michael.k...@gmx.at schrieb am Donnerstag, 16. Mai 2024 um 15:46:28 
>> UTC+2:
>>
>> Since the (public) power grid is part of the hardware your local weewx 
>> installation is running on, this is far from being off-topic. 
>>
>>
>> There are 3 types of UPS available: off-line, stand-by, and on-line. The 
>> first one is off as long as grid power is available and starts when the 
>> grid power goes off. The second one is similar, but it is in stand-by. So 
>> it start faster than the first one. The on-line one separates the grid and 
>> the output entirely. They are connected by DC only. So this type can 
>> additionally filter surges etc. The output frequency for the on-line type 
>> only depends on the internal circuit, while for the off-line and stand-by 
>> type the output frequency is always the same as the grid frequency.
>>
>> I use an on-line UPS and hope that will result in less damage in case of 
>> over-voltage, surges, and lightning strokes.
>>
>> To compare to Cameron's histogram I did one myself, based on 5 minutes 
>> averages of the grid frequency (NOT the UPS output frequency):
>>
>> [image: netzfrequenzhistogramm.png]
>>
>> This one has the peak at 50.00 Hz.
>>
>> -- 
>> 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/HBDfW-ayRyI/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/78c65e41-5ac1-4e13-9644-e46beb078147n%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/2e93006e-941c-4bd0-a265-dc9b10ed66b0n%40googlegroups.com.

Re: [weewx-user] Your hardware experience (for running WeeWX, the service)

['michael.k...@gmx.at' via weewx-user]

Gauß would connect to your power grid :D
Karen K schrieb am Donnerstag, 16. Mai 2024 um 16:56:45 UTC+2:

> michael.k...@gmx.at schrieb am Donnerstag, 16. Mai 2024 um 15:46:28 UTC+2:
>
> Since the (public) power grid is part of the hardware your local weewx 
> installation is running on, this is far from being off-topic. 
>
>
> There are 3 types of UPS available: off-line, stand-by, and on-line. The 
> first one is off as long as grid power is available and starts when the 
> grid power goes off. The second one is similar, but it is in stand-by. So 
> it start faster than the first one. The on-line one separates the grid and 
> the output entirely. They are connected by DC only. So this type can 
> additionally filter surges etc. The output frequency for the on-line type 
> only depends on the internal circuit, while for the off-line and stand-by 
> type the output frequency is always the same as the grid frequency.
>
> I use an on-line UPS and hope that will result in less damage in case of 
> over-voltage, surges, and lightning strokes.
>
> To compare to Cameron's histogram I did one myself, based on 5 minutes 
> averages of the grid frequency (NOT the UPS output frequency):
>
> [image: netzfrequenzhistogramm.png]
>
> This one has the peak at 50.00 Hz.
>
>

-- 
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/8f39266b-9144-43ee-9306-a3057310da8dn%40googlegroups.com.

Re: [weewx-user] Your hardware experience (for running WeeWX, the service)

['michael.k...@gmx.at' via weewx-user]

Since the (public) power grid is part of the hardware your local weewx 
installation is running on, this is far from being off-topic. Yet it's kind 
of complicated to switch to another. My UPS kicked in a couple of times 
already, but I only connected it to the NAS.as long as I am at home I 
shoudn't run into any trobles, if there is a blackout, I have a 22kWh 
battery and my inverter has one socket that provides up to 3600W in case of 
an power outage. I am not sure if I'll invest in an automatic full-backup 
switch, with all the work to be done it will cost way more than €1000...

The new zbox is up and running in the meantime, it sure is a nice little 
computer.

Cameron D schrieb am Donnerstag, 16. Mai 2024 um 04:46:14 UTC+2:

> Will get back on track eventually, but I was inspired by the mains 
> stability plot to look at my data.  I have nearly 13 years of data from my 
> PV system and did a histogram of the daily averages - so far just for 
> frequency.
> [image: distribution of daily averages.png]
> Curious - almost always below 50.0.  I can remember some years ago 
> readiing that the mains  frequency was always manipulated to reach a daiily 
> average of 50.000 Hz, in part  so that old style clocks would run 
> accurately.
> So, what's happening here?
> It seems unlikely that my inverter gets such a simple measurement wrong, 
> so is the correction no longer applied, or is it simply that the 
> corrections are made when the power system  is at lowest load and my 
> inverter is offline?
>
>
> So as not to be totally off-thread, I'll mention my system. I have my 
> weather devices connected directly to an  home server based on an Intel 
> desktop, with a Raid-5 array. I built this in 2010 from three WD black 
> drives and when they had accumulated 10 years of run-time I decided to 
> retire them. I tossed up going to SSD, but decided on WD Reds. After 
> building and copying the new array I then discovered they were the 
> (unspecified) shingled drives. Still, they came with a 3-year warranty, so 
> I thought I'd see how  they went.  All good when I tested nearing the 3  
> years, and 3 months later the first one collapsed dramatically. Out they 
> went, to be replaced by SSDs. The reduced power consumption should more 
> than make up for the cost difference - assuming they  last a reasonable 
> time.
>
> I don't recall any unexpected shutdowns since 2011, so never thought of 
> using a UPS, but I acquired one recently, so thought I'd connect it  up.  I 
> invoked the gods of irony upon myself, by deciding to first test out the 
> Linux drivers for the UPS, before plugging the server  into the UPS power.  
> I'd run out of USB ports on the server, so unplugged the mouse that is  
> never used, plugged in  the USB cable to the UPS and the server instantly 
> started rebooting.
>
> On Wednesday 15 May 2024 at 3:22:24 pm UTC+10 Karen K wrote:
>
>> michael.k...@gmx.at schrieb am Samstag, 24. Februar 2024 um 08:20:17 
>> UTC+1:
>>
>> Also, we have super stable power supply here. Often years without power 
>> surge, the last black some years ago, and this only locally. 
>>
>>
>> Off-topic-comment: That's interesting. The situation at our region is 
>> quite less stable. The voltage jumps up and down, and the frequency is 
>> decreasing actually.
>>
>> [image: netzspannung-8.png]
>>
>> [image: netzfrequenz.png]
>>
>

-- 
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/a1f3113b-c2cb-4220-9e89-1a8f32e180d6n%40googlegroups.com.

Re: [weewx-user] Your hardware experience (for running WeeWX, the service)

['michael.k...@gmx.at' via weewx-user]

Interesting, gotta monitor this, my PV-inverters provide all that data. 

Karen K schrieb am Mittwoch, 15. Mai 2024 um 07:22:24 UTC+2:

> michael.k...@gmx.at schrieb am Samstag, 24. Februar 2024 um 08:20:17 
> UTC+1:
>
> Also, we have super stable power supply here. Often years without power 
> surge, the last black some years ago, and this only locally. 
>
>
> Off-topic-comment: That's interesting. The situation at our region is 
> quite less stable. The voltage jumps up and down, and the frequency is 
> decreasing actually.
>
> [image: netzspannung-8.png]
>
> [image: netzfrequenz.png]
>

-- 
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/773f657e-9a43-4bed-aa8c-d657e24310c7n%40googlegroups.com.

Re: [weewx-user] Re: removed bad rainrate data but this did not reflect in totals

['michael.k...@gmx.at' via weewx-user]

Good to know. I can't remember how I recalculated the rainRate some years 
ago, when I switched from an 1h-interval to a 15-min interval. Obviously 
not with --calc-missing, because it worked :)

gjr80 schrieb am Dienstag, 14. Mai 2024 um 23:55:01 UTC+2:

> Whilst rainRate may be a value calculated by WeeWX, the current 
> StdWXCalculate service is limited in that it can only calculate rainRate 
> from loop packet data. In the case of a backfill/recalculate (as with an 
> import) the only rain data available is from archive records and hence 
> rainRate is not calculated. In these cases rainRate must be manually 
> calculated.
>
> Issue #787  was raised to 
> address this behaviour for imports. Any resolution to issue #787 would 
> likely fix the rainRate re-calculate behaviour as well, but I have no 
>  timeframe for when issue #787 might be addressed.
>
> Gary
>
> On Tuesday 14 May 2024 at 23:39:19 UTC+10 michael.k...@gmx.at wrote:
>
>> rainRate is a calculated value: 
>> https://weewx.com/docs/5.0/reference/weewx-options/stdwxcalculate/
>>
>> So first you correct all the rain values and may want to delete rainRate 
>> values from your database
>> Second recalculate them: 
>> https://weewx.com/docs/5.0/utilities/weectl-database/#calculate-missing-derived-variables
>> Third drop the daily summaries 
>> https://weewx.com/docs/5.0/utilities/weectl-database/#drop-the-daily-summaries
>> Fourth rebuild the daily summaries 
>> https://weewx.com/docs/5.0/utilities/weectl-database/#rebuild-the-daily-summaries
>>
>> If your archive values are sane, your totals will be sane then.
>> Consider only dropping/rebuilding the daily summaries for days with bad 
>> data, this will be faster and you won't lose the exact timestamps/value for 
>> min/max records on all the other days. See these switches in the docs:  
>> [[--date=-mm-dd] 
>> | [--from=-mm-dd] [--to=-mm-dd]]
>>
>> Kevin Crivelli schrieb am Dienstag, 14. Mai 2024 um 14:48:16 UTC+2:
>>
>>> I did everything here. It is how I was able to remove the bad rainrate 
>>> data. The problem now is that while the bad rainrate data is gone, the 
>>> resulting rain total data is not. I need to get the rain totals to reflect 
>>> the rainrate data now. The totals are still considering the bad rainrate 
>>> data that has been removed. 
>>>
>>> On Tue, May 7, 2024, 2:22 PM vince  wrote:
>>>
 You might want to consult the wiki.  That's why hundreds of hours have 
 been spent creating it.

 https://github.com/weewx/weewx/wiki/Cleaning-up-old-'bad'-data

 On Tuesday, May 7, 2024 at 9:19:04 AM UTC-7 Kevin Crivelli wrote:

> or perhaps there is a way to rebuild the raintotals fields from the 
> current rainrate data
>
> On Tuesday, May 7, 2024 at 12:17:20 PM UTC-4 Kevin Crivelli wrote:
>
>> I removed bad rainrate data but it did not effect the raintotals 
>> field. I was able to determine the epoch date-time for the bad rainrate 
>> data. Having those I was going to delete the rain_total values for those 
>> entries but how would I have that then reflect in the following 
>> rain_total 
>> fields?
>>
>> chatgpt gave me this which I feel is a start but I'm not quite there 
>> yet. anyone able to help me with this?
>>
>> -- Store the rain total of the specific datetime in a variable
>> SET @deleted_rain_total = (SELECT rain_total FROM your_table WHERE 
>> datetime = specific_datetime);
>>
>> -- Delete the rain total at the specific datetime
>> DELETE FROM your_table WHERE datetime = specific_datetime;
>>
>> -- Decrease the rain totals for the following datetimes
>> UPDATE your_table
>> SET rain_total = rain_total - @deleted_rain_total
>> WHERE datetime > specific_datetime;
>>
>> These are the date and times of the entries that need their raintotal 
>> nulled and then the proceeding raintotals to reflect the change
>>
>> 1699559700: 2024-05-10 01:55:00
>> 169956: 2024-05-10 01:56:40
>> 1709221800: 2024-05-26 06:50:00
>> 1709222100: 2024-05-26 06:55:00
>> 1713436800: 2024-06-16 10:00:00
>> 1713437100: 2024-06-16 10:05:00
>> 1713780900: 2024-06-20 03:35:00
>> 1713781200: 2024-06-20 03:40:00
>> 1714771200: 2024-06-25 18:40:00
>> 1714771500: 2024-06-25 18:45:00
>> 1699559400: 2024-05-10 01:50:00
>> 1699560300: 2024-05-10 01:51:40
>> 1709221500: 2024-05-26 06:45:00
>> 1713437400: 2024-06-16 10:10:00
>> 1713781500: 2024-06-20 03:05:00
>> 1714771800: 2024-06-25 18:10:00
>>
>> -- 
 You received this message because you are subscribed to the Google 
 Groups "weewx-user" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to weewx-user+...@googlegroups.com.
 To view this discussion on the web visit 
>

Re: [weewx-user] Re: removed bad rainrate data but this did not reflect in totals

['michael.k...@gmx.at' via weewx-user]

rainRate is a calculated value: 
https://weewx.com/docs/5.0/reference/weewx-options/stdwxcalculate/

So first you correct all the rain values and may want to delete rainRate 
values from your database
Second recalculate them: 
https://weewx.com/docs/5.0/utilities/weectl-database/#calculate-missing-derived-variables
Third drop the daily summaries 
https://weewx.com/docs/5.0/utilities/weectl-database/#drop-the-daily-summaries
Fourth rebuild the daily summaries 
https://weewx.com/docs/5.0/utilities/weectl-database/#rebuild-the-daily-summaries

If your archive values are sane, your totals will be sane then.
Consider only dropping/rebuilding the daily summaries for days with bad 
data, this will be faster and you won't lose the exact timestamps/value for 
min/max records on all the other days. See these switches in the docs:  
[[--date=-mm-dd] 
| [--from=-mm-dd] [--to=-mm-dd]]

Kevin Crivelli schrieb am Dienstag, 14. Mai 2024 um 14:48:16 UTC+2:

> I did everything here. It is how I was able to remove the bad rainrate 
> data. The problem now is that while the bad rainrate data is gone, the 
> resulting rain total data is not. I need to get the rain totals to reflect 
> the rainrate data now. The totals are still considering the bad rainrate 
> data that has been removed. 
>
> On Tue, May 7, 2024, 2:22 PM vince  wrote:
>
>> You might want to consult the wiki.  That's why hundreds of hours have 
>> been spent creating it.
>>
>> https://github.com/weewx/weewx/wiki/Cleaning-up-old-'bad'-data
>>
>> On Tuesday, May 7, 2024 at 9:19:04 AM UTC-7 Kevin Crivelli wrote:
>>
>>> or perhaps there is a way to rebuild the raintotals fields from the 
>>> current rainrate data
>>>
>>> On Tuesday, May 7, 2024 at 12:17:20 PM UTC-4 Kevin Crivelli wrote:
>>>
 I removed bad rainrate data but it did not effect the raintotals field. 
 I was able to determine the epoch date-time for the bad rainrate data. 
 Having those I was going to delete the rain_total values for those entries 
 but how would I have that then reflect in the following rain_total fields?

 chatgpt gave me this which I feel is a start but I'm not quite there 
 yet. anyone able to help me with this?

 -- Store the rain total of the specific datetime in a variable
 SET @deleted_rain_total = (SELECT rain_total FROM your_table WHERE 
 datetime = specific_datetime);

 -- Delete the rain total at the specific datetime
 DELETE FROM your_table WHERE datetime = specific_datetime;

 -- Decrease the rain totals for the following datetimes
 UPDATE your_table
 SET rain_total = rain_total - @deleted_rain_total
 WHERE datetime > specific_datetime;

 These are the date and times of the entries that need their raintotal 
 nulled and then the proceeding raintotals to reflect the change

 1699559700: 2024-05-10 01:55:00
 169956: 2024-05-10 01:56:40
 1709221800: 2024-05-26 06:50:00
 1709222100: 2024-05-26 06:55:00
 1713436800: 2024-06-16 10:00:00
 1713437100: 2024-06-16 10:05:00
 1713780900: 2024-06-20 03:35:00
 1713781200: 2024-06-20 03:40:00
 1714771200: 2024-06-25 18:40:00
 1714771500: 2024-06-25 18:45:00
 1699559400: 2024-05-10 01:50:00
 1699560300: 2024-05-10 01:51:40
 1709221500: 2024-05-26 06:45:00
 1713437400: 2024-06-16 10:10:00
 1713781500: 2024-06-20 03:05:00
 1714771800: 2024-06-25 18:10:00

 -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/b687da34-99af-42a8-a84b-490f6c902d91n%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/e79ab8f1-1051-45ca-abfb-3b626cb924f6n%40googlegroups.com.

Re: [weewx-user] Re: removed bad rainrate data but this did not reflect in totals

['michael.k...@gmx.at' via weewx-user]

rainRate is a calculated value: 
https://weewx.com/docs/5.0/reference/weewx-options/stdwxcalculate/
You may want to delete rainRate values from your database and recalculate 
them: 
https://weewx.com/docs/5.0/utilities/weectl-database/#calculate-missing-derived-variables

Kevin Crivelli schrieb am Dienstag, 14. Mai 2024 um 14:48:16 UTC+2:

> I did everything here. It is how I was able to remove the bad rainrate 
> data. The problem now is that while the bad rainrate data is gone, the 
> resulting rain total data is not. I need to get the rain totals to reflect 
> the rainrate data now. The totals are still considering the bad rainrate 
> data that has been removed. 
>
> On Tue, May 7, 2024, 2:22 PM vince  wrote:
>
>> You might want to consult the wiki.  That's why hundreds of hours have 
>> been spent creating it.
>>
>> https://github.com/weewx/weewx/wiki/Cleaning-up-old-'bad'-data
>>
>> On Tuesday, May 7, 2024 at 9:19:04 AM UTC-7 Kevin Crivelli wrote:
>>
>>> or perhaps there is a way to rebuild the raintotals fields from the 
>>> current rainrate data
>>>
>>> On Tuesday, May 7, 2024 at 12:17:20 PM UTC-4 Kevin Crivelli wrote:
>>>
 I removed bad rainrate data but it did not effect the raintotals field. 
 I was able to determine the epoch date-time for the bad rainrate data. 
 Having those I was going to delete the rain_total values for those entries 
 but how would I have that then reflect in the following rain_total fields?

 chatgpt gave me this which I feel is a start but I'm not quite there 
 yet. anyone able to help me with this?

 -- Store the rain total of the specific datetime in a variable
 SET @deleted_rain_total = (SELECT rain_total FROM your_table WHERE 
 datetime = specific_datetime);

 -- Delete the rain total at the specific datetime
 DELETE FROM your_table WHERE datetime = specific_datetime;

 -- Decrease the rain totals for the following datetimes
 UPDATE your_table
 SET rain_total = rain_total - @deleted_rain_total
 WHERE datetime > specific_datetime;

 These are the date and times of the entries that need their raintotal 
 nulled and then the proceeding raintotals to reflect the change

 1699559700: 2024-05-10 01:55:00
 169956: 2024-05-10 01:56:40
 1709221800: 2024-05-26 06:50:00
 1709222100: 2024-05-26 06:55:00
 1713436800: 2024-06-16 10:00:00
 1713437100: 2024-06-16 10:05:00
 1713780900: 2024-06-20 03:35:00
 1713781200: 2024-06-20 03:40:00
 1714771200: 2024-06-25 18:40:00
 1714771500: 2024-06-25 18:45:00
 1699559400: 2024-05-10 01:50:00
 1699560300: 2024-05-10 01:51:40
 1709221500: 2024-05-26 06:45:00
 1713437400: 2024-06-16 10:10:00
 1713781500: 2024-06-20 03:05:00
 1714771800: 2024-06-25 18:10:00

 -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/b687da34-99af-42a8-a84b-490f6c902d91n%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/4b040622-dec3-4496-9d5e-0f688f9441ccn%40googlegroups.com.

Re: [weewx-user] Your hardware experience (for running WeeWX, the service)

['michael.k...@gmx.at' via weewx-user]

I've just bought myself 
this: https://www.zotac.com/product/mini_pcs/zbox-ci337-nano-barebone and a 
data center SSD. Ask me in a year, or two :)
 

michael.k...@gmx.at schrieb am Samstag, 24. Februar 2024 um 08:20:17 UTC+1:

> Interesting insights. I've always been using the official power supplies 
> and SD-Cards and flash drives from major brands. And they always got me 
> brand new cards, as the were under warranty. Also, we have super stable 
> power supply here. Often years without power surge, the last black some 
> years ago, and this only locally. Despite that, my devices are connected to 
> a UPS since a while, and I had still issues.
>
> Tom Keffer schrieb am Samstag, 24. Februar 2024 um 00:25:43 UTC+1:
>
>> I'm with Vince. I believe the micro-SD cards are perfectly reliable. As 
>> an experiment I've been running WeeWX on an RPi B+ with an SD card for over 
>> 9 years. The key is a reliable power supply connected to a UPS. Webpage: 
>> https://www.threefools.org/weewx/status/index.html
>>
>> I'm getting tired of waiting for it to break --- it's taking up too much 
>> space on my desk. If it doesn't break soon, I'll probably end the 
>> experiment.
>>
>> On Fri, Feb 23, 2024 at 11:41 AM Gábor Szabados  
>> wrote:
>>
>>> Shamefully, running a bit old version of WeeWX, from 2019, on a 
>>> Raspberry Pi Zero W, which has Raspbian and mainly default settings WeeWX. 
>>> The same SD card since. The Pi operates in an interceptor way, it creates a 
>>> hotspot for the weather station which sends all information to WU, WeeWX 
>>> with Interceptor intercepts it, meanwhile the Pi connects to the local 
>>> network by Wifi as well. A bit over complicated, but it was before the 
>>> FineOffset clones were offering a custom URL option in their firmware.
>>>
>>> It was a minimum budget project, still runs without any issues. (Knock 
>>> on wood.)
>>>
>>> Graham Knights a következőt írta (2024. február 23., péntek, 19:43:49 
>>> UTC+1):
>>>
 I've been running weewx on a RPi 3B+ for just over 5 years, but after a 
 couple of other pi's died for various reasons (SD card being one of them), 
 I've moved it to a debian install on a VM in a Windows 10 Pro machine 
 (runs 
 my automation server).  Hardware is a Lenovo ThinkCentre M700 Tiny which I 
 find perfect for running a couple of small linux VM's on it.  Low power, 
 tiny, quiet, and versatile, and Lenovo hardware has been good to me over 
 the years. Machines are cheap to find on ebay/amazon, probably less than a 
 new Pi by the time you add all the parts.

 On Friday, February 23, 2024 at 9:46:42 AM UTC-8 vince wrote:

> If I was starting clean 'today', I would probably just throw $125 at 
> it and get one of those little beelink boxes amazon sells and toss linux 
> on 
> it.
>
> But to answer - currently on a 4GB pi4 to sd card for 2+ years with no 
> issues.
>
> Stability issues on a pi are almost always bad power supply these 
> days.  I've never had a micro-sd fail on a pi3, 3+, 4, or pi5.  Never.   
> I 
> did burn a 'lot' of big sd cards on the old modelB over the years but 
> again 
> that was related to either (a) cheapo cards or (b) cheapo power adaptors 
> not on surge suppressors.  My one remaining modelB is still happily 
> shooting my timelapse snaps for over a decade now.
>
> I do make one change to the pi setups to protect the sd card.  I mount 
> some filesystems as tmpfs so the sd can't be hammered by log writes by 
> appending this to /etc/stab
>
> # put logs and tmp dirs in ramdisk too ---
> tmpfs   /tmptmpfs   
> defaults,nosuid,mode=0755,nodev,noatime   0   0
> tmpfs   /var/logtmpfs   
> defaults,nosuid,mode=0755,nodev,noatime   0   0
> tmpfs   /var/tmptmpfs   
> defaults,nosuid,mode=0755,nodev,noatime   0   0
> #-
>
> Yes - if I reboot I lose the system logs.  But I basically never 
> reboot.
>
> I might add that I do install rsyslog and the matching logrotate.d and 
> rsyslog.d files from util/ to my v5 setup, so weewx logs to under 
> /var/log/weewx in that tmpfs partition, so I just run debug=1 here 
> because 
> it's not going to touch the actual sd card.  Super stable.
>
> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/86c8becf-edfb-4264-b93f-2626ed9adfacn%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 

Re: [weewx-user] Re: Vantage Vue: how to override humidity sensor values

['michael.k...@gmx.at' via weewx-user]

Ahh.. and I forgot: the BME280 is not suitable, take a look in the 
datasheet, it is not designed for use in condensing environments, and it 
really sucks in such conditions. Go for a Sensirion SHTxx.

michael.k...@gmx.at schrieb am Mittwoch, 8. Mai 2024 um 18:47:36 UTC+2:

> This might work in StdCalibrate/Corrections (not tested):
>
> outHumidity = extraHumid1 if extraHumid1 is not None and 'outHumidity' not 
> in locals() else None
>
> michael.k...@gmx.at schrieb am Mittwoch, 8. Mai 2024 um 18:38:58 UTC+2:
>
>> You can map the value to extrahumid1 and use this (hacky) extension:
>>
>> https://github.com/mKainzbauer/weewx_extensions/blob/master/usePreferred.py
>>
>> and put this in your weewx.conf:
>>
>> [UsePreferred]
>> outHumidity = extraHumid1
>>
>> Tom Keffer schrieb am Mittwoch, 8. Mai 2024 um 16:07:09 UTC+2:
>>
>>> On Wed, May 8, 2024 at 1:28 AM Lieven Hollevoet  
>>> wrote:
>>>

 I did find back this thread: 
 https://www.mail-archive.com/weewx...@googlegroups.com/msg47494.html 
  
 where I extracted the following correction formula:

 outHumidity = extraHumid1 if 'extraHumid1' in locals() else None

>>>
>>> Of course! Totally forgot about that solution!
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/37353893-193f-4c41-8e8d-ad09525a21d7n%40googlegroups.com.

Re: [weewx-user] Re: Vantage Vue: how to override humidity sensor values

['michael.k...@gmx.at' via weewx-user]

This might work in StdCalibrate/Corrections (not tested):

outHumidity = extraHumid1 if extraHumid1 is not None and 'outHumidity' not 
in locals() else None

michael.k...@gmx.at schrieb am Mittwoch, 8. Mai 2024 um 18:38:58 UTC+2:

> You can map the value to extrahumid1 and use this (hacky) extension:
> https://github.com/mKainzbauer/weewx_extensions/blob/master/usePreferred.py
>
> and put this in your weewx.conf:
>
> [UsePreferred]
> outHumidity = extraHumid1
>
> Tom Keffer schrieb am Mittwoch, 8. Mai 2024 um 16:07:09 UTC+2:
>
>> On Wed, May 8, 2024 at 1:28 AM Lieven Hollevoet  
>> wrote:
>>
>>>
>>> I did find back this thread: 
>>> https://www.mail-archive.com/weewx...@googlegroups.com/msg47494.html 
>>>  
>>> where I extracted the following correction formula:
>>>
>>> outHumidity = extraHumid1 if 'extraHumid1' in locals() else None
>>>
>>
>> Of course! Totally forgot about that solution!
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c851daf6-beb2-4136-8f6e-7edc659eb19fn%40googlegroups.com.

Re: [weewx-user] Re: Vantage Vue: how to override humidity sensor values

['michael.k...@gmx.at' via weewx-user]

You can map the value to extrahumid1 and use this (hacky) extension:
https://github.com/mKainzbauer/weewx_extensions/blob/master/usePreferred.py

and put this in your weewx.conf:

[UsePreferred]
outHumidity = extraHumid1

Tom Keffer schrieb am Mittwoch, 8. Mai 2024 um 16:07:09 UTC+2:

> On Wed, May 8, 2024 at 1:28 AM Lieven Hollevoet  
> wrote:
>
>>
>> I did find back this thread: 
>> https://www.mail-archive.com/weewx...@googlegroups.com/msg47494.html 
>>  
>> where I extracted the following correction formula:
>>
>> outHumidity = extraHumid1 if 'extraHumid1' in locals() else None
>>
>
> Of course! Totally forgot about that solution!
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/41861271-5c36-4f35-9fd7-02e4110ce012n%40googlegroups.com.

[weewx-user] Re: formatting MQTT message sensor lenght

['michael.k...@gmx.at' via weewx-user]

What's the problem with the number of digits? Are they displayed correctly 
in HA? Or is there a problem for HA dealing with that number of digits 
generally?

miso k schrieb am Mittwoch, 24. April 2024 um 22:15:18 UTC+2:

> Hello Weather observers,
>
> since long time my weewx server is running - and  updated to latest 5.0.2 
> version.
>
> I want to export MQTT messages to Home Assistant, but the numbers are too 
> long.
> How can I make them shorter?
> Example:
> outHumidity = 91.0
> inHumidity = 56.0
> outTemp_C = 3.776
> inTemp_C = 22.89
> windSpeed_kph = 9.0123264
> windGust_kph = 9.3341952
>
>
> I have tried to format it through format = %.1f , but it does not seems to 
> work
>
> My MQTT Configuration:
>
> [[MQTT]]
> server_url = mqtt://xxx:xxx@localhost:1883/
> topic = weather
> unit_system = METRIC
> binding = archive, loop
> aggregation = individual
> log_success = False
> log_failure = True
> [[[inputs]]]
> outTemp
> name = inside_temperature  # use a label other than outTemp
> format = %.1f  # two decimal places of 
> precision
> unit = degree_F# convert outTemp to F, others 
> in C
> inTemp
> unit = degree_C # use F instead of C
> format = %.1f   # use two decimal places 
> of precision
> name = inside_temperature   # use label other than 
> inTemp
> windSpeed
> units = meter_per_second# use knots instead of 
> meter_per_second
> format = %.1f   # use two decimal places 
> of precision
> name = wind_speed   # use label other than 
> inTemp
>
> Thank you!
> Michal
>

-- 
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/e4147bcb-4f9e-4ef8-8ead-15494835c3ecn%40googlegroups.com.

Re: [weewx-user] Generate temp gauge image

['michael.k...@gmx.at' via weewx-user]

Hi awe, the image you have pasted above is rendered in the browser by the 
Bootstrap skin, using apache eCharts. Home of the skin: 
https://github.com/brewster76/fuzzy-archer
The skin does not provide image generation for gauges and live charts in a 
way, that a static image is produced. The static image you linked above is 
produced in a completeley different way by weewx in the backend.
As far as I know, the eCharts library provides this, but the skin doesn't 
provide this functionality and it will not provide it in the future. The 
reason is that the gauges are only rendered in the browser, but not in the 
weewx backend.

You still can use the JSON 
data https://hpi3.hemmestad.com/weewx/Bootstrap/weewxData.json and use 
apache eCharts in "the other html page" to render whatever gauges and 
charts you want. But this is something I wouldn't call "an easy way".

Jimi Lawson schrieb am Donnerstag, 11. April 2024 um 22:13:32 UTC+2:

> I have the Steel Series gauges on my website if you want to see how they 
> look https://jlawson.co.uk/index.php/weather 
> Jimi
>
> On Thursday 11 April 2024 at 20:58:45 UTC+1 p q wrote:
>
>> https://github.com/gjr80/weewx-steelseries
>>
>> On Thu, Apr 11, 2024 at 10:34 AM awe  wrote:
>>
>>> Hello 
>>> Does anybody know an easy way to make WeeWX generate a gauge image (that 
>>> updates every X minute) of current temperature and wind that can be used in 
>>> another .html page? 
>>> Like this?
>>> [image: Capture.JPG]
>>> For the trends I see that WeeWX generate images like this: 
>>> https://hpi3.hemmestad.com/weewx/Bootstrap/daytemp-Bootstrap.png 
>>> But I cannot seem to get any gauges generated.. 
>>> Live data not required... 
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/3e8892b0-663d-4736-93ea-0a66c8097ab3n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>> Peter Quinn
>> (415)794-2264 <(415)%20794-2264>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/05424c33-ae6f-46ff-b7b8-8147bd958333n%40googlegroups.com.

[weewx-user] Re: obligatory eclipse thread

['michael.k...@gmx.at' via weewx-user]

I've seen a total eclipse on Aug 11, 1999.
My backyard was literally almost on the center line of the path of 
totality. Unforgettable!

vince schrieb am Montag, 8. April 2024 um 00:54:10 UTC+2:

> Having seen the 2017 total eclipse after a 4-hour drive south to below 
> Portland OR, I highly recommend finding a way to see this one if you have 
> the opportunity.  It is truly an amazing amazing experience you will 
> absolutely never forget.  The diamond ring is sooo incredible.   
> Temperatures dropped 20F at totality and everything turned the strangest 
> colors as totality approached.  Beyond cool.
>
> Lets see your solar sensor graphs too 
>

-- 
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/5d38aaae-4e90-4b8a-b6d7-278b700d1818n%40googlegroups.com.

[weewx-user] Re: Failed new install

['michael.k...@gmx.at' via weewx-user]

Just guessing by the error message:

weectl.py: error: unrecognized arguments: feet,foot

https://weewx.com/docs/5.0/reference/skin-options/units/?h=singular#groups
Note that the measurement unit is always specified in the singular. That 
is, specify degree_C or foot, not degrees_C or feet.



Ron Walker schrieb am Mittwoch, 20. März 2024 um 19:24:41 UTC+1:

> I have been through the forum looking for this issue , but have not seen 
> this issue addressed.
>
> I;m trying to install weewx 5.02 on a fresh install of Debian Buster on a 
> Raspberry Pi 3.  When I attempt to install weewx, I get the following:
>
> ron@WeatherPi5:~ $ wget -qO - https://weewx.com/apt/weewx-python3.list | 
> sudo tee /etc/apt/sources.list.d/weewx.list
> deb [arch=all] http://weewx.com/apt/python3 buster main
> ron@WeatherPi5:~ $ sudo apt update
> Hit:1 http://raspbian.raspberrypi.org/raspbian bullseye InRelease
> Get:2 http://weewx.com/apt/python3 buster InRelease [4,252 B] 
>  
> Hit:3 http://archive.raspberrypi.org/debian bullseye InRelease   
>   
> Get:4 http://weewx.com/apt/python3 buster/main all Packages [4,988 B]
> Fetched 9,240 B in 2s (5,992 B/s)  
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> All packages are up to date.
> ron@WeatherPi5:~ $ sudo apt install weewx
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> The following package was automatically installed and is no longer 
> required:
>   libfuse2
> Use 'sudo apt autoremove' to remove it.
> The following additional packages will be installed:
>   python3-cheetah python3-configobj python3-ephem python3-usb
> Suggested packages:
>   python-cheetah-doc python3-markdown python3-memcache python-configobj-doc
>   sqlite ftp httpd
> The following NEW packages will be installed:
>   python3-cheetah python3-configobj python3-ephem python3-usb weewx
> 0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
> Need to get 2,370 kB of archives.
> After this operation, 9,616 kB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Get:2 http://weewx.com/apt/python3 buster/main all weewx all 5.0.2-1 
> [1,556 kB]
> Get:1 http://mirror.us.leaseweb.net/raspbian/raspbian bullseye/main armhf 
> python3-configobj all 5.0.6-4 [35.8 kB]
> Get:3 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf 
> python3-cheetah armhf 3.2.6-1+b1 [142 kB]
> Get:4 http://mirror.us.leaseweb.net/raspbian/raspbian bullseye/main armhf 
> python3-usb all 1.0.2-2 [38.9 kB]
> Get:5 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf 
> python3-ephem armhf 3.7.7.1-1+b1 [596 kB]
> Fetched 2,370 kB in 2s (1,376 kB/s)
> Preconfiguring packages ...
> Selecting previously unselected package python3-configobj.
> (Reading database ... 173112 files and directories currently installed.)
> Preparing to unpack .../python3-configobj_5.0.6-4_all.deb ...
> Unpacking python3-configobj (5.0.6-4) ...
> Selecting previously unselected package python3-cheetah.
> Preparing to unpack .../python3-cheetah_3.2.6-1+b1_armhf.deb ...
> Unpacking python3-cheetah (3.2.6-1+b1) ...
> Selecting previously unselected package python3-usb.
> Preparing to unpack .../python3-usb_1.0.2-2_all.deb ...
> Unpacking python3-usb (1.0.2-2) ...
> Selecting previously unselected package python3-ephem.
> Preparing to unpack .../python3-ephem_3.7.7.1-1+b1_armhf.deb ...
> Unpacking python3-ephem (3.7.7.1-1+b1) ...
> Selecting previously unselected package weewx.
> Preparing to unpack .../archives/weewx_5.0.2-1_all.deb ...
> Unpacking weewx (5.0.2-1) ...
> Setting up python3-usb (1.0.2-2) ...
> Setting up python3-ephem (3.7.7.1-1+b1) ...
> Setting up python3-cheetah (3.2.6-1+b1) ...
> Setting up python3-configobj (5.0.6-4) ...
> Setting up weewx (5.0.2-1) ...
> Using weewx:weewx as user:group
> Creating /etc/default/weewx
> usage: weectl.py -v|--version
>weectl.py -h|--help
>weectl.py database --help
>weectl.py debug --help
>weectl.py device --help
>weectl.py extension --help
>weectl.py import --help
>weectl.py report --help
>weectl.py station --help
> weectl.py: error: unrecognized arguments: feet,foot
> dpkg: error processing package weewx (--configure):
>  installed weewx package post-installation script subprocess returned 
> error exit
>  status 2
> Processing triggers for man-db (2.9.4-2) ...
> Errors were encountered while processing:
>  weewx
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>  
> The result is that I cannot uninstall nor can I install weewx.  Any help 
> would be appreciated.  If this issue has been addressed, please point me to 
> it!  Thanks!
>

-- 
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+unsu

Re: [weewx-user] Re: Problem during fixing of potential corrupt database

['michael.k...@gmx.at' via weewx-user]

How many obvious bad timestamp values do you have? If there are only few, 
remove the lines from the database and see if you get along with it.

Michael Waldor schrieb am Mittwoch, 20. März 2024 um 14:13:54 UTC+1:

> Yes, I do have backups. But which one to use? I do not know WHEN the 
> potential error might have occured. I even don't know IF there is an error. 
> As I wrote, weewxd can happily append data.
>
> I "only" encounter problems when I try to manually run sqlite3 commands. 
> And those indicate that the error might have been introduced in 2018 just 
> after 2months of runtime. If that's true I might safely start a fresh DB:-(
>
> Tom Keffer schrieb am Mittwoch, 20. März 2024 um 14:04:37 UTC+1:
>
>> If you say the problem is in the database and the database cannot be 
>> recovered, I'm not sure there is anything we can offer. What are you 
>> looking for from the group?
>>
>> Hopefully you have a backup database.
>>
>> On Wed, Mar 20, 2024 at 5:55 AM 'Michael Waldor' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> weewx itself works without problems - it can add new entries into 
>>> weewx.sdb, and it'S running  right now.
>>>
>>> But when trying to manually tweak weewx.sdb using sqlite3 commands, 
>>> sqlite3 complains. Using .recover seems to make it worse - its sql output 
>>> contains some completely broken lines with datetime being 7 or 74 or 
>>> unprintable bnary data. Clearly weewxd rejects to use that "recovered" 
>>> weewx.sdb.
>>>
>>> Currently I try to follow 
>>> https://groups.google.com/g/weewx-user/c/PJuWj35o8TM
>>> Luckily the transformation process should run for ~30min (data is stored 
>>> on a SSD).
>>>
>>> But howto identify the location of a broken weewx.sdb? E.g. if I try to 
>>> run the sqlite3 command
>>> select date(datetime, 'unixepoch', 'localtime') from archive;
>>> It outputs data till 2018-03-31. And then there is an sqlite3 error 
>>> message. Only the date conversion seems to fail. If I stay with integer 
>>> datetime all data seems to be accessible.
>>>
>>> Tom Keffer schrieb am Mittwoch, 20. März 2024 um 13:28:57 UTC+1:
>>>
 This could be anything. We will need to see more of the log to tell. 
 For example, you could be asking for a date one month after January 30.

 Set debug=1, restart weewxd, post the log from startup through the 
 error.

 On Wed, Mar 20, 2024 at 3:57 AM 'Michael Waldor' via weewx-user <
 weewx...@googlegroups.com> wrote:

> Sadly those mysterious rows only appear AFTER .recover,  they appear 
> within weewx.sql.
> The failing command is
>
> SELECT count(*)
> FROM archive
> WHERE
>   date(datetime, 'unixepoch', 'localtime')
>   between '2024-03-15' and '2024-03-15';
>
> But that command works fine AFTER .recover.
>
> The error message from weewxd clearly indicates wrong datetime:
>
> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
>  last_d = datetime.date.fromtimestamp(weeutil.weeutil.startOfArchiveDay(
> Mär 20 11:34:37 imurr9 weewxd[15172]: time_dt = 
> datetime.datetime.fromtimestamp(time_ts)
> Mär 20 11:34:37 imurr9 weewxd[15172]: OverflowError: timestamp out of 
> range for platform time_t
> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:    
>  File "/usr/share/weewx/weeutil/weeutil.py", line 1196, in 
> startOfArchiveDay
> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
>  time_dt = datetime.datetime.fromtimestamp(time_ts)
> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
>  OverflowError: timestamp out of range for platform time_t
> Mär 20 11:34:37 imurr9 weewxd[15172]: CRITICAL __main__:  
>  Exiting
> Michael Waldor schrieb am Mittwoch, 20. März 2024 um 10:43:13 UTC+1:
>
>> I do have a first idea: There are entries within weewx.sdb where 
>> datetime is 0 or 7. Those values clearly are no valid timestamps.
>> I'll proceed in that direction ...
>>
>> Michael Waldor schrieb am Mittwoch, 20. März 2024 um 10:04:57 UTC+1:
>>
>>> Some days ago I've stopped weewx for roughly one day (I did change 
>>> the GPIO connections of my raspberry pi4). Now I wanted to insert some 
>>> data 
>>> into my weewx.sdb from that timespan.
>>>
>>> When trying some sqlite3 commands (on a local copy of weewx.sdb - as 
>>> an exercise a simple count) sqlite3 failed with corrupt database. OK, 
>>> can 
>>> imagine that that might have happened sometimes during the last 5 
>>> years. 
>>> Thus I tried to rebuild my database by
>>>
>>> mv weewx.sdb weewx_corrupt.sdb
>>> sqlite3 weewx_corrupt.sdb .recover > weewx.sql
>>> sqlite3 weewx.sdb < weewx.sql
>>>
>>> Now my sqlite3 commands worked as expected, i.e. the newly created 
>>> weewx.sdb seemed to be fixed. Keep in mind that I did not modify 
>>> wee

[weewx-user] Re: After new installation problems with season skin / no site

['michael.k...@gmx.at' via weewx-user]

He maybe never installed the Bootstrap skin, there are a couple of skins 
around that took the historygenerator from the skin, often many years ago, 
so usually, these are very outdated. Either try to get the 
historygenerator.py from the old installation, or from some outdated 
version of the Bootstrap skin, I doubt (but you can give it a try) that a 
recent version will work without updating the config, there were 
significant changes.

gjr80 schrieb am Sonntag, 17. März 2024 um 21:43:34 UTC+1:

> Yes, that will be fine. [[Bootstrap]] is only created when you install the 
> bootstrap skin.
>
> Gary
>
> On Monday 18 March 2024 at 06:37:52 UTC+10 Thomas Hackler wrote:
>
>> I have a copy of my old /etc/weewx/bin/user. there is a 
>> historygenerator.py file
>> but there is no [[Bootstrap]] in my new or in my old weewx.conf file
>>
>> so maybe it is enough to copy the file historygenerator.py from my old 
>> system to /etc/weewx/bin/user or should I install the bootstrap skin?
>>
>> So I guess I should install the neowx skin again too ?
>>
>> gjr80 schrieb am Sonntag, 17. März 2024 um 21:26:05 UTC+1:
>>
>>> Agree the problem is a missing user.historygenerator search list 
>>> extension which (from memory) is provided by the bootstrap skin, but 
>>> user.historygenerator is being called by the Seasons skin. So I suspect 
>>> you have modified your Season skin in the past and added 
>>> user.historygenerator to the Seasons skin config file, 
>>> skins/Seasons/skin.conf. This would explain why you missed it when 
>>> checking your backup weewx.conf.
>>>
>>> The solution is to obtain the historygenerator.py from the bootstrap 
>>> skin and add it to your system. You could simply extract this file from the 
>>> bootstrap skin and save it to you system, but the easiest way will be as 
>>> Vince said - just install the bootstrap skin. I would go one step further 
>>> and disable the bootstrap skin (set enable = False  under [StdReport] 
>>> [[Bootstrap]] in weewx.conf). This will have no impact on the 
>>> availability of user.historygenerator, but will prevent the Bootstrap 
>>> skin from generating its content/output.
>>>
>>> Gary
>>> On Monday 18 March 2024 at 05:43:50 UTC+10 vince wrote:
>>>
 Not quite.

 You need to install all added user extensions and skins. In your case 
 it looks like you had the bootstrap skin on your old system which has a 
 file bin/user/historygenerator.py that you are missing on the new system. 
 Either remove the reference to historygenerator in your weewx.conf or 
 install the bootstrap skin to add the missing file.


 On Sunday, March 17, 2024 at 12:23:43 PM UTC-7 Thomas Hackler wrote:

> sorry I don't understand, I followed this guide
>
> https://weewx.com/docs/5.0/usersguide/backup/
>
> I compared the weewx.conf file from the fresh installation with my old 
> one and added all the missing things
> so I guess everything should work after that? 
> The neowx skin works normal at the moment, so I will check the 
> warnings later
>
>
> vince schrieb am Sonntag, 17. März 2024 um 18:33:09 UTC+1:
>
>> ModuleNotFoundError: No module named 'user.historygenerator'
>> You need to install all skins and extensions referenced in your .conf 
>> files
>>
>> You also have a variety of warnings from neowx:
>> _etc_weewx_skins_neowx_material_month__Y__m_html_tmpl.py:406: 
>> SyntaxWarning: "is not" with a literal. Did you mean "!="?
>>
>> I 'think' this is related to newer versions of python being more 
>> strict.  I recall trying neowx once and simply editing all the places 
>> that 
>> weewx logged those warnings and they went away.
>>
>> On Sunday, March 17, 2024 at 8:12:09 AM UTC-7 Thomas Hackler wrote:
>>
>>> Hello,
>>> my raspberry pi crashed and I started with a new system. Fortunately 
>>> I have copies from my database and the skins.
>>> I started installing weewx and the gw1000 driver, then I copied the 
>>> skin folder and the database.
>>> I had some issues with permissions with the database but this works 
>>> now. 
>>> I use two skins. The neowx skin works fine but I get errors for the 
>>> season skin and no site is made and I don't understand why.
>>>
>>> Mar 17 15:45:28 raspberrypi weewxd[114945]: ERROR 
>>> weewx.reportengine: Caught unrecoverable exception in generator 
>>> 'weewx.cheetahgenerator.CheetahGenerator'
>>>
>>> Full log file attached.
>>> Thank you for helping!
>>> Thomas Hackler
>>>
>>>
>>>

-- 
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/83dfc84e-cf3f-4089-8e8d-8559207305f5

[weewx-user] Re: Daily rain total and daylight saving time error.

['michael.k...@gmx.at' via weewx-user]

Just curious: where are you from that DST changed today?
vince schrieb am Sonntag, 10. März 2024 um 18:10:30 UTC+1:

> I've learned many years ago to just ignore any days when daylight savings 
> changes either way
>
> On Sunday, March 10, 2024 at 10:00:32 AM UTC-7 Russell Swan wrote:
>
>> Hi, daylight saving time happened last night and my rain total 
>> ($day.rain.sum) for the day does not equal that on the Davis Vantage Pro2. 
>> The console reads 0.73" and weewx puts out 0.52". Interestingly, my Steel 
>> Gauges indicate the correct 0.73". I think an hour of rain was dropped. 
>>
>> weewx version 5.02
>>
>

-- 
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/731cebc0-42af-4710-ac45-adff8fb76349n%40googlegroups.com.

Re: [weewx-user] [StdCalibrate][[Corrections]] check if obs_type is present

['michael.k...@gmx.at' via weewx-user]

And honestly: I'm really glad you consider the expressions complicated. For 
me, they were. I needed to write a test to figure them out :D
Tom Keffer schrieb am Sonntag, 10. März 2024 um 16:24:35 UTC+1:

> Honestly, with an expression that complicated, I would write a simple 
> WeeWX service.
>
> On Sun, Mar 10, 2024 at 3:51 AM 'michael.k...@gmx.at' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> This one seems way better:
>> [StdCalibrate]
>> 
>> [[Corrections]]
>> windSpeed = ws90_windSpeed if 'windSpeed' not in locals() else 
>> windSpeed if 'ws90_windSpeed' not in locals() else ws90_windSpeed if 
>> ws90_windSpeed > windSpeed else windSpeed
>> windGust = ws90_windGust if 'windGust' not in locals() else 
>> windGust if 'ws90_windGust' not in locals() else ws90_windGust if 
>> ws90_windGust > windGust else windGust
>> windDir = ws90_windDir if 'ws90_windDir' in locals() and 
>> ws90_windDir is not None else windDir
>> michael.k...@gmx.at schrieb am Samstag, 9. März 2024 um 08:37:01 UTC+1:
>>
>>> Anyway, thank you for helping me with this one!
>>>
>>> For the record:
>>>
>>> I have two pieces of hardware, one is using a classic anemometer with 
>>> cups, the other one is an ultrasonic device. With very low wind speeds, the 
>>> classic one shows zero wind, while the ultrasonic one shows low, but very 
>>> plausible values. The ultrasonic one also doesn't freeze or gets blocked by 
>>> snow, because is has a heating. On the other hand, the ultrasonic device 
>>> often misses wind gusts and lacks accuracy in wet conditions.
>>> In short, the closes approach to represent reality is: always use the 
>>> values from the sensor, which is showing the higher reading. 
>>> Also, the Wind direction of the ultrasonic device has a better 
>>> resolution and no vane that sometimes doesn't move, even in wind speeds, 
>>> the classic anemometer is rotating.
>>> So the second thing is: always use windDir from the ultrasonic device. 
>>>
>>> Both readings arrive in the same loop packet, their names are 
>>> "windSpeed" and "ws90_windSpeed" (the latter ultrasonic), together with 
>>> their gust speed and direction, except for situations, the sensor's data 
>>> cannot be received by the console. So my first approach
>>>
>>> [StdCalibrate]
>>> [[Corrections]]
>>> windSpeed = ws90_windSpeed if ws90 if ws90_windSpeed > 
>>> windSpeed else windSpeed
>>> windGust = ws90_windGust if ws90_windGust > windGust else 
>>> windGust
>>> windDir = ws90_windDir if ws90_windDir is not None else windDir
>>>
>>> is working, but only in cases, both of the readings are present. 
>>>
>>> Yesterday, windSpeed (from the classic device) was missing, where 
>>> ws90_windSpeed was there. The result was, no windSpeed was recorded as at 
>>> all, due to a python NameError, which was silently ignored. 
>>>
>>> try:
>>> event.record[obs_type] = eval(self.corrections[obs_type], {'math': math
>>> },
>>>   event.record)
>>> except (TypeError, NameError):
>>> pass
>>>
>>> So, if this should work as intended, we need to check if windSpeed is 
>>> there, or not.
>>>
>>> What I want is to 
>>>
>>>- store whatever wind speed/gust is the higher, if both are present
>>>- store whatever wind speed/gust, when only one is present
>>>- store the ultrasonic wind direction if present, or else the other 
>>>one
>>>
>>> For now, I use these expressions, and the loop packets look good, and 
>>> there shouldn't be a need to check for both being present:
>>>
>>> [StdCalibrate]
>>> 
>>> [[Corrections]]
>>> # For each type, an arbitrary calibration expression can be 
>>> given.
>>> # It should be in the units defined in the StdConvert section.
>>> # Example:
>>> #foo = foo + 0.2
>>> windSpeed = ws90_windSpeed if 'windSpeed' not in locals() or 
>>> ws90_windSpeed > windSpeed else windSpeed
>>> windGust = ws90_windGust if 'windGust' not in locals() or 
>>> ws90_windGust > windGust else windGust
>>> windD

Re: [weewx-user] [StdCalibrate][[Corrections]] check if obs_type is present

['michael.k...@gmx.at' via weewx-user]

This one seems way better:
[StdCalibrate]

[[Corrections]]
windSpeed = ws90_windSpeed if 'windSpeed' not in locals() else 
windSpeed if 'ws90_windSpeed' not in locals() else ws90_windSpeed if 
ws90_windSpeed > windSpeed else windSpeed
windGust = ws90_windGust if 'windGust' not in locals() else 
windGust if 'ws90_windGust' not in locals() else ws90_windGust if 
ws90_windGust > windGust else windGust
windDir = ws90_windDir if 'ws90_windDir' in locals() and 
ws90_windDir is not None else windDir
michael.k...@gmx.at schrieb am Samstag, 9. März 2024 um 08:37:01 UTC+1:

> Anyway, thank you for helping me with this one!
>
> For the record:
>
> I have two pieces of hardware, one is using a classic anemometer with 
> cups, the other one is an ultrasonic device. With very low wind speeds, the 
> classic one shows zero wind, while the ultrasonic one shows low, but very 
> plausible values. The ultrasonic one also doesn't freeze or gets blocked by 
> snow, because is has a heating. On the other hand, the ultrasonic device 
> often misses wind gusts and lacks accuracy in wet conditions.
> In short, the closes approach to represent reality is: always use the 
> values from the sensor, which is showing the higher reading. 
> Also, the Wind direction of the ultrasonic device has a better resolution 
> and no vane that sometimes doesn't move, even in wind speeds, the classic 
> anemometer is rotating.
> So the second thing is: always use windDir from the ultrasonic device. 
>
> Both readings arrive in the same loop packet, their names are "windSpeed" 
> and "ws90_windSpeed" (the latter ultrasonic), together with their gust 
> speed and direction, except for situations, the sensor's data cannot be 
> received by the console. So my first approach
>
> [StdCalibrate]
> [[Corrections]]
> windSpeed = ws90_windSpeed if ws90 if ws90_windSpeed > windSpeed 
> else windSpeed
> windGust = ws90_windGust if ws90_windGust > windGust else windGust
> windDir = ws90_windDir if ws90_windDir is not None else windDir
>
> is working, but only in cases, both of the readings are present. 
>
> Yesterday, windSpeed (from the classic device) was missing, where 
> ws90_windSpeed was there. The result was, no windSpeed was recorded as at 
> all, due to a python NameError, which was silently ignored. 
>
> try:
> event.record[obs_type] = eval(self.corrections[obs_type], {'math': math},
>   event.record)
> except (TypeError, NameError):
> pass
>
> So, if this should work as intended, we need to check if windSpeed is 
> there, or not.
>
> What I want is to 
>
>- store whatever wind speed/gust is the higher, if both are present
>- store whatever wind speed/gust, when only one is present
>- store the ultrasonic wind direction if present, or else the other one
>
> For now, I use these expressions, and the loop packets look good, and 
> there shouldn't be a need to check for both being present:
>
> [StdCalibrate]
> 
> [[Corrections]]
> # For each type, an arbitrary calibration expression can be given.
> # It should be in the units defined in the StdConvert section.
> # Example:
> #foo = foo + 0.2
> windSpeed = ws90_windSpeed if 'windSpeed' not in locals() or 
> ws90_windSpeed > windSpeed else windSpeed
> windGust = ws90_windGust if 'windGust' not in locals() or 
> ws90_windGust > windGust else windGust
> windDir = ws90_windDir if 'ws90_windDir' in locals() and 
> ws90_windDir is not None else windDir
>
> I think this way I think I get my desired results, but after a long week 
> my brain is a bit overloaded. So if anybody with cognitive capacities left 
> could check if my expressions really make that much sense: very much 
> appreciated :) 
>
> michael.k...@gmx.at schrieb am Samstag, 9. März 2024 um 08:15:24 UTC+1:
>
>> Actually
>>
>> *outTemp = 44 if outTemp in locals() else None*
>>
>>
>> yields *None* when *outTemp * is there. 
>>
>> Since we are looking for the key '*outTemp' *and not it's value, our 
>> expression needs to be:
>>
>> *outTemp = 44 if 'outTemp' in locals() else None*
>>
>>
>>
>> Tom Keffer schrieb am Samstag, 9. März 2024 um 03:22:24 UTC+1:
>>
>>> The facility uses the Python function eval 
>>> <https://docs.python.org/3/library/functions.html#eval>. A dictionary 
>>> with key 'math' and value the math module is passe

Re: [weewx-user] [StdCalibrate][[Corrections]] check if obs_type is present

['michael.k...@gmx.at' via weewx-user]

Anyway, thank you for helping me with this one!

For the record:

I have two pieces of hardware, one is using a classic anemometer with cups, 
the other one is an ultrasonic device. With very low wind speeds, the 
classic one shows zero wind, while the ultrasonic one shows low, but very 
plausible values. The ultrasonic one also doesn't freeze or gets blocked by 
snow, because is has a heating. On the other hand, the ultrasonic device 
often misses wind gusts and lacks accuracy in wet conditions.
In short, the closes approach to represent reality is: always use the 
values from the sensor, which is showing the higher reading. 
Also, the Wind direction of the ultrasonic device has a better resolution 
and no vane that sometimes doesn't move, even in wind speeds, the classic 
anemometer is rotating.
So the second thing is: always use windDir from the ultrasonic device. 

Both readings arrive in the same loop packet, their names are "windSpeed" 
and "ws90_windSpeed" (the latter ultrasonic), together with their gust 
speed and direction, except for situations, the sensor's data cannot be 
received by the console. So my first approach

[StdCalibrate]
[[Corrections]]
windSpeed = ws90_windSpeed if ws90 if ws90_windSpeed > windSpeed 
else windSpeed
windGust = ws90_windGust if ws90_windGust > windGust else windGust
windDir = ws90_windDir if ws90_windDir is not None else windDir

is working, but only in cases, both of the readings are present. 

Yesterday, windSpeed (from the classic device) was missing, where 
ws90_windSpeed was there. The result was, no windSpeed was recorded as at 
all, due to a python NameError, which was silently ignored. 

try:
event.record[obs_type] = eval(self.corrections[obs_type], {'math': math},
  event.record)
except (TypeError, NameError):
pass

So, if this should work as intended, we need to check if windSpeed is 
there, or not.

What I want is to 

   - store whatever wind speed/gust is the higher, if both are present
   - store whatever wind speed/gust, when only one is present
   - store the ultrasonic wind direction if present, or else the other one

For now, I use these expressions, and the loop packets look good, and there 
shouldn't be a need to check for both being present:

[StdCalibrate]

[[Corrections]]
# For each type, an arbitrary calibration expression can be given.
# It should be in the units defined in the StdConvert section.
# Example:
#foo = foo + 0.2
windSpeed = ws90_windSpeed if 'windSpeed' not in locals() or 
ws90_windSpeed > windSpeed else windSpeed
windGust = ws90_windGust if 'windGust' not in locals() or 
ws90_windGust > windGust else windGust
windDir = ws90_windDir if 'ws90_windDir' in locals() and 
ws90_windDir is not None else windDir

I think this way I think I get my desired results, but after a long week my 
brain is a bit overloaded. So if anybody with cognitive capacities left 
could check if my expressions really make that much sense: very much 
appreciated :) 

michael.k...@gmx.at schrieb am Samstag, 9. März 2024 um 08:15:24 UTC+1:

> Actually
>
> *outTemp = 44 if outTemp in locals() else None*
>
>
> yields *None* when *outTemp * is there. 
>
> Since we are looking for the key '*outTemp' *and not it's value, our 
> expression needs to be:
>
> *outTemp = 44 if 'outTemp' in locals() else None*
>
>
>
> Tom Keffer schrieb am Samstag, 9. März 2024 um 03:22:24 UTC+1:
>
>> The facility uses the Python function eval 
>> <https://docs.python.org/3/library/functions.html#eval>. A dictionary 
>> with key 'math' and value the math module is passed in for *globals*. 
>> The record is passed in for *locals*. So, you could use the expression
>>
>> *outTemp = 44 if outTemp in locals() else None*
>>
>>
>>
>>
>> On Fri, Mar 8, 2024 at 3:33 PM Graham Eddy  wrote:
>>
>>> oops, python syntax would be: expr if ops_tye in globals() else None
>>> *⊣GE⊢*
>>>
>>> On 9 Mar 2024, at 10:31 am, Graham Eddy  wrote:
>>>
>>> i think ' if obs_type in globals() then expr else None ' would work
>>> *⊣GE⊢*
>>>
>>> On 9 Mar 2024, at 9:13 am, 'michael.k...@gmx.at' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
>>> I think I remember that this has been asked before, how to check with an 
>>> expression in Corrections, if an obs_type is present? 
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this g

Re: [weewx-user] [StdCalibrate][[Corrections]] check if obs_type is present

['michael.k...@gmx.at' via weewx-user]

Actually

*outTemp = 44 if outTemp in locals() else None*


yields *None* when *outTemp * is there. 

Since we are looking for the key '*outTemp' *and not it's value, our 
expression needs to be:

*outTemp = 44 if 'outTemp' in locals() else None*



Tom Keffer schrieb am Samstag, 9. März 2024 um 03:22:24 UTC+1:

> The facility uses the Python function eval 
> <https://docs.python.org/3/library/functions.html#eval>. A dictionary 
> with key 'math' and value the math module is passed in for *globals*. The 
> record is passed in for *locals*. So, you could use the expression
>
> *outTemp = 44 if outTemp in locals() else None*
>
>
>
>
> On Fri, Mar 8, 2024 at 3:33 PM Graham Eddy  wrote:
>
>> oops, python syntax would be: expr if ops_tye in globals() else None
>> *⊣GE⊢*
>>
>> On 9 Mar 2024, at 10:31 am, Graham Eddy  wrote:
>>
>> i think ' if obs_type in globals() then expr else None ' would work
>> *⊣GE⊢*
>>
>> On 9 Mar 2024, at 9:13 am, 'michael.k...@gmx.at' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>> I think I remember that this has been asked before, how to check with an 
>> expression in Corrections, if an obs_type is present? 
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/ae1bbcf8-23b1-475e-8749-62286df24fb0n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/ae1bbcf8-23b1-475e-8749-62286df24fb0n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/0507D046-7EED-4A96-8F28-038B70BECEC7%40geddy.au
>>  
>> <https://groups.google.com/d/msgid/weewx-user/0507D046-7EED-4A96-8F28-038B70BECEC7%40geddy.au?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/5c1198a9-1540-4630-969a-4d998ec91eebn%40googlegroups.com.

[weewx-user] [StdCalibrate][[Corrections]] check if obs_type is present

['michael.k...@gmx.at' via weewx-user]

I think I remember that this has been asked before, how to check with an 
expression in Corrections, if an obs_type is present?

-- 
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/ae1bbcf8-23b1-475e-8749-62286df24fb0n%40googlegroups.com.

[weewx-user] Re: Raddy L7 Weather Station: XML of Current Conditions-How to Feed WeeWx?

['michael.k...@gmx.at' via weewx-user]

Fwiw, it is JSON, not XML. If you can get your device to emit these values 
as MQTT messages, you probably can get along 
with https://github.com/bellrichm/WeeWX-MQTTSubscribe and some configs.
Michael schrieb am Mittwoch, 6. März 2024 um 18:02:47 UTC+1:

> Hello,
>
> First I am not a developer, so pardon my ignorance. 
>
> I have a Raddy L7 LoRa WX station.  I found that on the local 
> configuration screen of the device, you can enter /client?command=record 
> and get an XML output of current conditions.  Just wondering what getting 
> this data to feed into WeeWx would entail?  
>
> {"sensor":[ 
> {"title":"Indoor","list":[["Temperature","68.9","°F"],["Humidity","38","%"]]},{"title":"Outdoor","list":[["Temperature","61.7","°F"],["Humidity","29","%"]]},{"title":"Pressure","list":[["Absolute","26.76","inhg"],["Relative","29.84","inhg"]]},{"title":"Wind
>  
> Speed","list":[["Max Daily 
> Gust","5.1","mph"],["Wind","1.1","mph"],["Gust","1.6","mph"],["Direction","123","°"],["Wind
>  
> Average 2 Minute","0.4","mph"],["Direction Average 2 
> Minute","111","°"],["Wind Average 10 Minute","1.3","mph"],["Direction 
> Average 10 
> Minute","134","°"]]},{"title":"Rainfall","list":[["Rate","0.0","inch/hr"],["Hour","0.0","inch","43"],["Day","0.0","inch","44"],["Week","0.0","inch","45"],["Month","0.0","inch","46"],["Year","5.72","inch","47"],["Total","10.65","inch","48"]],"range":"Range:
>  
> 0inch to 
> 393.7inch."},{"title":"Solar","list":[["Light","261.36","w/m²"],["UVI","1.2",""]]}],"battery":{"title":"Battery","list":["All
>  
> battery are ok"]}}
>

-- 
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/35cecc00-debc-4f43-b7c4-c8ac07ca68f0n%40googlegroups.com.

[weewx-user] Re: Upgraded to 5.0.1, DB is updating but not reflecting

['michael.k...@gmx.at' via weewx-user]

Maybe this thread helps you solving your issue: 
https://groups.google.com/g/weewx-user/c/yfqGGuFw-L8/m/8Ba9Kd86AAAJ

Matt Johnson schrieb am Mittwoch, 6. März 2024 um 05:08:51 UTC+1:

> I've been at this hours. I updated my WeeWx from 4.10.2 to 5.0.1. I am 
> running Belchertown and have MQTT setup. That is all working. 
>
> The issue is I don't see the archive data updating the charts or 
> reflecting when you refresh the page. The database file itself does appear 
> to be updated every 5 minutes as the modified date is updating every 5 
> minutes.
>
> Any ideas to troubleshoot?
>

-- 
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/ae4b7a29-55f6-4d11-9948-6a791702b918n%40googlegroups.com.

Re: [weewx-user] Re: Horror upgrade from 4.10 to 5.0.2

['michael.k...@gmx.at' via weewx-user]

I can comprehend you point of view, since I more than once did updates in a 
similar way. What I learned from the past, sometimes the hard way:

   - I always check the list of packages, that will be upgraded
   - when I encounter a package I know I customized configs, I think twice.
   - when such a package does a major version upgrade x.x => y.0, I 
   definitely look for more info



Invisible Man schrieb am Sonntag, 3. März 2024 um 17:23:44 UTC+1:

> This happened during system upgrade: apt update, apt upgrade.
> When you do this, you do *not* read the Upgrade notes of each package you 
> are upgrading - and you don't have access to them, because it is supposed 
> to run correctly.
> And it did not : it did not load my weewx.conf at all (that's in a 
> previous post, but the issue is linked).
> Now, yes, the way I fixed it was wrong, and that's why I preferred to 
> downgrade, read the upgrade notes, and upgrade when I get more information.
>
> So, to clarify things:
> - No, it's not your fault, I'm not trying to blame anyone here, especially 
> that you do a wonderful work
> - It *was* a horror upgrade *for me*
>
>
>
> On Sunday, March 3, 2024 at 5:10:37 PM UTC+1 Tom Keffer wrote:
>
>> From what I see in the log, the upgrade ran perfectly. The problem was 
>> that you tried to use the old V4 utility "wee_extension" to install an 
>> extension in a V5 environment. As explained in the Upgrade Guide, you need 
>> to use "weectl extension install".
>>
>> I would not dismiss an upgrade as a "horror" if you haven't read the 
>> instructions. 
>>
>> On Sun, Mar 3, 2024 at 7:54 AM Invisible Man  
>> wrote:
>>
>>> Nice, no, that was exactly what I was looking for :)  Thanks! That'll 
>>> help very much.
>>>
>>> Just a pity that the upgrade went so bad. You expect an "apt upgrade" to 
>>> run without any issue...
>>>
>>>
>>> On Sunday, March 3, 2024 at 4:25:14 PM UTC+1 Tom Keffer wrote:
>>>
 It's all in the Upgrade Guide . 
 Did you read it?

 On Sun, Mar 3, 2024 at 7:22 AM Invisible Man  
 wrote:

> I downgraded back to 4.10. I will look into v5 later and calmly. This 
> is not just "some small upgrade that'll work out of the box". So many 
> things have changed like it's no longer wee_extension I see but weectl, 
> and 
> the daemon is running as weewx.
> Is there an upgrade procedure from 4.10 to v5 somewhere? + like all 
> the changes and new habits I should move to?
>
> sudo apt install weewx=4.10.2-1
> sudo apt-mark hold weewx 
>
> Thanks.
>
>
> On Sunday, March 3, 2024 at 3:44:44 PM UTC+1 Invisible Man wrote:
>
>> I used to have weewx 4.10 running smoothly with Interceptor driver. I 
>> upgraded to 5.0.2
>> There are the logs, and I believe I have tons of issues.
>> I add the upgrading logs at the end.
>>
>> First issue partially solved: the upgrade did not handle my 
>> /etc/default/weewx file and wasn't loading my config file. I fixed the 
>> /etc/default/weewx with this:
>>
>> WEEWX_PYTHON=python3
>> WEEWX_BINDIR=/usr/share/weewx
>> WEEWX_CFG=/etc/weewx/weewx.conf
>> WEEWX_BIN=/usr/bin/weewx
>>
>> Now, at least it's trying to do something. But it complains that No 
>> module named 'user'. I think that's because it is trying to run weewx as 
>> weewx user? Is that right?
>>
>> So, I thought I needed to install the interceptor driver in the weewx 
>> user account.
>> The command is ./wee_extension --install interceptor.zip, except I 
>> only have wee_extension in /etc/weewx/scripts and those were scripts but 
>> without the +x executable permission... I added it. 
>>
>> It's not working.
>>
>> $ ./wee_extension --install ~axelle/weewx-interceptor.zip 
>> python3: can't open file '/usr/share/weewx/wee_extension': [Errno 2] 
>> No such file or directory
>>
>> I'm no longer understanding where weewx has put its new files, thus 
>> my /etc/default/weewx file probably not correctly set. It's horrible 
>> mess. 
>> Where are things meant to be?
>>
>> Thanks
>>
>>
>>
>> Unpacking weewx (5.0.2-1) over (4.10.2-1) ...
>> dpkg: warning: unable to delete old directory 
>> '/usr/share/weewx/user': Directory not empty
>> dpkg: warning: unable to delete old directory 
>> '/etc/weewx/udev/rules.d': Directory not empty
>> dpkg: warning: unable to delete old directory 
>> '/etc/weewx/skins/Standard/smartphone/icons': Directory no
>> t empty
>> dpkg: warning: unable to delete old directory 
>> '/etc/weewx/skins/Standard/smartphone': Directory not empt
>> y
>> dpkg: warning: unable to delete old directory 
>> '/etc/weewx/skins/Standard/lang': Directory not empty
>> dpkg: warning: unable to delete old directory 
>> '/etc/weewx/skins/Standard/backgrounds': Directory not emp
>> ty
>>

Re: [weewx-user] leap year and span

['michael.k...@gmx.at' via weewx-user]

To show the adding one month also, and to show, it's not only three, but 
sometime four day in a row, plus/minus one month, lead to the very same 
date, I've added a few lines to the java example:

import java.time.*;
 
public class Leaps {
public static void main(String[] args)
{
LocalDate march28_23 = LocalDate.parse("2023-03-28");
LocalDate march29_23 = LocalDate.parse("2023-03-29");
LocalDate march30_23 = LocalDate.parse("2023-03-30");
LocalDate march31_23 = LocalDate.parse("2023-03-31");
LocalDate march29_24 = LocalDate.parse("2024-03-29");
LocalDate march30_24 = LocalDate.parse("2024-03-30");
LocalDate march31_24 = LocalDate.parse("2024-03-31");
 
System.out.printf("Minus:%n%n%s minus one month: %s%n", march28_23, 
march28_23.minusMonths(1));
System.out.printf("%s minus one month: %s%n", march29_23, 
march29_23.minusMonths(1));
System.out.printf("%s minus one month: %s%n", march30_23, 
march30_23.minusMonths(1));
System.out.printf("%s minus one month: %s%n", march31_23, 
march31_23.minusMonths(1));
System.out.printf("Leap year:%n%s minus one month: %s%n", 
march29_24, march29_24.minusMonths(1));
System.out.printf("%s minus one month: %s%n", march30_24, 
march30_24.minusMonths(1));
System.out.printf("%s minus one month: %s%n", march31_24, 
march31_24.minusMonths(1));

LocalDate jan28_23 = LocalDate.parse("2023-01-28");
LocalDate jan29_23 = LocalDate.parse("2023-01-29");
LocalDate jan30_23 = LocalDate.parse("2023-01-30");
LocalDate jan31_23 = LocalDate.parse("2023-01-31");
LocalDate jan29_24 = LocalDate.parse("2024-01-29");
LocalDate jan30_24 = LocalDate.parse("2024-01-30");
LocalDate jan31_24 = LocalDate.parse("2024-01-31");
 
System.out.printf("%nPlus:%n%n%s plus one month: %s%n", jan28_23, 
jan28_23.plusMonths(1));
System.out.printf("%s plus one month: %s%n", jan29_23, 
jan29_23.plusMonths(1));
System.out.printf("%s plus one month: %s%n", jan30_23, 
jan30_23.plusMonths(1));
System.out.printf("%s plus one month: %s%n", jan31_23, 
jan31_23.plusMonths(1));
System.out.printf("Leap year:%n%s plus one month: %s%n", jan29_24, 
jan29_24.plusMonths(1));
System.out.printf("%s plus one month: %s%n", jan30_24, 
jan30_24.plusMonths(1));
System.out.printf("%s plus one month: %s%n", jan31_24, 
jan31_24.plusMonths(1));
}
}

Output:

Minus:

2023-03-28 minus one month: 2023-02-28
2023-03-29 minus one month: 2023-02-28
2023-03-30 minus one month: 2023-02-28
2023-03-31 minus one month: 2023-02-28
Leap year:
2024-03-29 minus one month: 2024-02-29
2024-03-30 minus one month: 2024-02-29
2024-03-31 minus one month: 2024-02-29

Plus:

2023-01-28 plus one month: 2023-02-28
2023-01-29 plus one month: 2023-02-28
2023-01-30 plus one month: 2023-02-28
2023-01-31 plus one month: 2023-02-28
Leap year:
2024-01-29 plus one month: 2024-02-29
2024-01-30 plus one month: 2024-02-29
2024-01-31 plus one month: 2024-02-29 

Tom Keffer schrieb am Freitag, 1. März 2024 um 13:46:46 UTC+1:

> That's interesting! However, Python treats it differently. The equivalent 
> would be something like
>
> import datetime
> march29_23 = datetime.date.fromisoformat("2023-03-29")
> print(march29_23 - datetime.timedelta(month=1))
>
>
> Unfortunately, datetime.timedelta does not offer an argument "month", 
> perhaps for just this reason.
>
> However, I am open to a pull request should someone want to capture an 
> alternative behavior.
>
> -tk
>
>
>
> On Fri, Mar 1, 2024 at 1:13 AM 'michael.k...@gmx.at' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> Citing issue #436 <https://github.com/weewx/weewx/issues/436>
>>
>> "What is 30 March minus one month? By this solution, it should be 28 Feb.
>>
>> So then what is 29 March minus one month? Also 28 Feb? And so would 28 
>> March minus a month. So, "one month earlier" for three days in a row leads 
>> to the same date. That doesn't seem right."
>> That's how the Java People do it:
>> import java.time.*; 
>>   
>> import java.time.*; 
>>   
>> public class Leaps { 
>> public static void main(String[] args) 
>> { 
>> LocalDate march29_23 = LocalDate.parse("2023-03-29");
>> LocalDate march30_23 = LocalDate.parse("2023-03-30");
>> LocalDate march31_23 = LocalDate.parse("2023-03-3

Re: [weewx-user] leap year and span

['michael.k...@gmx.at' via weewx-user]

Citing issue #436 

"What is 30 March minus one month? By this solution, it should be 28 Feb.

So then what is 29 March minus one month? Also 28 Feb? And so would 28 
March minus a month. So, "one month earlier" for three days in a row leads 
to the same date. That doesn't seem right."
That's how the Java People do it:
import java.time.*; 
  
import java.time.*; 
  
public class Leaps { 
public static void main(String[] args) 
{ 
LocalDate march29_23 = LocalDate.parse("2023-03-29");
LocalDate march30_23 = LocalDate.parse("2023-03-30");
LocalDate march31_23 = LocalDate.parse("2023-03-31");
LocalDate march29_24 = LocalDate.parse("2024-03-29");
LocalDate march30_24 = LocalDate.parse("2024-03-30");
LocalDate march31_24 = LocalDate.parse("2024-03-31");
  
System.out.printf("%s minus one month: %s%n", march29_23, 
march29_23.minusMonths(1));
System.out.printf("%s minus one month: %s%n", march30_23, 
march30_23.minusMonths(1));
System.out.printf("%s minus one month: %s%n", march31_23, 
march31_23.minusMonths(1));
System.out.printf("%s minus one month: %s%n", march29_24, 
march29_24.minusMonths(1));
System.out.printf("%s minus one month: %s%n", march30_24, 
march30_24.minusMonths(1));
System.out.printf("%s minus one month: %s%n", march31_24, 
march31_24.minusMonths(1));
} 
} 

Output:
2023-03-29 minus one month: 2023-02-28
2023-03-30 minus one month: 2023-02-28
2023-03-31 minus one month: 2023-02-28
2024-03-29 minus one month: 2024-02-29
2024-03-30 minus one month: 2024-02-29
2024-03-31 minus one month: 2024-02-29

So, they claim it is right, what doesn't seem right for you. 
Tom Keffer schrieb am Donnerstag, 29. Februar 2024 um 21:03:55 UTC+1:

> I am not surprised that $year_delta=1 does not work on leap day. There is 
> no 29 February 2023.
>
> This is issue #436 .
>
>
> On Thu, Feb 29, 2024 at 9:45 AM František Slimařík  
> wrote:
>
>> Hi Tom,
>>
>> actually I found another for cycle which caused the issue. When I changed 
>> delta from "$year_delta=1" into "$day_delta=365" it works again. 
>> Interesting it worked without any issue till yesterday :)
>>
>> ##for $A in $span($year_delta=1).months
>>  $A.dateTime.format("%OB %Y");$A.rain.sum.format(add_label=False)
>> #end for
>>
>>
>> čt 29. 2. 2024 v 15:49 odesílatel Tom Keffer  napsal:
>>
>>> I just tried this and it worked fine:
>>>
>>> 28. February 2023;33.4
>>> 1. March 2023;36.1
>>> 2. March 2023;38.0
>>> 3. March 2023;37.1
>>> ...
>>> 26. February 2024;37.3
>>> 27. February 2024;38.5
>>> 28. February 2024;41.3
>>>
>>>
>>> On Wed, Feb 28, 2024 at 8:57 PM František Slimařík  
>>> wrote:
>>>
 Yes, right

 #for $i in $span($day_delta=365).days
 #set fDate = $i.dateTime.format("%-d. %B %Y")
 $fDate;$i.outTemp.avg.format(add_label=False)
 #end for

 čt 29. 2. 2024 v 1:49 odesílatel Tom Keffer  napsal:

> I don't know. How are you using the $span() tags? In a loop, I assume?
>
> On Wed, Feb 28, 2024 at 3:25 PM František Slimařík  
> wrote:
>
>> Hello,
>>
>> is it possible that leap year causes issue in span tag? I am using 
>> these:
>>
>> $span($day_delta=365).days
>> $span($year_delta=1).months
>>
>> Feb 29 00:10:43 rocky-weather-machine weewxd[405028]: ERROR 
>> weewx.cheetahgenerator: Evaluation of template 
>> /etc/weewx/skins/neowx/year.html.tmpl failed with exception '> 'ValueError'>'
>> Feb 29 00:10:43 rocky-weather-machine weewxd[405028]: ERROR 
>> weewx.cheetahgenerator:  Ignoring template 
>> /etc/weewx/skins/neowx/year.html.tmpl
>> Feb 29 00:10:43 rocky-weather-machine weewxd[405028]: ERROR 
>> weewx.cheetahgenerator:  Reason: day is out of range for month
>> Feb 29 00:10:43 rocky-weather-machine weewxd[405028]: ERROR 
>> weewx.cheetahgenerator:   Traceback (most recent call last):
>> Feb 29 00:10:43 rocky-weather-machine weewxd[405028]: ERROR 
>> weewx.cheetahgenerator: File 
>> "/usr/share/weewx/weewx/cheetahgenerator.py", line 334, in generate
>> Feb 29 00:10:43 rocky-weather-machine weewxd[405028]: ERROR 
>> weewx.cheetahgenerator:   unicode_string = 
>> compiled_template.respond()
>> Feb 29 00:10:43 rocky-weather-machine weewxd[405028]: ERROR 
>> weewx.cheetahgenerator: File 
>> "_etc_weewx_skins_neowx_year_html_tmpl.py", line 1380, in respond
>> Feb 29 00:10:43 rocky-weather-machine weewxd[405028]: ERROR 
>> weewx.cheetahgenerator: File "/usr/share/weewx/weewx/tags.py", 
>> line 
>> 132, in span
>> Feb 29 00:10:43 rocky-weather-machine weewxd[405028]: ERROR 
>> weewx.cheetahgenerator:   year_delta=year_delta, 
>> boundary=boundary),
>> Feb 29 00:10:43 rocky-weather-machine weewxd[405028]: ERROR 
>>

Re: [weewx-user] Your hardware experience (for running WeeWX, the service)

['michael.k...@gmx.at' via weewx-user]

Interesting insights. I've always been using the official power supplies 
and SD-Cards and flash drives from major brands. And they always got me 
brand new cards, as the were under warranty. Also, we have super stable 
power supply here. Often years without power surge, the last black some 
years ago, and this only locally. Despite that, my devices are connected to 
a UPS since a while, and I had still issues.

Tom Keffer schrieb am Samstag, 24. Februar 2024 um 00:25:43 UTC+1:

> I'm with Vince. I believe the micro-SD cards are perfectly reliable. As an 
> experiment I've been running WeeWX on an RPi B+ with an SD card for over 9 
> years. The key is a reliable power supply connected to a UPS. Webpage: 
> https://www.threefools.org/weewx/status/index.html
>
> I'm getting tired of waiting for it to break --- it's taking up too much 
> space on my desk. If it doesn't break soon, I'll probably end the 
> experiment.
>
> On Fri, Feb 23, 2024 at 11:41 AM Gábor Szabados  
> wrote:
>
>> Shamefully, running a bit old version of WeeWX, from 2019, on a Raspberry 
>> Pi Zero W, which has Raspbian and mainly default settings WeeWX. The same 
>> SD card since. The Pi operates in an interceptor way, it creates a hotspot 
>> for the weather station which sends all information to WU, WeeWX with 
>> Interceptor intercepts it, meanwhile the Pi connects to the local network 
>> by Wifi as well. A bit over complicated, but it was before the FineOffset 
>> clones were offering a custom URL option in their firmware.
>>
>> It was a minimum budget project, still runs without any issues. (Knock on 
>> wood.)
>>
>> Graham Knights a következőt írta (2024. február 23., péntek, 19:43:49 
>> UTC+1):
>>
>>> I've been running weewx on a RPi 3B+ for just over 5 years, but after a 
>>> couple of other pi's died for various reasons (SD card being one of them), 
>>> I've moved it to a debian install on a VM in a Windows 10 Pro machine (runs 
>>> my automation server).  Hardware is a Lenovo ThinkCentre M700 Tiny which I 
>>> find perfect for running a couple of small linux VM's on it.  Low power, 
>>> tiny, quiet, and versatile, and Lenovo hardware has been good to me over 
>>> the years. Machines are cheap to find on ebay/amazon, probably less than a 
>>> new Pi by the time you add all the parts.
>>>
>>> On Friday, February 23, 2024 at 9:46:42 AM UTC-8 vince wrote:
>>>
 If I was starting clean 'today', I would probably just throw $125 at it 
 and get one of those little beelink boxes amazon sells and toss linux on 
 it.

 But to answer - currently on a 4GB pi4 to sd card for 2+ years with no 
 issues.

 Stability issues on a pi are almost always bad power supply these 
 days.  I've never had a micro-sd fail on a pi3, 3+, 4, or pi5.  Never.   I 
 did burn a 'lot' of big sd cards on the old modelB over the years but 
 again 
 that was related to either (a) cheapo cards or (b) cheapo power adaptors 
 not on surge suppressors.  My one remaining modelB is still happily 
 shooting my timelapse snaps for over a decade now.

 I do make one change to the pi setups to protect the sd card.  I mount 
 some filesystems as tmpfs so the sd can't be hammered by log writes by 
 appending this to /etc/stab

 # put logs and tmp dirs in ramdisk too ---
 tmpfs   /tmptmpfs   
 defaults,nosuid,mode=0755,nodev,noatime   0   0
 tmpfs   /var/logtmpfs   
 defaults,nosuid,mode=0755,nodev,noatime   0   0
 tmpfs   /var/tmptmpfs   
 defaults,nosuid,mode=0755,nodev,noatime   0   0
 #-

 Yes - if I reboot I lose the system logs.  But I basically never reboot.

 I might add that I do install rsyslog and the matching logrotate.d and 
 rsyslog.d files from util/ to my v5 setup, so weewx logs to under 
 /var/log/weewx in that tmpfs partition, so I just run debug=1 here because 
 it's not going to touch the actual sd card.  Super stable.

 -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/86c8becf-edfb-4264-b93f-2626ed9adfacn%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/08904aca-2678-4467-a81e-7972496abb15n%40googlegroups.co

[weewx-user] Your hardware experience (for running WeeWX, the service)

['michael.k...@gmx.at' via weewx-user]

I'm curious what hardware you are running WeeWX on, and your experience 
with it. So, this is not about the weather station and the sensors, but the 
device which is running the service. The reason I ask this here, is because 
the issues I experienced with my hardware might be related to weewx and 
writing it's logs, and we all know the first rule for posting a question 
here :D

Since my first WeeWX installation in 2015, I've been using every generation 
of the RaspberryPi B, except for the 5th. But looking back it, has 
sometimes has been a royal PITA. It's not that I consider the Pi being bad 
at all, but I've been having issues with whatever storage I've been using. 
SD-Cards were a total disaster, USB flash drives were slightly better, USB 
attached SSDs, at least, lasted more than two years before being attached 
to the Pi killed them. The only type that didn't fail so far, was a NFS 
provided by a QNAP NAS, but this Kind of setup is a bit complex to 
maintain, and starting the NAS over, means quite a bit of downtime for the 
Pi also.

The Pi never was intended to be a server running 24/7, considering this, 
it's success in being used as such, is beyond imagination. Anyway, my 
experience for the Pi being a storage killer, doesn't seem to be uncommon. 
It's original intention was satisfied: I learned a lot about how not to 
lose data with unreliable hardware. Since 2015, my database isn't missing 
more than one archive value a day in average and the longest gap is about 
two hours back in early 2016, using the standard interval of 5 minutes.

What hardware are you using, what is your experience?
Can you suggest hardware with low power consumption as a requirement?
What about the newest generation, like Intel n100 based systems? 

-- 
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/69220248-dd7a-4e8a-a7bb-f3251017e0f5n%40googlegroups.com.

Re: [weewx-user] How to upgrade from setup.py v4 install to pip v5 install

['michael.k...@gmx.at' via weewx-user]

I'd do it this way:

- leave your existing installation running

- install v5 the pip way, exactly like described here, including 
provisioning a new station: https://weewx.com/docs/5.0/quickstarts/pip/
- provision the station with default values
- start and verify it
- copy your old weewx.conf over the newly created one
- check your paths in your weewx.conf (WEWWX_ROOT, HTML_ROOT, SKIN_ROOT and 
so on)
- in case of using sqlite: copy your database to ~/weewx-data/archive, 
overwriting the newly created one, if the file names are the same, 
otherwise delete the newly created one, to have things tidy
- install all extensions (drivers, skins, ...) you had before , see: 
https://weewx.com/docs/5.0/utilities/weectl-extension/
- if any, copy all your bin/user files that didn't come with an installer 
to ~/weewx-data/bin/user/

- if your device isn't limited to exclusive access, run weewxd in the venv 
and validate
- if your device is limited to exclusive access, stop the old installation 
and run (the new) weewxd in the venv and validate
- once validated, enjoy

Depending on your hardware, you might want to copy the udev rules and apply 
them (~/weewx-data/util/udev)
Depending on your needs and environment, create and enable systemd scripts 
(~/weewx-data/util/systemd)
gary@gmail.com schrieb am Mittwoch, 21. Februar 2024 um 16:44:02 UTC+1:

> I understand coming from v5 that would be a way.
> I need to upgrade my v4 setup.py to v5 though.
>
>
> On Wednesday, February 21, 2024 at 10:39:47 AM UTC-5 Tom Keffer wrote:
>
> The pip installs are super easy to back up. Just copy ~/weewx-venv and 
> ~/weewx-data and you have everything you need.
>
> Then activate the virtual environment, then "pip install weewx --upgrade". 
> It should be that easy. If something fails, just roll things back.
>
> On Wed, Feb 21, 2024 at 7:15 AM gary@gmail.com  
> wrote:
>
> I've had a test install of v5 since early alphas. Now, it is time to 
> upgrade my production install.
> I have a relatively simple install, Vantage Pro IP driver, weewx-mqtt. A 
> couple of additional internet uploaders (Windy and WeatherCloud). I run two 
> skins, Belchertown and weewx-wdc
>
> All is and has been quite stable. So, I hesitate to poke at it. But, v5 is 
> the new standard, so I need to get this done.
>
> I don't see many who have trod this path. How to go about 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+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-34ea51167f24n%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/c576449a-71b4-4c87-aa50-aed752615134n%40googlegroups.com.

Re: [weewx-user] How to upgrade from setup.py v4 install to pip v5 install

['michael.k...@gmx.at' via weewx-user]

I did this like dozens of times already, it is that easy.
v5 the pip way is just awesome.

Tom Keffer schrieb am Mittwoch, 21. Februar 2024 um 16:39:47 UTC+1:

> The pip installs are super easy to back up. Just copy ~/weewx-venv and 
> ~/weewx-data and you have everything you need.
>
> Then activate the virtual environment, then "pip install weewx --upgrade". 
> It should be that easy. If something fails, just roll things back.
>
> On Wed, Feb 21, 2024 at 7:15 AM gary@gmail.com  
> wrote:
>
>> I've had a test install of v5 since early alphas. Now, it is time to 
>> upgrade my production install.
>> I have a relatively simple install, Vantage Pro IP driver, weewx-mqtt. A 
>> couple of additional internet uploaders (Windy and WeatherCloud). I run two 
>> skins, Belchertown and weewx-wdc
>>
>> All is and has been quite stable. So, I hesitate to poke at it. But, v5 
>> is the new standard, so I need to get this done.
>>
>> I don't see many who have trod this path. How to go about 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/b2d73a89-3432-4ad4-8971-34ea51167f24n%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/c3102203-1e41-4938-8925-2ffca92e42a3n%40googlegroups.com.

[weewx-user] Re: Bad install

['michael.k...@gmx.at' via weewx-user]

Maybe , first of all, change 

[Station]
longitude =  -89-77993

to

[Station]
longitude =  -89.77993

in your weewx.conf and see, if this helps you getting rid of all this crap.
Adam White schrieb am Sonntag, 18. Februar 2024 um 19:33:01 UTC+1:

> Hi I'm stuck trying to install weewx on a pi 3b+ running bullseye. I used 
> apt install weewx and went through the configure options but it apparently 
> didn't like my inputs. Before completing the install it errored out. 
> I tried sudo dpkg --configure -a and it never worked until I deleted 
> /var/lib/dpkg/info/weewx*
> I would think after deleting that, running apt purge weewx and deleting 
> the following:
>
> sudo rm -r /etc/weewx
>
> sudo rm -r /var/www/html/weewx
>
> sudo rm -r /var/lib/weewx
>
> sudo rm -r /etc/weewx
>
> sudo rm /etc/default/weewx
>
> sudo rm -r /usr/share/weewx
>
> It would be able to start fresh but that's not the case. 
>
>
> Today I deleted all the above again, did a sudo apt install weewx and had 
> this output:
>
>
> pi@k4spbx:~ $ sudo apt install weewx
>
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Suggested packages:
>   sqlite ftp
> The following NEW packages will be installed:
>   weewx
> 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B/1,556 kB of archives.
> After this operation, 5,720 kB of additional disk space will be used.
> Preconfiguring packages ...
> Selecting previously unselected package weewx.
> (Reading database ... 122960 files and directories currently installed.)
> Preparing to unpack .../archives/weewx_5.0.2-1_all.deb ...
> Unpacking weewx (5.0.2-1) ...
> Setting up weewx (5.0.2-1) ...
> Using weewx:weewx as user:group
> Creating /etc/default/weewx
> Using configuration file /etc/weewx/weewx.conf
> Processing configuration file /etc/weewx/weewx.conf
> Traceback (most recent call last):
>   File "/usr/share/weewx/weectl.py", line 74, in 
> main()
>   File "/usr/share/weewx/weectl.py", line 66, in main
> namespace.func(namespace)
>   File "/usr/share/weewx/weectllib/__init__.py", line 121, in dispatch
> namespace.action_func(config_dict, namespace)
>   File "/usr/share/weewx/weectllib/station_cmd.py", line 311, in reconfi
> gure_station
> weectllib.station_actions.station_reconfigure(config_dict=config_dic
> t,
>   File "/usr/share/weewx/weectllib/station_actions.py", line 164, in sta
> tion_reconfigure
> config_config(config_dict,
>   File "/usr/share/weewx/weectllib/station_actions.py", line 205, in con
> fig_config
> config_latlon(config_dict, latitude=latitude, longitude=longitude, n
> o_prompt=no_prompt)
>   File "/usr/share/weewx/weectllib/station_actions.py", line 345, in con
> fig_latlon
> config_dict['Station']['longitude'] = float(final_longitude)
> ValueError: could not convert string to float: '-89-77993'
> dpkg: error processing package weewx (--configure):
>  installed weewx package post-installation script subprocess returned er
> ror exit status 1
> Errors were encountered while processing:
>  weewx
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
>
> Followed by:
>
> pi@k4spbx:~ $ sudo dpkg --configure -a
> Setting up weewx (5.0.2-1) ...
> Using weewx:weewx as user:group
> Saving old defaults to /etc/default/weewx-20240218113817
> Creating /etc/default/weewx
> Using configuration file /etc/weewx/weewx.conf
> Processing configuration file /etc/weewx/weewx.conf
> Traceback (most recent call last):
>   File "/usr/share/weewx/weectl.py", line 74, in 
> main()
>   File "/usr/share/weewx/weectl.py", line 66, in main
> namespace.func(namespace)
>   File "/usr/share/weewx/weectllib/__init__.py", line 121, in dispatch
> namespace.action_func(config_dict, namespace)
>   File "/usr/share/weewx/weectllib/station_cmd.py", line 311, in 
> reconfigure_station
> weectllib.station_actions.station_reconfigure(config_dict=config_dict,
>   File "/usr/share/weewx/weectllib/station_actions.py", line 164, in 
> station_reconfigure
> config_config(config_dict,
>   File "/usr/share/weewx/weectllib/station_actions.py", line 205, in 
> config_config
> config_latlon(config_dict, latitude=latitude, longitude=longitude, 
> no_prompt=no_prompt)
>   File "/usr/share/weewx/weectllib/station_actions.py", line 345, in 
> config_latlon
> config_dict['Station']['longitude'] = float(final_longitude)
> ValueError: could not convert string to float: '-89-77993'
> dpkg: error processing package weewx (--configure):
>  installed weewx package post-installation script subprocess returned 
> error exit status 1
> Errors were encountered while processing:
>  weewx
>
>
>
> How do I actually delete all this crap, actually purge and then start 
> fresh?
>
> Thanks.
>

-- 
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...@googl

[weewx-user] Re: Weewx don't work anymore after SD card restore, I don't know why?

['michael.k...@gmx.at' via weewx-user]

It will definitely help if you'd attach the log files as a whole, it
see>
ms >
the>
 lo>
g ab>
ove is not showing all the relevant data.
Thomas Hackler schrieb am Samstag, 17. Februar 2024 um 10:41:33 UTC+1:

> pi@raspberrypi:~ $ apt policy weewx
> weewx:
>   Installed: 5.0.2-1
>   Candidate: 5.0.2-1
>
>
> Thomas Hackler schrieb am Samstag, 17. Februar 2024 um 10:39:13 UTC+1:
>
>> here are some more information, something seems to be wrong with the 
>> gw1000 driver, but I changed nothing:
>>
>> pi@raspberrypi:~ $ systemctl status weewx*
>> ● weewx.service - WeeWX
>>  Loaded: loaded (/lib/systemd/system/weewx.service; enabled; vendor 
>> preset:>
>>  Active: failed (Result: exit-code) since Sat 2024-02-17 10:18:36 
>> CET; 17mi>
>>Docs: https://weewx.com/docs
>> Process: 606 ExecStart=weewxd /etc/weewx/weewx.conf (code=exited, 
>> status=4)
>>Main PID: 606 (code=exited, status=4)
>> CPU: 621ms
>>
>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:  
>>  s>
>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:  
>>Fil>
>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:  
>>  r>
>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:  
>>Fil>
>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:  
>>  r>
>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL weewx.engine:  
>>  user.>
>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL __main__: Unable to 
>> load driv>
>> Feb 17 10:18:36 raspberrypi weewxd[606]: CRITICAL __main__:  
>>  Exiting...
>> Feb 17 10:18:36 raspberrypi systemd[1]: weewx.service: Main process 
>> exited, cod>
>> Feb 17 10:18:36 raspberrypi systemd[1]: weewx.service: Failed with result 
>> 'exit>
>> lines 1-18/18 (END)...skipping...
>> ● weewx.service - WeeWX
>>  Loaded: loaded (/lib/systemd/system/weewx.service; enabled; vendor 
>> preset: enabled)
>>  Active: failed (Result: exit-code) since Sat 2024-02-17 10:18:36 
>> CET; 17min ago
>>Docs: https://weewx.com/docs
>> Process: 606 ExecStart=weewxd /etc/weewx/weewx.conf (code=exited, 
>> status=4)
>>Main PID: 606 (code=exited, status=4)
>> CPU: 621ms
>>
>> Thomas Hackler schrieb am Samstag, 17. Februar 2024 um 10:35:25 UTC+1:
>>
>>> Hello,
>>> I use weewx on a raspberry Pi 4. My system crashed and I had to go back 
>>> to an SD card image from January. It was a state were weewx was runing 
>>> normally.
>>> But now I don't know why weewx is not working anymore.
>>> I get no reaction for commands like 
>>>
>>> sudo /etc/init.d/weewx stop
>>> sudo /etc/init.d/weewx start
>>>
>>> debug = 1 and I don't see something in syslog:
>>>
>>> sudo tail -f /var/log/syslog | grep weewx 
>>>
>>> in January I had a weewx 4 and with apt upgrade I guess I changed to 
>>> version 5 now but this was not a problem during my last update.
>>>
>>> Any ideas? Thank you!
>>>
>>> Regards
>>> Thomas
>>>
>>

-- 
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/a56838d6-6761-4706-bfc6-3af01b7a303an%40googlegroups.com.

[weewx-user] Re: Can we upgrade to WeeWX 5.0x WITHOUT MAJOR RISK?

['michael.k...@gmx.at' via weewx-user]

...and keep the old installation running on the same machine!

michael.k...@gmx.at schrieb am Samstag, 17. Februar 2024 um 10:11:41 UTC+1:

> You can upgrade without any risk. Just follow the instructions in the 
> quickstart guide for pip: https://www.weewx.com/docs/5.0/quickstarts/pip/ 
> and install the new version in a venv, as described there.
>
> Your present installation won't be affected, as long they don't require 
> any exclusive access to resources, such as direct exclusive access to 
> devices, or servers on distinct local ports.
>
> Remy Lavabre schrieb am Samstag, 17. Februar 2024 um 09:59:19 UTC+1:
>
>> Good morning,
>>
>> I've been seeing various problems (mainly access rights?) for some time 
>> with the 5.x update.
>>
>> For a configuration in 4.10.2 on Pi with Bulleyes 64B, does the 
>> transition to 5.x present risks of malfunction with the use of a modified 
>> base skin (Seasons) but above all:
>>
>> - A personalized driver which retrieves Awekas data from the station via 
>> the internet as well as various other parameters from the Pi (temperature, 
>> memory, SSD status etc.) but also data on external counter modules;
>>
>> - An alarm generator (multialarm.py) allowing you to be notified based on 
>> precise weather criteria defined in advance
>>
>> - the excellent alltimeSeasons skin made by Glenn Mckechnie
>>
>>
>> With experience, are there checks to be made before to avoid surprises 
>> afterwards...?
>>
>> Thank you so much... ;-)
>>
>

-- 
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/b10c72cd-d5d4-4d4e-88f9-97aecd0ee2c7n%40googlegroups.com.

[weewx-user] Re: Can we upgrade to WeeWX 5.0x WITHOUT MAJOR RISK?

['michael.k...@gmx.at' via weewx-user]

You can upgrade without any risk. Just follow the instructions in the 
quickstart guide for pip: https://www.weewx.com/docs/5.0/quickstarts/pip/ 
and install the new version in a venv, as described there.

Your present installation won't be affected, as long they don't require any 
exclusive access to resources, such as direct exclusive access to devices, 
or servers on distinct local ports.

Remy Lavabre schrieb am Samstag, 17. Februar 2024 um 09:59:19 UTC+1:

> Good morning,
>
> I've been seeing various problems (mainly access rights?) for some time 
> with the 5.x update.
>
> For a configuration in 4.10.2 on Pi with Bulleyes 64B, does the transition 
> to 5.x present risks of malfunction with the use of a modified base skin 
> (Seasons) but above all:
>
> - A personalized driver which retrieves Awekas data from the station via 
> the internet as well as various other parameters from the Pi (temperature, 
> memory, SSD status etc.) but also data on external counter modules;
>
> - An alarm generator (multialarm.py) allowing you to be notified based on 
> precise weather criteria defined in advance
>
> - the excellent alltimeSeasons skin made by Glenn Mckechnie
>
>
> With experience, are there checks to be made before to avoid surprises 
> afterwards...?
>
> Thank you so much... ;-)
>

-- 
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/331e3c85-b76a-42e7-aadf-9011d3baad9en%40googlegroups.com.

Re: [weewx-user] Re: Upgrade to 5.0.x does not start

['michael.k...@gmx.at' via weewx-user]

The user which ist running weewxd has no permission to generate/modify the 
resource  "/var/www/html/weewx/json/24h.json"

Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: ERROR weewx.reportengine: 
  [Errno 13] Keine Berechtigung: '/var/www/html/weewx/json/24h.json'


geni08...@gmail.com schrieb am Freitag, 16. Februar 2024 um 16:13:19 UTC+1:

> I have used this
>
> sudo usermod -aG dialout weewx
> sudo systemctl restart weewx
>
> Weewx is running but there is another authorization problem
>
>
> Feb 16 16:10:27 Wetter-Raspi4 weewxd[440995]: DEBUG user.rainrate: 
> new_loop(1708096227): Added/updated pkt[rainRate] of 0.00
> Feb 16 16:10:27 Wetter-Raspi4 weewxd[440995]: DEBUG user.sunduration: 
> Calculated LOOP sunshine_time = 2.00, based on radiation = 90.00, 
> and threshold = 144.382899
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: DEBUG weewx.manager: Daily 
> summary version is 4.0
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: ERROR weewx.reportengine: 
> Caught unrecoverable exception in generator 
> 'user.belchertown.HighchartsJsonGenerator'
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: ERROR weewx.reportengine:   
>     [Errno 13] Keine Berechtigung: 
> '/var/www/html/weewx/json/24h.json'
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: ERROR weewx.reportengine:   
>     Traceback (most recent call last):
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: ERROR weewx.reportengine:   
>   File "/usr/share/weewx/weewx/reportengine.py", line 220, in 
> run
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: ERROR weewx.reportengine:   
>     obj.start()
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: ERROR weewx.reportengine:   
>   File "/usr/share/weewx/weewx/reportengine.py", line 409, in 
> start
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: ERROR weewx.reportengine:   
>     self.run()
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: ERROR weewx.reportengine:   
>   File "/etc/weewx/bin/user/belchertown.py", line 2817, in run
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: Traceback (most recent call 
> last):
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]:   File 
> "/usr/share/weewx/weewx/reportengine.py", line 220, in run
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: obj.start()
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]:   File 
> "/usr/share/weewx/weewx/reportengine.py", line 409, in start
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: self.run()
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]:   File 
> "/etc/weewx/bin/user/belchertown.py", line 2817, in run
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: with open(json_filename, 
> mode="w") as jf:
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: PermissionError: [Errno 13] 
> Keine Berechtigung: '/var/www/html/weewx/json/24h.json'
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: ERROR weewx.reportengine:   
>     with open(json_filename, mode="w") as jf:
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: ERROR weewx.reportengine:   
>     PermissionError: [Errno 13] Keine Berechtigung: 
> '/var/www/html/weewx/json/24h.json'
> Feb 16 16:10:28 Wetter-Raspi4 weewxd[440995]: ERROR weewx.reportengine:   
>     Generator terminated
>
>
> and
> sudo wee_reports
> sudo: wee_reports: Befehl nicht gefunden
>
>
>
> matthew wall schrieb am Freitag, 16. Februar 2024 um 14:44:24 UTC+1:
>
>> On Friday, February 16, 2024 at 7:57:08 AM UTC-5 geni08...@gmail.com 
>> wrote:
>>
>> where can i see which user starts weewxd?
>>
>>
>> if weewxd is running, do this:
>>
>> ps aux | grep weewxd
>>
>> the first word is the user running weewxd
>>
>> if weewxd is not running, then check the value for 'User' in the systemd 
>> unit file
>>
>> # if you installed using DEB/RPM:
>> grep User /usr/lib/systemd/system/weewx.service
>>
>> # if you installed using pip:
>> grep User /etc/systemd/system/weewx.service
>>
>> m
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/6582ee5e-b2d7-4369-bd96-60aed3c045e7n%40googlegroups.com.

[weewx-user] Re: Weewx upgrade questions

['michael.k...@gmx.at' via weewx-user]

Do you need to connect the station physically to the PI to get the data 
from the station(usb, serial, ...) or can you obtain data over the network? 
Or can you connect the station simultaneously to both PIs? If so, start 
from scratch with an OS update and a 5.x installation, and keep the old 
setup running, until you're satisfied.

If not, copy the database, do a 5.x install, configure simulator as the 
driver and when you're satisfied, copy the database again, configure the 
"real" driver and connect the station to the new hardware. 
When you do the database expansion is up to you. I'd do it on the new 
station.
(Also, I very much like the pip way to install everything)

kutz...@gmail.com schrieb am Montag, 12. Februar 2024 um 20:54:50 UTC+1:

> I have been remiss in upgrading my Weewx implementation and have decided 
> it's time to do that. I'm running version 3.9.1 (!) and plan to move to the 
> latest version 5.x. My install was setup.py. My station is a Davis Vantage 
> Vue.
>
> I'm running on a Pi Zero W with Buster OS and an added RTC. I've looked at 
> the upgrade guide, at least briefly, so far. I have a couple of questions:
>
> 1: I also want to upgrade the OS. I have a spare Pi 3B+ (also running on 
> Buster) and think I'll move Weewx to that device. Should I move my 
> implementation to the 3B+ before moving forward?
>
> 2: Should I upgrade the OS first, or do the Weewx upgrade first?
>
> 3: Am I best doing the Weewx upgrade in stages; moving to a version 4.x of 
> Weewx first before going to 5.x or go directly to 5.x? If so, which 4.x 
> version? The Upgrade guide talks about moving 4.x setup.pi to 5.x, but not 
> moving from 3.x to 5.x.
>
> 4: I know I need to install Python 3.6 or higher. I'll check the Upgrade 
> guide on that.
>
> 5: I've seen a number of posts regarding expanding the database. Should I 
> do that before upgrading Weewx? Or is that ifo in the Uprade guide?
>
> Thanks in advance.
> Phil
>

-- 
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/22009645-8b04-41a7-b5c5-9df9f1c5d3d7n%40googlegroups.com.

Re: [weewx-user] Which driver should i target for my custom weather station?

['michael.k...@gmx.at' via weewx-user]

ct data structure of a given weewx 
>>>> driver, which is the part i was asking about and can't easily find 
>>>> documented anywhere, i was basically looking at the driver code and trying 
>>>> to see how it maps packet data to weather data.
>>>>
>>>> On Tuesday 6 February 2024 at 23:28:05 UTC+10 p q wrote:
>>>>
>>>>> Yeah. I'm assuming you will be running Weewx on some computer other 
>>>>> than the ESP and have a network connection between the ESP and the 
>>>>> computer. I would use MQTT to publish the sensor data to a MQTT broker 
>>>>> running somewhere on your network, likely Mosquitto running on the same 
>>>>> machine as Weewx. Weewx would subscribe to the sensor data and go from 
>>>>> there. I am not up on the Weewx MQTT driver, but I would look into using 
>>>>> it. I personally use the Accurite driver as my original system is an 
>>>>> Accurite. Over time as I've added new sensors or replaced crummy ones, 
>>>>> I've 
>>>>> started to use MQTT as my preferred method of sending data from 
>>>>> microcontrollers to Weewx with various hacks on the Accurite driver.
>>>>>
>>>>> On Tue, Feb 6, 2024 at 2:51 AM 'michael.k...@gmx.at' via weewx-user <
>>>>> weewx...@googlegroups.com> wrote:
>>>>>
>>>>>> A few thoughts:
>>>>>>
>>>>>> Building the "station" on a ESP8266 doesn't sound like you are 
>>>>>> planning to get too far with your project. Compared to it's successor, 
>>>>>> it 
>>>>>> is very limited and has some really weird flaws.
>>>>>> Why would you connect the station with a serial interface, when it 
>>>>>> has WIFI on board?
>>>>>> p q's MQTT suggestion is a not a bad one. Let your station emit every 
>>>>>> single sensor reading as a MQTT message, and let weewx receive it with 
>>>>>> MQTT 
>>>>>> Subscribe <https://github.com/bellrichm/WeeWX-MQTTSubscribe>
>>>>>> Either MQTT Subscribe as a service, augmenting any off-the-shelf 
>>>>>> station supported by weewx with your sensors data, or use it as a 
>>>>>> driver. 
>>>>>> Encapsulating sensor data in JSON for the MQTT payload is commonly done 
>>>>>> and 
>>>>>> supported by MQTT Subscribe.
>>>>>> Pavocracy schrieb am Dienstag, 6. Februar 2024 um 11:07:05 UTC+1:
>>>>>>
>>>>>>> I'm not sure if im misunderstanding what you are saying, or if i am 
>>>>>>> not doing a good job at explaining my question, but even if i choose 
>>>>>>> mqtt 
>>>>>>> as my location to push the data, the data still needs to be in some 
>>>>>>> specific format for weewx to understand it no?
>>>>>>>
>>>>>>> So on the esp8266, that has a bunch of sensors attached to it, in my 
>>>>>>> embedded code i need to collect the data point for the sensor, and then 
>>>>>>> put 
>>>>>>> it in some specific format to send along somewhere that weewx will 
>>>>>>> read. 
>>>>>>> Reading through the source code it looked like the drivers are where 
>>>>>>> these 
>>>>>>> message formats are interrupted, but i could be wrong?
>>>>>>>
>>>>>>> On Monday 5 February 2024 at 23:45:25 UTC+10 p q wrote:
>>>>>>>
>>>>>>>> If I was going to do this, I would look into mqtt options. 
>>>>>>>>
>>>>>>>> On Sun, Feb 4, 2024, 11:03 PM 'Pavocracy' via weewx-user <
>>>>>>>> weewx...@googlegroups.com> wrote:
>>>>>>>>
>>>>>>>>> Hello all,
>>>>>>>>>
>>>>>>>>> I am working on a hobby project where i am trying to build my own 
>>>>>>>>> "weather station" from an esp8266 and a bunch of sensors. I am very 
>>>>>>>>> keen on 
>>>>>>>>> using weewx to display the post the data, and so i am looking at the 
>>>>>>>>> supported drivers and wondering if there is an obvious answer to 
>>>>>>>>> which 
>>>>>>>>> driver i should be targeting for my weather station output. 
>>>>>>>>>
>>>>>>>>> Is there an obvious choice for which driver supports the most 
>>>>>>>>> data, or perhaps is the easiest data to read or is there a driver 
>>>>>>>>> that is 
>>>>>>>>> the most robust? (particularly for serial connections)
>>>>>>>>>
>>>>>>>>> any thoughts or experience on the matter would be greatly 
>>>>>>>>> appreciated :) 
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> You received this message because you are subscribed to the Google 
>>>>>>>>> Groups "weewx-user" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>>>>>>> send an email to weewx-user+...@googlegroups.com.
>>>>>>>>> To view this discussion on the web visit 
>>>>>>>>> https://groups.google.com/d/msgid/weewx-user/831bd64d-0271-459c-9b52-929817b02319n%40googlegroups.com
>>>>>>>>>  
>>>>>>>>> <https://groups.google.com/d/msgid/weewx-user/831bd64d-0271-459c-9b52-929817b02319n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>> -- 
>>>>>> You received this message because you are subscribed to the Google 
>>>>>> Groups "weewx-user" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>>>> send an email to weewx-user+...@googlegroups.com.
>>>>>>
>>>>> To view this discussion on the web visit 
>>>>>> https://groups.google.com/d/msgid/weewx-user/f0733294-4828-4b22-941a-33de46a803fbn%40googlegroups.com
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/weewx-user/f0733294-4828-4b22-941a-33de46a803fbn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Peter Quinn
>>>>> (415)794-2264 <(415)%20794-2264>
>>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/a46a944f-3e4a-48a2-a632-616956d265d8n%40googlegroups.com.

Re: [weewx-user] Which driver should i target for my custom weather station?

['michael.k...@gmx.at' via weewx-user]

> So just to clarify, can weewx pull weather data from mqtt? 
Yes

> I dont see a driver for that.
MQTTSubscribe can be run as a driver, as already mentioned above:
*"Either MQTT Subscribe as a service, augmenting any off-the-shelf station 
supported by weewx with your sensors data, or use it as a driver."*
I even posted the link.

> but i cant find any documentation or examples of this kind of picture
It's behind the link above

> If thats only possible through third party extensions
If you don't want to use such extension, why would you use WeeWX in the 
first place?

> weather data collected by esp8266 ---> publish to mqtt (still isn't clear 
what kind of message structure i would need to follow for weewx to 
understand this)
It's described in behind the link above:
WeeWX-MQTTSubscribe

A Weewx service and driver that receives data from multiple MQTT topics.

Currently MQTT payloads of json, keyword (field1=value, field2=value..), 
and individual (each topic contains a single observation) are supported.

tl;dr; Click this link <https://github.com/bellrichm/WeeWX-MQTTSubscribe>, 
all your questions are answered there.

Pavocracy schrieb am Montag, 12. Februar 2024 um 07:58:33 UTC+1:

> So just to clarify, can weewx pull weather data from mqtt? I dont see a 
> driver for that. I can see there is community projects for enable both 
> subscribing to mqtt and also to publish to mqtt for data it already has in 
> its own database, but i cant find any documentation or examples of this 
> kind of picture:
>
> weather data collected by esp8266 ---> publish to mqtt (still isn't clear 
> what kind of message structure i would need to follow for weewx to 
> understand this) --> weewx subscribes to the mqtt messages and so can see 
> them and puts it into its own database
>
> If thats only possible through third party extensions, this leads me back 
> to instead wanting to just "emulate" a specific drivers data format to be 
> able to use the built in driver support instead. Because what i really want 
> is to really only have 2 pieces of the puzzle here. My esp8266 with sensors 
> attached, and in micropython i collect data points and put them into a data 
> structure directly understood by weewx, which then sends those messages to 
> a weewx instance running on a machine. But to do this, obviously i need to 
> understand the exact data structure of a given weewx driver, which is the 
> part i was asking about and can't easily find documented anywhere, i was 
> basically looking at the driver code and trying to see how it maps packet 
> data to weather data.
>
> On Tuesday 6 February 2024 at 23:28:05 UTC+10 p q wrote:
>
>> Yeah. I'm assuming you will be running Weewx on some computer other than 
>> the ESP and have a network connection between the ESP and the computer. I 
>> would use MQTT to publish the sensor data to a MQTT broker running 
>> somewhere on your network, likely Mosquitto running on the same machine as 
>> Weewx. Weewx would subscribe to the sensor data and go from there. I am not 
>> up on the Weewx MQTT driver, but I would look into using it. I personally 
>> use the Accurite driver as my original system is an Accurite. Over time as 
>> I've added new sensors or replaced crummy ones, I've started to use MQTT as 
>> my preferred method of sending data from microcontrollers to Weewx 
>> with various hacks on the Accurite driver.
>>
>> On Tue, Feb 6, 2024 at 2:51 AM 'michael.k...@gmx.at' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> A few thoughts:
>>>
>>> Building the "station" on a ESP8266 doesn't sound like you are planning 
>>> to get too far with your project. Compared to it's successor, it is very 
>>> limited and has some really weird flaws.
>>> Why would you connect the station with a serial interface, when it has 
>>> WIFI on board?
>>> p q's MQTT suggestion is a not a bad one. Let your station emit every 
>>> single sensor reading as a MQTT message, and let weewx receive it with MQTT 
>>> Subscribe <https://github.com/bellrichm/WeeWX-MQTTSubscribe>
>>> Either MQTT Subscribe as a service, augmenting any off-the-shelf station 
>>> supported by weewx with your sensors data, or use it as a driver. 
>>> Encapsulating sensor data in JSON for the MQTT payload is commonly done and 
>>> supported by MQTT Subscribe.
>>> Pavocracy schrieb am Dienstag, 6. Februar 2024 um 11:07:05 UTC+1:
>>>
>>>> I'm not sure if im misunderstanding what you are saying, or if i am not 
>>>> doing a good job at explaining my question, but e

Re: [weewx-user] Which driver should i target for my custom weather station?

['michael.k...@gmx.at' via weewx-user]

> So just to clarify, can weewx pull weather data from mqtt? 
Yes

> I dont see a driver for that.
MQTTSubscribe can be run as a driver, as already mentioned above:
*"Either MQTT Subscribe as a service, augmenting any off-the-shelf station 
supported by weewx with your sensors data, or use it as a driver."*
I even posted the link.

> but i cant find any documentation or examples of this kind of picture
It's behind the link above

> If thats only possible through third party extensions
I you don't want to use such extension, why would you use WeeWX in the 
first place?

> weather data collected by esp8266 ---> publish to mqtt (still isn't clear 
what kind of message structure i would need to follow for weewx to 
understand this)
It's described in behind the link above:
WeeWX-MQTTSubscribe

A Weewx service and driver that receives data from multiple MQTT topics.

Currently MQTT payloads of json, keyword (field1=value, field2=value..), 
and individual (each topic contains a single observation) are supported.

tl;dr; Click this link <https://github.com/bellrichm/WeeWX-MQTTSubscribe>, 
all your questions are answered there.

Pavocracy schrieb am Montag, 12. Februar 2024 um 07:58:33 UTC+1:

> So just to clarify, can weewx pull weather data from mqtt? I dont see a 
> driver for that. I can see there is community projects for enable both 
> subscribing to mqtt and also to publish to mqtt for data it already has in 
> its own database, but i cant find any documentation or examples of this 
> kind of picture:
>
> weather data collected by esp8266 ---> publish to mqtt (still isn't clear 
> what kind of message structure i would need to follow for weewx to 
> understand this) --> weewx subscribes to the mqtt messages and so can see 
> them and puts it into its own database
>
> If thats only possible through third party extensions, this leads me back 
> to instead wanting to just "emulate" a specific drivers data format to be 
> able to use the built in driver support instead. Because what i really want 
> is to really only have 2 pieces of the puzzle here. My esp8266 with sensors 
> attached, and in micropython i collect data points and put them into a data 
> structure directly understood by weewx, which then sends those messages to 
> a weewx instance running on a machine. But to do this, obviously i need to 
> understand the exact data structure of a given weewx driver, which is the 
> part i was asking about and can't easily find documented anywhere, i was 
> basically looking at the driver code and trying to see how it maps packet 
> data to weather data.
>
> On Tuesday 6 February 2024 at 23:28:05 UTC+10 p q wrote:
>
>> Yeah. I'm assuming you will be running Weewx on some computer other than 
>> the ESP and have a network connection between the ESP and the computer. I 
>> would use MQTT to publish the sensor data to a MQTT broker running 
>> somewhere on your network, likely Mosquitto running on the same machine as 
>> Weewx. Weewx would subscribe to the sensor data and go from there. I am not 
>> up on the Weewx MQTT driver, but I would look into using it. I personally 
>> use the Accurite driver as my original system is an Accurite. Over time as 
>> I've added new sensors or replaced crummy ones, I've started to use MQTT as 
>> my preferred method of sending data from microcontrollers to Weewx 
>> with various hacks on the Accurite driver.
>>
>> On Tue, Feb 6, 2024 at 2:51 AM 'michael.k...@gmx.at' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> A few thoughts:
>>>
>>> Building the "station" on a ESP8266 doesn't sound like you are planning 
>>> to get too far with your project. Compared to it's successor, it is very 
>>> limited and has some really weird flaws.
>>> Why would you connect the station with a serial interface, when it has 
>>> WIFI on board?
>>> p q's MQTT suggestion is a not a bad one. Let your station emit every 
>>> single sensor reading as a MQTT message, and let weewx receive it with MQTT 
>>> Subscribe <https://github.com/bellrichm/WeeWX-MQTTSubscribe>
>>> Either MQTT Subscribe as a service, augmenting any off-the-shelf station 
>>> supported by weewx with your sensors data, or use it as a driver. 
>>> Encapsulating sensor data in JSON for the MQTT payload is commonly done and 
>>> supported by MQTT Subscribe.
>>> Pavocracy schrieb am Dienstag, 6. Februar 2024 um 11:07:05 UTC+1:
>>>
>>>> I'm not sure if im misunderstanding what you are saying, or if i am not 
>>>> doing a good job at explaining my question, but e

Re: [weewx-user] Re: purge / clean mysql database?

['michael.k...@gmx.at' via weewx-user]

"reweight" was in the utils before 5.0. Of course, if you (as I do) very 
much value the precision of min/max values, you don't ever drop daily 
summaries unless it is really necessary, and even then only for the 
narrowest timespan necessary.

Min/Max values are from the LOOP, so any LOOP value leading to a min/max 
value has the timestamp of the LOOP packet in which it arrived, so this 
isn't anything related to Davis hardware, it depends on when the data 
arrives in the LOOP (if so).

Be even more paranoid than you seem to be concerning the database, I do 
hourly, daily, weekly and monthly backups and I run several weewx instances 
redundantly on independent hardware :D
Nate Bargmann schrieb am Montag, 12. Februar 2024 um 10:08:34 UTC+1:

> * On 2024 12 Feb 00:13 -0600, 'michael.k...@gmx.at' via weewx-user wrote:
> > Nate, this is 
> > what 
> https://weewx.com/docs/5.0/utilities/weectl-database/#recalculate-daily-summary-weights
>  
> > is for. Imagine you manipulate the database an know, the average of a 
> > certain type will change after that, the highs an lows aren't affected, 
> > e.g. you backfill a gap in the database for outTemp from another source, 
> > because your primary sensors battery was empty. Last good value was at 
> 8:00 
> > a.m., after the morning low, you've replaced the battery at 1 p.m., 
> before 
> > the afternoon high. After you've replaced the values in the database, 
> you 
> > run "reweight" for that day, you highs and lows will be untouched.
>
> Note that I am still on 4.10 and that I found what I stated occurred a
> couple of months ago before 5.0 was released. In this case the 4.10
> wee_database docs should be consulted.
>
> Try this on a copy of your DB:
>
> Drop the daily summaries.
> Rebuild the daily summaries.
> Compare.
>
> Again, perhaps this varies based on the backend, but with the Davis
> backend I saw that min/wax values logged between archive intervals were
> lost. Fortunately, wee_database has the capability to restore a single
> archive_day record if needed.
>
> I am very cautious working with the DB and do so on a copy if need be (I
> recently filled a bunch of locally missing data from before a Raspberry
> Pi crash in 2015 from Weather Underground. It worked very well). I
> also dump and back up the DB offsite every six hours.
>
> - Nate
>
> -- 
> "The optimist proclaims that we live in the best of all
> possible worlds. The pessimist fears this is true."
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>
>

-- 
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/73529a4c-d507-4664-ab45-bfe4dc9bd27an%40googlegroups.com.

Re: [weewx-user] Re: purge / clean mysql database?

['michael.k...@gmx.at' via weewx-user]

Nate, this is 
what 
https://weewx.com/docs/5.0/utilities/weectl-database/#recalculate-daily-summary-weights
 
is for. Imagine you manipulate the database an know, the average of a 
certain type will change after that, the highs an lows aren't affected, 
e.g. you backfill a gap in the database for outTemp from another source, 
because your primary sensors battery was empty. Last good value was at 8:00 
a.m., after the morning low, you've replaced the battery at 1 p.m., before 
the afternoon high. After you've replaced the values in the database, you 
run "reweight" for that day, you highs and lows will be untouched.

Nate Bargmann schrieb am Sonntag, 11. Februar 2024 um 21:39:35 UTC+1:

> Be careful throwing away archive_day-* data!
>
> On my setup with the Davis driver min and max values often occur in
> between archive intervals. I found that those are lost if the daily
> summaries have to be rebuilt from the archive table. My archive
> interval is 5 minutes.
>
> I did some testing a couple of months back cleaning up some spurious
> solar sensor data that crept in from a failing ISS transmitter. In the
> process I rebuilt the daily summaries on a copy of the database and saw
> every daily summary min/max value was on the five minute mark. I knew a
> recent day had recorded a low, just briefly, at something like 24.4 and
> in the original DB was recorded at that value at the precise time but
> both values were lost in the regenerated daily summaries. I've become
> quite careful to not disturb the daily summaries after that.
>
> I think this should be prominently noted in the WeeWX documentation.
>
> In my DB I noticed that the dailies started recording this information
> when I switched to version 4.x in the first days of 2021. I don't
> recall if there was something done to the DB in that upgrade or not.
>
> - Nate
>
> -- 
> "The optimist proclaims that we live in the best of all
> possible worlds. The pessimist fears this is true."
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>
>

-- 
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/c38a6b00-64db-4bd4-ac63-37564a8135ebn%40googlegroups.com.

Re: [weewx-user] MQTTSubscribe and paho mqtt heads up

['michael.k...@gmx.at' via weewx-user]

It did a fresh pip install on bookworm and ran into this for weewx-mqtt. It 
will be an issue people ask about in the near future, that's for sure.

vince schrieb am Sonntag, 11. Februar 2024 um 20:32:48 UTC+1:

> No reason to upgrade if it works for you already and if there are no 
> security risks since then.
>
> To list all versions available "pip list paho-mqtt=="
> To install a specified version "pip install paho-mqtt==1.6.1"
>
> Or for apt...
>
> List all versions "apt-cache policy python3-paho-mqtt"
> Install one specified version "apt-get install python3-paho-mqtt=1.5.1-1"
>
>
> Note that for deb12 (raspi) the latest package is 1.5.1 which is a year 
> older than 1.6.1, so they're not upgrading either.
>
>
> On Sunday, February 11, 2024 at 11:27:54 AM UTC-8 Greg Troxel wrote:
>
>> vince  writes: 
>>
>> > Why not stick with 1.6.1 indefinitely and the matching version of the 
>> > extension and not sweat it ? 
>>
>> Because bugs are not going to be fixed, and packaging systems are going 
>> to have 2.0.0, and in general trying to stay in the past causes too much 
>> trouble eventually. The same reason weewx had to cope with python 
>> instead of just telling people to use 2.7 :) 
>>
>

-- 
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/1305fec1-cdb8-4ebd-8c67-0caede21e73dn%40googlegroups.com.

[weewx-user] Re: Noob Question

['michael.k...@gmx.at' via weewx-user]

Everything looks right to me, although I can't tell, because you didn't 
past the wind speed plot.
Nick Name schrieb am Sonntag, 11. Februar 2024 um 14:00:27 UTC+1:

> Following epic session finally have WeeWx up and running. Learned much & 
> happy with this software.
>
> Vanilla RaspberryPi -> Vantage Pro2 -> Clean install WeeWx, Zero 
> customisation.
>
> Have repeated above about three time too get here so have learned a bit 
> about the overall process.
>
> I have one tiny issue and I wonder if anyone has seen similar and could 
> offer pointer.
> Attached image is of wind graphs from current running setup.[image: 
> screenshot 2024-02-11 at 09.29.10.png]
> "Something" does not look right to me! This being a vanilla install I 
> thought I would ask before I get into ANY "investigation".
>
> Hope above makes sense.
> Thanks for any suggestions.
> Regards.
> Frank C.
>

-- 
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/a25f9968-844d-495f-88fa-a25dd724606fn%40googlegroups.com.

[weewx-user] Re: purge / clean mysql database?

['michael.k...@gmx.at' via weewx-user]

What's the problem with even millions of entries in the database?
The min/max values are stored in the corresponding archive_day_xxx-tables 
but derived from archive and (re)built from archive.

Mario Wesolek schrieb am Sonntag, 11. Februar 2024 um 12:03:00 UTC+1:

> hi there,
>
> i use weewx 5.0.2 with belchertown skin 1.3.1 with mysql database. over 
> the time there are tousends of entrys in the database. is there a good / 
> easy way to purge them without lost of alltime records statistik? i think 
> the min/max values came from table archives, so i can select them and 
> delete the other - so i think this is not a good way to do that like this. 
> does anybody knows a better way or is a tool for that job include?
>
> thank you
> mario
> dg1fi
>

-- 
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/8331ccd5-7783-45ff-9d09-69ba3a701876n%40googlegroups.com.

[weewx-user] paho-mqtt and weewx-mqtt: paho-mqtt-2.0.0 not compatible!

['michael.k...@gmx.at' via weewx-user]

WeeWX won't crash, but MQTT won't work: when using weewx-mqtt with 
paho-mqtt-2.0.0, it fails with:

Exception ignored in: 
Traceback (most recent call last):
  File 
"/home/michi/weewx-venv/lib/python3.11/site-packages/paho/mqtt/client.py", 
line 874, in __del__
self._reset_sockets()
  File 
"/home/michi/weewx-venv/lib/python3.11/site-packages/paho/mqtt/client.py", 
line 1133, in _reset_sockets
self._sock_close()
  File 
"/home/michi/weewx-venv/lib/python3.11/site-packages/paho/mqtt/client.py", 
line 1119, in _sock_close
if not self._sock:
   ^^
AttributeError: 'Client' object has no attribute '_sock'
Exception in thread MQTT:
Traceback (most recent call last):
  File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
self.run()
  File 
"/home/michi/weewx-venv/lib/python3.11/site-packages/weewx/restx.py", line 
357, in run
self.run_loop(_manager)
  File 
"/home/michi/weewx-venv/lib/python3.11/site-packages/weewx/restx.py", line 
384, in run_loop
self.process_record(_record, dbmanager)
  File "/home/michi/weewx-data/bin/user/mqtt.py", line 522, in 
process_record
self.get_mqtt_client()
  File "/home/michi/weewx-data/bin/user/mqtt.py", line 444, in 
get_mqtt_client
mc = mqtt.Client(client_id=client_id)
 
TypeError: Client.__init__() missing 1 required positional argument: 
'callback_api_version'

With pip, install paho-mqtt-1.6.1 as a workaround:

pip install paho-mqtt==1.6.1

-- 
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/741ccdcb-2c24-43a0-94c9-6b9ae203f129n%40googlegroups.com.

[weewx-user] Re: MQTT publish time after upgrade to weewx 5.0.1

['michael.k...@gmx.at' via weewx-user]

Seems like now weewx MQTT is emitting a message every time a LOOP packet 
arrives. Let me guess, you hardware is capable of measuring wind/gusts in a 
2.5s interval, maybe a Tempest?
I don't know why this has changed, does Belchertown let you set the 
interval? Usually you set this like described 
here: 
https://github.com/matthewwall/weewx-mqtt/blob/d1739f3d57f07f402ddd3c20ac10ad5f874be1e9/bin/user/mqtt.py#L33
Mario Wesolek schrieb am Freitag, 9. Februar 2024 um 12:07:05 UTC+1:

> After update to 5.0.1-4  the MQTT publish data every 2-5 seconds ... have 
> anyone an explanation or can tell me where i can setup the publish time?
>
> Feb  9 12:04:08 weewx chronyd[522]: Selected source 217.197.91.176 (
> de.pool.ntp.org)
> Feb  9 12:04:09 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:10 CET (1707476650)
> Feb  9 12:04:12 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:12 CET (1707476652)
> Feb  9 12:04:14 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:15 CET (1707476655)
> Feb  9 12:04:17 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:17 CET (1707476657)
> Feb  9 12:04:19 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:20 CET (1707476660)
> Feb  9 12:04:22 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:22 CET (1707476662)
> Feb  9 12:04:24 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:25 CET (1707476665)
> Feb  9 12:04:27 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:27 CET (1707476667)
> Feb  9 12:04:29 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:30 CET (1707476670)
> Feb  9 12:04:32 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:32 CET (1707476672)
> Feb  9 12:04:34 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:35 CET (1707476675)
> Feb  9 12:04:37 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:37 CET (1707476677)
> Feb  9 12:04:39 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:40 CET (1707476680)
> Feb  9 12:04:42 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:42 CET (1707476682)
> Feb  9 12:04:44 weewx weewxd[716]: INFO weewx.restx: MQTT: Published 
> record 2024-02-09 12:04:45 CET (1707476685)
>
> thank you very much!
> mario 
> dg1fi 
>
> Mario Wesolek schrieb am Dienstag, 6. Februar 2024 um 10:42:58 UTC+1:
>
>> hi there!
>>
>> i use weewx with belchertown skin and publish the data via mqtt. in 
>> versions < 5.0.1 mqtt publish the data to every full minute, like 10:01:00, 
>> 10:02:00 and so on... after upgrade the time is uneven, like:
>>
>> Feb  6 09:56:50 weewx weewxd[4654]: INFO weewx.restx: MQTT: Published 
>> record 2024-02-06 09:56:50 CET (1707209810)
>> Feb  6 09:57:50 weewx weewxd[4654]: INFO weewx.restx: MQTT: Published 
>> record 2024-02-06 09:57:50 CET (1707209870)
>> Feb  6 09:58:50 weewx weewxd[4654]: INFO weewx.restx: MQTT: Published 
>> record 2024-02-06 09:58:51 CET (1707209931)
>> Feb  6 09:59:50 weewx weewxd[4654]: INFO weewx.restx: MQTT: Published 
>> record 2024-02-06 09:59:51 CET (1707209991)
>> Feb  6 10:00:51 weewx weewxd[4654]: INFO weewx.restx: MQTT: Published 
>> record 2024-02-06 10:00:00 CET (170721)
>> Feb  6 10:00:51 weewx weewxd[4654]: INFO weewx.restx: MQTT: Published 
>> record 2024-02-06 10:00:52 CET (1707210052)
>>
>> this is not really a problem but i will understand the reason. have 
>> anybody a explanation? 
>>
>> thank you very much!
>> mario 
>>
>

-- 
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/5a259c50-9811-4c0a-a4ef-9fab88ca1361n%40googlegroups.com.

Re: [weewx-user] weewx v5.0.1 upgrade problem

['michael.k...@gmx.at' via weewx-user]

sudo apt install weewx=4.10.2
Stefan Gliessmann schrieb am Dienstag, 6. Februar 2024 um 13:02:38 UTC+1:

> I run weewx 4.10.2 on Ubuntu.
> I did an sudo apt update, too,  and weewx 5.x got installed.
> Since then, weewx is no longer running.
>
> How did you revert back to weewx 4.10.2? 
>
> TIA,
> Stefan
>
> On Tuesday, February 6, 2024 at 10:36:52 AM UTC+1 Stefanos Kalaitzis wrote:
>
>> I had the same error with sdr driver(weewx v5 )  running on debian 12 . 
>> The problem solved by making udev rules ... maybe you are in the same 
>> situation as i was. 
>>
>> Στις Τρί 6 Φεβ 2024, 11:29 ο χρήστης Mks Mk  έγραψε:
>>
>>> The system was running weewx v5.0.0 with no issue then we did the 
>>> upgrade to v5.0.1 (sudo apt update) and weewx failed to run.
>>> we downgraded weewx to v5.0.0 but it did not work this time, so we went 
>>> back to v4.10.2 and it run just fine.
>>> did the upgrade again and got the same error.so we are back to v4.10.2
>>> we tested the sdr hardware using rtl_433 and it is working fine.
>>> we are not sure of what to do next!
>>>
>>> log:
>>> weewxd[2386]: INFO __main__: Starting up weewx version 5.0.1
>>> weewxd[2386]: INFO weewx.engine: Using binding 'wx_binding' to database 
>>> 'weewx.sdb'
>>> weewxd[2386]: INFO weewx.manager: Starting backfill of daily summaries
>>> weewxd[2386]: INFO weewx.manager: Daily summaries up to date
>>> weewxd[2386]: INFO weewx.engine: Starting main packet loop.
>>> weewxd[2386]: ERROR user.sdr: rtl_433 version 23.11-41-g06b03b7a branch 
>>> master at 202402051043 inputs file rtl_tcp RTL-SDR
>>> weewxd[2386]: ERROR user.sdr: Use "-F log" if you want any messages, 
>>> warnings, and errors in the console.
>>> weewxd[2386]: ERROR user.sdr: usb_open error -3
>>> weewxd[2386]: ERROR user.sdr: Please fix the device permissions, e.g. by 
>>> installing the udev rules file rtl-sdr.rules
>>> weewxd[2386]: INFO weewx.engine: Main loop exiting. Shutting engine down.
>>> weewxd[2386]: INFO user.sdr: shutdown process rtl_433 -f 433.7M -s 1024k 
>>> -R 40
>>> weewxd[2386]: Exception in thread stdout-thread:
>>> weewxd[2386]: Traceback (most recent call last):
>>> weewxd[2386]:   File "/usr/lib/python3.9/threading.py", line 954, in 
>>> _bootstrap_inner
>>> weewxd[2386]: Exception in thread stderr-thread:
>>> weewxd[2386]: Traceback (most recent call last):
>>> weewxd[2386]:   File "/usr/lib/python3.9/threading.py", line 954, in 
>>> _bootstrap_inner
>>> weewxd[2386]: self.run()
>>> weewxd[2386]:   File "/etc/weewx/bin/user/sdr.py", line 197, in run
>>> weewxd[2386]: for line in iter(self._fd.readline, ''):
>>> weewxd[2386]: ValueError: PyMemoryView_FromBuffer(): info->buf must not 
>>> be NULL
>>> weewxd[2386]: self.run()
>>> weewxd[2386]:   File "/etc/weewx/bin/user/sdr.py", line 197, in run
>>> weewxd[2386]: for line in iter(self._fd.readline, ''):
>>> weewxd[2386]: ValueError: PyMemoryView_FromBuffer(): info->buf must not 
>>> be NULL
>>> weewxd[2386]: INFO user.sdr: shutdown complete
>>> weewxd[2386]: CRITICAL __main__: Caught WeeWxIOError: rtl_433 process is 
>>> not running
>>> weewxd[2386]: CRITICAL __main__:   Waiting 60.0 seconds then 
>>> retrying...
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/4c62d6c3-d690-49e8-8151-8b9af8dd5b43n%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/3eff3ae3-8343-437e-a259-ae24753baa61n%40googlegroups.com.

[weewx-user] Re: New User: First Problem

['michael.k...@gmx.at' via weewx-user]

The warning tells you: WeeWX is receiving 0.0 for "pressure". You say, "The 
hardware console is operating correctly as expected", so the problem is 
somewhere in between the hardware and the LOOP. It may be, that your 
hardware/driver combination doesn't supply a valid value for "pressure" (it 
should return "None" instead of "0.0" in this case), did you try 
"barometer" or "altimeter" instead? You can also check in your database, if 
there are values for these types. If so, take a look into this article 
, 
to make sure, you really use the correct type for your needs. Having only 
one out of the three "pressure", "altimeter" and "barometer", it should be 
possible to calculate the others, when you have the altitude, the 
temperature and humidity (or even something in addition to that).

Alan Salmon schrieb am Dienstag, 6. Februar 2024 um 12:48:48 UTC+1:

> Hello everyone.
>
> I installed weewx for the first time today on a Raspberry Pi Zero 2W, 
> using a Fine Offset 3081 station that I used for about 10 years until the 
> local cockatoos decided it would be fun to dismantle it!
>
> It came up on the second attempt after a few minor adjustments to the 
> config file, paths, etc. (I used the pip install method on Debian 11).
>
> The hardware console is operating correctly as expected, but weewx is 
> giving me the following error:
>
> Feb  6 22:26:01 bigfish-08 weewxd[1909]: WARNING weewx.qc: 2024-02-06 
> 22:26:02 AEDT (1707218762) LOOP value 'pressure' 0.0 outside limits (24.0, 
> 34.5)
>
> As the value displayed on the console (roughly) agrees with a BME680 I 
> have running, can anyone suggest where I should start trying to solve this?
>
> Note that I am configured for metric with barometric pressure in 
> hectopascals (hPa) which is currently just over 1010hPa, so I am at a bit 
> of a loss as to why it is showing '0.0' and where the range "24.0 to 34.5' 
> comes from.
>
> The error has been consistent for the 9 hours it has been running.
>
> Thanks for any advice you can offer.
>
>
>

-- 
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/31ad1404-a6ee-4245-868b-15f75bd7e73bn%40googlegroups.com.

Re: [weewx-user] Which driver should i target for my custom weather station?

['michael.k...@gmx.at' via weewx-user]

A few thoughts:

Building the "station" on a ESP8266 doesn't sound like you are planning to 
get too far with your project. Compared to it's successor, it is very 
limited and has some really weird flaws.
Why would you connect the station with a serial interface, when it has WIFI 
on board?
p q's MQTT suggestion is a not a bad one. Let your station emit every 
single sensor reading as a MQTT message, and let weewx receive it with MQTT 
Subscribe 
Either MQTT Subscribe as a service, augmenting any off-the-shelf station 
supported by weewx with your sensors data, or use it as a driver. 
Encapsulating sensor data in JSON for the MQTT payload is commonly done and 
supported by MQTT Subscribe.
Pavocracy schrieb am Dienstag, 6. Februar 2024 um 11:07:05 UTC+1:

> I'm not sure if im misunderstanding what you are saying, or if i am not 
> doing a good job at explaining my question, but even if i choose mqtt as my 
> location to push the data, the data still needs to be in some specific 
> format for weewx to understand it no?
>
> So on the esp8266, that has a bunch of sensors attached to it, in my 
> embedded code i need to collect the data point for the sensor, and then put 
> it in some specific format to send along somewhere that weewx will read. 
> Reading through the source code it looked like the drivers are where these 
> message formats are interrupted, but i could be wrong?
>
> On Monday 5 February 2024 at 23:45:25 UTC+10 p q wrote:
>
>> If I was going to do this, I would look into mqtt options. 
>>
>> On Sun, Feb 4, 2024, 11:03 PM 'Pavocracy' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> Hello all,
>>>
>>> I am working on a hobby project where i am trying to build my own 
>>> "weather station" from an esp8266 and a bunch of sensors. I am very keen on 
>>> using weewx to display the post the data, and so i am looking at the 
>>> supported drivers and wondering if there is an obvious answer to which 
>>> driver i should be targeting for my weather station output. 
>>>
>>> Is there an obvious choice for which driver supports the most data, or 
>>> perhaps is the easiest data to read or is there a driver that is the most 
>>> robust? (particularly for serial connections)
>>>
>>> any thoughts or experience on the matter would be greatly appreciated :) 
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/831bd64d-0271-459c-9b52-929817b02319n%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/f0733294-4828-4b22-941a-33de46a803fbn%40googlegroups.com.

[weewx-user] Re: Klimalogg driver fails after update to weewx 5.0.0.1

['michael.k...@gmx.at' via weewx-user]

So this is a package install? Did you do try restating already? A friend 
had the same error with a package install update 5.0.0 =>  5.0.1 on 
Raspberry Pi OS, but with the ws23xx driver. He restarted the OS, then it 
worked. Maybe restarting udev or another daemon is sufficient also, I don't 
know.

Marco Biner schrieb am Dienstag, 6. Februar 2024 um 09:40:51 UTC+1:

> Hello
> seems that I am one of the rare users of the kl.py application from 
> Matthew Wall.
> As google does not help me with a solution here my problem.
> After the last update of weewx to version 5.0.0.1 kl.py fails importing 
> the driver:
>
> the log file reports:
>
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO __main__: Initializing 
> weewxd version 5.0.1
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO __main__: Command line: 
> /usr/share/weewx/weewxd.py /etc/weewx/weewx.conf
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO __main__: Using Python 
> 3.9.2 (default, Feb 28 2021, 17:03:44) #012[GCC 10.2.1 20210110]
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO __main__: Located at 
> /usr/bin/python3
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO __main__: Platform 
> Linux-6.1.21-v8+-aarch64-with-glibc2.31
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO __main__: Locale: 
> 'en_US.UTF-8'
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO __main__: Entry path: 
> /usr/share/weewx/weewxd.py
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO __main__: WEEWX_ROOT: 
> /etc/weewx
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO __main__: Configuration 
> file: /etc/weewx/weewx.conf
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO __main__: User module: 
> /etc/weewx/bin/user
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO __main__: Debug: 1
> Feb  6 08:46:44 curlevon weewxd[3865888]: DEBUG __main__: Initializing 
> engine
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO weewx.engine: Loading 
> station type KlimaLogg (user.kl)
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO user.kl: driver version is 
> 1.4.2
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO user.kl: channel is 1
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO user.kl: frequency is EU
> Feb  6 08:46:44 curlevon weewxd[3865888]: DEBUG user.kl: using custom 
> sensor map
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO user.kl: sensor map is: 
> {'temp0': 'Temp0', 'humidity0': 'Humidity0', 'heatindex0': 'heatindex0', 
> 'dewpoint0': 'dewpoint0', 'temp1': 'Temp1', 'humidity1': 'Humidity1', 
> 'heatindex1': 'heatindex1', 'dewpoint1': 'dewpoint1', 'temp2': 'Temp2', 
> 'humidity2': 'Humidity2', 'heatindex2': 'heatindex2', 'dewpoint2': 
> 'dewpoint2', 'temp3': 'Temp3', 'humidity3': 'Humidity3', 'heatindex3': 
> 'heatindex3', 'dewpoint3': 'dewpoint3', 'temp4': 'Temp4', 'humidity4': 
> 'Humidity4', 'heatindex4': 'heatindex4', 'dewpoint4': 'dewpoint4', 'temp5': 
> 'Temp5', 'humidity5': 'Humidity5', 'temp6': 'Temp6', 'humidity6': 
> 'Humidity6', 'temp7': 'Temp7', 'humidity7': 'Humidity7', 'temp8': 'Temp8', 
> 'humidity8': 'Humidity8', 'rxCheckPercent': 'SignalQuality', 
> 'batteryStatus0': 'BatteryStatus0', 'batteryStatus1': 'BatteryStatus1', 
> 'batteryStatus2': 'BatteryStatus2', 'batteryStatus3': 'BatteryStatus3', 
> 'batteryStatus4': 'BatteryStatus4', 'batteryStatus5': 'BatteryStatus5', 
> 'batteryStatus6': 'BatteryStatus6', 'batteryStatus7': 'BatteryStatus7', 
> 'batteryStatus8': 'BatteryStatus8', 'Sensor1': 'Kollektor warm aus', 
> 'Sensor2': 'Kollektor kalt in', 'Sensor3': 'Speicher unten', 'Sensor4': 
> 'Waermepumpe Ruecklauf', 'Sensor5': 'Boiler warm aus', 'Sensor6': 'Boiler 
> kalt in', 'Sensor7': 'Speicher Mitte', 'Sensor8': 'Speicher oben', 
> 'Sensor9': 'Speicher Brauchwasser', 'Sensor10': 'Schacht', 'Sensor11': 
> 'Erdsonde 1', 'Sensor12': 'Erdsonde 2', 'Sensor13': 'Heizung Vorlauf', 
> 'Sensor14': 'Temperatur 5Zi Wohnug', 'Sensor15': 'Temperatur Aussen', 
> 'Sensor16': 'Warmwasser', 'Sensor17': 'Drehzahl Pumpe Brauchwasser'}
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO user.kl: catchup limited to 
> 51200 records
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO user.kl: timing is 300 ms 
> (0.300 s)
> Feb  6 08:46:44 curlevon weewxd[3865888]: DEBUG user.kl: 
> CommunicationService.init
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO user.kl: comm_interval is 8
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO user.kl: logger_channel is 1
> Feb  6 08:46:44 curlevon weewxd[3865888]: INFO user.kl: found transceiver 
> at bus= device=
> Feb  6 08:46:44 curlevon weewxd[3865888]: ERROR weewx.engine: Import of 
> driver failed: The device has no langid ()
> Feb  6 08:46:44 curlevon weewxd[3865888]: CRITICAL weewx.engine:  
>  Traceback (most recent call last):
> Feb  6 08:46:44 curlevon weewxd[3865888]: CRITICAL weewx.engine:  
>File "/usr/share/weewx/weewx/engine.py", line 115, in setupStation
> Feb  6 08:46:44 curlevon weewxd[3865888]: CRITICAL weewx.engine:  
>  self.console = loader_function(config_dict, self)
> Feb  6 08:46:44 c

[weewx-user] Re: I can't install weewx

['michael.k...@gmx.at' via weewx-user]

What can you do?

   - You can search the forums, you're not the first one having the issue. 
   I did that for 
   you: https://groups.google.com/g/weewx-user/search?q=ED444FCCF0E2B09E
   - You can install weewx the "pip and venv" way, and you won't encounter 
   the issue: https://www.weewx.com/docs/5.0/quickstarts/pip/

I'd go for the latter.

Florian Weber schrieb am Montag, 5. Februar 2024 um 20:08:24 UTC+1:

> What can I do. I made all steps from the quickguide, but I got a problem 
> with a signatures.
>
> Hit:1 http://deb.debian.org/debian bookworm InRelease 
>  
> Hit:2 http://security.debian.org/debian-security bookworm-security 
> InRelease  
> Hit:3 http://deb.debian.org/debian bookworm-updates InRelease
> Get:4 https://weewx.com/apt/python3 buster InRelease [3,614 B]
> Err:4 https://weewx.com/apt/python3 buster InRelease
>   The following signatures couldn't be verified because the public key is 
> not available: NO_PUBKEY ED444FCCF0E2B09E
> Reading package lists... Done
> W: GPG error: https://weewx.com/apt/python3 buster InRelease: The 
> following signatures couldn't be verified because the public key is not 
> available: NO_PUBKEY ED444FCCF0E2B09E
> E: The repository 'https://weewx.com/apt/python3 buster InRelease' is not 
> signed.
> N: Updating from such a repository can't be done securely, and is 
> therefore disabled by default.
> N: See apt-secure(8) manpage for repository creation and user 
> configuration details.
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> E: Unable to locate package weewx
>
>
> I hope somebody can help me.
>

-- 
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/242d8ebe-ef89-4eab-80e5-779799af7b50n%40googlegroups.com.