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

[sash.sc]

Was mach eigentlich, das Attribut, um devices zu blocken ??

Bei mir rauschen ins Hauptlog jede menge Meldung über "please define it" device 22 und 05.
Habe auch mal autocreate aktiviert, aber es wird kein device mit den Nummer angelegt !

Du hattest mal was gerschrieben, ob da evtl. ein Signalduino oder so in Betrieb ist ?
Was könnte der denn danmit zu tun haben ?

gruß
Sascha

[HCS]

Was mach eigentlich, das Attribut, um devices zu blocken ??

Es freut sich seit 25.02.17 darauf angewendet zu werden.
Zitat aus der commandref:

filter
defines a filter (regular expression) that is applied to the incoming data. If the regex matches, the data will be discarded.
This allows to suppress sensors, for example those of the neighbour.
The data of different kinds of sensors starts with (where xx is the ID):
LaCrosse sensor: OK 9 xx
EnergyCount 3000: OK 22 xx xx
EMT7110: OK EMT7110 xx xx
LevelSender: OK LS xx
Example: set lgw filter ^OK 22 117 196|^OK 9 49
will filter the LaCrosse sensor with ID "49" and the EC3000 with ID "117 196"

Du hattest mal was gerschrieben, ob da evtl. ein Signalduino oder so in Betrieb ist ?

Nanu, wo habe ich denn so was geschrieben?

[sash.sc]

Heißt, ich muss die Nummern /id der Sensoren angeben die durchgelassen werden, oder die, die geblockt werden sollen?

Muss dann jede id einzeln angegeben werden?

Z. B. D id's von 10 bis 19 => 1.*

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk

[HCS]

Heißt, ich muss die Nummern /id der Sensoren angeben die durchgelassen werden, oder die, die geblockt werden sollen?

Es ist ein Filter, bedeutet, wenn die regex matcht, dann wird der Sensor ignoriert.

[sash.sc]

Danke

Gesendet von meinem E6653 mit Tapatalk

[sash.sc]

So, habe den Filter jetzt funktionsfähig am laufen.

Es waren die device Nummer 22 und 05 die gefiltert werden sollen.
Hat im ersten Ablauf nicht funktioniert.
Habe mal im log auf dem esp Gateway nachgeschaut.
Dabei ist mir aufgefallen, dass alle id's in dezimal in der Firmware geloggt werden.
Habe natürlich das device 22 nicht gefunden. Habe es dann mal in dezimal umgerechnet und in den Filter eingetragen. Siehe da, das device 22 wird gefiltert.
Das device 05 wurde auch nicht gefiltert. Erst nachdem ich die Null von der 05 entfernt habe, hat auch dieser Filter gegriffen.

Also, wenn unbekannte devices auftauchen, dann in dezimal umrechnen und in das Attribut Filter eintragen.

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk

[Dummbatz]

Hi Jungs,

Ich habe das LGW in der Version 1.25 und mal eine Frage zur Funktion.

Wie sollte der Stick sich verhalten wenn er stromlos geworden ist und sich wieder einwählt im Netz ??

Ich habe 3 Sensoren TX29DTH-IT dran hängen und das läuft so weit auch rund.

Bei Bastelarbeiten wurde der Stick stromlos und hat ewig gebraucht um wieder komplett in FHEM zu erscheinen.

Danke & Grüße

Dummbatz

[HCS]

Bei Bastelarbeiten wurde der Stick stromlos und hat ewig gebraucht um wieder komplett in FHEM zu erscheinen.

Kann man "ewig" in Sekunden, Minuten oder Stunden definieren?

Hast Du das timeout Attribut im LaCrosseGateway in FHEM gesetzt?
Bsp.: attr myLGW timeout 60

Nachdem das LGW wieder mit Spannung versorg wird, baut es sofort die Verbindung zum AccessPoint auf
FHEM erkennt nach <timeout> Sekunden, dass es die Verbindung zum LGW verloren hat und baut sie neu auf.
Bei "timeout 60" sollte FHEM also spätestens 60 Sekunden, nachdem das LGW wieder da ist, eine Verbindung haben.
Wenn es sich ganz unglücklich trifft, dann schlimmstenfalls nach 120 Sekunden.

Dass jetzt aber keiner auf die Idee kommt, eine Sekunde einzustellen 
Weniger als 30 würde ich nicht machen.

[Dummbatz]

Danke HCS,

werde ich prüfen.

LG

[marco-f]

Hallo zusammen,

nach mehreren, teils nervenaufreibenden, Monaten mit dem LaCrosseGateway muss ich mich hier leider auch mal zu Wort melden.

Bis Jahresanfang hatte ich in meiner Wohnung einen Jeelink laufen, aber nach dem Umzug ins Eigenheim reichte der dann leider nicht mehr aus so dass ein LaCrosseGateway her musste. Mit einem NodeMCU DevKit v1.0, einem RFM69CW, einem 1,3" OLED und aufgespieltem LaCrosseGateway v1.30 habe ich nun eine Grundkonfiguration im Betrieb, welche aber leider alles andere als stabil läuft und verschiedene seltsame Verhaltensweisen aufzeigt. Da ich hier im Thread recht wenig von Problemen lese, ich selbst aber nicht mehr weiter weiß, wende ich mich mal mit der bitte um Hilfe an euch.

Hardwarekonfiguration - siehe oben
Fhem - aktueller Stand auf einem Raspberry Pi 3
LGW Fhem Einbindung

Code Auswählen Erweitern


define myLaCrosseGateway LaCrosseGateway 192.168.1.84:81
attr myLaCrosseGateway timeout 120,30
attr myLaCrosseGateway usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]

1. seltsame Erscheinung - LGW Neustart:

Bei einem LGW Neustart wird häufig keine WLAN Verbindung aufgebaut. Laut Wiki bedeutet das erste Symbol in der OLED Statuszeile "WiFI connect erfolgreich". Dies kann ich bei mir so nicht bestätigen. Dieses Symbol kommt bei mir immer, auch wenn sich das LGW nicht mit dem WiFi verbunden hat. Ich erkenne nur anhand der Signalstärke ob ein Connect erfolgt ist, bei erfolglosem Connect habe ich eine positive Signalstärkeanzeige. Im Anhang ist ein Bild von der Anzeige, wenn der Connect nicht efolgreich war. Irgendwann las ich mal davon, dass Nutzer Probleme mit gewisser WLAN Hardware haben. Um dies Auszuschließen habe das LGW sowohl in meinem WLAN auf der Wohnetage mit einem LINKSYS Router (mit DD-WRT), als auch im Kellergeschoss an einer Fritz!Box 7490 probiert (beide Geräte versenden getrennte SSIDS, sind also getrennte Netze) - bei beider Hardware das gleiche Verhalten. Abhilfe schafft hier nur immer wieder vom Strom trennen bis die Verbindung klappt und die feste IP vom LGW irgendwann wieder im LAN Erreichbar ist.

2. seltsame Erscheinung - sporadisch kein LGW Reconnect nach FHEM Neustart:

Ein weiteres immer mal wieder auftretendes Problem liegt darin, dass nach einem FHEM Neustart keine Verbindungmehr aufgebaut wird. Wenn ich Änderungen im FHEM vornehme, ein Update fahre o.ä. kommt es ja doch immer mal wieder dazu dass FHEM neu startet und da passiert es gerne mal, dass keine LGW Verbindung mehr aufgebaut wird. Der Status vom LGW steht dann auf "opened", aber spingt nicht mehr auf "initialized". Hier kann ich dann vom FHEM aus einen reboot Befehl an das LGW senden und mich überraschen lassen ob LGW sauber neu startet und danach wieder spielt oder ob das unter Punkt 1 beschriebene Problem eintrittt.

3. seltsame Erscheinung - keine Verbindung mehr bis FHEM Reboot:

Nach längerem laufendem Betrieb des LGW stellt dies plötzlich den Betrieb ein. Manchmal sind das 14 Tage, manchmal aber auch nur 2 Tage. Gestern hatte ich wieder so einen Fall. Das LGW stand wieder einmal plötzlich auf state "opened" und sprang auch nach mehreren Reboots (zwischendurch gab es wieder mehrfach Problem 1, was solche Aktionen immer sehr nervenaufreibend werden lässt) nur immer wieder in diesen Zustand. Im Logfile standen dabei im 10-20-Sekunden Takt Einträge drin dass das mylacrossegateway connected sei. Als mir schon wieder die Fragen im Gesicht standen und ich der Verzweiflung nahe war fiel mir ein dass manchmal auch ein FHEM neustart hilft. Also hab ich den FHEM neu gestartet und seitdem läuft es wieder.


Nun die große Frage - wo und wie fange ich jetzt am Besten an? Ich habe das Gefühl dass hier mehrere Probleme zusammenkommen - sowohl auf LGW Seite als auch auf FHEM Seite. Ich hätte gern auch ein stabiles LGW und nicht bei jeder mehrtägigen Reise die bange Frage - wie lange empfange ich wohl daheim alle Sensoren!?!

MfG
Marco

[reinni123]

Hab dieselben Probleme mit der 1.28. Als Lösung hab ich einen Homematic-Aktor dazwischen geschaltet und ein paar "at"s hinzugefügt. Siehe auch meinen Blogbeitrag dazu:

https://www.frombeyond.de/2017/tech-review-homematic-funk-schaltaktor-hm-lc-sw1-pcb/#Problemstellung

Ich hatte auch keine Lust nach einem FHEM-Restart Geräte einsammeln zu müssen, deshalb führe ich alle paar Stunden einen automatischen "connect" durch. Irgendwann pendelt sich dann alles wieder sauber in FHEM ein.

[HCS]

Hier mal von einem meiner LGWs die interessanten Werte.
Das LGW hat nun immerhin 38 Tage uptime und seit Monaten (oder Jahren?) übersteht das FEHM-restarts, Stromausfälle usw.

Code Auswählen Erweitern

Internals:
   DEF        192.168.31.210:81
   STATE      T:26.1 H:41 P:1028 rssi:-55 dBm fpm:87 up:38Tg. 9Std. 40Min. 58Sek. (initialized)
   TYPE       LaCrosseGateway
   model      LaCrosseITPlusReader.Gateway.1.30
   settings   (1=RFM69 f:868295 t:20~3) + (2=RFM69 f:868960 r:6631) + (3=RFM69 f:868300 r:20000) + BME280 {IP=192.168.31.210}]
   READINGS:
     2017-10-16 11:54:05   RSSI            -55
     2017-10-16 11:54:05   ReceivedFrames  3113133
     2017-10-16 11:54:05   UpTime          38Tg. 9Std. 40Min. 58Sek.
     2017-10-16 11:54:00   humidity        41
     2017-10-16 11:54:00   pressure        1028
     2017-10-16 11:54:05   state           initialized
     2017-10-16 11:54:00   temperature     26.1
Attributes:
   initCommands 868295#1f 3#1m 20#1t 2,868960,120i 20000#3r 220h 0a v
   timeout    120


Aus

Code Auswählen Erweitern

attr myLaCrosseGateway timeout 120,30
kannst Du mal

Code Auswählen Erweitern

attr myLaCrosseGateway timeout 60
machen, aber das kann eigentlcih nicht die Ursache Deiner Probleme sein.

Poste mal bitte einen kompletten list von myLaCrosseGateway
Und den Inhalt der Hardware- und der Setup-Page vom LGW

Ich habe übrigens gerade ein FHEM-update mit anschließendem Neustart gemacht und alle LGWs sind wie üblich auf initialized gekommen.

Ich habe das Gefühl (ohne konkret aktuell etwas zu erkennen), dass alle beschriebenen Erscheinungen von Problemen des ESP8266 mit seiner WiFi-Verbindung kommen.
Hast Du eine gute Spannungsversorgung für das devkit? Spannungsversorgung ist ein durchaus denkbares Problem für übles Verhalten des ESP8266.
Was ist denn am anderen Ende des schwarzen Kabels und ist es ein USB-Kabel, das ein vernünftiges Innenleben hat?

Schritt eins muss sein, zu erreichen, dass das LGW bei jedem boot sicher einen Connect zum AP bekommt.
Welchen RSSI hast Du, wenn es den Connect hinbekommen hat?

Hab dieselben Probleme mit der 1.28. Als Lösung hab ich einen Homematic-Aktor dazwischen geschaltet und ein paar "at"s hinzugefügt. Siehe auch meinen Blogbeitrag dazu

Das sind dann die Symptome kuriert anstatt die Ursache behoben.

Das sollte man aber eigentlch auch mit der Watchdog-Funktionalität des LGW erreichen können (siehe commandref), die im LGW einen Reset auslöst, wenn sich ein FHEM lange genug nicht um das LGW gekümmert hat, weil es keine Verbindung hatte.
Also z.B.:

Code Auswählen Erweitern

attr myLaCrosseGateway timeout 60

Code Auswählen Erweitern

attr myLaCrosseGateway watchdog 300

[reinni123]

Das sind dann die Symptome kuriert anstatt die Ursache behoben.

Absolut richtig.

Allerdings hatte ich auch das Problem das sich das Gateway nach Stromwegnahme/Stromzuführung manchmal gar nicht mehr mit dem WLAN verbunden hat. Wenn dann das Gateway blöd verbaut wurde, ist meine Lösung gar nicht so unpraktikabel.

Hab auch mit den Timings rumprobiert hat aber nichts gebracht.

Ich wäre stark auch an einem problemlos funktionierenden Gateway für zukünftige Projekte interessiert, vermute aber auch ein Problem mit den ESP8266.

Wenn es zur Lösung beiträgt:
Ein Unifi AC Pro hängt ca. 3m entfernt. Spannung liegt mit einem Meanwell-Hutschienennetzteil bei ca. 5,1V .

Code Auswählen Erweitern


setstate KeyValueProtocol_LGW_264989 2017-10-16  FramesPerMinute 78
setstate KeyValueProtocol_LGW_264989 2017-10-16  FreeHeap 17720
setstate KeyValueProtocol_LGW_264989 2017-10-16  LD.Avg 0
setstate KeyValueProtocol_LGW_264989 2017-10-16  LD.Max 36
setstate KeyValueProtocol_LGW_264989 2017-10-16  LD.Min 0
setstate KeyValueProtocol_LGW_264989 2017-10-16  OLED on
setstate KeyValueProtocol_LGW_264989 2017-10-16  RSSI -55
setstate KeyValueProtocol_LGW_264989 2017-10-16  ReceivedFrames 40353
setstate KeyValueProtocol_LGW_264989 2017-10-16  UpTimeSeconds 37251
setstate KeyValueProtocol_LGW_264989 2017-10-16  UpTimeText 0Tg. 10Std. 20Min. 51Sek.
setstate KeyValueProtocol_LGW_264989 2017-10-16  Version 1.28


[marco-f]

Uptimes von 38 Tagen wären bei mir Traumwerte. Ich glaube mein Rekord lag mal bei 12 Tagen.

Spannungsversorgung ist ein 5V 1A Smartphonenetzteil, Kabel ist entweder das Originale vom Netzteil oder eines vom Chinamann, das müsste ich daheim mal nachschauen. Wenn die WiFi Verbindung steht hab ich ein RSSI von -60dBm.

LGW Hardware und Setup Page hänge ich. list MyLaCrosseGateway ergibt folgendes:

Code Auswählen Erweitern

Internals:
   Alive      2017-10-15 16:59:04
   Clients    :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
   DEF        192.168.1.84:81
   DeviceName 192.168.1.84:81
   FD         14
   NAME       myLaCrosseGateway
   NR         37
   PARTIAL
   RAWMSG     OK 9 28 1 4 180 70
   STATE      initialized
   TIMEOUT    0.5
   TYPE       LaCrosseGateway
   model      LaCrosseITPlusReader.Gateway.1.30
   myLaCrosseGateway_MSGCNT 70094
   myLaCrosseGateway_TIME 2017-10-16 12:57:06
   settings   (1=RFM69 f:868300 r:17241) + OLED {IP=192.168.1.84}]
   MatchList:
     1:PCA301   ^\S+\s+24
     2:EC3000   ^\S+\s+22
     3:LaCrosse ^(\S+\s+9 |OK\sWS\s)
     4:EMT7110  ^OK\sEMT7110\s
     5:Level    ^OK\sLS\s
     6:KeyValueProtocol ^OK\sVALUES\s
   READINGS:
     2017-10-16 12:57:06   state           initialized
   helper:
Attributes:
   room       Hardware
   timeout    120,30
   usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]

[heka]

Ich hatte mal USB Kabel mit anscheinend zu geringem Cu-Querschnitt. Da gabs beim WiFi Connect immer kurze Spannungseinbrüche. Mit dem Multimeter natürlich nicht feststellbar.  Beim WiF-Connect werden hohe Ströme benötigt. Nach Tausch auf ,gute' USB Kabel hat sich das Problem erledigt und mein LGW verbindet sich seitdem sicher und  auch ,immer'.


Gesendet von iPhone mit Tapatalk