SmartThings Edge Developer Beta | Known Issues and Bug Tracking

Yes. QR code scanning works.

4 Likes

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))
end

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

2 Likes

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.
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.