search

letscontrolit / ESPEasy

Easy MultiSensor device based on ESP8266/ESP32
http://www.espeasy.com
Other
3.28k stars 2.22k forks source link

[Enhancement] LoraTTN and future P2P protocol structure #2661

Open enesbcs opened 5 years ago

enesbcs commented 5 years ago

@TD-er :

I am now looking into the TTN part of sending data. (LoRaWAN/Things network) And I was wondering what should we do with plugin IDs? Right now it is limited to 8 bits and I'm not even sure all places where it is being used is having uint8_t as type, so we may also run into issues when passing 127.

Should we go for 16 bit?

Absolutely. Originally i choosed "word" type as i started programming with TurboPascal and a word means a two-byte long numeric variable that can hold value between 0..65535 to me at least. :) As you can see i am not an expert C programmer... Now i changed it to uint16_t plugin_id; as the ESP32 has other thoughts about "word" datatype meaning.

And are we going to run into other limits like these? (e.g. unit numbers)

Unit number is a really interesting question as i've never heard anybody running more than 255 ESPEasy-RPIEasy-ArduinoEasy on the same network, but it can happen. Personally i do not think that it is common, but we can ask the users instead. :)

TD-er commented 5 years ago

So 16 bit it should become. At least in the ESPEasy addressing a plugin. That would already be a huge refactoring process and will perhaps also break current p2p implementation. So I maybe want to 'reserve' bit nr 7 (128 - 255) to be able to toggle between 1 byte and 2 byte representation. Or do you already have plugins in that range?

enesbcs commented 5 years ago

I have 7 plugin in range 128-255 but i can renumber it. Perhaps the C013 P2P V1 structures may be untouched for backward compatibility with R120, and the P2P V2 has to support 16 bit plugin number.

TD-er commented 5 years ago

The older versions don't support the (not yet existing) plugins anyway. So we have still about 40 plugins to go until we really have to make the decision what to do with the most significant bit of the plugin ID. One thing we really should do is make sure the p2p messages will be discarded if not supported. Or we simply use a new message ID for the plugin ID's > 127.

About the node unit numbers. If the support for LoRa and ESPnow really will be accepted the way I hope it will be, then we may run out of unit numbers. I already know of people having > 200 ESP nodes active although I don't know if these are all in the same network. Also the current implementation of ESPeasy p2p is very inefficient when it comes to large number of units. So that may be also a thing to solve when working on p2p v2.

To ease the transition, we could already use a define for the unit numbers and plugin ID. Not sure if the compiler can apply strict checks on a defined type. Would be nice if we can let the compiler do the checking for us.

tonhuisman commented 1 year ago

This issue is no longer relevant, or at least implemented differently, so can probably be closed.

TD-er commented 1 year ago

Nope, is still an issue