[ST Edge] - Custom Capabilities Issue

I haven’t managed to get my custom capabilities to work. I keep getting an error from st.capabilities in the command handler definition.

@orangebucket If the suggested implementation from SampleDrivers/custom_capability doesn’t work for you, you can directly use the st.capabilities.build_cap_from_json_string and pass it as follows:

local capabilities = require 'st.capabilities'

local custom_cap = [[
{ ... }
]]

return capabilities.build_cap_from_json_string(custom_cap)

About this:

are you getting any specific log referencing your command handler??

I don’t have a copy of it to hand but basically I had done a:

local customCapability = capabilities[ 'namespace.customCapability' ]

and when I tried to create a device it was pulled up on the first reference to

customCapability.commands.customCommand.NAME

where the command handlers were being defined during driver object creation. The error said something about string( "st.capabilities" ), line 89 and capabilities[ "namespace.customCapability" ] not being defined or something. I was surprised the previous line wasn’t being picked up.

I know there is some issue with custom capabilities that requires a hub reboot or something after first pairing, but my device hasn’t actually got as far as pairing and the hub has been rebooted too.

My (first) test driver is a fusion of Hello World and Custom Capabilities so I reserve the right to have done something dumb (for example, Hello World splits the source across multiple files and Custom Capabilities doesn’t so I may have done something silly scope wise). I still don’t quite have it clear in my head how things are bolting together, including exactly what steps are needed to update a driver in the hub. I probably need to read the library source to see what it is actually doing.

At one stage I realised that I must have been building a package without a profile file as changing the profile file extension from .yaml to .yml triggered some errors. So it could be I did something silly there and never actually corrected the live driver and starting from scratch might help.

How curious! I’ve been able to replicate this in two circumstances:

As soon as I define directly from the capabilities module (i.e. capabilities['namespace.capability']) I get the error.

But if I use capabilities.build_cap_from_json_string, the capability works as expected when its being called from the added lifecycle. It only fails when I execute a command.

Here’s the log, which I believe is the same error you’re receiving:

ERROR demo-230022-vcustom-edge thread encountered error: [string "st.capabilities"]:89: Capability againschool57104.rockPaperScissors version 1 definition not found

I’ll document and share this with the team at once!

1 Like

Ah yes, that looks familar. I got bits of it right.

I get the error in creating the driver object. The actual snippet is …

capability_handlers = {
    [binarySensor.ID] = {
      [binarySensor.commands.binaryactive.NAME]   = commands.binaryactive,

The reported line number is for the last of those lines.

1 Like

I implemented my custom capabilities like shown in the sample and when I install a new version I often get that error when it attempts to emit an event for a custom capability, but waiting about an hour and rebooting the hub solves it.

I shared my drivers with some users and waiting a few hours and rebooting their hubs solved the problem for them too.

1 Like

Sharing drivers i hear? May i join?

I’ve invited you to my Zooz Channel - Beta PM, but I only have drivers for the Zooz ZSE41 and Zooz ZSE42.

@orangebucket @erickv

I will add that I too have experienced the problem as described above with the sample driver/custom capability package. I had converted over the drivers I was working on to the example’s methodology and it was working fine for me for a couple weeks, then all of a sudden it stopped working and I was getting the ‘definition not found’ error. Very frustrating! In an act of desperation I converted back to the ‘old’ style using build_cap_from_json_string, and that’s working ok for me at the moment. Very strange.

@TAustin

Just for reference, can you share the error log, please?

If you are directly constructing the capabilty from JSON, you also need to add it to the capability lookup table. The build command isn’t really intended to be a public interface, and was just used as a workaround before we had the correct definition syncing in place. Unfortunately there was a case that was missed with that syncing which is why a hub reboot is required after a device is joined to get that working. This is obviously a bug and work is ongoing on a fix. In the meantime if you use the build command directly, you also need the line:

local capabilities = require "st.capabilities"

capabilities["namespace.customCapability"] = capabilities.build_cap_from_json_string(custom_cap)

otherwise when the command is received with the ID of your custom capability it is going to try to look it up in the directory.

2 Likes
2021-09-10T17:21:13.156007184+00:00 FATAL Envisalink2  Lua: runtime error: [string "init.lua"]:581: Capability partyvoice23922.dscdashswitch version 1 definition not found
stack traceback:
	[C]: in function 'error'
	[string "st.capabilities"]:98: in metamethod '__index'
	[string "init.lua"]:581: in main chunk

Thanks, @TAustin

I’ve noticed that this error is raised only when the custom capability has been built directly from the st.capabilities module, and as Zach mentions, we just need to reboot the Hub to synchronize it accordingly:


Also, I haven’t seen this error from:

local caps = require 'st.capabilities'

caps['namespace.customCap'] = caps.build_cap_from_json_string(custom_caps.json_definition)
local customCap = caps['namespace.customCap']

and commands are handled properly.

I haven’t experimented with this lately as I am interested in virtual devices and I can’t see a way ahead for them yet. However I remain bemused by talk of rebooting the hub after the device has joined as I found the error prevents the device being joined to start with.