Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

node config information when set with msg.output #8

Open
animalkingdoms opened this issue Oct 22, 2023 · 4 comments
Open

node config information when set with msg.output #8

animalkingdoms opened this issue Oct 22, 2023 · 4 comments

Comments

@animalkingdoms
Copy link

Is there a way to get the config of the node when it has been customised using msg.output

In my use case I am adjusting the weights and the active status of 6 outputs on the router, but have no way to confirm at any time the config of the node. I am storing my status in a flow variable as a workaround but would love to see this information / extract it form the router node directly

@animalkingdoms
Copy link
Author

Just providing a suggestion on how this could be done.
Refer to node-red-contrib-queue-gate
"The status command can be used in conjunction with a Status node to obtain the current state of the gate or the number of messages in the queue. This is shown in the Basic Operation flow. (Thanks to Colin Law for suggesting and implementing these commands.)"

This could be implimented into the router by sending a specific control message and having a status node provide an object of each output its its configuration state

@bartbutenaers
Copy link
Owner

Hi @animalkingdoms,

I have never used the Status node myself. For the node-red-contrib-queue-gate node that indeed sounds a logical way to do it, since the status information for that node is fairly short.

But not sure how I should implement that into my node. I have N outputs, which each have multiple properties (weight, ...). So that is quite a bunch of information, which I cannot simply show in the status of the node.

The status of a node is plain text, and not an object (see documentation).

Can't we solve your problem another way? Currently this node allows (see readme) to change the settings of a specified output, by injecting a message containing an msg.output field. For example ´msg.output: 5´. Suppose this msg.property can contain two other values:

  • *: the settings are applied to all outputs
  • ?: the settings of all outputs are send as an output message (on a new extra second output)

Bart

@animalkingdoms
Copy link
Author

animalkingdoms commented Oct 24, 2023

I see some possible options from what you have said.

  1. include the settings in the msg that passes through the output under something like msg.routerSettings
    This would be good, but not ideal if I want to check what the current settings are of a single, multiple or all outputs. I walso dont want to have a msg enter the upstream of this node just to get status information

  2. a dedicated config/status output on the router node.
    This status output on the router node may get confused with a regular output, but this would be a suitable option to get all configs of the outputs in the router, without it entering the rest of the fessage flow.

  3. Utilizing the Status node payload.
    Like in q-gate a control status message is sent which gets picked up by the Status Node. The status node sends a payload with all status information - a similar output to option 2, but handled seperate from the router node.

If the payload from the status was a text dump from the router node that would be OK, but i would format it like the below - preferably by the node, but can be done by formatting the payload that comes out of the status node with a function or parsser of some sort

{
    "output1": {
        "state": "true",
        "clone": "false",
        "weight": 1,
        "delay": 0
    },
    "output2": {
        "state": "true",
        "clone": "false",
        "weight": 5,
        "delay": 0
    },
    "output3": {
        "state": "true",
        "clone": "false",
        "weight": 7,
        "delay": 0
    },
    "output4": {
        "state": "true",
        "clone": "false",
        "weight": 10,
        "delay": 0
    }
}

Cheers!

Here is Q-Gate flow with a status control message, with a status node connected to a debug

[ { "id": "5ccfbec460d89e92", "type": "q-gate", "z": "d22fb9beaeb9e818", "name": "Q-Gate 6", "controlTopic": "control", "defaultState": "closed", "openCmd": "open", "closeCmd": "close", "toggleCmd": "toggle", "queueCmd": "queue", "defaultCmd": "default", "triggerCmd": "trigger", "flushCmd": "flush", "resetCmd": "reset", "peekCmd": "peek", "dropCmd": "drop", "statusCmd": "status", "maxQueueLength": "99", "keepNewest": false, "qToggle": false, "persist": false, "storeName": "default", "x": 1623, "y": 1242, "wires": [ [ "e7ab4bb2ad618243" ] ], "l": false }, { "id": "8e6aa5d3b6790e13", "type": "inject", "z": "d22fb9beaeb9e818", "name": "", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "control", "payload": "status", "payloadType": "str", "x": 1496, "y": 1242, "wires": [ [ "5ccfbec460d89e92" ] ] }, { "id": "e7ab4bb2ad618243", "type": "debug", "z": "d22fb9beaeb9e818", "name": "debug 314", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 1762, "y": 1242, "wires": [] }, { "id": "c72ebfdd183ca5be", "type": "status", "z": "d22fb9beaeb9e818", "name": "", "scope": null, "x": 1524, "y": 1134, "wires": [ [ "327474a2f1a9869d" ] ] }, { "id": "327474a2f1a9869d", "type": "debug", "z": "d22fb9beaeb9e818", "name": "debug 315", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 1712, "y": 1134, "wires": [] } ]

Its output on the debug is under msg.status
{"status":{"fill":"red","shape":"ring","text":"closed","source":{"id":"5ccfbec460d89e92","type":"q-gate","name":"Q-Gate 6"}},"_msgid":"66bb16018a40c2e3"}

The status node can be set to only give status of specific nodes for clean use if the user has multiple nodes

@bartbutenaers
Copy link
Owner

bartbutenaers commented Oct 25, 2023

Thanks for the detailed information!

Option 1 - include the settings in the msg that passes through

Like you already said: that way we are are polluting all the messages that are passed through (with duplicate information), and you cannot simple ask the current setting.

Option 3 - Utilizing the Status node payload.

Yes but your example shows what I tried to explain above.

  • The status of a node in Node-RED is a small text with a maximum length of 20 characters.
  • The Q-gate node status ("open", "closed", "queueing", "queue full") is such a simple text, so you can intercept that with a Status node like in your example: ,"text":"closed". All the other information you see there (source, and so on) is added by Node-RED behind the scenes).
  • But now you want me to send me the following array as status:
    [{
       "output1": {
         "state": "true",
         "clone": "false",
         "weight": 1,
         "delay": 0
       },
     ...
    }]
    
    Which will of course never work, because this is not a short text...

Option 2 - a dedicated config/status output on the router node.

Indeed that might be confusing since you have already N outputs, where N is not fixed.

So I don't know a good solution. Option 2 seems to be the least bad solution...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants