Interesting problem:
Recently I switched ISPs to one that uses CGNAT and no longer can get a routable public IP from them.
Config is a supervised Debian VM, doing the full (old terms I know) HassIO thing.
I had the DuckDNS add-on and LetsEncrypt going on before. Useless now.
But I also have a Nabu Casa subscription so it really didn’t matter.
Eventually the LetsEncrypt certificate expired and this caused havok with the Android App. So I thought, no big deal, time to revert HA internally back to non-https.
I removed the add on, and commented out the stuff in configuration to go back to http… all seemed fine at first.
But then I noticed this oddity:
- Using the side panel add ons that use ingress flash and go blank going to http://internalIP:8123
- If I go out the internet to my Nabu Casa remote link, they work fine being passed out to it and back
What in the WORLD is ingress doing??? Hahaha… so strange.
By the way, something went haywire in the last update and filled my VMs hard disk, and ya know how hard it is to recover the system when BOTH of these things are going on via the web… hahaha… anyway, thank goodness for VM backups… ha.
Any thoughts on how to get internal non https ingress working again?
Piles of this in the logs when I try anything…
“21-10-01 14:44:26 WARNING (MainThread) [supervisor.api.ingress] No valid ingress session None”
I also see ONLY for the Node-Red Add-On, this…
“21-10-01 14:33:30 WARNING (MainThread) [supervisor.addons.options] Option ‘require_ssl’ does not exist in the schema for Node-RED (a0d7b954_nodered)”
I’m wondering if the initial install of the DuckDNS add on plus setup of the LetsEncrypt certs is somehow automated that it changes configs of other add-ons in ways there’s no clean way to reverse?? Unless the Android App can learn to ignore an expired ssl cert, I definitely don’t want SSL inside the LAN right now.
(And yeah I thought about using a self-signed cert and dealing with that to make Android happy internally, but that’s hideous.)