Hacker News Reader

Comment by DanielHB | Hacker News Reader

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.

View on HN

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.

apps can stop being supported by new devices if not updated

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.

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.

> 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...

Reply on news.ycombinator.com