@Glenn the historygenerator alltimeseasons integrated from fuzzy-archer has 
been undergoing massive changes to the better, also adding features like 
alltime min/max/avg and so on. You might want to take a look. Also, nor 
more template adaptions necessary, like vetti52 mentioned above.
see: https://github.com/brewster76/fuzzy-archer

Vetti52 schrieb am Mittwoch, 23. Juli 2025 um 11:21:36 UTC+2:

> Oh well, I‘ve got the logic now. To see the data from the [HistoryReport] 
>  stanza [[hail]] in the html table, I had to add the table into 
> histgenerator.inc:
>            <h3>Regenfall Piezo (mm)</h3>
>           $hail_table
>
> Now, I see the Piezo data! Great!! Although easy, it was a hard way for me 
> to proceed. Thanks to all of you!
> Peter
> Vetti52 schrieb am Dienstag, 22. Juli 2025 um 21:44:11 UTC+2:
>
>> well, to suppose, what the „original“ driver might be, I have my own 
>> story:
>> There is the „original“ 0.6.3 GW1000 driver, plus the 0.1.0a28 
>> Ecowitt_http driver at Ian‘s repository, plus the actual 0.1.6 Ecowitt_http 
>> driver at Werners branch.
>> I was interested to insert „is_raining“ in my alltimeSeasons skin. Crazy? 
>>  Currently I use the GW1000 driver and GW1000Service to collect the data 
>> from my GW1000 and GW3000. There is no „is_raining“. So, I decided, to 
>> replace the GW1000Service by Ecowitt_httpService. Nice idea, but the 
>> field_map_extension copied from GW1000Service does not match. 
>> Unfortunately, I mapped piezoRain.0x0D.val to hail. That resulted in 
>> rain_event running into rain data for a while. Suddenly my rain rate rised 
>> to several thousand mm/h. Ugly. So, I had to stop weewx, edit the database 
>> to zero all hail data for this afternoon (this was easy because of no rain) 
>> rebuild the today summaries and start weewx in the previous configuration 
>> in a hurry: Because then it started to rain (and it still rains)….
>> I will wait, until the two versions of ecowitt_http drivers grow 
>> together, hoping, not to mix up the field maps again, and stay with the 
>> „original“ GW1000 driver. And no „is_rain“ for now.
>>
>> Besides I could edit the NOAA file properly. First, I forgot to „paint“ 
>> the heading lines in the table, but now it looks perfect. The HistoryReport 
>> needs to be done yet. Thanks, @Glenn!
>>
>> Auchtermuchty Weather schrieb am Dienstag, 22. Juli 2025 um 15:17:41 
>> UTC+2:
>>
>>> I have the original driver working just fine with a new gateway, with 
>>> the SD card. It has it's own IP address (set in a DHCP server on my home 
>>> network) and I also have an older gateway working alongside it, the DHCP 
>>> gives that a different IPA.
>>>
>>> On Monday, 7 July 2025 at 16:34:28 UTC+1 vince wrote:
>>>
>>>> If you don’t need backfill you can possiblt still use the original 
>>>> driver.
>>>>
>>>> Two issues.  The first is whether your old gateway can read data from a 
>>>> new model sensor. I had to upgrade from my old gw1000 gateway to a gw1200 
>>>> to be able to hear a newer ws85 sensor.
>>>>
>>>> The second issue is how to merge multiple sensors into one weewx 
>>>> database. Generally you just need a sensor-map to select which wind or 
>>>> rain 
>>>> sensor to use. Worst case two instances and MQTT should work.
>>>>
>>>> FWIW my experience is that the ecowitt piezo rain sensors are horrible. 
>>>> I found no way to calibrate my rain readings to be able to believe them 
>>>> even with a calibrated cocorahs manual gauge nearby. I gave up trying and 
>>>> took the ws85 down. I never worked trying to see if its wind readings were 
>>>> good or not.
>>>>
>>>>
>>>> On Monday, July 7, 2025 at 4:48:05 AM UTC-7 Vetti52 wrote:
>>>>
>>>>> So, my first approach seems to be promising. Maybe, I will at first, 
>>>>> run the Wittboy in parallel, without integration into Weewx and compare 
>>>>> the 
>>>>> data and calibrate, when possible. At least I will have to omit the wind 
>>>>> data, because in the area there will be no suitable place to measure the 
>>>>> wind speed and orientation, because at an elevation of 2m AGL there are 
>>>>> too 
>>>>> many turbulences and will result in a data mess pretty sure. As far, as I 
>>>>> have read the documentation of GW1000 or GW3000, there is no method to 
>>>>> silence specific sensors of the array. So I will have to find out, how to 
>>>>> ignore wind data in Weewx. Am I right?
>>>>> Besides, since now, I never needed to backfill data from Ecowitt or 
>>>>> WU. So, I hope, this remains that way, and I do not need the new backfill 
>>>>> method. However, I am not sure, if there are other advances, which will 
>>>>> urge Ecowitt users to switch to the http based driver, Gary was working 
>>>>> on. 
>>>>> But, maybe, there is some progress on this project from other specialists 
>>>>> here in the forum, that can enlighten me meanwhile.
>>>>>
>>>>> Thanks so far
>>>>> Peter
>>>>>
>>>>> [email protected] schrieb am Freitag, 4. Juli 2025 um 19:31:42 
>>>>> UTC+2:
>>>>>
>>>>>> I use two GW2000 with one WeeWX instance, one with the Ecowitt 
>>>>>> Gateway Driver as a Driver, the other  one with the Ecowitt Gateway 
>>>>>> Driver 
>>>>>> as a Service. I am on 0.6.3, which isn't capable of backfilling data 
>>>>>> from 
>>>>>> the gw3000s SD-storage in case your WeeWX wasn't running for whatever 
>>>>>> reason.
>>>>>>
>>>>>> Vetti52 schrieb am Freitag, 4. Juli 2025 um 18:46:51 UTC+2:
>>>>>>
>>>>>>> Since a couple of years I have an EFWS2900 working without any 
>>>>>>> failure now. This is an Ecowitt 2900 clone, positioned on a pole at 6m 
>>>>>>> above ground. It has a colored console, which is just used for visual 
>>>>>>> checks. I added a Froggit DP1500, which is a clone of Ecowitt GW1000, 
>>>>>>> serving as source for weewx, using the GW1000 driver, version 
>>>>>>> 0.6.3. This works perfectly. However….
>>>>>>> When there is only drizzling rain, the sensor does not react. I 
>>>>>>> therefore decided, to add another rain sensor, which should be 
>>>>>>> positioned 
>>>>>>> at 2m AGL. 
>>>>>>> My current approach is: 
>>>>>>> I have purchased an Ecowitt GW3001 (coming next week), which 
>>>>>>> consists of a Wittboy sensor set and a GW3000. I plan to replace the 
>>>>>>> WS2900 
>>>>>>> on the pole with the Wittboy and place the WS2900 at a position 2m AGL 
>>>>>>> nearby. This should then be used for additional rain measurement only. 
>>>>>>> The GW3000 should be connected per LAN, situated directly at the 
>>>>>>> router in the basement. The temperature sensor is thus not relevant. 
>>>>>>> The 
>>>>>>> old GW1000 remains in the living room for temperature and, maybe, for 
>>>>>>> pressure measurement.
>>>>>>> So, I need a setup for collecting data from the GW1000 and GW3000. 
>>>>>>> My first approach was, to stay with the current setup using the GW1000 
>>>>>>> driver, and ad the GW3000 with a second GW1000 driver, but running as a 
>>>>>>> service. Is this possible? And, if yes, how should I configure 
>>>>>>> weewx to „merge“ the data into an arrangement, which provides a 
>>>>>>> „smooth“ 
>>>>>>> transition?
>>>>>>> I have seen the thread started from gjr, concerning a separate 
>>>>>>> GW3000 driver, which indicates, that there are improvements coming, 
>>>>>>> concerning Ecowitt drivers at all. But the actual situation of gjr 
>>>>>>> being 
>>>>>>> „offline“, touches me considerably. 
>>>>>>> So, I am hesitating to follow my approach. Or should I, instead, 
>>>>>>> replace the complete GW1000 driver based data collection setup by 
>>>>>>> something, which is more „up to date“, and which needs, however, still 
>>>>>>> to 
>>>>>>> be developed?
>>>>>>>
>>>>>>

-- 
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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/weewx-user/b2a48bbe-ea83-455b-a606-841f6e6bbe0cn%40googlegroups.com.

Reply via email to