bojote

The HID Manager will look for ALL of your devices with the same PID/VID. Serial Number is how you setup the custom name for each device. There is really nothing you need to do, its already meant to be used with multiple devices

Totally agree with you, most people still stick with the “tried and true” Nanos and Megas, but the ESP32, especially the S2/S3 versions with USB-C, are a big step up if you want more flexibility. Once you try DCS-Anywhere’s USB HID setup, it really opens up new ways to build and connect panels, especially if you want to get away from the serial/COM port headaches. About running on a headless Pi: yeah, that would be really useful. Right now the CockpitOS HID Manager only runs with a GUI (Tkinter), so you need a desktop environment. There’s no official CLI mode yet, but I’m definitely considering it for the future. Would just need to strip out the GUI bits and let the network/HID bridge run in the background, maybe with logs to the terminal or a file. It’s kind of funny how much inertia there still is around Arduino Nanos/Megas, even though the newer options (like ESP32-S2/S3 with native HID and multi-platform support) are just so much better for this kind of stuff. I think as more people look for driver-free, network-connected panels, projects like this will eventually get more attention. One quick note for anyone curious: “CockpitOS” and DCS-Anywhere aren’t the same thing. CockpitOS is actually a full-featured firmware that supports most TEKCreation panels—it’s what I use for my home cockpit setup. DCS-Anywhere is more like a lightweight example or starter template. If you want to check it out, here’s the link: https://github.com/BojoteX/CockpitOS

Good! keep in mind I created a custom trained "GPT" that is better than me for answering technical or even implementation questions. I edited the original post with a link to it. Glad you you could make it work. Remember you can use that Python script on a Linux computer, MAC, Windows, Raspberry Pi with the panels connected locally, you don;t need to use the DCS computer to connect the panels! this will allow you to run them "remotely" and it scales nicely with almost 0% CPU usage even on a raspberry!

Here's how you fix it: 1) Check the directory where CockpitOS_HID_Manager.py is located. Notice the settings.ini file? open it. take note of the vid and pid values, should look something like: [USB] vid = 0xCAFE pid = 0xCAF3 2) Now Open Arduino IDE or notepad editor and open the sketch "Config.h" file. It should be located in the same directory where DCS-Anywhere.ino is. File should contain something like: // USB VID/PID #define MY_DEVICE_VID 0xCAFE #define MY_DEVICE_PID 0xCAF3 If vid and pid dont match, then HID Manager will not work. You definitely have different values there. Post both full files if still having issues or RE-download and without modifying a single line of code try to compile again. It will and should definitely work

While I have not tried the S3 with DCS Anywere I do have one that I use for the full stack ‘CockpitOS’ without issues. What I would do later today is download the latest version I uploaded, compile and test it. Give me until later today to test

What Arduino Core version you compiled the firmware with?

Yes, you can use a Raspberry Pi as the "host PC" for the DCS-Anywhere solution, but the cockpit hardware must still be ESP32 (S2/S3) running the supplied Arduino-based firmware. How it works: The Python HID Manager runs on any OS: Windows, Linux (including Raspberry Pi OS), or Mac. Just pip install hidapi, then run the Python script with your ESP32 cockpit panel(s) plugged into the Pi via USB. The Pi listens for DCS-BIOS UDP data and bridges it to your panel(s) over USB HID. No serial, no drivers, no COM ports! Your Pi and DCS computer must be on the same LAN (UDP multicast enabled). Limitations: Only ESP32/ESP32-S2/S3 boards (with Arduino framework) are supported as cockpit devices. Raspberry Pi cannot directly emulate a cockpit device (i.e., you can't plug a Pi into another PC as if it's a panel), but it is perfect as a network "panel hub." Example workflow: Flash the ESP32 panel with the supplied firmware. Plug it into your Pi. On the Pi: pip install hidapi python CockpitOS_HID_Manager.py Your ESP32 panel will now receive DCS-BIOS data anywhere on your network! Display support: You can use the ESP32's USB HID protocol to build an HSI or artificial horizon on your cockpit panel, with the Pi acting as the bridge. Docs: GitHub CockpitOS (full cross-platform support) All features work on Raspberry Pi as long as it runs Python 3.7+ and has HIDAPI Probably the only "concern" would be performance as I have no idea how the ARM CPU compares to my home Ubuntu/Linux intel mini-pc in terms of speed, but I'm confident this will work great

Got it. I probably misunderstood the original question. yes, both Arduino's and ESP32s (one using Serial and the other USB) will work perfectly fine. Part of the "beauty" of how DCSBIOS works is that it pushes the DCS data stream to a multicast IP address, *ANY* software component that joins this multicast group will be able to access that data and do whatever it wants with it, so there will be no conflicts of any kind in your proposed setup. In fact, if you wanted, you could even use one of those cheap amazon small mini-pc with Ubuntu, plug your ESP32 to it and they will literelly just work without you doing anything. The python script will run just fine on Linux and has almost 0% CPU usage. Its a cool test/experiment. Now, I imagine you are planning to do this on a SEPARATE Hub right? as the power requirements I don't think will change that much. 25 Arduinos vs (e.g 20 Arduinos + 5 ESP32 on same hub) will not make much difference.

The DCSBIOS part is "standard" both the actual library and interaction with the incoming DCS data stream. Whats really 'unique' about this code is how the transport layer works. It completely bypasses Serial (socat) and uses the ESP32 device USB bus for bidirectional communication with the Python script, which in turns acts as a "bridge" between your device and the "network" where DCSBIOS sends and receives data from DCS. Keep in mind what DCSBIOS does is simply "convert" DCS World data to "network data streams" you just happen to use them locally on your computer and have "socat" forward them to your device via Serial. I do exactly the same, I just dont forward this info to the device via Com ports, I use the Python script to push it via native USB. Now, to your original question: Arduino's are meant to be used and optimized for Serial comunication. Their native USB stack is not as robust as the one in the ESP32's, so even if you ported this to work in native USB's arduino's (technically possible) you'll have to modify how you instantiate USB HID. Keep in mind what I shared is a basic, simplistic template/reference which you can fork/modify as you wish. I'm pretty sure there are Arduino experts here that can take a look at the code and figure out how to implement. You need NATIVE USB in order for this to work, 100% HID protocol compatible at USB 2.0 speeds, if not, it will not work. If you tell me which Arduino's support this I could take a look and try to implement as an experiment and in that case you could mix this with a "normal" DCS-BIOS/Arduino setup

EDIT: A new GPT assistant was created to help users migrate code and help with general questions, you can try it here -- Hey all, Just sharing a little project I put together for my own home cockpit setup, but figured it might be useful for others building custom panels. DCS-Anywhere is a lightweight framework for running DCSBIOS-enabled panels on ESP32 hardware (including S2/S3 variants), but with a twist—you’re no longer tied to serial COM ports or to having panels physically connected to your DCS PC. With this, you can plug your ESP32-based panels into any computer on your network (Windows, Linux, Mac), and use USB HID to get panel inputs/outputs working seamlessly with DCS-BIOS. No drivers, no COM ports, just standard USB or network. Once connected via USB to that computer, the "HID Manager" can forward and receive all UDP DCS traffic to/from the device. Uses the official DCS-BIOS Arduino Library (so your existing panel code works, no need to rewrite for “lite”/custom forks) Supports ESP32, ESP32-S2, ESP32-S3 (Arduino framework) Network bridge (Python) lets you run panels from any PC, not just your sim rig Cross-platform: you can use Linux or Mac as a panel hub, not just Windows How it works: DCS World (with the DCS-BIOS Skunkworks fork) exports cockpit data via UDP on your network. A lightweight Python script bridges your panels (over USB HID) and the DCS PC. Your ESP32 panels communicate with the Python script via USB or UDP—no COM port headaches. All the details, code, and usage notes are here: https://github.com/BojoteX/DCS-Anywhere It’s basic and meant as a starting point, but if you’re looking for a simple way to get DCSBIOS panels working over the network (or on a non-Windows PC), give it a try. Read the README for setup and compatibility notes. If anyone gives it a go or has suggestions, let me know. Happy flying!

And thats still the case. I can confirm that Kneeboard builder (when using custom positioning profiles) does overwrite a lua file in the core folder. This change breaks IC for servers with the Pure client *SCRIPT* option (which few servers use). There is no way around this.

if you use it just to 'build' a Kneeboard, then yes, you are 100% correct. Thats why I stated in my message that my assumption is that this is due to the custom positioning via profiles in Kneeboard builder which is not a feature everyone uses. You know what feature I'm referring to?

Great software! being using it since last year, really good! I just noticed that I get a Pure Client Script IC check error when using some servers. I assume this is due to the Kneeboard custom positioning. I ask because I was under the impression (I read somewhere) that Kneeboard Builder passed IC checks. is it me doing something wrong or its just a limitation? thanks!

thanks!! yes, fully aware I can designate both members and donors, I was simply puzzled they were not assigned and other package elements were not showing on the SA page. As Baltic mentioned its probably a DCS Core issue. Not a big deal, as I said, I consider this an "in-flight system failure" for entertainement purposes.

No worries. Its one of those things that add complexity and challenge. As if it was an in-flight failure scheduled to finish Mission 15 today and will later check your new rampagers campaign. Thanks for your great work!