How to trigger a function in an edge driver from another device?

One concern with the custom capability approach is my understanding from ST that they are not supported in 3rd party integrations… I’m not sure if that impacts all data streams for the 3rd party tool ConstantGraph (which I’m testing as a replacement for my soon to die Grovestreams data logging), not clear why it would. I should probably give it a try and find out.

The current driver doesn’t have any capability handlers.

Glad I have at least two possible approaches with hints now; I’ll report back after a bit more research, hacking and testing.

Capabilities are the way to interact with devices in the new framework. Any data that comes out of the device or commands that go into it have to go through a capability.

You can use a stock capability if you find one that fits your needs. Most of the stock capabilities aren’t supported by 3rd party integrations though. The list of supported ones is usually just the extremely common - switch, contact, motion, etc.

Custom capabilities are supported by some 3rd parties like SharpTools, but most don’t.

So what happens if your device has a capability that a 3rd party doesn’t support? The 3rd party just doesn’t see that capability. It still handles switch, contact, motion, etc the same as it otherwise would.

2 Likes

You could do it with a standard capability, just add a reset button (using either momentary or a switch capability) that does what you need. Then use a scene to press the momentary on each device at the same time. As @philh30 said

1 Like

Got it working nicely with the stock momentary capability and a scene. Next minor cleanup is to change the provided button’s label to something meaningful, which I gather from other posts is possible albeit a bit involved. Thanks again for the pointers.

1 Like

You can’t change the label on a stock capability. This would require a custom capability.

1 Like

A while ago, we could do this using the Device presentation, there’s an example in the post below:

I’m not sure if with the latest changes this still works, could you help us confirm, @georgeh, please?

I’ve give it a shot later this week.

@nayelyz
So I did review that thread (again). The simple approach I have in mind is to:

  1. get the existing device-config presentation for the stock driver
  2. modify the label from that template
  3. create a new presentation and do whatever next is needed for my driver to use it (presumably referencing the presentationID provided as output from the smartthings presentation command.)

For step 1, I’m not sure where to find this. I think the smartthings presentation command can provide the template based on a presentationID, but I could not see where I find the existing presentationID for the stock driver.

The stock drivers don’t contain the VID property because the presentation is generated automatically, do you have a device installed using this driver?
If so, there are two ways of getting the device-config for you to modify it:

  1. With the profileId you can use the command below to generate the device-config based on the profile’s config.
smartthings presentation:device-config:generate profileId -j -o=deviceConfig.json

Note: You can also select the YAML format (-y -o=deviceConfig.yaml)

  1. With the presentationId, you can use the command below to get the original device-config used to create that specific presentation. This is super helpful when working with custom presentations because of the special configuration we can use:
smartthings presentation:device-config presentationId -j -o=deviceConfig.json

First attempt did not seem to work following those steps, the label in the app’s detailed view was unchanged. (Yes, I had a device installed using the driver). I used the first option to get the original device-config. I then modified the detail view and automations view to add the key and value. Note I am not entirely sure the “key” I parameter I used was correct (followed other examples for that).

{
    "dashboard": {
        "states": [
            {
                "component": "main",
                "capability": "powerMeter",
                "version": 1,
                "idx": 0,
                "group": "main",
                "values": [],
                "composite": false
            }
        ],
        "actions": [],
        "basicPlus": []
    },
    "detailView": [
        {
            "component": "main",
            "capability": "momentary",
            "version": 1,
            "values": [
                {
                    "key": "momentary.value",
                    "label":"Apply Settings"
                }
            ],
            "patch": []
        },
        {
            "component": "main",
            "capability": "powerMeter",
            "version": 1,
            "values": [],
            "patch": []
        },
        {
            "component": "main",
            "capability": "energyMeter",
            "version": 1,
            "values": [],
            "patch": []
        },
        {
            "component": "main",
            "capability": "refresh",
            "version": 1,
            "values": [],
            "patch": []
        }
    ],
    "automation": {
        "conditions": [
            {
                "component": "main",
                "capability": "powerMeter",
                "version": 1,
                "values": [],
                "patch": [],
                "exclusion": []
            },
            {
                "component": "main",
                "capability": "energyMeter",
                "version": 1,
                "values": [],
                "patch": [],
                "exclusion": []
            }
        ],
        "actions": [
            {
                "component": "main",
                "capability": "momentary",
                "version": 1,
                "values": [
                    {
                    "key": "momentary.value",
                    "label":"Apply Settings"
                    }
                ],
                "patch": [],
                "exclusion": []
            },
            {
                "component": "main",
                "capability": "energyMeter",
                "version": 1,
                "values": [],
                "patch": [],
                "exclusion": []
            },
            {
                "component": "main",
                "capability": "refresh",
                "version": 1,
                "values": [],
                "patch": [],
                "exclusion": []
            }
        ]
    },
    "type": "profile"
}

Next I ran the “create” command, and used the resulting vid & mnmn in the driver’s profile.yml (below), and repackaged/assigned/installed the new driver, then changed to using it in the app. No errors were seen in the logs during that process, but the value on the screen did not change (still the default “Standby” text for the stock momentary capability).

name: base-electric-meter
components:
- id: main
  capabilities:
  - id: momentary
    version: 1
  - id: powerMeter
    version: 1
  - id: energyMeter
    version: 1
  - id: refresh
    version: 1
  categories:
  - name: CurbPowerMeter
preferences:
  - name: powerReportInterval
    title: Power report interval (seconds)
    description: Time between power (w) reports in seconds
    required: false
    preferenceType: integer
    definition:
      minimum: 1
      maximum: 86400
      default: 300
  - name: energyReportInterval
    title: Energy report interval (seconds)
    description: Time between energy (kwHr) reports in seconds
    required: false
    preferenceType: integer
    definition:
      minimum: 1
      maximum: 86400
      default: 3600
metadata:
  vid: e830f1c4-eb5f-34a4-a38f-6024c6419a22
  mnmn: SmartThingsCommunity

As a check, I tried running the …presentation:generate tool using the same vid that I was provided at time of creation, and it barfed on the attempt. Perhaps that indicates some problem with my device-config.

C:\Users\grhay\SynologyDrive\ST_Driver_WIP\GRH_ST_EdgeDrivers-main\MyDriverWIP>smartthings presentation:device-config:generate e830f1c4-eb5f-34a4-a38f-6024c6419a22
    Error: Request failed with status code 500: {"requestId":"0CAAD803-442C-431E-A332-5DBC275990AC","error":{"code":"UnexpectedError","message":"Error generating device
    configuration","details":[]}}

One odd but unrelated thing I did notice I also want to ask about, but it seems unrelated, is that when I checked my devices to get their ID’s I noticed one of the 3 meters (#5 below) that are using this modified driver shows the “generic-sensor” name, whereas the other two meters (#3&4) using the same driver show “base-electric-meter”. This predates any changes I made for the label stuff, and all 3 devices are behaving similarly and show they are using the same driver in the app query… any ideas on cause or whether I need to fix that (&how)?


───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 #  Label                     Name                                             Type   Device Id
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 1  Family Room Multi-Sensor  motion-battery-temperature-illuminance-humidity  ZWAVE  ce196f6d-098f-45a1-b9cf-21fb329b1543
 2  Front porch multi-sensor  multi-functional-motion                          ZWAVE  9fb8511b-9ee8-42ef-b11a-fdf264c5234b
 3  MR Energy Meter           base-electric-meter                              ZWAVE  5fc34a44-72a1-4234-964a-ea0b8b42c81d
 4  Net (-MR) Energy Meter    base-electric-meter                              ZWAVE  f7ce5f1d-1e0b-44e0-86c5-4d77f7602e01
 5  Solar Energy Meter        generic-sensor                                   ZWAVE  c65654e3-701e-433d-997e-6da9b8b0a194
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

ok, first, sorry, I didn’t notice you were trying to change the label of the momentary capability. This is a special case because it only has one command (push) and no attributes. So, the key momentary.value doesn’t seem effective.
I already asked the team about this. I’ll let you know their comments.

About the devices, there are two properties each of them has, “name” and “label”. For Edge-based devices, the name used corresponds to the device profile’s name. The label should have the text you see in the app.
If you use the -j or -y flags in the command, you’ll see the complete details of all the devices or one by one if you add the device’s ID.

//all
smartthings devices -j
smartthings devices -y

//single device
smartthings devices deviceID -j
smartthings devices deviceID -y

Thank you for the update.

By “name”, did you mean “key” or something different? (Was my choice for the key parameter correct.)

Any comment on my “generic-sensor” name question at the end of my last post?

Sorry, this comment was about your question of the devices name that appears in the CLI:

In this case, knowing the exact format is pending because this capability has only one command. That’s what I asked the team.
But, if it had an attribute called momentary as well, it would be correct.

My confusion, sorry… I grabbed all the device info for the 3 meters using this driver, shown below. What is odd is that the last one (name=generic-sensor) has that name instead of “base-electric-meter”. The latter was the name in my edge driver’s device profile, since that same driver is used by all 3 devices as confirmed by the driverID’s. I did notice that the vids for all 3 are not the custom one I attempted to create, confirming there was some problem in that attempt.

device info (snipped for brevity)…

- deviceId: 5fc34a44-72a1-4234-964a-ea0b8b42c81d
  name: base-electric-meter
  label: MR Energy Meter
  deviceManufacturerCode: 0086-0002-0009
  manufacturerName: SmartThingsCommunity
  deviceModel: 0002-0009
  presentationId: 55d63670-00f1-3c33-94b0-f57023d6f492
[...snip...]
    driverId: 51bbdf78-fdfc-4f84-8e7f-ead931741a5b
[...snip...]
  type: ZWAVE
  vid: 55d63670-00f1-3c33-94b0-f57023d6f492
  mnmn: SmartThingsCommunity
  ocfDeviceType: x.com.st.d.energymeter
  restrictionTier: 0
  allowed: []

- deviceId: f7ce5f1d-1e0b-44e0-86c5-4d77f7602e01
  name: base-electric-meter
  label: Net (-MR) Energy Meter
  deviceManufacturerCode: 0086-0002-001C
  manufacturerName: SmartThingsCommunity
  deviceModel: 0002-001C
  presentationId: 55d63670-00f1-3c33-94b0-f57023d6f492
[...snip...]
    driverId: 51bbdf78-fdfc-4f84-8e7f-ead931741a5b
[...snip...]
  type: ZWAVE
  vid: 55d63670-00f1-3c33-94b0-f57023d6f492
  mnmn: SmartThingsCommunity
  ocfDeviceType: x.com.st.d.energymeter
  restrictionTier: 0
  allowed: []

- deviceId: c65654e3-701e-433d-997e-6da9b8b0a194
  name: generic-sensor
  label: Solar Energy Meter
  deviceManufacturerCode: 0086-0002-0009
  manufacturerName: SmartThingsCommunity
  deviceModel: 0002-0009
  presentationId: 55d63670-00f1-3c33-94b0-f57023d6f492
[...snip...]
    driverId: 51bbdf78-fdfc-4f84-8e7f-ead931741a5b
[...snip...]
  type: ZWAVE
  vid: 55d63670-00f1-3c33-94b0-f57023d6f492
  mnmn: SmartThingsCommunity
  ocfDeviceType: x.com.st.d.energymeter
  restrictionTier: 0
  allowed: []

Check the fingerprints.yml file and look for the device’s fingerprint. There, we specify which profile must be used by the device. For example:

image

In your case, are all devices using the same device profile?
Also, if it’s not taking the new VID assigned, you need to make sure the configuration in the profile is correct (the indentation is also important). For example:

name: temp-humidity-press-illu
components:
- id: main
  capabilities:
  ...
  categories:
  - name: Thermostat 
metadata:
  mnmn: SmartThingsCommunity
  vid: 1b807861-a243-3df4-99fa-f815f562278a

Note: Please consider that even if you assign the VID you created, the label won’t be modified because the reference isn’t correct and the answer from the team is pending.

AFAIK. All devices are using the same driver, with the same device profile. Also, two of the devices
have identical fingerprints – one being the oddball “generic-sensor” and the other having the expected “based-electric-meter” name. Its almost like there’s stale data somewhere. I have updated the devices several times, and its possible that other name was in a much older version of the driver, but not in the currently installed one.

The device name for z-wave/zigbee is the name of the profile the device used when it was first included. It never gets updated, and I haven’t found a way to change it (except through the Groovy IDE, which is a problematic way to do it).

2 Likes

Have you checked the profile’s ID? In the device’s details (response of the API), there’s a property called “profile” (“id” inside), you would know if they’re using the same one.
If you made changes without deleting the driver’s package or reinstalling the device, it makes sense both have different names because of what @philh30 mentioned.

All profileID’s are identical.

@philh30’s explanation must be correct in this case, although I swear I had to reinstall the device (after excluding) to get it to pair with the new edge driver. It doesn’t seem to impact the behavior any, just provides another opportunity for confusion. Hopefully its a reported problem already.

On the label re-attempt, I’ll wait to hear about the correct reference to use.

Thanks for the efforts!

No, it shouldn’t impact the behavior, users don’t see this text in the app either, only the label, which they can change as required.
Just to understand the situation to see if I can replicate it:

  1. You had the profile “generic-sensor”, then changed it to “based-electric-meter”.
    a. If you have a single profile, you cannot change the name and package it again because it would seem you deleted the original one. Instead, you need to delete the package completely (uninstall, unpublish, remove).
    b. If you had another profile called “generic-sensor”, you would be able to package the driver again and that could have cause the mismatch.

  2. From the previous points which one is your case, a or b?