That webhook address looks peculiarly long. When I set up the Ecowitt integration, it provides the webhook id like this: 98ae565580f7e9a8180e294447d41e00
The Path sould be /api/webhook/98ae565580f7e9a8180e294447d41e00 using my previous example webhook id.
I checked again and think I have it sorted. Thanks. Let’s see if it updates!
Ok, I may be missing something. Here is a screen cap of the webhook from the Nabu Casa tab and what I am putting into the awnet app for the weather station. I am not seeing any updates. Thanks!
That looks right.
Is the Server IP, 172.20.20.250 is the local IP off your Home Assistant?
Otherwise, do you see anything in the logs? Anything with Ecowitt? Like warning of unknown sensor, or anything?
Same situation with me. Upgraded to 2025.3.3, and I think everything is set up correctly, but not seeing any data or anything about Ecowitt in the logs. I presume this is not correct as well?
Weird. My “Ambient Local” device is still updating. When I stop the AddOn the data isn’t updated, but when I start the AddOn back up, refreshed (and changed) data is populating the Ambient Local sensors.
I think this means that my update of the weather station did not actually cause it to stop sending to the previous address/path/port. If that’s the case, it’s not an issue with the new Ecowitt integration per se, but still something that needs to be figured out for anyone who wants to migrate from Ambient Local…
Update: Yeah, I can’t find any working way to change the values in the weather station. The steps look like they work, but it doesn’t change anything. The AWNET app hasn’t been updated in 2 years and has 1 star reviews saying the same thing: it used to work, but no longer. So - I guess I’m stuck with Ambient Local until I replace the weather station.
@dancwilliams, @PecosKidd, thanks for both of you trying it. I will revert back to the Github PR and try to discuss it with the PR’s author, what else has been done on his side.
In the meantime regarding the AWNET app.
Does the Ambient Weather stations work with the WS Tool / WS View or WSView Plus apps? Those are the ones for the FineOffset / Ecowitt weather stations. WSView Plus is the latest iterarion.
@dancwilliams, @PecosKidd, can you try to adjust the Path set in the AWNET app and add at the end a ? (question mark sign)?
Or if that doesn’t make any difference, then you can try to close it as /? after the webhook id.
That might be the issue which I have overlooked as a difference from Ecowitt.
Morning! Putting the ? at the end of the webhook worked. So here is the format I am using on the AWNET app:
Awnet is old but it works and has always been solid for me. Haven’t tried anything else.
Now I am seeing data in the echowitt device:
@dancwilliams, let me know if any log messages about unknown sensors.
Where exactly would you like me to check so I know I am gathering the correct info? Thanks!
Settings/System/Logs in HA.
It should show something like this as a warning, if any missing sensor:
Unhandled sensor type console_batt value 2.48
You can search for ecowitt and will show if there is any issue.
Great, just like to be sure I am grabbing what people are expecting.
Don’t see any logs:
And under the device I only see one sensor as “unavailable”:
Everything else is working well!
It will come and go, depending on what the device calculates as Windchill, as I remember.
This is how it looks for me.
Cool! Alright, guess just let us know when this gets upstreamed. Thanks for looking into this!
One thing I noticed was that the Ecowitt integration was reporting by batteries as low even though the device is saying the battery (both outside and co2) have a status of 1 which is OK according to the referenced API docs.
{
"stationtype": "AMBWeatherV4.3.6",
"PASSKEY": "XXX",
"dateutc": "2025-03-11 00:26:40",
"tempinf": "80.6",
"humidityin": "38",
"baromrelin": "30.021",
"baromabsin": "29.962",
"tempf": "59.9",
"battout": "1",
"humidity": "70",
"winddir": "188",
"windspeedmph": "0.0",
"windgustmph": "0.0",
"maxdailygust": "17.2",
"hourlyrainin": "0.000",
"eventrainin": "0.000",
"dailyrainin": "0.000",
"weeklyrainin": "0.020",
"monthlyrainin": "6.154",
"totalrainin": "236.220",
"solarradiation": "0.00",
"uv": "0",
"batt_co2": "1"
}Thanks for noting this. This is exactly a small difference which I need to look at. As I don’t have any device with this sort of low battery reporting, and have not dug into the Ecowitt/Ambient Weather documentation yet to crosscheck them.
Can you confirm that you are not using a “Meteobridge”? If you look at the documentation that makes things more complicated for some of those battery reporting.
Not a problem. I am not using the Meteobridge. I am using the monitor interface that comes stock with the Weather Station. Pictures below for reference (please excuse the dust):
I guess you must have the Osprey, is it? I have a Eurochron, sold by Konrad in Europe. It has exactly the same indoor console unit, just the frequency is 800something Mhz. Hence being all FineOffset clones, they have all the same hardware and mostly software as well.
Thanks for all the help. I will try to update that PR or open a new one with the stuff which I added to that custom one, and will see how the Ecowitt integration can be extended to Ambient Weather in HA. I have no clue yet, if a virtual integration will need to be raised or how will get it into Core.
Obviously, it is working, and that is a good step forward likely for all the 1000+ Ambient Weather Station integration users.
Do you have at all an external WH45 (PM and CO2) sensor? I assume not, as somebody else has reported it, that the device sends for him a batt_co2 even without having an external unit.
