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
