Reading the same thread, I can't avoid thinking about my ES (Amitime) air-to-water heatpump. It's a full-Chinese design, but clearly air-to-water units are more niche than air-to-air units so not subject to cost optimization - which in this case is a bad thing, because no cost optimization means "built with minimum engineering resources from some random modules". The outdoor unit is quite OK - an inverter board basically, but the indoor controller box has this massive module with dozen unused relays, inputs and outputs, which does almost nothing but acts as some sort of RS485 gateway. But then the actual horror is a small embedded computer with touchscreen, running f****ing Windows CE (with Chinese start menu flashing on the screen when it boots).
And who would have guessed this Windows CE just slows down day after day, until after a few months of runtime it basically locks up totally, so that the heatpump stops performing its normal operations - it can be stuck off heating, so your house starts to cool down, or it can be stuck on, not doing defrost cycles, so that the evaporator is blocked with frost eventually. You need to power-cycle the machine.
All it does is look at a few temperature sensors and give some simple modbus commands to the inverter card, really, so for the heatpump to operate, minutes of lag is still fine; the UI gets slow to use first, so the user is the watchdog; when it gets awkward, user power-cycles the machine and all is well again. What they forget is this is supposed to be an automated heating device; someone might never touch it after initial setup, some random grandma might have no idea how they should be rebooting it. Their house will just freeze.
Our home automation controller (which does control heaters, boilers, battery inverters of dozens of brands, and participates to grid stabilization services), on the other hand, is a bare metal microcontroller thing. It's cheap to manufacture, boots in milliseconds (it actually maintains relay positions through reboot; proven that the boot time to GPIO config is fast enough that relay coil current (see V = L*dI/dt) does not decay below the specified pull-apart current), maintains exact same timing characteristics regardless of uptime; and of course, offers the necessary grid frequency measurements, realtime control, and data logging as required by TSO (grid operator).
It differs from the usual solutions exactly by not being a Raspberry Pi, not running Homeassistant, and instead being a monolithic, non-scalable, closed, developed and maintained by us. People who want a box that just works buy it; Homeassistant hobbyists keep asking HA integration
Now, to your question about ESS and how shitty they are, and this is a question we get asked a lot, and our answer unfortunately (with experience of ~2000 units of ~10 brands) is, we cannot wholeheartedly recommend
any BESS.
They
all are nasty, buggy horrible kludges held together with bubble gum and duct tape - and the few that obviously are Real Software Projects, are even worse, to the point of us having to seriously consider dropping the support. Large % of our fleet are Solis inverters and Dyness batteries (like, ~1000 units). Outright crashes are not as common as your Enphase example, but the problem is with magical "features" and numerous settings no one, including manufacturer itself, do not fully understand, and for which no stable default values exist, so expect to do a lot of debugging trying out random settings, firmware updates and reboots to see if the problem goes away.
We have seen stuff like inverter OTA update making power command registers 10x more sensitive with internal 16-bit wrap-around, so that 1kW charge command becomes 10kW charge command overnight, and 5kW charge command becomes 17kW discharge command. Or a 40kW unit becoming a 50kW unit overnight since a wrong firmware version was applied (no safeguards).
Or, with Kostal, we saw the internal TCP implementation just crash, requiring end-user to reboot the inverter. After months of struggle, we found out a workaround of single-using TCP socket for a single poll, then close and reopen the socket. The crash was obvious from the fact that even the inverter's LCD+buttons menu got extremely sluggish, and the internal web server stopped responding. And I don't think it runs Windows CE; I believe it could be some sort of RTOS. It nevertheless crashes. Workaround works. Otherwise very reliable machines.
And these are not the bad examples; I can actually
recommend these brands because no one else is really significantly better (the best vibes we currently get is Sungrow which mostly just keeps working, but N is still too small, <50, to really say). But no brand has been problem-free. And in almost all cases, the root issue is the difficulty of escalating bug reports (or getting questions "how this feature should be working") to the R&D (i.e., the poor guy who's trying to keep the spaghetti working) and this is even with us having contacts and enough volume that we are being taken somewhat seriously. There is just one exception - FoxESS - with the usual amount of problems like everyone else, but they are
actually fixing the bugs we have reported
within days; that's nearly unbelievable.
And that only covers inverters. Add batteries to the mix and now you have a buggy BMS from manufacturer X communicating with a buggy inverter from manufacturer Y. Even the best (so BYD) batteries do sometimes just magically turn off. So we need to write email to the customer and explain their battery has malfunctioned, may be faulty, or maybe just needs a reboot, and instruct them where the physical power switches are and how they are operated.
The absolute worst offender, an "European" company labeling some Chinese junk yet somehow managing to gain a good reputation for no reason whatsoever - all broken crap and hostile attitude. Batteries just die on their own, with or without our box. I'm not brave enough to mention the name or even more details. They are crazy enough they could actually do a lawsuit or something. So avoid labelled stuff, proudly buy Chinese with Chinese names.
Our box? We also do have bugs
- let's say, for example, wrap-around math of 32-bit 1/1024 second counter handled in a wrong way, so that inverter communications got killed after 48 days of uptime. The nastiest issue in our box is that maybe one in 300-500 installs, it fails to reliably connect with Ethernet while customers say other devices do work. Some weird compatibility thing with certain router + possibly bridge-mode extender combinations. Most of them are finally resolved by customer realizing their other things didn't after all work very well either, so that way it stops being our fault, and a router or extender gets replaced, but still, clearly something in Wiznet stack escalates fairly benign intermittent networking issues to more serious blackouts. Probably would not happen on linux or Windows CE - we would see other problems then. But overall, embedded stability-wise we are totally debugging problems of
others 99% of the time, so, that's a testament to "KISS principle - bare metal - as much own code as possible, minimized library use". And maybe, "keep the one who wrote it in the house" (me). Because I have a feeling (I don't have a proof though) that a lot of these problems are caused by
outsourcing software development work and assuming it works as well as outsourcing, say, PCB or mechanical design. Maybe it does if the product is exceptionally simple and the developer is exceptionally good. But normally, bug reports will keep pouring in, and the one who made it will be in the best position to also fix it. At least I'm doing mistakes, so it's important I keep fixing them too. Hiring someone else competent enough can turn out to be more difficult than anyone can expect.
Home
Help
Search
Login
Register
