vcontrold
vcontrold copied to clipboard
Create a shared communication backend so that the server becomes optional
Just thinking about how we could make vcontrold better here.
My personal use-case is that I have a Raspberry Pi whose dedicated only job is to talk to my heating. A cronjob runs vclient
each 5 minutes and reads out the data I'm interested in, then visualizes it and provides it via a HTTP server. Most probably, this is a quite common use-case, isn't it?
If so, most people run a server talking TCP/IP on a host that is only acessed locally by the vclient
program, on the very same machine. Thus, we have the overhead of the server-client communication, one more process to run 24/7 and possible security implications because we expose a port to talk to from the whole LAN, that potentionally has to be secured and whatnot.
So, my idea is:
We split up the vcontrold server into the real server stuff and the communication backend. Then, we create a second "client" program, which does not talk to the server, but simply uses said shared library to talk to the heating itself.
This way, we could cover the (imo) most common use-case described above with minimum effort: A cronjob running a program that queries the heating itself, without a server, only running until it's done. I would even claim that using a server to have multiple clients in a LAN being able to talk to the heating is actually an exotic, corner use-case.
This would possibly also make maintenance easier, because we could work on the "real" communication with the heating without having to mess with the server-client protocol.
What do you think?
I can see the point of this. You think of exposing a simple API like for
- get list of data points with their data types and read/write capabilites
- get
- set
- api version
Then it is simple to build REST, mqtt, etc. on top of this.
But who is willing to work on it?
Yeah, that's it. This way, we could build a nice API and other stuff on top of it. I think, for now, not even exposing commands would be needed, as those are defined in the XML file.
I'm not sure if I could do it. I can code a bit of C++ (mostly using Qt), but I never really worked on C code …