Hi Chris, thanks for bringing that up. I think it’s a bit similar than our "pseudo symbolic addressing" idea for (old) S7 Driver. So I am strongly for an additional (query-)parameter for the filenames.
Julian Am 22.11.19, 14:20 schrieb "Christofer Dutz" <[email protected]>: Hi, while working on the KNX and the BACnet support I did come across, that usually you only get sensible and usable data, if we enrich this with data from some other source. For BACnet this is a so-called EDE file and for KNX I had to add a parser for the ETS5 knxproj files. For KNX for example the protocol provides raw byte data which can only sensibly be decoded if you know the type. You can only get the type from the group-address a piece of data is sent to. How to decode the group address is also controlled externally in thr knxproj file. So if that says, this house is using 3-level group addresses, I know how to decode the two bytes of the destination address. Then I can use this to lookup the type and can use that information to decode the payload. In SteamPipes I used a so-called Processor to enrich the raw data-stream. But when using this sort of thing in a PLC4X driver, how do we do this? Should I add multiple optional parameters: * knxproj-file: to get the full enrichment * group-address-encoding-level (1 | 2 | 3): to at least be able to decode the destination addresses I think it doesn’t make sense to generally add a layer of abstraction to these drivers that sort of wrap the driver … what do you think? Chris
