IoT end-node configuration: Single-purpose tool versus the swiss knife approach

My background is in mechanical engineering. I know a thing or two about various types of conveyors, and what are they being used for. I have even designed one or two. That being said, my coding background is almost non-existent and the minute I see a chunk of code is the minute I stop reading further - or at least that was the case before I got my toes tipped into the IoT (internet of things) world.

The internet of things device - in general, and as I can understand it - is any device that has a connection to the internet. Doesn't matter if the device goes directly to the local network or it goes through various radios to eventually end up on the "internet". ACRIOS Systems , among others, is one of the many IoT device developers and manufacturers.

Within this IoT world, there are little to no plug&play solutions and if they are, it is usually from the companies that can supply the whole end-to-end solution. But even then, some configuration of the end device might be and is needed and the question is, how do you want to configure such a device? Who will configure it and what are his or her technical skills?

Configuration approaches and their benefits

I am aware of 2 different approaches:

1. Let the customers specify the use case and the configuration will be hard-wired within the firmware
2. Provide the customer with a nice GUI (Graphical User Interface) in which he or she can configure the variables, such as the reading period and others

Both the approaches have their pros and cons. In the first case, the benefit for the customer or end-user is that they don't have to really deal with configuration and the manufacturer is responsible for anything. While it all works, this is arguably the best approach. The issue comes when it doesn't work - and that's usually the case. For example, you specify that you will be connecting a Kamstrup meter and you want to read out specific registers via Modbus protocol. The device comes to you and it is ready to get connected to Kamstrup. You arrive at the metering station and since Murphy's law works 100% of the time, you find a Diehl meter instead of Kamstrup and your only option is to get back to your office and mail the device to the manufacturer for re-programming and you have to go there the second time. This can really get time & source-consuming as well it is not possible to do the last-minute installation in case you have some of the devices in stock. Also, you have to note which device has which configuration.

In the second case, you have the luxury of an easy configuration - usually over some USB cable but I have seen also the NFC being used - and in case you find a different meter with different registers, it is a matter of changing the registers. Great, you don't have to turn back and mail the device.

But what if...

...but what if there is anything you want to or need to configure but the option is simply not within the GUI? For example some of the cases I have encountered:

• Changing the LoRaWAN registration method from OTAA to ABP or vice-versa.
• Setting the fixed data rate in case you have any troubles with the network and you want to have fixed SF12 (not recommended in public networks).
• Changing the behavior of the device - could be programming the Modbus unit to behave not as a master, but as a slave.
• Connecting the multiple M-bus meters and their addressing. Or you don't know the addresses so you want to send the broadcast query but change the baud rate before each query.
• Edge computing on the device's level - for example, you don't need 5 telegrams x 200 bytes from the electrometer, but you really only need the first 50 bytes. Can you modify it? And if so, can you do it for each connected meter differently?
• You want to add a logic that saves a message in case the network is not available and will send it after the device re-connects.

Of course, all of the use-cases above can be done within a GUI, but it would have to be a very complex GUI and there still will be a chance that the feature you want and need is not there. Above the 2 approaches mentioned above, there is also a 3rd approach being used within some PLCs and such. That is the implementation of the scripting interface which allows you to change anything in case you have to, but you don't need to.

In our case, we do use the LUA scripting interface in our devices

Pros

• Ability to change only the variables you need without needing to have any knowledge about the LUA scripting interface
• Advanced users can create their own unique LUA scripts and really modify the device's logic or create your own logic altogether.
• Having to maintain only one firmware across the products as the logic is within the LUA script. This is a huge benefit for reliable and stable applications as we don't have multiple firmware versions across our customers
• It is possible to implement your own proprietary protocols - mainly within the RS-485 converter - without having to explain the protocol to us
• Possibility to have the edge computing ability - for example with the VIF DIF filtering within the M-bus frame or the ability to modify the payload to the existing payload parser being used by the receiving software application
• Implementing the LUA script which will allow for remote configuration over the network. This is the approach we use within the wireless M-Bus projects which I will share with you soon.

Cons

• The configuration can be a bit confusing for new users as the only thing they see is a code with configuration variables in the header
• With great power comes great responsibility - mainly regarding power efficiency. It is easy to create a non-optimal LUA script that will use more energy than needed.
• For advanced logic it is good to have some knowledge of basic coding - it is still a scripting interface

Luckily, most of the cons can be outweighed by the support we are able to provide you. We do have a full-time colleague whose job description is to help you with the configuration and/or LUA scripts to ensure your project goes as smoothly as possible.

Thank you for your time and for reading all the way to the bottom of this article. If you find it interesting feel free to share it with others. I am interested what is your experience with the IoT device configuration. Have you come across any limitations which are not listed above or have you seen the scripting interface before? Are you aware of other configuration approaches which are not listed here? Let's discuss under the article in the comment section and alternatively let's discuss on the call or by email at smetana(at)acrios.com.

Thank you and I am looking forward to hearing your feedback on this very first article on the topic of IoT and the approach we have!

Lukas Smetana / ACRIOS Systems