While it's utterly true these features will simply get abandoned by the manufacturer, people seem to discount how hard (read: expensive) it is to develop local-first software, especially the one you want to just work with a mobile app that might or might not be on the same local network or subnet (try explaining that bit to your regular Bosch customer).
Since we are, ultimately, such a minority, I am sure that not even returning the product would make the manufacturer understand that this is — really — unacceptable. The only way we can get this "fixed" is by mandating open APIs for local use by regulators, when we'll see the proliferation of custom apps.
Why make it work with a mobile app at all? How is that even a convenience? This is an appliance you need to be physically present at to load and unload.
No disagreement there, but once you are set on a mobile app, you are going to push for it to be used.
It all probably starts benign: let's push some notifications to customer's phones (already requires a server — ahem, a cloud — and a mobile app).
Then smart product managers realize that the app is not used by anyone, and they start thinking about "value add" with the app, and quickly, you are looking at removing things from the physical unit and putting them only in software.
A PM next: look, this release has increased usage of the app 10x!
Instead of them just doing the right thing and nixing the app — but who'd advocate for cutting their own job?
I could see a remote notification that it finished being useful. That said, the manufacturers would never go for this, but a dry contact for a GPO that is asserted on the machine finishing is likely all a number of people here would ever need/want.
How complicated of software does one need in a dishwasher? Feels like a solution looking for a problem
How do I use Home Assistant to run my dish washer, charge my electric car, start my washing machine, etc based on the capacity of my solar array's battery and the fluctuation of electricity prices day to day to pay the least amount of money without software connectivity? All of this is possible today with the right hardware.
It does NOT need cloud connectivity and all of these devices should be able to communicate locally to a matter or zigbee hub or over Wi-Fi without Internet directly to my server. That is the actual problem. We should not let corporate greed stifle innovation by saying new features are pointless because a company then can try to exploit it for further profit.
I agree that's the goal we as a community should steer to.
But on how we do that, my opinion seems to differ.
I postulate that it's hard (expensive) to do what you suggest: finding people to build that for every customer, while not increasing support costs is tricky today.
Just ensuring your personal computing device (a phone, laptop or server running home assistant) can see and talk to your device is a hard problem (which is why the go to solution is poke a hole in your router fw by pushing data to a server, and have mobile app only talk to the cloud).
Can we, as a software development community, come up with an approach that makes this easy to do for local first but remote enabled?
The "software development community" isn't going to do shit, quite frankly, as long as bean counters rule the world. The businesses will keep hardening their equipment (or paying someone to do it poorly), and they'll threaten to sue anyone who attempts to free the hardware.
Some things that are already wildly out of control cannot be fixed from within. We can only hope that regulation and government influence could stop the waterfall. Or, a good old fashioned tea party (if that would even have the slightest effect nowadays).
Obviously they aren't, as long as they are not even willing to acknowledge that developing local-first while also supporting mobile app use outside the homes _is_ more expensive. And obviously, "bean counters" are not going to invest in doing the more expensive thing when the cheaper one "works" (we all disagree with that, but these products continue selling in the market).
So I think it's either increased government regulation, or IT crowd working to simplify development of local-first/mobile-supported applications for any type of a connected device and client. I don't really think this will come from a community, but a push to standardize on a couple of protocols, API formats, how apps can talk to the same API locally and over the internet and such — those are things that could really be done once (or at most a couple dozen times, for everyone's favourite framework and language :)), and then there won't be an "expensive" excuse for companies.
Or, rules can mandate that, when it will become cheaper because companies will join together to bring the price down (like they did with Matter).
Now that I could totally get behind. Built in Matter/Zigbee/Z-Wave radio would be amazing! Might actually make it halfway 'smart'.
Or phrased another way, if local first software is so difficult why are we doing it at all when these devices worked BEFORE they had software.
The worst washing machine I've ever had is my current one, and it isn't even a "smart" appliance. It has just enough software to be worse than my one with dials for everything.
They have had software for decades. They were run by microcontrollers. The only difference is that it was an embedded system with no network capabilities.
And they switched from tactile controls to touch-sensitive buttons.
That's the oppression of the "sleek": touch-sensitive buttons are worse in every way except that they allow for "flatter" design.
At least we are seeing actual, tactile buttons start their return in cars!
people seem to discount how hard (read: expensive) it is to develop local-first software
How hard and how expensive is it? It used to just be called "software" for four decades and literally everything was made this way up until a few years ago so I think the evidence is against you on this one.
It was made for different use cases.
Nobody had a personal computing device in their pocket 90% of their awake time.
Now the goal for product department is to make their newly "smart" devices accessible to said computing devices.
The simplest solution that (almost) always works on home networks is to initiate an outgoing connection to an external server (the "cloud"), push notifications and poll for commands; after, have the mobile app only talk to the server.
If you do anything else, you are at the very least setting yourself up for support nightmare: "I am at home and I can't access my washer through the app" (are you on the same network? maybe your phone has wifi turned off?)
For usecases of the sort, this is one general solution that — from the perspective of a PM — always works.
By simply discounting reality that it's more expensive to implement both locally accessible smart devices, yet keep remote capability, and discounting that support costs are going to balloon too, we are not driving to a positive outcome for all of ourselves either.
I think we should focus on getting the cost down, by building better tooling and protocols and patterns that make it easy for a mobile app (or any client) to discover and talk to any smart device, making it simple for a customer to decide if they want remote capability or not.