I’m having some trouble changing drivers through the API Browser. Added an Aeotec Wallmote Quad today, which was included insecurely via the ST app, default driver is the SmartThings Z-Wave Button driver. Then went to change the driver through the ST app, only to see the driver [Aeotec WallMote (Advanced Options)] that I installed on my hub is not shown on option menu for the Wallmote. So I uninstalled CommanderQ’s driver from my hub and reinstalled it - but still isn’t shown on the ‘Select different driver’ menu. Pfft, OK, whatever.
So I then tried using the API Browser to change the Wallmote’s driver but after selecting CommanderQ’s driver from the list and clicking ‘Change’, I’m met with a “Driver change failed with HTTP error 400” message.
Why am I not able to change this driver? And further, why isn’t the driver I installed shown as an alternative option for the Wallmote?
Does the driver show up in the app for that device when trying to change drivers vs using the API Browser?
No, still isn’t listed as alternate driver for the Wallmote. Also double checked the ST app to see if the Aeotec WallMote (Advanced Options) driver is shown and it’s there.
I don’t think it will show up in the API Browser as an alternative if it doesn’t show up in the app. That likely means the fingerprints for the driver don’t include the fingerprints for your device(s). You probably need to contact Aeotec or Commander Q to get clarification.
Already did my homework before installing the alternate driver: the Wallmote Quad is listed among the compatible devices.
Not sure what you meant, but it’s shown on the drop-down menu list of installed drivers.
The API Browser doesn’t know which drivers are applicable to which devices and lists all drivers installed on your hub. The ST app knows which drivers have fingerprints that will match your device so you should check in the app to see what drivers it thinks will work with your device. Here is an example for my Schlage lock:
ST App Changing Driver
API Browser Changing Driver
The ST mobile app thinks the alternate driver that will work with the Wallmote is ‘Z-Wave Switch’ - which is obviously wrong.
What is the fingerprint for your device? And if that driver doesn’t find have that fingerprint, it could be matching based on Z-Wave command classes in the driver fingerprint file.
If the ST app doesn’t think the Wallmote driver matches, the API that changes the driver will give an error (which is what the API Browser is showing). The ST CLI is showing a similar output like the app when trying to change the driver for my lock. It only presents drivers it considers matching to prevent using a driver that might not be compatible.
bep@debian10:~$ st edge:drivers:switch
? Select a device. 39
──────────────────────────────────────────────────────────────────
# Name Driver Id
──────────────────────────────────────────────────────────────────
1 Z-Wave Associator 038a9312-66c8-4a30-9299-b346d57f28a9
2 Z-Wave Device Config Mc 7ca45ba9-7cfe-4547-b752-fe41a0efb848
3 Z-Wave Explorer 2575f638-2ebb-429c-91a2-9bff827396a0
4 Z-Wave Lock 0f206d13-508e-4342-9cbb-937e02489141
──────────────────────────────────────────────────────────────────
? Choose a driver to use.
I’m not sure but I think there may be a fingerprint issue with CommanderQ’s driver and the ZW130-A model, US variant Wallmote - even though the device’s model number is shown on Aeotec’s compatibility webpage. I’ve switched to the Aeotec Group driver; need the extra options to disable sound, vibration, and LED touch interactions. Thanks for the help, Bruce.
Swap out some text for buttons and an alternative ST app would appear
Just saying and great work Tod
Just ran into an issue with the browser.
Under Device details, is there a reason some Z-Wave devices do not show a Network ID while most do?
I don’t know why. It it blank or does it say “unassigned” ?
I’d compare what the API Browser says with what the ST CLI says to see if there is a difference.
I’d imagine this is the same issue as:
i.e. the DNI isn’t exposed for the DTH in the API.
Figured it out in a separate thread, for some reason my IDE graph was cleared at login, I am still able to now access the network IDs for DTHs.
Sorry about the false alarm!
Hi. Tod
I’ve not paid much attention to the Mfg Name or Mfg Code fields visible in the Details panel for Devices.
I just noticed that it seems to be listing the Mfg Name as SmartThings for all devices still using a DTH. And it’s listing SmartThingsCommunity for all that are on Edge even if the driver is from SmartThings.
In some cases the Mfg Code is a name, in others it’s a hex string. Are you doing a lookup for the Mfg Code or is that built into the API?
Is the Mfg Name supposed to represent the driver manufacturer and the Mfg Code the device manufacturer?
I don’t do any secondary lookups for those fields - what you are seeing is whatever the API is returning.
Others may know better, but I’m not sure that Mfg Code is even really used anymore. I don’t see where you can set it for any of the modern schemas (i.e. it’s not in the Developer Workspace nor documented for Edge device profiles). Mfg Name (sometimes also referenced as 'mnmn" seems to be the standard now.
TL;DR - Yes, sort of.
The ‘Mfg Code’ seems to be taken from the deviceManufacturerCode which works with the deviceModel in the fingerprinting. I think they may be SmartThings inventions that draw on similar information at the protocol level. For Zigbee they might be something like SONOFF and S26R2ZB. I don’t have any Z-Wave devices to inspect but I would image they use the numbers that appear in fingerprints.
The ‘Mfg Name’ seems to be taken from the manufacturerName, which is also seen as mnmn (Mah Na Mah Na). For whatever reason, vid and mnmn seem to live on in Edge drivers rather than their supposed replacements presentationId and manufacturerName.
The mnmn, which represents a registered organisation/brand and sometimes is the same four hex digits as the mnid, seems to be a relic of the earlier days of the ‘new platform’ and the scary Developer Workplace, before ST techies took their heads out of their hands and stopped crying and started trying to make it less … well weird basically. The Manufacturer Name and its friend the Vendor ID, which was basically a product code, were used to uniquely identify the UI Manifest. As these started appearing in DTHs they had a dalliance with being known as the Visualization Identifier and the Presentation Resource before everyone seemed to give up saying anything but Vid and the latter became the Device Presentation which was still 100-200kb of gibberish before becoming the meaningful blend of Device Config and Capability Presentations it is now.
UPDATE NOTICE
The API Browser+ has been updated with a new option under the Automations menu for viewing Lighting Automations, which were previously unavailable.
Thanks again to @orangebucket for making me aware of the source.
Note for those curious, this data is actually not coming from the published SmartThings API, but rather an alternate endpoint. As such this is subject to change without notice!
Simply refresh your browser to get the update.
Wowsers. All my interests and curiosities piqued when I saw this. Wish I’d seen this earlier. Pretty please may I have access to poke around.
Have token, will play 