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

[HCS]

... aber es werden keine Devices angelegt (autocreate ist an). Was fehlt mir noch??

Häng mal bitte ein "list myLeeLink" hier an.
Hast Du ein KeyValueProtocol device bekommen oder das auch nicht?

[HCS]

... nach dem Connect ein Absturz, Reboot und dann wieder von vorne mit anscheinend leerem Flash und als AP. 
Nach Neueingabe über das Webinterface und Neustart --> alles O.K. 

Ich habe schon einige Zeit den Verdacht, dass die Flasherei mal besser und mal schlechter klappt, mit seltsamen Ergebnissen zu Laufzeit.
Ist mir auch schon mal passiert, dass nach dem Flashen es augescheinlich irgendwie lief, aber dann doch nicht so richtig und nach erneutem Flashen der selben .bin alles gut war.

Evtl. finden wir ja noch das FlashTool mit der ultimativen Erfolgsquote ...

[Wzut]

Evtl. finden wir ja noch das FlashTool mit der ultimativen Erfolgsquote ...

Arduino 1.6.5 IDE : was wird dort benutzt ? Obwohl man im Netz auch Berichte liest das der Sketch nicht immer gleich das macht was er soll ...
Ich melde inzwischen mal Erfolg
Flashversuch mit dem esptool : Das ging nun beim Devkit, allerdings war danach gar kein offener AP mehr im Wlan sichtbar.
Nächster Versuch : mit esptool die alte Version geflasht (57600 Baud) -> LaCrosse AP da und Parameter im EEPROM !
Dritter Anlauf : neue Version mit esptool drübergebügelt, da die Eprom Settings dabei erhalten bleiben : läuft
Autocreate hat LGW angelegt, WS1600/LaCrosse und EMT 7110 musste ich allerdings von Hand definieren.

Update : inzwischen läuft auch der nackte ESP8266-12 - die neue Version direkt geflasht mit esptool (auch wieder nur mit 57600 Baud)

[HCS]

Ich melde inzwischen mal Erfolg

Bin ich was froh ...

Arduino 1.6.5 IDE : was wird dort benutzt ? Obwohl man im Netz auch Berichte liest das der Sketch nicht immer gleich das macht was er soll ...

Die spannende Frage ist, ob es die flash tools oder der bootloader sind, die mein Werk beim upload ruinieren?
Mit 57600 Baud ist halt krass langsam.

Was bisher gut funktioniert ist OTA. Ist auch richig schnell. Allerdings verwende ich da meistens diese Variante, weil ich es von meiner Entwicklungsumgebung aus hoch lade (das ist eine weitere Variante zu der aus dem Post oben beschriebenen, die ich ebenfalls im sketch unterstütze)

Code Auswählen Erweitern

python ota.py 192.168.31.211 LaCrosseGateway.bin
Ich hänge mal die ota.py, die ich verwende, hier an. Geht natürlich nicht beim ersten mal, sondern erst, wenn der Sketch drauf ist, läuft und mit dem wlan verbunden ist. Es muss Python 2.7 sein.

Autocreate hat LGW angelegt, WS1600/LaCrosse und EMT 7110 musste ich allerdings von Hand definieren.

Das ist auch seltsam, habe es gerade probiert: auf dem Testsystem Sensoren gelöscht und nach einem

Code Auswählen Erweitern

set myJeeLink LaCrossePairForSec 120 ignore_battery
wurden sie angelegt. Aber da bei Olly auch nichts per autocreate angelegt wird, bist Du zumindest nicht allein mit dem Problem.
Dürfte ich mal einen "list myJeeLink" sehen?

[Olly]

So, Hallo,

hier dann mal mein list JeeLink:

Code Auswählen Erweitern


Internals:
   Clients    :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
   DEF        192.168.140.70:81
   DeviceName 192.168.140.70:81
   FD         67
   NAME       myJeeLink
   NR         215
   PARTIAL
   RAWMSG     OK 9 8 1 4 57 106
   STATE      Initialized
   TYPE       JeeLink
   initMessages
   model      [LaCrosseITPlusReader.Gateway.1.06 (RFM69 f:868300 r:17241) {IP=192.168.140.70}]
   myJeeLink_MSGCNT 1611
   myJeeLink_TIME 2015-11-30 21:13:20
   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:
     2015-11-30 20:29:27   state           opened
Attributes:
   flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
   timeout    120,30

Was ich noch sagen muss: Ich selbst habe wissentlich kein LaCrosse-Device. Da aber auf der seriellen Konsole in recht kurzen Abständen (wenige Sekunden) OK 9.... Meldungen auftauchen gehe ich eigentlich davon aus, dass in meiner Umgebung was passendes Funkt.

Gruß

     Olly

[Olly]

Grad noch was im Logfile gesehen:

Code Auswählen Erweitern


2015.11.30 21:22:54 3: myJeeLink: Unknown code OK VALUES LGW 456439 UpTimeSeconds=77400,UpTimeText=0Tg. 21Std. 30Min. 0Sek. ,WIFI=gehteuchnixan,MacAddress=AA:BB:7F:06:F6:F7,ChipID=456439,ReceivedFrames=47210,FramesPerMinute=38, help me!

Da scheint noch was nicht ganz zu passen...

Gruß

    Olly

[HCS]

   RAWMSG     OK 9 8 1 4 57 106
   myJeeLink_MSGCNT 1611

Das ist ein Temperatursensor, der 8,1 °C sendet.
Sieht alles gut aus.

2015.11.30 21:22:54 3: myJeeLink: Unknown code OK VALUES LGW 456439 UpTimeSeconds=77400,UpTimeText=0Tg. 21Std. 30Min. 0Sek. ,WIFI=gehteuchnixan,MacAddress=AA:BB:7F:06:F6:F7,ChipID=456439,ReceivedFrames=47210,FramesPerMinute=38, help me!

Das sind die Statuswerte des LGW. Eigentlich sollte ein KeyValueProtocol device angelegt werden.
ReceivedFrames=47210
FramesPerMinute=38
Immerhin sind schon 47210 Frames vom LGW decodiert und verarbeitet worden. Und 38 Frames pro Minute ist nicht schlecht für jemand, der keine snesoren hat 

Kann es sein, dass autocreate bei Dir generell, warum auch immer, nicht funktioniert?
Einen "set myJeeLink LaCrossePairForSec 120 ignore_battery" hast Du aber schon mal abgesetzt, oder?

Was ich noch sagen muss: Ich selbst habe wissentlich kein LaCrosse-Device.

Und was willst Du empfangen, außer den Sensoren vom Nachbarn?

Nachtrag: ist Dein FHEM auf einem aktuellen Stand? Hast Du eine 36_KeyValueProtocol.pm in deiner Installation?

[Olly]

Hallo,

in der Tat bin ich nicht ganz auf dem aktuellsten Stand. Ich warte mit dem Update auf 5.7 noch ein paar Tage.
Der Hinweis auf die 36_KeyValueProtocol.pm hat es wohl gebracht. Habe die Datei zusammen mit 36_JeeLink.pm und 36_LaCrosse.pm manuell per update geholt. Nach einem shutdown restart und einem erneuten set myJeeLink LaCrossePairForSec 180 ignore_battery hab ich jetzt 2 Temperatursensoren und auch das KeyValueProtocol.
Ich hoffe übrigens die Daten meiner WH1080 empfangen zu können. Hab nur noch nicht geschaut, ob ich eine FSK oder OOK Anlage habe. Momentan sind dort auch leider die Batterien leer und bei diesem Wetter mag ich gerade nicht auf die Garage steigen.

Gruß

    Olly

[Wzut]

Mit 57600 Baud ist halt krass langsam.
Was bisher gut funktioniert ist OTA.
--snipp ---

Code Auswählen Erweitern

set myJeeLink LaCrossePairForSec 120 ignore_battery
wurden sie angelegt. Aber da bei Olly auch nichts per autocreate angelegt wird, bist Du zumindest nicht allein mit dem Problem.

Sicher ist 57600 langsam, liegt bestimmt auch an meiner alten Hardware. Aber ist auch egal da OTA ein guter Weg ist. Damit muss ich mich jetzt unbedingt näher befassen ( u.A. für meine anderen offen Baustellen wäre das verdammt elegant)

Autocreate : Ich habe heute Morgen schnell mal alles aus dem svn in ein neues Dir kopiert und eine mini fhem.cfg dafür erstellt. Alles was ich am Basteltisch empfangen kann wurde mit autocreate erfolgreich angelegt. (TX29-IT, EMT7110 & WS1600)
Einzig bei der WS1600 habe ich einen Schönheitsfehler gefunden ( siehe Screenshot) :
Es wurde noch kein Temperaturwert empfangen aber der state steht auf T:65535

Wenn Du da aufspringen willst, dann gib Bescheid und ich denke mal drüber nach, wie ich es ermöglichen kann, dass Du diesen Teil beiträgst.
Wenn Du eine komplette eigene Firmware aufziehen willst, ist das auch OK

Ich hänge dir mal meine bisherige Version eines RFM-MQTT Gateways an, basiert auf deinen libs ohne Änderung. Da werden nur Geräte unterstützt die ich auch besitze und somit auch testen kann, allerdings wenn ich das mit deiner letzten Version vergleiche vergeht mir eigentlich die Lust da noch mehr Energie reinzustecken, zumal ich eigentlich noch zwei andere offene Baustellen habe die drigend zugemacht werden müssten ....
Das bringt mich gleich zum Thema Wunschliste für dein Projekt :
a. statt bisher zwei RFMs zu unterstützen würde ich auf drei gehen, damit würde diese ganze elende Datenrate Umschalterei entfallen da jede der drei möglichen Datenraten ihren eigenen Empfänger hat.
b. den Part InternalSensors noch um den Anschlusspin für einen interen DHT22 erweitern und diesen wie einen TX29-IT mit fixer ID ( 00 oder FF) behandeln
c. mehr als ein fhem Client Connect möglich, dann könnte jede fhem Instanz sich mit dem Gateway verbinden und ihre Werte direkt abholen ohne auf fhem2fhem Verbindungen oder einen MQTT Broker als Verteiler Instanz angewiesen zu sein. 

[HCS]

Einzig bei der WS1600 habe ich einen Schönheitsfehler gefunden ( siehe Screenshot) :
Es wurde noch kein Temperaturwert empfangen aber der state steht auf T:65535

Ja, ist mir auch schon aufgefallen, muss ich mal richten, bei Gelegenheit.

Ich hänge dir mal meine bisherige Version eines RFM-MQTT Gateways an, basiert auf deinen libs ohne Änderung. Da werden nur Geräte unterstützt die ich auch besitze und somit auch testen kann, ...

OK, ich schau mir mal an, wie die MQTT-Geschichte generell läuft. Muss mir erst irgendwo ein Mosquitto drauf packen.
Was ist denn der Vorteil/UseCase im Zusammenhang mit FHEM?
Wir haben LaCrosse-Sensoren, die können ein Protokoll senden, das FHEM versteht und an die passenden Module dispatcht.
Wenn man das nun nach MQTT übersetzt, es an einen zusätzlichen Broker gibt, dort abholt und dann in FHEM irgendwie wieder verteilen muss, ist doch nichts besser als vorher.
Der einzige sinnvolle UseCase, der mir einfällt, ist, wenn man die Daten mit etwas anderem als FHEM weiterverarbeiten will.

a. statt bisher zwei RFMs zu unterstützen würde ich auf drei gehen, damit würde diese ganze elende Datenrate Umschalterei entfallen da jede der drei möglichen Datenraten ihren eigenen Empfänger hat.

Die Idee hatte ich auch schon, da das, im Gegesatz zum Atmega-Sketch, nun von Speicher und Rechenleistung her machbar wird auf dem ESP.

b. den Part InternalSensors noch um den Anschlusspin für einen interen DHT22 erweitern und diesen wie einen TX29-IT mit fixer ID ( 00 oder FF) behandeln

Muss ich mir mal anschauen und überlegen. Ich glaube (muss nochmal genau schauen), dass mit einem dritten RFM und einem DHT dann alle GPIOs der EMT verbraucht sind.
Irgendwie habe ich aber auch den Wunsch, ein OOK-Radio anschließen zu können, aber das könnte eventuell auch der dritte RFM69 konfigurierbar anstatt dritte DataRate übernehmen.
Und einen GPIO hätte ich eigentlich gerne als Reserve, für die Idee, die ich erst in drei Monaten bekomme.
Zuammenfassung diese Gefasels: Ich brauche erst einen Plan was jetzt und irgendwann wie unterstützt werden könnte.

c. mehr als ein fhem Client Connect möglich, dann könnte jede fhem Instanz sich mit dem Gateway verbinden und ihre Werte direkt abholen ohne auf fhem2fhem Verbindungen oder einen MQTT Broker als Verteiler Instanz angewiesen zu sein.

Steht auf der Wunschliste, ist aber nicht ganz ohne. Aktuell denke ich darüber nach, dafür drei Daten-Ports bereitzustellen (81, 82 und 83) auf die man jeweils ein FHEM setzen kann.
Bin ich aber auch noch nicht mit durch, ob das so klappt.

[Wzut]

Aktuell denke ich darüber nach, dafür drei Daten-Ports bereitzustellen (81, 82 und 83) auf die man jeweils ein FHEM setzen kann.

Ich fang mal hinten an : drei Ports wäre für mich optimal. Die drei RFMs + ein ESP8266 +  3,3V Schaltnetzteil in ein Steckergehäuse und irgendwo im Haus in eine Steckdose gesteckt und jeder fhem Server holt sich dort die Sensorendaten die er braucht - MQTT wäre für mich damit als Verteiler komplett vom Tisch.
GPIOs : klar irgend wann ist jeder verfügbare verbaut. Wenn der User keinen BMP180 verwendet könnte man einen der beiden I2C Ports dafür benutzen.
Aber um es nun kurz zu machen : Mach so weiter mal wie du denkst, wenn irgendwann dann mal der Quellcode da ist mache ich es wie immer und ändere für mich einfach das was mir nicht so 100%ig in den Kram passt    

[HCS]

Ich fang mal hinten an : drei Ports wäre für mich optimal. Die drei RFMs + ein ESP8266 +  3,3V Schaltnetzteil in ein Steckergehäuse und irgendwo im Haus in eine Steckdose gesteckt und jeder fhem Server holt sich dort die Sensorendaten die er braucht - MQTT wäre für mich damit als Verteiler komplett vom Tisch.

So könnte es werden, muss es nur hinbekommen. Dann stelle ich das MQTT-Thema mal zurück.
Allerdings holt sich FHEM die Daten nicht, sondern bekommt sie  (und zwar alle) gepusht. Aber man kann ja in den jeweiligen FHEMs die Daten ignorieren, die nicht interessieren.

GPIOs : klar irgend wann ist jeder verfügbare verbaut. Wenn der User keinen BMP180 verwendet könnte man einen der beiden I2C Ports dafür benutzen.

Das sind genau die Überlegungen, die ich anstellen muss: was könnte dran, was alternativ und was kann man an den Ports unterscheiden und testen, ob es dran ist. I2C ist da gerade so ein Kapitel, weil man schnell mal stecken bleibt, wenn man einen nicht upgepullten (colles Wort  ) Bus anspricht.

Mach so weiter mal wie du denkst, wenn irgendwann dann mal der Quellcode da ist mache ich es wie immer und ändere für mich einfach das was mir nicht so 100%ig in den Kram passt

Der wird verfügbar. Hatte gerade am Wochenende angefangen zu schauen, wie man es mit einer puren Arduino IDE compiliert bekommt, weil meine Entwicklungsumgebung etwas anders aussieht.
Ist aber beim LaCrosse Arduino Sketch auch so, dass mir ein Script etwas zusammenstellt, das man mit der Arduino-IDE direkt bilden kann.
Mit der kommenden 1.07 wird es hoffentlich auch den Source geben.
Klar kannst Du es ändern, aber dein UseCase deckt sich weitestgehend mit meinem, also könnte es ja auch was werden, dass Du einfach nehmen kannst.
Darfst es aber dann auch gerne an Deine Wünsche anpassen.

Bist Du eigentlich auf den DHT22 fixiert oder könnte es auch ein Temp-/Hum-Sensor mit I2C sein?
Weil, der könnte einfach anstatt BMP180, zusätzlich oder eben nicht an SDA/SCL mit dran, ohne über weitere Ports nachdenken zu müssen.

[Wzut]

Bist Du eigentlich auf den DHT22 fixiert oder könnte es auch ein Temp-/Hum-Sensor mit I2C sein?

DHT22 war als Beispiel gedacht, sind halt einfach bzw. günstig (oder ein DS1820) am ESP in Betrieb zu nehmen.
Temperatursensor für I2C habe ich sogar auch noch zwei irgendwo in der Bastelkiste liegen, muß ich demnächst mal suchen und am ESP testen.

[kohlenmacher]

Hallo,

ich habe das LaCrosseGateway auch mal zusammengesteckt. Hat bis auf Kleinigkeiten auch sehr gut funktioniert.
Z.Z. betreibe ich den NodeMCU noch über den MicroUSB an meinem Rechner und schaue mir die Daten im Terminalprogramm an.

Mir ist aufgefallen, dass wenn ich den Resettaster am NodeMCU betätige er keine WLAN Verbindung mehr bekommt. Ziehe ich den USB-Stecker funktioniert es.
Kann das jemand bestätigen?

Vielen Dank
Kohlenmacher

[Olly]

Hallo,

ich habe das LaCrosseGateway auch mal zusammengesteckt. Hat bis auf Kleinigkeiten auch sehr gut funktioniert.
Z.Z. betreibe ich den NodeMCU noch über den MicroUSB an meinem Rechner und schaue mir die Daten im Terminalprogramm an.

Mir ist aufgefallen, dass wenn ich den Resettaster am NodeMCU betätige er keine WLAN Verbindung mehr bekommt. Ziehe ich den USB-Stecker funktioniert es.
Kann das jemand bestätigen?

Vielen Dank
Kohlenmacher

Nö, das funktioniert bei mir auch wenn man einen Reset macht. Kommt denn dann was außergewöhnliches auf der seriellen Konsole?

Gruß

   Olly