CoAP set limited to 15 characters

97Cweb commented 2 months ago

Board

ESP32-C6 to ESP32-C6

Device Description

ESP32-C6 Waveshare

Hardware Configuration

no

Version

latest development Release Candidate (RC-X)

IDE Name

Arduino IDE

Operating System

Windows 11

Flash frequency

80MHz

PSRAM enabled

yes

Upload speed

921600

Description

Trying to set "coap set 0123456789ABCDE" works but "coap set 0123456789ABCDEF" fails with Error 7: InvalidArgs

Sketch

/*
 * OpenThread.begin(false) will not automatically start a node in a Thread Network
 * The user will need to start it manually using the OpenThread CLI commands
 * Use the Serial Monitor to interact with the OpenThread CLI
 *
 * Type 'help' for a list of commands.
 * Documentation: https://openthread.io/reference/cli/commands
 *
 */

#include "OThreadCLI.h"

void setup() {
  Serial.begin(115200);
  OThreadCLI.begin(false);  // No AutoStart - fresh start
  Serial.println("OpenThread CLI started - type 'help' for a list of commands.");
  OThreadCLI.startConsole(Serial);
}

void loop() {}

Debug Message

ot> coap set "00000000000000
Done

ot> coap set 0123456789ABCDE
Done

ot> coap set 0123456789ABCDEF
Error 7: InvalidArgs

ot>

Other Steps to Reproduce

Follow the below cli commands to cause the error

coap stop thread stop ifconfig down dataset clear dataset channel 24 dataset networkkey 00112233445566778899aabbccddeeff dataset commit active ifconfig up thread start coap start coap resource json coap set 0123456789ABCDE coap set 0123456789ABCDEF

I have checked existing issues, online documentation and the Troubleshooting Guide

[X] I confirm I have checked existing issues, online documentation and Troubleshooting guide.

lbernstone commented 2 months ago

This seems very likely a limitation of the source, seeing as how it is trapped and has a useful error. You will be much better served by asking upstream at https://github.com/openthread/openthread/issues

97Cweb commented 2 months ago

This seems very likely a limitation of the source, seeing as how it is trapped and has a useful error. You will be much better served by asking upstream at https://github.com/openthread/openthread/issues

Thank you for the direction, I am crosslinking the post here so it can be tracked too.

https://github.com/openthread/openthread/issues/10712

Hopefully this gets resolved soon

VojtechBartoska commented 2 months ago

Any ideas regarding this @SuGlider?

97Cweb commented 2 months ago

Discussion branched to another thread on their end here is their link, https://github.com/orgs/openthread/discussions/10713 You might be able to make a variable overwrite this? They also say CLI is not meant for actual use though, so not sure...

97Cweb commented 2 months ago

I cannot find the point to overwrite the buffersize. Can you point me in the right direction?

lbernstone commented 2 months ago

This code is compiled into the sdk libraries. You would need to compile your own libraries and modify the code in the esp-idf/openthread with that larger buffer. In order words, this is not a simple one line change.

97Cweb commented 2 months ago

Aw shoot. That is beyond me at least for now. Thank you for telling me this so I dont have to pull more hair out trying to find the line. Hopefully something is found soon to make it more flexible.

SuGlider commented 1 month ago

OpenThread CLI sets maximum message size to 16 bytes and URI to 32 bytes. It can't be changed, except by rebuilding the library with new values. This is explained here: https://github.com/orgs/openthread/discussions/10713#discussioncomment-10654886

There are 2 possible solutions for sending a message larger than 15 bytes (last byte is always a '\0')

1) spliting the original message into a few smaller messages. Let say that the application needs to send 100 bytes. It is possible to send 10 messages with a valid payload of 10 bytes each. The message frame may have a format such as: | msg# :: 1 byte | total number of messages for the whole payload :: 1 byte | len :: 1 byte | payload :: len bytes | CRC8 :: 1 byte | Total Frame Length = 1 + 1 + 1 + 11(max) + 1 = 15 bytes maximum, given that the payload should not exceed 11 bytes. In the case of sending 100 bytes, it would be necessary to break it into 10 payloads of 10 bytes each. Put the frame together and send each one, waiting for the ACK confirming that the other side has received it. Example:

  | 0x00 | 0x0A | 0x0A | payload_01 | CRC-8 calculation |
| 0x02 | 0x0A | 0x0A | payload_02 | CRC-8 calculation |
....
| 0x09 | 0x0A | 0x0A | payload_10 | CRC-8 calculation |

2) Another way to deal with OpentThread/CoAP + Arduino would be by using OThread CoAP native API, instead o f using CLI. This could be done using the CLI CoAP example from https://github.com/openthread/openthread/blob/d7810fa04d46f77eb5b78af81ad0bdb59bfcd436/src/cli/cli_coap.cpp

SuGlider commented 1 month ago

97Cweb commented 1 month ago

Thanks for the idea of the binary options. I'll look more into that, I do think I'll need more info, but we'll see. I do hope that one day it is not a baked in constraint though, as I can put much larger values, but cannot get them back

SuGlider commented 1 month ago

Thanks for the idea of the binary options. I'll look more into that, I do think I'll need more info, but we'll see. I do hope that one day it is not a baked in constraint though, as I can put much larger values, but cannot get them back

Please take into consideration that Thread isn't a protocol created for fast/large data communication.

Thread uses IEEE 802.15.4 2006 with 127-byte packets and an underlying data rate of 250 kbps. The Thread packet format results in a 63-byte payload. For payloads above 63 bytes, the Thread stack fragments using 6lowpan.

63 bytes application payload per single packet isn't a lot of space, considering a JSON format data information.

SuGlider commented 1 month ago

It may be interesting considering other protocols, such as WiFi Mesh or Mesh BLE.

ESP-WIFI-MESH is a networking protocol built atop the Wi-Fi protocol. ESP-WIFI-MESH allows numerous devices (henceforth referred to as nodes) spread over a large physical area (both indoors and outdoors) to be interconnected under a single WLAN (Wireless Local-Area Network). ESP-WIFI-MESH is self-organizing and self-healing meaning the network can be built and maintained autonomously.

It needs a WiFi Router... https://docs.espressif.com/projects/esp-idf/en/v5.3.1/esp32/api-guides/esp-wifi-mesh.html

Bluetooth® mesh networking enables many-to-many (m:m) device communications and is optimized for creating large-scale device networks.

Devices may relay data to other devices not in direct radio range of the originating device. In this way, mesh networks can span very large physical areas and contain large numbers of devices. It is ideally suited for building automation, sensor networks, and other IoT solutions where tens, hundreds, or thousands of devices need to reliably and securely communicate with one another.

Bluetooth mesh is not a wireless communications technology, but a networking technology. This technology is dependent upon Bluetooth Low Energy (BLE) - a wireless communications protocol stack.

No external router or coordinator is necessary https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/esp-ble-mesh/ble-mesh-index.html

97Cweb commented 1 month ago

Thank you for the idea of bluetooth mesh. I'll look into it more, as that seems to be similar to what I want to achieve

On Wed, Oct 9, 2024 at 8:24 AM Rodrigo Garcia @.***> wrote:

It may be interesting considering other protocols, such as WiFi Mesh or Mesh BLE.

ESP-WIFI-MESH is a networking protocol built atop the Wi-Fi protocol. ESP-WIFI-MESH allows numerous devices (henceforth referred to as nodes) spread over a large physical area (both indoors and outdoors) to be interconnected under a single WLAN (Wireless Local-Area Network). ESP-WIFI-MESH is self-organizing and self-healing meaning the network can be built and maintained autonomously. It needs a WiFi Router...

https://docs.espressif.com/projects/esp-idf/en/v5.3.1/esp32/api-guides/esp-wifi-mesh.html

Bluetooth® mesh networking enables many-to-many (m:m) device communications and is optimized for creating large-scale device networks.

Devices may relay data to other devices not in direct radio range of the originating device. In this way, mesh networks can span very large physical areas and contain large numbers of devices. It is ideally suited for building automation, sensor networks, and other IoT solutions where tens, hundreds, or thousands of devices need to reliably and securely communicate with one another.

Bluetooth mesh is not a wireless communications technology, but a networking technology. This technology is dependent upon Bluetooth Low Energy (BLE) - a wireless communications protocol stack. No external router or coordinator is necessary

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/esp-ble-mesh/ble-mesh-index.html

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/10350#issuecomment-2402173298, or unsubscribe https://github.com/notifications/unsubscribe-auth/APFMQOYQMKMCWFTOMIWRT5LZ2UN7JAVCNFSM6AAAAABOHMXTB2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBSGE3TGMRZHA . You are receiving this because you were mentioned.Message ID: @.***>

-- Collin Barker

SuGlider commented 3 weeks ago

Ok. I'll close this issue. Feel free to open it again, if necessary.

espressif / arduino-esp32