Real-time telemetry simulation to Samsung Artik IoT platform

In this video we demonstrate in 1 minute how MIMIC MQTT Simulator
exports real-time telemetry that changes precisely. The chart in the

Samsung Artik dashboard that monitors the temperature value shows
the changes at the instant they happen.

Solarwinds and MIMIC Simulator

If you need to develop and test customizations, or train staff on the
Solarwinds management application, then you can create a facsimile
of your production network in MIMIC Simulator and reproduce interesting
scenarios.

For example, here we show a simulated network being managed by Solarwinds.

Long-term testing with MIMIC Simulator

What do our test systems do over the weekend? They run longer-term tests
that we cannot run overnight.

For example, they run one MIMIC MQTT Simulator test that continuously in
a loop starts 1000 sensors, publishes messages for a while, then stops
them, as might happen in a real-world scenario.

The code is as simple as this:

% while ( 1 )
    ./mimicsh --nogui --script mqtt-start-many.mtcl --args "1 1000 1000"
    sleep 10
    ./mimicsh --nogui --script mqtt-stop-many.mtcl --args "1 1000 1000"
end

With this simple 5-line test we found that a third-party MQTT broker
was failing after a while. Apparently it was not configured to handle the
"TCP SYN flood" that the OS detected.

Chalk it up to another configurable on brokers that we learned the
hard way.

 If your MQTT broker does not have the configurables for SYN flooding
in their documentation, then you will encounter this problem in your
deployment when all those sensor connections start flapping.

This is but one of the many tests that you can perform with MIMIC MQTT
Simulator on your MQTT broker before IoT deployment to avoid costly
problems in the real world.

Online MQTT Lab for your access

We have just released a SaaS lab with hundreds/thousands
of simulated MQTT sensors to prototype/test your IoT solution at

http://mqttlab.iotsim.io

You can test your applications by connecting to the lab at any time.

Check out the 3 minute video at

https://www.youtube.com/watch?v=cttbEh16MOI&hd=1

MIMIC MQTT Simulator integrates with Google IoT Core

While integrating simulated Bosch sensors in MIMIC MQTT Simulator
with Google IoT Core we implemented JSON Web Tokens (JWT) for the
MQTT Password, as standardized in RFC 7519 .

This allows for any number of devices publishing MQTT telemetry
with arbitrary authentication parameters to Google IoT Core or
any other IoT platform that requires JWT.

This is in addition to previous support for OAuth 2.0 .

The screenshot below shows 2 pulled subscriptions with unique
telemetry:

Update 12/01/2019:

We have since improved our demo scenarios as detailed in this post.

LWM2M-MQTT and MIMIC MQTT Simulator

Are you implementing LWM2M-MQTT in your environment?

MIMIC MQTT Simulator supports arbitrary payloads for MQTT messages
for a large number of simulated MQTT-enabled devices.

You can use it to quickly prototype your LWM2M-MQTT implementation.
In particular, you can test scalability of your LWM2M server over the MQTT
transport.

Check this 2-minute video that shows 2 sensors publishing unique telemetry
to Eclipse Leshan. 

How to right-size your IoT platform

You have run extensive tests on your IoT platform candidates, have gotten
QOS / performance guarantees from the vendor, and have selected the most
promising choice.  You may have even put money down.

Now that you are ready to deploy your IoT platform, these are the problems
you will need to solve:

1. initial configuration

   Likely the IoT platform will need to be tuned to your individual
   requirements in the production environment, which is likely much
   different than your test environment. You may have tested in-house,
   and are deploying on the cloud, or vice versa.
   
   Configuration does not only involve the middleware software components,
   but the OS itself, as we had learned in this post.
   
   For example, it took us multiple tries until we could scale ActiveMQ
   to 20,000 simultaneous client connections. Out of the box, on a 8-CPU
   system, we could only scale to about 800 sessions. Then we applied ARP
   cache- and thread-tuning, and got to 7,000 sessions.  Only on the third
   try did we get to 20,000 sesssions.
   
   You will face this with any IoT platform. With MIMIC MQTT Simulator this
   exercise took an hour including research on this unknown software.
   How long will / would it take you?
   



2. end-to-end tuning

   The process above just gets us part-way to the ultimate requirements.
   There are many variables that impact long-term run-time performance
   in your production environment:
   

   a) connect rate:

   at what rate do clients connect to the broker. For example, your devices
   may all simultaneously connect after a brownout, or there may be a
   steady trickle of sensors connecting and disconnecting during the day.
   Every scenario is different.
   

   b) publish rate:

   how often do clients publish telemetry? How large and what size
   distribution do the messages have? What QOS and encryption
   parameters are being used? The scenario of 1 message every minute
   with 100 bytes per sensor is quite different from a camera publishing
   hi-res images at 10 / second.
   

   c) consumption rate:

   how many applications are consuming messages? Since the broker is
   essentially a layer 4 switch, the fanout determines switching
   performance. Wildcard topic subscriptions challenge topic matching
   algorithms. Are your consumers running with enough power to not bog
   the broker down?
   
   MIMIC MQTT Simulator is highly customizable allowing you to vary all
   these variables to run many end-to-end scenarios to ensure adequate performance.
   
   

3. devops

   You have your production system running, but how do you test that it
   scales up and down with varying performance levels? How do you test
   changes to your applications while it is running?
   
   With MIMIC you can run synthetic loads even on your production system
   to verify operational adjustments. Your broker cluster should absorb the
   extra load, and contract when the load is gone. By generating custom
   payloads you can test new features and fixes to your consumer application.