Add the ability to send links or notifications to guests on your local Wi-Fi leveraging the quick share functionality. Not sure if this could be exposed to the companion app, but if so it could be quite useful.
Use case:
I have family and friends that automatically connect to our Wi-Fi when we gather for various events. The quick share functionality could be used to send end dashboard links to guest users, allow them to select music choices, control lights, etc.
In addition, quick share could send notifications to external services, for example remind our visiting children to access their mom’s Amazon wish list for a birthday gift. This feature would not require them to have the companion app, or access to any dashboard.
Quick share could also leverage access to [Music Assistant] (Music Assistant 2.0: Your Music, Your Players) and quickly provide nearby phones the URL to the Music server for guests.
This feature might also be useful for people who are Airbnb hosts, etc. and have Home Assistant installed. It could be used to provide quick onboarding to a dashboard specific for guests.
I assume the IOS Companion app could be leveraged for the same purpose.
A QR code could perform the same purpose, but it would be cool if it could be automated once a user is connected and in proximity.
Potential Implementation:
A local Android tablet hosts the companion app. Using the Nearby connection API, it notices that several new clients have come within range. Utilizing unspecified client details an automation could then trigger the nearby share that uses REST to determine if that client is in fact connected to the local network. If so, the automation could provide messages, links to internal or external services, or simple on-boarding details to load a local dashboard or install the companion app.
For this to work, just sharing a link to a dashboard would not be enough, you’d need to bypass Home Assistant authentication as well. The other thing that would be problematic is that if the guests are on guest wifi, they cannot access local resources. They would need external access. So the link would not only need to bypass security, but also need to bypass security over the internet. I would not want such links to be possible myself.
Node Red is used to create the dashboard, so your comments about Home Assistant authentication don’t apply. Also, I’m assuming anyone who implements such a tool can manage the issue of providing the dashboard on guest Wi-Fi, or, for example, in my case where I don’t have a separate guest Wi-Fi, then there is no issue.
Personally, I don’t mind having the options of such links. Everyone has to evaluate their own risk tolerance.
Again, it’s just an option. Currently minimizing the friction of notifying the guest phone is a key missing detail, hence the FR. Discussions of the security of any services the option could potentially point to is outside the scope of this FR.
I agree Node Red security is of no concern to HA. But if it is a node red dashboard you’re sharing, shouldn’t it be a node red FR? Why would HA share things that are not from HA?
The node red dashboard is just an example. The feature request is to have the companion app facilitate the sharing of the dashboard/message/whatever by recognizing there are nearbly users that may have interest in the dashboard.
Here’s another example:
Let’s say our children are visiting around Mother’s Day or their mom’s birthday. This “feature” could trigger a notification to them that shares a link to their Mom’s Amazon wish list with the reminder of the holiday/birthday. (I’m assuming the nearby share provides enough details about the client to know it’s one of our children
The point of the feature request is to leverage an existing phone notification API that don’t require the user have the companion app, or any other pre-configured linkage to Home Assistant itself. I feel that requirement is the friction such a novel feature could be useful for.
Thanks for the clarification. Maybe augment the original FR, which seems to mention things in HA that you could currently not link to if you shared it any other way.
Quick Share use Bluetooth and WiFi direct, not AP based WiFi, so you do not know which, if any, WiFi network does receiving phones are connected to.
If you have a Node Red dashboard then you probably have the link in your phone to share over Quick Share, so no need for it to be store in HA.
Same would go with a wish list on any service.
Since the Quick Share service require the receiver to accept the sharing first, then this would be a manual action anyway with no possibility to automate it.
Yes, this would function on the automation of sending it (the hard part) not accepting the shared item. The notification could explain the need for local Wi-Fi or perhaps the API supports knowing that requirement. Either way, this FR is not to work out the underlying local communications requirements (which can all be resolved) but to facilitate a notification to a nearby, non-home-assistant-companion phone. I believe the API can even redirect to the Google Play Store for specific support.
Logic of whether the client is LAN connected locally can be worked out by the automation. For example, the first notification could be to the Rest API, and if that triggers successfully then a local URL could be provided. Just a thought.
I’ve added additional use cases and potential implementation details in my OP.
Google’s description of Nearby Connect:
Nearby Connections
The Nearby Connections API allows apps to discover, connect to, and exchange data with nearby devices in real-time, regardless of network connectivity. It uses Bluetooth, Wi-Fi, and other technologies, and is designed to hide the complexity of these technologies so your app can focus on discovering and interacting with nearby devices.
You should choose the Nearby Connections API for your app when:
You want to discover nearby devices without requiring Internet connectivity and incurring the cost of a network round-trip on each operation.
You want to stream content or transmit arbitrary payloads or files between nearby devices.
You want to use the latest peer-to-peer technologies such as Wi-Fi Aware when available.
They point to the same API from what I can tell. That said, I’m not an Android programmer so I could easily be wrong. Either way, seems the API to achieve my FR is available.
You can make the connection with that API, but you need an app in both ends to make the usage of that connection.
This is equal to a WiFi connection. No more.
As I understand it, Android has this built in. In my proposed FR the guest receiver has the needed OS support built in, and the Android companion app would implement the needed sending function via the API.
It’s more than Wi-Fi, because it supports specifying intents, specifying the needed application to read the received data, and more. I use a Google published Windows app that sends and receives data to Android phones. It can share text, urls, contacts, etc. Nothing required to install on the phone.
Technically this “Nearby Share” can already be done on any device running the companion app, I’m just suggested an automation function that can be leveraged by Home Assistant.
It is still provides no benefit with this feature in the companion app.
Your kids that need the wishlist are probably using a Google account you have or can have in your contacts, which means they “only” have to the screen active on their phone to get the shared link.
Your guest might be using a Google account that you have in the contacts or they might be using a pseudo Google account.
The ones in your contact"just" need to activate the screen, while the other needs to activate the feature too and youthen have 10.minutes.to share.
For both cases there is a need for a manual check of the receiver to make sure they can get the shared information.
Only way to automate it is to monitor their screen and feature setting, which means installing the companion app, which then make this feature obsolete.
If you then wish to go with the manual check of the receiver, then the devs would have to make and maintain code to make this happen and you would have to set up the information to be shared.
Since the link you would share is with 99% probability a static link, then you can already now just store it in your current app and share with that without losing any feature compared to your suggested feature request
The left over one percent is for links that are not static, but I can not come up with such a link that would be needed to be shared, whether you run HA or not.
This ubstatic link would then also need to be detectable by HA for it to be automatically updated for sharing or the idea would be null again.
I would like to see an use case for this feature request that makes sense and that takes the limitations set in the technology into account.
