Ingress support has been added, which means the add-on works via the cloud connection as well, simply by clicking the “OPEN WEB UI” button on the add-on page.
You can still enable the “old” direct access method, by setting a port in the network section of the add-on configuration panel.
Updated and everything seems to work. However, there is no info anymore showing when I node was last triggered and the Debug node does not show any information in the Debug panel.
Update, got Debug and Statuses to work by accessing hassio directly (ip:port) instead thru reverse proxy - so seems to be an issue when going thru reverse proxy server.
Same here as well… at least using chrome. Using the WebGui link opens the “embeded” version but still does not login, showing an empty page with just the nodered logo on top.
Shift+F5 end up showing:
Update: Using Firefox the external site is working including login
Which listens on /eagleentery on port 1880. Is there a way to disable authentication or use some type of token that I can append to the URL that I add to my smart meter?
Replying to my own post, adding leave_front_door_open to the config and removing the username/password is letting my POST get through. I wish there was a way to secure the web UI, but allow other access. Maybe in a future version.
STATUS: The port method doesn’t let me login. On the Ingress method, I’m seeing webpage loading errors. This happens when accessing it the second time on the http load not on the https(works fine on https)…
Clearing cache helps load once again on http(local ip) and when i try to load page the second time it fails again to load and then i see the below page errors.
Https (port 1880) login is possible for me but only using firefox, chome is not working. (ssl enabled via addon config/ ssl is not enabled for HA itself). The Ingress method is not working for me at all.
Looking to get a different adress to use with panel_iframe. When I take the url when using the web_ui from the add_on page and try to use it with panel_iframe I get the panel doubled. I had the same problem with configurator but was able to find another url following the instructions from this page:
When I look at the adress I have for node_red it is:
I’ve been having a lot of trouble accessing Node-RED after 3.0. To access via ingress I seem to have to force refresh every single time in order to get it to load at all. Otherwise it just loads the basic frame but no content. When it does load, many of the icons for nodes are broken images. Which ones seem to vary. In addition, sometimes I have to force reload several times to get it to load. This is in Chrome.
After first enabling the port method again, I had the issue where it asked for credentials over and over and never loaded. But after clearing all my browser data, port method seems to be working and reliably loading.
Any advice on how to troubleshoot please. NodeRed has been running fine but when i tried to upgrade yesterday to 3.0 using the Hassio webinterface i get the following error message.
19-04-15 22:16:28 INFO (SyncWorker_17) [hassio.docker.interface] Pull image hassioaddons/node-red-armv7 tag 3.0.0.
19-04-15 22:16:29 ERROR (SyncWorker_17) [hassio.docker.interface] Can’t install hassioaddons/node-red-armv7:3.0.0 -> 500 Server Error: Internal Server Error (“readlink /mnt/data/docker/overlay2/l: invalid argument”).
I tried uninstalling NodeRed in the addons and rebooting, and then trying to install from scratch but same issue.
After upgrade to 3.0.0 and setting network port running in to issues accessing Node Red instance via reverse proxy. Monitoring tools like uptimerobot and freshping do not see Node Red as up while it’s running just fine if accessing directly. Also log now shows all web activity which didn’t show before?
I wish I could have a choice to use Ingress or not. This is a major breaking change.
This is an unfortunate docker issue that points to some corruption in the filesystem. It’s been coming up a lot lately but I think the common factor is a pi and SD ? I may be wrong.
The best thing to do is reflash and restore from snapshot, since the fix involves removing everything anyway.
For people who opened direct access by enabling and setting the port to 1880 and experiencing repeated login cycles. This might be a solution to resolve it:
It seems like node-red stored a piece of information about the login system used in versions of the node-red add-on before v3.0.0 (e.g., v2.0.2).
This authentication method does not exist anymore but nevertheless, throws off Node-RED so it seems.
Removing this manually helps in all the tests I’ve done tonight.
I pasted this as my node red url for panel iframe and it worked as before. No need to enable any ports.
I reached it immediately from my iMac. I initially had problems with my iPad (unauthorized 401). But if I first entered either add-on (I also have configurator) from the web ui link on the I could access it directly from the panel.