[PROJECT] Driver for Ambient API/Local and Ecowitt

Maybe @christi999 can chime in. Since they were the first to use a modified version of the driver back on January 29th to use with the Ecowitt. After that I built the support in. But since I do not have one myself, I have no real way to walk people through the differences.

In the meantime, if you set it to do Debug logging, what does it show? Wondering if it is failing to connect or something.

I don't have an option to enable debug logging on the device like I do with my other devices.

@snell, I found this in my logs. dev60 is the Ecowitt gateway, and the Mac address is 2CF4323E3156. I cant yet post images, otherwise I'd upload a copy of the deice page. looking at the code, I don't see why the preferences wouldn't appear. I've tried chrome and safari and neither have them listed.

[dev:60]2020-03-10 02:30:05.038 pm [warn]java.lang.String cannot be cast to java.util.Map$Entry
[dev:60]2020-03-10 02:30:03.742 pm [warn]java.lang.String cannot be cast to java.util.Map$Entry
[dev:60]2020-03-10 02:30:02.365 pm [warn]java.lang.String cannot be cast to java.util.Map$Entry
[dev:60]2020-03-10 02:28:58.708 pm [warn]java.lang.String cannot be cast to java.util.Map$Entry
[sys:1]2020-03-10 02:28:46.268 pm warnReceived data from 192.168.86.108, no matching device found for 192.168.86.108, C0A8566C:5ABA, 2CF4324E3156 or C0A8566C.

You have driver 0.94 but no preferences appear? That does not make sense. Even if you had selected to hide the preferences it still shows the Show All Preferences option. It IS supposed to hide preferences that do not apply for Ecowitt like the MAC Address, Data Refresh Rate, and API Key.

I removed my device and put it back with your newest driver and I get the same result, no preferences showing and [warn]java.lang.String cannot be cast to java.util.Map$Entry from the device...

The coma between the two "30" should be a colon... :scream:

input( type: "enum", name: "RefreshRate", title: "Data Refresh Rate (in minutes)", required: true, multiple: false, options: [ [ "1" : "1" ], [ "5" : "5" ], [ "15" : "15" ], [ "30", "30" ] ], defaultValue: "5" )

1 Like

@christi999 that did it! Thanks

Arg... Copy-paste error when I added the 30min option in. It is now corrected and the version updated to 0.95... Darn. Thanks for catching that.

I was wondering how it got there...

I have been doing general cleanup of a bunch of my drivers and when I was working in there I thought someone might like 30min... Ugh... It just had to be something simple but I did not notice because on my development hub it was correct. I messed it up when I was editing the driver on my webserver.

Maybe I need to look at some sort of "upload from hub"... :confounded:

it looks like there may be another Ecowitt issue. The PM2.5 sensor I have seems to be relaying the information, but the driver doesn't seem to handle it properly. Here's whats being passed from my logs

2020-03-11 12:00:26.290 pm [debug]GW1000 - [[PASSKEY:REDACTED, stationtype:GW1000B_V1.5.7, dateutc:2020-03-11+19:00:18, tempinf:72.9, humidityin:41, baromrelin:29.902, baromabsin:29.902, temp1f:62.42, humidity1:58, soilmoisture1:42, soilmoisture2:50, soilmoisture3:36, soilmoisture4:42, soilmoisture5:58, soilmoisture6:56, pm25_ch1:5.0, pm25_avg_24h_ch1:7.2, batt1:0, soilbatt1:1.4, soilbatt2:1.4, soilbatt3:1.4, soilbatt4:1.4, soilbatt5:1.4, soilbatt6:1.4, pm25batt1:5, freq:915M, model:GW1000_Pro]]

Edit: its the value names, they don't match between ambient weather and Ecowitt devices

That should be easy enough to handle. I think I will include the other information I see in here, like stationtype, freq, model, etc... Thanks for the batch of info. I will get to work on this this evening so you can probably expect a release soon.

UPDATED @ 8:35pm EST
Version 0.96 is now posted. It should handle the new values provided by the Ecowitt stations, and should not impact any other users. @frank1, if you can take a look and let me know if it works out that would be useful. The added values are:

  • stationtype
  • pm25_ch1
  • pm25_avg_24h_ch1
  • pm25batt1
  • freq
  • model
1 Like

Current States

  • Version : Latest driver
  • baromabs : 29.79
  • baromabsin : 29.796
  • baromrelin : 29.796
  • batt1 : 1.4
  • batt2 : 1.4
  • batt3 : 1.4
  • batt4 : 1.4
  • batt5 : 1.4
  • batt6 : 1.4
  • dateutc : 2020-03-12+01:02:16
  • freq : 915M
  • humidity1 : 44
  • humidityin : 42
  • model : GW1000_Pro
  • pm25_avg_24h_ch1 : 5.0
  • pm25_ch1 : 5.0
  • pm25batt1 : 5
  • soilhum1 : 42
  • soilhum2 : 50
  • soilhum3 : 36
  • soilhum4 : 41
  • soilhum5 : 59
  • soilhum6 : 56
  • stationtype : GW1000B_V1.5.7
  • temp1 : 73.4
  • temp1f : 73.40
  • tempin : 76.3
  • tempinf : 76.3
  • WindChill : null
  • HeatIndex : null

It’s working great!

Good to hear. Is there any value in separating out the station type's version? I am not sure if those are upgradeable and if it is useful as a separate value in any way, so I wanted to ask.

An error was found in the way I had the Wind Direction String being generated. 0.97 is now posted and corrects this.

Ambient Weather is currently having DB retrieval issues so my Hubitat is reporting it was last observed 12-11-2019 right now.

That is quite the gap there... I double checked mine and it has a date of 2019-11-25.

Another incentive for the Ecowitt models.

I'm currently seeing errors when trying to connect. Anyone else seeing these? Tied to their DB issue possibly?

Yeah, mine keeps getting errors too but the Ambient dashboard still says they have DB retrieval issues so I'm hoping those errors go away once they fix their side.

1 Like

Yeah. Not much I can do about their side having issues. Even if I put some sort of error messaging attribute, I am not sure that would help people. Everyone would have to make that in their related rules and it would not help with dashboard displays anyways.