please kindly point me in the right direction, I am lost in the sea of Forum Information, and google Universe…
I want to power cycle, lets say, ether2 when the RX traffic drops below 4 Mbps for more than a minute.
As I am completly new in MT-scripting I wonder:
Is something like that even possible?
Which commands/functions should I use?
Why?
MT can only communicate in Management-VLAN.
ether2 is not part of Management-VLAN
A Camera is connected to ether2 and sometimes, for some obscure reasons stops video streaming.
If both the above are true, you can use a simpler netwatch probe.
In recent RoS, besides ICMP pinging (simple) there are other possible probes: https://help.mikrotik.com/docs/spaces/ROS/pages/8323208/Netwatch
so maybe one of the others could reflect the operational or non-operational status of the camera, should the simple icmp ping not be suitable.
@jaclaz,
Thanks for your answer, but..
the problem with netwatch is – it needs Network connectivity between MT and Camera.
As I wrote, there is no connectivity, as MT has no IP Address in Camera Network.
So netwatch does not help with this issue.
That`why I looked for annother way to check if CAM is working propperly without pinging it.
In a nutshell:
/interface {:put [get ether2 rx-bytes]}
then, after a short delay, let’s say 10 seconds, verify that the value has changed.
Or get some values from the array:
:put [/interface monitor-traffic ether2 once as-value]
i.e.:
:put ([/interface monitor-traffic ether2 once as-value]->“rx-bits-per-second”)
The possible issue with your script as is, is that if the rx-packets are low for ANOTHER reason (let’s say a flaky cable/connector or the power to the cameras is off, or whatever) the power-cycle on ether2 will change nothing, so you will have the interface being powered cycled again (and again) indefinitely at each script run.
You should probably find a way to add a counter of some kind to the effect that if immediately after (say) two consecutive power cycles if the packets are still below the desired threshold, an alarm (mail, or whatever) should be triggered and subsequent power cycles are prevented.
This counter should be zeroed only in case of number of packet bigger than threshold.
I have no idea if the power-cycle can actually contribute to wear prematurely something, but anyway you would fill the log.