I have a specific installation (v3.62) that takes forever to connect to the node-red proxy as advertised by the VRM, i.e. when I try to access it through the VRM (“Venus OS Large” menu). Sometimes the connection completely times-out. Both the node-RED editor and the node-RED Dashboard do this. I have not yet tested local access when this happens, however the nodes seem to work fine, since the system does what it’s supposed to do, according to the set scripts.
Everything else Victron-specific or otherwise network-related is working fine, it’s just the node-RED stuff that do this.
I have restarted the Cerbo, with no luck. Is there anything else I can try, to make things better? It used to work fine, a few days ago.
Above-discussed situation lasted for a few hours, and then connectivity to Node-RED running on the Cerbo was re-established. However, a few days later I am having the exact same issue. My installation currently uses “******-nodered.proxyrelay7.victronenergy.com” as a relay. Yesterday, if I remember correctly, this installation was using proxyrelay1. Any chance there’s a server issue at play?
Having the same issue again, on the same installation. Node-RED and its dashboard take forever to load. Again on proxyrelay7. Is there a trick I can use so as this specific installation will use a different proxy to talk to the outside world?
I’ve now tracked the issue to part proxing and part the internet provider. The Cerbo gets online using an ethernet cable. However, the building’s owner is using a “hybrid” internet connection, it’s copper with a fall-back to 4G data, when there seems to be something wrong with the landline. For some reason, whenever the “fallback” is activated, I loose any connectivity to anything node-red related. VRM and everything else keeps working fine, though. Strange thing is that, if there is an active connection to the node-red dashboard, falling back to 4G doesn’t seem to hurt; it’s only the initial connection that has issues.
I do have a node red flow, but not a particularly complex one. The flow is getting the inverter power in real-time and setting the grid point accordingly, so as not to have back feed to the grid. Also switching to “inverter only” when demand is low and the battery is charged.
While the contact to nodered is lost (remotely or via LAN), the flow works flawlessly, since all expected functions are working.
Maximum feed-in or grid set-point don’t work fine in my case, where I need absolutely zero back-feed to the grid. Any large consumption on the inverter output that suddenly stops, produces an instantaneous noticeable back-feed, that can last for a few seconds, which is not accepted by certain operators. Anyway, that’s another issue completely.
I will try to disable the flow and try it out, the next time I will be local at the installation. Thanx for the heads-up, somehow I didn’t think of it.
Correct, when larger loads go off than there always is a bit of dancing around the zero line before it settles. But does that not happen with your flow?
No, this doesn’t happen with my flow, because I’ve set it up so as the grid set-point rises depending on the real consumption and its jitter during the last 3 minutes. So, when there’s a high consumption, set point is set high as a percentage of consumption; when there’s high jitter (consumption coming and going), set point is being set even higher. That way, there’s virtually and ACTUALLY zero back-feed.
But, as already said, that’s not the topic of my original question.
While trying to further debug the issue I am having, where I cannot connect to the Node-red interface or its Dashboard when the system is working parallel to the grid, I thought I’d enable shh access to the Cerbo, in order to check for high CPU/memory usage in those cases.
However, finding it really hard to setup a remote ssh connection. I went as far as enabling superuser and remote support, which gives me an IP and port, remote support tunnel shows up as “online”, however ssh still times out from my side.
