I'm a newbie to DialogFlow and I don't event know if what I want to achieve is possible.
I'm trying to create a DialogFlow intent that would make an HTTP request from the user device after receiving a given command. I know how to do this with webhooks, but problem is that webhooks HTTP requests come from Google servers, and not the user device.
The reason why I want the request to come from user device is that the receiver will only listen to local network (it's a web server running in an internet router). So this will only work if the HTTP request comes from a device connected to the router.
A workaround could be to create a public tunnel to the router (with softs like ngrok), but my application aims at real users, so I would prefer to avoid this complex setup.
Is it possible to do local requests with DialogFlow? Or is there another Google-Assistant API I could use for this purpose, like Google IoT solution?
Thanks
You could do this, but you wouldn't necessarily do it like a regular Dialogflow project. Here are the steps:
Build your Action through Dialogflow and add web fulfillment
Add a way to push a notification of some sort to your local device
This could listening to a database, polling, push notifications, etc.
When your device gets that notification, it performs the action locally
If you want this local action response to be sent back, you could update the webhook through an HTTP response (if making an HTTP call) or updating a field in a cloud-based database.
Actions do have a timeout of around 5 seconds to get a response, so be aware of that limit if you want to do this
Related
On this page they explain Web Push with Service Workers stating
Chrome currently uses Firebase Cloud Messaging (FCM) as its push service. FCM recently adopted the Web Push protocol. and then explaining Firebase and so on...
Since the Service Worker gives me a unique endpoint and a pubkey, it seems to me that technically it should be possible to use that endpoint directly, without anything additionally - except if Google deliberally forces a registration.
I mean, just send a POST request to that endpoint, sending just the notification data encrypted/authenticated using the pubkey without any "VAPID".
Do I absolutely need a Firebase account or is it possible to access the endpoint directly (without additional registration) if I just want to send a notification to a single device?
It's 2021 and all major browsers implement a push service and support VAPID now. You use a web push library (Javascript, Python, C#,..) of choice.
There is no need to register anywhere.
The technical mechanism in short is this:
You generate two VAPID keys once using the push library. One key is private and one is public.
The public key is used in the javascript as "application server key" when subscribing to the push service of the browser.
If the subscription is successful you receive a subscription object from the browser containing an endpoint and two additional keys.
The endpoint is an address depending on the web browser / manufacturer and the service it is currently using. The endpoints look like (Oct 2021) e.g.
Google Chrome h_tt_ps://fcm.googleapis.com/fcm/send/cz9gl....., Microsoft Edge h_tt_ps://wns2-par02p.notify.windows.com/w/?toke....., Mozilla Firefox h_tt_ps://updates.push.services.mozilla.com/wpush/v2/gAAAAABhaUA....
If your server program has this information (endpoint and keys from subscription object) it can send a push message to the endpoint with the push library. The corresponding service in the web, hosted by the manufacturer sends this to the browser's service on the device.
There is the PushAPI which shall get used.
But it doesn't is supported by every Browser at the moment.
You can find nice examples in the Service Worker Cookbook of Mozilla
I have a couple of questions on Firebase. I went through their documentation on their site, and the tutorial. I've never used anything like this before, so it's a bit confusing:
I see there is a REST API and a Javascript API. Is the main difference that the REST API is more like a traditional API and requires polling, whereas the Javascript API allows you to receive deltas from Firebase itself?
I want to create a service that receives these deltas and stores them in my own database. But I don't understand how Firebase can keep a connection open for so long. I'm assuming there must be a connection open that Firebase pushes the data through back to my service. Is there a time limit? Or if the connection gets closed is the best practice to detect this error and re-login?
There are many differences between the Firebase REST API and its client libraries. The biggest difference is indeed that most REST clients don't use a persistent connection. But REST clients can listen for changes too, using Firebase's SSE based REST Streaming.
Firebase uses web sockets to establish a persistent connection from the client to the server. On browser platforms where web sockets are not available, the client falls back to HTTP long-polling.
We are using Elastic Beanstalk to serve a REST API. Now, I want to develop an endpoint that serves notifications from an SNS-topic in an asynchronous way.
In order to receive those notifications, I need to subscribe the API-servers to the SNS-topic. How could I do this, with the scenario in mind that the EBS application can scale up to multiple servers and scale down again? I don't want a lot of dead links subscribed to the SNS-topic...
In spring world we have a #PostConstruct which gets called on server startup, where you can subscribe "this.server" url to a given topic (you may need to build a proper working subscription url --using InetAddress et el).
Hence there is the working subscribe url using #RestController which confirms such an subscription instantaneously causes sns endpoint to be registered. Any new servers will do the same aka getting registered themselves (when new stack is created). We also need additional code for the consumption of notification messages subsequently and do something when confirmed subscription endpoints receive one.
The way AWS wants you to use SNS is not by directly subscribing to it. Any notification which need to trigger something in a component should buffer notifications with an SQS queue. For this reason we chose to do Pub-Sub with a variable/scalable group of Subs using the Amazon managed Redis distribution.
I'm trying to understand what I will need to build on my server for Push notifications to work successfully.
My thoughts were:
The phone sends the notify URL to my server
The server stores the information in a Database
A separate process or PHP script will query the database and open continuous looping process for each device. (Each socket will be querying a 3rd party API)
When there is a change detected in the API for that device a push notification will be sent to the device's notify url.
Is this the right method on what needs to be done. Isn't this going to eat up server resources or is it the expected outcome of Push a push notifications server?
I've produced a simple diagram on all this below:
First of all, let's separate the process in the main stages needed for PUSH.
Device subscription.
Send the PUSH
Process the notification on device.
Subscription
For the subscription, your device (more specifically, your App) must call the PUSH api,for enabling PUSH notifications. This call to the push API will give you a URL that uniquely identify the device where your application is installed and running. You should store this URL on your database, the same way you store a user's email, or a user's phone number. No special black magic here. You only use it when you need to send a communication to a user.
Send the PUSH
For the push stuff, the same approach as for email, or SMS messaging here: "One does not simply make an infinite loop and send a message if any change is detected". What you have to do is, just send the PUSH message when your application needs to. So you have the user to which you want to send a message, instead of opening a SMTP connection to send ane mail, just build the PUSH XML Message and call the URL associated with that user. Some things to consider here are:
Network reliability (you need to retry if you can't connect to the server).
Response error code-handling (you don't need to retry if the server tells you that the phone has uninstalled your application, for example).
Scalability. You don't want to send a PUSH message from your PHP code, because you don't know how long it will take for the task to be completed. You have to make this thing asynchronously. So just queue up all the push messages, you can create a separate process (windows service, nodeJS service, cron job, daemon, etc.) to send the PUSH, handle retries and errors and clean the queue.
Process the notification on Device
So now that you are this far, you need to handle the notification on the phone. It depends on the type of PUSH notification that you are sending:
Tile. You will update the image, text and counter of the application tile, if the user has put your application to the start screen. On client side you need nothing to so, as all these parameters are part of your PUSH request.
Toast. This one requires a title, text (limited to some 35 characters more or less) and a relative URL inside of your APP. Your application will be launched (like when you click on a Toast notification from Twitter, for example) using the URI that you specify in the payload. So a bit of data can be already injected here. You may/or may not make a request to your server for new data. It is up to you.
Raw. This one is pretty much silent. Is not seen by the user if your APP is not running. As you might guess, this kind of PUSH is useful to live update your running APP, instead of continuously polling your server, wasting user battery and bandwidth and wasting your server resources. You can send anything (raw bytes or strings) up to the max size of the payload allowed my Microsoft.
If yo have any more questions, don't hesitate to ask.
Bottom line: separate the PUSH sending, make it async, don't you ever forget that...
Your PHP script that continually pings the database for changes...THAT is what will eat up your system resources. Push notifications go hand in hand with Event Driven Programming. This means that ideally, your code shouldn't continuously ping your DB. Rather, when something happens (ie, an "event"), THEN your code does something...like contact your phone via push notification.
Your steps for push notifications are more or less correct, but are incomplete. Step 4: the server contacts the client via the notify url (which you have). Step 5 is that the client then contacts the server to actually pull down the information it needs. That is: The new information is not provided to the client via the notify url. Once the client has its new information, then the program continues as normal (populates a list, downloads skynet, etc.)
Your third step is very wasteful and not practical if your app is installed on more than a few devices.
Instead, each device should be subscribed to types of server updates it cares about. Your server's DB will have a mapping from each type of update you support to the list of notification channel URLs of devices that care about this update type.
When your server detects an update of type X, it would send a notification to all devices subscribed to that type of update.
I have an app set up to generate passbook passes. The successfully install on the device and I can do manual (pull-down) updates.
Next I began to implement APNS. I'm using the enhanced request method to connect to the production environment, sending in an empty payload (as required) and it returns no error codes when I request a push notification, but my pass never updates and I see no requests hitting my server. I'm using my own device to test until I can get see an update for myself. No pass updates are received.
I then implemented the Feedback service in the hope that it might tell me something. I noticed this. If I pass in the push token, I receive a response which indicates that the device is not receiving notifications (even though the pass is set for automatic updates). The pass is not updated.
I'd appreciate any info into why the the push notifications do not seem to be arriving.
Thanks.
-Erich
One gotcha to check is that you are not using the sandbox APNS server. All Passbook push requests should be sent to the live APNS server.
Try enabling the additional logging option from the PassKit section of the Developer Settings on your device then connecting your device to Xcode and monitoring the console as you send the push. If the push is received, then you should be able to see your device requesting the serials to be updated from your webservice and you should also see your server's response.
Assuming you send a serial and that it matches the serial installed on your device, you should then see the device requesting the updated .pkpass bundle.
If no push is received, try toggling automatic updates on and off while monitoring the device console. It could be that the device is not receiving a valid registration (201) response or that you are using a stale token - you'll be able to see these via the console.