Executing a userscript in the io juggler is not possible with RUT956 RUT9M_R_00.07.20.3

[uwet]

The following script worked on the RUT955:

#!/bin/ash

if [ $(gpsctl -s) -eq 1 ]; then # Wenn GPS Signal vorhanden

latitude=$(gpsctl -i)
longitude=$(gpsctl -x)

uci set gps.aktuelleposition.longitude=$longitude
uci set gps.aktuelleposition.latitude=$latitude

uci commit gps
/etc/init.d/gpsd reload

else

gsmctl -S -s “+49xxxxxxxxxxx Kein GPS Empfang Geozaun nicht gesetzt”

fi

On the RUT956, this only works via the console CLI. The script doesn’t set the geofence values ​​in the I/O Juggler. How do I get the necessary permissions for usi set gps.longitude/latitude? It seems that the rights are missing in the context of the I/O juggler.

Thank you

[Vilius]

Greetings @uwet ,

Thank you for reaching out.

To help investigate this issue further, could you please clarify the following:

1. Script execution context:
   When you test the script manually via SSH/CLI, are you logged in as the root user?
2. I/O Juggler script setup:
   In the I/O Juggler action, did you upload the script directly in the rule or did you specify a script path? Note that the RUT956 has a Custom Scripts section in the web UI that is intended for scripts executed at boot via /etc/rc.local, which is separate from the scripts uploaded in I/O Juggler actions.
3. Observed results:
   What exactly happens when the script is triggered by the I/O Juggler — does it simply do nothing, or are there any visible results (e.g., partial behavior or unexpected output)?
4. Error outputs/logs:
   Are there any error messages in the system logs or in the Juggler trigger results? Screenshots or log excerpts would be very helpful.

Getting these details will help determine whether this is a permission/context issue, a script upload path issue, or something else in the I/O Juggler configuration.

Looking forward to your reply,

Best regards,
V.

[uwet]

Greetings,

1. When I test the script manually via CLI, I am the root user. Then everything executes correctly.
2. Whether I upload the script normally or from a path does not change the fact that it is executed incorrectly.
3. The script runs without any visible errors. The SMS sending commands are executed correctly. Only the coordinates are not changed via ‘uci set’. This can be seen in the map under gps/geofence. The location is not changed; the old coordinates remain.
4. There are no error messages.

As I already mentioned, everything works correctly up to RUT9M_R_00.07.13.4; the coordinates in the geofence are set correctly. I also tested versions RUT9M_R_00.07.20.3 and RUT9M_R_00.07.21.1. In both, the script works in the CLI as root, but not in the I/O Juggler. In the latter case, only the SMS commands are executed, but the new geofence coordinates are not set.

[Vilius]

Hi, @uwet ,

Thank you for the additional details and for confirming that the script works when executed manually as root . Since the uci set commands do not seem to apply when the script is triggered by I/O Juggler , it may be related to the execution context or permissions in newer firmware versions.

To help narrow this down, could you please try the following checks?

1. Verify which user executes the script from I/O Juggler

Please add the following lines temporarily to the script:

id > /tmp/juggler_user.txt
whoami >> /tmp/juggler_user.txt

After triggering the rule, check the result via CLI:

cat /tmp/juggler_user.txt

This will confirm whether the script is running as root or a restricted system user.

2. Check if UCI writes are blocked in this context

Please add a simple test inside the script:

uci set gps.testvalue=test
uci commit gps

Then verify the result:

uci show gps

If the value does not appear, it would indicate that the script cannot modify this configuration when executed through I/O Juggler.

3. Monitor system logs while triggering the rule

Run the following command in the CLI:

logread -f

Then trigger the I/O Juggler rule and check if any related errors appear in the logs.

4. Use full command paths

Since the I/O Juggler environment may use a limited PATH, please try replacing the commands with full paths:

/usr/sbin/uci set gps.aktuelleposition.longitude=$longitude
/usr/sbin/uci set gps.aktuelleposition.latitude=$latitude
/usr/sbin/uci commit gps
/etc/init.d/gpsd reload

5. Test modifying a different configuration

To determine whether the behavior is specific to the GPS configuration, please try a temporary change such as:

uci set system.@system[0].hostname=test123
uci commit system

If this works while the GPS configuration does not, it may indicate that the restriction applies specifically to that configuration.

6. Capture script debug output

You can also run the script with debug output enabled:

sh -x /path/to/script.sh > /tmp/juggler_debug.log 2>&1

Then review the output:

cat /tmp/juggler_debug.log

Once you have the results from these checks, please share them with us and we will continue investigating the issue further.

Best regards,
V.

[uwet]

Hello, I’m back with a test setup. The whoami command isn’t implemented, so I’ve been testing the necessary permissions. I’m using the two keys to start a script that sets coordinates.

Example:

#!/bin/ash
#uci set gps.testvalue1=test
#uci commit gps

#latitude=‘52.344509’
#longitude=‘14.515258’

latitude=‘52.343528’
longitude=‘14.517436’

uci set gps.standort.longitude=$longitude
uci set gps.standort.latitude=$latitude
uci commit gps
#/etc/init.d/gpsd reload

First problem: it wasn’t always executed. So, as feedback for the key press, I enabled the internal relay to click. After the key press was audibly registered, sometimes only after the third attempt or a pause (for some reason), I was able to track the change in coordinates under Services/GPS/GPS Geofencing/location. The result: Executable (666) isn’t sufficient. The script located in usr/local/home/user requires at least permissions 766. Only then are the geofence coordinates reset. However, you definitely have to access it via GPS Geofence/Variable and the Event Type Log. I haven’t figured out how to change the coordinates in the Event Juggler/Event Type GPS. Perhaps someone knows more about that. I haven’t yet tested whether an alarm is triggered when leaving the newly set geofence; everything is still on my desk.

Regards

[Vilius]

Hi @uwet,

Thank you for the thorough testing and for sharing your findings - this is very helpful and will likely benefit others facing the same issue!

To summarize what you discovered for the benefit of the community:

1. File permissions matter in the I/O Juggler context: A script requires at least 766 permissions to execute correctly when triggered by the I/O Juggler. Permissions of 666 are not sufficient - the execute bit must be set.

   You can set the correct permissions via CLI:

   chmod 766 /path/to/your/script.sh
   

2. Script action configuration: As a reminder, the Event Juggler Script action supports two modes — Upload (upload the script file directly) or Path (specify the full path to the script file on the device). Either way, the execute permission must be set correctly.

One important thing to note about your test script: the coordinates you used were hardcoded (latitude='52.343528', longitude='14.517436'), which confirms that uci set writes are working once permissions are fixed - but it does not yet validate the dynamic part of your original script. Your original script used gpsctl -i and gpsctl -x to read the current GPS position at runtime:

latitude=$(gpsctl -i)
longitude=$(gpsctl -x)

Now that the permissions issue is resolved, it would be worth re-testing with the full dynamic logic to confirm that gpsctl also returns valid values when executed from the Event Juggler context (not just from the CLI). If gpsctl produces no output in that context, the variables would be empty and uci set would silently write nothing - which could still cause problems.

Regarding your open question about setting coordinates via the Event Juggler GPS event type - according to the wiki, the GPS event type (Geofencing/Altitude/Speed) is used as a trigger for actions, not as a way to dynamically update geofence coordinates. Updating coordinates programmatically via uci set through a Script action, as you have been doing, is the correct approach.

Please share the results once you have tested the full dynamic script and the geofence alarm - it would be very valuable for others following this thread.

Best regards,
V.

[uwet]

Hello, I’m reporting back with new results. The commands:

uci set gps.standort.longitude=$(gpsctl -x)
uci set gps.standort.latitude=$(gpsctl -i)
uci set event_juggler.6.gps_longitude=$(gpsctl -x)
uci set event_juggler.6.gps_latitude=$(gpsctl -i)
uci commit gps
work. I can also read the set values ​​afterwards. Both the values ​​for setting the values ​​in the services/gps/gps Geofence and in event_juggler event type: gps have been newly set. Unfortunately, that doesn’t help at all. As I already noted at the beginning, I can only change the UCI values ​​in the context of the event juggler. Unfortunately, that doesn’t help at all. As I already noticed at the beginning, I can only change the UCI values ​​in the context of the event juggler. For example, I can’t execute the command: ‘id >> /usr/local/home/user/juggler_user.txt’, even though the file exists and has permissions of 777. If I run the script from the command line as root, the file is written. I lack the necessary permissions. The same thing happens when I try to apply the new GPS coordinates with ‘gpsd restart’ or ‘gpsd reload’. Therefore, no event or log entry is created that I can use. What options do I have to restart the gpsd service in order to transfer the data?

regards

[uwet]

Hello, I’ve done some more testing with a script in Juggler. The only thing that works is ‘id >> /mnt/sda1/juggler_user.txt’. It then contains: uid=0(root) gid=0(root). I can’t create any other file from Juggler anywhere else in the file system, and I probably can’t restart any services either. The script works in the CLI and writes to /temp/ with the result: uid=0(root) gid=0(root) groups=0(root). Regards

[Vilius]

Hello, uwet,

Thank you for an update,

Please carry out the following tests in order and share the results with us:

1. Confirm permissions are correctly set. Verify the script file has the correct permissions:

   ls -la /path/to/your/script.sh

Expected output should show -rwxrw-rw- (766) or stricter (e.g. 755 or 777 will also work). If not, apply:

chmod 766 /path/to/your/script.sh

2. Test gpsctl output in the I/O Juggler context to confirm that gpsctl returns valid data when the script is run via the I/O Juggler (not just from CLI), add the following lines temporarily to your script:

   gpsctl -i > /tmp/juggler_gps_test.txt
   gpsctl -x >> /tmp/juggler_gps_test.txt

Trigger the rule, then check the output:

cat /tmp/juggler_gps_test.txt

If the file is empty or missing, gpsctl is not returning data in this execution context, which would cause uci set to silently write empty values - and the geofence would appear unchanged.

3. Re-test with the full dynamic script. Once Step 2 confirms gpsctl is working, restore the full script logic with live coordinate reads and trigger the I/O Juggler rule. Verify the result under Services → GPS → GPS Geofencing to confirm coordinates have updated.

4. Test the geofence alarm trigger. Once the coordinates update correctly, verify that the geofence alarm fires as expected when the device exits the newly set geofence zone.

5. Check system logs during execution

If any step above does not behave as expected, please capture the system log output while triggering the rule:

logread -f

Share any relevant log entries with us - even an absence of errors is useful information.

Please do not hesitate to reach out if you have any questions in the meantime.

Best regards,
V.

[uwet]

Hi, the permissions for the script are -rwxrw-rw- (766).

gpsctl -i > /tmp/juggler_gps_test.txt

gpsctl -x >> /tmp/juggler_gps_test.txt

changed to

gpsctl -i > /mnt/sda1/juggler_gps_test.txt

gpsctl -x >> /mnt/sda1/juggler_gps_test.txt

Because no file is created in /temp or anywhere else in the file system when I run the script in Juggler. Even if I create it manually, nothing is written to it. If I change the destination to the USB stick, the current position is in the file. The data is also updated in Services → GPS → GPS Geofencing. I already mentioned that this works. However, there’s no geofence alarm. For that to happen, the gpsd service needs to be restarted to apply the new coordinates: /etc/init.d/gpsd restart. This doesn’t happen in the context of Juggler, only in the console. It’s also strange that the root user in Juggler isn’t allowed to write to the file system, but only to the USB stick. I’ve now tested everything with a RUT955 as well. It works there. Regards

[uwet]

The Juggler script cannot be run with the command sh -x /path/to/script.sh > /tmp/juggler_debug.log 2>&1. Therefore, there is no log file. Regards

[Vilius]

Thank you for the detailed feedback and for performing the additional tests.

Based on your results, we can confirm the following behavior:

• The script is executed in Juggler, and permissions are not the limiting factor.
• gpsctl behaves differently depending on execution context:
  • Output is correctly generated when using external storage (USB)
  • Internal filesystem paths (e.g. /tmp) are not written to during Juggler execution
• GPS coordinates are updated and visible in Services → GPS → GPS Geofencing
• However, the geofence alarm is not triggered automatically
• A manual restart of the GPS service (/etc/init.d/gpsd restart) is required for the geofence alarm to become active
• Logging via sh -x redirection is not producing a file when executed through Juggler

At this point, the behavior suggests a difference in how service updates are handled when scripts are executed via Juggler compared to CLI execution, particularly in relation to gpsd reload behavior required for geofence activation.

Therefore, for testing purposes, would it be possible to update the firmware to the latest release without Keep Settings option enabled? This would help us to rule out the firmware related issues. As for today, the latest release is 07.22.1.

You can find firmware downloads here:

RUT956 Firmware Downloads - Teltonika Networks Wiki

Please let me know how it goes.

Best regards,
V.

[uwet]

So, I’ve now tested this on two RUT956 units running firmware 7.20.3. Afterward, you have to reset the router to factory settings and re-enter all the configuration details manually. Once that’s done, it works. Performing a firmware update while retaining the existing settings does not work.
Thanks and regards.