[MacOS]: openStreamDeck error with listStreamDecks()[0].path

[CubexsOne]

Today I tried to use this lib but got an error now.

System:

• MacOS 11.5.2
• node 16.1.0
• npm 7.21.0
• yarn 1.22.11

I use the lib in typescript with nodemon, typescript and ts-node.

My current code:

import { openStreamDeck, listStreamDecks, StreamDeckDeviceInfo, getStreamDeckInfo } from 'elgato-stream-deck'

function getStreamDeck(): StreamDeckDeviceInfo {
    return listStreamDecks()[0]
}

function init() {
    const deviceInfo = getStreamDeck()
    const currentStreamDeck = openStreamDeck(deviceInfo.path)
}

init()

If I start the code I got this error:

/Users/user/Projects/project/node_modules/node-hid/nodehid.js:49
    this._raw = new (Function.prototype.bind.apply(binding.HID,
                ^
TypeError: cannot open device with path IOService:/AppleARMPE/arm-io@10F00000/AppleT810xIO/usb-drd1@2280000/AppleT8103USBXHCI@01000000/usb-drd1-port-hs@01100000/USB2.0 Hub@01100000/AppleUSB20Hub@01100000/AppleUSB20HubPort@01140000/USB2.0 HUB@01140000/AppleUSB20Hub@01140000/AppleUSB20HubPort@01143000/Stream Deck XL@01143000/IOUSBHostInterface@0/AppleUserUSBHostHIDDevice
    at new HID (/Users/user/Projects/project/node_modules/node-hid/nodehid.js:49:17)
    at new StreamDeckBase (/Users/user/Projects/project/node_modules/elgato-stream-deck/src/models/base.ts:152:17)
    at new StreamDeckGen2Base (/Users/user/Projects/project/node_modules/elgato-stream-deck/src/models/base-gen2.ts:9:1)
    at new StreamDeckXL (/Users/user/Projects/project/node_modules/elgato-stream-deck/src/models/xl.ts:16:3)
    at Object.openStreamDeck (/Users/user/Projects/project/node_modules/elgato-stream-deck/src/index.ts:114:9)
    at init (/Users/user/Projects/project/src/app.ts:9:31)
    at Object.<anonymous> (/Users/user/Projects/project/src/app.ts:12:1)
    at Module._compile (node:internal/modules/cjs/loader:1109:14)
    at Module.m._compile (/Users/user/Projects/project/node_modules/ts-node/src/index.ts:1310:23)
    at Module._extensions..js (node:internal/modules/cjs/loader:1138:10)

Some ideas?

[czottmann]

Same issue here. The path returned by listStreamDecks() is wrong. MBP M1 on macOS Big Sur 11.6, node v16.6.1.

[
  {
    model: 'originalv2',
    path: 'IOService:/AppleARMPE/arm-io@10F00000/AppleT810xIO/usb-drd0@82280000/AppleT8103USBXHCI@00000000/usb-drd0-port-hs@00100000/USB2.0 Hub             @00100000/AppleUSB20Hub@00100000/AppleUSB20HubPort@00130000/USB 2.0 Hub@00130000/AppleUSB20Hub@00130000/AppleUSB20HubPort@00133000/Stream Deck@00133000/IOUSBHostInterface@0/AppleUserUSBHostHIDDevice',
    serialNumber: 'AL18K2C57511'
  }
]

[Julusian]

Are you able to check what the path is supposed to be? Ive not had any issues in a Mac Mini M1

The path is coming directly from and fed back to https://github.com/node-hid/node-hid, so I find it strange that it would be wrong.

[chrisspiegl]

UPDATED:

I ran into the same issue, however after disconnecting the Stream Deck (MK2 in my case) and reconnecting again, testing it all, it seemed to work.

Not sure what exactly the issue may have been? Possibly the path was occupied? Somehow already connected in a process or something.

[Julusian]

If you are connecting the device through a usb hub, it is possible that the path is too long for an underlying library and so is being trimmed, causing the open to not find it. It is also possible (especially when used with nodemon) that the device is open in another process (nodemon might not be terminating the old process properly before the new one tries to open it?)

@chrisspiegl do you know what the path was when it both did and didnt work? Perhaps someone with the issue could see if it is possible to open it directly with node-hid with the vid&pid constructor? https://github.com/node-hid/node-hid#device--new-hidhidvidpid Make sure to call HID.setDriverType('libusb') first, as the default driver may behave differently

[chrisspiegl]

Thanks @Julusian for the reply. I have since moved to not rely on the path and instead use the serial number to figure out which device is setup. I am assuming that will be more reliable anyways since the path may change the moment another port is used.

I also was using nodemon so that probably added to my situation 🙈.

[BarryCarlyon]

I just ran into this on mac as well.

I had the streamdeck software running. After killing that the code works. (But the web example doesn't) Then killing my code the web example now works.

Something weird on mac where two things can't control the USB/communicate to the streamdeck at the same time all the time (sometimes it will let two or more things and sometimes it won't)? Mighr help narrow it down at least?

[Julusian]

Something weird on mac where two things can't control the USB/communicate to the streamdeck at the same time all the time

That is expected. The usb devices are opened in exclusive mode, to avoid them being opened by multiple applications simultaneously.

[BarryCarlyon]

I thought it weird as this didn't happen on windows initial testing with the chrone example. my streamdeck software and the browser version happily went to war with each other

If the expected behaviour is that one thing wins then I need a different approach to what I was thinking of doing (which is fine, exploring options!)

[Julusian]

Oh yeah, windows is different.

Its an issue with different behaviour in a library a couple of layers deep, with different hardcoded behaviour for different platforms (exclusive mode on linux & mac, shared on windows)

It looks like it might now be possible to change the behaviour on mac now https://github.com/libusb/hidapi/issues/27, but for a device like this I dont see where it makes sense to do it. You will be relying on every application which might use the streamdeck to be cooperative in how it sends bitmaps.

At some point I am hoping that that library will add an option to open in exclusive mode on windows, and to I will enable that in this library. I wasnt planning on making that configurable, but I am open to it. Either way, it sounds like linux doesnt have any choice in how it is done