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" <[email protected]>:
>
> 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" <[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
> > >
> >
>
