[weewx-user] $archive[1].wind.gustdir.format: N/A

Since update to version 4.2.0, I have a curious result in season skin. Although $current.windDir is properly displayed and continuously collected, there are no longer windDir data in the hi/lo section. Wind Max shows speed correctly, but no direction. I checked hilo.inc. There are no changes, c

Re: [weewx-user] $archive[1].wind.gustdir.format: N/A

chive/weewx.sdb. > > *sqlite3 /var/lib/weewx/weewx.sdb* > sqlite> *select datetime(dateTime, 'unixepoch', 'localtime'), * from > archive_day_wind order by dateTime desc limit 20;* > sqlite> *.quit* > > -tk > > On Tue, Dec 8, 2020 at 8:15 AM

Re: [weewx-user] $archive[1].wind.gustdir.format: N/A

> 2. What is your setting for option ignore_zero_wind, if any? > 3. What is your setting for option record_generation? > > -tk > > > On Tue, Dec 8, 2020 at 8:44 AM Vetti52 wrote: > >> It says "N/A". >> >> The output of sqlite: >> >

Re: [weewx-user] $archive[1].wind.gustdir.format: N/A

020-12-04 22:00:00 101.0 Vetti52 schrieb am Dienstag, 8. Dezember 2020 um 19:33:13 UTC+1: > tha update was on 2020-12-04, right. > > at 1. > I am running Weewx on a Raspi4 under buster, installed with apt-get > install weewx. My station is a EFWS2500, which is a clone of Ecowitt

Re: [weewx-user] $archive[1].wind.gustdir.format: N/A

So, I am still not sure, if wee_database --update or --reweight should solve the problem. Or do I have to wait for a special fix? Vetti52 schrieb am Dienstag, 8. Dezember 2020 um 21:01:56 UTC+1: > BTW, there are some values not null in the database after update, as seen, > when filteri

Re: [weewx-user] $archive[1].wind.gustdir.format: N/A

> Does the driver emit windGustDir on every LOOP packet? Or, does it rely on > software record generation to provide it at the end of an archive period? > > Sorry I cannot be of more help. > > -tk > > On Thu, Dec 10, 2020 at 11:29 AM Vetti52 wrote: > >> So, I am

Re: [weewx-user] $archive[1].wind.gustdir.format: N/A

sr/share/weewx/weewx/accum.py. > > Set debug=1, restart weewx, then let it run through the first reporting > cycle. Post the log. > > -tk > > On Sat, Dec 12, 2020 at 9:33 AM Vetti52 wrote: > >> Here a comparison of three outputs, first as GW1000.service , then as >&g

Re: [weewx-user] $archive[1].wind.gustdir.format: N/A

Just to complete the log file, I restarted again using GW1000 driver, which I would like to use, as sson as the missing . Looks different. HTH --ph Vetti52 schrieb am Sonntag, 13. Dezember 2020 um 15:27:27 UTC+1: > Here is the result > > Thanks > -ph > > BTW, I had a look

Re: [weewx-user] $archive[1].wind.gustdir.format: N/A

e you let it run through the first reporting cycle. In your first > run, you stopped it a bit too early. > > -tk > > On Sun, Dec 13, 2020 at 6:42 AM Vetti52 wrote: > >> Just to complete the log file, I restarted again using GW1000 driver, >> which I would like to use

Re: [weewx-user] $archive[1].wind.gustdir.format: N/A

ok, here we are: tke...@gmail.com schrieb am Sonntag, 13. Dezember 2020 um 19:10:51 UTC+1: > I see the problem. It's a subtle bug. Try this version of accum.py. > > -tk > > On Sun, Dec 13, 2020 at 9:43 AM Vetti52 wrote: > >> ok, this time, I think,

Re: [weewx-user] $archive[1].wind.gustdir.format: N/A

e data. The GW1000 is capable of > operating with many sensors. These sensors are individual powered and the > GW1000 can provide battery state data for each sensor. In such a situation > the use of the general txBatteryStatus would be confusing (what sensor > does it refer to?).

Re: [weewx-user] $archive[1].wind.gustdir.format: N/A

> > On Sun, Dec 13, 2020 at 1:24 PM Vetti52 wrote: > >> ok, here we are: >> >> >> tke...@gmail.com schrieb am Sonntag, 13. Dezember 2020 um 19:10:51 UTC+1: >> >>> I see the problem. It's a subtle bug. Try this version of accum.py. >>&g

Re: [weewx-user] $archive[1].wind.gustdir.format: N/A

> wrote: > >> Yes I did. >> >> On Sunday, December 13, 2020 at 4:01:37 PM UTC-7 tke...@gmail.com wrote: >> >>> pmcgeorge: I take it that you swapped out your version of accum.py for >>> the one I posted? >>> >>> Vetti52: The new ver

[weewx-user] yet another question to GW1000 api driver mapping

Well, I started this conversation already at another thread (https://groups.google.com/g/weewx-user/c/ua0JjTp1DW8/m/AFGZf7AyAgAJ), concerning wind.gust.dir in version 4.2.0. As TK managed to solve the main problem, there is still the other part unsolved. So, I want to move this topic into a new

[weewx-user] Re: yet another question to GW1000 api driver mapping

g, 15. Dezember 2020 um 23:51:10 UTC+1: > Some comments below. Hopefully it gives you a process to work through to > identify your problem. > > Gary > > On Wednesday, 16 December 2020 at 06:37:40 UTC+10 Vetti52 wrote: > >> Well, I started this conversation alre

[weewx-user] Re: yet another question to GW1000 api driver mapping

I must admit, that I do not understand, what I am doing. This python coils. Vetti52 schrieb am Mittwoch, 16. Dezember 2020 um 14:18:26 UTC+1: > Thanks, Gary, for your polite explanations. > Since I have read some of your comments with equal advices in other > threads, I proceeded a

[weewx-user] Re: yet another question to GW1000 api driver mapping

16 December 2020 at 23:18:26 UTC+10 Vetti52 wrote: > >> Thanks, Gary, for your polite explanations. >> Since I have read some of your comments with equal advices in other >> threads, I proceeded already to sucessfully map the fields. Otherwise I did >> not even had an

[weewx-user] Re: yet another question to GW1000 api driver mapping

Typo: $get_battery_status($current.wh65_battery.raw), of course with closed brakets Vetti52 schrieb am Donnerstag, 17. Dezember 2020 um 11:01:26 UTC+1: > Ok, I added the entries into accumulator. So, this part is completed now. > But still the battery value is missing. > > The

[weewx-user] Re: yet another question to GW1000 api driver mapping

t;Voltage", because that is included in the template. > [[Generic]] > wh65_battery = WH65 >... > > Gary > > > > On Thursday, 17 December 2020 at 20:09:18 UTC+10 Vetti52 wrote: > >> Typo: $get_battery_status($current.wh65_battery.raw), of c

[weewx-user] Re: yet another question to GW1000 api driver mapping

1652, yearRain: > 29.17716535433071 > > The field name is wh65_battery not wh_65battery. Anywhere you use $day or > $current to access the WH65 battery state you need to be using > $day.wh65_battery or $current.wh65_battery. > > Gary > > On Thursday, 17 December 2020 at 22:38:5

[weewx-user] Re: yet another question to GW1000 api driver mapping

e > Customization Guide. > > Gary > > On Friday, 18 December 2020 at 19:30:22 UTC+10 Vetti52 wrote: > >> Thanks, Gary. The typo was here, not in seasons.inc. But I had another >> assumption: When displaying the values $current.txBatteryStatus.raw and >> $current.

Re: [weewx-user] Version 4.4.0

Just upgraded from 4.4.3 to 4.4.0, but it fails. got this in systemctl status weewx.service: Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine: debug_wind=self.debug_wind) Feb 03 16:44:25 RaspBee python3[629]: weewx[629] CRITICAL weewx.engine: File "

Re: [weewx-user] Version 4.4.0

Typo: Upgrade from 4.3.0 to 4.4.0. Version 4.3.0 had no issues so far. Vetti52 schrieb am Mittwoch, 3. Februar 2021 um 18:17:46 UTC+1: > Just upgraded from 4.4.3 to 4.4.0, but it fails. > got this in systemctl status weewx.service: > Feb 03 16:44:25 RaspBee python3[629]: weewx[629]

Re: [weewx-user] Version 4.4.0

just to narrow down my problem: When starting manually weewxd /etc/weewx/weewx.conf it works. Starting with systemctl start weewx, it fails. Maybe, I will find out, what makes the difference. But, just in case, someone knows the trick, please tell! Thanks -Peter Vetti52 schrieb am Mittwoch

Re: [weewx-user] Version 4.4.0

ould be another thread, I think. Thanks Peter gjr80 schrieb am Mittwoch, 3. Februar 2021 um 20:33:21 UTC+1: > Ok, can you please set debug=1, restart WeeWX as a daemon and post in a > new thread the log through until the failure occurs. > > Gary > > On Thursday, 4 February 2021 a

[weewx-user] Suggestion to weewx after booting with gw1000 driver

My Weewx installation was updated to version 4.4.0 using sudo apt-get update sudo apt-get install weewx under debian buster on a Raspberry Pi 4. The driver is gw1000 version 0.2.0. After rebooting my Raspberry Pi (this happens only about once or twice a year), I realized, that weewx was not ru

[weewx-user] Re: Suggestion to weewx after booting with gw1000 driver

Thanks for the comments. I checked weewx.conf for all "loop" entries, no loop_on_init exists. So, by default, is it set to false? Shouldn't it be generally enabled for gw1000 driver? I wonder, why weewx could not be started after exiting. To me, this indicates, that it was in fact still runnin

[weewx-user] Re: Suggestion to weewx after booting with gw1000 driver

l work as well. We will see, if all works, when I need to reboot again. In a year, or so... -Peter gjr80 schrieb am Dienstag, 9. Februar 2021 um 05:40:14 UTC+1: > Peter, > > Some comments below. > > Gary > > On Tuesday, 9 February 2021 at 06:40:28 UTC+10 Vetti52 wrote: > >

[weewx-user] Re: Suggestion to weewx after booting with gw1000 driver

ffect, but using the init.d script. And, in addition, it prevents some problems with upgrading weewx (depending on systemd using weewx.service?). -Peter gjr80 schrieb am Dienstag, 9. Februar 2021 um 20:42:42 UTC+1: > On Tuesday, 9 February 2021 at 23:56:24 UTC+10 Vetti52 wrote: > >&g

Re: [weewx-user] Re: weewx server?

Well, the original question was, how to see weewx from a public ip. I must confess, that I did not think about security issues and just did it this way: I used a IPv6 only DNS from dynv6.com. So I could readily access http://raspbee.example.dynv6.net:8000/weewx/index.html from outside. So far,

Re: [weewx-user] YEAR Tab graph dates

I just tried this little trick with month_images too and changed it to %d.%m. And, yes, after restarting weewx, it worked! Nice!!! However, year_images was not changed. There is a little typo in Rick's post, needs to be %y instead of y%. But, still no success. So, I had a look into the web sit

Re: [weewx-user] Re: Volunteer translators needed!

I found an entry in skin.conf missing in en.conf: For German: [HistoryReport] monthnames = Jan, Feb, Mar, Apr, Mai, Jun, Jul, Aug, Sep, Okt, Nov, Dez and some translations for Beaufort as text version would also be helpful. Here is my german version, used in current.inc: #if $varExists('day.w

Re: [weewx-user] Re: Volunteer translators needed!

t; And, I agree, converting a skin is a right pain. > > On Tue, May 18, 2021 at 7:38 AM Vetti52 wrote: > >> I found an entry in skin.conf missing in en.conf: >> For German: >> [HistoryReport] >> monthnames = Jan, Feb, Mar, Apr, Mai, Jun, Jul, Aug, Sep, Okt,

Re: [weewx-user] Translation into german

I used the term "windchill" also, because there is no equivalent in german. The term "Gefühlte Temperatur" would include heat index and wind chill as well. For Weewx there are two separate equations, as Tom Keffer described here: https://github.com/weewx/weewx/wiki/Wind-chill-and-heat-index. Ac

Re: [weewx-user] New Google Groups User Interface - Tested

the most annoying thing is, that whenever I log in, I am driven to the new interface and have to switch back to the good old one. And everytime, the new version starts, an error message about server failure pops up. So, my advice it to even not try to use it! And Emacs would be worth to look at,

[weewx-user] Re: weather forecast inside the weewx standard skin seasons

Same question to me! Although, I think, that the forecast extension from https://github.com/chaunceygardiner/weewx-forecast currently is the most promi

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

Finally, I managed to install the latest release also. I used WU Api key and it works nicely. I find it much easier to integrate it into the season skin as a wiget than as iframe. I do not get iframes sized correctly for tablet or smartphone displays. The wigeds look much better. And, as the fo

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

Well, I took forecast-table.inc for my Weewx site now. There is no dew point column, although it is set to #set $forecast_source = 'WU', and the inc file includes #set $show_dewpoint = int($local_settings.get('show_dewpoint', $show_dewpoint)) The dew point column shows only in the multiple-tabl

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

go searching that much of what is in this file is > not defined anywhere. If you do find something definitive, please let me > know. You can start here: > > > https://docs.google.com/document/d/1_Zte7-SdOjnzBttb1-Y9e0Wgl0_3tah9dSwXUyEA3-c/edit > > I am very interested

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

hemerial data for today differ somewhat. The forecast data read for today 25%, celestial data read 28%. Why? Anyway, almost everything (except of the clouds) is fine now, even, as I do not understand much of what I did. Vetti52 schrieb am Sonntag, 23. August 2020 um 10:24:18 UTC+2: > To inacti

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

urs). > > Try this to get get forecasts twice as often as the default: > > [[WU]] >api_key = X >interval = 900 > > On Aug 23, 2020, at 1:24 AM, Vetti52 wrote: > > >  > > To inactivate dewpoint, I thought to delete (or comment out)

[weewx-user] Zambretti translation

Some time ago, I was wondering about the nice and colorful forecasting pictures on my weather station, and how to get the corresponding data downloaded. Since I have recently installed the Weewx forecast module, I have concluded, that these pictures may be graphical interpretations of Zambre

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

&apiKey=d8e258b8a134405ba258b8a134805b1e> > > Let me know if you think something in the WU forecast returned from the > above URL is amiss in the forecast extension. Note: there is plenty in > what WU sends that has no place in the forecast extension schema. > > > On

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

in the cases you mention? > > The choices are: > 'CL': 'Clear', > 'FW': 'Few Clouds', > 'SC': 'Scattered Clouds', > 'BK': 'Broken Clouds', > 'B1': 'Mostly Cloudy', > '

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

11 9 11 10 11 11 11 wxPhraseShort 0 "Showers" 1 "P Cloudy" 2 "PM Lgt Rain" 3 "Rain" 4 "Rain" 5 "Rain Early" 6 "P Cloudy" 7 "Shwrs Late" 8 "Showers" 9 "Showers" 10 "Showers" 11 "Showers

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

07:00 18,9°C Considerable Cloudiness Issued at 24-Aug-2020 09:20 for geocode=54.09,10.26 To my intension, every line should end with a description, such as 'Mostly cloudy'. Well, actually I miss 'Clear', but this is, due to the current weather situtation, not an option.

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

them (as was done by the author of the post you provided). I note that > these extra icons were not generated for the prior WU daily forecast. Let > me think about whether or not I want to add that functionality. > > On Aug 24, 2020, at 3:36 AM, Vetti52 wrote: > >  >

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

frzngdrzl, frzngrain, > flurries. > > On Aug 25, 2020, at 4:03 AM, Vetti52 wrote: > >  > > > ok, I was thinking of keep it simple. So the correlation of iconCode to > one icon each looked straight forward to me. Probably you can see, what I > mean in the attache

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

differences in time, but the forecast seems to be the same. And, there is some rain outside jo...@johnkline.com schrieb am Dienstag, 25. August 2020 um 17:52:08 UTC+2: > Can you state with certainty that you waited for a new WU forecast to be > downloaded? > > On Aug 25, 2020, at 8:32

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

ohn Kline wrote: > >  > Please point me to a exactly one specific thing you think is not correct. > I’m not suggesting you are wrong, but I’m very busy (I have a real job) > and that will help me quickly find the issue. Also, please send your lat > long. > > On Aug

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

ork is planned to go out of existence once Matthew updates his code for > WeeWX 4. > > On Aug 26, 2020, at 3:37 AM, Vetti52 wrote: > >  > > When looking at single-strip.html from the sampler, there are only the > cloud icons, but no precipitation icons. So it is not completely

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

e at sailing.mit.edu, as linked above. I am happy with that result for forecast_table.inc now. We could let Matthews work on the rest, for my opinion. And there is more time for hard real time jobs... And I have learned a little bit about python. Just a tiny little bit Vetti52 schrieb am

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

; push that. > > > On Aug 26, 2020, at 11:38 AM, Vetti52 wrote: > >  > > And, I just modified forecast.py at line 2563, and changed "0" to "20": > > if precip_chance > 20 and (precip_type == 'rain' or precip_type == > 'snow&#

Re: [weewx-user] Re: weather forecast inside the weewx standard skin seasons

right border. I would therefore prefer to omit the seconds in sun and moon columns. Or create a separate mobile skin. Vetti52 schrieb am Donnerstag, 27. August 2020 um 14:57:21 UTC+2: > Well, at least it looks pretty same with WU forecasts now. > And, yes, there are still some co

Re: [weewx-user] GW1000 firmware update v1.6.2

Although I tried to cancel the update, all the rain data were already lost. So I continued the update, and "recreated" the rain data from the data collected in Weewx. The barometric calibration was also gone. Fortunately, I have my data saved in a spreadsheet, which calculates them for me (see

Re: [weewx-user] Register your WeeWX station!

just registered today, due to the advise in this thread. However there is no map entry. I get this log: Oct 5 21:00:30 raspbee weewx[10983] ERROR weewx.restx: StationRegistry: Failed to publish record 2020-10-05 21:00:00 CEST (1601924400): Failed upload after 3 tries I am using Weewx 4.1.1. M

Re: [weewx-user] Register your WeeWX station!

m/station/pws-f069b42a, without any quotes. > > -tk > > On Mon, Oct 5, 2020 at 12:21 PM Vetti52 wrote: > >> just registered today, due to the advise in this thread. However there is >> no map entry. I get this log: >> >> Oct 5 21:00:30 raspbee weewx[10983] ERRO

Re: [weewx-user] Register your WeeWX station!

this satisfy as source for a preview picture? Vetti52 schrieb am Dienstag, 6. Oktober 2020 um 10:49:19 UTC+2: > That's it! > thanks > > tke...@gmail.com schrieb am Montag, 5. Oktober 2020 um 23:26:19 UTC+2: > >> I'm seeing an error on the server end: "station_

Re: [weewx-user] Register your WeeWX station!

Just a cosmetic proposal: If there is no preview image, just omit the "cracked" image in the preview. BTW, in my view of weewx.com/stations.html neither right- nor middle-button click does anything. I use Win10/Firefox81.0.1. How is it intended to work properly? To open a link in a new tab, I

Re: [weewx-user] Register your WeeWX station!

westwards from their origin (supposed to stay in UT, TN, CO, and others). Is there any supervision? Am Donnerstag, 8. Oktober 2020 16:42:02 UTC+2 schrieb vince: > > On Thursday, October 8, 2020 at 6:58:15 AM UTC-7, Vetti52 wrote: >> >> Just a cosmetic proposal: If there is no previe

Re: [weewx-user] Re: Added All-time graphs to Seasons Skin, how to share?

Still staying with Weewx version 4.1.1, the installation worked smart. Great job! In addition I had to integrate it into my personal seasons skin, which I had translated into German. Unfortunately there is still no general structure in WeeWx for labelling in different languages. So it still was

[weewx-user] simple python question, while adopting current.inc

After upgrading to Weewx version 4.2.0 I want to replace the deprecated type Beaufort by the new unit $current.windSpeed.beaufort. First, I replaced the previous evaluation in my accomodated current.inc, where I want to express the beaufort value by a literal description: #if $varExists('day.win

Re: [weewx-user] simple python question, while adopting current.inc

rrent_beaufort = 'N/A' > #end if > > You should be able to do $current.windGust.beaufort as well. However, > oceanographically, Beaufort's observations are related to the steady wind > speed, not gusts, so the results cannot be related to sea state through his > t

Re: [weewx-user] simple python question, while adopting current.inc

; #else > #set $word_current_beaufort = 'N/A' > #end if > On Thu, Dec 3, 2020 at 9:35 AM Vetti52 wrote: > >> I tried the integer version already, with the same result. So, I assumed, >> that Beaufort is a string. Still no success. >> At least current.wi

[weewx-user] weewx.service fails at reboot

After upgrading to version 5.0.0, I can regularily observe, that starting Weewx sudo sdystemctl status weewx.service fails because of network error. My setup is a Rasperry Pi4 under a freshly installed bookworm. I installed the apt package as described in the guide, immediately stopped Weewx an

[weewx-user] Re: weewx.service fails at reboot

> no battery backed realtime clock so weewx might be waiting for your pi to > get accurate network time. > > On Thursday, February 1, 2024 at 1:27:26 PM UTC-8 Vetti52 wrote: > >> After upgrading to version 5.0.0, I can regularily observe, that starting >> Weewx su

[weewx-user] Re: weewx.service fails at reboot

Oops, the log entry is missing: It should read sudo journalctl -xeu weewx.service ... raspbee weewxd.py[1316]: historygenerator.py: Generated 5 tables in 0.15 seconds every five minutes. Nothing else. Thanks Peter Vetti52 schrieb am Freitag, 2. Februar 2024 um 22:19:25 UTC+1: > Well, th

[weewx-user] Re: weewx.service fails at reboot

won't help Thanks Peter Vetti52 schrieb am Freitag, 2. Februar 2024 um 22:24:17 UTC+1: > Oops, the log entry is missing: It should read > sudo journalctl -xeu weewx.service > ... > raspbee weewxd.py[1316]: historygenerator.py: Generated 5 tables in 0.15 > seconds &g

[weewx-user] Re: weewx.service fails at reboot

I have detected, that I was messed up with the way, I updated from Weewx version 4.10. to 5.0. But, I prefer to put this update topic into a separate thread Peter Vetti52 schrieb am Freitag, 2. Februar 2024 um 22:39:06 UTC+1: > Hi, Vince! > > To complete the questions: The pi is LAN c

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

After updating to from v5.0.0 to v5-0.1I got this log entry: Feb 05 14:59:07 raspbee systemd[1]: weewx.service: Deactivated successfully. Feb 05 14:59:07 raspbee systemd[1]: Stopped weewx.service - WeeWX. Feb 05 14:59:07 raspbee systemd[1]: weewx.service: Consumed 27min 28.104s CPU time. Feb 05 14

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

group is weewx running as? That user needs > correct permissions to be able to access your attached hardware. My guess > is that you need to add the weewx user to the same groups the default pi > user is in. > On Thursday, February 8, 2024 at 1:57:38 PM UTC-8 Vetti52 wrote: > >> Afte

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

4 um 18:22:37 UTC+1: > If you do not need gpio for weewx, do not install anything related to gpio > in your weewx.conf file. Seems pretty simple to me. > > On Friday, February 9, 2024 at 3:47:59 AM UTC-8 Vetti52 wrote: > >> Concerning my v4 update process I should add some cla

[weewx-user] Re: import weewx data from mqtt to home assistant.

It is easier to keep the mqtt data in a separate file. So just add in your configuration.yaml the line mqtt: !include mqtt.yaml and create a separate mqtt.yaml file containing the data, you have exported from weewx into your mqtt broker. My mqtt.yaml looks like (be careful with the indentations!

[weewx-user] Re: import weewx data from mqtt to home assistant.

t; frontend: >> themes: !include_dir_merge_named themes >> >> automation: !include automations.yaml >> script: !include scripts.yaml >> scene: !include scenes.yaml >> >> http: >> ssl_certificate: /ssl/fullchain.pem >> ssl_key: /ssl/privkey.pem

[weewx-user] Re: import weewx data from mqtt to home assistant.

; acl_file /etc/mosquitto/acl > [image: Screenshot 2024-02-10 alle 08.21.14.png] > > Before writing here, I also followed the instructions in this post but > without success > community.home-assistant.io/t/weewx-mqtt-and-how-to-import-data/212344 > > Il giorno sabato 10 febb

[weewx-user] Update to 4.10

According to the upgrade guide, the format of the delta time string, such as in celestial,inc should read, which does result in the correct long_form, but after the new line the text is shown as „$sun_visible_change….“ istead of it‘S value. What did I miss here? $gettext("Total daylight") $alman

Re: [weewx-user] Update to 4.10

e in daylight, pick a string to indicate whether it is > more or > ## less than yesterday: > #set $sun_visible_change = $almanac.sun.visible_change > #if $sun_visible_change.raw < 0 > #set $change_str = $gettext("less than yesterday") > #else > #se

Re: [weewx-user] Update to 4.10

it? > > On Sun, Jul 2, 2023 at 12:22 PM Vetti52 wrote: > >> Of course ephem is installed, thanks. And, yes, you are right with your >> conclusion. So I am missing $sun_visible_change. >> My top of celestical.inc looks like: >> ## If extended almanac information

Re: [weewx-user] Update to 4.10

out celestial.inc with the current version > <https://raw.githubusercontent.com/weewx/weewx/master/skins/Seasons/celestial.inc>, > > then editing as necessary. > > On Sun, Jul 2, 2023 at 2:49 PM Vetti52 wrote: > >> Well, alltimeSeasons was not changed

[weewx-user] Re: Interceptor and WH57 Lightning sensor from Ecowitt

Am Saturday, 6. June 2020 11:48:05 UTC+2 NanoG5Kite wrote: > > > > > https://github.com/matthewwall/weewx-interceptor/pull/64/commits/00bdecdc1822d7deaa7c41f20dfc4c30a349936d > > > >

Re: [weewx-user] Almanac Extras....

The other way roundin my case. After upgrading to 4.1.1, and moving from python2 to python3 celestial data fail. It contains this instead: Install *pyephem* for detailed celestial timings. And *python3 -c "import ephem"* returns nothing. And when I run "sudo wee_reports /etc/weewx/weewx.conf"

Re: [weewx-user] Almanac Extras....

on't quite understand the question. What do you mean by the "next html > update"? The utility wee_reports runs only once. > > Or, are you saying that wee_reports works as expected, but weewxd does not? > > Also, you have not posted a log, so it's hard to draw any c

[weewx-user] StdWXCalculate: beaufort = prefer_hardware

Hi you Weewx experts! first I would like to say, that my station ( a WS2900 clone) is not that sophisticated, especially concerning wind speed and direction. There are many tall trees around, being closer than their 10fold height, so that the wind is often much smoother and more disturbed than

Re: [weewx-user] StdWXCalculate: beaufort = prefer_hardware

On, July 8th 2020 18:25:06 UTC+2 Tom Keffer wrote: > > Beaufort is treated as a separate observation type, not an alternative > unit. So, you should be able to use it like any other type. For example, > > The current wind speed is $current.windSpeed, which is beaufort > $current.beaufort. > >

Re: [weewx-user] StdWXCalculate: beaufort = prefer_hardware

The tags are derived from the listing of Paul VE1DX (@WindnFog), which he presented in the thread mentioned in my post above. I expanded it to treat with gust also, by evaluating $current.windGust.raw the same way and put it all together into skins/seasons/current.inc where it finally is display

Re: [weewx-user] StdWXCalculate: beaufort = prefer_hardware

nt.windSpeed, which is beaufort > $current.beaufort. > > If you want to plot it, you would need to put 'beaufort' in your database > schema. > > -tk > > > > On Wed, Jul 8, 2020 at 6:42 AM Vetti52 > > wrote: > >> Hi you Weewx experts! >> >> firs

Re: [weewx-user] StdWXCalculate: beaufort = prefer_hardware

no beaufort or have windSpeed and have an > incorrect beaufort value then something is wrong and we need to dig > deeper. If the loop packets/archive records are correct then the issue is > downstream in the skin/skin config. > > Gary > > On Tuesday, 21 July 2020 at 20:55:37 UTC+10

Re: [weewx-user] StdWXCalculate: beaufort = prefer_hardware

m that beaufort is appearing in > archive records. > > Gary > > On Thursday, 23 July 2020 22:38:14 UTC+10, Vetti52 wrote: >> >> Hi, Gary! >> Thanks for the hints. In deed, there is a value for beaufort in the loop: >> LOOP: 2020-07-23 14:16:36 CEST (

Re: [weewx-user] Re: New GW1000 Driver available for testing

When running reconfigure with prompts, there are two changes, that occured in my case without asking: group_pressure turns to inHg, and group_speed and group_speed2 turn to mile_per_hour and ~2 respectively.You better diff old and new version before restarting. In addition, 'radiation': 'solar_r

Re: [weewx-user] Re: New GW1000 Driver available for testing

ely, > it may be that there is something else available in the API that is not > documented. > > Gary > > On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote: >> >> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote: >>> >>> When running reconfi

Re: [weewx-user] StdWXCalculate: beaufort = prefer_hardware

suggestion to run WeeWX >> directly for at least a full archive period to confirm that beaufort is >> appearing in archive records. >> >> Gary >> >> On Thursday, 23 July 2020 22:38:14 UTC+10, Vetti52 wrote: >>> >>> Hi, Gary! >>> Thank

Re: [weewx-user] Re: Bad Data after Maintenance

This thread is a very practical recipe for deleting unwanted data. I could reproduce it step by step, except, that the data was shown in archive_day_rain. Thanks a lot! One thing, I had to consider, was, that after rebuilding, the wrong data in the archive_day_rain were shown again. I found, th

Re: [weewx-user] Re: New GW1000 Driver available for testing

your system. > > Gary > > On Sunday, 26 July 2020 17:42:57 UTC+10, Vetti52 wrote: >> >> The setting 'radiation': 'solar_radiation', is copied from >> interceptor.py, which is propagated into radiation in weewx. When changing >> to gw1000 api dr

Re: [weewx-user] Re: New GW1000 Driver available for testing

>> python version to the default on your system. >> >> Gary >> >> On Sunday, 26 July 2020 17:42:57 UTC+10, Vetti52 wrote: >>> >>> The setting 'radiation': 'solar_radiation', is copied from >>> interceptor.py, which is pr

Re: [weewx-user] Translation into german

And you will have to look into weewx.conf. Here are my adoptions: [Station] # Start of week (0=Monday, 6=Sunday) week_start = 0 [StdReport] ... [[Defaults]] [[[Units]]] ... Labels day = " Tag", " Tage" hour = " Stunde", "

[weewx-user] Re: wanted: users with ecowitt gw1000 wifi bridge

Although no GW1000, but with a Fine Offset WS2900 clone, I also used the instructions as described in your link with the ecowitt-client and interceptor.py version 0.49. Additionally I have changed line 2234 to 'wh65batt': 'battery', PYTHONPATH=/usr/share/weewx/ python bin/user/inte

[weewx-user] Re: wanted: users with ecowitt gw1000 wifi bridge

Thanks, Matthew! This will make things a bit easier. However, I must confess, that I am sometimes a bit messy. So, when updating interceptor.py from your site, I will have to remember, on which parts I mades my modifications. So, for me it would be much easier, if all modifications could resid

[weewx-user] Re: wanted: users with ecowitt gw1000 wifi bridge

Am Sonntag, 12. Januar 2020 22:01:36 UTC+1 schrieb mwall: > > On Sunday, January 12, 2020 at 7:23:30 AM UTC-5, Vetti52 wrote: >> >> This will make things a bit easier. However, I must confess, that I am >> sometimes a bit messy. So, when updating interceptor.py from yo

[weewx-user] Re: wanted: users with ecowitt gw1000 wifi bridge

Am Montag, 13. Januar 2020 12:32:33 UTC+1 schrieb Vetti52: > > > > Am Sonntag, 12. Januar 2020 22:01:36 UTC+1 schrieb mwall: >> >> On Sunday, January 12, 2020 at 7:23:30 AM UTC-5, Vetti52 wrote: >>> >>> This will make things a bit easier. However, I mu

[weewx-user] Re: wanted: users with ecowitt gw1000 wifi bridge

gt; >> On Tuesday, 28 January 2020 03:41:22 UTC, Paul McGeorge wrote: >>> >>> Are you using the latest version .52? >>> >>> I am getting identical readings on ecowitt.net and Weewx with my GW1000 >>> and the latest version and no extra configura

  1   2   >