A general reminder: Beta week is not designed to fully overhaul a new feature, but to identify bugs that may be introduced with the update.
If you have an issue, please let us know here! However, the developers are very active in the #beta channel of our Discord server during Beta - it's good to hop in there if you can. To ensure things are addressed in a timely manner, be sure to also submit issues on GitHub in their proper space:
Not yet listed in the release blog: Sun and Time triggers got a major update in automations as well.
Activity Logbook is now officially called Activity, and it's a timeline view. Very nice looking at a glance, and you can click into each one for more detailed views.
Instead of a long list of every individual item that needs to be updated on the Updates page, they are now grouped into cards which includes an Update all button!
Infrared and radio frequency continue to get some love this month with dedicated panels in Settings, just like the other protocols we support in Home Assistant.
New integrations this release are Aqvify, Chef iQ, Edifier Infrared, energieleser, Envertech EVT800, Greencell, Helty Flow, KlikAanKlikUit, and MELCloud Home. Great job for all the hard work these integration owners did to make it into this release!
We also added a few new virtual integrations: Avosdim, BWT, and Nexen.
Noteworthy improvements to existing integrations - Alexa Devices gained announcement and communication switches, SwitchBot got a couple improvements, GitHub now has entities to track user accounts, Environment Canada gained a new action for get_alerts, Droplet will report leak alerts, Yoto was introduced last release but already has a ton of improvements, openSenseMap exposes environmental measurements in sensors, Green Planet Energy has actions to find the cheapest stretch of energy prices, and a truck load more. Check out the full list to see if your active integrations received some improvements this month.
We had 7 integrations achieve new quality scale levels - 1 reached Platinum, 2 reached Gold, 3 reached Silver, and 1 reached Bronze. Nice job getting these moving up the quality scale, devs!
We did a bit of cleanup and say farewell to some very outdated integrations.
Other noteworthy changes - a faster frontend most notably for energy, history, and statistics graphs, device and area pages use a responsive column layout, scene editor has more context, Apps store now has tags, tune each entity from a new sub-editor for the statistics graph card, improved status icons for conditions, hide the Device and Area columns on the States tab of the Developer tools, Matter soil moisture sensors show up now, media players have a projector device class, template lights gained xy color, Google Assistant will let you clean a specific room, Raspberry Pi firmware has a new update entity, improvements to the template engine means they render up to 40% faster, and automation traces now always includes template errors.
The list of integrations impacted by backward-incompatible changes includes renaming of entity triggers and conditions as we update the automations, iCloud, Reolink, Zeroconf, Z-Wave JS, and a handful more. Check out the full list to ensure that you're not impacted before updating.
That's normal. You're choosing the entity in the first screenshot, and the device in the second. The target yaml option works the same way as it has with actions. Meaning it can target devices or individual entities.
what entities reside in that device? Are they properly created entities? I.e. do they have device_classes, unit of measurements, etc.
There's alot that goes into that and I don't know the specifics.
Yes, but from the device it has to find the entity based on the trigger type and if you have multiple entities that it finds, you'll get multiple things that are triggering it. Just like if you target a device in a switch.turn_on action and it has 2 switches, both switches will turn on.
So, this is saying that ANY power measurement above that value on that device will trigger?
That is, it's watching state changes on each entity?
triggers:
- trigger: power.changed
target:
device_id: 3bfe11cce947a150e691c5a3085b4cf3
options:
threshold:
type: above
value:
active_choice: number
number: 1500
unit_of_measurement: W
Is it using device ID so that if, in the future, the devices adds additional power meters those will also trigger? Not sure I'd expect that to happen as could be unrelated to the purpose of the automation.
And, as I understand it, if you use an 'area' instead of a device or entity any devices you assign to that area would be automatically picked up by the automation.
Or perhaps more useful, using labels -- it's much more likely I want to trigger on something happening to a member of a group, for example leak sensors that are not in one area. That involves explicitly adding or removing entities as members of a label.
It's a bit odd to trigger on a device. Maybe it's mostly ESPHome where a single "device" might be sensing different, unrelated things and that is more likely to change. Having an old automation magically start triggering on an addition to the ESP device might be a surprise. It's not very clear that can happen.
That is what I've been doing for some time now, they're super useful to me. Like you, I'm just trying to understand the new purpose specific stuff. I've steered clear until now because changes kept getting made to them and I didn't want to have to continually adjust until they were ready.
Yeah, that's good advice. My ESPHome devices often start off as one-offs and then I just add more things over time. I should always just start with a virtual device.
Still, I can't imagine using device IDs, though, since I do almost everything in packages. I want to be able to read what it is. That said, ESPHome is good at re-using device IDs when you replace an MCU, but z-wave not (for now?).
Title: Alexa Media Player config flow fails on Home Assistant 2026.7.0b1 ("Invalid flow specified")
After upgrading from Home Assistant 2026.6.x to Home Assistant Core 2026.7.0b1 (Home Assistant OS 18.0), Alexa Media Player (v5.15.4) no longer allows reauthentication.
The integration detects that the Amazon session has expired and logs:
Reauthenticate on the Integrations page. Relogin required...
However, when clicking Reconfigure or Reauthenticate from the Integrations page, Home Assistant immediately returns:
The config flow could not be loaded: {"message":"Invalid flow specified"}
The authentication flow never starts, making it impossible to log back into Amazon.
The logs also report new asyncio blocking warnings from Alexa Media Player:
Detected blocking call to open
Detected blocking call to load_verify_locations
These warnings originate from the Alexa Media Player custom integration after upgrading to Core 2026.7.0b1 (Python 3.14).
Environment
Home Assistant OS: 18.0
Home Assistant Core: 2026.7.0b1
Supervisor: 2026.06.2
Frontend: 20260624.0
Alexa Media Player: v5.15.4
The integration was working correctly before upgrading to Home Assistant 2026.7.0b1.
This appears to be a compatibility issue with the current beta, as the reauthentication flow cannot be created and Home Assistant reports "Invalid flow specified."
welcome to the forum...........
couple of points on your post
A) this is a custom component and not related to Core at all....issues with any custom component should be raised in that component's thread and/or GitHub repository as they'll not get attention here
B) Alexa Media Player v5.15.5 is released with a note about compatibility with the 2026.7 release so you prob need an update here
I suggest installing the Alexa Devices integration and using that instead - much more stable with the same functionality and built into Core. Someone else ran into this in Discord and switched over to the Core integration, now they have no more issues.
Not currently mentioned in the beta release-notes is that all the libraries for the ZHA (Zigbee) integartion has been bumped to 2.0.0 version because they contain a major update with a huge change where the Quirks API for ZHA Device Handlers is now fully revamped which is first step to make adding support for new Zigbee devices simpler so that the ZHA community can support advanced/complex devices more quickly:
"Our quirks API is now fully revamped: complex ZHA entities can now be created entirely within with quirks, allowing for faster community support of new devices and new complex devices."
For reference, the first major step towards improving zigpy/zha APIs to make adding new devices simpler so that the ZHA community can support new devices more quickly. See that this is also raised and tracked as an Open Home Foundation roadmap item too:
@MissyQ IMHO it would by the way also be good to make a new dedicated Home Assistant blog-post to high-light this major change ZHA And then also make it a dubble-whammy by announcing Open Home Foundation's fully open-source host-side Zigbee stack, Ziggurat that is not mentioned in the release notes either but is now in public beta and possible to use with the Home Assistant 2026.7 release and later. Ziggurat can replace closed-source Zigbee Coordinator firmware on any Zigbee adapter with OpenThread RCP (more info) and runs inside of a Home Assistant app. Ziggurat is not yet mature, but it is 100% open source, very fast, written in safe Rust, and lets your Zigbee network benefit from the computing power of a general purpose computer.
).
That's right, creating automations just became easier, natural, and more powerful. And no, you do not need to rewrite anything. YAML is still there for you, if that's how you like building your automations, too.
And then also make it a dubble-whammy by announcing Open Home Foundation's fully open-source host-side Zigbee stack,