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. This has been fixed for tcp.connect in hub firmware 0.39. It hasn’t been fixed for send however, in 99.99% of cases you won’t need to every worry about that blocking.
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. FIxed in hub firmware release 0.39,
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.
Capabilities
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.
Libraries
HTTP
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. Fixed in hub firmware 0.39.X.
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.
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))
end
I had to define the handler explicitly, like above, for illiminanceMeasurement to make it run without error.
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. 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.
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.
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
nayelyz
(SmartThings Developer Support)
Split this topic
14
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.
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 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.
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.
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 athing, but which will keep the preferences in cache and they will not be lost automations and scenes.
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.
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.
I already shared it with the engineering team, I’ll let you know how it goes.