Which tool to choose to automate the work with VT100?

Question

Python

Access to the equipment is organized through the VT100 interface. It is required to automate work with the terminal emulator.
Of the features of the task, it should be noted the ability to control a given area of ​​the screen, because. this moment is very important. This is necessary to respond when information about an accident appears, as well as to read information to obtain data. In a sense, this is an attempt to replace a person in front of the terminal to perform routine operations.
I see two options:
1) use a terminal program with the ability to write scripts.
2) modify the open source terminal emulator to fit your needs.
I'm more inclined towards the second option, because. in fact, it has no potential limitations. Work will be done on Windows. I can program under C/C++/Qt, PHP, Python.
Perhaps there is a tool that, when feeding it a VT100 data stream, builds a picture that can be read. I appeal to the collective experience, because. I didn't find the right tool. Are there any? Or on the basis of what is it faster to create your own instrument? I propose to discuss.
If we really dream, then it is desirable to expand the logic of the machine in a scripted form, because. recompiling the project to change the algorithm is not the best option.

Answer 1

Bombus , first you make a library to issue VT100 commands (this is from the controller side), and then you are looking for a solution to render VT100 sends into an image and track changes in screen areas. I understand correctly?! It reminds me of something ...
If for good, make the mode switch from the controller side - data / visual.
In visual mode, work by sending VT100 - beautifully, clearly, you can connect with a terminal ... In data mode, exchange data, at least via modbus - reliably, machine-readable, etc.
To switch modes, you can use some text sequence, for example ++++====++++=1 switch to visual mode, and ++++====++++=2 switch to data mode.
If our data mode is not the main one, then you can exit it by some kind of timeout, for example, after 5 minutes without a response to the packages. And vice versa too...
And yes, many old programs like kermit switched operating modes in a similar way...