Questions about Ecowitt GW1000 Gateway and Ambient Weather Station

I'll wait until t hey are available through normal channels...

Yowser, it sure as heck does...and as a result it gives me pause supporting it. Will have to look further. I HATE the rampant and blatant IP theft that goes on.

As far as Kickstarter, I hear yah....and wouldn't have given it a second thought without it being a familiar name and success story.

That's all I really have to go on as well, what they have said on the kickstarter page.

For the little I have done on the drivers since taking over their development, from what I have seen there is not an API as such. The gateway pushes the data to an HTTP endpoint, in our case being the the HE hub, which the virtual device looks out for, parses the information and records it.

From what they have indicated on the kickstarter page, the format of the data sent from this new weather station is compatible with the existing EcoWitt services, like their web site, the WS View App, etc. So I would expect it to work like the existing gateway's and consoles people are using.

BTW - It is actually made by the same people, at least it is on the EcoWitt facebook page. I looked up the GW1100 Gateway and followed the link from there to their FB page and the first thing they bring up is a post about the WittBoy project.

I can't say I have had any dealings with the company directly, aside from having purchased my weather station. It is certainly promising to see them continue to develop their product line.

1 Like

Interesting. I’m definitely interested but I think I’ll wait for the retail release.

Thanks for taking the time to look into it, explaining some stuff, and making a judgement call.

At this point I'm less worried about it being a kickstarter than i am about how blooming similar it is to the WeatherFlow Tempest as @snell noted. I suppose WittBoy could be shut down if it is infringing patents. That isn't always easy to affect as we know that slight changes can make it indefensible.

Anyway, thanks!

Addendum for general interest:
(WS View Plus for HA integration)

1 Like

I purchased Ambient Weather WS-5000 and several sensors. I pasted the snell code for the device and changed the API Key. I created application API key on Ambient Weather.net and put that in driver code. What is Personal API Device page I created?

As I understand, this polls AmbientWeather.net. What do I need to change to make it poll the WS-5000 locally?

I might need to call on @snell to clarify some of the differences. The EcoWitt Gateway driver accepts data from EcoWitt gateways locally, but I am not sure about the WS-5000.

Does anyone else have experience with WS-5000 devices?

I do not have the WS-5000, just an old WS-2902A with new firmware (and an Ecowitt Gateway). But I can compare a bit between the methods now supported in my driver:

  1. Ambient API - Must be connected to the cloud, requires you to get a Personal API key from Ambient and the MAC address of your device. Returns a bunch of data in a fairly easy to use format.
  2. Ecowitt Local - Requires an Ecowitt gateway device and the MAC address of your gateway as the DNI for the device you add to Hubitat. You also need to configure the gateway to send data to your Hubitat using one of the apps that can communicate with it. A big plus is the additional sensors the Ecowitt can have added. Uses the exact same formatting as the API.
  3. Ambient Local - Requires an Ambient networked device with newer firmware. Once configured (very similar to the Ecowitt gateway) it will send data to the Hubitat. The initial formatting of the data is different (requires a bit of work) and some of the data attributes/values are different for some reason (even from the Ambient API) but for the most part it is similar enough.

I think the WS-5000 uses the Ambient Local method, which is now supported in my driver.

As for the Application Key, if someone is reusing my driver they do not need to get their own. If someone is reusing the basic code and making their own entirely separate driver, then I recommend they get their own Application Key. It is meant to help identify different developer applications accessing the API. If other people make changes, make a mistake that starts causing trouble for the servers, but keep my Application Key... then Ambient might come to me first instead of the correct person to fix the problem. This key is completely different from the Personal API Key you need to use the driver and is set in preferences. It is tied to your own account and weather station(s).

1 Like

OK, I have it set to the API key you have in your code, and it works using Ambient API. I added the child driver. It sees one of the added sensors (3 total including the outdoor and indoor sensors it came with), but there are 11 total. Will this just take time to populate?

No, it should not. As soon as it receives data from the API it creates whatever child devices it can determine from that data.

So... couple questions you can provide the answers in a PM if you want:

  1. What added sensors do you have?
  2. Can you provide a sample of the data returned (open a separate window/tab for the Logs section, set the logging preference of the parent device to Trace, then perform a Refresh with the parent, and copying the "Raw Data = ..." line from the logging)? That would provide a copy of all the fields returned so I can see if I am somehow mis-identifying something.

UPDATED:
Per the sample provided by @jack4 there is definitely something funny going on with the driver that I need to look into. The fields are being returned and the driver sees them... but is putting most of them in "unhandled" instead of correctly generating a sensor (even though it does for the first for some reason).

I will attempt to fix this and post the updated version in the thread for my driver.

UPDATE 2:
I found the problem... and it is rather silly on my part. There are regex checks to determine which number sensor is returned in the data fields (for example, temp4f refers to a temperature from sensor 4). When I was making changes to support the new local method from Ambient though I noticed they support up to 10 sensors. I changed the regex command to 1-10... but that is NOT how it should be. So that broke it for anything but sensor 1. I have already fixed it (in my code) to handle back to 9 and it works properly again. I will hold off publishing the fix a little longer to make sure I can handle 10 though also. But no matter what, a fix will be coming tonight (my time) for 1-9.

UPDATE 3:
Fixed driver (version 0.7.12) has been published. The regex was simple to do, once I found out how to do it. It took longer to hunt down all the possible instances AND make a sample of fake data that include a whole bunch of sensors to test with.

I am confused about Ambient Local. I have it set to Ambient API (cloud integraton). And it works well.

I simply changed it to Ambient Local and it quit updating. What are the additional steps I need to take to get the driver to poll from the local network using Amblent Local?

Just make sure the Weather Method on the Ambient Weather driver page is set to 'Ambient Local' with 'enable child devices' is turned on.. and set the Device Network ID to the MAC address of the WS-5000 console (no colons or spaces). No API key needed.

On the console itself (must be firmware 1.6.9 or later) go to the 'Setup' page, select 'Weather Server' > 'Customized', then set State to 'Enable', protocol type 'Same as AMBWeather', set the IP of your hub and port to 39501. Select your interval, if you want to change the default, and you're done,

I have the WS-5000 set up in local server mode and it works fine. However the WS-5000 itself has wifi peculiarities, at least in my environment. It's configured and runs perfectly as a Wunderground server; however I noticed that at some point (usually within two or three days) if also set up to push data to Ambientweather.net it stops responding to pings, coincident with the local server ceasing data reports to HE. Yet its Wunderground server remains online and never stops reporting Wunderground data.

If I disable Ambientweather.net reporting (via the Awnet phone app), it will keep reporting to HE for a week or more before failing; seems like some kind of resource exhaustion is happening in the WS-5000 console yet the Wunderground service keeps working. For some reason the unit also is incapable of seeing the unhidden SSID of my Verizon G3100 tri-band AX router (regardless of whether the G3100 has AX mode enabled or not). It has no issue seeing the SSID's of my Asus router (regardless of whether its AX mode is enabled or not). My WS-5000 console is HW revision 2.0. It's been updated to firmware 1.7.4 and wifi firmware 4.3.2; none of the updates have fixed these wifi issues (I see there have been multiple wifi firmware revisons so I suspect the implementation is somewhat flaky still).

I just set up an additional display console (sold as the WS-2000 Console). It's identical to the LCD unit that comes with the WS-5000 setup and apparently identical to the Ecowitt HP2551 console; it runs the same base firmware, though not the same wifi firmware-- supposedly it will not work with all Ecowitt branded sensors though I have read that the Ecowitt console will work with all Ambient branded sensors.

This new unit is identical in HW revision and wifi f/w level but came with a later base firmware level (1.7.9) than my WS-5000's console; it established connection to my WS-5000's sensors immediately (and the WS-5000 automatically generated a new child device for a freebie T/H sensor that was included with the purchase) yet for some reason would not display sunrise/sunset times on its display even when lat/long was configured; also the weather speed it displayed from the WS-80 sensor was double what the original console was displaying. I fixed that issue by going into the new console's sensor calibration; for some reason my unit (which appeared factory sealed) was set with a 2.1X multiplier for wind speed. The lack of sunrise/sunset continued to be an issue until I resorted to a full factory reset-- that got it working normally again.

I have this additional console setup without running the Wunderground server to see how long it will maintain a local data feed to HE without failing.

Thanks Tony. I did as you wrote, and it is pulling locally. We will see for how long.

1 Like

I don't think it ever pulled locally.
I think I went by these instructions in the code:

  • Setup Information - Ecowitt Local
  • On Ecowitt Gateway app
    1. Select the Ecowitt Gateway from the Live Devices
    1. Select More
    1. Select Weather Services
    1. Select Next until Customized is shown
    1. Set the Server IP/Hostname to match your Hubitat
    1. Set the Port to be 39501
    1. Set the Upload Interval as desired
    1. Save
  • On Hubitat
    1. Setup a new virtual device
  •   Type = AmbientEcowittWeather 
    
  •   Device Network ID = MAC Address of your Ecowitt Gateway, all uppercase, no : or spaces in it (ex: ABCDEF012345)
    
    1. Save Device
    1. Set method of obtaining weather to Ecowitt Local in Preferences, as well as any other desired preferences
    1. Save Preferences
  • Setup Information - Ambient Local
  • Follow the same steps as in the Ecowitt Local, except with settings for your Ambient station (ex: Ambient's MAC address)

Some screen shots:
The AWSNET app on my Android:

The hubitat devices page:




The only thing I can add (that needs to be added to the instructions the next time I update the drivers) is to leave the path as the default "/data/report/". It seems that if this is blanked out, it does not work... but I have not checked to see if it just have to have "something" in the field (since the default works... why mess with it is usually how I try to operate).

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.