Page 2 of 3
Re: Ecowitt GW-1000 suggestion
Posted: Tue 10 Mar 2020 9:59 am
by zoomx
Yesterday I seached in CumulusMX and tested some modification in order to copy chosen external sensor data into main channel. No interface, only cumulus.ini modification
In GW1000Station.cs
Code: Select all
case 0x1A: //Temperature 1(?)
case 0x1B: //Temperature 2(?)
case 0x1C: //Temperature 3(?)
case 0x1D: //Temperature 4(?)
case 0x1E: //Temperature 5(?)
case 0x1F: //Temperature 6(?)
case 0x20: //Temperature 7(?)
case 0x21: //Temperature 8(?)
chan = data[idx - 1] - 0x1A + 1;
tempInt16 = ConvertBigEndianInt16(data, idx);
DoExtraTemp(ConvertTempCToUser(tempInt16 / 10.0), chan);
if (chan == cumulus.Gw1000MainChannel) {
DoOutdoorTemp(ConvertTempCToUser(tempInt16 / 10.0), dateTime); //zoomx
}
idx += 2;
break;
case 0x22: //Humidity 1, 0-100%
case 0x23: //Humidity 2, 0-100%
case 0x24: //Humidity 3, 0-100%
case 0x25: //Humidity 4, 0-100%
case 0x26: //Humidity 5, 0-100%
case 0x27: //Humidity 6, 0-100%
case 0x28: //Humidity 7, 0-100%
case 0x29: //Humidity 9, 0-100%
chan = data[idx - 1] - 0x22 + 1;
DoExtraHum(data[idx], chan);
if (chan == cumulus.Gw1000MainChannel) {
DoOutdoorHumidity(data[idx], dateTime); //zoomx
}
idx += 1;
break;
In Cumulus.cs
Code: Select all
3210
// GW1000 setiings
Gw1000IpAddress = ini.GetValue("GW1000", "IPAddress", "0.0.0.0");
Gw1000AutoUpdateIpAddress = ini.GetValue("GW1000", "AutoUpdateIpAddress", true);
Gw1000MainChannel = (byte)ini.GetValue("GW1000", "MainChannel", 0);
3775
// GW1000 settings
ini.SetValue("GW1000", "IPAddress", Gw1000IpAddress);
ini.SetValue("GW1000", "AutoUpdateIpAddress", Gw1000AutoUpdateIpAddress);
ini.SetValue("GW1000", "MainChannel", Gw1000MainChannel);
4849
public string Gw1000IpAddress;
public bool Gw1000AutoUpdateIpAddress = true;
public byte Gw1000MainChannel = 3
Numbers are line numbers in code just to reach easily the right place.
On first launch nothing happens, just close CumulusMX and you will find the new key in cumulus.ini
MainChannel=0
Just change the zero with other channel. No check for channel >8 (or negative) but simply they will not work. Maybe negative will raise an error.
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Thu 02 Apr 2020 4:11 pm
by Sadgit
I didn't want to start a new thread and my outside lux sensor has died.. and waiting delivery of a Ecowitt 1000 with various sensors including this one
WS80 - Ultrasonic Wind Speed&Direction, Solar Radiation & Light, Temp & Humidity 6-in-1 Sensor
Does Cumulus report on the LUX levels from the WS80 please?
Cheers
Mark
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Thu 02 Apr 2020 4:33 pm
by mcrossley
You'll need an Ecowitt person to answer that - it may be better to ask over on the wxforum. But if the GW1000 reads it, Cumulus should report it.
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Thu 02 Apr 2020 7:20 pm
by Mapantz
I have never seen it reported on Ecowitt's dashboard - owners of the WS80. I don't know if it even shows up on the console, as there's no room for it.
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Mon 06 Apr 2020 1:47 am
by galfert
mcrossley wrote: ↑Thu 02 Apr 2020 4:33 pm
You'll need an Ecowitt person to answer that - it may be better to ask over on the wxforum. But if the GW1000 reads it, Cumulus should report it.
Mark,
Cumulus could make use of Lux data from the GW1000 if you wanted. The Lux data would be 0x15 and it is 4 bytes long.
These Fine Offset station really only have one sensor that is used for both Solar Radiation and UV. This sensor is a Lux sensor. The station then applies a predetermined formula to Lux to then end up with a value for both Solar Radiation and UV. The Solar Radiation is 0x16 (2 bytes) and UV is 0x17 (1 byte).
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Mon 06 Apr 2020 8:28 am
by mcrossley
Thanks, CMX does already pick-up the light (it converts lux to W/m2) and UV-I, which why I said if the GW1000 picks up the values Cumulus should use them. But maybe I should have said "will use them"
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Mon 06 Apr 2020 10:42 am
by galfert
Interesting that you chose to go through the extra work of converting Lux to Solar Radiation and UV instead of picking those up directly. I would have done it the other way around and then benefit from the GW1000 and it's ability to calibrate both Solar Radiation and UV. If CMX only picks up Lux and does its own conversions then the calibrations don't take effect.
Some people are noticing that both Solar Radiation and UV are high and they want a way to adjust these.
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Mon 06 Apr 2020 1:09 pm
by mcrossley
According to the Ecowitt documentation they do no provide a W/m² value? Just Lux, UV in micro Watts/m² and a UV-I
Not sure what use the UV in µW/m² is though!
0x15 = Lux
0x16 = UV (µW/m²)
0x17 = UV-I
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Mon 06 Apr 2020 1:39 pm
by galfert
0x16 (2 bytes length) is Solar Radiation, it is just returning µW/m² instead of W/m². You just have to move the decimal place. It is poorly labeled. I've read the documentation and it could certainly benefit from a lot of improvements. You can see from other parts of the documentation that it mentions solarRadGain as an adjustment, showing that it does have Solar Radiation.
0x15 Lux is just the raw sensor data with no calibration.
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Mon 06 Apr 2020 1:54 pm
by mcrossley
So you divide the supplied value by 1000000?
Seems an odd unit to choose!
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Mon 06 Apr 2020 3:04 pm
by galfert
Yes.
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Mon 06 Apr 2020 3:28 pm
by mcrossley
Hang on that is a two byte field, so unsigned the max value is 65536, as the max W/m² is around 1200, it must be divide by 10? Which would make a more sensible unit, so the actual supplied units are deci-Watts. The documentation is doubly wrong in that case!
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Mon 06 Apr 2020 6:52 pm
by zoomx
I read that there in no UV sensor and that UV and solar radiation are derived from Lux.
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Mon 06 Apr 2020 7:35 pm
by galfert
mcrossley wrote: ↑Mon 06 Apr 2020 3:28 pm
Hang on that is a two byte field, so unsigned the max value is 65536, as the max W/m² is around 1200, it must be divide by 10? Which would make a more sensible unit, so the actual supplied units are deci-Watts. The documentation is doubly wrong in that case!
Yes that sounds about right, although I haven't actually tested it myself.
Re: Ecowitt GW-1000 suggestion - added b3067
Posted: Mon 06 Apr 2020 9:58 pm
by galfert
Okay I've finally had a chance to do some testing with 0x16 (2 bytes unsigned). I just can't get it work.
I did get an email from Fine Offset engineer that said:
The received solar data is in 0.1lux unit. You can convert it to w/m2 by dividing 1267.
The UV data is in uw/cm2
Seems to me like although you should be able to convert µW/cm² to W/m², the results just don't make sense to what I see in WS View app live data.
Either way it seems like the documentation on 0x16 is not well documented as it clearly says, "#define ITEM_UV 0x16//UV (uW/m2) 2" and that doesn't agree with what the FO engineer is saying.
I say forget it and just stick to Lux and convert it W/m² as you have been doing. I do hope that you are using the 126.7 conversion factor to do this:
https://help.ambientweather.net/help/wh ... tor-126-7/