The combined sensor list was from what some users reported a long time ago. I cannot remember if it was for Ecowitt (maybe?) or not.
You know... it never occurred to me that battsm is "battery soil monitor"... because there has been soilbatt as a separate one returned. I just thought (since both have been in there forever) that it must have been something for a future sensor type.
So what is going to happen is I will combine those two (like soilhum and soilmoisture). Should be done in a few minutes here as it really does not change the code much...
Thanks!
Updated Version(s):
AmbientEcowittWeather.groovy = 0.7.17
Change(s):
Combined soilbatt and battsm readings into a single "soilbatt" section similar to soilhum and soilmoisture
Change to the driver version checking to match up to my "latest" style. The driver will now also update the version (but not the status message) when someone saves preferences (so it is an easy way to "make sure" of your version)
I wonder what is returning soilbatt#? It's not list in either API document. I don't see it being sent from my device.
battsm# returns 0 (bad) or 1 (ok), so shouldn't it be using BatteryValue()? (rather than the math originally in place for soilbatt#)
With this latest change, my soil batteries went from 75 (with my change) to 66.67 (with the math). And on the main device, I now have "soilbatt1 : 1.0" (note the decimal) because line 953 casts it as a float.
That would likely be another oversight on my part about the math darn it. Probably why I had them separate. Yet another fix I will have to do tonight. I think Soilbatt is Ecowitt. I actually HAVE one of those.
Updated Version(s):
AmbientEcowittWeather.groovy = 0.7.18
Change(s):
Separated the soil sensor battery data again but made the battsm so it goes to the Soil Sensor as well as some corrections to the two
Noticed an error with soil temp so that is corrected
Added and removed a number of attributes that were either not included (additional batteries for example) and removed duplicates
Updated attributes to remove temperature specific reference. For example: an attribute name could be temp1f even though the actual value was being converted to whatever the Hubitat is set for so it could be a Celsius value, therefore they are now named along the lines of temp1
Note(s):
Sorry all for so many updates lately
Just for general knowledge, soilbatt is returned by the Ecowitt Local method (confirmed with my device after making the changes)
@snell , thanks so much for all your great work here. I'm using 0.7.18 with the Ambient API. Things generally work very well except that I'm sometimes getting the wrong data back from the humidity event. Randomly, I'm getting the external humidity instead of the internal humidity - I have both switches for temp and humidity off. I've even gone in and commented out code so that humidity is always set to humidityin. Still, once in a while, humidity is set to humidityout. Have you seen this behavior before?
Well, I have not seen it myself but I really do not look at the states THAT frequently. Despite having multiple weather-related drivers I am not much interested in whether stuff.
So... There are a variety of factors that could affect it:
You already mentioned you are using the API method not the Local one, so that is one question out of the way.
Do you have it set to Report outdoor humidity in your device preferences? That is the default.
Do you have any additional sensors or soil moisture sensors?
#3 really should not matter as extra sensors would only ever set humidity for their child devices (if enabled) not the parent device.
There are only two spots in the code that will actually process the humidity event to put it on the parent device, lines 712 and 719 (lines 707 to 721 handle humidity and humidityin reports).
Thanks, yes, I have the preferences set for indoor humidity, which it does report most of the time. No add'l sensors. I changed the triggers to work directly off of the humidityin attribute. This seems to be operating more slowly, but it's reporting the correct numbers.
Weird. As you probably saw when trying commenting out stuff, the code is pretty simple. I hate to say it... but if you enable Trace logging (which will dump a TON of stuff) then look at the logs the next time it happens... One possibility is maybe bad data from Ambient? It would be interesting to see if there is some weird "flip" in the humidity reported.
Did there seem to be any particular frequency to it?
I'm pretty sure it's not your code. As you said, relatively simple and very clean. As I mentioned, I even commented out all code that might be changing humidity and just set it to humidityin. No joy. The problem frequency is low. Just a couple of times a day. I'll track the logs and report back. I really appreciate how responsive you've been.
I will make an edit to mine to have it flag if there appears to be a "flip" of the values reported. It would stink if it is something coming from the API but at least then we could let them know it is doing something weird.
Finally looked at a full trace on this humidity thing. It's interesting that the "event" humidity moves from humidityin to humidityout and back to humidityin. This doesn't seem to be happening for other variables.
Well, that is all part of one data push so I cannot see how it is an API-side thing. Not sure how it is happening but I will have to find a way fake it on my side and see if I can figure out a fix.
Thanks for this, it helps... The really odd thing is the 67% humidity BEFORE the humidityout... since it should get the humidityout and set that before it sets the humidity, but only based on the Preferences. For some reason it is acting like the preference is not set maybe? Not sure. Either way, something for me to dig into.
EDIT: Found the bug... I feel really silly having missed it... the problem was that outdoor humidity is reported as "humidity" and indoor humidity is reported as "humidityin"... but in almost all cases I post an event based on what the key is so it was using the humidity key. Basically duplicating. So I changed it so that it now calls it humidityout for that specific event.
I also moved the check for which humidity to report towards the end once all the data should be in, rather than while it is running through it.
Updated Version(s):
AmbientEcowittWeather.groovy = 0.7.19
Change(s):
Indoor Humidity should be properly reported and not overwritten by outdoor humidity when that preference is selected.
Excellent. Thanks. I'll try it out. Silly question because I'm new to Hubitat, do I move to the new version by just overwriting with the URL or is they a better way of doing it?
Also, the existing link is still pointing to 0.7.18, unless I'm doing something wrong.
There are two methods. The easiest/most common is to use the Import button from the driver code page. The second is to use the link and copy/paste the driver code onto the driver code page.
The link points to the overall driver, there is not separate naming for versions for any of my drivers (it would just become too much overhead for me).
The only "gotcha" some people hit upon is that their browser (I have had it happen also) will cache the driver. So you may import or copy/paste, but if you recently gotten the driver or updated it you might get the "old" version your browser cached. The workaround to this is to refresh the driver's page.
Once you update, all my drivers check daily for any further updates. But many of them ONLY check daily. So you may still see an update notice until it performs the check the next day. Some of my drivers (including this one) will update the Driver Version state when you Save Preferences (as a way for people to double check).
Hello. I am very interested in getting my AmbientWeather data into my hubitat (I am currently using IFTTT...gets the job done but this would be better). Can someone give me instructions for setting up an AmbientWeather device? I have read the setup instructions posted in the code for an Ecowitt device and read that AW instructions are the same, but I don't know where to start. I don't see a place in my AW app where it would allow me to share the data locally.
Using the awnet app (Android, I do not know if it is the same with an iPhone app):
Select you Ambient Weather station from the device list (it should open the "AmbientWeather . net" screen. Perform any firmware updates if it says there is one.
Select the Next button in the top right, keep selecting it until you get to the "Customized" screen.
Enter the IP/Hostname of your Hubitat as the Server IP/Hostname, leave the Path as "/data/report", set the Port to be 39501, and set the Upload Interval (the default 60 seconds is usually good) then select the Save button.
Select the Finsh button in the top right.
Keep the app open, you will need the MAC address of the station shortly...
At this point your Ambient Weather station is sending data to the Hubitat. The rest of this is performed on your Hubitat, you need to select your driver of preference, and since you are posting in my project thread, we will use mine as the example.
Load both the parent driver (AmbientEcowittWeather.groovy) and child driver (WeatherSensorChild.groovy) onto your Hubitat.
Add a new Virtual Device for your Hubitat.
Set the Virtual Device's type to be AmbientEcowittWeather (bottom of the driver list most likely), enter a Device Name, and set the Device Network Id to be the MAC address of the station, but without any ":" in it. Ex: DC4F22590101. Then select the Save Device button.
Once the page refreshes you should see a number of Preferences listed for the device. The REQUIRED one is to set the Weather Method to "Ambient Local" in this case. I also recommend enabling the "Enable Child Devices" so it splits up the data between various sensors. Then select the "Save Preferences" button.
At this point it should be done and working. Once it receives data from the weather station (~1 minute or so) it should start populating the data for the device(s).
Hey, just to doublecheck...can someone confirm that the "weeklyrain" is the currently calendar week's rainfall, not the prior 7 days? At least, that's the way it looks like it is reporting. If so, is there a variable for the rainfall from the prior 7 days, or do I need to run a rule to keep track?
"weeklyrainin" as returned by the station has the oh-so-helpful description of Weekly Rain on their site... There is not another field offering an alternative, so you are probably going to be stuck having to use a variable and add the daily values together.
As a note, the similar data point returned using the API method has the same description...
So if you have discovered that it appears to be calendar-week and not a rolling 7 day week that is something I never knew before (I have never needed that field for my own purposes/rules, I primarily use temperature, humidity, and wind speeds).
