[PROJECT] Driver for AmbientWeather API

@inetjnky I don't think @snell actually has any Ecowitt products, and I don't know for sure, but maybe this will help you...

As I understand it Ambient and Ecowitt are both just branded versions of Fine Offset devices which is why they have a lot of compatibility in terms of frequencies and protocol. In fact, I have the GW1000 a bunch of sensors and the Ambient WS2902 array and they work almost seamlessly together. (Almost because the "outdoor temp/humidity" from the WS2902 overrides the measurements from the WH32 so I cannot use that independently). Anyway, looking briefly at the description of the HP3501 it looks like it supports a "user customized website" likely in the same way the GW1000 does, and I suspect is speaks the same protocol. So, my guess is it will very likely work with @snell's driver as is. You might poke around on some of the WeeWx forums or similar and see if you can find anyone who has one who can tell you what the payload looks like and compare it to that of the GW1000. I suspect they are the same and I suspect the driver will work.

I hope this helps. Report back if you get one. :slight_smile:

1 Like

Thanks but I decided to go with a Weatherflow Tempest. Hopefully they start shipping in a few weeks.

1 Like

Just what @OpenDave mentioned, I do not have any Ecowitt devices. But @christi999 showed how it could be done and the changes to make my driver support it overall were fairly minor.

If it sounds like it will have pretty much the same method as a GW1000, it should work. If some slight tweaks are needed in the driver, that should be possible also.

I will make some changes in the next rev of my driver to help with the Ecowitt... Try to avoid requiring a Fake API Key and such things going forward.

1 Like

@snell you're awesome. If you need any help, let me know.

1 Like

Main thing is if you spot anything that is not working as well as it could, or features you would like, let me know. Worst case, I would say no. :slight_smile:

Otherwise, my drivers are basically a hobby now. They pretty much all do everything I need them to but I am always working on them a bit to make them better or as I learn new things while working on entirely new drivers.

UPDATED:
Version 0.99 is now posted. Only Ecowitt users should see any difference as you will no longer need a fake MAC or API Key (they are hidden). For new users, the process is to add the virtual device, select the driver, then select the method you want (Ambient API or Ecowitt Local) and save preferences. If Ambient, it will then display the preferences for the MAC and API Key. Both get to select about the temperature, humidity, etc...

@snell I just did a clean new install of this driver for Ecowitt and it works as you describe. Thank you!

Also, @snell I went ahead and added the Ecowitt GW1000 to the list of Community Device Drivers

Thank you again for your work!

1 Like

Glad you like it!

Ok, hopefully this is the right place to ask, if not, I can bring my question somewhere else...

Now that I have all my measurements reporting in through HE, how do I use them like other devices. So, I have 8 temp/humidity sensors which are all reporting back through this one virtual device. If I link this device to a single temp/humidity sensor in a dashboard or whatever, it's only going to show one value. So, how do I get a "device" for each child device data brought in through this driver?

As I said, this may be a question for another area about mapping multiple data fields in one device to multiple virtual devices or something. Or maybe I'm not understanding something. Like I said, I'm fairly new to HE.

Thanks so much!

@OpenDave, I asked the very same question a few days ago.

See @snell reply.

It works but it's not ideal, so I've decided to write my own Ecowitt GW1000 driver which will create a child driver (and a tile) for each sensor connected to the Ecowitt gateway.

I should be done in a couple of days. If you are interested I can share it.

As @mircolino says, it is not a nice simple 1:1 method at the moment. However I had been thinking about whether Child Devices would be useful. If @mircolino makes that, then it would solve the issue but I would feel like I let people down. :slight_smile:

It would be easy for me to make a string field in the current driver that combines the two parameters, but then people could not easily compare them (great for displaying them but not as useful if you wanted them for Rules). That is where child devices come into play, something I have tried to avoid until now.

So... is there interest in child devices for these secondary sensors?

To be honest, I thought this was something you could just do with HE directly. Like set the values on one device based on the values from something else. But then I could not figure out how to do that. Yup, I would be interested in sub devices.

@snell I don't think you let anyone down. I feel if we all work together we will keep making the idea even more great. I'm not sure how you feel about sharing the code, but maybe we could combine it all into one project or something. We could have some core components which deal with common stuff and then specific areas for Abient and/or Ecowitt and some of the other offshoots (like Metrobridge) etc.

I think it would make sense to work together rather than have everyone create new drivers... but maybe that's just me.

I'm happy to help as well. I have the devices so I can test, but I also know how to code so I'm willing to jump in there as well.

I obviously have no problem sharing my code or it would not be available. :slight_smile:

All the data is there, but the problem is in presentation. The current dashboard does not have an easy way to represent multiple custom attributes into a single tile, although that is not really that surprising to me. Workarounds exist (as previously mentioned) but a more consistent method would be best and that looks like it might be child devices in this case.

@snell & @OpenDave, I have a working prototype which I'll share on github this week (need a couple more days of testing). It only supports WH32, WH31 and WH51 sensors because these are all I have at the moment, but I plan on buying more on Amazon and support those as well.

@snell, you are welcome to incorporate my code code if you think it could be useful to your project.

1 Like

@mircolino,
I would be happy to! I incorporated code that @christi999 came up with to get the Ecowitt devices working in the first place, so if this makes the driver better for more people I would be happy to get it added in. Let me know when you think I can take a look at it.

@snell & @OpenDave

I just published my driver on github.

It's an early implementation that needs cleaning, testing, optimization and further development (additional sensor support, sensor garbage collection when they disappear, etc).

But the basic architecture is in place: child sensor devices are automatically created when POSTs are received with new/unrecognized tags.

Suggestions and constructive criticisms are always welcome. I'm learning groovy and hubitat app/dh architecture as I go along. So y'all go easy on me please.

@mircolino it's looking pretty good. Like I said, we should converge before we diverge much. :slight_smile:

I am less concerned about the tiles/display, and more concerned about how I can use the individual values. So I would like to do something like "If it's warmer outside than inside, do XYZ" or "If it's windy outside and the window is open do XYZ". So, being able to use the sub sensors as first level citizens in rules etc.

@mircolino I also have the WS-2902A sensor array. If it helps, here is the output sent from the GW1000 in Ecowitt format for the array:
PASSKEY=REDACTED&stationtype=GW1000B_V1.5.7&dateutc=2020-04-27+22:51:24&tempinf=72.5&humidityin=23&baromrelin=24.498&baromabsin=24.498&tempf=79.0&humidity=17&winddir=0&windspeedmph=2.01&windgustmph=3.36&maxdailygust=11.41&solarradiation=363.46&uv=3&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&dailyrainin=0.000&weeklyrainin=0.000&monthlyrainin=0.539&yearlyrainin=2.780&totalrainin=2.780&temp1f=52.34&humidity1=52&temp2f=74.66&humidity2=22&temp3f=71.42&humidity3=26&temp4f=59.36&humidity4=39&temp6f=73.22&humidity6=20&temp7f=51.98&humidity7=54&temp8f=60.08&humidity8=42&soilmoisture3=51&soilmoisture4=39&wh65batt=0&batt1=0&batt2=0&batt3=0&batt4=0&batt6=0&batt7=0&batt8=0&soilbatt3=1.4&soilbatt4=1.4&freq=915M&model=GW1000
This also contains 2 WH51s, 8 WH31s. I do not have a WH32, but the array itself is reporting outdoor temp/humidity.

Let me know what I can do to help.

For that, @snell driver works just fine. When you create a RM rule, just use Custom Attribute and then select the individual device value.

Gotcha, ok, I hadn't tried that. Still, think it would be nice to treat them as individual devices as you have started to do.

Might take me a couple days (my "honey do" list JUST turned into repainting 2 rooms and completely gutting a 3rd, so I am stuck in planning for those), but I will look into trying to merge this all in.

You guys are really making me wish I had bought a higher-end model that I could add sensors to, but I know it would mostly just be playing on my part. The single-most reason I got a weather station was to be able to know if wind speed was getting too high so I could turn off my wife's inflatables at Christmas. That is all... Just to save me the aggravation of turning them off myself individually, or having to repair them do to wind damage. So anything beyond that is a bonus. :grinning:

Which one do you have @snell? They are pretty cross-compatible and it likely will work with the GW1000 and thus you could also add sensors.

Download the Hubitat app