I just simply cant get it to work.
How can you push an incoming MQTT value to a php page in a Node-Red flow?
"1" is sent to topic "test", I then would like this to be pushed to a blank PHP page, just a simple "1". I do not want the PHP site needed to be refresh.
Appreciate all the inputs I can get! Thanks. :)
If you want truly instant updates then you have 2 real options
Skip Node-RED all together and just subscribe to the same MQTT topic using MQTT over Websockets and the Paho Javascript client. This requires the broker to be running a Websockets listener, but most of the major brokers support this these days.
Use the built in Websockets nodes to provide updates to the web pages. You will need to add a Websocket client to the page and then connect back to a pair of Websocket nodes (input/output) and wire in a MQTT subscriber node. An example Websockets flow can be found here
Related
I would like to create cloud service like arest.io to access MQTT broker (Mosquitto) via REST API like it is on cloud.arest.io service. The main goal is bridge between mosquitto mqtt broker and apache2 http server to getting access to sepecific mqtt topics like:
cloud.arest.io/47fd9g/digital/5/1
where 47fd9g/digital/5/1 means publish "digital/5/1" in "47fd9g" topic. In the http response I can get JSON data from my IoT device connected to "47fd9g" topic. If you ever used the arest arduino library and arest.io cloud, You know what I mean. I have ubuntu based server with apache, php, mosquitto, php, Mosquitto-PHP php extension. Mosquitto works fine with my IoT device but I don't know how to mosquitto and apache make working toghether like arest.io.
There are a number PHP MQTT clients that you can use to write service as you describe, but you don't directly connect apache to mosquitto. You will have to write the bridge.
But encoding data into the URL as you suggest is not going to work well, it assumes that topics are only ever a single level deep which really doesn't scale well and doesn't allow the use of wildcards.
It would be better to have a HTTP POST to http://example.com/some/multi/level/topic, with the message payload as the body of the post would publish to a the topic some/multi/level/topic makes a lot more sense.
I am having two tomcat servers running same web application. Both the web applications subscribe to topic 1 in MQTT server. Whenever message is received in topic 1 both the applications receive the message. But I want only one server to process the request instead of both. The worst case I have to do condition check at both the web applications to allow one time processing. Any suggestions for this case ?
You need to use a MQTT broker that supports Shared Subscriptions1
This feature allows you to have multiple clients subscribed to the same topic and the broker will deliver them in a round-robin fashion to all the clients (e.g. first message to client 1, second to client 2, 3rd to client 1, 4th to client 2...)
1 Shared Subscriptions was a feature a number of brokers implemented at v3 but with different mechanisms so they were not always compatible, as of v5 of the MQTT spec Shared Subscriptions is an optional component the broker can support and all brokers that implement the feature should behave the same.
I was reading this about topic subscription. So if I subscribe using a wild card, to the # topic, then I will receive all the messages.
Does that mean I could intercept the communication? When someone is publishing a message to a secret topic, then I will also get it.
Obviously that is not the case. But what am I missing?
On a related issue, how does the broker prevent users from subscribing to specific topics or publising to other? I assume not anybody can just send data to a broker. Is it somehow similar to HTTP?
With the basic out of the box configuration, anybody can connect to the broker and subscribing to # will get all the messages published and you can publish to any topic you want.
The MQTT protocol includes support for authentication as part of setting up a connection to the broker. Once you have an authenticated user it becomes possible to apply rules to what that user can do. Different brokers implement how create those rules in different ways, but mosquitto has support for ACLs.
With the ACL you can define what topics a user can subscribe and publish to. The built in mechanism for this is a flat file, but there is also support for a plugin system that allows you to keep username/password and allowed topics in a database. This allows the ACL to be easily updated without having to restart the broker.
From a Web Server running in Windows 2012, I would need to send messages to specific clients. These clients are Delphi applications, over 2000. Each message is for a specific client, no broadcast.
Which technology can I use? I am totally new on this issue.
I am seeing Websockets, SignalR (that is based in Websockets), MSMQ, RabbitMQ, ...
MSMQ: Seems a good solution. Cons: It only works in Windows. Maybe in a future, I need to add other platforms as clients.
RabbitMQ: It is also good,but I think that it provides too features for my scenario. Basically I only need to send messages from server to specific clients.
SignalR: I am confused. It seems basically for web browsers, not for client applications. It seems a simple solution.
Basically, I am looking a simple and basic solution that I can implement in Delphi to receive messages from a web server.
WebSocket (a HTTP upgrade) is a light-weight option and also available for Delphi clients:
WebSocket is designed to be implemented in web browsers and web
servers, but it can be used by any client or server application. The
WebSocket Protocol is an independent TCP-based protocol.
See WebSocket client implementations for Delphi
RabbitMQ and other solutions are useful for example if the client could be offline while the server wants to send the message. The message broker provides a store where the message will be waiting for the client, even if the server restarts. Also a message broker will reduce load on the HTTP server.
Consider the tic-tac-toe game built with Nginx as a reverse proxy and having multiple Rails backends. Each client sets up a websocket connection with some Rails backends. If two clients playing a game are each connected to a different Rails backend, then a move sent to one backend needs to be routed to the other backend so it can be pushed on the other websocket as shown in the picture below.
In Rails what is the idiomatic way to communicate between two Rails backends?
In this situation you should setup separate WebSocket server and connect both users and Rails servers to it. This way you will be able to handle all users from one server without worrying about sharding.
In case of high traffic you could also setup several WebSocket servers and implement some kind of queue or message bus between them that will propagate new messages - for example master server that will only handle propagating messages and slave servers that will be connected to it and sent all messages received from users to it. Please note that in such configuration master server should not handle connection from users and server only for propagation of messages between slaves.
Finaly, answering your last question directly, there is usually no need to contact between Rails servers directly - as opposite to WebSocket servers they serve on request-response basis so exchanging informations via database is enough in most cases. If you really need immediate change then solutions like AMQP should help.