search

openv / vcontrold

:fire: vcontrold Daemon for control and logging of Viessmann® type heating devices
https://github.com/openv/openv/wiki
GNU General Public License v3.0
100 stars 54 forks source link

Create a shared communication backend so that the server becomes optional #121

Open l3u opened 1 year ago

l3u commented 1 year ago

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?

speters commented 1 year ago

I can see the point of this. You think of exposing a simple API like for

Then it is simple to build REST, mqtt, etc. on top of this.

image image

But who is willing to work on it?

l3u commented 1 year ago

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 …