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.
Related
I want to create an application in which my web app will work as remote , a node based web socket server will work as CMS(central management system) and an electric vehicle charger which will be my device. I want help in how to send instruction to my device according to the commands i receive from it.
You can use socket.io on your server, it is easy to use and has a socket client implementation in almost languages that exist.
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 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.
I recently set up a Twilio account and got a registered Twilio phone number. Is there a way that I can get those messages on my raspberry pi? My intent is to display those messages on a LED screen.
You'd have to either expose the RasPi to the public internet (so Twilio's SMS callback could reach it), or use some proxy service in between.
The proxy would capture the inbound callback, then the RasPi could either poll, or use some better method, to check for new messages (meaning, the RasPi does not have to be on the public internet).
Temboo also has a set of tools that make it easier to build IoT applications that interact with APIs. I believe they can act like the proxy I describe.
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.