Are you telling me that your Wife should be able to make an automation, without an Admin-role ? Or are you trying to say that you haven't figured out how she in an easy way can turn down the heat in i.e the Livingroom ?
Lets take this to another thread please
3 Likes
I've carefully read the above speculations about the functionality of the new version of automation, and I've come to one conclusion. I admire people who inflict self-harm, trying to convince themselves how wonderful the current automation solutions are. The truth is, unfortunately, that they are simply weak and unintuitive. There's a saying that "where Cook 6 is, there's nothing to eat." The system should have a single administrator who knows its architecture and operation perfectly, understands the principles of automation, and is the one who decides how, where, and when things are to be done without their knowledge—that is, automatically. Attempting to provide such options to those unfamiliar can only mean one thing. Let's be honest, Smart Home isn't, and never will be, for everyone to play the director's game. Those who don't have a clue about this topic should spend their free time building the Eiffel Tower out of LEGO bricks instead of creating automation. And entrusting your home to AI mechanisms is a whole new level of madness.
3 Likes
By reclassifying 0,0 as a “valid” map coordinate that must be rendered, the developers have forced a scenario where:
-
Ghost Markers in the Ocean: Users now have active markers plotted in the middle of the Atlantic Ocean, hundreds of miles from any civilization. This serves zero practical purpose for a home automation dashboard. No user is tracking a package delivery to a buoy in the Gulf of Guinea.
-
Breaking Established Norms: The change ignores the entire history of GIS development where
0,0is explicitly used to catch errors. Instead of fixing the map card to filter these obvious errors (as professional GIS tools do), the developers chose to display them, prioritizing “technical correctness” (it is a valid coordinate pair) over “practical utility” (it is never a real home location). -
Forced Workarounds: The result is that thousands of users must now implement complex template sensors or conditional logic to achieve what was previously free: the ability to say “this entity has no location.”
The insistence that 0,0 is a valid location for a smart home map is akin to insisting that a “blank” text field must display the word “NULL” instead of remaining empty. It is a solution in search of a problem that creates a new, absurd problem: populating user dashboards with markers in the middle of the ocean. The fact that this coordinate is physically impossible for any home device to occupy makes the developers’ refusal to treat it as a “hide” signal not just technically rigid, but practically nonsensical.
You’ll have to provide more information. 0,0 has always been valid in home assistant from day one. The change you’re referencing may be coming from the entities you’re using, not home assistant as a whole. Can you please provide the integration that is now producing 0, 0 for lat/lon?
You are correct that 0,0 has technically always been a valid coordinate pair in Home Assistant. The issue is not that the validity of 0,0 changed, but rather how the Map Card in the 2026.4 frontend update handles the rendering of entities with those coordinates.
- Previous Behavior (Pre-2026.4): The Map Card contained an implicit filter that treated
0,0(Null Island) as an invalid or “empty” location for the purpose of visualization. If an entity hadlatitude: 0andlongitude: 0, the card would silently skip rendering a marker for it, effectively respecting your “hidden” programming. - Current Behavior (2026.4+): The frontend refactor removed this implicit filter to adhere to strict data validation. The logic now dictates: “If an entity has
latitudeandlongitudeattributes, plot them.” Since0,0is a valid coordinate pair, the map now faithfully renders a marker there.
The integration producing the 0,0 coordinates has not changed its output. It is still sending 0,0 exactly as it did before. The change is entirely within the Home Assistant Frontend (Map Card) which now refuses to hide those coordinates automatically. This used to be a programmers “trick” as a quick way to hide a marker off the map for whatever reason and required no overhead. You are trading a zero-cost native behavior (ignoring 0,0 ) for an active, resource-consuming workaround (Template Sensors) to achieve the exact same visual result.
Do you have a link to the PR that changed this behavior?
Basically what I’m getting at here is: This is most likely a bug and you’re posting large complaints assuming this was done on purpose. It looks like it’s just an oversight made in this PR. The removed code just checked for lat/lon and 0 is a truthy value meaning false. The new code checks for numerical values. Then again, I could be reading it wrong as I’m not a front end dev.
There is no PR as this is likely an unintended conseq uence of just cleaning up code when the map card was looked over to remove any “magic” last month. :
- Previous Logic: The old card had a hidden check:
if (lat === 0 && lon === 0) return;(Skip rendering). - New Logic: The refactored card treats all entities with
latitudeandlongitudeattributes as valid data points to be rendered, adhering to the principle that “0,0 is a valid coordinate.”
There’s a small issue with the decimal separator in Firefox. When changing a value using the up/down buttons or the arrow keys, the decimal separator changes from the appropriate language-specific separator (e.g., a comma) to a period. This can be observed, for example, by creating a numeric helper with a step size < 1 and changing the value as described above.
I use Firefox and Brave - Brave is not affected by this bug. Core ver. 2026.7.1
Check if it’s reported here, otherwise log it:
1 Like
That is a scary thought! I also use UPB - I have about 65 devices - and the UPB technology is still probably one of the best going in the home automation world. The thought that it could be discontinued some day is terrifying!
Nobody else with this issue? Found some additional logs:
Logger: homeassistant.helpers.script.websocket_api_script
Quelle: helpers/script.py:2197
Erstmals aufgetreten: 10:58:02 (1 Vorkommnis)
Zuletzt protokolliert: 10:58:02
websocket_api script: Error executing script. Error for call_service at pos 1: Another command exists for the same parameter : close
Logger: homeassistant.components.websocket_api.http.connection
Quelle: components/websocket_api/connection.py:331
Integration: Home Assistant WebSocket API ([Dokumentation](https://www.home-assistant.io/integrations/websocket_api), [Probleme](https://github.com/home-assistant/core/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+websocket_api%22))
Erstmals aufgetreten: 10:58:02 (1 Vorkommnis)
Zuletzt protokolliert: 10:58:02
[546582384608] Error handling message: Another command exists for the same parameter : close (home_assistant_error) User from 192.xxx.xx.xx (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.5.2 Safari/605.1.15)
And here the actual yaml of the action step within the automation (…which I did not modify, I’m a GUI-Guy 
)
action: cover.close_cover
metadata: {}
data: {}
target:
area_id: dg
How will this go further? Is this something that will be resolved in a 2026.7.x release?
Seems that energy was fixed 2026.7.2, but Gas has legend still missing
2026.7.2 Spanish translation fails in all the integrations, reverted to 2026.7.1 Why?
Okay, to join /dev/null here: I now had time to actually interact with the new automation system.
As said previously, I can see the vision there, but.. oof.
This new automation feature is not ready to the degree that would warrant making it this default.
Arguably, it might never be (though feel free to prove me wrong there).
You’ve introduced a whole new mental model of how automations should be, which happens to be worse at being precise and deterministic, because it assumes that the system will (and, implied, even can) be smarter than its operator.
They’re effectively “magic” you’re supposed to trust that they will “just work”, and that will be amazing if they actually, do, but if they do not, they will likely fail in a way that is utterly opaque.
Which is worrying, because that’s a complete philosophy swap.
You’ve thrown in an entirely different engine, essentially.
Which also means that I cannot adapt to it by just patching the UI editor in my local setup.
But I can also not adapt to it by patching my own mental model, because this one is objectively worse at the goals of a deterministic and precise automation engine and tool.
I know that someone is probably going to say “just give it time while the kinks are ironed out”, but you cannot iron out kinks out of a different philosophy. Those kinks are that philosophy.
Long story short:
This is a significant downgrade (and not just because new = bad). It is not an extension but something new and I have my doubts that the trade-offs are the right strategic choice here.
Long-term, anyway.
Or maybe it is, but not for Home Assistant as the software we’ve known, but home assistant the bureaucratic entity interested in self-preservation.
I suppose in the grand scheme of things, one could argue that for a normal person (you known. The ones not thinking in primitives), HA is still a positive force in the space.
And that is true. But it is also a different goal.
Or at least I think it might be. Feel free to tell me that this was the goal all along and I just misunderstood previously.
Either way, I am curious what the future now holds.
Because you cannot have it both ways at the same time.
Long-term, anyway. But there’s a lot of substance, so it might take a while.
Super TL;DR:
Assuming that a machine could be smarter than its user is (IMO) wrong.
The rest I’ve said (or could say) is just that but explored with more concrete stuff.
Which does make me wonder if the current AI boom has anything to do with that belief, because the story told by those labs is the same.
1 Like
It’s not the default though. All the previous triggers are accessible from the first page without choosing a new tab. They are in the left tree under unassigned.
You can also get to them from by type tab under generic section
4 Likes
Version 2026.7.2 changed the language of the sensor statuses and native applications from Spanish to English, even though the entire system is set to Spanish. How can I fix this?
1 Like
Continuing the monologue no one asked for or cares about:
I do believe that there is room for specific triggers that are shorthands for common uses, eliminating the usual HA footguns that come with working with primitives.
Community blueprints I think were conceived in that spirit, and, this new way of building automations arguably is a spiritual continuation. Or could be that.
Howevever, the way it is sold, understood as and implemented right now is simply not that.
All the writing and UX funnels the user towards a lossy abstraction, solving problems they might not have in ways that introduce new ones.
While, simultaneously, treating the real tool for the job as this legacy something stashed away somewhere in a hidden box.
It is not legacy though. The new thing is just syntactical sugar that comes with severe trade-offs unfixable, because they’re inherent to the concept of a lossy abstraction hiding complexity.
My prior comment might’ve been too fatalistic in the sense that I took public communication as actual reality.
In reality though, I have no idea how the internal engineering team feels or thinks about this. I just see the public facing part (and that one is broken).
Assuming that there is an internal disconnect like that, this thing could also just be a power struggle in which I am rooting for the engineering team.
If that assumption holds, then this could hypothetically be recovered by shifting the balance back to a stable position.
If there is an agreement that there is something that needs recovering and is currently in an unstable unbalanced state that is.
But idk maybe I just have no idea.
Edit:
FWIW, contrary to what I’ve said before, I can in fact (for now at least) greatly reduce the impact of this through a rather small patch:
“By type” is the default.
Purpose-specific triggers still exist but are pushed down.
The actual logical blocks are back at the top.
I know that you were happy to get rid of the “expert mode” user toggle, but this would be exactly where one would be super useful to not piss off either of the two distinctly different target audiences.
You will absolutely again need such a toggle if you want to both gain further market share and not lose the one you’ve already got.
Seems Voice Assist Intents are no longer working, particularly if custom sentences are used. I have written up an issue, but so far, not getting much love 
1 Like