Edge Drivers Spontaneously Restart

Developer Programs Writing Edge Drivers
1

I wanted to report something I have observed with Edge LAN drivers to (1) see if other developers have seen the same thing, (2) make this phenomenon known to the general Edge driver user community, and (3) ensure the SmartThings team (@nayelyz) is aware.

The problem is that Edge LAN drivers can spontaneously restart for no apparent reason. Logs show no errors, just a spontaneous driver restart at a seemingly random point of execution. It can happen once or twice a day or less.

I know this is happening because I have long running logs to file along with other notification methods when a driver is (re)starting.

Hopefully the driver would restart and resume normally, and the user is none the wiser. However, because there are also known glitches with driver installs (a separate problem I’ve reported before where the driver may not restart after a reinstall), it is possible that these spontaneous restarts could result in a non-functioning driver.

2

By “restart”, do you mean that the init lifecycle is executed periodically?
Or, do you see in the logs that everything is loading again? I mean when we see all the elements of the driver are displayed (similar to when the device is discovered)

3

I mean full driver restart; typically begins like:

Setup driver xxxxx with lifecycle handlers: DeviceLifecycleDispatcher: xxxxx
  default_handlers:
    driverSwitched:
    added:
    init:
    removed:
    infoChanged:
    doConfigure:
    deleted:
  child_dispatchers:
Setup driver xxxx with Capability handlers: CapabilityCommandDispatcher: xxxxx
  default_handlers:
    xxxxxx ....
  child_dispatchers:
<Begin driver start log messages> (e.g. "Starting xxxx driver version n")
Received event with handler environment_info
Found DeviceLifecycleDispatcher handler in xxxxx
<INIT handler stuff starts>
4

Has it been long since the last time this happened?
Please, we need your help by sending the Hub logs through the IDE to see if there’s more information there:

  1. In the IDE, enter “my hubs”
  2. Enter the corresponding Hub and go to “view utilities”
  3. Click on “send” below "send hub logs

Just remind me which account you’re using and if you have more than one Hub, please share the corresponding ID, eg. D052A83xxxxxxxxx (over DM)

5

How long are the hub logs kept? I think it’s been about 23 hours since I last saw it happen.

If we need something more recent, I’ll keep an eye out and send the info when it happens again.

6

It depends on how many devices you have installed (+devices >> - logs storage time) but, it’s better a recent log about the issue. So, please, let me know when you send them :smiley:

1 Like
7

@nayelyz,
I don’t know if it has to do with this problem of restarting the drivers, but today when installing with the CLI a new version of a driver that had new custom capabilities and a new VID and it has been restarted 3 times in succession in the installation, what happened next:

  • At the beginning of the installation, the installation process has been carried out 3 times in a row.

  • I have seen that the variables saved in permanent memory have been deleted (offset from local time to UTC) as if I had changed the driver or uninstalled it.

  • Analyzing the logs I have seen that in the first installation instead of arriving an InfoChanged lifecycle, a Removed has arrived. Device have uninstalled and then started with init, added, driverSwitched… But driver have installed the same device ID, it have not created a different one.

  • 1 sec later the infochanged lifecycle has arrived and the process has started again and/or it has performed 3 times in a row.

I have the log in a file.

  • I have made a small change in the driver and I have repackaged and installed it. It has been installed perfectly, like the previous times.
  • The lifecycle infoChanged has arrived and then it has been installed, without losing any information.

I also have the log in a file

8

We cannot know if they are related for sure, for that, we need to check the Hub’s logs so, please send them:

  1. In the IDE, enter “my hubs”
  2. Enter the corresponding Hub and go to “view utilities”
  3. Click on “send” below "send hub logs

Also, please share with us the files you mentioned, you can send them to us via email (build@smartthings.com). Include the email account you use for ST and the Hub’s name if you have more than one.

9

I already sent the hub logs and CLI logs.
I put it here because it is a LAN driver, virtual Calendar

I have reinstalled the previous version and I have reinstalled the new version again and in both cases it has been installed fine, only once and without loss of saved information.

10

Hello, @TAustin, @Mariano_Colmenarejo
Have you seen this error again?
If you do, could you please send the driver’s logs (logcat command) and the Hub logs (through the IDE), please?

The team has been analyzing the information provided so far and there are no details that can help them find the root cause.

11

I think it continues to occur, but I’ll start monitoring more closely and try to catch the next one.

1 Like
12

Hi @nayelyz

I have not seen it again, but I have not installed or reinstalled a driver for more than 15 days and without use the CLI

13

Are you using sockets in a loop/timed manner? Wondering if you’re running into this

14

I just sent a hub log for a restart that occurred a short while ago. I sent a note to support@smartthings.com that also included the CLI log showing when it happened.

1 Like
15

This is pretty interesting. If there is a memory leak with creating sockets, then this could indeed be the cause of the problem in my driver where I’m continuously polling device through http. This driver seems to have the most predictable problem of spontaneous restarts for me.

16

@nayelyz I wanted to report that since the firmware update, I have not seen this happening again. Whereas before it was happening pretty much daily with one of my drivers, I don’t see it happening any more. I do suspect it was related to the socket-related memory leak that was fixed.

4 Likes
17

Thank you for the info, @TAustin! I’ll share this comment with the team.

1 Like