subscribe to our Youtube


14455 questions

17168 answers


0 members

We are migrating to our new platform at Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
270 views 8 comments
by anonymous

The GUI of the TRB255 is pretty useful, regarding I/O juggler, we can create actions to trigger HTTP request when an input state change.

Unfortunately we saw no way to periodicaly trigger an action to send the input state (even if no change occured). There is prabably a way to do this with a custom script uploaded through SSH but I doesn't seems too much job to implement this as a native feature. Did we miss something on the documentation to do this ?

1 Answer

+1 vote
by anonymous


Thank you for your suggestion.

Could you please provide more details on how do you want to receive the input state?

Configuring periodic processes, such as yours, should be relatively simple. It does indeed require a script in combination with crontabs functionality.

To retrieve the input state, the following command can be used:

  • ubus call ioman.gpio.dioX status

Replace X with values 0, 1 or 2, depending on the output used.

Example of script sending SMS about input state can look the following:

TEXT=$(ubus call ioman.gpio.dio1 status | grep value)
gsmctl -S -s "0037060000000 $TEXT"
How to setup crontabs, to execute the script periodically, please refer here.
The script can be edited to have infinite while loop with sleep function to define the frequency of command execution and placed in System -> Custom scripts page to run in the background upon device boot.
Best regards,
by anonymous


For exemple and keepalive action

With the following content

it would be very usefull to trigger this actions peridicaly, using for exemple the scheduler.

If we craft a custom script is there any variable we could use to get ICCID, or signal strengh ?

Best regards

by anonymous

hi @

by anonymous


To trigger periodic sending of your desired information, configure the action according to your requirements. For testing, I had a listening host at on port 8080 and used used the below configuration:

Add this action to your I/O Juggler instance and save the settings.

Next you will need to generate crontab with the periodicity you want your information sent to some host. It can be generated in this site. The command you want to periodically execute, to trigger input is the following:

  • ubus call ioman.gpio.dio0 update '{"invert_input":true}' && sleep 5 && ubus call ioman.gpio.dio0 update '{"invert_input":false}'

After generating the crontab, login to your device via SSH. Enter command:

  • crontab -e 

Press letter i to start editing and add the generated crontab.

Once done, press Esc button to stop editing, enter :wq and press Enter to save changes.

Best regards,

by anonymous
Thank you for your answer.

The purpose of the keepalive, is also to check if we didn't miss a state change (ie an input was changed from low to high during network failure). The keepalive should report also the input state, if we use the suggestion above, the keepalive will report a false input state (inverted).
by anonymous


A different approach can be attempted, which would include reading input state from the device using MODBUS protocol and then forwarding this data over HTTP(S) protocol.

To begin configuring, navigate to Services -> MODBUS -> MODBUS TCP Slave.

  • Enable instance;
  • If necessary, edit configuration details according to your needs, otherwise, leave the rest as default;
  • Save settings. 

Go to Services -> MODBUS -> MODBUS TCP Master.

  • Add a new instance;
  • Enable it;
  • Enter a name;
  • If you did not change slave ID in slave settings, leave default value 1;
  • Set IP address option with the LAN address of the gateway.
  • If you did not change port number in slave settings, leave default value 502;
  • Leave the rest as default or edit accordingly, except for the Period;
  • Set Period (in seconds), according to the frequency you want the input value to be read;

Next, within the same configuration window, below configure data request:

  • Give it a name and press Add;
  • Data type: 16bit UINT, high byte first;
  • Function: Read holding registers (3);
  • First register number: 325 (pin 3, for pin 4 it would be 326);
  • Number of registers: 1;
  • Set rightmost slider button to on
  • Save the settings;
  • You can enter the settings again and test, if the request returns correct value.

Once done, navigate to Services -> Data to server page.

  • Add a new instance;
  • Enable it;
  • Give it a name;
  • Data source: MODBUS data;
  • Protocol: HTTP(S);
  • JSON format: {"Input state":"%a"}
  • Segment count: 1;
  • URL / Host / Connection string: address, where to send data;
  • Period: define, how frequently to send collected data;
  • Leave the rest as default;
  • Save the settings.

For testing, I have used Hercules utility, input data was periodically sent:

Best regards,

by anonymous
Yes there is multiple ways to do it. IMHO the custom script is way simplier than modbus, but the main purpose of our reflexion is there is almost everything needed in the I/O section and it would be smart to have this feature inside this section. Then the all thing would be coherent (aka same consistent payload, and same way to push data).
by anonymous

I understand your implication, however, the whole purpose of I/O juggler is to send data only on occurrence of predefined actions and conditions.

For periodicity, I would suggest to switch to MODBUS, as the data you want to transfer (RSSI, serial, input data) is mostly available by predefined registers. Even more data points can be gathered with the use of additional custom registers. 

Having configured necessary MODBUS requests, using Data to server application will ensure continuous periodic data transfer.

You can find more details on MODBUS here.

Instructions, how to configure custom registers are provided here.

Best regards,

by anonymous
the whole purpose of I/O juggler is to send data only on occurrence of predefined actions and conditions.

I get it, and this is what is our interrest. But what happens if an occurrence happens and there is no LTE connection at this time ?