The issue of managing 220V loads from a Mikrotik router was raised several times on the forum.
Another normal solution could be to use the USB GPIO EXTENDER module from the Russian company Open Development http://open-dev.ru
The module can be connected to any Mikrotik router that has a USB port.
“On board” the module there are 5 digital IN lines and 5 OUT lines.
Unfortunately, the module does not support the AT exchange format, so we cannot receive data from the input lines of the module, but we can control the digital outputs by setting their state to “1” or “0”. If you connect a relay block to them, you can control low-voltage or high-voltage loads.
When the relay module control voltage is +5V, the relay block power can also be obtained from the USB GPIO EXTENDER.
I implemented a ready-made device in a housing, including both a module and a relay unit, controlled from the Mikrotik OS Router using a special script function.
In the spirit of Glasnost… I put in a feature request a while back on non-AT serial support. And got a response to it recently, I’m told RouterOS will add some support for doing something like /system/serial-terminal input=“<>” in a future version. This avoid the “at-chat” and its “OK” requirement for serial. So theoretically any USB device that presents itself as serial device to Linux, should be scriptable. Mikrotik does not make promise of when, but the serial support seems on the radar at least.
Please tell me, Amm0! Do you not know how the support for AT commands works? I mean, how should the device accessed by the ppp-out interface return the data so that it is “correctly” returned by the interface? I’ll explain. There is a programmable version of the device that I described here. Both theoretically and practically, it is possible to make it support AT commands…
While I’m working with the device, the trick is to transfer data to the dial-on-demand field:
Actually the input do NOT have to be “AT”, it is the output that has to return “OK” which is what modems do at when done with an “AT” command. The “at-chat” command returns the buffer when it sees “\nOK” in the data stream. So it actually that “\nOK” your device would need to send to get at-chat working on V6. But on the input side, it could be anything. But it will hang or timeout if you don’t send an OK that’s the limitation.
I didn’t understand everything, but I probably got the gist. If my device does, say, sprintf(&UART0.TX, “A%d\n”, PA4.VALUE) by sending A11101\n to TX, then in order for this to work correctly with AT-CHAT, do I need to return OK\r\n\A11101\r\n ?
That is, you need to add “OK” to the returned data, no matter where (to the beginning, to the end?)
It has to be at the end of what returned to RouterOS from your device’s serial. The “OK” mean command is done/finished to that what trigger at-chat to put the data from input= to the OK into the variable.
Now I see where the “string with 10101” OR needs come up in from your other thread.
FWIW, if you control what being sent…you can make your parsing on the RouterOS easier. The printf % stuff is pretty flexible, so you can do stuff like add a “0x” with leading zeros (%#010x) or just %d to get the base 10 of the bits - that let you use [:tonum] on the result from at-chat. And with a number on the RouterOS side all the bit-wise operators would just work.
Take sprintf(&UART0.TX, "%#010x\r\nOK\r\n", PA4.VALUE) with the 11101 bits in value.
that should get: “0x0000001D” as a string into some routeros variable from :global status [/interface ppp-client at-chat ... input="get"]. With that string, you can convert it to a number :global powerbits [:tonum $status] and with those “powerbits”, all the OR XOR AND stuff work on the bits from device’s C code.
Like :put ([:tonum "0x0000001D"] & 1) would let you know if the right-most bit was on/1… Using XOR, you can know the 2nd from right is OFF using “:put ([:tonum “0x0000001D”] ^ [:tonum “0x1F”])”.
Similarly, if you want to set power, if you just provide a base 10
:global status [/interface ppp-client at-chat … input=“set 29”]
… you could use atoi() to get the 29 into a number in C (where same bit-wise stuff work.
Thank you very much, Amm0, for your advice and help. In the end, everything worked out for me and it works. I have modified the firmware of the programmable version of the USB GPIO EXTENDER T so that it returns OK in the responses and now the device is adequately supported /ppp-client at-chat Mikrotik. I also wrote functions for modified firmware to use them in Mikrotik scripts for a programmable version of the USB GPIO EXTENDER T (TOIC) device.
You can download them here https://github.com/Sertik13/USB-GPIO-EXTENDER-T-TOIC/tree/main
