Ecowitt Integration - HTTPS requirements non functional

[JohnMcLear]

The problem

Duplicate of garbled1/homeassistant_ecowitt#154

I'm running HA Blue hardware w/ HASS and want to use HTTPS to make Ecowitt plugin (core) work.

Since the plugin went into core HA the TLS/SSL was dropped and the requirement is to use NGINX to reverse proxy HTTPS > HTTP.

Before I had port 4199 > 4199 forwarded(at the router) to the HA Blue box and it was working fine (using custom plugin). I modified the new path to match the path specified by the plugin at time of installation/configuration and I have no data coming through and no errors in the logs.

Given that I expose https for core without a plugin what are my options here?

Related to garbled1/homeassistant_ecowitt#149 but I wanted to create a new issue to remove the noise

What version of Home Assistant Core has the issue?

core-2023.5.2

What was the last working version of Home Assistant Core?

n/a

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Ecowitt

Link to integration documentation on our website

https://www.home-assistant.io/integrations/ecowitt/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant]

Hey there @pvizeli, mind taking a look at this issue as it has been labeled with an integration (ecowitt) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of ecowitt can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign ecowitt Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

ecowitt documentation
ecowitt source
_{^{(message by IssueLinks)}}

[veilofsecurity]

The requirement to use NGINX proxy is a step backward and a security issue. The custom integration was able to expose a specific port for a specific purpose and not expose 8123 over HTTP. Even local I do not consider exposing my entire HA instance over HTTP acceptable.

This integration should be reworked to support HTTP without exposing all of HA via HTTP like the HACS version did.

[JohnMcLear]

This integration should be reworked to support HTTP without exposing all of HA via HTTP like the HACS version did.

Is this accurate @veilofsecurity - It doesn't change your point but I think the above statement includes mistakes? I think it's meant to say

1. "This integration should be reworked to support HTTP for a specific purpose without the requirement to expose all of HA".

and/or (and this is for my use case).

2. "This integration should be reworked to support ecowitt where HA is exposed via core HTTPS handlers and not require Nginx reverse proxying.

They are two separate approaches. You'd of thought 2) would be supported "out of the box" given that it was implemented for hass.io.

[veilofsecurity]

My wording about HACS was definitely ambiguous and your 1 clarifies the meaning. Your 2 wont work because the Ecowitt gateways only support HTTP and I doubt they will be updated anytime soon, if ever.

There are 3 options:

1. Best - Ecowitt updates to support HTTPS and we use the native integration as is.
2. Better - HA makes the integration expose an HTTP port whose only function is to ingest from Ecowitt. This is what HACS did and doesnt make all of HA available via HTTP which is unacceptable in my opinion.
3. Not great - Expose HA via HTTP allowing Ecowitt to send to the integration. Use NGINX Rev Proxy to enable HTTPS for HA for your everyday use, mobile apps, etc.

For now I am continuing to use the HACS integration with the line 21 code fix but I dont expect that integration to work forever as it seems to now be unmaintained. I would like to see option 2 implemented in the official integration or I am open to othet ideas if I've missed something.

[adynis]

Where could I vote for option "1. Best" from previous post from @veilofsecurity ? :-)

[JohnMcLear]

For now I am continuing to use the HACS integration with the line 21 code fix

Given the situation I might be forced to do the same ;( Can you please link to the line 21 code fix?

[adynis]

I suppose it's this one: garbled1/homeassistant_ecowitt#149 (comment)

[Cellivar]

Skimming through the code it looks like the port for the webhook could be made configurable?

core/homeassistant/components/ecowitt/config_flow.py

Line 46 in 3fbc026

"port": str(base_url.port),

My GW1000 seems to support adding different ports, just not using HTTPS over whatever port is selected.

[Entropy512]

Given that option 1 is extremely unlikely to happen (since that would require ecowitt to add the function and this does not seem likely), option 2 would make most sense. It also is the easiest for existing ecowitt users to migrate to.

Funny thing is that when installing the new Ecowitt integration after deleting all of the old HACS-originated stuff, it talks about finding an open port and even suggest 4199 which is what the old HACS ecowitt integration used - but it obviously does not actually support listening on 4199...

[raucao]

Just ran into this issue with a new weather station. Option 2 seems the most reasonable to me as well, because I also don't want to expose the rest of HA on HTTP. And option 1 is out of our control.

[andcastellani]

Is it not possible meanwhile a workaround, like writing a different port number in a config file?
Or, for instance, can core/homeassistant/components/ecowitt/config_flow.py code file be edited for this type of "hacking"?

[kbx81]

Just ran into this issue with a new weather station.

Add me to the list 🙃

Option 2 seems the most reasonable to me as well, because I also don't want to expose the rest of HA on HTTP. And option 1 is out of our control.

Solid agree. 😄

[del13r]

I also recently struggled with setting up simultaneous:

• HTTPS secure web browser access via NGINX proxy
• HTTP webhook access direct to home assistant

I made a guide on how I solved my issue if anyone else is currently lost:
https://community.home-assistant.io/t/nginx-tls-proxy-add-on-config-to-allow-simultaneous-https-and-http-access-required-by-ecowitt-integration/589276

[andcastellani]

Thank you very much @del13r for your excellent guide, very useful to make ecowitt devices working again with home assistant (hoping that in the next future the integration will also allow us to choose the http port number listening for ecowitt messages)

I also recently struggled with setting up simultaneous:

• HTTPS secure web browser access via NGINX proxy
• HTTP webhook access direct to home assistant

I made a guide on how I solved my issue if anyone else is currently lost: https://community.home-assistant.io/t/nginx-tls-proxy-add-on-config-to-allow-simultaneous-https-and-http-access-required-by-ecowitt-integration/589276

[JohnMcLear]

@del13r Can you please confirm if your solution will work for Home Assistant OS users IE users who purchased Home Assistant Blue hardware and have a managed operating system?

[del13r]

My solution uses 2 addons.
For that reason, if you are running Home Assistant Operating System, you WILL be able to install the addons.
If you are running Home Assistant Container, you will NOT be able to install addons.

On this page https://www.home-assistant.io/installation it says:

If you are using the Home Assistant Blue, the Home Assistant Operating System is already installed.

I am confident the solution should work for you as well.

[veilofsecurity]

Skimming through the code it looks like the port for the webhook could be made configurable?

core/homeassistant/components/ecowitt/config_flow.py

Line 46 in 3fbc026

"port": str(base_url.port),

My GW1000 seems to support adding different ports, just not using HTTPS over whatever port is selected.

This appears to just be the text at the end of setting up the integration and not the actual port used. Making the port selectable and listening on it would be a bit more involved than just modifying that section. Not to say it can't be done, the HACS integration managed to do it without issue.

In the meantime, I have forked the HACS integration and fixed the bug if anybody wants it: https://github.com/veilofsecurity/homeassistant_ecowitt

In my opinion this is a much better option than doing as @del13r or the official HA docs suggest. Exposing HA on HTTP is just a bad security practice.

[del13r]

Exposing HA on 80 is just a bad security practice.

Home assistant http default port is 8123.
Nginx https proxy default port is 443.

both of these can be changed to whatever port numbers you like and you only need to publicly expose / port forward the https port and just use the http port internally without exposing/forwarding it.

[JohnMcLear]

@del13r RE HAOS

For that reason, if you are running Home Assistant Operating System, you WILL be able to install the addons.

Home Assistant OS supports HTTPS without the requirement of Nginx ergo exposing HA on 443. That's the documented/supported way to do it. See https://www.home-assistant.io/integrations/http/

Using nginx to reverse proxy SSL might be fine(FWIW I use it at lot but not w/ HA) but it's not the core method of supporting HTTPS and as such your documentation should reflect that a user using your documentation may have a degraded user experience or difficulties down the line. A simple warning caveat should suffice.

Also if a user already has HTTPS setup the correct way (as per HA docs) then your workaround wont work.

I do appreciate your contribution and solution though, thanks for sharing!

[del13r]

it's not the core method of supporting HTTPS

I see your point and I will try to make an ammendment.

In my article, I had explained that when I started, I already had HTTPS exclusively setup on default port 8123 using the default instructions for DuckDNS.
I also explain that by following the default DuckDNS instructions where "you'll need to configure the Home Assistant Core to pick up the SSL certificates", that this is what upgrades default port 8123 from using http to https.
Perhaps I could make that more clear.

Instuctions from https://github.com/home-assistant/addons/blob/master/duckdns/DOCS.md

Additionally, you'll need to configure the Home Assistant Core to pick up the SSL certificates. This is done by setting the following configuration for the HTTP integration configuration in your configuration.yaml:

http:
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

Also if a user already has HTTPS setup the correct way (as per HA docs) then your workaround wont work.

This is why I start the article by:

• advising to remove the DuckDNS addon and the NGINX addon if also installed,
• remove this section of the http config block which demotes the https server down to a http server and then reboot Home Assistant:

http:
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

• delete any certificates in the ssl folder

I do appreciate your contribution and solution though, thanks for sharing!

Thanks for the recognition :)

[veilofsecurity]

Exposing HA on 80 is just a bad security practice.

Home assistant http default port is 8123. Nginx https proxy default port is 443.

both of these can be changed to whatever port numbers you like and you only need to publicly expose / port forward the https port and just use the http port internally without exposing/forwarding it.

This is correct. I meant "Exposing HA on HTTP is just a bad security practice" regardless of port used. The point still stands though, even using HTTP internally is not a good idea. You can never assume your internal environment is free of threats. I have updated my comment to avoid confusion.

[del13r]

even using HTTP internally is not a good idea

I agree, hence why I originally exclusively used only HTTPS on port 8123.

The problem begins and ends with the ecowitt device only supporting http for sending webhook data.
This has a knock on effect which causes the native ecowitt integration to require that I expose my home assistant core using http so it can receive the http webhook data from the ecowitt device.

If you want to receive data from the ecowitt device using the native integration, this is where you have to make some choices:

• Demote your home assistant core from https to http to suit the ecowitt device and just leave it at that.
• Additionally install NGINX proxy addon to give you both https via the addon as well as http access via core.

I chose to do both.

To be honest, I haven't evaluated or even looked at any of the HACS alternatives yet, but I assume they will function differently to the native ecowitt integration.

[raucao]

The HACS one simply opens a new listener for http on a different port, only to receive this specific webhook. Which solves this problem elegantly and without drawbacks. It's the best native integration path, because it neither requires exposing the rest of hass via http, nor to run a custom reverse proxy in front of it.

[del13r]

You make a fair point. I only got my ecowitt device last week. I thought I would get the native integration “working” first and decided to document my journey to help me and others understand what to do make the native integration work. I may spend some time evaluating HACS options in the future

[JohnMcLear]

@raucao

Which solves this problem elegantly and without drawbacks.

I'm in agreement with the caveat that the drawback is that you are opening up an additional TCP port (and potentially another attack vector) and also that it's possible when you replace your router you miss adding this port forward. I'm nitpicking though ;)

Most core integrations don't open a new TCP port so it sort of makes sense that HA core wanted to do it this way, ultimately Ecowitt are the party here who need to get their act together and support HTTPS/SSL.

Has anyone actually reached out to Ecowitt for comment?

[ChrisRomp]

If it's helpful to anyone else, I've written a very simple Home Assistant add-on which will listen on HTTP and forward the request to the Ecowitt webhook. This hasn't been tested super thoroughly, just in my simple configuration. Input welcome.

https://github.com/ChrisRomp/addon-ecowitt-proxy

[ascheucher]

@ChrisRomp Thanks for sharing your little add on!

But couldn't get it up and running sadly. I created an issue in the repo.

[ascheucher]

With a little hint from @ChrisRomp it works now.

If somebody else wants to give it a try:
But I can't get it to work. This is how I have installed it:

• In HA go to Settings
• Add Ons
• Add On Store
• Three little dots on the top right corner -> Repositories
• Add the URL: https://github.com/ChrisRomp/addon-ecowitt-proxy
• reload the Add On Store page and the Ecowitt Proxy Add On shows
• Install :)
• crate a Ecowitt device in the Ecowitt Integration
• copy the webhook id and paste it in the Ecowitt Proxy ID field
• select an free port
• safe the config and start the proxy
• set up the Ecowitt app
  • device
  • three dots top right corner
  • Others
  • DIY Upload Servers
  • Customized
    • Ecowitt protocol
    • http url: your internal hostname
    • path: log/ha
    • port: 8081 <- config of proxy ignores other port settings
    • save
    • go back
  • go back
  • save again

[del13r]

Expose a separate HTTP port for this specific purpose only.

For this to happen, the exposed http port would need a whitelist function with just the IP of the ecowitt gateway device on it and anything else would be considered blacklisted and blocked.

Has anyone seen any other core integrations successfully do this before?

[Momro]

I highly appreciate everyone's work on this issue and the discussion. I find it extremely irritating that ecowitt does not allow https, not even with a publicly trusted certificate. Is this 2003 or what?

However, I don't understand why HA does in fact not offer any way to access the system with http AND https, like most Web servers do (but most will forward http to https, which could be configurable).

I'll try the previously mentioned ecowitt proxy solution. An additional nginx reverse proxy sounds neat, but like lots of additional work for something that simple as offer http.

[jimangel]

My nginx solution ultimately ended up breaking on me a few weeks ago, and I have since abandoned all Ecowitt products; which is a shame given the amount of investment I had in the ecosystem.

The platform I replaced it with works great and everything just works with Home Assistant; as it should. I am now in electronic-smart-home-weather bliss.

I'd share the replacement info but don't want to sound like an advertisement. For now, I'd like to focus on the shortcomings of Ecowitt 😅 and I hope they update their app!

[adynis]

@jimangel : Please share the replacement info ! :)

[Momro]

Yes, please do so

[mikejmeier]

Just bought some Ecowitt devices (Gateway GW2000B) and discovered they do not support TLS/SSL. I've been using the Nginx Proxy Manager from the default Add on store forever to manage my SSL certificates and proxy traffic for other services and devices on my network. I did not have a HTTP proxy set up so I did the following to get it to work

1. Set a static IP address on the gateway device, I chose to do this through my router but can be set on the device itself.
2. In Nginx Proxy Manager, go to Access lists and add a new one. Call it Ecowitt, go to Access tab, and put in the static IP with a /32 subnet mask. Hit save.
3. in Nginx Proxy Manager, go to Proxy hosts and Add Proxy Host. Domain name will be the IP address of your home assistant, assuming HA is already using SSL: Scheme will be https, forward hostname/IP will be the HA IP address again, and Forward port will be 8123 (assuming you didn't change ports in HA). Select Cache assets and Websockets support. From the Access list drop down, choose Ecowitt. Leave all other tabs untouched. Save.
4. In your ecowitt gateway, for the hostname/IP, use the HA IP, use the path the Ecowitt integration gave you to use, and use port 80. Leave the reporting interval at 60 seconds. Save.

You should then notice your HA Ecowitt integration come alive within a minute or two and start displaying any of the devices you have connected to the gateway. I tested that attempting to navigate to the HA IP address from my browser gave me a 403 Forbidden error, so the access list appears to be working.

I would also like to give a +1 to finding a better way to address this.

[Coder84619]

@mikejmeier earlier in this thread I linked to a blog post I wrote that is much easier. It uses a third party (not mine) Ecowitt proxy add-on that is dead easy to setup.

[richardsg307]

I'm running HA as a generic x86-64 system with Duckdns and https. I just bought the Wittboy system which i've got working on my phone and now find it won't connect to the Ecowitt integration because of the http vs https issue.
I don't understand any of the above. Can someone tell me how to solve the connection problem in a simple way?

[Momro]

Install this:

https://github.com/ChrisRomp/addon-ecowitt-proxy

It contains 100% detailed description.

You need HACS for this. You will find all information on Google how to do that

[richardsg307]

I've installed it manually (ie not the Add Add-on button as that didn't work for me), added the Webhook ID (/api/webhook/ce2e..........................7fb1) and default port (8081) to the Configuration options. I'm still not getting any entities. On checking the log, i can see something is being received every minute (the Upload interval) but I get the error message

2024-07-05 21:37:42 ERROR    HA API Error: 404: Not Found
2024-07-05 21:37:42 INFO     192.168.x.y - - [05/Jul/2024 21:37:42] "POST /log/ha HTTP/1.1" 200 -

The IP is definitely that of the Ecowitt hub.
In the phone ap I have the settings 192.168.x.z for HA, i've tried both /log/ha and log/ha in Path (the /log/ha bit of the error message doesn't change!) and 8081 for the port.
I have HACS installed already, but can't see how I've used it for this!
Any more help appreciated.

[ChrisRomp]

@richardsg307 In the API key field, just put in the api key not the /api/webhook/ part. Just the ce2e...7fb1 part.

[ChrisRomp]

@Momro BTW it doesn't require HACS; it's using the HA add-on model. https://www.home-assistant.io/addons/

[richardsg307]

@richardsg307 In the API key field, just put in the api key not the /api/webhook/ part. Just the ce2e...7fb1 part.

That did it. Thank you so much.

[ChrisRomp]

I've finally gotten around to updating the add-in to do some validation on that field, so hopefully that doesn't keep happening for folks.

[mircob85]

HI,
I have tried several times to configure the add-on but I get this error, even when changing the port.
What can I do? Thank you

`-----------------------------------------------------------
Add-on: Ecowitt HTTP Proxy
An HTTP proxy for Ecowitt weather stations to forward to the Ecowitt integration over HTTPS since Ecowitt does not support HTTPS.

Add-on version: 1.0.1
You are running the latest version of this add-on.
System: Home Assistant OS 12.4 (aarch64 / raspberrypi4-64)
Home Assistant Core: 2024.5.3
Home Assistant Supervisor: 2024.06.2

Please, share the above information when looking for help
or support in, e.g., GitHub, forums or the Discord chat.

s6-rc: info: service base-addon-banner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service base-addon-log-level: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service base-addon-log-level successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
[11:55:59] INFO: Using webhook ID ****************************
[11:55:59] INFO: Using port 8082
Address in use
Port 8082 is in use by another program. Either identify and stop that program, or start the server with a different port.
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service base-addon-log-level: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service base-addon-log-level successfully stopped
s6-rc: info: service base-addon-banner: stopping
s6-rc: info: service base-addon-banner successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped`

[ChrisRomp]

Try port 8083, 8084, etc.

[issue-triage-workflows]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[veilofsecurity]

Still not fixed and workarounds are complex or lower security of entire instance.

[n0nk]

Install this:

https://github.com/ChrisRomp/addon-ecowitt-proxy

It contains 100% detailed description.

You need HACS for this. You will find all information on Google how to do that

In my opinion, this is (at the moment) the best solution and should be mentioned in the documentary on the integration page -> https://www.home-assistant.io/integrations/ecowitt/

[Entropy512]

Install this:
https://github.com/ChrisRomp/addon-ecowitt-proxy
It contains 100% detailed description.
You need HACS for this. You will find all information on Google how to do that

In my opinion, this is (at the moment) the best solution and should be mentioned in the documentary on the integration page -> https://www.home-assistant.io/integrations/ecowitt/

However kinda the whole point if this integration was to get Ecowitt support out of HACS...

What HA really needs is the ability to expose webhooks to HTTP and not HTTPS for purposes such as this. Sadly, I can understand that might be such a niche use case (maybe only Ecowitt) that I'm close to just resuming my work on geting rtl_433_ESP and esphome more robust so I can just receive all of my weather devices with a Lilygo LoRa32...

[Vicio88]

Aggiungendo un'altra soluzione al mix (eseguendo un semplice proxy inverso nginx fai da te): https://gist.github.com/jimangel/77bd9393e0097e748005fb8ee44db6bf

Volevo possedere la soluzione al 100% per garantire la sicurezza e soddisfare le mie esigenze specifiche, tuttavia penso che chiunque fosse disposto a eseguire nginx in un contenitore (o in altro modo) sulla propria rete troverebbe valore nella soluzione.

Nel mio caso, sto eseguendo Home Assistant su un Intel NUC con un'installazione Docker/Supervisor e NON voglio abilitare un endpoint HTTP sul mio HA. Sto anche usando Nabu Casa come destinazione webhook HTTPS esterna per ecowitt, ma potrebbe essere qualsiasi endpoint HTTPS. Buona fortuna!

scusami ho anche io nabu casa cosa devo fare per integrare ecowitt

[Freacly]

@ChrisRomp Thank you so much for your integration! You're a lifesaver.... i almost went crazy before I found your add on.

THANKSS!

[devLeitner]

I have a question regarding what the ecowitt devices are able to do. I ran a http setup for 2 years, but now I have switched to a kubernetes infrastructure. And I really don't want to expose the pod-port all the way to the host.

So now I have a reverse proxy (traefik-ingress) which serves my 'main' url (e.g. homeassistant.mydomain.com) with ssl termination. For the ecowitt I added a second route which is a local only domain (e.g. homeassitant.myhomenet). I resolve this domain via a dns server on my network.

Works great in theory. I can curl homeassistant.myhomenet:80 and can access everything. But I can't get it working with the ecowitt device. I can't set a dns server and I don't have logs to know what the device is doing. But we aren't still in 2005, you should be able to resolve domains / set a dns server. (and terminate ssl but that's another thing)

Are there any other options besides giving this thing an IP and Port?

Edit ( Thoughts I had):
The device can connect to the ecowitt.net network, can't it? This traffic is encrypted and there is a domain name resolution happening. So the device IS able to do this (?!)

[veilofsecurity]

I dont quite follow what your issue is. You can set a static DNS in ecowitt or hand out DNS via DHCP (with reservation if necessary). Unless you are doing sni at reverse proxy you should also just be able to just target the IP of your http domain.

All this assumes you have HA exposed with HTTP in some way or the hotfixed version of HACS Ecowitt.

[rdperkins]

I no longer have a problem with Ecowitt in HA.. Thanks though.

[rdperkins]

No longer have a problem with Ecowitt. Thanks From: vosec ***@***.***> Sent: Monday, December 30, 2024 9:05 PM To: home-assistant/core ***@***.***> Cc: Robert Perkins ***@***.***>; Comment ***@***.***> Subject: Re: [home-assistant/core] Ecowitt Integration - HTTPS requirements non functional (Issue #93000) I dont quite follow what your issue is. You can set a static DNS in ecowitt or hand out DNS via DHCP (with reservation if necessary). Unless you are doing sni at reverse proxy you should also just be able to just target the IP of your http domain. All this assumes you have HA exposed with HTTP in some way or the hotfixed version of HACS Ecowitt. — Reply to this email directly, view it on GitHub<#93000 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AH55NH5WUKHVO7XYFUHFNDD2IH3VDAVCNFSM6AAAAAAX7YOERCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRWGA3TCNZTHE>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[devLeitner]

I dont quite follow what your issue is. You can set a static DNS in ecowitt or hand out DNS via DHCP (with reservation if necessary). Unless you are doing sni at reverse proxy you should also just be able to just target the IP of your http domain.

All this assumes you have HA exposed with HTTP in some way or the hotfixed version of HACS Ecowitt.

I can? The options are to statically set the network conf or receive it via dhcp. But there is no entry for dns, only for IP, subnetmask and gateway.

The decice couldnt resolve/didn't send to the webhook with following configuration.
Hostname: homeassistant.mylocalnet
Path: /api/webhook/xxx
Port: 80

But i couldnt figure out why. I resolved it another way.

(For everyone who stumbles upon this and maybe its helpful: I added an Ingress, which matches on every Host and on a PathPrefix, this PathPrefix gets stripped away later again. So i can query on ip on my external loadbalancer like this: x.x.x.x/homeassitant/api/webhook/xxx)