We have recently been working on Obsis, a visualisation platform for raw data gathered in real-time by physical sensors. Initially, the main users of this platform will be from industry, measuring important metrics like machine throughput, operating temperatures and soforth, but we anticipate all sorts of potential uses in the future: everything from monitoring light levels in hotel rooms to electricity consumption in offices to humidity in commercial greenhouses. And with the continuing rise of the Internet of Things, it could be used to keep track of almost anything.
Obsis aggregates data sent as MQTT messages from the sensor devices. MQTT is a very simple brokered message protocol that has become something of a lingua franca in this area. We run the open source MQTT broker Mosquitto to read the messages from the hardware and publish them on to listener servers that normalise the message data and store it in a database. These database tables are then read and summarised by Java programs on behalf of the main charting system.
We have developed this system using SmartClient, which has a comprehensive set of databound charts and visual widgets which are extremely flexible and programmable - essential when you have to integrate these components into a general visualisation platform. As mentioned above, there is a lot of logic at the back-end to convert raw MQTT messages from the sensor devices into usable data, but once we've done that, the involved chart rendering is all handled by SmartClient; as always with SmartClient, if you take care with the DataSources, the client-side components just work. We also make use of SmartClient's PortalLayout component, which gives the system a dashboard interface that users can rework to their liking using intuitive drag and drop and drag-resize interactions.
We also use SmartClient for the entire UI needed for managing tenants, users and other domain elements. This screenshot shows a different skin - the skins we are using in this project were developed in-house.
I'm pleased with what we've achieved so far, though of course we have many improvements in the pipeline. For example, the current version polls for updates, because this makes it much easier to sample the dataset (sampling frequency can be configured per-chart, as can the sampling method - each point in the charted dataset can be the earliest, latest, mean, median, mode, greatest or smallest value from the set of candidates in the larger underlying raw dataset). The upcoming version can optionally use a more sophisticated approach, so that individual updates to the raw data can be pushed to the client, where they are incorporated into the sampled data on the fly.
Pushing data to the client also allows us to offer another advanced feature: rule-based notifications. With push messaging enabled, you can configure "records" to be derived from various server-side sources, and each client will always have an up-to-date copy of every values in these "records". This information can now be used with SmartClient's Advanced Filter engine to create sophisticated rule-based notifications. For example, the system can be configured to send a notification when the throughput on machine A has been below 250 units per minute for more than 10 minutes, while the throughput on machine B has remained above 250 units per minute. And that is just a simple example - rules of arbitrary complexity are supported, with multiply-nested subclauses. And notifications can be sent in email, SMS text messages, or as in-app notifications, with Slack and WhatsApp integration already in development.
I will post periodic updates on how the Obsis platform is progressing, particularly when we implement some new bit of technology that we're particularly proud of...
Obsis aggregates data sent as MQTT messages from the sensor devices. MQTT is a very simple brokered message protocol that has become something of a lingua franca in this area. We run the open source MQTT broker Mosquitto to read the messages from the hardware and publish them on to listener servers that normalise the message data and store it in a database. These database tables are then read and summarised by Java programs on behalf of the main charting system.
We have developed this system using SmartClient, which has a comprehensive set of databound charts and visual widgets which are extremely flexible and programmable - essential when you have to integrate these components into a general visualisation platform. As mentioned above, there is a lot of logic at the back-end to convert raw MQTT messages from the sensor devices into usable data, but once we've done that, the involved chart rendering is all handled by SmartClient; as always with SmartClient, if you take care with the DataSources, the client-side components just work. We also make use of SmartClient's PortalLayout component, which gives the system a dashboard interface that users can rework to their liking using intuitive drag and drop and drag-resize interactions.
We also use SmartClient for the entire UI needed for managing tenants, users and other domain elements. This screenshot shows a different skin - the skins we are using in this project were developed in-house.
I'm pleased with what we've achieved so far, though of course we have many improvements in the pipeline. For example, the current version polls for updates, because this makes it much easier to sample the dataset (sampling frequency can be configured per-chart, as can the sampling method - each point in the charted dataset can be the earliest, latest, mean, median, mode, greatest or smallest value from the set of candidates in the larger underlying raw dataset). The upcoming version can optionally use a more sophisticated approach, so that individual updates to the raw data can be pushed to the client, where they are incorporated into the sampled data on the fly.
Pushing data to the client also allows us to offer another advanced feature: rule-based notifications. With push messaging enabled, you can configure "records" to be derived from various server-side sources, and each client will always have an up-to-date copy of every values in these "records". This information can now be used with SmartClient's Advanced Filter engine to create sophisticated rule-based notifications. For example, the system can be configured to send a notification when the throughput on machine A has been below 250 units per minute for more than 10 minutes, while the throughput on machine B has remained above 250 units per minute. And that is just a simple example - rules of arbitrary complexity are supported, with multiply-nested subclauses. And notifications can be sent in email, SMS text messages, or as in-app notifications, with Slack and WhatsApp integration already in development.
I will post periodic updates on how the Obsis platform is progressing, particularly when we implement some new bit of technology that we're particularly proud of...
Comments