Integration von MySensors in FHEM geplant?

[schka17]

Hallo,

spiele immer noch mit dem MQ-135 herum.
Der MQ-135 soll ja CO2 SO2 NH3 NH4 CH3 CO messen können.

Hier gibt es ein schöne Sketch für einige Gas Sensoren, läuft aber wohl nicht auf einem Nano.
https://github.com/empierre/arduino/blob/master/AirQuality-Multiple_Gas_Sensor1_4.ino

Das hier läuft auch, liefert aber nur CO2
https://github.com/GeorgK/MQ135

genau so wie dieses hier
https://github.com/empierre/arduino/blob/master/AirQuality-MQ135.ino

Für mich wäre aber noch NH3 interessant und die anderen Werte.
Hat das schon mal jemand hin bekommen?

Hi, ich spiele auch schon länger damit und habe auch das Datenblatt gelesen, ich denke nicht dass du mit dem MQ-135 einzelne Gase erkennen kannst, das ist ein Air-quality sensor der auf alle beschriebenen Gase mit Änderung des Messwiderstandes reagiert, du kannst aber aufgrund des Messwiderstandes nicht ein bestimmtes Gas erkennen. D.h. Ich habe einfach einen Schwellwert für gute Luft definiert (halbe Stunde im Garten gemessen) und das ist meine Referenz.
Mehr gibt dieser Sensor nicht her.

[Edi77]

Hallo,

Ich habe ja auch den CO20 im Einsatz, und hatte den auch draußen eingesetzt, was natürlich auch zu Fehlmessungen führte weil nicht Temperaturkompensiert.
Ich will den MQ-135 auch draußen einsetzen, weil einige Bauern gern Gülle zu nah am Wohngebiet einsetzen, da wäre NH3 schon interessant wenn man das einzeln auswerten könnte, den beim AirQuality-Multiple_Gas_Sensor1_4.ino scheint das ja zu gehen. AirQuality-Multiple_Gas_Sensor1_4.ino so wie ich das sehe muss das auf einem Arduino Mega laufen, muss ich mal testen, den hier werden die einzelnen Gase ja angezeigt.
Für das kalibieren sollte man den Sensor bei ca. 20C draußen auf CO2 400ppm einstellen.

[schka17]

Ich glaube nicht dass das geht, solltest du das aber hinbekommen wäre es interessant.


Sent from my iPad using Tapatalk

[Edi77]

Hallo,

Habe mir die Skechts und die Datenblätter mal angeschaut, und es ist wohl richtig das man nur einen Gesamtwert geliefert bekommt.
Daher denke ich bleibt der Multible Gas Sensor interessant. Wenn man z.B. einen reinen CO2 Sensor hat, kann man bei gleichbleibenden CO2 Werte aber abfallenden Werte bei einem anderen Sensor ausschließen das es CO2 ist usw.
So könnte Wertänderung beim einen Sensor mit einem anderen Sensor abgleichen und evtl. so das Gas heraus finden welches Gas gerade in der Luft ist.

[Beta-User]

Frage: hat schon mal jemand versucht, den "echten" IR_SEND-Modus in FHEM zu nutzen?

FHEM meckerte eben: "ir_send3 not defined: no mapping for reading ir_send3". Jemand eine Idee, wie das zu konfigurieren ist?

Und wenn es dann mit dem Versenden des kompletten Sendekommandos klappen sollte: Beim Kompilieren hatte ich die Rückmeldung, dass irsend.send() drei Argumente haben möchte, ich aber nur eines liefern würde, und das auch noch als String, was gar nicht ginge... Vor ich mir mit viel trial-und-error den Kopf zerbreche: Hat jemand einen Lösung parat, wie man einen String wie "3, 0x00001522, 13" wieder in die Einzelteile zerlegt, die "3" durch "RC5" ersetzt (ok: Array, aber am liebsten entsprechend dem jeweiligen Stand der Dinge in der IRLib )
und dann möglichst effektiv an irsend.send() übergibt?

OK, habe auch mal auf 2.0 beta upgedated, damit ich da auf dem gleichen Stand bin.

Mal ne Frage zu deinem Sketch.
Ich dachte in Arduino wird erst die setup() ausgeführt und dann die loop(). Wie wird denn die presentation() ausgeführt. Oder wird pauschal alles einmal ausgeführt, was vor der loop() kommt?

presentation() ist Teil der geänderten Notation in der 2.0.0-Version von Mysensors. Vorneweg: Es funktioniert... Nach meinem Verständnis ist das als Teil der setup-routine innerhalb von MySensorCore.cpp definiert. Es scheinen also mehrere Ebenen zu sein, die im Rahmen des Kompilierens dann ineinander geschoben werden (so jedenfalls mein laienhaftes Verständnis).

Bist Du weitergekommen mit den 0000... und fff... (In meinem Sketch habe ich das schlicht als nicht zu versenden rausgefiltert).

[r_knipp]

Frage: hat schon mal jemand versucht, den "echten" IR_SEND-Modus in FHEM zu nutzen?

FHEM meckerte eben: "ir_send3 not defined: no mapping for reading ir_send3". Jemand eine Idee, wie das zu konfigurieren ist?

Und wenn es dann mit dem Versenden des kompletten Sendekommandos klappen sollte: Beim Kompilieren hatte ich die Rückmeldung, dass irsend.send() drei Argumente haben möchte, ich aber nur eines liefern würde, und das auch noch als String, was gar nicht ginge...

Ich denke du meinst void send(IRTYPES Type, unsigned long data, unsigned int data2); in der IRLib?
Ich würde den String zerlegen. Schau mal hier: http://www.cprogramming.com/tutorial/string.html unter Searching and Substrings.
Type würde ich dann über eine Art Mapping erzeugen. data2 müsste man per Typecasting in int ändern können.
Bei data wüsste ich jetzt nicht. Der IR-Code ist dockeigentlich HEX, aber die Funktion erwartet ein long.

Bist Du weitergekommen mit den 0000... und fff... (In meinem Sketch habe ich das schlicht als nicht zu versenden rausgefiltert).

Noch nicht. Bin noch unterwegs. Heute Abend bin ich wieder zu Hause. Dann werde ich weiter testen.
Würde ich aber auch so machen, oder halt das Ergebnis der decode() Funktion abfragen.
Werde aber auch noch mal den TSOP1738 ausprobieren. Vielleicht hat sich das mit einem anderen Empfänger ja auch erledigt.

Vielleicht auch mal ne anderer Lib ausprobieren?
Der IRMP (https://www.mikrocontroller.net/articles/IRMP) funktioniert wohl sehr zuverlässig und sollte auf dem Arduino doch auch laufen.

[Beta-User]

Ich denke du meinst void send(IRTYPES Type, unsigned long data, unsigned int data2); in der IRLib?

Ist etwas mißverständlich; ich spreche von zwei Dingen:

Zum einen nämlich ging es um die Frage, ob jemand aus FHEM "irgendetwas" via der Variabel IR_SEND an eine MySensors-Node (zurück) verschickt hat (das klappt bei mir nämlich weder mit einem String, noch mit einer "0" oder "1". Hast Du da eine Idee? (Wäre es evtl. eine Idee, die Node auch als "Custom" zu deklarieren, dann ginge es evtl. mit V_VAR1, oder hätte man da dasselbe Problem? Sollte man die Variable evtl. initialisieren, indem man den letzten Wert beim Controller abfragt? Vielleicht geht es dann?)).

Zum anderen ging es dann um das Thema, wie den String zerlegen und das typecasting machen. Da werde ich mir die von Dir genannten Seiten mal zu Gemüte führen... War aber mit dem umgekehrten Weg (sprintf()) schon recht lange beschäftigt, um den vollständigen Code an FHEM zu versenden.

Aktueller Sketch liegt in meinem repo auf Github, anbei auch ein screenshot, dann ist evtl. klarer, was ich mit meiner Fehlermeldung zu IR_SEND meinte.

Was die IRLib angeht: ich verwende diese: https://github.com/ElectricRCAircraftGuy/IRLib. Die erkennt jedenfalls meine Yamahe(NEC) recht ordentlich, allerdings muß ich auch die Wiederholcodes noch filtern.

[r_knipp]

Ich habs schon mal hinbekommen, dass der IR Typ als Text nach FHEM übertragen wird.

Code Auswählen Erweitern


String IRType_string = Pnames(My_Decoder.decode_type);
char IRType[IRType_string.length()+1];
IRType_string.toCharArray(IRType,IRType_string.length()+1);
sprintf(buffer, "%s, 0x%08lX, %i", IRType, My_Decoder.value, IrBits);


Edit:
Senden aus FHEM geht auch:

Code Auswählen Erweitern


attr mapReading_ir_send3 3 ir_send

damit das Reading auch auf die Variable gemappt wird.

Ich habe es nur noch nicht hinbekommen einen String wie NEC,0xBE414DB2,32 zu senden.
FHEM interpretiert das als drei Werte.
Also man muss sämtliche Befehle die man senden möchte als Readinsgwerte in setReading_ir_send3 eintragen.
Oder könnten wir vielleicht andere Trennzeichen verwenden und sie dann im Sensorsketch ersetzen?

Edit2:
Wenn ich das Reading manuell setze

Code Auswählen Erweitern


set MYSENSOR_100 ir_send3 NEC,0xBE414DB2,32

wird es auch gleich wieder empfangen und dekodiert

Code Auswählen Erweitern


Received IR send command...
NEC,0xBE414DB2,32
decoding
NEC, BE418D72, 32
send: 100-100-0-0 s=3,c=1,t=33,pt=0,l=19,sg=0,st=ok:NEC, 0xBE418D72, 32
NEC, 0xBE418D72, 32

Der Receiver schaltet aber nicht ein. Habe den Sensor direkt vor das Gerät gehalten. An der Reichweite kanns also nicht liegen.

Da läuft wohl noch beim Senden des IR etwas nicht so richtig. Da weiß ich jetzt aber erstmal nicht weiter.

Edit3:
Oh, ich sehe gerade der gesendete und dekodierte code stimmen nicht überein.

[r_knipp]

Ich sehe gerade, der Sendet noch gar kein IR. Ist doch auskommentiert.
Warum empfängt er dann nach dem "Senden" etwas? Verstehe ich nicht.

[r_knipp]

Moin,

sorry für die etwas wirren Posts. War dann wohl doch schon etwas zu müde gestern Abend.

Das Senden von und nach FHEM funktioniert jedenfalls.
Das Senden eines IR-Codes sollte ich dann heute Abend hoffentlich auch hinbekommen.
Die benötigten String-Funktionen, um den empfangenen String in die entsprechenden Argumente zu zerlegen, stehen jedenfalls in der Arduino-Referenz.

Vielleicht kann noch jemand sagen, wie ich einen Wert wie NEC,0xBE414DB2,32 als Attributwert speichern kann, ohne dass die Kommas als Trennzeichen gewertet werden.
Vielleicht hat ja auch noch jemand eine Lösung, wie man am besten die zu steuernden Geräte anlegen kann.
Also z.B. einen Receiver als Dummy mit entsprechenden Funktionen (On, Off, lauter, leise, ...).
Kann man das ohne großes DOIF Gefrickel hinbekommen?

@Joe_re
Ich habe übrigens die MySensors Lib 2.0.0 beta und die IRLib von ElectricRCAircraftGuy mit deinem aktuellen Sensorsketch als Grundlage genommen.

[Beta-User]

Ich habs schon mal hinbekommen, dass der IR Typ als Text nach FHEM übertragen wird.

Code Auswählen Erweitern


String IRType_string = Pnames(My_Decoder.decode_type);
char IRType[IRType_string.length()+1];
IRType_string.toCharArray(IRType,IRType_string.length()+1);
sprintf(buffer, "%s, 0x%08lX, %i", IRType, My_Decoder.value, IrBits);


Edit:
Senden aus FHEM geht auch:

Code Auswählen Erweitern


attr mapReading_ir_send3 3 ir_send

damit das Reading auch auf die Variable gemappt wird.

Ich habe es nur noch nicht hinbekommen einen String wie NEC,0xBE414DB2,32 zu senden.
Vielleicht kann noch jemand sagen, wie ich einen Wert wie NEC,0xBE414DB2,32 als Attributwert speichern kann, ohne dass die Kommas als Trennzeichen gewertet werden.

Auf das mapReading wäre ich wohl nie gekommen, herzlichen Dank!!!! Und auch das mit dem Senden des "NEC" ist evtl. auch ein deutlicher Fortschritt (braucht aber mehr Bandbreite zum Senden und ist nicht genau die erste Ziffer (für den "Rückweg")).

Könnte das mit dem String senden klappen, wenn man ihn in """" setzt? Also "NEC,0xBE414DB2,32"?

Vielleicht hat ja auch noch jemand eine Lösung, wie man am besten die zu steuernden Geräte anlegen kann.
Also z.B. einen Receiver als Dummy mit entsprechenden Funktionen (On, Off, lauter, leise, ...).
Kann man das ohne großes DOIF Gefrickel hinbekommen?

Habe mich zwar noch nicht so recht mit der grafischen Aufarbeitung unserer neuen Möglichkeiten beschäftigt, aber evtl. läßt sich das mit remotecontrol (http://www.fhemwiki.de/wiki/Remotecontrol) recht einfach realisieren. Also die definierte remotecontrol mit dem MySensors-Device über "# Syntax:
set <name> makenotify <executingDevice>"koppeln (<executingDevice> = MYSENSORSDEVICE_XXX_IR_SEND oder so) und dann "einfach" direkt die jeweiligen FHEM-Sendekommandos hinterlegen?
"# Syntax:
attr <name> rowXX <command>:<icon>"
Könnte also so gehen: "attr <name> row01 NEC,0xBE414DB2,32:PLAY" 

@Joe_re
Ich habe übrigens die MySensors Lib 2.0.0 beta und die IRLib von ElectricRCAircraftGuy mit deinem aktuellen Sensorsketch als Grundlage genommen.

@r_knipp: Pflege gerne Deine Änderungen (v.A., wenn das mit dem Aufsplitten klappt!!!) mit ein bzw. laß' Dich als Miteditor zu, wenn Du magst. Andererseits: Die von Dir genannte IRMP-Library könnte noch besser sein: Mehr Maintainer und die kann evtl. schon meinen Panasonic-Beamer, ohne dass ich irgendwelche LIRC-Files übersetzten müßte ? Würde das gerne mal ausprobieren, aber da sind die Aufrufe wieder anders, oder? (War gestern dann auch zu müde, um das zielführend anzugehen).

[r_knipp]

... und ist nicht genau die erste Ziffer (für den "Rückweg")).

Das verstehe ich nicht. Was meinst du?

Könnte das mit dem String senden klappen, wenn man ihn in """" setzt? Also "NEC,0xBE414DB2,32"?

Ich habe "" und () ausprobiert und gegoogelt. Aber nix gefunden.
Aber wahrscheinlich ist es auch gar nicht nötig die Befehle dort zu hinterlegen. Das wird man ja eher woanders machen wenn das so funktioniert, wie du es beschrieben hast.

@r_knipp: Pflege gerne Deine Änderungen (v.A., wenn das mit dem Aufsplitten klappt!!!) mit ein bzw. laß' Dich als Miteditor zu, wenn Du magst. Andererseits: Die von Dir genannte IRMP-Library könnte noch besser sein: Mehr Maintainer und die kann evtl. schon meinen Panasonic-Beamer, ohne dass ich irgendwelche LIRC-Files übersetzten müßte ? Würde das gerne mal ausprobieren, aber da sind die Aufrufe wieder anders, oder? (War gestern dann auch zu müde, um das zielführend anzugehen).

Also ich würde das gerne erstmal mit der jetzt verwendeten Lib komplett zum Laufen bekommen.
Klar, kannst mich gern als Miteditor eintragen. Habe bisher zwar nicht mit GitHub gearbeitet aber schon länger nen Account (rknipp).

Ja, bei der IRMP-Lib sind die Aufrufe sicher anders. Habe die auch noch nicht selber verwendet. Läuft aber in meiner Wordclock sehr zuverlässig.
Würde es aber, wie gesagt, gerne erstmal fertig bekommen. Das Umbauen des Sketches sollte dann ja aber kein großer Aufwand sein.
Kannst ja nen Fork von deiner Version machen und es parallel versuchen wenn du Lust hast.

[r_knipp]

Mehr Maintainer und die kann evtl. schon meinen Panasonic-Beamer, ohne dass ich irgendwelche LIRC-Files übersetzten müßte ?

Gerade mal durch den IRMP-Artikel geschaut. Panasonic Beamer ist seit November letzten Jahres drin. Leider kein BenQ
Muss ich doch weiter an der ESP8266 Serial Bridge basteln.

Hab gesehen, IRMP wurde auch für den ESP8266 portiert. Vielleicht auch ne Lösung. Fragt sich nur, wie an FHEM anbinden.
Aber das passt hier eigentlich nicht hin...

Es gibt aber auch einen Beispielsketch für Arduino. Sollte also auch funktionieren.

[Beta-User]

Das verstehe ich nicht. Was meinst du?

Na ja, wir haben wohl grundsätzlich zwei Optionen, auf welche Art wir der Node von FHEM aus sagen, welches Protokoll verwendet werden soll:
1. entweder im Klartext ("NEC"). Das müssen wir dann mit einer Textanalyse aus dem FHEM-Sendekommando extrahieren wie vorgeschlagen
2. oder wir nehmen den numerischen Wert (derzeit kennt die IRLib 8 Protokolle oder so, das wäre also genau ausreichend für die erste Ziffer, die zurückgesendet wird) und übersetzten das dann erst wieder zum IR-Senden in Text (über eine Array-Zuordnung nach dem Motte: Protokolle[3]=NEC)

1 hat den Vorteil, dass wir Klartext reden und dann unabhängiger von der verwendeten IRLib sind, für andere dürfte es auch besser nachvollziehbar sein
2 braucht weniger Bandbreite, entsprach der alten Fassung des IR_RECEIVE und sah für meine Programmierkenntnisse damit einfacher realisierbar aus . Dann hatte ich noch den Eindruck, dass (zumindest bei meinen FB's) auch die irBits eigentlich immer in einer festen Korrelation zum Protokoll stehen. Wenn das so ist, könnte man auf der Node ein 2. Array definieren, das die passenden irBits auswirft und sich beim Senden aus FHEM dann darauf beschränken, statt "NEC,0xBE414DB2,32" dann "30xBE414DB2" zu senden; damit würde man übrigens wohl auch das Komma-Problem lösen

Ich habe "" und () ausprobiert und gegoogelt. Aber nix gefunden.
Aber wahrscheinlich ist es auch gar nicht nötig die Befehle dort zu hinterlegen.

Sorry für den doofen Vorschlag mit dem "". Hoffe auch, wir brauchen die Kommandos nur einmal festzunageln und gut is...

Gerade mal durch den IRMP-Artikel geschaut. Panasonic Beamer ist seit November letzten Jahres drin. Leider kein BenQ

Na ja, muß nix heißen; Yamaha=NEC... Vielleicht klappt es doch auch für BenQ mit dieser Lib, auch ohne dass es explizit erwähnt wäre.

Also ich würde das gerne erstmal mit der jetzt verwendeten Lib komplett zum Laufen bekommen.

I'm absolutely with you! Kannte diese lib aber noch nicht, Panasonic-Unterstützung klang sehr verlockend und Du schienst zu wissen, wie es geht! Also: Übernächster Schritt oder so...
Nach meinen Eindruck ist es wichtiger, erst mal den Transportweg für die Signale zu haben (und die "Knöpfe" in FHEM). Dann sollte es irgendwie auch möglich sein, die Protokolle zu erweitern (LIRC.conf-Übersetzungen...). Das dürfte langfristig zielführender sein, als gerade jetzt das Pferd zu wechseln

[Beta-User]

Senden aus FHEM geht auch:

Code Auswählen Erweitern


attr mapReading_ir_send3 3 ir_send

damit das Reading auch auf die Variable gemappt wird.

Ich habe es nur noch nicht hinbekommen einen String wie NEC,0xBE414DB2,32 zu senden.
FHEM interpretiert das als drei Werte.
Also man muss sämtliche Befehle die man senden möchte als Readinsgwerte in setReading_ir_send3 eintragen.
Oder könnten wir vielleicht andere Trennzeichen verwenden und sie dann im Sensorsketch ersetzen?

Edit2:
Wenn ich das Reading manuell setze

Code Auswählen Erweitern


set MYSENSOR_100 ir_send3 NEC,0xBE414DB2,32

wird es auch gleich wieder empfangen und dekodiert

Code Auswählen Erweitern


Received IR send command...
NEC,0xBE414DB2,32


Habe vorhin auch das Reading gemapped, jetzt kann ich auch rückwärts (FHEM->Node) senden, es kommt auch was bei der Node an! Positiv: kann beliebige Strings senden, also auch "RC5,0x00001520,13" (ohne irgendwelche Klammern, Anführungszeichen oä.) . Negativ: das klappt mal und klappt dann wieder nicht ; kann noch keinen Zusammenhang erkennen .

@r_knipp: Habe Dich als Coautor zugelassen, Sorry für das Durcheinander im Repo, der "eigentliche" Sketch ist dieser: https://github.com/rejoe2/Mysensors-IR/blob/master/IrSensor/IrSensor.ino.

In der IRMP-Library sind übrigens auch sehr viele Definitionen für Protokolle hinterlegt. Es scheint nicht das große Hexenwerk zu sein, aus einer (bekannten) LIRC.conf zumindest die Eckdaten abzulesen und damit dann auch in der jetzt verwendeten IRLib anzufügen. Der BenQ könnte auch ein verkappter NEC sein, scheint auch 32 irBits zu haben, vgl. http://lirc.sourceforge.net/remotes/benq/MP620 (man muß wohl die Angaben für pre_data und bits addieren).  [/code]