[PROJECT] Driver for Ambient API/Local and Ecowitt

I do not think there is a perfect tile match for those sensors, but even then the normal tiles will not see the reported values properly because they are not named "normally" (since you can only provide one "temperature" per device for example). You could make tiles with the Attribute template. That will show one attribute on each though.

The other, more convoluted but maybe more what you want, way is to Connect a Global Variable to your Dashboard. I tried that just now to answer your question and I did come up with something. Basically I created 3 global variables (Temperature, Humidity, and WeatherString). I then created a rule that triggered whenever the two device attributes (temp & humidity, but could be anything) from my AmbientData device changed. It set the Temperature and Humidity variables based on the selected device attributes. Then I had it set the WeatherString based on those. There might be an easier way to do it, but I managed to get it working quickly as a sample.
Here is what it looks like:
Weather - Variable String

And here is what I had as the Rule:
WeatherString Rule

The errors with the Ambient Weather Net API have continued so I posted an inquiry to them about the issues we're having. Turns out their cloud vendor has been having problems with one of the physical servers and is attempting repairs. Following is their response to Ed Edelman at Ambient Net:

We have identified an issue on the physical machine hosting one or more of your Droplets, which are listed below. In order to minimize disruption, we will be migrating the Droplets to a healthier physical machine. Throughout the migration, Control Panel and API events - including: power offs, resizes, and attempts to destroy the Droplet - will not succeed for the affected Droplet(s).
In order to minimize downtime, we will attempt to perform live migrations in all possible cases. A live migration would result in no downtime, but minor performance decreases in disk I/O and a second or less of packet loss as the network is switched over to the new physical host.
In the event that we are not able to perform a live migration of a Droplet, we will perform an offline migration during which the Droplet will be powered off and migrated offline during the window.
We apologize for any inconvenience and will be happy to answer any questions or concerns - simply reply to this email or open a support ticket on your account.
Best Regards,
DigitalOcean Cloud Operations

Not a surprise then. I really wish they had a mechanism for me to be able to know about server-side issues so I could provide a better status. I sent them an email about it previously... but never got a response.

Don't want to jinx the matter, but I haven't gotten an error on the Ambient Weather Net API poll since 2:46 PM yesterday ( dev:3532020-04-21 02:46:24.910 pm [error] Country Ln PWS - No data returned by Ambient). Just left a message at Ambient Weather Net thanking Ed Edelman and their cloud vendor for fixing the problem on the API servers.

@anon81541053, @frank1 or @christi999 I have a GW1000 and maybe you can help me. I'm a bit new to HE so maybe I did something wrong. This is what I've done so far:

  1. Imported @snell's latest custom driver into HE.
  2. Setup a new virtual device of type AmbientWeather
  3. Set a fake random string for API key
  4. Set a fake mac address of aa:aa:aa:aa:aa:aa
  5. Set Ecowitt Local and then Debug level logging
  6. Saved the device
  7. Set my GW1000 customized server to the IP address of my HE
  8. Set the GW1000 customized server path to "/aaa" (also tried other things)
  9. Set the GW1000 customized server to port 39501 with an upload interval of 30 seconds.

But I do not seem to be getting any data in HE.
I've tested changing the IP to one of my linux boxes listening on port 39501 and then changed the GW1000 to point to that box, and it received calls from the GW1000, so I know that is working.
I've telnetted to the HE on port 39501 and can see that the port is open.

After all this, there was nothing in the Events for the new AmbientWeather device I added...

Am I missing something?

Thanks for the help!

@snell Iā€™m about to pull the trigger on an Ecowitt HP3501. Does your driver support this model? Also, what mounting pole are folks using to mount the Anemometer on their house? How high should it be off a roofline? Thanks!

Try @anon81541053 suggestion first, the hub needs to know that what is coming from the GW1000 MAC address needs to go to the correct driver. When that doesn't happen, the GW1000 message appears as an error in the log.

1 Like

@anon81541053 that worked! Sorry I did not see that part! @christi999 thank you also for the help! Alright! Now to play with it! YAY!

Thank you all!

1 Like

@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!

As @anon81541053 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 @anon81541053 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.

@anon81541053,
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.