Preview | SmartThings-managed Edge Device Drivers

A post was merged into an existing topic: [ST Edge] - Local HTTP Requests

@orangebucket, I deleted them a long time ago from the IDE, and they are groovy, not edge

Yes, just like these …

Every single thing there is actually a deleted Groovy DTH. Despite their not being Edge drivers I was still able to delete them one at a time with smartthings edge:drivers:delete but it probably would have been better had I left them in place for diagnostic purposes.

1 Like

Hey Mariano,

Thank you for leaving these in place. I think we have been able to identify the issue and we should have a fix for it out fairly soon. At this point if the extra records are causing you any problems feel free to just delete them like @orangebucket suggested. We shouldn’t need them any longer for diagnostics

2 Likes

Renaming the config.yaml file has worked all right. I had already tried it, but the authentication page did not appear to authorize access to the CLI, it was waiting for an answer. Now if it was opened.

I have installed the modifed zigbee smoke sensor beta driver by adding the fingerprint for the Heiman (HS1SA-E) EF-3.0 model, which is the one currently sold for Europe.

Works well but with these differences with respect to the groovy DTH:

  • In the device tile it does not show the current status, but the icon does change with the current status
  • STHM shows it as offline, but it works fine and generates the response when activated.

The battery information and livelogging are correct.
It is visible and can be used in automations and smartApps such as smart lighting

In case it helps someone, I have modified driver with Visual Studio Code on windows and it has built in terminal, PowerShell, from which you can run the CLI.

First steps with Edge driver fine!
Thanks

Updated:

  • STHM now detects the sensor as connected
  • The smoke detector icon is not displayed on the tile now. The thing icon is displayed.
  • As in IDE it is shown as Type “placeholder” the metrics of the zigbee connection have been lost. I don’t know if they will meet somewhere else in the future.
3 Likes

@nayelyz,

hello,
Regarding the version control of the edge driver, I have the following comments:

  • When I modify the code of a driver, I want to keep the same name and create the package. It creates it with the same name, the same id and the current date as version:
    │ Driver Id │ a2f7ec78-14c8-492d-9965-7544b0fc3b68 │
    │ Name │ Zigbee Smoke Detector Heiman │
    │ Package Key │ zigbee-smoke-detector-heiman │
    Version │ 2021-08-28T11: 18: 25.128977
    └─────────────┴─────────────────────────────────── ───┘
  • When you publish it, it overwrites the previous version, but you cannot see the version (date)
  • When you install driver in the hub, it overwrites the previous one and does not differentiate the version (date), only see version 2, which has not changed from the original.
  • In order for this new version to be installed on the device, it must be uninstalled and re-paired.
  • I cannot use the app tool to use the other driver, since only the latest version is in the hub.
  • The only solution I see is to create another channel for each version and delete de older after installed in device
  • By the way, does this app tool to use another driver work? It gives me an error: make sure your phone is connected to the network. See this thread.
    New Edge Drivers Beta list - #51 by Mariano_Colmenarejo

Thanks

If you originally installed the driver to your hub using the CLI and you package a new version, publish it to your channel, and install it again through the CLI then you should see the new version almost instantly.

You can use the CLI to see the version published to the channel and your hub, but it doesn’t matter if the end user can see it because the new version gets pushed to their hub automatically.

The important detail missing from the documentation is that the new version doesn’t get installed immediately for users that installed the driver using the invitation link.

I’m not sure if this is a recommended approach, but to avoid accidentally breaking things for end users I created a dev channel for myself that I use while working on my drivers.

Once I’m finished testing I publish the driver to my shared channel which ensures that only fully tested versions get installed on their hubs.

The driver ends up being published to 2 channels which might be a problem if you attempt to install it from both or could potentially be one in the future, but my dev hub only uses my dev channel and my other hub only uses my shared channels so I haven’t had any issues yet.

2 Likes

The problem is that to install the new version on the device you have to uninstall and pair again.
They would have to enable a way to update the driver. The one for the app to change the driver does not work for me. Does it work for you?

To make a device use a driver you have to remove it and join it again, but new versions get applied to existing devices automatically as long as you don’t change the device id and you’re publishing the new version to the same channel they used to install the driver.

That can take up to 12 hours, but I’ve had multiple users confirm that their devices were updated without them having to do anything.

That being said, I’ve only written Z-Wave drivers, but it seems unlikely that the process would be different.

3 Likes

I Will try it

12 posts were split to a new topic: [ST Edge] Motion sensor icon not displaying correctly

3 posts were split to a new topic: [ST Edge] Change Driver Tool in the ST App

Awesome write up Kevin. The driver channels were designed not only for sharing drivers but also to give developers an opportunity to test things themselves before pushing changes to a wider audience exactly like you described.

The backend will only allow you to have one version of a driver installed on a hub at a time, but if you ever wanted to switch your hub from the dev channel to your “shared” channel what you can do is just go through the install step in the CLI again (smartthings edge:drivers:install) and specify that you want to install the driver from the “shared” channel. This should automatically update your hub to the version of the driver in the shared channel. Let me know if you ever try that and it doesn’t work for you though.

2 Likes

FWIW, After a week of getting used to using the channel approach to hub installs, I would very much like to see the self-published option continue, so I’m hoping you are successful with your suggestion :grin:

1 Like

8 posts were split to a new topic: [ST Edge] Device Preferences

Will we be able to create simple “virtual” device drivers using Edge, such as a virtual switch, virtual switch/contact sensor, virtual switch/motion sensor, etc?

1 Like

Eventually, yes. Right now they aren’t supported since there is no mechanism to add a virtual device to your location.

1 Like

A post was split to a new topic: [ST Edge] Issue with device history

5 posts were split to a new topic: [ST Edge] - Driver/Device timers

@TAustin @krlaframboise We have added back in some helper params to make using channels less verbose and more like the “self-published” driver flow. You can now specify a channel and hub in the package command so that the driver is “packaged”, “assigned to a channel”, and “installed to a hub” all in one command. The command would look like

smartthings edge:drivers:package --channel <channel-id> --hub <hubId>

You can also use the --assign and --install params and the CLI will prompt you to select a channel and hub. You can see additional examples here

Make sure you pull in the latest CLI version to get these changes.

The “self-published” flow as it was is unlikely to return, but let us know if there is anything we can do to make using channels easier.

6 Likes