Split up device and traits

[normanr]

The Smart Home API already splits up devices and traits, where-as it looks like Smart NORA devices have (mostly) hard-coded traits. It would be nice if it were possible to somehow split the traits out of the device definitions, and allow the device config to specify what the traits were (when configuring the device).

It would probably be quite a significant refactoring, but would also make it much simpler (hopefully near zero effort) to add new traits to devices.

[andrei-tatar]

New traits/device types need to be first supported by the nora service as they are validated against the schema to increase security (here's a list with the common stuff between the node-red client and the service: https://github.com/andrei-tatar/nora-firebase-common/blob/master/src/device.ts).

The service already supports defining any combination of traits/device types/attributes/etc. (from the supported list).

It would be nice to have a "device" node in the node-red plugin where you can combine all of these but the hardest part is the node-red html file where you define the interface for such a node. It would be a multi thousand line monster... Hard to write and maintain.

There are some nodes that do support multiple device types (open/close, media) and only the specific traits but in general I find the specific nodes easier to use for > 90% of the cases. There's always an edge case where someone has a light with a fan and a camera built in...

That being said, contributions are welcomed. So if you do want to add a device with customizable device type/traits/configuration per trait, just submit a PR.

[normanr]

I wonder if the traits could be in their own files (one trait per file) in their own script template, and then injected into the config dialog with oneditprepare. That would avoid the issue of a single huge file. I'd hope that defaults can be handled similarly.

I was also considering a single "device" node. The Node-RED general guidance for creating nodes says that nodes should be "well defined in their purpose", and having a "group of nodes that each serve a single purpose" is preferred. Looking at some of the other Node-RED Google Home integrations it's about a 50/50 split of "single node" vs "node per device type".

[andrei-tatar]

Yeah, not sure if the editor works like that, though I haven't tried it. I guess a new node will be easier, since it's mostly a copy of the fan node with a few small changes.

[normanr]

Also because it would be nice to list the exact traits of the device that the Smart Home API supports. i.e. light devices may or may not have brightness (but hood and switch also have brightness ability); currently it's controlled via the brightnesscontrol bool. Not all airpurifier devices will support fan state (mine happens to, which is why I used the fan device previously), some will support sensors (mine doesn't because I only have control via an infrared remote).

I'm imagining data-template-name being set to something like noraf-trait-brighness (eg: for the brightness trait). The list of traits would be shown as an editableList, and each item would have a "select" to choose the type of trait and when chosen the html template for the trait would be injected into a div (sort of like a mini-sub-config).

Looking at the code in node-red editor-client editor.js buildEditForm it just uses dialogForm.html($("script[data-template-name='"+type+"']").html()); to grab the template html to populate the dialog. (It looks like node-red-contrib-victron does something like this, but it's more static (happens at init time, and every node has the same template). Unfortunately a bunch of the helpful logic in prepareEditDialog that happens before oneditprepare is not exported. I wonder if a new oneditbuild event might be a useful request for Node-RED (would fire where subflow-template is currently handled manually).

[andrei-tatar]

I will investigate this on the next round of nora time I have. Such a node would definitely make it easier to support new traits/devices.