SmartThings Edge Developer Beta | Known Issues and Bug Tracking

In case you want to update known issues, you may already know:

The smartthings multipurpose edge driver works well on groovy-based smartApps.
Tested with smart lighting, left it open, left it open-multicontacts, simple event logger and door knocker

illuminance sensor Edge Driver in SmartThings Drivers (beta) channel the needs to be patched ASAP, before the library update to the hub firmware.

Since Edge Driver takes priority to dth, one could have difficulty using illuminance sensor with SmartThings,
like the posting in Korean SmartThings Community.
https://m.cafe.naver.com/stsmarthome/41803

I think Illuminance Zigbee packet handler needs to be added explicitly, like I did in my Hue Motion Sensor Edge Driver, until the library update to the hub firmware.

I think the following were already discussed in separate threads, but for completeness, it is probably worth to mention them here:

  1. Zigbee floating point types are not supported
  2. Component’s name can not be changed
  3. Components are not shown in declared order
  4. Child devices are not supported

I think if supporting child devices is not possible, at least we should allow user changing component’s name
Thanks

3 Likes

Here are some more to add to the list: (Android app)

  • The order of the preferences in the profile are ignored. I have no clue what’s determining the order because it doesn’t appear to be name or title.

  • The maximum value integer preferences allow you to enter is 999.

  • The popup for integer preferences allows you to enter values outside of the specified minimum/maximum and no warnings are displayed, but the value won’t actually get saved.

  • Changing a setting sometimes causes the “info_changed” method to get called 10+ times. (I need to double check the documentation to make sure this isn’t be caused by the way I’m handling syncing of the z-wave configuration changes, but I’m pretty sure it’s not my code…)

  • The documentation for emit_component_event shows an example using device.components, but that generates an error. I was able to get it to work using device.profile.components, but I’m not sure it that’s a mistake in the documentation or if it has something to do with using a custom presentation.

2 Likes

@ygerlovin, @krlaframboise

Thank you guys for taking the time to collect and organize your feedback. Some of the points you mention had been already documented and we’ll keep an eye on the remaining ones.

Feel free to patch you list of issues at any time = )

1 Like

A post was split to a new topic: Temperature Scale set for the location

I’m seeing multiple lifecycle calls as well when changing just one field one time. Although for me it’s seems be around 4-5 duplicate calls.

One other observation I have regarding preferences: although ‘default’ is supposed to be optional in the field definition, I have found that if it is omitted, the device, although it seems to get created in the SmartThings mobile app alright, won’t initialize properly (added or init lifecycles are never called). It just seems to get hung. Adding defaults seems to solve the hang issue.

1 Like

The issue of several calls of the infoChanged lifecycle is already reported.
I’ll verify the new one you mention, just as a reference, how many preferences did you configure?

I’ve seen the default issue come up with as few as 4 fields, and as many as 17 most recently.

More a mild irritation than a big deal, but …

I have three hubs. Two are in a Location owned by my everyday account, and one is owned by a different account (just because it can be) and my everyday account is a member of that Location.

The CLI and channel invitations offer me all three hubs to enroll. However if I try to enroll the hub from the Location I don’t own the CLI gives an error and the button in the invitation does nothing.

Ideally I would prefer not to be offered the hubs I can’t actually use. The same would apply for any other operations that I don’t actually have permission to do.

1 Like

Error that sometimes occurs to me when installing a new version of the driver when it has devices already connected:

Let’s see if I explain myself well, is too long.

There are times when you make a change in the driver, package, publish and install it in the hub:

  • The devices that are installed in the driver seem to continue to work, it does not show offline or searching, but it does not work.
  • No activity is seen in the logcat.
  • You think, I have done something wrong with the changes. Undo the changes you have made in the driver code, package, publish and install.
  • There is still no activity in logcat and connected devices are not working.

This is no longer resolved until you uninstall the Driver from Hub and reinstall it. Then it works again.

Problem:

  • If you have several devices connected to this driver, the App or the CLI will not allow you to uninstall the driver from the Hub until all the devices have been removed from the driver. All Preferences, automations, scenes … lost in all devices removed. :dizzy_face:

Solution:

  • If you have another driver compatible with the installed devices in your Hub, you can change the driver on all devices for another driver with the App.
  • Then Remove the driver in the App
  • Reinstall the driver in the Hub with App or with CLI.
  • In devices, with the App, change the driver for the original one and it works. Preferences are not lost, they are stored in the cache, and automations, scenes … since devices keeps its network ID.

If this is happening to me from time to time and I think I have not done anything wrong, it could be the case that when new versions are updated in the official smartthings channels or in channels of other developers or users, they will be automatically installed in the enrolled hubs and in some cases they could leave some users with inoperative devices connected to the updated driver.

Not all users will have compatible drivers installed in their Hub to make the change and will have to uninstall and reinstall their devices.

If the cause of the error is not found, a possible solution would be, which I don’t know if it will be technically possible, that App allow change the device driver, showing a warning, by a generic driver, which shows the device as a thing, but which will keep the preferences in cache and they will not be lost automations and scenes.

Has this error happened to anyone else?

1 Like

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