So you never reset your password anywhere? I often forget to save my password and then I reset it when I need to log in again on the mobile app for the device, but then Homey can’t log in anymore so I need to change it in Homey. Repair function is very useful for this
No, but even if I would, almost every HA integration allows you to reconfigure it (like updating credentials), which is similar to repairing.
No.
First, all my passwords are stored in Apple Passwords/iCloud Keychain. Apple devices automatically detect when credentials are entered or changed and store them securely in the Keychain, which is synchronised across all my devices using the same account.
So no, I simply don’t lose passwords.
Second, I always use a self-developed algorithm to generate passwords. The algorithm exists entirely in my head, and for a given site, device or service I can regenerate the same password again whenever necessary.
But the most important point in my smart home is that I primarily use local Matter devices. There is no device account password to remember at all. The credentials are handled by the system.
What surprises me most is that you, as someone who strongly advocates cloud solutions, apparently consider forgotten passwords and password recovery a normal part of the equation.
That is exactly one of the things I want to avoid.
Password recovery pages sometimes stop working, services get discontinued, manufacturers abandon products, and websites disappear completely. Depending on such an external service for access to a device is not what I would call particularly robust or secure system design.
So for me, “you can reset the password in the cloud” is not an advantage. It is a dependency I prefer not to have in the first place.
One example is my air cleaner.
It is available through a cloud integration, but I deliberately don’t use that integration.
The air cleaner is connected to a smart plug. When a window is opened, the plug is switched off. When the window is closed again, the plug is switched back on.
For air-quality measurements, I use a separate local Matter sensor.
So the device may offer cloud control, but for my actual automation I simply don’t need the cloud at all.
Embrace AI guys. I have now been intensively working with it for a couple of months and it will trigger a backup, reconnect devices (or whatever has to be done) in HA and repair entity names afterwards if necessary.
It even checks the source code (open source rulez) of new integration versions to judge if it is safe to update.
And it has never failed on me so far and should it fail some day I have a backup, that is easy as to restore on HA. - With the latter being another hughe plus over Homey.
It’s not that I forget my passwords a lot, everything is saved in Samsung Pass usually, though sometimes it isn’t and I forget it, which means that I need to reset the password.
But I often don’t create accounts on my phone, I actually create them on an Android emulator, usually before I even have the physical device. I do this to make sure that it’s possible to reverse engineer an Android app, in order to build a Homey app for the device. By knowing how the app logs in, and how it connects to the realtime communications channel (MQTT, WebSocket or a custom TCP protocol), I can better understand the protocol before buying the device, to make sure it doesn’t use any captcha’s or other security that would make it impossible to build a Homey app for the device.
Since this Android emulator doesn’t have Google Play, I download some of the apps from sketchy APK websites. Since I don’t trust these APKs, I just use a random password that I know will not be re-used anywhere. When I paired the device successfully and finished the Homey app for the device, I just end the session on the emulator by logging out, and then reset the password to make sure it isn’t compromised.
Since I buy some devices specifically for building Homey apps (sometimes I don’t even use the device at all, only to build the Homey app for it), this is the standard workflow for new devices.
As you might know, my entire smart home runs via the cloud. Everything is routed via the cloud, also Zigbee devices since those are linked via the manufacturer’s gateway. So to “simply not use the cloud” is not an option in my case, everything runs there.
But this is getting way too off-topic it seems
I believe it is.
At the moment, Claude only has read-only access to my Home Assistant installation.
I want to remain the master of my automations, mainly because I still want to understand how everything works.
At the beginning, Claude generated YAML that worked perfectly, but when I opened the automation in the visual editor, I ended up with lots of template blocks containing Jinja and YAML.
One of the big advantages of Claude, however, is Projects.
I created several text files with instructions for Claude. One of them is an architecture.md file that defines how I want my HA configuration to be structured.
One of my first rules was:
Avoid Jinja and YAML in the visual editor.
That worked very well.
But at some point Claude wanted me to create around 10 Helpers just to avoid about five lines of Jinja. That made me realise that blindly avoiding templates can become counterproductive.
So I changed the rule.
Now it is roughly:
Avoid Jinja and YAML in the visual editor wherever reasonably possible. But if more than two Helpers are required just to avoid one small Jinja block, use the Jinja template instead.
That works much better.
As a result, I now have very few places where Jinja is visible in the automation editor, while still avoiding unnecessary Helpers.
I will probably give Claude write access at some point, but with very strict limits defined in an access_rights.md file.
Until now, the AI has followed my instructions remarkably well.
For example, replacing a device could become a controlled AI task:
-
read and store the old Entity IDs
-
remove the old device
-
pair the replacement
-
rename the new entities to the old Entity IDs
-
verify that the existing automations still reference the correct entities
That is the kind of maintenance task where AI could become extremely useful.
What Claude can already do with Home Assistant for about €20/month is quite impressive.
A recent example:
I had a Shelly where a light did not turn off as expected.
Claude analysed the logs and traces and reconstructed what had happened:
-
the Shelly itself never became unavailable
-
the automation sent the command to turn the light on
-
the timer ran
-
afterwards, the automation sent the command to turn the light off
-
but the original “turn on” command had never been confirmed properly by the device
-
because the automation was running in
singlemode, the whole sequence ended up in an unexpected state
Claude identified that very quickly and immediately proposed a more robust automation that also handles this kind of failure.
Without that analysis, I would probably still be searching for the cause manually.
And this is where Home Assistant has another major advantage: it exposes enough information for an AI to actually diagnose what happened.
With traces, logs, entity states and configuration data, the AI has something concrete to work with.
Homey’s logging is much more limited. And if the system does not expose enough diagnostic information, even the best AI cannot magically reconstruct what happened.
For me, that combination of deep diagnostics + AI access is becoming one of the most powerful aspects of Home Assistant.
Yes, but that is also because you are a long-time Home Assistant user.
Newer versions of HA effectively give you two different ways to build automations:
- the traditional way, using entities
- the newer, more Homey-like way, using devices and their available triggers, conditions and actions
Both approaches have advantages and disadvantages.
The important difference when it comes to device replacement is that a device reference is tied to the device’s unique internal ID.
If you remove a device and pair it again, it gets a new device ID. Any automation that directly referenced the old device may therefore break.
Entity IDs, on the other hand, can be renamed.
Fortunately, at some point I asked Claude how I should design my automations if I wanted device replacement to remain manageable.
Its recommendation was very clear:
Don’t use device references where you can avoid them. Use entities instead.
At that point, I had already used device references in roughly ten places, so I changed those automations to use entities and added a rule to my HA architecture guidelines:
Use entities, not devices, in automations whenever possible.
That way, if I replace a device, I can give the new entities the old Entity IDs and the existing automations continue to work.
So HA gives you the convenient Homey-like device approach, but for long-term maintainability I now deliberately prefer the older entity-based approach.
Long-time users are generally accustomed to using entities, while new users may naturally choose devices without realizing the implications for future device replacement. Understanding that difference is therefore important.
This is why every seasoned HA user will tell you not to use devices for automations. I never use devices, always entities, but that’s also because I write all my automations in YAML directly. The automation UI does prefer to use device id’s, from what I can see.
Not really. The visual editor offers both approaches quite naturally.
But most consumer-oriented smart home systems, including Homey, are built around devices. So new Home Assistant users coming from those platforms will probably choose device-based actions without necessarily realising what that implies for future device replacement.
I still prefer the visual editor.
One of the main reasons I originally bought Homey was that I hoped someone in my family could maintain the system if I die or am no longer able to do it myself.
But over time I also realised that Homey automations can become complex enough that nobody else may really understand them either.
With Home Assistant, I have now arrived at a different vision.
I don’t expect my family to understand the complete system. Instead, I want them to be able to maintain it with the help of AI.
Using Claude, they could make many changes simply by describing what they want in natural language.
That is also why I am creating architecture, rules and instruction files that clearly define how the system is structured, what Claude is allowed to do, and what it must never touch.
For me, AI may eventually become the maintenance layer my family can use — but only within clearly defined boundaries.
OTOH, flows are mostly built around capability changes, which is comparable to triggering on entities.
I think we are looking at this from slightly different angles — or simply using different definitions. 
For me, this is the device-based approach:
You select a device and Home Assistant then offers the triggers that belong to that device, such as battery changes, opening, closing, etc.
That feels very much like the Homey way to me: select a device first, then select one of its available capabilities/events.
In contrast, this is what I mean by the entity-based approach:
You just get triggers for that entity.
In the visual editor, both triggers do the same thing, but are also shown slightly different.
In YAML the difference becomes even more apparent:
The first one references a device_id, while the second one references the actual entity_id.
So yes, capability-wise they may be comparable, but from a user’s perspective I still see the first approach as the more Homey-like one.
I’ve had HA for three months now and built just one automation
The UI is truly painful to use and every function frustrating to learn to operate and I don’t see it ever improving. We shouldn’t have to learn YAML, just to add shortcuts to basic functions in the sidepanel
I don’t understand how anyone put up with this before the advent of AI
I wouldn’t call the UI truly painful.
There are very few systems that offer the same level of power. Hubitat may come close in some areas, but its UI is certainly not easier.
For simple automations, Home Assistant’s visual editor is actually quite straightforward. It becomes more complex when you start pushing the automation engine much further.
I wrote Flow Gadgets for Homey, which adds a lot of powerful Flow cards. But that power also comes with a learning curve, which is why I maintain an online manual for it.
In Home Assistant, I can achieve much of the same functionality with Helpers.
The same applies to my Chronoflow app: I was able to reproduce roughly 85% of its functionality in HA just by combining Helpers and native functionality.
And that is the big difference for me:
You can build these extensions yourself without waiting for a developer to create an app for you.
Of course, once you push the system that far, it requires some effort and learning.
But believe me, it is still considerably less effort than writing and maintaining an entire Homey app.
Where does the power of Home Assistant end?
Today I discovered another concept I hadn’t used before: Packages.
I asked AI to build a rather complex system to calculate how much CO₂ my solar installation actually saves compared with the same house without solar.
The calculation includes several parts:
-
I use an API that provides the current CO₂ intensity of the electricity mix from the grid.
-
I calculate how much CO₂ my electric car saves compared with an equivalent combustion car, including charging losses.
-
I calculate the CO₂ benefit of the solar electricity I export to the grid.
-
And all of this is accumulated into useful statistics that I can display on my dashboard.
My first question to the AI resulted in a proposal involving 32 Helpers.
That seemed a little excessive, so I asked:
“Do I really need 32 Helpers for this?”
The answer was: no.
Instead, Claude proposed using a Home Assistant Package.
A Package can bundle multiple Home Assistant configuration components into one YAML file. In my case, it contains the sensors, calculations and Jinja templates required for the complete CO₂ model.
So instead of manually creating 32 Helpers, I ended up with one self-contained file implementing the whole calculation.
And after adding it to HA, my dashboard suddenly had all the resulting values available for cards, statistics and graphs.
Wow.
Yes, at that level you are back to YAML and Jinja.
Normally I consider that a disadvantage and try to keep both out of my visual automations wherever reasonably possible.
But this is a very different use case.
Claude created the complete package within minutes, and I don’t have to maintain dozens of Helpers manually. The logic is contained in one place and works like a charm.
For me, this shows another interesting side of Home Assistant:
You can start with a completely visual system.
Then you discover Helpers.
Then Scripts and Templates.
And if what you want becomes too complex even for that, you can bundle an entire functional subsystem into a Package without having to write a full integration.
At some point the question changes from:
“Can Home Assistant do this?”
to:
“Can I describe precisely enough what I want it to do?”
And with AI generating the more technical parts, that boundary moves surprisingly far.
I am actually convinced, that Home Assistant is by far the superior System. But this here is “just programming” and can most likely be done in Homey Script (or even with the new Python API?) just as well. - So, not a real advantage for HA as it seems to me.
Give Claude access to the necessary ressources in Homey ( [APP][Pro] MCP AI Bridge - Control Homey with any AI assistant (Claude, ChatGPT, Gemini, Copilot, Cursor or Mistral) via the Model Context Protocol highly recommended) and it will probably do the same there.
Wait, what does this have to do with Homey? Your post doesn’t even mention it at all! I think it’s better to post it here in that case.
Using YAML (yet another markup language) doesn’t mean you’re programming, just like using a Homey Logic card that support calculations isn’t programming either. Jinja templates are similar to the Homey Logic calculations, but much more elaborate.
Homey has no real equivalent to YAML, Jinja templates, and/or packages.
HomeyScript is real programming; the Home Assistant equivalent is using Python scripts (or pyscript), and I’m sure 99.999% of HA users never use them.
Homey apps are miles above that in terms of complexity. The HA equivalent for those are integrations.
for me, besides that it compliments each other in ha integrations vs homey apps , i started to like the ha dashboard . for the moment, i use primary homey dashboard with webframes to ha dashboard tiles, but i guess i will move completely to ha dashboards. before , the yaml code behind the tiles was a bit of a pain, but thanks to claude, it generates the yaml exactly for each tile /widget based on my spec. below is my hybrid homey dashboard (part of) running on an old ipad for my walking pad.
yes, i know, i should change the minimum hr or auto remove the gauge when the hrm is not connected, else it shows a very critical issue with 0bpm
Dashboards in HA are in another universe compared to Homey. I can only recommend to go for it.
However, get a little help from AI and you´ll have your dream dashbards up and running in a matter of hours. - And that includes things like protecting functions or (sub)dashboards with a PIN, which Athom has been refusing to even consider ever since the introduction of their Dashboards.
Claude Opus 5.5 does an outstanding job and there is a very good community integration / MCP server available for HA.
Building Dashboards in Homey on the other hand is not even made available through an API. So no AI support there.
Score on this one: HA 3 - Homey 0
It has everything to do with the comparison.
I didn’t mention Homey because, as far as I can see, Homey simply has no real counterpart to this concept.
Of course I could say that Packages are something I would like to see in Homey, but I honestly don’t even know how Homey could implement the same idea without changing some fundamental concepts.
Home Assistant’s configuration and automation layer is heavily based on YAML and templates, so Packages fit naturally into its architecture. Homey cannot simply copy that approach.
I don’t think that is really the same thing.
YAML is not a programming language. It is a structured description format.
Most of the time, you are essentially describing things such as:
-
Which entity is involved?
-
Which state or value should it have?
-
Which action should be performed?
-
Which parameters belong to this object?
That is very different from HomeyScript, which is JavaScript-based and therefore actual programming.
Here is a simple example of a Helper defined in YAML:
input_number:
energie_referenzleistung:
name: Energie - Referenzleistung
min: 3
max: 100
step: 1
mode: box
unit_of_measurement: kW
icon: mdi:transmission-tower
You don’t need to be a programmer to understand what this does.
It defines an input_number with:
-
the entity ID
energie_referenzleistung -
a minimum value
-
a maximum value
-
a step size
-
a unit
-
an icon
The same Helper can also be created through the graphical interface.
The difference is that inside a Package I can define this Helper, then define the next one directly below it, then sensors, templates, calculations and other related components — all together in one self-contained configuration file.
That is the real advantage.
Jinja is a little different. It is a template language and does contain programming-like expressions, so yes, there is some logic involved.
For example:
netzanteil: >-
{{ [bezug | float(0) / last | float(0), 1] | min if last | float(0) > 0 else 0 }}
You do have to understand or learn the syntax.
But conceptually, this is still just an expression saying something like:
Divide one value by another, limit the result to a maximum of 1, and return 0 if the denominator is not greater than 0.
That is quite different from writing a complete JavaScript program in HomeyScript.
So yes, Packages can contain code-like logic.
But reducing them to “you can do that in HomeyScript” misses the important part: Packages are a native way to bundle Helpers, sensors, templates and configuration into one reusable subsystem inside Home Assistant.
