Bevywise Networks | IoT Platform & IoT Solutions - IoT Solutions & Artificial Intelligence to make a better tomorrow.
  • Docker MQTT Broker

Docker MQTT Broker for easy service manageability

By Ranjith Kumar Diraviyam




  • Docker MQTT Broker

Docker MQTT Broker for easy service manageability

By |July 9th, 2018|


Docker is one of the leading container application that is used most widely used in running a well managed deployment environment.  Docker MQTT Broker will help you have more control over your IoT production environment. Most than 60% of the servers is using either Ubuntu / Debian for their hosting.

 You can use the following instructions to run the MQTT Broker on Docker on any of cloud providers like Amazon EC2 or Google Cloud or Microsoft cloud or on premise behind the firewall.

Requirements for Docker MQTT Broker

1) Ubuntu 14.04 

2) Docker 1.6.2

3) Mysql 5.5

Setting up the MySQL

We recommend MySQL to be run on a physical machine than a container for the data persistence purpose. Follow the below instructions to set up the MySQL. You have to install the MySQL Server first.

 $ sudo apt-get update

 $ sudo apt-get install -y mysql-server-5.5

Modify the MySQL configuration. By default the mysql runs at 127.0.0.1 and allows only the local application to connect to it. You have to change it as 0.0.0.0 for application running on containers and other machines to access the MySQL.  

$ gedit /etc/mysql/my.cnf

     bind-address = 127.0.0.1to bind-address = 0.0.0.0

Restart the MySQL for the changes to take effect.

$ sudo service mysql restart

Providing data access. The root user of MySQL has access only form the local machine to read and write data into the databases. We need to allow the root user to access data from the container. Connect to the MySQL console from the localhost and then execute the following queries.

$ mysql -u root -p
Enter password: <provide your password here>

mysql> GRANT ALL PRIVILEGES ON *.* TO ‘root’@’%’ IDENTIFIED BY ‘root’ WITH GRANT OPTION;

mysql> FLUSH PRIVILEGES;

Your MySQL server is all set to connect from any container that runs on your Ubuntu server.

Creating Docker MQTT Broker

Docker needs to be installed in your ubuntu to create the docker image of the MQTT Broker and also run the dockerized MQTT Broker. To install the Docker, run the following command.

 $ apt-get install docker.io

Download the LInux version of the  MQTT Broker and Extract it from your /home/ubuntu folder. If you are extracting the archive from some other folder, make sure you use the right reference folder

 [email protected]<yourmachinename>$ unzip Bevywise_MQTT_Route_Linux.zip 

We will be creating a docker image in the name of mqttroute. Create a directory for creating the docker file.

$ mkdir /home/ubuntu/mqttroute

Copy files of the MQTT Broker to the mqttroute folder.

$ cp -rf /home/ubuntu/Bevywise/MQTTRoute/* /home/ubuntu/mqttroute/

Modify the configuration of the MQTT Broker for MySQL connections 

$ cd /home/ubuntu/mqttroute/

$ gedit conf/data_store.conf

DB_SERVER = MYSQL

DBHOST=<mysql host ip>

MYSQL_USER= <your mysql user>

MYSQL_PASSWORD = <mysql db password>

Create the mount folder where the docker images will be mounted.

$sudo mkdir /bin/mqtt

Create the docker file

$ gedit Dockerfile

FROM ubuntu

COPY . /bin/mqtt

CMD [“sh”, “/bin/mqtt/bin/runbroker.sh”]

 

Build the docker image

 # docker build -t mqttroute .

Verify & Run Docker MQTT Broker

 # docker images

[email protected] # docker images

REPOSITORY     TAG     IMAGE ID     CREATED     VIRTUAL SIZE

mqtt         latest         45f7ee9a1ec7       7 seconds ago      81.15 MB

ubuntu    latest          7feff7652c69       4 weeks ago         81.15 MB

Start using the docker command. The following command will run the MQTT Broker as a daemon process. If you are planning to run MQTT Broker in a secure mode, you can refer to our previous blog on ssl certificate creation and placement of the files inside the MQTT Broker.

$ docker run –restart=always -d -p 8080:8080 -p 1883:1883 -p 10433:10433  mqttroute

Download now to  get started now to set up your own Docker MQTT Broker

Download FREE MQTT Broker

Feel free to contact support for any questions or feedback. 

 

  • MQTT Broker Integration

MQTT Broker integration using REST API

By |June 18th, 2018|


MQTT Broker integration with your application is very crucial for any process / production management application in Industrial and Customer implementation.  MQTT broker was built with options to store data into any back end data storage via the custom data store. By storing data into the storage which is processed by your application, you will be able to visualise it the way you want. You can use the ready to use plugin to store data to Elastic and MongoDB.

We are working hard to make the MQTT Broker work more seamlessly with any of your application. Today we are happy to announce the availability of APIs in our MQTT Broker through which your IoT Application can manage your edge devices via the MQTT Broker.

MQTT Broker integration with REST API:

We can carefully selected the most useful communication that is needed between any application and its broker to provide the first version of the API. Following are the list of interactions available now

  1. Send a message to any specific device.
  2. Send a message to all devices based on a subscription.
  3. Add a MQTT Device Authentication username and password dynamically from your application.
  4. Remove a MQTT Device Authentication String from the MQTT Broker
  5. Get the list of active devices connected right now to the MQTT Broker.

For more details on the API, refer to the  MQTT Broker API page 

Unsolicited Messages:

MQTTRoute now supports sending of Unsolicited messages to the Edge Device. Yes, you read it right. You can now send messages to any specific device for a topic for which the client is not already subscribed to. This is an enhancement to support device development platforms like Telit. This can be achieved by sending the http call to /clientsend with the target device, topic provided by the device for receiving unsolicited messages, message, QoS and Retain as required.

We have also added an advanced custom implementation inside the /lib folder of the product to send the data received into your Python class file to process it in a better way.

Try the fastest MQTT Broker now

Download FREE MQTT Broker

Feel free to contact support for your queries and feedback

  • 5 Powerful Reasons to choose an IoT Platform over MQTT Broker

5 reasons to choose an IoT Platform over MQTT Broker

By |May 31st, 2018|


IoT and Industry 4.0 together pave the way for smart industrial developments and every industry needs a dedicated & personalized IoT/Industry 4.0 implementation. Even within a specific industry in medium and large enterprises, there are cases where the processes may require customization or a custom implementation of the solution. Such requirements result in millions of distinct IoT implementations in the entire world. In order to build cost effective solutions, these million implementations will need a central M2M engine (MQTT Broker) or an IoT Platform.

This blog helps you identify whether you need an IoT Platform or a simple MQTT Broker to get started with the implementation of your solution.

Save Money with IoT Platform:

The IOT Platform provides everything that needs to be a part of the central M2M communication, Data Storage, REST APIs and more, in order to run a complete solution for any IOT automation. Using an IoT Platform as part of your implementation will have more advantages and higher cost savings than using MQTT Broker. This makes your server ready without spending a huge amount of money and time on implementing the same.

Easy scale up:

IoT Platforms are designed and built with scaling up your IOT Solution to handle millions of devices. Most platforms are micro services-based allowing you to deploy only the service that is needed. In the industrial implementation, there are two scenarios.

  1. Less number of devices and more messages per device
  2. Lot of devices and lower frequency of messages per device.

The components of the Platform that enables higher connections and higher message rates can be deployed accordingly as per the situation. This is something not possible with the broker unless you go for some huge customization of the broker.

Multi tenancy:

Bevywise IoT Platform comes with multi tenancy. Most solutions today require more than one customer and you cannot have one instance per customer. Multi tenancy is something that is needed for most industrial scenarios. Platforms implement multi tenancy from devices using different set of authentication keys, data processing & storage, and data analytics based on the organization.

Faster Time to market:

The core of any IoT Implementation is the edge device and the management of the devices using your mobile application. The IoT platforms provide REST based APIs and SDKs for the faster mobile application and other application integration. The platform helps to get you the complete IoT Solution up and running in days.

High Availability of IoT Platform:

IoT Platform comes with an in-built monitoring and self healing tools. The platform monitoring tools help in keeping the Dev-ops team informed of the server health. The self healing tools can be configured in such a way to restart the services based on the CPU and Memory usage, making the service work more reliably.

Try the hosted Bevywise IOT Platform now.

Create Account in Bevywise Device Manavger

For more information on the Platform, download the brochure here.  Contact support for a hosting a white labeled Platform for your IoT Solution.

  • MQTT Simulator enhanced

MQTT Simulator 1.5 – Everything you need to know

By |April 24th, 2018|


We are happy to announce the new updated MQTT Simulator which can help you do simulate a more complex nested MQTT JSON data simulation and much more. Here is the list of additional values the simulator can provide to your test environment.

Complex MQTT Data Simulation

Most devices today send data as nested JSON. As more than one meaningful value is packed into a message, the real world has moved on to the JSON as a default data format on all the IoT Implementations. To enable testing of such environment, we have made the simulator to publish messages that has the same kind of JSON format. You can simulate any level of nested JSON to help you test any manager application.

complex nested mqtt data simulation

Emulate Real world Device Uptime

In the Real world situation, the devices connectivity cannot be uniform due to various reasons like power , network and other device failure related circumstances. In order to replicate the same real time scenarios, we have added the Randomized start / stop of devices based on your configuration. You can specify the lowest possible uptime you would like to simulate in the networks. We will make sure the devices have an uptime that ranges from the specified value up till 100%.

For example, if you specify the minimum uptime as 91% in the MQTT Simulator, then the devices will have a uptime between 91% & 100%. The devices will be automatically stop and restart multiple times to maintain an uptime of the specified range. Different devices will have a different stoppage time based on the random data. We are working on generating a report for the uptime so that it can be compared with your manager applications report. The reports will be available in the next version of the simulator.

Flexible IoT Events

90% of the world is going to be with Sensors which are going to just publish events. These sensors sends events with different variable data and variable times. The simulator can now send events On StartOn Disconnect , For a specified time duration & For the whole day with a specified time interval , at a specified time and by a manual trigger. You can add multiple events for these each criteria and each event can have unique complete JSON with a variable data of System defined variable, RANDOM , RANGE and LINEAR data variance. These features make the simulator event generation more versatile and robust.

Flexible IoT Simulator Events

Refreshing MQTT Simulator UI

The MQTT simulator UI now provides a easy to view events that are published from the device and the commands received from the manager / broker application on the user interface to make the testing much easier. The User interface also has been made more cleaner for easier overall device simulation.

The Settings of the simulator like Broker Address and Port , TLS / SSL enable , Python Interceptor and Uptime simulation has been moved to the User interface for the ease of use.

MQTT Simulator UI

Try the latest version of the Bevywise MQTT Simulator now.

Download IoT Simulator

We are working on integrating the simulation with the other automation tools to provide a complete test automation.

For more reference Please refer our Help document and watch our YouTube videos. 

  • Advantages of MQTT

MQTT vs REST from IoT Implementation perspective

By |April 11th, 2018|


Most of the IoT Implementations today uses REST over HTTP based connectivity from the client to the Server. REST has its own limitation that pops in while your solutions scales up to the larger number of devices and more number of translations per second. MQTT, the light weight protocol designed exclusively for IoT has its advantage over REST in all dimensions. This blog compares MQTT vs REST to help you finalize your communication protocol.

Instant Response – Need of the hour

REST is a one way connection. The connection to the server is intermittent. The client connects to the server when needed to push data from the client and pulls the data down to the client. The server needs to wait for the clients to connect to send the data that is intended for the client. This makes the user intended action to wait for the client connection. Most solution providers allow their edge server or their gateways to connect every 1 minute or higher so that the server is not loaded.

Take an example of a activating a light from a mobile app. The message from the mobile will hit the server instantly. But the message from the server to the client needs to wait for the time client to connect.

MQTT allows the client to be connected always providing a two way communication between the client and the server. This allows server to push the message to the edge device making the device respond to your command instantly as expected by Customers.

Lower Power consumption

When directly compared for the same data transfer using REST and MQTT, MQTT consumes 20% lesser power. In the case of the REST, most energy is lost on the resources used on connecting and disconnection and resource cleanup on both the server and the client. So when you build a battery operated remote device, MQTT helps you with a longer battery life than REST.

Highly Secure IoT Device Deployments

Most of devices today are deployed behind the firewall for the security reasons. One of the limitation of the REST is that the server can no way communicate from the server to the client on demand. Even if we put a REST Server on the client devices and try to make connections form the server, it will fail when devices are installed behind the firewall. MQTT inherently solves this problem of two way communication with the persistent connections.

MQTT vs REST Performance

MQTT is an always connected against the intermittent REST Calls. Due to the permanent connection, the need to connect and disconnect for every data transfer is not required. The keep alive ping has a much lesser overhead compared to the reconnection connection calls the REST makes. As per the analysis and test reports, MQTT data transfer can transfer data at a rate 20 to 25 times faster than REST Calls.

The number of message transaction highly depends on the number of connections the server can accept in the stipulated time. The number of concurrent connections that the fastest available web server today will be in the order of 1000s per second. This restricts the data transfer in sequence. MQTTRoute can process upto 40,000 messages per second on a commodity server. The number of parallel connections the broker can hold can again be tweaked based on the hardware. A simple commodity server can hold upto 50,000 connections in parallel.

In a clear advantage, MQTT wins the MQTT vs REST choice for the IoT Implementation.  Try MQTTRoute the fastest MQTT Broker available today.

Download FREE MQTT Broker

Do write back your queries to Bevywise support.

  • Iot Implementation - Design the data

IoT Implementation Series – Design the Data

By |March 21st, 2018|


As part of the IoT Implementation series, this topic covers the best practices in designing the data communication between the edge device and the Central Platform.

IoT Device to Cloud response

Humans always expects a response for every action. The response can be emotional, physical, visual or in any human understandable form. The same is the norm when we interact our intensions via an ioT device. Developers often miss the point that the edge device too need them for a completion of the response back to the humans. The acknowledgement user need is different from what the protocol provides. The protocol level ack message only confirms the receipt of the data at the edge or the server. But the action happens after the protocol ack is sent back. So you need to make sure you send back a message from the device or the server once the intended action is complete. The response should be a success or a fail message based on the outcome. Check the outcome before the message is triggered.

Design the right message handle

All IoT Protocols have an identifier for the event and command messages between device and manager application. MQTT calls it by the name Topic. It is very important to define good and clear topics for the communication. The topics should be very relevant as it should be understandable by the Humans too. It is advisable to have a mandatory device identifiers on the subscriptions, as we will be able to know where the command is going. For the events, it is the implementors choice to use the topic.

Send relevant Data to MQTT Cloud

An half baked data is equivalent to having no data. So make sure you put all the data available into the cloud from the edge. For example, when we collect a machine status from the edge device, the core information is about the health of the machine like temperature, coolant flow, vibration level. But we often loose sight of the time relevance at the edge. It is better to get the time from the edge device than use the time on the server. Add the device identifier also as part of the data which can help a lot during the data analysis. There will some more core information which may not be of interest today. But it is better to have them for future analysis.

Identify & Group the Devices

Different IoT Cloud application has different kind of device identification process. Most of them get this done when they add the device. But this process increases the human effort to add these devices. Bevywise Iot Platform allows any device to connect if they have the right auth keys. The device can send additional data later. Most of the IoT Protocols today does not allow you to send more information while connecting to the server. So identify the register command and the list of data requested by the IoT Platform and send it as a separate message based on the protocol. On the platform side, you will be able to create device specific user interface for your operators based on their roles. The IoT Platform mostly need to know the type of the device, manufacturer, location, etc. But you can always customise it to have more information as needed for your IoT Device management and inventory.

Mobile integration

One of biggest deceiving point in the IoT Implementation is that the developers tend to use the same protocol to connect your mobile applications. But that is not the right IoT implementation of the mobile application. The mobile application should be built over the REST API of the IoT Platform and should be integrated with messaging system like Firebase Cloud messaging for the notification. As an option, developers can use the protocol based communication when the app is open for instant messages to the server, but should not depend on it end to end.

Bevywise Networks is an end to end solution provider for IoT Implementation for any vertical from Edge devices to IoT Cloud Platform. We would be happy to help you get your solution tailored by us.

Free IoT Consulting

 

Related Post:

Designing the Edge