MQTT 503 c8y_LogFileRequest not working?

I m currently working on a device agent using MQTT and want to handle the c8y_LogFileRequest.C8y v 1015.0.278
I have done the step by step approach as explained in topic here

It works as expected except for setting the Operation to Successful:

  • My operation is set to executing correctly using publish("s/us","501,c8y_LogFileRequest")

  • My event is successfully created using a SmartRest template so I receive the event ID back

  • The binary is correctly attached to the event

  • The url of the binary is correct and return the content of the file
  • When I m using publish("s/us","503,c8y_LogFileRequest,"), my operation is remaining in the Executing state.

Can you please advice on what i m missing?
thank you

503 updates the oldest operation of the specified fragment type in status EXECUTING. If you have other older operations still present from earlier testing they will be updated first instead. Could this be the case for you?

it s not the case unfortunately.
As you can see on my screenshot, all my ops were either in success or failed (success when i update via REST API).
I tried again to execute an operation and as you can see it still remains in executing state, event still I sent the 503.
Also to double ensure there was not pending operation i run GET {{url}}/devicecontrol/operations?status=PENDING&deviceId=956200 before sending my LogFileRequest, and there is definitely no operation pending.

In the screen you’ve posted the Operation is still PENDING not EXECUTING.

Beside that everything looks fine so far. Might sound silly but happened even more then once for me: Are you sure you’re updating the correct device in the correct tenant? It took me sometimes 30 minutes just to figure out I used the wrong tenant ID in my credentials and was wondering why my device wasn’t updated as expected…

Do you receive anything on “s/e”?

Indeed it s still pending which means the 501 cmd is not working neither.
I am definitely updating the correct device since we can see the event being generated with attached binaries on that device.
I am also printing my device id in that cmd and it s pointing to the correct one.

PS: no error msg

Should I file a bug for this version of C8Y?

I tried it with GitHub - SoftwareAG/cumulocity-devicemanagement-agent: Cumulocity Reference Agent written in Python to demonstrate most of the Device Management Capabilities of Cumulocity IoT and could not reproduce it.
All logs are displayed correctly as expected.

Did you test on 1015.0.278 ?
See attached my python, it s using a smartResttemplate to get the event id back so we can attach the log file to that event.
My event has definitely the correct log file attached to it but my operations remains in pending.
DeviceLogRequest(1).json.txt (1.2 KB) (2.8 KB)

DM-Agent is working fine on Will check your implementation.

1 Like

Calling template 501 in c8y prod 10.15 sets the operation to executing, no problem.

Then 503,c8y_LogFileRequest, sets it to ‘Successful’ and I see the green tick in the UI.

It would be nice to see your agent log.

For the device you are trying this for - what is the external id in the Identity tab?

Hi Robert

type c8y_Serial
External ID 123456789UAIAAVDSG

My aggent log is a per below (please note it says operation set to successful because i m sending the 503)

Agent Start
Received operation 522,123456789UAIAAVDSG,Power,2023-04-23T10:46:00+0100,2023-04-24T10:46:00+0100,1000
Received operation c8y_LogFileRequest of type Power
Executing c8y_LogFileRequest
Creating event c8y_Logfile
Received operation 413,1403638,Power
Event ID 1403638
Attaching Power log file…
Operation Successfull

Looking at the operation on your tenant it has ‘LogfileRequest’ i.e. lower case ‘f’.

You are trying to update an operation of type ‘LogFileRequest’ - upper case ‘F’.

Is your REST call that creates the operation creating the incorrect type?

1 Like

omg that was it! you have a lynx-eyed, I would never have seen it ! thank you

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.