You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Home Assistant uses python-slugify to convert device names into entity ids. However, slugify treats a curly apostrophe (e.g., the one that iOS devices use by default) differently than a straight apostrophe. Whereas a straight apostrophe is replaced with the defined separator (underscore), a curly apostrophe (u"\u2019") is omitted entirely, leading to inconsistent entity names as shown below:
This became an issue for me while testing the iOS 16 beta, which prevents the iOS app from discovering the iOS device name, causing Home Assistant to rename the notification service to notify.mobile_app_iphone until the user renames the device in the HA app settings.
(Open issue: home-assistant/iOS#2148)
I was able to rename the device in the HA app settings, but because the iOS device keyboard defaults to a curly apostrophe which is then omitted by slugify, the updated notify service was named notify.mobile_app_johns_iphone rather than notify.mobile_app_john_s_iphone, which wasn't consistent with the previous service name and prevented my automation and script notifications from working. Ultimately, I had to find a random straight apostrophe on the web that I could copy-and-paste into the device name in the HA app, which resolved the issue.
I suspect other iOS users may run into similar issues over the course of the iOS 16 beta, as Apple often suggests possessive device names with apostrophes.
This issue was raised on the upstream package a few years back (un33k/python-slugify#30), but it didn't appear to get much traction amid a larger debate over the appropriate treatment of apostrophes generally.
Within Home Assistant, I would be inclined to use slugify's replacement parameter to pre-replace curly apostrophes with straight apostrophes, but I recognize this could break things from the perspective of users that already have device names with curly apostrophes, so I welcome others' thoughts before creating a PR.
Bottom line, it's weird that Home Assistant, because of python-slugify, treats straight apostrophes and curly apostrophes differently when converting device names to entity ids, and I think we should make them consistent.
What version of Home Assistant Core has the issue?
core-2022.7.3
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
No response
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered:
I ran into this same issue just now after updating my phone to iOS 16. It's also especially confusing because the Home Assistant app for Mac doesn't allow you to set a Device Name (there are no Companion App settings in the app), so some devices have a _ for the ' character and some are just an empty string for the curly apostrophe.
Not sure if there is a great solution, but just commenting here in case others have this issue. My solution was to rename the Device Name, delete the Home Assistant app from iPhone, remove the device from Home Assistant devices, and finally reinstall the app on iPhone.
Also @krazos, fwiw you can hold down on the apostrophe key on the iPhone and it will give you the straight apostrophe as an option to select from. Hopefully that will save you some time copy/pasting the character from the internet in the future.
The problem
Home Assistant uses python-slugify to convert device names into entity ids. However, slugify treats a curly apostrophe (e.g., the one that iOS devices use by default) differently than a straight apostrophe. Whereas a straight apostrophe is replaced with the defined separator (underscore), a curly apostrophe (
u"\u2019"
) is omitted entirely, leading to inconsistent entity names as shown below:This became an issue for me while testing the iOS 16 beta, which prevents the iOS app from discovering the iOS device name, causing Home Assistant to rename the notification service to
notify.mobile_app_iphone
until the user renames the device in the HA app settings.(Open issue: home-assistant/iOS#2148)
I was able to rename the device in the HA app settings, but because the iOS device keyboard defaults to a curly apostrophe which is then omitted by slugify, the updated notify service was named
notify.mobile_app_johns_iphone
rather thannotify.mobile_app_john_s_iphone
, which wasn't consistent with the previous service name and prevented my automation and script notifications from working. Ultimately, I had to find a random straight apostrophe on the web that I could copy-and-paste into the device name in the HA app, which resolved the issue.I suspect other iOS users may run into similar issues over the course of the iOS 16 beta, as Apple often suggests possessive device names with apostrophes.
This issue was raised on the upstream package a few years back (un33k/python-slugify#30), but it didn't appear to get much traction amid a larger debate over the appropriate treatment of apostrophes generally.
Within Home Assistant, I would be inclined to use slugify's replacement parameter to pre-replace curly apostrophes with straight apostrophes, but I recognize this could break things from the perspective of users that already have device names with curly apostrophes, so I welcome others' thoughts before creating a PR.
Bottom line, it's weird that Home Assistant, because of python-slugify, treats straight apostrophes and curly apostrophes differently when converting device names to entity ids, and I think we should make them consistent.
What version of Home Assistant Core has the issue?
core-2022.7.3
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
No response
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: