Re: [weewx-user] Re: Garni 1025 (unknown protocol) and interceptor driver
@Cameron D. I think you are mistaken here regarding the console WLAN - even if that Garni piece is manufactured by CCL, what they do is a commonly used process. E.g. factually all FineOffset (clone) consoles can create their own WLAN and a WLAN enabled device (PC, Smartphone etc.) can connect to it via the SSID the console sends. So that console also becomes an access point for its own WLAN. It has not yet anything to do with the local WLAN. The local WLAN is then selected through the console and the user can connect to it via the local SSID and the router password. Now, that console has two interfaces - through its own WLAN and through the local WLAN. Usually the console WLAN is switched off once the connection to the local WLAN is established. This process sometimes called "WiFi provisioning" or "pairing" is quite common. The 2.4 GHz come into play as the console is usually only 2.4 GHz enabled. Considering this having a minimal value is immaterial - the value consists of being able to connect the console to the local WLAN - this type of setup is quite common and usually works well - provided the user takes a few precautions like e.g. switching off the mobile data network during the "pairing" process and avoiding also having a 5 GHz WLAN with the same SSID active during the pairing. On 24.03.2025 05:42, 'Cameron D' via weewx-user wrote: I don't understand why the Garni would need to be set up as you describe - its specification is only 2.4GHz for Wifi, so its value as a real AP would be minimal. It does not seem to need to use wifi for connecting to anything else (that uses 868MHz). You wrote that "I managed to connect the laptop to the network created by the Garni panel..." but that does not fit - an AP does not create a new wifi network, it only extends the existing one created by the router. Most likely the router recognises that the upload traffic from the panel is not local and does not show it to the laptop/pi, since it would require retransmitting. A domestic router is unlikely to offer traffic mirroring/monitoring. If all that is correct then I think your options are: 1. investigate the option where it says "access data on user's own server" 2. set up the Pi as another wifi router and pass the traffic through it - then use ethernet to the external router On Sunday, 23 March 2025 at 5:48:59 am UTC+10 Tomasz Lewicki wrote: Today I had the opportunity to face the Garni 1025 station. Unfortunately, the issue is much more complex than it might seem at first. The universal driver “interceptor” is powerless in this case. The station communicates with the environment in a strange way. It turns out that the panel with the display does not connect directly to the local network as a device with an IP address in the range given by the DHCP server of the home router, but probably forms a kind of bridge between itself and the router. The way I came to this was that after connecting the Raspberry Pi with Weewx installed, I scanned the local network with my smartphone and found no device in it that could be a Garni panel. From the instructions, I learned that to configure the panel, you need to press the appropriate button on the case and enter AP mode. Then you can enter the default address 192.168.1.1 with a browser and there enter the SSID of your home network and the password for it. I managed to connect the laptop to the network created by the Garni panel and started sniffing on the network traffic. Unfortunately, tcpdump didn't show anything that would give any meaningful clues. The only packets were sent by the Garni panel to my laptop. I couldn't see any packets that Garni was routing to the router, yet it must be transmitting something if data is being sent to the WU, right? Do you see any way that I could still try? PS. Does Weewx allow you to import data from WU in "quasi real time"? What I mean is, can I download data from WU, for example, every 5-10 minutes and feed it to Weewx so that it creates charts locally. niedziela, 16 marca 2025 o 10:02:32 UTC+1 Tomasz Lewicki napisał(a): Thank you all for the helpful replies. As I said, the station is out of my reach so I hoped to prepare "dry run" and set up Weewx in my home environment and then just connect in in target network, changing only necassary things (WiFi network and so on). If it is not possible, I have to use tcpdump "in situ", where Garni works. But - replying to Reiner Lang's suggestion - Garni sends the data to WU instantly; you can check it here -> https://www.wunderground.com/dashboard/pws/IKOWAL30 In the meantime I got a photo of manual page from the owner of the station (Garni doesn't share the manuals on its website - it's strange) and then I was almost sure that Garni uses Weatherclo
[weewx-user] Re: Calculate max sun angle each day at my location
Just put the code in a template and see, if it does, what you want. Anythings else: step by step :) bgra...@umw.edu schrieb am Samstag, 22. März 2025 um 19:53:08 UTC+1: > Thanks, Michael, I’ll work with your suggestion but I’m not sure how to > put this in a template other than the Standard skin. I guess this would be > code in another file that would be called from Standard? Sorry, I’m not > very Python literate—only enough to get myself into trouble. > Cheers, > Bob > > On Saturday, March 22, 2025 at 4:29:23 AM UTC-4 michael.k...@gmx.at wrote: > >> See: >> https://weewx.com/docs/5.1/custom/cheetah-generator/?h=ephem#heavenly-bodies >> >> Note: ephem has to be installed >> >> Assuming the maximum angle of the sun is really when it transits, then >> the maximum height can be calculated like this: set almanac time to transit >> time, and then calculate the altitude for the sun at this time: >> $almanac(almanac_time=$almanac.sun.transit.raw).sun.alt >> >> >> But as far as I know, $almanac.sun.transit doesn't yield today's transit, >> but next transit, which may be tomorrow, if the current time is after >> today's transit. For today's transit, you calculate the next transit from >> today's start of day, and then calculate the sun's altitude for this time: >> $almanac(almanac_time=$almanac(almanac_time=$day.start.raw >> ).sun.transit.raw).sun.alt >> >> >> Then put the above code in a template of your choice (which may arise >> your next question) in a way, it survives a WeeWX update/skin update. >> You also may want to format the result in a way, it doesn't show a dozen >> of decimals and add degrees(°), which requires additional code. >> >> There may be other and/or easier ways. >> bgra...@umw.edu schrieb am Freitag, 21. März 2025 um 23:58:03 UTC+1: >> >>> Hello, >>> I would like to display (Standard skin) the max sun angle for the day at >>> my latitude. Not being a programmer, I’m not sure how to do this. I have a >>> solar hot water heater. >>> My system is an RPI5 with pip install of the latest weewx. >>> Thanks in advance. >>> Cheers, >>> Bob >>> grattans.org/wx >>> >> -- 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 visit https://groups.google.com/d/msgid/weewx-user/6a89eb2c-6c40-4eb4-a0e7-4f5e31522d90n%40googlegroups.com.
Re: [weewx-user] Re: Garni 1025 (unknown protocol) and interceptor driver
yes, I realised my mistake once Vince mentioned the EcoWitt setup. It is an unfortunate ambiguity of "Access Point" terminology, which I have only seen used to describe the process I was referring to - bridging two network segments. >From the description Tomasz gave it seems the panel has a single wifi interface that either sets up an isolated private wlan, or acts as a wifi client. On Tuesday, 25 March 2025 at 6:24:10 am UTC+10 Rainer Lang wrote: > @Cameron D. > I think you are mistaken here regarding the console WLAN - even if that > Garni piece is manufactured by CCL, what they do is a commonly used process. > E.g. factually all FineOffset (clone) consoles can create their own WLAN > and a WLAN enabled device (PC, Smartphone etc.) can connect to it via the > SSID the console sends. So that console also becomes an access point for > its own WLAN. It has not yet anything to do with the local WLAN. > The local WLAN is then selected through the console and the user can > connect to it via the local SSID and the router password. Now, that console > has two interfaces - through its own WLAN and through the local WLAN. > Usually the console WLAN is switched off once the connection to the local > WLAN is established. > This process sometimes called "WiFi provisioning" or "pairing" is quite > common. > The 2.4 GHz come into play as the console is usually only 2.4 GHz enabled. > Considering this having a minimal value is immaterial - the value consists > of being able to connect the console to the local WLAN - this type of setup > is quite common and usually works well - provided the user takes a few > precautions like e.g. switching off the mobile data network during the > "pairing" process and avoiding also having a 5 GHz WLAN with the same SSID > active during the pairing. > On 24.03.2025 05:42, 'Cameron D' via weewx-user wrote: > > I don't understand why the Garni would need to be set up as you describe - > its specification is only 2.4GHz for Wifi, so its value as a real AP would > be minimal. It does not seem to need to use wifi for connecting to anything > else (that uses 868MHz). > You wrote that "I managed to connect the laptop to the network created by > the Garni panel..." but that does not fit - an AP does not create a new > wifi network, it only extends the existing one created by the router. > > Most likely the router recognises that the upload traffic from the panel > is not local and does not show it to the laptop/pi, since it would require > retransmitting. A domestic router is unlikely to offer traffic > mirroring/monitoring. > If all that is correct then I think your options are: > 1. investigate the option where it says "access data on user's own server" > 2. set up the Pi as another wifi router and pass the traffic through it - > then use ethernet to the external router > > On Sunday, 23 March 2025 at 5:48:59 am UTC+10 Tomasz Lewicki wrote: > >> Today I had the opportunity to face the Garni 1025 station. >> Unfortunately, the issue is much more complex than it might seem at first. >> The universal driver “interceptor” is powerless in this case. The station >> communicates with the environment in a strange way. It turns out that the >> panel with the display does not connect directly to the local network as a >> device with an IP address in the range given by the DHCP server of the home >> router, but probably forms a kind of bridge between itself and the router. >> >> The way I came to this was that after connecting the Raspberry Pi with >> Weewx installed, I scanned the local network with my smartphone and found >> no device in it that could be a Garni panel. From the instructions, I >> learned that to configure the panel, you need to press the appropriate >> button on the case and enter AP mode. Then you can enter the default >> address 192.168.1.1 with a browser and there enter the SSID of your home >> network and the password for it. I managed to connect the laptop to the >> network created by the Garni panel and started sniffing on the network >> traffic. Unfortunately, tcpdump didn't show anything that would give any >> meaningful clues. The only packets were sent by the Garni panel to my >> laptop. I couldn't see any packets that Garni was routing to the router, >> yet it must be transmitting something if data is being sent to the WU, >> right? >> >> Do you see any way that I could still try? >> >> PS. Does Weewx allow you to import data from WU in "quasi real time"? >> What I mean is, can I download data from WU, for example, every 5-10 >> minutes and feed it to Weewx so that it creates charts locally. >> >> niedziela, 16 marca 2025 o 10:02:32 UTC+1 Tomasz Lewicki napisał(a): >> >>> Thank you all for the helpful replies. >>> >>> As I said, the station is out of my reach so I hoped to prepare "dry >>> run" and set up Weewx in my home environment and then just connect in in >>> target network, changing only necassary things (WiFi ne
Re: [weewx-user] Weewx 5.1 - Observation over 2 days
Just new here... do not know karen k, or about her repo yet... where is her
repo is it on github?
Yes AU is metric, I assume if you set the it in conf it will do what it
does...
On Mon, 24 Mar 2025 at 16:08, 'michael.k...@gmx.at' via weewx-user <
weewx-user@googlegroups.com> wrote:
> Didn't Karen K have something of this sort in her repo?
>
> The above will only work with metric db, will it?
>
> Dr Henk Harms schrieb am Montag, 24. März 2025 um 06:56:39 UTC+1:
>
>>
>> So been "messing with it"
>> To create a table.
>>
>> CREATE TABLE archive_bom_minmax (
>> dateTime INTEGER NOT NULL PRIMARY KEY,
>> usUnits INTEGER NOT NULL,
>> `interval` INTEGER NOT NULL,
>> min_temp DOUBLE,
>> min_temp_time INTEGER,
>> max_temp DOUBLE,
>> max_temp_time INTEGER
>> );
>>
>> Then add this to /usr/share/weewx/user
>> #!/usr/bin/env python
>> # -*- coding: utf-8 -*-
>>
>> """
>> bom_minmax.py - WeeWX service to record BoM-compliant min/max temperatures
>>
>> This service records minimum and maximum temperatures between 6pm the
>> previous
>> day and 9am the current day, storing them at 9am in a dedicated table.
>> """
>>
>> import datetime
>> import time
>> import weedb
>> import weewx
>> from weewx.engine import StdService
>>
>> # Try to use new-style WeeWX V5 logging
>> try:
>> import logging
>> log = logging.getLogger(__name__)
>> def logdbg(msg):
>> log.debug(msg)
>> def loginf(msg):
>> log.info(msg)
>> def logerr(msg):
>> log.error(msg)
>> except (ImportError, AttributeError):
>> # Use old-style WeeWX V4 logging via syslog
>> import syslog
>> def logmsg(level, msg):
>> syslog.syslog(level, 'bom_minmax: %s' % msg)
>> def logdbg(msg):
>> logmsg(syslog.LOG_DEBUG, msg)
>> def loginf(msg):
>> logmsg(syslog.LOG_INFO, msg)
>> def logerr(msg):
>> logmsg(syslog.LOG_ERR, msg)
>>
>> # BoM observation time configuration
>> BOM_MORNING_HOUR = 9# 9am
>> BOM_EVENING_HOUR = 18 # 6pm
>>
>> class BomMinMaxService(StdService):
>> """Service to record min/max temperatures in BoM format."""
>>
>> def __init__(self, engine, config_dict):
>> super(BomMinMaxService, self).__init__(engine, config_dict)
>>
>> loginf("Starting BoM Min/Max Temperature Service")
>>
>> # Get the database configuration
>> self.db_dict = config_dict.get('BomMinMax', {})
>>
>> # Archive database binding - where to get temperature data from
>> self.archive_binding = self.db_dict.get('archive_binding',
>> 'wx_binding')
>>
>> # Output database binding - where to store BoM min/max data
>> self.output_binding = self.db_dict.get('output_binding',
>> 'wx_binding')
>>
>> # Table name for BoM min/max data
>> self.table_name = self.db_dict.get('table_name',
>> 'archive_bom_minmax')
>>
>> # Temperature field to use
>> self.temp_field = self.db_dict.get('temp_field', 'outTemp')
>>
>> # Initialize the table if it doesn't exist
>> # Commented out for stability
>> #self.init_table()
>>
>> # Bind to archive events
>> self.bind(weewx.NEW_ARCHIVE_RECORD, self.new_archive_record)
>>
>> loginf("BoM Min/Max Temperature Service initialized")
>>
>> def init_table(self):
>> """Initialize the table if it doesn't exist."""
>>
>> try:
>> with self.engine.db_binder.get_manager(self.output_binding)
>> as dbm:
>> # Check if table exists
>> if self.table_name not in dbm.connection.tables():
>> loginf(f"Creating table {self.table_name}")
>>
>> # Create the table
>> dbm.connection.execute(
>> f"CREATE TABLE {self.table_name} ("
>> f"dateTime INTEGER NOT NULL PRIMARY KEY, "
>> f"usUnits INTEGER NOT NULL, "
>> f"`interval` INTEGER NOT NULL, "
>> f"min_temp DOUBLE, "
>> f"min_temp_time INTEGER, "
>> f"max_temp DOUBLE, "
>> f"max_temp_time INTEGER)"
>> )
>> except Exception as e:
>> logerr(f"Error initializing table: {e}")
>>
>> def new_archive_record(self, event):
>> """Called when a new archive record is available.
>>
>> Check if it's just after 9am and if so, record the min/max data
>> for the 6pm-9am period.
>> """
>>
>> timestamp = event.record['dateTime']
>> dt = datetime.datetime.fromtimestamp(timestamp)
>>
>> # Only process records at or just after 9am
>> if dt.hour == BOM_MORNING_HOUR and dt.minute < 10:
>> self.process_bom_minmax(timestamp)
>>
>> def process_bom_minmax(self, current_ts):
>> """Process and record BoM min/max temperatures.
>>
>> Args:
>> cu
Re: [weewx-user] Ecowitt GW3000 user assistance
Gary, I was just wondering how the development of the new driver is progressing? If you need any help with testing, I am very happy to help. Ian On Friday, March 14, 2025 at 2:10:44 PM UTC Rainer Lang wrote: > the just released firmware final 1.0.4 upgrade for the GW000 should cover > all missing entries in the csv files > On 14.03.2025 14:17, 'Steeple Ian' via weewx-user wrote: > > Sorry, that should be 1.0.4 > Ian > > On Friday, March 14, 2025 at 1:16:38 PM UTC Steeple Ian wrote: > >> Firmware 1.04 has finally been rolled out for GW3000 >> >> On Monday, March 3, 2025 at 11:46:00 AM UTC Rainer Lang wrote: >> >>> roll-out mistake (almost) in time detected, reported and corrected - the >>> future now hopefully final SD card header layout coming with firmware 1.0.4 >>> is in the WiKi >>> for the other network readable SD card device, the WS6210 WLAN/4G >>> gateway, additional observations apply - see also WiKi, table of possible >>> headers >>> https://meshka.eu/Ecowitt/dokuwiki/doku.php?id=start#gw3000-csv >>> VPD (vapour pressure deficit), unit kPa, an agriculture related >>> observation, will be added to the XXZ.csv file behind the "Feels Like" >>> observation >>> On 03.03.2025 10:22, 'michael.k...@gmx.at' via weewx-user wrote: >>> >>> That was a false rollout they did. >>> See https://www.wxforum.net/index.php?topic=48216.msg486394#msg486394 >>> Steeple Ian schrieb am Montag, 3. März 2025 um 09:21:44 UTC+1: >>> Having said that, it is strange that version number has gone backwards and no sign of piezo rain data in the card .csv files after the old files had been deleted. On Monday, March 3, 2025 at 8:02:09 AM UTC Steeple Ian wrote: > I see that the new firmware has arrived. GW3000A_V1.0.1 > > On Tuesday, February 18, 2025 at 5:21:55 PM UTC michael.k...@gmx.at > wrote: > >> In the mean time my GW3000 is installed already in my test >> environment, so if there is anything I can help with, let me know. I've >> got >> no problem even with a still-not-ready, potentially buggy, bleeding edge >> version of the driver in my test environment. >> >> steepleian schrieb am Montag, 17. Februar 2025 um 13:22:43 UTC+1: >> >>> Good news indeed. Thank you for your update. >>> Ian >>> https://claydonsweather.org.uk >>> >>> On 17 Feb 2025, at 10:50, 'Rainer Lang' via weewx-user < >>> weewx...@googlegroups.com> wrote: >>> >>> >>> >>> Ecowitt has confirmed that the missing piezo data, the WH7 time >>> stamp of the last lightning event and the LDS01 depth will be added to >>> the >>> SD card data with the next firmware for the GW3000 and WS6210. >>> >>> @Gary: the header text now contains for temperatures a one-character >>> representation of °C and F - this will become two letters/characters >>> "°" >>> and "C" resp. "F" >>> >>> All the LDS values have already been added to the WiFi firmware of >>> the other consoles (those which have two firmwares) for the Customized >>> Server and for those people using the Interceptor driver it can now >>> also be >>> retrieved >>> (of course you have to use an extended version of the driver and not >>> the "barebone" version at GitHub - that could get an update with all >>> now >>> existing sensors and values ...) >>> The world has significantly changed in the past years ... there are >>> user created (tested and working) complete versions available though >>> Gary's local API driver looks up to date (probably LDS01 to be added) >>> On 13.02.2025 09:23, Rainer Lang wrote: >>> >>> there are a few more things to be considered from the bigger >>> perspective with the GW3000 >>> - some referring to the SD card archiving of also other sensor >>> values (e.g. LDS01, WH57 ...), the file name change etc - all needs to >>> be >>> streamlined - already a few things were sorted with the last firmware >>> upgrade >>> - some referring to the customized server posting >>> >>> The WiKi is quite up to date regarding the expected-to-be situation >>> and partly also regarding the "missing feature" situation. >>> https://meshka.eu/Ecowitt/dokuwiki/doku.php?id=start#gw3000 >>> there is a table with the so-far existing observations in the CSV >>> files corresponding to the header items - and the known missing ones >>> >>> all this also needs to be synchronized with the WS6210 console, >>> which is the other one having the API accessible SD card option >>> >>> Some field testing may also be needed >>> >>> an educated guess would be the end of the month - but they might be >>> faster >>> On 12.02.2025 09:17, 'Ian Millard' via weewx-user wrote: >>> >>> No problem Gary. >>> I see that Gyvate has submitted the request to Ecowitt however I >>> h
[weewx-user] Need help with some built in variables
In weewx-data/skins/ss/index.php.tmpl I have added some info lines to the resulting page. This is what I am using and for the most part it works (e.g daily, weekly, monthly seem to show correct data) but rain total for the last 365 days isn't right, its showing the same value as the monthly rain total. I am using weewx version 5.1.0 Month: $span($day_delta=30).rain.sum Year: $span($day_delta=365).rain.sum -- 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 visit https://groups.google.com/d/msgid/weewx-user/ce5b6e7b-f197-4cd4-8ab5-0c4f1f4fca83n%40googlegroups.com.
[weewx-user] Re: Garni 1025 (unknown protocol) and interceptor driver
OK, so I will try this approach - connecting to Garni's own network, power off and on and tcpdump'ing. I will then give a feedback here. Maybe it will help someone in the future. But I can make such an attempt at next weekend. poniedziałek, 24 marca 2025 o 06:41:41 UTC+1 vince napisał(a): > The setup procedure you mention is exactly like an ecowitt gateway’s. You > put an ecowitt gateway/console into a setup mode and you can connect to it > from any wifi device to do the setup steps. So that is why it works that > way. It permits setting it up from a laptop or other wifi device > wirelessly without requiring bluetooth (which a weatherflow hub requires, > for example). > > Using a pi zero certainly makes your diagnostics more difficult, I still > recommend starting tcpdump and capturing to a file, power cycling the > garni, and seeing if you can capture its communication. It almost certainly > does a ntp lookup and probably dns queries as well. You might set the garni > dns to 8.8.8.8 and 8.8.4.4 to use google dns (if I recall their addresses > correctly) but that might be on the advanced tab in your setup gui. I > didn’t notice it on the jpeg you linked to. > > > On Sunday, March 23, 2025 at 10:26:59 PM UTC-7 Tomasz Lewicki wrote: > > I don't know how or why it works that way. Unfortunately, as I wrote > earlier, the station does not belong to me and I have no physical access to > it. When I entered AP mode (that's exactly what the manual calls it), a new > one called PWS-nn (nn are the last six digits of the MAC address) > appeared in the list of wireless networks. I would then connect - without a > password - to that AP. But when the Garni is in AP mode, it does not > transmit data to the Internet, i.e. to the home router - I see it because > WU isn't refreshed. I have to leave AP mode for it to start sending data > again. But at the same time, when leaving AP mode, my laptop stops > receiving packets from Garni's panel. > > -- 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 visit https://groups.google.com/d/msgid/weewx-user/0c208189-3be6-4d25-ab57-89973f5334e6n%40googlegroups.com.
Re: [weewx-user] Ecowitt GW3000 user assistance
Thank you for the update Gary. Ian On Sunday, March 23, 2025 at 10:13:06 PM UTC gjr80 wrote: > Thank you Ian, > > I have a working version running on a system at home. It needs some > tidying up plus the backfill via device history files needs a touchup after > the v1.0.4 firmware release. The absence of any complete and reliable local > device HTTP API documentation is not helping. I am away on holiday in > months time and am aiming to have a version suitable for public use by then. > > Gary > > On Sunday, 23 March 2025 at 20:15:58 UTC+10 steep...@btinternet.com wrote: > >> Gary, >> I was just wondering how the development of the new driver is >> progressing? If you need any help with testing, I am very happy to help. >> Ian >> >> On Friday, March 14, 2025 at 2:10:44 PM UTC Rainer Lang wrote: >> >>> the just released firmware final 1.0.4 upgrade for the GW000 should >>> cover all missing entries in the csv files >>> On 14.03.2025 14:17, 'Steeple Ian' via weewx-user wrote: >>> >>> Sorry, that should be 1.0.4 >>> Ian >>> >>> On Friday, March 14, 2025 at 1:16:38 PM UTC Steeple Ian wrote: >>> Firmware 1.04 has finally been rolled out for GW3000 On Monday, March 3, 2025 at 11:46:00 AM UTC Rainer Lang wrote: > roll-out mistake (almost) in time detected, reported and corrected - > the future now hopefully final SD card header layout coming with firmware > 1.0.4 is in the WiKi > for the other network readable SD card device, the WS6210 WLAN/4G > gateway, additional observations apply - see also WiKi, table of possible > headers > https://meshka.eu/Ecowitt/dokuwiki/doku.php?id=start#gw3000-csv > VPD (vapour pressure deficit), unit kPa, an agriculture related > observation, will be added to the XXZ.csv file behind the "Feels > Like" > observation > On 03.03.2025 10:22, 'michael.k...@gmx.at' via weewx-user wrote: > > That was a false rollout they did. > See https://www.wxforum.net/index.php?topic=48216.msg486394#msg486394 > Steeple Ian schrieb am Montag, 3. März 2025 um 09:21:44 UTC+1: > >> Having said that, it is strange that version number has gone >> backwards and no sign of piezo rain data in the card .csv files after >> the >> old files had been deleted. >> >> On Monday, March 3, 2025 at 8:02:09 AM UTC Steeple Ian wrote: >> >>> I see that the new firmware has arrived. GW3000A_V1.0.1 >>> >>> On Tuesday, February 18, 2025 at 5:21:55 PM UTC michael.k...@gmx.at >>> wrote: >>> In the mean time my GW3000 is installed already in my test environment, so if there is anything I can help with, let me know. I've got no problem even with a still-not-ready, potentially buggy, bleeding edge version of the driver in my test environment. steepleian schrieb am Montag, 17. Februar 2025 um 13:22:43 UTC+1: > Good news indeed. Thank you for your update. > Ian > https://claydonsweather.org.uk > > On 17 Feb 2025, at 10:50, 'Rainer Lang' via weewx-user < > weewx...@googlegroups.com> wrote: > > > > Ecowitt has confirmed that the missing piezo data, the WH7 time > stamp of the last lightning event and the LDS01 depth will be added > to the > SD card data with the next firmware for the GW3000 and WS6210. > > @Gary: the header text now contains for temperatures a > one-character representation of °C and F - this will become two > letters/characters "°" and "C" resp. "F" > > All the LDS values have already been added to the WiFi firmware of > the other consoles (those which have two firmwares) for the > Customized > Server and for those people using the Interceptor driver it can now > also be > retrieved > (of course you have to use an extended version of the driver and > not the "barebone" version at GitHub - that could get an update with > all > now existing sensors and values ...) > The world has significantly changed in the past years ... there > are user created (tested and working) complete versions available > though > Gary's local API driver looks up to date (probably LDS01 to be > added) > On 13.02.2025 09:23, Rainer Lang wrote: > > there are a few more things to be considered from the bigger > perspective with the GW3000 > - some referring to the SD card archiving of also other sensor > values (e.g. LDS01, WH57 ...), the file name change etc - all needs > to be > streamlined - already a few things were sorted with the last firmware > upgrade > - some referring to the customized server posting > > The WiKi is
