I am developing thermostat ReportState functions, I use Smart Home Report State Dashboard to
check the status, It seems report state is OK when I manually set the temperature, I can see the temperature value from dashboard, but I try to use google assistant App to set or ask the temperature, it will return correct status by voice, but In google assistant App UI status no
changes as attached file. Is anything I miss reply to Google’s Home Graph?
Here is the state value I report as below:
{
thermostatMode: 'cool',
thermostatTemperatureSetpoint: 89,
thermostatTemperatureAmbient: 76,
thermostatHumidityAmbient: 61
}
BR,
Jack
This is most likely not related to your Report State implementation. That UI panel is populated using your response to the EXECUTE intent and the subsequent QUERY issued to confirm the state change.
Ensure that you are returning the updated state in the EXECUTE response, and verify that the state values you provided via Report State are also present in the QUERY response (a QUERY response should always contain the full set of current states).
Related
I'm building a SPA site in React (using redux).
To my site, any user can connect through Google or Facebook.
Each user who logs in to the site receives a personal user_id.
For each user, the system needs to keep a history of documents created by this same user (like the recent docs in Word).
I need to create functionality that whenever the user is logged in he will be able to see a history of the five documents he has created/updated.
In addition, the latest documents will load even after disconnecting and reconnecting to the system.
To load the history into the system I am thinking of using a dedicated index in ElasticSearch.
My question is which way would be suitable the most to use when the user is already logged in and creates several documents one after the other -
Should I need to save everything within the index in ES or is there a smart way to save and update the information locally without producing a lot of calls to DB?
I want that in the end there will be only 2 DB calls that are made in total - one call to load the information on login and one call to update the information when the user logs out. Any other create and update docs will save locally on the client side until leaving the site.
After the successful authentication on Google, user get event information
Which is processed on our server.
But if any events edit or delete user is not able to getting update regarding this, user need again call calender api.
How we can get changing update regarding google calendar events on our server without again call of calendar api.
If I understand you correctly, you want to receive a notification to your server whenever a calendar event changes.
If that's the case, consider using push notifications:
First, set up a URL where notifications will be received.
Second, call Events: watch to set up the notification channel.
Take a look at push notifications for a complete guide on this, and Events: watch for documentation on the method you'll have to call after setting up the webhook.
Non-technical person here 🙋♂️
I'm having an issue where (using the Oauth 2.0 Playground) I authorize an internal user's GMB account and configure real-time notifications to be sent to our GCP topic. Every few days or so, notifications stop getting sent to our topic and when I check the notification settings for that account, they have been subscribed to an unknown GCP topic. I can reconfigure the notifications settings again, but every few days they are reconfigured to the unknown GCP topic.
It's possible some other app is overwritting my changes periodically, but I am having trouble figuring out where they're coming from.
Is there a log I can review to know where the request to change the notification settings is coming from?
When using the OAuth 2.0 Playground to configure settings, do they "expire" at some point? If so, is how do I prevent that from happening?
Thanks in advance for your help!
You can start looking into when and who created the unknown GCP topics by checking your Cloud Logging for created topics. You can do this by:
Open your Google Cloud Console
Open "Logging"
There should be a "Query" tab and select it.
Input protoPayload.methodName="google.pubsub.v1.Publisher.CreateTopic" and click "Run Query". You can check this reference if you'd like to see other logs related to Pub/Sub.
Click "LAST 1 HOUR" to adjust the time parameters of your log query. (Example: adjust it to a whole month to query all Created topics within a month)
Click the ">" beside the result and expand the log.
There are lots of info like the created topic name, what email authenticated this request, etc. In your case you should look out for field authenticationInfo for you to check who invoked the request:
authenticationInfo: {
principalEmail: "email-used-to-create-the-topic#example.com"
principalSubject: "user:email-used-to-create-the-topic#example.com"
}
NOTE: For testing purposes I blacked out my project-id and email for this example. Also the topic I created is log-this-topic and the email in the log mine since I was the one that created the topic.
OAuth have set rules for expiration, you can check it on Refresh Token expiration.
I am developing a REST API based on Node / Express and a frontend for it based on React / Redux. Users can login (which gives them access to additional functionality) but they can use basic functionality also without logging in.
When a user logs in, the client makes an HTTP call with the credentials, the server creates a session and returns a user object (user_id and some other data) as well as a session cookie. The React app saves the user object in its Redux state. In subsequent HTTP calls, the user is authenticated through the cookie.
When rendering the user interface, the React app determines whether it is logged in or not by checking for a user object in its state. This is used to grey out some buttons which are only available to logged in users, or to hide the login link when the user is already logged in.
The problem
It could occur that the session expires, or that the user logs out in a different browser tab. The React app has no way of knowing this and thinks it is still logged in (i.e. app state mismatches reality), leading to wrong UI display.
What pattern to solve this?
Put a hook on all Ajax calls to check for 401 and update the
state?
Return session state in HTTP headers (and then?)
A Comet pattern for the server to notify the client that it has been logged out? (not a REST API anymore then)
Additional calls before actual API calls to make sure user is still logged in? (seems wasteful)
And how to deal with this once the client detects it is no longer logged in during an ongoing operation? I'd prefer to handle this in one place rather than all functions making API calls...
I'd be thankful for some best practice!
There are two straightforward ways to deal with this issue in a React application that I can think of. Both inspired by a colleague of mine few days ago.
Use SSE (server-side-events) technology to PUSH notifications. As you correctly pointed out, this makes your API less pure. This approach should be quite an acceptable sacrifice where flawless UX is required AND/OR your server might need to push other notifications to the app.
Establish a short term timer somewhere in your client app (e.g.: setTimeout(...)) that makes periodic calls to a "ping" API endpoint that will return current user/session information. This approach will impact UX for the duration of timeout, often negligible, and is commonly known as polling.
Hope this helps!
As an alternative to the naive polling, you can make it a little smarter by adding an endpoint that lets you know in how many seconds timeout is set to occur for the session at that point in time.
Then ping just before that time (instead of at a certain poll-rate) and update accordingly.
Logging out in another tab would return with an invalid token so would be picked up, too, but not as quickly if this is your main concern.
For this you could use broadcasting to let the other tabs know immediately (or use sessionStorage's change event to simulate a broadcast on unsupported browsers).
Otherwise the best way would be to implement a ServiceWorker; these can handle all requests for your app to the server. It's a centralised piece of code separate from your app that can broadcast to all tabs that a session is lost the moment it sees that one of its requests was rejected, and you can efficiently naively poll from this one place (instead of in each individual tab's runtime).
Since I am using token from the API Server that is valid for a specific period of time. So in addition to setting token in session storage I was thinking of setting up another session storage variable that stores the timestamp at which the token was generated. Then, in my js code I plan to add the validity period (say, 3600 seconds) and check if the token is still valid or not. If it is valid then the user session is valid else it is invalid.
I am building an sample application that lets user store comments.
I've created the registration and login process. When the user registers, his details are stored in a MySQL database and a token is returned to the browser. Now he can access the Profile page.
When an existing user logs in he is redirected to the profile page. The profile page is accessible only when a user registers or logs in.
After logging in, I want to show all his comments if he has already added them.
My frontend is in Angular and backend use Laravel. For authentication I use Satellizer.
I want to know, what is the best approach while playing with data, considering the fact that the user will add, edit his comments. Should I use localstorage and store data in a key value pair or should I create a json file which gets updated everytime the user adds a comment or makes a change.
I wanted to know what is the most efficient way to deal with data from server so that the application is fast even when it scales to a 10000 users and lot of data for each user.
Thanks
You should be updating it on the server when changes are made rather than only relying on localstorage. You can use localstorage to cache, but it should only be for immutable data, it shouldn't really be used for data that is going to change.
So in this case you'll be adding and updating new comments via your API (ideally a RESTful one!). Once you've made a change, you could store the comments locally and only update them when the user makes a new comment, however you'll quickly run into issues where the data is invalid on different clients. (i.e. if you update the comments on a different computer, the other computer won't be aware).
Alternatively, you could cache the comments and then simply ping the server to find out if new comments have been added. This could be using a HEAD request for example to check the last modified date on your comments resource.
You can store comments data locally on user browser, but you should properly manage it.
I don't how much load your server will have and if the time invested now worths it.
You can fetch comments and store them locally
User adds a comment, then you update locally and send a request to the server
You need to track the request response, if requests fail so notify user and remove comments from local.
if request was successful so you can continue on your way.
** facebook uses this "success first" approach
user does an action, and he see it happens instantly, in the background it could take few seconds, only if it fails they will notify you.
** look at their commenting process, when you comment, it appears instantly, no loading... but in the BG the load happens.