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.
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:
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.
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
@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!
I have seen the cosock error once myself as well. It just happened completely randomly about a week ago from a driver that had been running happily prior to that. I reinstalled the driver, it’s back to working normally. I haven’t seen it again.
I want to report an issue I have seen off and on ever since the alpha-level code: every couple weeks I will get into a situation where all my Edge drivers are receiving duplicate capability commands from the ST cloud (for example if you press a button in the mobile app to perform an action or an automation triggers a device command). I have confirmed it is not a problem with my drivers: I can literally see duplicate commands being received in the the log separated by not much more than 100 milliseconds. It seems there is a bug somewhere between Edge and the cloud that is causing this condition. Only a hub reboot will fix it.
Can anyone provide us a status on the problems with Settings? There are a number of them, as has been reported, but the biggest offender is where the info_changed lifecycle is being generated multiple times as a result of only one field change. I’ve noticed in those multiple calls that it seems to swap the old and new values back and forth each time. In other words, if I change a settings value from a to b, the first lifecycle call will properly have old=a / new =b, but then another one is received only about 50 milliseconds later with old=b / new=a, then another one back to old=a / new=b, and so on up to a random number of times. This wreaks havoc on the driver as you can imagine, so this really needs to be fixed SOONER rather than later; otherwise driver development and testing becomes nearly impossible to do.
Please, if anyone can comment, is there an outlook for this to be fixed?
any mistake in the lifecycle handlers lead to the driver being available in the list but does not produce any logging
lifecycle_handlers = {
init = misspelled_function,
},
expected behaviour - error message to be printed in the log, preferably every time driver installed
Hello, everyone!!
I just wanted to thank you all for the great effort you’ve spent among Edge Drivers development and for the disposition you’ve had while detailing issues experienced so far.
Also, I wanted to let you know that our engineers are constantly looking into the resolution of these issues and, in this context, I’d like to share with you all a few tips that will help us get things on the right track faster and accurately:
Whenever you find an issue that is whether or not beyond your driver’s code you can do the following:
Additionally to the issues that y’all already shared, we wanted to let you know that we’ve found some others that might result annoying while developing and deploying your Edge Drivers, hence we encourage you to keep in mind the following points:
Without further news, thank you for taking the time to read and for contributing with your feedback.
Keep the great work!
As long as groovy exists there is no problem, but to be thinking about the future, it would be necessary to have a generic edge driver, for example for zigbee devices, that can be installed and uninstalled from the official channel and can be used to discover devices that do not exist and we know the fingerprint, manufacturer and model.
As with the DTH, it discovers them as “Thing” and then you can add your fingerprint to a DTH and modify it later.
This is definitely going to be a thing in one form or another at some point. When we get to the point where things can no longer fingerprint to DTHs there will have to be a fallback that can do nothing but offer a ‘switch driver’ flow. Though, we don’t have a solid plan on what exactly that will be. (Empty driver, something intrinsic to the platform above the level of a driver, something in between?)
@psbarrett Maybe is time to add Tool for Edge Drivers, comparable to IDE, where non Devs can look at Edge devices’ data, and be able to report issues.
Many devs don’t have every device that they are creating drivers for, and have to reach back to users when issues are found.
@nayelyz,
How is this problem going?
There has been an update to the Android app and it remains the same.
It would be important to solve this problem of the app, the hub’s controllers page to be able to see all the content of the page by scrolling.
When you have a few drivers installed, you no longer have access to channels and can install and uninstall.
You have to use the CLI and there are users who do not use it.
Also channels need to be first, or maybe on drop down list like on Automations page. Select channel first, then driver.
Thanks Eric - Regarding your 2 points under Found Issues:
Yes, although our team keeps reviewing the best option to improve the time it takes to apply the latest driver version. For now, the max 12 hours rule keeps being the standard.
The engineering team is still working on the fix, I’ll let you know as soon as I get more info.
