Hello @alvarolb
We were very excited to see the new IOTMP repositories on Thinger’s GitHub.
In an initial analysis, we noticed a significant code refactoring and a different approach to DEBUG messages.
However, we are curious to know if, in addition to the code refactoring, there were any improvements or new features?
I remember that some improvement in data loading was planned (Data Traffic Analysis - GSM and Thinger - #5 by alvarolb ).
Nice to know you got better results now! Just curious, what are the changes you did to the modem?
The data transmission shown on Thinger is just the size of the effective payload, so, it is normal that the operator size is greater taking into account the TCP/IP plus SSL stack. However, the ratio you show (94%-6%) seems quite unrealistic even with the stack overhead. I am not sure how a mobile operator computes the traffic, but it could be charging also the underlying radio protocols?. A good test could be to let the device connected for 12 hours without any sending (just the keep alives, which are 2 bytes up&down every minute).
Regarding the IOTMP protocol, it will improve a little bit the bandwidth, but taking into account that your payload is only 6% of the total traffic, it will not be noticeable. However, it allows configuring the keep alive timeout, so you can save some traffic there setting a higher value, i.e., 5 min. Hope we can pre-release an Arduino library before summer.
Regarding a “Sleeping State” for devices that sleep after sending a message, is there any functionality that needs to be developed in IOTMP or are these improvements more related to functionalities in the Thinger Server code?
opened 03:12PM - 04 Feb 23 UTC
enhancement
Implement “Sleeping” state for devices in “Device List” screen (May need to adap… t Thinger-ARDUINO & IOMTP & PSON librarys to get this functionality)
Justification: It is very common for us to create routines for devices to go into Sleep mode to save battery power or save on data traffic.
The problem is that if we put the device to sleep, the Thinger Server points out that the device is disconnected.
But the device may be disconnected for various reasons that prevent it from working properly. In sleep mode, the device is working correctly, and will wake up again at a defined future time (10, 20, 30 minutes…), to reestablish its connection with the Thinger Server to send or receive data… sleep then…
It would be interesting if the sleep mode could be set by the device (via a function from the Arduino-Library library) or by the Thinger Server, in the same way that today we can set Sampling Interval vs Stream by Device to write to the Bucket.
I imagined something like the highlighting of the name and the time left for the device to wake up:
If this functionality is available, I can use it on my device that uses GSM(M2M) internet connection to save data. Recently, I saw that maintaining the device’s connection with the Thinger Server, using the GSM(M2M) internet, consumes a lot of data with download. And my GSM(M2M) plan only has 20 MBs per month. In addition, instead of appearing disconnected, it would be informed that the device is sleeping and the time until it wakes up again, which is very relevant information to know that everything is working fine.
With the WiFi 6 protocol, it became feasible to develop devices that send data to the router and then go to sleep without losing the initial connection, thus saving energy. Could IOTMP also contribute to this flow to save energy on battery-powered devices?
Regarding PSON, perhaps a possible improvement would be to enable some approach to reduce the overhead of the key strings, since, in many cases, this is what consumes the most in the payload. Perhaps some approach involving IOTMP + Server that would allow the use of some “key compressor” or some type of translator (equivalence table).Possibility to create aliases for bucket variable names · Issue #58 · thinger-io/thinger-server · GitHub µON [muon] library repository presents very interesting information about the overhead of key strings in the total payload size.Muon - Google Slides
Thank you very much for this further evolution in the Thinger ecosystem.
