Hacker News new | ask | show | jobs
by yetihehe 672 days ago
>The owner of the panels and inverters can meanwhile establish a connection with that manufacturer using an app or website, and via the manufacturer see how their own panels are doing

> It wasn’t necessary from a technical standpoint to let everything run through the manufacturer’s servers, but it was chosen to do it this way.

(emphasis from article)

I'm working on IoT cloud system. It was chosen to be done this way because netither consumers nor installers have any expertise whatsoever to setup their own network or any devices to be acessible from outside (and they want their panels to be accessible when they are outside their home). I can do it, most readers of HN could do it, but typical consumer or installer can't. Sad but true.

12 comments

The cloud can operate as a dumb TURN relay relaying E2E-encrypted traffic. Then the worst the cloud can do is deny service to remote management (and even then, local management would still work), but it wouldn't be able to send direct control commands to the equipment since they don't have the authentication nor encryption keys.

This also makes it simpler from a programming point of view - instead of having separate cloud sync & local control protocols, you just have one local protocol and you merely tunnel it through the (dumb) cloud if you can't connect directly.

It could, but this requires to store historical data about usage on devices. If you store that encrypted data in cloud, then getting it to your mobile phone is super slow. If you store it in cloud, you can get historical data even if your device is dead or has 256 BYTES of memory and 1 megabit of flash storage. We have such devices, very effective at managing local municipal heating network and controlling several thermal controllers each via rs232 or rs485. Fortunately we preemptively moved everything into VPN'ed mobile network, we need special approval to touch anything on that network and can't connect without them granting access, so after EU started moving with cybersecurity this year, we are covered.

> This also makes it simpler from a programming point of view - instead of having separate cloud sync & local control protocols, you just have one local protocol and you merely tunnel it through the (dumb) cloud if you can't connect directly.

Having only cloud protocol is even simpler, I've done all of the above (I do backend and our firmwares).

> we preemptively moved everything into VPN'ed mobile network

Unless your device itself is handling the VPN, I have bad news for you if you trust the mobile network to not open your devices up to malicious attackers: https://berthub.eu/articles/posts/5g-elephant-in-the-room/

We consider "they hacked the mobile network VPN's AND had time to reverse our protocol before being booted out of network" as too high a level to be resolved by us. If someone has enough resources to do this, he will also just hack into standard-level secured server at municipal office and there will probably be no one there to stop him or discover what went wrong.
reversing the protocol can be done in advance, if they order your product
Do you at least fuzz your software?
I don't think E2E is simpler to program if you want to get it right. There are entire companies whose raison d'être is actually managing keys properly (e.g. Signal, Tailscale).
This should be the basic model. A fully third party TURN service. You pay $20/mo to keep your home connected, and all devices and providers can use a standard protocol, and users remain fully in control of their data.
These plants or farms are usually built around and on top of industrial IEC protocols and SCADA controllers which is a lot more low level than what any cloud IoT privider offers.

I have done a controller for a 40 foot container battery and it wasn't like we received any API from Hitachi (battery manufactor). We had to write everything ourselves.

What's the reasoning for not allowing both control paths, via cloud but also locally? So that people who can and want to, will use the local control.
Often there are two control paths. Sometimes more! Plenty of inverters will quite happily give you an RS232 port specification and you can create your own dongle!

However, for purpose of the security of the nation's power grid, I don't just need my inverter to be secure, I need pretty much everyone's inverter to be secure. If an attack bricks 95% of solar inverters, the fact the nerdiest 5% of users have their inverters airgapped won't stop the grid having a lot of problems.

> RS232 port specification and you can create your own dongle!

This is just a way of pretending to give access while making it as hard as possible. We are talking about a device that is already connected to the network. The local path is not some rest services, but a serial port for which I need to fabricate some hardware? Don't piss on me and tell me it's raining.

Perhaps I wasn't clear - when I say "Sometimes more!" I mean many cheap chinese inverters actually support four options:

1. Cloud management with their app.

2. Wifi management without the cloud (when you're on your home wifi).

3. Unplug the wifi dongle from the inverter for a fully offline system. You don't really need your inverter on the internet anyway.

4. Unplug the wifi dongle and DIY whatever you want, the dongle's just a serial-to-wifi converter.

That's not to say the security of any of this stuff is good, of course. In fact the security is pretty bad! But you can for sure get inverters with multiple options for non-cloud operation.

The real answer is it's more than twice the work to have both paths, and there's not enough demand for it.

That said, Apple Homekit integration is local network based, so products that do that and the typical manufacturer cloud system have done both paths.

Homekit is a pain to use without Apple hardware/software, but there you go. (There's a plugin for HomeAssistant, but I'm still classifying that as a pain)

I have a weather station.

It can connect to standard cloud weather service providers and I can view my data there.

I can also just redirect that exact same protocol to any other host or IP I specify.

They built it once and just gave me the ability to control WHERE that data goes. It's honestly not that hard.

Cheapness. It would require to be at least semi secure, application on phone would need to find those devices locally and it should be synchronized with cloud anyway, synchronization is error prone and we had problems with devices sometimes responding twice or very slowly through local interface (through cloud was much faster, no idea why, not our firmware). Also not enough people requesting that feature, most don't care and think that losing internet is not often enough to warrant worrying about this.
Why not offer an either/or rather than both? Some people (I am one of them) actively do not want these kinds of things to be managed through the cloud servers. I don't want it to sync, I want to fully turn that off. I want to locally host, and I'm willing to take responsibility for that feature, including when it breaks. All I want is access to whatever the data reporting and control APIs are.

I get that I'm a tiny minority, and that very few customers want what I want. But A) it seems like giving me what I want should be very cheap (i.e should not entail ongoing customer support costs beyond normal, and in fact would get rid of the small cloud hosting cost) and B) I'd be willing to pay a premium to get it.

In some areas like cameras there are a decent number of cloud-free alternatives. Hopefully as the IOT market grows we'll get cloud-free versions of everything.

I think you're too optimistic about costs though. Providing any support at all, even one-time during the install, is expensive and cloud-free IOT is going to require support due to home networks being broken.

Yes, support is expensive, but what I am proposing will, if anything, reduce support. I'm imagining something where, if I opt into local control, I am giving up all rights to any support that is not related to the core functionality of the device. For example the solar panels/inverters in the article. If I opt in to local control, then the only support I am entitled to is the solar panels stop generating power or if the inverter stops inverting. Anything that is network related is no longer the companies problem, because I have assumed complete responsibility for that. I'd even be willing to agree that, in the case that I ever decide I don't want local control, and I want to switch to the cloud hosting, that I will pay for the support required to switch me back over.

So if my home network breaks, that is not their problem. And they don't need to set it up, they just need to make it possible for me to set up, including figuring out how to make it work with my potentially broken home network. If it requires a new router because mine doesn't provide some necessary functionality? Not their problem. Etc. Etc.

Consumer electronics doesn't work that way. If people can't get a product to work they will return it to the retailer and when the retailer gets a lot of returns they will penalize the company or drop them completely.
> So if my home network breaks, that is not their problem.

Differentiating between people like you, who can take blame for misconfiguring device and 99% of other consumers is not viable for most companies. Also, if you bought our device and wanted to do that, I would probably make a firmware version for you that connects to your endpoint and give you some docs. But:

- Just talking and coordinating that possibility for one user would cost my company more than the final price of device, when considering time spent on this.

- You would have to spend a lot of time to implement a lot of functionality to glue our protocol to your desired endpoint.

I have some shelly devices which manage to do all that, and cost next to nothing. Work with local rest services or cloud, password protection, TLS. Sure, it costs more than zero, but not much.

In the end, freedom goes away because we could not be arsed to ask for it at least, let alone fight.

OK, so key question: why is there a control plane in there at all?

I can understand people wanting to be able to see the metering live, but remote control of the panels just seems like a security incident waiting to happen. I'm quite glad I have a non-internet-connected inverter.

For IoT stuff in general; I can do it, and I don't want to because I'd rather spend my time doing other things (although yeah, I totally did learn everything I could about my solar array, because it is a source of power, after all. But for the other stuff...)
I agree, and I wish it were otherwise. Why is it so difficult for me to have a home network where things can just work? Why is it a mess of configuration and self signed certificates? It seems like nobody is incentivised to provide this, because nobody providing me with devices, services, and so on lives in my house with me. They need my data and my control pathways to go via them, not to stay in my house.
Also administering a bunch of IOT systems is a pain. If something is an open source community project, ok, I’ll play. If somebody is selling a product they are responsible for making sure it works.
You could put an sql database on a local device and just access it remotely like anything else. But you are correct you're stuck with administering each and everyone one of them.

The standard go to a raz pi solution will up and die every few months. And half the time you'll need physical access to get it back. It takes a lot of work to develop an embedded system that has enough reliability.

If we've learned anything from the security cam and baby cam scandals, then it's that convenience is king and we as a society would rather risk everything than be arsed to take few additional steps to setup/learn something to prevent such basic breaches. We (the society) don't even want to change the default password on most things.
People gonna be people. It's up to engineers and product designers to make things user friendly but also safe-by-default. If something needs to be configured, then provide instructions on how to configure it. Instead of pretending that it's society's fault (can't be arsed), maybe ask why the IT industry can't make instructions that are written out--explicit, fairly standard, and easy to follow--like the manual for putting together a piece of furniture. Or why the stupid device doesn't come with a randomly-generated strong password taped to it.
> fairly standard, and easy to follow--like the manual for putting together a piece of furniture.

And people still have problems following that instructions. We gave a lot of instructions, but some people just don't read them. Or can't understand and follow them. Example from this week:

Yeah, main support guy for our client is on holidays this week and only a girl from sales is available and she doesn't know why our device doesn't work, she tried resetting her phone wifi but still can't pair our zigbee smart hub connected with usb modem stick (problem: no one told her she needs to message us to actually activate sim card before installing device for end client).

Yes, you can solve this one problem, but there are many more we didn't see yet. Consumer support does not scale and you can't write tests for something you don't know will be a problem.

> no one told her she needs to message us

Did you have that written down somewhere? In instructions, which was my point.

Sorry for the snark, but I think "no one knows how to do anything" coupled with "Oh, the idiot didn't know to discombulate the canooter valve before inserting into the tinklerater--it's so obvious we didn't write it down" supports the point I'm making.

This was custom configuration process tailored specifically for that one client and it was written in a detailed instruction with each step tested and with screenshots. Apparently that instruction was not distributed internally at our client office. So mere existence of instructions is not often enough, you will still get very confusing calls about how to attach toaster to 36V to charge a wallet (when you did not send any toasters or wallets and client just wants your premade pizza).
So yes I sympathize that people didn't read the instructions, but I feel that that is partly out of habit that said instructions don't exist. We could work towards a better status quo where the configuration steps are simple, easy to follow, written out, and it's standard practice to just do them and they work.

The IT world seems to be an endless swamp of special cases and things breaking deep in the stack that require very specific, arcane skills from unwritten textbooks.

> Instead of pretending that it's society's fault (can't be arsed), maybe ask why the IT industry can't make instructions that are written out

Because the competitor that doesn't have this installation "hassle"¹ will sell more units. It ends back up with society choosing to behave this way in aggregate

Society is obviously good (wouldn't want to live without it) and capitalism held up for hundreds of years now (not sure it's the best solution but with the tweaks that are in place in many well-faring countries it seems to work okay for them), but I do believe "society" does have a tendency to go for easy and cheap more than complicated and thorough when the need is not self-evident and has not been tangibly pointed out in living memory

¹ Example of hassle that HN users may not think of as exceedingly difficult: iOS setup. My dad asked me to help him set up his new tablet. I've fallen for Apple's motto and was annoyed he doesn't just do it himself. So we sit there and... lo and behold, it's good that he asked me. I forgot the details by now but things like what the heck screen time is, whether the Find My network is something to enable, whether to enable automatic updates, what to do about Siri, whether Apple Pay is something he needs to use banking apps, etc. are not things he'd have any idea of and I can give the necessary context from my IT background even if I don't have iOS myself. However, we still needed to contact their support because we both couldn't figure out how to get an Apple account set up. The continue button was disabled. I tried scrolling: nothing. Tapping the button: nothing. No error message, nothing. Turns out, the flow was only tested in portrait mode but my dad wants landscape mode easier for typing and so we never tried portrait. A part of the screen was in fact scrollable (I've used Apple devices before and my dad used the old tablet weekly, it's not like we're not familiar with their design patterns or don't know how to use a touchscreen) and revealed a required input field that would have been visible by default in portrait. Next, even setting up a standard Microsoft 365 email server in Apple Mail wasn't self-evident, iirc because he had never heard of the word Exchange and the oauth flow worked across multiple devices with again different bugs in Apple's own UIs (one needed landscape instead of portrait, another required some trick with zooming beyond intended bounds iirc)

"Hassle" is already perceived in setting up what people proclaim the most user-friendly of systems. Units that don't need it will absolutely sell better, even if that leads to a potential national energy supply risk

> We (the society) don't even want to change the default password on most things.

Like you wouldn't believe.

My most memorable case of insecure IoT devices - wifi socket was sending wifi ssid and password of the network in cleartext in every ping packet to chinese servers.

> and we as a society would rather risk everything than be arsed to take few additional steps

Large manufacturers would like you to think this. It would provide them a convenient excuse for not even trying to differentiate the market along these lines.

> We (the society) don't even want to change the default password on most things.

Actually.. I just want to use my device _first_ and not go through some manufacturer controlled song and dance of dark patterns.

In my experience, if you don't pre load the user with this garbage, and then wait for them to have an actual _need_ that depends on the feature, they're FAR more compliant with following even lengthy instructions to get it done.

It's more a problem of aligned benefits and timing than anything else.

> In my experience, if you don't pre load the user with this garbage, and then wait for them to have an actual _need_ that depends on the feature, they're FAR more compliant with following even lengthy instructions to get it done.

Nope, they want to have it working out of the box like with any other manufacturer out there. If you enable functions only after user wants it, they will comment "this sh*t doesn't work" on your app store page. Then you have to respons to each comment with "what doesn't work, could you specify please?" and then after several days that user has enabled the functionality, but in the mean time several another gave such comments.

> they will comment "this sh*t doesn't work" on your app store page.

What if I told you those 3% of people will say this no matter what you do. These comments and the reality of your product are entirely disconnected. We had a small userbase and added voice uploads into the app; unsurprisingly, about 3% of them are clearly impaired in some way when they leave a message. [x-files theme].

In any case, a simple "Fast / Slow Setup?" question to start is all you need, and a "Do More Setup?" after they finish one item has, again, in my experience, been entirely sufficient.

Reasonable people understand, "oh.. this needs the cloud.. and I didn't do that part yet.. so I'll go ahead and click the 'social media provider' button." If you also decide this is a good time to ask about a news letter, well, you got what you bargained for.

Victron (to cite an NL vendor) actually can perfectly operate in LAN only via MQTT and ModBUS also offering a (bad) WebUI locally for settings pretty anything, including a display for the said WebUI in a framebuffer with an embedded mini-keyboard. It's up to the installer decide to go with their cloud offer or not.

The sole remark I have against them (beside the not so good software quality it's the impossibility for individual owners to do offline updates, we can upgrade via VRM portal but not downloading fw and flash it locally even if the needed device is on sale, because they offer fw files only to registered vendors.

Fronius (to remain in the EU) have a local WebUI witch need a connection only for fw updates, even if differently from Victron it's not a Debian based system with sources available but a closed source one, they unfortunately offer only a very limited REST API and a very slow ModBUS but still anything con be do locally.

I'm not sure, since I haven't any myself by SMA (Germany) and Enphase (USA) seems to been able to operate offline as well.

Stated that, yes, you are damn very right in saying most installers have no competence, thankfully where I live self-installation is allowed (at least so far), but that's simply demand better UIs and training for them perhaps avoiding the current state of the industry with an immense amount of CRAP at OEM level, with most "state of art" systems not at all designed to be used in good ways (see below) and absurdly high prices to the customer at a level it's not interesting installing p.v... 4 years ago I paid my system 11.500€ for 5kWp/8kWh LFP, the smallest offer to have it designed and built by someone else was ~30.000€ the most expensive ~50.000€ and all the 6 offers I tried shows some unpleasant issues and incompetence.

About OEMs just observe how ABSURD is that there is no damn DC-to-DC direct car charger. Most EVs now have 400V batteries, the same of stationary batteries, with equal BMS comms. Why the hell not sell an MPPT-to-CSS combo direct solution? Ok, we do not ONLY charge from the Sun, than it's perfectly possible have a compo charging station with DC for p.v. and AC for the grid, switching from one to another as needed. It's ~30% energy lost in double conversion.

Why no DC-to-DC high power appliance who still run DC internally (A/C, hot-water heat-pump heaters etc)?

Why not a modern standard protocol for integration of anything instead of building walled gardens?

Long story short OEMs have choose the cloud model partially because most installers are electricians able to use desktop holding the mouse with one hand and clicking with the other, but also because they have no intention to made user-interesting solution in an open market...

I'm not a pro in these systems (yet, I hope), but my understanding is that, beside lack of demand, HVDC is a safety nightmare compared to AC, and inverters are getting more efficient each year. So, even given the choice, I'd keep AC home-wide distribution and set up inverters in key places, with exactly the highest required voltage.
Well, yes DC is unsafe because if you get electrocuted instead of being "pushed out" you get "attached" to the conductors, but if you have a p.v. inverter at home you already have a 400V DC line from the module to the inverter, how different can be having the same to the garage? The same to an exterior heat-pump unit (where the DC compressor it's typically located) witch is also insulated by the mere fact you drive it via a remote?

Aside I'm not much an expert as well but, from DC to AC we are pretty efficient, around 98% of energy get converted. But the other way round it's pretty inefficient, meaning a loss around 30%. So while your p.v. it's pretty efficient in generating AC, your car it's pretty inefficient generating DC from AC to recharge. You heat pump would gain as well.

To be clear I do not advocate DC for any DC home appliance like washing machines or dishwashers, just for energy intensive appliances like big heat pumps and car chargers. Not more.

Valid points, though for safety I thought less about shock and more about fire: the DC arc is much more stable, thus the switches, breakers and relays have to be more robust. The rated DC voltage of magnetic relays is about 1/10 of AC.
Well... I'm ready to pay 10-time the price of an AC breaker to recharge regularly DC-to-DC and since that's the very same link than stationary 400V LFP batteries being able to use the car battery as a home one when I'm at home.

Try to imaging how well you could run if you have a small battery, as an expensive UPS for the home when you are not there (ventilation, homeservers, fridge(s)/freezer(s) etc) and when you are at home, thanks to a let's say 70kWh battery you can also run your heating in winter in case of a blackout...

In the end it's the very same power circuit, why not? 300€ extras in breakers to run my heat pumps more efficiently? No issue, they'll pay back countless more.

The key failure is that despite the IPv6 transition we don't have static IPs at home and can start hosting servers at home.

Certainly this requires a lot of progress to secure the IOT space, but we can allow the enshitification of clouds to continue.

>they want their panels to be accessible when they are outside their home

I call bullshit. They've been conditioned to think that they want it, because all product brochures have it.

What kind of tangible benefit could there be to know how bright the sun is at your home while you're not there? A cool party trick to virtue signal or a break between doomscrolling, I suppose, but it's not like you're gonna jump up and drive back to... what even could you do if you knew?

> I call bullshit. They've been conditioned to think that they want it, because all product brochures have it.

You gave reason WHY they want it. Maybe consumers were conditioned to want access, but they still want access. If you give them similar devices, they will chose the one which has application or webpage to see how their big investment is actually working. It's not about current state of device, it's all about historical data and month-by-month savings presented as a nice graph. They will check this maybe every week or month (later every several months), but buyers still want to know what their installation did for them.

To be fair, I can do it only if I have time and physical access to the network. Home routers have different gateway IPs, different web interfaces, different password policies (e.g. there might be an admin password and an additional password for changing anything), etc.

It reminds me of <https://xkcd.com/627/>, but when you're launching a product that isn't good enough.

It's hard enough to open up a port even with uPNP (typically disabled) and other made-for-purpose tech. Torrent clients end up trying to poke holes and such. Service discovery might work via local UDP broadcast, or it might not. LAN clients might live at 10.* or 192.* or be isolated by default. It's easier to just go onto the public internet and contact some mysterious server. Botnet by design.

You mention IPv4. We're in 2024, this is getting ridiculous.

Governments should have done the same thing as with digital TV transition(s) : first ban selling devices that can't do IPv6, then ban selling (most) devices advertising they can do IPv4.

Here comes Matter protocol to the rescue, it supports IPv6 natively. It's even more complicated than Zigbee and of course doesn't specify all the devices available (but 1/4 of protocol specification is dedicated to smart fridge functionality because one fridge producer actually had someone to do any collaboration with protocol makers) and allows for "manufacturer specific fields" which means all manufacturers will have incompatible implementations of some fields anyway and you can't control them universally.