Error: 'Net' in namespace 'ustd' does not name a type ?

[nohkumado]

Hello,
ran into another problem.... i just copied over the sample code (from https://github.com/muwerk/munet), and there this line:
#define LED_BUILTIN 2 //had t o add this since ESP don't have a predefined LED_BUILTIN
ustd::Net net(LED_BUILTIN);

gives the following error:
Tankwaechter:24:7: error: 'Net' in namespace 'ustd' does not name a type
ustd::Net net(LED_BUILTIN);
^
/home/bboett/Arduino/Tankwaechter/Tankwaechter.ino: In function 'void setup()':
Tankwaechter:53:5: error: 'net' was not declared in this scope
net.begin(&sched); // connect to WLAN and sync NTP time, credentials read from SPIFFS, (s.b.)
^
Mehrere Bibliotheken wurden für "WiFi.h" gefunden
Benutzt: /home/bboett/.arduino15/packages/esp32/hardware/esp32/1.0.4-rc1/libraries/WiFi
Nicht benutzt: /home/bboett/Downloads/arduino-1.8.12-linux64/arduino-1.8.12/libraries/WiFi
exit status 1
'Net' in namespace 'ustd' does not name a type

how can i solve this one?

BTW in the sample code it would be nice to add the values for ESP vars in line 1!

[domschl]

This is probably caused by using Arduino-GUI, which was not well suited to resolve library-dependencies for complex projects at the time this project was created. Basically every single library you install could mess up other libraries.

There seems to be an update for Arduino-GUI's library dependency-management, which should enable library-dependency-management, and I will look at that.

In the mean time, a work-around for Arduino-GUI is to use full paths for the includes, e.g.:

#include "your-home/Documents/Arduino/libraries/munet/Net.h"

I've rechecked, and I also needed to provide a full #include path for Arduino/libraries/Muwerk_ustd_library/queue.h.

The best solution is to use platformio for muwerk.

I am closing this here, since it's not an issue for the ustd-project.

Generally, you are right, the examples need more and better documentation. This is planned, once the mupplet project is ready for publication.

[nohkumado]

ok, thanks!
now i got the example compiling! beware of the casing in your answer, Net.h and net.h are not the same (at least on my platform)

well platformio, i looked into it, that's a completely different IDE... and what's more it runs on something where the first word of the name makes me immensely uncomfortable ;)

sorry to continue to boither you, but i am still missing the steps afterward?
if i get this correctly from the mgtt.h file, after instantiating the Mqtt object, i have to call begin?
and afterwards i found a subsMsg method, but not a pubMsg method?
i only need to send stuff to the server (at least for the moment) i tried to look into the examples, but found only probable platformio stuff, and since i am still on Arduino-IDE....

do you have an easy example laying around where you connect to the mqtt server, publish a message, and eventually the reverse, subscribing and receiving messages (for later) for Arduino IDE?

and sorry, but for the moment i am having a hard time understanding what mupplets are? and on what they run... the hardware seems to be some special board?

[domschl]

I tried to explain this a bit here: https://muwerk.github.io/munet/docs/classustd_1_1Mqtt.html, and mupplet example is here: https://github.com/muwerk/Examples/blob/master/led/src/led.cpp

Basically, muwerk implements a cooperative multitasking system on Arduino. Each of those network-objects (e.g. Net, Mqtt, Ota) are tasks in muwerk. I am currently working on making several standard sensors (leds, button, temperature sensors and many more) available as tasks, they are called mupplets ;-)

The nice thing is, that way all those rather complicated functions can run "concurrently" without the need of big messy main loops.

The muwerk scheduler also provides mqtt-like communications between those local tasks: tasks can subscribe and publish messages to each other using the same semantics Mqtt uses: E.g. the Net task publishes the rssi values or connection states of the Wlan. Any other task can subscribe to those. Or a button-task can publish if the button is pressed, and a led task can subscribe to that topic and switch the led accordingly. This all works without any external mqtt server.
The corresponding functions use the scheduler-object sched.subscribe(task_id, topic, callback) and sched.publish(topic, message). (see: https://muwerk.github.io/muwerk/docs/classustd_1_1Scheduler.html)

If an external mqtt server is connected, any communication that uses sched.subscribe(tid, topic, callback) and sched.publish(topic, message) is exported to the extern mqtt server. Publishing a topic mytopic outgoing is prefixed with omu/hostname/mytopic on sched.publish("mytopic", "hello, world!"), so your mqtt server will see a topic omu/hostname/mytopic. If you don't want that prefix, simply use ! as first character of the topic to publish:

// ...
mqtt.begin(&sched);
sched.publish("led/state","on";  // This publishes a message "on" with topic "omu/hostname/led/state"
sched.publish("!led/state","on";  // This publishes a message "on" with topic "led/state" (no automatic prefix because of `!`.

For subscription: on mqtt.begin(); the process subscribes on the external mqtt-server for messages of topic-form mu/hostname/#. The prefix mu/hostname is stripped, and the external topic mu/hostname/somesubtopic becomes the internal stripped topic somesubtopic. To subscribe to this, use:

void myCallback(String topic, String msg, String originator) {
    // This is called if a subscription-message is received.
}
//...
mqtt.begin(&sched);
int tID = sched.add(appLoop, "main", 1000000);
sched.subscribe(tID, "mysubtopic", myCallback);
//...

void appLoop() {
   // called every 1000000uS (once a second)
}

If now somebody publishes to the external MQTT server with topic mu/hostname/mysubtopic, the callback myCallback is called with the corresponding message.

If you want to subscribe to something without any prefix-translation, you can use mqtt.addSubscription(tID, topic, myCallback). This adds an additional subscription to the external Mqtt server, and incoming messages are given to the callback without transformation.

[nohkumado]

great! thats it!

now i have to find out why my JSN-SR04T sensor tells me my watertank is full (20cm mesured) instead of the actual emptiness of ~3.5m.....
and the capacity of the ESP to connect through walls and windows to the wifi AP seems quite limited too :(