Hi ikegam,
I am not sure, that it helps to increase the query limit counter to solve the problem (Note that I did not hat a close look at your code).
We once had probably the same issue. When we restarted the Backend we lost thousands of datapoints within the first hour after restart. The reason was hard to detect, because our logfile looks good, except of a few Typecast-Exceptions.
In our case the problem was, that every time a Typecast-Exception has been occured, all measuring points that are also transmitted with this exception are lost. It turns out that the OpenEMS backend collects more than 1000 measuring points and transmits them to the database in one piece. So everytime we got a Typecast-Exception we lost all this 1000+ measuring points. On a typical backend startup we saw maybe 50 Typecast-Exception in the backend log. But in the end, this has lead to >50.000 lost measuring points.
We solved this, by fixing our code and updating all edges. Still we have a very
few “unsolvable” Typecast-Exceptions. But for them we added some hardcoded, predefined typecast handler.
Now, any new seen typecast exception sets the alarm bells ringing. And we respond with immediate action. Also we try to improve our internal development process to find this kind of problem in the review phase already.
So I would suggest to fix all Typecast-Exceptions as early as possible. In the end this may help you more, than fixing the querylimit counter mechanism.