knxlib & physical address based messages - Printable Version +- Logic Machine Forum (https://forum.logicmachine.net) +-- Forum: LogicMachine eco-system (https://forum.logicmachine.net/forumdisplay.php?fid=1) +--- Forum: Scripting (https://forum.logicmachine.net/forumdisplay.php?fid=8) +--- Thread: knxlib & physical address based messages (/showthread.php?tid=3667) |
knxlib & physical address based messages - Fred - 06.11.2021 Hello, Is the knxlib full feature set documented anywhere? I find threads and information here and there but nothing centralized. Maybe an idea for the documentation pinned link above I am looking to support physical address messages level, f.e. to write to a device memory, that sort of things. Thanks for any info or pointer! RE: knxlib & physical address based messages - admin - 08.11.2021 You can run log(buslib) to get a list of functions in this library. These functions are not fully documented because they are mostly used internally. Can you describe your use case for accessing KNX device memory directly? RE: knxlib & physical address based messages - Fred - 29.08.2022 Generically, I think having the ability from LogicMachine to send a telegram addressed to a physical address is valuable. It could be a basic implementation, i.e. send and receive of raw data, without support for all the KNX features - building/decoding telegrams should be left to user. Tapko for example provides a module (SIM-KNX) that offers this: a KNX stack for group addresses and objects, along with the capability to send/receive raw telegrams. My use case is to be able to deploy a LM and an array of identical devices on a simple single KNX line without requiring ETS. If every device has a predefined unique physical address, then I do not need the group address layer (which in this case just replicates the physical address layer: every device has its own unique set of group addresses). For example, 25 displays connected to a LM displaying messages sent by the LM. Granted, this is a slightly heretical use of KNX, but having both options as proposed above provides flexibility in using LogicMachine for "custom" use cases without formally embracing them |