Page 1 of 1

MB Pro shows messed up sensor data for Ecowitt WH45 5-in-1 air quality

Posted: Thu Dec 31, 2020 9:41 pm
by Gyvate
Please see
https://www.wxforum.net/index.php?topic=41084.0 for details -
don't want to write it again - in a nutshell - Meteobridge doesn't handle the new Ecowitt WH45 5-in-1 air quality sensor(s) properly.
(Firmware and API already available for 2-3 months)

Re: MB Pro shows messed up sensor data for Ecowitt WH45 5-in-1 air quality

Posted: Fri Jan 01, 2021 1:50 am
by galfert
Same experience with my new WH45. Wrong data showing up.

Gyvate has extra GW1000 and it would be best for Boris to remote into his MB. I disconnected my WH45 because WeeWX crashes.

Re: MB Pro shows messed up sensor data for Ecowitt WH45 5-in-1 air quality

Posted: Fri Jan 01, 2021 3:39 pm
by Gyvate
@galfert
my weewx is up and running again - see
https://www.wxforum.net/index.php?topic=41099.0
The weewx guys (Gary) solved their issue.

Re: MB Pro shows messed up sensor data for Ecowitt WH45 5-in-1 air quality

Posted: Fri Jan 01, 2021 3:40 pm
by Gyvate
galfert wrote: Fri Jan 01, 2021 1:50 am Same experience with my new WH45. Wrong data showing up.

Gyvate has extra GW1000 and it would be best for Boris to remote into his MB. I disconnected my WH45 because WeeWX crashes.
Boris is working on/in/at my test MB Pro and has first findings

Re: MB Pro shows messed up sensor data for Ecowitt WH45 5-in-1 air quality

Posted: Fri Jan 01, 2021 6:58 pm
by Gyvate
Error detected in a joint effort - Boris will provide the fix with next release (update).

Re: MB Pro shows messed up sensor data for Ecowitt WH45 5-in-1 air quality

Posted: Sun Feb 14, 2021 12:05 pm
by Gyvate
I'm happy with the default setup for my 2 WH41 and the WH45 sensors
MB-PM-sensors.JPG
MB-PM-sensors.JPG (18.8 KiB) Viewed 1665 times
and I don't see the need for a changed mapping.

the air2pm sensor is (originally) meant for 1 ug/m3, which is so far not an Ecowitt sensor.
I think the physical sensor setup is originally meant for (or derived from) Davis stations.

If you had the max number of WH41 (4), air0pm - air3pm would represent these.
Now air4 and air5 have been added for the WH45.

So I'm not sure what added value a different mapping would give here
(but there might be scenarios, e.g. some web site templates to be fed by MB ,where this could/would make sense - it all depends on your use case).

Re: MB Pro shows messed up sensor data for Ecowitt WH45 5-in-1 air quality

Posted: Mon Feb 15, 2021 10:02 pm
by Gyvate
Sorry, I don't get your point .... :shock:
First of all, where do you want to upload your sensor data to ?
E.g. I am uploading the CO2 sensor data, the data of the two WH41 sensors I have, 5 WH51 Soil Moisture sensor data, 5 WH31 extra temperature and humidity sensor data (out of 7, limitation is only on the Meteotemplate end), even one lightning sensor data (out of three, but the limit here is not Meteobridge but Meteotemplate) to Meteotemplate.

When you upload data using a http request (or FTP upload), you define the upload and the sensor descriptors you use.
That's different from the pre-configured uploads to the Weather Networks like WU, AWEKAS, .....

I can give you the example of the upload (published by me already in several posts in this forum) to Meteotemplate:
- and no mapping done !! - why/what for would I do this ??

http://mysite/myfolder/template/api.php?U=[epoch.1:]&T=[th0temp-lastval.1:]&TMX=[th0temp-max5:]&TMN=[th0temp-min5:]&H=[th0hum-lastval.1:]&P=[thb0seapress-lastval:1]&W=[wind0avgwind-lastval=kmh:1]&G=[wind0wind-lastval=kmh:1]&B=[wind0dir-lastval:1]&R=[rain0total-daysum:--]&RR=[rain0rate-lastval:1]&S=[sol0rad-lastval:2]&UV=[uv0index-lastval:1]&TIN=[thb0temp-lastval.1:]&HIN=[thb0hum-lastval.1:]&T1=[th1temp-lastval.1:]&H1=[th1hum-lastval.1:]&T2=[th2temp-lastval.1:]&H2=[th2hum-lastval.1:]&T3=[th3temp-lastval.1:]&H3=[th3hum-lastval.1:]&T4=[th4temp-lastval.1:]&H4=[th4hum-lastval.1:]&SM1=[th20hum-lastval.0:]&SM2=[th21hum-lastval.0:]&SM3=[th22hum-lastval.0:]&SM4=[th23hum-lastval.0:]&SM5=[th24hum-lastval.0:]&L=[lgt0energy-lastval.0:]&PP1=[air0!0pm-lastval:2]&PP2=[air0!1pm-lastval:2]&PP3=[air0!4pm-lastval:2]&PP4=[air0!5-lastval:2]&CO2_1=[data4num-lastval:2]&PASS=mypassword

the data arrive and are stored in the respective database fields - all fine.

the Meteotemplate acronyms for better understanding
PP1 = PM2.5 #1 = WH41 (1)
PP2 = PM2.5 #2 = WH41 (2)
PP3 = PM2.5 = WH45
PP4 = PM10 = WH45
CO2_1= CO2 = WH45
(I am repurposing PP4 at the Meteotemplate end as there is no PM10 field in the database)

This is an example for Meteotemplate. But in order to see what you might need, I would first need to know your use case, your scenario.

Any upload with Meteobridge to a server, template, ... would go by the same principle, even if you use text files like realtime.txt or clientraw.txt which you send by FTP.

Mapping, as I understand it, I would do, if I wanted to camouflage data, present a physical sensor under a different name - extremely spoken - send e.g. a temperature value as humidity, or send the data of an extra temperature sensor (WH31) as the outdoor temperature sensor data (WH32) - but I still don't see why I would do this with my WH41/WH45 data. However, without an example and use case description from your end there is a lot of space for talking across purpose.