Mobile notification abstraction layer for Home Assistant (device-independent automations)

[antoinevalentinHA]

Hello,

I built a small Home Assistant infrastructure layer that decouples automations from specific mobile phones.

Instead of calling notify.mobile_app_<phone> directly inside automations, this approach introduces a small abstraction layer using helpers and scripts.

The goal is to make automations completely independent from the actual phones used.

Repository:
https://github.com/antoinevalentinHA/ha-mobile-notification-architecture

---

Problem

Many Home Assistant setups contain things like:

service: notify.mobile_app_pixel_7a

This creates a few issues:

• changing phone requires editing many automations
• device names leak everywhere
• duplicated notification logic

---

Solution

This repository introduces a small notification infrastructure layer:

Automations
      │
      ▼
script.notification_send
      │
      ▼
notify.mobile_app_<phone>
      │
      ▼
Phone

Phones are defined through helpers:

input_text.user_1_phone
input_text.user_2_phone

From these values, the system automatically derives:

notify.mobile_app_<phone>
device_tracker.<phone>
sensor.<phone>_wi_fi_bssid

So replacing a phone only requires updating one helper.

No automation changes required.

---

Included components

• notification abstraction scripts
• phone helper synchronization automation
• optional Wi-Fi BSSID dynamic sensors
• example Lovelace settings dashboard

Everything is 100% native Home Assistant (no custom integrations).

Feedback is welcome.

---

[Hellis81]

@antoinevalentinHA

Problem

Many Home Assistant setups contain things like:

service: notify.mobile_app_pixel_7a

This creates a few issues:

• changing phone requires editing many automations
• device names leak everywhere
• duplicated notification logic

You could also just name the phones “John Doe” instead of pixel_7a and everything would just work.
If you just had renamed the phone then all the same steps would be needed as you just did, but it would work for any future phone also.

[antoinevalentinHA]

Hi Hellis81,

Yes, renaming the phone entity to something stable like “John Doe” is definitely a valid approach and it works well in many setups.

The goal of this project is slightly different though: the idea is to introduce a small abstraction layer so that automations never reference a device directly.

Instead they call a notification script, which resolves the actual notify service dynamically via helpers.

This also allows deriving other related entities (tracker, Wi-Fi BSSID sensor, etc.) from the same phone identifier. So changing the phone only requires updating a single helper and everything else follows automatically.

So the renaming approach works well for simpler setups, while this pattern tries to keep automations completely device-independent.

Thanks for the suggestion

[Hellis81]

I understand what you are doing but all the effort to get this in place is the same as just renaming the device and all associated automations and scripts. Because that has to be done either way.

@antoinevalentinHA

So the renaming approach works well for simpler setups, while this pattern tries to keep automations completely device-independent

Simpler in such a way that there is less effort yes.
But not simpler as in you can do more with your way of doing it.

@antoinevalentinHA

This also allows deriving other related entities (tracker, Wi-Fi BSSID sensor, etc.) from the same phone identifier. So changing the phone only requires updating a single helper and everything else follows automatically

Yes… The same.
I change the name of the new phone to the same name as the previous one and everything just works.
All entities get the same name.
So yes I update one field just like you and everything else just follows automatically.

The big difference is that I don’t need an abstraction layer.
I don’t need to template every time I need to use an entity.
If I want to use the phone state, then I use sensor.andreas_phone_state, I don’t need to use "sensor.{{ states('input_text.user_1_phone') }}_phone_state".

In my opinion you created an layer of abstraction making it more abstract and harder to use.
But if this works for you then great. I just want to make sure people know there are simpler ways.

[antoinevalentinHA]

Hi Hellis81,

Totally fair point — renaming the phone/device to keep stable entity_ids is indeed the simplest approach in many HA installs.

My goal here is slightly different: I’m trying to treat the HA setup more like a “finished product” where everything is configurable from the UI, without having to rename devices/entities or refactor anything when hardware changes.

So instead of “go rename the new phone to match the old one”, the only UI action is:

• update one helper value (the phone slug)

…and the rest (notify, tracker, wifi sensor references) is derived automatically.

So I agree your approach is simpler for a typical HA admin workflow. This pattern is more about a product-style workflow: UI-only configuration, strict separation between logic and device layer.

Thanks for the discussion

[Hellis81]

@antoinevalentinHA

without having to rename devices/entities or refactor anything when hardware changes.

I don’t…
When I download the HA companion app on the new phone I replace the name suggested in the onboarding process. That is it…
I would say that is simpler than having to use the developer tools to find a helper and set a new value.

[tmjpugh]

@Hellis81

When I download the HA companion app on the new phone I replace the name suggested in the onboarding process.

I always changed it in phone settings. Suggested name is taken from phone name in phone settings. Changing in app is even better.