Fix: Adding device types through custom XML #1565
Conversation
- Fix front-end issue for custom XML device types
- Fix device type reference updating for custom XML device types
- Fix use case where custom XML device type is being used for different sessions using different zcl files
- Fix default attributes and commands enabled when custom cluster is enabled
aa3eec8 to
944dfa8
Compare
985cbc3 to
a2c3bb3
Compare
- Fix front-end issue for custom XML device types - Fix device type reference updating for custom XML device types - Fix use case where custom XML device type is being used for different sessions using different zcl files - Fix default attributes and commands enabled when custom cluster is enabled - Fix endpoint-config helper when custom xml device type is used - Fix file open for .zap file with custom xml device type - Added tests
a2c3bb3 to
c3f48d9
Compare
| break | ||
| } | ||
| if (endpointTypeCategory) { | ||
| zclPropertiesPkgs = zclPropertiesPkgs.filter((pkg) => { |
There was a problem hiding this comment.
zclPropertiesPkgs = zclPropertiesPkgs.filter((pkg) => pkg.category == endpointTypeCategory)
| packageId = pkgs[i].id | ||
| break | ||
| } | ||
| if (endpointTypeCategory) { |
There was a problem hiding this comment.
Is there a use case where an old stack will not have endpointTypeCategory because categories did not exist from the start of ZAP invention? What happens if an endpoint type has category as null?
There was a problem hiding this comment.
Then all zcl properties files will be passed since the if (endpointTypeCategory) will not be true and zclProperties` will not be changed. Since it is an old stack this will not be an issue because there will no multi protocol.
src-electron/db/query-config.js
Outdated
| ) | ||
| // Relevant packages are zcl file (filtered by category) and all custom xmls in the session | ||
| let pkgs = zclPropertiesPkgs.concat(zclXmlStandalonePkgs) | ||
| if (pkgs == null || pkgs.length < 1) |
There was a problem hiding this comment.
Should this error check be done on zclPropertiesPkgs ? Do we want a session with just custom xml?
src-electron/db/query-device-type.js
Outdated
| return dbApi.dbRemove( | ||
| db, | ||
| ` | ||
| DELETE FROM DEVICE_TYPE_CLUSTER |
There was a problem hiding this comment.
Format this query like the others
| ) | ||
|
|
||
| // clean up unlinked device type clusters | ||
| return deleteUnlinkedDeviceTypeClusters(db, packageId) |
There was a problem hiding this comment.
Avoid delinking. Throw warnings into the notifications pane stating certain device type clusters do not exist.
There was a problem hiding this comment.
Throwing warnings but will still need to delete unlinked clusters to avoid duplicates in certain cases.
src-electron/rest/user-data.js
Outdated
| sessionId, | ||
| dbEnum.packageType.zclProperties | ||
| ) | ||
| let zclXmlStandalonePkgs = await queryPackage.getSessionPackagesByType( |
There was a problem hiding this comment.
Instead of multiple queries should we get packages once and then filter based on type? Would get us out of multiple database interactions.
| expect(endpointConfig 8000 ).toContain( | ||
| '/* Endpoint: 1, Cluster: Test Cluster - Device Type (server) */ \\' | ||
| ) | ||
| }) |
There was a problem hiding this comment.
Recently figured out how to open a file in the browser when zap server is running
http://localhost:9070/?standalone=false&filePath=%2abc%2Fconfig%2Fzcl%2Fzcl_config.zap#/
You could try using this in the cypress tests to open a .zap file with custom xml and check UI elements if you are curious.
| if (result) { | ||
| const existingId = result.DEVICE_TYPE_ID | ||
|
|
||
| if ('clusters' in dt) { |
There was a problem hiding this comment.
For future just create one. Fine for this.