SDK Name has a hardcode somewhere in the brain

[tmrobert8]

This took me quite awhile to figure out but there must be some hardcoding somewhere in the brain on the adapter name of the SDK.

Background Correct me if I'm wrong on this - but my understanding is this...

When an SDK registers itself with the brain, a POST occurs to "http://xxx/v1/api/registerSdkDeviceAdapter" with the JSON content:

{"name":"src-cbeaf17d9045bb9ef39011b90b6bcd2f10d1b20c","baseUrl":"http://xxxx:yyyy"}

The name attribute specifies the unique name of the SDK and the baseURL represents the call back URL that the brain will use

When you add devices, etc - the device is added into the brain with an association to the SDK by name that added the device (and the device capability paths are then relative to the associated baseURL).

Issue When I created my own SDK (java based) for openHAB, I registered my adapter with the following:

{"name":"openHAB-{unique UUID}","baseUrl":"http://xxxx:yyyy"}

I noticed two bizarre things with my SDK:

1. The "Cleanup Unused Adapters" ALWAYS blew my adapters away even though I had devices defined.
2. The new Directory type did not provide POST callbacks when pressed.

While the first one wasn't much of a concern, the second one is a bit more critical.

After doing ALOT of debugging work, I figured out this issue is with the NAME of the adapter - specifically the name MUST BEGIN WITH src.

{"name":"openHAB-{unique UUID}","baseUrl":"http://xxxx:yyyy"}

Causes the two issues to happen.

If I change the name to...

{"name":"srcopenHAB-{unique UUID}","baseUrl":"http://xxxx:yyyy"}

both issues are resolved (the cleanup doesn't remove my adapter and the DIRECTORY types suddenly provide post backs).

How to recreate Very simple to recreate the issue using the official SDK. Modify lib/device/index.js and change the line

return 'src-' + validation.getUniqueName(conf.name);

to

'tim-' + validation.getUniqueName(conf.name);

Start up the File Browsing SDK example - add the file browsing device. Add the "Browsing Example" shortcut to a device and press on it - you'll see no POST back and the remote will spin for awhile before timing out.

Then open the APP, go to the Brain options/SDK integration and press the "Cleanup" button - you'll see the adapter is removed EVEN though the file browsing device is still present.

I'm in a bit of quandary what to do at this point. I could change my adapter name to add the "src" but that would break all the existing installations for the openHAB users - I'd rather if you could remove the dependency on needing the "src" at the beginning.

Looking forward to your response! Tim

EDIT

1. Apparently the "Cleanup" only requires "src" to start the adapter name
2. Apparently the Directory type requires "src-" to properly post (adding just "src" won't post)

[pfiaux]

The API underneath the neeo-sdk requires the pattern of the driver name to be src-${uuid}. I think @neophob will be better able to answer how we plan to handle support other language implementations of the neeo-sdk.

To clarify:

• Using the neeo-sdk module everything works without issues
• The issue surfaces when using a different pattern for the name when:
  • A. Modifying the neeo-sdk implementation
  • B. Your implementation of the neeo-sdk in another language

[neophob]

Hi @tmrobert8

Thats correct - the src- prefix is mandatory at the moment and your observed side effects (Cleanup Unused Adapters) are because your driver is not discovered as SDK device.

So unfortunately I don't see an other way to fix this than handle it on your side. But maybe you could handle the redirection on your side (form /openHAB-{unique UUID} to /src-openHAB-{unique UUID}) - not sure if thats feasible. But at least the existing installations would not break and new installation might already use the correct path.

But thanks for the hint, looks like we should add more docs about the API interface - even if its "officially" defined as "internal use" only.

I'm closing this as there's nothing else we can do about that for now.

[tmrobert8]

Hope you don't mind extending the discussion here a bit because there are some followup questions I have.

I kinda assumed you used a smart name concept to denote SDK added devices rather carry an additional attribute. However, since it's strictly a brain attribute - doesn't it make more sense to enforce this strictly on the brain rather than have it spread across the brain and SDK? In other words, shouldn't the brain be adding the 'src-' to the name internally if that's what it requires? Just a thought...

My real question is on the device names - the official SDK prefixes with "apt-{{uuid}}". Is that a required pattern? I absolutely don't follow that (just use the openHAB UUID directly without a prefix) and have never noticed an issue with it.

Lastly - the name prefix really doesn't matter to my code at all (since as I mentioned before, it's really a brain concept for identification only and doesn't 'leak' out anywhere in the API [nor is used in any URLS]) and there really isn't any 'handling' or 'redirection' I can do on my side.

The ONLY issue in changing a name is with the DEVICE SEARCH from the brain. If I were to change my name to "src-openHAB" from "openHAB" and use the new code with an existing installation (that has the old name registered still) - then, to the brain, I have TWO different SDKs registered to the same URL. Not a problem until you do a device search - in which case the brain see's two different SDKs, call their associated URLs (which are the same) and I start getting duplicate device results showing up in the brain (one for each unique name). Note: this would also occur with the official SDK if the UUID were to change (config, resinstallation, etc).

Would be nice if the search function would be limited to calling UNIQUE URLs (regardless how many SDK names were assigned to it) or add something to the request that would include the name of the SDK (X-NEEO-SDK header or maybe something in the URL that would uniquely identify it).

[neophob]

currently apt- is not mandatory, but I think its better if you stick to the same naming scheme to avoid any incompatibilities.

If I were to change my name to "src-openHAB" from "openHAB" and use the new code with an existing installation

yes thats expected as from the brain view there are two different sdk adapters running (as there are two different urls). but a cleanup of the unused sdk adapters might help as long as the old routes are still around.

we will improve the core api docs in the future and we might also recheck if there are some validation improvements.

thanks for the head up!