home-assistant
deCONZ in Ingress: failed login attempts when only surfing/loading Phoscon app
Describe the issue you are experiencing
Only surfing /core_deconz/ingress and selecting "Phoscon" ("deCONZ" works just fine) creates failed logins for the client. When using HTTP security (ban module on frequent failed logins) this immediately leads to a blocked client in ip_bans.yaml which hurts quite a bit (need to clean the file and restart HA Core):
xxx.xxx.xxx.xxx:
banned_at: '2024-05-10T15:38:43.146448+00:00'
I can reproduce this issue with different clients (Win 11 in Firefox, iOS with HA Companion app, doesn't really matter).
It is sufficient to only load the Phoscon part, no need to enter any password at all. Some automatic API request seem to fail.
Assumption: As probably most users don't use HTTP security this issue has not been discovered so far.
What type of installation are you running?
Home Assistant OS
Which operating system are you running on?
Home Assistant Operating System
Which add-on are you reporting an issue with?
deCONZ
What is the version of the add-on?
6.23.0
Steps to reproduce the issue
- Load deCONZ in ingress (
/core_deconz/ingress) - Select "Phoscon"
- Wait and see the failed logins
System Health information
System Information
| version | core-2023.4.6 |
|---|---|
| installation_type | Home Assistant OS |
| dev | false |
| hassio | true |
| docker | true |
| user | root |
| virtualenv | false |
| python_version | 3.10.10 |
| os_name | Linux |
| os_version | 6.1.73-haos-raspi |
| arch | aarch64 |
| timezone | Europe/Berlin |
| config_dir | /config |
Home Assistant Community Store
| GitHub API | ok |
|---|---|
| GitHub Content | ok |
| GitHub Web | ok |
| GitHub API Calls Remaining | 5000 |
| Installed Version | 1.32.1 |
| Stage | running |
| Available Repositories | 1478 |
| Downloaded Repositories | 85 |
| HACS Data | ok |
Home Assistant Cloud
| logged_in | false |
|---|---|
| can_reach_cert_server | ok |
| can_reach_cloud_auth | ok |
| can_reach_cloud | ok |
Home Assistant Supervisor
| host_os | Home Assistant OS 12.2 |
|---|---|
| update_channel | stable |
| supervisor_version | supervisor-2024.05.1 |
| agent_version | 1.6.0 |
| docker_version | 25.0.5 |
| healthy | true |
| supported | true |
| board | rpi4-64 |
| supervisor_api | ok |
| version_api | ok |
Anything in the Supervisor logs that might be useful for us?
No, nothing specially related to deCONZ. But see HA logs below.
I see one entry which might be related to "a0d7b954_vscode" used at the same time and having some more log entries before (please check with port and URL if this is deCONZ or VS Code related):
2024-05-10 17:38:26.680 ERROR (MainThread) [supervisor.api.ingress] Stream error with http://172.30.33.2:8099/pwa/language/de/index-de.json: Cannot write to closing transport
Anything in the add-on logs that might be useful for us?
Unfortunately I could not grab addon logs, as the productive log data was too much so the ones from around the last incident was not visible anymore.
Anyway, this is what is logged in HA log:
2024-05-10 17:38:27.691 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from client-name.local (xxx.xxx.xxx.xxx). Requested URL: '/api/config?_=1715355507074'. (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0)
2024-05-10 17:38:32.428 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from client-name.local (xxx.xxx.xxx.xxx). Requested URL: '/api/config?_=1715355507075'. (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0)
2024-05-10 17:38:38.146 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from client-name.local (xxx.xxx.xxx.xxx). Requested URL: '/api/config?_=1715355507076'. (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0)
2024-05-10 17:38:42.462 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from client-name.local (xxx.xxx.xxx.xxx). Requested URL: '/api/config?_=1715355507077'. (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0)
2024-05-10 17:38:43.126 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from client-name.local (xxx.xxx.xxx.xxx). Requested URL: '/api/config?_=1715355507078'. (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0)
2024-05-10 17:38:43.129 WARNING (MainThread) [homeassistant.components.http.ban] Banned IP xxx.xxx.xxx.xxx for too many login attempts
Additional information
Possibly related to the Phoscon bug introduced with addon version 6.21.0 (https://github.com/home-assistant/addons/pull/3226#issuecomment-1737293462), being reverted in 6.22.0 and "somehow" fixed (worked around?) in 6.23.0.
During that adventure the Phoscon page was in the spotlight of issues already. Maybe this issue is a leftover or a side effect of the fix.
Similar issue, I get this problem when starting Phoscon from Campanion app but not from Chrome on windows
Test 1: Tried with Google Chrome on Android - same issue.
It really doesn't matter which browser/app is used.
Really starts to annoy me as hell as it makes it impossible to use Phoscon ~at all~ in Home Assistant!
Test 2: Tried to directly access Phoscon by using http://servername.domain:40850 in the browser. This is working - as it bypasses Home Assistant's UI. So it seems to be an Ingress related issue.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Still broken. And no one cares. Great perspective for deCONZ users in Home Assistant.
Yes still broken. It's really strange that there aren't more complaints. I know for myself that the next coordinator will not be a conbee.
Same problem here, successfully locked me out with all my devices somehow :)
This is the request that fails:
Seems like it is also an old problem: https://github.com/home-assistant/addons/issues/929
The lack of interest from HA side (because of ZHA) and the lack of man power (and understanding how important the HA addon is in their chain and for their user base) from Dresden will very likely be the reason for this issue to never get solved. Same drama like with releases (we're now half a year behind the latest release...).
For this case both is needed: knowledge of Phoscon and of Ingress (HA side).
Feel free to prove me wrong.
Upgrade deConz to v2.27.6 :) https://github.com/home-assistant/addons/pull/3708
Upgrade deConz to v2.27.6 :)
https://github.com/home-assistant/addons/pull/3708
Interesting. Where's the proof it fixes the issue? Any specific change or what are you referring to?
And recent PRs for the 2.27.6 release have been rejected so far, so I don't see a quick solution yet.
Still exists for me with deCONZ v2.28.1 (updated following https://github.com/home-assistant/addons/pull/3708) 😞
As this issue sits right between the two competence fields of both involved parties (HA team on the Ingress side and Dresden Elektronik team on the deCONZ side), I doubt this will be fixed or even looked into until they found an agreement on the deCONZ addon support topic.
Yes, I ordered sonoff zigbee dongle E and I am moving my zigbee network to it right now.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Massive issue, definitely needing a fix. Phoscon not usable in HA ingress at all with http settings enabled.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Same probleme here I will send the Raspbee back an switch to another Zigbee solution for HA
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Nope. Alive. And annoying on a daily basis. deCONZ is useless (unusable) in Ingress.
Problem besteht weiter, ich habe meinen neuen ConBee_III zurückgegeben. Warum soll ich einer Firma weiter Geld geben wenn es keinen Support gibt. Ich nutze weiter meinen ConBee_II mit dem gleichen Problem (nur um mal zu schauen wie lange das noch dauert um ein so "kleines" Problem zu lösen). Ich glaube in Dresden wird nur als Hobby in der Garage gebastelt. Neue und gute Lösung für mich: SLZB-06. Sehr schade, ich hätte lieber von einer deutschen Firma gekauft...............
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Dear bot you are absolutely annoying and useless (at least a nice reminder we still suffer from an issue) because no one is taking care to fix this issue.
Because of this it will stay open until someone will fix it. So we will play this stale -> unstable game like forever.
From what I can tell, this is a problem of the Phoscon web app. It seems to poll the absolute path /api/config on the origin host/port, which is where Home Assistant Core http server is at.
Phoscon should not poll that end point, but instead the relative endpoint... Ingress only works reliable if all requests back to the origin server are done using relative paths. I don't think much can be done from the add-on side.
Interesting discovery. So when was this behaviour introduced and how could it be reverted or modified in the way you mention it?
Some deCONZ expert is needed very likely.
Interesting discovery. So when was this behaviour introduced and how couldn't be reverted or modified in the way you mention it?
I don't know. Based on your observations I guess somewhere between 2.22.2 and 2.23.1.
It seems that the problem sometimes stops from happening. I think after a login and manual logout, but I might be wrong on that.
Test 2: Tried to directly access Phoscon by using http://servername.domain:40850 in the browser. This is working - as it bypasses Home Assistant's UI. So it seems to be an Ingress related issue.
That makes sense, as the port is different in this case, so the Phoscon App running in your browser won't bother the Home Assistant Core web server (running on a different port).
There seems to be some scanning running on the login page which causes this. Not sure if we could disable this feature for the add-on case, since in this case we know exactly where to find the gateway.
@manup has maybe insights based on this observation?
An old thing / not the first time this behavior is seen:
https://github.com/home-assistant/addons/issues/2658
Hello everyone, the bug has now been fixed with version 2.31.1-beta and will soon be available to everyone. So just a little patience.
A big thank you to @manup.
Stable v2.31.2 containing the fix is available now.
Who will file a PR to update the deCONZ addon?
https://github.com/dresden-elektronik/deconz-rest-plugin/releases/tag/v2.31.2