devices call not returning all devices; account permission granted - nest-device-access

I have 4 Nest devices: 1 camera, 2 doorbells, and 1 thermostat. All 4 have all permissions granted to my Device Access project via PCM. However, when I make a device list call, only the 2 doorbells and camera are returned in the JSON. The thermostat is not returned.
It was returning calls up until January 11, 2020, and then just stopped reporting. I had made no changes (that I know of) to device access. At that point, it stopped being returned by the device call as well.
I have tried disabling and re-enabling access from my project to the thermostat, and still have no luck. What else can I do to troubleshoot or resolve?
Image: PCM showing Thermostat access

Workaround:
Delete the device from your account via the Nest app
Reset the account info in the device (not a full factory reset)
Re-add the device via the app
Authorize access to the 'new' device in PCM
Re-query devices

Related

Set different sound notification

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

Firebase 3 - We have blocked all requests from this device due to unusual activity

I was testing my login/sign up feature and for some reason I can't understand Firebase now is blocking all requests from my device.
I've waited one day to try again, but I still have the same problem.
ERROR:
"We have blocked all requests from this device due to unusual activity. Try again later."
What should I do to have access to my database again?
If you use Phone Authentication, Here is what to do:
Go to Firebase Console
Authentication ==> Sign-in-method
Go to "Phone" and pop-up will show
Add your phone number at "Phone Numbers for testing" along with a verification code from your choice.
And it works now :)
One of the possible solutions:
Go to your Firebase console -> Auth -> Users table
Locate the user you are testing.
Delete this user.
Retest.
I contacted firebase support and received this message:
The error "We have blocked all requests from this device due to
unusual activity. Try again later." is usually thrown when a user is
making SMS authentication requests to a certain number of times using
the same phone number or IP address. These repeated requests are
considered as a suspicious behavior which temporarily blocks the
device or IP address.
Additionally, there's a limit of 5 SMS per phone number per 4 hours.
With this, you may try doing the following to resolve the issue:
Reduce the frequency of attempts to avoid triggering the anti-abuse
system Try using whitelisted phone numbers for testing your app
Use multiple testing devices (as the limits are applied per IP or
device) Wait for an hour for the quota to lift
I tried to increase the quota as per #lhk answer but there answer is the
following:
You also mentioned that you have increased the quota to
1000 but it didn't work. Do note that this "Manage to sign up quota"
field is intended for Email/Password and Anonymous sign-ups.
I've run into the same problem.
By default (for the free plan), firebase caps sign-ins to 100 per hour, per IP-address.
This broke our automated testing. You can change the setting like this:
open console
open your project
go to "authentication"
go to "sign-in method"
scroll down to "manage sign-in quota"
That's it. Currently the maximum setting for this quota is 1000 per hour
.
This is one of many quirks that I am running into. While Firebase seems to be a nice framework/product/service, at the moment it doesn't seem to be totally ready for broad production deployment yet. In this case I only used one particular (fake) user for testing/debugging and only after just a few attempts (probably no more than 10 sign-ins), I ran into this issue. The funny thing is that my tests delete the fake test-user after each run so I couldn't see any user in my auth user table afterwards. The solution for me was to manually add that user via the "ADD USER" button and then delete it. I think they should have (at least as a workaround) a definable user that is for testing/debugging, who is not subject to this restriction, if they really feel they have to have such a (low) limit.
I have added my phone as a test number in the Sign-in method tab.
Actually this error occurs when your quota limit is exceeded.
Just add your number and testing OTP to get it worked.
Note: The testing number will not get any message of OTP as we already
defined static OTP code.
See my answer at https://stackoverflow.com/a/39291794/18132
I went into firebase > Authentication > sign-in method > google and added my client id to the whitelist.
I managed to get this working straight away by resetting the users password.
Steps are as follows:
Go into your admin console, Authentication, Users
Locate the user
Click on the menu dots in the far right hand column
Choose reset password, then click ok
Follow the steps in the email when it comes through
The error "We have blocked all requests from this device due to unusual activity. Try again later." is usually thrown when a user is making SMS authentication requests to a certain number of times using the same phone number or IP address. These repeated requests are considered as a suspicious behavior which temporarily blocks the device or IP address.
Additionally, there's a limit of 5 SMS per phone number per 4 hours. With this, you may try doing the following to resolve the issue:
Reduce the frequency of attempts to avoid triggering the anti-abuse system Try using whitelisted phone numbers for testing your app Use multiple testing devices (as the limits are applied per IP or device) Wait for an hour for the quota to lift
Add that number of yours to Firebase as a tester. This way you can test it as many times as you can.
Else multiple requests from one number to a project. Firebase deals it as a hacker and blocks it.
Add your number as Tester as:
Go to
-> Firebase Console -> Authentication -> Sign-in-method -> Edit Phone -> Phone numbers for testing (optional)
Add your phone number and verification code of your choice and that number will then work.
You will not get verification code from firebase, but you can give the verification code you set as a tester and can login through phone
One of the causes can be sending too may verification email to a user's email within a short duration of time. Try adding a duration timer and check if the verification message has been sent within the time duration.
If you are doing tests a better way to go about it is to add the phone number as a test number Authentication > Sign in method > Phone. Then add the test number + the verification code you'll use
I was facing the same issue and I solved this problem by Buying Blaze plan. This blocking seemed like a security measure on Firebase's side.
If you are using Firebase for development purpose, buying the Blaze plan won't cost you any thing as it has the same quota of free services offered in Spark plan.
Also, setting up Firebase Auth test phone numbers should help.
Per https://firebase.google.com/docs/auth/ios/phone-auth#test-with-fictional-phone-numbers:
Test with fictional phone numbers
You can set up fictional phone numbers for development via the Firebase console. Testing with fictional phone numbers provides these benefits:
Test phone number authentication without consuming your usage quota.
Test phone number authentication without sending an actual SMS message.
Run consecutive tests with the same phone number without getting throttled. This minimizes the risk of rejection during App store review process if the reviewer happens to use the same phone number for testing.
Test readily in development environments without any additional effort, such as the ability to develop in an iOS simulator or an Android emulator without Google Play Services.
Write integration tests without being blocked by security checks normally applied on real phone numbers in a production environment.
Fictional phone numbers must meet these requirements:
Make sure you use phone numbers that are indeed fictional, and do not already exist. Firebase Authentication does not allow you to set existing phone numbers used by real users as test numbers.
One option is to use 555 prefixed numbers as US test phone numbers, for example: +1 650-555-3434
Phone numbers have to be correctly formatted for length and other constraints. They will still go through the same validation as a real user's phone number.
You can add up to 10 phone numbers for development.
Use test phone numbers/codes that are hard to guess and change those frequently.
Create fictional phone numbers and verification codes
In the Firebase console, open the Authentication section.
In the Sign in method tab, enable the Phone provider if you haven't already.
Open the Phone numbers for testing accordion menu.
Provide the phone number you want to test, for example: +1 650-555-3434.
Provide the 6-digit verification code for that specific number, for example: 654321.
Add the number. If there's a need, you can delete the phone number and its code by hovering over the corresponding row and clicking the trash icon.

Sending a RESTful url (endpoint) from Band

I just have a general question. Can you send a url from a button on the band. I have a home automation system that you can trigger events by sending a RESTful url (endpoint) to. Basically I can put the url in any web browser and trigger the event. It would be great if this could be done through the Band. I don't really need a response from the Url, just to send it.
Does that make sense?
Thanks,
Scott
No, the Band communicates only via Bluetooth to (applications on) its paired device. On Windows (Phone), the application must be running, with a connection to the Band, and subscribed to the Tile button pressed event in order to receive such notifications. This generally rules out scenarios that require ad-hoc input from the Band unless you're willing to use voice commands via Cortana.
But i think its possible by creating custom tile and handling custom tile events. Haven't tried it in my project but can see from sdk documentation.
For android you can implement broadcast receiver and listen to tile events. Check: sdk doc
Chap 9, page 51
In short, yes it is possible.
However, the problem would be that the button would be single use to only send that ONE URL command and it actually wouldn't be done via the Band.
You can create custom layouts for your applications with the Microsoft Band SDK which will allow you to create a button. You'll then need to register to the click event from the Band which then would get fired on the device the app is running on. From there, you'd be able to send the URL but it would be sent from the Windows Phone or Windows PC rather than the Band so you'd need to be connected. The documentation covers how you can do this here: http://developer.microsoftband.com/Content/docs/Microsoft%20Band%20SDK.pdf
A downside to doing this with WinRT is that as soon as the app is closed and the connection to the Band is lost, your button click won't have any action. The best way to get around this is to create the connection to the Band in a background task but unfortunately, you can't keep hold of the connection to the Band for an infinite amount of time and you'd have to live with the possibilities that you may have times where it doesn't work. I have a GitHub sample which shows you how to connect to the Band in a background task for an indefinite amount of time.
The Microsoft Band has really been developed for the Health aspect and collecting data rather than interactions with other apps which it does in some way support.

Use GAE background thread to trigger SSE to multiple web clients

All,
I have completed the basic GAE "Guestbook" example which uses Google Cloud Endpoints and Google Cloud Messaging. I can successfully add a note to the guestbook and have it appear on all registered devices.
I've also used the super simple Server Sent Event (SSE) mechanism to have a web page initiate an event source and then update itself as events are received. But separate web pages appear to create their own distinct event sources (even if using the same URI to the event source) and thus get their own events at their own times.
The objective here is to create a bit of collaboration such that user actions can come from an android device or a web page and the effects the received action are then pushed to all connected users/devices/web pages.
I have assumed I will need a background module and that both Endpoints and 'normal' web pages / queries would channel the received user action to that background module. I believe I can get that far. Next, I need the background module to trigger a push notification to all interested parties.
I believe I can trigger a Google Could Messaging event to registered Android devices from that background module.
But it isn't clear to me how a background module can be the source of an SSE, or how the background module can best communicate with a foreground module that already is the source of an SSE.
I've looked at the Google Queue API, but I have a feeling I'm making something quite easy much more difficult than it needs to be. If you were not going to 'poll' for changes from a web page... and you wanted to receive notifications from an SSE source when changes were made by other users, possibly using Android devices rather than a typical web page, and the deployed application is running on the Google Application Engine, what would you recommend?
Many thanks,
Randy
You are on the right track, not really sure why you are using the background module but from what i understood you need to:
Your front end module receives an update
You retrieve a list of all devices receiving that update
Use the Queue service to send the update via GCM to every single device
Why use queues? because front end instances have a 1 min time limit per request and you'll need to queue work in order to go beyond that time to serve you (potentially) thousands of users.
Now, If you already have a backend instance (which does not have the 1min limit) you could just iterate over the list and send all messages on one request. I believe you have a 24 hr request limit so you should be OK. But in this scenario you don't have need for the front end module, you can just hit this server straight up.

How can I increment a Windows Phone tile notifications counter with Push Notification (not knowing the actual counter value)?

I am sending a XML with the "Count" parameter for tile update, and the tile is updating with that value, no problem here.
But I don't know how many pending notifications the user actually has, to increment. I see WhatsApp increments the counter immediately after I got a message. The only way to do this is to store the "unread" count in the server? I wouldn't like to do this because the user can: receive the notifications, disconnect, open the app (that will reset the counter), close, and connect to internet. When it happens, the "unread" count will be incorrect after a new notification.
(I'm using a standard tile for WP 7 compatibility)
Maybe this is a hint from the design gurus -- you might not need to show the user exactly how many unread notifications s/he has. Instead, you could make the push notification simply set a visual flag that there are some unread notifications. When the user opens the app, it displays all the queued notifications and resets the visual flag. Like a knock at the door: once you go to the door, you're going to let in however many dwarves you find waiting there.
Alternatively, you could use raw push notifications sent directly to the app, and let the app locally update the count on the tile.

Resources