The Future of EasyTerm
How dull life would be if we couldn't constantly look forward to something!
For those of you who have developed a curiosity about EasyTerm or already own it, the following article has been written – a compilation of ideas and plans that would be worthwhile to implement with EasyTerm. Why? So you can have something to look forward to! :-)
EasyTerm is already a "synergy" of several functional units and possibilities. One possibility is to control and monitor almost everything that comes to mind. Whether it's a device you're developing or operating, or various integrated circuits and sensors. Often, monitoring is associated with the ability to log data for later analysis. Another possibility is to use EasyTerm as a "multitool." Sometimes I need a PWM signal, sometimes an analog signal, and other times I need to read register X from sensor Y. And it's just great to have everything in one place – quickly, comfortably, efficiently, and right at hand. And since EasyTerm has a display (HMI), you have almost unlimited ways to control and combine it all.
However, one thing is still missing – and we've already received the first inquiries on this topic. That is, using EasyTerm as a means of automation.
Basically, a lot is already in place, it can do a lot, and the display is excellent for user interaction and for quickly "checking" how everything is working. But what's still missing?
Two things come to mind:
- An extension of the communication protocol for better device-to-device interaction.
- Wireless communication – for convenience (when EasyTerm is used standalone and controlled from a non-mobile device, like a desktop PC).
What's missing from the communication protocol? Not much anymore – we're already in the experimental phase of some form of command tagging support. For simplicity, we’re drawing inspiration from the JSON-RPC protocol, where a command has three parts: a method, method parameters, and an identifier. The device executing the command then includes the identifier in its response, allowing pairing of "request-response" – primarily needed for asynchronous communication. A very interesting tool for automation is the Node-RED environment. Node-RED heavily uses the JSON format, and it would be a shame to go against the grain. However, the EasyTerm protocol is very easily (and naturally) convertible to the JSON-RPC format.
For example, the EasyTerm command to change the PWM signal duty cycle (with the identifier in square brackets):
PWM dutyCycle=50 [0]
Can be rewritten into JSON-RPC as:
{
"method": "PWM",
"parameters":
{
"dutyCycle": 50
},
"id": "0"
}
How can this be done automatically? For example, by implementing simple Node-RED widgets that allow us to parse the JSON-RPC <-> EasyTerm API protocol.
By using these, we can take full advantage of the Node-RED environment for our needs!
And what about wireless connectivity? One of the priorities of EasyTerm was compactness – in other words, to "fit" in your hand. There's no space left on the circuit board, and the microcontroller doesn’t have a single free pin! Adding something that existing owners would miss out on is a path to disaster. However, at the top of the device, there are power and UART connectors side by side, and there are plenty of ESP Wi-Fi modules on the market, as well as many open-source software implementations of Wi-Fi <-> UART bridges available online. In principle, it should already be possible to run EasyTerm wirelessly. However, the issue cannot be fully resolved here – in the future, this option should be thoroughly documented, tested, and officially supported!
Are you excited? :)
