search

robertklep / bosch-xmpp

Protocol implementation for Bosch XMPP protocols
MIT License
48 stars 7 forks source link

bridge cannot handle simultaneous requests #26

Open kafeenstra opened 2 years ago

kafeenstra commented 2 years ago

I noticed when running the bosch-xmmp client in bridge mode (localhost), that if different applications send a request simultaneously, the return values are garbled (I have not tried to figure out how, but I suspect some values get swapped; apparently the output is still valid json as I get no errors about that). In particular, I have one python script polling thermostat temperatures every few minutes, and logging them into a database, and can display them in a graph. I have a simple (php) web page which shows the real-time values, which updates every few seconds. When I have that page open, I see occasional weird temperatures in my database and graphs. There is a simple workaround, to start multiple instances of bosch xmmp bridge, and let each app connect to their 'own' bridge. However, I would consider it a neater solution if one bridge could nicely handle simultaneous requests. It seems there may be two ways to do this:

  1. Simplest would be to block any subsequent requests while one is in process. This puts the burden on the app, to retry (but most apps would have some provision for this anyhow).
  2. Nicer would be to have a request queue, but that would complicate things considerably, I presume.

I wouldn't mind helping implementing a solution, but am entirely new to node-js and to this codebase, so would need some pointers to get started ;-)

robertklep commented 2 years ago

The Bosch backend (or rather, the device itself) cannot handle more than one request at a time, and the client already uses a request queue to work around that (to make sure that there's always only one active request).

Do the Python script and the PHP page retrieve the same endpoint, or each a different one? And if so, do the "occasional weird temperatures" make sense for one of the two endpoints, or are they seemingly random? Of it is always a fixed (but weird) value?

Running multiple bridges (or even multiple clients) probably won't work, and will likely actually cause more issues because it becomes impossible to correlate requests with responses.

kafeenstra commented 2 years ago

yes, it seems that the weird values would be valid numbers for other fields. For example, a temperature of 125 degrees, which is the time in minutes to the next programme setpoint. I'm running a pi0 that controls the fans on my radiator, which needs to know the (thermostat) temperature for that. I'm also collecting the readings in a database on a pi4. I'm now running endpoints on both, because I haven't figured out how to securely give the pi0 access to an endpoint on the pi4, without exposing it to anything and anyone on my local network ;-) That said, I tried before to run one bridge on the pi4, which served the database collection, as well as a web frontend status page. If memory serves me, I also saw 'crossover' values in that case; so, two clients reading from one bridge. I'll double check this and post back on it here.

robertklep commented 2 years ago

FWIW, I did some testing and it seems that the bridge can handle multiple requests (multiple clients retrieving an endpoint) without issue, I'm always getting back the expected response for the endpoint. I tested with about 10 concurrent requests.

So multiple clients using one bridge is okay, but like I said, running multiple bridges against the same device is a no-no.