This application note aims to introduce you to a LUA scripting interface in terms of flexibility and what is possible. Specific application notes with the possible functions can be found in the application note section or in the LUA API section.
LUA is a simple scripting language we use to modify the logic of our devices. It allows us to maintain one master code base which is being split during the manufacturing process into the specific versions of the device - be it M-bus, RS-485, WM-Bus, or pulse input converter. With this approach, we can make sure that in case we find and resolve specific corner-case, this change is being implemented within all products. The specific logic of the device is then being altered by a specific LUA script. This allows us and you to easily integrate our device into specific applications.
The first impression can be a bit overwhelming, especially when you expect an easy-to-use GUI with a parametrization through a table layout. With our devices, the first thing you get to see is a "code". The LUA script to be specific. Generally our LUA scripts - or at least our default ones - are easy to read even when you have no coding background and they are split into the 3 main sections:
The configuration allows you to set the parameters of the network and also the parameters of the interface - be it M-Bus, RS-485, or WM-bus. The configuration is different based on the specific version of the device. Below is a configuration section for a basic M-bus to LoRaWAN converter:
----- LoRaWAN ---------- ack = 0 -- 1 for acknowledged, 0 for non-acknowledged port = 100 -- transmit port receiveTimeout = 10000 -- the maximum execution time in milliseconds
As you can see it allows you to set up specific LoRaWAN parameters, such as acknowledged messages, the port on which you wish to communicate, and RX timeout.
Then there is a M-Bus configuration:
----- M-BUS ----------- baudrate = 2400 -- baudrate: up to 921600 baud parity = 2 -- communication parity: 0 for none, 1 for odd and 2 for even parity stopBits = 1 -- number of stop bits: 1 or 2 dataBits = 8 -- number of data bits: 7 or 8
Regarding the M-Bus LUA script, there is also an M-Bus query to be made which sends a request to the connected meter. This query can be altered or modified in any way possible. You can add a delay after the query is made which can be used for example when using the ABB B23 electrometer which sends up to 7 telegrams and you want to send them all.
How the M-Bus converter works, in general, is that it send you the answer from the meter 1:1. Of course, this can be changed so you can for example split the message based on the VIFs and DIFs and only sends the data you need, or you can add a mechanism for message splitting which allows you to get the whole answer of the meter in case it is longer than X. The X is defined by the actual data rate and the LoRaWAN limitations.
After the M-Bus configuration, we can modify the timing. By timing, we mean a wake-up interval in which the device will wake up and send a message.
------ Timing --------- -- device wakeup interval periodHours = 2 periodMinutes = 30 -----------------------
The OnWake functions specify everything that is being done every single time the converter wakes up accordingly to the "Timing" configuration section. Most of the LUA script modifications are being done in this section. With the M-Bus default script, the functions are following:
-- set link parameters - 2400 baud, 8E1 api.mbusSetup(baudrate,parity,stopBits,dataBits) api.mbusState(1) api.delayms(2000)
-- CREATE MBUS QUERY -- -- UD2 --b=pack.pack('<b5', 0x10, 0x5B, 0xFE, 0x59, 0x16) b=pack.pack('<b5', 0x10, 0x7B, 0xFE, (0x7B+0xFE)%256, 0x16) status,c,a,ci,ans = api.mbusTransaction(b,3000,1) api.mbusState(0)
print("From MBus Calorimeter: ") api.dumpArray(ans) if #ans < 1 then buf = "NO DATA RECEIVED" else buf = ans end
print("To LoRaWAN: ") api.dumpArray(buf) print("Sending to LoRaWAN") res, rxport, rcvd = api.loraSend(ack, receiveTimeout, buf, port) print("Done sending") print("Sleep now, wake in " .. tostring(periodHours) .. "hrs:" .. tostring(periodMinutes) .. "mins.....") api.wakeUpIn(0,periodHours,periodMinutes,0)
This section specifies what has to happen every single time the device is powered on. It can be that you want to send a specific message to a specific port or you want to change LoRaWAN keys, for example. All of it can be done here and the changes will apply after every power-on cycle.
In the specific M-Bus case we only have a print:
print("Starting up LoRaWAN MBUS default script") end
You can set the keys which allow you to duplicate HW in terms of the network server. Suitable for when you want to change an HW but don't want to re-register the device. Also, you can fix the payload size, turn on or off the ADR (not recommended in general applications), select how to join (ABP or OTAA), and others.
You can do the payload operations within the converter, such as splitting the messages, parsing them, sending only specific parts of the payload, or converting different data types (integer to float, etc.). This allows you to modify a payload to fit your existing parser so you don't have to create another parser and you can approach the project with our device as an identical replacement to the existing solution.
Thanks to the versatility of the LUA scripting interface you can implement your protocols. For example, you can have an LUA script over the RS-485 converter which will work with the DLMS protocol or you can use the RS-485 converter as a transparent wireless bridge.
In case you need to save any data, we can offer you a 20kB of space which should be enough for most of the applications. The memory is usually used within an S0 counter application.
By following the application note you can split the messages in any form or shape you like. You can also add a different mechanism to make sure that you get all of the messages you should get.
We can help you to create a device that is not available on the market - for example, the IoT pulse pattern recognition tool working over the LoRaWAN network as described here.
You are not limited by us which parameter you can or can not change over the LoRaWAN or NB-IoT network. You can decide which parameter is worth changing over the air and with a backend tool create a complex solution able to get deployed in hundreds of pieces without having to worry about the configuration of each unit - just send the configuration over the air. We have cover this here. We also use this approach with the Wireless M-bus backend solution here.
By using the function WakeUpIn you specify in what time-frame the device should wake up relative to its power-on cycle. By using the WakeUpAt function you can set in what time the device should wake up. Given it has a time either from the network or from a connected meter. By this approach, you can get the 15 min max exactly on the 15 min time mark (1:15, 1:30, 1:45, etc...).
Our devices can be deployed as a slaves instead of the masters. You can see it in a application note.
The LUA scripting interface is a powerful tool that allows you to create an application other devices just can not fit. BUT it comes with a price of not having a simple GUI where you just choose the Modbus registers (although we have prepared a simple Modbus LUA script as well) in a table. If you need any help with creating your application or want to discuss a possible solution, let us please know at firstname.lastname@example.org. We will be looking forward to hearing from you soon.