Node red not loading dashboard after several days use on IOS devices

Node-RED
, , ,
1

Hi all, node red is failing to load on my ios devices (iphone and ipad) after several days of use.

image
image758Ă—1000 64.4 KB

Initially everything works fine. Then after a few days, I get the page above displayed instead of the dashboard, on either the ipad or the iphone or both.
Clicking Retry does nothing,
Refreshing, closing, reopening the browser, does not fix the issue.
Restarting the node red service, does not fix the issue.
Restarting the CerboGX does not fix the issue.

The dashboard still works fine on other devices (Windows). It will also work on other IOS devices while the other is displaying this message…eventually the other ios device(s) will eventually display the same message.
This page displays in both the Safari and Chome browsers on IOS.
Node red is a clean install. and the Cerbo GX firmware is up to date
I have tested with the most basic flow possible. An inject node outputting a timestamp to a text box, with the same results
Clearing the browser cache fixes the issue but is not a practical solution.

If I install the official node red image on another server. Node red works fine without any issues. So it appears to be specific to the Victron install of node red.

One question, how is Victron enabling https on port 1881 for node red? There is nothing in the node red settings.js files, where the https settings are documented out.

I suspect it’s a certificate issue, though I can’t be certain

Anyone else have this issue or know of a solution.
Thanks

2

Turns out Victron are using poorly created https certificates that do comply with IOS guidlines.
see here: Requirements for trusted certificates in iOS 13 and macOS 10.15 - Apple Support

3

I see this same behavior and the only way I can get around it is going to my local node-red editing page (10.0.0.9:1883) and then clicking on the dashboard link in the top right.

It is a downright terrible solution and I wish I had something better to offer.

Anyone else come up with any work around or fix?

4

I really doubt that this is caused by the used certificate and like to get a bit more background and possibly a few more screenshots showcasing this problem so I can try to replicate it first and hopefully fix it.

5

I was also doubting the credentials things as well, as the Node-Red configuration/editing page (10.0.0.10:1881) always, always is working. It is only when the /dashboard page is added to the URL that the problem arises.

It does not ever happen on my Windows machine (Chrome browser), but it does happen on iOS devices (phone and tablet) using Chrome or Safari as the browser.

I have no idea if this is an issue on Android devices.

I am using dashboard 2.0 (I don’t think this happened with Dashboard 1.0, however I can not say this conclusively as I have not used that interface in any flows in a long time)

I have three pages under Dashboard,

  • …/dashboard/InventerControl
  • …/dashboard/InverterControlInstructions
  • …/dashboard/HotWater

If I try to go to any of these pages (once the problem presents itself), I get the same response from the web server:

image
image1206Ă—2622 151 KB

Interestingly, if I go to a made up path, such as …/Dashboard/MadeUpPage, I also get the error, but if I go to a made up path, such as …/dashboa I get prompted to confirm access to an un-trusted site, which I give, and then I am given a response that the ./dashboa path could not be found:

image
image1206Ă—2622 52.1 KB

But after that occurs, if I go to …/Dashboard, it then starts to work!

It would appear that the acceptance of viewing the “non-trusted” page times out, so by going to an non-existent page, I force the browser to re-confirm that I want to in fact go to this site (which must be stored as the domain only within the browser). Maybe this is a Cookie issue?

I don’t claim to understand the workings of this, but I can at least pass on these observations.

If you are not able to re-create this on your end, I could add you to my system as a user and you could remotely access my Node-RED using VRM, but let’s try to exhaust other possible means to debug this first, please.

Let me know if there is other information I can provide,

Mike

1 Like
6

Bump. @dfaber Any thoughts? Happy to help diagnose. I’m comfortable getting into Linux and checking any logs, etc.

Mike

7

Nothing from my side yet. Haven’t been able to reproduce this. Though I admit in not having spent too much time on this.
Just did make a setup that will should suffer from this.

Just to be sure. Are you experiencing this when accessing the dashboard locally or via the VRM buttons?

8

I almost always access locally via the internal website. I have accessed before from the VRM portal and it has always worked, but I would only do that when off the boat(rare, unless I’m showing someone my script), and I don’t think I’ve left those web pages open to where this error could occur, if that makes sense.

Standing by.

Mike

9

Yes, makes sense.

I did think of a work-a-round for you that you might want to check: Venus OS Large image: Signal K and Node-RED [Victron Energy]
So running Node-RED locally on a non-https port besides the https one. Might not be ideal either, but should at least solve things for on the boat until we find the actual fix.

Meanwhile I still haven’t been able to see this on my local setup. Probably need to set this test up on my home computer instead of on my laptop.

10

Thank you @dirk

I had actually came across this and tried that, but the Node-Red dashboard does not respond at all to me on 1880 (http) after following these steps.

Mike

11

@njka

If you get a chance, can you check to see if this problem still exists if your GX device is updated to V3.66? I just updated to that version about a week ago and since then have not encountered this problem. Could be a fluke, but getting your experience would help us all understand if maybe it was unexpectedly fixed?

Mike

12

I’ve been experiencing this issue ever since I started using VenusOS Large and Node Red back in the spring of 2025. I have tried everything I can to get my iOS device to trust the SSL certificate and I think I have made progress there. But regardless of browser on my iOS device (Chome and Safari), I continue to receive this error for the /dashboard page.

I initially tried to save the /dashboard URL to my Home Screen as it’s own app. This works for a short time until the app encounters the reload error. From there forward the Home Screen link is useless and broken and must be deleted. If accessing the /dashboard URL from within the browser directly, at least I can back out the URL from /dashboard/page1 to “/dashboard”, and the page will eventually reload.

Very frustrating and is a HUGE limitation if mobile functionality for an ALMOST amazing product and implementation.

I am running Venus OS v3.65

Update: Updated to Venus OS 3.66. Will monitor and provide feedback.

13

I have already experienced the same thing with the node red dashboard on VenusOS 3.66.

IMG_7618
IMG_76181206Ă—2153 135 KB

In the site URL, backing out the URL from the end, essentially removing “/page1” so that all that is left is “https://:1881/dashboard” is the work around to get the page to load without losing the open tabs in the browser.

14

Adding one more tidbit, a month or two ago I attempted to get the Cerbo to listen on 1880 for HTTP traffic in attempt to remove SSL from the equation but I could not get it to answer after following the link posted earlier in this thread….

15

Just getting back to my boat/computer after a trip and yes, I also experienced it again on V3.66.

I was able to follow the steps in the post from @dfaber and I am able to access on port 1880, however it also didn’t work for me the first time. The only thing I can think of if is I may have not rebooted the first time. @jcic I would suggest trying again since the steps in that article did work for me the second time I tried.

Mike

16

@MikePail When you experienced the Node Red reload issue again, was it over HTTP or HTTPS?

When I attempted to allow connections on HTTP I do not think I powercycled the entire Cerbo, but I did restart Node-Red. I thought the documentation stated that was all that was needed. If you continue to experience this issue and are using HTTP, then I’m not sure it’s worth the trouble going that direction.

17

I was able to get the cerbo to listen via HTTP on port 8080 after a reboot. So I’m running it this way until I can determine if I continue to have the “Reload Page” issue.

1 Like
18

It doesn’t seem like this topic is getting much attention but I thought I would check in with an update. Ever since configuring the Cerbo to listen on HTTP on port 1880 I have not encountered the reload issue. It certainly seems like an issue specific to SSL.

1 Like
19

I concur.

20

Have you tried using venus.local as the hostname instead of the IP for local access?