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 [email protected] > 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 [email protected]. >> >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/e853ed8b-d965-4092-9f2f-e0f7d6ccbb46n%40googlegroups.com.
