Simon Black is a Technical Evangelist for the Marketing team at Mendix. He works to help build a critical mass of support for Mendix by providing technical talks, blogs, user demonstrations and the creation of sample projects.
Jan is Product Documentation Manager in the Mendix Community team. He is responsible for increasing the expertise level of community members through documentation, training, and other forms of knowledge transfer. At any given moment he works on multiple projects to enable the community and achieve these goals.
ABOUT THE WEBINAR
Still confused about IoT and how to use it? In this webinar, Simon Black will help demystify IoT and give you the tools needed to build Mendix apps on top of connected devices. He will explain the IoT landscape, how Smart Apps can help your business, and demonstrate simple but awesome IoT solutions. And of course, he will teach you how to quickly and easily build applications that utilize connected things!
During this webinar we will cover the following topics:
- The IoT landscape
- How IoT and Mendix can help your business
- Awesome IoT demo
- Creating an IoT app in minutes
- Other cool features
QUESTIONS & ANSWERS
The amount of data is growing if you capture all the IoT data. Will the default Postgres database handle this? Any best practices with big data?
I would suggest that if you are going to store all the IoT data, that you use a scalable database model, something like AWS Redshift, AWS RDS or a Big Data solution. In our Mendix examples we are only storing the last 30 seconds of data, as we are only concerned with immediate data and being able to trigger alerts based on high light levels. We would recommend using Mendix only to store alerts or data for a short period time if you are using a traditional postgres database. For historical data store this data in a big data warehouse.
I understand why we listen to sensors (subscribe to broker), but I don't understand why we need to send data (publish to broker)?
We often we need to send information back to sensors or devices so that it can act based on some logic. For instance, if we look at a home automation example. If our house contains a temperature sensor, this sensor will be publishing data to the broker about the temperature of the house. Then a Mendix application could see the temperature via the MQTT subscribe and decide that the house is too hot. Mendix application can then send a publish MQTT method to the broker to open up the windows. The broker will tell the actuator for the window to open the window.
How do the devices communicate to the broker. certainly from within a container?
In most IoT scenarios a device/sensor won’t communicate directly with the MQTT. Usually the sensors will communicate with a Device Hub/Gateway using a protocol such as Bluetooth, Zigbee, WiFi, Z-Wave as well as many others. These Hubs/Gateways will then communicate with the broker hubs using MQTT or other protocols.
Does the IoT broker charge for the use of the brokerage services?
Yes IoT brokers will charge for usage. You can usually try these brokers out for free before you buy. For instance the AWS IoT free tier gives you 250,000 free messages per month, for 12 months (https://aws.amazon.com/iot-platform/pricing/) and IBM has a lite tier which allows for 500 devices and 200MB of data per month. If you want to set up your own broker up I would recommend using a popular open source broker like Mosquitto (https://mosquitto.org/).
What would be shown if the IoT device went down? Is there specific error handling built in the microflow activities?
If an IoT device sensor fails, there is no impact on the application or broker. The MQTT Broker will just accept any messages that are from a valid device and in a valid format. If however a device sends a malformed payload, like invalid JSON, you could have an error on the subscribing app. That is why it is important to add some error handling on the Mendix side to handle malformed data payloads.
View past Expert Webinars on-demand at developers.mendix.com.