HTTPS requirement upon change to core version of plugin.

[JohnMcLear]

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 https://github.com/garbled1/homeassistant_ecowitt/issues/149 but I wanted to create a new issue to remove the noise

[rbauman70]

John, I encountered the same problem as you when I upgraded to the latest version of HA. Since I don't think we can count on Ecowitt to support SSL connections, I've managed to work around the problem by redirecting the my Ecowitt Gateway's POSTs to a PHP handler and reposting it to my HA SSL port. I'm using the HA container version and have PHP available in the Linux distribution. I was surprised that the HA Web UI is available on the HA port using a non-SSL connection (http://) so I had hoped the websocket/webhook handlers might be available there too, but no such luck. According to Wireshark, the HTTP POST is acknowledged but nothing happens in HA. This would certainly solve the Ecowitt problem for us.

My workaround was to use PHP's built-in server and define a handler in the docroot's folder as index.php.

<?php
#
# Redirect Ecowitt POST to our Home Assistant instance as a webhook
#

#error_log( print_r($_SERVER, true) );
#error_log( print_r($_POST, true) );

$MYSTATIONID = 'ecowitt';
$ha_url = 'https://MY_HA_URL';

$ch = curl_init();

# configure the Ecowitt device custom service path as /api/webhook/WEBHOOK_ID.
# concatenate it to the HA URL.
curl_setopt($ch, CURLOPT_URL, $ha_url . $_SERVER["REQUEST_URI"] );

curl_setopt($ch, CURLOPT_HEADER, true);
curl_setopt($ch, CURLOPT_POST, true);

# override the stationtype so firmware updates don't change the sensor names
$_POST["stationtype"] = $MYSTATIONID;

curl_setopt($ch, CURLOPT_POSTFIELDS, $_POST );
$result = curl_exec($ch);
curl_close($ch);
#error_log( print_r($result, true) );
?>

The PHP server is started as

/usr/bin/php -S 0.0.0.0:8000 -t YOUR-WEBROOT-DIRECTORY

In the Ecowitt web UI, I set the customized weather service server to my Linux server, port to 8000 and the path to the same one that the Ecowitt integration displayed on setup, something like /api/webhook/XXXXX. Once I had it all working, I used a system service to automatically start the PHP server for the handler.

You might notice that I overrode the stationtype form variable. The newest Ecowitt integration uses the stationtype variable in the sensor names. At least with my gateway, that seems like a poor idea since the stationtype name will change if the firmware gets updated and there's no way to set it through the Ecowitt web UI. A better way would be to use a user-supplied field in the integration config flow to uniquely identify the Ecowitt instance being integrated.

Hope this helps you with the HA Blue hardware.

Ron

[JohnMcLear]

@rbauman70 Afaik that doesn't solve the problem as HA operating system doesn't like you altering the OS.