I am doing some research on the WebUSB API for our company because we are going to start to manufacture devices in house.
Our current device manufacture comes with an application so the team can plug the device into a computer and diagnose it. Their application allows us to read outputs from the device, as well as pushing commands/configuration to the device over a wired connection.
Since this device is 100% ours, we are also responsible for building out the diagnostic tooling. We need some sort of interface that allows a user to read outputs and send commands/configuration to the device over a wired USB connection.
Is the webUSB the correct API? If not, what are some suggestions for accomplishing the requirement? Are we limited to building some sort of desktop or mobile application?
I would recommend resources below to read to help you understand if the WebUSB API fits your needs or not:
https://web.dev/devices-introduction/ helps you pick the appropriate API to communicate with a hardware device of your choice.
https://web.dev/build-for-webusb/ explains how to build a device to take full advantage of the WebUSB API.
From what you describe, WebUSB isn't strictly required but won't hurt either.
First and foremost, you will need to implement the USB interfaces reading data and sending configurations. It will be a custom protocol, and not one of the standard USB device classes such as HID, video or mass storage. The details of the protocol and if you use control, interrupt or bulk transfers is your choice.
I'm assuming you will connect the devices to Windows PCs, and you likely don't want to put money into writing device drivers. If so, the easiest approach is to add the required descriptors and control requests required for Microsoft OS 2.0 Descriptors. That way, the WinUSB driver will be installed automatically when the device is plugged in.
Using the WinUSB API, a Windows application will then be able to communicate with the USB device. No additional drivers are needed. (On macOS and Linux it's even easier as you don't need the Microsoft OS 2.0 Descriptors in the first place.)
On top of that you can implement the additional descriptors and control requests for WebUSB. It will provide the additional benefit that you can write a web application (instead of a native application) for communicating with the USB device. (Currently, you are restricted to the Chrome browser.) WebUSB devices should implement the WinUSB descriptors as the alternative (.INF files, manual installation process) is a pain.
The already mentioned web page https://web.dev/build-for-webusb/ is a complete example of how to implement it.
Related
I would like to talk to a custom piece of hardware via my web application using WebUSB
The hardware is already able to communicate to a python script running on a laptop via USB
Now I have 2 questions and I hope you can help me :)
Does the hardware need to implement anything WebUSB specific? Or is the USB communication that is already implemented enough?
Is WebUSB ready for production? This application will be used by customers to talk to machines like excavators.
The whole application (talking to machines) already works via internet - we just need to implement the USB communication to handle the case that the user doesn't have a working internet connection.
best,
Kev
Does the hardware need to implement anything WebUSB specific? Or is the USB communication that is already implemented enough?
It is enough.
Is WebUSB ready for production? This application will be used by customers to talk to machines like excavators.
The Chrome team takes the decision to make a Web API available to developers very seriously and is committed to supporting these APIs for the long term. The draft status of the WebUSB API should not be taken as a reflection of the Chrome team commitment to this work. It is a necessary effect of how the web standardization process works.
The WebUSB API has been available for quite some time and is considered stable. While we have been making steady investments in the implementation of the API there are no changes to the developer-facing interface planned.
Over the last couple of years I have been looking for an easy way to control a few relays from Javascript. I want to build a web App to control starting sequence horns for sailing races.
I recently discovered webUSB and it seems like exactly what I need. A direct connection from JS in chrome to the USB world. Simple coding in a language I already use.
On the hardware side I am having trouble finding a product that is compatible. Googling USB Relay finds 100's of products that all seem to rely on some proprietary SW for the OS. I can find lots of educational demo's that turn an LED on and off.
Does anyone have any ideas where to find such a product?
While I'm sure you will be able to find USB relays that can be controlled via WebUSB, most USB relays will probably come with some kind of serial port driver, e.g. https://numato.com/product/1-channel-usb-powered-relay-module uses a CDC serial port driver. These can be controlled using Web Serial, available in Chrome 77 and later behind a feature flag. For a tutorial, see https://codelabs.developers.google.com/codelabs/web-serial/
Explainer: https://github.com/WICG/serial/blob/gh-pages/EXPLAINER.md
API docs: https://wicg.github.io/serial/
If you search for "5V USB Relay Programmable Computer Control For Smart Home" on eBay, you will also find low-cost relays that use HID instead. The advantage of these is that you don't need any serial port or USB drivers, as it will use the operating system's built-in HID drivers. For that you can use WebHID. For more info, see https://github.com/robatwilliams/awesome-webhid.
I have a USB audio device (Scarlett Focusrite 18i6) which does not require a driver, so I assume it uses the USB HID Audio Class standard.
It works on everything from Windows and Mac to Linux and iOS.
But on Mac and Windows, it has a control application which can for instance enable and disable direct monitoring.
How would I go about reverse-engineering how this is done, so that I can reproduce it on platforms where the control application does not exist?
I'm thinking of booting up Windows in a VMWare session and then logging the USB communication (somehow?) while using the control application, but it does sound tedious considering the amount of data and my very limited understanding of USB.
Any other suggestions?
You could try running the control application using Wine instead of reverse engineering it. However, if it's accessing USB devices then there is a good chance it might be using an API not supported by Wine.
To reverse engineer it, you should find a way to look at the USB traffic between the computer and the device. Total Phase has some hardware USB protocol analyzers, but you might be able to find a good software solution for free.
I am writing a windows application (written entirely in C++) which reads files from a storage card on a mobile phone running Windows Mobile. The tough part is, I don't know how to make my application detect the event that a user has connected the mobile phone to the USB of laptop. I did some reading on MSDN and have written a small code using RegisterDeviceNotification, which detects whenever a USB disk is attached/removed from the laptop. However, I am unable to tweak this to make it work for phone type devices. Please help me out through any links/tutroials which explains this(preferrably C++, as I don't know .NET or C#).
Thanks
Alok
According to this article you can use RegisterDeviceNotification to get notifications when activesync detects a device has been plugged/unplugged. (See option 3 at the end of the article)
It may just be a matter of setting up the correct notification filter.
Windows Mobile devices use RNDIS, a network interface protocol behind the scenes. Hence, the RegisterDeviceNotification method still works, but you're looking for a DEV_BROADCAST_DEVICEINTERFACE, not DEV_BROADCAST_VOLUME. (i.e. dbch_devicetype==DBT_DEVTYP_DEVICEINTERFACE)
You can use RAPI or RAPI2 to detect when a Windows Mobile device connects to a PC via Active Sync or Windows Mobile Device Center. RAPI can also be used to read the files on the storage card and much more.
RAPI is simpler to program because it is a C based API. RAPI2 has more functionality than RAPI, but is an object oriented COM API. If your needs are simple and you only care about one device/connection at a time then RAPI is good enough. There are two RAPI functions used to detect connections: CeRapiInit (blocking), and CeRapiInitEx (signals an event upon connection).
I need to connect to a Bluetooth device through virtual COM port created in Windows. It's easy when the port has been already created during manual pairing procedure. But I would like my application to relieve an user from the manual pairing of a device. I would like to present all devices in the range, allow user to chose one, and then create virtual COM port connected with the selected device. I'm not trying to avoid the pairing procedure itself, but rather I would like to invoke it by my application.
I started getting familiar with Microsoft Bluetooth API. And then some doubts arose. I've been wondering what happen if some user would use different (than Microsoft's) Bluetooth stack? Is the Microsoft's API the real Bluetooth API, which have to be implemented by any other Bluetooth stack provider? Or rather each provider has its own API, and the Microsoft's is only one of many other?
Thanks everyone for valuable input. I'd like to summarize what I've found so far. The Microsoft Bluetooth API is not operating system API. Application written against it will not cooperate correctly with any other Bluetooth stack. It seems that applications which are intended to cooperate with multiple stacks need to provide some stack abstraction layer, and stack specific code for all of them.The other solution is to allow user for manual pairing of the Bluetooth device, which eventually create some virtual device in the operating system (e.g., COM port). Then the application can use standard interface of such a device.
I can't speak for the Microsoft Bluetooth API, but there are multiple Bluetooth stacks available for the PC platform (even more for mobile devices).
The underlying API is defined by the Bluetooth Core Spec and so all stacks should be able to interact, in fact it is mandatory that they interop or they cannot use the Bluetooth name and logo.
As to pairing, your going to have a hard time getting devices to pair if they have default security, which requires a pin code.
Things might be simpler in the (near) future, as the Bluetooth standard has introduced a new security model, secure simple pairing, which has a 'just works' mode that requires no Pin code. This is still stronger then the current security, except against Man in the middle attacks. However, it could be a while before you see the chips with this feature in PCs.
If you can change to using .NET :-/ I can recommend our library 32feet.NET.
For explicit pairing there's BluetoothSecurity.PairDevice. We can also create the virtual port for you, for example:
BluetoothClient cli = new BluetoothClient();
BluetoothDeviceInfo[] list = cli.DiscoverDevices();
BluetoothDeviceInfo selected = GetUserToSelectOne(list);
BluetoothSecurity.PairDevice(selected, pin);
// Ask Win32 to create a virtual serial port
selected.SetServiceState(BluetoothService.SerialPort);
However I really don't like virtual serial ports so I always suggest that people use a normal sockets connection using our BluetoothClient class, it will automatically handle a pairing request if required.
On Win32 we support the stacks from Microsoft, Widcomm/Broadcom, and BlueSoleil. On Widcomm there's no support for SetServiceState there yet, and their API has no support for responding to pairing requests. BlueSoleil should support both.
A brief user's guide is at 32feet.NET — User’s Guide, and all the class documentation is available at the main site http://32feet.net, the Widcomm documentation is only in our code repository at the moment.