Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
l3u opened this issue Jan 30, 2023 · 2 comments
Open

Comments

@l3u
Copy link
Collaborator

l3u commented Jan 30, 2023

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
Copy link
Member

speters commented Jan 30, 2023

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?

@l3u
Copy link
Collaborator Author

l3u commented Jan 30, 2023

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 …

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants