I am trying to integrate smart home devices with Google home and Alexa but I am facing following issue.
Communication between Google Home/Alexa and our device cloud server is HTTP.
Communication between smart home device and our device cloud server is MQTT.
How do I keep track of synchronous request-response? Is there a better way to implement this system?
Perfectly possibly to do with HTTP to MQTT and back again.
I've done it for both Alexa & Google Home for my Node-RED nodes.
You just need to keep track of on going requests and include a unique id in the request/response MQTT messages while also running a timer to handle no response from the device.
The project gBridge (https://github.com/kservices/gBridge; https://about.gbridge.io) basically implements plain Google Assistant/ Alexa to MQTT bridging.
Regarding your questions, there are two points that help to implement these solutions:
Think in terms of devices or endpoints, rather than requests. When you just want to "translate" HTTP to MQTT, you are inducing a lot of issues like you've figured out. You probably want to implement a logic that allows MQTT topics to control/ query your actual deviecs - not ones that respond to HTTP requests. This makes thing a whole lot simpler.
Caching is essential. Allow your bridge to have a local copy of your device's states. When having the properly implemented cache, you won't need for any response. Just use the cached data.
Related
Currently building a mobile application that ideally would have functionality that allows one user to "nudge" another user, pretty much the equivalent to a Facebook "poke." For the sake of building quickly, we'd like to use as many third-party libraries/services as possible. So far we were looking into using pusher and expo, but to be totally honest, we are a bit confused as to how to architecture this.
From what I understand, the front-end (ios app) would subscribe (open a socket) to a specific channel/server and the server would then send messages to the client(s) that subscribed whenever necessary. How this works with users being subscribed to every other user they are friends with, I don't understand. What's the proper way to architecture this?
I also read that on the front end, when a user doesn't have the ios application open you can't have any websockets open to the server, so how does that work?
Additionally, how does one bundle notifications??
Really confused with this, any help would be greatly appreciated.
Chris
Well, push notifications now mostly are implemented with Firebase. This is a service inside most of mobiles, so you only need use these libraries to implement your client application.
From the server, you only need to consume a rest api of Firebase.
Now there are permissions to allow mobile applications receive push notifications in background. You do not need to implement a socket or websocket, that is a feature of Firebase.
Read more about this.
https://medium.com/google-cloud/push-notification-for-react-native-bef05ea4d1d0
https://dzone.com/articles/how-to-add-push-notifications-on-firebase-cloud-me
Is there any way to create your own google IOT device based on webhooks and POST-request? Without using firebase, IFTT, node.js
Samples that Google are very poor, they don`t show all steps of creating your own app, they just showing how to deploy "their sample"
I tried to make action with dialogflow & webhook, it was pretty simple. Just processed JSON in POST request to Azure function.
But when I try to create IOT device, its ask me for fulfilment url and it does not even tries to reach that address. I read about action.device.sync, action.device.execute, it just does not communicate with the specified address, giving simulator some voice command doesn`t affect at all. Are there any ways to create IOT device to work with POST-requests & web-hooks?
The answer is it depends.
There are many different ways to do server-device communication: web sockets, local servers, hub/local control, polling, MQTT, and likely many others. All of these solutions have trade-offs, and work in particular circumstances. Depending on exactly what IoT device you want to build, its requirements and technical specs, and what cloud providers you are using, you may identify what works best.
If you run the sample, you'll see it is sending JSON requests to a server and expect JSON responses back. This is must like Dialogflow & a webhook. In this case, the smart home platform communicates solely with the server.
Your server can then communicate with the device in any way that you want. I'm not too familiar with Azure offerings. It might have an MQTT service as well, or some other sort of push notification service you might be able to use.
If you're seeing simulator issues, you may need to make sure your authentication is set up correctly, and you'll need to first complete account linking on your phone before you can use the simulator.
If you had to open a resource from a database in a web browser on another computer, using an Apple tablet app as a remote control, how would you implement such a feature? This is basically what WhatsApp Web does, so it should be technically possible. But how would you go about it?
I'm assuming that you mean a situation where the app modifies something on the server, and the browser then updates automatically to reflect this. If you mean something like the iOS Remote app, then you may have to use another method (and you may not be able to do it from the browser).
To do this you'll have to have a server that both the iOS app and the browser are connected to. When the app does something, it updates the server, e.g. by submitting an HTTP request to a REST API. The server then updates the database.
Now you have to get the browser to update, and there are two ways of going about this. One is by polling the server periodically, using AJAX to update parts of the page dynamically without refreshing the whole page. This works, but there's a lot of overhead and it can be a drain on a laptop battery.
The better, but slightly more difficult to setup, alternative is to use WebSockets. WebSockets allow for two-way communication between server and client, and the connection stays open until one party closes it (or it times out after a long time). The client can submit information to or pull information from the server as before, but the server can also push information to the client without the client having to request it. This would typically be how games, chat clients, etc. can operate nearly in real time.
Setting this up isn't necessarily that difficult, but it's a very broad, open-ended topic that's beyond the scope of just iOS development. Beyond the iOS app and the web client, you'll also need a backend that's capable of using sockets. Node.js is a popular JavaScript-based backend for this sort of application; there are numerous others out there as well. You'll have to do your own research to determine what's right for you.
I just wonder why and for what kind of application or case we need the Socket.IO.
I am the iOS developer of a known open source project socket.IO-objc
Usually, we need HTTP or HTTPS to communicate with server. The socket aims to conduct real time communication (It should always keep a live HTTP connection.)
Libraries like socket.IO are needed when we need real-time in our app. Let me explain this in little more detail. Let's assume that you are developing a game, which is multiplayer and 2 or more users can play that simultaneously. Then, in that case, you won't be making HTTP or HTTPS calls because of many reasons and one of them is that their packet size is large and other is that these calls are very slow. In such scenarios we use libraries like sockets to send and receive data to and from the server. Sockets are really fast and are capable of sending only those data packets which are needed. Using HTTP programming you can never create any multiplayer game or any app which will be interacting with a server on a realtime basis.
Let's take another example. Let's assume that you are working on a chat application. When user A is typing something then user B should know that A is typing (similar to gtalk of facebook messenger). If you will use HTTP calls at that point of time then "B" will never be able to see the actual status of the other person because of the delay. So what we can use is sockets so that when user A is typing anything then his device will send only one data packet which will just notify the server that he is typing and will be delivered to user B, this process is really fast (almost realtime) and will reduce the data transfer also.
I'm working on chat application using socket.io also. So it seems to replacing everythings with socket.io. This is making me in doubt and curiousness. I totally agree with real-time app like chat suits for socket.io. However there is round-trip communication (such as user login) that's more suitable for HTTP.
Socket.io uses web socket to pass data among users who are all connected to a web server. With web socket, there is no negotiation protocols and connection remain open as long as users concerned are registering for service with the web server. As pointed out also, the payload is significantly less than http/https protocol.
Socket.IO is a JavaScript library for realtime web applications. It enables realtime, bi-directional communication between web clients and server. It has two parts: a client-side library that runs in the browser, and a server-side library for node.js. Both components have a nearly identical API.
I'm trying to make an iOS 5 app that features real-time things coming from the server. It will only use these whilst the app is running.
To make it real-time without polling I have been evaluating two design routes:
Creating a socket from the app to the server, and exchanging information via streams.
Pros: Relatively simple and would not involve a 3rd party.
Cons: Battery life drain.
For an overview of how this might work, check
out this excellent tutorial:
http://www.raywenderlich.com/3932/how-to-create-a-socket-based-iphone-app-and-server
Using standard HTTP to communicate with the server, and with each request from the app let the server know what they are viewing. If something new is available for user, send an Apple Push Notification (with no visible alert) to let app know it can go and download new thing.
Pros: Not opening up a new TCP connection, so battery life not drained unnecessarily.
Cons: Feels like a poor hack.
The official docs on APNs http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
I think a socket would be the way to go, but before I commit to it I wanted a second opinion, as this is the first time I've made anything like this!
Sockets would be my choice. I do not know how time critical your application is, but sockets might perform better as APNs if realtime is a must.
Does it really need to be "full real time"? From my point of view i would prefer http since it is already well integrated into the iOS SDK. Its easy to understand, maintain and implement and plenty of documentation is on the web. So maybe a http poll every minute or so will be enough (depending on the app and the number of users). Please consider firewalls too! Traffic to unknown ports maybe denied due to firewall policies of provider or local wifi. So if you really need realtime connectivity I guess you have to use sockets.