[btashton]

This kind of response is a big part of why I have given up building commercial IoT products for now. It's great to want to have some super abstract high level self discovering protocol, but when you actually start to build on it it really hampers the product.

If you want to build a smart light switch you are trying to get the response time very low and worry about things like syncing behavior around the network. Doing these things ends up being very domain specific and you do creative engineering to make it happen. These are very different than the requirements for say a vacuum cleaner.

Then we have standards that come out like Bluetooth mesh or HomeKit that say this is exactly how a light switch should work. Great, except your light switch has this cool feature that Philips did not think of in the committee meeting and now you are forcing it in and your product once again suffers.

These standards all suck, some small percentage of your customers want custom access (rightfully so), and a large percentage are comparing you on price and experience. The outcome is a closed off product. With maybe a cloud API.

Like I said this is why I don't want to work on these products anymore. You cannot win.

[hakfoo]

> Then we have standards that come out like Bluetooth mesh or HomeKit that say this is exactly how a light switch should work. Great, except your light switch has this cool feature that Philips did not think of in the committee meeting and now you are forcing it in and your product once again suffers.

This seems like it could be solved by a meta-standardizzation: a standardized extensibility model. So the light bulb supports "on", "off", and "dim", and the vaccuum supports "begin cleaning", "return to charging base" and "open dust cup lid", but both support a "Get model-specific register and function list" command, yielding something like WSDL.

Maybe Philips bulbs activate their RGB disco seizure mode with Model Specific Function 82, and GE bulbs have colour temperature control on Model Specific Function 74, but so long as the bigger, smarter device controlling both can query this and package it up for users, it works fine. And when your new vaccuum has "knit new cat out of collected cat hair" they can define it as MSF 74 if they want, so long as the catalog is accurate.

[kadal]

This vaguely sounds like MIDI to me

[shimfish]

Or CSS extensions

[corrigible]

Or SNMP MIBS

[ViViDboarder]

You don’t have to follow a standard to not use an obfuscated API.

Following a standard is great but extending beyond that for your own features or using a variation is still fine if the API is accessible by users.

[Animats]

A good model for this is the HID protocol for "human interface devices". This supports keyboards, mice, joysticks, game controllers, etc. over USB. It's simple enough to be used by very basic devices, and descriptive enough to extend to most control-like devices.

Most home automation stuff doesn't have that big a command vocabulary.

[mattmanser]

I completely understand and sympathise with this sentiment, as I'm sure many others will.

It's one things to want standards, but when it's still an emerging field, with so much different functionality, it's an impossible task.

Any poster who advocates standardization at this stage would probably be wise in reading about the early computing days, when you had so many different standards, before it crystallized behind IBM MS-DOS. Or even HTML, where would we be today if MS had listened to "standards" and not released XMLHttpRequest/MSXML library.

No ajax, no modern web.

This is a perfectly normal, and perhaps desired, period of experimentation where standards will just hold the industry back.

[II2II]

Standards are convenient, but a lot of issues would be resolved if products were publicly documented. To my knowledge PostScript was never standardized and PDF has been standardized for about half of its history, yet they were both fairly well documented by the vendor. Contrast that to other popular document formats, or this bike, which had to be reverse engineered. Yes, documenting implementations adds overhead that inhibits the rate of progress. On the other hand, not documenting implementations are usually inhibits progress as well since it is all about short term gains.

[elephant_talk]

You have a valid point about velocity being held back by standards. But you don’t do yourself any favors, IMHO, pointing to the modern web as an example. If anything, the modern web is the perfect cautionary tale. Walled gardens, app churn, bloated apps. No way to use part of a service without all the crap that comes with it.

The modern web could stand to let off the gas.

[strken]

Are walled gardens and app churn really the fault of AJAX requests, though?

For that matter, would removing AJAX and modern JS have fixed anything, or would people have routed around the problem? Any alternate web I can imagine just ends up with everyone using Flash/Shockwave/Silverlight/Java applets, which are even worse. A handful of diehards stay on plain HTML, just like they do today, while everyone else moves to gigantic ad-ridden behemoths.

[elephant_talk]

Walled gardens aren’t the result of Ajax, no. They’re the result of insufficient or missing standards (or at least lack of standards enforcement).

How many times do you encounter a website that doesn’t support your OAuth provider of choice? So you keep 2 or 3 around, and oh this site only does their own password based auth, OK I’ll use my password manager to make a one-off for this site.

Keep in mind, JS itself was developed by one browser vendor (Netscape IIRC) because there was a lack of a standard for interactivity on the web. These tools arise out of need, but because of capitalism the players creating the tools don’t work together. They stand to benefit if they can “win” and starve the others until the other solutions die, so that’s what they hope to do. It’s anti-consumer.

I don’t know what the answer is. Maybe it should be illegal for apps not to allow certain levels of interoperability and freedom to migrate. Hence a previous poster’s term, “GDPR-sized hammer”.

[Cieplak]

It's also interesting to consider how standardization can similarly maintain an industry dominated by larger players, trying to establish their moat through regulatory capture.

Sort of a duality to how lack of standards propels innovation in the nascent days of a technological field.

Not saying there shouldn't standards in general; simply that we should be cognizant of market forces using standardization efforts as offensive tactics.

[moron4hire]

> I completely understand and sympathise with this sentiment, as I'm sure many others will.

I don't. He's basically admitting his engineers are incapable of reading relatively short, well-written spec documents.

This stuff is standardized. BLE is extremely easy to use, both on a device and in an application. BLE makes it possible to create self-documenting devices that any application could use. Device manufacturers are going out of their way to prevent that from happening.

[btashton]

We wrote a Bluetooth mesh product before there was Bluetooth mesh standard. Don't call me lazy for not publishing a short spec when the actual Bluetooth spec is over 100 pages. BLE is "easy" managing a mesh network with transactions , droped packets, authentication, 100s of settings across different products is not. Instead we focused on the product we were trying to sell and things people actually bought based on like Alexa and Google support. We had lots of internal docs that heavily documented things including things that would damage the performance of the network and experiments that failed in practice.

[thereisnospork]

I don't think it should be a protocol so much as 'english-ish'. So not a framework which defines a lightbulb (and every other IOT), but a defining human/NLP readable language so a human/alexa can have a conversation with an arbitrary device[0]. Trying to be rigid in definition for the scope of all IoT is madness[1], and imo this is where the future of the NLP AI is: acting as a fuzzy intermediary between people and 'smart' devices to save users and devs both from that madness.

[0] >send 10.10.10.143 'what are you'

>> "A light bulb serial number ######"

> 'list commands'

>> on() | off() | color(int red, int green, int blue) | strobe(frequency)

>help color

>>"""description of color function"""

etc.

Where there isn't a predefinition for say 'strobe' specced anywhere, or 'light bulb' for that matter, but a person or reasonably intelligent AI can work it out from context. There does need to be a bit of a framework and around 'what are you' and 'list commands' for this to work.

I hope I've explained this well, but it doesn't seem far off for an AI to credibly facilitate the bulk of human-smart device interaction with a little bit of help breaking the ice.

[1] As you mentioned, scoping even a light switch without feature creep is a challenge.

[rckoepke]

You'd want any interface like this to only be accessible over JTAG/serial in order to help prevent bad actors from recruiting the devices for Mirai-style botnets. Additionally, DNN NLP AI really isn't possible on these devices.

The ESP8266 microchip is very popular for use with consumer IoT, because it includes not only a microprocessor with full TCP/IP software stack included, but also WiFi hardware that's compatible with most consumer WiFi systems, all on a 5mm x 5mm x 1mm IC. However, it doesn't even have enough computation power to implement 802.11x WiFi certificate authentication for standard enterprise WiFi environments. There's no hope for implementing an NLP DNN AI on chips like this. You'd "need" to upgrade from a $2 microchip to a $100 IoT Edge AI chip like Coral or Jetson, and now each of your $30 IoT light switches would cost $130 instead and consume much more power.

You could instead have a pretty standard telnet access with 'help' functions like most *nix programs have, but enabling any kind of telnet/SSH is often a big security risk with IoT devices.

[adrianN]

You don't want any devices accessible over the normal internet. Set up a Tor Hidden Service, require some authentication at the bastion host to your internal network and you're good to go.

https://youtu.be/j2yT-0rmgDA

[moron4hire]

I've worked in the same space. This is bullshit crocodile tears. All of the device control protocols have systems for creating custom features. BLE is particularly easy to use, though it's really not that different from older specs like ZWave and ZigBee.

[btashton]

BLE mesh is difficult to do at high performance across multiple platforms and we did it years before there was a spec. Would I use the spec now? Probably. Would I have waited 3 years for the spec to come out? No.

At the time you could lock up Android devices just by sending too many beacons and require users to factory reset there network settings.

When people say Bluetooth is easy I assume they have not done much more than GATT connections and a simple beacon.

[nextaccountic]

Do you know what's the fix for this? Open source. And letting people flash their own firmware.