LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino

weini · 02 Oktober 2016, 11:40:20

ZitatDas liegt nicht an 36_LaCrosseGateway.pm

Völlig richtig, funktioniert nämlich wunderbar

Ich hatte es gestern versucht, da ging es nicht. Ich vermute, dass zu deim Zeitpunkt die Namesauflösung vom Raspi aus (mein FHEM Server) noch nicht funktioniert hat, von meinem Desktop aber sehr wohl.

Wie auch immer, Feature ist da! Vielleicht könntest du es bei Gelegenheit noch in der Doku erwähnen, da ist aktuell nur von IP-Adresse die Rede.

Bapt. Reverend Magersuppe · 13 Oktober 2016, 10:01:41

Whow, jetzt habe ich mir das ganze mal von Seite 1 an durchgelesen und bin total beeindruckt!
Kann man den Sketchup so erweitern das der auch MQTT-Nachrichten raushaut?
Das wäre doch eine klassische Anwendungsfalle dafür. Temperatur kommt per LaCrosse rein, zack raus als mqtt-Nachricht.

HCS · 13 Oktober 2016, 10:16:30

Zitat von: Bapt. Reverend Magersuppe am 13 Oktober 2016, 10:01:41
Kann man den Sketchup so erweitern das der auch MQTT-Nachrichten raushaut?

Sorry wegen der schlechten Nachricht: aktuell habe ich keine Pläne Richtung MQTT. Das wird es eher nicht geben.
MQTT macht aber auch keinen Sinn, um die Daten nach FHEM zu bringen, dafür gibt es ja bereits den Weg über das JeeLink / LaCrosseGateway device mit den nachgelagerten Modulen für LaCrosse, PCA301, EMT7110, Level, ... und MQTT wäre nur ein paralleler Pfad, um das zu erreichen, was bereits möglich ist.

Bapt. Reverend Magersuppe · 13 Oktober 2016, 10:34:10

Zitat von: HCS am 13 Oktober 2016, 10:16:30
Sorry wegen der schlechten Nachricht: aktuell habe ich keine Pläne Richtung MQTT. Das wird es eher nicht geben.

Oh wie schade. Da ist es wohl doch sehr mit fhem verheiratet und nicht universell einsetzbar. Da es nicht auf github liegt wird es wohl lizenzlich auch nicht möglich sein es zu forken ohne mit einem Bein auf der Anklagebank zu sitzen.

HCS · 13 Oktober 2016, 10:54:27

Zitat von: Bapt. Reverend Magersuppe am 13 Oktober 2016, 10:34:10
Oh wie schade. Da ist es wohl doch sehr mit fhem verheiratet und nicht universell einsetzbar.

Ja. Ich habe es genau und nur für FHEM geschrieben.

Zitat von: Bapt. Reverend Magersuppe am 13 Oktober 2016, 10:34:10
Oh wie schade. Da ist es wohl doch sehr mit fhem verheiratet und nicht universell einsetzbar. Da es nicht auf github liegt wird es wohl lizenzlich auch nicht möglich sein es zu forken ohne mit einem Bein auf der Anklagebank zu sitzen.

Der Quellcode ist veröffentlicht und open source, Du kannst damit machen, was Du willst - kopieren, optimieren, ruinieren, ...
Nur eben nicht erwarten, dass ich jeden Patch übernehme.

Bapt. Reverend Magersuppe · 13 Oktober 2016, 11:13:10

Zitat von: HCS am 13 Oktober 2016, 10:54:27
Ja. Ich habe es genau und nur für FHEM geschrieben.

Ich arbeite eben viel mit NodeRed und da gehts besser mit MQTT. Will ja auch kein Stress mit dem Autor machen wenn ich mich dran verüble. Also Du wärst nich sauer wenn man sich dran lang hangelt um das entsprechend anzupassen?

HCS · 13 Oktober 2016, 11:32:38

Zitat von: Bapt. Reverend Magersuppe am 13 Oktober 2016, 11:13:10
Ich arbeite eben viel mit NodeRed und da gehts besser mit MQTT. Will ja auch kein Stress mit dem Autor machen wenn ich mich dran verüble. Also Du wärst nich sauer wenn man sich dran lang hangelt um das entsprechend anzupassen?

Wie schon geschrieben, Du darfst Dir aus dem Quellcode machen was Du willst, aber ich werde in meine "offizielle" Version (zu 99,9x%) keine MQTT Implementierung übernehmen.
Das zieht nämlich (wenn man es für die Allgemeinheit tauglich machen will) eine Menge Implementierung, Konfiguration, Test, Dokumentation, ... nach sich.

Mal aus dem hohlen Bauch raus (kenne Deinen genauen use case nicht): denk mal drüber nach, ob ein alternatives IO-Device in FHEM (anstatt 36_JeeLink bzw. 36_LaCrosseGateway), das die Daten nicht an nachgelagerte FHEM-Module dispatched sondern per MQTT weitersendet, eine Alternative wäre.
Dann bräuchte man nicht zwei LGWs.

pc1246 · 18 Oktober 2016, 15:20:36

Moin
Ich habe jetzt das Carrierer-Board von Locutus. Wollte das jetzt eigentlich mit einem Wemos D1 betreiben. Aber ich finde jetzt keine Zeichnung wo das LGW mit einem Wemos abgebildet ist! D1-D8 sind soweit klar, RX, TX, RST und A0 auch. Nur den EN (CH_PD), den finde ich nicht! Kann mir jemand helfen?
Gruss und Danke Christoph

oli82 · 18 Oktober 2016, 15:39:14

Zitat von: pc1246 am 18 Oktober 2016, 15:20:36
Nur den EN (CH_PD), den finde ich nicht! Kann mir jemand helfen?

Soweit ich noch weiß und den Schaltplan lese, ist EN / CH_PD bei den Wemos D0

HCS · 18 Oktober 2016, 16:56:51

Nimm RST, das geht auch.

sash.sc · 20 Oktober 2016, 18:42:53

Hallo zusammen.

habe da mal noch ne Frage. Ich wollte meinem LCG 2x RF69cw einpflanzen. Müssen an D1/d2 die beiden PullUp Widerständer von 4K7 dann verlötet werden? Oder nur wenn die anderen Sensoren mit verlötet werden.

Gruß Sascha

PeMue · 20 Oktober 2016, 19:20:38

Hallo Sascha,

wenn Du ein breakout Bord mit Sensoren verlötet, sind die pull-ups mit drauf.

Gruß Peter

sash.sc · 20 Oktober 2016, 19:33:54

Habe nur nen fertigen nodemcu.

Von mobil gesendet daher kurze Antwort

Hagenuck1 · 21 Oktober 2016, 21:03:45

Hab da mal ne blöde Frage... Hatte die Tage nen zweiten RFM69 auf nen Breakout gelötet, dann lt. Schaltplan verbunden.
Wollte das ganze dann Testen und habe dabei gesehen, dass auf dem LGW noch ne 1.17 oder so war, die ja keine Hardware Seite hatte. Dann habe ich durch nen "backup" Befehl das FHEM komplett zerschossen und die Sicherungen wollten auch nicht mehr.

Habe mittlerweile alles wieder eingerichtet und die alte fhem config wieder drin. Verbindung zum LGW wird nun auch aufgebaut, habe das dann nun auch auf die 1.22 aktualisiert. Hier wird mir jedoch auf der Hardware Seite unter "Hardware: Radio 1 & Radio 2 nichts angezeigt. Im LGW Log erscheint allerdings:

"DataPort: #81 received '1,868950,120i v'"
"PCA301: Initialized with 868950 kHz and 120 seconds poll"

Das LGW Device steht allerdings im LGW auf initialized & RAWMSG: "OK VALUES LGW 1302976 UpTimeSeconds=540,UpTimeText=0Tg. 0Std. 9Min. 0Sek. " -> Verbunden ist er also anscheinend und überträgt auch Daten.

Bin nun etwas verwirrt, weshalb bei meinen PCA301 Devices keine Daten mehr im FHEM bekommen

HCS · 21 Oktober 2016, 21:12:10

Zitat von: Hagenuck1 am 21 Oktober 2016, 21:03:45
Hab da mal ne blöde Frage... Hatte die Tage nen zweiten RFM69 auf nen Breakout gelötet, dann lt. Schaltplan verbunden.
Wollte das ganze dann Testen und habe dabei gesehen, dass auf dem LGW noch ne 1.17 oder so war, die ja keine Hardware Seite hatte. Dann habe ich durch nen "backup" Befehl das FHEM komplett zerschossen und die Sicherungen wollten auch nicht mehr.

Habe mittlerweile alles wieder eingerichtet und die alte fhem config wieder drin. Verbindung zum LGW wird nun auch aufgebaut, habe das dann nun auch auf die 1.22 aktualisiert. Hier wird mir jedoch auf der Hardware Seite unter "Hardware: Radio 1 & Radio 2 nichts angezeigt. Im LGW Log erscheint allerdings:

"DataPort: #81 received '1,868950,120i v'"
"PCA301: Initialized with 868950 kHz and 120 seconds poll"

Das LGW Device steht allerdings im LGW auf initialized & RAWMSG: "OK VALUES LGW 1302976 UpTimeSeconds=540,UpTimeText=0Tg. 0Std. 9Min. 0Sek. " -> Verbunden ist er also anscheinend und überträgt auch Daten.

Bin nun etwas verwirrt, weshalb bei meinen PCA301 Devices keine Daten mehr im FHEM bekommen

RFM69 falsch angeschlossen?