Module and Tile separation is one of the major concepts of the Moduware platform, while it is designed to be naturally understood by a user we’re going to take an in-depth look at this in this article. Why did we separate modules and their interfaces? What is happening under the hood? How can I drive a module and what does that mean? These are some of the questions I’m going to answer.

As Moduware is a platform, there can be thousands of supported modules from thousands of developers. It is impossible for our application to include a module interface for each possible module type. This would inflate application size and make maintenance a nightmare. From our experience, the module creator isn’t always capable of creating a good module interface, due to a lack of resources or experience.

To address these problems we separated modules and module interfaces. We call these interfaces Tiles because they are displayed as rectangular tiles on the Moduware dashboard. The application still comes with tiles for modules of Starter Kit pre-installed, but for any other module, a default tile is downloaded automatically on the modules first plug-in. In addition to default tiles, a user can install alternative tiles for the module by other developers.

Custom module interfaces

You probably noticed that I said “default tile”. This is where the real versatility of our platform is hidden. You as an owner of a gateway and modules aren’t limited only to default module interfaces. A long press on the module slot on the dashboard or pencil tool at the top right corner opens a list of tiles that can work with that specific module.

So to summarise – we have modules that are simple hardware pieces with relatively simple firmware and various tiles that handle most of the complexity and allows you to work with modules in various ways that weren’t anticipated by the original module creator.

This approach allows us to have a market that is split and united at the same time. Hardware specialists can focus on a module and provide a basic interface, while software specialists can focus on UI, UX and features to make the most out of the module.

Driving a module

If you are a software person, you might be thinking “How can I communicate with a module?”. Many would expect that you need to have access to the module firmware, and know how it works in each aspect. As we in Moduware developed about a dozen modules, we found out that this approach makes development more complicated. Not only do languages and mindsets for both parts differ, but also this locks down the module developer into particular firmware architecture after the module is released.

The solution we came up with is called a “Module Driver”. Instead of the tile developer learning how module firmware works, now the module developer declares a public API for his or her module. The driver API defines what commands the module supports and defines the arguments for those commands. The driver also defines what data the module can send, and how to translate the data from transferred byte values into an actual module reading, like temperature or distance.

Module Driver

Conclusion

We at Moduware are working hard to make our platform strong and mature,  with the goal of making developers lives as comfortable as possible. The last but not the least, an important factor for us is to make the platform fun to use. If you are interested in developing on the Moduware platform check out our documentation. You can also take a look at module drives for Starter Kit modules.

If you are somewhere near Melbourne, Australia, join us for our series of workshops that will introduce you to tile development and how you can build upon our platform.

Psst, did you know that you can control more than one module with a tile? We can talk about it another time =)

By Alex Chernov