I'm very new to this and I am currently reading lots of learning resources to get up to speed. One thing I have noticed (and which has me slightly concerned about Node-RED's suitability for me) is that all the examples and tutorials I have seen are very hard-coded in terms of the connections between specific devices. For example, a simple lighting example has 'Living room light switch' connected to 'Living room light'.
Is it possible to describe flows in a more generic manner? I.e. I would like a generic flow that describes how a 'light switch' and a 'light' interact, and then I'd like to be able to associate individual light switches with their corresponding light. I might have dozens of instances of this 'switch and light' flow and it would seem rather onerous to hard-code each relation in the flow itself.
If this is possible, can someone please point me at some relevant examples, tutorials or videos?
You can also use environment variables for many of the node configuration properties ${myEnvVar} style... that allows quite a lot of per instance customisation.
A node-red way to do this would be to have one flow that handles all lights and light switches and make it data driven. An incoming event (a switch change event for example) would identify which switch it was and what the event was. Then a lookup table or other mechanism would be used to attach data that identifies the associated light to the message, and this would be passed to your generic flow to take the appropriate action.
It could depend on the method you're using to communicate with your switches and lights, and how you receive and send information.
In my own system I'm aiming to have a large number of "sensors" and controlled devices, and I've chosen MQTT as the comms layer. The MQTT message topics define which device they are to or from, such as "hall/light1" or "kitchen/temperature". If you're using e.g. GPIO nodes, then the message topic will identify which pin the input is from, and other input methods will likely provide some way to identify the source.
The processing flow can, to a large extent, ignore which input and output it's dealing with in each message, and only route to a specific output at the last stage, meaning you could use the same flow for all similar "connections".
edit : which is pretty much what @Colin said above
Could you elaborate a bit on this? Many members of this forum have had success in using NR for home automation or similar control applications. There certainly are areas involving code commonality or re-use where NR could be improved, so if other tools are clearly superior they might suggest ways that those improvements could be made.
The other tool I am investigating, and which seems more suitable for my purpose is ThingsBoard. The key features for me are:
Devices can be associated with a two-tier hierarchy of ātenantsā and ācustomersā.
Devices can have arbitrary type and attributes.
Arbitrary relationships can be defined between devices.
That means that I can, for example, define a building alarm system that comprises devices of type 'alarm sensor' and 'alarm siren'; sensors might have a 'zone' attribute to identify their location. I can then define a generic flow that describes how the building alarm system operates using these device types.
To instantiate a system of this type, all I need to do is register the devices and give them the correct types, associate sensors with sirens and assign the devices to a customer. Not only are the device relations and assignations clearly represented and documented in the UI, but instantiating additional systems does not require touching the core logic. The other responses I've received seem to imply that in Node-RED this would have to be implemented with conditionals in the flow; not only is that difficult to document and maintain, but instantiating a new system risks breaking the functionality for all other users by the introduction of coding errors which, for an exception-based system, may go unnoticed for quite a long time.
This is not to imply that ThingsBoard is superior in all ways -- Node-RED seems to be quite a bit more flexible in terms of the actual flow processing. However for my purpose I need to be able to design and test a robust system, then instantiate instances 'cookie cutter' style, and it seems that ThingsBoard wins in that regard.
Thanks. That helps me understand your thinking. Node-RED operates at a different (lower) level of abstraction than tools like ThingsBoard or many others that you may have considered, such as Home Assistant, Hubitat, SmartThings, and so on. There is no built-in concept of a device with a type, attributes, and relationships. You have to construct all of this yourself, although there is plenty of help to be had online. Most members of this forum are probably in the DIY camp, else they would be spending their time in the discussion group for one of the "higher-level" packages. I don't think this is a question of better or worse -- just a difference that can be very much a matter of taste.
