Development device not restarting agent and server.log not outputting

Hi there,

I am a bit new to electric imp development, so I apologize if I sound a bit lost. I have an imp004m configured as a development device that was off for more than 30 days, and thus its agent went offline. As I understand it, when this happens the device will automatically restart the agent when it comes back online, however this particular device’s agent remains offline. I am able to successfully BlinkUp this device, and I can see in the ImpCentral that this device is online as well, but the agent shows as offline.

On this same device, it seems that none of the calls to serial.log() in my device code are actually logging anything, or at the very least, the logs are not showing up on ImpCentral despite the device being connected to WiFi. I have several serial.log() statements in my device code that I have confirmed are not blocked by the agent being offline. There are various hardware events in my system that tell me that the device code is working properly (LEDs turning on, Bluetooth initialization and connectivity all work as expected), but I am confused as to why nothing that is logged with serial.log() is coming through on my end. Again, this is the only device in this development group that is experiencing this issue.

Let me know if there’s any more information I can provide. Any help is greatly appreciated!

How are you determining the agent is offline? Generally, if the agent is hitting runtime errors after being restarted by the device coming back online, it may get held off from restarting - but you should see these errors being reported in impCentral.

Presuming you mean server.log not serial.log? What do you see in the logging area of the IDE when you power up the device?

I can’t help with diagnosing, but if you provide the device ID to @zandr he should be able to check everything looks ok. There are strange corners you can get into if you blessed the device (eg if you made it production) and then blinked up with the owning developer account as I remember.

Thank you for your reply. Would it be possible for the agent to hit runtime errors on one device but not on others that are running the exact same build? This issue is only happening on two imps, while the other imps that are in the same development group running the same code run the agent just fine.

Yes, I am using server.log, not serial.log, my mistake. With this particular device, I only see [Status] messages in the logging area of the IDE. When it powers on, I see “[Status] Device Connected”, and when I make changes to the code and build I see “[Status] Downloading new code; 33.6% program storage used”. The other devices that are not experiencing this agent issue show the server.logs in the IDE as expected with no problem.

This device was never blessed, it has always been a development device. Is there anything that needs to be done for new imps that need to run the agent for the first time? I believe the two devices experiencing this issue had their agent running previously, so if something like that exists it’s probably already been done to them, but I’d be interested in trying it out.

Also, to touch on the first part of your response, I am seeing that the agent is offline in imp central. When I power the device on, I can see the status dot next to “Device” go from red to green, but the dot next to “Agent” remains red. When I go into the IDE, I can see it displays (Offline) in red for the agent at the top of the logging area.

Sounds very much like it should be running, but there are some things you could check first:

  • Device & agent versioning is paired, ie if the device code does not complete its update, the agent code will not update either (to ensure agent & device versions remain in sync)
  • The IDE indicates that new code is being sent to the device, but until you see activity from your new code, you can’t tell that the update was successful. If you keep seeing “downloading” even with no code changes on the device, that’s a sign that the device isn’t successful in getting the new version
  • Try moving the device to a group which just has a simple log statement on both device & agent (so device code is minimally sized) and check both the device & agent code run ok
  • Then move it back and see what happens.

Thank you for your suggestions. I moved the device to a group with just a simple server.log statement in both device and agent code, and the agent remained offline in both this new simple group and the original group that I had it in. I did not see any logs in the simple log-only group after moving it in, despite seeing in the logging area of the IDE that the download of the code began. It looks like the code consisting of a single log in both device and agent used up a reported 0.26% of program storage, so it’s definitely minimally sized.

I see your point that the device might not be receiving the updates successfully, and that very well could be what’s going on, however I’m having a tough time verifying that. For clarity, I should mention that I’m only seeing the “downloading” message when I build a new version of the code or go through a successful blinkup. The device is not repeatedly trying to download new code, it seems to only be doing the download when it’s asked to. Is there some other way that I could verify that the device is receiving its updates successfully, without using any server.logs?

It seems unlikely that device code that small won’t get to the device (unless it has something pathological in the device-side code that is blocking and preventing an update - eg the device connects and sleeps instantly without an imp.onidle() callback for example, though that was improved in more recent versions of the OS).

The only way to tell if an update has “taken” (from the web side) is to see the new code running. If you’re not seeing the log from the new device code then it’s not running. I believe you can likely also see if new code is running by using “impt info” (see GitHub - electricimp/imp-central-impt: impt - the impCentral Command Line Toolkit )

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