Ray and Shawn
Thank you for the answers.
I have realized in meantime the options are calculated automatically if I rewrite the MAX_PROGRAMDATA parameter. Thanks for the clarification of the 2 starting bytes.
The eeprom MAC address is quite new for me. I think there should be a “default MAC” in the firmware, because it works without this eeprom populated, but I only tried with one instance.
May be you have analysed using flash memory instead of SD, because SD is not a long term memory solution in my mind.
WE have started a cloud based experiment to eliminate the dynamic IP, and port forwarding features.
My idea is to set up a data puffer between the UI requests and the firmware responses.
The firmware regularly polls the cloud server sending the answer to “Get All = /ja?..” content to the server. The server stores the results.
Each day logs also stored on the server.
If there is a request from the UI what can’t be handled based on the “polled data” the server would sending to the firmware as an UI request.
The firmware will make the answer and changes what is requested, like present style.
The server have to keep the UI in controlled waiting position till the time while the firmware will poll next time the server and can serve the request.
The server will know when the next poll is expected, so the UI can be informed the user how long have to wait for the action.
At the moment we have the server side what communicate through the API commands to the firmware and stores the answers.
Next we should make the polling function in the firmware.
Some new API function will be applied to handle the sensor’s data and the cloud operation.
Also the appropriate UI changes should be done, what still the weakest point.
I would like to see your opinion about the idea.