AVNET's iotconnect.io cloud platform is an online service that you can use to send data to, and then show it on a dashboard*. In this blog series I'm learning how to talk to it with Node-RED. In this post: Messages and commands from the cloud to the Thing.
This is the last post in the series. |
iotconnect.io supports 3 types of messages:
- simple one-way communication from the cloud
- communication with acknowledgement back from the Thing
- firmware updates over the cloud
I'm experimenting with the first two.
Set up the commands
You can only use commands that are defined in the template for the thing. That's good.
I'll set up two simple commands, that send a "desired temperature" to the Thing.
It's up to the thing to decide what to do with it.
My thing logs the info to a debug window 
. The easiest way to learn and share on a blog post.
In the real word, this could be a command for a temperature control thing
Here you can see the two commands. Both request to the thing to "set the desired temperature. One with, the other without confirmation.
.
This is the one without receipt:
It will send and forget.
The Node-RED flow is also simple. Just take the payload out of the IoTConnect connection node.
And this the one with acknowledgement:
This one behaves differently. The Node-RED flow will have to send an acknowledgement back for a full success.
You can monitor missing acknowledgements on IoTConnect the cloud pages.
I have not found an option yet where you can act on missing ACKs.
Node-RED flow that can deal with both types
The data coming out of the Node-RED IoTConnect node, when receiving a command, has an attribute that tells if an ACK is needed.
msg.payload.ack [true|false]
For a complex flow, where you need functional checks before confirming, you'd make a dedicated flow to validate, then ACK.
In my case, I just want to confirm that the message (any message) has been received. So I created a generic flow:
This flow always sends the received data out, as payload.
It also checks the data for the msg.payload.ack attribute.
If false, nothing happens.
If true, the ACK is generated and injected (with the IoTConnect injector) in that same IoTConnect node.
Since the version the Node-RED SDK of May 21, 2021, you need to set 2 attributes in the payload before injecting the ACK:
source: IoTConnect Client Libraries & SDKs (requires an account)
That's then the input to the ACK injector:
Actual Examples
The first one sends a command that does not request an ACK.
The desired temperature is given as 30.
The command is received at the Thing. The Node-RED flow dumps the payload to the debug window, and does not call the ACK flow.
The cloud portal shows success when the message was sent. It does not know if it arrived.
The second test sends a command that requests an ACK.
The desired temperature is given as 25.
The command is received at the Thing. The Node-RED flow dumps the payload to the debug window.
Because the msg.payload.ack == true , it sends and acknowledgement.
In this case, the flow only reports good if the ACK arrived:
The third test deliberately does not send an ACK, to show that this works.
I broke the flow for this. I removed the ACK block. Just to show that you can see in the cloud portal if a message was not correctly handled at the Thing side.
You can see that the portal only knows that the message departed. It will not show success.
That's the point of the ACKs. Getting feedback.
Should you use ACKs all the time?
No. An application that relies on unconfirmed messages (and unreliable connections) is - in the long run - more stable than one that needs an acknowledgement. It's a skill to design processes that can deal with uncertainty, bad connections, no replies. But if you deal with it, your software will be much more resilient to real life. And for a thing that's out there, not in a server room with reliable redundant connectivity, real life will matter.
Try to design flows that can deal with failed messages from both sides. Accept that that will be the reality once you have 11.000 of them out there in the wild. Don't expect return values. Don't expect that a message (either way) went fine. It will make your design stronger.
That said: the ACK mechanism will help you: You can use it in non-real-time (ASYNC). It can be a mechanism to show that a flow failed over a long time. That's useful. |
In several of the other posts in this series, you will see that I use different ACK design.
Always refer back to this blog post for the correct ACK setup.