vcontrold icon indicating copy to clipboard operation
vcontrold copied to clipboard

Create a shared communication backend so that the server becomes optional

Open l3u opened this issue 2 years ago • 2 comments

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?

l3u avatar Jan 30 '23 09:01 l3u

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.

image image

But who is willing to work on it?

speters avatar Jan 30 '23 13:01 speters

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 …

l3u avatar Jan 30 '23 17:01 l3u