Its a pretty good hill to die on. Everything IOT should be forced to communicate over transparent and self-documenting protocols so a. anyone can write an app to control said device and b.[0] Alexa/Cortana/Siri can query to set up a voice control interface.
[0] Maybe in the future when their capabilities get a bit better, but the gist is every device should respond to a 'hello' ping with a list of commands and NLP'able descriptions such that for an air conditioner 'alexa set temp 67 degrees F' just works.
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.
> 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.
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.
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.
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.
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.
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.
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”.
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.
> 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.
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.
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.
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.
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.
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.
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.
Years ago, there was Jini (Apache River now). It never gained much traction. But I always liked the idea of interoprable home devices announcing themselves on my network. "Hi, I'm a mass storage device. If anyone's got data they need storing, send it my way!"
HomeKit is probably the closest thing at the moment as, while it's a proprietary protocol, it's already been mostly-reverse-engineered enough to have open-source HomeKit controllers for most devices, as well as open-source bridges from non-HomeKit devices to HomeKit protocols.
Home Assistant[0] is a great tool to act as this bridge. It can act as a HomeKit device, so anything it knows about can be exposed to Apple devices via the Home app. It also has integrations to talk to virtually anything, or you can build your own IoT devices with ESPHome[1].
So much this - ESPHome is incredible. The next amazing bit is how good a system you can cook up with some low cost ESP8266 or ESP32 chips and a few sensors.
I’ve been looking for ages for a decent thermometer that connects to Home Assistant. All were expensive and required all sorts of contortions to get into HA. A week or two ago I bought some US$6 chips and a few US$3 sensors and they had me there in short order. I have no electronics background and very little coding experience.
If you want to take this kind of thing to the next level, check out Node-RED. It's a visual programming environment that's well-suited for home automation.
One of my most-used automation setups is a dust collection fat near the cat litter boxes. The basic idea is to turn the fan off, if it's on, when the cats approach, then turn it on five minutes after they leave and turn it off ten minutes later. The cats are detected using a PIR sensor hooked to an ESP8266 running ESPHome. I've also got an automation which will turn the fan on and ignore the PIR sensor for ten minutes so that I can clean the litter without breathing in a bunch of dust - this part is kicked off via an input_boolean that's exposed to HomeKit, so I can tell Siri to turn it on and it triggers a whole bunch of work.
The main thing that prevents me from DIY IoT is worry about fire hazard. Is there a guide out there for picking right components (e.g. are Sonoff devices solid enough) and assembling them in a way they could be safely plugged to mains, or used to switch mains power? Alternatively, are there guides on how to build battery-powered IoT? I'd be fine powering stuff around home from rechargable AAs if I had a clue on how to build IoT devices like that (IANAEE).
Yeah, I would not suggest DIY'ing anything that's directly connected to mains power unless you are super sure you know what you are doing. That's a really good way to cause you problems with your homeowner's insurance if you have a fire and it could be against your local building codes.
That said, there are devices out there that can be used on mains power that are UL certified. I have a ton of Z-Wave [0] switches and relays for various things all talking to Home Assistant. Z-Wave is an open [1] (or soon to be open) mesh networking communications protocol that is pretty widely used and supported, so you're not locked into a single vendor.
For low-power stuff, I'm a bit more willing to experiment, but not on mains power. But I am also not an EE. :P
For powering my ESP32/ESP8266 stuff, I use "trustworthy" USB power supplies (e.g., stuff from a brick-and-mortar store, or leftover iPhone adapters, not random Aliexpress adapters) and use short USB cables to connect them. Costco usually has some kind of appropriate adapter for a reasonable price.
For controlling 110V loads, I've found that the Ikea TRÅDFRI outlets work well. If you stay within the TRÅDFRI ecosystem, you need a "steering device" such as a switch or remote to pair them to the gateway, but if you're willing to step outside that ecosystem Zigbee adapters like the ConBee II can talk to the outlets directly (I'm in the process of migrating my Ikea gear to this). The Home Assistant TRÅDFRI component works well.
I use USB chargers/hubs for anything I build myself, and Sonoff plugs (even better if they're the kind you don't need to splice into wires) for anything that needs to control mains. This approach has worked excellently so far.
So far my chips are all sensors powered off USB. Adding relays is next level and I haven't done that.
I've relied on smart plugs that are wall-wart style.
However I want to refill the boiler automatically on an old La Cimbali Junior and when I find an ultrasound sensor that will penetrate my espresso machine's boiler and detect a low water level (risking element burn out) I likely will though. I've tried a Hall sensor and one ultrasound sensor and neither work. I think I need an ultrasound sensor designed for fuel tanks or similar.
A quick look at the manual suggests that there's a light that tells you when it needs to be filled with water. It might be easier to just trace that back and piggy back off of whatever sensor it already has.
It may be too small for an ultrasonic sensor to work well. The ultrasonic sensors I've used are all basically blind to anything closer than 5-10cm.
If your goal is just to fill the reservoir automatically from a plumbed-in water source, without monitoring/logging water levels, a small float valve like this[0] might be a good answer too. I don't know how big the reservoir in your machine is, nor do I know if this particular valve is food-safe.
You should definitely fix that light though. That sensor may also be part of a safety cutoff to prevent burning out the element.
You probably don’t need an ultrasound sensor or anything fancy for detecting water levels. Get a couple of strips of conductive metal which isn’t going to rust, then stick them down either side of the water tank, and finally hook the top of those strips into an ESP8266 or similar. When water level is above the required point the water will complete the circuit, and when it drops below the circuit will be broken.
There are two water levels that could be monitored, the stainless reservoir and the brass boiler. Despite the metal I think it would still work for the reservoir, because this seems to be how new models work.
It’s the boiler I mainly want to monitor however, and it is very hot and is pressurised.
I had no idea about that, but some cursory Googling seems to indicate this property is only really true of fully purified water - either via distillation or turning it into steam first. I suspect that all but the most impressive water filters are still going to give you conductive water, but regardless it’s an easy thing to test.
Xiaomi makes a $10 BLE temperature and humidity sensor. You don’t have to use their proprietary app, there’s an open source MQTT bridge available. It also has a display and runs for months from an AAA cell, which anything esp8266 based won’t.
They won’t run long on battery if you try to run them constantly. This is why they support deep sleep, which allows you to instruct it to shutdown until an interrupt is fired by either the real-time clock, or some other input. Typical behaviour for a device like a temperature sensor is to wake up, report the temperature, and then go back to sleep either for a set duration or until a significant change in temperature is reported by some lower power components.
Thank you - I’ve been playing with this and it’s really neat. It’s an amusing workflow in ESPHome as you have to work out when the device is awake to run an OTA update.
I have been really happy with a HomeBridge and HomeKit setup. The only downside is the eventual hardware: for various boring reasons I was forced into getting Lutron smart light switches, and they require a hub. That hub has a Telnet connection that Home Assistant uses and it’s super flakey.
I just wish there was more truly open hardware out there.
Web. A self documenting protocol is it runs a webserver that accepts simple form requests.
"But web tech is insecure!"
If they can't secure a form post, what hope do they have of securing a proprietary api?
Yes, home appliances running webservers would have downsides for management, but that's where routers could add value. It would be trivial for a router to scan port 80 of every device on your network and present a page to pick your devices. That's something I'd even use an app for.
"Port 80? But what about encryption you complete monster!"
How the hell is that cert going to work? Even if they had some magical way to store a cert on the device securely, surely they're going to screw up keeping it up-to-date, or do you want your "it's MY device! Mine!" to depend on an external provider for security?
Just make sure the devices can run on some kind of VPN.
Router can keep them on a VPN and run a proxy with proper SSL for outsiders. Then you only need one device in your network secured to modern standards, all your IoT run in the router's IoT sandbox and all access to them is through a proper SSL-encrypted proxy portal.
There. It would be possible to make that layman-friendly infrastructure. Router detects you connecting to LAN device over port 80 and says "hey, this looks insecure, do you want to move this device to the secure sandbox? You can access all IoT devices securely through my app! Y/N/OMG this is awful never ask me again!"
[0] Maybe in the future when their capabilities get a bit better, but the gist is every device should respond to a 'hello' ping with a list of commands and NLP'able descriptions such that for an air conditioner 'alexa set temp 67 degrees F' just works.