[Enhancement] Device Name in output (and/or in context variable timers)

[joinke]

I seem to have noticed that device names are not stored in context but in the main flow json .
The timers context is only containing output as an index to the device name array.

Is there any way to have the device names also stored in context, so we can make use of them at initialisation , independent of the scheduler node configuration ? (In other words, we can then input device names and schedules independent of what is in the node config)

timers | array[4]0: objectstarttime: 1615404600000days: array[7]**output: "0**"endtime: 1615404900000

Thanks,

[joinke]

Hi , I forgot to say thanks for the excellent node !
In addition to above, what it basically means is that 1 output for devices could be enough (as the msg.topic can already provide necessary means to separate flows0 , and the input msg could be used to override the config in the node.

[fellinga]

Hi joinke,

thanks for your suggestion - I need a a little more information though.
First of all, yes device names are currently only stored in the device configuration and not anywhere else.

Is there any way to have the device names also stored in context, so we can make use of them at initialization , independent of the scheduler node configuration ?

If the device names are (additionally?) stored in context, how exactly would you make use of it?

(In other words, we can then input device names and schedules independent of what is in the node config)

You can already send new schedules to the node through a msg.payload just like you would inject new schedules after a reboot. What would be your use case to change a device name? I mean you can't rewire the output of a device so the device probably won't change anyway (without the rewiring).

And speaking of outputs... yes - from todays perspective one output would be enough (sending a msg topic was an addition just a little while ago) but some people see it as very useful to just connect the device to the correct output without having to deal with topics (changing that would also break existing installations). If you would prefer one output you can just combine all the outputs to a switch node for example.

[joinke]

Hi Fellinga,

Thanks for the elaborate answer. Well understood and agree, and my initial comments were not entirely structured ;-)
My use case is the following :

• If am not mistaken, the current implementation of this excellent node, requires you to go into the NR editor ,i.e. in the configuration of the time scheduler node to add/delete/modify a device, and that's what I want to avoid end-users having to do.
• Admitting that I've already made an attempt to modify your code, I'm reading the following payload from file :
  {"devices":[{name:Valve1,description:VA1},{name:Valve2,description:VA2}],"timers":[.....]}
• With this I'm in control to add/remove/change devices external to the Node RED Editor, e.g. from a UI dashboard. Main change is to add , in addition to your getTimers() method, a getDevices(). It's a working configuration , but of course I'm ignoring completely the device list in the configuration of the node in this case.

P.S. Using this node to controle an irrigation system, where solenoid valves (=devices) are "often" added. Trying to avoid end-users having to use the node-red editor. Devices are stored in a mysql db and as such, ideally, would be fed into the time-scheduler node.

Many thanks for your answers provided. Much appreciated. I am not expecting any action , just your opinion.

[fellinga]

Thanks for the explanation, sounds like a very nice project!
I suppose you also changed the configuration so that the node statically only has 1 output and you only distinguish by msg.topic, right?

The implementation would not be a big problem but I can't see a solution that is backwards compatible:

• Having a dynamic number of devices means a dynamic number of outputs and this can not be done without re-deploying the flow/node (additionally these outputs would not have any wires attached).
• Changing the nodes implementation so that all devices send their signal via the same output (with msg.topic enabled) would definitely be bad for existing users.

Any ideas?

[joinke]

Valid comments.

• What about a general option in node configuration to use either NR Editor as Device Manager or a specific input payload object?

That option could be used to show/hide devices in the configuration of the node and as a parameter in the code.
I'm probably missing something, but would it not achieve 100% backwards compatibility ?
And yes, you would go for changing the node implementation so that IF you chose to use specific input payload, you would not use 'config.devices' but a value from getting device list in payload .

[xjustbmw]

Is there a version yet available with one single output and the msg.topic option to show the item #number of output?
I have quite a large number of items (80) to control and it woud be nice to have the output redirected to each one of them through a function with one wire. Instead of... 80 :)

[xjustbmw]

Regarding backwards compatibility would be an additional output (at the end), this way nothing really breaks for current users.

[xjustbmw]

i added msg.id to the output to be able to identify it in a function after, seems to work