Edge driver to Associate Eaton Dimmer Switch RF9642 does not show up for my device

I downloaded the “Z-Wave Device Config Mc driver” (see path below) so that I can associate my Eaton RF9642 Accessory Dimmer to my RF9640 Master Dimmer.

(EDGE Driver-Mc): Z-Wave Device Config Mc - Devices & Integrations / Community Created Device Types - SmartThings Community

The driver shows up in the ST app for the master dimmer, but not the accessory dimmer. Using the smarthings.com API (see path below) I see the Execution location of both switches says “Cloud”. The Type says “placeholder” for the RF9640 and “secure dimmer” for the RF9642 accessory dimmer. I believe this means my master switch is in the cloud, but my accessory dimmer is running local (I’ve read that the execution location is not always reliable).

Device List (smartthings.com)

How do I get the driver to show up on my RF9642? I was told I have to set up the association on the accessory dimmer (with master being the target) so I believe I need to access the driver from the RF9642 (not the RF9640 master)

Thanks

tagging @Mariano_Colmenarejo

The IDE is being discontinued and the information in it (for the most part) is unreliable. You should check the API Browser+ which pulls data directly from the ST APIs and provides a lot of the same information that used to be in the IDE.

Also, from what you describe, the master dimmer is using an Edge driver, so you are able to switch to other compatible Edge drivers. The accessory dimmer sounds like it is still running a DTH and you can’t change from a DTH to an Edge driver. The device needs to be excluded and re-added so that it picks up an Edge driver. If you have a custom DTH installed for that device, you need to delete the custom DTH after you’ve excluded it from your hub.

1 Like

Ignore the IDE. It’s part of the old architecture and information there will be unreliable, inaccurate, or out of date in many cases. You should only use it if there’s something that cannot be done with the current new architecture tools. Otherwise, again, more confusion.

See the following if you find a reference to something in a thread dated prior to November 2022 and you’re not sure how to do it now.

Life after the IDE: Questions and Answers

Also, just a terminologies point: you are trying to associate the master with the accessory. Not “to.” no one will care about this except zwave engineers, but it can help reduce the confusion of which is the trigger and which is the target. :sunglasses:

1 Like

As far as why the driver is not showing up as a choice but it does show up as a choice for another device, there are two possibilities:

One) the device is still using a custom DTH so it didn’t even look at the driver.

Two) the fingerprint for the device is not in that driver. That shouldn’t apply to the Z wave configurator driver, though, as it uses a generic match.

See the following post from the community edge FAQ, and make sure you have followed all of the steps.

FAQ: I have no idea what Edge is. Is that a new developer tool? (2022) - #3 by JDRoberts

1 Like

Interesting. I have never installed any Custom DTH, but just to be safe I excluded the Z-Wave device and added it back to the network. I then used the ST Device Viewer (see path below) to check the Type and it shows up as “DTH”.

ST Device Info Viewer (lrmulli.github.io)

So it looks like both of my RF9642 dimmers are defaulting as DTH upon adding them to the network. The same thing is happening to all of my Eaton Outlets RFTR9605 and my Eaton switches RF9601, but the Eaton Master Dimmers RF9640 are OK and all show up as Z-wave

Dimmer Switch

Is there a way to fix this issue? If not, will it auto-correct after SmartThings fully transitions to from DTH to Edge?

And now for the novice question…Assuming I am able to solve the problem above, how do I actually access the configuration driver to associate the master with :slightly_smiling_face: the accessory? Do I map the Edge driver to the device first and then access the configuration tool via some sort of web-based GUI? Amazingly I have searched the forum for the last hour and can’t seem to find clear instructions on this step, but I’m sure it is there somewhere…

are you using “Scan for nearby devices”?

There is always the option to remove any DTHs that are being used. Note - once removed they are gone for good… no way to add them back.

1 Like

The author of an Edge Driver has the option to let the “device details“ page in the smartthings app display fields for the parameters stored in the device’s firmware, and in many cases to update those values.

That’s what’s going to happen here. Once you have assigned the configurator driver to a device, you go to that device in the smartthings app, open its details page, and then you will see fields that you can enter for the different parameter values.

For further questions of this type, ask in the author thread for the specific custom edge driver and someone there will help you. They can also show you a screenshot of what the page will look like. :sunglasses:

Can you post a full screenshot of the information for the device that isn’t choosing an edge driver? . In particular, we need to see the “fingerprint” which is the manufacture and model

Occasionally, a zwave device joins, but fails the security test when it does so, and then its fingerprint gets set to zeros. DTHs didn’t care about that, but edge drivers do, so that would be a third reason it might fail to find an edge driver. The solution for that one is to exclude the device, and re-add it, hopefully more successfully. :thinking:

Hi - I added using the Scan QR code. Are you saying that I should exclude the device again and try to add it back via the “Scan for nearby devices” instead of using the “Scan for QR Code” option? This will allow me to remove the DTH driver from the RF9642 prior to adding it to the network, so that when it gets added it will utilize Edge drivers instead of DTH?

BTW, I just wanted to mention that I’m sorry this is so annoyingly complicated right now.

Part of it is because we are in between two architectures.

Part of it is because smartthings has always put its own unique architectural overlay over the top of the independent third-party standards like Z wave and Zigbee.

Although they’ve never said so officially, it appears that they thought that their mass-market consumer audience would be confused if they had to know anything about the different protocols being used. They wanted everything to look just the same.

But that means there’s this whole layer unique to smartthings and it’s not well documented and we don’t get a lot of power user tools to see what’s happening underneath, so we just get into these really complex dance steps where we, as a community of customers, just try to help each other figure out exactly what is going to make this work.

other home automation platforms are generally more restricted in the devices you can add, but can also be much simpler in the way that you add them.

So, if this feels unnecessarily complex and obtuse, just know that you are not alone in that feeling. :man_shrugging:t2:

Can you post a full screenshot of the information for the device that isn’t choosing an edge driver?

I was afraid to post the full snapshot as I thought there may be information that is sensitive and could allow others to access the device. Is that not the case? There were a number of fields that were listed. Are any of these sensitive? I included the ones that look benign to me.

  • device ID: sensitive?

  • name: “Dimmer Switch”,

  • lable: “Back Hallway Light Accessory”,

  • manufacture Name: “SmartThings”,

  • presentationID: "SmartThings-smartthings-Secure_Dimmer

  • deviceManufacturercode: “001A-4441-0502”,

  • locationID: sensitive?

  • roomID: sensitive?

  • deviceTypeID: sensitive?

  • deviceTypeName: “Secure Dimmer”,

  • deviceNetworkType: “ZWAVE”,

  • createTime: “2023-03-26T23:12:46.620Z”,

  • parentDeviceID: sensitive?

  • comletedSetup: true,

  • deviceNetworkType: "“ZWAVE”,

  • deviceTypeId: sensitive?

  • deviceTypeName: “Secure Dimmer”,

  • executingLocally: false,

  • hubId: sensitive?

  • networkSecurityLevel: “ZWAVE_S2_AUTHENTICATED”

  • type: “DTH”

  • restrictionTier: 0,

  • allowed: [ ]

BTW, I just wanted to mention that I’m sorry this is so annoyingly complicated right now

Yes this does seem very complicated given that all I want to do is make my 3-way dimmers work! LOL. That said, this community as you say seems very eager to help so I do find comfort in that. I am also stubborn and refuse to give up, which has proven to be my downfall when it comes to maintaining my sanity :sweat_smile:

1 Like

I also wanted to mention that the only reason to use zwave direct association is if you want to be sure that the accessory can still turn the light on and off even if your hub isn’t working.

If that’s not a concern, you’re OK with people just having to go over to the master to get it to work, then you can forget all about association and just use the regular automations in the smartthings app to tie the two switches together.

Someone else can tell you how to synchronize them, I don’t use that feature myself. But it doesn’t require knowing anything about edge drivers or downloading anything special.

This is the option that people use if they want to have, say, a zwave switch cause a Zigbee bulb on a different circuit to turn on and off. Or a batterypowered thread device actuate a zwave device.

As one of my engineering professors used to say “it will all work fine as long as everything is working fine.“ :wink:

So there is a very simple way to make it all work most of the time, you just have to understand that if the hub failed, the accessory wouldn’t work. your choice.

Ohh. That is very interesting. I did not see any literature about using routines to link the devices. I would be OK with that as a temporary work around so that my wife can stop bugging me that the switch does not work, and she can use it until I figure out this more robust solution. :slightly_smiling_face: I will research that in tandem with the association group solution

Tagging @jkp

None of the information output from the API Browser+ is sensitive.

I’d be curious what the deviceManufacturercode is for the Master dimmer that uses an Edge driver. I’m guessing it’s using the stock Z-Wave Switch driver.

In looking at the fingerprints for the production drivers, this is the only one that is close to the accessory dimmer but there is no specific model:

 - id: "Eaton/0000"
    deviceLabel: Eaton Dimmer Switch
    manufacturerId: 0x001A
    productType: 0x4441
    productId: 0x0000
    deviceProfileName: switch-level

Since there is still a valid DTH and there is no fingerprint match for an Edge driver, it makes sense that it installs with the DTH. Your best bet at this point is to ask @Mariano_Colmenarejo to update his Z-Wave Switch and Childs Mc driver to include your Accessory dimmer. His driver is a clone of the stock ST driver, but he has added other switch and dimmer fingerprints so that it will work with devices not included in the stock driver.

1 Like

There are multiple ways you can “link” device behavior. Since the Accessory switch is using a DTH, no Routine is going to run local to your hub. Only once both devices are using Edge drivers can the Routine(s) run local.

  • Have a Routine that says “If this device turns on then turn on this other device”. The downside is you need two Routines, one for on and one for off.
  • Use the Smartlighting app and create a rule where the “Device to control” has an Action of “Sync with switch” and choose the Master dimmer as the device to sync with.

If you expect the Accessory dimmer to mirror the dim level of the Master, then Smartlighting is really the only way to do it.

Also, you may be able to use Association Groups even with one device using an Edge driver and the other using a DTH. You would want to configure the device ID of the Accessory dimmer in Association Group 2 of the Master dimmer.

1 Like

Hi - The master dimmer that is using the Edge driver has a deviceManufacturercode: “001A-4449-0501”

That’s a great idea. I will reach out to him to see if he can add my device. Thanks!

Interesting. I only see this Eaton fingerprint that is close.

 - id: 001A/4449/0101
    deviceLabel: Eaton Dimmer Switch
    manufacturerId: 0x001A
    productType: 0x4449
    deviceProfileName: switch-level

I’m wondering if it matches just because the productType matches and there is no specific productID.