Curious if anyone has upgraded to the GW3000? I’m still running on GW1000 and wondering if it would be worth it to upgrade. I’m not finding any issues with my existing gateway.
2 Likes
Doesn't look to be any killer feature, just some good incremental steps forward like the SD card option, antenna and USB type c power. In terms of general function it looks to be much the same.
1 Like
Yep, the IP address is correct. looks like some sensors have not updated to Hubitat since September!
At one point I did have it on a manual IP, but some how it isn't anymore, but the ip address still seems to be valid. In the next week I'll be removing my current network and switching to Ubiquity , so Im not to concerned at the moment, but one other oddity. the hub is a GW2000 (so has a ethernet port) and I do have it connected by therenet, but for some reason it is showing up as wireless? Any ideas there (So I dont move a proble to the new network)?
That GW3000 Antenna looks interesting. Maybe run SMA cable and connect the antenna on the outside of my shed and keep the hub inside.
2 Likes
Sma cables have a quick drop in db/foot so cannot be very long at all. I remember when i tried to put a long pigtail on an external wifi antenna
Funny I came here this evening to broach the same question about the GW3000. Not sure it’s “killer”, but the one thing that would make this a major step up for us is the removable antenna. Ecowitt told me you could detach and run it outside via coax cable.
This would help my setup immensely as we struggle with signal quality on backyard soil sensors.
Curious if…
- anyone has any reason to believe the 3000 would or wouldn’t be compatible with this integration?
- Anyone has found other creative ways to extend outdoor signal range to/from soil sensors?
Thanks…
Per Ecowitt:
“ We have a new gateway, GW3000. This gateway's antenna can be detached from the main body, and you can connect the antenna sitting outdoors with a coaxial cable. ”
I have an Ecowitt WS90/GW200 Weather Station and I'm having an issue with the Solar Battery Reading (i.e., Haptic Array Capacitor)
The Ecowitt says it's currently at 5.3 V (5.4 V is 100%), while Hubitat (via this device) says it's 44% - which is not correct. I know that the two readings matched in the past. I've rebooted the weather station and the Ecowitt hub without any change.
Any suggestions?
Edit: All other readings are accurate.
The 5.3 is not the battery that is the capacitor. The battery is the batteryorg it should be around 3.3 for 100%.
This is my ws90
1 Like
Thanks for your response. I'm sure I miscommunicated something. Here's my readings:
Ecowitt
Hubitat Device
Now, looking at my figures again, I'm perhaps still messed up.
Interesting i dont have those attributes but for you it definately looks wrong. The approach also seems wrong as you cannot really assert a battery percentage to a solar capacitor as it depends on sunlight strength and will fluctuate accordingly?
That is why i did not implement it when i coded ws90 changes. It looks like someone in the current release further changed it? @sburke781
I'll take a look
I'm a little more confused now.... 
Or it could just be the time of night... Feel free to PM me if you want to chat about it some more that way...
The first entry for ws90cap_volt would produce the Capacitor Voltage attribute reading of 5.3, but I then can't see how the later ws80 and ws90 capacitor voltage case statements would get triggered...., which I expect are the only parts that would produce the solar attributes.... With the 2.5 solar voltage reading also being odd... Will keep looking at it, including timing of changes to the code and whether that could be at play....
case ~/ws90cap_volt[1-8]/:
case "ws90cap_volt":
state.sensor = 1;
updated = attributeUpdateCapacitorVoltage(val, "capacitorVoltage");
break;
case ~/ws90_ver[1-8]/:
case "ws90_ver":
state.sensor = 1;
updated = attributeUpdateString(val, "ws90Firmware");
break;
case ~/batt[1-8]/:
case "wh25batt":
case "wh65batt":
state.sensor = 1;
updated = attributeUpdateBattery(val, "battery", "batteryIcon", "batteryOrg", 0); // !boolean
break;
case ~/batt_wf[1-8]/:
case ~/leaf_batt[1-8]/:
case ~/soilbatt[1-8]/:
case ~/tf_batt[1-8]/:
state.sensor = 1;
updated = attributeUpdateBattery(val, "battery", "batteryIcon", "batteryOrg", 1); // voltage
break;
case ~/pm25batt[1-4]/:
case ~/leakbatt[1-4]/:
case "wh57batt":
case "co2_batt":
state.sensor = 1;
updated = attributeUpdateBattery(val, "battery", "batteryIcon", "batteryOrg", 2); // 0 - 5
break;
case "ws80cap_volt":
case "ws90cap_volt":
state.sensor = 1;
updated = attributeUpdateBattery(val, "batterySolar", "batterySolarIcon", "batterySolarOrg", 3);
break;
@lflorack1 - Do you happen to have a WS80 - Ultrasonic Wind Speed & Direction, Solar Radiation & Light, Temp & Humidity Sensor Array?
EDIT - If you are unsure, feel free to PM a copy of the trace log output from the gateway feed, including messaging me on how to do this...
1 Like
Nope. I have the Wittboy Weather Station GW2001 'package' - which includes:
- GW2000 Wi-Fi IoT Hub
- WS90 7-in-1 Outdoor Solar Powered Weather Sensor
1 Like
Thanks. Perhaps for my own sanity ( )it would help if you could turn on trace logging and send me a PM of the log output? Let me know if I need to explain that process some more... (likely tomorrow if I need to)
I agree .. i dont see how that could be coming out and in addition that last ws90cap_volt is not needed as it is dead code. Did i add that? if so i fcked up.
I'm going to check if maybe there is another ws90 firmware update. By the way there just came out a update for the gw1100b ver 2.4.0
1 Like
Lol... I still need to do the forensic analysis of who did what and conduct the necessary investigation.... My legal team will be in touch... 
(Every chance that could be to offer an apology... )
1 Like
Thanks
could you have an older version of the code.. there was one point where i did a change and was missing a break statement in the code which could cause the behaviour you are seeing.
1 Like
