Just wanted to let you know of options. There's also the Davis lineup and they have ways to integrate local as well.
BTW in the last several years this is the first big outage I'm aware of with Ambient Weather API.
thank you for the info!!! I am sure it will start working at some point. I have seen the illuminance jump up to just under 1000 at times today, but it is clear and sunny, so I think it should be much higher. I was trying to use simple lighting to write a rule that if the sensor shows under 10000, turn on lights, but if it was 0, leave them alone... but I really cant figure out how to do it.
if luminence is less than 10000 but not 0, then turn on lights. Seems easy, but cant figure it out in simple lighting app or rule machine.
Now that I can't help with. I'm not vested in the details or nuances of HE automations so somebody else will have to step in for that.
i figured it out... I am real new so it took a while to figure out that I could use conditions...
I have light to come on if sensor shows less than 10000, but only if the same sensor shows not equal to 0, and the time is between 8am and 4pm. HE is really a useful hub.... loving it...
When it comes time for a new station, those will definitely be at the top of my list. But for now, this one works "mostly" and the API portion they can make more reliable. I do not have anything critical based on it... But I did use it to turn off our Christmas inflatables when the wind got too strong. Something I wanted to do since I first started on HA, this year I finally could with the combination of Ambient and Hubitat. Only triggered once, but it proved it works.
Just got an Ecowitt GW1000 gateway with a couple extra sensors and it turned out that getting it to work locally was easier than I had anticipated. I used your AmbientWeather driver with an extra function and configured the GW1000 gateway to send its data directly to HE.
First the configuration for the gateway:
This is the customized "Weather Services" sub-menu of the WS View app. Protocol is set to Ecowitt, Server IP is my hubitat node IP, Path doesn't really matter, although I think I might have had problems when I left it empty, not too clear on that. Port needs to be 39501, I set the upload interval to 16 seconds for testing, it doesn't go lower.
Second, I added the following function to the driver, needs improvement but working with my setup...:
[Update ] This code is now part of the driver release, just choose the "Ecowitt Local" option for "Which method of obtaining weather data do you want to use? " in the preferences
def parse(String description) {
def msg = parseLanMessage(description)
def body = msg.body // => request body as a string
// Building json object from string
a = body.split('&')
out = "[{"
for(i=0; i<a.length;++i)
{
b= a[i].split('=')
if((b[0] == "PASSKEY") ||(b[0] == "stationtype")||(b[0] == "dateutc")||(b[0] == "freq")||(b[0] == "model"))
{
out = out + '"' + b[0] + '":"' +b[1] +'"'
}
else
{
out = out + '"' + b[0] + '":' +b[1]
}
if(i<a.length-1)
{
out = out + ','
}
}
out = out + "}]"
def slurper = new groovy.json.JsonSlurper()
json2 = slurper.parseText(out)
ParseWeather( json2 )
}
Third is the driver configuration for communication with the GW1000 (after adding a virtual device specifying the AmbientWeather as the "type" of the device):
I just entered the MAC address of the Gateway in the Device Network Id field in uppercase and no punctuation (from the WS View app or the HE logs after it starts sending data)
That is it, no polling necessary and it is all local.
1 Like
I can see about adding the function right into my driver and having it check that method when not using the API.
2 Likes
That would be nice.
Ok. Posted v0.92 of my AmbientWeather driver. It now includes what I THINK should work for your Ecowitt, if you can give it a shot. Just select the Ecowitt Local method of obtaining data. 
Unfortunately I cannot test this myself since my station cannot perform it... but it does not appear to impact the normal Ambient API code at all, so everyone should be able to use it without issue.
As a note, I made it so that if you select the Ecowitt Local method, it will hide the fields for the Personal API Key and Refresh Rate...
Works great, thanks, You could also hide the MAC address, it is just confusing to people trying to set the GW1000 MAC address, just experienced it in another thread an hour ago...
Good point. I will build that into 0.92... doubt many people had a chance to copy it yet... and done.
Great, thanks again.
I was wondering why loading the device page for the ecowitt was taking so long (>10sec) now compared to this morning... I just noticed there are 18719 events logged on the device 's events page...
You said you had it set for 16 seconds? That means 225 data pushes from the weather station every hour. If yours has sensors like mine and reports back 25 items, you would get ~5,625 events an hour... Ouch.
Yea, not great, I will probably remove the device and put it back to clear it...and increase the 16 seconds value... I wonder if it would be worth my time looking into sending events only when values change by a certain amount.
That could help with the events, although the Hubitat will still be receiving an awful lot of data. Made me think about mine a bit... since I would be over ~7K events a day with a 5 minute polling interval. I have generally found that to be plenty for monitoring most cases.
What would be best is if there was a way to set those limits at the weather station, so it would only notify you if something changed enough but it would notify you right away. Otherwise it would need to send a status FAR less frequently.
Yes, that would be ideal. I could always setup an intermediate node to do that work at 16sec and update the HE only when needed but that defeats the simplicity of sending it directly to HE and I don;t want that, oh well...
I will try to give it some thought, but I do not expect an easy fix for this one without custom code. It would have to give people the ability to set a range to notify them, up or down, for almost any attribute... but at the same time I have no way of knowing which attribute their station actually makes use of.
I used to get around that on my Neptune Apex driver by allowing people to set a warning range for a few fields EVERYBODY would have (like temperature and pH), but it was a bunch of added preferences and not one person complained when I removed that ability.
Trying to help someone with moisture meters connected to the GW1000 and they were showing with names different/new from your driver ("soilmoisture" and "soilbatt"). Not sure if it is Ecowitt specific or not? Here is the log:
dev:2202020-01-30 12:55:08.560 pm debug[mac:B4E62D75A987, ip:c0a8011e, port:369b, headers:[POST /aaa HTTP/1.1:null, Connection:close, Host:192.168.1.29, Content-Length:333, Content-Type:application/x-www-form-urlencoded], body:PASSKEY=9EE87E64EF742F7FF9BCB78997394207&stationtype=GW1000B_V1.5.6&dateutc=2020-01-30+17:55:06&tempinf=77.7&humidityin=16&baromrelin=29.811&baromabsin=29.811&soilmoisture1=23&soilmoisture2=0&soilmoisture3=0&soilmoisture4=42&soilmoisture5=0&soilbatt1=1.6&soilbatt2=1.5&soilbatt3=1.6&soilbatt4=1.6&soilbatt5=1.6&freq=915M&model=GW1000, header:POST /aaa HTTP/1.1 Connection: close Host: 192.168.1.29 Content-Length: 333 Content-Type: application/x-www-form-urlencodedYes, the Ambient API does not have those. It references SoilHum (Soil Humidity) and just Batt1-10 (each addon sensor, 1 to 10, has a battery value listed).
Ok. Try version 0.93 out for them. It will still list soilhum1... and batt1... but it will put the values from soilmoisture1 and soilbatt1 in those instead. So this should only be a problem for people having both types being reported from the same thing. Hopefully not going to happen. If it does, I will have to create that additional 20 attributes and so on...
1 Like
