For those of us with local push IoT devices that don’t support SSL, like the Ecowitt Weather Station, please enable webhook handling on the internal_url if SSL is enabled with the http configuration.
The Ecowitt integration used to use a dedicated listening port to handle the Ecowitt POSTs but has been updated to use webhooks. However that now requires the NGINX TLS Proxy Add-on which itself requires the MariaDB add-on. Not exactly a clean solution. Since the web UI is already available on the internal_url, it doesn’t seem like it would be much of a security issue.
Perhaps, but I traced the webhook registration and handling of the Ecowitt integration. It works fine if a webhook POST is made to the SSL port. But the same post made to the non-SSL port results in no callback to the integration code although the TCP connection is handled.
It seems you make a generality from an Ecowitt issue, maybe?
You might open an issue towards the Ecowitt integration.
If you are then told to create a feature request, be specific that it is related to that integration, because the current title doesn’t make sense.
My suspicion is that it’s an Ecowitt limitation, though.
Which is even more confusing as the integration doc specifically say it doesn’t support SSL
Yes, the problem is that the Ecowitt device is not an SSL-capable HTTP client. However, any small embedded device can generate an HTTP POST using a sockets interface. I am making a generalized feature request so that these types of devices can be integrated into HA using webhooks. It is not an Ecowitt integration issue since that integration uses the HA webhook registration and callback methods. My requested change is to the HTTP websockets interface to allow /api/webhook requests to be handled on the internal_url socket without using SSL.
OK, I think you’re missing the point here. This isn’t a bug report about webhooks not working. This is a feature request to enable webhooks on a non-SSL port if SSL is enabled. If today HA only responds to either SSL or not doesn’t mean it has to stay that way. Handling HTTP requests from multiple SSL and non-SSL ports is quite feasible–Apache has virtual hosts for that very reason. And HA currently knows enough right now to redirect a non-SSL request to the web configurator:
If you have something to say on the merits of this feature request, let’s hear them. For me, it generalizes the ability to use webhooks for simple IoT devices to pass data to HA. The developers can decide if this request is worthwhile or feasible.
Necro post but I’m having this same exact issue so +1. I have SSL on HA and I want to use the webhook feature from F.lux software, but it seems to only support non-ssl.
