Custom Event Juggler Conditions Using Lua Scripts: VPN Status to Digital Output
The information on this page is updated in accordance with the 00.07.23.7 firmware version .
Introduction
This guide explains how to use Event Juggler together with Lua scripts to create custom, script-based conditions on a Teltonika Networks device. Instead of relying only on the built-in condition types, a Lua script can be used to check virtually any status on the router and return a true or false result, which Event Juggler then uses to trigger an action. As an example, this guide demonstrates how to periodically check whether a VPN tunnel (in this case, OpenVPN) is up or down, and automatically set a digital output pin to High or Low accordingly. This same approach - using a Lua script as an Event Juggler condition - can be adapted to monitor other statuses (e.g. mobile connection, Wi-Fi clients, or other services) and trigger different types of actions beyond digital outputs.
Configuration overview and prerequisites
Before we begin, let's take a look at the configuration that we are attempting to achieve and the prerequisites that make it possible.
Prerequisites:
- A Teltonika Networks device with a digital output;
- A configured and working VPN connection;
Step 1: Connect the device to VPN
In this example, we are going to use OpenVPN. Below you can see the device successfully connected to the OpenVPN network:

Step 2: Creating Event Juggler events
In this example, two events are created: one for setting the output state to Low, and another for setting it to High, according to the VPN status.
Event 1 – Set output Low when VPN is down
The first event will check the VPN state every minute, and if the VPN status is down, the output (PIN 4) state will be set to Low.
Event data configuration:
![]() |
|
|---|---|
|
Action data configuration:
![]() |
|
|---|---|
|
Condition data configuration:
![]() |
|
|---|---|
|
As a condition, we are going to use a Lua script which checks whether the OpenVPN interface exists and is up. If the interface does not exist, or is down, the script returns true, which makes Event Juggler execute the action (set digital output PIN 4 state to Low).
The code in vpnDOWN.lua is:
local VPN_IFACE = "tun_c_1"
function handle_condition_request(env)
local h = io.popen("ifconfig " .. VPN_IFACE .. " 2>/dev/null")
if not h then return true end
local s = h:read("*a")
h:close()
return not (s and s:find("UP") and s:find("RUNNING"))
end
Note: Change the local VPN_IFACE variable according to your setup. To find your VPN interface name, use the command ifconfig.
Event 2 – Set output High when VPN is up
The second event will check the VPN state every minute, and if the VPN status is up, the output (PIN 4) state will be set to High.
Event data configuration:
![]() |
|
|---|---|
|
Action data configuration:
![]() |
|
|---|---|
|
Condition data configuration:
![]() |
|
|---|---|
|
As a condition, we are going to use a Lua script which checks whether the OpenVPN interface exists and is up. If the interface exists and is up, the script returns true, which makes Event Juggler execute the action (set digital output PIN 4 state to High).
The code in vpnUP.lua is:
local VPN_IFACE = "tun_c_1"
function handle_condition_request(env)
local h = io.popen("ifconfig " .. VPN_IFACE .. " 2>/dev/null")
if not h then return false end
local s = h:read("*a")
h:close()
return s and s:find("UP") ~= nil
end
Note: Change the local VPN_IFACE variable according to your setup. To find your VPN interface name, use the command ifconfig.
Step 3: Testing
We will test both events to verify that the digital output sets to Low when the VPN connection is down, and to High when the VPN connection is up.
After disabling the OpenVPN connection and waiting for Event Juggler to run, the digital output becomes Low. This can be seen in Services → Input/Output → Status, as shown below:

After connecting to OpenVPN and waiting for Event Juggler to run, the digital output state becomes High. This can be seen in Services → Input/Output → Status, as shown below:

Router logs also confirm that one of the events was triggered while the other was not - meaning the event checking if VPN is up was triggered, while the event checking if VPN is down was not triggered:

See also
Relay to Open Collector Output





