since I'm new to this Forum: Hi, my name is Jöran and I'm using NR mainly for added functionality of my KNX setup but also to integrate other somewhat smart devices like Fritz, Sonos, ...
Here's the stronghold I try to conquer: I have a subflow that acts as a proxy to forward incoming KNX messages and outgoing ones.
For some messages that should be available after injection at the input of the subflow an output should be generated. Background: Scenes triggered on KNX are not provided back to the KnxIn within the subflow and non-KNX devices will not take notice within other flows.
Therefore, the node function_KnxInternalForward should provide this information to the output which is not working if I have multiple instances of my subflow. Here's a MWE:
In the second row the KnxOut subflow is not sending any message to the debug node.
I would like to ask for a solution / approach that allows me to trigger the subflow from any Flow in my project allowing that any other instance of this subflow forwards my desired messages that are not provided again on KNX.
No idea? The question might also be put in another way: Is there an implementation to get a notification of a trigger without having a link between the the triggering and the listening node?
I assume this is a general question since you can't have all your nodes on one flow that are function-wise connected.
As node-red does not keep a state, this will need to be handled by the user.
There are link/in/out/call nodes available that can connect over flows/tabs without immediately showing the connections (only when the node is selected).
With link nodes (link visible as the node was selected):
Another way is to use MQTT. publish to mqtt and the subscriber receives the message when something has changed.
Note that a subflow is used for instanciation - multiple subflows with their own variables.
The KNX example - i assume - only should exist as a single instance in all flows.
I've tried the link-in and link-out concept. As described in their respective documentation an use of them is not possible if they're within subflows.
For this example the KNX subflow is instanciated multiple times as the respective KnxIn and KnxOut nodes would be otherwise as well.
This leaves me with the opportunity to use the link-in/-out before the KnxProxy which is fine as of now since there aren't that many usages of messages that aren't returned via a status from Knx. I'll also have a look at the MQTT option later. Thanks once again
Why shouldn’t they? Honestly, I think the concept of these KNX nodes is designed in that manner also having a config node in the background. I didn’t read the manual for a long time but used it that way. Otherwise a Link Out node would/should be a “mandatory” part of the concept.
It may partly be that people (like me) don't use KNX, and so therefore don't really understand the use case.
From your flow it appears that sometimes the subflow returns immediately (InternalForward) and sometimes it returns 'later' (Transmitter/Receiver). I'm therefore guessing that KnxIn responds to all received KNX messages. Meaning if you have two instances of the subflow, the KnxIn will fire on each. Obviously then the output node will not know where to return control.
I assume there's also something on the KnxIn message that you can use to pair to the KnxOut request. Therefore, you could potentially replace the subflow and substitute with MQTT, where the message topic was that 'something'. I'm guessing that you're using node-red-contrib-knx - its documentation doesn't show what is received with the KnxIn, but let's assume it has "srcphy" and "dstgad" and the following message can be sent and received.
You would have a flow with an mqtt-in responding to the 'set' message to create the payload and send to KNX. Then the KnxIn would construct a topic for the mqtt-out node. If you really want to keep the joined nodes like the KnxInOut, you could put this in a subflow. Does that help?
thx for the example with MQTT and the other inputs - being on a short vacation I thought over it a bit more and would assume that the following approach should be worth mentioning (quickly sketched via Apple Freeform):
