Ecowitt add-on vs. HACS integration, what's the difference?

As the subject reads. I searched, but did not find an answer. Thanks!

The offical integration forces you to expose your HA instance over HTTP (insecure) and use a proxy if you want HTTPS. This integration exposes a webhook on your default HA port and you point Ecowitt at it.

The HACS integration is no longer maintained but allows you to expose HA on HTTPS only and open a separate HTTP port specifically for HA.

There is a bug in the HACS integration currently but it is fixable and I have also forked it with the fix built in if interested. I dont intend to maintain it long term either though.

The hope is that either Ecowitt updates devices to support HTTPS (unlikely) or the official integration is updated to support an alternate port so we don’t have to expose all of HA over HTTP for just this integration.

See here for more.

1 Like

@bs87 thank you for all the information and fork. I am trying to understand why HA needs to be exposed for Ecowitt’s sake at all? Is it because the gateway can only talk to one server at a time and if HA is the server, then the add-on/integration must relay the data to Ecowitt for the native app or other weather data recipients? Or, does the official integration automatically exposes the HTTP webhook?

The way I see it, if Ecowitt is limited to local mode (talking to HA only–if that is possible), then there is no need for any exposed ports or services? Even when I need to see the Ecowitt data from the outside, I assume I would be making a connection through HA’s cloud services, not directly to Ecowitt. I am doing my homework before diving into the ecosystem.

Curiously, for how long have you been maintaining the fork? Again, thank for your work!

I’m not sure how the Ecowitt app works as I’ve never used it. I have Ecowitt send everything to HA and access and use in automations directly from there.

The Ecowitt gateways push their data to whatever you configure in the gateway itself. This is currently limited to HTTP endpoints only. You don’t expose any ports on the Ecowitt gateway.

The official integration does not expose a dedicated port but exposes a webhook on your HA port (default is 8123). If you have configured HA to use HTTPS only (secure configuration) Ecowitt will not be able to send data to HA. HA instead requires you to use HTTP for all of HA so Ecowitt can send to webhook. The official integration does not allow you to choose what port for the specific integration.

The HACS integration exposes a port different from your HA port (default is 4199 but it is configurable when you set up the integration). You can then leave HA secured with HTTPS (per the issue linked, I do not consider the NGINX workaround a secure or acceptable alternative) but only expose this one port with a specific purpose on HTTP. Ecowitt then sends to this alternate port on your HA server.

I am not maintaining the fork except for my own personal use. There are many pull requests on the original HACS repo with the fix but nobody is maintaining it so none have been merged. I just incorporated those changes to make adding it to HACS with the fix easy. If another HA update breaks it I can’t guarantee I will be able to fix it in a timely manner or at all.

1 Like

Ah, I think I understand–these are internal/local connections. I was confused before why an external/Internet-facing webhook would be needed.

Aside from the HTTPS vs HTTP issue you described, are there any functional or feature difference between the official and HACS?

Understood regarding you maintaining the fork only for personal use and no gurantees.

Thanks again!

Correct, all communication is local for both integrations.

I am not sure if the official is different from the HACS integration but I have had no issues with the HACS one. I think I saw somewhere that the official is based on the HACS version but not sure if that is accurate. I have not used the official integration due to the HTTP requirement.

I have 3 gateways (GW1100) with the following sensors and all have been rock solid for well over a year.

  • 21 soil moisture sensors WH51 (only replaced 1 battery so far)
  • 2 soil temperature sensors WN34BS
  • 1 indoor air quality sensor WH45
  • 1 weather station GW1102
  • 3 temperature and humidity sensors WH31
1 Like

I was wondering why you needed 3 gateways, so I decided to look at the GW1100 specs–up to 8 soil moisture sensors per gateway. Thanks again for all the help!

I strongly recommend to just try out the standard Ecowitt integration.

I started by setting up the Ecowitt GW2000 gateway using the local webserver approach described in the Ecowitt getting started docs. Still using the local webserver, I added batteries to the first soil moisture sensor and this was discovered automatically.

Next I added the Ecowitt integration in Home Assistant. I found the walkthrough did not need reference to any docs to follow the steps. In the Ecowitt web page the customization config was under a different menu, but when you browse around the options it is pretty obvious. The Ecowitt gateway and soil moisture sensor were discovered immediately.

After that whenever additional moisture sensors are added, the entities are automatically visible in Home Assistant.

One small tip with Ecowitt is to label your sensor each time you pair them to avoid confusion.

Brilliant compatibiltity between Ecowitt and the Home Assistant ecosystem - I can’t recommend strongly enough.

No. Using the built in Ecowitt integration as you described leaves your entire Home Assistant assistance exposed insecurely unless you do some convoluted and unnecessary reverse proxy set up. It says this at the bottom of the integration page.