RpiEasy didn't work with ESPEasy P2P Network

[crazybanane]

Hello,

I updated my ESPs and now I can't get any connection to RPIEasy via P2P Network. The devices that are send over P2P won't shown up.
But RPIEasy see ESPs in MainPage please fix to latest P2P part.

THX have a nice day.

[crazybanane]

Summary of the Problem and Solution for "P2P invalid type: 35"
Problem Description:
The rpieasy log shows repetitive error messages like 20:08:40 P2P invalid type: 35 and Unknown command: b'\xff\x01\x94\xa9\x90\x97\xf98\xc0\xa8\ny\x01\xfdRBrunnen'. This indicates that the rpieasy Python controller is receiving UDP packets from an ESP-based device (ESPEasy) on IP 192.168.10.121, but it cannot correctly interpret the packet type, specifically reporting type 35. As a result, rpieasy then attempts to parse the entire malformed packet as an "unknown command".

Root Cause Analysis:
The core issue lies in a mismatch between the P2P protocol version/structure used by the sending ESPEasy device and the one expected by the rpieasy Python controller.

ESPEasy C++ Code Insights: The provided C++ code for ESPEasy (e.g., C013_SendUDPTaskData and C013_Receive) shows that it uses C013_SensorDataStruct and C013_SensorInfoStruct to prepare and send UDP packets. Crucially, newer ESPEasy builds (like Build 20460 and later, as indicated by dataReply.sourceNodeBuild >= 20460) have added new fields to these data structures (e.g., deviceNumber, sensorType, timestamp_sec, timestamp_frac).

rpieasy Python Code Deficiencies: The data_packet.decode() method in the rpieasy Python script (rpieasy_p2p.py) is designed to interpret specific packet types (1, 3, 5). When it receives a packet where the second byte (the pkgtype field) is 35, it falls into an else block, logs "invalid type: 35", and sets pkgtype to 0. This 0 then triggers the "unknown command" handler.

The "35" Mystery: The value 35 is likely not a new, distinct packet type. Instead, it's highly probable that due to the added fields in the newer ESPEasy structs, the byte corresponding to the actual packet type (which should be 3 or 5 for sensor info/data) is being misaligned or combined with an adjacent byte (e.g., sensorType or deviceNumber) when interpreted by the older Python struct.unpack_from format string. This leads to the Python code reading 35 where it should read 3 or 5, or a different byte is now in the position it expects the type.

Solution:

The solution requires updating the rpieasy Python controller's packet decoding logic to match the current P2P protocol structure used by your ESPEasy firmware.

Identify Exact ESPEasy P2P Structure:

Crucially, obtain the header files (specifically C013_p2p_SensorDataStruct.h and C013_p2p_SensorInfoStruct.h) from the exact ESPEasy firmware version running on your 192.168.10.121 device. These files define the precise byte layout of the UDP packets. Pay close attention to the order, size, and data types of all member variables (uint8_t, uint16_t, float, etc.).

Modify data_packet.decode() in rpieasy_p2p.py:

Adjust the struct.unpack_from calls within the decode method to accurately parse the new packet formats for pkgtype 3 (sensor info) and pkgtype 5 (sensor data).

Based on the C++ headers, you will need to:

Update the format strings (e.g., <8B 4f might need to become <B B B B B B H 4f I H H or similar, depending on the exact C++ struct layout) to reflect the added fields and their byte alignment.

Adjust the indices used to access the unpacked cdata tuple, as the position of existing fields might have shifted due to new fields being inserted.

Add logic to correctly extract values from potentially combined fields (e.g., if deviceNumber and sensorType are packed into a uint16_t).

Ensure the expected buffer length check (if len(self.buffer) >= ...) is updated to match the new, larger packet sizes.

By synchronizing the Python decoder with the actual C++ packet structure, rpieasy will correctly recognize and process the incoming P2P messages, eliminating the "invalid type: 35" and "unknown command" errors.

I don't know how to handle it, if it helps then pls update Thanks

[CionB]

The same problem. Is the project being supported or abandoned?