Restructure Packet

[kipe]

As discussed in #14.

@kipe wrote:

Might need to change the Packet.data to Packet.message and create a new Packet.data to reflect the actual, documented data? This would be a very major change, which I'm a bit reluctant to do. On the other hand, it would be fairly easy to do at this point and way more logical (for example, Packet.optional_data, Packet.sender etc already point to the correct data)...

@romor wrote:

Packet could then only consist of Packet.message while data, rorg, status,... could all be properties just accessing the corresponding entry in Packet.message. Alternatively it could be the other way round such that Packet holds data, rorg, status, ... and Packet.message could just be generated from the other variables. The seconds looks more reasonable to me.

Not sure which way this should be handled, as it's largely dependent on whether we're sending or receiving the message...

[TheMeaningfulEngineer]

Packet.data doesn't reflect the data prom the documentation?
I did behave that way so far with the BS4 packets I tested

[kipe]

Well, it does and it doesn't. Packet.data includes the whole data, including stuff like RORG, Sender ID etc, which are not included in EEP.
The idea of this issue is to separate the message to Packet.data, Packet.optional_data, Packet.sender, all of which correspond to the logical parts of the documentation.

[stv0g]

I am trying to understand how we could decouple Packet.build() and Packet.parse_msg() as they are different for ESP2 (see #72). I guess this would be also related to this issue..