New Stock Edge Drivers Beta list

As I was saying, you can try to see the live logging in the CLI, activating it before pairing device with command “smartthings edge: drivers: logcat” as seen in the tutorial and you will be able to see the response of the device when it is paired:

  • It will send the information of acceptance of the configuration and battery level value, values in red in the capture. Check if it calculates it by percentage or by voltage. In the capture, value= hex C8 = 200/2 = 100%
  • It also sends the RSSI and LQI zigbee signal metrics, values marked in blue. I did not know where this could be seen now and it is seen in the live log every time an event is sent to the hub.
2 Likes

Yes, the IDE doesn’t fully recognize the Devices handled by Edge Drivers, that’s why those fields are empty and execution is set as “CLOUD” but they run locally.
If you query the devices list through the ST API, you’ll see their info, such as network ID, device ID, etc.

@nayelyz I am used to being able to ‘re-pair’ devices that are misbehaving instead of deleting them first. Is this something that should be possible with Edge drivers? Only I had a motion sensor that seemed to be genuinely offline and not responsive so I thought I’d pair it again. End result was the motion sensor clearly thought it was still trying to pair, and the app had silently marked it back online. So I had to delete it and pair it again from scratch.

Zwave siren and zwave range extender have just been added.

1 Like

What on earth is a jenkins?

i’m guessing its how they’re going to automate GitHub pull requests publishing to the website where you install the driver.

Yeah i searched about that as well. Seems kind of an automation software for developers.lets hope this means faster driver additions and upgrades for us.

It won’t affect additions, but definitely faster from the Pull Request being submitted to them being live to install from the website. The new ones just went live on the channel URL which is faster than last week between PR acceptance and able to install.

Well anything that can be done faster the better! I am really waiting for some buttons.

Ecolink firefighter

Switched out from the Custom DTH that I was using for this, and now it cannot be used in the STHM as a Smoke Sensor. In addition the internal Temp monitoring that was available in the old DTH is not available.

Actiontiles recognizes it as well, but only for Battery and Sound.

This was a problem with the standard Ecolink Groovy DTH too (probably why you were using a custom one). For some reason SmartThings standard DTH and Drivers implement it with sound sensor capability instead of Smoke and CO sensor. STHM requires Smoke and CO sensor capability.

1 Like

Indeed, it uses this profile:

The SmokeSensor capability is not included, is this the original DTH you’re referring to?

So, the device has the Smoke Sensor feature but it is not included there or it just uses the events from other capabilities to set the Smoke Sensor value?

If you want, you can take the released driver and change it according to your custom DTH, you can share more details here or a new post and we can help you out.

Nayely, while you are technically correct that the poster can modify the driver for their own use. I’d probably submit a bug on the driver as released.

In its current form It’s useless in STHM - which is also probably the use case 85% + of the users want it for. It should have the smoke / CO capability added and re-released. Where does that need to go?

1 Like

Of course, I will report it but I need to know more about the device, that’s why I requested this information:

This is because if the device has those sensors included but they were omitted since the Groovy DTH was published, the team might need to check other things.

Understood - To answer your question, The Ecolink is a microphone essentially, it’s tuned to listen for the specific tones and patterns used for Smoke and CO alarms. When it ‘hears’ the alarm tone it then alerts accordingly on the ZWave side. It’s primary use case is to relay an audible smoke alarm or CO signal onto a ZWave network. So its understandable it has the sound capabilities - but it needs the Smoke / CO capabilities to actually be functional.

1 Like

Agreed… Both Smoke and CO capabilities are included in the modified DTH and need to be in the new edge device in order to make it usable within STHM.

In addition, the unit has temperature capabilities as well, which, at least for my use case, is necessary.

EDIT: Forgot to answer the question on ‘which’ custom DTH represented the capabilities.

Thanks, everyone. I’ll create a report about this driver. Keep the comments coming, this helps us a lot to enhance the tools and handlers released. :wink:

1 Like

Please check if HEIMAN SmokeSensor-EF-3.0 is comparable with zigbee smoke detector.
I have this one and tried to enroll the device with Edge driver, but failed.
I hope adding finger print wil work for this driver.

And…I registered heiman carbon monoxide detector and aeotec z-wave range extender with edge drivers from you.
Both of them are working good, but icon from ST device is ugly…(default Null icon is applied)
Please update this.

Many Thanks!!

Adding this to the fingerprints.jml file works the same as the other originals.
I have 2 working from the beginning and they go well, except that in the mosaic it shows searching, or without connection but it is not true

    deviceProfileName: smoke-battery
  - id: "HEIMAN/SmokeSensor-EF-3.0"
    deviceLabel: HEIMAN Smoke Detector
    manufacturer: HEIMAN
    model: SmokeSensor-EF-3.0
    deviceProfileName: smoke-battery

Adding this at end of smoke-battery.yml the icon is always displayed correctly

metadata:
  deviceType: SmokeDetector
  ocfDeviceType: x.com.st.d.sensor.smoke
  deviceTypeId: SmokeDetector

Oh this works!! many Thanks~~

1 Like