Closed Loeffelmaster closed 2 months ago
Can you give more info on the issue? There doesn't seem to be any error in the log you shared.
That's the problem, there is nothing else. The only thing I can see is, that after the update the Ecowitt device and all entities went to unavailable. :( When I restart HA the AddOn isn't restartet at least the log doesn't change. Not even, when I make a full restart of the host system. Only when I restart the AddOn.
But the new version is just a bunch of problems. My detection if HA was restarted properly is gone due to the new notify version it doesn't work anymore, then it cries because of a missing repository link for an AddOn without stating which AddOn. Funny because how could I installed it without as I have no AddOn installed by hand.
Ok, it's possible something in the API changed and I didn't see it in time. I'm not on 2024.6 yet but I'll try to upgrade tomorrow or over the weekend and see if I can reproduce the cause. However, based on the other issues you're describing I think the problem is possibly something outside of the add-on.
Can you remove your add-ons? I would also suggest checking the HA core repo issues (link) for anyone reporting similar issues with 2024.6.
As a data point, I am running 2024.6 and the proxy is still working fine for me.
Ok, it's possible something in the API changed and I didn't see it in time. I'm not on 2024.6 yet but I'll try to upgrade tomorrow or over the weekend and see if I can reproduce the cause. However, based on the other issues you're describing I think the problem is possibly something outside of the add-on.
Can you remove your add-ons? I would also suggest checking the HA core repo issues (link) for anyone reporting similar issues with 2024.6.
I removed all repository links, I'm not using anymore and suddenly HA said which repository link was missing, so I could correct this. The start thing I can't repair, as HA devs only say, that notify.restart_notify is deprecated, but they aren't telling you what to use instead. Only that it is via notify.send_message, but not how to use it. But with all the problems the HA devs gave me in the past 12 months I don't expect anything else from them.
In the HA Github there are several reports of integrations and add-ons failing for some users, but I could see no solution for it.
As far as I interpret the log file, this error message kills the ass-on: WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
Why? As you can see in the log (below), after successfully starting all services, this message pops up and then all services are stopped again, at least due to the log. I have fully reinstalled the add-on (deinstall, fully restarting the host, insatlling) but nothing changed. Might it be, that know the add-on only runs on a Pi? I use a HP 500 G6 Elitedesk Mini as the platform.
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 [10:48:46] INFO: Using webhook ID xxxxxxxxxxxxxxxxxxxxxxxxxxxx [10:48:46] INFO: Using port 8081 2024-06-06 10:48:50 INFO WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
The dev server warning doesn't kill the server; it's just a warning and I see that in mine, too. Is your Ecowitt able to hit http://10.101.3.10:8081/log/ha
?
Also check the supervisor logs: https://my.home-assistant.io/redirect/logs/?provider=supervisor
This should (hopefully) show the add-in errors, if any: https://my.home-assistant.io/redirect/logs/?provider=1d2e7f3c_ecowitt-proxy
The dev server warning doesn't kill the server; it's just a warning and I see that in mine, too. Is your Ecowitt able to hit
http://10.101.3.10:8081/log/ha
?
No, not available.
`Die Website ist nicht erreichbar10.101.3.10 hat die Verbindung abgelehnt. Versuche Folgendes:
Verbindung prüfen Proxy und Firewall prüfen ERR_CONNECTION_REFUSED`
Also check the supervisor logs: https://my.home-assistant.io/redirect/logs/?provider=supervisor
Nothing to see in the supervisor log. (attached) supervisor_2024-06-06T18-28-35.477Z.log
This should (hopefully) show the add-in errors, if any: https://my.home-assistant.io/redirect/logs/?provider=1d2e7f3c_ecowitt-proxy
Just the same as I posted before.
2024-06-06 19:23:45.938 INFO (MainThread) [supervisor.addons.addon] No 1d2e7f3c_ecowitt-proxy addon Docker image 1d2e7f3c/amd64-addon-ecowitt-proxy found
2024-06-06 19:23:45.939 INFO (MainThread) [supervisor.docker.addon] Starting build for 1d2e7f3c/amd64-addon-ecowitt-proxy:0.1.18
2024-06-06 19:24:04.643 INFO (MainThread) [supervisor.docker.addon] Build 1d2e7f3c/amd64-addon-ecowitt-proxy:0.1.18 done
2024-06-06 19:24:04.712 INFO (MainThread) [supervisor.addons.addon] Creating Home Assistant add-on data folder /data/addons/data/1d2e7f3c_ecowitt-proxy
2024-06-06 19:24:04.713 INFO (MainThread) [supervisor.docker.addon] Starting build for 1d2e7f3c/amd64-addon-ecowitt-proxy:0.1.18
2024-06-06 19:24:05.267 INFO (MainThread) [supervisor.docker.addon] Build 1d2e7f3c/amd64-addon-ecowitt-proxy:0.1.18 done
2024-06-06 19:24:05.267 INFO (MainThread) [supervisor.addons.manager] Add-on '1d2e7f3c_ecowitt-proxy' successfully installed
Looks like it wasn't installed, and the supervisor installed it here. This is pretty normal. And your earlier add-in logs look normal except for where it just shuts down. Are you stopping the add-on manually or is it automatically shutting down?
In most cases if we see the startup logs and then no activity, it just means that Ecowitt isn't posting anything to the add-on (i.e. no traffic), either because nothing was sent or something else is blocking network access.
Searching for s6-rc: info: service legacy-services: stopping
shows other HA add-ins having something similar happen, but I don't see any common causes.
I'll update my HA over the weekend and test on 2024.6.
Are you stopping the add-on manually or is it automatically shutting down?
When I start the add-on it immediately shuts down again. This is no manual shutdown, but when I look at the add-on controls HA says that it is running.
I did a full reset on the Ecowitt integration, so new webhook id and everything. Now it is back online and working. I have no idea what happened there.
Solved by total reconfiguration of Ecowitt integration.
Thanks for updating!
The proxy worked perfectly not like the NGinx shit. But now with the new version the proxy breaks. Due to the log it is started and I can open the website, but the Ecowitt integration shows the device as unavailable.
This is my log:
`----------------------------------------------------------- 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: 0.1.18 You are running the latest version of this add-on. System: Home Assistant OS 12.3 (amd64 / generic-x86-64) Home Assistant Core: 2024.6.0 Home Assistant Supervisor: 2024.06.0
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 [02:46:10] INFO: Using webhook ID xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [02:46:10] INFO: Using port 8081 2024-06-06 02:46:14 INFO WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.