search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.9k stars 498 forks source link

Fix script paths for DDF files #7726

Closed Zehir closed 4 months ago

Zehir commented 5 months ago

The validator does not yet validate script path, I found 3 that was invalid

ebaauw commented 5 months ago

I don't think it wise to refer to JavaScript files in directories for other manufacturers. The maintainer of the JavaScript won't realise it's being used by devices from other manufacturers as well. Hopefully this will be solved by bundling DDFs, but for now, I think we better copy the JavaScript files.

Zehir commented 5 months ago

I don't think it wise to refer to JavaScript files in directories for other manufacturers. The maintainer of the JavaScript won't realise it's being used by devices from other manufacturers as well. Hopefully this will be solved by bundling DDFs, but for now, I think we better copy the JavaScript files.

There already other DDF referencing script from an other folder.

Even with the bundling the directory structure of the devices directory will be the same. Or we can do an other workflow, any idea ?

Or we can create a shared folder with scripts used by many DDF ?

ebaauw commented 5 months ago

Generic JavaScript files are already in the devices/generic folder. Apparently with a subfolder per cluster.

Zehir commented 5 months ago

If @manup agreed I can edit this PR to move all generic scripts in the generic folder and update the paths

manup commented 5 months ago

Interesting topic.

The maintainer of the JavaScript won't realise it's being used by devices from other manufacturers as well. Hopefully this will be solved by bundling DDFs

That's indeed one of the main benefits of bundles. If something like above happens — and we had quite some cases already — a new "defunct" bundle would be created and labeled beta (via signature), but the old bundle is still available and keeps working.

If @manup agreed I can edit this PR to move all generic scripts in the generic folder and update the paths

If the scripts are truly generic that's fine. But the Tuya version script for example is not and should stay in tuya directory. I also agree with @ebaauw that if needed a script can be duplicated into another vendor directory to keep a meaningful tree structure.

In this case and for all Tuya branded devices, perhaps it's easier to move the DDFs in moes/ into tuya/. I'm not 100% sure but think we already have Tuya cases which started in <brand>/ directory and later on the DDFs were extended with totally different brands modelid/manufacturername (because Tuya...).

@Smanar I guess you have more insight here?

Smanar commented 5 months ago

Yes exaclty, there is "Moes" but thee is too "nedis", "fantem", "tesla" and more. Using <brand>/ directory is more friendly, but not good for common fies, and to group clone.

For me Tuya is Tuya, can be different brands, but same working mode, same problems, I don't see a difference beetween Moes or Nedis.

But I can understand an user buying a "Telsa" device not searching in the "Tuya" folder.

if needed a script can be duplicated into another vendor directory to keep a meaningful tree structure.

Yes me too, if one day someone change a script in the "tuya" folder, 99% of chance it will be compatible for all tuya but not sure it will be still compatible for other brands.

Zehir commented 5 months ago

What about an import syntax ? Maybe not a good idea, could be a mess for bundling

manup commented 4 months ago

Merging for now to get the path errors fixed. We can address the logical organization of where to put things later on.