[nyanpasu64]

I wouldn't want a USB-based Picoprobe debugger or logic analyzer to depend on (or even use?) wireless connectivity. And for a low-latency game controller adapter which translates between wired NES/SNES, N64/GC, and/or USB protocols, converting a regular controller to a Bluetooth controller is quite an invasive change which requires adding batteries to the device, and increases input latency/unreliability when you're using a wireless connection, so many adapters don't bother with networking.

In terms of whether WiFi or Bluetooth is a wise idea (as opposed to being cool or useful), I find that wireless/networked protocols are easier to get wrong than simpler configuration. I have a video scaler (GBS-Control) which exposes a network-based interface over the ESP8266's Wi-Fi adapter. The IP address it picks up in my LAN is random, and though you can visit gbscontrol.local to resolve the URL using mDNS, this is unsupported on older versions of Android. And in certain video modes, the video circuitry interferes with the wireless signal, causing network requests to stall indefinitely.

In my observation, networking is especially prone to race conditions. If I toggle my power strip and power on both the ESP8266 and my router at the same time, the ESP8266 boots before the router, fails to connect to the router (remembered by PersWiFiManager), and decides to expose its own access point and never reconnect to the existing router afterwards. Worst of all, the web server used runs networking code in the yield() callback, leading it to handle network requests in the middle of I2C communication call stacks and possibly overflow the stack. It's also known to corrupt heap memory when concurrent HTTP requests occur (https://github.com/me-no-dev/ESPAsyncWebServer/issues/324 was closed by a bot without a solution). I found an concurrency footgun where the server allows HTTP callbacks to ask the server to reply with a SPIFFS file handle, but you can reopen and write to the file in subsequent code after the HTTP callback finishes, but before the server finishes streaming data from the file handle. This results in corrupted data being sent to the HTTP client.

I also heard that the Pinecil V2 released with a Bluetooth Low Energy compatible microcontroller, but the wireless-enabled firmware apparently malfunctions on certain irons and causes them to fail to boot (https://github.com/Ralim/IronOS/issues/1661), though this may be fixed over time.

[eternityforest]

Pinecil is one of the few things I'm kind of Meh on the Bluetooth part, once they added USB-PD and safety auto shutoff, it seems like there's not much to add that wouldn't cost money or size.

I wouldn't mind a wireless logic analyzer, if it had good battery life. Being able to use it on a tablet easily while charging without dongles so you had a second screen could be cool.

For a game controller adapter, I'd definitely prefer Bluetooth, because the performance is good enough for a casual gamer and it's pretty convenient. It doesn't necessarily even have to involve batteries, BLE is still useful with wired power, if your device doesn't have a lot of ports and you've got more spare chargers than spare hubs.

Android should have supported mDNS like, 10 years ago, but slowly we are getting to a saner place.

Network programming definitely is 10x harder than non-network programming. It absolutely will screw up and ruin your day if you don't assume all packets can be lost, all connections can be dropped, IP addresses can change, MACs can change, there can be 500ms of latency for no reason, you can get requests from multiple devices, connections can be closed uncleanly, devices can show up in any order, other devices can mysteriously forget connection info, IP conflicts absolutely will happen if you have manual static IPs and aren't really careful, there will be random code in frameworks to hammer flash memory caching credentials on every boot in Arduino, etc. But hey, it's still easier than soldering and 0603!

A lot of problems for anything remotely hobby level can be solved with heavy handed locks though. Like, don't touch the filesystem except under a lock, and use the same lock for everything, and hold the lock for the whole HTTP request, and only try to get more clever in specific places that need it. It might really suck and be slow, but at least it might be correct.

Network is a lot of hassle but it's also a lot of potential. Especially for configuration and debugging where it's ok if it's not 100% reliable, and for things that inherently tolerate a bit of loss, like telemetry.