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

[PeMue]

NanoLGW

Das alles in das Gehäuse zu bekommen und drin zu verdrahten ist aber nichts für schwache Nerven 
@PeMue: das wäre noch cooler auf einer Platine (nee lass mal, das brauchen wohl nicht viele)
Muss nur noch einen BMP 180 oder zumindest einen LM75 reinbekommen (notfalls mit dem Hammer) dass sich auch auf dem I2C Bus was abspielt.

Das Gehäuse ist kein Problem, das gibt es bei Conrad auch in transparent und ich habe schon Platinen dafür gemacht (Bibliothek ist vorhanden  ).
Wenn das nanoLGW auch mit PCA301 funktioniert, dann hätte ich sogar ein gewisses Eigeninteresse.
Wenn Du einen Schaltplan hast, kannst Du ihn mir ja mal zukommen lassen, dann schaue ich mir das Ganze an, wenn der "großen" LGW fertig ist ...

Gruß PeMue

[HCS]

Zuerst habe ich mich mal mit dem OTA-Update auseinandergesetzt. Ich bin mir nicht sicher, ob das Update funktioniert hat, da sich mein LGW immer noch mit Version 1.11 meldet.

Wenn ich schlau gewesen wäre, hätte ich die Version hochgesetzt 
Du kannst es daran erkennen, dass es auf der Setup-Page vom LGW einen Abschnitt mit der Überschrift "PCA301 (normally no need to change it)" gibt.

Beim Aufruf von http://<ip des FHEM-Servers>:8083/fhem/firmware/LaCrosseGateway.bin erhalte ich direkt die Datei im Browser (als nicht wirklich lesbarer Text). Als Download bekomme ich die Datei nicht angeboten.

Ist OK, das hängt vom Browser ab. Manche starten einen Download und manche zeigen es an.

Ein List meines LGW:
Internals:
   STATE      Initialized
   model      [LaCrosseITPlusReader.Gateway.1.11 (1=RFM69 f:868295 t:20~3) + (2=RFM69 f:868950 r:6631) + BME280 {IP=192.168.0.28}]
Attributes:
   initCommands 868295#1f 3#1m 20#1t 2,868950,120i 96h 0a v
   timeout    120,60

Sieht aber gut aus. Den "2,868950,120i" hat es übernommen, sonst wäre das nicht gesetzt: "2=RFM69 f:868950 r:6631"

Evtl. hast Du ein wohl bei PCA301 verbreitetes Problem mit der Frequenz. Probier mal 868970 und 868990 aus.
Bei einem von meinen RFM69 muss ich auch 868970 setzen, dass es läuft.

[HCS]

Wenn das nanoLGW auch mit PCA301 funktioniert, dann hätte ich sogar ein gewisses Eigeninteresse.

Bei mir funktioniert es. Aber dann halt nur mit PCA301, weil mit nur einem einzigen Radio nichts weiteres geht.
Aber ein NanoLGW, bei dem man wifi abschaltet (die Option dafür ist übrigens als Command implementiert), wäre auch ein netter JeeLink-Ersatz, mit deutlich mehr Rechenleistung und mehr Speicher.
Das Volumen der benötigten Verbindungsleitungen entspricht ungefähr einem RFM69.   
Evtl. bekommt man ja auch zwei rein und verzichtet komplett auf lokale Sensoren.

Wenn Du einen Schaltplan hast, kannst Du ihn mir ja mal zukommen lassen, dann schaue ich mir das Ganze an, wenn der "großen" LGW fertig ist ...

Muss ich Bleistifte spitzen und malen, sobald er fertig ist, hänge ich ihn an.

[Omega]

Leider keinen Erfolg.
Den Abschnitt mit der Überschrift "PCA301 (normally no need to change it)" habe ich, d.h. OTA hat zumindest funktioniert.

Ich habe mit 3 Steckdosen alle 3 Frequenzen durchprobiert – nichts. Vorsichtshalber habe ich sogar mit und ohne LaCrossePairForSec getestet (bin mir nicht sicher, ob es benötigt wird oder nicht).

Danach habe ich Kabel an einen weiteren RFM69CW gelötet und auch noch auf dem Steckbrett untergebracht. Auch hier bei allen 3 Frequenzen und allen 3 Steckdosen leider nichts.

Noch mal ein List, jetzt mit den 3 RFM und dem zuletzt verwendetem initCommands

Code Auswählen Erweitern


Internals:
   Clients    :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
   DEF        192.168.0.28:81
   DeviceName 192.168.0.28:81
   FD         92
   LaCrosseGateway_MSGCNT 3849
   LaCrosseGateway_TIME 2016-01-17 18:04:00
   NAME       LaCrosseGateway
   NR         740
   PARTIAL
   RAWMSG     OK 9 15 1 3 222 88
   STATE      Initialized
   TYPE       JeeLink
   initMessages
   model      [LaCrosseITPlusReader.Gateway.1.11 (1=RFM69 f:868295 t:20~3) + (2=RFM69 f:868300 r:8842) + (3=RFM69 f:868990 r:6631) + BME280 {IP=192.168.0.28}]
   Matchlist:
     1:PCA301   ^\S+\s+24
     2:EC3000   ^\S+\s+22
     3:RoomNode ^\S+\s+11
     4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
     5:AliRF    ^\S+\s+5
     6:EMT7110  ^OK\sEMT7110\s
     7:KeyValueProtocol ^OK\sVALUES\s
   Readings:
     2016-01-17 18:02:48   state           opened
Attributes:
   flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
   initCommands 868295#1f 3#1m 20#1t 8842#2r 3,868990,120i 96h 0a v
   room       LaCrosse
   timeout    120,60


Zwischen den Änderungen in den initCommands habe ich das LGW sogar immer stromlos gemacht, damit nur ja die Änderung auch durchkommt (obwohl ich in der Oberfläche sehen konnte, das alles ok sein müsste).

[Omega-5]

Ja, sowohl aus meiner Entwicklungsumgebung heraus als auch mit dem ESP8266Flasher (NODEMCU FIRMWARE PROGRAMMER).
Mit dem ESP8266Flasher kann ich die LGW Firmware oder auch NodeMCU problemlos auf das NanoLGW flashen.
Wobei ich den Reset über EN auslöse und nicht über RST, was aber beides funktioniert.

Nachdem ich mir mal angeschaut hatte, wie RTS und DTR für einen flash angesteuert werden, lag die Vermutung auch nahe.

Ich war mir nicht ganz sicher ob das mit dem ESP8266Flasher klappt, weil beim esptool ein Parameter -cd <board> angegeben werden muss, der die Unterscheidung für verschiedene Beschaltungen berücksichtigt. https://github.com/igrr/esptool-ck Readme.md "Supported boards".

Gruß Friedrich

[HCS]

Leider keinen Erfolg.

Konntest auch keinen haben, ausgerechnet das Pairing hat nicht mehr funktioniert und das habe ich schon lange nicht mehr gemacht.
Anbei ein neuer Anlauf. Am besten erst mal wieder auf 868950 zurück.
Und vor dem pairen warten, bis FHEM sich mit dem LGW wieder verbunden hat, dass das initCommand geschickt wurde.
Wenn das LGW eine Dose kennen gelernt hat, muss auf der Setup-Page etwas eingetragen sein.

... weil beim esptool ein Parameter -cd <board> angegeben werden mus, der die Unterscheidung für verschiedene Beschaltungen berücksichtigt.

Ja, die Flash-Methode, die funktioniert, ist "nodemcu". Ich glaube "ck" geht nicht.

Nachtrag: Anhang entfernt, da nun eingecheckt

[Omega]

  Juchuu – es funktioniert auf Anhieb (als Version 1.12  ).

Zuvor hatte ich mal meinen JeeLink umgeflashed auf PCA301. Da wurde die Steckdose sofort erkannt und funktioniert auch einwandfrei. Da wusste ich wenigstens, dass die Dosen iO sind.

Morgen starte ich dann mit einer vernünftigen Testeinbindung.

Danke
Holger

[AxelSchweiss]

Konntest auch keinen haben, ausgerechnet das Pairing hat nicht mehr funktioniert und das habe ich schon lange nicht mehr gemacht.
Anbei ein neuer Anlauf. Am besten erst mal wieder auf 868950 zurück.
Und vor dem pairen warten, bis FHEM sich mit dem LGW wieder verbunden hat, dass das initCommand geschickt wurde.
Wenn das LGW eine Dose kennen gelernt hat, muss auf der Setup-Page etwas eingetragen sein.
Ja, die Flash-Methode, die funktioniert, ist "nodemcu". Ich glaube "ck" geht nicht.

Mit der neuen Firmware funktionierts bei mir ... like a charm
Habe noch schnell ein Radio drangelötet nachdem der FHEM-Nachwuchs im Bett war. 
Danach nach Schema F konfiguriert mit 1,868950,120i 200h v
Statuszeile: [LaCrosseITPlusReader.Gateway.1.12 (1=RFM69 f:868950 r:6631) + BMP180 {IP=192.168.11.140}
Die Steckdose wurde automatisch erkannt und eingebunden.

Super ... Vielen Dank ...  jetz bestell ich noch n paar Radios

[Billy]

So jetzt bin ich auch mal für meine PCA301 eingestiegen!

Konfiguriert mit 1,868950,120i v
model: [LaCrosseITPlusReader.Gateway.1.12 (1=RFM69 f:868950 r:6631) {IP=192.168.148.121}]
Die 11 Steckdose wurde automatisch erkannt und eingebunden.

Folgendes ist mir augefallen!
In FHEM werden die channels grösser 10 in HEX ausgegeben, im LCG Web dezimal.
Bsp. ein list channel in FHEM --> PCA301_03A6E2  11 --> im Web 03A6E2=17
Das war zuerst etwas verwirrend! Da auch die DEF   --> mit  03A6E2 11 den Kanal 11 ausweist.

Ein PCA --> NAME PCA301_0FA6A6 reagiert etwas träge beim Schalten. Rückmeldung on/off hängt manchmal.
beim Schalten mit dem Jeelink gehts deutlich besser?
Wie gesagt das ist nur einer von 11. Interessanterweise wurde der auch als letzter durch autocreate erkannt.

Ansonsten kann ich mich nur meinen Testkollegen anschließen tolle Arbeit und vielen Dank an HCS.

Gruß Billy

Billy

[HCS]

In FHEM werden die channels grösser 10 in HEX ausgegeben, im LCG Web dezimal.
Bsp. ein list channel in FHEM --> PCA301_03A6E2  11 --> im Web 03A6E2=17

Habe mir in die ToDo geschrieben, dass es HEX werden sollte.
Wenn man nur drei Dosen besitzt, merkt man das nie 

Ein PCA --> NAME PCA301_0FA6A6 reagiert etwas träge beim Schalten. Rückmeldung on/off hängt manchmal.
beim Schalten mit dem Jeelink gehts deutlich besser?
Wie gesagt das ist nur einer von 11. Interessanterweise wurde der auch als letzter durch autocreate erkannt.

Kannst Du "etwas träge" grob in eine Zeit umsetzen? Sekunde, halbe Sekunde, ...
Das könnte auch die Frequenz sein. Der JeeLink mit einem RFM12 liegt sicher mit der Frequenz ein klein wenig anders als der RFM69
Wenn die Dose nicht antwortet oder die Antwort nicht gehört wird, dann wird bis zu drei mal versucht, mit ein wenig Pause dazwischen.
Evtl. klappt das bei der Dose nie auf Anhieb und mit jedem Versuch zieht sich die AFC entwas näher ran, bis der RFM was empfängt, das er auch versteht.
Das habe ich aber gerade in meiner leeren Kaffeetasse gesehen, kann natürlich auch einen völlig anderen Grund haben.
Kommt, wenn Du die Dose lokal schaltest, der Lampenumschlag in FHEM schnell oder auch verzögert?

Generell sind aber die Antwortzeiten mit dem LGW mit PCA301 etwas schlechter als mit dem PCA-Sketch, weil das LGW die Daten an FHEM bündelt (also nur alle 250 ms etwas an FHEM sendet) um den Protokoll-Overhead, der für jeden einzelnen Datenschnipsel entstehen würde, zu minimieren.

[Omega]

Das LGW ist doch zunächst mal losgelöst von einer FHEM-Installation. Erst über ein

Code Auswählen Erweitern


define LaCrosseGateway JeeLink 192.168.0.28:81

verbinde ich es per WLAN mit FHEM.

Ich habe derzeit bei mir eine 2. FHEM Installation. Kann ich auch hier das gleiche LGW zuweisen (evtl. über einen anderen Port)? Testhalber habe ich es mal definiert, bekomme aber nur den Status ,,opened" und nicht ,,Initialized".
Verwende ich den Port 82, bekomme ich nur ein ,,disconnected" als Status. Da fehlt aber evtl. auch die Eingabe des Ports auf der Setup-Seite.

Bevor ich weiter experimentiere, frage ich dann doch lieber mal nach (mein MySensorsGateway, das auch auf dem ESP8266-12 basiert, kann ich auf beiden Installationen verwenden).

[HCS]

Das LGW ist doch zunächst mal losgelöst von einer FHEM-Installation.

Richtig.

Erst über ein

Code Auswählen Erweitern


define LaCrosseGateway JeeLink 192.168.0.28:81

verbinde ich es per WLAN mit FHEM.

Eigentlich umgekehrt, das LGW stellt Datenports (default nur Port 81) zur Verfügung und FHEM verbindet sich drauf.

Ich habe derzeit bei mir eine 2. FHEM Installation. Kann ich auch hier das gleiche LGW zuweisen (evtl. über einen anderen Port)?

Ja. Zuerest musst Du auf der Setup-Page des LGW bei "Data ports" einen weiteren Port definieren (z.B. 82)
Nach dem Speichern der Settings incl. Reboot kann man dann ein FHEM (JeeLink device) auf 192.168.0.28:81 und ein zweites auf 192.168.0.28:82 konfigurieren.
Die initCommands der beiden FHEM müssen aber gleich sein, da nicht sicher ist, ob sich evtl. nur eins verbindent oder wenn beide in welcher Reihenfolge.
Falls die initCommands unterschiedlich sind, gewinnt dann das FHEM, das sich zuletzt verbindet.
Wenn man die initCommand nur bei einem einträgt, dann bekommt das ohne erst dann Daten, die der Konfiguration entsprechen, wenn sich das andere mit den initCommands verbunden hat.
Das ist generell nicht schlimm, außer bei der Höhenkorrektur für den Luftdruck, weil es im Plot unschöne Beulen gibt.

Zwei angekoppelte FHEMs in Verbindung mit PCA301 habe ich aber noch nicht ausprobiert. Sollte aber auch gehen, zumindest theoretisch, wie immer halt, ...

Der angestrebte usecase ist, dass:
1.: ein LGW mehrere FHEM versogen kann
2.: ein FHEM sich bei mehreren LGW bedienen kann (weil z.B. eine Empfangsposition nicht für das komplette Areal reicht)
3.: 1. + 2.

Aber ausgetestet habe ich das in allen denkbaren Varianten nicht so ganz ...

[Billy]

Kannst Du "etwas träge" grob in eine Zeit umsetzen? Sekunde, halbe Sekunde, ...

Interessant ist, dass der entsprechende PCA auch in der list PCA.* myJeeLink_TIME hängt!
d.h. seit ca. 12 Minuten kein Time update bekommt.

Code Auswählen Erweitern

PCA301_019E87        2016-01-18 16:10:03
PCA301_01A220        2016-01-18 16:10:03
PCA301_03A6E2        2016-01-18 16:10:09
PCA301_055640        2016-01-18 16:10:48
PCA301_061F30        2016-01-18 16:10:46
PCA301_06CAAD        2016-01-18 16:10:01
PCA301_076299        2016-01-18 16:10:01
PCA301_09F383        2016-01-18 16:09:25
PCA301_0EB463        2016-01-18 16:10:45
PCA301_0EB59F        2016-01-18 16:11:15
PCA301_0FA6A6        2016-01-18 15:58:07

Das mit der Frequenz änderung werde ich mal testen.

Kommt, wenn Du die Dose lokal schaltest, der Lampenumschlag in FHEM schnell oder auch verzögert?

Ja auch dann!

[Omega]

Zwei angekoppelte FHEMs in Verbindung mit PCA301 habe ich aber noch nicht ausprobiert. Sollte aber auch gehen, zumindest theoretisch, wie immer halt, ...

Gleich der 1. Test war erfolgreich. Ich kann die Steckdose von beiden Seiten schalten, der jeweilige Schaltzustand wird auf auf beiden Seiten korrekt dargestellt.
Das erspart mir jetzt eine FHEM2FHEM-Verbindung, die ich bisher in Verbindung mit einer Homematic-Schaltsteckdose verwendet habe.

[Billy]

Das könnte auch die Frequenz sein. Der JeeLink mit einem RFM12 liegt sicher mit der Frequenz ein klein wenig anders als der RFM69

So, habe die Frequenz auf 868960 gesetzt jetzt funkt alles bestens.
Mit 868970 war's schon wieder schlechter!

Alle 11 PCA's schalten jetzt problemlos!
Wenn ich mit dem Jeelink z.B auf off schalte, dann wird spätestens nach dem Poll Intervall der state im Gateway-FHEM auf off geändert.
Mit einem statusRequest wird die Änderung sofort angezeigt.