Hi all, per just now: v3.70~46. Various small improvements, see detailed change-log above.
Hi,
same it’s happening to my Shelly EM. As I’ve mentioned in this other post:
My shelly is not sending the path expected by dbus-shelly, because it is an old gen. And anyway dbus-shelly is using HTTP API GEN2+ which is not supported by GEN 1 devices, so I guess they will never be natively supported.
Best regards,
Raúl.
Hi, a heads-up for those using the Node-RED victron-vrm-api node: per v3.70~47 (expected to be in beta this week), it will be changed so that backwards compatibility to the version in v3.66 is maintained, and marked as deprecated. And the newly added functionality remains.
Hi, correct! And I see I never added the details on the Shelly support into the change log of this post. Have done that just now. Its gen2 or newer only.
1 Like
UPDATE @mpvader : STILL BROKEN. The structure of the ‘installations stats’ object stored in the global context / returned has changed. For reasons I do not understand, the siteID has been removed from the stored object, requiring adaptation of all our function nodes that make use of that global context object. Even though our adapted flow now works again, I strongly advice Victron to revert to the original object structure to include the siteID again for all other stakeholders using this API endpoint as soon as possible. We will then revert our fix on the broken reinstatement of the legacy API endpoint again.
For illustration pourposes, here the code snippet of what we had to change to make it work for our function nodes (take note that we store the siteID in the flow context):
/*
let vrmsiteid = flow.get(‘siteId’)
let global_get = ‘installations.stats.’ + vrmsiteid.toFixed(0)
*/
let global_get = ‘installations.stats’
And sorry but I have to ask: do you run any regression testing when making these chances? Or are you just wiggling it only to respond re-actively when we beta testers flag issues? I personally do not sign up for that role, uncompensated.
Hi, using the shelly Pro 3EM. The values are ok. now. Still missing the role “Grid” in the Setup. Thanks a lot.
Hi @MotoringMariah ,
Looking into labels for tanks is on the todo list. However, Maretron seems to be using a proprietary PGN for this (130818) while instead they should’ve been using PGN 130060. Also, I don’t know if there are tank sender out there that support the latter.
@dfaber just had new crash and was quick enough to catch the logs. Clearly memory leak effective and not only warning. I have the feeling there is a relation with new deploy off modified flows. Something opening new everytime after the start off the flows and not closing the old one? Mqtt?
Shelly PM Mini devices are still not found with ~46. Other devices, such as 1PM mini and 2PM Pros are found without issues.
Not much I can do pinpoint the cause, based on that log. The ui-event (dashboard 2) is the first one complaining, so I suggest trying to get that number at least below the suggested 10. I’ve never worked with that node, but can’t you use just one and use the output of that?
Other suggestion is disabling one or more tabs to see if that resolves the crashing, so you know the leak is in one or more of the disabled flows.
I don’t think mqtt has anything to do with the crash. What makes you think it does?
UI event is below 10 , normal that it is the first to complain when dashboard is open (triggers flow when opening webpage). It is also native to NodeRed and not new.
Mqtt just a gues because every deploy it stops & restart. Crash happens when many deploys follow in short time. Mqtt is keep-alive every new start a new one kept alive? Just a idea (buikgevoel).
Afaik dashboard-2 was installed separately and isn’t native to Node-RED. (See node-red-dashboard (node) - Node-RED ).
The mqtt node, on the other hand, is a core node ( node-red/packages/node_modules/@node-red/nodes/core/network at master · node-red/node-red · GitHub ). that is shipped with Node-RED. This doesn’t mean that it can’t be mqtt causing this, but I am affiliated with neither of these nodes. So I am afraid there isn’t much I can do for you to solve it. You could ask on the discourse of Node-RED: https://discourse.nodered.org/.
It is not that I don’t want to help, I just don’t see how I can add much more support than I’ve already done.
Is it possible to add engine temperature and controller temperature to the boat page?
If it’s added to the virtual motor drive, it will automatically appear on the boat page.
It’s easy and complete if they’re visible on the page.
Ok I understand and thx for the efforts anyhow.
I’m testing the virtual switches in ~49. The dimmable switch has a little on/off toggle switch at the left. The other two sliders (temperature setpoint and basic slider) haven’t. On the other hand the nodes of all three sliders have the 2nd output showing the on/off state which works only for the dimmable slider. Is that on purpose? Would love to have a little on/off toggle switch available for all three sliders.
Cheers, luphi
1 Like
Agree with the above comment about needing switch state button with the basic slider switch as currently require a toggle and basic slider to achieve the required functionality.
The Node-RED custom control node has no entry for com.victronenergy.system.
How is one to go about writing to com.victronenergy.system/GpsSpeed to feed filtered data to the boat page speed dial?
Care to shed a light on this change @ptrenz ? Any news on accessing the unfilterred USB GPS NMEA datastream without resorting to root hacks?
That seems to be a mistake from my side. Both the temperature slider and the basic slider aren’t supposed to output the state (as they don’t have that).
Please don’t remove the state from the nodes, add the toggle switches to the sliders instead. 
Changing the superuser password seems to log it in clear text. See below.
2025-10-18 14:42:25.628009500 “” cannot convert QVariant(QString, “whatever password I typed in here”) to QMetaType()
With a few more warnings which I don’t think affects any functionality:
2025-10-18 14:45:01.629144500 file:///opt/victronenergy/gui/qml/Multi.qml:11:33: QML VBusItem: Binding loop detected for property “valid”:
2025-10-18 14:45:01.629160500 file:///opt/victronenergy/gui/qml/VBusItem.qml:12:2
2025-10-18 14:45:02.216604500 file:///opt/victronenergy/gui/qml/OverviewTiles.qml:12:34: QML VBusItem: Binding loop detected for property “valid”:
2025-10-18 14:45:02.216619500 file:///opt/victronenergy/gui/qml/VBusItem.qml:12:2
2025-10-18 14:45:02.342738500 file:///opt/victronenergy/gui/qml/OverviewHub.qml:79: TypeError: Cannot read property ‘value’ of undefined