gpb01:
Mah ... allora potresti ogni volta trasferire due bytes ... nel primo byte metti un numero che identifica il dato e nel secondo byte metti il dato vero e proprio. Se poi vuoi aumentare la sicurezza di bytes ne trasmetti tre, l'identificativo, il dato, il checksum (che, per così poco, può benissimo essere un XOR dei valori preceventi) 
Concordo, il problema è più semplice di quanto l'OP abbia temuto, secondo me gli basta fare qualche test, come dico io, "a secco" (ossia sketch che fanno per ora SOLO quello), poi quando funziona li "inscatola" in apposite funzioni (es. "sendByte(byte valore)" e "readByte(byte valore)"), e si porta queste nel suo codice.
Visto che progetta in pratica un "protocollino" e che il dato non va oltre 127, io farei per maggior sicurezza un pacchetto fatto così:
0xFF (start byte, che non si potrà mai confondere con i dati)
(byte che identifica la variabile, es. 0x01 per la prima, 0x02 per la seconda, ecc.)
(il valore da trasmettere)
(xor del valore ossia "val^0x7F" per evitare di avere il bit alto settato)
0xFE (end byte)
(certo, il controllo senza un handshake permetterebbe al ricevente solamente di identificare dati errati, non di correggerli).
Tra l'altro potrebbe anche "impacchettare" più di un valore da trasmettere ripetendo i tre byte centrali, fino a trovare lo stop 0xFE:
0xFF 0xFE (end byte)
gpb01:
Ma non puoi usare la stessa seriale del WiFi ... devi ovviamente usare un'altra seriale dedicata alla cosa.
Una mia curiosità, per mia ignoranza: mi spieghi meglio questa cosa, ossia per le NodeMCU non si può usare la seriale per comunicare ossia non si possono usare i pin RX e TX?
