I just tied it back together again and it works again. I guess I just have to wait for it to change in the UI again which has happened twice in two days that I’ve noticed. I’ll report back tomorrow.
Luckily, I only have like 4 notifications going to the apple device so it’s not super critical but I’d still like to get to the bottom of it.
that’s weird, posted on Feb 8th. But definitely the same issue. I will start following it. Thanks for the find!
i don’t know if it’s exact the same, but seems like related to The Phone(Device) and it’s App, … if it was as i’ve experienced, the phone.tracker.entity would have changed name to trailing _2 _3 _4 … until you go nuts 
PS: i had no “notifications” just automations, that didn’t like that
EDIT: Thou just for the record, this was 2-3 month ago, so NOT related to this, or any releases
PS: Clean startup logs since last 2 updates 2022.4.4 2022.4.5 , and just a-lot new features to explore … don’t know who to thanks, so i take that upon my self 
Is there any documentation as to which tables in the database store configuration settings? I don’t really have a huge preference as to where or in what format settings are stored, as long as I know where to find them.
You win for useless, contextless post of the month.
I have no idea what he’s saying with that statement. Nothing is stored in sql lite configuration wise. Only the state history is stored in sql
Yeah I just re-read about sqlite, you can ignore all my comments on that. As I said above I’ve not tested 2022.4 yet, just been following this thread and it seems to be a nightmare for a lot
Not true. Works perfectly.
Also on that … You also seems to have forgot that let’'s say 100.000 Ha installations made by 100.000 individuals on vast amount of variations in Hardware, Add-ons and integrations, configurations, customization s, network specifics, external devices of various brands and protocols, with 3rd-4th part software, or user-flashed etc. etc. etc. , i don’t say that some people didn’t have/had a lot concerns, but your definition of “a-lot” should be in the right context, and non of your commends here seems related to any “problems” of your own, or with above mention in mind
That’s sort of the problem, the term “release” is relatively meaningless. There is no way to tell where a safe place to jump in is. Most months a .0 release is at best a release candidate.
I usually wait at least a couple weeks, butI think I’ve had issues every time a new feature tempted me into trying the .0 release.
It’s been discussed before, but HA needs some sort stable/LTS/etc track, even if it’s just re-tagging the last release of the month.
No, it needs more beta testers and people who install .0 releases.
Thanks Hellis81. Using the zha_event in dev tools before/after 2022.4 could see something had changed. Ran automation debug traces before/after 2022.4 and could see that resulted in a different set of “changed variables” which are used as conditions for the automation. Updated the blueprint and all is good now. I appreciate the suggestion.
@boheme61, is your device have a setting on the WIFI network that enables MAC randomization? This could look like a new device to HA every time you connect to the WIFI. If it is enabled you might want to disable that for your WIFI SSID.
MAC randomisation is per wifi network on the iPhone. This limits tracking across different networks while retaining the same mac address for each remembered network.
I don’t think the devs are using the mac address as the unique id though (not 100% sure).
It seems a lot of issues are related to blueprints and not actual automations.
I’m almost thinking of installing.
I disagree. Every month there is a main topic (or a few of them) for the first release and for the remainder of the month fixes and tweaks are implemented. I can’t remember a major feature added mid-month. With the traditional versioning scheme it was perhaps a bit clearer though, but it is what it is. Regardless, the more people can help test upfront the better. If you want more stability, wait until later in the month. And remember, with basically all software, a new major version will have some issues. The goal is to minimise this, but it’s seldom perfect, especially at the pace of development here.
Devices like plugs/switches and the likes have no such specific settings, but 1 thing i did, was as mentioned to Enabled Manual IP Settings for DHCP scope, which “Bind” the devices MAC to it’s Friendly Name and IP, so the wifi device can report whatever it likes, it’s friendly-name/ or factory-name, Router looks at it’s MAC and use the Friendly name i defined in Router. This seems to be what solved my “issues”, i can take any devices(almost) offline for hours and days, plug them in and they are reconiced by the Router, by it’s MAC.
But iPhones seems to have some own “weird” way(i don’t have any iPhones), but if that’s the case, using the Router to “overwrite” this could be a solution.
As Tom says, if Devs somehow should use Devices MAC, which i also doubt, then it would be what ever is reported from the Router, but most likely Devs uses device-name/id or Friendly name/IP coming from the Router. … atlest that’s what i think
This is how it looks in HA ( Thou this is for a Device, not an automation/service )
core.config_entries
"entry_id": "626ea42369da98f557e3c8bd6e14f580",
"version": 1,
"domain": "localtuya",
"title": "N3Plug",
"data": {
"friendly_name": "N3Plug",
"host": "192.168.50.21",
core.entity_registry
"area_id": null,
"capabilities": null,
"config_entry_id": "626ea42369da98f557e3c8bd6e14f580",
"device_class": null,
"device_id": "039e05adf1bb6b9fd29c06f995fd09b5",
"disabled_by": "config_entry",
"entity_category": null,
"entity_id": "switch.n3plug",
"hidden_by": null,
"icon": "mdi:power-socket-de",
"id": "f894bf9b25b6c59c8830a061d4828ed0",
"name": null,
"options": {},
"original_device_class": null,
"original_icon": null,
"original_name": "N3Plug",
"platform": "localtuya",
"supported_features": 0,
"unique_id": "local_bf100c0f9708c220a2jiiw_1",
"unit_of_measurement": null
PS: However, the device_tracker actually reports the MAC-Address as-well 
"area_id": null,
"capabilities": null,
"config_entry_id": "b46f7d8cf94d1441ff3b9867e5a74371",
"device_class": null,
"device_id": null,
"disabled_by": null,
"entity_category": "diagnostic",
"entity_id": "device_tracker.sm_g390f_2",
"hidden_by": null,
"icon": "mdi:cellphone-wireless",
"id": "44e4bd12f27ae61dae8b0e6aaef0867a",
"name": null,
"options": {},
"original_device_class": null,
"original_name": "SM-G390F",
"unique_id": "90:xx:xx:-----< MAC-Address
The Trailing _2, is a “leftover” from when i finally found a “solution” that sticked, renaming it in HA would probably just cause HA to generate a new _3, and also seems to ignore “friendly-name” from the Router