Integration von MySensors in FHEM geplant?

[Beta-User]

Vielleicht hat ja auch noch jemand eine Lösung, wie man am besten die zu steuernden Geräte anlegen kann.

Aktueller Zwischenstand:
Das Modul remotecontrol macht m.E. genau das. Nochmal im Zusammenhang die Schritte dafür:
- Mysensor-Node, die IR_SEND entgegenimmt (!= Beispiel-Sketch, der sich für den "Rückweg" wie ein "on/off"-Schalter verhält!)
- Das reading IR_SEND muß in FHEM manuell gemapped sein ("attr MYSENSOR_99 mapReading_ir_send3 3 ir_send")   
- Mit "define Receiver remotecontrol" eine neue FB für FHEM definieren
- Layout für den Start: "set Receiver layout samsung"
- Device für's Versenden definieren: " set Receiver makenotify MYSENSOR_99 ir_send3"
- Tasten belegen: "attr Receiver row02 NEC 0x5EA111EE 32:1,2,3"

"1" auf "Receiver"-FB gedrückt => auf der seriellen Konsole ist zu sehen, dass die Node "NEC 0x5EA111EE 32" empfangen hat

Das ist schon mal nicht übel, aber:
- Das Komma als Seperator verträgt sich nicht mit remotecontrol => Leerzeichen geht => muß im Sketch berücksichtigt werden (sollte aber kein Problem sein )
- OFFEN: Der empfangene Gesamtstring müßte im Sketch dann in seine Einzelteile zerlegt werden und diese dann jeweils wieder im "richtigen" Format an irsend() übergeben werden  Wenn also jemand eine auch für mich verständliche Lösung hat, BITTE, BITTE, BITTE!!!
Meine Versuche mit strtok() usw. sind ein ziemlicher Gang im Nebel, was irsend() braucht, ist: void send(IRTYPES Type, unsigned long data, unsigned int data2). Ein einziger String wie "NEC 0x5EA111EE 32" wird beim übersetzten zum einen nicht akzeptiert und jetzt sind auch tendenziell die Kommas raus...)

Alternative Wege erscheinen mir nicht mehr so naheliegend, da remotecontrol jeweils genau ein Sendedevice kennt (sonst könnte man mehrere ir_send[j] anlegen und darüber das zu verwendende Protokol definieren. Oder bin ich da auf dem Holzweg?

[r_knipp]

Aktueller Zwischenstand:
Das Modul remotecontrol macht m.E. genau das. Nochmal im Zusammenhang die Schritte dafür:
- Mysensor-Node, die IR_SEND entgegenimmt (!= Beispiel-Sketch, der sich für den "Rückweg" wie ein "on/off"-Schalter verhält!)
- Das reading IR_SEND muß in FHEM manuell gemapped sein ("attr MYSENSOR_99 mapReading_ir_send3 3 ir_send")   
- Mit "define Receiver remotecontrol" eine neue FB für FHEM definieren
- Layout für den Start: "set Receiver layout samsung"
- Device für's Versenden definieren: " set Receiver makenotify MYSENSOR_99 ir_send3"
- Tasten belegen: "attr Receiver row02 NEC 0x5EA111EE 32:1,2,3"

"1" auf "Receiver"-FB gedrückt => auf der seriellen Konsole ist zu sehen, dass die Node "NEC 0x5EA111EE 32" empfangen hat

Super dass das schonmal funktioniert.

Das ist schon mal nicht übel, aber:
- Das Komma als Seperator verträgt sich nicht mit remotecontrol => Leerzeichen geht => muß im Sketch berücksichtigt werden (sollte aber kein Problem sein )

Das Trennzeichen ist ja ziemlich egal.

- OFFEN: Der empfangene Gesamtstring müßte im Sketch dann in seine Einzelteile zerlegt werden und diese dann jeweils wieder im "richtigen" Format an irsend() übergeben werden  Wenn also jemand eine auch für mich verständliche Lösung hat, BITTE, BITTE, BITTE!!!
Meine Versuche mit strtok() usw. sind ein ziemlicher Gang im Nebel, was irsend() braucht, ist: void send(IRTYPES Type, unsigned long data, unsigned int data2). Ein einziger String wie "NEC 0x5EA111EE 32" wird beim übersetzten zum einen nicht akzeptiert und jetzt sind auch tendenziell die Kommas raus...)

Versuche ich mich auch schon seit gestern Abend dran. Doch komplizierter als ich dachte

IRTYPES ist übrigens ein unsigned char.

Code Auswählen Erweitern


irData = message.getString();

irData ist ein pointer und getString() liefert halt einen pointer auf die message.
Die message ist ein char array, daher funktionieren die ganzen String Funktionen nicht.
Auf strtok() bin ich auch gekommen. Habe aber auch nichts vernünftiges hinbekommen.
Dieses pointer Gedöns ist auch echt tricky.

[Beta-User]

Super dass das schonmal funktioniert.
Das Trennzeichen ist ja ziemlich egal.
Versuche ich mich auch schon seit gestern Abend dran. Doch komplizierter als ich dachte

Freu mich auch riesig; eigentlich habe ich so was seit mehr als 2 Jahren im Hinterkopf und mit LIRC beschäftige ich mich seit ca. 10 Jahren immer wieder, war aber noch nie so nah' an meinen Vorstellungen, unglaublich, dass es jetzt an so einer Erstsemesterübung hängt...  Andererseits: bin blutiger Anfänger mit C und Co, ist alles nur copy/paste mit trial/error (vor allem letzteres...) 

Den Code habe ich etwas aufgeräumt und das mit dem Leerzeichen gleich umgesetzt, so dass es auf allen Ebenen einheitlich ist (Konsole/Versenden/Empfangen); wie üblich auf github.

[r_knipp]

Probier mal bitte das:

Code Auswählen Erweitern


    int i = 0;
    char *arg[3] = {0,0,0};

    char *irString = strdup(irData);
    char *token = strtok(irString," ");

    while(token != NULL){
       strcpy(arg[i], token);
       token = strtok(NULL, " ");
       i++;
    }
   
    Serial.print("Protocol:"); Serial.print(*arg[0]);
    Serial.print(" Code:"); Serial.print(*arg[1]);
    Serial.print(" Bits:"); Serial.print(*arg[2]);

kommt hier her: http://stackoverflow.com/questions/8056146/breaking-down-string-and-storing-it-in-array

Es kompiliert. Ich kann aber gerade nicht test. Habe ein Verbindungsproblem mit MySensors. Muss ich erstmal wieder hinbekommen.

[r_knipp]

Das ist zum verrückt werden.
Der Sensor verbindet sich anscheinend.

Code Auswählen Erweitern


Starting sensor (RNNNA-, 2.0.0-beta)
Radio init successful.
send: 100-100-0-0 s=255,c=3,t=15,pt=0,l=2,sg=0,st=fail:

send: 100-100-0-0 s=255,c=0,t=17,pt=0,l=10,sg=0,st=fail:2.0.0-beta
send: 100-100-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=fail:0
send: 100-100-0-0 s=255,c=3,t=11,pt=0,l=9,sg=0,st=fail:IR Sensor
send: 100-100-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=fail:1.0
send: 100-100-0-0 s=3,c=0,t=20,pt=0,l=0,sg=0,st=fail:
find parent
send: 100-100-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
Init complete, id=100, parent=0, distance=255


In FHEM wird er aber nicht angelegt.
Sensor und Gateway neu geflasht und Gateway auch neu angelegt.
Nach einem Neustart des Raspberry habe ich immer einen Sensor mit ID 0 als Repeater
Hast du eine Idee?

Edit:
Hat sich erledigt. Der Kondensator steckte nicht richtig am NRF. So was Blödes

[r_knipp]

Mit dem oben geposteten Code startet der Controller bei Empfang neu.

Code Auswählen Erweitern


Received IR se�Starting sensor (RNNNA-, 2.0.0-beta)
Radio init successful.
send: 100-100-0-0 s=255,c=3,t=15,pt=0,l=2,sg=0,st=ok:

send: 100-100-0-0 s=255,c=0,t=17,pt=0,l=10,sg=0,st=fail:2.0.0-beta
send: 100-100-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
send: 100-100-0-0 s=255,c=3,t=11,pt=0,l=9,sg=0,st=ok:IR Sensor
send: 100-100-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.0
send: 100-100-0-0 s=3,c=0,t=20,pt=0,l=0,sg=0,st=ok:
Init complete, id=100, parent=0, distance=1

Wie kann das denn?

Edit:
Es liegt an der while Schleife. Wenn ich die auskommentiere läufts.

[r_knipp]

So, bin jetzt so weit, dass der empfangene String richtig zerlegt wird.

Code Auswählen Erweitern


Received IR send command...
NEC 0xBE414DB2 32
Protocol:NEC Code:0xBE414DB2 Bits:32

Jetzt noch die Typen richtig konvertieren,damit sie auch mit irsend() versendet werden könne.
Das aber morgen. Jetzt schlafen...

[Beta-User]

So, bin jetzt so weit, dass der empfangene String richtig zerlegt wird.
Jetzt noch die Typen richtig konvertieren,damit sie auch mit irsend() versendet werden könne.
Das aber morgen. Jetzt schlafen...

Super, den Schlaf hast du dir redlich verdient!!!!!
Wenn du den aktuellen Code einpflegst bzw. mir zukommen läßt, aktualisiere ich den Sketch auf github...
Was das Konvertieren angeht: Unter https://github.com/markszabo/IRremoteESP8266/blob/master/examples/IRGCTCPServer/IRGCTCPServer.ino gibt es ein Beispiel, bei dem eine (als http://-string eingehende Message passend zerlegt wird (allerdings nur in zwei Teile, wenn ich das richtig verstehe)). Auch unter https://alexbloggt.com/esp8266-smarthome-gateway/ gibt es was dazu und dem Tutorial-Link unten (lesen von Serial).
Vielleicht hilft das weiter, mein derzeitiges Abstraktionsvermögen übersteigt es....

Dann:
- Laut http://tech.cyborg5.com/2013/04/22/irlib-tutorial-part-3a-sending-ir-codes/ kann man irsend() auch in der Form irsend(IRTYPES(int),...) aufrufen. Evtl. wäre es einfacher, statt "NEC" eine "1" (oder 3) zu senden; würde es nicht zumindest einen Teil der Konvertierung erleichtern, wenn wir die Teile praktisch nur numerisch hin und her schieben (und ggf. noch auf "0x" verzichten)?
- Was unsere FB's angeht:
Der Benq nutzt vermutlich das Samsung32-Protokoll, da gibt es ein Beispiel unter http://www.spech.de/blog/article/universalfernbedienung, wie das Protokoll in die (normale) IR-Lib einzubinden wäre.
Mein Panasonic-Beamer bräuchte  wohl die Eckdefinitionen für neue Panasonic-TVs. Ansätze dafür gibt's hier: https://github.com/cyborg5/IRLib/pull/15
Aber eins nach dem anderen

Bis frühestens heute Abend dann.

[r_knipp]

Wenn du den aktuellen Code einpflegst bzw. mir zukommen läßt, aktualisiere ich den Sketch auf github...

Ja, mache ich dann wenns läuft. Ist je eh "nur noch" die Konvertierung. Aber ich denke das wird auch noch. Hatte mir dazu gestern eigentlich schon alles rausgesucht.

..., bei dem eine (als http://-string eingehende Message passend zerlegt wird (allerdings nur in zwei Teile, wenn ich das richtig verstehe)).

Das coole an der der while Schleife mit der strtok() Funktion ist, dass die Anzahl der Teile egal ist. Das teilt so lange bis keine Trennzeichen mehr gefunden werden.
Man kann auch mehrere unterschiedliche Trennzeichen angeben.
Du kannst damit zum Beispiel auch NEC,0xBE414DB2:32 trennen mit strok(string,",:").
Ich hatte vor allem ziemlich Probleme mit den Pointern, da ich noch nie wirklich mit Pointern programmiert hatte. Bisher hauptsächlich Visual Basic und da brauchte ich die nicht.
Man lernt aber viel wenn man sich damit intensiv beschäftigt 

- Laut http://tech.cyborg5.com/2013/04/22/irlib-tutorial-part-3a-sending-ir-codes/ kann man irsend() auch in der Form irsend(IRTYPES(int),...) aufrufen. Evtl. wäre es einfacher, statt "NEC" eine "1" (oder 3) zu senden; würde es nicht zumindest einen Teil der Konvertierung erleichtern, wenn wir die Teile praktisch nur numerisch hin und her schieben (und ggf. noch auf "0x" verzichten)?

Das ist ja eigentlich egal. Konvertieren muss ich es so oder so. Empfangen wird immer ein Pointer auf ein char Array. Ob ich das array nun nach int oder unsigned char konvertiere sollte eigentlich keinen Unterschied machen.

Hast du eigentlich mal die Reichweite deiner IR-Diode getestet? Hatte mal zum Test beim Empfang irgendeiner Nachricht das Power On Signal senden lassen, um zu testen, ob der Receiver sich damit überhaupt schalten lässt. Meine reicht vielleicht nen halben Meter. Da muss auf jeden Fall was viel kräftigeres her, vor allem da Beamer und Receiver sich natürlich auf entgegengesetzten Seiten des Raumes befinden.

Und hast du Erfahrung mit der Reichweite von MySensors? Aus meinem Abstellraum neben der Küche reicht es mit den normalen Modulen jedenfalls nicht annähernd bis ins Wohnzimmer. Habe das Gateway zum Testen erstmal am Aquarium-Raspi im Wohnzimmer hängen. Habe mir aber auch zwei NRF mit PA und Antenne bestellt. Die brauchen aber noch etwas aus China.

[Beta-User]

Ob ich das array nun nach int oder unsigned char konvertiere sollte eigentlich keinen Unterschied machen.

Für's Konvertieren macht es evtl. keinen Unterschied, aber m.E. ist es besser, wenn es "universell" ist. Und der Panasonic- bzw. Samsung32-String braucht halt mehr Bandbreite als 2 Ziffern max. (zumal der Panasonic-Code dann auch nochmal eine Bitlänge von 56 hat (?)...

Hast du eigentlich mal die Reichweite deiner IR-Diode getestet?

...ich habe nur Bauteile hier rumliegen, zum Senden bin ich vor lauter lauter noch gar nicht gekommen (ergo auch nicht zum Zusammenstöpseln). Plan ist, einen Widerstand, einen NPN in Verbindung mit mehreren Dioden in unterschiedlicher Ausrichtung in Reihe zu nutzen, Vorschläge dazu gibt's ja Zuhauf im Netz (muß ich aber auch erst wieder suchen).

Und hast du Erfahrung mit der Reichweite von MySensors?

JAAA, Reichweitenprobleme bei Mysensors kenne ich gut . Ein PA-Modell am Gateway ist in jedem Fall eine gute Idee, damit kommt auch mein USB-powered Standard-NRF durch die Betondecke und etwas Wand in den ersten Stock; Keller-> 1. OG mit 2 PA-Modellen klappt auch. Ggf. müssen die #define PA_LEVEL... angepasst werden (hier war bei jemandem für das GW standardmäßig "LOW" eingestellt. Dann gibt es noch lustige Sachen wie angelötete Antennen usw. (Link müßte ich suchen), der Kondensator hat bei mir wenig gebracht, habe jetzt aber trotzdem einige Sockel hier liegen für zukünftige Projekte.

(Wäre vermutlich Zeit, die ganzen Beispiele und Erfahrungen etwas zu strukturieren und in's Wiki zu nehmen; die Seiten dazu bei Mysensors sind zwar klasse, aber englisch und nicht unbedingt FHEM-spezifisch (wie diese IR_SEND-Zuordnung usw.).

[r_knipp]

(Wäre vermutlich Zeit, die ganzen Beispiele und Erfahrungen etwas zu strukturieren und in's Wiki zu nehmen; die Seiten dazu bei Mysensors sind zwar klasse, aber englisch und nicht unbedingt FHEM-spezifisch (wie diese IR_SEND-Zuordnung usw.).

Wegen dem ir_send Mapping habe ich dem Ersteller des Moduls eine PM geschrieben. Das sollte am besten, genau wie das Mapping ir_receive, automatisch erzeugt werden. Meiner Meinung nach fehlt das beim autocreate.

[Beta-User]

Wegen dem ir_send Mapping habe ich dem Ersteller des Moduls eine PM geschrieben. Das sollte am besten, genau wie das Mapping ir_receive, automatisch erzeugt werden. Meiner Meinung nach fehlt das beim autocreate.

Gut, da gehört es auf jeden Fall auch hin!
Andererseits gibt es hier zwar sehr viel Info (das mit dem mapping war auch für mich schon mal ein Problem, als ich versucht habe, meinen Gas-Sensor als solchen anzulegen; ist jetzt halt ein Wasserzähler ). Aber alle Infos sind ziemlich verteilt und nicht besonders strukturiert. Und dann bist du der 2., der meine Erfahrungen bzgl. Reichweite zu hören bekommen hat...

[Beta-User]

Hast du eigentlich mal die Reichweite deiner IR-Diode getestet?

So, Bauteile eben mal zusammengesteckt. Reichweite nach dem einfachen NPN-Bauplan aus https://learn.adafruit.com/using-an-infrared-library/sending-ir-codes und der Serial-Remote (aus der neuen IRLib) als Sketch: ca. 2,5m, direkte Sichtverbindung... Andere Tests (kein Widerstand, 3 bzw. 2 Dioden in Reihe waren eher schlechter. 

Allerdings wollte irsend.send() (bzw. dort My_Sender.send(IR_types_t(... ) zunächst nicht so recht, erst als ich mein NEC in der Form My_Sender.send(IR_types_t(1), code, bits) übergeben habe, ging das kompilieren. Vorher dachte ich schon, die Diode (bzw. auch die 2.) wäre kaputt

[r_knipp]

So, es läuft endlich.
Beim Empfang übergebe ich einfach zur Info das Protokoll auch in Klartext.
Zum Senden muss das Protokoll als Zahl übergeben werden. Habe es einfach nicht als Klartext konvertiert bekommen aber das sollte ja kein Problem sein. Siehe Screenshot.

Habs auf GitHub geändert.

[Beta-User]

So, es läuft endlich.

Super Job!!!

- Würde gerne noch die Reihenfolge beim Senden anders herum machen (Klartext nach hinten); wenn der Sendetext zu lang sein sollte, wird hinten abgeschnitten, was bei der Textinfo nicht so tragisch wäre. Einwände?
Da wir die ganzen seriellen Infos dann hoffentlich nicht mehr brauchen: #ifdef MY_DEBUG nutzen?

- Protokolle: Wenn ich dazu komme (Tendenz eher am WE), würde ich mal versuchen, PanasonicNew und Samsung32 einzupflegen, oder wird dein BenQ doch bereits erkannt? Die Lib habe ich mal geforked, kann dich gerne auch wieder als Editor zulassen?

- Gibt es erprobte Ideen, was die Reichweite der IR-Diode angeht? Ansonsten würde ich es erst mal mit den weiterführenden Links von Adafruit versuchen (ich habe nur drei "blanke" IR-Dioden, kein Modul).

Off IR-Topic:
Ach ja: habe noch eine Dunstabzugshaube, die wohl einen 433MHz-Code nutzt (den ich allerdings bisher nicht ernsthaft versucht habe zu decodieren, aber so steht es auf der FB). An sich müßte man die hier entwickelte FHEM<->MySensor-IR-Mimik doch auch nutzen können, um das Teil damit zu steuern, oder? Einen rudimentären Sketch dazu gibt es in der 2.0.0 beta (bislang nur für's Empfangen).