You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2020/11/12 17:33:48 UTC
[DISCUSS] Does our Subscription API actually make sense?
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
Re: [DISCUSS] Does our Subscription API actually make sense?
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <lu...@code-house.org>:
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
>
Re: [DISCUSS] Does our Subscription API actually make sense?
Posted by Łukasz Dywicki <lu...@code-house.org>.
Yes, this is assumption to make it consistent - receiving notification
should bring trigger field and not subscribed field. I think this is a
bit of unclear in our API cause what we probably return is still
subscribed field.
I believe it is testable through driver-it framework and could be easily
enforced across different languages.
Cheers,
Łukasz
On 16.11.2020 11:39, Christofer Dutz wrote:
> Hmmm ... I like the idea.
>
> So your getField(name) doesn't return the field used in the subscription, but the real value ...
> In my case when subscribing to "hurz = */*/*" (evertything) in my KNX environment, then if I do a "getField("hurz")", I might get "1/2/3" ...
> Is that what you mean?
>
> I could probably even access the original field by doing "getRequest().getField("hurz")" ...
>
> If yes: I like it :-) if not: please explain a bit more.
>
>
>
> Chris
>
>
>
> Am 16.11.20, 00:22 schrieb "Łukasz Dywicki" <lu...@code-house.org>:
>
> I have similar case with CANopen and I did register different instances
> of callback for each subscription:
> https://github.com/splatch/canopen-cmi-uvr-playground/blob/master/reader/src/main/java/brute/force/scanner/UVR16Printer.java#L125L136
>
> I believe the ultimate solution would be access to actual field instance
> through subscription event. Currently it is (in theory) doable through:
>
> String name = event.getFieldNames().iterator().next(); // in case of
> wildcard subscription name doesn't matter much
> PlcField field = event.getFiled(name);
>
> I know it is a bit awkward - but it does work with current API. Even if
> an subscription might bring 1..N updates for bus systems it is usually
> 1..1. Exceptionally, even with group addresses supported by KNX you'll
> probably have 1..1 event as whole invention is to reduce bus load. Maybe
> it is good idea to have different field type for groups?
>
> I was also thinking of how to handle "patterns" for CANopen. there are
> heartbeat events sent by nodes. I assumed that nodeId==0 means all nodes
> and nodeId > 0 means specific node. There is just one case when field
> becomes a wildcard and it does not require extra regexp.
> My point in all above is to balance amount of regexps, cause they might
> differ between languages and become a trouble above certain complexity
> threshold.
>
> Best,
> Łukasz
>
>
> On 13.11.2020 13:55, Christofer Dutz wrote:
> > Another thing a came across, was that with subscriptions (at least for KNX) it makes sense to have field addresses that allow matching multiple values.
> >
> > For example if I have an address */*/12, I get all the actual temperature values for all rooms in my house.
> >
> > The problem now is, that if I simply return a PlcValue (or multiple) ... we no longer know which address a value belongs to.
> >
> > So I was thinking:
> > - We distinguish between pattern-fields and normal fields. Normal fields identify only one element, Pattern Fields can identify multiple values.
> > - If a normal field is used, a normal PlcValue is returned
> > - If a pattern field is used, a PlcStruct is returned (even if it's only one element) where the name of the property name is a stringified representation of the address and the value is the PlcValue
> >
> > Does this make sense?
> >
> >
> > Chris
> >
> >
> > Am 12.11.20, 23:15 schrieb "Łukasz Dywicki" <lu...@code-house.org>:
> >
> > 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
> > >
> >
>
Re: [DISCUSS] Does our Subscription API actually make sense?
Posted by Christofer Dutz <ch...@c-ware.de>.
Hmmm ... I like the idea.
So your getField(name) doesn't return the field used in the subscription, but the real value ...
In my case when subscribing to "hurz = */*/*" (evertything) in my KNX environment, then if I do a "getField("hurz")", I might get "1/2/3" ...
Is that what you mean?
I could probably even access the original field by doing "getRequest().getField("hurz")" ...
If yes: I like it :-) if not: please explain a bit more.
Chris
Am 16.11.20, 00:22 schrieb "Łukasz Dywicki" <lu...@code-house.org>:
I have similar case with CANopen and I did register different instances
of callback for each subscription:
https://github.com/splatch/canopen-cmi-uvr-playground/blob/master/reader/src/main/java/brute/force/scanner/UVR16Printer.java#L125L136
I believe the ultimate solution would be access to actual field instance
through subscription event. Currently it is (in theory) doable through:
String name = event.getFieldNames().iterator().next(); // in case of
wildcard subscription name doesn't matter much
PlcField field = event.getFiled(name);
I know it is a bit awkward - but it does work with current API. Even if
an subscription might bring 1..N updates for bus systems it is usually
1..1. Exceptionally, even with group addresses supported by KNX you'll
probably have 1..1 event as whole invention is to reduce bus load. Maybe
it is good idea to have different field type for groups?
I was also thinking of how to handle "patterns" for CANopen. there are
heartbeat events sent by nodes. I assumed that nodeId==0 means all nodes
and nodeId > 0 means specific node. There is just one case when field
becomes a wildcard and it does not require extra regexp.
My point in all above is to balance amount of regexps, cause they might
differ between languages and become a trouble above certain complexity
threshold.
Best,
Łukasz
On 13.11.2020 13:55, Christofer Dutz wrote:
> Another thing a came across, was that with subscriptions (at least for KNX) it makes sense to have field addresses that allow matching multiple values.
>
> For example if I have an address */*/12, I get all the actual temperature values for all rooms in my house.
>
> The problem now is, that if I simply return a PlcValue (or multiple) ... we no longer know which address a value belongs to.
>
> So I was thinking:
> - We distinguish between pattern-fields and normal fields. Normal fields identify only one element, Pattern Fields can identify multiple values.
> - If a normal field is used, a normal PlcValue is returned
> - If a pattern field is used, a PlcStruct is returned (even if it's only one element) where the name of the property name is a stringified representation of the address and the value is the PlcValue
>
> Does this make sense?
>
>
> Chris
>
>
> Am 12.11.20, 23:15 schrieb "Łukasz Dywicki" <lu...@code-house.org>:
>
> 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
> >
>
Re: [DISCUSS] Does our Subscription API actually make sense?
Posted by Łukasz Dywicki <lu...@code-house.org>.
I have similar case with CANopen and I did register different instances
of callback for each subscription:
https://github.com/splatch/canopen-cmi-uvr-playground/blob/master/reader/src/main/java/brute/force/scanner/UVR16Printer.java#L125L136
I believe the ultimate solution would be access to actual field instance
through subscription event. Currently it is (in theory) doable through:
String name = event.getFieldNames().iterator().next(); // in case of
wildcard subscription name doesn't matter much
PlcField field = event.getFiled(name);
I know it is a bit awkward - but it does work with current API. Even if
an subscription might bring 1..N updates for bus systems it is usually
1..1. Exceptionally, even with group addresses supported by KNX you'll
probably have 1..1 event as whole invention is to reduce bus load. Maybe
it is good idea to have different field type for groups?
I was also thinking of how to handle "patterns" for CANopen. there are
heartbeat events sent by nodes. I assumed that nodeId==0 means all nodes
and nodeId > 0 means specific node. There is just one case when field
becomes a wildcard and it does not require extra regexp.
My point in all above is to balance amount of regexps, cause they might
differ between languages and become a trouble above certain complexity
threshold.
Best,
Łukasz
On 13.11.2020 13:55, Christofer Dutz wrote:
> Another thing a came across, was that with subscriptions (at least for KNX) it makes sense to have field addresses that allow matching multiple values.
>
> For example if I have an address */*/12, I get all the actual temperature values for all rooms in my house.
>
> The problem now is, that if I simply return a PlcValue (or multiple) ... we no longer know which address a value belongs to.
>
> So I was thinking:
> - We distinguish between pattern-fields and normal fields. Normal fields identify only one element, Pattern Fields can identify multiple values.
> - If a normal field is used, a normal PlcValue is returned
> - If a pattern field is used, a PlcStruct is returned (even if it's only one element) where the name of the property name is a stringified representation of the address and the value is the PlcValue
>
> Does this make sense?
>
>
> Chris
>
>
> Am 12.11.20, 23:15 schrieb "Łukasz Dywicki" <lu...@code-house.org>:
>
> 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
> >
>
Re: [DISCUSS] Does our Subscription API actually make sense?
Posted by Christofer Dutz <ch...@c-ware.de>.
Another thing a came across, was that with subscriptions (at least for KNX) it makes sense to have field addresses that allow matching multiple values.
For example if I have an address */*/12, I get all the actual temperature values for all rooms in my house.
The problem now is, that if I simply return a PlcValue (or multiple) ... we no longer know which address a value belongs to.
So I was thinking:
- We distinguish between pattern-fields and normal fields. Normal fields identify only one element, Pattern Fields can identify multiple values.
- If a normal field is used, a normal PlcValue is returned
- If a pattern field is used, a PlcStruct is returned (even if it's only one element) where the name of the property name is a stringified representation of the address and the value is the PlcValue
Does this make sense?
Chris
Am 12.11.20, 23:15 schrieb "Łukasz Dywicki" <lu...@code-house.org>:
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
>
Re: [DISCUSS] Does our Subscription API actually make sense?
Posted by Łukasz Dywicki <lu...@code-house.org>.
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
>