Thanks for the release. No issues updating here so far.
Could I ask you to rewrite this sentence in the release notes? I've read it 3 times but don't understand it.
Those the triggers
entered_homeandleft_homeas also the conditionsis_homeandis_not_homegot removed from the Person and Device Tracker.
I would like some detail about how to use the new RF capabilities compared to what I've already got - if it's useful at all.
I understand that the IR and RF integrations are an entity type that other integrations use; I wouldn't set them up directly.
I have a Broadlink RM-Pro that I've learned RF commands with to control my RF ceiling fan. It works. What does the new RF integration add that would improve this for me? (Don't say, "if it works, don't fix it".)
I think this could be helpful for those of us who have working IR and RF and would like to know if/how we can leverage the new integrations. Thanks!
In the previous version of the "Purpose-specific Triggers and Conditions" Labs feature there were triggers and conditions for the person and device_tracker domains. Some examples of those would be:
Triggers
device_tracker.entered_homeperson.left_homeConditions
person.is_homedevice_tracker.is_not_homeThose were removed in this version and will be replaced in a future version by triggers and conditions that cover both domains.
One of the things that grabbed my attention was this throw-away:
I know, I know, “documentation” doesn’t exactly scream headline feature.
Documentation is one of my bugbears in HA. Way too much HA documentation assumes a much higher knowledge of Linux and coding than I have. Basically you get told "To turn on the light, turn on the light". If not for some of the great help from Mods and more experienced users in the forum, I'd give up or not know a lot of possibilities. Am I alone here?
An update to the templating documentation is a big thing.... IF it is done properly. I know some of the old hands working in this area get frustrated (sometimes with good reason), but it is part of the learning process and brings more users into the fold.
I'm with you here. I use the Broadlink RM-Pro, and the Sonoff Bridge to send RF commands and in the case of the Sonoff to also receive 433mhz sensor info via RTL-433. At a quick glance I am not sure how the changes give me anything new, other than to repackage things I already have via scripts and automations.
Exciting new features.
I'll be taking a look at the new serial support. Until now, I have been running Infinitive on 2 Raspberry Pis, each with RS-485 interfaces to my Carrier furnace & heat pump. The Pis each need their own maintenance (OS updates and so on). If the network serial support is adequate, I could an ESPHome device, and run Infinitive as a container app within HAOS. Not sure if it will work properly with timing or not, but I will try.
My UHD65 projector also has an RS-232 interface, and it sounds like ESPhome serial should come in handy to automate it as well.
The new automation features "do xxx if yyy state lasts for more than xxx minutes" sounds very useful to me. I have had to write very complex state machine automations to implement a proper vacancy switch. The edge cases are the hardest, though, especially when there is no state change, ie. light is on when HAOS starts, and motion sensor state is already off. The light still needs to turn off after x minutes of no motion. The other major difficulty was implementing the reactivation feature, if motion is newly detected shortly after the automation turned off the light. I will try to see if it's possible to implement this through GUI now.
How is the trigger/for and condition/duration implemented under the hood?
I have a lava lamp on a smart switch and I've got an automation to turn it off if it's been left on for 9 hours because much longer is bad for the wax.
But in order for it to be reliable I had to set up datetime entities to track the actual time it was turned on, because last_changed can flap if the state changes to unknown and back if there's a network issue or HA was restarted.
If all this new functionality is just sugar on top of last_changed I'm not sure it will be as reliable as someone may expect.
Why do you always "hide" the breaking changes in the accordian boxes? The rest of the release notes can be fully read without having to click on anything to "reveal" the answers, except for the breaking changes? Surely it's more work for you to do this formatting than it would be if you just formatted them like the rest of the release notes? Frustrates me having to click through each one just to make sure I haven't missed something. It's the one part of the release notes that I make sure I thoroughly read each month!
RS-232 is very cool! I wish my AMP has RS-232 now! 
The new built-in Maintenance dashboard
I recently added a section of my battery devices on my custom dashboard too.
The new shortcut card
At first I thought that we finally have popup window card..
Your timers got a whole lifecycle of new triggers: started, paused, restarted, cancelled, and finished
This is cool, but what about timers cards and timers integration?
Also alarm clock card when? 
Then new maintenance dashboard showing batteries is really nice, but it completely disregards devices with binary_sensor battery entities that just show "normal" or "low"
My use-case supports the accordion style. I scan these as headings, and only expand the ones I have installed. If there's a breaking change with, say, the Norwegian weather integration, I don't need to scroll past it to get to the rest.
At least for me, the selective accordion style is good.
Personally though, I would like it before the "Need help?" section, which feels like the default (same for every release) ending. Breaking changes is much more specific and important so should be higher before I feel like I'm finished reading.
That’s a good question. Depending on that, you want or don’t want to use it for long-time durations …
Is it annoying anyone else that the new toggle style is no longer right aligned with any sensor values? It's triggering my OCD… 
Do we know why the tile card feature to display the hourly forecast has been removed from this release?
Actually I am more triggered about the color of the toggle. IIRC previously it was matching the default "off" state blue. The new light blue style does not blend in with the rest of the UI anymore... Have not noticed the right alignment offset until now - and now I cannot unsee it 
And now I can’t unsee the different blue…. 
I don't know if I am the only one but, making cards after new update feels laggy...
Really like the new maintenance dashboard 
One issue I came across is the settings screen telling me that some bluetooth permissions thing isn't set up correctly. It pointed me to some configuration I'd have to do for the Docker container install method, but my install is HAOS (on raspberry pi 4). I chose to ignore it because I don't use Bluetooth anyways.
In release notes we can see:
"Toggles across Home Assistant got a small but lovely makeover this release. Every toggle in the app has been updated with a fresh new design."
Lovely... according to whom? If you one who uses default theme the change is transparent and in line with overall look and you might not care. But if you use heavily customised theme then once again you have piece of UI completely misaligned to the rest. Every month we get such fly in the ointment... What would be the cost to add instantly in the release note how to style this, so we can maintain consistent look?
