Connection: WebSocket
Reason: Avoid using SLScripting as much since user is running hundreds of these elements in one DMA.
My goal is to avoid running a QAction every time there is unnecessary data coming in from the device. So for example, the data comes in the following format, each one represents a full JSON object sent by the device 1 by 1:
- {"msgType":"objectState","configurations":[...]}
- {"msgType":"fmmStatus","statuses":[...]}
- {"msgType":"permissionMsg","permissions":[...]}
- {"msgType":"activeAlarmStatus","statuses":[...]}
To avoid parsing objects 2,3, and 4, I composed the Response with fixed parameters and next parameters to match and fill. Then according to the value of the msgType, I add conditions to the QAction:
This implementation works fine but the problem is that when the data is big, the device sends the JSON data in chunks:
- {"msgType":"objectState","configurations":[...........
- ..................................................................................
- .................................................................................
- ...............]}
- {"msgType":"fmmStatus","statuses":[...]}
The first part comes in and it qualifies to run in the QAction, but the rest of the data doesn't qualify for match and fill so the QAction will never run. Parts 2,3, and 4 need to be saved to be parsed at the end.
Ideally, it would make sense to have a pair with multiple responses, if the first response doesn't match, then have a second one with only a next param and process that data. But since this is a web socket connection I can only have one response (at least that is my understanding).
Please and thank you for any of your ideas!
Hi Miguel, what you're trying to do is probably not possible, but maybe there is another approach.
Some time ago I worked on a smart-serial driver that was receiving 1000+ messages/s (Netflow). Every message was triggering a QAction that simply stores the data in a queue, and then immediately exits.
A protocol timer triggered the same QAction every x seconds to process all data that is available in the queue. This way we were able to process the incoming data in a much more efficient way. For instance, we were able to aggregate the data, ignore duplicate entries and set many parameters at once instead of doing sets after every message. Depending on the nature of the data that the driver needs to process, this could already help solving the performance issue.