How should I answer a not implemented MQTT static template with 502 to abort the command?
The Cumulocity IOT can send to the device (e.g. Upload configuration file with type) like:
Normal, I would answer with 502 if it is not correct with the “c8y_UploadConfigFile” like:
502,c8y_UploadConfigFile, not implemented
But how should I answer, when this template is not implemented? So I do not know the “c8y_UploadConfigFile”, I have to answer "502,???, not implemented, but the command in the IOT is still pending, because I have not send c8y_UploadConfigFile
Is there a better way, to abort a not implemented type, I do not want to include all mqtt static template numbers, with the correct c8y_ string, for not implemented features.
Thanks for help, ragards manfred
So usually the UI does only allow to send operations to the device, that the device has previously said it supports using the 114 template (Device integration using MQTT - Cumulocity IoT Guides).
So from my point of view there is actually not really a need to handle “unsupported operations” since they should not have been created at all via the UI, if you didn’t mark the device to support those.
As Tristan wrote our general approach is that the device only adds operations that it can handle into its c8y_SupportedOperations fragment. Then the user interface will only offer the capabilities the device itself offered. This means that users typically don’t create unsupported operations for devices.
Of course there are other means to create operations for devices than the user interface. It is always a good approach to clean up pending operations even if the device doesn’t support them. You can modify the status of operations of unknown type by using the 501 and 502 static templates like this:
The 501 message will update the oldest operation for the device in PENDING status to EXECUTING, and the 502 message will respectively update the oldest operation for the device in EXECUTING status to FAILED. This works because internally these templates internally search for the first operation in the respective status that contains the parameter supplied at position 2 of the message. Usually this is the operation fragment type, but it also works for other parameters. In this case it targets the deviceId parameter which is present in all operations.
If you go forward with this approach it is even more important than usual to execute operations strictly sequentially in order of arrival. Otherwise the device may send an update for an operation that should not have been updated because it is still in progress in another thread.
Hello Philipp Emmel and Tristan Bastian!
Thanks for reply, but why is the Button, “Snapshot vom Gerät abrufen” active, when my 114 string looks like:
In my 114 string, there is no "c8y_UploadConfigFile”, but the button is there!
I tried the
with 520/526 command but for me this does not work when button “Snapshot from Gerät abrufen” is clicked, it only works, when i send:
and add "c8y_UploadConfigFile” to my 114 String.
Do I miss something, what I do not do correct ?
Thanks, regards manfred
The availability of the get configuration from device button and other functionalities and buttons in the configuration tab for devices is not always correct in some currently available versions. In this case the get configuration from device button is displayed always when the device has completed at least one operation to apply a configuration. Of course, this is is not correct and the button availability should be tied to the supported operation. You can expect a future version in 2022 to contain a correction in that regard.
Regarding the 501 and 502 messages:
I just verified this approach manually with multiple operations including ones for configuration and it worked fine with all of them. There are two potential pitfalls where it won’t work as expected though:
- “deviceId” is not a placeholder for the device’s ID. This parameter targets the equally named parameter in the operations data model and must be transmitted exactly as described. The MQTT message must contain “501,deviceId” (case sensitive) and not “501,12345”
- both 501 and 502 messages must be used in together because 501 only moves operations from pending status to executing and 502 only moves from executing status to failed. So the device must always send the 501 first and the 502 second. This can be done in a single MQTT message with 501 in the first line and the 502 in the second line or in separate MQTT messages.
Hello Philipp Emmel!
Thanks for the reply, ok, when in future versions, the wrong available buttons will disappear, is this ok for me, so i do not have to do anything…
Why my 501, 502 commands with the correct device ID do not work, on 520/526 commands, i do not know. But when this buttons will disappear, so the error will disappear…
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.