Hacker News Reader

Comment by ohazi | Hacker News Reader

Products like this make me furious.

Selling a product whose interface/API/whatever is deliberately obfuscated so that the manufacturer also has a monopoly on a subscription service or an app for said product is blatantly anti-consumer, anti-competitive, anti-environment, and should be illegal.

Fuck Peloton. Fuck Flywheel. Fuck all the proprietary IoT companies.

And apparently fuck me for having the gall to want to control my air conditioner from my computer rather than GE Android app #12 that has God-knows-what baked in and that's going to be abandoned in two years anyway.

Nobody should ever feel like they have to throw out an otherwise functional refrigerator-sized appliance because of software obsolescence.

I am absolutely willing to die on this hill. We need a GDPR-sized hammer to fix this.

View on HN

> Fuck Peloton. Fuck Flywheel. Fuck all the proprietary IoT companies.

And not just in the IoT field. Pretty much every company that could use their closed software/firmware/designs plus lawyers to enforce their right to render a product useless or obsolete, or simply becoming the only authorized to repair it then refuse the repair, so the user must buy a newer one, will eventually do that if allowed by the law.

John Deere has been really hostile to their customers, for example. https://www.vice.com/en_us/article/xykkkd/why-american-farme...

The legislation will probably originate somewhere there. At some point world should realize that software sales are not different from hardware sales.

John deere only made sense to me when I found out bill gates as it's largest shareholder

Don't forget Apple. They absolutely hate customers servicing the hardware they bought and paid for, and they fight it with both technology and lawyers.

Remember that awesome time when Apple disabled phones, because they had a 3rd party home button installed? Absolute scumbags.

I mean, it sure seems like a scumbag move, until you understand the full reasoning behind enforcing encrypted keys for each piece of security hardware. Which I believe was to close a security loophole.

To my memory the bricking of phones was a bug related to not handling the non-matching key condition correctly. But I believe they fixed that bug quickly?

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.

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

[0] https://home-assistant.io/

[1] https://esphome.io/

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

[0] https://en.wikipedia.org/wiki/Z-Wave

[1] https://www.theverge.com/2019/12/19/21029661/zwave-open-stan...

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.

This is a really good suggestion - my trust in that light is currently zero as I can’t get it to trigger reliably.

Solving that issue is a rather more obvious way forward. Wood, trees etc.

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.

[0] https://www.amazon.ca/Kerick-Valve-MA252-Float-Adjustable/dp... This was from a quick search, I know nothing about this particular valve.

Thanks. I’m going to get that light fixed and I think it is the best way of monitoring the water level.

The hard part with checking the water level is that the boiler is pressurised and very hot, which is going to be hard in any sensor.

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.

Will it do so even after going through whatever filtering scheme you're using? I was under the impression that clean water is a bad conductor.

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.

Thanks for the idea.

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.

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.

Hit me up if you need any advice!

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.

Thanks - I have tried to track one down here in New Zealand and found it hard. You are quite right that ESP8266s won't run long on battery.

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.

Home Assistant may be my favorite open source project. The community is great and incredibly active too.

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.

Could you make a regular old float sensor work?

HomeKit protocol is open and there are extensive documentation available.

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!"

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.

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.

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

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.

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.

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

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.

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.

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.

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

This vaguely sounds like MIDI to me

Or CSS extensions

Or SNMP MIBS

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.

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

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.

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

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!"

My condo building has these fancy new Technogym "MyRun" cardio machines which are basically regular workout machines with giant iPads on them. So now instead of turning them on and starting a workout I must wait 3 1/2 minutes for the touchscreen to boot every morning and every other week theres a failed software update causing the machine to shut down mid workout to restart the software in an endless loop. Or it just won't turn on due to the software on/off switch not working and we have to call the technician. It's unbelievably bad. Unless you actually care about connecting your workout to an app (i dont) a prehistoric cheap workout machine from 20 years ago has a better experience and is actually maintainable

>GE app #12 that's going to be abandoned in two years anyway

Not merely abandoned, but abandoned with gaping security flaws, no other way to update the device, and an always-on internet connection. We really have not thought this IOT stuff through.

Inevitably the long-term solution is going to be more layers of abstraction. Web application firewalls for every wifi device in your router, for example, or operating systems maintained by cloud vendors (for “edge devices”). If always transmitting connectivity isn’t required, maybe HomeKit-style app-based (offline or app-based updating) devices that use other devices as repeaters which can then be reverse engineered from their apps (largely illegally in many countries). I don’t think we’ll see open specs unless Apple or Google or government make a significant push, or a future large-scale chipset manufacturer uses open source as a way to both get customers and maintain long-term support for their chips. But we know how well GPL works with most hardware (poorly, unusably, etc.)

What worries me is not layers of abstraction, but layers of control. Who owns that WAF? Who owns the apps?

And if it's not user that owns it in practical (control) sense, then I hate it already and personally won't buy it.

Or, maybe the whole impetus behind the free software movement isn't wacko bullshit after all...

We had a solution and everyone pissed on it because the misinformed and perhaps intellectually lazy lawyers and leaders and yes even engineers convinced everyone that the GPL was unfit for a capitalist society.

“Was” is admittedly unfair because free software is not actually dead. It’s just popularly dead. If this type of crap actually outrages you, it’s not GDPR that we need (it makes no sense if you think about it, too), it’s smarter consumers and more courageous engineers/leaders. Go speak with your feet and use free software products. And help breath life into a culture that has been wounded by greed.

At the risk of repeating the "Stallman was right" meme, Stallman really was right about this stuff. The more I work in and with tech, the more I'm appreciating GNU/FSF philosophy.

Some time ago I finally understood what's the point of GPL vs. just Open Source - the former is written with end users in mind, not developers. And unfortunately, these days not only developers aren't end users, they're very often working against end users.

Yep. Permissive licenses (MIT et al) maximize freedom for developers. Copyleft licenses place sometimes-frustrating restrictions on developers in order to guarantee more freedom for end users. I like to compare it to laws against slavery. Yes, they impose restrictions on would-be owners, but society is freer as a result.

or any abuse of power imbalances.

> Yes, they impose restrictions on would-be owners, but society is freer as a result.

I'm still going to prefer MIT but this is probably the best rhetoric I've seen in favor of copyleft.

We need a free hardware movement.

Hardware is, in fact, exactly how the free software movement was born. Stallman couldn't service his Xerox copier due to proprietary software and license restrictions. Sound familiar? It has always been about combatting the artificial control companies have individually and collectively to dictate how users interact with hardware they own due to proprietary unfree software.

Convinced who, exactly?

Free software isn't illegal. You can run Linux and not buy IoT/IoS junk. Yes, you might have to decline Netflix and Disney.

The only place consumers are screwed is when they get stuck with monopolists like John Deere -- and no one got "convinced" there, just screwed.

Have you ever actually had a discussion about building and running a business around the free software model where you GPL all your software and charge for services? It just doesn't compute with most people who consider themselves leaders in the software industry. Stallman is just a crazy whacko and his license unfit for serious business. That's the summary of the stance I've encountered most of the time.

I'm simply saying people don't take the free software movement seriously and if you as consumer advocates and developers get frustrated by this fact you don't need to invent a "GDPR for software interoperability" you just need to advocate for software that protects consumers. And you need to do so even in the face of uneducated and uncultured business leaders, which takes courage.

Which part of the GPL being focused on end users don't you understand?

The GPL was not created to help businesses, it was created to help end users, which for the most part means people with the know-how to understand software and improve on it or extend it for themselves.

> app #12 that has God-knows-what baked in and that's going to be abandoned in two years anyway.

It was a revelation putting a Pihole on the network and making a firewall rule that forced any non-Pihole port 53 traffic back to the Pihole. Samsung and Google make a lot of connections to home.

HTTPS is great for users, but I'm annoyed that it will let companies get around this sort of thing. I want to control the traffic on my network.

That's why the combination of DoH and certificate pinning worries me - individually they're sound security technologies, but together, they're a nice package to disenfranchise end users with respect to networked devices they own.

One of the top reasons for DoH with cert pinning was to prevent DNS ad blocking with pihole on e.g. chromecasts

> And apparently fuck me for having the gall to want to control my air conditioner from my computer rather than GE Android app #12 that has God-knows-what baked in and that's going to be abandoned in two years anyway.

My aircon is infrared based so I bought a $20 infrared emitter, recorded all the button signals from the remote control and plugged it into HomeKit. Now I can voicecontrol/Remote control my antique aircon better than current models that still don’t support HomeKit

Bonus points: I put the emitter in line with both aircon and TV and use the same device to control both

Is it really that different than the razors-and-blades, inkjet printers, games consoles, or electric toothbrush business model? Or even the new cars and service model [wherein more money is made in the service bays than on the showroom floor].

I wasn't around on this planet when razors-and-blades model was first invented, but it wouldn't surprise me if people raised objections back then.

To me, the general model of selling/giving away a device that serves only to lock the customers into buying overpriced consumables is ethically questionable. I find it exploitative, dishonest, wasteful and anti-competitive. Such business model requires the corrupting the law to create completely artificial constraints, to make it illegal for competitors to offer said consumables, in order to prevent competitive pressure from pushing the price of consumables down to where it should be[0].

I can't give a detailed and coherent argument for why I feel that way, not just yet - part of the reason I comment in IoT/DRM/another-product-turned-into-bullshit-service threads is to try and discover that argument through discussion. But it really feels wrong, compared to a hypothetical reality where both the devices and their consumables were properly priced closer to the marginal cost of production, which can happen only if people can freely build on top of platforms.

[0] - And if I'm listing negative adjectives, I might add parasitic - in the sense that if you imagine business models as organisms, this one took over host society's legal system to ensure it could to outcompete more straightforward (honest) ones.

I don't think you need to expand so much on the reason why you're opposed to this business model, it's all understood and well-documented. The usual argument against this sentiment is that it's difficult to establish clear legislation on it. See the very similar debates on planned obsolescence and right to repair.

> Such business model requires the corrupting the law to create completely artificial constraints

So what? As long as no such laws exist that's fine, and a corrupt country will get bigger problems anyway. The problem is that it's not true since constructors can increasingly rely on complexity: reverse-engineering is getting more and more complex (see recent iPhones).

It has to be fixed through regulation. The free market does not support long term, expensive solutions, such as APIs.

If you provide the bike with a public API, it’s going to cost more. You now need to actually test the API works, instead of simply testing the bike works, end-to-end, with your own software.

A stable API with supported version changes and backwards compatibility is a much more challenging engineering prospect.

Forever ‘twas this. Maybe they can start by using something like an automotive CAN bus.

The scariest thing IMO is that this strategy seems to work for the seller. (Besides John Deere oweners and the HN crowd) How many consumers are protesting this kind of nonsense? I would bet most are dazzled by the prospect of some "futuristic" product feature.

To me, this stuff actually devalues the product. It has the potential to be useful but the way it is being used is to deny the buyer full ownership and reserve additional rights for the seller.

I just return stuff.

I bought a segway mini years ago, only to find out you had to download an app before you could ride it.

Same with with a DJI mavic quadcopter.. you could not just turn it on and fly it with the included RC remote controller - it would just say "see app" or some nonsense.

both got sent back. Seemed a little silly at the moment (I just got this cool new thing -- cave.. cave..) but I'm way better off.

(turns out the mavic sends details of EVERYTHING to lots of sites willy-nilly)

The bike is not even close to being bricked. You can use it without the app, there are multiple replacement apps; both a free version from the same vendor, a equvalent subscription from the new owner and some other third party apps.

Otherwise yes, agree that subscription dependent IoT needs regulation.

One issue with open interfaces for these kinds of applications is BT-LE itself. It is nominally designed as open standard for transferring exactly this kind of data, but it cannot do anything else than SNMP-like get/put/trap on some attribute, so everybody ends up designing their own proprietary L4 TCP-like protocol on top of attribute writes and reads to accomplish anything interesting.

Most "smart" devices don't need anything beyond attributes, heck, some of them (thermometers and the like) could just fit all the data into a beacon advertisement!

Manufacturers often do really silly things like encoding all the data into one custom attribute:

https://github.com/open-homeautomation/miflora/blob/31e59bdb...

All of this easily could've been done with standardized attributes but fuck interoperability lol.

> it cannot do anything else than SNMP-like get/put/trap on some attribute

It can do whatever you want. Nobody is forcing you to use ATT, you can speak anything over L2CAP.

This twitter account is well aligned to this sentiment, proof included: https://twitter.com/internetofshit

>And apparently fuck me for having the gall to want to control my air conditioner from my computer rather than GE Android app #12 that has God-knows-what baked in and that's going to be abandoned in two years anyway.

Do you have IR controller for your AC ? If so you could get one of those smart plugs that you can control remotely (zigbee, wifi service, whatever) and it will communicate with your AC via IR, you plug it in to the AC socket and then plug AC into it.

I'm looking into mini splits for an apartment and project room I'm building in my shop. I really like the Mitsubishi ones partly because they have a documented port to connect to them and people have already written code and schematics. Unfortunately, they are twice the price of the cheap ones that only have a proprietary wifi dongle that I'd have to reverse engineer myself.

Get the Mitsubishi Super Inverter. Not because of the wifi (mine does not have that option), but because it's a really good product.

I have one running for the last 6 years and I always say that it was the best purchase of an electrical appliance I ever made.

Super quiet also, my model is around 19dB inside and the outside unit is also quiet.

And to think I‘m used to make fun of RMS for complaining about how he wanted to run his own software on his microwave.

Agreed. Right to repair, which I believe includes software should become law. I have a pile of bricked stuff, mostly electronics that I can't use (hello Pebble Watch). I hesitate to buy "connected" products unless they are open (e.g. Z-wave switches), never proprietary stuff!

Just wait until you here about this company called Tesla that is paving the way for “your car is an IoT subscription”. Oh yeah and this company called John Deere with their subscription model for their DMCA protected tractor that you “own”.

I might even take it a step further and say no product should be rendered unusable without an Internet connection unless the Internet is an absolute requirement of the product’s basic function. I.e even IoT devices ought to be able to be air-gapped and on their own closed network (unless, for instance, it’s a clock or something and relies specifically on things like weather/traffic APIs). And even in cases where there is a legitimate product feature that requires an internet connection, not having one should NOT render the other parts of that product unusable.

trying to dig into the root of this frustration, i think it mostly stems from the misalignment for how we expect the internet to behave (open, accessible, all the other fun Tim BL stuff, etc). it’s extremely unfortunate that companies like peloton, john deere, skydio, on some level DJI, and others as we cross software into the real world haven’t kept up with those expectations. huge loss, and concerning behavior as the internet starts to expand further IRL.

> I am absolutely willing to die on this hill. We need a GDPR-sized hammer to fix this.

Any thoughts on a labelling system? Like, "re-flashable open source firmware", "cannot be remotely bricked", "API-spec and code examples included" stuck on the side of the box.

I'm surprised some hardware hacker supply company, like adafruit/sparkfun hasn't gotten on this yet.

Relevant to your interests: https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-...

Just like the wink hub. They recently switched from free always to we now need 60 bucks a year from you. Talk about bait and switch.

Hey, we both know the answer - you don't need fancy app to be fit on your bike. Neither for making sense from your aircon.

I agree with your points, but in this case it was not obfuscated at all and as the article shows, not really difficult to figure out. Furthermore, this knowledge can now be shared with others.

As long as RE is legal (and even when it isn't...), people will figure things out.

We need a GDPR-sized hammer to fix this.

AFAIK, RE for interoperability (which this is absolutely an instance of) has always been and is likely to remain legal in the EU.

As pointed out upthread, we’re increasingly seeing devices that never get reversed.

Even many of the really popular ones take years to hack these days, because the mitigations keep getting stronger.

I would like to see a "Right to Repair" for software.

Any FOSS or Commons Clause software fits the bill.

Or are you saying you would like to see Right to repair legislation for software? Me too, but it won't happen.

The latter

What does the GDPR-sized solution look like?

Maybe "every IoT vendor must put their source code in escrow and when they go out of business the source code becomes GPL"? Of course they could just escrow incomplete software with parts just being sourceless blobs and no-one would have verified it is complete by the time they go out of business. It also doesn't work when they buy proprietary software bits from other companies.

Generally yeah, fuck'em all. There are however cases when playing with the device using 3rd party software could lead to bypassing safety features and if people got hurt who is to answer?

"Freedom is not worth having if it doesn't include the freedom to make mistakes."

The person who bypassed safety features, or insurance coverage.

Reply on news.ycombinator.com