I'm looking to integrate Nest doorbell and cameras with my app using the new Google Device Access API.
When following the authorisation flow in the user guide (https://developers.google.com/nest/device-access/authorize), the user is presented with the option to select which devices to connect with our app. Is there a way to filter this so that only devices with camera capability/traits will show?
Currently all devices seem to show (e.g. thermostats), but my app will only be able to use the camera traits.
No, there is not a way to filter those at this time.
Related
There are several ways to send FCM messages and I don't understand which one to use even if I read the documents over and over.
My use case:
I have a user that is logged into the app on her iPhone, iPad and Android tablet. I want to make sure the push notifications are sent to all of her devices.
There are three ways to do this (I'm using the admin to send the push notifications):
Topic messaging (messaging().sendToTopic): My understanding this is for sending the same notification to larger groups. For example a topic could be all users that want weather notifications for New York. Not for my use case.
Send Multicast (messaging().sendMulticast([array of tokens]): My understanding this will send the same message to all device tokens in the array (up to 100). This seems perfect for my use case, right?
Device group messaging (messaging().sendToDeviceGroup): I don't really understand this one. Why use this instead of multicast or topics?
For my use case it seems the best way is to each time a FCM token is updated I add this token to the user in the database. I then send the notification using the admin.messaging().sendMulticast([array of tokens]). Is this what you would recommend? Why or why not?
You probably want to use multicast if you're targeting an individual user's specific devices. You probably don't want to use device groups. I suggest reading the documentation to understand how device groups work:
Device group messaging allows you to add multiple devices to a single group. This is similar to topic messaging, but includes authentication to ensure that group membership is managed only by your servers. For example, if you want to send different messages to different phone models, your servers can add/remove registrations to the appropriate groups and send the appropriate message to each group. Device group messaging differs from topic messaging in that it involves managing device groups from your servers instead of directly within your application.
Device groups are basically just topics whose membership is fully managed by your server code, not by client code.
I am using FCM console to send push messages to the users. Until now I am targetting using User Segments through which I can filter users based on language. But now I need to allow users to subscribe or unsubscribe to the type of alerts they can receive. So I am exploring the option Topics. But now from firebase console I can either target users based on User Segments or Topics.
I want to be able to use Topics with the options I can get in User Segments(where I can filter based on language). Is there a way to make this possible?
Thanks,
Sindhu
Segments can't be targeted with topics. Segments are populated by data collected by Firebase Analytics, and don't identify individual devices. Topics are just names that you make up, and the names must match between the device and server.
You will need to find a way to match up users in a segment to the topic that you create for that segment. You could try to use Remote Config to give clients the name of a topic that matches their segment, then use FCM to subscribe to that topic.
I am working on an in house project with several sensor devices. I do not want a user to register each and every device individually. In the sense I want to use the same Public/Private Key pair for all devices registering to a registry but be able to pass device information on to pubsub via mqtt/http with unique device information like name or id. Is it possible to achieve that?
I am assuming if i am using the same Keys. I am registering all devices as one but is it possible to send device info as part of the message being published. does doing that inhibit the usage of google's inbuilt functionality in any way like API's.
new to cloud technologies, any thoughts/suggestions would help.
Depends on MQTT-broker configuration.
Normally Certificate based authorization is used only for authorisation on MQTT-Broker side. So you can use Public/Private Key pair to authorize and connect to the broker and use MQTT ClientID to differ between your devices.
MQTT-Broker can be also configured to use Identity from authorization Public/Private Key pair as Username.
use_identity_as_username true
In this case, if MQTT-Broker has also username based ACL configuration for example like that:
#device info sent from device. %u <- username
pattern readwrite %u/devinfo
All your devices will publish messages under same username, you should set different ClientID for each device or use CleanSession Flag in this case.
Here is a good reading to understand how the connection between device and broker works at all: https://www.hivemq.com/blog/mqtt-essentials-part-3-client-broker-connection-establishment/
Sounds like you really want to be using the new gateway functionality (it's in beta now, but I've run through using it a bunch and it's quite stable).
Check out this tutorial on gateways to get an idea of what we're talking about:
https://cloud.google.com/community/tutorials/cloud-iot-gateways-rpi
TL;DR version is that it allows a single device to manage many smaller devices (which may not be capable of auth on their own) but still have those smaller devices be represented in the Cloud.
So basically, you have a more powerful device (like a Raspberry Pi, or a desktop machine, whatever) registered in IoT Core as a "Gateway". Then when you create the individual devices in the Cloud, you don't specify an SSL key (the Console will warn you about the device not being able to connect) and then you can "associate" the device with the gateway, and it'll handle the auth piece for you. Then the individual devices instead of calling out to the internet, connect and talk to the gateway device locally.
I have developed a mobile app (hybrid app), which is to track multi user in real time using firebase.
My question is:
Is there's any restrictions on the maximum distance between the users (mobile devices) or it is unlimited? (since the app connecting with firebase cloud)
Firebase services don't care where in the world clients are accessing it, nor does it care about the distances between the clients. It's just moving data around, wherever it comes from.
I have a pool of device tokens (iOS and Android) and in the docs, I find only one parameter sound for both platforms and obviously I have 2 different notification sound, one for Android and one for iOS.
Do I have to split device tokens by device type for sending to 2 separate device types? Or did I just miss something ?
Thanks.
Solution 1
You could name the same both audio files, like 'your_app.mp3'.
Same name, but different music file on each app. This not allow the user choose the notification sound, but at least allow each app to have a different sound.
Solution 2
Migrate to the new Firebase HTTP v1 API which allows you to customize notifications across platforms
Personal experience
Solution proposed by #daniel-raouf to send Data Messages is great; but in my experience, some Data Messages could not be delivered to your users when:
An user has a power save mode on his phone (by default on Huawei, Xiaomi, One Plus...)
When iOS users clear your app from recent apps (multitask).
So, in my opinion, Data Messages are not a reliable solution for notifications.
You had missed something,
A- If you want to allow the user to select his preferred notification sound at any device so
don't send notification
send only data to force the received content to pass by the onReceive event
In on receive add the sound the icon and data you want to the notification builder.
B- If you want the app to use the default sound
so in the notification body set sound:'default' and it would work for all types of devices