SmartThings Edge Developer Beta | Known Issues and Bug Tracking

This happened to me when I changed Ecosmart bulbs from Groovy to Edge, and than want to go back to Groovy. As all devices had to be removed prior to driver removal, all Automations also disappeared.
When I removed first bulb, I have also tried to add it back as Groovy, avoiding “Scan Nearby”, by selecting manufacturer, device type, scanned code, however bulb was connected back again with Edge driver. I have tried with other 3 bulbs, and same thing happened.
I had to completely remove Edge driver, and than reinstall as Groovy device.
To keep my other Automations when I am swapping drivers/devices, I have placed Virtual Switches instead of Edge devices, and than I have swapped them later for Groovy devices.

1 Like

I also have groovy virtual devices that I named Placeholder that I temporarily put into automations when I change between Groovy and Edge drivers. That way I don’t lose the automation.

1 Like

One more issue I don’t think has been noted regarding device Settings notification to the driver:

I have seen instances where you press OK on the Settings screen after changing a value, and the driver fails to get notified via info_changed lifecycle. Then if you try changing another preferences field, the driver does get notified with both changes.

1 Like

Problem uninstalling a device from App, that has an edge driver. It disappears in the app and is not properly uninstalled from the driver:

It happened to me yesterday with a light bulb, it was not uninstalled well and the driver was left with the light bulb installed, it was seen activity in the logcat.
The device was no longer appears in app, API and IDE.
I can not remove the driver since it was in use according to the system.
I reset the bulb and the hub, it was still the same.
In the end turning off the hub was solved.

4 posts were split to a new topic: [ST Edge] Persistent Store

Does the issue persist if you reboot your hub? If so, the next time it happens, send Hub logs and raise a ticket at build@smartthings.com including this information:

  • Hub Id
  • Firmware version
  • Timestamp from when you sent the Hub logs.

Note: To send Hub logs go to your Groovy IDE > My Hubs > [Select your Hub] > View Utilities and find the option under the Hub commands section.


I’ll comment it out with the engineers to see if there’s a feasible solution for this.

1 Like

I have a issue

The Edge driver that I’ve been using for almost about a month, suddenly stopped working, so I tried removing the device and pairing the device again, but I got following Error message while pairing.

In the error message, it says “this is a bug, please report it”, so I’m reporting the error here.

2021-09-22T04:07:42.754700397+00:00 TRACE Tuya Window Shade  Setup driver tuya-window-shade with lifecycle handlers:
DeviceLifecycleDispatcher: tuya-window-shade
  default_handlers:
    added:
    doConfigure:
    infoChanged:
    removed:
    driverSwitched:
    init:
  child_dispatchers:

2021-09-22T04:07:42.760208189+00:00 TRACE Tuya Window Shade  Setup driver tuya-window-shade with Capability handlers:
CapabilityCommandDispatcher: tuya-window-shade
  default_handlers:
    switchLevel:
      setLevel
    windowShade:
      close
      open
      pause
    windowShadePreset:
      presetPosition
    refresh:
      refresh
  child_dispatchers:

2021-09-22T04:07:42.763505481+00:00 TRACE Tuya Window Shade  Setup driver tuya-window-shade with Zigbee handlers:
ZigbeeMessageDispatcher: tuya-window-shade
  default_handlers:
    attr:
    global:
    cluster:
      ZclClusterCommandHandler: cluster: 0xEF00, command: 0x01
      ZclClusterCommandHandler: cluster: 0xEF00, command: 0x02
    zdo:
  child_dispatchers:

2021-09-22T04:07:42.791435022+00:00 TRACE Tuya Window Shade  Received event with handler _resync
2021-09-22T04:07:42.794461231+00:00 TRACE Tuya Window Shade  Received event with handler environment_info
2021-09-22T04:07:42.803572439+00:00 TRACE Tuya Window Shade  Found DeviceLifecycleDispatcher handler in tuya-window-shade
2021-09-22T04:07:42.807124606+00:00 TRACE Tuya Window Shade  <ZigbeeDevice: 2c6bcb97-3f4c-462d-a00e-2b76b41ce05f [0x95F5] (Zemismart Curtain Motor)> received unhandled lifecycle event: init
2021-09-22T04:07:42.810021814+00:00 DEBUG Tuya Window Shade  Zemismart Curtain Motor device thread event handled
2021-09-22T04:07:42.813114647+00:00 TRACE Tuya Window Shade  Received event with handler _resync
2021-09-22T04:07:42.816553022+00:00 TRACE Tuya Window Shade  Received event with handler environment_info
2021-09-22T04:07:42.819643106+00:00 DEBUG Tuya Window Shade  Z-Wave hub node ID environment changed.
2021-09-22T04:07:42.823572939+00:00 TRACE Tuya Window Shade  Received event with handler device_lifecycle
2021-09-22T04:07:42.826935856+00:00 INFO Tuya Window Shade  <ZigbeeDevice: 2c6bcb97-3f4c-462d-a00e-2b76b41ce05f [0x95F5] (Zemismart Curtain Motor)> received lifecycle event: added
2021-09-22T04:07:42.830957856+00:00 TRACE Tuya Window Shade  Found DeviceLifecycleDispatcher handler in tuya-window-shade
2021-09-22T04:07:42.835535356+00:00 INFO Tuya Window Shade  <ZigbeeDevice: 2c6bcb97-3f4c-462d-a00e-2b76b41ce05f [0x95F5] (Zemismart Curtain Motor)> emitting event: {"component_id":"main","capability_id":"windowShade","attribute_id":"supp
ortedWindowShadeCommands","state":{"value":["open","close","pause"]}}
2021-09-22T04:07:42.845614439+00:00 INFO Tuya Window Shade  <ZigbeeDevice: 2c6bcb97-3f4c-462d-a00e-2b76b41ce05f [0x95F5] (Zemismart Curtain Motor)> emitting event: {"component_id":"main","capability_id":"windowShade","attribute_id":"wind
owShade","state":{"value":"unknown"}}
2021-09-22T04:07:42.858292189+00:00 INFO Tuya Window Shade  <ZigbeeDevice: 2c6bcb97-3f4c-462d-a00e-2b76b41ce05f [0x95F5] (Zemismart Curtain Motor)> emitting event: {"component_id":"main","capability_id":"switchLevel","attribute_id":"leve
l","state":{"value":50}}
2021-09-22T04:07:42.871914189+00:00 DEBUG Tuya Window Shade  Zemismart Curtain Motor device thread event handled
2021-09-22T04:07:42.875105981+00:00 TRACE Tuya Window Shade  Received event with handler device_lifecycle
2021-09-22T04:07:42.878447397+00:00 INFO Tuya Window Shade  <ZigbeeDevice: 2c6bcb97-3f4c-462d-a00e-2b76b41ce05f [0x95F5] (Zemismart Curtain Motor)> received lifecycle event: doConfigure
2021-09-22T04:07:42.887186064+00:00 TRACE Tuya Window Shade  Found DeviceLifecycleDispatcher handler in tuya-window-shade
2021-09-22T04:07:42.890487522+00:00 DEBUG Tuya Window Shade  Zemismart Curtain Motor device thread event handled
2021-09-22T04:07:42.893901481+00:00 TRACE Tuya Window Shade  Received event with handler _resync
2021-09-22T04:07:42.896745606+00:00 TRACE Tuya Window Shade  Received event with handler _resync
2021-09-22T04:07:42.907177564+00:00 DEBUG Tuya Window Shade  Zemismart Curtain Motor device thread event handled
2021-09-22T04:07:42.911671481+00:00 FATAL Tuya Window Shade  Lua: runtime error: [string "cosock"]:296: cosock tried to call socket.select with no sockets and no timeout. this is a bug, please report it
stack traceback:
        [C]: in function 'error'
        [string "cosock"]:296: in field 'run'
        [string "st.driver"]:721: in method 'run'
        [string "init.lua"]:260: in main chunk

Thank you.

@nayelyz,
The issue that the st-multipurpose sensor status information did not appear on the favorites page has been resolved.
I do not know what you have changed, but now the open status appears correctly in favorites, Show status information

1 Like

@iquix If you’re not able to identify which resource is raising this error, follow these steps to escalate the issue properly:

Note: To maintain the integrity and confidentiality of your data, hide the driver and Hub Ids you shared below the snippet = )

Cheers!

1 Like

I have seen the cosock error once myself as well. It just happened completely randomly about a week ago from a driver that had been running happily prior to that. I reinstalled the driver, it’s back to working normally. I haven’t seen it again.

I want to report an issue I have seen off and on ever since the alpha-level code: every couple weeks I will get into a situation where all my Edge drivers are receiving duplicate capability commands from the ST cloud (for example if you press a button in the mobile app to perform an action or an automation triggers a device command). I have confirmed it is not a problem with my drivers: I can literally see duplicate commands being received in the the log separated by not much more than 100 milliseconds. It seems there is a bug somewhere between Edge and the cloud that is causing this condition. Only a hub reboot will fix it.

@erickv, @nayelyz

Can anyone provide us a status on the problems with Settings? There are a number of them, as has been reported, but the biggest offender is where the info_changed lifecycle is being generated multiple times as a result of only one field change. I’ve noticed in those multiple calls that it seems to swap the old and new values back and forth each time. In other words, if I change a settings value from a to b, the first lifecycle call will properly have old=a / new =b, but then another one is received only about 50 milliseconds later with old=b / new=a, then another one back to old=a / new=b, and so on up to a random number of times. This wreaks havoc on the driver as you can imagine, so this really needs to be fixed SOONER rather than later; otherwise driver development and testing becomes nearly impossible to do.

Please, if anyone can comment, is there an outlook for this to be fixed?

any mistake in the lifecycle handlers lead to the driver being available in the list but does not produce any logging

 lifecycle_handlers = {
    init = misspelled_function,
  },

expected behaviour - error message to be printed in the log, preferably every time driver installed

Hello, everyone!!

I just wanted to thank you all for the great effort you’ve spent among Edge Drivers development and for the disposition you’ve had while detailing issues experienced so far.

Also, I wanted to let you know that our engineers are constantly looking into the resolution of these issues and, in this context, I’d like to share with you all a few tips that will help us get things on the right track faster and accurately:

Reporting Issues:

Whenever you find an issue that is whether or not beyond your driver’s code you can do the following:

  • Push Hub logs (Hub command available at Groovy IDE > My Hubs > [Select your Hub] > View utilities) and open a ticket at build@smartthings.com adding the following information:
    • Hub Id (EUI)
    • Firmware version
    • Timestamp from when you sent the Hub logs
  • If you share logs or code along your community post / ticket, use backticks ( ` ) to enclose it, this will make your information readable, not only for us but for others experiencing the same issue and that are looking to share their information as well.

Found Issues:

Additionally to the issues that y’all already shared, we wanted to let you know that we’ve found some others that might result annoying while developing and deploying your Edge Drivers, hence we encourage you to keep in mind the following points:

  • While debugging profiles (presentation / preferences / components ) try reducing the submission of updates per minute. We’ve noticed that at some point the driver will stop logging and discovery flows may be buggy (in case of Zigbee devices, they’ll behave as joined devices, but the driver won’t create an instance at the platform).
  • If you’re distributing a driver through channels, consider having staged-based channels, i.e. your DEVELOPMENT and private channel, where the debugging driver packages will be submitted, and the PRODUCTION channel which will have the latest and stable driver package.

Without further news, thank you for taking the time to read and for contributing with your feedback.

Keep the great work!

3 Likes

@erickv,

As long as groovy exists there is no problem, but to be thinking about the future, it would be necessary to have a generic edge driver, for example for zigbee devices, that can be installed and uninstalled from the official channel and can be used to discover devices that do not exist and we know the fingerprint, manufacturer and model.
As with the DTH, it discovers them as “Thing” and then you can add your fingerprint to a DTH and modify it later.

1 Like

This is definitely going to be a thing in one form or another at some point. When we get to the point where things can no longer fingerprint to DTHs there will have to be a fallback that can do nothing but offer a ‘switch driver’ flow. Though, we don’t have a solid plan on what exactly that will be. (Empty driver, something intrinsic to the platform above the level of a driver, something in between?)

1 Like

@psbarrett Maybe is time to add Tool for Edge Drivers, comparable to IDE, where non Devs can look at Edge devices’ data, and be able to report issues.
Many devs don’t have every device that they are creating drivers for, and have to reach back to users when issues are found.

3 Likes

@nayelyz,
How is this problem going?

There has been an update to the Android app and it remains the same.

It would be important to solve this problem of the app, the hub’s controllers page to be able to see all the content of the page by scrolling.
When you have a few drivers installed, you no longer have access to channels and can install and uninstall.
You have to use the CLI and there are users who do not use it.

Also channels need to be first, or maybe on drop down list like on Automations page. Select channel first, then driver.

1 Like

Thanks Eric - Regarding your 2 points under Found Issues:

  1. frequent profiles updates: I think I’ve been seeing this one myself, so thanks for pointing it out
  2. I follow your recommendation for dev vs production channels, however it’s still not clear to me how we are to synchronize profile updates and driver code updates. It seems the former get updated realtime, while the driver code is subject to the 12 hour rule. Is versioning supposed to address this eventually?