Wouldn't it be great if a universal standard existed for devices sending their diagnosis via audio?
If there is a microcontroller and a beeper in there anyway, at only the extra cost of internal memory? Instead of a modem-type modulation and a speaker, make use of the bare minimum piezo beepers and send something that is universally understood? All of that without FCC, no extra hardware cost, no backchannel und thus little security considerations?
Yea - I know. Works much better to upsell "wifi enabled" and I'm happy that the appliances only beep rarely.
That reminds me of another thing I wish was a universal standard for major appliances.
I’d like to see them all have a USB port. If you plug in a thumb drive the appliance should create a directory named with the appliance manufacturer and model and serial number. In that directory it should place a copy of its manual and other documents that normally come with it.
...or just have device side usb port that shows up as a mass storage device?
That would be pretty inconvenient for appliances in places that are hard to reach with a computer, but definitely an improvement over the status quo.
An appliance could just have blutooth so it can connect to an app on your phone. With the machine not having a direct internet connection, the app can collect diagnostics, metrics and do software updates. Require you to press a button in the machine to pair it to your phone.
99% of the functionality with 0 annoyance and ~0 security/privacy risks.
But that still requires installing their app on a mobile device, and that app will still have invasive access to data and internet, etc. If we have to have an "app" I'd much rather it be a built-in web server (despite the inevitable security decay) that serves up a local-only web interface. Best scenario though is to just give me hardware controls and a simple display :-)
Apps require permissions and they can't just sniff the network willy nilly. Any IoT device on your network has way more access to privacy-related things than apps.
Why ?! Audio diagnostic is passive and (I suppose/hope) associated with a button (?).
Can we stop putting obligatory (hackable) active network devices everywhere ?
For basic diagnostics that is enough, but if you want to do more data-intensive stuff (including software updates) you need something more.
Yes! I've been thinking about bluetooth and a standard protocol and generic app. You'd get basic gui functionality for any compliant device, showing whatever device specific stuff the manufacturer wants.
Kinda of like a bluetooth X-terminal, but way way simpler. Think tkinter over bluetooth, probably sans canvas.
A bunch of people will say to just use wifi, make the device a Hotspot, and use your web browser. That's not a bad idea, but tiny devices aren't going to run web servers dishing out multi megabits frameworks.
> I've been thinking about bluetooth and a standard protocol and generic app.
A long time ago I developed a project called "Handbag[0] for Android"[1] based around a similar concept--it targeted the short-lived "Android Open Accessory Protocol" initially over USB & later also over network/WiFi.
(My project notes from the time mentioned a long-term goal of also supporting Bluetooth but that never eventuated...)
Handbag made use of a "generic" Android app for UI display/interaction and an Arduino library that communicated with the app over a binary protocol.
The app would display various UI widgets such as labels/progress bars to display feedback from the accessory and text inputs/buttons to accept input forwarded to the accessory.
While the project did not take the world by storm, I was reminded when digging up these links that at least one person called the concept genius[2]. :)
----
[0] Because it let you "accessorize your Android phone or tablet". :D
[1] https://web.archive.org/web/20130205135845/http://handbagdev...
[2] https://www.doctormonk.com/2011/11/handbag-android-and-ardui...
If you afford a bluetooth chip you can definitely definitely afford a CPU that can push 2-5mb HTML files through it in reasonable time (you can pre-gzip it) and some flash storage (which you probably already need if you are any kind of metrics over time).
It could be hard to encode JSON messages dynamically for the actual data to show in the web application, but you _can_ use other protocols from a browser too (CBOR is quite popular for this).
>> If you afford a bluetooth chip you can definitely definitely afford a CPU that can push 2-5mb HTML files through it in reasonable time
Maybe not. I'm using a micro controller with specific peripherals and ADC requirements for a high speed control system. This has less RAM and flash that you can probably get away with for a web server. We'd have to add a bluetooth radio chip, but I hear those go for well under $1. There are all kinds of embedded devices that have few resources but could be expanded with cheap Bluetooth connectivity. I realize this is changing quickly, but there will always be very small devices.
Yes running a full blown web server with HTTP support requires a bigger CPU and RAM, but don't need a lot of RAM or CPU to stream an HTLM file through blutooth from flash storage. Serving data over blutooth for that HTML application would need some custom stuff (because it would go over blutooth and JSON-encoding for messages would probably require too many resources). My point is that it is definitely possible to serve a HTML file over blutooth, render it in a app through an WebView and have the app communicate to the device over blutooth without putting a beefy CPU in there.
The product I worked on the bluetooth chip was more expensive than the CPU if memory serves me right and we did something similar. But I am not a board designer or procurement expert.
Or flashing led and use mobile phone camera to scan it.
Back in the days infrared connection was a thing. I remember connecting my Compaq iPAQ PDA to Nokia phone.
Wonder if the modern cellphone cameras are fast enough to act as receiver and if this supported one way communication.
> Or flashing led and use mobile phone camera to scan it
Miele uses flashing LED as some sort of serial communication.
How about a wifi feature that is useful on a LAN and doesn't need 'the cloud'? The annoying part of wifi appliances is that network connectivity almost always means phoning home to some server on WAN. Home routers or a separate box on LAN ought to have functionality to be the bridge between appliances and client devices instead. That's a standard I'd rather see.
Because most people don't have anything on the LAN that can integrate with the appliance, and with just a phone app and the appliance, you're limited in computing power, background activity and storage (you can't store all usage data on the machine itself, and you can't rely on the phone always being on the same wifi to collect the data and store it).
"you can't store all usage data on the machine itself"
I can buy 128M flash for $2/10k
> Yea - I know. Works much better to upsell "wifi enabled"
A good marketer could give a catchy name to sell the advantages of that system too. Top of my head I can think of "near-fi", but certainly could be done better.
"Spyware and asbestos free"
Spyware, and asbestos free!
("Sugar, Free Donuts" - The Simpsons)
D'oh! I realize now, I should have wrote it as:
Spyware and asbestos, free!
This reminds me that Fischer & washing machines have an Easter egg where they can use that beeper to play God Defend New Zealand.
Or just codes that you can look up. Most washers have a small LCD screen capable of displaying two digits.
> Wouldn't it be great if a universal standard existed for devices sending their diagnosis via audio?
LG must have some internal standard for this feature. If they would just publish it and then that could be the standard.
Edit: to the downvotetards, if you worked in actual engineering like I do, then you would understand that this is how most standards naturally materialize. Someone does one thing particularly well, it becomes the standard.
No, that might be the beginning of the standard, because once it's published you realize they don't have a version number or vendor ID or any way to add fields other than the ones they hard coded or whatnot. But it's a start and it would be great if they did it!