I have some ideas on how to get a lower CPU consumption per Device.
This ticket is a placeholder for trying out many ideas 😄
Some of them can be mapped to the EoN too
How do we check if the sending has been successfully completed? I bet you want to introduce some asynchronously task? I cannot think of another simpler solution?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
MQTT.Publisher.xDone only comes true after a PUBACK has been received back from the server. This could last seconds depending on the server load and network load.
So the Entry Action should do all the one time setup stuff, and then the Cyclic Action should call Publisher() until .xDone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This requires a change in the code as the sending of a message now happens 'atomically' in a single method.
This now has got to be split into some setup and feedback part.
Fortunately the FB has been built to accommodate your suggested strategy.
So, the setup is done in a state Entry, and the feedback is checked during the continuous part of the state.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Publishing of Certificates / DATA is now done in a "non-blocking" fashion.
However, payload encoding and decoding is still done in a REPEAT UNTIL LOOP during the Entry Step of each publishing state.
Though this technically is equal to a blocking statement, Encoding / Decoding is most likely always finished in 1 scan since Google Protobuf encoding/decoding is finished very quickly.
If in a future release or during "in the wild" testing pahse this seems to be an issue's, we will separate this further but for now it should suffice.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Offcourse we have seen many other points for revision.
However having a complete v2.0 has a higher prio then optimisation.
I'll close this ticket for now. A new optimisation round will be a new ticket (e.g profiler)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Implementation of FB_EoNTopicProvider
Implementation of FB_DeviceTopicProvider
Which helps to significantly lower the WCONCAT function usage count as string manipulation is known to be CPU consumption prone.
currently, publishing is done in a repeat until loop. this should exit the loop if still busy, rather than blocking until complete.
How do we check if the sending has been successfully completed? I bet you want to introduce some asynchronously task? I cannot think of another simpler solution?
MQTT.Publisher.xDone only comes true after a PUBACK has been received back from the server. This could last seconds depending on the server load and network load.
So the Entry Action should do all the one time setup stuff, and then the Cyclic Action should call Publisher() until .xDone.
This requires a change in the code as the sending of a message now happens 'atomically' in a single method.
This now has got to be split into some setup and feedback part.
Fortunately the FB has been built to accommodate your suggested strategy.
So, the setup is done in a state Entry, and the feedback is checked during the continuous part of the state.
Publishing of Certificates / DATA is now done in a "non-blocking" fashion.
However, payload encoding and decoding is still done in a REPEAT UNTIL LOOP during the Entry Step of each publishing state.
Though this technically is equal to a blocking statement, Encoding / Decoding is most likely always finished in 1 scan since Google Protobuf encoding/decoding is finished very quickly.
If in a future release or during "in the wild" testing pahse this seems to be an issue's, we will separate this further but for now it should suffice.
Offcourse we have seen many other points for revision.
However having a complete v2.0 has a higher prio then optimisation.
I'll close this ticket for now. A new optimisation round will be a new ticket (e.g profiler)