Phone Entities: Battery, Wi-Fi, Charging, Sound Mode, and Sensors
After installing the app, the phone has a lot of entities in Home Assistant. This lesson looks at what the app makes available and which data is genuinely useful. We're not building automations yet. First we pick a handful of sensible entities and leave the rest alone.
In Lesson 3 you sorted out the user, the device, and the person. Now let's look inside the phone device itself. The Companion App can send Home Assistant dozens of data points: battery, Wi-Fi network, charging state, sound mode, and various sensors. That looks impressive, but for a beginner it's also a trap. It's easy to dump everything onto a dashboard and end up with chaos.
Plan on roughly forty-five to fifty minutes. By the end, you'll pick your phone's five most important entities and add them to a simple diagnostic view. You'll leave the rest untouched for now.
This lesson's core rule
The phone can send Home Assistant an enormous amount of data.
At the start, pick a handful of useful entities. Leave the rest alone until you know what you'd use them for.
Where to see the phone's entities
The phone's entities are tied to the device you named in Lessons 2 and 3, say, Marek's Phone. The easiest way to find them is one of two paths: through the device, or through the entity list.
- Go to Settings, then Devices and Services.
- Open your phone's device from the mobile app integration.
- You'll see the list of entities tied to that device.
- Alternatively: Settings, Entities, and search for your phone's name or the word mobile.
Your first look at a phone's entity list can be surprising. There might be a dozen or several dozen. That's normal. It doesn't mean you have to use them all. Search by the device name you gave it in Lessons 2 and 3, say, Marek's Phone. A readable device name helps you tell your phone apart from other devices in the home much faster.
What the Companion App sends to Home Assistant
The mobile app works like a bridge. It gathers data from the phone and hands it to Home Assistant as entities. Each entity is one kind of information: battery level, Wi-Fi network name, whether the phone is charging, and so on. Some entities update often, others less so.
| Data type | What it tells you | Why it's worth it at the start |
|---|---|---|
| Battery level | How much charge remains | Diagnostics, whether the phone is alive |
| Charging | Whether the phone is plugged into a charger | Power context, not proof the app is working |
| Wi-Fi SSID | The name of the Wi-Fi network | Shows whether the phone is on the home network |
| Connection state | Wi-Fi, mobile data, or no network | Diagnosing the connection to HA |
| device_tracker | Home or away | The foundation of a person's presence |
| Last update | When the phone last sent data | Checking that the phone has reported recently |
| Sound mode | Ring, vibrate, or silent | Useful before you get to notifications |
| Do Not Disturb | Whether DND mode is on | Context for notifications |
On top of that come optional data points: Bluetooth, activity sensors, a step counter, screen brightness, and others. Some only show up on Android, some only on iPhone, and some not at all, if the system doesn't hand that data to the app.
Why entities don't always update right away
The phone doesn't send Home Assistant every piece of information every second. The phone's own system saves battery, limits background app activity, and sometimes batches updates. That's why battery level, location, Wi-Fi, or the last_changed and last_updated attributes in Developer Tools can lag behind. That's normal. Not every phone has one universal "last update" entity, check the specific sensors and attributes instead.
Don't expect second-by-second precision
Phone entities are great for diagnostics and context, but don't treat them like instant industrial sensors. Delays are especially normal around presence and location.
Battery and charging: what they're for at home
Battery level and charging state are the simplest diagnostics for a phone in Home Assistant. You're not building anything complex on them yet. You want to know whether the phone is alive and fit to serve as a presence data source.
If the battery drops to zero, the phone stops sending data. Presence can then look stuck, and notifications stop arriving. So battery isn't just a percentage. It's a signal for whether the device can cooperate with the home at all. Charging state helps with context, but it doesn't guarantee the app is running correctly in the background. The last-update entity helps with that too.
No automation just yet
Don't build a rule like "when battery drops below 10%, send a notification" yet. First watch the data for a few days and see how the phone actually behaves.
Wi-Fi and connection: diagnostics, not automation
The Wi-Fi SSID entity shows the name of the network the phone is connected to. That's useful when you're checking whether the phone is on the home network and whether the app should be using the local address. Connection state tells you more broadly whether the phone has Wi-Fi, mobile data, or momentarily nothing at all.
This data suits a diagnostic view well. It works less well as a foundation for household automations right at the start. The mere fact that the phone is on the home Wi-Fi doesn't always mean a household member is home. The phone could have stayed on a desk while you left without it. We'll get to presence properly in Lesson 5.
Sound mode and Do Not Disturb
Sound mode and the "do not disturb" state are contextual data. They'll come in handy once you reach the notification lessons, when you're deciding whether to send a routine reminder or something more urgent. At this stage it's enough to know these entities can exist, and that not every phone shows them.
If you have these entities, you can add them to the diagnostic view as a sixth item, or leave them for later. If you don't have them, that's fine too. They're not essential before your first notifications.
Activity sensors and Bluetooth: leave for later
On Android you'll often see more sensors: activity, steps, screen brightness, orientation, sometimes Bluetooth. That looks interesting, but for a beginner it rarely offers quick value. A sensor like that changes often, says little about the home, and easily introduces noise into the system.
Bluetooth only becomes useful once you have a specific idea, say, presence detection through a beacon, or pairing with a device at home. Without a plan like that, the "Bluetooth on" entity by itself gives you little. Leave it alone until you know what you'd use it for.
Android and iPhone don't show the same things
This needs saying plainly: not every phone has the same set of entities. Android and iPhone differ in what data they expose to apps. Home Assistant shows what it gets from the system. If your phone is missing some entity, that doesn't mean something's misconfigured.
Android: often more sensors and diagnostic options. You'll sometimes see more network, activity, and system-state data.
iPhone: usually fewer technical entities, more limited access to system data. Basics like battery, network, and location work, but not everything will match Android exactly.
The takeaway: don't compare your phone against someone else's entity list on a forum. Only compare what you actually have and what you genuinely want to use.
This is normal
Not every entity will be available on every phone. Android and iPhone differ in what data they offer. A missing entity on your phone doesn't mean the install went wrong.
What's worth using at the start
A short list is enough to begin with. These entities give you the most information for the least chaos. The rest can wait for the presence, notification, or battery-diagnostics lessons.
Battery level: at a glance, whether the phone has power and can serve as a data source.
Charging: shows whether the phone is plugged in, and helps you understand why the battery is rising or falling.
Presence (device_tracker): shows the phone's state and becomes the starting point for Lesson 5's household presence.
Wi-Fi SSID: shows whether the phone is on the home network. Useful for local-connection diagnostics.
Last update: shows when the phone last sent Home Assistant data.
Do Not Disturb: if available, it'll be useful before the notification lessons.
A sample starting set
Marek's Phone Battery, Marek's Phone Charging, Marek's Phone (device_tracker), Marek's Phone Wi-Fi, Marek's Phone Last Update. Exact names may vary slightly, but the idea is the same: five basic pieces of data about your phone.
Phone entities and privacy
Phone entities can say more than they look like at first glance. Battery by itself isn't a problem, but location, Wi-Fi network, sound mode, activity, or sensor data can reveal a household member's daily rhythm. So don't add someone else's phone and its entities without a conversation and consent.
A privacy rule
The phone is a personal device. Treat its entities as personal data too. Before you add a household member's phone and start showing their data in Home Assistant, agree on it with them clearly.
What not to use at the start
Just because an entity exists doesn't mean you have to put it on a dashboard or build an automation on it. At the start, it's better to skip data you don't understand or that changes in ways that don't mean much for the home.
Every sensor at once: don't add every phone entity just because it's available.
Advanced activity sensors: steps, activity, orientation, and similar data are rarely needed at the start.
Odd technical entities: if you don't know what an entity means, skip it for now.
Bluetooth without a purpose: the bare Bluetooth state rarely gives value until you have a specific idea for it.
How to avoid chaos out of fifty entities
The most common beginner mistake: open the phone's entity list, see a lot of them, and add everything to the dashboard "just in case." A week later that view is unreadable, and automations are hard to keep track of. The phone is supposed to serve the home, not clutter Home Assistant.
Step 1: go through the phone device's entities and mark the ones you understand.
Step 2: pick the five most important ones to start with. The rest stays in the system, but doesn't need to be on the dashboard.
Step 3: add them to a separate diagnostic view, not to the home's main dashboard.
Step 4: come back to the remaining entities only once you have a specific reason, say, notifications or presence.
An entity can exist without being used
Home Assistant doesn't require every entity to sit on a dashboard or in an automation. Five useful data points beat fifty random ones.
What about entities you don't use
You don't have to delete phone entities you don't need right now. In Home Assistant you can simply leave them off the dashboard. If they clutter your entity list too much, you can hide them in the entity settings. That tidies up the view without disabling the phone integration itself.
Hiding an entity isn't the same as turning off a feature in the app. It's just a way to stop seeing things you don't use. You can come back to them later if they turn out useful. At this stage, deliberately picking a handful of entities matters more than perfectly tidying the whole list.
Not using it doesn't mean deleting it
At the start, the safest move is simply not adding an entity to the dashboard. Save disabling entities for later. Disable something by accident, and you might later wonder why a piece of phone data stopped working.
Disabled, unavailable, and unknown: what these states mean
A hidden entity, a disabled entity, and the unavailable state are different things
Hiding an entity removes it from some default views, but the entity still works. Disabling an entity (disabled in the registry) means Home Assistant won't load it until you turn it back on. The unavailable state means the entity is active but momentarily has no current data. Unknown and unavailable are entity states, disabled is something else entirely.
You don't need every phone sensor
Some Companion App sensors are disabled by default. Frequent reporting from a lot of sensors puts a load on the database and history. Disable sensors you don't need in the app's settings. The Do Not Disturb sensor depends heavily on the platform and permissions, don't assume every phone has it.
With phone entities you may see various states that look alarming at first. Not every one of them means a malfunction. Sometimes an entity is disabled, sometimes the phone just hasn't sent data momentarily, and sometimes the app doesn't know the current state yet.
| State | What it means | What to do |
|---|---|---|
| disabled | The entity is turned off and isn't actively running in Home Assistant. | Don't turn it on out of curiosity. Enable it once you know why you need it. |
| unavailable | Home Assistant momentarily has no data from this entity. | Check the phone's connection, battery, background app behavior, and last update. |
| unknown | The entity exists, but Home Assistant doesn't yet know its current state. | Refresh the app, wait a moment, and check whether the phone is sending data. |
Observe first
A single unavailable or unknown state doesn't necessarily mean a problem. A problem starts when the phone's basic entities are unavailable constantly or very often.
A simple phone diagnostic view
At this stage, a separate view just for checking the phone is enough. It doesn't need to be pretty. It should answer these questions: is the phone alive, does it have battery, is it on the home network, and is it sending data to Home Assistant. We'll build a full mobile dashboard later, in its own dedicated lesson.
- Create a new view, say, Phone Diagnostics.
- Add entity cards for your five chosen data points.
- Stack them vertically, one under another, with no decoration.
- Don't mix in lights, cameras, or Zigbee devices here.
- Treat this view as a service tool, not a household panel.
If an entity shows unavailable or unknown, check the table above and look at battery, connection, and the last update. A single occurrence like that usually doesn't mean a malfunction.
What can go wrong
Adding every entity to the dashboard: a few days later, nobody knows what to look for or what matters.
Comparing yourself to a different phone: a missing entity on your side doesn't always mean an error. It's often just Android versus iPhone.
Building an automation on an odd entity: if you don't understand the data, don't base household logic on it.
Ignoring the last update: the phone can look present even though it hasn't sent Home Assistant data in a long time.
Mixing diagnostics with your everyday remote: keep the phone's technical view separate from the dashboard you use daily.
Assuming entities update instantly: the phone saves battery, so some data can lag.
Disabling entities without a note: later you might not remember why some phone data isn't working. At the start it's better to just not use it.
Showing someone else's phone data without a conversation: location, Wi-Fi network, and phone activity touch on household members' privacy.
Assignment: pick five entities and build a diagnostic view
To do
☐ Open your phone's device in Home Assistant and go through the entity list.
☐ Pick your five most important entities for the start, say, battery, charging, Wi-Fi, device_tracker, and a check of last_changed / last_updated in Developer Tools.
☐ Note which entities your phone doesn't have, and don't treat that as an error.
☐ Create a Phone Diagnostics view and add only your chosen entities.
☐ Check whether the entities show current data after refreshing the app.
☐ Leave the remaining entities as they are. Don't add them to automations yet.
☐ Check that your chosen entities aren't stuck showing unknown or unavailable.
☐ Write down which entities you're deliberately leaving unused, to avoid chaos.
☐ If you're adding another household member's phone, make sure they know what data will be visible.
Key takeaways
The phone has many entities, but you don't need to use them all, pick a handful of sensible data points to start.
Android and iPhone differ, a missing entity on your phone is often normal.
At the start, the basics matter: battery, charging, presence, Wi-Fi, and last update.
Keep diagnostics separate from your everyday dashboard, the phone's technical view shouldn't clutter the home's main screen.
Don't build automations on data you don't understand, learn the entities first, then use them in your home's logic.
What's next
In Lesson 5 we'll tackle household presence: the person entity, device_tracker, the home and not_home states, delays, and the real-world problems that come with a phone. This will be the foundation for a lot of personal automations, but still without critical actions like disarming the alarm or opening the gate.
For now you have a sorted-out phone, an assigned person, and a short list of entities genuinely worth knowing. That's a good moment to move from raw data to how Home Assistant actually understands whether you're home.
