The bill nobody adds up
A client rings because nothing in the living room has switched since the weekend. The system is three and a half years old, cleanly built, never gave any trouble. You drive over, swap the part, drive back. Two hours of work, the journey, the material. And somewhere on the way home the uncomfortable thought arrives: who is actually paying for this?
Not the manufacturer. That warranty expired. Possibly not the client either, because he points at a period that is still running. Which leaves you.
That is the gap this piece is about. An integrator needs three numbers that never appear next to each other anywhere: how long am I liable? How long is the manufacturer liable towards me? And how long does the thing actually last? The first sits in the statute book, the second on a manufacturer’s website, the third nobody knows. What follows is an attempt to gather all three for the five classes of device you realistically deal with in Germany: KNX, Loxone, Shelly, home-built ESP32 and the Raspberry Pi as the hub.
Three limitations up front, because they carry the rest of the text. All warranty figures are as of August 2026 and can change at any time; when in doubt, check the linked manufacturer page. The durability reports come largely from community forums, which makes them anecdotes and not statistics. And the legal part is not legal advice, it is an overview to think with. It also describes German law throughout, which may or may not be the law that applies to you.
Statutory liability is not a warranty, and the difference costs money
The two terms get mixed up cheerfully in everyday conversation, even though they have almost nothing to do with one another.
Gewährleistung, statutory liability for defects, comes from the law. It runs against the seller, meaning against you in the client relationship, and towards consumers it cannot be contracted away. Garantie, a manufacturer warranty, is a voluntary promise. The manufacturer decides what goes in it and how long it runs. Nobody is obliged to give one at all.
The periods are in § 438 BGB: two years for goods, and five years for a thing that “has been used for a building in accordance with its customary manner of use”. In special cases it is thirty. A readable explanation of the provision is over at Juraforum, and a view from the trades here.
The interesting question, obviously, is when a smart home component counts as part of a building. And the honest answer is: it depends. Electrical installation in new-build is broadly treated as building work. A surface-mounted wireless sensor, or pure software, rather less so. Between those two lies a lot of grey area, and anyone who wants to see how thoroughly these classifications get fought over should look at the analogous case of photovoltaics, where the chamber of trades has summarised the court debate around the five-year period.
As a working hypothesis for your quote, a plain rule of thumb still does the job: the deeper the device sits inside the electrical installation, the more likely you land on five years. An actuator in the distribution board is a different case from a Zigbee window sensor you can lever off with a fingernail. If real money is riding on it, ask your lawyer and not a blog post.
Oh, and for readers in Austria and Switzerland: different periods apply there. I have not researched them, so I am not claiming anything about them.
Where the gap opens up
Now lay the two on top of each other. Suppose a relay permanently built into the installation falls under the five-year period at the client’s place. The manufacturer warranty on it is, depending on brand, two or three years. From the end of year three onwards, every replacement is on your bill: device, travel, working time, plus the delightful side effect that on the third service call a client starts questioning the system as a whole.
With one client, that is an annoyance. With forty clients and five affected devices each, it is a line in your P&L that nobody budgeted for.
KNX: short warranty, very long system life
KNX is the most interesting case here, because the two numbers sit so far apart.
On the warranty side there is not much to get excited about. MDT gives three years of product warranty and makes a point of manufacturing in Engelskirchen, which the KNX Association picked up on. With other brands the picture is patchy. Gira, for instance, ran a time-limited registration promotion for HomeServer and FacilityServer that extended the period to five years in total; the promotion has ended, and I have not found a general manufacturer warranty going beyond the statutory period. So I am not saying that one exists, and I am not saying it does not. Read the collected thread on product warranties in the KNX user forum and it becomes clear quickly: this is a field where every manufacturer does its own thing.
The real strength of KNX appears in no warranty booklet. The standard traces back to EIB from 1990, the first products arrived in 1991, and backwards compatibility is part of the norm. ETS6 advertises thirty years of backwards compatibility and can still parameterise devices from the EIB era.
That is the distinction that matters when advising a client, and I consider it the single most important thought in this whole text: nobody is claiming an individual device lasts thirty years. The claim is that in thirty years it will still be replaceable and configurable. System life beats device life. An actuator that dies after twelve years is a twenty-minute job as long as successors exist that the same bus understands. A device from a discontinued ecosystem is equally dead after twelve years, except that half the installation dies with it.
Wear and tear exists all the same, of course, and it is pleasantly predictable because it is mechanical. In a thread on the lifespan of switch actuators, the users are not discussing the bus electronics but the relays. Jung actuators are reported there as having been tested to 15,000 switching cycles, which at two switch operations a day works out at roughly ten years. The second failure cause named is dried-out electrolytic capacitors in older electronics. On buying second hand, the tone of the thread is fairly clear: BCUs, binary inputs and pushbutton interfaces are considered uncritical, switch actuators are advised against, because you do not know the history of those relays.
The datasheets themselves quote considerably larger numbers, but always load-dependent; at reduced load, six-figure cycle counts are normal, see for example the MDT datasheet for the AKS series. If you want to understand why the spread is so wide, the background is in the technical notes on relays from Finder: inrush current peaks on capacitive loads eat contacts far faster than a comfortable resistive load does.
Which yields a sentence I now work into every advisory conversation: the load determines the lifespan, not the price tag. An actuator channel feeding a row of LED drivers ages differently from the neighbouring channel on a wall socket. Spread the critical channels deliberately at planning time and you push the first service call out by years.
Loxone: clear terms, known weak points, and a fair reading
With Loxone the contractual side is pleasantly easy to look up. The international terms and conditions (retrieved 13 August 2026) state 24 months for new goods, with the defect having to be present at the passing of risk and detectable within those 24 months. Wear parts are set shorter: batteries six months, LCD displays twelve. Software defects have to be reproducible and reported in writing within four weeks, claims lapse three months after the period ends, and for an unjustified complaint a processing fee of 20 euros plus VAT is named. There is expressly no promise of interoperability with third-party products. I did not find a separate manufacturer warranty going beyond that in the terms; so I am claiming neither that one exists nor the opposite.
Loxone itself advertises its manufacturing quality and a fully automated test of every device. That is manufacturer communication, and I am quoting it here as exactly that. Also relevant in practice is the sales channel: you buy through authorised partners, and grey-market goods sit there without warranty or support.
It gets more interesting when you look at what the community reports. Two topics come up again and again.
The first is the memory card. The LoxWiki documents this in detail: up to firmware 4.x there were many Miniserver failures caused by apparently defective microSD cards, and the cause was confirmed as software-side file system damage from timing problems. Since firmware 5.x that is no longer known according to the wiki, and around version 9.0 reports piled up again in connection with updates. An estimate circulating in the community says that in roughly ninety percent of cases it is not the Miniserver that is broken but the card, which makes swapping the card before swapping the device worthwhile. That is a community estimate and not a measurement, but as an order of operations it is usable and can save an expensive replacement unit. If you need to rescue a card, the wiki has a guide to data recovery, and there is a hands-on account worth reading. From the same community, incidentally, comes the counter-evidence: cards that ran nine years without a murmur.
The second topic is power supplies. On loxforum there are several threads about early failures of the 100 W unit, here is one, here a second. One user describes a unit that failed after 48 hours with a loud bang and then left him waiting six weeks for a replacement; another reports three power supplies from the same batch dying within days.
And now the reading that has to go with it, because it is right there in the same threads: a considerable share of those failures is attributed there to indirect lightning effects, overvoltage and missing equipotential bonding, in other words to the installation environment. Loxone also does not manufacture these power supplies itself. Distil “Loxone power supplies are rubbish” out of threads like that and you have read them badly. The fairer reading, and the more useful one for your own work, goes like this: a switch-mode power supply is a component that reacts to the quality of the electrical installation, and surge protection is not an upsell gimmick.
What remains is the system risk you should tell the client about beforehand: if the central 24 volt supply drops, the installation stops. What that feels like and how others handle it is discussed in the threads on the consequences of a Miniserver or extension failure and on the emergency scenario of a dead Miniserver. How an actual warranty case plays out from the integrator’s side is shown in a thread about a defective channel on a dimmer extension. All manageable, provided you know the weak points and keep a spare or two on the shelf.
Shelly: good warranty on paper, extreme spread in the field
The manufacturer behind Shelly is Allterco Robotics EOOD from Sofia. The tiered warranty reads as follows on the official warranty page: three years on Plus, Wave, Gen3 and Gen4, five years on Pro and Wave Pro, two years on everything else. The clock starts at the purchase date per the receipt, and coverage relates to the hardware, not to consumables such as batteries or accessories such as tapes, cables and stickers. You can also look it up in the terms, in the German-language warranty conditions in the manual and in a reseller’s summary. Since this sort of thing changes, please check the manufacturer page for your specific case rather than this paragraph.
Five years on the Pro line is, measured against what everyone else here offers, a strong promise. It even covers the five-year scenario from the legal section. This is the point where you have to give Shelly honest credit.
And then comes the field.
The threads in the Shelly forum on lifespan, on durability and how people deal with it and on commercial deployment describe a failure pattern that is strikingly uniform across all of them: the relay keeps switching, but the Wi-Fi never comes back up. The cause named in the community is an ageing electrolytic capacitor; one user mentions a bag of faulty 100 µF electrolytics from a cheap manufacturer, another writes that he has repaired something like 200 Shelly 2.5 by rough count. The models named are above all the 2.5, plus 1PM, 1, Dimmer and Dimmer 2, RGBW2 and Uni. The reported time frame is frequently two to three years.
But from those same threads come these voices too: a user with over a hundred Shellys in production since 2018 who can “count the failures on the fingers of my hands”. One with around thirty devices since late 2020 and exactly one failure, some of them at 38 to 53 degrees inside junction boxes. And one who quotes a failure rate of around forty percent.
That spread is the actual finding. From “practically nothing” to “four in ten”, and everyone is talking about the same product family. Forums come with a built-in self-selection bias you have to keep in mind: satisfied people rarely write a post. Even so, bias alone does not explain a spread that size. Batch, installation situation and thermal environment evidently matter a great deal, and a defensible failure rate is something nobody knows, me included.
One more data point belongs here, and it is the cleanest one available on the subject, because it comes not from a forum but from the manufacturer. On 10 July 2024, an additional goodwill scheme for Gen1 devices was announced: if a Shelly 1, 1PM or 2.5 fails in its third year, there is a fifty percent discount on the corresponding second or third generation successor. Not a replacement, a price reduction. You can read that in two directions, and both are legitimate: as a response to a cluster of failures, and as customer orientation nobody was obliged to show.
On the question of whether the newer generations last longer, I have to pass. The threads barely discuss generational differences explicitly, and with the sources I have this cannot be shown cleanly. Two things can be shown: the documented failure reports cluster around Gen1 models, and the manufacturer gives a longer warranty on the newer lines than on the old ones. Taken together, that is an indication. It is not proof, and I am not going to turn it into one.
For practice this means something thoroughly unromantic. A Shelly is cheap enough that swapping it is almost always cheaper than diagnosing it. With twenty devices in your own house, that is a footnote. With two hundred devices across forty client installations, the service van turns into a business model, and one with a poor margin. The typical failure pattern does not help: if the relay keeps switching and only the connection disappears, neither the client nor you will notice until some automation eventually runs into nothing.
ESP32 and ESPHome: technically sound, legally the trickiest case
I like ESPHome. For soil moisture, temperature, meter readings and similar uncritical sensing, a self-built device is a perfectly legitimate solution and often the more elegant one. Anyone who paints it otherwise does not know the platform.
Technically, the ESP32 is regarded as considerably more stable in continuous operation than its predecessor the ESP8266, which is better known for periodic reboots; the experiences are collected in the Arduino forum and at ioBroker. The same three practical tripwires keep showing up there: the quality of the power supply, Wi-Fi stability (a static IP instead of DHCP is repeatedly described as a noticeable improvement) and flash write cycles when writes happen often.
The sore point is elsewhere. Buy a dev board, populate it, put it in an enclosure and install it at a client’s, and you become the party placing it on the market. The two euros of statutory cover on the board from the distributor help nobody at that stage. CE conformity, liability, spare parts availability over years: all yours. I am deliberately not going deeper into the legal detail here, because I have not researched it to that depth. The practical core is enough anyway: the DIY solution is cheap to buy and expensive in responsibility.
So the useful question is not “good or bad”, it is a very concrete one: what happens if this particular device fails while the client is on holiday? With a soil moisture sensor: nothing. With something that switches a pump or involves a door: please use a production product with a manufacturer behind it.
Raspberry Pi: shortest promise, best known wear, cheapest fix
The warranty here runs through the distributors and is commonly one year, see the warranty documents from Farnell, a statement from element14 and the discussion in the Raspberry Pi forum, which also chews through the relationship to EU statutory rights.
That produces a nice, uncomfortable punchline for the advisory conversation: of all things, the brain of the installation carries the shortest manufacturer promise in the entire build. Every actuator in the distribution board is covered longer than the computer without which none of them does anything sensible.
The classic wear item is the SD card, and here too the experiences scatter wildly: from “over six years and never a failure” through to several cards used up. You can read up on it in the Photovoltaikforum, at smarterkram and in a troubleshooting guide which states that in roughly eighty percent of cases the problem lies with the power supply or a damaged card. That, too, is a community estimate and not a measurement series. As a checking order when something breaks it is still useful, and it lines up strikingly with what the Loxone people write about their cards.
The pleasant part: the fix is known and costs almost nothing. SSD or NVMe instead of an SD card, or hardware with eMMC from the start. Home Assistant Green has eMMC on board; the Yellow with its M.2 slot has, according to a comparison overview, not been produced since 2025, with a pointer to the Green as successor. That is a third-party source, so read it with the usual reservation. How the move from SD to SSD works is well documented and done in an evening.
If you build for clients and the hub still boots from an SD card, that is the cheapest risk reduction this entire text has to offer.
Five risk profiles side by side
No ranking. The classes solve different jobs, and the table only sorts out what kind of risk you are buying into with each.
| Class | Manufacturer promise (as of 08/2026) | Typical weak point | Type of risk |
|---|---|---|---|
| KNX | manufacturer-dependent, e.g. 3 years at MDT | relays in switch actuators, old electrolytics | plannable, mechanical; spares available long term |
| Loxone | 24 months per the terms, batteries/displays shorter | memory card, central power supply | manageable once the weak points are known, high vendor dependency |
| Shelly | 2/3/5 years by line per manufacturer statement | reported: Wi-Fi gone, relay keeps switching | spread; installed-base risk at large device counts |
| ESP32 / ESPHome | practically none worth counting | power supply, Wi-Fi, flash | liability sits entirely with the integrator |
| Raspberry Pi | commonly 1 year via distributor | SD card, power supply | high, but cheap and well understood to defuse |
What I take away from all this
Three things, and the first is the least popular: warranty length is fairly worthless as a selection criterion. It tells you how long you may send a box back, not how long the installation runs. Five years of warranty on a device whose successor will not exist in eight years is worth less than three years on a device from a standard that started in 1991 and is still backwards compatible.
Second: price the gap into the quote instead of ignoring it. If you are liable for five years and the manufacturer bows out after two or three, the remaining years are a line item with a price. Either you calculate it in, or you pay for it later out of your margin. A maintenance contract is the usual way to smooth that out; what one of those may cost, I have worked through elsewhere.
Third, and this one only really dawned on me during the research: for the classes with the big spread, meaning Shelly and the Pi, the only workable countermeasure is knowing your installed base. Not better hardware, not longer warranties. Knowing which device hangs where and since when, and noticing when one of them quietly disappears.
Because the difference between an installation that runs for twenty years and one that turns into a nuisance after four is rarely the brand. It is whether somebody noticed the failure before the client called.