I have a Raspberry Pi running Windows IOT Core and it is running my home automation application. Now I need to set up communication between the RB pie and ESP8266.
I've been considering the MQTT protocol but I don't want to have an external server running the MQTT broker and I can't find a broker for the Win IOT. Does a MQTT broker exist for Windows IOT Core? If not, what communication protocol would you recommend for this purpose?
Antonio there are a few options available for you on Windows IoT Core
If you're building an application using Node.js there's Mosca (http://www.mosca.io)
If you're building an application using Python, you can check out hbmqtt (https://github.com/beerfactory/hbmqtt)
Of course for .NET applications you can search Nuget. GnattMQ (www.nuget.org/packages/GnatMQ) seems to be pretty popular .NET library
The is the GnatMQTT which is written in C# so I guess should build on Window IoT
Possibly there exist some MQTT lib or another protocol. But I assume the following situation and going to suggest a solution:
Assumptions:
Rpi is at the core of the system.
ESP is working like satellite, sensor etc.
So ESP is reporting data to the Rpi
They (Rpi and ESPs) all are in the same subnet.
Solution:
On the Rpi side implement a simple UDP bcast listener and listen to some specific port on BROADCAST ip. (ex: 8889)
On the ESP side implement a UDP Client to send data to BROADCAST ip and to specific port. (ex: 8889)
Implement a message format and make ESP to send it and Rpi to parse it.
Example Message Format:
The message can be a string (ASCII encoded).
ABBBEEECCCDDDD.....DDD
A: Start Header
BBB: Sender ID
EEE: Receiver ID
CCC: Payload Byte Count
D..: Payload
OR
A|BBB|EEE|DDDDD..DDDDDD|F
A: Start Header
|: Seperator
BBB: Sender ID
EEE: Receiver ID
D..: DATA payload
F: End Header.
This config will allow you to use DHCP, not to record any IP address of the clients and it is cheap to implement (according to resources ram,cpu etc).
Note: I don't know how MQTT uses resources.
There are a ton of MQTT brokers available. ActiveMQ is built with Java and can be installed on any platform that supports Java. Mosquitto and RabbitMQ have installers for Windows.
However, if you want something even more lightweight than MQTT you might also want to look into CoAP.
Related
I am new beginner and try to create IoT network.
As I search on the Internet and see some information,
there is a device (MQTT client), and broker (MQTT server).
I have use node.js (masca) to setup a web server with static IP as "broker".
I have a TinkerBoard as "device", and it run bash command as publisher.
But I meet a problem and very confuse about the architecture... all the sample code I found are one-way communication.
The broker does not send anything back to device.
Is that necessary I have to create both publisher and subscriber program in the device to allow user send command through the broker to control the device?
Yes if you want to receive messages on your device as well as publish them then it will have be both a subscriber and publisher.
It is perfectly normal for a single client to do both.
I want to develop a publisher -> subscriber model with 1 publisher and many subscriber in nodejs.
Currently my idea was to use a normal websocket. The problem with this is that every subscriber needs a static ip and port forwarding if it runs over the internet. This doesnt suit the requirements.
A solution to this seems to be MQTT as it should be suited for that use case, but i saw that it also runs over websockets which should lead to the same problem or does MQTT handle it differently?
Essentially i need a solution where the publisher has a static ip and the subscriber can be anywhere on the world. Is this possible with MQTT or do i need another solution?
No, only the MQTT broker needs a fixed IP address (and preferably a DNS entry) so the clients know where to find it.
All the MQTT clients (both subscribers and publishers), be they native MQTT or MQTT over websockets connect out to the broker. This means they will work even behind a NAT router running with a dynamic IP address (they would all get disconnected when ever the IP address changed, but nearly all MQTT clients automatically reconnect).
These features make MQTT a good choice for consumer IoT devices as the situation described above is pretty much every home broadband setup.
It sounds like your subscribing devices are on local networks, and yes, you would need a static IP for the network and forwarding inside it (not to mention a firewall exception in many systems) for a local device to serve incoming requests. Regardless of protocol, your subscribers do not need to be servers. It is far safer, and ultimately easier, to have them query a central server/system. Only that system needs an IP.
WebSockets do not require port forwarding - they are often used to avoid it. The client opens a connection to a server, then keeps using it to send and receive. It no more requires port forwarding than your computer does when receiving a page from a website. If your publisher is a server or other web-exposed system, you may get the job done by configuring your subscribers to open websockets to it.
However, you may still want MQTT:
It sounds like your publisher might be something other than a webserver, and might be less suited to serving than your clients, since you asked this question. With an MQTT client, it could publish to an MQTT broker on a server, which will then pass the messages to the subscribers' clients.
Developing robust publish-subscribe functionality is extra work, and existing MQTT software will often serve better than new development.
With some extra configuration, it is even possible to make MQTT subscriptions over WebSockets, but even a regular subscription works fine for avoiding static IP, portforwarding, and inbound firewall rules.
Explore one way RPC approach. It will not need a public IP address or port forwarding.
I have a REST server to handle communication between my database server and Android/iOS devices, the REST server is also able to send push messages via Firebase. My second server is a UDP server, that receive and send messages to a IOT device, both server are written in Node.js and running on different EC2 instances.
Then my UDP server receive a message from the IOT device, lets say some GPS data. Is there a good way to call some methods from my REST server via the UDP server? Or send the data to it ? Are there any ways that the two server can communicate with each other ?
You could implement a separate API on your REST server that would be called from your UDP server.
Interprocess communication is a wide topic, there are plenty of ways to do it, it all depends on your needs.
via http
via tcp/ip or udp
via a database (or even a file)
using named sockets (on unix/linux)
using a pub-sub library
using a message queue library
by piping standard input/output
I am trying to build a LoRaWAN-based sensor network. These sensors communicate their data through the LoRaWAN protocol to the gateway which forwards these data to an application server through the MQTT protocol and in the other way around.
The communication has to be done from the sensors to the server and from the server to the sensors. However, things get tough at the gateway level since the message from the sensors to the server and the message from the server to the sensors can arrive at any time and my LoRaWAN module (the RN2483 from Microchip) cannot be on listening and sending mode at the same time. Hence, if I try to forward the message from the server to the sensors, the LoRaWAN packet sent by the sensors will be lost.
Do you have protocol ideas or literature suggestion for efficiently sharing the LoRaWAN module between listening and sending mode?
Thank you all and have a nice day.
I strongly recommend you to read LoRaWAN specification carefully. The LoRaWAN (not LoRa P2P model) has 3 types device, class A, B and C. RN2483 is one of class A devices, it will always have 2 receive windows (RX1, RX2) which last for 1 second long each after sending the message to gateway (uplink). You may use this feature to schedule your downlink messages. And the LoRaWAN server and LoRaWAN app server will handle the downlink issue (e.g., when to send downlink, immediately or one by one).
Is it possible to have a j2me app on a mobile to act as a "SMS gateway" that will handle incommming messages, do a query on a database via GPRS and reply the user back?
This is entirely possible on any J2ME handset that supports JSR 120 (i.e.: most of them). However as Wonil said, you can't just process ANY incoming SMS message. It has to be an SMS sent to a port number on which your app is listening (using a server connection as Wonil explained).
It wouldn't be automatic unless the app was signed (as confirmation is generally required for sending SMS and network access).
Another approach is to tether your phone to a PC using a USB cable/bluetooth/IR, open a serial connection using the phone as a modem, and write a program to listen for new SMSs using AT+CGML as described here. This would allow ANY incoming SMS to be processed (no port number required), and without any annoying confirmation prompts.
HTH
I think you should check about JSR-120 documentation to confirm.
But, in my thought it might be impossible. If you want to receive message by using JSR-120, you should assign specific end point(port number) to listen as like below:
serverConn = (MessageConnection)Connector.open("sms://:5000");
So, you can't catch all SMS messages. It can't be a gateway then.
It probably depends if your phone supports it. Have a look at the J2ME Wireless Messaging API:
The Wireless Messaging API (WMA) is an optional package for the Java 2
Platform, Mobile Edition (J2ME) that
provides platform-independent access
to wireless communication resources
like Short Message Service (SMS).
http://java.sun.com/products/wma/overview.html
This article has some examples which can probably serve as a starting point for what you want to achieve: http://www.ibm.com/developerworks/wireless/library/wi-extendj2me/
Edit: as others have pointed out, you might not be able to receive all messages.