I have created a nest client with refrence to this link.
https://developer.nest.com/documentation/cloud/register-client
Now this link use to say client have user :---
"after a client is created, then your users will be notified when you update the client"
1> So what exactly a NEST client is ? Is it a mobile or HTML app which can control NEST devices ?
2> What exaclty is the meaning of users in above statement ? Is it means suppose there are 5 members of the house, so there are 5 users ?
3> mostly the client server model is like this :--
html/mobile app <----> NEST service <-----> NEST devices
Suppose my home have 5 NEST devices & i want to control them.
Now where will this NEST service will exist :--
a> will it be in be in a standalone Embedded device running in my home, connected to internet MODEM at one end & NEST devices at other end ?
b> or NEST service will be running on cloud server. where my mobile app & NEST devices can get update & set the desired value for NEST device in JSON object ?
1)Client is an "adaptor" for the app you're going to create using the Nest API.
2)Users in this case are the tokens you get per each user of your app. For more details see access tokens in Wiki. To answer the second part of the question: If each of the 5 members has a different version of the app you developed with the Nest API and they try connecting to one of your Nest accounts then each of them will create a connection using an access token and will be counted as a "user". To read more, check out "How your users experience Works with Nest"and "User Limits"
3)Yes and no, you can see how it works here and here. This should answer a) and b) as you can have app to cloud Works With Nest connections and cloud to cloud.
Related
I'm new to working with sockets and have a small system design question:
I have 2 separate node processes for a web app, 1 is a simulator that is constantly running and the 2nd is an api server. Both share the same MongoDB database and we have a React app running for the client, served by the api server.
I'm looking to implement socket.io for real-time notifications and so I've set up a simple connection between the api and client.
My problem is that while the simulator runs, there are some events that I also want to trigger push notifications for so my question is how to hook that into everything?
The file hierarchy is like:
app/
simulator/
api/
client/
I saw this article for communication between node processes and I currently have 3 solutions in mind:
Leave hierarchy as it is and install socket.io package inside simulator as well. I'm not sure if sockets work this way but can both simulator and api connect to the same socket?
Move simulator file into api file to fork as a child process so that the 2 processes can communicate via child/parent messaging. simulator will message api which will then emit updates through the socket to client
Leave hierarchy as is and communicate via node-ipc. Same situation as above with simulator messaging api first before api emits that to client
If 1 is possible, that seems like the best solution in my impression. It seems like extra work to add an additional layer of messaging for 2 and 3.
Leave hierarchy as it is and install socket.io package inside simulator as well. I'm not sure if sockets work this way but can both simulator and api connect to the same socket?
The client would have to create a separate socket.io connection to the simulator process. Then, the client can receive data from the API server over one connection and from the simulator over another connection. You would need two separate, independent socket.io connections from the client, one to the API server and one to the simulator. Simulator and API server cannot share the same socket unless they are in the same process.
Move simulator file into api file to fork as a child process so that the 2 processes can communicate via child/parent messaging. simulator will message api which will then emit updates through the socket to client
This is really part of a broader option that the simulator communicates with the API server and sends it data that the API server can then send to the client over the single socket.io connection that the client made to the API server.
There are lots of different ways for the simulator process to communicate with the API server.
Since it's already an API server, you can just make an API for this (probably non-public). The simulator calls an API to send data to the client. The API server receives that data and sends it to the client.
As you suggest, if the simulator is run from the API server as a child process, then you can use parent/child communication messaging built into node.js. Note, you don't have to move the simulator files into the API file at all. You can just use child_process to launch the simulator as another nodejs app from another project. You just have to know the path to that other project.
You can use any another communication mechanism you want between the simulator process and the API server process. There could be a socket.io connection between them. You could use several forms of IPC, etc...
If 1 is possible, that seems like the best solution in my impression.
Your #1 option is not possible as separate processes can't use the same socket.io connection.
It seems like extra work to add an additional layer of messaging for 2 and 3.
My options #1 and #2 are not much code in each server. You're doing interprocess communication. You should expect to use some code to enable that. But, it's not hard at all.
If the lifetime of the simulator server and the API server are always together (they have no independent uses), then I'd probably do the child process thing where the API server launches the simulator and then use parent/child messaging to communicate between them. You do NOT have to combine sources to do this.
The child_process module can run the simulator process by just knowing what directory it is located in.
Otherwise, I'd probably make a small web server on a non-public port in the API server and have the simulator just send data to that other web server. I often refer to this as a control port. It's a way of "controlling or diagnosing" the API server internals and can only be accessed from within the private network and/or with credentials. The reason I'd use a separate web server (in the same nodejs app as the API server) is to make it easy to secure so it can't be accessed from the outside world like the regular public APIs can. You just put the internal web server on a port that is not exposed to the outside world.
You should check Socket.IO docs about adapters and Emitters. This allows to connect to sockets from different node processes and scalability.
I am using Angular CLI latest version and NodeJS, want to archive web push notification, we got few documentations but gives error, May I know any Documentation for web push notification which supports angular and nodejs.
The requirements are send push notification to all users who notification granted while browser closed as well.
Sample docs :
https://ciphertrick.com/2017/03/14/browser-push-notifications-in-angular-applications/ (getting error pushNotificationModule not exported)
https://www.npmjs.com/package/angular2-notifications (Not clear for CLI)
The Angular2+ directive angular2-notifications is doing only the last part showing the message in UI/UX. And that is the least of your challenges.
You say:
The requirements are send push notification to all users who
notification granted while browser closed as well
The part 'while browser closed as well' is the tricky part.
This means you need a Service Worker. A Service Worker is a script that your browser runs in the background, to which the message is being pushed when the browser is closed. For a nice introduction to Service Workers, read this. Angular has a Service Workers implemented in production version since 5.0.0. Klik here to read more about it.
I don't think setting up a WebSocket connection (like socket.io) from Node to a Service Worker is possible. It's complicated, some people say it's possible, others say no. See this for more info. I would at least say that it is not stable enough, so you need a 'real' push notification.
You can use a push notification provider to do the job. Click here for a list of them. You pay for these services.
If you want to do it yourself (free of costs) you can use Google's cross-platform messaging solution Firebase Cloud Messaging (FCM) (the successor of Google Cloud Messaging (GCM)).
To connect your NodeJS server with the FCM you can use different libraries e.g. node-pushserver and many others.
I'm trying to make it so that NodeRed uses a webhook to send an interactive message to a slack app to ask permission to activate something. I can POST to the webhook without any issues from my custom node, but how do I get the reply?
Do I need to use the "http in" node to create an endpoint Slack can use? Is there a way to handle it from the same node that POSTs the message?
Also, I'm running NodeRed locally. Can I use ngrok so that Slack can access the http endpoint (in case I need to use that)?
You can define your own http endpoints that are private to your custom node, this is how nodes that need to do oAuth handle the callback. Also nodes like the serial port node do this to supply information to the config dialog.
Make sure to give the endpoint a unique route so it's unlikely to clash with any other nodes.
You can look at the source for the serial port node here
How you ensure that Node-RED is safely made accessible from the internet should be a separate question.
1) Yes, ngrok works nicely for exposing your local webserver securely to the Internet and Slack. I use it every day for my Slack app development. Keep in mind that if your app can't be reached from the Internet, then also Slack can not reach it.
2) Interactive Messages only work with Slack apps. One reason being that you need to provide the route to your app, so that Slack knows where to send the requests when someone uses your interactive messages (e.g. clicks on a button). But you can use interactive messages with webhooks, as long as both are setup within the same Slack app.
3) Don't believe the "http-in node" approach will work. As said, you need to configure the route to your app for receiving messages from Slack in your Slack appp.
I'm building a simple node app for broadcast messaging using socket.io. It will have 3 users at a time
user 1: Moderator (gets a stream of social media comments from various APIs, picks messages to send to user 2 and user 3)
user 2: Graphics (displays messages pushed from user 1 as graphics in OpenBroadcastSoftware)
user 3: Host (displays messages pushed from user one on an iPad (to field viewer questions)
This is all for realtime use, nothing needs to get saved or logged.
I know all the basics of sending and receiving socket.io messages.
My question is, for portability, I want to host this App on Heroku
If this was a single Free/Hobby dyno app, would I need any sort of backend like Redis? Or would it work as if i was hosting the app on a local server since there is only once instance?
This app is never going to have more than the 3 users described above, so I'm not looking to implement any scaling what-so-ever
Thanks!
No You don't. The websocket can work with just the app, tested it out.
I want to build a Raspberry Pi (RPi) based device similar to the Nest Thermostat, except that I want to control light switches. I know I could easily code up a Node.js script on the RPi and then just hook it up to my local router and control it with a PC hooked up to the same router.
But, I want to make it more like a Nest. I want to be able to control 20 (or more) RPis across different subnets through a cloud provider like Heroku.
The Nest thermostat does not require the user to open a port on their router so that the Nest server can communicate with it.
How is Nest able to control customer's thermostats over the web without enabling port forwarding in the customer's router?
Blog post Nest Thermostat API using Node JS and Nest API Update discusses the API
between the thermostat and the nest lab servers. In particular:
The API uses mostly JSON formatted data POSTed to their web servers.
So there is your answer. By periodically POSTing data to the nest web servers using HTTPS, Nest is able to avoid having the user open any ports on their router.
For what it's worth, the unofficial API (in node.js!) from the blog post is available on github: Unofficial Nest API on Node.
I think the thermostat periodically posts a request with the thermostat serial number to nest. It may have timeouts in the http headers set to infinity or more likely, the nest server simply closes the connection after a minute or so if no command for that device has come in. Whenever nest closes the connection the thermostat opens a new one. When a command request comes in with serial number, its a quick lookup to find the thread currently connected to that thermostat. The command is sent in the payload of the current thermostat request, which is executed, the connection is closed, and the thermostat opens a new request to nest .
Take a look at eventSource in the HTML 5 standard. It does everything that is required.