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]
<mailto:[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/2497c1c8-8489-ecd5-2d72-df0364321d93%40gmail.com.
