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

[HCS]

Danke für deine Geduld (du wirst noch mehr davon brauchen  )

Habe mir zur Sicherheit noch eine Schachtel Geduld gekauft, bekommen wir schon hin 

So ganz habe ich es noch nicht verstanden – ich versuche mal:
868295#1f   -- > Radio 1 auf 868295 MHz (f=Frequenz)
3#1m      -- > Radio1: Toggle-Mode 3 (m=toggle mode). Die 3 ist vermutlich binär zu sehen (17241 UND 9579)
20#1t      -- > Radio1: toggle data rate interval 20 Sekunden
2,868950,60i   -- > vermutl. die PCA301-Initialisierung (ich vermisse ein #2, deswegen habe ich ein Problem mit der Zuordnung)

Der Rest ist mir klar, wobei das ,,v" nicht ausgereicht hat zur Aktualisierung. Erst nach einem Reset hatte das LGW meine initCommands umgesetzt.

Soweit richtig verstanden. Die PCA301 Initialisierug (die es offiziell noch gar nicht gibt, hätte ich sie nur rausgelassen) hat ein anderes Format:
<Radio>,<Frequenz>,<Poll-Interval>
Sobald ich die erste Beta mit PCA301 rausgebe, beschreibe ich das dann nochmal ausführlich

Nach dem Ändern der initCommands muss man immer einen Reset auf dem JeeLink auslösen, das "v" dient nur dazu, dass (nach dem Reset) der Sketch seine aktuelle Konfiguration an FHRM zurückschickt (informativ), dass sie in dem Internal "model" (nach einem manuell durchzuführenden Page-Reload in FHEM) angezeigt wird.

Im KeyValueProtocol_LGW_16446580 war eingetragen als IODev: myJeeLink (das ist aber mein JeeLabs-Stick). Vermutl. kam das durch das automatische Anlegen vom KeyValueProtocol_LGW_16446580.
Nachdem ich das IODev auf LaCrosseGateway (der von mir vergebene Name) umgesetzt habe, waren die Fehlermeldungen weg.

FHEM (nicht das LaCrosse-Modul) ermittelt automatisch ein passendes IODev. Wenn man mehrere Kandidaten hat, die in Frage kommen, erwischt es regelmäßig das falsche, passiert mir auch öfters.
Ich müsste mal die Logik dahinter erforechen, aber ich denke, dass das über MatchList und Clients geht und zwei vorhandene JeeLink devices sind halt schlicht gleichwertig und es gibt vermutlich nichts, woran festgemacht werden könnte, welches davon nun das richtige wäre.

Im KeyValueProtocol_LGW_16446580 war eingetragen als IODev: myJeeLink (das ist aber mein JeeLabs-Stick). Jetzt verbleibt noch das Phänomen mit stateFormat. Selbst ein Löschen und Neuanlegen des Devices bringt keine Änderung. Ich kann in stateFormat schreiben was ich will (zuerst wird es scheinbar angenommen) aber nach einem erneuten Aufruf des Devices steht immer T: 22.8 H: 38 D: 7.8 im STATE (selbst dann, wenn kein stateFormat definiert ist). Die Werte selbst werden aktualisiert.

Funktioniert stateFormat bei anderen devices bei Dir korrekt wie es soll?
Weil, stateFormat ist ein readingFnAttribute, damit macht 36_LaCrosse.pm selbst überhaupt nichts, es kommt von FHEM mit dazu.

Wobei, gerade sehe ich es bei mir:
stateFormat: T: temperature H: humidity P: pressure

Auf der page vom device:
Internal "STATE": T: 21 H: 53 P: 993
Reading "state": T: 21 H: 53

Darstellung in WebFrontend: T: 21 H: 53 P: 993

Allerdings steht bei mir das stateFormat dauerhaft drin, auch wenn ich das device erneut öffne und auch nach einem FHEM-Neustart.

[Omega]

Mein Nachtrag im vorigen Post (Nachtrag: nach ca. 1h (ohne weitere Änderungen meinerseits) war das stateFormat mit einem Mal korrekt umgesetzt (wie gut das Datenverarbeitung so wenig mit Logik zu tun hat  )) hat sich mit deiner Antwort überschnitten.
stateFormat sehe ich momentan als gelöst an. Hatte ich vorher schon so bei anderen Devices erfolgreich eingesetzt gehabt, daher meine Vermutung, dass es irgendwie mit dem LGW zu tun haben muss.

Dann ist ja momentan alles in Butter - danke noch mal
und - das mit dem PCA301

Die PCA301 Initialisierug (die es offiziell noch gar nicht gibt, hätte ich sie nur rausgelassen)

finde ich guuut - ich habe doch schon extra ein paar gekauft zum Üben 

[HCS]

Mein Nachtrag im vorigen Post (Nachtrag: nach ca. 1h (ohne weitere Änderungen meinerseits) war das stateFormat mit einem Mal korrekt umgesetzt (wie gut das Datenverarbeitung so wenig mit Logik zu tun hat  )) hat sich mit deiner Antwort überschnitten.

Der ist mir entgangen, egal.

Dann ist ja momentan alles in Butter - danke noch mal

Prima.

und - das mit dem PCA301finde ich guuut - ich habe doch schon extra ein paar gekauft zum Üben 

Mehr als in die Steckdose stecken kann man aktuell halt nicht üben ... 
Aber ich arbeite an dem Thema. Wenn ich geahnt hätte ....

[Wzut]

Ich habe heute einen RFM69HCW geschenkt bekommen.
Hat den schon mal jemand erfolgreich als LaCrosse Empfänger getestet ?
Laut Datenblatt dürfte der ausser einer anderen Pinbelegung eigentlich nur eine größere Sendeleistung als der CW haben ?

[Omega]

Folgende Kleinigkeit ist mir aufgefallen. Ich habe das GW kurz stromlos gemacht, dann wieder neu angesteckt. Seitdem kommen keine Daten mehr in FHEM an. Die Aktivity-LED blinkt auch wieder, d.h. für mich: anscheinend wurde das initCmd nicht oder nicht richtig übergeben.

Ich habe dann ein explizites

Code Auswählen Erweitern


set LaCrosseGateway reset

ausgelöst. Danach war wieder alles iO.

Irgendwie hapert es anscheinend noch am Zusammenspiel zwischen FHEM und dem LGW bei einem Neustart.

LG
Holger

[HCS]

Irgendwie hapert es anscheinend noch am Zusammenspiel zwischen FHEM und dem LGW bei einem Neustart.

Das Problem ist, dass wenn das LGW einfach verschwindet, FHEM das nicht mitbekommt und den Port nicht schleißt und erneut versucht zu öffnen, wie es z.B. passiert, wenn man ein USB-device abzieht und wieder steckt.

Aus diesem Grund gibt es im JeeLink device das Attribut "timeout"
Beispiel: attr myJeeLink timeout 120,60
legt fest, dass wenn 120 Sekunden lang keine Daten mehr gekommen sind, der Port geschlossen und neu geöffnet wird, was zu Folge hat, dass eine neue Verbindung zum LGW aufgebaut wird und auch die initCommands wieder geschickt werden.
Die 60 bedeutet, alle 60 Sekunden prüfen.
In diesem Beispiel wird also nach frühestens 120 und spätestens 180 Sekunden bemerkt, dass vom LGW keine Daten mehr kommen und dann alle 60 Sekunden versucht, eine neue Verbindung aufzubauen.
Die Zeiten nicht zu klein wählen, sonst könnte es passieren, dass ein neuer Reset ausgelöst wird, obwohl das LGW wieder da ist aber noch hochfährt und darum noch nicht geantwortet hat.

Zusammenfassung: timeout 120,60 macht automatisch das, womit Du es manuell geregelt hast.

[Omega-5]

Ich habe heute einen RFM69HCW geschenkt bekommen.
Hat den schon mal jemand erfolgreich als LaCrosse Empfänger getestet ?
Laut Datenblatt dürfte der ausser einer anderen Pinbelegung eigentlich nur eine größere Sendeleistung als der CW haben ?

Ich habe einen RFM69HW V2.0 868MHz dran. Ohne C, der klappt einwandfrei.

Gruß Friedrich

[Omega]

Zusammenfassung: timeout 120,60 macht automatisch das, womit Du es manuell geregelt hast.

Super  . Ich hatte schon befürchtet, mir einen Watchdog definieren zu müssen

[Doublefant]

spitze!
Über dieses Problem bin ich beim Experimentieren auch schon öffters gestolpert. Allerdings habe ich den Grund nicht herausgefunden.
Fazit war, wenn es erstmal läuft dann überträgt es auch stabil Daten. Falls nicht, muss man alles komplett neustarten.

Danke für die Erklärung mit dem timeout 

[HCS]

NanoLGW

Ich habe was gebraucht, das ich an das MacBook stecken kann zum Entwickeln. Hatte keine Luste mehr, breadboard und Kabel am Apfel-Gerät hängen zu haben.

Ergebnis siehe Bilder.
Gehäuse: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=36507
ESP-12E
Auto-Flash-Reset-Schaltung mit zwei Widerständen
CP2102 FTDI http://www.aliexpress.com/item/6Pin-USB-2-0-to-TTL-UART-Module-Serial-Converter-CP2102-STC-Replace-Ft232/32364013343.html?spm=2114.13010208.99999999.261.mWmpl5
breakout board mit einem AMS 1117 3.3V
ein RFM69CW
Status-LED

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.

Was auch interessant ist: obwohl der ESP-12E und der RFM69 direkt aufeinander sitzen, hat es wifi Empfang quer durchs Haus und kommuniziert vom 1. OG aus mit einer PCA301 im Keller.

Nachtrag: Schaltplan angehängt

[Omega-5]

CP2102 FTDI http://www.aliexpress.com/item/6Pin-USB-2-0-to-TTL-UART-Module-Serial-Converter-CP2102-STC-Replace-Ft232/32364013343.html?spm=2114.13010208.99999999.261.mWmpl5

Nur zur Klarstellung der CP2102 ist von SILABS und ein Ersatz für den FT232R von FTDI. 

Auto-Flash-Reset-Schaltung mit zwei Widerständen

Und das klappt mit der Standardsoftware? Die Transistorschaltung ist ja, wenn ich das richtig interpretiere, quasi eine EXNOR Schaltung mit hochohmig (OPEN) bzw. LO (GND) Ausgang. 

Gruß Friedrich

[HCS]

Und das klappt mit der Standardsoftware?

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.

Code Auswählen Erweitern

                    < 5ms ><       50ms     >     
RTS (RST)    1 -----       ------------------------------------
             0      |-----|

DTR (GPIO0)  1 -----------                    ---------------
             0            |------------------|


GPIO0 = low:  flash
GPIO0 = high: run
Reset bei steigender Flanke an RST oder EN

EN, RST und GPIO0 mit 10k Pullup und
RTS über 470 Ohm -> EN
DTR über 470 Ohm -> GPIO0

[HCS]

... wenn ich das richtig interpretiere, quasi eine EXNOR Schaltung ...

Naja, nicht so wirklich, ein EXNOR hat nur einen Ausgang ...
Eigentlich zwei Inverter mit "Enable NOT" oder so, keine Anhnung, ob diese Schaltung einen Namen hat ... 

[HCS]

Zitat
    Die PCA301 Initialisierug (die es offiziell noch gar nicht gibt, hätte ich sie nur rausgelassen)

finde ich guuut - ich habe doch schon extra ein paar gekauft zum Üben 

Zitat von: HCS am 07 Januar 2016, 13:19:19
    #3: PCA301

Funktioniert das schon? ... Steckdose habe ich schon mal vorsichtshalber hier liegen 

Haben eure PCA301 Lust, an einem Pre-Beta-Test teilzunehmen?

Falls ja, dann anbei die LGW-Firmware.

Beschreibung:
PCA301 im LGW funtioniert ähnlich dem PCA301 Sketch, allerding mit einigen systembedingten Abweichungen.
Per default ist PCA301 nicht aktiviert, es muss in den initCommands aktiviert werden. Dazu gibt es das command "i".

Code Auswählen Erweitern

<RadioNr>,<Frequenz>,<Poll-Intervall>i
Beispiel: 2,868950,120i initialisiert den zweiten RFM auf 868950 MHz und setzt das Poll-Intervall auf 120 Sekunden
Die Initialisierung kann auch erneut geschickt werden, um z.B. das Poll-Intervall zu ändern.
Man darf aber nur ein Radio für PCA301 initialisieren, nicht mehrere. Und das Radio ist dediziert für PCA301, es kann nicht noch LaCrosse "nebenbei" machen.
Dafür kann man ja aber bis zu drei Radios anschließen.

Man sollte das Poll-Interval nicht extrem runtersetzen (unter eine Minute), da PCA301 sonst LaCrosse verdrängt, es hat Prio, da es bei der Kommunikation
mit den Dosen keine Antworten überhören darf.

Eine komplette Initialisierung eines LGW mit zwei Radios könnte also z.B. so aussehen, wenn man TX29, TX35, PCA301 und BMP180 hat:
attr myJeeLink initCommands 1,868950,120 3#2m 20#2t 220h 0a v
Das erste Radio macht PCA301 und das zweite toggelt 17241/9579 im 20 Sekunden Takt um TX29 und TX35 zu empfangen und der BMP180 liefert den Druck für 220m Meereshöhe und die LED ist deaktiviert

Nachdem PCA301 initialisiert ist, lauscht das LGW auf der entsprechenden Frequenz.
Sobald eine Dose empfangen wurde, wird sie in der Konfiguration (EEPROM) dauerhaft registriert und ab sofort gepollt.
Das polling funtioniert so, dass für jede Dose geschaut wird, wann sie zuletzt empfangen wurde und wenn das länger als das konfigurierte Interval zurück liegt,
dann wird sie abgefragt. Wenn sonst etwas (Basisstation, anderes FHEM) die Dose abgefragt hat und das LGW die Antwort gehört hat, dann gilt das auch als
empfangen und es wird kein eigener Poll für die Dose ausgelöst. Das Zusammenspiel mit einer echten Basisstation konnte ich aber nur grob simulieren, da ich keine habe.

Das Pairing (also die Vergabe eines Kanals) funktioniert wie im PCA301-Sketch, button an der Dose 3 Sekunden drücken, dann vergibt das LGW den nächsten freien Kanal.
Dosen, die bereits einen Kanal haben, kann man das LGW einfach dadurch lernen lassen, dass man sie einmal vorort schaltet. Das LGW erkennt sie und nimmt sie in die
Konfiguration auf. Falls die Dose bereits mit einem anderen Kanal bekannt war, wird der Kanal im LGW aktualisisert.

Auf der Setup-Page im Web-Frontend des LGW kann man die Liste der bekannten Dosen (ID=Kanal) sehen. Man sollte daran aber kein Änderungen vornehmen.

Wenn ein Kommando (Schalten, Daten abfragen, ...) an eine Dose gesendet wurde und keine Antwort kam, wird bereits im Sketch drei mal versucht, eine Antwort zu bekommen.
Aktuell werden maximal 16 Dosen unterstützt.

Das PCA301 Modul in FHEM funktioniert komplett wie bisher (hoffentlich)
Den restlichen PCA301-Teil in FHEM kann man sich im wiki, PCA301Thread, ... anschauen, hier gibt es keine Unterschiede.

Die Commands, die der PCA301-Sketch kennt, gibt es im LGW nur teilweise:

Code Auswählen Erweitern

a "turn activity LED on or off
-> wie bisher
l "list known devices"
-> entfallen, kann man nun im Web-Frontend sehen
q "turn quiet mode on or off"
-> wie bisher
r "list recordings"
-> entfallen
s "send to plug"
-> wie bisher
v "report version and configuration parameters"
-> wie bisher
d, e, p "poll / turn a device on / off"
-> entfallen
h, +, -, # "modify and display RF12 Frequency register"
-> entfallen, ersetzt durch das "i" command bzw. das bereits vorhandene "f" command

Edit: Anhang gelöscht, siehe weiter unten

[Omega]

Leider klemmt es irgendwo.

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.

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.

Ein List meines LGW:

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 95
   LaCrosseGateway_TIME 2016-01-17 15:28:44
   NAME       LaCrosseGateway
   NR         740
   PARTIAL
   RAWMSG     OK VALUES LGW 16446580 UpTimeSeconds=1763,UpTimeText=0Tg. 0Std. 29Min. 23Sek. ,WIFI=WLAN4Me,MacAddress=18:FE:34:FA:F4:74,ChipID=16446580,ReceivedFrames=490,FramesPerMinute=23,RSSI=-42,FreeHeap=22504
   STATE      Initialized
   TYPE       JeeLink
   initMessages
   model      [LaCrosseITPlusReader.Gateway.1.11 (1=RFM69 f:868295 t:20~3) + (2=RFM69 f:868950 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 15:25:44   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 2,868950,120i 96h 0a v
   room       LaCrosse
   timeout    120,60


Ein Pairing mit einer Dose funktioniert auch nicht.

Ich könnte jetzt ja auch über USB flashen, möchte aber die Option OTA doch gerne richtig einsetzen, bevor ich weiter teste.