You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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 …
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?
The text was updated successfully, but these errors were encountered: