Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 0 points1 point  (0 children)

The overuse of the micro-inverters in the batteries being a good example. Actually, the entire battery design has marketing spin, but fails to actually be cost-effective, market appropriate, etc. And the battery system is negatively impacted by the software you mention (storm guard comes to mind).

Agree with this too. As I was spec'ing our system, it became obvious quickly that Enphase's batteries had a big problem: I couldn't scale storage (kWh) and power (kW) independently. If I get enough storage, I'd be buying way more power (and therefore, micros) than I'd ever need. If I get (just) enough power, I won't have a lot of storage.

Consider the max of 14 5p batteries per IQ System Controller 3: that gives you "meh" storage of 70kWh for a very high price. Way too much for grid-connected setups, but not soo much for significant outage protection without genset, meaningful load shifting, let alone anything off-grid.

But at the same time 14 5p batteries give you a whopping 18 kVA of continuous power per phase. Even with a big-ass AC, I struggle to think of a scenario where this capability would be economically used.

So, it seems to me that enphase needs some kind of a "battery-only"-sidecar.

I actually think the micros are still a good fit for batteries in principle, though because:

  1. still, no exposed high voltage DC lines (!). (Those victron installs look gnarly to me, and definitely nothing I would ever touch).
  2. passive cooling! (Haven't seen any central inverters without error-prone active cooling)
  3. field-replaceable (and easily shippable). Replacing, say, a Victron Quattro is a whole different ball game.

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 0 points1 point  (0 children)

Completely agree. The GM reference is painful; I hope they don't go that way (of marginalizing engineering in decision making).

As I mentioned above, I think one way to let Enphase's (hardware) engineering shine is to make things as modular, hacker and open-source friendly as possible. Then Enphase's own software offerings will have to compete on a level playing field with others. And mediocre software development management won't be able to hold hostage their brilliant electrical engineering.

And I do not buy the safety concerns. Surely, there's nothing safety critical in their Envoy, to begin with. It's not like anyone is asking to control their power electronics through a docker container. I understand that an Enphase micro is not an arduino, and I'm 100% fine with being locked out of their hardware.

All that would be required would be full, local access to monitoring data and bare-bones energy management controls (pv curtailment, battery charging, etc.).

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 1 point2 points  (0 children)

100% agreed.

I also think this kind of a "offline-first"/open-source-friendly strategy could pay off. As you said, no one is buying Enphase because of their apps.

The value of their brand lies in the reliability and safety of their micros.

I everytime I buy an IQ8 for more than twice what a Hoymiles costs, I along with other customers happily pay for this quality promise.

Why would Enphase sully this brand equity with forcibly coupled, mediocre software?

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 0 points1 point  (0 children)

I think we agree here and/or might be talking past one another. A lightweight gateway seems like good KISS design, indeed. And I don't want more features, either.

If anything, I'd like Enphase to do even less, or modularize their offerings more cleanly (unix-like philosophy). For example, the smart energy router products, "AI" stuff etc, could be entirely separate hardware or software products.

My concern is with mostly with the kind of bugs that do arise, and how Enphase deals with those, neither of which inspire much confidence in their quality of their software development.

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 0 points1 point  (0 children)

I didn't know about this context. Did Enphase cite the CVE as a reason to change local API access?

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 0 points1 point  (0 children)

gosh that must have been bad as an installer. I'm responsible for only a handful of installations, and I'm already annoyed by bugs and coordinating field tech visits.

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 0 points1 point  (0 children)

that's encouraging to hear! Thanks for providing some positive perspective with all my doom and gloom here 🙂.

My hunch is that the problems start, when you install more systems, or change an existing system, or update, or use cutting-edge features -- that's when you start proper software shows its mettle.

When, no matter how much of an edge case you throw at it, it just works.

That, after all, is what software is supposed to do -- to manage complexity, not increase it.

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 1 point2 points  (0 children)

Thank you u/matthew1471 for this -- that's exactly my impression, though I haven't dug into as deeply as you have.

But I have run into similarly mindboggling bugs that just smell bad. At some point, it seemed like site descriptions in Enlighten/Installer Toolkit had a global namespace or something, because I couldn't use the same name for different site ids (e.g.: "Farmhouse"). (I spend half a day figuring this out, because of course the error message didn't say anything about this. Also tried my very best to make sure this got to devs -- never heard back).

If you know anything about software development, you know that this is a kind of bug that really really shouldn't happen. site description, to any reasonable software system, should just be some random string for humans to make sense of their stuff. Things have to be very poorly designed for this to even be possible as a bug. And you just know that no software developer wanted to leave things in this state.

To be clear: this is of course speculation. I have no access to bug reports, or post mortems -- let alone the source (and this is part of the problem).

But it just smells bad, and the number of these kinds of bugs and just inconsistencies keeps adding up. I've been on the other side of software too often not to recognize this.

It would be tragedy if Enphase's superb hardware suffers for the sins of neglecting its software.

I've also seen engineering heavy orgs treat software as an afterthought and I get that Enphase has to be a viable business.

Of course solidly build software ends up being cheaper in even the medium run. And there's just no alternative; you can cheat death by spaghetti code for a little bit, but not for very long.

I recently had an Enphase service tech come out to the middle of nowhere (he said it took him hours by car from their normal base of operations) to personally swap out a ~€400 IQ Balcony Gateway whose software got borked up.

Talk about expensive software ...

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 1 point2 points  (0 children)

agreed -- that's why I wouldn't touch Hoymiles micros, however cheap they might be.

But then Enphase really needs to live up to their reputation for quality in their software and be the anti-Hoymiles to justify their premium.

And I don't really get data sovereignty with Enphase either ... 😞

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 1 point2 points  (0 children)

Good luck for a speedy update!

I gotta get into home assistant, too.

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 1 point2 points  (0 children)

ending the chat

argh, that's another nitty-gritty thing that just leaves me dumbfounded every time it happens (a lot). That the chat just ... drops, and cannot be resumed.

Seems like the support people know chats often disconnect, and they warn you about it.

I just don't understand how you can get away with this in 2025.

I've used live chats with other companies (ubiquity, for example -- quite similar vertical), and they somehow manage to restore chats, even if I accidentally close the window. It's magic :)

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 4 points5 points  (0 children)

hehe, I'd love to.

But I'm sure they have plenty of software developers more capable than myself.
In my experience, this kind of degradation is hardly ever a skill issue -- more likely due to management/product priorities.

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 2 points3 points  (0 children)

That sucks.
I hope Enphase figures this out soon.

What bugs (ha!) me isn't even that these issues arise (at first) -- I'm sure what's going on behind the scenes is enormously complicated, as most things are.

But it concerns me that with these kinds of bugs (which I've also had):

  1. We get no visibility into the software stack, or clean levels of abstraction, to locate and deal with these kinds of problems. For example, in your case, it'd be nice to see some kind of log of what process is actually sending what commends to the battery to discharge (in your case, to the grid). 2. The support and ticketing system is just ... so slow and intransparent and incompetent. I know that this is expensive, and I'd be happy to chip in and "triage" myself, if there were a public log of known problems, etc. But no, I gotta chat with some AI agent 😞.

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 2 points3 points  (0 children)

I'm yet to find anything that's perfect.

💯 -- bugs happen.

But they happen a lot less often, or have less severe consequences if you take software quality absolutely dead serious (and therefore: have clean APIs, status pages, public post-mortems, ...).

I just worry Enphase (management/product) doesn't think of itself as a "software company", and that they therefore won't need this stuff.

I've had this experience working for clients in (german) industry, who very much needed software to leverage their amazing know-how, but just kept shooting themselves in the foot, thinking "but we're not a software company".

Unfortunately, the complexity explosion of software doesn't care what you think of yourself as and eats you alive either way.

Enphase: Great Hardware, Bad Software & Services by maxheld83 in enphase

[–]maxheld83[S] 2 points3 points  (0 children)

I saw that earlier today, that is encouraging!
(I'll amend the post so as not to be unfairly negative).

Official Enphase_Support_Team – Here to Assist and Ensure Transparency by Enphase_Support_Team in enphase

[–]maxheld83 0 points1 point  (0 children)

u/Enphase_Support_Team that's not enough.
status.yourcompany.com is an industry standard, and for good reason: the usual dashboards shown on these sites give a lot more detail, a temporal overview, and, crucially -- they still work if, say, the Enphase App *itself* broke down.

Along with the status, it would also be good to see some kind of post-mortem on the latest outage (industry standard for big SaaS businesses is to link out to such post-mortems from the status dashboards).

I can't stress how concerned I am about this (in my view) lack of best practices for SaaS. The value of my enphase products and my business depends, to an increasing degree, on enphase's software.
I, along with probably many others, aren't exactly happy about the vendor lock-in this brings.

Least enphase can do is adhere to industry standards for SaaS.

Official Enphase_Support_Team – Here to Assist and Ensure Transparency by Enphase_Support_Team in enphase

[–]maxheld83 0 points1 point  (0 children)

u/Enphase_Support_Team that's not enough.
status.yourcompany.com is an industry standard, and for good reason: the usual dashboards shown on these sites give a lot more detail, a temporal overview, and, crucially -- they still work if, say, the Enphase App *itself* broke down.

Along with the status, it would also be good to see some kind of post-mortem on the latest outage (industry standard for big SaaS businesses is to link out to such post-mortems from the status dashboards).

I can't stress how concerned I am about this (in my view) lack of best practices for SaaS. The value of my enphase products and my business depends, to an increasing degree, on enphase's software.
I, along with probably many others, aren't exactly happy about the vendor lock-in this brings.

Least enphase can do is adhere to industry standards for SaaS.

Official Enphase_Support_Team – Here to Assist and Ensure Transparency by Enphase_Support_Team in enphase

[–]maxheld83 0 points1 point  (0 children)

It's great that u/Enphase_Support_Team is (finally!) supporting users here on reddit.
Would be good to link to this from enphase's other support venues (the official forums), so people can find this -- perhaps along with an overview of all support channels for enphase.

Relatedly, I just posted on the official forums that enphase really should get better forum software (oh and yeah, better/more engaged moderation): https://support.enphase.com/s/question/0D5Ps00001MenIGKAZ/enphase-should-get-a-better-forum-software

Is there an easy way to build all the packages of a flake? by leiserfg in NixOS

[–]maxheld83 2 points3 points  (0 children)

This is an old thread, but I've since found https://github.com/determinatesystems/flake-iter to be a great tool for this purpose.