Notification attributes (array/list) not expanded (android.textLines and android.people.list) / Stacked messages
See original GitHub issueHome Assistant Android version: 3.0.2-full
Android version: 10.0
Phone model: Samsung S20+
Home Assistant version: 0.118
Last working Home Assistant release (if known): n/a
Description of problem:
When you get multiple messages from a single app, they can be grouped together.
In this case, even if the messages are all visible in the notifications on the phone, the only captured information as android.text
is something like “4 new messages”. The text itself in then stored in android.textLines
but this object needs to be converted to something that can be read.
Similar issue regarding android.people.list
where it’s not possible to use the attribute because the list is not expanded.
In my case, I play TTS (Google Cloud) on my Google Home when I get WhatsApp notifications.
However, if I don’t open the WhatsApp conversations, the messages are stacked and I am only able to retrieve a generic message which is “4 new messages”. I would prefer to be able to use the latest android.textLines
or the android.text
if the first one is empty / not present.
android.appInfo: ApplicationInfo{5767c9 com.whatsapp}
android.infoText: null
android.largeIcon: null
android.people.list: [android.app.Person@213eede0]
android.progress: 0
android.progressIndeterminate: false
android.progressMax: 0
android.reduced.images: true
android.remoteInputHistory: null
android.showChronometer: false
android.showWhen: true
android.subText: null
android.summaryText: 4 nouveaux messages
android.template: android.app.Notification$InboxStyle
android.text: 4 nouveaux messages
android.textLines: [Ljava.lang.CharSequence;@97a1bd0
android.title: John Doe
package: com.whatsapp
friendly_name: Téléphone Julien Dernière notification
icon: mdi:bell-ring
Maybe related: https://stackoverflow.com/a/50868911 https://stackoverflow.com/a/49181208
Suggested implementation: Since the attribute size is limited to 255 characters, it would not be possible to use the same field for all the lines. I think multiple attributes could be created based on the array size:
- android.textLines_0: Message 1
- android.textLines_1: Message 2
- android.people.list_0: John Doe
- android.people.list_1: Jane Doe
Issue Analytics
- State:
- Created 3 years ago
- Comments:16 (13 by maintainers)
Top GitHub Comments
@Mincka Updated #2478 based on your comments, thanks! When Android provides an array/list, it will now always be sent to your server as a list.
Items in the list are still limited to strings using
toString()
(and booleans/numbers) though;android.textLines
is a list of strings (messages) and works as expectedandroid.messages
is a list of bundles, they are converted to a string and will still give you problems if a message includes ", " (possible workaround: use a regex to select text betweentext=
and, time=
)Confirmed as fixed. 👍 I am able to get the 7 latest individual messages of the conversation in Whatsapp.
android.textLines: [Morgane: 😫, Morgane: 😔🐦, Morgane: 🫣, Morgane: 4, Morgane: 5, Morgane: 6, Morgane: Très cher chéri, second part of the last message]
I don’t know if #2478 is a good fit for this sensor because of the ‘,’ issue. At the beginning, I thought it was great because I could create a template sensor to always get the latest message as it would be the latest list item of the textLines attribute. But if there is a comma in any of the last 7 messages, it will fall back as an array (if I understood it correctly) and my template will fail. If that’s an “array as a string” (
"[xx, y, y]"
), I will have the same issue you have during the conversion, I will attempt to get the latest message after the latest comma but I won’t be sure that I get the latest message or a part of it after a comma.The biggest “issue” would be to have this inconsistent behavior, sometimes a string with the array, sometimes that would be list. Maybe it would be better to avoid the conversion for sensors with non-predictable content that may have a comma?
That’s more a discussion for #2478 anyway since this one is clearly fixed by the PR, thanks again. 👍
Edited to fix the example.