The NodeRED ibmiot node seems to connect to the MQTT broker using a scalable clientID. This would normally make sense as it allows the creation of multiple instances of the NodeRED application while ensuring that the MQTT broker sends each message to only one instance of the NodeRED app, simplifying scalability.
We have a situation where our NodeRED application maintains a very thick device status that we do not want to constantly persist and try to share between NodeRED application instances. It would be much easier for us to have the ibmiot node connect using the normal Client ID (not the scalable ID) and then have each instance do a hash on the deviceID to determine if it is the instance that is supposed to handle that particular device's message - discarding the message if it is not the correct instance.
I cannot find any information on if this is possible using the default ibmiot node.
Would it be more correct to use the NodeRED mqtt node instead of the ibmiot node? Per the info on that node, "The node will generate a random Client ID if one is not set and the node is configured to use a Clean Session connection. If a Client ID is set, it must be unique to the broker you are connecting to." So it would seem that the Client ID could be left blank, so each instance of the NodeRED application would get a random Client ID. If so, is their a way to have the NodeRED mqtt node read its server and security information from the environment, so DEV/Staging/PROD instances of the NodeRED application do not have different hardcoded values in the NodeRED mqtt node?
Any help would be appreciated.
After several days of digging through code, I posted an answer to this (which I originally posted). The answer was awaiting moderation, but now is gone. The moderation message indicated that if I had concerns I should contact an administrator, but I see no way of doing that nor does 'search' bring up how to do that.
Any guidance on why my answer was discarded?
So I posted the answer again as a comment instead of an answer. The comment was there for a day but now that comment is gone as well.
Can some administrator please give some guidance as to why my answer to this question is being moderated?
Answer by Andrew Roy (1) | May 08 at 02:07 AM
Posting this again as a comment rather than an answer:
There does seem to be a way to do this with the default ibmiot in node. You can do it with the following steps:
1) Create a Standard Application in the IBM Watson IoT Platform
Open the IBM Watson IoT Platform application from the IBM Cloud console.
From the left-hand nav bar select Apps.
Click the "Generate API Key" button.
Enter an appropriate description.
Click the "Next" button.
Copy the displayed API Key and Authentication Token values.
2) In Node-RED configure the ibmiot in node to use the newly created API Key, configuring the connection to not use a Scalable connection.
Open the Node-RED application and navigate to the tab with the ibmiot in node.
Double click the ibmiot in node to configure it.
In the "Authentication" drop down, select API Key. This will cause a new row to appear, API Key, with an edit button to create a configuration for an API Key connection.
Click the edit (pencil) icon on the "API Key" row. This will display a new configuration dialog, "Add new ibmiot config node".
Enter an appropriate name for this connection.
Enter the API Key and Authentication Token that you copied in step 1 above.
Enter the appropriate server name for your IBM Watson IoT instance.
Ensure that the Scalable checkbox is not checked (it is not checked by default for a new config).
Leave the Application ID blank so the code will generate a unique client ID for each instance.
Set keep-alive and Clean Session as appropriate to your needs.
Press the "Add" button.
3) The ibmiot properties dialog will be re-displayed, indicating that the node is configured to use API Key authentication with the API Key config that you created in step 2. Save the changes.
Press the "Done" button.
4) Deploy the modified flow.
Press the "Deploy" button.
At this point, multiple instances of the Node-RED application will now each receive a copy of each inbound message.
Additional Nodes:
1) This does not easily solve the deployment across multiple environments (ex: DEV, QA, PROD). The DEV deployment of the ibmiot node will be configured to use the API Key that you created in the DEV IBM Watson IoT instance. Deploying that Node-RED flow to other environments will cause those other environments to be receiving messages from DEV. This is likely not what you want. Your deployment instructions must include steps to change the ibmiot in API Key config to use the config appropriate to that environment. I will continue to hunt around for something to automate this and report back if I find anything.
2) For reference, the ibmiot node source code can be found here: Git-hub link to node-red-contrib-scx-ibmiotapp. The version in Git-hub is 0.0.49 which matches the version installed in IBM Cloud when you create a Node-RED Starter resource as of 2019-04-30.
How to communicate to beagle bone black using watson iot platform? 1 Answer
How to make a secure connection to IoT MQTT broker in Node Red "mqtt in" node? 1 Answer
How to set up mqtt in BlueMix NodeRed to subscribe to messages sent by my devices? 2 Answers
IBM IoT: Node-RED: MQTT API Client configuration 3 Answers
MQTT connection to Watson device 2 Answers