I use extensively openhab’s notification feature with a Squeezbox Boom as audio sink using the Squeezebox binding. However I experience common concurrency issues if two
say("asdf")
commands are called close to each other (in different rules triggered by independent events). The Squeezebox almost end in an random state (e.g. with volume set to be zero)
Is there a way to handle this, without using semaphores in Openhab code (if this would work at all)? I would wonder why there is no internal mechanism to avoid these concurrency issues.
Because many technologies can handle this sort of sequence of events just fine. Should OH break all of those instead? It is difficult to come up with any solution that works well for all 300+ supported technologies and APIs. When faced with a choice, the one that provides the fewest constraints on what a technology can support is chosen.
Hi, I am not sure, if my question was too generic formulated. What I meant - to break it down - if I put a lock/unlock mechanism say, such as
lock.lock
say(asdf)
lock.unlock
it may do the job to call two concurrent say commands (which trigger a sequence of squeezebox command - e.g. changing volume, changing stream, etc.). So I would have a lot of boilerplate code here. So why not put the locking mechanism inside the say implementation or even inside the binding?
There may be good reasons, but I think I do not get them yet…
No, it wont. That is why I developed and posted the Gate Keeper DP I posted above. The lock will only prevent two instances of the same rule from executing the say command at the same time. But if you call say from more than one rule the lock will not prevent them both from running at the same time. Also, I believe the say command exits immediately instead of waiting for the text to be said so the lock won’t do much for you without a Thread::sleep inside the locked block.
You need to centralize the calls to say so there is only one line and add the locking and checking in the DP around that singular call to say.
No, here you would just call Say.sendCommand("Changing Volume") etc. This will trigger a rule that limits how fast the say command can be called so there are not two running at the same time.
Because, as far as I’m aware, the Sonos is the only device that seems to have this problem. Should the ability to call the say command before the next one finishes be disabled for those devices that do not exhibit this problem?
