RUT 955 - digital relay changes from default status after 5 mins


I am having an issue with the Relay Output functionality on a Teltonika RUT 955.

The RUT 955 is running firmware version 06.09.5.

I am powering a device from pins 5 and 10 and would like to use the relay functionality to power off the device remotely (via the web interface Services>I/O>Output>ON/OFF) when necessary.

I have set the default output state configuration for the relay output to “Contacts closed”, which, if I understood this correctly, it does set the default for the “off” position of the relay.

So I was expecting that, when the RUT 955 starts up, the contacts on pins 5 and 10 to be closed and the relay would show in the “Output > ON/OFF” tab as “off” and the device powered by the relay on pins 5 and 10 to be on.

This is the case when the router is started up but after approximately 5 minutes, the router changes the relay position to “on” and the device connected to pins 5 and 10 is obviously powered off.

This happens without any inputs or any other changes, but it looks like the RUT 955 makes this change just by itself (it shows this same behaviour without anything connected to relay as well).

The events logs show the following entries:

In the same second I can see two entries:

“Digital OC output off”


“Digital relay output on”

There are no entries in the logs before or after the two above.

Of course, this is a problem as the system I am trying to set up will not be in the expected status and the device attached gets powered off.

Is this some sort of bug in the RUT 955 or have I missed something obvious in the setup?

Any help or suggestions really appreciated.

Thanks a lot



Perhaps you have a different rule conflicting with your current I/O Juggler configuration? Could you try updating to the latest firmware without the option to Keep Settings enabled, only configure the relay, and check if the issue is still present?
I doubt that this is an issue with the firmware, as we’ve not seen this complaint before. However, if it even was a bug, legacy RutOS firmware is no longer being developed, thus I’d recommend using the latest firmware.

Best regards,

Many thanks for the quick reply @Daumantas.

I have updated the device to the latest FW (07.04.5).

I cannot see a way to set the default status for the relay output - I’m I right to believe that in this FW version the relay will always stay in whatever was the last status before the device was powered off?

I’ll test a bit more shortly and report back.

Many thanks



If it was set manually in the I/O Status page, then yes.

Let me know how the testing goes!

Best regards,

Hi @Daumantas,

I spent a bit of time testing and it looks like the following happens:

  • There is no “default” setting for the relay in the new FW
  • The “Open” setting gets the device connected to pins 5 and 10 powered up
  • The “Closed” setting removes power from the device connected to pins 5 and 10
  • If the RUT-955 loses power with the relay in “open” status, the device connected to pins 5 and 10 continues to be powered. When the RUT-955 restarts, there is no change to the status and the device remains powered.
  • If the RUT-955 loses power with the relay in “closed” status, the relay immediately changes status to “open” and the device connected to pins 5 and 10 is powered up.
  • When the RUT-955 is restarted after the scenario in the point above (last status before power off was “closed”), the relay stays in “open” status for about 5-6 minutes and then changes by itself to the “closed” position. There are no entries in the logs that indicate this change but it can be seen on the Input/Output status page.

I guess that the question now is: is the process described above the intended behaviour of the digital relay? Especially the delay after restart to change to the latest status and the immediate change to “open” from “closed” in case of no power to the RUT-955?

Many thanks



This is the intended behavior, as the relay is of NO - normally open type.

The relay state is most likely saved in the configuration of the device, that is why it returns to the previously known state. However, 5-6 minutes seems quite long. I’ve tested it on my setup, and from the time relay opens during reboot, it closes again right after the WebUI becomes reachable, which took around 1 minute 15 seconds. I’d suggest resetting the device to factory defaults and checking if the time to close the relay stays the same.

Best regards,

Thanks for clarifying the intended behaviour of the relay.

Regarding the time it takes to get back to the previously known state, you mention that the relay closes again when the WebUI becomes reachable.
I wonder if the 5-6 minutes it takes on my setup is because that it’s the time for the SIM card to connect to the network (it’s a multinetwork SIM so it takes some time to scan through the available providers) which will mean it takes that time for the WebUI to become reachable?



Indeed, that could be the case, as the order of process startup is:

  • Core system components;

  • Mobile connection;

  • Other services (VPN, I/O Juggler, etc.);

So this is most likely what’s causing the issue. I’d advise against altering of this order, as it will most likely break the startup process.

Best regards,

That makes sense, thanks. As a final question can I ask what happens is the Mobile connection is not started up (e.g. no network connection)? Will the other services (in this case the I/O ones) start eventually even if there is no mobile connection?

Many thanks



I’d have to take a look at your logs to understand which part of network registration is taking so long, but if:

  • No SIM card is inserted;

  • Modem cannot connect to operators;

  • Modem connects to the mobile operator, but is unable to establish data connection;

It will simply start the other services. If this delay causes issues in your setup, please reboot the device, wait for the connection to establish, then navigate to System → Administration → Troubleshoot, open the system logs window, and copy all available logs. Paste them into a third-party file sharing service and link it here if the forum does not allow to paste them into the comment window. Make sure to remove any sensitive information like IP addresses.

Best regards,


Many thanks.

The delay might not be a big issue in the setup, we’ll have to test it in the field and see if it causes any problems.

Looking at all the logs I cannot find any reference to the relay gong back to the previous state, Is this expected?

I can see all the services staring etc. but no reference to a change in status of the relay. But perhaps that is not meant to be logged.

Thanks again for all your support



Yes, this is intended, changed relay state should not leave any log entries.

Best regards,

This topic was automatically closed after 15 days. New replies are no longer allowed.