Question

I configure some actions/conditions which works as expected.

But how to trigger the input after reboot "trigger rising" if its already high during reboot?
At the moment I must change the input to low and back again to high after reboot.

Is there a solution?

Answer 1

Ok, this challenge is harder than I thought!

I try the following script in /etc/rc.local

if /bin/ubus call ioman.gpio.din1 status | grep -q "High" ; then
        uci set openvpn.myVPN.enable='1'
        /etc/init.d/openvpn restart
fi
echo "DONE" > /tmp/script_runs

exit 0

After reboot the input is high, test file "script_runs" is in /tmp, but my vpn do not connect.

So I create a script in /etc/config/autoconnect.sh with this commands, execute it ./etc/config/autoconnect.sh and my vpn connect as expected.

Any ideas?

Comments

Hello,

  

Sorry, since you replied to your post it was marked as answered and we missed it.

The issue here seems to be the lack of uci commit openvpn after changing the value and before restarting OpenVPN.

Let me know how it goes.

  

Best regards,
DaumantasG

---

Thanks for reply!

uci commit openvpn means the setting is saved (?), but the default must be VPN disabled (only enabled if Input (PIN 3) is high.

And why my script works after reboot and execute it via SSH without the UCI commit openvpn?

---

Not sure why it would work without running via SSH without the uci commit, it may be that the uci commit performs a similar action as restarting the service.

The UCI command only runs if the condition is specified, so it should only enable OpenVPN if the pin is high. So I'd recommend adding

uci set openvpn.myVPN.enable='0'

uci commit openvpn

/etc/init.d/openvpn restart

before the IF condition. This way the OpenVPN will get disabled either way and if the pin is HIGH, it will re-enable the OpenVPN. However, it should be kept in mind, that this script only runs once, thus adding a crontab to check the state of the input pin and enable the OpenVPN if needed.

  

Best regards,
DaumantasG

---

My I/O trigger works as expected (https://community.teltonika-networks.com/67288/rutx08-use-i-o-for-openvpn-how), but
not if PIN 3 is high during reboot, thats my problem.

This is why I test the PIN and try to enable VPN, without success.

---

Try to debug this problem, my script from /etc/rc.local works, but ubus call do not give any result!

#!/bin/sh
sleep 60
echo "sleep done" > /tmp/script_runs

ubus call ioman.gpio.din1 status >> /tmp/script_runs

if ubus call ioman.gpio.din1 status | grep -q "High" ; then
        echo "enabled" >> /tmp/script_runs
fi
echo "DONE" >> /tmp/script_runs

exit 0

And my logfile contains only:

sleep done
DONE

But why?

---

Hello

Thank you for contacting,

Based on my understanding, you're issue here is getting the status of the I/O using scripts.

Based on my testing,  what I do to filter out the status of I/O while custom scripting is 

either

iostate1="$(ubus call ioman.gpio.din1 status | grep "value" | cut -c 12)"

 if [ "$iostate1" == "1" ]; then

this one basically counts the status reply  ie: the 12th character  of the "ubus call ioman.gpio.din1 status" would give you the I/O status

or

DI_STATE=$(ubus call ioman.gpio.din2 status| grep value)

    if [ "$DI_STATE" == ""value": "1"," ]; then

        DELAY=$((DELAY + 1))

this one just compares the output

Thanks

Shahl

---

@shahl.rasheed

but why should this work:
DI_STATE=$(ubus call ioman.gpio.din1 status| grep value)

and this not?
ubus call ioman.gpio.din1 status >> /tmp/script_runs

Check a state of din1 with "cut -c 12" look like not good for me, if something change cut give the wrong result...

---

Use jq instead of cut:

opkg update; opkg install jq

ubus call ioman.gpio.din1 status | jq .value

---

Hi @itwolf,

The command you're using is fine, but it does not work in your case due to how you're calling it from the custom scripts (rc.local). When you run the command, the ubus ioman is not unavailable at that time, causing it to fail to output anything to a file. Using the sleep function may not resolve this specifically. I previously provided a suggestion to run the script in the background in your other thread a few weeks ago (here). Have you seen and tried it? It should work fine if you execute it that way.

Kind Regards,