My favorite was alttimeSeasons, because there are no speedometer like gimmicks. Just tables and graphs. The only „round“ design, I would accept, was a compass rose, preferably in a marine design. If one could kick off all of them, besides of the winddir display in the bootstrap skin, it could be of interest for me, So far I am happy with alltimeSeasons.
Glenn McKechnie schrieb am Mittwoch, 23. Juli 2025 um 14:27:26 UTC+2: > Thanks Michael, > > Indeed. I've had my eye on the skin for a while and I did a test install > of version 4,3 back at the start of Jan 2025. (It must have been my > NewYears resolution!) > It's still there at http://cgm.id.au/weewx/Bootstrap/ > > I like it. It renders well, especially using the phone; that alone is a > huge plus. > I've always liked the dynamic graphs (which is why I spent the time > updating the original mesowx skin - > https://github.com/glennmckechnie/weewx-mesowx that I run internally) > > The trouble is, I just haven't had the time to migrate my existing install > over to it. I used up my coding allotment on another project and my ToDo > list got way out of sync. If the (promised - cough) rain comes later this > week, I may just be able to sit down, guilt free, and make a decent start > on it... but who knows ? > > Cheers > Glenn > > Various WeeWx addons at > https://github.com/glennmckechnie > > On Wed, 23 Jul 2025 at 19:34, '[email protected]' via weewx-user < > [email protected]> wrote: > >> @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 >> >> <https://groups.google.com/d/msgid/weewx-user/b2a48bbe-ea83-455b-a606-841f6e6bbe0cn%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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/weewx-user/34d0f358-bd79-49d7-95e2-7bf7188db409n%40googlegroups.com.
