Re: Programming avice needed: parsing bus system
|
Without knowing the formatting of what you are parsing and exactly how it gets distributed it is difficult to comment with any certainty.
Depending on what your dispatcher is doing, you may be able to embed unique data on the outputs that set up your individual modules for what it is looking for or how it is to act. That unique data might?be transmitted to the downstream modules on program boot to "configure" them for their specific tasks, On Thu, Jan 9, 2025 at 8:01?AM Thorsten K?hler via <thorsten.koehler= [email protected]> wrote:
That?s how I?ve implemented it now. Instead of having multiple module parsing the input stream for relevant data, the whole stream now only gets parsed once in a ¡°dispatcher¡±-module. Then the device-specific modules only parse the small piece that is relevant to them. Thanks for that suggestion! I think that reduces the parsing-workload significantly. ? The Dispatcher-module now has 100+ serial output signals that are connected to the corresponding device-module. Any idea how to make that a bit more elegant? ? Also thanks to Matt and Jay for your thoughts! ? Cheers,
Thorsten ? ? I might go with an option C, which is a bit of the two combined. You have a parsing/sorting module (call it the sorting hat) that looks at incoming data and then sorts it based on subsystems, with each subsystem getting a serial output that feeds your B option modules. Instead of parsing all of your devices in one big module you sort it out so that your specific modules are only ever looking at data that is relevant. As presented, your Option B requires every module to startup and evaluate if the data is for them... easy to implement?in SIMPL but a large overhead in SIMPL+ thread creation that?isn't necessary. When data comes in, your sorting hat main module (ideally it can be GATHERed and only use a single thread) handles it and passes it onto a much smaller amount of modules to deal with it.? My $0.02 ? Hi Thorsten, In my drivers I do the parsing in S#.? Then I have individual S+ modules for each device type that is supported by the driver.? So, there might be a thermostat S+ module, a switch S+ module, etc.? An S#? HTTPRequestEventHandler receives messages from devices, parses the messages, and then uses the SignalChangeEvents mechanism in S# to pass the parsed data along to the S+ modules.?? S+ modules will look at the data sent from S# and decide if the event is meant for them.? The decision process is dependent on the driver.? For example, with my Shelly driver each Shelly device has an individual IP address.? The S# parsing code passes along the IP address of the device that sent the message.? Then, for example, a Shelly S+ relay module has the devices IP address as a parameter and can decide if the message originated from a Shelly device matches the IP address parameter on the module.? If there is a match it will act upon the data received.? If there isn't a match it ignores the data. I have used this mechanism over and over with different drivers and it has proved very reliable.? You can look at the Shelly code on my GitHub for an example. The mechanism is especially good for devices that send JSON because you can use Newtonsoft for parsing. Hope this helps Jay On 1/7/2025 7:07 AM, Thorsten K?hler via wrote: Hi, ? I?ve got a bus system called ¡°LCN¡± installed in my house. It?s similar to KNX, but different. ? The bus is connected to the LAN via gateway and I?m able to send and receive commands to the bus to control lighting, relay, etc. and receive status feedback, sensor readings, etc. Communication is via TCP and ASCII. I?ve programmed a parser that receives and parses the bus messages. I?ve done that for a few LCN modules for testing and would like to extend that to all modules and sensors in my house (100+). ? My question is how would I approach this best: - Write a central parsing module (all SIMPL+) that receives all bus messages, parses and separates the messages to all the different modules.
- Write smaller modules based on the specifics of the hardware modules/sensors that only parse the messages dedicated to each module.
? ? ¡°A¡± would lead to one huge module with long and huge parsing flow, but it would be just one module parsing the whole input stream. ¡°B¡± would lead to 100+ modules just waiting for messages addressed to the specific module/sensor and then just parse these. ? I tend to option ¡°B¡± combined with a central module that opens up and handles the TCP connection and receiving and sending the bus communication. ? Any thoughts? ? Thanks, Thorsten
|
BruteForceIsUnderRated