Handling of USB disconnect/reconnect about xkeys HOT 6 CLOSED

panel.productId + panel.unitId
may not be unique enough. If a device with productId 1062 and unitId 4 is connected along with another device with productId 1065 and unitId 1, both end up with uniqueIdentifier == 1066, so will look like 'reconnected' but should be a 'new-connected' since they're clearly different devices.

Rather than a simple arithmetic addition of productId and unitId, it might be better to do a string concatenation - something like:
const uniqueIdentifier = panel.info.productId.toString().concat('.', panel.info.unitId);
which would give 1062.4 and 1065.1 for the example devices - now clearly different.

from xkeys.

... on the other hand...

node-usb-detection is good at doing exactly that - detecting add/removals of USB devices.
But it doesn't report back the path or some other unique identifier that is shared with node-hid (and thus xkeys lib).
Which means it will be difficult to use the output from node-usb-detection to determine whether the Xkeys panel in use what (dis)connected.

The reason for this whole exercise is to properly handle the scenario where multiple Xkeys panels are connected to a single computer, and one of them is removed.
Potentially two XK-24's could be connected - it must then be possible to distinguish between them, and correctly handle one of them being removed and then reconnected.

from xkeys.

I can definitely see that being able to handle reconnections for a previously connected panel could be useful.
If you (or anyone else) would submit a PR I'd be happy to review it.

I think we should at least add the functionality:

• Enable a consumer to listen to some event ("deviceConnected", device: HID.HID, isReconnecting: boolean), so that the consumer can use that to set up when a new panel is connected.
• Keep track of previously connected panels, and emit a ("reconnect") on the panel when it's reconnected.

from xkeys.

Agree.

Ok, I'll poke around in this and see what I can do.

from xkeys.

Note to self:

I'm waiting with this a little bit until we've gotten 2.0.0 released.

I intend to add an option to XKeysWatcher() to enable an "automatic unitId mode", which automatically sets the unitId to something unique in order to be able to uniquely identify different panels.
It'll be an opt-in option, as it may cause unwanted behavior if the user isn't aware of what is done to the panels.

It should be able to handle most situations, with one big caveat:
If you have an xkeys-panel which has a unitId set previously, it might conflict with another panel. If this happens, two "identical" panels can be connected at the same time. We could potentially handle this by force-setting the unitId of one of the panels to something else. Some thought-work needed.

Pseudo-code:

on('panel-connected', (panel) => {
  if (automaticUnitIdMode) {
    if (panel.unitId == 0) { // if it is 0, we assume that it's new from the factory and can be safely changed
      panel.setUnitId(nextUniqueForThatProductId) // the lookup-cache is stored either in memory, or preferrably on disk
    }

    const uniqueIdentifier = panel.productId + panel.unitId // the PID+UID pair is now enough to uniquely identify a panel
    if (uniqueIdentifier is in memory-cache) {
      emit('reconnected')
    } else {
      emit('new-connected')
    }
  } else {
      emit('new-connected') // default behaviour
  }
})

from xkeys.

I've published version 2.2.0, which adds the 'reconnect' event (when using automaticUnitIdMode).

@mountaindude feel free to open another issue if you have any other problems (or solutions) regarding macOS.

from xkeys.