It's that time now

[wojtas810 17]

Time to say thank you to HC3 – and I switched to Home Assistance. HC3 only started working for me as a receiver. The amount of integration I can do with Home Assistance compared to what I've believed in for over eight years is a bit excessive. In my opinion, it's a dying system, light years ahead of others. Thanks to everyone for the good suggestions on switching to something that makes more sense these days. I won't regret Fibaro.

[awlieser 19]

I can only concur - Fibaro is way behind the curve in comparison to HA - problem is migrating all of your non-mobile devices … ☹️

Edited March 19 by awlieser

[Sankotronic 2,370]

Hi @wojtas810 , @awlieser ,

 

first of all, wish you all the best with Home Assistant.

I tried HA not long ago and it is really interesting. On first run it recognised and added all of my devices that could be found in my home, much more than my HC3. But that is where I stopped because to go further I had to start learning from scratch again. I found that HA is not that much user friendly even when it comes to simple sorting how my devices will show in browser. Maybe I'm not that smart as you are.

 

In more than 10 years with HC2 controlling my house, there where ups and downs, but at the end experience is highly positive.

HC2 was doing exactly what I programmed it to do, no more no less  

My HC2 has given my family so many nice moments, not to mention laugh whenever it spoke through Sonos speakers.  

It is now time to get the same and even more from HC3.

Currently I'm enjoying developing Yubi UHAS for HC3 and hopefully will be better that HC2 version with which I learned lots of interesting things about home automation.

 

I found that biggest disadvantage of Fibaro system is its maker. I will never understand why they make gateway with embedded programming language that gives great power, but then never provide developer guide for it!?!?!?!

I will never understand why Fibaro after so many years still thinks small, while having great gateway and other products? @m.roszak any thoughts on that?

 

[wojtas810 17]

Totally agree, @Sankotronic  buddy. I've been using the HC2 since 20215, then the HC3 for the past three years in my new home. But after installing HA—and quickly connecting the HC3, plus the Tuya, Xiaomi, Dream, Panasonic, Tesla, and a few other things—and I can also create a great dashboard—how can I not be nervous? How long can I wait? For fixes? A stable system for connections, etc. I'm tired of waiting. I was faithful for many years and waited with gritted teeth. But look at yourself, you're getting irritated And look again, even the Beta versions can't release anything without breaking anything, and it's been like this for years since the HC2... 
I plan to throw out all the scenes and other stuff from the HC3, and this one will act as my Z-Wave hub because it's probably not suitable for anything else... and anything that breaks from it will be replaced gradually, and that's it...

[RH_Dreambox 189]

@wojtas810

I understand your frustration and I’m absolutely convinced you’re doing the right thing.
I’ve used both HC2 and HC3 myself before switching to Home Assistant, and I haven’t regretted it for a single second.
Now I have Z-Wave, ZigBee, 433 MHz, Bluetooth, and Wi-Fi, all working without a hitch. I build my own sensors easily using ESP32.

ESPHome, which is an integration within Home Assistant, makes it incredibly easy to programme and manage the sensors.

You simply have your pick from the thousands of apps and integrations that you can install directly from within Home Assistant.

Home Assistant (Nabu Casa) has also developed its own ‘antennas/hubs’ for Z-Wave (ZWA-2) and ZigBee/Thread (ZBT2), which are absolutely fantastic.

I’ve been using these antennas for a couple of months now, and previous interference and missed communications have completely disappeared.

In other words, the automation is completely stable, even for sensors in my letterbox and greenhouse 30–40 metres away.

 

Please login or register to see this link.

Please login or register to see this link.

[jgab 2,641]

On 3/20/2026 at 12:19 AM, Sankotronic said:

I found that biggest disadvantage of Fibaro system is its maker. I will never understand why they make gateway with embedded programming language that gives great power, but then never provide developer guide for it!?!?!?!

I will never understand why Fibaro after so many years still thinks small, while having great gateway and other products? @m.roszak any thoughts on that?

I second that. The basic architecture is quite ok with the device models etc - HA's model is more flexible but on the other hand a bit more messy, here I think Fibaro has a struck a reasonable tradeoff. They just need to be a bit more agile when it comes supporting new device types and capabilities - and in capabilities I include reasonable UI elements.

This from a perspective of developing your own integrations, vs just drag&drop existing - here HA of course has a couple of years head start because the Fibaro developer experience stopped evolving 2013... So I understand the attraction of HA.

 

It's difficult to understand the lack of (interest for) developer support - but they probably never saw developers developing integrations as a part of their business equation - it was just glue for certified integrators(?)
This compared to HA where the community has created hundreds of integrations and are quick to release new for new devices - which then becomes the main attraction and value of HA... and thus people moving away from Fibaro to HA as life becomes easier...

Anyway, even if I was a certified integrator I would still have questions (or maybe they are answered by their integrator program)
-Lack of development documentation
-Crippled Lua environment (no coroutines, rawset, rawget)

-Lack of support for user libraries (sharing code, stuff hard to do in pure lua but necessary to interact with modern devices)
-Lack of 3rd party API support, ex. crypto, oath, etc)
-Lack of debugging possibilities.

With more power comes more danger - security issues etc - but that is manageable and part of owning a platform and should not be a reason to keep developers in the dark.... age.
Have a developer mode for the HC3 where we get the lua debugger and can run mobdebug for remote debugging - other embedded Lua systems allowed this years ago...

Edited March 21 by jgab

[wojtas810 17]

You know what this reminds me of? I'll tell you - back in the day, in Poland, where Fibaro originated (I know they were sold), there were Polonez cars like that - where are they today? ... I hope the Fibaro path never ends the same! That's what I wish for them, and I hope I'll apologize to them for this post.

[tinman 1,070]

3 hours ago, jgab said:

Anyway, even if I was a certified integrator I would still have questions (or maybe they are answered by their integrator program)
-Lack of development documentation
-Crippled Lua environment (no coroutines, rawset, rawget)

-Lack of support for user libraries (sharing code)
-Lack of 3rd party API support, ex. crypto, oath, etc)
-Lack of debugging possibilities.

 

there is some documentation available, but it is more important to know that the few certified integrators (don't confuse it with certified installer) got in the past support from dev team directly.

Certified installers - since NICE takeover - don't even get marketing or traning material, support got reduced to cosumer level, ... maybe except the few webinars per year (which are valuable for sure, but drops in the ocean honestly)

 

Dubugging, afaik due to lack of shell access, is more complex - before with HC2 was much easier to develop a plugin. With HC3 Fibaro was really paranoid with shell access, as it was from the beginning desiged to act as "alarm system certified" (which failed due to typical restrictiion like "user should not have right to play on alarm system" .. anyway). Later, as Fibaro got some nice security reviews, they remained paranoid - which is honestly good thing for me/my company, there are no other Smart Home gateways that i could use as Smart Building without being killed by security or IT auditors in germany.
 

Plugin are additionally hard to maintain - that's why Fibaro introduced for the comunity the QuickApps - much easier to develop / debug, but on the other hand less possibilities (yes a plugin can still use already integrated cypto, oath, coroutines are posible ...)

While QuickApps are nice idea, it might be real pain in ... when talking about restirctions, i did spent 2 months i think, to rewrite my previous local TUYA implementation, to code new aes libs (these i posted once were nice, but not sufficient). @wojtas810 you right, on HA TUYA would be "one click", sure, but only because someone already spend time on it. Check the dev/driver logs, you will see it took weeks to reverse and develop something (local TUYA, no the cloud thing).

 

For me, as i think the last certifed Fibaro trainer in germany, it has become very dificult to convince installer to still use that platform. Luckily other commercial products are toys in compare - are consumer and not real commerial products, with issues / updates which the consumer have to fight with each every day (hardware bugs, firmware bugs, major features simply not implemented properly or at all, dev restrictions as well, big marketing but nothing behind ...). On the other hand is HA not really commercial product, so yeah, we do HA as well, but always only for tech inclined customers, who are capable of maintaining and managing the system themselves in the long term.

@wojtas810 definitly you should leave HC3 as z-wave gateway for HA

 

[cag014 731]

I’ve been following this thread and I just want to add a different perspective.

I don’t think Home Assistant is the universal answer, and I also don’t think HC3 is “dying” just because it isn’t trying to be HA.

These are two completely different products aimed at two completely different types of users.

HA is great if someone wants to tinker, experiment, build dashboards, flash ESP boards, and spend time maintaining a system.

It’s extremely powerful, but it also requires a lot of involvement and technical knowledge. That’s perfect for some people, but definitely not for everyone.

HC3, on the other hand, is built as an appliance. It’s meant to be stable, secure, and manageable without constantly digging into configs or YAML.

It focuses on Z‑Wave reliability and a predictable environment. Not everyone wants to run Docker containers, troubleshoot integrations, or rebuild things after an update.

For many households, HC3’s “set it and forget it” approach is exactly what they need.

So yes, HA offers more integrations and faster development, but that doesn’t automatically make HC3 obsolete.

It just means the two systems serve different expectations. Some users want maximum flexibility, others want a system that works without becoming a hobby.

For advanced users, combining both systems is often the best solution—HC3 as a solid Z‑Wave hub, HA for the extra integrations.

But saying HC3 has no future just because it doesn’t follow HA’s philosophy feels like an oversimplification.

Not everyone wants or needs what HA offers, and that’s perfectly fine.

 

And honestly, this is no different from TVs. Nobody wants a DIY TV with custom firmware, endless configuration, and experimental features.

People want a TV they take out of the box, plug in, and it works. HC3 follows that philosophy.

HA is more like building your own media center from scratch—amazing for enthusiasts, but not something the average person wants to deal with.

[L3n 4]

I've been using the Fibaro HC3+HA for two years now (HA 2y, HC 10+y). But recently, I tried moving some Z-Wave devices to HA directly.
Unfortunately, I don't understand why, for example, associations in HA happen instantly, while on the HC3 it takes 1–2 seconds, which is annoying. 

To sum up: In my tests, Fibaro devices run faster on HA than on their native HC3 and I don't understand that 😐

Edited March 30 by L3n

[Brors94 115]

24 minutes ago, L3n said:

I've been using the Fibaro HC3+HA for two years now (HA 2y, HC 10+y). But recently, I tried moving some Z-Wave devices to HA directly.
Unfortunately, I don't understand why, for example, associations in HA happen instantly, while on the HC3 it takes 1–2 seconds, which is annoying. 

To sum up: In my tests, Fibaro devices run faster on HA than on their native HC3 and I don't understand that 😐

You got me to think about this on engine 2 it was kinda slow 🤔
Have you tested with the z-wave engine 3? 
Seems like it is faster on the engien 3.
(battery devices is slow because you have to wake them up, but I guess you know about that) 





 

[L3n 4]

3 hours ago, Brors94 said:

Seems like it is faster on the engien 3.
(battery devices is slow because you have to wake them up, but I guess you know about that) 

Unfortunately, no. I can't switch to engine 3 yet.
Of course, I understand about battery-powered devices, but my situation is different.
In my case, it’s a relay + a S2 button switch that controls the light on another device via an association. 
I've been using this setup for over 10 years on HC2/3 in different rooms with various devices - dimmers, relays, etc. I'm used that there's a delay in this kind of setup. But I was really surprised when I tried the same setup with HA, where the second device responds almost instantly.

[cag014 731]

6 hours ago, L3n said:

Unfortunately, no. I can't switch to engine 3 yet.
Of course, I understand about battery-powered devices, but my situation is different.
In my case, it’s a relay + a S2 button switch that controls the light on another device via an association. 
I've been using this setup for over 10 years on HC2/3 in different rooms with various devices - dimmers, relays, etc. I'm used that there's a delay in this kind of setup. But I was really surprised when I tried the same setup with HA, where the second device responds almost instantly.

Just to clarify — Z‑Wave associations always work device‑to‑device, HC3 is not in the command path.

The difference you see between HC3 and HA is in how fast each controller processes the status reports, not in the association itself.

 

In short, the idea that HC3 makes Z‑Wave associations slow is not correct. Z‑Wave associations are always direct device‑to‑device communication, no matter which controller you use.

The controller isn’t in the path and can’t delay the command. The real difference you’re seeing between HC3 and HA is how fast each system processes the status reports that come after the association.

On HC3, the action itself is instant, but the controller updates the UI and scenes slowly, especially under load.

Home Assistant (with Z‑Wave JS) processes those reports much faster, so it feels like the association is faster even though the actual Z‑Wave command happens at the same speed on both systems.

So the delay you’re noticing isn’t in the association — it’s in how quickly the controller reacts to the result.

[wojtas810 17]

On 30.03.2026 at 00:11, cag014 said:

Śledzę ten wątek i chciałbym podzielić się inną perspektywą.

Nie sądzę, że Home Assistant jest uniwersalnym rozwiązaniem, i nie sądzę też, że HC3 „umiera” tylko dlatego, że nie stara się być HA.

Są to dwa zupełnie różne produkty skierowane do dwóch zupełnie różnych typów użytkowników.

HA to świetne rozwiązanie, jeśli ktoś chce majsterkować, eksperymentować, budować panele sterowania, programować płytki ESP i poświęcać czas na konserwację systemu.

To niezwykle potężne narzędzie, ale wymaga też dużego zaangażowania i wiedzy technicznej. To idealne rozwiązanie dla niektórych osób, ale zdecydowanie nie dla każdego.

HC3 z kolei został stworzony jako urządzenie. Ma być stabilny, bezpieczny i łatwy w zarządzaniu, bez konieczności ciągłego zagłębiania się w konfiguracje czy pliki YAML.

Koncentruje się na niezawodności Z‑Wave i przewidywalnym środowisku. Nie każdy chce uruchamiać kontenery Dockera, rozwiązywać problemy z integracjami ani przebudowywać wszystko po aktualizacji.

Dla wielu gospodarstw domowych podejście HC3 typu „ustaw i zapomnij” jest dokładnie tym, czego potrzebują.

Tak, HA oferuje więcej integracji i szybszy rozwój, ale to nie oznacza automatycznie, że HC3 staje się przestarzały.

Oznacza to po prostu, że oba systemy spełniają różne oczekiwania. Niektórzy użytkownicy oczekują maksymalnej elastyczności, inni systemu, który działa bez konieczności hobby.

Dla zaawansowanych użytkowników najlepszym rozwiązaniem okazuje się często połączenie obu systemów — HC3 jako solidna centrala Z‑Wave, a HA dla dodatkowych integracji.

Jednak stwierdzenie, że HC3 nie ma przyszłości tylko dlatego, że nie jest zgodne z filozofią HA, wydaje się zbyt dużym uproszczeniem.

Nie każdy chce lub potrzebuje tego, co oferuje HA, i jest to całkowicie w porządku.

 

I szczerze mówiąc, niczym się to nie różni od telewizorów. Nikt nie chce telewizora DIY z niestandardowym oprogramowaniem, nieograniczoną konfiguracją i eksperymentalnymi funkcjami.

Ludzie chcą telewizora, który wyjmują z pudełka, podłączają i działa. HC3 podąża za tą filozofią.

HA bardziej przypomina budowanie własnego centrum multimedialnego od podstaw — świetne rozwiązanie dla entuzjastów, ale nie jest to coś, z czym przeciętny użytkownik chciałby się mierzyć.

 

I agree with most of what you're writing about. We're just starting to live in an AI world, where when the user you're describing starts demanding something more—connecting a Tesla, Omoda, or other car to see its status from a nicely designed dashboard, and at the same time turning on the air conditioning and reducing recuperation—they can do it all from a single display panel, not five apps (because HC3 doesn't offer that)—then you start to wonder, like me. Access to sensors, which, for example, are non-existent (for example, show me a soil moisture sensor with a temperature of up to HC3 - I searched and couldn't find one) - of course, Fibaro promises that Zigbee will work smoothly from 2020 - over 6 years of BETA version - a version that only allows you to practically add sensors - you can't add switches, the mentioned soil moisture sensor, etc. - Every version of the system screws something up - breaks something - and often for the worse... since the NICE takeover - zero development creativity, zero acceleration in programming... - Ladies - I've been on this forum since 2014 and I follow who's doing what here - IF IT WASN'T FOR YOU - e.g. you or @Sankotronic etc.... this system would be crap... honestly

[Łukasz997 117]

2 godziny temu, wojtas810 napisał:

I've been on this forum since 2014 and I follow who's doing what here - IF IT WASN'T FOR YOU - e.g. you or @Sankotronic etc.... this system would be crap... honestly

Of course, everyone has the right to their own opinion. I think, however, that such total criticism of Fibaro is not really justified.

 

What bothers me the most in Fibaro right now? Definitely - the LACK OF COROUTINES. And the manufacturer’s assurance that they will not be introduced. That is a real shame.

As far as I know, this problem does not exist in Home Assistant. In other words, you have an asynchronous system, but you also have a tool that allows you to write code in a synchronous style (await).

 

The lack of coroutines is not something that immediately stands out, especially for non-expert. Everything seems to work exactly as it should. There are calls between QuickApps, events, timeouts. Only after some time you start to feel that something is not quite right - that a very natural way of thinking about a program is simply unavailable. It is about the ability to pause execution and return to exactly the same place when a response arrives.

 

The Fibaro model is entirely asynchronous. You send a request and move on. The response, if it comes at all, arrives through a separate channel, to some handler that has to know what to do with it. And this is, in fact, consistent with how the system works.  The problem is that this very quickly starts to affect the structure of the code itself. Instead of writing logic as a sequence of consecutive steps, you begin to split it apart. What should be the “next line” ends up in a callback or in event handler that has to reconstruct the context of the earlier call. 

 

How many things do you have to keep in your head at once!? The meaning of the whole program gets spread across functions, events, and state structures. The problem does not have to be complex for you to feel that you are no longer dealing with the problem itself, but with the execution model. And some things simply cannot be done at all.

The most irritating part is that Lua itself solves this problem. Coroutines exist precisely for this purpose: they allow you to pause execution, delegate control, and then return to the same place. The code can look linear while still being asynchronous underneath. But all (or... most!) of that disappears from the programmer’s view.

In Fibaro, this possibility simply does not exist. You cannot just “recover” the natural way of writing code, because you are forced into a continuation-in-callback model. In more ambitious approaches, people even build DSLs and pseudo-VMs to simulate the missing mechanism (it seems to me that this is how ER6 works).

 

But there has to be a cost boundary to this: is someone really supposed to build a VM for Lua in Lua just to use coroutines that are already there but blocked? That’s absurd.

 

It works, but the cost is real. The code grows, the structure becomes more complex, and MOST of the effort goes into managing the control flow instead of the actual logic.

That is why I believe the most important missing element in this environment is not another API function, but something much more fundamental.

The difference between code that has to be split into pieces and code that can be written straightforwardly is not just a minor convenience.

 

Maybe the manufacturer will eventually come to understand that.

Edited March 31 by Łukasz997

[JDF 0]

I completely agree with your assessment. Fibaro definitely hit a wall around 2018. I was working with their systems since 2014 too and watched the quality and support deteriorate significantly over the years.

The HC3 is essentially the same garbage as HC2 - no real improvements, just more bloatware and buggy firmware. The support is non-existent these days(They were useless in 2015 too when we tried to point out problems that never got fixed before EOL for the HC2), and the system feels like it's been abandoned by the company.

I wouldn't use it as a gateway either so i don't agree with cag014, it's not as stable as you think. The Fibaro ecosystem is dead.

[Brors94 115]

14 hours ago, L3n said:

Unfortunately, no. I can't switch to engine 3 yet.
Of course, I understand about battery-powered devices, but my situation is different.
In my case, it’s a relay + a S2 button switch that controls the light on another device via an association. 
I've been using this setup for over 10 years on HC2/3 in different rooms with various devices - dimmers, relays, etc. I'm used that there's a delay in this kind of setup. But I was really surprised when I tried the same setup with HA, where the second device responds almost instantly.

when going to HA did you have any old devices that you didnt bring to HA? 
by old I mean not 500 chip or newer. 
Since they make the z-wave network slow...
300chip is on 40kbit/s speed, but 500+ is on 100 kbit/s data rates
older is even on the 9.6...

So one old deivce "Choke" the rest btw 😅 As how I understand it**
 

[L3n 4]

58 minutes ago, Brors94 said:

when going to HA did you have any old devices that you didnt bring to HA? 

 

Sure. Most of my devices are old or very old devices running on old chips.

I still think the problem is with Engine 3 and that it's the one causing this speed, not the HC3 or HA. 

 

Please login or register to see this attachment.