smartheim / wakaamanode Goto Github PK

Hi all!

I'm trying to use wakaamaNode library (latest version, freshly downloaded) on my NodeMCU board (based on esp8266, https://docs.zerynth.com/latest/official/board.zerynth.nodemcu_esp32/docs/index.html ).
I use PlatformIO as development tool (latest version, freshly re-installed).

I tried to upload a few simple esp8266 sketches (WiFiScan, WiFiAccesspoint ) and they worked on the same board, so the board is allright.

Next step: I wanted to try the nodemcu_with_led example code ( https://github.com/Openhab-Nodes/wakaamaNode/blob/master/examples/nodemcu_with_led/src/main.cpp ) from wakaamaNode as a beginning. I assumed that it should work without any modifications on my nodemcu board. But when I try to upload it with PlatformIO, I get two compilation errors, see below.

Processing nodemcu (platform: espressif8266; board: nodemcu; framework: arduino)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif8266/nodemcu.html
PLATFORM: Espressif 8266 > NodeMCU 0.9 (ESP-12 Module)
HARDWARE: ESP8266 80MHz 80KB RAM (4MB Flash)
Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF MODES: FINDER(chain) COMPATIBILITY(soft)
Collected 28 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <WakaamaNode> 1.0.2
|-- <ESP8266httpUpdate> 1.3
|   |-- <ESP8266HTTPClient> 1.2
|   |   |-- <ESP8266WiFi> 1.0
|   |   |   |-- <WakaamaNode> 1.0.2
|   |-- <ESP8266WiFi> 1.0
|   |   |-- <WakaamaNode> 1.0.2
|-- <ArduinoOTA> 1.0
|   |-- <ESP8266mDNS> 1.2
|   |   |-- <WakaamaNode> 1.0.2
|   |   |-- <ESP8266WiFi> 1.0
|   |   |   |-- <WakaamaNode> 1.0.2
|   |-- <ESP8266WiFi> 1.0
|   |   |-- <WakaamaNode> 1.0.2
|-- <ESP8266WiFi> 1.0
|   |-- <WakaamaNode> 1.0.2

warning: Ignoring missing SConscript 'extra.py'
File "C:\users\epapzso\.platformio\penv\lib\site-packages\platformio\builder\main.py", line 175, in <module>
Compiling .pioenvs\nodemcu\src\examples\nodemcu_with_led\src\main.cpp.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\cipher.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\cipher_wrap.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\cmac.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\ctr_drbg.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\debug.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\des.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\dhm.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\ecdh.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\ecdsa.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\ecjpake.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\ecp.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\ecp_curves.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\entropy.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\entropy_poll.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\error.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\gcm.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\havege.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\hmac_drbg.c.o
Compiling .pioenvs\nodemcu\src\src\network\mbedtls\library\md.c.o
examples\nodemcu_with_led\src\main.cpp: In function 'void loop()':
examples\nodemcu_with_led\src\main.cpp:123:37: error: no matching function for call to 'LwM2MConnect::process(timeval*)'
int result = context.process(&tv);
^
examples\nodemcu_with_led\src\main.cpp:123:37: note: candidate is:
In file included from examples\nodemcu_with_led\src\main.cpp:16:0:
./src/include/lwm2m/connect.h:48:10: note: void LwM2MConnect::process()
void process();
^
./src/include/lwm2m/connect.h:48:10: note:   candidate expects 0 arguments, 1 provided
examples\nodemcu_with_led\src\main.cpp:129:13: error: 'class LwM2MConnect' has no member named 'watch_and_reconnect'
context.watch_and_reconnect(&tv, 5);
^
*** [.pioenvs\nodemcu\src\examples\nodemcu_with_led\src\main.cpp.o] Error 1
============================================================================================================== [ERROR] Took 5.41 seconds ==============================================================================================================

I've read the documentation too, especially the Connection API, as my problem is related to that in my opinion. I've noticed, that the connect.h and connect.cpp files don't match the Connection API documentation.

According to Connection API docs ( https://openhab-nodes.github.io/wakaamaNode/api/connection-api/#connection-c-api ) the problematical functions should look like

int process(struct timeval* next_event);
and
void watch_and_reconnect(struct timeval* next_event, int reconnectTime);

In the downloaded wakaamaNode library these functions look like:
'void process();'
and
watch_and_reconnect is completely missing from connect.h and connect.cpp, so no wonder I get these compilation error.

Am I doing something wrong, could you please explain?

Thanks for reading, and any help is appreciated! :)

At the moment Wakaama uses preprocessor #ifdefs to enable certain codepaths (server, client, bootstrap server, json), transport properties (dtls) and other features (firmware upgrade).

The compiler and linker are already eliminating dead code, so independent features like firmware upgrade do not need to be #ifdef'ed.

Server, client and bootstrap functionality should be separated more and refactored into own classes with an own state machine each.

Hi, Not an issue but a question how to make it work with a GSM modem like SIM7000 connected to a microcontroll through UART?

Repair travis-ci usage. A cronjob rebuilds every day, make sure the sync works.

Replace the current manually implemented state machine by a compile-time-static state machine library (https://github.com/digint/tinyfsm, MIT license)

Wakaama does a lot of casting. Which is a common C pattern for allowing some kind of generic code. The code does compile with a lot of warnings if -pedantic is enabled and does not compile at all if -ansi is used.

C++ templates will allow a much greater type consistency and type correctness. It is safe to assume that the C++ compiler will create smaller/faster binaries if no type erasure takes place all the time.

Wakaama uses structs a lot. But because C lacks constructors and destructors, a lot of boilerplate code just allocates/inits/deinits/frees those structs in various success and error code paths.

• The use of proper classes with constructors/destructors solves object lifetime tracking.
• The use of unique_ptr, shared_ptr reduces explicit destructor requirements
• The use of string_view (C++ backport, use of C++14 native if available) / string instead of raw const char* pointers make it obvious which string are owned by a structure

See https://github.com/martinmoene/string-view-lite

The freertos support might break in the future because of no automatic checks.
Add a freertos CI example.

The "lwm2m_get_time" function uses some internal 32bit esp buffer, running at 1MHz, so after around 70 minutes the buffer overflows, and the client registration update mechanism stops working, because suddenly "current" time is lower than "previous" time.

One way to fix it: #17

The wakaama library allows to override the alloc/free functions. It is not very fine grained control though, as some allocations are just small strings (that basically never change), some are for various sized transactions, some for huge block1 data.

All general heap usage should disappear.

Receiving

It should not be necessary to allocate heap memory at all for receiving.

Sending

Because the client library is restricted to UDP usage, the network MTU defines the maximum packet size. On top of that, for most packets the final size can be precomputed or determined at build time (C++11/14 constexpr). Transactions should not use the general heap directly.

• The transaction class should get an own new/delete override and two memory strategies should be delivered: A pool allocator with two pools (one huge for request-all, one small for average object requests) and a heap allocator.

Block1

It can be assumed that only one Block1 data packet is on the wire at any time. The block1 class should use the general heap directly.

• The block1 class should get an own new/delete override and two memory strategies should be delivered: A pool allocator with a one slot pool and a heap allocator.

Strings

Strings are used for

• describing the lwm2m device to a server (the lwm2m device object)
• or for connection details (server URI, dtls PSK/x509).

Most of the time string literals will be used, optimize for this use case.
Remove all strdup() calls. The lwm2m server object gets read-only with this change. If an API user wants a modifiable lwm2m server object, he need to roll out his own.

Adding/Removing a server

Instead of passing arguments to an add_server function, that allocates memory to create a new list entry and inserts all those arguments, the user should be requested to create a ServerConnection object that implements a linked list entry interface and is passed to the library.

Necessary allocations and memory management is moved to the users obligations.

Rename the library before releasing it.

Hi,

I'm new to lwm2m.

I was able to compile and upload using the pio command.
Though, I'm not familiar and can't see the Arduino react.

I understand that compile-time definitions are needed, how can we change to source code for it to compile for Arduino?

Even so, I don't see any examples in both Arduino & PlatformIO to select WiFi AP & a server to connect to.

Best Regards,

Nickson

Check documentation, examples, images

Wakaama is following the C pattern of returning a value that might be a success or failure, depending on the specific value or specific error ranges. The library is not consistent in its returns though. Sometimes COAP error codes are returned, sometimes just a -1 or a 0 means an error.

The C++ std::optional (C++11 backport, using C++17 native if available) should be used for returning a value instead. The alternative would be exceptions, but using these in the embedded domain is controversial and the code might be compiled with -fno-exceptions.

See https://github.com/martinmoene/optional-lite