Question: Is Service Characteristic limited to one-dimensional values only? For instance, variables like Temperature, Humidity, Speed, or True/False fall into this category. However, what if I need to transmit an array of variables and then decode this data structure on the receiving client side? Is JSON a recommended approach for this purpose? what about structure decoding on the client side? While I grasp the advantages of conserving battery life by employing one-dimensional values at low reporting rates, potentially extending battery longevity to a year or more, I can't help but feel that this approach is rather constraining. It appears to be well-suited for only a specific range of solutions. Are there alternative approaches that could be explored to address a broader set of solutions?
To provide further clarity on my question, I'm wondering if it's advisable to opt for a custom service that allows sending multiple variables individually, rather than combining the data together to conserve battery power. In scenarios where preserving battery life is crucial, would the approach of using a custom service for each variable be more effective than consolidating the data? Under certain circumstances, there might arise situations where multiple variables need to be transmitted simultaneously, while at other times single variable transmission works fine.
@@yaghiyahbrenner8902 Of course, that depends a bit on the use cases. Actually, you can store whatever you want in a characteristic: an array, a struct, or a string. Thera are always transferred bytes. The recipient can always store this in an appropriate data structure. If only data is to be transmitted, it may be better to store this in an array or as a string in one characteristic, for example. If, for example, different settings are to be made, such as with a battery management system, it probably makes more sense to define a separate characteristic for each setting, than always handling a complete array or parse a string.
@@wsniot Thanks for getting back to me. This makes sense I guess I have somewhat answered my own question based on your answer it's really interesting to know what "data exchange architecture" exists but this is probably specific to the design intent. Thanks for covering this topic.
