It is a sweet little device.....I like the built-in web server. I was amazed at how small it was. I was expecting a larger box.. Thanks again for your help!
@snell Everything is working perfectly! Thanks for your app and all of the assistance in getting it up and going. A couple of quick questions.
-
Does your app report the values/attributes from remote sensors on the GW1100 like lightning or soil moisture?
-
I want to use the rainrate value as a trigger for a rule. I noticed that it is being returned as a "null" value when it is not raining. Unfortunately I can't find a way to evaluate the "null" value in the trigger only a zero which doesn't evaluate the same. Is there a reason that when it is not raining that the value is not zero instead of null? See attached...
Glad it is mostly working... Barring the rainrate weirdness. As for the answers:
- Yes! I have both a lightning sensor and a soil sensor, and they are both reported. As well as a PM2.5, Leak Sensor, and a couple others.
- It sounds like it has not received a value. Drivers cannot dynamically create attributes so I have to list them all. If no value has been received for that attribute it will generally NOT show up in the Current States list for the device in question BUT it will still be available in Rules or other apps (and will have a value of null). One thing to check for is whether there is a State Variable "rainratein" listed for the device. That is the actual field reported by the GW and I pop it as a state variable although those are not usable in apps. My GW does not appear to report it (it may be an Ambient API only item). Alternatives to it could be eventRain or hourlyRain (I see those listed on my device).
Let me know if that helps!
@automation - I'm assuming you have transitioned to the updated drivers I re-released. Has it rained since you made that transition? It has rained recently for me and I can see a rain rate of zero when I try to use that state variable in a trigger:
I expect it is going to be more in my court to sort out with the EcoWitt driver than something for @snell to solve in the Ambient Weather app / driver, though all help is welcome 
I am currently using @snell driver that takes data directly from the Ecowitt gateway. Now that I have the issues resolved with the AmbientWeather vs Ecowitt issues, I may re-install your driver and take it for a spin....
1 Like
Have you guys seen this ? Totally new integrated sensor package in the works w/ a GW2000 hub.
Yes, the local API is always the same for GW2000 and GW1100.
1 Like
Wow. That looks pretty cool. Buy one and give us a full report
well, I'm half way there....just looking for the folks that know the HE "back end" stuff and Ecowitt's track record (as a development team) and the simplicity of the API to weigh in on the likelihood of the GW2000 API being the same as the GW1000 which they're familiar with. Ecowitt says it is.
Honestly I might get one regardless. I just need to find a good place to mount it.
To me it looks like a less-fancy WeatherFlow Tempest.
I used to back a lot of projects on Kickstarter... almost never anymore and definitely not one outside the US. Been burned almost every time a project was overseas for me.
But good luck and let us know how it works if you get one!
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:
- 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.
- 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.
- 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:
- What added sensors do you have?
- 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.
