It has come to my attention that RutOS 7.14 has removed the I/O POST/GET function in favour of the standard API. At present we use the time parameter to temporarily toggle a pin, which the API does not appear to support. We use this as a kind of power switch, and the device making the request is the device that gets power cycled, so it is essential that the router itself can switch the pin back again without any further requests from the device. Is there any plan to add this function to the API?
We are in the same situation. We have achieved some advances, creating a bulk request ( https://developers.teltonika-networks.com/fundamentals#bulk-requests ), but without a timeout between switching on and then off the dout1 pin. The advantage of a bulk request is that you launch a unique request and forget. The execution of individual requests is done in an “atomic” way.
An additional question is: Does it exist a way to introduce delays between two endpoints requests in a bulk request?
I found a completely dirty way to insert a delay: repeat the first trigger multiple times in the bulk. Repeating 8 times in a RUT241 gives aprox. 1 second of delay, enough for my purposes.
Elegant? Not at all! Does it work? Yes. (Long live engineering
Anyway, it would be nice to find a clean way to do it from the API… Let’s wait for someone at Teltonika to respond.
Beyond other uses for I/O pins, I think power cycling devices is a feature that is in demand (it certainly is for my organization).
The rise-delay-fall (or vice versa) feature available in the deprecated I/O API, executable as an atomic operation, is very important. It could be implemented as an enhancement to the /io/{id}/actions/change_state endpoint (adding parameters similar to those of the equivalent deprecated API command), or as an additional, completely separate “delay” endpoint, allowing it to be included within a bulk request. This latter approach may be even more interesting, allowing the entire bulk sequence to execute each individual endpoint sequentially.
Yes we will be in the same situation. we use the the GET/POST interface to power cycle devices,I Just upgraded to 7.16 to find this out :\ I will down grade to 7.13 until 7.18 comes out and implement bulk requests with the time period attribute.
It will take a long time before the deprecated endpoint is removed, so you can safely continue using it for now. It was reworked due to an improper endpoint structure when implementing the backup functionality. In the future, if there is a need, delay functionality will likely be added to the new endpoint as well.
“Deprecated” is a warning that an endpoint is no longer supported (although in some cases it may still be partially supported and even receive bug fixes). It also indicates that the endpoint will be removed with a major API version update. However, that API version upgrade has not happened yet and is not expected in the near future.
We reiterate our interest in maintaining the implementation of I/O change_state, to perform power cycling in our organisation, without the need of workarounds like bulk requests.
Thanks for reaching out, Jose. This issue seems to have been fixed with 7.18 firmware. Could you please update, if you haven’t yet, and confirm whether everything works as expected?
