[PROJECT] Driver for Ambient API/Local and Ecowitt

Is it trying to provide data using a weather underground method? This driver will only accept receiving data that is formatted for Ecowitt or Ambient (which are nearly the same data, but not quite) methods.

It also looks like the device might be set to "Ecowitt Local" mode. From digging into the Misol IP Observer (which I had never heard of before this nor seen the similar Ambient IP Observer) it looks like it is specifically an Ambient "esque" device. So you want to set the Weather Method preference on the device page to be "Ambient Local".

On the device page, it is updating every 15 secs, so it is talking to the driver.

It must be a format issue at this point. Is there a way to capture this data stream and see what data is being generated?

In trace mode the log generated is.....

Can you send me the logging lines from the Raw data and Local Headers that you have shown as text in a message directly to me? It does appear to be a decoding issue.

Whatever it is doing... it is NOT providing it in the "normal" Ambient Local method. So it will be necessary to figure out how it is encoding the data, decode it, and then maybe I can add a new method to support it.

I sure can except I do not know how to capture this raw date other than what I see in the C7 logs.

I did find this website for Misol.....

Did you by chance see this topic in here?

aaiyarAmbassador

1

Jun 13

ecowitt sensors are very reliable and integrate well with Hubitat using integrations from @snell and @sburke781 both of which are linked below:

These sensors are actually fairly inexpensive for their quality, running in the $15-30 range for moisture and temperature/humidity sensors. However, I found a cheaper alternative that also works with the ecowitt integration.

Basically, you need a gateway made by Misolie; the Misol GW1000 is exactly identical to the ecowitt GW1000. It costs about $20 on AliExpress. Misol soil moisture and temperature/humidity sensors are also identical to the equivalents sold as ecowitt sensors, and cost between $5-10.

The reason you need the Misol gateway is because the gateway and sensors are all configured to use 433 MHz, whereas ecowitt equipment sold in the US uses 915 MHz. As far as I can tell, it is legal to use 433 MHz equipment in the US because there's lots of other products that do ....

Anyway, here are the links:

Misol GW1000
Misol Soil Moisture Sensor
Misol WH31 Temp/Humidity Sensor
Misol Water Temperature Sensor

Anyway, if you're undecided about getting ecowitt sensors because of the cost involved, these lower-priced alternatives might help .....

I'm using the Misol WiFi gateway (GW1000) and soil moisture sensors at my friend's house.

Edit: I was just thinking. Since ecowitt hardware is limited to a particular number of sensors of each type (eg. 8 soil moisture sensors), using this gateway also becomes a way to increase the number of sensors available for automation.

For the logging, you can just shoot me the text that is right from in the logging system. I can attempt to decode it.

If the Misol WiFi Gateway is actually supposed to be replicating an Ecowitt then the Method preference should be set for Ecowitt Local. But I think you had it set that way originally, correct?

Yes I did. I set it to Ambient local now. Either way it's not working.
Set on trace. These lines just keep repeating every 16 seconds.

This update should only be useful to people with an ObserverIP (ie: @buckchucko).

Updated Version(s):

  • AmbientEcowittWearther.groovy = 0.8.2

Change(s):

  • Added a new WeatherMethod to the parent device preferences "Live Data Scrape". In this method you configure the IP/Hostname of your device (the ObserverIP's IP/Hostname). It will then attempt to get and parse the "livedata.htm" file from the base of that location.
  • Additional data names have been added. Almost all were duplications (with a different name of course) of existing data. They also (of course) report battery values differently.

Caveat(s):

  • I only had the sample posted on Ambient's site about this page and it is VERY old. So there may be additional data types that need to be handled.
  • There is one data point I did NOT deal with at this time "uv". I am not sure what value the uv represents as their sample shows "2292" which really does not correspond to anything I could readily find. They already provide the normal "uvi" and a solar radiation value.
1 Like

Changes are for ObserverIP "Live Data Scrape" functionality. Nobody else should see any difference in how their data is reported EXCEPT the last entry on UV.

Updated Version(s):

  • AmbientEcowittWeather.groovy = 0.8.4

Change(s):

  • LiveData was being attempted using HTTPS but the ObserverIP is only set for HTTP so this has been switched.
  • Eliminated most cases of making variable names based on their data field name (it.key) because of different names being received causing trouble. These have been switched with specifically set variable names now.
  • UVI values of 30 and above will be ignored. Since the highest registered during scientific studies happened at very specific locations on the planet and only reached 25. Ultraviolet readings will also only be referenced as uvi (or ultravioletIndex) now.
1 Like

Updated Version(s):

  • AmbientEcowittWeather.groovy = 0.8.5

Change(s):

  • Additional field name "windspeed" accepted because the actual ObserverIP data did not follow it's own example page for field names.

Looks like the final tweak on this one... changes should only be useful to someone using the Live Data Scrape method.
Updated Version(s):

  • AmbientEcowittWeather.groovy = 0.8.6

Change(s):

  • Tweak to how the livedata was being polled due to a change in newer Hubitat firmware.
  • "uv" data from a Live Data Scrape will be ignored and instead the "uvi" value will be used in all cases due to the fact that livedata includes both and the "uv" value has not been found to really match anything useful.

Found a word flip in variables when trying to create a rain sensor logic in the case on lines 976 to 985:

			case "rainratein":
				ProcessState( "rainratein", it.value as float )
				if( MeasurementStandard == "Metric" ){
					ProcessEvent( "RainRate", ConvertInches( "Imperial", state.raterainin ), "mm" )
					PostEventToChild( "Outdoor Station", "RainRate", state.RainRate, "mm" )
				} else {
					ProcessEvent( "RainRate", state.raterainin, "in" )
					PostEventToChild( "Outdoor Station", "RainRate", state.RainRate, "in" )
				}
				break

I've validated switching state.raterainin to state.rainratein gets RainRate to report correctly.

Thanks for the great work!

Confirmed, lines 979 and 982 had the wrong state name... This has also been this way for a LONG time it appears. Corrected version will be posted in a couple minutes (not much testing needed for this).

Updated Version(s):

  • AmbientEcowittWeather.groovy = 0.8.7

Change(s):

  • Corrected references for rainrate state names. Thanks to @sid1 for pointing out this error.
  • Added Runtime state data if returned (it showed up on my Ecowitt gateway at least). This gets converted from the number of seconds to a "human-readable" string like X Days Y Hours and Z Minutes.
1 Like

Great! Took me over 3 weeks to find it.

Nice on runtime data. My Ecowitt gateway shows it as well. I also have a soil sensor that I don't use the gateway is returning unhandled data:

GW1000B - Unhandled data: soilad1 = 324

I don't use it and haven't dug into.

Thanks again!

I had no idea what soilad was... but I found ONE reference to a WXForum Thread in Google searches and it actually matches(!).

It appears soilad1..8 is returning the soil sensors calibration value. That is it. It has no apparent value as the calibrated values from the soil sensor are already returned and the calibration was set in the app.

So... the next time I am making an edit I will try to include it in the "state variable only" section of data. Interestingly enough, it is not in the data returned for my soil sensor. I will have to check if I have the latest version of the firmware for everything...

Thanks for letting me know! That is exactly the reason I flag "Unhandled data" in case someone sees something potentially valuable that I can start capturing.

1 Like

Yep, I found the same thing recently, they are the calibration settings.

Updated Version(s):

  • AmbientEcowittWeather.groovy = 0.8.8

Change(s):

  • Added in the soilad# for recognition so that these can be properly handled.
  • Made some changes to the driver attribute names. They were changed from "Driver Name" to "DriverName", "Driver Version" to "DriverVersion", and "Driver Status" to "DriverStatus". This is to eliminate a couple of the visual glitches on a device's page if those are updated (because they have spaces in them). Unfortunately it is tough for me to fix this problem overall as I would have to overhaul almost all attributes I currently use and I do not want to break whatever Rules and uses people are already using them for. So I am starting to change a couple most people likely would not even notice otherwise and handling it with completely new projects as I make them.