Warning: copy(/home/sheer/public_html/wordpress/wp-content/wflogs//GeoLite2-Country.mmdb): failed to open stream: No such file or directory in /home/sheer/public_html/wordpress/wp-content/plugins/wordfence/lib/wordfenceClass.php on line 2073
Never been one to let the carrier drop » Blog Archive IOT problems - Never been one to let the carrier drop

IOT problems

So, one problem that we in general have with computers is that they are constantly in a state of growth and therefore it tends to be difficult to read files written 20 or 30 years ago because we don’t have anything remaining that can either handle the physical or logical format. (This makes me wonder if anyone has made something like the 7 layer model for data storage)

Anyway, one upcoming problem is that we lately are doing a lot of IOT devices – and a whole lot of these are going to be in landfills in ten years. The basic problem is that the people coding for them have fallen in love with the latest moronic fad, which is to have a ‘app’ to set up everything.

We need to have a *universal* configuration language that runs over bluetooth – someone should have a working group together. Or, we could just stream HTML over bluetooth – hm, that seems like a really good idea now that I mention it. Anyway, I also am pondering if most devices should just use bluetooth to negotiate the initial internet connection and then be configured via a web page. That seems like it might be best.

What isn’t best, what is in fact awful, is to have custom code, a dedicated app, for each device to be configured. Some of the obvious problems with this:

1) It requires the user to have a device that the app will run on. In 20 years there may be no android or IOS devices left because someone may have written a much better operating system

2) There’s also some version issues. As per usual the developers don’t write things to run on all versions, and it’s very likely that future versions will also be incompatible

3) This requires the developers of the hardware to continue releasing software – in some cases the developers may not even exist, and even if they do exist capitalism says it won’t be profitable to continue to support devices that are even a few years old so I doubt if we’re going to continue to see new versions of configuration tools

So, here’s what I think tehy should be doing

#1: We need a standard communication protocol for bluetooth for configuring all devices that are configured via bluetooth or BLE. Bluetooth working group, I’m looking at you. If you can charge $8000 per device for people to have your logo, you can do less of a halfass job at telling them not to make devices that won’t be configurable in a few years because the apps will no longer be maintained

#2: We need to have a agreement that whenever possible we’re going to use a standard web browser to configure devices. You can still make custom apps that do it as well, but you should document the API and have a plain ol’ javascript version of it so those of us who don’t want to deal with your apps can still use our devices

#3: Whenever possible you should make it so that your device can be maintained locally without your cloud service. Ideal ways to do this include docker and kubernetes containers that run your service that the customer can install on their local hardware, open source descriptions of your protocols, etc.

#4: You should publish schematics, source code, and whatnot for your products – both allowing users to change the basic functionality and publish new and better versions of the firmware, and allowing them to look for security holes and design flaws. In a lot of cases, IOT devices can cause a lot of damage – you all need to be building equipment we can trust.

I’m currently in the process of working on firmware for a IOT device, and it has really made me think about how poor a job humans are doing on IOT in general right now.

Another thing I’d like to mention, and this in particular is aimed at ORbit’s B-Hyve. Whenever possible, *DO NOT* waste the user’s time. If you do not *need* to upgrade the firmware to be able to continue, *don’t*. If you must upgrade the firmware, try to do it over the internet rather than BLE – at the very least, kick into bluetooth classic in order to be able to get halfway decent amounts of bandwidth.

(B-Hyve is in many, many ways a example of how not to, when it comes to IOT devices. It’s a great idea, and the hardware is well done, but the software is *awful* in a very long list of ways)

Leave a Reply