Hi Lukasz, in KNX generally only something similar to on-value-change is supported, however it's just similar as some values simply get re-transmitted periodically. So they actually don't change.
So for the new Go driver I implemented the driver in a way that it caches the last version of every group-address post. Now it uses this to do a real value-change check and I can use the cache to build responses for periodic fields and I can now even support active reading of values. So you see ... we do have options to provide functionality in the API which the protocol doesn't generally support. Chris Am 12.11.20, 23:15 schrieb "Łukasz Dywicki" <[email protected]>: Looking at subscription methods - I am not sure if there is one standard which can support all three kinds at the same time. Some kind of distinguish is necessary, but for an end user (counting myself) - multiple types of subscription happening at the same time are rather unlikely to happen. Looking from canopen perspective - there is possibility to subscribe to some messages happening directly on the bus if plc4x becomes a so-called master node (that's the way its implemented currently using EVENT subscription kind). There is also possibility to subscribe over coordinator node which is specified by yet another specification which number I don't remember right now. In theory - we could also subscribe to other node messages since canbus is still a bus system so everyone sees everything. Later two cases are currently left unimplemented. Best, Łukasz On 12.11.2020 18:33, Christofer Dutz wrote: > Hi all, > > I’m currently implementing the different subscription types in KNX4Go … and here I noticed something. > We create a SubscriptionRequestBuilder and here can add different types of fields and even combinations. > So we could create a subscription request with some on-value-change fields, some periodically pulled fields and some events/alarms. > > Now does it actually make sense to have this sort of combinations? I mean the program processing the results has to be very flexible in this case. > > Wouldn’t it make sense to have 3 different types of subscription requests? > > Chris >
