I have some flows that use Victron input nodes like Custom Input, Battery Monitor, Dynamic ESS and System. I normally set the Only changes property to only trigger the next node when there is a change in value. Since VenusOS v3.60, the initial trigger after a re-deploy doesn’t work anymore, which is a problem when the value doesn’t change often such as for instance AC-Input to check whether the grid is available. The label below the box only shows connected instead of the value. It still worked in v3.55, but not anymore in v3.60 and v3.62.
Curious, if you try the new beta (built on nodered v4) is it the same?
You can easily roll back via the backup firmware option on the GX.
I upgraded to v3.70~5 but unfortunately, this did not fix the issue. So perhaps it is an issue with the Victron nodes instead of node-red?
However, it did fix another issue I had: Since v3.60, the dbus-fronius log file would fill up with warning No functional TLS backend was found messages. That is no longer the case.
Thanks. I have mentioned it to the team responsible.
1 Like
As a workaround you can uncheck the ‘only changes’ box and use a filter node set to ‘block unless value changes’ right after the input node to ‘dedup’ the 5msg/s datastream.
1 Like
Deffo a bug. It will be fixed in due course.
@dick this is fixed in 3.70~7 beta
It is indeed fixed, but I now have a couple of new issues.
- I get a new login prompt when I access the gui-v2 for the first time via the local network. I read in another post that you could login with a space as password, and indeed, that worked.
- A node-red Custom Control node for
com.victronenergy.settings/Settings/DynamicEss/SystemEfficiencyreports:Not connected to dbus. Publish was unsuccessful. - A node-red VRM API node for
Get DESS configurationVRMreportsError fetching VRM data. - On a node-red deployment, I get a message about an unused Victron Energy Client node. What is that?
4.. check ‘Configuration nodes’ for unused nodes.
Hi @dick , this was fixed in v3.64; official release.
Thanks again for the report!
Your issues 1 to 4 are mostly fixed in newer beta versions I’d think.
If you still have any such issues, then please report in the Venus OS beta category - thanks!
Firmware 3.64 testing using Node-Red : INITIAL VALUE ON CERBO RESTART
Test 1
Product: Cerbo GX MK2
Firmware version: v3.54
Node-RED Program: Node Red 20 seconds for tests
AC IN interrupted :
After 25s: MP shut down (thanks to Node-Red function)
After 600s: Cerbo shut down (thanks to delayed relay timer)
When AC IN returns:
Cerbo restarts
75s later: MP restarts (thanks to Initial Value set in Node-Red function, as soon as Cerbo starts up)
→ GOOD
Test 2
Product: Cerbo GX MK2 (same SN)
Firmware version: v3.64
Same Node-RED Program: Node Red 20 seconds for tests
AC IN interrupted :
After 25s: MP shut down (thanks to Node-Red function)
After 600s: Cerbo shut down (thanks to delayed relay timer)
When AC IN returns:
Cerbo restarts
75s later: MP does not restart!
→ Not GOOD
The new firmware version causes a malfunction in Node-RED:
The initial value is not sent to the device after re-powering the Cerbo GX.
The Multi eventually started after 795 seconds (i.e., more than 13 minutes later)
There is a known issue that the first message might get lost in Node-RED, see also this bug report.
Victron is remotely checking stuff on my install so I’m expecting more feedback somewhere this week.
1 Like
@mpvader I did some tests with V3.65 : I have the same issue as with V3.64.
I had to downgrade to V3.54 to solve this problem
Hi @Arthur , thanks for the report. Noted.
We’ll look into it
Hi @Arthur. We’ve tried, but so far haven’t been able to reproduce this on our test setup.
Mind moving further discussion to Victron Input Nodes with *only changes* do not trigger on re-deploy · Issue #279 · victronenergy/node-red-contrib-victron · GitHub , to see if we can get this reproduced consistently and fixed? If you are still suffering from that on 3.65, that is. If not, please also let us know.