Multi-device driver ?
I'm trying to write a single driver able to handle all the hardware line made by my company. Thanks to enableDiscovery (https://neeoinc.github.io/neeo-sdk/#lib-device-devicebuilder.js-enablediscovery) I can create distincts devices with distincts device id matching the hardware devices discovered on the network. I tested it, it works. But how am I supposed to tell which UI element belong to which device ? I'm asking because all devices don't have the same features set.
For instance: I can define discovery as follow
.enableDiscovery(
{ headerText: 'HELLO HEADER',
description: 'ADD SOME ADDITIONAL INFORMATION HOW TO PREPARE YOUR DEVICE' },
function() {
return [ { id: 'unique-device-id-001', name: 'first device', },
{ id: 'unique-device-id-002', name: 'second device' } ]; } )
then I want to had a switch to unique-device-id-001 only, but according to https://neeoinc.github.io/neeo-sdk/#lib-device-devicebuilder.js-addswitch , addSwitch doesn't take any device id parameter.
Is this even possible ? or am I supposed to solve this at higher level by defining multiple drivers like this :
driverObject1= neeoapi.buildDevice("Device 1");
driverObject2= neeoapi.buildDevice("Device 2");
....
const neeoSettings = {
brain: "192.168.0.9",
port: 1104,
name: "Yoctopuce",
devices: [driverObject1, driverObject2]
};
....
neeoapi.startServer(neeoSettings)-
It depends... :-)
if the capabilities of a specific model is static, let’s say there are two models, where model A has a power toggle button and model B has a power toggle and a switch, then exposing them as two separate drivers is the best solution. Both can use the same controller code but the capabilities are pre defined and offered separately by your driver.
When the capabilities are dynamic and can differ per installment/per user then SDK version >=0.52.x has a nice feature where you can define the capabilities at the discovery stage.
it requires the >=0.52 firmware that is not yet released at the time I write this.
Here is an example driver where I dynamically build drivers for MHUB uControl. https://github.com/nklerk/neeo_driver-mhub/blob/master/devices/mhub/uControlController.js
a NEEO example can be found here:https://github.com/NEEOInc/neeo-sdk-examples/tree/next/lib/dynamicDeviceBuilder
-
So, basically, right now I'm stuck with only one options 😐, OK, I can work with that. One more question though: is it possible to dynamically add drivers without having to stop/ restart the server? Since we are talking about IP devices, new devices can appear on the network at anytime.
-
Marc Martin The new feature is only needed for highly dynamic devices. For instance my MHUB driver exposes installed infrared drivers on the HDA MHUB HDMI matrix system. HDA have branded it uControl. I’m reading the installed drivers including all Ir command names. Then offer that to NEEO. After discovery the app shows me all installed uControl drivers and even their device type and NEEO icon. After selecting one of them all the capabilities are offered to NEEO depending on the capabilities in the uControl driver.
if you need this feature then I would suggest using it even though the firmware isn’t released yet. Probably will be released SOON™️ anyway. If you cannot wait for the release you could always contact NEEO directly and explain the situation. Who knows what solutions they can offer you.
typically a device has a static feature set. So all models might have command A,B and C while model Y has an additional command D and model Z has an additional command E. You can just define these and offer these as separate devices to NEEO within the same driver and while using the same controller logic. On my git you can checkout my LIFX driver. That one optionally supports different models. You would need to update the driver when a new model comes on the market. And thus restart the driver. When a new known model is added you the network then no reboot or code adjustments are needed as it follows the discovery process.
an alternate option to build a driver dynamically is to start a discovery upon startup of your driver, build drivers out of that dynamically and offer that as a drive to NEEO. Requires to restart your code when something changes in the network. This is not a great solution and more a workaround. Especially because the upcoming firmware can do the same and more in a clean way.
-
Niels de Klerk OK. I went for dynamically creating drivers for each discovered device and adding them to config's devices array while stop/restart the NEEO server. I still have iron out a few wrinkles, but It seems to work. Note that this slightly changes the way discovery works: instead of choosing a driver for a specific model and then one of the discovered devices matching that model, the user just have to choose a driver matching a discovered device. So I don't really need the enableDiscovery feature: it adds a useless step in the configuration process.
Now, the next problem: is there a proper way to deal with devices that goes offline/online? i.e. disable remote UI elements linked to offline devices? Our API can tells us exactly when one of our device gets disconnected / reconnected, how am I supposed to pass that info along to the NEEO API? I found updateReachable(id, reachable), but it requires an unique deviceid, and since I don't use enableDiscovery anymore, all my devices have their Id set to "default".
any idea ?
-
Marc Martin you’re following the same loop I once had. 😆 I can laugh now as it was so frustrating and I know the solution is around the corner.
as far as I know an unavailable device won’t gray out the UI components. You could use a text label to display the device status to the user.
i have no idea what you are building but it looks to me that you strongly need the upcoming discovery feature. Stopping and starting the code every time something changes is going to annoy you sooner or later.
-
Niels de Klerk OK, I'll do what I can with the current version and I'll see what can be improved when the new version is out. There is no point in writing software that our customers won't be able to use until
GodNEEO knows when. 🙂
-