Multiple devices about xkeys HOT 6 CLOSED

X-keys have a unit ID, (UID) so 2 devices with the same Product ID (PID) can be distinguished. The UID once set remains with the device. Factory new they are often 0, and it can be incremented (0 to 255) so two devices on the same machine are not the same. This may be better than the path which could change in a replug event.

I can elaborate more on UIDs and their uses if this method looks like it would work.

Michael

from xkeys.

It would help if the devices already had the uid set. At the moment a user with, say, 2 new devices would have to ensure that at least one of them had a new uid set before plugging in the second device - otherwise they'd have two devices with probably the same uid=0.

A problem with factory set uids is that 0-255 is not a huge range so a user could conceivably end up with multiple devices having the same uid. That's perhaps unlikely but not impossible, so a user assigned uid is probably preferable. I just noticed in issue #27 that there has been some thought about automatic uid assignment. That would definitely help and is something I can try locally - bearing in mind the warning about EEPROM writes being limited to a few thousand :)

However a problem of making the uid unique at scale remains. It's not a problem for me but I can imagine a business with multiple devices on multiple machines having to move device(s) between machines for some reason. There would be a high likelihood of a machine ending up with devices having the same uid.

Back to availability of devicePath, I'm not sure that the possibility of a path change after a replug event is a big issue. The first part of a replug is a disconnect event which should have been handled by the application e.g. by removing the device from its device list etc. The second part of that replug is a connect event so the app just sees a new connection which it handles as usual (by adding to its device list etc.). The fact that the device might (or not) have a new path doesn't really matter; at least not for the way I was using the devicePath. Having the devicePath exposed again (as it was in v2.0.0) works better for me.

from xkeys.

Good points @cwilling !

I've implemented my idea from #27 and also added back the devicePath, in the PR #48 .
@cwilling could you have a look at that (npm install [email protected]), and let me know if it solves your direct issue?

The issue with having unique ids at scale remains, but I don't think that it's something we'll be able to solve in this library.

from xkeys.

Thanks, devicePath is working again in 2.2.0-alpha.1 although after thinking more about it all, the automatic uniqueIdentifier idea is very attractive too.

I see that the auto uid allocation has been added to the watcher. Would it not also (or instead) be useful to be in xkeys itself?

from xkeys.

Well, it's a close call I suppose. Since the watcher is the one handling connected/disconnected-events I thought it would fit best in there.

from xkeys.

Version 2.2.0 has been published to npm

from xkeys.