In addition to outstanding reboot and naming I have noticed that the state of virtual switch listed in “Devices” does not follow the actual state when on.
Ho do you control the Truma? in Nodered dashboard? or. I have it in homeassitant. I really would like it in implemented it in the Venus gui as a new page (using old gui)… but I ran out of experience… /Mattias
If you control your heating already in HA, than you can replicate the same automation logic in NodeRed to control the heating witrh the virtual switches and the MQTT nodes
Hello! In case of a restart of the Gx device, the name and position (latching) of the virtual switch are not maintained. They return to default. This bug was also present in previous beta firmware versions.
Hello all, and thank you again for the feedback.
All is sorted now with regards to the virtual switch - feedback & confirmation welcome!
Virtual switch name and state persists on reboot now.
The switch state in devices still shows off when the switch is on.
I have 3 virtual switches as a test. The custom output names and groups do not survive a reboot.
Also I’ve noticed that virtual devices in the device list do not pick up a node name change. On reboot, temperature devices and switch devices revert to the creation name from node name.
Addition: For use in node red, it would be very helpful to have the ability to disable a switch from a custom control node or MQTT.
I have 3 virtual switches as a test. The custom output names and groups do not survive a reboot.
Also I’ve noticed that virtual devices in the device list do not pick up a node name change. On reboot, temperature devices and switch devices revert to the creation name from node name.
That should all start working from 3.60~76. Mind sharing your vrm dashboard id (the number in the vrm url) and enabling remote support, so I can take a look where it is going wrong?
Addition: For use in node red, it would be very helpful to have the ability to disable a switch from a custom control node or MQTT.
I can add the ShowUIControl option to the switch, which will allow for controlling if the button is visible in gui-v2 or not. Or do you have another type of disabling control in mind?
Enabled, 744292, thanks for looking. Apologies for the messy flow, it’s new to me.
Disable the ability for a user to change the switch state (gray out) would be my preference but I don’t see an example of that in the UI library. Expanding the range of SwitchableOutput/Status choices would be a good 2nd option.
The ability to show a node red dash on cards, like where the switches live, would open up a world of possibilities. Signal level I/O control is what I’m playing with. The ability to over-ride automation with manual user control is where I’m at now.
Spoke too soon in my post above. If a virtual switch is on then the Cerbo is rebooted, on start up it now stays on.
However, if the virtual switch is off then on reboot it turns on.
The persistence is not yet fully solved.
@dfaber
Modified switch names do not survive a reboot (version 3.60~76)
The persistence is a bit of a delicate thing to get right. Not wanting to get too technical, but it is probably good to give some background info. The last known state is flushed to the underlying flash every 30 seconds, which is the Node-RED default interval and set so in order not to wear out the used underlying flash too much. If the device gets rebooted before that flushing occurred, the state and other things that got changed might end up in the previous state.
On @MiPaul 's system, I do see that the persistent data does get written (everything gets stored under /data/home/nodered/.node-red/context).
And afaik there is no API call on Node-RED to force a flush. So probably need to add this disclaimer to the persistence first and then figure out a way to force updates.
Considering the remark of @DutchSolarFreak : Yes, that seems to be a bug indeed. I not storing that Name yet (only the group names) and will add that.
1 Like
I lose these settings on reboot. Individual output name and group. I haven’t tested type. Is that considered persistent data?
Type should be persistent Type is always taken from the configuration of the node.
But having enough reports right now to realize that the persistency isn’t always functioning as intended. Still got some work to do in order to get this stable.
1 Like
Thanks for that.
Also, is there an official wish list of features that we can add to?
Dirk-Jan,
After your description of the 30 second flush of states, I turned the virtual switch off, waited a while, then rebooted and it has stayed off this time. Last time I rebooted quite quickly after turning the switch off.
Also, is there an official wish list of features that we can add to?
You can add feature requests here: GitHub · Where software is built
But that is only limited to what is possible on the node-red-contrib-victron side.
Thank you. I was referring to the Venus GUI. I see quite a few requests for features, but haven’t found an official wish list.
There is no official wish list, post a topic with “feature request” in the title in Venus OS beta thread, it will be seen, but not necessarily acted upon.
VRM ID 765666
It’s a pure test system (RPI) without any equipment connected. Feel free to change anything.
I updated from 3.60-7x to 3.60-80 and do not find a way to create a virtual switch in node-red.
My previuosly defined switches were broken after the update.
Last time I created a virtual swtich, I got a “wizzard” to create swtiches and PWMs.
I connaot find this.
- blue “Switch Control” node → There are no switch services available. Please check that a switch is connected or try a different node.
- blue “Swtich” node → There are no switch services available. Please check that a switch is connected or try a different node.
- yellow “Custom Control” node → “Custom” = “Virtual Swtich” → only “/Mgmt” and “Product…” but no switch
BTW: I noticed Virtual Devices that have been deleted, remain in selectable items until reboot.