This is a list of currently know limitations, issues, and bugs related to the Edge Drivers platform:
- There’s an auth problem with in the live logging system. If you see a 403 error when running the
logcatCLI 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.
- 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.
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.
- “send” type operations currently will block all driver threads. Operations include
tcp.connectis the only one you likely need to be careful with.
sendcalls will allow buffering in the kernel, so unless you’re sending very large amounts of data, those should happen instantly.
However,This has been fixed for
tcp.connectwill 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.
tcp.connectin hub firmware 0.39. It hasn’t been fixed for
sendhowever, 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
udp.setsocknamemay only specify port 0 to be assigned a port randomly, unless you are binding to a multicast IP address and have already set the
reuseaddrsocket 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.
- Virtual devices do not yet exist. Temporary workaround: create a LAN device with no LAN permissions.
- 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 callingFixed in hub firmware 0.39.X.
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.