I want multiple subscriptions on same event or same property, is that possible?
Not from the same thing, this is a huge limitation on the platform that R&D introduced silently on 6.5, still I don't find the reason ( we had long chats with R&D about this).
We had to build our own DataChange event system in order to overpass that huge limitation
Even if we build our own event then also it wouldn't allow us to create multiple subscriptions on that same event?
from the same thing you can add multiple subscriptions for:
-same event with different properties or,
-same property but events should be different
but if you want to add multiple subscriptions for same events with same property in same thing, I don't think there is need to write multiple subscriptions in this case. you can write your code in single subscription with different conditions according to your need.
Hi Priyanshi Saxena,
Multiple subscription to the same Thing property is not possible currently.
As a workaround you can write different services for different subscription and then call all the services in the single subscription code.
Hope it helps.
If you write different services for different subscription and then call all the services in the single subscription code, that's not really flexible when you have multiple ThingShapes interacting, and makes the solution not really flexible.
That's the real reason on having multiple subscriptions to the same event from the same thing, making a really decoupled system, what you are proposing it's a coupled system which using in development it's a big problem for complex and flexible systems.
Thank you for your valuable input.
Could you please elaborate more on this. I would like to understand the pros of having multiple subscription to same Thing in a complex system.
As per my understanding having multiple subscription to same Thing had some cons. For example we didn't had control over which subscription will run first. So, if two or more subscription code is updating the same property we cannot confirm the final result. Somewhat like race condition in Threads.
We can start a long discussion on this... We had a long discussion a while back when R&D decided to pull off this feature.
Your first point "we didn't had control over which subscription will run first" --> Neither you have control when Event will be Fired/Executed as it may be executed on different threads, your code should support parallelism, we are on a concurrent system, then this problem you are saying it's always there.
About having two or more subscription code updating the same property --> Same as before, this may happen always, not becouse of the subscriptions on the same event from the same thing, you can have timers, other subscriptions which writes to the same property, and so and so.
About the pros:
Hi Charles, absolutely agree!!
The race condition is hopefully not the reason for switching this off. Every MQTT Server does allow multiple subscriptions on keys and fire them in a non predictive way to the subscribers. No issue. there. You just have to be aware.
Secondly there are several other conditions like timer events that can also cause race conditions on property changes. You comments regarding the discussion with R&D makes me really scary.
Nice to meet you, yes you can be scared about this, the talk with R&D was tough (back in July 2015), still now I can't believe their answer, and as time passes we will see more and more complaining customers on this ( as IoT solutions get more complex as are our one ).