I think smaller ones might be useful for network quality testing and mapping. I think carriers drive around with boxes in vehicles to test their own networks reliability and map their competitors.
Octoprint is still a great piece of software that works with most printers, but it's running into a dead end where streaming G Code over the USB Serial emulation isn't fast enough on the newest generation of printers to keep them printing at their full speed.
Weirdly I had the exact opposite experience. Elgato always felt laggy. I bought a no-name USB Stick format card and it looked great (once I got my camera settings dialed in) but would disconnect when I bumped my desk. I cracked the case open and soldered a USB cable I cut in half to the pads, and 3d printed a new case and it's been rock solid for the last 4 years. Only problem is the once in a blue moon I need to use Teams my video get's horizontally squished and I can't seem to fix it.
I can say that in San Antonio where I live and also operate a ADSB receiver the dedicated air force flight trainers (T38 Talons and T6 Texans) routinely fly with ADSB on. The C5 cargo plans also fly with ADSB on when doing training but I've seen non-training flights fly overhead with ADSB off.
I can actually receive high flighting planes over Del Rio so it would be interesting to see if they are reporting bad NIC values.
Sadly Bluetooth support on Node is a mess and has been so forever. Noble is the only BLE library, and the original creator abandoned it years ago. The community forked it and has been maintaining it since then, but it's still got a lot of the baggage from the original, particularly that it's near unusable on Windows. I've considered rewriting one of my projects in another language just to get away from Noble.
This has been my hell trying to navigate for the past year. As a general rule, anyone who can't commit to updating and testing their software to run on the latest JDK ever 6 months should avoid the Oracle OpenJDK binaries like the plague since support for even LTS versions of Java is dropped 6 months after initial release.
Whether you use LTS versions or not, you must update your JDK every 3 months or so to stay secure, and must perform full regression tests. That we've recently changed the version naming scheme and started giving the 6-monthly updates new integer numbers does not make them major releases. I understand that people are confused because LTS and feature releases perhaps mean something different for Java than for other products, but the probability of an update breaking your app to the point you need to change code isn't much higher for a feature release than for an LTS patch. Updating to feature releases is overall cheaper and easier, it just requires companies to adapt. We realize change is hard and it will take time, but we believe this is the right approach. Those who have made the transition seem to agree.
That's all well and good for software developed in house by a full time development team that gets deployed to a single known environment, but that's only one way that the JDK gets used. If you provide software to customers to deploy in their own environments without direct control over updates, or if you have maintenance mode line of business software that you just want to keep patched this becomes a much bigger burden. Oracle also hasn't really been giving the time for these changes to be adopted either when the support for even LTS JDK builds is dropped at the same time the next stable major version is released. I realize that Oracle's answer is "and that's when you should pay us for support", but for anyone who wants to continue to use Java (or the JDK) in the "free" way its been historically, it's so much safer form a business perspective to use a JDK provider that has better support commitments to their free versions. Other than the fact that it's the default served by *.jdk.net that people are used to, I don't see why you would choose the Oracle OpenJDK over another provider.
Free support for JDK 8 ended after an average of 5 years and a notice of one year. Moreover, early access and then public availability JDK 9 builds were avaialble for a year and a half before end of public support. This is at least as much time as any previous version. Add to that the fact that the current free perpetual support is cheaper and easier than ever (although it does require a bit of getting used to), and the claim that people did not have enough time to adjust sounds tenuous.
In addition, Oracle has completely open-sourced the JDK, for the first time ever, and as we had done several times before, we transferred ownership of old JDK versions to Red Hat. Feel free to use whatever OpenJDK distribution you find suitable to your needs, but keep in mind that 90% of the work on OpenJDK is done by Oracle.
Finally, it is incorrect to say that support is dropped the next time the major version is shipped as Java 9 was the last major release ever. "Dropping support" for the semi-annual release as soon as the next one is released has been the practice for at least the past 7 years (e.g. there were no further updates to 8 once 8u20 was released). What has changed is that the semi-annual releases get an integer number. This certainly confuses people who don't realize that what would have been called 9u20 was renamed 10 and so on, and that cheaper upgrades are now easier and cheaper than ever before. So I agree communication could have been better (we're working on that), but I disagree with your characterization.
To summarize, free perpetual support is easier than ever, there was plenty of time for people to adjust, and open sourcing of the JDK has opened up the field for other distributions for different support options. All in all, things are cheaper, freer, and you have more options than ever. Yes, it seems that people have not yet internalized the meaning of the new feature releases (they are not major releases, but much closer to the old "limited update" releases), as well as the meaning of LTS (which is only recommended if you have a good reason not to use the current JDK).
Another pain point with making is that it's really hard to get it integrated with stuff you have bought. I built my own garage door automation with a Particle Photon board. It works great and can do things like text me if I leave the house with the garage door open using the IFTT support from my WiFi router. The problem is that it's really hard to get it integrated with any other control system that the rest of my house uses like my ZWave light switches and Hue lights.
I've been working on a custom UI that sits on top of the Wink Hub API to unify everything, but I'be been stuck with their almost completely undocumented Pubnub event API.
I would check out https://www.home-assistant.io/ for integrating multiple systems together. I use it on a RasPi to integrate a few disparate systems (Amazon, Nest, RadioRa2) and it works very well. There are modules for most existing systems and it's easy to write your own in python.
I probably should try it. I've been writing my own partly as an excuse to learn React. I've already got a Pi with a touchscreen and a 3d printed enclosure setup to run whatever solution I actually end up using.
I know I’m a little late here, but I would look into MQTT as a transport layer for messages across your different devices. It’s super easy to interface with via python or a host of third party services.
