SmartThings Edge Developer Beta | Known Issues and Bug Tracking

This is a list of currently know limitations, issues, and bugs related to the Edge Drivers platform:

Installing Drivers

  • There’s an auth problem with in the live logging system. If you see a 403 error when running the logcat CLI command, change the “Location Mode” (Home/Away/Night by default) of the location your hub is in, this will force a resync of the same message to the hub containing your account’s auth verification information.

Device Automation

  • Driver-based devices do not work with Groovy SmartApps, including SmartLighting. Drivers do support Rules as automatons in the App or via the API, or Endpoint Apps.

Device Discovery

  • When a device is discovered it does not pop up in the app as having been discovered. For now watch your driver logs and back out of the discovery pages in the app, your new device will appear in the “No room assigned” section at the bottom of the app. Edit: Fixed in android, fixed in next iOS release. Fixed in both apps now.
  • There is no individual device discovery. Driver based devices can only be discovered using the “Scan Nearby” option in the app. Zigbee and Z-Wave devices can be discovered without LAN devices being discovered by selecting a Zigbee or Z-Wave device from the catalog as this starts a network wide scan for those devices.

Network Sockets

  • “send” type operations currently will block all driver threads. Operations include tcp.send, tcp.connect, and udp.send. tcp.connect is the only one you likely need to be careful with. Both send calls will allow buffering in the kernel, so unless you’re sending very large amounts of data, those should happen instantly. However, tcp.connect will block until the connection succeeds or times out. To ensure this isn’t a problem we reccomend performing discovery immediately before connecting to have the best possible chance of connecting quickly.
  • Sockets must be manually closed. Sockets are not getting properly closed when a socket handle is garbage collected. This can lead to your driver being unable to create new sockets after too many have been created.
  • Calls to tcp.bind or udp.setsockname may only specify port 0 to be assigned a port randomly, unless you are binding to a multicast IP address and have already set the reuseaddr socket option to true. This is to prevent unexpected collisions between drivers trying to bind to the same port. We’re looking into ways to allow binding to stable port numbers in a way that prevents conflicts, but don’t have solid plans yet. If you have a hard need this, let us know.

Device Model

  • Virtual devices do not yet exist. Temporary workaround: create a LAN device with no LAN permissions.

Programming Model

  • Coroutines can not be used from within user code as the cosock runtime would interfere with your resuming and yielding. I would like to fix this, but don’t have a timeline for when this will happen. Leave a reply if this is important to you.


  • There is a current bug with Custom Capability definitions being synced for locally running devices. To work around this, after the first device has joined using a edge driver using a custom capabilities, you will have to reboot your hub. Once this has been done, the driver should function as expected with those custom capabilities.



  • When calling require "socket.http" you’ll see a warning this non-standard location, socket.ltn12, has been depricated, please require as the standard top-level module ltn12. This is an error in the http library, you can safely ignore this warning. It has been fixed and will be released with hub firmware 0.39.X.

Can Zigbee 3.0 and z-wave plus devices be added? aka does QR code scanning work in the app for Edge drivers?


Yes. QR code scanning works.


Could that be clarified? Clearly there is some functionality as I have a motion sensor working with ActionTiles displaying and updating motion and battery states.

I found a bug in illuminanceMeasurement

When we don’t specify handler for illuminanceMearurement, it uses the default handler code in the /st/zigbee/defaults/illuminanceMeasurement_defaults.lua
But it throws error message as below.

thread encountered error: [string "st.zigbee.defaults.illuminanceMeasurement_def..."]:33: attempt to call a nil value (field 'pow')

I searched the web for this error message, and I found out that math.pow() is no longer available in Lua 5.3. Instead, we should use ^ operand.

So the source code should be changed into

function illuminance_measurement_defaults.illuminance_attr_handler(driver, device, value, zb_rx)
  local lux_value = math.floor(10 ^ ((value.value - 1) / 10000))
  device:emit_event_for_endpoint(zb_rx.address_header.src_endpoint.value, capabilities.illuminanceMeasurement.illuminance(lux_value))

I had to define the handler explicitly, like above, for illiminanceMeasurement to make it run without error.


Thank you for sharing this @iquix. :smiley: I already shared it with the engineering team, I’ll let you know how it goes.

driver crashes and does not restore after some time

2021-09-01T09:55:07.985404861+00:00 FATAL Zigbee Motion Sensor  Lua: runtime error: [string "cosock"]:241: [string "socket"]:64: attempt to call a nil value (field 'warning')
stack traceback:
	[string "socket"]:64: in local 'cb'
	[string "st.driver"]:741: in function <[string "st.driver"]:700>
stack traceback:
	[C]: in function 'error'
	[string "cosock"]:241: in field 'run'
	[string "st.driver"]:749: in method 'run'
	[string "init.lua"]:43: in main chunk

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.

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


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.

1 Like

@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