Well, that will give other people another option. Thanks for letting everyone know another option.
Hi there. New to hubitat and also to installing drivers, and ambient weather (I have 2902A). I installed the driver just yesterday. After installing it, illuminance was running about 19000 (partly cloudy day). Overnight, we had rain and then today, partly cloudy again but the illuminance sensor is reporting 0. I have reinstalled the driver, and I have rebooted the weather station, but I still am only getting 0. Is it my weather station or is it the driver? Help would be appreciated! Love the drivers and the community for helping me get a new hobby...
The last time it appears to have data for (date) is 3:45am... so it would be dark then I assume. Do any of the other values change when you run a refresh? This is only looking directly at the data reported by the API so there could be other factors such as:
- Your weather station is not reporting to the API (or has not recently).
- The API is not reporting newer data (API problem).
One thing you could do is turn on the "Debug" logging level. In the logs you will see the entire batch of data as reported, or an error if the API did not pass anything. You would want to select the Debug level, Save Preferences, open the log (in a separate tab works best) then Refresh. I do not recommend leaving the Debug logging level running constantly. It can get long.
I noticed on my web app that there is a message on top stating "we are experiencing Cloudant issues. They will be resolved shortly". On the ambient webpage, UV is updated correctly, so I think it is leaning to be an API issue. I did try a new API and no luck.. When I refresh, I do see many of the fields update. I notice UV, solar radiation and iluminance not updating. I am in the central timezone, and I thought that the station reports UTC.
I turned on debug and the following is what was reported... thank you for responding so quickly!!
dev:2772019-12-29 02:38:48.278 pm debugWeather - [[tempf:68.9, date:2019-12-29T03:45:00.000Z, totalrainin:0.378, feelsLikein:75.4, lastRain:2019-12-29T03:45:00.000Z, dewPointin:59.6, monthlyrainin:0.378, dailyrainin:0.378, solarradiation:0, humidityin:58, humidity:97, maxdailygust:25.1, uv:0, windspeedmph:2.5, winddir:275, hourlyrainin:0.945, eventrainin:0.37, baromabsin:29.711, dewPoint:68.01, tempinf:75.4, battout:1, feelsLike:70.05, dateutc:1577591100000, windgustmph:3.4, baromrelin:29.634, weeklyrainin:0.378]]
dev:2772019-12-29 02:38:48.270 pm debugWeather - 26 fields from AmbientWeather
dev:2772019-12-29 02:38:47.460 pm debugWeather - Getting data from MAC Address: A4:CF:12:A0:38:06
dev:2772019-12-29 02:36:49.953 pm debugWeather - [[tempf:67.6, date:2019-12-29T04:11:00.000Z, totalrainin:0.52, feelsLikein:75.4, lastRain:2019-12-29T04:08:00.000Z, dewPointin:59.6, monthlyrainin:0.52, dailyrainin:0.52, solarradiation:0, humidityin:58, humidity:94, maxdailygust:25.1, uv:0, windspeedmph:3.8, winddir:218, hourlyrainin:0, eventrainin:0.512, baromabsin:29.711, dewPoint:65.81, tempinf:75.4, battout:1, feelsLike:67.6, dateutc:1577592660000, windgustmph:4.5, baromrelin:29.634, weeklyrainin:0.52]]
dev:2772019-12-29 02:36:49.939 pm debugWeather - 26 fields from AmbientWeather
dev:2772019-12-29 02:36:49.301 pm debugWeather - Getting data from MAC Address: A4:CF:12:A0:38:06
--- Live Log Started, waiting for events --
I can confirm the same issue with UV and illuminance.
1 Like
I would say that Ambient's servers/API are the culprit at this time.
What is REALLY strange to me about the data returned is the date and dateutc returned. The "older" one, from 02:36...pm in your look is actually a NEWER time (~04:11) compared to the log entry at 02:38 (~03:45). That also seems to point to some issue with their API.
Just checked on my own and there is DEFINITELY something weird going on with Ambient. The date in the logs is not in any expected sequence and one result even came from yesterday! The returned values also look strange as the outdoor temperature went up substantially... and it is night and cooling off here right now. My app ONLY queries for the most recent data. I do not request historical data at all... so they must be returning the wrong info.
On a different note:
Illuminance is not returned by the API but is calculated from Solar Radiation. So if that is 0, Illuminance will be 0. In fact, you can see every field returned from the API in your debug data! When set for debug I let it throw the entire returned array into the log.
1 Like
Mine is set to query every 5 minutes... Here are the date values I have gotten back over the last 20 minutes (oldest query first):
date:2019-12-29T05:30:00.000Z
date:2019-12-28T22:40:00.000Z
date:2019-12-29T10:25:00.000Z
date:2019-12-29T05:30:00.000Z
As a note... it is almost 8pm EST on the 29th for me... so if it was a recent data push it should have been something like 2019-12-30T00:30... or something to signify that it is the 30th (since the date data of the server is based on UTC, which is 5 hours ahead of me).
1 Like
Well, I hope they fix it...for what I wanted to do, not having the UV, solar radiation and the illuminance reporting to the API, will be the end of my little smart home task....
thanks for looking into it though!
M
I'm not sure if a app exists yet for HE but you may want to look into the EcoWitt PWS systems. They can be used completely local with no external API or internet access required.
thanks for the recommendation, but I just received this station as a gift and it will suit my needs. The driver for the HE was just a bonus, I can work around the problems...
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...
