OK, understand. Nothing to concern the GW1000 driver. I suspect the vast majority of cases where WH45 obs are included in a skin will be user modified/developed skins and experience shows the user will format/order as the user sees fit. I suspect the default skins that ship with WeeWX will continue to be fairly generic in nature.
Gary On Saturday, 2 January 2021 at 12:59:46 UTC+10 galfert wrote: > The data comes off the GW1000 API in this order: > > 1 temp_co2 > > 2 humi_co2 > > 3 pm10_co2 > > 4 pm10_24h_co2 > > 5 pm25_co2 > > 6 pm25_24h_co2 > > 7 co2 > > 8 co2_24h > > 9 co2_batt > > I'm just trying to impart some input if it were to ever be included in any > default skin or presentation. This order is not good. > > * Reference: Official Ecowitt GW1000 API documentation. Which has limited > access by Ecowitt for now. I have it as I'm like an ambassador / liaison > for Ecowitt and the various software developers. Bound to by NDA. > > > > On Friday, January 1, 2021 at 9:48:14 PM UTC-5 galfert wrote: > >> I realize that this WH45 data is not yet part of any skin. I was only >> trying to preempt its default inclusion in a skin. In that case my comments >> were that the PM2.5 be first and the PM10 data second. and the CO2 data >> third. >> >> The reason I state this is because in the raw data from the GW1000 API >> ....something you can't see unless you are in the know with the GW1000 API >> as I and Gary are (Ecowitt NDA regarding GW1000 API documentation). This >> note only will make sense to Gary. The data as is comes off the GW1000 >> sends PM10 before PM2.5. >> >> >> On Friday, January 1, 2021 at 5:53:28 PM UTC-5 lang....@googlemail.com >> wrote: >> >>> As for me, the code of the new driver (0.2.1b1) works fine as far as I >>> can tell. >>> >>> All data arrives and can be addressed, and the application doesn't crash >>> anymore. >>> It can be archived (some assignment needed as not all fields are part of >>> the extended database schema), >>> and it can be used in the reports. >>> >>> And the order in the field map is: >>> >>> ....................... >>> >>> 'pm2_5': 'pm251', # =WH41/43 #1 >>> 'pm2_52': 'pm252', # =WH41/43 #2 >>> 'pm2_53': 'pm253', # =WH41/43 #3 >>> 'pm2_54': 'pm254', # = WH41/43 #4 >>> 'pm2_55': 'pm255', # = WH45 PM2.5 >>> 'pm10': 'pm10', # = WH45 PM10 >>> 'co2': 'co2', # =WH45 CO2 >>> >>> ........................... >>> >>> Temperature and Humidity are sorted into the extraTemperature 'section' >>> as #17 >>> >>> Here I don't really understand George's request regarding sequence/order >>> either. >>> >>> " >>> Please note that even though the raw data coming from this new sensor is >>> for the PM10 to come first and then the PM2.5 that is not the order that we >>> would typically refer to the sensor as ...it is *called the PM2.5, >>> PM10, CO2 sensor in that order*. Looking at the GW1000 API >>> documentation it baffles me why the engineers decided to send PM10 data >>> first. Also on the GW1000 mobile app (WS View) and on Ecowitt.net the order >>> is also PM2.5 first and then PM10. *I fee therefore that WeeWX should >>> keep the order as PM2.5 first and then PM10.*" >>> >>> @George: maybe you explain more in detail what exactly you mean, where >>> some sequence (order) is not maintained and why this is important 😎. >>> >>> At least in the field map (in my terms/language: the weewx GW1000 driver >>> interface record declaration [but we may have different wording here, >>> depending on our >>> programming language history]) exactly this sequence (order) is >>> maintained. Where else is this order missing ? >>> >>> At the end of the day, e.g. in the WSView app, it's a matter of >>> presentation. And which sequence/order you choose for showing this data in >>> the reports (e.g. Seasons skin) >>> is up to you. There is no preset report for the WH45 data (yet), afaik, >>> but my knowledge may not be complete. >>> >>> >>> >>> On 01.01.2021 22:20, Paul Ward wrote: >>> >>> Gary I have a WH45 on order so subject to shipping delays I’m happy to >>> test the code too in couple of weeks when I get it, if you don’t release >>> beforehand. >>> >>> On Friday, January 1, 2021 at 1:26:45 AM UTC gjr80 wrote: >>> >>>> WH45 support was coded some time ago though of course not tested with >>>> an actual device. Have had a number of other features I was working on to >>>> add at the same time which delayed release of the WH45 compatible version >>>> of the driver. Rainer now has a copy of a compatible version of the driver >>>> to test and once he confirms it works I will shortly afterwards release >>>> the >>>> WH45 compatible version. >>>> >>>> As an aside, and on a technical note, this did highlight that I need to >>>> change the approach the driver uses to dealing with sensor data from the >>>> GW1000. Ideally adding an new sensor type should not cause a driver that >>>> does not know about that new sensor type to crash; rather the driver >>>> should >>>> continue to operate but just not provide data for the (to it) unknown >>>> sensor. This will be something to work on for the next version of the >>>> driver, fortunately Ecowitt is not releasing new sensors that often. >>>> >>>> Gary >>>> >>> -- >>> >>> 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/afcd4401-6b46-421f-a25c-e74aa235e870n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/weewx-user/afcd4401-6b46-421f-a25c-e74aa235e870n%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/231fdd21-a2dd-4537-92c2-7364bc768dbbn%40googlegroups.com.
