Node red and remote console v1 not reacheable from VRM

Node-RED
, ,
1

Hello

I need some help. I recently upgraded a CerboGX system to the latest firmware. First I tried the latest Beta but I went back to the latest stable version 3.75.

The system is working fine. I am able to access GUI-v1 GUI-v2 and Node Red. But unfortunately GUI-v1 and Node Red only locally.

I cannot reach GUI-v1 or Node Red via the VRM. GUI-v2 is working fine via VRM!

When I try to open Node Red the screen stays white and after a while I see this message: Token expired. Go back to VRM and try again.

I go back to the VRM hit F5 and try again. Same white screen.

When I try to open the GUI-v1 console I see this:

image
image800Ă—506 95.5 KB

and when I select classic UI I see this:

image
image679Ă—362 4.48 KB

after a while I get this message:

image
image620Ă—289 5.73 KB

When I start console GUI-v2 I am able to connect and that is working.

image
image1339Ă—776 112 KB

I maintain more systems and I don’t experience this with other. Other systems I can reach by VRM. Also I tried another computer/browser and still the same. Also I tried another VRM account (from customer) and it behaves the same.

I have access via tailscale to the system so could someone help me to investigate whats wrong?

Maybe there are some “beta left overs” on the system I need to clear?

Your help will be appreciated

PS If this is not the right topic (node-red) please move it to the correct topic.

2

This weirdness pops up occasionally.
For nodered have you tried to export your flow, use the nodered reset to default option to reinstall it, then import flows again?
Sometimes that helps in fringe cases.

3

Thanks @nickdb I till try that.

But the strange thing is that Gui-v1 is also not reachable…

4

That is indeed strange. They use two very different forms of comms.

5

Unfortunately that didn’t help

I have checked all kind of log files but I cannot find any suspicious things.

I was wondering if Victron could help me and they could check my system? Or they are able to see something from the VRM side?

It could be also an issue from the VRM side.

Any help would be appriated

6

Are you using both the wifi and the ethernet interface by any chance?

7

The Cerbo is connected by ethernet and wifi is disabled in the GUI.

Both option: Acces point is switched off and Use Wifi for internet is also switched off

8

What are the digits in the vrm url?

9

XXXXXX

XXXXXX-nodered.proxyrelay1.victronenergy.com heeft geen gegevens verzonden.

ERR_EMPTY_RESPONSE

10

This might sound silly, but have you tried just rebooting any local wifi ap’s and routers? Sometimes something gets stuck.

11

That’s not that silly. That was the first thing I did. This site has KPN routers and they have a reputation…

12

Maybe a security setting? Can you access Node red locally from a PC on the same LAN?

13

Yes, as per the original post:

14

Summary:

CerboGX version 3.75 CerboGX is connected via LAN. The system worked fine until I upgraded from version 3.40 to 3.80Beta and back to 3.75.

Some background information:

The reason why I upgraded was the support for a feature of SolarEdge 4k and 5k pvinverters in the latest 3.80Beta. As a test I downgraded to the latest stable version 3.75 and the SE worked with this release as well so I want to keep 3.75. The system is working as it should only I am unable to acces GUI-v1 and the Node-red flows via the VRM.

Works locally:

  • SSH
  • GUI-v1
  • Access to Node-Red flows
  • GUI-v2

Works using VRM

  • Remote console GUI-v2
  • SSH via Tailscale

Doesn’t work using VRM

15

I have asked if someone could have a look.

What you can also try as a last resort, on the gx disable vrm access and enable it again. Try adjust security levels in case that has an effect.

Lastly, for weird and persistent issues follow the chapter 19 reset to factory procedure. You’d be surprised how often that works.

16

I had a look.

What is happening is that part of the process that starts up the tunnel for things like GUI-v1 and also Node Red, also enumerates the connections to EV chargers, and your two EV charger processes are currently hanging and cannot reply. This creates a delay long enough that things time out.

The reason why they are hanging, is because the process is scanning the network for new hardware, and it’s trying to talk to two SolarEdge devices you have, IP addresses ends in 103 and 104.

Autoscanning is disabled, but these addresses are configured as devices, which I assume is incorrect. SolarEdge PV-inverters are handled by the PV-inverter settings, not the modbus devices settings. So removing those addresses from the modbus devices and rebooting should resolve it.

17

@iburger Thank you very much!

I will change this to tonight. (FYI it was working with version 3.40. But this was pre GUI-V2)

to be sure just remove these two:

image
image1348Ă—371 41.6 KB

18

I don’t know what 102 is either, currently nothing seems to be on that address (ARP did not resolve so I could check the manufacturer), odds are 102 also should not be there. Unit ID 126 would suggest it was targetting a PV-inverter, so it should probably go as well.

19

@iburger and @nickdb

Thank you very much for your support. I just rebooted and all is working fine.

Thanks

20

102 is/was an old SolarEdge 2200 device. I will remove it as well