Bug: Virtual switch has no value after deploy

[mman]

Describe the bug
Creating a virtual switch of type Numeric Input and Stepped Switch creates the switch, but when displayed in GUI-v2 it does not have an active default value.

To Reproduce
Steps to reproduce the behavior:

1. Using node Virtual Switch with 2 outputs
2. Create Switchable Output of type Stepped Switch and Numeric input
3. Deploy
4. Connect to GUI-v2 and observe that the switches are available but have no value displayed. First interaction with the control then sets the value.

Expected behavior
Both switch types should start with a well defined value. Perhaps in NR you can inject a value on start, but even without injection the switch should behave predictably. Or maybe not?

[dirkjanfaber]

Not entirely sure on this.. The value is defined as persistent, so a set value will be restored on restart of the system. That could potentially conflict with the configured value to inject. That could also lead to some users complaining. So getting this to behave in an expected way that is easy to explain to users is not straight forward.

But I agree that there is some room for improvement. Putting this as a low prio improvement for now.

[mman]

I agree it's not a big deal.

What I got confused about was that for example Stepped Switch, that clearly must have a value did start without any value. And did not paint anything onscreen. In case of stepped switch the UI behaves strange but can represent a state with "no value", as strange as it is...

But for example the slider with a handle can not represent a "no value present" state at all, so I have to fallback to some value... and in the end in the UI that does not reflect reality ...

...so thinking about it some more it all comes down to clearly defining:

1. what is a valid state for each control
2. what is the source of truth

In case of 1. Any dimmable controls (slider, stepped, numeric input) need to have a defined value because without value they violate rule number 1.

For 2. the absolute source of truth is DBus, so creation of the virtual switch on DBus should bring it to the well defined state. It can be done by NR (inject node, or implementation of the virtual switch) and it can also be done on the DBus side, making sure that whatever is emitted from DBus is valid state...

so perhaps this bug better be addressed on the DBUS side?