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

Begonnen von tfriedrich85, 15 Februar 2022, 13:37:28

Vorheriges Thema - Nächstes Thema

tfriedrich85

Zitat von: frober am 21 Februar 2022, 21:04:17
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

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

#16
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.

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" };


client.publish(feuchte[i], humidity, true);
client.publish(temperatur[i], temperature, true);


Verständlicher?


Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frober

#18
Zitat von: Beta-User am 22 Februar 2022, 12:18:25
Boah, ihr geht ja ganz schön verschwenderisch mit dem verfügbaren Speicherplatz um...

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

Zitataber 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...
Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Beta-User

#19
Zitat von: frober am 22 Februar 2022, 12:55:29
Ist das so schlimm  :o
Ich stehe hier eigentlich auch noch am Anfang mit MQTT und hatte keine bessere Idee 8)
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 :P ...

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...

ZitatDaran 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 ...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frober

Zitat von: Beta-User am 22 Februar 2022, 13:05:37
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 :P

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.
Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

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 :P .

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)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frober

Zitat von: Beta-User am 22 Februar 2022, 15:55:17
Nun ja, hau' das mal durch den Compiler...
Bei Gelegenheit...

Zitat
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).

Zitat
MySensors-GW ohne MQTT, aber mit den paar Sensoren sollte darauf jedenfalls gehen, wenn man es effizient löst :P .
So hatte ich das auch gedacht.

Zitat
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   ;)
Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Beta-User

Zitat von: frober am 22 Februar 2022, 16:12:54
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...

Zitat
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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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

Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

tfriedrich85

#26
Zitat von: frober am 25 Februar 2022, 05:55:45
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

Zitat von: tfri ;)edrich85 am 25 Februar 2022, 12:41:06
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...

Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...