[gelöst] Über einen Arduino mit Mysensors DHT22 Werte einsammeln

[tfriedrich85]

If Schleife und für jeden Sensor ein eigener Publish

oder

Als topic eine Variable.
D.h. je ein Array mit den beiden topics
 z.B.  char* feuchte[]    = {  "topic1", "topic2" }
und char* temperatur[]    = {  "topic1", "topic2" }

Ich stehe etwas auf dem Schlauch. In dem Array stehen dann die Räume, so etwa:
Definition

Code: [Auswählen]

static char humidity[15]; //Speicherbereich reservieren um die Fechtigkeit zu speichern
static char temperature[15];
float h[2];
float t[2];
char* feuchte[2]    = {  "Kueche", "Bad" }
char* temperatur[2]    = {  "Kueche", "Bad" }
Ausgabe
client.publish("zuHause/Arduino_1/all"feuchte,humidity, true);
    client.publish("zuHause/Arduino_1/all"temperatur,temperature, true);

[frober]

Ersten muss die 2 weg.
Wenn das Array leer definiert wird, ist die Zahl nötig um den Platz zu reservieren. Bei Zuteilung vom Inhalt, gibt der Inhalt den Platz vor.
Du hast den Inhalt auf Platz 2 ( also 1) geschrieben.

Code: [Auswählen]

char* feuchte[]    = {  "zuHause/Arduino_1/Kueche/Kuehlschrank/Luftfeuchte", "zuHause/Arduino_1/Bad/Luftfeuchte" };
char* temperatur[]    = { "zuHause/Arduino_1/Kueche/Kuehlschrank/Temperatur", "zuHause/Arduino_1/Bad/Temperatur" };

Code: [Auswählen]

client.publish(feuchte[i], humidity, true);
client.publish(temperatur[i], temperature, true);
Verständlicher?

[Beta-User]

Boah, ihr geht ja ganz schön verschwenderisch mit dem verfügbaren Speicherplatz um...
Leider kann ich dazu grade kein Beispiel finden, aber es sollte eigentlich möglich sein, z.B. den Topic aus "festen Bestandteilen" und "i-abhängigen" Bestandteilen zusammenzusetzen. Im Zweifel würde ich übrigens dazu neigen, einfach nummerische Topics zu bauen und dann die "Klartext-Umwandlung" auf der Empfängerseite vorzunehmen (=in FHEM).

Just my2ct.

[frober]

Boah, ihr geht ja ganz schön verschwenderisch mit dem verfügbaren Speicherplatz um...

Ist das so schlimm 
Ich stehe hier eigentlich auch noch am Anfang mit MQTT und hatte keine bessere Idee

aber es sollte eigentlich möglich sein, z.B. den Topic aus "festen Bestandteilen" und "i-abhängigen" Bestandteilen zusammenzusetzen.

Daran hatte ich auch gedacht, war mir jedoch nicht sicher ob das funktioniert...

[Beta-User]

Ist das so schlimm 
Ich stehe hier eigentlich auch noch am Anfang mit MQTT und hatte keine bessere Idee

Na ja... Hier in diesem Forenbereich geht es "eigentlich" um MySensors, und ggf. etwas weiter gefaßt um die Programmierung von MCU's. Und da gehört jedenfalls nach meiner Auffassung der effiziente Umgang mit Ressourcen noch viel mehr zum "Pflichtprogramm" wie bei FHEM allgemeint ...

Was MQTT auf einer MCU angeht, bin ich auch mehr oder weniger kompletter Novice und hatte damit zuletzt im Rahmen einer Eigenbau-Lösung für IR-Signale was am Hut, da war das Framework aber auch schon fertig vorhanden und nur "ein bißchen anzupassen". Wenn es irgend geht, finde ich nach wie vor für bidirektionales Zeug MySensors die bessere/einfachere Lösung...

Daran hatte ich auch gedacht, war mir jedoch nicht sicher ob das funktioniert...

Es müßte gehen, aber leider habe ich die Funktion noch nicht gefunden, die hier genutzt wird:
https://github.com/mysensors/MySensors/blob/development/core/MyGatewayTransportMQTTClient.cpp#L127

Edit: die Funktion protocolMyMessage2MQTT() findet sich in https://github.com/mysensors/MySensors/blob/development/core/MyProtocol.cpp#L100. Sieht aber auch nicht "einfach" aus, was da so steht, aber wenn man der Kernfunktion "snprintf_P" folgt, landet man z.B. hier: https://cpp4arduino.com/2020/02/07/how-to-format-strings-without-the-string-class.html ...

[frober]

Na ja... Hier in diesem Forenbereich geht es "eigentlich" um MySensors, und ggf. etwas weiter gefaßt um die Programmierung von MCU's. Und da gehört jedenfalls nach meiner Auffassung der effiziente Umgang mit Ressourcen noch viel mehr zum "Pflichtprogramm" wie bei FHEM allgemeint

Hmm, char belegt 1Byte, ein Array soviel wie an Inhalt definiert ist. Also hier 2 Byte, wenn ich mich nicht irre.
Also spielt es mEn keine Rolle wie lange der String ist!?

Allgemein, wenn der Arduino mit MQTT schon an der Grenze ist, wird es mit MySensors eh zuviel...
Ich hätte das auch nicht kombiniert...
...oder zumindest gleich einen ESP genommen.

[Beta-User]

Nun ja, hau' das mal durch den Compiler...

Hätte eher vermutet, dass das char-Array ein n-faches (n=Zahl der Elemente) vom längsten darin enthaltenen String braucht; irgendwo müssen die Strings ja abgelegt werden, oder woher sonst sollen die gelesen werden?

Der ATMega328 war vermutlich nur durch die ungünstige Nutzung der verfügbaren Ressourcen nicht geeignet, und wie wir (hoffentlich) gesehen haben, geht das MySensors-framework relativ restriktiv vor, was den Ressourcenverbrauch angeht. MySensors-GW ohne MQTT, aber mit den paar Sensoren sollte darauf jedenfalls gehen, wenn man es effizient löst .

Aber klar, man kann auch die Microsoft-Methode anwenden und mit mehr CPU+Memory draufhauen, bis es paßt (und sich um selbstgestrickte Altlasten erst mal nicht kümmern)...

[frober]

Nun ja, hau' das mal durch den Compiler...

Bei Gelegenheit...

Hätte eher vermutet, dass das char-Array ein n-faches (n=Zahl der Elemente) vom längsten darin enthaltenen String braucht; irgendwo müssen die Strings ja abgelegt werden, oder woher sonst sollen die gelesen werden?

Ich dachte, das der Inhalt durch Char begrenzt ist (256 Zeichen).

MySensors-GW ohne MQTT, aber mit den paar Sensoren sollte darauf jedenfalls gehen, wenn man es effizient löst .

So hatte ich das auch gedacht.

Aber klar, man kann auch die Microsoft-Methode anwenden und mit mehr CPU+Memory draufhauen, bis es paßt (und sich um selbstgestrickte Altlasten erst mal nicht kümmern)...

So war es nicht gemeint...
Wenn der TE MQTT mit MySensors kombinieren möchte und dann an einen UNO ein Netzwerk bastelt, dann wäre das die einfachere Lösung   

[Beta-User]

Ich dachte, das der Inhalt durch Char begrenzt ist (256 Zeichen).

Jein. Das ist nach meinem Verständnis erst mal die Ausgangsdimension. Danach kommt als weitere Dimension die Länge der Zeichenkette ("String" war vorhin nicht technisch gemeint). Da dann ein char-Array-Array (iSv. einem Array mit den char-Arrays drin) vorgeschlagen war, meine ich, dass der reservierte Speicherplatz dann noch durch die Zahl der Elemente vervielfacht werden muss, wobei eben die Längste "Kette" in der 2. Dimension einen der Faktoren bildet. Bin da aber auch nicht so tief drin...

Wenn der TE MQTT mit MySensors kombinieren möchte und dann an einen UNO ein Netzwerk bastelt, dann wäre das die einfachere Lösung   

MAn. nein. MQTT+MySensors ist im FHEM-Kontext die schwierigere Kombination. Wenn MQTT, bringt MySensors keinen Zusatznutzen, aber MySensors kennt ein paar Hilfsmittelchen, die den MQTT-Overhead auf der FHEM-Seite überflüssig machen. Anders gesagt: Wenn man sowieso auf der MCU programmiert, kann man auch direkt MySensors wählen, wenn man es bidirektional will (was hier nicht zwingend wäre).
Die einfachste "unidirektionale" Variante wäre mit einiger Sicherheit immer noch UDP-Broadcast und keyValueProtocol (vorausgesetzt, man findet jemanden, der sich damit auf der FHEM-Seite auskennt und einen coacht).

[tfriedrich85]

Danke für Eure Hilfe, @frober & @Beta-User! Ressourcenverschwendung hin oder her, ich konnte damit 7 Wmos Esp32 Minis ablösen und diese Arbeit wird jetzt von einem Arduino Mega erledigt! Das ist doch super effizient und funktioniert davon abgesehen schön über Kupfer anstatt WLAN! Also alles Tip-Top Vielen Dank!

[frober]

Na das hört sich doch gut an, freut mich.

[tfriedrich85]

Na das hört sich doch gut an, freut mich.

Den Code hab ich auf Github hochgeladen. Mal sehen ob sich jemand findet, der daran weiterentwickeln möchte.
https://github.com/tfriedrich85/temperature-Sensors-to-MQTT

[frober]

Den Code hab ich auf Github hochgeladen. Mal sehen ob sich jemand findet, der daran weiterentwickeln möchte.
https://github.com/tfriedrich85/temperature-Sensors-to-MQTT

Verbesserungspotential gibt es 

z.B. clientloop() gehört zum callback und kann weg...
dht.begin kannst du auch über eine for-Schleife abarbeiten...