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

[PeMue]

Hallo HCS,

ich habe gerade gesehen, dass das RFM69CW und die LoRa Module von HopeRF dasselbe Pinout haben.
Ich weiß, dass Du überhaupt keine Zeit hast, aber meine Idee ist folgende:
Ein Radio wird quasi "geopfert" und für eine serielle (LongRange) Schnittstelle missbraucht, d.h. man kann sie in FHEM bezüglich Baudrate parametrieren und Daten über eine längere Distanz seriell übertragen.
Vermutlich steckt folgender Aufwand dahinter:
- die RFM9x Bibliothek einbinden
- die serielle Schnittstelle parametrierbar machen (statt Radio)
- weiteres, was ich nicht bedacht habe.
Könntest Du Dir das mal bitte anschauen, inwieweit das aus Deiner Sicht Sinn macht bzw. umsetzbar ist.
Ich würde mich dann um die andere Seite (seriell/RS485 aus LoRa) Umsetzer (z.B. für meinen Solarzähler) machen. Ggf. bräuchte ich von Deiner Seite für die Firmware einige Denkanstöße 

Danke + Gruß

PeMue

[HCS]

ich habe gerade gesehen, dass das RFM69CW und die LoRa Module von HopeRF dasselbe Pinout haben.

Ich glaube da hast Du Dich verguckt.
Die LoRa RFM95/96/97/98 haben pro Seite 8 Anschlüsse, das ist das Layout vom RFM69HW aber nicht vom CW.

[PeMue]

Ich glaube da hast Du Dich verguckt.
Die LoRa RFM95/96/97/98 haben pro Seite 8 Anschlüsse, das ist das Layout vom RFM69HW aber nicht vom CW.

Mist, wenn man nicht genau hinschaut. Aber ich schau mir die Hardware trotzdem mal an.

Gruß PeMue

[Omega]

Ich habe mir jetzt ein 2. LGW zusammengebaut, da ich in einigen Räumen bei den PCA301-Steckdosen z.T. leichte Empfangsprobleme hatte.

Wie ist jetzt die beste Vorgehensweise?
Steckdosen in auch im 2. LGW definieren (hart über ,,Setup"-Page)?
Oder neu Anlernen über LaCrossePerForSec?

Obwohl eine Steckdose im LGW_2 noch nicht definiert ist, hat sie bereits als LastInputDevice das neue LGW stehen. Als IODev steht aber immer noch das 1. drin.

Oder gibt es eine Variante, dass sich die Steckdosen / Sensoren selber das beste IODev aussuchen (ähnlich wie die VCCU bei Homematic)? 

LG
Holger

[pc1246]

Moin
Kurzer Statusbericht. Wie es immer so ist, das was man denkt, dass es am einfachsten sei, klappt natuerlich gar nicht! Ich hatte mir gedacht, ich bringe noch eben schnell das Nextion Display in Gang und dann spiele ich die Signalduino firmware auf. Aber Pustekuchen! Ich habe zwei von den LGW's von Locutus aus der ersten Serie. Leider ist da aber kein Anschluss fuer vorgesehen. Da ich aber RXD und TXD gesehen hatte, habe ich da natuerlich mit rumprobiert. Als ich dann endlich gemerkt habe, dass das nichts wird, ist mir dann aufgefallen, dass ich immer noch Bockmist mit den 2fhem Instanzen hatte. Eine slowRF die andere Homematic. Dann wollte sich das auf einmal nicht mehr mit den fhems verbinden lassen. Erst ein Entfernen der Spannungsversorgung hat dann wieder den Normalzustand herbeigefuehrt! Lange rede gar kein Sinn, heute abend geht es weiter. Das Wetter wird ja auch schon wieder zusehends schlechter, da kann ich in ruhe frickeln!
Gruss Christoph

[HCS]

Wie ist jetzt die beste Vorgehensweise?

Ich würde einfach alle Steckdosen manuell mal schalten, dann sollte das zweite LGW (sofern in Reichweite) sie kennen lernen.
Und dann kannst Du die IODev wo erforderlich auf das neue LGW umschreiben.

[Omega]

Danke. Hat so gut funktioniert.
Gibt es eigentlich eine Möglichkeit, die Empfangsqualität der Devices zu erkennen - als Hilfsmittel, das besser geeignete LGW zuzuweisen?

LG
Holger

[pc1246]

Moin
Ich muss jetzt noch mal doof fragen. Also klar ist, dass man auf dem CUL nicht zwei verschiedene Betriebsarten betreiben kann. Aber wie sieht es mit zweimal Homematic mit unterschiedlichen ID's aus? Das scheint mir den CUL immer so aus dem Tritt zu bringen, dass nur Power off hilft. Wenn ich Slow-RF mache, wie entscheidend sind dann die Einstellungen? Weil das meiner Meinung nach auch nur bedingt funktioniert. Die KS300 ist nicht immer im zweiten System vorraetig. Wenn das dann doch eigentlich problematisch ist, sollte man das vielleicht eher wieder ausschalten, bzw. versuchen das auf der HW-Seite des LGW darzustellen, sofern moeglich.
Morgen kommt nun mein drittes LGW, fuer das Nextion!
Grus Christoph

[HCS]

Gibt es eigentlich eine Möglichkeit, die Empfangsqualität der Devices zu erkennen - als Hilfsmittel, das besser geeignete LGW zuzuweisen?

Leider nicht

Moin
Ich muss jetzt noch mal doof fragen. Also klar ist, dass man auf dem CUL nicht zwei verschiedene Betriebsarten betreiben kann. Aber wie sieht es mit zweimal Homematic mit unterschiedlichen ID's aus? Das scheint mir den CUL immer so aus dem Tritt zu bringen, dass nur Power off hilft. Wenn ich Slow-RF mache, wie entscheidend sind dann die Einstellungen?

Das hat jetzt mit "LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino" recht wenig zu tun.
Das LGW stelt den an der Bridge angeschlossenen Arduino, mit was auch immer da drauf ist, transparent auf einem Port zur Verfügung und kümmert sich nicht drum, was da drüber geht.
Aber generell kann es nie sinnvoll sein, ein und den selben CUL zwei verschiedene Dinge tun zu lassen.

Wenn das dann doch eigentlich problematisch ist, sollte man das vielleicht eher wieder ausschalten, bzw. versuchen das auf der HW-Seite des LGW darzustellen, sofern moeglich.

Sorry, verstehe nicht, was Du meinst.

[pc1246]

Sorry
Hatte noch nen Kampf mit nem Samsung Fernseher, der irgendwie HDMI und LAN nicht gleichzeitig mag, und dann irgendwie die VU+ lahmlegt!
Also ich definiere irgendwann einmal den "transparenten" CUL. Irgendwann faellt mir ein, dass es ja praktisch ist, den mit zwei fhem's zu nutzen. Also nochmal definiert, und schon passt etwas nicht! Ob nun der Mode, die HMid, oder oder oder. Bei den anderen Funkmodulen wird ja auch dargestellt, was Sie machen, also quasi eine Rueckmeldung. Bei der Bridge irgendwie nicht, und das war halt meine Idee, wenn es moeglich waere. Ist fuer mich jetzt aber gegessen, da mir das zu oft schon Probleme bereitet hat.
Jetz versuche ich gerade das Nextion an das neue GW zu knoepern. Das will aber noch nicht so richtig. Geht dann heute nachmittag weiter, in 5 Stunden klingelt der Wecker!
Gruss Christoph

[HCS]

Bei den anderen Funkmodulen wird ja auch dargestellt, was Sie machen, also quasi eine Rueckmeldung. Bei der Bridge irgendwie nicht, und das war halt meine Idee, wenn es moeglich waere.

Die RFMs sind ja auch im LGW implementiert. Darum weiß das LGW, was da abläuft.
Du must Dir die Bridge wie ein langes USB-Kabel von FHEM bis zum Arduino mit der culfw vorstellen.
Wenn das LGW verstehen wollte, was da abläuft, müsste es alle Protokolle verstehen, die da durch gehen könnten (CUL, Signalduino, ...)

Allerdings würde ich mal vermuten, dass es da einen Bug in der CUL firmware gibt. Es sollte eigentlich nicht machbar sein, sie durch (auch unsinnige) Kommandos so abstürzen zu lassen
, dass nur noch ein power on reset hilft.

[Christian Uhlmann]

Hallo HCS,

erst einmal vielen Dank für deine tolle Arbeit an dem Modul und der Firmware. Bin echt begeistert

Ich habe da eine Erweiterungsanfrage, ist es wohl möglich den BMP280 (nicht BME280 und nicht BMP180) auch mit einzubinden in die Firmware?
ESPEasy kann diesen Sensor anbinden (https://www.letscontrolit.com/wiki/index.php/BMP280) und ich habe ein paar davon.

Vom Preis her sind die auch recht günstig und gut zu bekommen, zusammen mit einem DHT22 kann man dann sehr gut und günstig Temperatur, Luftfeuchtigkeit und Luftdruck messen.


Danke und Grüße

Christian

[locutus]

Allerdings würde ich mal vermuten, dass es da einen Bug in der CUL firmware gibt. Es sollte eigentlich nicht machbar sein, sie durch (auch unsinnige) Kommandos so abstürzen zu lassen
, dass nur noch ein power on reset hilft.

Schuld an dem Verhalten ist der Arduino Bootloader.
https://wiki.fhem.de/wiki/Selbstbau_CUL#Hinweise_zum_Betrieb_mit_FHEM

[SusisStrolch]

@locutus, an deinen Boards ist doch ein GPIO an den CUL Reset geklöppelt?
Könnte man da nicht im LGW einen CUL-Reset implementieren?

[locutus]

Das ist die DTR-Leitung. Über RX, TX und DTR wird der µC mit der Firmware gefüttert.
Hardwareseitig wäre eine zusätzliche Transistorschaltung an einem freien GPIO erforderlich.
Die LGW Software müsste ein GPIO zum schalten des Transistors zur Verfügung stellen.