Generic text variable type
-
V_TEXT already exists in version 2.0 : see in the code, or in Doxygen ! :-p
But because of the NRF24L01 limitation, the maximum payload size is 25 bytes!.
This means that V_TEXT messages would be limited to 25 characters, which could be too short in some case.Maybe Mysensors could split longer V_TEXT in multiple messages when sending, then recomposing it when receiving ie:
"Here is a sentence longer than 25 characters that should be splitted."
Could be encoded into messages like this :
1;0;0;47;Here is a sentence lon;1;4 1;0;0;47;ger than 25 characters;2;4 1;0;0;47; that should be splitt;3;4 1;0;0;47;ed.;4;4Then it would be automatically decoded at the arrival.
This way V_TEXT message would be limited to 23*255 characters (more than enought), without writing complicated code from the controllers or in the sketch !
-
Hello,
I'm interesting about sending or receive text through a node for exemple to receive informations to write to a LCD or OLED screen... I've read about V_TEXT type but I don't found any example with text and LCD example or description, or idealy Build example... do you have ideas for How to do this ?
Thanks
(sorry, my engliish's very bad, I know... oups !)@medline2c there are a few examples on the forum scrolling text
-
V_TEXT already exists in version 2.0 : see in the code, or in Doxygen ! :-p
But because of the NRF24L01 limitation, the maximum payload size is 25 bytes!.
This means that V_TEXT messages would be limited to 25 characters, which could be too short in some case.Maybe Mysensors could split longer V_TEXT in multiple messages when sending, then recomposing it when receiving ie:
"Here is a sentence longer than 25 characters that should be splitted."
Could be encoded into messages like this :
1;0;0;47;Here is a sentence lon;1;4 1;0;0;47;ger than 25 characters;2;4 1;0;0;47; that should be splitt;3;4 1;0;0;47;ed.;4;4Then it would be automatically decoded at the arrival.
This way V_TEXT message would be limited to 23*255 characters (more than enought), without writing complicated code from the controllers or in the sketch !
-
-
V_TEXT already exists in version 2.0 : see in the code, or in Doxygen ! :-p
But because of the NRF24L01 limitation, the maximum payload size is 25 bytes!.
This means that V_TEXT messages would be limited to 25 characters, which could be too short in some case.Maybe Mysensors could split longer V_TEXT in multiple messages when sending, then recomposing it when receiving ie:
"Here is a sentence longer than 25 characters that should be splitted."
Could be encoded into messages like this :
1;0;0;47;Here is a sentence lon;1;4 1;0;0;47;ger than 25 characters;2;4 1;0;0;47; that should be splitt;3;4 1;0;0;47;ed.;4;4Then it would be automatically decoded at the arrival.
This way V_TEXT message would be limited to 23*255 characters (more than enought), without writing complicated code from the controllers or in the sketch !
