Hey Chris, Issue is slightly different than you indicated in your answer. There is one request (1) but multiple fields (N) and there is no way to read out partial information from device. Also device response contains all necessary bits to describe answer (self descriptive frame). This means that driver will have all the information to form reply composed from multiple fields. Passing part of logic from driver to interceptor/optimizer seems to create more troubles. In such case answer is processed in two places instead of one. This is problem I would like to avoid. If we go with optimizer path then we have also situation it will must buffer answer and take care about expiry of values. There is no other metadata than "read out" so discovery should rely on pretty much the same code as driver.
Best, Łukasz On 22.03.2021 14:22, Christofer Dutz wrote: > HI Lukasz, > > I think the org.apache.plc4x.java.spi.optimizer.BaseOptimizer is your friend > here. > We use this for example in the S7 driver to intercept requests and to split > them up into multiple requests and to bring the results back together again. > I think in your case you would simply go through all items and for each > device addressed in that, create one request that reads all fields of a > device. When the results come back you pick only the required bits of > information from the response and return that to the client. > > Perhaps the "Optimizer" isn't that good of a name ... perhaps we should > rename it to "RequestInteceptor" which would sort of cover also your usecase. > In general it was intended to be used by a proposed "optimizer" component to > rewrite requests to be executed in the most efficient way (Auto re-writing > reading of 8 boolean fields to a byte read behind the scenes) > > Hope that helps. > > Chris > > > -----Ursprüngliche Nachricht----- > Von: Łukasz Dywicki <[email protected]> > Gesendet: Montag, 22. März 2021 13:55 > An: [email protected] > Betreff: Mapping of single request to multiple fields, M-Bus read request > > Hey, > I do have an question about M-Bus devices. There are several things which are > quite specific to this standard. > > When there is an read out request device answers with all values it does > have. Given my current (limited) knowledge about M-Bus, there is no way to > get single field. I believe it makes some sense since it is an bus system > where frame overhead matters. > > Currently we miss a developer guidelines which would provide durection for > most common scenarios. I think in all other places it is rather simple cause > request items usually map to single (primitive) value in the field device or > complex type (user defined type) at most. That's why we didn't need any major > writing about above. > > To put more context. Each reading of meter contains 0..N fields. Each field > have several points: > - Reported value (an int/decimal/string etc). > - Medium (ie. Electricity, Water, Gas) > - Function (instant value, min/max/avg value) > - Tariff > - Storage number (ie. actual or past month) > > This means that for field request which is just "<slave-id>" we get N fields > whereas each field has several associated values. I guess that some of values > can be shifted to response metadata. > I need an advice how to handle this 1..N situation. I don't think we have it > in any other place. What driver should do? > > Should it answer with: > - one field and struct with primitives > - one filed and struct of structs with all information > - multiple fields whereas answer for caller specified field will contains > List<String> indicating recognized field names. > > I will also mention that for Wireless M-Bus situation is even more > complicated cause same device can report different set of fields. For example > there is one kind of frame every 15 seconds and another one every 60 seconds. > > Kind regards, > Łukasz >
