LaCrosseGateway
Vorab: inzwischen hat amunra (vielen Dank) das Wiki für das LaCrosseGateway erstellt.
Darin findet man die nachfolgenden und viele weitere Informationen zum LGW.
Link zum Wiki: http://www.fhemwiki.de/wiki/LaCrosseGateway
Dieser Beitrag hier bietet nur einen groben Überblick und eine Schnelleinstieg.
Zweck
Empfang und Bereitstellung der von LaCrosse Sensoren empfangenen Daten im WLAN zur Verarbeitung in FHEM
Abfrage und Steuerung von PCA301 Funk Mess-/Schalt-Steckdosen
Empfang von Energy Count 3000 Funk Mess-Steckdosen
Empfang der Wetterstation WS 1600
Empfang von EMT7117
Empfang des LevelSenders
Interne Sensoren für Temperatur und Luftdruck
Optionales Display
Transparente Bereitstellung von bis zu zwei NanoCUL
Warum eigentlich
Das Ganze kann man teilweise auch mit einem JeeLink(Clone) und ser2net usw. realisieren, jedoch benötigt man dann mehrere JeeLinks
Das hier hat in Stichpunkten folgende Vorteile:
- Im Minimalausbau nur zwei Bauteile (NodeMCU DEVKIT 1.0 + RFM69)
- Alternativ am USB-Port wie ein JeeLink verwendbar oder per wifi anbindbar
- Erweiterbar
- Kann an eine Stelle platziert werden, an der alle Sensoren optimal empfangen werden, nur Strom (5V/1A USB Netzteil) und wifi erforderlich
- AllInOne, eine Firmware die die Protokolle von LaCrosse, PCA301, EMT7110, ... versteht.
Unterstützte Sensoren:
Alle Sensoren, die auch vom "LaCrosse Arduino" Sketch unterstützt werden, incl. WS 1600 und WS 1080 (Hinweis beachten)
siehe http://www.fhemwiki.de/wiki/JeeLink#LaCrosse_Sketch
On board: BME280, BMP180, LM75, DHT22
Ab Version 1.13 auch die PCA301 Funk-Mess-Steckdose
Ab Version 1.14 auch die EC3000 Funk-Mess-Steckdose
Hinweis zur WS 1080: Die WS 1080 gibt es (unter gleichem Namen) in einer OOK- und in einer FSK-Version
Der LaCrosse Sketch und das LaCrosseGateway können nur die FSK-Version empfangen, die OOK-Version nicht.
Die FSK-Version erkennt man an dem grünen Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS 7". Nur diese Version kann empfangen werden.
Die OOK-Version erkennt man an dem grünen Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS A14C".
Siehe auch die Hinweise im wiki.
Projekt-Status:
Release
Platine
PeMue hat hier eine Platine für das LGW entworfen: https://forum.fhem.de/index.php/topic,45594.0.html
locutus hat hier eine Platine für das LGW entworfen: https://forum.fhem.de/index.php/topic,55705.0.html
Hardware:
ESP8266 ESP-12E, am einfachsten ist es, wenn man ein NodeMCU DEVKIT 1.0 nimmt, da ist alles bis auf den RFM69 drauf, was man braucht.
Es wird aber keine NodeMCU-Firmware verwendet, wir wollen nur ein Board
Dieses hier: https://raw.githubusercontent.com/nodemcu/nodemcu-devkit-v1.0/master/Documents/NodeMCU_DEVKIT_1.0.jpg
Alternativ kann man sich das auch alles um einem puren ESP-12E drum rum bauen, aber bei fernost-Preisen von ca. 6 EUR für das DEVKIT rentiert sich das eher nicht.
RFM69 (optional ein zweiter und ein dritter)
Plus die oben genannten on board Sensoren
Features (Auszug):
- Access Point für die Konfiguration
- Konfiguration (SSID, Password) wird im EEPROM gespeichert
- Vom LaCrosseGateway Modul in FHEM über IP:Port ansprechbar
- Konfigurations-Frontend auf Port 80
- Unterstützt bis zu drei RFM69CW (keine RFM12)
- Unterstützt einen BMP180 oder BME280
- Alternativ per USB anschließbar, als ob es ein JeeLink wäre
- WebFrontend auf Port 80 mit Informationen wie MAC-Adresse, wifi, ...
- Statische IP anstatt DHCP (konfigurierbar)
- Hostname konfigurierbar
- OTA Firmware update
Schaltung:
siehe Anhang:
Schaltplan: LaCrosseGateway-CircuitDiagram ...
Minimalversion auf breadboard: LaCrosseGateway Minimum 1.png und LaCrosseGateway Minimum 2.png
Funktionsweise:
Das LaCrosse Gateway versucht sich in einem WLAN anzumelden. Dazu muss es eine ssid und ein Passwort kennen.
Beim ersten Start ist das natürlich noch unbekannt. Darum fährt es folgende Strategie:
Wenn es sich in keinem WLAN anmelden kann, dann öffnet es einen Access Point mit der ssid "LaCrosseGateway_xxxxxx", wobei xxxxxx die eindeutige Chip-ID des ESP ist.
Dieser wird aus Sicherheitsgründen nach 15 Minuten wieder geschlossen.
Innerhalb dieser 15 Minuten kann man sich auf ihn verbinden (http://192.168.222.1/setup) und die Konfiguration durchführen.
Er vergibt (DHCP) IP-Adressen aus dem Netzwerk 192.168.222.0
Die Konfiguration wird im EEPROM gespeichert und bei zukünftigen Neustarts verwendet.
Die Konfigurationsseite ist auch erreichbar, wenn das LaCrosse Gateway im "Normalbetrieb" ohne Access Point läuft, über http://'seine aktuelle IP-Adresse'/setup
Wenn das LaCrosse Gateway sich an dem konfigurierten WLAN anmelden konnte (es wartet max. 30 Sekunden auf einen connect) und von diesem per DHCP eine IP-Adresse erhalten hat, dann stellt es auf dieser Adresse den Port 81 zur Verfügung, über den in FHEM das LaCrosseGateway Modul angebunden wird.
Hinweis: den Port 81 nicht mit einem Browser öffnen, das killt aktuell die gespeicherten Settings im ESP.
Die Definition sieht dann z.B. so aus: define myLGW LaCrosseGateway 192.168.22.33:81 (natürlich mit der passenden IP-Adresse)
IP-Adresse ermitteln: das WebFrontend zeigt die MAC Adresse des ESP an. Mit der kann man dann auf dem DHCP-Server nach der IP schauen.
Oder man pingt ihn einfach. Der Hostname ist LaCrosseGateway.
Um einen erneuten connect zu bekommen, falls das LaCrosse Gateway mal wegstirbt (Stecker gezogen, wlan weg, ...) kann man das timeout Attribut des LaCrosseGateway device in FHEM verwenden.
Die initCommands im LaCrosseGateway device können wie gewohnt verwendet werden.
Da hier wifi-Verbindungen usw. aufgebaut werden, das LaCrosseGateway Modul je nach Konfiguration einige Zeit braucht, bis es einen neuen Connect auf den Datenport des LaCrosseGateway versucht, mus man beim experimentieren etwas Geduld haben, es kann auch schon mal ein, zwei Minuten Dauern, bis die ersten Daten in FHEM einlaufen.
Firmware flashen:
Wie bei einem JeeLink muss auch für das LaCrosse Gateway die Firmware erst mal auf das DEVKIT drauf.
Das DEVKIT hat eine CP2102 UART Bridge drauf, das bedeutet, man muss einen CP2102 Treiber installiert haben.
Damit sollte es auf Windows, Mac und Linux gehen (getestet habe ich es nur auf Windows 10 und El Capitan):
esptool 0.4.6 beschaffen: https://github.com/igrr/esptool-ck/releases (für die entsprechende Platform)
flashen mit:
esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 921600 -ca 0x00000 -cd nodemcu -cf JeeLink_LaCrosseGateway.bin
Port und Pfade sind natürlich anzupassen.
Hinweis: das esptool ist nicht fürchterlich stabil. Es kommt vor, dass es manchmal den upload nicht startet oder nicht durchbekommt.
Einfach dann nochmal anwerfen, bis es klappt.
Alternative für Windows: https://github.com/nodemcu/nodemcu-flasher
Einstellungen (Advanced Tab): 921600 Baud, 4MByte Flash size, 80 MHz Flash speed, SPI Mode: DIO
Auf dem Tab "Config" das JeeLink_LaCrosseGateway.bin auswählen, Ziel-Adresse 0x00000
Hinweis: die Geschwindigkeit von 921600 baud ist wohl nicht auf jedem Rechner (besonders auf virtualisierten Systemen) machbar.
In diesem Fall die baud rate auf 57600 runternehmen, besser langsam flashen als gar nicht.
Ab V1.15 kann man die Firmware auch ganz einfach vom LaCroseGateway-Modul aus mit "set myLaCrosseGateway flash" aktualisieren.
Die Firmware befindet sich hier: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip
Nach einem FEHM-Update alternativ auch hier: <FHEM-Installations-Verzeichnis>/FHEM/firmware/JeeLink_LaCrosseGateway.bin
ChangeLog:
V1.03
- Debug Ausgaben entfernt
V1.04
- Test-Version mit debug messages auf der seriellen Schnittstelle (57600 Baud)
V1.05
- Konfiguration: Sonderzeichen funktionieren jetzt
- Command 0e um das EEPROM zu leeren (von einem Terminaprogramm aus absetzen)
- Hostname, und statische IP konfigurierbar
V1.06
- Port 81 im Browser öffnen killt die gespeicherten Settings nicht mehr
- Optische Darstellung der Initialisierung
- Status-Werte als XML abrufbar
- WebFrontend: UpTime in Tage, Stunden, ...
- WebFrontend: MessagesPerSecond
- WebFrontend: Navigation
- OTA-Firmware-Update (erste noch zu verbessernde Version)
siehe auch hier: http://forum.fhem.de/index.php/topic,43672.msg366148.html#msg366148
V1.07
- Quellcode verfügbar
- Fix OTA-Update bei Browsern (Mac-Chrome), die ein ? an die url anhängen
- Neues Setting KV-Identity
- Neuer Staus-Wert "RSSI" (wifi Signalstärke)
- Bis zu drei Clients (FHEMs) möglich
- Dritter RFM möglich
- Commands Logik für drei RFMs erweitert
siehe auch hier: http://forum.fhem.de/index.php/topic,43672.msg370146.html#msg370146
V1.08
- Unterstützte Sensoren: BME280, BMP180, LM75
siehe auch hier: http://forum.fhem.de/index.php/topic,43672.msg373652.html#msg373652
V1.09
- Möglicher Crash beim Booten verhindert
- DHT22 vorübergehend stillgelegt, wegen Problemen mit GPIO9 auf manchen Boards
V1.11
- Das Problem mit Leerzeichen in der SSID ist behoben
V1.13
- Erase EEPROM: Ist jetzt 8266e
- Erkennung der Radios verbessert, speziell, wenn man das 1er nicht drauf hat
- Nach einem Reset mit Taster oder einem WDT-Reset funktioniert wifi jetzt
- PCA301 implementiert
- KVP: Die Versionsnummer des Sketch hinzugefügt
- PCA301: es werden bis zu 50 Dosen unterstützt
- KVP: Daten wie z.B. MacAddress, ChipID usw., die sich nicht ändern, werden nur am Anfang und dann all 30 Minuten gesendet
siehe auch hier: http://forum.fhem.de/index.php/topic,43672.msg397296.html#msg397296
V1.14
- Energy Count 3000 implementiert
siehe auch hier: http://forum.fhem.de/index.php/topic,43672.msg405444.html#msg405444
V1.15
- neue Firmware-Update-Methode "set myJeeLik flash"
siehe auch hier: http://forum.fhem.de/index.php/topic,43672.msg409619.html#msg409619
V1.16
- RFM12 entfallen
- Bugfixes
- Log im frontend
- Erweiterungsmöglichkeiten
siehe auch hier: https://forum.fhem.de/index.php/topic,43672.msg427404/topicseen.html#msg427404
V1.17
- DHT22 wiederbelebt
- Help page
- Konfiguration erweitert
- Transparent serial bridge (z.B. für NanoCUL)
siehe auch hier: https://forum.fhem.de/index.php/topic,43672.msg441446.html#msg441446
V1.18
- Frontend Passwort
- Zugriffsprobleme auf den AP beseitigt
siehe auch hier: https://forum.fhem.de/index.php/topic,43672.msg446348.html#msg446348
V1.19
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg455540.html#msg455540
V1.20
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg471910.html#msg471910
V1.21
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg481690.html#msg481690
V1.22
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg490438.html#msg490438
V1.23
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg512376.html#msg512376
V1.24
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg546877.html#msg546877
V1.25
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg553960.html#msg553960
V1.26
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg583437.html#msg583437
V1.27
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg584320.html#msg584320
V1.28
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg594398.html#msg594398
V1.29
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg603449.html#msg603449
V1.30
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg634935.html#msg634935
V1.31
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg748764.html#msg748764
V1.32
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg820228.html#msg820228
V1.33
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg958380.html#msg958380
V1.34
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg972729.html#msg972729
V1.35
Siehe hier: https://forum.fhem.de/index.php/topic,43672.msg974602.html#msg974602
Hallo HCS,
bin begeistert! Über das Thema werde ich ausführlich in meinem Blog berichten!
Vor allem mit der Anmeldung an das lokale WLAN gefällt mir.
Ich werde das mal sofort nachbauen.
Wo ist denn das LUA-File?
LG
/robin
Zitat von: fh168 am 07 November 2015, 15:51:18
Wo ist denn das LUA-File?
Es gibt kein LUA-File und es wird auch keins benötigt. Das angehängte bin-File ist nativer Code für den ESP8266. NodeMCU wird nicht verwendet.
Wenn das angehängte bin drauf geflasht ist, dann gibt es auf dem Board kein NodeMCU mehr, zumindest solange man keins wieder drauf flasht.
hm.. mal "eben" geht das wieder nicht.
Ich habe windows 10 angeworfen, er scheint zu flashen, aber es wird kein accesspoint aufgemacht.
esptool v0.4.6 - (c) 2014 Ch. Klippel <ck@atelier-klippel.de>
setting port from COM1 to COM3
setting baudrate from 115200 to 921600
setting address from 0x00000000 to 0x00000000
setting board to nodemcu
espcomm_upload_file
stat c:\users\robin\Downloads\esptool-0.4.6-win32\esptool-0.4.6-win32\LaCrosseGateway.bin success
setting serial port timeouts to 1000 ms
opening bootloader
resetting board
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
read 0, requested 1
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
read 0, requested 1
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
read 0, requested 1
resetting board
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
read 0, requested 1
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_send_command: receiving 2 bytes of data
espcomm_open
Uploading 378768 bytes from c:\users\robin\Downloads\esptool-0.4.6-win32\esptool-0.4.6-win32\LaCrosseGateway.bin to flash at 0x00000000
erasing flash
size: 05c790 address: 000000
first_sector_index: 0
total_sector_count: 93
head_sector_count: 16
adjusted_sector_count: 77
adjusted_size: 04d000
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
setting serial port timeouts to 10000 ms
setting serial port timeouts to 1000 ms
espcomm_send_command: receiving 2 bytes of data
writing flash
...
starting app without reboot
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
espcomm_send_command: receiving 2 bytes of data
closing bootloader
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
Ein kurzer Blick in dem Serial monitor unter 115200 Baud offenbart folgendes:
ets Jan 8 2013,rst cause:4, boot mode:(3,4)
wdt reset
load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld
怘€æ€˜€
irgend ne idee?
Das esptool braucht bei mir auch manchmal mehrere Anläufe. Ist auch aus der Entwicklungsumgebung heraus so.
Wenn man die baud rate drastisch runter nimmt, geht es zuverlässiger, aber dann dauert es halt auch ewig.
Ich vermerke das gleich mal im ersten Beitrag oben.
Du hast ein DEVBOARD v1.0?
Häng es mal an den Serial-Monitor mit 57600 Baud und schaue, was da kommt.
Ich sollte wohl erst mal mal eine Version mit mehr Debug-Ausgaben beim Start auf der Seriellen machen, dass man sieht, was da so passiert.
Hatte sei nur rausgenommen, weil es das FHEM-Log zuspamt, wenn man es als JeeLink-Ersatz per USB verwendet.
Das Board sieht so aus, wie bei dir auf dem Foto. auf der Rückseite steht NodeMCU Amica. Ich glaube es ist ein V 2. Ich probiere mal mit geringeren Baudraten. Am Serial Board /arduino gui sieht es dann so aus:
Œ8øíÈîö,,½¬HnZªJ*¨Xj+È
ÄŸÖˆ˜œþ
ÊKŒýÊK ¯
!�
JJ!!ˆH½
1Œ8øíÈ÷û̽ֈK¥SˆˆkH
ÊX ÌŸÖˆ˜œ!Hn:˜!Hn:ø¯
œ
HHZ*Þ!÷S ÊÛp[›Xi88øíÈ÷û̽ֈK¥Sˆˆ[°j+È
ÄŸ¬H Œ) Š˜þ
ÊK
mit 57600 geflashed, gleiche Fehlermeldung.
Das flashen hat aber lt. Log funktioniert.
Nachtrag: oder doch nicht, das sind zu wenig ...
Sieht so aus, als ob der upload zwar angelaufen, aber dann abgebrochen ist.
nene.. ich hab das log in einer datei reinlaufen lassen. wenn ich das nicht mache sind dann über 4 zeilen ... drin
ich habe mal mit einem zweiten nodemcu probiert... gleiches problem, gleiche ausgabe.
Dann sollte der Upload eigentlich geklappt haben
Was zeigt denn bei dir der Serial monitor an?
Ich müsste ja nach Deiner Doku einen AP haben mit LaCrosse... ist aber nicht
.
Andere Frage: Kann man das ganze Parameter-Gedöns nicht abkürzen und gleich den ESP8266-Flasher nehmen?
Datei auswählen -> Flashen gut is. Ist einfacher zu bedienen.
Zumindest bei mir kommt aber leider das gleiche Ergebnis (Serial Monitor) heraus.
Man kann mit allem, was geeignet ist (also ein "bin" File draufladen kann), flashen. Der ESP8266-Flasher sollte eigentlich auch gehen, habe es aber nicht getestet damit.
Ich habe oben einen neue Version angehängt. Probier mal bitte mit der.
Nachtrag: immer dran denken, der AccesPoint kann frühesten nach 30 Sekunden da sein.
das sieht schon mal besser aus!
..............................................WiFi: NO CONNECT
Access point opened: LaCrosseGateway_372603
[LaCrosseITPlusReader.Gateway.1.01 wifi=on]
Gut.
Jetzt sollte der AP da sein. Drauf verbinden und auf die Setup-Page gehen.
ssid und passowrt eintragen, wo er sich anmelden soll und speichern.
Danach macht der ESP einen Reset (meistens :) )
Dann sollte er im netz sein.
Einfach mal mit einem browser aufmachen und posten, was da kommt.
hab ich gemacht, hat auch wohl sich kurz ins netz gehangen..
aber eine Website kommt nicht, auch auf Port 81 nicht
und mein serial monitor spuckt das aus
ets Jan 8 2013,rst cause:4, boot mode:(3,4)
wdt reset
load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld
怘€æ€˜€
Kann aber sein, weil ich noch kein rfm angeschlossen habe.
Kann ich auch ein rfm 12B nehmen?
Ja, ein RFM12B geht auch.
Auf Port 81 ist keine Seite, nur auf Port 80. Der 81 ist nur ein Datenport.
kommt nix, weil wegen Crash. :-)
Aber warte mal, vielleicht liegt es daran, das ich noch kein RFM angeschlossen habe. Ich hole mal den Lötkolben raus. Dauert aber was, und ich melde mich wieder.
Zitat von: fh168 am 07 November 2015, 18:30:52
ets Jan 8 2013,rst cause:4, boot mode:(3,4)
wdt reset
load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld
怘€æ€˜€
Die initialisierung, die er mit 115200 sendet, interssiert eher weniger. Bleib mal auf 57600, das hier: 怘€æ€˜€
ist der interessante Teil.
Ich habe eine Version mit mehr logging hochgeladen.
Und einen RFM12B draufgesteckt, dass wir gleiche Verhältnisse haben.
Wenn der Connect ins wifi funtioniert, sollte die serielle Ausgabe mit 57600 so aussehen:
.................
WiFi connected
ssid: geheim
IP: 192.168.31.126
wifi setup done
RFM setup done
BMP setup done
[LaCrosseITPlusReader.Gateway.1.02 (RFM12 f:868300 r:17241) wifi=on]
OK 9 36 1 4 162 70
OK 9 38 1 4 125 83
so..
ich habe mal ein RFM genommen und angeschlossen. aber er crashed immer noch.
Die IP hat er bekommen und in der Fritzbox ist er auch gelistet.
ets Jan 8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld
Mit der 1.02 ?
das sieht doch schon mal gut im serial mon aus
OK 9 40 1 4 203 106
OK 9 20 1 4 207 59
OK 9 63 1 4 212 57
OK 9 18 1 4 213 58
website sagt das:
LaCrosseGateway V1.02
Uptime: 151 Seconds
Connected to: sssid
MAC address: FU:CK:ME:05:AF:7B
Chip ID: 372603
Dann mach mal in Browser die IP auf
siehe oben...
fhem sagt das:
CFGFN
Clients
:PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF
192.168.178:24:81
DeviceName
192.168.178:24:81
NAME
myJeeLink
NEXT_OPEN
1446921282
NR
45874
PARTIAL
STATE
Opened
TYPE
JeeLink
Readings
state
disconnected
2015-11-07 19:33:42
Mach mal einen shutdown restart
sieht gut aus!
Clients
:PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF
192.168.178.24:81
DeviceName
192.168.178.24:81
FD
38
NAME
myJeeLink
NR
448
PARTIAL
RAWMSG
OK 9 18 1 4 213 58
STATE
Initialized
TYPE
JeeLink
model
[LaCrosseITPlusReader.Gateway.1.02 (RFM12 f:868300 r:17241) wifi=on]
myJeeLink_MSGCNT
69
myJeeLink_TIME
2015-11-07 19:46:41
serial monitor
K 9 15 130 4 166 125
OK 9 63 1 4 212 57
OK 9 18 1 4 213 58
OK 9 40 1 4 202 106
OK 9 20 1 4 206 59
OK 9 63 1 4 213 57
OK 9 15 130 4 167 125
OK 9 18 1 4 213 58
OK 9 15 1 4 189 106
OK 9 20 1 4 206 59
OK 9 63 1 4 213 57
und rote LED flackert auf dem nodemcu, klappt!
Zitat von: fh168 am 07 November 2015, 19:46:32
sieht gut aus!
und rote LED flackert auf dem nodemcu, klappt!
Nanu, rote LED? meine ist blau ???
Aber immerhin klappt es, nach einigen Anlaufschwierigkeiten ;D
Das ist wohl der Prüfmodus wie bei VW, dann ist die Blau, sonst rot :-)
Ich werde ein paar von den Dingern bauen und in den Langzeitbetrieb schicken.
Dann blogge ich drüber.
Robin
Übrigens, sie blinkt, wenn der ESP einen Connect von FHEM hat und ein Datenpaket an FHEM zugestellt wird, oder wenn wifi deaktiviert ist, und ein Datenpaket über die serielle an FHEM zugestellt wird.
Wenn man ihn per USB an FHEM anbindet, kann man mit dem Command (initCommands im JeeLink Modul) 0w wifi komplett abschalten, aber nicht mehr einschalten.
Dass das FEHM log nicht vollgemüllt wird, muss ich jetzt erst mal die Version 1.03 machen, aus der die debug Messages auf der seriellen wieder raus sind.
Jetzt können wir alle unsere Beiträge wieder löschen, dass der Thread nicht so chaotisch beginnt ;D ;D
sollen wir die beiträge wieder löschen? findest du das sinnvoll?
Zitat von: fh168 am 07 November 2015, 20:06:46
sollen wir die beiträge wieder löschen? findest du das sinnvoll?
Habe zwar bisher nur mitgelesen, fände das Löschen aber sinnvoll.
Gibt es eine bevorzugte Quelle für das NodeMCU DEVKIT?
Wie hoch ist eigentlich der Stromverbrauch des Gateways?
Gruß Billy
ist eh noch alles Beta, bei mir hat er sich gerade weggehangen. In Fhem wurde keine Daten mehr angezeigt.
Der geneigte Leser des Forums schaut eh meistens auf den ersten und letzten Post :-)
@Billy
ich habe meine von Amazon, habe da schon einiges mit den NodeMCUs nachgebaut hier aus dem Forum:
http://blog.moneybag.de/fhem-wlan-gateway-mit-mysensors-ohne-zu-loeten/
http://blog.moneybag.de/olympia-protect-9061-wlan-switch/
http://blog.moneybag.de/wlan-thermometer-fuer-fhem-ohne-loeten/
Verbrauch habe ich mal eben gemessen mit meinem Aldi- USB - Duo Ladegerät - Netzteil.
Ich habe 0,9 W gemessen, also am USB-Ausgang vom Raspi würde ich den nicht anschließen.
LG
/robin
Zitat von: fh168 am 07 November 2015, 20:16:52
ist eh noch alles Beta, bei mir hat er sich gerade weggehangen. In Fhem wurde keine Daten mehr angezeigt.
Komisch, das eine System läuft bei mir seit einer Woche nonstop, ohne Probleme.
Aber: wenn man das LaCrosseGateway verwendet, sollte man auf alle Fälle beim JeeLink device das neue timeout Attribut auf z.B. 120,30 setzen.
Das Problem ist, dass, wenn die wlan-Verbindung mal kurz wegwackelt oder sonstwie die Verbindung wegzuckt oder man es mal kurz von der Stromversorgung trennt, FHEM das nicht merkt und keinen neuen Connect macht.
120,30 prüft alle 30 Sekunden, ob seit mindestens 120 Sekunden keine Daten mehr reinkamen (myJeeLink_TIME) und falls dem so ist, macht es einen Reset auf der Schnittstelle, was die Verbindung zum LaCrosseGateway neu aufbaut.
Bedeutet, in so einem Fall ist die Verbindung nach spätestens 150 Sekunden wieder da.
Zum löschen: wir lassen es bleiben, in zwei Wochen ist der Thread eh so abgefahren wie der andere und es kommt auf die paar Beiträge auch nicht an ;D
Zitat von: Billy am 07 November 2015, 20:11:26
Gibt es eine bevorzugte Quelle für das NodeMCU DEVKIT?
eBay, Amazon, ... für so 15-20 EUR und in China für ca. die Hälfte.
Aber
achtgeben, es muss das devkit
V1.0 sein, nicht das 0.9
Zitat von: Billy am 07 November 2015, 20:11:26
Wie hoch ist eigentlich der Stromverbrauch des Gateways?
Das "läuft seit einer Woche nonstop-System" hängt an einem 1A Billig-USB-Netzteil, ohne Probleme.
Siehe Bild im ersten Beitrag.
Zitat von: fh168 am 07 November 2015, 20:24:28
Verbrauch habe ich mal eben gemessen mit meinem Aldi- USB - Duo Ladegerät - Netzteil.
Ich habe 0,9 W gemessen, also am USB-Ausgang vom Raspi würde ich den nicht anschließen.
Ich habe einen mal eine Zeit lang am USB-Port von einem CubieTruck laufen lassen, das hat problemlos funktioniert.
Ob es der Raspi auch packt kann ich nicht sagen.
Aber 0,9W sind ca. 200mA, das sollte doch ein USB-Port hergeben?
stimmt, ich habe direkt an der steckdose gemessen. Das Aldi-Netzteil verbrät auch wohl einiges. Mein usb-doktor (-> siehe Blog-Beitrag: http://blog.moneybag.de/uebersicht-ueber-verschiedene-module-zur-hausautomation-fuer-fhem/) kommt am USB-Bus auf 100mA, sollte klappen. Spannungsspitzen nicht eingerechnet.
Standardmäßig lassen sich die vier USB-Ports beim Raspberry PI 2 mit zusammen 600mA belasten.
Man kann den Strom auch durch einen Eintrag in der " config.txt" auf 1200mA erhöhen.
Erklärt in diesem Blog: http://powerpi.de/mit-diesem-einfachen-trick-bekommst-du-mehr-strom-aus-den-usb-ports-am-raspberry-pi-2/ (http://powerpi.de/mit-diesem-einfachen-trick-bekommst-du-mehr-strom-aus-den-usb-ports-am-raspberry-pi-2/)
Nur der zusätzliche Bedarf muss ja irgendwie gedeckt werden, heißt das Netzteil für den RasPi muss entsprechend mehr Strom liefern.
http://www.elektronik-kompendium.de/sites/raspberry-pi/1912111.htm (http://www.elektronik-kompendium.de/sites/raspberry-pi/1912111.htm)
Zum Anderen ist der RasPi am Eingang mit einer 2A reversierbaren Sicherung geschützt und brauch selber schon bis zu 700mA.
Also alles ganz einfach, oder auch nicht. ;)
Gruß Friedrich
Zitat von: HCS am 07 November 2015, 22:41:07
eBay, Amazon, ... für so 15-20 EUR und in China für ca. die Hälfte.
Aber achtgeben, es muss das devkit V1.0 sein, nicht das 0.9
Sieht man die Versionsnummer auf der Platine? Bei ebay gibt es Angebote mit angeblich v1.0. Ich kann dort aber keine Versionsnummer erkennen.
Zitat von: Alexander am 09 November 2015, 19:53:43
Sieht man die Versionsnummer auf der Platine? Bei ebay gibt es Angebote mit angeblich v1.0. Ich kann dort aber keine Versionsnummer erkennen.
Das v0.9 devkit ist breiter.
Das ist v0.9: https://raw.githubusercontent.com/nodemcu/nodemcu-devkit/master/Documents/NodeMCU_DEVKIT_V0.9.png
Das ist v1.0: https://raw.githubusercontent.com/nodemcu/nodemcu-devkit-v1.0/master/Documents/NodeMCU_DEVKIT_1.0.jpg
Weitere Erkennungsmerkmale:
- v1.0 hat "FLASH" und "RST" Button, bei v0.9 ist es "USER" und "RST"
- auf dem v0.9 steht v0.9 drauf
Habe diese hier: http://bit.ly/1MlNkZO
Hi,
ich habe gedacht: super, wirklich eine tolle Anleitung - das probierst du auch einmal (meine 1. Versuche mit solcher Hardware und der Arduino-IDE).
Irgendwann hatte ich auch die Firmware drauf, ich kam auf die Setup-Seite. Super, danach die Daten für mein WLAN-Netzwerk erfasst und ... nichts.
Das Gateway hat sich nie verbinden können und ging nach 30 Sekunden immer wieder auf die 192.168.222.1 zurück (habe ziemlich lange gebraucht, bis ich das realisiert habe).
Da ich mein Passwort immer per Cut&Paste übernommen habe, habe ich das nie in Frage gestellt.
Aus lauter Verzweiflung habe ich dann aber doch mein Passwort geändert auf eine deutlich kürzere Variante und siehe da: jetzt geht es. Umkehrschluss: LaCrosseGateway.bin begrenzt anscheinend Passwörter in der Länge - was für mich aber ein ko-Kriterium ist.
Schön wäre es, wenn man auf der Setup-Seite auch eine statische IP bereits mitgeben könnte wie z.B. in der GatewayESP8266.ino möglich (die ich im Moment noch nicht verwenden kann, da ich Compile-Fehler bekomme, die ich nicht nachvollziehen kann).
Was ich weiter nicht verstehe:
Im Serial-Monitor steht als letztes:
[LaCrosseITPlusReader.Gateway.1.03 {IP=192.168.4.1}]
Die echte Adresse ist aber 192.168.11.21 - von dort bekomme beim Aufruf auch folgendes:
LaCrosseGateway V1.03
Uptime: 818 Seconds
Connected to: meinWLAN
MAC address: 18:FE:34:FA:F4:74
Chip ID: 16446580
Was ist das jetzt für eine IP (die 192.168.4.1)?
Gruß
Holger
Zitat von: Omega am 10 November 2015, 10:52:24
Aus lauter Verzweiflung habe ich dann aber doch mein Passwort geändert auf eine deutlich kürzere Variante und siehe da: jetzt geht es. Umkehrschluss: LaCrosseGateway.bin begrenzt anscheinend Passwörter in der Länge - was für mich aber ein ko-Kriterium ist.
Ja, aktuell können sowohl SSID als auch Passwort maximal 32 Zeichen lang sein. Das liegt momentan an der Settings-Speicherei im EEPROM, die ich gerade am überarbeiten bin.
Wie lang ist denn das Passwort?
Zitat von: Omega am 10 November 2015, 10:52:24Schön wäre es, wenn man auf der Setup-Seite auch eine statische IP bereits mitgeben könnte ...
Steht doch im ersten Beitrag unter "Geplante Features"
Zitat von: Omega am 10 November 2015, 10:52:24
Was ich weiter nicht verstehe:
Im Serial-Monitor steht als letztes:
[LaCrosseITPlusReader.Gateway.1.03 {IP=192.168.4.1}]
Die echte Adresse ist aber 192.168.11.21 - von dort bekomme beim Aufruf auch folgendes:
Was ist das jetzt für eine IP (die 192.168.4.1)?
Ist mir auch unklar. Das ist die IP, die mir die API nennt, wenn ich sie frage, welche IP wir bekommen haben.
Bei mir passt die aber auch. Ich schaue es mir mal an, warum das auch eine andere sein kann.
Zitat von: Omega am 10 November 2015, 10:52:24
[LaCrosseITPlusReader.Gateway.1.03 {IP=192.168.4.1}]
Hast Du keinen RFM12 oder RFM69 angeschlossen, weil da nichts davon drin steht?
Zitat von: oli82 am 10 November 2015, 10:36:29
Habe diese hier: http://bit.ly/1MlNkZO
Ja, der sieht gut und günstig aus. Wenn die auch das schicken, was auf dem Bild ist, dann ist OK.
@HCS:
Sollte ich dir in den nächsten 5-7 Tagen sagen können ;)
Zitat von: HCS am 10 November 2015, 13:28:18
Ja, aktuell können sowohl SSID als auch Passwort maximal 32 Zeichen lang sein. Das liegt momentan an der Settings-Speicherei im EEPROM, die ich gerade am überarbeiten bin.
Wie lang ist denn das Passwort?
Lt. Wiki ist ein WPA2-Passwort max. 63 Zeichen lang. Das sollte dann auch möglich sein.
Zitat
Steht doch im ersten Beitrag unter "Geplante Features"
um so besser ;D - danke.
Zitat
Hast Du keinen RFM12 oder RFM69 angeschlossen, weil da nichts davon drin steht?
Nein, noch nicht. Das kommt alles Schritt für Schritt. So lange die WLAN-Anbindung für mich noch nicht richtig funktioniert, hat das auch Zeit.
Mein eigentlicher Ansatz ist zunächst die kabelgebundene Anbindung 2er oder mehr DHT22 an das Gateway. Da gibt es wohl auch bereits Beispiele. Allerdings hast du für mich die einzelnen Schritte am ausführlichsten beschrieben, so dass ich - schon alleine um zu lernen - zunächst diese Variante nachvollziehen möchte.
Im Prinzip müsste das auch möglich sein, sowohl kabelgebundene Sensoren als auch die Funkanbindung parallel zu betreiben. Das Gateway dient doch nur als Brücke zwischen den Sensoren (Funk oder Kabel egal) und FHEM. Oder bin ich da auf dem berühmten Holzweg?
Zitat von: Omega am 10 November 2015, 14:37:53
Im Prinzip müsste das auch möglich sein, sowohl kabelgebundene Sensoren als auch die Funkanbindung parallel zu betreiben. Das Gateway dient doch nur als Brücke zwischen den Sensoren (Funk oder Kabel egal) und FHEM. Oder bin ich da auf dem berühmten Holzweg?
Da bist Du tatsächlich auf dem Holzweg. Das LaCrosseGateway empfängt LaCrosse Sensoren auf 868MHz und stellt die Daten für FHEM zur Verfügung.
Es ist nicht als universelle Brücke von "irgendwas" zu FHEM gedacht und auch nicht so verwendbar.
Da brauchst Du eine andere Lösung, panstamp, mysensors oder was auch immer.
Zitat von: Omega am 10 November 2015, 14:37:53
Lt. Wiki ist ein WPA2-Passwort max. 63 Zeichen lang. Das sollte dann auch möglich sein.
Ja, so wird es auch. War mir nur nicht aufgefallen, dass es beim EEPROM-Schreiben/Lesen abgeschnitten wird.
Zitat von: HCS am 10 November 2015, 15:44:34
Das LaCrosseGateway empfängt LaCrosse Sensoren auf 868MHz und stellt die Daten für FHEM zur Verfügung.
Einen Jeelink mit 868MHz habe ich bereits, daher wäre eine 433er Version für mich interessanter. Ginge das genauso mit einem RFM22B? Oder bin ich wieder zu blauäugig?
Zitat von: Omega am 10 November 2015, 16:38:48
Einen Jeelink mit 868MHz habe ich bereits, daher wäre eine 433er Version für mich interessanter. Ginge das genauso mit einem RFM22B? Oder bin ich wieder zu blauäugig?
Mit einem RFM12B oder RFM69CW. Keine Ahnung, ob ein RFM22B Software-kompatibel zum 12er oder 69er ist.
Aber: was willst Du denn auf 433 MHz empfangen? Das kann dann nur etwas sein, das das gleiche Protokoll wie einer der 868 MHz LaCrosse Sensoren sendet, nur halt auf 433 MHz.
Oder ich versuche es mal anders zu beschreiben: so ein Sketch kann nicht einfach irgend etwas empfangen, sondern nur das, wofür das Protokoll des Sensors implementiert wurde.
Und das ist hier aktuell mal genau das, was auch der LaCrosse-Sketch für den JeeLink beherscht, siehe dort bzw. wiki.
@ HCS
Die ESP8266 sind gestern schon angekommen (http://bit.ly/1MlNkZO)
Wenn der Aufdruck stimmt, un die Module funktionieren, sind sie eine günstige Alternative zur Bucht.
(http://www.oli82.de/files/fhem/esp8266.jpeg)
Zitat von: HCS am 10 November 2015, 17:01:10
Aber: was willst Du denn auf 433 MHz empfangen?
;) Ich habe noch ein paar alte Sender von TFA, die auf 433 MHz senden. Die möchte ich bei Gelegenheit auch mit verwenden.
Letztendlich ist es wohl eine Frage der Software, wie welcher Sender implementiert wird.
Hallo,
sehr interessantes Projekt!!!
Da ich gelesen habe, dass man damit die WH1080 Wetterstation auslesen kann hab ich mir gedacht, dass baue ich mal nach.
Eine nodemcu war eh schon bestellt (sogar glücklicherweise eine v1.0).
Gestern Abend hab ich die Firmware installiert und konnte mich auch über die IP verbinden und die Daten zum AcccessPoint eingeben.
Leider komme ich da aktuell noch nicht weiter. Auf der seriellen Schnittstelle erhalte ich fortlaufend diese Anzeige:
Exception (0):
epc1=0x40202e61 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
ctx: cont
sp: 3fff04d0 end: 3fff06c0 offset: 01a0
>>>stack>>>
3fff0670: 00000000 00000000 00000000 00000000
3fff0680: 00000000 00000000 00000000 00000000
3fff0690: 00000000 00000000 00000000 3ffef698
3fff06a0: 3fffdc20 00000000 3ffef690 402088ce
3fff06b0: 00000000 00000000 3ffef6a0 40100114
<<<stack<<<
Ich muss dazu sagen, das der AccessPoint eine versteckte SSID hat, kann das ein Problem sein??
Ein RFM ist leider auch noch nicht angeschlossen, der fehlt mir noch. Kennt da jemand zufällig eine günstige Quelle in DE ohne große Versandkosten??
Bin für Tipps dankber.
Gruß
Olly
Zitat von: Olly am 12 November 2015, 16:32:43
Exception (0):
...
OK, dann müsen wir forschen beginnen.
Weist Du noch, ob im Konfigurations-Frontend, als Du SSID/password konfiguriert hast, V1.03 oder eine andere Version drüber Stand?
Kannst Du mal zum Test die SSID sichtbar machen, ob es daran liegt?
Hast Du ihn mal von der Spannungsversorgung getrennt und wieder angeschlossen?
Kannst Du mal mit 57600 Baud auf der seriellen schauen, ob er vor dem Crash beginnt, Punkte auszugeben?
Nachtragsfrage: blinkt der ESP fünf mal, nachdem Du ihn mit der Spannungsversorgung verbunden hast?
Zitat von: HCS am 12 November 2015, 17:37:44
OK, dann müsen wir forschen beginnen.
Weist Du noch, ob im Konfigurations-Frontend, als Du SSID/password konfiguriert hast, V1.03 oder eine andere Version drüber Stand?
Kannst Du mal zum Test die SSID sichtbar machen, ob es daran liegt?
Hast Du ihn mal von der Spannungsversorgung getrennt und wieder angeschlossen?
Kannst Du mal mit 57600 Baud auf der seriellen schauen, ob er vor dem Crash beginnt, Punkte auszugeben?
Nachtragsfrage: blinkt der ESP fünf mal, nachdem Du ihn mit der Spannungsversorgung verbunden hast?
Hallo HCS,
also installiert ist die Version V1.03, das gibt er auch aus.
Es kommen ein paar Punkte (so ca. 8-10) und dann die angegebene Meldung.
Leider hab ich nicht drauf geachtet, ob und wie oft die LED blinkt. Muss ich dann noch mal nachstellen. Werde ebenfalls mal mit meinem sichtbaren Gast-Netzwerk testen.
Der ESP sollte sich aber auch ohne angeschlossenes RFM-Modul erst mal mit dem AccessPoint verbinden, oder?
Gruß
Olly
So, noch mal getestet.
Beim starten blinkt die blaue LED ein paar mal schnell. Aber auch wenn ich mich versuche mit einem nicht versteckten Netzwerk zu verbinden klappt das nicht. Teilweise geht der ESP dann auch einfach wieder in den AP-Mode und man kann sich per Browser wieder verbinden und das Netzwerk erneut konfigurieren.
Hab das ganze jetzt mit 4 Netzwerken probiert.
Any Ideas???
Gruß
Olly
Hallo,
ich habe exakt den gleichen Fehler. Das setup ging einwandfrei, aber nachdem die Daten für SSID und Passwort drin waren, crashed das Ding immer an der gleichen Stelle. Zum Test, ob es am NodeMCU liegt habe ich mal einen Sketch mit Arduino raufgespielt. Das lief problemlos. Liegt also m.E. nicht an kaputter Hardware. Kann ich irgendwie beim debuggen helfen?
Aktuell hat die Verwaltung der Settings noch ein Problem. Das Passwort darf nicht länger als 32 Zeichen sein und auch bestimmte Sonderzeichen nicht enthalten.
Ich mache am Samstag eine Version, mit der das hoffentlich besser geht.
Die hat dann auch auf der Seriellen ausreichend Debug-Ausgaben, um zu sehen, was genau abläuft.
Zitat von: HCS am 13 November 2015, 07:15:29
Aktuell hat die Verwaltung der Settings noch ein Problem. Das Passwort darf nicht länger als 32 Zeichen sein und auch bestimmte Sonderzeichen nicht enthalten.
Ich mache am Samstag eine Version, mit der das hoffentlich besser geht.
Die hat dann auch auf der Seriellen ausreichend Debug-Ausgaben, um zu sehen, was genau abläuft.
Hallo,
also ich hab ja an verschiedenen AccessPoints ausprobiert. Alle haben bei SSID und Passwort definitiv weniger als 32 Zeichen. Einer hat als Passwort nur Zahlen, mein Gast-Netz bei beidem nur jeweils 8 Buchstaben. Zwei Netze mit Sonderzeichen im Passwort habe ich auch, da würde ich das dann ja verstehen.
Wenn ich mit debugging helfen kann, immer her mit den Infos dazu.
Nochmal die Frage: Am momentan noch nicht angeschlossenem RFM kann es nicht liegen, oder?
Gruß
Olly
Ob es ohne RFM geht, kann ich in der Bahn gerade nicht testen. Solltest einen beschaffen, ohne macht das eh keinen Spass. :D
Ansonsten bitte etwas Geduld bis morgen, dann können wir besser testen.
Reden wir aktuell über crash oder hartnäckiges Öffnen des AP?
Ja, ohne RFM bringt nicht so viel.
Ich suche gerade noch eine günstige Quelle aus Deutschland.
Pollin hat den zwar im Programm, aber nur dafür bestellen....
Bei mir sieht es nach Crash und reboot aus.
Aber warten wir mal auf deine neue Version Morgen.
Gruß
Olly
Zitat von: Olly am 13 November 2015, 09:41:12Ich suche gerade noch eine günstige Quelle aus Deutschland.
Habe ich leider auch keine, ich habe meine Sammlung an RFM12, 69, 433MHz, 866MHz mal vor ewigen Zeiten in größerer Stückzahl bei irgendwas mitbestellt, und seitdem ausreichend da 8)
Zitat von: Olly am 13 November 2015, 09:41:12
Bei mir sieht es nach Crash und reboot aus.
Die Firmware geht auf alle Fälle davon aus, dass das erste Radio da ist, für das optionale zweite schaut sie dann, ob das auch da ist.
Ich bin mir nicht sicher, was der SPI Bus macht, wenn absolut nichts dran ist und ob das überhaupt ein konsistentes Verhalten dann ist.
Wobei das bei Omega wohl auch ohne lief:
[LaCrosseITPlusReader.Gateway.1.03 {IP=192.168.4.1}]Da war auch kein RFM dran, sonst würde es drinstehen. Aber das kann, wie gesagt, auch ein Zufallsgeschäft sein, wenn man keinen dran hat.
Falls Du einen RFM12B da hast, den kannst Du auch nehmen.
Zitat von: HCS am 13 November 2015, 11:30:17
Habe ich leider auch keine, ich habe meine Sammlung an RFM12, 69, 433MHz, 866MHz mal vor ewigen Zeiten in größerer Stückzahl bei irgendwas mitbestellt, und seitdem ausreichend da 8)
Die Firmware geht auf alle Fälle davon aus, dass das erste Radio da ist, für das optionale zweite schaut sie dann, ob das auch da ist.
Ich bin mir nicht sicher, was der SPI Bus macht, wenn absolut nichts dran ist und ob das überhaupt ein konsistentes Verhalten dann ist.
Wobei das bei Omega wohl auch ohne lief:
[LaCrosseITPlusReader.Gateway.1.03 {IP=192.168.4.1}]
Da war auch kein RFM dran, sonst würde es drinstehen. Aber das kann, wie gesagt, auch ein Zufallsgeschäft sein, wenn man keinen dran hat.
Falls Du einen RFM12B da hast, den kannst Du auch nehmen.
Hmm, Mist,
dann muss ich mal schauen, wo ich was her bekomme. Hab leider auch keinen RFM12 :-(
Gruß
Olly
Hab auch so meine Probleme mit dem Modul.
Leider verbindet es nicht mit meinem WLan.
Nach mehreren Reboots bekomme ich dann folgende Meldung:
[LaCrosseITPlusReader.Gateway.1.03 (RFM12 f:868300 r:17241) + BMP180 {IP=192.168.4.1}]
Über diese IP komme ich wieder auf die Setup Seite.
EDIT:
Nun habe ich mal ein RFM69 Modul angeschlossen:
Nach dem Programmstart und eintragen meiner WLAN Zugangsdaten folgt dann:
.............
Exception (0):
epc1=0x40202e61 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
ctx: cont
sp: 3fff04d0 end: 3fff06c0 offset: 01a0
>>>stack>>>
3fff0670: 00000000 00000000 00000000 00000000
3fff0680: 00000000 00000000 00000000 00000000
3fff0690: 00000000 00000000 00000000 3ffef698
3fff06a0: 3fffdc20 00000000 3ffef690 402088ce
3fff06b0: 00000000 00000000 3ffef6a0 40100114
<<<stack<<<
Ahh, ist interessant, "Olly" hat es auch bei 0x40202e61 zerlegt.
Zitat von: oli82 am 13 November 2015, 14:33:38.............
Exception (0):
Das sieht so aus, als ob er nach dem erfolgreichen Verbinden mit dem konfigurierten wlan stirbt.
Ich nehme mal in der Version für morgen noch MDNS und das Bereitstellen des OTA Ports raus, um das als Ursache auzuschließen.
............. bedeutet, dass er nach 6,5 Sekunden eine Verbindung hatte.
Einen DHCP-Server habt ihr ja laufen, nehme ich mal an?
Weil, wenn er sich auf eurem AP anmelden konnte, aber dann keine IP bekommt, läuft vermutlich auch noch einiges aus dem Ruder.
Zitat von: oli82 am 13 November 2015, 14:33:38EDIT:
Nun habe ich mal ein RFM69 Modul angeschlossen:
Nach dem Programmstart und eintragen meiner WLAN Zugangsdaten folgt dann:
.............
Exception (0):
epc1=0x40202e61 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
Verstehe ich das richtig, dass der crash nur mit dem RFM69 kommt und nicht mit dem RFM12?
Es bleibt dabei, mit der Version morgen haben wir mehr logging und sehen, wo es stirbt.
Leider tritt der Fehler bei beiden Modulen auf
@HCS, womit erstellt du die .bin Datei bzw. was benutzt du aktuell an Quellcode ?
K.A. wieviel Arbeit du bis jetzt investiert hast, aber wäre die Arduino 1.6.5 IDE nicht eine Alternative ?
Zitat von: HCS am 13 November 2015, 16:38:49
Ahh, ist interessant, "Olly" hat es auch bei 0x40202e61 zerlegt.
Das sieht so aus, als ob er nach dem erfolgreichen Verbinden mit dem konfigurierten wlan stirbt.
Ich nehme mal in der Version für morgen noch MDNS und das Bereitstellen des OTA Ports raus, um das als Ursache auzuschließen.
............. bedeutet, dass er nach 6,5 Sekunden eine Verbindung hatte.
Einen DHCP-Server habt ihr ja laufen, nehme ich mal an?
Weil, wenn er sich auf eurem AP anmelden konnte, aber dann keine IP bekommt, läuft vermutlich auch noch einiges aus dem Ruder.
Verstehe ich das richtig, dass der crash nur mit dem RFM69 kommt und nicht mit dem RFM12?
Es bleibt dabei, mit der Version morgen haben wir mehr logging und sehen, wo es stirbt.
Also ich habe einen RFM12 dran und habe genau den gleichen Stacktrace. Außerdem scheint der ESP noch nach einer IP zu fragen bevor er stirbt. So sieht es im syslog aus:
Nov 13 00:10:07 neon dhcpd: DHCPDISCOVER from 5c:cf:7f:xx:xx:xx via local
Nov 13 00:10:07 neon dhcpd: DHCPOFFER on 192.168.1.26 to 5c:cf:7f:xx:xx:xx (ESP_XXXXXXX) via local
Nov 13 00:10:08 neon dhcpd: DHCPDISCOVER from 5c:cf:7f:xx:xx:xx (ESP_XXXXXX) via local
Nov 13 00:10:08 neon dhcpd: DHCPOFFER on 192.168.1.26 to 5c:cf:7f:xx:xx:xx (LaCrosseGateway) via local
Ein DHCPACK kommt nicht mehr.
Zitat von: Wzut am 13 November 2015, 18:05:41
@HCS, womit erstellt du die .bin Datei bzw. was benutzt du aktuell an Quellcode ?
K.A. wieviel Arbeit du bis jetzt investiert hast, aber wäre die Arduino 1.6.5 IDE nicht eine Alternative ?
Genau damit entwickle ich es. Mit dem "Arduino core for ESP8266".
Nur so konnte die ganzen Libraries für RFM, LaCrosse, EMT7110, WSxxx usw. gemeinsam für den Arduino-LaCrosse Sketch und hierfür verwenden.
Ich werde auch irgendwann den Quellcode veröffentlichen und die Entwicklungsumgebung beschreiben (für die Arduino IDE).
Allerdings kommt es da drauf an, dass man die exakt passenden Libraries aus dem "Arduino core for ESP8266" Projekt verwendet und sonst noch einiges in der Entwicklungsumgebung wirklich passt. Vorerst will ich aber vermeiden, dass zusätzliche Rätsel durch unterschiedliche Entwicklungsumgebungen entstehen, die sich unterschiedlich verhaltende Firmwares produzieren. Als Entwicklungsumgebung verwende ich Visual Studio mit dem "Visual Micro" Plugin das die Arduino 1.6.5 toolchain verwendet.
@All:Nun zur Version 1.04, die ich gerade an den ersten Beitrag oben gehängt habe:
Wichtig: Das Speichern der Settings im EEPROM hat sich geändert (u.A. wg. dem Passwort, das 63 Zeichen lang sein darf).
Das führt leider dazu, dass die bisher gespeicherten Settings nicht mehr funktionieren. Nach dem flashen der 1.04 wird das LGW (ab sofort die Abkürzung für LaCrosseGateway) also erst mal in den AP Modus gehen, und man muss auf der Setup-Page SSID und Passwort nochmal setzen. Wenn man das speichert, dann macht das LGW einen Reset. Das klappt aber (vermutlich wegen Problemen, die es noch in der API gibt) häufig, aber leider nicht immer. Darum ggf. den ESP einfach danach mal von der Spannungsversorgung trennen und wieder verbinden, dann macht er garantiert einen reset.
Um zu verfolgen, was beim Start des LGW passiert, protokolliert man die Ausgaben auf der seriellen Schnittstelle mit 57600 Baud mit.
Die könnt ihr dann mal posten, um zu schauen, wo wir stecken bleiben.
Passwort und ggf. SSID in dem Log vor dem posten anonymisieren, die wollen wir ja nicht publik machen. Vorher aber mal schauen, ob sie mit dem, was auf "/setup" eingegeben wurde, übereinstimmen.
Wenn das LGW sich auf den konfigurierten AP verbinden kann, sieht das Log so aus:
This is line 5 of void setup(void)
Read settings
Settings are:
Key:ctSSID Val:mySSID
Key:ctPASS Val:myPassword
Starting wifi
Trying to connect to an AP
......
connected :-)
SSID: mySSID
IP: 192.168.31.126
OTA running on port 8266
Searching RFMs and BMP
First RFM found: RFM69
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.04 (RFM69 f:868300 r:17241) {IP=192.168.31.126}]
Setup completely done
OK 9 38 1 4 86 70
OK 9 45 130 2 219 125 Wenn es keine Verbindung bekommt, dann so:
This is line 5 of void setup(void)
Read settings
Settings are:
Key:ctSSID Val:mySSID
Key:ctPASS Val:WrongPassword
Starting wifi
Trying to connect to an AP
..............................
We got no connection :-(
Starting Access point
Access point running: LaCrosseGateway_15936302
Searching RFMs and BMP
First RFM found: RFM69
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.04 (RFM69 f:868300 r:17241) {IP=192.168.222.1}]
Setup completely done
OK 9 2 1 4 176 106
OK 9 48 1 4 162 65
OK 9 45 1 4 173 106Ich habe dann noch getestet, ob das LGW auch ohne RFM läuft (auch wenn es keinen Sinn macht, außer man will nichts empfangen sondern nur einen BMP180 draufpacken).
Bei mir geht das.
Zitat von: HCS am 14 November 2015, 12:08:41
Ich werde auch irgendwann den Quellcode veröffentlichen und die Entwicklungsumgebung beschreiben
Sehr schön, freue mich schon darauf das nach meinem Urlaub auch mal von Grund auf zu testen.
Hallo,
Hört sich gut an mit der neuen Firmware. Werde sie heute Abend mal ausprobieren und mein Log dann posten.
Gruß
Olly
Bei mir läuft der ESP jetzt mit der 1.04. Allerdings wurde ich nicht nach neuen Setup-Einstellungen gefragt, sondern er hat sich direkt mit den alten Einstellungen mit meinem AP verbunden.
Das kam auf der seriellen raus.
This is line 5 of void setup(void)
Read settings
Settings are:
Starting wifi
Trying to connect to an AP
..
connected :-)
SSID: XXXX
IP: 192.168.1.26
OTA running on port 8266
Searching RFMs and BMP
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.04 {IP=192.168.1.26}]
Setup completely done
Ich habe zwar einen RFM12B dran, aber den scheint er nicht zu finden. Vielleicht habe ich den auch falsch verdrahtet. Hat jemand einen Link auf ein Bild wie ich den richtig mit dem ESP verdrahten muss?
EDIT: Beim 2. Neustart des ESP hat er dann auch den RFM12B gefunden und sofort irgendwas auf der seriellen geloggt.
OK 9 8 1 4 73 106
OK 9 8 1 4 73 106
OK 9 8 1 4 56 106
OK 9 8 1 4 73 106
OK 9 8 1 4 56 106
OK 9 8 1 4 73 106
OK 9 8 1 4 56 106
Hallo,
ich kann mit der Version 1.04 auch einen Teil-Erfolg melden.
Verbindung zu meinem Gastnetzwerk funktioniert:
This is line 5 of void setup(void)
Read settings
Settings are:
Key:ctSSID Val:xxxxxxxx
Key:ctPASS Val:yyyyyyyy
Starting wifi
Trying to connect to an AP
.....
connected :-)
SSID: xxxxxxxx
IP: 192.168.179.22
OTA running on port 8266
Searching RFMs and BMP
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.04 {IP=192.168.179.22}]
Setup completely done
Beim Versuch mich mit meinem "normalen" WLAN zu verbinden hängt es noch etwas. Habe aber den Grund wohl schon gefunden. Mein Passwort enthält das Zeichen "#" als Sonderzeichen, das mag der ESP wohl in der momentanen Version noch nicht. Im Log wird das Zeichen als %23 angegeben, so wird es vom Browser wohl auch übermittelt.
Hab mal als Gegentest das Passwort ohne das Sonderzeichen gesetzt, dann klappt die Verbindung (sogar zum versteckten Netzwerk).
Liegt das jetzt speziell am #-Zeichen, oder gibt es generell noch Probleme mit Sonderzeichen?
Gruß
Olly
Prima, langsam kommen wie in die Spur.
Zitat von: BlackFlag am 14 November 2015, 16:14:01Allerdings wurde ich nicht nach neuen Setup-Einstellungen gefragt, sondern er hat sich direkt mit den alten Einstellungen mit meinem AP verbunden.
Das kam auf der seriellen raus.
Interessanterweise verbindet sich der ESP wieder auf den AP, mit dem er zuletzt verbunden war, wenn man der API SSID und Passwort leer rein gibt, und genau das passiert, wenn man noch die alten Settings im EEPROM hat. Solltest sie trotzdem mal neu speichern.
Zitat von: BlackFlag am 14 November 2015, 16:14:01
OK 9 8 1 4 73 106
OK 9 8 1 4 73 106
Dann solltes Du eigentlich jetzt mit
define myJeeLink JeeLink 192.168.1.26:81ein JeeLink device anlegen können und in FHEM Daten empfangen.
Zitat von: Olly am 14 November 2015, 21:49:03
[LaCrosseITPlusReader.Gateway.1.04 {IP=192.168.179.22}]
Brauchst halt noch einen oder zwei RFM und wenn Du Lust hast einen BMP180
Zitat von: Olly am 14 November 2015, 21:49:03Liegt das jetzt speziell am #-Zeichen, oder gibt es generell noch Probleme mit Sonderzeichen?
Sonderzeichen in den Settings gehen generell noch nicht, da bin ich gerade dran.
Wie es weiter geht: Sonderzeichen in Settings, Hostame konfigurierbar und optional statische IP anstatt DHCP.
Zitat
Wie es weiter geht: Sonderzeichen in Settings, Hostame konfigurierbar und optional statische IP anstatt DHCP.
Hallo,
erst mal einen riesigen Dank für deine geleistete Programmierung!!!
Dann warte ich mal auf deine weiteren Versionen. Statische IP und die Sonderzeichen sind das, was mir dann noch fehlen.
Vielleicht schaffe ich es ja auch dann mal einen RFM an den Start zu bringen.
Gruß
Olly
Hallo,
bin gerade über diesen Thread gestolpert: sehr interessante Sache. Muss ich mir mal anschauen.
Gruß PeMue
Zitat von: HCS am 15 November 2015, 08:47:34
Dann solltes Du eigentlich jetzt mit
define myJeeLink JeeLink 192.168.1.26:81
ein JeeLink device anlegen können und in FHEM Daten empfangen.
Device anlegen ging auch. Habe dann ewig gesucht, bis ich herausbekommen habe, dass empfangene Sensoren nur hinzugefügt werden, wenn man LaCrossePairForSec auch mal auf 120 setzt. Dann hat FHEM einen Temperaturfühler gefunden. Der wechselt jetzt ständig (quasi im Sekundentakt) zwischen 2 Temperaturen hin- und her. Kann es sein, dass ich zufällig 2 mit der gleichen ID habe?
Zitat von: HCS am 15 November 2015, 08:47:34
Prima, langsam kommen wie in die Spur.
Interessanterweise verbindet sich der ESP wieder auf den AP, mit dem er zuletzt verbunden war, wenn man der API SSID und Passwort leer rein gibt, und genau das passiert, wenn man noch die alten Settings im EEPROM hat. Solltest sie trotzdem mal neu speichern.
Wie soll ich denn die Settings neu speichern? Das Setup kommt ja gar nicht mehr, weil der ESP nicht als AP startet. Kann man den Konfigurationsspeicher des ESP löschen (mit esptool evtl.)?
Zitat von: BlackFlag am 15 November 2015, 12:47:10
Wie soll ich denn die Settings neu speichern? Das Setup kommt ja gar nicht mehr, weil der ESP nicht als AP startet. Kann man den Konfigurationsspeicher des ESP löschen (mit esptool evtl.)?
Hi,
du kannst dich doch auch mit dem konfigurierten Gateway verbinden. Einfach die per DHCP erhaltene IP /setup im Browser aufrufen, dann kommst du doch auch auf die Konfigurationssite und kannst SSID und Passwort noch mal eingeben.
Gruß
Olly
Zitat von: Olly am 15 November 2015, 13:15:30
Hi,
du kannst dich doch auch mit dem konfigurierten Gateway verbinden. Einfach die per DHCP erhaltene IP /setup im Browser aufrufen, dann kommst du doch auch auf die Konfigurationssite und kannst SSID und Passwort noch mal eingeben.
Gruß
Olly
Danke, auf die Idee bin ich nicht gekommen. Das war zu einfach ;-).
Zitat von: BlackFlag am 15 November 2015, 12:29:21Der wechselt jetzt ständig (quasi im Sekundentakt) zwischen 2 Temperaturen hin- und her. Kann es sein, dass ich zufällig 2 mit der gleichen ID habe?
Ja, sieht so aus. Mach mal aus einem die Batterien raus und wieder rein, dass er eine neue ID bekommt.
Version 1.05 (am ersten Beitrag):
- Die Konfiguration geht nun auch mit Sonderzeichen im Passwort usw.
- Man kann den Hostname und eine statische IP-Adresse anstatt DHCP konfigurieren.
Wenn DHCP verwendet werden soll, lässt man IP-Adresse, Mask und Gateway leer.
- Da man sich mit der statischen IP bei einer Fehlkonfiguration den Ast absägen kann, gibt es jetzt ein Command, um das EEPROM zu leeren,
was dazu führt, dass man wieder den Access Point bekommt und neu konfigurieren kann.
Dazu setzt man von einem Terminalprogramm an der seriellen Schnittstelle mit 57600 Baud das Command 0e ab.
Wow, das geht ja hier mit riesigen Schritten voran.
Klappt jetzt bei mir auch mit dem Passwort mit Sonderzeichen und auch mit statischer IP.
This is line 5 of void setup(void)
Read settings
Settings are:
Key:ctSSID Val:xxxxxx
Key:ctPASS Val:xxxxxx
Key:staticIP Val:192.168.xxx.xx
Key:staticMask Val:255.255.255.0
Key:staticGW Val:192.168.xxx.yy
Key:HostName Val:LaCrosseGateway
Starting wifi
HostName is: LaCrosseGateway
Using static IP
IP: 192.168.xxx.xx
Mask: 255.255.255.0
Gateway: 192.168.xxx.yy
Trying to connect t an AP
........
connected :-)
SSID: xxxxxxxx
IP: 192.168.xxx.xx
OTA running on port 8266
Searching RFMs and BMP
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.05 {IP=192.168.xxx.xx}]
Setup completely done
Einzig die Ausgabe auf der seriellen Schnittstelle ist noch nicht perfekt positioniert ;-)
Jetzt muss ich aber wirklich sehen, dass ich mir nen RFM besorge um weiter zu testen.
Danke und Gruß
Olly
Guten Morgen.
Bei mir läuft es nun auch. Jetzt folgt erstmal ein Langzeittest.
Danke für die schnelle Umsetzung.
Zitat von: Olly am 15 November 2015, 22:49:48Einzig die Ausgabe auf der seriellen Schnittstelle ist noch nicht perfekt positioniert ;-)
Das sieht aber bei mir deutlich besser aus. Mit was schaust Du denn auf die Schnittstelle?
Ahh, gerade ahne ich es, das sind die Zeilen, die ich nur mit \n enden lasse und nicht mit \r\n
Kann ich noch optimieren ...
Wichtig: Die offizielle Unterstützung der WS 1080 revidiere ich vorerst mal. Wie sich im LaCrosse Thread inzwischen herausstellt, gibt es die WS 1080 auch unter gleichem Namen in verschieden Versionen und nicht alle senden ein Protokoll, das wir verstehen.
Bis zur endgültigen Klärung würde ich von der Anschaffung einer WS 1080 abraten. Wer eine hat, kann natürlich gerne mal probieren und auch bei Erfolg mal eine Rückmeldung geben.
In diesem Tread wird die WS1080 auch behandelt.
http://forum.fhem.de/index.php?topic=39451.new;topicseen#new (http://forum.fhem.de/index.php?topic=39451.new;topicseen#new)
Hier klappt anscheinend die Einbindung.
Zitat von: AxelSchweiss am 20 November 2015, 08:41:22In diesem Tread wird die WS1080 auch behandelt.
http://forum.fhem.de/index.php?topic=39451.new;topicseen#new (http://forum.fhem.de/index.php?topic=39451.new;topicseen#new)
Hier klappt anscheinend die Einbindung.
Ja genau. Bin über SignalDuino nicht genau im Bilde, aber das empfängt doch OOK?
Das würde bedeuten, dass die 14c gekennzeichneten Stationen OOK senden, und darum mit SignalDuino gehen und nicht mit dem LaCrosse Sketch, der FSK empfängt.
Nachtrag: habe gerade mal bei der SignalDuino Truppe nachgefragt.
Nachdem es beim mir und fh168 über längere Zeit stabil läuft (einer von meinen ist nun 6 Tage konstant up und empfängt meinen kompletten LaCrosse-Zoo incl. WS 1600 und EMT7110) geht es dann mit etwas (noch nicht implementiertem) Feintuning weiter.
aufgegriffene Vorschläge u.A von fh168 (kannst sie ruhig hier posten, dann muss ich es nicht nochmal wiedererholen):
Lichtsignale:
Beim Start und der Initialisierung mit der Borad-eigenen LED signalisieren, was gerade passiert (könnte so ungefähr werden):
5 Schnelle blinks direkt nach dem Start, als Zeichen, dass ein Reset stattgefunden hat (ist bereits so)
Blinken im Sekundentakt, während versucht wird, sich mit einem wlan zu verbinden.
LED aus, wenn der Connect zu einem wlan geklappt hat und dann vereinzeltes Blinken, wenn Daten an FHEM übermittelt werden (ist bereits so)
Dauerleuchten, wenn kein Connect zu einem wlan möglich war und der AccessPoint geöffnet wurde.
Setup-page:
Die Setup-Page ist ja auf 192.168.222.1/setup zu erreichen.
Wenn kein connect zu einem wlan möglich war und desshalb der Acces Point geöffnet wurde, erreicht man die Setup-page direkt auf 192.168.222.1 ohne /setup hinten dran.
Web-Frontend erweitern:
So Dinge wie "Uptime: 484473 Seconds" verbessern zu "5 Tage 14 Std. 34 Min. 33 Sec" (das ist übrigens gerade die aktuelle UP-Time von meinem Testsystem) und den Überlauf nach 50 Tagen behandeln
Status-Informationen in FHEM
Ich schreibe gerade im Zusammenhang mit Davis Vantage ein universelles FHEM-Modul (36_KeyValueProtocol), das universell Daten entgegenenehmen und zu Readings umsetzen kann.
Der Sketch wird dann solche Dinge wie Up-Time usw. in diesem Format übermitteln, so dass man sie in FHEM zur Verfügung hat.
Wie gesagt, das ist der Plan, werde mich dann mal ans Implementieren machen.
Sinnvolle Ideen, Anmerkungen und Rückmeldungen sind willkommen.
Hi
Ich würde das Gateway gerne in mein Netzwerkmonitoring (Nagios+Cacti) mit einbeziehen.
Dazu wäre eine Statuspage sehr nützlich.
Vielleicht lässt sich ja eine implementieren.
z.B.:
Get http://192.168.222.1/status
uptime: 484473
registered devices: 4
messages per second : 23
usw.. was eben noch interessant ist
Dann könnte ich nämlich prüfen ob das Gateway noch sauber funktioniert .... ein Ping ist dazu etwas wenig.
Wichtig wäre mir das die Statusseite ganz simpel aufgebaut ist und ich sie nicht erst mit einem HTML-Parser durchforsten muss.
Einfach plain ASCII raushauen.
Zitat von: AxelSchweiss am 21 November 2015, 12:02:47
Get http://192.168.222.1/status
uptime: 484473
registered devices: 4
messages per second : 23
usw.. was eben noch interessant ist
Das ist eigentlich genau das, was ich mit der 36_KeyValueProtocol Schiene vorhabe.
Das LGW sendet alle x Sekunden diese informationen. Das Modul in FHEM stellt diese Daten als Readings zur Verfügung. Sieht dann z.B. so aus:
Internals:
DEF LGW 12345
ID LGW_12345
IODev myJeeLink
LASTInputDev myJeeLink
MSGCNT 19
NAME KeyValueProtocol_LGW_12345
NR 235
STATE Initialized
TYPE KeyValueProtocol
model LGW
myJeeLink_MSGCNT 19
myJeeLink_RAWMSG OK VALUES LGW 12345 UpTime:2345678, SSID:MyCoolNetwork,LastReceiveTime:2015-11-17 13:39:14,Mode:OK,Connected,Cool,OTA:Ready,MeesagesPerSecond:23
myJeeLink_TIME 2015-11-21 12:10:59
CHANGETIME:
Readings:
2015-11-21 12:10:59 LastReceiveTime 2015-11-17 13:39:14
2015-11-21 12:10:59 MeesagesPerSecond 23
2015-11-21 12:10:59 Mode OK,Connected,Cool
2015-11-21 12:10:59 OTA Ready
2015-11-21 12:10:59 SSID MyCoolNetwork
2015-11-21 12:10:59 UpTime 2345678
Attributes:
IODev myJeeLink
room KeyValueProtocol Man hat also ein Device in FHEM, das die aktuellen Statuswerte des LGW darstellt.
Würde das Deinen use case mit abdecken?
Hmmm ... nun ja .... nicht ganz
Ich würde das gerne direkt vom Gateway haben und nicht über den Umweg mit FHEM.
Das hat aber prinzipielle Gründe.
Wenn ich wissen möchte wie es einem Patienten geht frage ich ja auch nicht seinen Kumpel sondern direkt den Patienten.
Ich möchte einfach vermeiden das ich in FHEM einen alten Status bekomme und dann davon ausgehe das das Gateway noch lebt.
Eigentlich würde die Anzahl der Messages/Minute ausreichen.
Dann kann ich prüfen ob ich hier unter einen kritischen Wert falle.
OK, verstanden so weit.
Wird aber etwas dauern, die Statusgeschichte im Frontend war so eine erste quick&dirty Aktion. Das muss ich mal auf einen ordentlichen Status-Handler umbauen, der dann die ermittelten Werte als HTML für das Frontend (also für den Menschen) und als Daten für eine Maschine und für FHEM raus geben kann.
Muss es wirlich plain ASCII sein? Das muss man ja auch irgendwie parsen. Für XML könnte ich mich schon eher begeistern.
So in der Art:
<?xml version="1.0" encoding="UTF-8"?>
<LGW>
<Info Key="MeesagesPerSecond" Value="23" />
<Info Key="UpTime" Value="2345678" />
</LGW>
Nachtrag: da könnte man dann sogar mit XSLT transformieren und sich sein eigenes hübsches XML draus machen.
Wenn's für dich einfacher ist dann nimm XML
Zitat von: AxelSchweiss am 21 November 2015, 12:40:03
Wenn's für dich einfacher ist dann nimm XML
OK, das LGW würde dann bei 192.168.1.2/status das XML liefern. Dann ist es eigentlich ein REST Web Service. Hat auch was :)
Messages/Minute
Ich vermute, das soll eine gleitende Minute sein, und angeben, wie viele Pakete von Sensoren erfolgreich empfangen, decodiert und an FHEM zugestellt wurden?
Ich habe es auf der ToDo. Jetzt brauchst Du nur noch Geduld ...
Zitat von: HCS am 21 November 2015, 12:47:35
Messages/Minute
Ich vermute, das soll eine gleitende Minute sein, und angeben, wie viele Pakete von Sensoren erfolgreich empfangen, decodiert und an FHEM zugestellt wurden?
Ich habe es auf der ToDo. Jetzt brauchst Du nur noch Geduld ...
Ja genau ... dann sieht man den aktuellen Durchsatz ... und somit weisst du das da noch "Bewegung" ist.
Geduld habe ich ... da ich selbst beim Programieren bei Turbo Pascal 5.5 stehen geblieben bin ... und das nur rudimentär gemacht habe :)
Daher .... Vielen Dank schon mal
Ich habe heute versucht die .bin Datei aus dem ersten Post mit dem esptool (Link auch aus dem ersten Post) auf einen ESP8266-12 zu flashen.
Leider ohne Erfolg :(
Auf meiner Festplatte hatte ich aber noch ein Python esptool.py , damit konnte ich das File erfolgreich flashen :
esptool.py -p /dev/ttyUSB0 write_flash 0x00000 ./LaCrosseGateway.bin
Nach einem Reset ist der AccesPoint und die Setup Seite erreichbar, leider werden auch nach mehren Versuchen (DHCP / Statische IP) keinerlei Einstellungen übernommen und der ESP startet immer wieder als AP :
This is line 5 of void setup(void)
Read settings
Settings are:
Starting wifi
HostName is: LaCrosseGateway
Using DHCP
Trying to connect to an AP
..............................
We got no connection :-(
Starting Access point
Access point running: LaCrosseGateway_10469021
Searching RFMs and BMP
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.05 {IP=192.168.222.1}]
Setup completely done
[LaCrosseITPlusReader.Gateway.1.05 {IP=192.168.222.1}]
Setup completely done
Key:ctSSID Val:sensor
Key:ctPASS Val:xxx_xxx <- PW geändert, aber echtes PW ist mit Underline
Key:staticIP Val:192.168.0.111
Key:staticMask Val:255.255.255.0
Key:staticGW Val:192.168.0.253
Key:HostName Val:LaCrosseGateway
b��d����������������FC�愄������䄥��熤D�Ƅbŧ���E���Ĥb�d
This is line 5 of void setup(void)
Read settings
Settings are:
Starting wifi
HostName is: LaCrosseGateway
Using DHCP
Trying to connect to an AP
..............................
We got no connection :-(
Starting Access point
Access point running: LaCrosseGateway_10469021
Searching RFMs and BMP
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.05 {IP=192.168.222.1}]
Setup completely done
Den RFM12B habe ich bis jetzt noch nicht angeklemmt, wollte warten bis WiFi rund läuft.
@HCS,
ich würde ja zu gerne den normalen Arduino LaCrosse Sketch mal mit der Arduino 1.6.5 IDE auf den ESP flashen, allerdings gibts im ersten Anlauf Fehler beim übersetzen der RFMxx.cpp. Wäre wirklich schön wenn du irgendwann mal deinen Quellcode veröffentlichen würdest, ich denke dann könnte man den ganzen AP und Setup Umweg auch einfach weglassen und alle Parameter "hartcoded" in den Quelltext packen.
Zitat von: Wzut am 21 November 2015, 19:40:54
Ich habe heute versucht die .bin Datei aus dem ersten Post mit dem esptool (Link auch aus dem ersten Post) auf einen ESP8266-12 zu flashen.
Leider ohne Erfolg :(
Ein ESP8266 ESP-12 oder ein ESP8266 ESP-12E oder ein NodeMCU devboard?
Zitat von: Wzut am 21 November 2015, 19:40:54
Einstellungen übernommen und der ESP startet immer wieder als AP :
Das sieht so aus, als ob die Settings nicht im EEPROM gespeichert werden.
Aber keine Ahnung warum das bei Dir nicht geht.
Zitat von: Wzut am 21 November 2015, 19:40:54
ich würde ja zu gerne den normalen Arduino LaCrosse Sketch mal mit der Arduino 1.6.5 IDE auf den ESP flashen, allerdings gibts im ersten Anlauf Fehler beim übersetzen der RFMxx.cpp.
Ja, der läuft nicht auf einem ESP. Nicht alle Libs, die man so hat, funktionieren auf dem ESP. Manche kann man nicht compilieren, und manche machen einfach nicht das, was sie auf einem Arduino machen. Das war ein mühsamer Weg, die so hinzubekommen, dass sie auf Arduino und ESP gehen.
Was hast Du denn vor? Der originale Arduino-Sketch macht recht wenig Sinn auf einem ESP.
Wenn Du irgend ein Projekt vor hast, das einen RFM verwendet, kann ich Dir zumindest mal die RFMxx in einer Version geben, die auch auf dem ESP geht.
Zitat von: Wzut am 21 November 2015, 19:40:54
... ich denke dann könnte man den ganzen AP und Setup Umweg auch einfach weglassen und alle Parameter "hartcoded" in den Quelltext packen.
Das glaube ich nicht. Es wird nicht jeder Anwender gewillt und in der Lage sein, die dafür erforderliche Entwicklungsumgebung aufzubauen und dann eine neue Version zu compilieren und zu flashen, nur weil er das Passwort von seinem wlan mal geändert hat.
Zitat von: HCS am 22 November 2015, 08:28:57
Ein ESP8266 ESP-12 oder ein ESP8266 ESP-12E oder ein NodeMCU devboard?
Ein nackter ESP8266 ESP-12 , ein NodeMCU Devboard V1.0 ist bestellt aber noch nicht da
Zitat von: HCS am 22 November 2015, 08:28:57
Das sieht so aus, als ob die Settings nicht im EEPROM gespeichert werden.
Die Vermutung hatte ich auch :(
Zitat von: HCS am 22 November 2015, 08:28:57
Das war ein mühsamer Weg, die so hinzubekommen, dass sie auf Arduino und ESP gehen.
Das glaube ich dir aufs Wort ! Da ich aber eine "faule Sau" bin lebe ich nach dem alten Motto :
"Gute Programmierer schreiben guten Code, geniale Programmierer
borgen sich guten Code" :)
Zitat von: HCS am 22 November 2015, 08:28:57
Was hast Du denn vor? Der originale Arduino-Sketch macht recht wenig Sinn auf einem ESP.
Wenn Du irgend ein Projekt vor hast, das einen RFM verwendet, kann ich Dir zumindest mal die RFMxx in einer Version geben, die auch auf dem ESP geht.
Ich habe die letzten Wochen einiges mit dem ESP8266 (Arduino IDE) und MQTT gemacht. Daher würde ich gern ein LaCrosse - MQTT Gateway bauen.
D.h. die empfangenen Daten sollen nicht als Telegramm an eine bestimmte fhem Instanz weitergereicht werden sondern decodiert direkt an den MQTT Broker.
Die diversen fhem Instanzen holen sich dann vom Broker genau die Werte die sie benötigen.Auf die Art löse ich z.Z. bestehende fhem2fhem Verbindungen ab.
Zitat von: HCS am 22 November 2015, 08:28:57
Es wird nicht jeder Anwender gewillt und in der Lage sein, die dafür erforderliche Entwicklungsumgebung aufzubauen und dann eine neue Version zu compilieren
Gebe ich dir 100%ig Recht, aber die ersten Beta Versionen müssen ja auch nicht zwingend für jedermann direkt einsetzbar sein.
Zitat von: Wzut am 22 November 2015, 10:16:06
Ein nackter ESP8266 ESP-12
Muss mal in der Bastelkiste suchen, ob ich einen habe und damit probieren.
Das könnte auch erklären, warum die flasherei nicht geklappt hat, die reset-Logik auf dem devboard ist ziemlich special.
Zitat von: Wzut am 22 November 2015, 10:16:06
"Gute Programmierer schreiben guten Code, geniale Programmierer borgen sich guten Code" :)
Mist, ich muss unbedingt irgendwie den Sprung von "gut" zu "genial" schaffen, dann könnte ich jetzt in der Sonne (die nicht scheint) liegen und das 500 KM entfernte Meer anschauen. ;D ;D ;D
Zitat von: Wzut am 22 November 2015, 10:16:06
Ich habe die letzten Wochen einiges mit dem ESP8266 (Arduino IDE) und MQTT gemacht. Daher würde ich gern ein LaCrosse - MQTT Gateway bauen.
D.h. die empfangenen Daten sollen nicht als Telegramm an eine bestimmte fhem Instanz weitergereicht werden sondern decodiert direkt an den MQTT Broker.
Ich will Dir unter keinen Umständen etwas wegnehmen, aber da wäre zu überlegen, ob es wirklich Sinn macht, eine Firmware zu haben, die 95% alles gleich macht, und nur am Ende das dann wo anders hin schickt. Das könnte ja das LGW auch optional beherrschen.
Es muss eigentlich nur bei erfolgreich verarbeiteten Daten das optional noch an den MQTT Broker schicken. Auch dazu wird wie für die FHEM-Anbindung ein wifi connect usw. benötigt.
Aktuell ist es eh schon so ausgelegt, dass man es alternativ am Server per USB verwenden kann, als ob es ein JeeLink wäre (wenn dann die debug-Messages wieder raus sind). Das macht z.B. dann Sinn, wenn das LGW mal Sensoren kann, die der LaCrosse Sketch nicht mehr lernen wird und man warum auch immer kein wifi haben möchte.
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, dann gebe ich Dir die RFMxx und Du kannst basteln.
Gerade gemerkt: brauche ich Dir nicht geben. Im aktuell eingecheckten LaCrosse Sketch (http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosse-LaCrosseITPlusReader.zip) ist die drin, die auch mit den ESP geht. Ist übrigens die Einzige, bei der ich es nicht geschafft habe, dass sie für beide funktioniert, ohne verschiedene Code-Zweige zu haben.
Du musst oben den
//// #define ESP8266
scharf machen, dass sie für ESP kompiliert und funktioniert.
Zitat von: Wzut am 22 November 2015, 10:16:06... aber die ersten Beta Versionen müssen ja auch nicht zwingend für jedermann direkt einsetzbar sein.
Ein Grund für die recht frühe Beta ist, Felderfahrung zu sammeln, um zu sehen, was da draußen so alles ist und passiert (z.B. plaine ESP-12, ...) und dafür, wenn möglich, Lösungen zu finden.
Was ich dabei aber vermeiden will ist, dass Probleme gesucht werden müssen, die es eigentlich nicht gibt, nur weil jemand nicht die exakt passende tool chain aufgebaut hat. Beim LaCrosse Sketch gab es da auch oft Probleme und seit man es einfach mit set myJeeLink flash erledigen kann, ist Ruhe eingekehrt.
Jetzt habe ich einen RFM69CW bekommen (433 MHz) und angeschlossen.
Gateway wird erkannt, IP erfolgreich geändert, Statusseite zeigt
LaCrosseGateway V1.05
Uptime: 2130 Seconds
Connected to: WLAN4Me
MAC address: 18:FE:34:FA:F4:74
Chip ID: 16446580
Gatewaydevice habe ich im FHEM definiert und FHEM sagt dazu auch Status: Initialized
define lcg_Jeelink JeeLink 192.168.0.222:81
attr lcg_Jeelink initCommands 30t v
Leider kann ich aber keines meiner 433MHz Thermostate anlernen (eines ist z.B. ein TFA 30.3125 auf 433 MHz, ein anderes ein Noname).
Die blaue LED leuchtet fast konstant, die rote ca. kurz im Sekundentakt.
Ein List des Gateways bringt
Internals:
CFGFN
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF 192.168.0.222:81
DeviceName 192.168.0.222:81
FD 93
NAME lcg_Jeelink
NR 2744
PARTIAL
STATE Initialized
TYPE JeeLink
model [LaCrosseITPlusReader.Gateway.1.05 + (RFM69 f:868300 r:9579) {IP=192.168.0.222}]
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-22 17:59:39 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 30t v
room LaCrosse
Passt das Internal model zu 433 MHz?
Oder fehlt mir noch anders?
Zitat von: HCS am 22 November 2015, 11:00:38
Ich will Dir unter keinen Umständen etwas wegnehmen
-- snipp --
dann gebe ich Dir die RFMxx und Du kannst basteln.
Ich sehe das nicht als wegnehmen, im Gegenteil ich bin doch auch der Meinung das Rad muss nicht täglich neu erfunden werden :)
Ich habe mir deine ESP8266 taugliche RFMxx lib gezogen und ersteinmal einen mini Sketch damit aufgesetzt,
bis jetzt klappt zumindest schon mal die Erkennung des RFM69CW !
Zitat von: Omega am 22 November 2015, 18:39:20
Jetzt habe ich einen RFM69CW bekommen (433 MHz) und angeschlossen.
Gateway wird erkannt, IP erfolgreich geändert, Statusseite zeigt
LaCrosseGateway V1.05
Uptime: 2130 Seconds
Connected to: WLAN4Me
MAC address: 18:FE:34:FA:F4:74
Chip ID: 16446580
Super, dass das bei Dir funktioniert hat.
Zitat von: Omega am 22 November 2015, 18:39:20
Internals:
...
model [LaCrosseITPlusReader.Gateway.1.05 + (RFM69 f:868300 r:9579) {IP=192.168.0.222}]
...
Passt das Internal model zu 433 MHz?
Also rein LGW technisch sieht das gut aus. Es läuft, und FHEM konnte sich drauf verbinden und hat die Initialisierung bekommen.
Ich habe keine Ahnung, ob der 30.3125 ein Protokoll sendet, das einem der 868 MHz Sensoren, die implementiert sind, entspricht.
f:868300 passt auf alle Fälle nicht.
Habe ein Datenblatt zum 30.3125 gefunden. Da steht drin:
Zitat· Transmission interval : every 5 minutes
· Transmission frequency : 433.92MHz
Dann wären folgende initCommands richtig:
433920f 0r v
alternativ
433920f 1r v
Aber, der sendet lt. diesem Datenblatt nur alle 5 Minuten, da braucht man Geduld, selbst wenn man die Parameter richtig hat.
Und der autocreate wird auch nicht gehen, ohne ihn umzukonfigurieren, weil der erwartet als default, dass der Sensor innerhalb von 120 Sekunden zwei mal empfangen wird.
Zitat von: Wzut am 22 November 2015, 19:09:21
bis jetzt klappt zumindest schon mal die Erkennung des RFM69CW !
Hast Du evtl. etwas anderes erwartet ;D ;D ;D
Vorschlag, entwickle mal mit minimalem drum-rum-Aufwand Deine MQTT Übermittlung, und dann schauen wir, wie wir es in das LGW mit rein bekommen.
Zitat von: Omega am 22 November 2015, 18:39:20(eines ist z.B. ein TFA 30.3125 auf 433 MHz ...
Etwas suchen bringt mich zu folgender Erkenntnis: der sendet OOK, somit wird das nichts.
Dann muss ich mich mal schlau machen, was OOK bedeutet.
Zusätzlich habe ich noch einen 30.3015 - der geht auch nicht.
Wahrscheinlich blöde Frage aber: beim Einrichten meines Jeelinks musste ich nach Anlegen des Devices in FHEM noch einen Befehl zum flashen absetzen. Ist das hier auch noch notwendig oder ist das bereits alles im Code (LaCrosseGateway.bin) enthalten?
Zitat von: Omega am 22 November 2015, 21:08:56a
Dann muss ich mich mal schlau machen, was OOK bedeutet.
Das ist die Art, wie die Daten auf dem HF-Weg übertragen werden. Hilft aber nichts, das kann der Sketch nicht.
Ich sehe ziemlich schwarz für deine 433 MHz Sensoren, das ganze wurde (sowohl der LaCrosse Sketch als auch das LGW) für die 868 MHZ IT+ Schiene entwickelt.
Einen 433 MHz Sensor zu haben, der zufällig dieses Protokoll sendet, nur halt auf 433 ist dann mehr als Glück.
Siehe hier: http://www.fhemwiki.de/wiki/JeeLink#Getestete_iT.2B_Sensoren_incl._Wetterstation_WS_1600
Zitat von: Omega am 22 November 2015, 21:08:56a
Wahrscheinlich blöde Frage aber: beim Einrichten meines Jeelinks musste ich nach Anlegen des Devices in FHEM noch einen Befehl zum flashen absetzen. Ist das hier auch noch notwendig oder ist das bereits alles im Code (LaCrosseGateway.bin) enthalten?
wenn die LaCrosseGateway.bin geflasht ist, ist alles prima.
Da habe ich mich wohl zu früh gefreut, als ich dachte, meine alten Sensoren noch günstig einbinden zu können.
Trotzdem danke für die Unterstützung.
Holger
Heb den 433 MHz RFM gut auf (vielleicht kommt ja mal eines Tages was im LGW, das ihn verwenden kann), besorg Dir einen 868er und Sensoren, die als funktionierend deklariert wurden und dann klappt es.
Ganz generell nochmal,
dieser Absatz in der Beschreibung in Beitrag #1 ganz oben hat schon seine Berechtigung.
Wer mit anderer Hardware, Frequenz, Sensoren, die nicht aufgeführt sind oder sonst wie etwas plant, sollte zu Sicherheit erst mal nachfragen, wie die Chancen sind, dass es gehen könnte. Das vermeidet ggf. unnötigen Frust.
Zitat von: HCS am 07 November 2015, 14:39:36
Unterstützte Sensoren:
Alle Sensoren, die auch vom "LaCrosse Arduino" Sketch unterstützt werden, incl. WS 1600 und WS 1080
siehe http://www.fhemwiki.de/wiki/JeeLink#LaCrosse_Sketch
Zitat von: HCS am 22 November 2015, 20:09:55
Hast Du evtl. etwas anderes erwartet ;D ;D ;D
*Hust* .... frag lieber nicht oder willst du belogen werden ?
Ich habe deinen LaCrosse Sketch auf den ESP gehauen, leider hängt der Watchdog dann schon beim Init in einer Resetschleife fest, daher werde ich jetzt langsam Stück für Stück das Ganze aufbauen und sehen ab wann es wo klemmt.
Was mir aber noch aufgefallen ist : Nach deiner Zeichnung ist ja der Interrupt Ausgang des RFM gar nicht mehr verbunden, kommst du nun ganz ohne Interrupt Verarbeitung aus ?
Zitat von: Wzut am 23 November 2015, 14:32:54
Ich habe deinen LaCrosse Sketch auf den ESP gehauen, leider hängt der Watchdog dann schon beim Init in einer Resetschleife fest, daher werde ich jetzt langsam Stück für Stück das Ganze aufbauen und sehen ab wann es wo klemmt.
Wie ich schon geschrieben hatte, der LaCrosse Sketch läuft nicht grad mal so auf dem ESP. So kompatibel ist die API dann doch nicht.
Darfst aber gerne die Nummer, bis das geht, auch mal durchmachen ... :D :D :D
Zitat von: Wzut am 23 November 2015, 14:32:54
Was mir aber noch aufgefallen ist : Nach deiner Zeichnung ist ja der Interrupt Ausgang des RFM gar nicht mehr verbunden, kommst du nun ganz ohne Interrupt Verarbeitung aus ?
Ja, das war im LaCrosse Sketch schon so und ist beim LGW auch so. Das funktioniert ohne Interrupts.
Hallo HCS,
ich habe mir testhalber auch mal ein LGW zusammen gestöpselt. NodeMCU Dev. Amica und RFM69H gerade aus CN bekommen.
Was soll ich sagen, Software v1.05 drauf, Setup auf feste IP und es läuft. :)
Vorhandene JeeLink vom Raspi-2 entfernt, DEV in IP:81 geändert und in FHEM läuft alles wie vorher (TX29).
Was du vieleicht noch in den ersten Post schreiben solltest, den Datenport 81 nicht versuchen im Browser (FireFox) zu öffnen, das hat mir zweimal die Settings zerschossen. :(
Gruß Friedrich
Zitat von: Omega-5 am 23 November 2015, 16:36:50
ich habe mir testhalber auch mal ein LGW zusammen gestöpselt. NodeMCU Dev. Amica und RFM69H gerade aus CN bekommen.
Was soll ich sagen, Software v1.05 drauf, Setup auf feste IP und es läuft. :)
Vorhandene JeeLink vom Raspi-2 entfernt, DEV in IP:81 geändert und in FHEM läuft alles wie vorher (TX29).
Das freut mich. Danke für die Rückmeldung.
Mit welchem Tool hast Du geflasht?
Zitat von: Omega-5 am 23 November 2015, 16:36:50
Was du vieleicht noch in den ersten Post schreiben solltest, den Datenport 81 nicht versuchen im Browser (FireFox) zu öffnen, das hat mir zweimal die Settings zerschossen. :(
Ohh. OK muss ich mal ausprobieren, da bin ich noch garnicht drauf gekommen, das man das machen würde...
Ich habe es in Beitrag #1 reingeschrieben und werde aber mal schauen, warum das passiert und versuchen, es zu verhindern.
Zitat von: HCS am 23 November 2015, 17:07:33
Mit welchem Tool hast Du geflasht?
Unter Windows 7 mit ESP8266Flasher.exe (Win64).
https://github.com/nodemcu/nodemcu-flasher (https://github.com/nodemcu/nodemcu-flasher)
Gruß Friedrich
PS: 5 mal editiert Link klappte nicht.
Zitat von: HCS am 23 November 2015, 15:45:44
Darfst aber gerne die Nummer, bis das geht, auch mal durchmachen ... :D :D :D
Ach was bist du heute wieder so gut zu mir .... wie die Mutter ohne Brust :P
by the way , gerade aus dem Seriellen Monitor meiner mini Version geholt :
End receiving, HEX raw data: 9F C6 10 6A CB AA AA 0 0 7F FF FF FF FF FF FF
OK 9 63 1 4 186 106
Version 1.06
Hier: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/firmware/LaCrosseGateway.bin
Ab morgen nach einem FHEM-Update auch lokal in <FHEM-Installations-Verzeichnis>/FHEM/firmware/JeeLink_LaCrosseGateway.bin
Neuerungen:
Port 81
Wenn man den Port 81 im Browser öffnet, wurden die gespeicherten Settings zerschossen. Ist nun verhindert.
Optische Darstellung der Initialisierung
Beim Start und der Initialisierung wird nun mit der Board-eigenen LED signalisieren, was gerade passiert
- 5 schnelle blinks direkt nach dem Start, als Zeichen, dass ein Reset stattgefunden hat
- Blinken im Sekundentakt, während versucht wird, sich mit einem wlan zu verbinden.
- Dauerleuchten, wenn kein Connect zu einem wlan möglich war und der AccessPoint geöffnet wurde.
- LED aus, wenn der Connect zu einem wlan geklappt hat und dann vereinzeltes Blinken, wenn Daten an FHEM übermittelt werden
FramesPerMinute
Es gibt einen neuen Statuswert "FramesPerMinute". Dieser gibt an, wie viele frames von Sensoren in der letzten Minute erfolgreich empfangen, dekodiert und verarbeitet wurden.
An ihn kann man eine Überwachung dranhängen, die alarm schlägt, wenn weniger als ein Grenzwert empfangen wird, dann ist nämlich was faul.
Ein Beispiel, wie dieser Wert einen Tag lang geloggt aussieht, habe ich angehängt.
Danke AxelSchweiss, für diese geniale Idee.
ReceivedFrames gibt an, wie viele seit dem Start des LGW empfangen wurden.
Statuswerte abrufen:
Mit <IP-des-LGW>/state können die Statuswerte, die das LGW-Frontent anzeigt, als XML zur Weiterverarbeitung abgerufen werden.
Beispiel, was man zurückbekommt:
<LGW>
<Info Key="UpTimeSeconds" Value="107086"/>
<Info Key="UpTimeText" Value="1Tg. 5Std. 44Min. 46Sek. "/>
<Info Key="WIFI" Value="NeverTellThem"/>
<Info Key="MacAddress" Value="18:FE:34:9A:6D:48"/>
<Info Key="ChipID" Value="10120520"/>
<Info Key="ReceivedFrames" Value="93593"/>
<Info Key="FramesPerMinute" Value="52"/>
</LGW>
LGW-WebFrontend:
Hat eine Navigation bekommen
Die Setup-page hat neue Eigenschaften bekommen
Statuswerte als KeyValueProtocol
Entsprechend der vorgenommenen Konfiguration auf der Setup-page sendet das LGW (default alle 10 Sekunden) seine Statuswerte an FHEM.
Dort werden sie von dem neuen Modul "KeyValueProtocol" als readings angezeigt. Sobald das LGW das erste Mal (also ab V1.06) Statuswerte schickt, wird bei aktivem AutoCreate automatisch das device angelegt. Siehe angehängtes KVP.png (Nachtrag: das doppelte UpTime reading bitte übersehen, ist noch eine Altlast)
OTA-Firmware-Update
Wem der Begriff fremd ist: OTA steht für "Over-The-Air" und ermöglicht es, die Firmware des LGW über das wlan zu aktualisieren, anstatt es per USB zu flashen.
Das ist noch fühes Stadium, aber wenn man es nicht rausgibt, treten auch keine Fehler auf :)
Um ein OTA-Update zu ermöglichen, benötigt man einen WebServer, der die Firmware (JeeLink_LaCrosseGateway.bin) bereitstellt. Das kann jeder beliebige WebServer sein, auf den man die .bin legen kann.
Was sich anbietet: FHEM dafür verwenden. In FHEM kann man HTTP-Server definieren.
Beispiel:
define firmware HTTPSRV firmware FHEM/firmware firmware
Ob die Firmware korrekt bereit gestellt wird, kann man einfach im Browser testen.
Mit http://<IP des FHEM-Servers>:8083/fhem/firmware/JeeLink_LaCrosseGateway.bin muss man einen Download angeboten bekommen.
Auf der Setup-Page des LGW konfiguriert man dann im Abschnitt "OTA update" diesen Server.
OTA-Server: <IP des FHEM-Servers>
OTA-Port: 8083
OTA-url: /fhem/firmware/JeeLink_LaCrosseGateway.bin
"Save and restart" nicht vergessen.
Danach kann man dann auf der Seite "OTA-Update" des LGW zukünftig das Update ausführen.
Falls das OTA-Update fehlschlägt und die Firmware auf dem LGW zerschossen hat, kann man das LGW dadurch retten, dass man es wie bisher per USB flasht.
Sorry, viel getan, also muss man auch viel beschreiben ;)
Wow,
da hat sich ja wieder eine ganze Menge getan. RESPEKT!!!!
Werde die neue Firmware dann mal probieren.
Mittlerweile ist mein RFM-MODUL auch angekommen, muss es nur noch verkabeln und anschliessen.
Danke für die tolle Entwicklung und Gruß
Olly
Zitat von: Olly am 28 November 2015, 10:40:00
Werde die neue Firmware dann mal probieren.
Ja, unbedingt, ich will ja wissen, ob es funktioniert ;D
@All: Tip der Woche: nach dem Speichern der Settings oder einem OTA-Update nicht den Browser mit F5 aktualisieren, sonst läuft es gleich nochmal ab, sondern mit "Zurück" wieder auf die vorhergehende Seite gehen.
Mein Devkit 1.0 ist inzwischen da, habe nun damit auch deine neue Version getestet, allerdings wieder mit dem Fehler das die Einstellungen nicht gespeichert werden und das ding immer als AP läuft. Hier die Ausgabe auf der Konsole :
OK VALUES LGW 455198 UpTimeSeconds=207,UpTimeText=0Tg. 0Std. 3Min. 27Sek. ,WIFI=---,MacAddress=5C:CF:7F:06:F2:1E,ChipID=455198,ReceivedFrames=0,FramesPerMinute=0
OK VALUES LGW 455198 UpTimeSeconds=217,UpTimeText=0Tg. 0Std. 3Min. 37Sek. ,WIFI=---,MacAddress=5C:CF:7F:06:F2:1E,ChipID=455198,ReceivedFrames=0,FramesPerMinute=0
OK VALUES LGW 455198 UpTimeSeconds=227,UpTimeText=0Tg. 0Std. 3Min. 47Sek. ,WIFI=---,MacAddress=5C:CF:7F:06:F2:1E,ChipID=455198,ReceivedFrames=0,FramesPerMinute=0
OK VALUES LGW 455198 UpTimeSeconds=237,UpTimeText=0Tg. 0Std. 3Min. 57Sek. ,WIFI=---,MacAddress=5C:CF:7F:06:F2:1E,ChipID=455198,ReceivedFrames=0,FramesPerMinute=0
OK VALUES LGW 455198 UpTimeSeconds=247,UpTimeText=0Tg. 0Std. 4Min. 7Sek. ,WIFI=---,MacAddress=5C:CF:7F:06:F2:1E,ChipID=455198,ReceivedFrames=0,FramesPerMinute=0
Key:ctSSID Val:xxx
Key:ctPASS Val:xxx_xxx
Key:staticIP Val:192.168.0.111
Key:staticMask Val:255.255.255.0
Key:staticGW Val:192.168.0.253
Key:HostName Val:LaCrosseGateway
Key:KVInterval Val:10
Key:otaServer Val:
Key:otaPort Val:
Key:otaURL Val:
!
J�J!!�H��
1�8��ֈK�S��kH
ʄ ̇ֈ��!�n:�!H�:��
This is line 5 of void setup(void)
LaCrosseITPlusReader.Gateway V1.06
Read settings
Settings are:
Starting wifi
HostName is: LaCrosseGateway
Using DHCP
Trying to connect to an AP
..............................
We got no connection :-(
Starting Access point
Access point running: LaCrosseGateway_455198
Searching RFMs and BMP
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.06 {IP=192.168.222.1}]
Setup completely done
OK VALUES LGW 455198 UpTimeSeconds=17,UpTimeText=0Tg. 0Std. 0Min. 17Sek. ,WIFI=---,MacAddress=5C:CF:7F:06:F2:1E,ChipID=455198,ReceivedFrames=0,FramesPerMinute=0
OK VALUES LGW 455198 UpTimeSeconds=27,UpTimeText=0Tg. 0Std. 0Min. 27Sek. ,WIFI=---,MacAddress=5C:CF:7F:06:F2:1E,ChipID=455198,ReceivedFrames=0,FramesPerMinute=0
OK VALUES LGW 455198 UpTimeSeconds=37,UpTimeText=0Tg. 0Std. 0Min. 37Sek. ,WIFI=---,MacAddress=5C:CF:7F:06:F2:1E,ChipID=455198,ReceivedFrames=0,FramesPerMinute=0
OK VALUES LGW 455198 UpTimeSeconds=47,UpTimeText=0Tg. 0Std. 0Min. 47Sek. ,WIFI=---,MacAddress=5C:CF:7F:06:F2:1E,ChipID=455198,ReceivedFram
Zitat von: Wzut am 29 November 2015, 19:14:56
Mein Devkit 1.0 ist inzwischen da, habe nun damit auch deine neue Version getestet, allerdings wieder mit dem Fehler das die Einstellungen nicht gespeichert werden und das ding immer als AP läuft.
Gibts doch nicht. Hast Du etwas Besonderes in SSID oder Passwort drin?
Versuch mal test / test, kann zwar dann nicht verbinden, aber um zu sehen, ob die Settings gespeichert werden.
Hallo,
ich habe jetzt auch meine nodemcu mit dem RFM69 verheiratet und die 1.06er Firmware installiert.
Die vorher eingestellte Werte wurden übernommen und die Verbindung mit dem WLAN klappt. RFM69 wird erkannt.
Auf der seriellen Konsole tauchen dann fast im Sekundentakt Zeilen mit OK und Zahlen auf.
Jeelink habe ich dann in FHEM definiert, wird auch richtig erkannt.
TOLL!!!!
Aber wie mache ich jetzt weiter?
Hab ein
set myLeeLink LaCrossePairForSec 120 ignore_battery
abgesetzt, aber es werden keine Devices angelegt (autocreate ist an). Was fehlt mir noch??
Gruß
Olly
Zitat von: HCS am 29 November 2015, 19:33:55
Hast Du etwas Besonderes in SSID oder Passwort drin?
Versuch mal test / test
Auch das habe ich breits erfolglos in den beiden Spielarten DHCP und Fixe IP hinter mir.
Inzwischen ist auch der RFM69 angeschlossen und wird erkannt, einziger Unterschied ist das nun die LaCrosse "OK 9" Meldungen zusätzlich noch im seriellen log erscheinen.
Da aber wohl nur ich mit diesem Problem kämpfe sollte ich den Hebel vllt. an der Stelle ansetzen wo mein Handeln von dem der anderen User abweicht und da fällt mir spontan nur der Flashvorgang als solcher ein. Ich werde heute Abend mal schauen welche anderen Programme ich jetzt mit den Devkit unter Linux noch benutzen kann.
Vorbereitung zum flashen beim Devkit ist doch Flash Taste drücken und halten und dann einmal kurz Reset ?
Hallo,
@Wzut: Ich verwende unter Windows den NodeMCU Flasher (github.com/nodemcu/nodemcu-flasher). Da stelle ich einfach den richtigen COM-Port ein, wähle die. bin-Datei aus und klicke auf Flash. Die Buttons auf der NodeMCU brauche ich gar nicht zu drücken, das geht so.
Gruß
Olly
Hier ist meine Feststellungen in Bezug auf ein Update von 1.05 auf 1.06.
Unter Windows 7 mit ESP8266Flasher.exe (Win64) Version 1.06 geflasht, dazu musste auch kurz die Flashtaste gedrückt werden.
Danach Putty über die COMx mit 57600baud gestartet. Dabei kamen zuerst einige unlesbare Zeichen, dann aber
This is line 5 of void setup(void)
LaCrosseITPlusReader.Gateway V1.06
Read settings
usw.
mit den alten Daten, 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 noch kein OTA Update probiert. Kommt beim nächsten mal.
Gruß Friedrich
Zitat von: Olly am 29 November 2015, 22:37:56
... 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?
Zitat von: Omega-5 am 30 November 2015, 14:22:09
... 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 ...
Zitat von: HCS am 30 November 2015, 16:56:08
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)
Zitat von: Wzut am 30 November 2015, 18:52:48Ich melde inzwischen mal Erfolg :)
Bin ich was froh ...
Zitat von: Wzut am 30 November 2015, 18:52:48
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)
python ota.py 192.168.31.211 LaCrosseGateway.binIch 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.
Zitat von: Wzut am 30 November 2015, 18:52:48
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
set myJeeLink LaCrossePairForSec 120 ignore_batterywurden 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?
So, Hallo,
hier dann mal mein list JeeLink:
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
Grad noch was im Logfile gesehen:
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
Zitat von: Olly am 30 November 2015, 21:20:15
RAWMSG OK 9 8 1 4 57 106
myJeeLink_MSGCNT 1611
Das ist ein Temperatursensor, der 8,1 °C sendet.
Sieht alles gut aus.
Zitat von: Olly am 30 November 2015, 21:28:25
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 ;D
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?
Zitat von: Olly am 30 November 2015, 21:20:15
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?
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
Zitat von: HCS am 30 November 2015, 21:02:22
Mit 57600 Baud ist halt krass langsam.
Was bisher gut funktioniert ist OTA.
--snipp ---
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 :)
Zitat von: HCS am 22 November 2015, 11:00:38
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.
Zitat von: Wzut am 01 Dezember 2015, 11:15:13
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.
Zitat von: Wzut am 01 Dezember 2015, 11:15:13
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.
Zitat von: Wzut am 01 Dezember 2015, 11:15:13
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.
Zitat von: Wzut am 01 Dezember 2015, 11:15:13
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.
Zitat von: Wzut am 01 Dezember 2015, 11:15:13c. 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.
Zitat von: HCS am 01 Dezember 2015, 15:18:30
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 :)
Zitat von: Wzut am 01 Dezember 2015, 16:07:54
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.
Zitat von: Wzut am 01 Dezember 2015, 16:07:54GPIOs : 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 ;D) Bus anspricht.
Zitat von: Wzut am 01 Dezember 2015, 16:07:54Mach 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.
Zitat von: HCS am 01 Dezember 2015, 16:55:01
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.
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
Zitat von: kohlenmacher am 02 Dezember 2015, 10:17:58
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
Zitat von: kohlenmacher am 02 Dezember 2015, 10:17:58Mir ist aufgefallen, dass wenn ich den Resettaster am NodeMCU betätige er keine WLAN Verbindung mehr bekommt. Ziehe ich den USB-Stecker funktioniert es.
Genau das kann ich nicht bestätigen, aber eine ähnliches Problem: wenn ich aus der IDE per USB flashe (was ich eigentlich nie mache, weil OTA), dann bekomme ich auch manchmal keinen wifi-connect. Spannugsversorgung trennen und wieder verbinden, dann geht es. Per OTA geht es immer (beim Entwicklen garantiert schon einige hundert mal gemacht).
Muss mal den Reset-Taster drücken, was dann passiert, das habe ich, glaube ich, noch nie getan :). Aber der ist gerade weit weg...
Zitat von: Olly am 02 Dezember 2015, 10:41:06
Nö, das funktioniert bei mir auch wenn man einen Reset macht. Kommt denn dann was außergewöhnliches auf der seriellen Konsole?
Das ist exakt die entscheidende Frage. Kannst mal bitte das Log anhängen?
Nachtrag: damit meinte ich natürlich kohlenmacher
Zitat von: Olly am 02 Dezember 2015, 10:41:06
Nö, das funktioniert bei mir auch wenn man einen Reset macht. Kommt denn dann was außergewöhnliches auf der seriellen Konsole?
Nicht das mir was aufgefallen wäre. Beim Connect-Versuch kommen mehrere Punkte und anschließend die Meldung das kein Connect möglich ist.
Nach dem "USB-Reset" geht der Connect sehr schnell.
Zitat von: HCS am 02 Dezember 2015, 11:05:49
Das ist exakt die entscheidende Frage. Kannst mal bitte das Log anhängen?
Nachtrag: damit meinte ich natürlich kohlenmacher
Ich mache heute abend von beiden Fällen mal ein Log.
Gruß
Kohlenmacher
Heute kam mein DevKit ... ;D
Angeschlossen ... kurz mit AT getestet ob es funkioniert ... brav Danke bei Ali gemacht ... und los.
Geflasht habe ich mit dem nodeMCU-Flasher nach Anleitung auf Seite 1 vom Thread ... danach nur den RESET-Button gedrückt.
Und ... Oh Wunder ... ein AccessPoint ... allerdings nicht der der auf der Console steht.
Verbunden ... mein Wlan konfiguriert ..... nix ... :'(
Passwort falsch ... hmmm ... PEBSAC ... korrigiert .... LÄUFT
Allerdings noch ohne RFM-Modul das kommt am WE.
Aber das erste Zittern der Hände ist schon mal weg 8)
Serielle Ausgabe nach dem Einschalten:
Read settings
Settings are:
Key:ctSSID Val:meineSSID
Key:ctPASS Val:meinWLANPasswort
Key:staticIP Val:192.168.1.223
Key:staticMask Val:255.255.255.0
Key:staticGW Val:192.168.1.1
Key:HostName Val:LaCrosseGateway
Key:KVInterval Val:10
Starting wifi
HostName is: LaCrosseGateway
Using static IP
IP: 192.168.1.223
Mask: 255.255.255.0
Gateway: 192.168.1.1
Trying to connect to an AP
...
connected :-)
SSID: nomansland
IP: 192.168.1.223
OTA running on port 8266
Searching RFMs and BMP
First RFM found: RFM12
BMP 180 found
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.06 (RFM12 f:868300 r:17241) + BMP180 {IP=192.168.1.223}]
Setup completely done
OK 9 48 130 4 184 125
OK 9 16 1 4 188 54
OK 9 17 130 4 251 125
OK 9 48 1 4 183 106
OK WS 0 2 4 182 255 255 255 255 255 255 255 255 255 0 3 221
Die Ersten Zeilen fehlen, weil ich das Terminalprogramm neu starten muss.
und nach drücken des Resettasters
¦X¦@IeI¦¦E?¦CQ@¦]_[¦¦N¦T?¦a\¦eH¦`H¦¦c¦hJ¦¦¦¦%
S?TY¦¦¦¦¦.¦a\¦¦^¦¦
This is line 5 of void setup(void)
LaCrosseITPlusReader.Gateway V1.06
Read settings
Settings are:
Key:ctSSID Val:meineSSID
Key:ctPASS Val:meinWLANPasswort
Key:staticIP Val:192.168.1.223
Key:staticMask Val:255.255.255.0
Key:staticGW Val:192.168.1.1
Key:HostName Val:LaCrosseGateway
Key:KVInterval Val:10
Starting wifi
HostName is: LaCrosseGateway
Using static IP
IP: 192.168.1.223
Mask: 255.255.255.0
Gateway: 192.168.1.1
Trying to connect to an AP
..............................
We got no connection :-(
Starting Access point
Access point running: LaCrosseGateway_16400273
Searching RFMs and BMP
First RFM found: RFM12
BMP 180 found
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.06 (RFM12 f:868300 r:17241) + BMP180 {IP=192.168.222.1}]
Setup completely done
OK WS 0 2 4 181 255 255 255 255 255 255 255 255 255 0 3 221
OK VALUES LGW 16400273 UpTimeSeconds=17,UpTimeText=0Tg. 0Std. 0Min. 17Sek. ,WIFI=nomansland,MacAddress=18:FE:34:FA:3F:91,ChipID=16400273,ReceivedFrames=0,FramesPerMinute=0
OK 9 48 130 4 184 125
OK 9 24 1 4 198 51
OK 9 48 1 4 183 106
OK 9 16 1 4 188 54
OK 9 17 130 4 251 125
OK WS 0 2 4 181 255 255 255 255 255 255 255 255 255 0 3 221
SSID und Kennwort habe ich hier geändert, im Orginallog ist es korrekt.
Gruß
Kohlenmacher
Zitat von: AxelSchweiss am 02 Dezember 2015, 22:16:02Aber das erste Zittern der Hände ist schon mal weg
Wenn es bei Dir geht, dann lässt mein Zittern hoffentlich auch nach :)
Ave Wzut: Ich habe hier gerade ein LGW ans laufen bekommen, an dem drei RFMs dran sind, zwei 69er und ein 12er. Ein BMP180 auch.
Und es versorgt zwei FHEMs mit Daten. Das scheint so hinzuhauen, wie ich es mir vorstelle 8)
Die bis zu drei Portnummern für die FHEMs werden gerade auf der SetupPage konfigurierbar.
Das triple-LGW bringt aktuell mit meinem Sensorzoo einen Datendurchsatz von ca. 100 Frames/Minute, mit einem zweier-LGW (einer 8k für die WS und einer toggle für 9k und 17k) waren es zwischen 40 und 60 Frames/Minute pendelnd.
@kohlemacher: sieht in beiden Fällen korrekt aus. Ich werde es mal untersuchen. Musste jetzt aber erst unbedingt ausprobieren, ob das "triple-RFM-multi-FHEM-LGW läuft" ;D ;D
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:CustomSensorExample:KeyValueProtocol
DEF 192.168.31.211:81
DeviceName 192.168.31.211:81
FD 10
NAME myJeeLink
NR 12
PARTIAL
RAWMSG OK 9 38 1 4 60 81
STATE Initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.Gateway.1.07 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + (3=RFM12 f:868300 r:8842) + BMP180 {IP=192.168.31.211}]
myJeeLink_MSGCNT 201413
myJeeLink_TIME 2015-12-02 22:16:56
CHANGETIME:
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-12-02 22:05:08 state opened
Attributes:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:CustomSensorExample:KeyValueProtocol
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:CustomSensorExample" => "^OK\\sCC\\s" , "8:KeyValueProtocol" => "^OK\\sVALUES\\s" }
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
group JeeLink
room System
timeout 60,10
Zitat von: HCS am 02 Dezember 2015, 22:43:11
Ave Wzut: Ich habe hier gerade ein LGW ans laufen bekommen, an dem drei RFMs dran sind, zwei 69er und ein 12er. Ein BMP180 auch.
Und es versorgt zwei FHEMs mit Daten. Das scheint so hinzuhauen, wie ich es mir vorstelle 8)
:) :) :) und ich habe meine I2C Temp und Temp/Hum Sensoren in der Bastelkiste gefunden.
Am WE werde ich mal versuchen die in deine InternalSensors lib zu packen.
Zitat von: Wzut am 03 Dezember 2015, 07:43:09
:) :) :) und ich habe meine I2C Temp und Temp/Hum Sensoren in der Bastelkiste gefunden.
Am WE werde ich mal versuchen die in deine InternalSensors lib zu packen.
Am besten fände ich, wenn in Deiner Kiste ein BME280 drin wäre. Den könnte man alternativ zum BMP180 bestücken und hätte dann Temperature, Luftfeuchtigkeit und Luftdruck.
In InternalSensors ist es genau an der richtigen Stelle, die kann ich dann einfach übernehmen.
Zitat von: HCS am 03 Dezember 2015, 09:12:02
Am besten fände ich, wenn in Deiner Kiste ein BME280 drin wäre. Den könnte man alternativ zum BMP180 bestücken und hätte dann Temperature, Luftfeuchtigkeit und Luftdruck.
http://forum.fhem.de/index.php/topic,41388.0.html :)
Gruß PeMue
n.P. wenn mir PeMue einen seiner Prototypen verkauft, ansonsten habe ich erst einmal den LM75 da.
Zitat von: Wzut am 03 Dezember 2015, 13:29:59n.P. wenn mir PeMue einen seiner Prototypen verkauft, ...
Ich fände es besser, wenn er mir einen
schenkt ;D ;)
Ja, mach mal LM75 (nach dem muss ich auch mal in der Bastel-Kiste buddeln), dann mache ich den BME280 dazu.
Aber ich habe gerade gelernt, dass PeMue Platinen layouten kann, evtl. brauchen wir das ja auch mal noch irgend wann, um den ganzen 2mm Kram direkt auf eine Platine zu bekommen.
Zitat von: HCS am 03 Dezember 2015, 13:42:22
Ich fände es besser, wenn er mir einen schenkt ;D ;)
Aber ich habe gerade gelernt, dass PeMue Platinen layouten kann, evtl. brauchen wir das ja auch mal noch irgend wann, um den ganzen 2mm Kram direkt auf eine Platine zu bekommen.
Tja, wie nennt man das, Interessenskonflikt? ;D
Gruß Peter
Zitat von: PeMue am 03 Dezember 2015, 14:05:42
Tja, wie nennt man das, Interessenskonflikt? ;D
OK. Der Deal wäre: Du machst ein Layout und ich verwende meinen eigenen BME280 ;D ;D
Aber ohne Scherze, ich will dich da zu nichts drängen, das braucht eh noch Zeit, bis wirklich sicher ist, was drauf müsste, könnte, sollte ....
Aber falls sich jemand berufen fühlt, kann er ja schon mal einen Schritt vortreten.
Hi
Isch hätte da mal ein Problem ... genauer eine Bitte
Lässt sich die Stärke des WLAN-Signal in die Statusseite aufnehmen ?
Warum?
Ich hatte das Gateway an einem Ort aufgestellt bei dem die Signalstärke sehr grenzwertig war. Ohne es zu wissen.
Als Ergebniss hatte ich zahlreiche Disconnects immer wenn das Signal etwas mau wurde. Ich dachte schon das GW wäre abgestürzt.
Da fällt mir ein ... macht das GW einen Reconnect wenn es den AP verloren hat ?
Ansonsten läuft das GW (noch ohne Funk) stabil.
Zitat von: AxelSchweiss am 03 Dezember 2015, 18:01:38
Lässt sich die Stärke des WLAN-Signal in die Statusseite aufnehmen ?
Gerade für die 1.07 erledig
ZitatInternals:
LASTInputDev myJeeLink
MSGCNT 8869
NAME KeyValueProtocol_LGW_02
model LGW
Readings:
2015-12-03 21:28:58 ChipID 15936302
2015-12-03 21:28:58 FramesPerMinute 76
2015-12-03 21:28:58 MacAddress 18:FE:34:F3:2B:2E
2015-12-03 21:28:58 RSSI -36
2015-12-03 21:28:58 ReceivedFrames 2956
2015-12-03 21:28:58 UpTimeSeconds 2086
2015-12-03 21:28:58 UpTimeText 0Tg. 0Std. 34Min. 46Sek.
2015-12-03 21:28:58 WIFI wieeeeefiiiiiii
Zitat von: AxelSchweiss am 03 Dezember 2015, 18:01:38Da fällt mir ein ... macht das GW einen Reconnect wenn es den AP verloren hat ?
Ja. Das sollte aktuell schon so sein. Ich kann den AP abschalten und wenn er wieder läuft, hat das LGW auch wieder die Verbindung.
Und wenn man im JeeLink device in FHEM das timeout Attribut gesetzt hat (z.B. auf 120,30) dann baut auch FHEM nach ca. zwei Minuten die Verbindung zum LGW wieder auf.
Oder mal so gesagt: man kann alles, was im Spiel ist, aus und wieder einschalten und kurz drauf sollten wieder Daten kommen.
Zitat von: HCS am 03 Dezember 2015, 21:32:29
Gerade für die 1.07 erledigt
Schick ... Danke dafür
Zitat von: HCS am 03 Dezember 2015, 14:11:03
OK. Der Deal wäre: Du machst ein Layout und ich verwende meinen eigenen BME280 ;D ;D
Aber ohne Scherze, ich will dich da zu nichts drängen, das braucht eh noch Zeit, bis wirklich sicher ist, was drauf müsste, könnte, sollte ....
Schaltplan aus dem ersten Thread? Leiterplattengröße? Wenn klar ist, was drauf soll und wie die Leiterplattengröße ist, warum nicht? So wie es aussieht, besteht sogar bei meinen Layouts die minimale Chance, dass sie funktionieren (http://forum.fhem.de/index.php/topic,38561.msg368669.html#msg368669) 8) 8) 8)
Edit: Nach dem Bibliotheks-"Desaster" (http://forum.fhem.de/index.php/topic,38561.msg373517.html#msg373517) korrigiere ich die Größe der Chance, dass die Leiterplatte funktioniert auf ein "muckeseckele" ...
Hab es nun (nach mehreren Anläufen) geschafft, von der 1.01 auf die 1.06 zu aktualisieren.
Da ich unter Windows (VM) aktualisiere, hat es erst geklappt, als ich die Baudrate auf 57600 gestellt habe.
Evtl kann das ja jemand bestätigen ;)
Ich habe das ganz stumpf ... quasi im idiot-mode ... nach der Anleitung aus dem 1. Beitrag gemacht
Zitat
Alternative für Windows: https://github.com/nodemcu/nodemcu-flasher
Einstellungen (Advanced Tab): 921600 Baud, 4MByte Flash size, 80 MHz Flash speed, SPI Mode: DIO
Auf dem Tab "Config" das LaCrosseGateway.bin auswählen, Ziel-Adresse 0x00000
hat ohne Probleme auf Anhieb funktioniert. Auch mit dieser komischen BaudRate.
Ich musste auch nichts stromlos machen ... Reset hat ausgereicht.
Zitat von: oli82 am 04 Dezember 2015, 13:37:52
Da ich unter Windows (VM) aktualisiere, hat es erst geklappt, als ich die Baudrate auf 57600 gestellt habe.
Evtl kann das ja jemand bestätigen ;)
Das kann man nicht pauschal bestätigen. Wzut hatte auch Probleme mit hohen baud raten und mit 57600 hat es geklappt.
Ich bekomme das problemlos mit 921600 baud durch, andere auch.
Die hohen baud raten müssen von der Hardware (oder virtualisierten Hardware) halt unterstützt werden und bei VmWare kann ich mir schon vorstellen, dass das dann nicht klappt.
Ich werde mal im ersten Beitrag oben drauf hinweisen, dass es die Nächsten einfacher haben. Nachtrag: getan.
Hallo HCS,
da ab 1.06 ja OTA funktioniert, wollte ich das jetzt alles platzsparend an einen ESP8266 12E löten, musste aber feststellen, dass es da GPIO6/7/8 und 1 nicht gibt. Wenn ich mir die Firmware selbst kompiliere und andere GPIOs nehme, würde das klappen? Ausreichend GPIOs hat der ja (0,2,4,5,9,10,12,13,14,15,16). Eine alternative Firmware für den 12e willst du nicht schnell mal machen ;-).
Ich würde übrigens den Vorschlag unterstützen, dass man noch einen DHT11/22 dranhängen kann. Dann kann man das ganze auch noch als zusätzlichen Innenraumsensor mit Druck, Temperatur und Feuchtigkeit nehmen.
Zitat von: BlackFlag am 04 Dezember 2015, 21:03:28
Hallo HCS,
da ab 1.06 ja OTA funktioniert, wollte ich das jetzt alles platzsparend an einen ESP8266 12E löten, musste aber feststellen, dass es da GPIO6/7/8 und 1 nicht gibt. Wenn ich mir die Firmware selbst kompiliere und andere GPIOs nehme, würde das klappen? Ausreichend GPIOs hat der ja (0,2,4,5,9,10,12,13,14,15,16). Eine alternative Firmware für den 12e willst du nicht schnell mal machen ;-).
Ich würde übrigens den Vorschlag unterstützen, dass man noch einen DHT11/22 dranhängen kann. Dann kann man das ganze auch noch als zusätzlichen Innenraumsensor mit Druck, Temperatur und Feuchtigkeit nehmen.
Beim betrachten des Devkits fiel mir auf, dass da ja ein 12e draufgelötet ist. Also sind die GPIOs nur umbenannt.
Auf dem Bild im Anhang kann man die Zuordnung von GPIO zu Dxx-Pins sehen. Muss also mit der gleichen Firmware gehen.
Zitat von: BlackFlag am 04 Dezember 2015, 21:19:12
Muss also mit der gleichen Firmware gehen.
Richtig.
Allerdings ist Dein Bild ein devkit V0.9
Das devkit V1.0 sieht so aus (da sind gpio9 und 10 rausgeführt, gpio9 wird ab LGW 1.07 als CS für den dritten RFM verwendet)
(http://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=41456;image)
Der Mann mit der roten Kleidung und dem Bart hat etwas gebracht:
V1.07
Quellcode verfügbar
hier: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip
Zum compilieren (wofür es eigentlich keinen Grund gibt, das binary reicht) ist (aktuell) folgende tool chain erforderlich:
- Arduino IDE V1.6.5 (nicht V1.6.6)
- ESP8266 Arduino Library V2.0.0-rc2
Fix OTA-Update bei manchen Browsern
Einigen browser (z.B. Chrome auf El Capitan) haben an die url hinten ein ? angehängt, wo ich es nicht erwartet hätte.
Das hat dann das OTA-Update verhindert.
Neues Setting KV-Identity
Auf der Setup-Page kann nun die identität des LGW für die Statuswerte in FHEM festgelegt werden, bisher war es fix die Chip-ID
Neuer Staus-Wert "RSSI"
Die wifi Signalstärke (dBm). -36 ist besser als -60
Bis zu drei Clients (FHEMs)
Es können nun auf der Setup-Page bis zu drei Ports, auf die sich dann bis zu drei FHEMs verbinden können, definiert werden.
Ports die man nicht benötigt, sollte man leer lassen, um Speicher und Rechenleistung zu sparen.
Die Portnummer 8266 ist verboten, die wird von OTA verwendet, und 80 geht natürlich auch nicht.
Wenn sich mehrere FHEMs ein LGW teilen, kann das natürlich nur mit einer gemeinsamen Konfiguration gehen.
Wenn die FHEMs unterschiedliche initCommands senden, gewinnt das (zufällig) letzte und legt es für alle anderen fest.
Dritter RFM möglich
Es kann nun ein dritter RFM69 / RFM12 angeschlossen werden.
MOSI, MISO und SCK parallel drauf, der ChipSelect für den dritten ist GPIO9 (SD2)
Aktualisierter Schaltplan in Beitrag #1 folgt in Kürze.
Commands Logik für drei RFMs erweitert
Da es nun drei RFMs gibt, die man konfigurieren muss / kann, reicht das System "Kleinbuchstabe ist #1 und Großbuchstabe ist #2" nicht mehr aus.
Es ist zur Kompatibilität noch aktiv, zusätzlich gibt es diese Variante:
<value>#<RfmNumber><command>
Beispiele:
Frequenz des zweiten RFM setzten: 868300#2f
Frequenz des dritten RFM setzten: 868295#3f
DataRate des ersten RFM setzen: 0#1r
DataRate des dritten RFM setzen: 8842#3r
Viel Spaß oder Glück oder was immer man für diese Version braucht ...
Zitat von: HCS am 06 Dezember 2015, 10:01:57
Der Mann mit der roten Kleidung und dem Bart hat etwas gebracht:
Einwandfrei !! , da kann ich die Integration des DHT22 und DS1820 gleich am lebenden Objekt testen.
Ich denke mit den beiden Sensoren werde ich heute fertig.
Leider hat mein LM75 ne Macke so das ich den erst nächste Woche mit aufnehmen kann.
Zitat von: HCS am 06 Dezember 2015, 10:01:57
Zum compilieren (wofür es eigentlich keinen Grund gibt, das binary reicht) ist (aktuell) folgende tool chain erforderlich:
- Arduino IDE V1.6.5 (nicht V1.6.6)
- ESP8266 Arduino Library V2.0.0-rc2
Lief bei mir im ersten Versuch nicht durch. Ich musste #include WiFiUDP.h durch #include WiFiUdp.h ersetzen und in den libs #include "Arduino.h" ganz entfernen.
Im Anhang eine geänderte Version der InternalSensors lib, diese unterstützt einen internen DHT22 und/oder einen DS1820.
Einbinden :
in der LaCrosseGateway.ino bei den includes diese beiden Libs noch hinzufügen:
#include <OneWire.h>
#include <DHT.h>
Aufruf des/der internen Sensor(en) z.B. im Abschnitt setup :
internalSensors.TryInitializeBMP180();
if (internalSensors.HasBMP180()) {
internalSensors.SetAltitudeAboveSeaLevel(ALTITUDE_ABOVE_SEA_LEVEL);
if (DEBUG_ESP) {
Serial.println("BMP 180 found");
}
}
danach diese Zeilen hinzufügen :
else
{
internalSensors.TryInitializeOW(5); // DS1820 am Pin5 bzw. D1
internalSensors.TryInitializeDHT(4); // DHT22 am Pin4 bzw. D2
}
unter der Bedingung das man keinen BMP180 an den beiden I2C GPIOs (4 & 5 bzw. D1 & D2) hängen hat.
Sind die beiden Pins schon belegt kann man auf jeden Pin anderen ausweichen der noch frei ist.
Wichtig : den/die verwendeten Pin(s) je mit einem PullUp (z.B 4,7 K) gegen VCC versehen.
Der DHT22 und der DS1820 meldet sich in fhem wie ein normaler TX29-IT ( der DHT mit der festen ID FE , beim DS1820 hängt die ID von seiner ROM Adresse ab).
Ich habe leider mit der C++ Syntax immer so meine kleinen Problemchen, daher findet sich in der InternalSensors.cpp eine etwas unschöne (doppelte) Verwendung von OneWire ds(pin,false). Vllt kann mir ja mal jemand zeigen wie man so etwas eleganter macht.
Zitat von: HCS am 06 Dezember 2015, 10:01:57
Dritter RFM möglich
Es kann nun ein dritter RFM69 / RFM12 angeschlossen werden.
MOSI, MISO und SCK parallel drauf, der ChipSelect für den dritten ist GPIO9 (SD2)
Aktualisierter Schaltplan in Beitrag #1 folgt in Kürze.
Kann man damit dann auch diese PCA301 Steckdosen mit dem gleichen Sketch schalten?
Soweit ich das begriffen habe scheiterte das bisher an dem anderen Radio und dem zu wenig Ram des Arduino.
Zitat von: AxelSchweiss am 06 Dezember 2015, 18:19:07
Kann man damit dann auch diese PCA301 Steckdosen mit dem gleichen Sketch schalten?
Soweit ich das begriffen habe scheiterte das bisher an dem anderen Radio und dem zu wenig Ram des Arduino.
Das Radio sollte OK sein, PCA301 verwendet glaube ich auch RFMs.
Dass der LaCrosse-Sketch am Anschlag ist, ist richtig.
Ein weiterer Grund ist, dass ich es implementieren müsste, mir also mal PCA301 draufschaffen, so 'ne Steckdose habe ich auch nicht, ...
Ich habe es schon von Beginn an auf der Wunschliste für das LGW, aber ob und wann das was wird, will ich jetzt mal noch keine Prognose abgeben.
Zitat von: Wzut am 06 Dezember 2015, 17:32:40
Lief bei mir im ersten Versuch nicht durch. Ich musste #include WiFiUDP.h durch #include WiFiUdp.h ersetzen und in den libs #include "Arduino.h" ganz entfernen.
Ja, Groß-/Kleinschreibung falsch. Merkt man unter Windows nicht...
Habe es repariert.
Den Rest muss ich mir dann mal in Ruhe anschauen.
Kannst Du mir noch die DHT-Lib schicken, die Du verwendet hast?
Zitat von: HCS am 06 Dezember 2015, 19:42:24
Kannst Du mir noch die DHT-Lib schicken, die Du verwendet hast?
Ja kein Problem, ich müsste diese haben : http://playground.arduino.cc/Main/DHTLib
Habe aber gerade gelesen das es von adafruit eine Version gibt die man durch einen zusätzlichen Warteparameter besser auf den ESP8266 abstimmen kann ->https://github.com/adafruit/DHT-sensor-library
ZitatSo when you use an example DHT application make sure to add that extra 15 parameter to the DHT object's constructor call. The parameter tells the code to wait an extra amount of cycles to read ones and zeros from the sensor--normally the library assumes its running on a slower Arduino so it can get a little confused when the processor is faster
werde ich heute Abend mal testen zusammen mit einem anderen LM75
Zitat von: Wzut am 07 Dezember 2015, 09:01:15werde ich heute Abend mal testen zusammen mit einem anderen LM75
OK. Bevor Du zu viel Arbeit in die falsche Richtung inverstierst, einige Gadanken und Unumgänglichkeiten dazu:
- Wenn DHT22 / DS1820 unterstützt werden, sollte das auf alle Fälle zusätzlich zu BMP180 gehen, sonst muss man auf den Luftdruck verzichten
- DHT22 / DS1820 würde ich auf einem GPIO abhandeln, es macht ja nur einer Sinn, nicht beide gleichzeitig
- Mögliche GPIO-Verwendung:
GPIO4 und 5 sind immer I2C, da kann ein BMP180, ein BME280 oder sonst ein I2C Baustein (z.B. LM75) dran.
GPIO10: (OneWire oder) DHT22 oder sonstwas wie z.B. ein OOK Radio
GPIO9 ist bereits der CS für den dritten RFM
GPIO0 muss ich mal noch ermitteln, was machbar ist, ohne den Bootvorgang zu gefährden, evtl. ein OOK Sender
Wenn man LaCrosse, Temp, Hum und Feuchte will, könnte man verwenden:
ein bis drei RFMs und einen BME280
ein bis drei RFMs, einen BMP180 und einen DHT22
Wenn man keine Feuchte will, dann: ein bis drei RFMs, einen BMP180
Wenn man nur die Temperatur will, dann: ein bis drei RFMs und einen (DS1820) LM75
Und das Ganze sollte so werden, dass diese Varianten vom Sketch erkannt werden, ohne dass man Ports konfigurieren
und die Firmware bilden muss.
Wenn der LM75 implementiert wird, dann würde ich auf die DS1820 Implementierung verzichten, weil man dann die Temperatur auf I2C hat und weniger Stress auf GPIO10.
1Wire wäre dann ganz raus.
Das LGW muss nun auch nicht die "AllSensorsYouCanFind" Plattform werden, der primäre Zweck ist der Empfang von LaCrosse.
Das sollte noch von der Architektur anders werden, aus der InternalSensors muss DHT und OneWire raus, weil ich die auch in anderen Projekten verwende (z.B. LaCrosse-Sketch) und es dort eher störend ist. Am besten wird man im LGW eine "LGWSensors" von der "InternalSensors" ableiten.
Zitat von: HCS am 07 Dezember 2015, 09:19:54
Und das Ganze sollte so werden, dass diese Varianten vom Sketch erkannt werden, ohne dass man Ports konfigurieren
und die Firmware bilden muss.
Ganz schön anspruchsvoll. ;) Dann würde es sich aber auch anbieten, statt des Portpins für 1-Wire, einen DS2482 I²C 1-Wire Master ein zusetzen. Dann kann man die Auswertung verschiedener 1-Wire-Sensoren in FHEM machen. Für die meisten sind ja schon Module vorhanden. Mit dem Baustein und einem FET bekommt man dann auch die parasitäre Speisung besser in den Griff.
Gruß Friedrich
mit dem Busmaster am I²C wäre auch mein Favorit. Bin mir aber nicht sicher, ob das in diesen Thread gehört.
Zitat von: Omega-5 am 07 Dezember 2015, 11:51:47
Ganz schön anspruchsvoll. ;)
Echt?
Wie viele und weche Sorte (12 oder 69) RFMs bestückt sind und ob ein BMP180 drauf ist, erkennt es ja auch schon.
Und was es nicht als Alternativen erkennen kann, bleibt raus.
Zitat von: HCS am 07 Dezember 2015, 09:19:54
Das LGW muss nun auch nicht die "AllSensorsYouCanFind" Plattform werden, der primäre Zweck ist der Empfang von LaCrosse.
Und dabei bleibe ich.
Es kann bereits: 1...3 x RFM12 oder RFM69 (auch gemischt) automatisch erkannt
BMP180 für Druck und Temperatur automatisch erkannt.
Es wird auf alle Fälle (auch automatisch erkannt) den BME280 für Temperatur, Feuchte und Druck können.
Der DHT22 für Temperatur und Feuchte ist auch noch machbar, auch automatisch erkannt.
Wie viele Sensoren soll es denn noch können und warum?
Zitat von: Omega-5 am 07 Dezember 2015, 11:51:47
Ganz schön anspruchsvoll.
Da bin ganz Friedrichs Meinung :)
@HCS, es ist dein Baby und somit auch deine Entscheidung wieviel Arbeit und welcher Art (und für wen) du dir in Summe ans Bein binden willst.
IMHO hast du mit der Setup Seite im Webinterface schon eine gute Grundlage, warum alle 200 möglichen Anbauteile und deren 500 Ausbaustufen via autocreate erfassen und nicht auf der Setupseite selbst zusammen klicken ?
Ideen was man noch alles anschliessen könnte werden mit Sicherheit noch einige kommen :P ( Mir allein fallen da schon spontan das OLED I2C Display und die I2C digital I/O Port Erweiterung ein ... )
Zitat von: Wzut am 07 Dezember 2015, 12:44:21
Da bin ganz Friedrichs Meinung :)
Ist mir nicht ganz klar, was da jetzt so anspruchsvoll ist. Ich habe nur das Konzept für alle Sensoren, die Du ins Spiel gebracht hast, aufgezeigt.
Und die Erkennung, ob ein DHT22 und ein DS1820 angeschlossen ist, hast Du doch auch schon in der InternalSensors implementiert.
Ich habe das Ganze nur ein wenig auf den GPIOs umverteilt und will die InternalSensors ableiten, um nicht andere Projekte dran anpassen zu müssen.
Trotzdem müsste mir jemand noch die Frage beantworten, warum es 5 verschiedene Temperatursensoren unterstützen sollte.
Eine andere (noch völlig unausgereifte) Idee ist mir aber gerade eingefallen: wenn ich auf der seriellen Schnittstelle ein Protokoll zur Verfügung stelle, mit dem man Daten beim LGW abliefern kann, könnte jeder, der Bedarf hat, sich einen Sub-Prozessor dranpacken, z.B. einen kleinen Mega oder 'nen Tiny mit Sensoren dran, was immer er will und das LGW würde die Daten dann stumpf an FHEM übermitteln, z.B. per KeyValueProtocol.
Somit müsste sich jemand nicht mit WiFi, Konfiguration und dem ganzen Kram rumschlagen, sondern nur ein wenig Sensor auslesen implementieren und auf der Seriellen in einem bestimmten Format rausgeben. Das LGW erledigt dann den Rest. Dann wäre das LGW, ohne es ändern zu müssen, universell erweiterbar.
Stabil scheint es auf alle Fälle zu laufen:
<LGW>
<Info Key="UpTimeSeconds" Value="711895"/>
<Info Key="UpTimeText" Value="8Tg. 5Std. 44Min. 55Sek. "/>
<Info Key="WIFI" Value="هذا هو سري"/>
<Info Key="MacAddress" Value="18:FE:34:9A:6D:48"/>
<Info Key="ChipID" Value="10120520"/>
<Info Key="ReceivedFrames" Value="615949"/>
<Info Key="FramesPerMinute" Value="94"/>
</LGW>
Aber länger halte ich nicht durch, ohne neue Firmware zu flashen ;D ;D
Ich lese hier schon eine Weile mit und finde das Projekt sehr interessant.
Die Teile sind jetzt bestellt.
Ich werde mich an der Einrichtung versuchen und Feedback geben.
Ich hätte auch einen Funktionswunsch, auch wenn es nicht out-of-the-box verhanden ist die der LaCrossSketch, aber evtl. besteht ovn anderer Seite auch noch irgendwo Interesse für eine Umsetzung.
Soweit ich es im Datenblatt gelesen habe unterstützt der RFM69 Baustein von Haus aus die OOK Modulation.
Demnach müsste es doch in der Theorie möglich sein, mit dieser Gateway auch die OOK-Wetterstationen einzulesen und/oder Baumarksteckdosen zu schalten?
Speicherplatz müsste ausreichend vorhanden sein.
Zitat von: HCS am 07 Dezember 2015, 13:36:50
Trotzdem müsste mir jemand noch die Frage beantworten, warum es 5 verschiedene Temperatursensoren unterstützen sollte.
Eine andere (noch völlig unausgereifte) Idee ist mir aber gerade eingefallen: wenn ich auf der seriellen Schnittstelle ein Protokoll zur Verfügung stelle, mit dem man Daten beim LGW abliefern kann, könnte jeder, der Bedarf hat, sich einen Sub-Prozessor dranpacken
Es müssen keine fünf sein, nach meiner Meinung eichen auch zwei vollkommen. Entweder man hat noch einen GPIO frei dann den DHT22 oder es sind alle Ports belegt dann weicht man auf auf die I2C Schiene aus.
Sub-Prozessor fände ich suboptimal, klar er bringt dann wieder jede menge IOs, opferst aber die direkte serielle fhem Anbindung. Aussderdem müsste man sich noch einen Baustein programmieren und auf dem ESP ist doch noch jede Menge Platz. Stichwort Platz, im Anhang das LGW mit 128x64 Pixel I2C OLed Display.
(auch da ist noch viel Platz für nette Infos frei ..... )
Zitat von: Doublefant am 07 Dezember 2015, 19:03:57und/oder Baumarksteckdosen zu schalten?
Das scheint machbar, aber OOK ist bisher nicht unbedingt mein Spezialthema.
Da muss ich mich mal irgendwann in Ruhe mit beschäftigen.
Zitat von: Doublefant am 07 Dezember 2015, 19:03:57Demnach müsste es doch in der Theorie möglich sein, mit dieser Gateway auch die OOK-Wetterstationen einzulesen ...
Das ist schon heftiger, aber evtl. auch machbar.
Zitat von: Doublefant am 07 Dezember 2015, 19:03:57
Speicherplatz müsste ausreichend vorhanden sein.
Speicherplatz ist nicht das Problem. Es könnte eher ein Problem sein, dass man bei OOK heftig das RSSI pollen muss und das könnte auf dem ESP, der "nebenbei" ja den kompletten IP protokoll stack, wifi und sonst einiges in Schwung halten muss, problematisch werden. Eventuell wird da noch ein Signalisierungs-Port des RFM benötigt, für den dann noch ein GPIO des ESP8266 frei sein muss.
Ich habe das auf der Langzeitagenda, aber Prognosen, ob überhaupt oder wann das was wird, gebe ich mal noch keine ab.
Wichtig: ich habe gerade den ChipSelect des dritten RFM auf GPIO0 (D3) verlegt (ab V1.08)
Grund: GPIO0 ist der flash taster mit PullUp. Das spielt für den CS keine Rolle, da er erst nach dem Booten zum Ausgang wird und ein RFM69 hier nicht stören kann.
Somit sind dann GPIO9 und GPIO10 noch verfügbar, und die können beide als Eingänge oder Ausgänge verwendet werden, weil sie keine Spezialfunktionen wie z.B. die Bootsteuerung haben.
GPIO9 "opfere" ich für einen internen Sensor (z.B. DHT22), der andere bleibt als Vorrat für OOK oder sonst was "wichtiges".
Zitat von: Wzut am 07 Dezember 2015, 19:41:36
Sub-Prozessor fände ich suboptimal, klar er bringt dann wieder jede menge IOs, opferst aber die direkte serielle fhem Anbindung
Darum ist es ja auch ein Sub(optimal)-Prozessor ;D ;D ;D
Die direkte serielle Anbindung an FHEM wollte ich nicht opfern, ich dachte eher an ein SoftSerial über nur einen Pin.
Zitat von: Wzut am 07 Dezember 2015, 19:41:36
im Anhang das LGW mit 128x64 Pixel I2C OLed Display.
Coole Sache. Auch auf die Gefahr hin, dass ich die permanente Spaßbremse bin, was ist denn da der use case?
Zitat von: HCS am 07 Dezember 2015, 22:47:32
Coole Sache. Auch auf die Gefahr hin, dass ich die permanente Spaßbremse bin, was ist denn da der use case?
Man könnte doch da einen loadabhängigen Pacman drüber flitzen lassen ? ..... nur'n Scheerz.
Habe ich mich auch gefragt wozu das soll ... aber welche Lib hast du den dafür verwendet .... U8glib ?
Zitat von: AxelSchweiss am 07 Dezember 2015, 22:51:22
Man könnte doch da einen loadabhängigen Pacman drüber flitzen lassen
Besser so einen use case als gar keinen ;D ;D ;D
Zitat von: HCS am 07 Dezember 2015, 22:47:32
Auch auf die Gefahr hin, dass ich die permanente Spaßbremse bin, was ist denn da der use case?
[OT on]
Wenn ich ich gemein wäre würde ich mit der Gegenfrage antworten "warum lecket der Hund sich die Eier ?" (Antwort : "weil er es kann")
Das Display hängt bei mir sowieso am Devkit weil ich es für eine andere noch offene Baustelle benötige. Die verwendete Lib ist von Adafruit.
[OT off]
Bei mir soll später das LGW mit drei RFMs und einem kleinen Schaltnetzteil zusammen in einem Steckgehäuse irgendwo in der Wohnung an einem zentralen Punkt in einer Steckdose stecken. Z.Z. überlege ich noch ob ich dem LGW ein/zwei LEDs spendiere um zumindest etwas vom Status direkt anzuzeigen oder doch noch so ein Oled kaufe und neben Status Infos auch Temperatur und Luftfeuchte des interen Sensors anzeige. So wie der beliebte TX29DTH-IT Sensoren sein kleines LCD auch nicht für einen internen PacMan hat ....
Die Idee das in ein Steckergehäuse zu verpacken finde ich gut.
Ich möchte nä(h)mlich das LGW einfach in die Ecke werfen und nicht mehr sehen .... es soll dann einfach nur noch funktionieren.
Zitat von: AxelSchweiss am 08 Dezember 2015, 08:56:29
Ich möchte nä(h)mlich das LGW einfach in die Ecke werfen und nicht mehr sehen .... es soll dann einfach nur noch funktionieren.
So ich auch. Am besten hinter einem Schrank.
Das war auch die Grundidee des LGW, dass die ideale Position zum Empfang aller Sensoren meist nicht mit dem Standort des Servers übereinstimmt.
Zitat von: AxelSchweiss am 08 Dezember 2015, 08:56:29
Die Idee das in ein Steckergehäuse zu verpacken finde ich gut.
Die Frage ist, wie realistisch die Temperaturwerte in einem Steckergehäuse mit Spannungsversorgung innen drin sind.
Ich glaube, dass ich es lieber in ein kleines Gehäuse setze (auf einer hübschen kleinen Platine, habe es nicht vergesen, PeMue) und mit einem externen USB-Steckernetzteil versorge.
Aber dass kann ja dann zum Glück jeder nach seinem Geschmack gestalten.
Ich werde noch den beliebten DHT22 und den BME280 mit autosense implementieren, und dann ist erst mal gut mit lokalen Sensoren.
Wer jetzt schon Hardware bastelt, sollte aber zu Sicherheit noch etwas Platz lassen, um irgend welche weitere Hardware später noch rein zu bekommen.
ich habe mir ebenfalls ein NodeMCU zugelegt und wollte ein wenig damit spielen. Meine Idee ist es, mit UDP-Multicast ins Netz zu brüllen. Ggf. sinkt damit der CPU-Aufwand im Gateway (mehr Nachrichten pro Minute).
In FHEM könnte anhand der ChipID (wird mittels http gelesen) selektiert werden, welche Nachrichten verarbeitet werden sollen (mehrere Gateways in einem Netz). Nur so eine Idee für ein kleines Framework, die ich zur Diskussion stellen wollte.
Würde gut zum KeyValueProtocol passen (schön generisch).
Es hat mir (oder mich?) in den Fingern gejuckt. ;)
Mal geschaut welche Bauteile schon in den Eagle Libs sind und wie groß der Platzbedarf wohl ist. Natürlich kann man auch einige Module auf die Unterseite packen und unter das Dev-Kit. Aber jetzt habe ich wenigstens schon mal eine Vorstellung wie groß das Gehäuse sein muss.
Gruß Friedrich
Zitat von: Omega-5 am 08 Dezember 2015, 11:56:46
Es hat mir (oder mich?) in den Fingern gejuckt. ;)
Cool. Jetzt kannst Du mit PeMue absprechen, wer sie machen will...
Um die Themen etwas zu kanalisieren, schlage ich vor, einen eigenen "Hardware" Thread für die Platine aufzumachen, am besten von demjenigen, der sie designen will, dass er Beitrag #1 ändern kann.
Ich habe eine Reihe Ideen/Punkte dafür, die würde ich dann dort posten.
Würde derjenige, der das Design macht, auch Produktion und Verteilung organisieren?
Zitat von: HCS am 08 Dezember 2015, 12:34:40
Cool. Jetzt kannst Du mit PeMue absprechen, wer sie machen will...
Hallo Friedrich,
sollen wir knobeln? Wenn das Layout nicht zeitkritisch ist, kann ich es machen. Aber ich lasse Dir gerne den Vortritt ;)
Gruß PeMue
Zitat von: HCS am 08 Dezember 2015, 09:21:44
Ich werde noch den beliebten DHT22 und den BME280 mit autosense implementieren
D.h. ich kann das Thema LM75 vorläufig zur Seite legen ?
if (HCS_Antwort eq "ja") { OK; }
else
{
da der LM75 drei Address Pins hat: Soll eine bestimmte Adresse fix vorgegeben werden oder eine mini Suche über die möglichen acht Adressen statt finden ?
}
Zitat von: Wzut am 09 Dezember 2015, 09:18:41
D.h. ich kann das Thema LM75 vorläufig zur Seite legen ?
Eigentlich brauchst Du nichts machen, ich habe in einem anderen System (meiner Heizungssteuerung) eine Reihe LM75 laufen, die Routinen sind somit vorhanden und die Dinger kenne ich mehr als mir lieb ist.
Bin übrigens (aufgrund der Erfahrung aus diesem System) kein besonderer LM75 Fan.
Die liegen teils auch bis zu zwei Grad daneben, musste für alle Temperaturen Offsets konfigurierbar machen.
Ich habe wohl noch einige LM75 ganz unten in der Kiste vergraben, wenn DHT22 und BME280 durch sind, baue ich den vielleicht noch ein, und dann ist gut.
Auf I2C kann ich mich eher mit sowas anfreunden.
Muss jetzt sowieso erst mal die InternalSensors umarangieren ...
Der DHT22 und der BME280 laufen aber schon mal generell.
meine Erfahrungen:
Hardware: Huzzah Dev Board+ CP2104 USB Bridge + RMF12
- Teile zusammengelötet
- mit dem nodemcu-flasher deine Software Version 1.07 aufgespielt
- neu gestartet und mit dem Accesspoint verbunden
- über die Setup IP Page meine Netzwerkdaten eingegeben (static IP)
- Werte werden über die serielle Schnittstelle ausgegeben
- in Fhem definiert
- mit einem LaCrosse gepairt
- funktioniert 8)
Tolles Teil und problemlos einzurichten, DANKE!
Der RFM69 ist leider noch nicht angekommen, ich denke aber der wird dann auch am Board laufen.
Blöderweise bin ich bei der Bauteilbestellung noch vom DS1820 ausgegangen, somit habe ich jetzt noch keinen Sensor direkt dran hängen.
Ich werde mir einen passenden Sensor nachbestellen.
Bitte zur Bestätigung ob ich das richtig verstanden habe:
-Im Moment wird nur der BMP180 unterstützt
-DHT22 und BME280 sind in der Testphase
-DS1820 und LM75 werden erst einmal nicht unterstützt
Allerdings verstehe ich noch nicht worin der use-case eines Luftdrucksensors Indoor besteht, außer nice to have.
Die Idee mit dem Sub-Prozessor über RS232 finde ich ein nettes Feature. Für mich würde sich damit die Möglichkeit bieten eigene Hardware einzubinden ohne sich mit Raspbian und Fhem Protokollen/Datenübergabe/Einbindung einlesen zu müssen.
Zum Abschluss noch ein Hinweis:
Bei mir sendet die Gateway alle paar Sekunden einen Statusbericht über die Serielle Schnittstelle.
Der gleiche Bericht wird auch in Fhem über Wifi übertragen.
Da dort sehr viele Informationen drin stecken wird der Event Monitor und das Logfile meiner Meinung nach sehr zugespamt.
Ich Tippe aber darauf, dass es zum Debugging während der Entwicklung in der Beta-Phase extra so gewollt ist?
Zitat von: Doublefant am 09 Dezember 2015, 19:46:58
Allerdings verstehe ich noch nicht worin der use-case eines Luftdrucksensors Indoor besteht, außer nice to have.
Das ist der normale use-case. ;)
Dem Luftdruck ist es wurscht ob er innen oder außen gemessen wird.
Deshalb wird bei den meisten Wetterstationen der Luftdruck innen im Empfangsteil gemessen.
Gruß Billy
UDP-Mulitcast
habe ein Test fertig und bin etwas erstaunt, das ein HTTP-Response ca. 200 - 500 ms benötigt. Ein UDP-Multicast benötigt lediglich 1,001 ms.
Im Sketch noch die WiFi-Einstellungen vornehmen.
Empfang der Pakete kann mit tcpdump getestet werden (alle 5s 2 Pakete).
tcpdump -i <interface> -n dst port 12345
HTTP-GET via telnet
GET / HTTP/1.1
HTTP-POST via telnet
POST /config HTTP/1.1
Content-length:6
Content-type:application/x-http-form-urlencoded
p1=abc
Zitat von: Doublefant am 09 Dezember 2015, 19:46:58
Der RFM69 ist leider noch nicht angekommen, ich denke aber der wird dann auch am Board laufen.
Ja, läuft.
Zitat von: Doublefant am 09 Dezember 2015, 19:46:58
Bitte zur Bestätigung ob ich das richtig verstanden habe:
-Im Moment wird nur der BMP180 unterstützt
-DHT22 und BME280 sind in der Testphase
-DS1820 und LM75 werden erst einmal nicht unterstützt
Der BMP180 wird aktuell unterstützt. Er misst Luftdruck und Temperature
DHT22 und BME280 werden in der V1.08 (wohl nächste Woche) verfügbar werden.
Der LM75 wird vermutich irgendwann auch noch implementiert (aber ohne Garantie) und der DS1820 wohl eher nicht.
Man kann, wenn es dann so weit fertig ist, folgendes messen (je nach Bestückung):
BMP180: Druck und Temperatur
BME280: Druck, Temperatur und Feuchte
DHT22: Temperatur und Feuchte
BMP180 + DHT22: Druck, Temperatur und Feuchte
Zitat von: Doublefant am 09 Dezember 2015, 19:46:58
Bei mir sendet die Gateway alle paar Sekunden einen Statusbericht über die Serielle Schnittstelle.
Der gleiche Bericht wird auch in Fhem über Wifi übertragen.
Da dort sehr viele Informationen drin stecken wird der Event Monitor und das Logfile meiner Meinung nach sehr zugespamt.
Ich Tippe aber darauf, dass es zum Debugging während der Entwicklung in der Beta-Phase extra so gewollt ist?
Du meinst die "OK VALUE ..." Daten?
Das ist ein Feature. Das LGW sendet periodisch seine Statusdaten an FHEM.
Auf der Setup-Page kann man das einstellen, ob und wie oft. Das setting ist "KV-Interval"
10 bedeutet alle 10 Sekunden die Informationen übermitteln. Mit "off" kann man es abschalten.
Wenn Autocreate aktiv ist, sollte eigentlich automatisch ein KeyValueProtocol device in FHEM angelegt werden, in das die Daten reinlaufen, und dort kann man die Events ja dann mit event-on-change-reading usw. bremsen.
Ich logge z.B. FramesPerMinute und RSSI, um zu sehen, ob das LGW noch ordentlicht Sensoren empfängt und ausreichend wlan Empfang hat. Siehe Beispiel LGW.png.
Man kann damit auch sehr gut verschieden Standorte für das LGW austesten oder schauen, ob es bestimmte Zeiten gibt, zu denen der Empfang durch irgend etwas gestört wird, ...
Generell: das LGW sendet alle Daten, die es über wifi an FHEM zustellt, auch auf die serielle Schnittstelle. Somit kann man das LGW auch (alternativ, gleichzeitig macht keinen Sinn) anstatt über wifi so wie einen JeeLink an FHEM betreiben. Dazu kann man über die initCommands des jeeLink device in FHEM das wifi im LGW mit dem Command "0w" abschalten.
Zitat von: habeIchVergessen am 09 Dezember 2015, 22:35:56
habe ein Test fertig und bin etwas erstaunt, das ein HTTP-Response ca. 200 - 500 ms benötigt. Ein UDP-Multicast benötigt lediglich 1,001 ms.
Im Sketch noch die WiFi-Einstellungen vornehmen.
Ich verstehe die Problematik an sich noch gar nicht. Mein LGW empfängt (siehe Hardcopy im vorhergehenden Beitrag) ca. 100 SensorFrames pro Minute und die werden gebündelt einmal pro Sekunde über den datenport 81, auf dem das JeeLink device sitzt, zugestellt (push) und zwar alle.
Wo liegt das konkrete Problem?
Und bei mir geht übrigens ein http get auf die Status-Seite des LGW auch deutlich schneller, so im Bereich 50-60 ms, siehe Anhang.
Zitat von: Billy am 09 Dezember 2015, 21:21:45
Das ist der normale use-case. ;)
Dem Luftdruck ist es wurscht ob er innen oder außen gemessen wird.
Deshalb wird bei den meisten Wetterstationen der Luftdruck innen im Empfangsteil gemessen.
Genauso ist es. Das war schon beim "SuperJee" der Grund, warum ich dort den BMP180 implementiert habe. Man hat alle Daten der Wetterstation in FHEM außer dem Luftdruck, weil der nicht vom Außensensor gemessen und gesendet wird, sondern von der Anzeigeeinheit, die man im Haus an der Wand hängen hat.
Und irgendwie will man ja wissen, dass gerade ein Sturmtief naht. :)
Uhhh sorry :-\
Wenn man keine Ahnung hat, einfach mal die Klappe halten...
Naja, immerhin habe ich was gelernt, der Luftdruck wird in der Basisstation gemessen und nicht im Außensensor :-X
Genau, ich meinte die "OK VALUE..." Daten.
Achso, ich kann das Intervall einstellen, sehr gut, muss ich gleich mal probieren. Das muss ich im Eifer bei der Einrichtung übersehen haben.
Das KeyValueProtokoll wurde automatisch angelegt und wird auch schön mit Daten gefüttert.
Zitat von: Doublefant am 10 Dezember 2015, 19:52:53
Wenn man keine Ahnung hat, einfach mal die Klappe halten...
Nö, ist schon OK, wenn man fragt.
V 1.08
Sensoren
Es werden nun folgende Sesoren unterstützt:
BME280, BMP180, DHT22 und LM75
Die Sensorphalanx arbeitet so:
Alle Sensoren werden automatisch erkannt, wenn sie vorhanden sind.
Sie werden in folgender Reihenfolge verwendet:
Wenn ein BME280 vorhanden ist, wird dieser verwendet und sonst nichts, da man dann bereits Temperatur, Feuchte und Druck hat.
Ist kein BME280 vorhanden, wird geschaut, ob ein BMP180 vorhanden ist. Falls ja, haben wir Druck und Temperatur.
Dann wird geschaut, ob ein DHT22 vorhanden ist. Wenn ja, wird er zusätzlich verwendet, aber vom BMP180 dann nur noch der Druck.
Temperatur und Feuchte vom DHT22, dass dieses Wertepaar von einem Sensor stammt.
Wenn kein BMP180 und kein BME180 da ist, sondern nur ein DHT22, dann hat man Temperatur und Feuchte.
Wenn nichts Vernünftiges vorhanden ist (also keiner der bisher genannten Sensoren), wird, falls vorhanden, der LM75 verwendet.
Daraus ergeben sich folgende Sensor-Varianten (andere ergeben keinen Sinn):
BME280
-> Temperatur, Feuchte und Druck
BMP180:
-> Temperatur und Druck
BMP180 + DHT22:
-> Temperatur, Feuchte und Druck
DHT22
-> Temperatur und Feuchte
LM75
-> Temperatur
Schaltplan
An Beitrag #1 hänge ich die aktualisierte Schaltung an.
LaCrosseGateway-CircuitDiagram-DevBoard-Minimum.png = Minimalausbau mit einem RFM
LaCrosseGateway-CircuitDiagram-DevBoard-Full.png = Alle Sensoren, die möglich sind
Hier noch ein Bild (LaCrosseGateway-SensorPhalanx.png) von einem voll ausgebauten LGW auf breadboard.
Da beginnt man dann von einer Platine zu schwärmen :)
Und klar, ihr habt es schon erkannt, habe es ja oben erläutert, das macht keinen Sinn mit allen vier Sensoren drauf, außer man muss es entwickeln und testen ... ;D
Hallo HCS,
ich habe mal hier http://forum.fhem.de/index.php/topic,45594.0.html die Ideensammlung zur Platine gestartet ...
Gruß PeMue
Zitat von: PeMue am 12 Dezember 2015, 21:36:48
Hallo HCS,
ich habe mal hier http://forum.fhem.de/index.php/topic,45594.0.html die Ideensammlung zur Platine gestartet ...
Gruß PeMue
Toll!
Komme gleich dort hin ... ;)
Zitat von: HCS am 12 Dezember 2015, 21:09:31
V 1.08
Bei mir ging das Update daneben ... sowohl via OTA als auch direkt via Flash am Port
Nach Rückfall auf 1.0.7 mit dem direkten Weg funktioniert das LGW wieder.
Er rebootet reproduzierbar immer an der gleichen Stelle ... wenn er die angeschlosenen Komponenten sucht.
Angeschlossen ist nur ein BMP180 ... und noch kein Radio.
Log anbei:
ZitatThis is line 5 of void setup(void)
LaCrosseITPlusReader.Gateway V1.08
Read settings
Settings are:
Key:ctSSID Val:xxxxxxx
Key:ctPASS Val:xxxxxxx
Key:HostName Val:LaCrosseGateway
Key:KVInterval Val:10
Key:otaServer Val:foo.bar.com
Key:otaPort Val:80
Key:otaURL Val:/LaCrosseGateway.bin
Starting wifi
HostName is: LaCrosseGateway
Using DHCP
Trying to connect to an AP
.
connected :-)
SSID: xxxxxxx
IP: 192.168.11.140
OTA running on port 8266
Searching RFMs and BMP
,, œ
HHZ1)˜þ!!H{ ½½
*,,ŒÚ�»Û½ÖˆK¥SˆˆkH
Ê{° Ÿ¬H Œ)oˆ– Ü¿Hn:ø¯
This is line 5 of void setup(void)
LaCrosseITPlusReader.Gateway V1.08
Read settings
First, Du solltest evtl. nun doch Dein wpa passwort ändern, in den Benachrichtigungs-Mails ist es raus ;)
Das könnte an der neuen Sucherei der I2C-Sensoren liegen. Kannst Du mal testen, ob es mit zwei 4,7K PullUp Widerständen an SDA und SCL funktioniert?
Ich dachte, dass ich alle Sensorkombinationen / Varianten probiert habe, bin aber nicht ganz sicher, ob ich einen BMP180 alleine mal drauf hatte.
Zitat von: AxelSchweiss am 12 Dezember 2015, 23:35:14
Er rebootet reproduzierbar immer an der gleichen Stelle ... wenn er die angeschlosenen Komponenten sucht.
Angeschlossen ist nur ein BMP180 ... und noch kein Radio.
Interessant, ich kann das Problem nachvollziehen, auf einem puren ESP-12E stirbt es bei mir, auf dem devkit geht es.
Hast Du ein devkit oder einen puren ESP-12E?
Das wird wohl heute noch eine V1.09 werden >:(
Habe diese DevKit
http://de.aliexpress.com/item/Update-Industry-4-0-New-esp8266-NodeMCU-v2-Lua-WIFI-networking-development-kit-board-based-on/32358722888.html?detailNewVersion=2 (http://de.aliexpress.com/item/Update-Industry-4-0-New-esp8266-NodeMCU-v2-Lua-WIFI-networking-development-kit-board-based-on/32358722888.html?detailNewVersion=2)
Zitat von: AxelSchweiss am 13 Dezember 2015, 09:00:37
Habe ein devkit.
Misteriös ...
Den Test mit den PullUps kannst Du streichen, daran liegt es nicht.
Meine Supportabteilung, die Entwickler und das Test-Team arbeiten mit Hochdruck daran ...
Zitat von: HCS am 13 Dezember 2015, 09:02:31
Meine Supportabteilung, die Entwickler und das Test-Team arbeiten mit Hochdruck daran ...
Ahh .. gleich MissionCritical-Support Support mit eingeflogenem Core-Developer
8)
Zitat von: AxelSchweiss am 12 Dezember 2015, 23:35:14
Er rebootet reproduzierbar immer an der gleichen Stelle ... wenn er die angeschlosenen Komponenten sucht.
Habe V1.09 eingecheckt. Das Problem ist wohl, dass der Zugriff auf GPIO9, an dem der DHT22 dran ist (oder dran sein könnte) nur auf manchen ESP12E klappt.
Ich habe hier beide Fälle laufen, den geht und den geht nicht Fall.
Um erst mal wieder eine (hoffentlich) überall lauffähige Version zu habe, habe ich in meiner Verzweiflung den DHT22 erst mal stillgelegt, bis ich dafür eine bessere Lösung habe.
Kannst Du bitte mit der Version hier
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/firmware/LaCrosseGateway.bin
es probieren, und kurz eine Rückmeldung geben?
Funktioniert
ZitatThis is line 5 of void setup(void)
LaCrosseITPlusReader.Gateway V1.09
Read settings
Settings are:
Key:ctSSID Val:xxxxx
Key:ctPASS Val:xxxxx
Key:HostName Val:LaCrosseGateway
Key:DataPort1 Val:81
Key:KVInterval Val:10
Key:KVIdentity Val:961937
Key:otaServer Val:xxxxx
Key:otaPort Val:80
Key:otaURL Val:/LaCrosseGateway.bin
Starting wifi
HostName is: LaCrosseGateway
Using DHCP
Trying to connect to an AP
...
connected :-)
SSID: xxxxx
IP: 192.168.11.140
OTA running on port 8266
Searching RFMs and BMP
BMP180 found
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.09 + BMP180 {IP=192.168.11.140}]
Setup completely done
OK WS 0 4 4 182 255 255 255 255 255 255 255 255 255 0 3 228
OK VALUES LGW 961937 UpTimeSeconds=10,UpTimeText=0Tg. 0Std. 0Min. 10Sek. ,WIFI=xxxxx,MacAddress=5C:CF:7F:0E:AD:91,ChipID=961937,ReceivedFrames=0,FramesPerMinute=0,RSSI=-81
OK WS 0 4 4 182 255 255 255 255 255 255 255 255 255 0 3 228
OK VALUES LGW 961937 UpTimeSeconds=20,UpTimeText=0Tg. 0Std. 0Min. 20Sek. ,WIFI=xxxxx,MacAddress=5C:CF:7F:0E:AD:91,ChipID=961937,ReceivedFrames=0,FramesPerMinute=0,RSSI=-81
OK WS 0 4 4 183 255 255 255 255 255 255 255 255 255 0 3 228
Zitat von: HCS am 13 Dezember 2015, 11:14:32
Das Problem ist wohl, dass der Zugriff auf GPIO9, an dem der DHT22 dran ist (
9 und 10 sind betroffen -> http://smarpl.com/content/esp8266-esp-201-module-freeing-gpio9-and-gpio10
Hallo,
da gestern endlich mein NodeMCU DEVKIT 1.0 angekommen ist, habe ich mich heute mal hingesetzt um ein paar Versuche zu machen.
Flashen hat soweit gut geklappt, nur leider bekomme ich keine Anbindung in mein Netzwerk hin.
Meine Vermutung ist, das es Probleme mit meiner SSID gibt.
FRITZ!Box 7390
Es kommt keine Verbindung zustande und wenn ich mich danach wieder über die 192.168.222.1/setup verbinde steht bei SSID FRITZ!Box+7390 drin.
Das Leerzeichen wird durch ein + ersetzt.
Anbindung über Gastzugang (SSID ohne Sonder- und Leerzeichen) funktioniert.
Beide Passwörter sind ohne Sonderzeichen.
Brauche ich für das Leerzeichen ne andere Schreibweise?
Ich würde nämlich nur ungern meine SSID ändern.
Gruß
Stefan
Zitat von: StefanW am 17 Dezember 2015, 09:35:51
"FRITZ!Box 7390" -> "FRITZ!Box+7390"
Ups, das scheint ein Fehler zu sein. Ich hoffe, dass das Problem in meiner Settings -> EEPROM Schreiberei liegt, dann kann ich es beheben.
Ich schaue es mir mal an.
Super!
Dann hoffe ich mal das beste. ;-)
Zitat von: StefanW am 18 Dezember 2015, 13:20:01
Super!
Dann hoffe ich mal das beste. ;-)
Hoffen hat geholfen. Habe gerade V1.10 eingecheck, in der das Problem behoben ist.
Ich habe übrigens damit begonnen, PCA301 im LGW zu implementieren.
Zitat von: HCS am 18 Dezember 2015, 20:47:10
Ich habe übrigens damit begonnen, PCA301 im LGW zu implementieren.
Schick ... Schick ... Schick ...
Und schon reduziert sich mein Zoo hier 8)
Danke!
Zitat von: HCS am 18 Dezember 2015, 20:47:10
Ich habe übrigens damit begonnen, PCA301 im LGW zu implementieren.
Denkst du dass du den PCA301 mit dem RFM69 zum Laufen bekommst?
Gruß Billy
@HCS , bevor dir langweilig wird :
Du hattest im Platinen Fred das Thema RSSI angesprochen bzw. Unterschiede zwischen einfachen und externen Antennen.
Ich habe z.Z. leider nur den ESP8266-12 auf dem Steckbrett und nicht den -07, kann somit jetzt keine Aussage über bessere oder schlechtere RSSI Werte machen, was man aber machen könnte ist ein Netzwerk Scann um das Wlan Umfeld anzuzeigen. Macht die Sache bei der Erstinstallation einfacher da man statt dem Textfeld eine Dropdown Liste anzeigen könnte bzw. auch nachher auf der Setupseite falls man zugunsten eines besseren RSSI Wertes die SSID wechseln möchte (Ich habe z.B. bei mir im Haus/Grundstück drei SSID) Bsp Netzwerk Scann :
byte available_networks = WiFi.scanNetworks();
for (int network = 0; network < available_networks; network++)
{
strBuffer = WiFi.SSID(network);
if (DEBUG)
{
Serial.print("SSID : "+strBuffer);
Serial.println(" "+(String)WiFi.RSSI(network));
}
}
Ich habe das Stückchen mal ganz zu Anfang unter setup() gepackt und sehe somit schon mal was ich wie gut am Basteltisch empfange.
Obwohl ich in einem Forum etwas anderes gelesen konnte ich den Scann auch wiederholen nachdem der ESP bereits aktive Verbindungen hatte und diese dabei nicht abgebaut wurden.
Zitat von: Billy am 18 Dezember 2015, 21:14:26
Denkst du dass du den PCA301 mit dem RFM69 zum Laufen bekommst?
Da gebe ich in diesem Stadium noch keine Prognose ab. Aber es steht auf der ToDo.
Zitat von: Wzut am 18 Dezember 2015, 21:43:34
@HCS , bevor dir langweilig wird
;D ;D ;D ;D ;D
Ich implementiere gerade PCA301. Und Billy will es auf dem RFM69...
Zitat von: Wzut am 18 Dezember 2015, 21:43:34
WiFi.scanNetworks();
Wie lange dauert denn der Scan bei drei Netzwerken?
Ich schreibe es mal auf die ToDo, mit Prio 4.75
Das kann man übrigens mit jedem Android-Smartphone und einer kostenlosen App sehr übersichtlich darstellen.
Und nein, das sind nicht meine Netzwerke, das ist das Beispiel aus dem Play-store
Zitat von: HCS am 18 Dezember 2015, 20:47:10
Hoffen hat geholfen. Habe gerade V1.10 eingecheck, in der das Problem behoben ist.
Habe mir eben die V1.10 aus dem svn geholt und ausprobiert.
Der Fehler "FRITZ!Box 7390" -> "FRITZ!Box+7390" besteht leider immernoch.
Gruß
Stefan
Du hast die Settings nochmal neu gespeichert?
Ist nach dem Speichern das + immer noch drin oder ist es raus und Du bekommst nur keinen connect dann?
Ich konnte nur testen, ob die Settings korrekt gespeichert werden, weil wollte auch keine SSID bei mir auf einem AP ändern ;)
Ich habe die Settings ein paar mal geändert und neu gespeichert.
Nach dem Neustart ist immer wieder das + drin und somit kommt auch keine Verbindung zustande.
Hallo,
ich habe es mit der 1.09 noch hin bekommen. Nach einen missglückter Versuch habe ich das initCommands 0e über das Terminalprg. geschickt und das Setup neu gemacht. Dann war das + weg. Bei mir war versehentlich SSID ein Name mit Leerzeichen zum Schluss.
Gruß
Maxel
PS: @HCS - Superentwicklung! :)
Zitat von: StefanW am 19 Dezember 2015, 08:20:25
Ich habe die Settings ein paar mal geändert und neu gespeichert.
OK, probier mal bitte mit der angehängten Version. Der Glühwein gestern Abend war wohl nicht förderlich für den bugfix :-[
Zitat von: Maxel am 19 Dezember 2015, 08:41:08Bei mir war versehentlich SSID ein Name mit Leerzeichen zum Schluss.
Was es nicht alles gibt :o
Nachtrag: Anhang entfernt weil nun im Repo eingecheckt.
Also, mit der Version funktioniert es jetzt!
Vielen Dank!!!
OK. Habe es commited: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/firmware/LaCrosseGateway.bin
Diesmal nur das bin, nicht den Source in contrib.
Zitat von: HCS am 19 Dezember 2015, 00:00:22
Wie lange dauert denn der Scan bei drei Netzwerken?
Dauer ca. 2 - 3 Sekunden dann habe ich eine Liste von 8 -10 SSIDs , d.h. meine drei plus die die aus der Nachbarschaft kommen.
Zitat von: Wzut am 19 Dezember 2015, 16:52:26
Dauer ca. 2 - 3 Sekunden dann habe ich eine Liste von 8 -10 SSIDs , d.h. meine drei plus die die aus der Nachbarschaft kommen.
Würde sich als weitere Page auf dem WebFrontend anbieten. Muss aber erst mal die PCA301 in den Griff bekommen.
Das Problem mit dem DHT22 ist natürlich ungünstig, ein Feuchtesensor wäre ein netter Bonus zur Grundfunktion gewesen.
Da aber wohl wenig Interesse besteht und es sich auf die schnelle nicht lösen lässt bzw. das Konzept angepasst werden müsste, wäre mein Vorschlag den Sensor zu streichen und dafür die Priorität der Subprozessoranbindung zu erhöhen. Ich würde ihn dann über diese Schnittstelle selbst anbinden :)
Zitat von: Doublefant am 21 Dezember 2015, 12:21:05
Das Problem mit dem DHT22 ist natürlich ungünstig, ein Feuchtesensor wäre ein netter Bonus zur Grundfunktion gewesen.
Da aber wohl wenig Interesse besteht und es sich auf die schnelle nicht lösen lässt bzw. das Konzept angepasst werden müsste, wäre mein Vorschlag den Sensor zu streichen und dafür die Priorität der Subprozessoranbindung zu erhöhen. Ich würde ihn dann über diese Schnittstelle selbst anbinden :)
Der BME280 ist als Grundausstattung vorgesehen, der wird auch auf der Platine (hoffentlich) vorgesehen. Mit dem hat man Druck, Temperature und Feuchte aus einem Chip.
Habe hier ein LGW mit einem BME280 laufen.
Evtl. hat der DHT22 ja noch eine Chance, allerdings dann auf einem AddOn Board.
Sub-Prozessor steht auch noch auf der ToDo, das kann ich auch bei mir brauchen.
Ich muss jetzt aber erst mal PCA301 fertig machen. Generell läuft die Kommunikation mit den Dosen (auch mit dem RFM69) schon mal. Muss aber noch das ganze Pairing / Conf-Speichern, ... usw. machen.
Und die PCA301 macht man nicht mal schnell nebenbei :(
Hi,
hab die 1.11 an einem 12e am laufen. Es ist ein RFM12B und ein BMP085 angeschlossen. Vom 085 empfängt FHEM nichts. Könnte die Status-Seite nicht anzeigen welche Sensoren gefunden wurden. Also die die per Lötkolben angeschlossen wurden ;-).
Zitat von: BlackFlag am 22 Dezember 2015, 23:33:23Vom 085 empfängt FHEM nichts. Könnte die Status-Seite nicht anzeigen welche Sensoren gefunden wurden. Also die die per Lötkolben angeschlossen wurden ;-).
Hast Du ein BreakOut mit PullUps drauf, wenn nicht brauchst Du für SDA und SCL 4,7K PullUps
Im JeeLink device steht in model u.A. alle Hardware, die erkannt wurde
Bei Start wird sie auch auf der Seriellen ausgegeben.
Dass es per Lötkolben angeschlossen wurde ist aber nicht gleichbedeutend mit "es konnte erkannt werden" ;)
ZitatInternals:
...
NAME myJeeLink
...
model [LaCrosseITPlusReader.Gateway.1.11 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + (3=RFM12 f:868300 r:8842) + BMP180 {IP=192.168.31.210}]
....
Zitat von: HCS am 22 Dezember 2015, 23:44:02
Hast Du ein BreakOut mit PullUps drauf, wenn nicht brauchst Du für SDA und SCL 4,7K PullUps
Die 4,7k habe ich nicht drangelötet.
Zitat von: HCS am 22 Dezember 2015, 23:44:02
Im JeeLink device steht in model u.A. alle Hardware, die erkannt wurde
Bei Start wird sie auch auf der Seriellen ausgegeben.
Dass es per Lötkolben angeschlossen wurde ist aber nicht gleichbedeutend mit "es konnte erkannt werden" ;)
LaCrosseITPlusReader.Gateway.1.11 (1=RFM12 f:868300 r:17241) + BMP180 {IP=192.168.1.80}Also hat er den BMP085 als 180 erkannt? Und wie komme ich an die Druckdaten? Ich dachte, FHEM findet dann einen neuen LaCrosse-Sensor?
Da ich meinen Lötkünsten nicht so recht traue, habe ich ja nach einer Übersicht der Sensoren auf der Webseite des LGW gefragt ;-).
Ansonsten auch von mir vielen Dank für die tolle Arbeit an diesem Modul. Ich habe mir nur deswegen 3x RFM69 und einen BMP180 bestellt.
Ach ja, frohe Weihnachten.
Zitat von: BlackFlag am 23 Dezember 2015, 11:30:13
Also hat er den BMP085 als 180 erkannt?
Ja. Das die sind kompatibel, allerdings habe ich es nie mit einem BMP085 getestet.
Zitat von: BlackFlag am 23 Dezember 2015, 11:30:13
Und wie komme ich an die Druckdaten?
set myJeeLink LaCrossePairForSec 60 ignore_batteryDann sollte von autocreate ein LaCrosse device mit der ID 0 angelegt werden, das die Werte bekommt.
Notfalls kann man es auch von Hand anlegen, die ID, mit der das LGW die internen Sensoren sendet, ist immer 0.
Es tut so, als ob es eine Wetterstation (wie z.B. WS 1600) wäre, nur dass es halt keinen Wind kennt, dafür den Druck.
Zitat von: BlackFlag am 23 Dezember 2015, 11:30:13Ich habe mir nur deswegen 3x RFM69 und einen BMP180 bestellt.
Na da habe ich ja was angerichtet. ;D ;D
So, konnte nicht warten bis das NodeMCU_DEVKIT_1.0 aus China kommt und habe mir das Adafruit HUZZAH ESP8266 Breakout beschafft. ;)
Der war in 3 Tagen da und kam noch rechtzeitig zum Heilig Abend. :D
Mit dem UM2102 (ELV) USB<->UART Umsetzter verbunden und
- mit dem nodemcu-flasher die Software Version 1.11 aufgespielt
- neu gestartet und mit dem Accesspoint verbunden
- über die Setup IP Page meine Netzwerkdaten eingegeben (static IP)
Alle Verbindungen funktionieren.
Werde jetzt Zug um Zug die RFM69CW einbinden.
Danke für die tolle Arbeit.
Noch schöne Feiertage
Gruß Billy
Guten Morgen,
kann mir mal bitte jemand auf meine Frage eine Antwort geben ???
Ich check das noch nicht ganz als Anfänger **Sorry**
Wofür brauche ich oder besser wo ist der unterschied zwischen den RFM69CW = RFM69HW = RFM12B ??
Es ist ja auch möglich drei Module zu mischen, wenn ich gleichzeitig Lacrosse Temp868 und IT433 und evtl. HM oder andere 868/433Mhz Sender benutzen möchte, nehme ich dann nur 868 oder auch einen 433Mhz für IT
Ich würde mir die Module dann entsprechend bestellen, habe nur noch keinen Shop gefunden wo ich alles auf einmal bestellen kann
Besten dank vorab für eine Antwort
Gruß Werner
Zitat von: Intruder1956 am 07 Januar 2016, 11:34:54
Guten Morgen,
kann mir mal bitte jemand auf meine Frage eine Antwort geben ???
Ich check das noch nicht ganz als Anfänger **Sorry**
Wofür brauche ich oder besser wo ist der unterschied zwischen den RFM69CW = RFM69HW = RFM12B ??
Es ist ja auch möglich drei Module zu mischen, wenn ich gleichzeitig Lacrosse Temp868 und IT433 und evtl. HM oder andere 868/433Mhz Sender benutzen möchte, nehme ich dann nur 868 oder auch einen 433Mhz für IT
Ich würde mir die Module dann entsprechend bestellen, habe nur noch keinen Shop gefunden wo ich alles auf einmal bestellen kann
Besten dank vorab für eine Antwort
Gruß Werner
Hallo, für HM und FS20 sowie MAX! Benötigst du einen CUL 868, keinen jeelink ..
IT geht meines Wissens auch nur mit einem CUL am besten einen mit 433 Mhz ...
Um mehrere Systeme (hm, fs20, max usw) zu betreiben empfiehlt sich je einen cul einzusetzen
Mobil erstellt daher kurz gehalten
Zitat von: Intruder1956 am 07 Januar 2016, 11:34:54
Wofür brauche ich oder besser wo ist der unterschied zwischen den RFM69CW = RFM69HW = RFM12B ??
RFM69CW ist der Nachfolger vom RFM12B und es ist egal, welchen man verwendet.
RFM69HW ist die in DE nicht zugelassene Variante vom RFM69CW, die mehr Sendeleistung hat.
In DE darf im Bereich 868,0 ... 869,2 mit maximal 25 mW gesendet werden.
Zitat von: Intruder1956 am 07 Januar 2016, 11:34:54
Es ist ja auch möglich drei Module zu mischen, wenn ich gleichzeitig Lacrosse Temp868 und IT433 und evtl. HM oder andere 868/433Mhz Sender benutzen möchte, nehme ich dann nur 868 oder auch einen 433Mhz für IT
Das LGW ist für den Empfang von 868MHz LaCrosse Sensoren (und WS 1600, ..) entwickelt, Liste siehe wiki.
Das IT-Protokoll und HM kann es nicht empfangen und auf 433MHz habe ich keine Ahnung, ob es da Sensoren gibt, die das gleiche Protokoll senden, wie die 868MHz Sensoren.
Wenn Du sicher sein willst, dass Du einen Sensor empfängst, dann sollte es einer aus dieser Liste sein: http://www.fhemwiki.de/wiki/JeeLink#Getestete_iT.2B_Sensoren_incl._Wetterstation_WS_1600
Ups, noice war schneller, aber ich ausführlicher ;)
Da hätte ich auch noch eine Frage:
Ich habe mir als Weihnachtsgeschenk eine WS1600 Wetterstation zugelegt.
Die hat aber eine Baudrate von 8k , die LaCrosse Sensoren die ich habe laufen stabil bei 17k.
Nun schalte ich jetzt alle 30sec zwischen den Baudraten hin und her .... verliere dadurch aber Telegramme der Wetterstation .... schlecht :'(
(Ach so ... Läuft noch auf auf einem originalen Jeelink)
Kann ich auf dem LGW je einen Radio mit 17k und den anderen mit 8k laufen lassen?
Wenn ja wie stelle ich das ein ?
Oder brauche ich dann doch zwei LGW
Hallo HCS und noice,
vom vielen lesen bin ich völlig verwirrt, es steht ja oben Lacrosse :-)
Ich hab natürlich noch einen RPI2 mit entsprechenden CUL´s (Hauptsystem)
Einen RPI ohne CUL habe ich noch über und wollte damit ein wenig mit den ESP8266 basteln.
Jetzt ist mir klar, dass sich dieser Tread nur auf Lacrosse bezieht, steht ja oben
Also brauche ich für meine TX29DTH nur einen ESP8266 und einen RFM69CW.
Sollte ich mal auf PCA301 umsteigen wollen dann benötige ich einen zweiten RFM69CW wegen dem Sketch.
Mich hatte wohl das Foto vom Layout im Beitrag 180 von Omega-5 verwirrt, weil da drei verschiedene Module platziert sind.
Ich hoffe jetzt richtig verstanden zu haben.
Danke
Gruß Werner
Zitat von: AxelSchweiss am 07 Januar 2016, 12:57:01
Ich habe mir als Weihnachtsgeschenk eine WS1600 Wetterstation zugelegt.
So ein Leben möchte ich auf führen können ;D ;D ;D
Zitat von: AxelSchweiss am 07 Januar 2016, 12:57:01
Kann ich auf dem LGW je einen Radio mit 17k und den anderen mit 8k laufen lassen?
Wenn ja wie stelle ich das ein ?
Das LGW unterstützt bis zu drei RFM69CW und jeder kann eine andere data rate verarbeiten.
Gesteuert wird das über die initCommands im JeeLink device.
Wenn man nichts angibt, dann macht das erste 17241, das zweite 9579 und das dritte 8842
Beispiel initCommands, wenn man zwei Radios drauf hat und 17241 und 8842 will
17241#1r 8842#2r v
Beispiel initCommands, wenn man zwei Radios drauf hat und 20 Sekunden 17241 toggle 9579 plus 8842 permanent will
3#1m 20#1t 8842#2r v
Ich habe bei mir drei Radios drauf, die machen:
#1: 17241 toggle 9579 für die LaCrosse Sensoren
#2: 8842 für die Wetterstation
#3: PCA301
Zusammanfassung: man kann die drei Radios machen lassen, was man will (im Rahmen der Möglichkeiten natürlich)
Es kann auch jedes für sich auf eine passende Frequenz gesetz werden (Beispiel 868310#2f)
Der Aufbau ist: <Wert>#<Radio-Nummer><command>
Commands:
m t: toggle-Steuerung
r: data rate
f: frequenz
Plus dann noch einige, z.B. h falls man einen BMP180 drauf hat, um die Höhe über NN zu definieren, dass man einen normalisierten Luftdruck bekommt.
Wenn sich jemand bereit erklärt, das mal ins wiki zu übernehmen, erläutere ich gerne noch die restlichen commands, die es gibt ;)
Zitat von: Intruder1956 am 07 Januar 2016, 13:08:04
Also brauche ich für meine TX29DTH nur einen ESP8266 und einen RFM69CW.
So ist es
Zitat von: Intruder1956 am 07 Januar 2016, 13:08:04
Sollte ich mal auf PCA301 umsteigen wollen dann benötige ich einen zweiten RFM69CW wegen dem Sketch.
So ist es. Also einen zweiten RFM69CW an dem bereits vorhandenen ESP8266
Und wie gerade AxelSchweiss erläutert, wenn man sich noch eine WS 1600 schenkt, dann macht dafür ein eigener RFM69CW Sinn.
Wenn Du ein LGW aufbaust (in einem anderen Thread entsteht gerade ein Platine dafür, powerd by PeMue) kannst Du bis zu drei RFM69CW draufpacken.
Das kann man gleich tun oder später bei Bedarf.
Super .. Danke
Zitat von: HCS am 07 Januar 2016, 13:19:19
So ein Leben möchte ich auf führen können ;D ;D ;D
Zitat von: HCS am 07 Januar 2016, 13:19:19
#2: 8842 für die Wetterstation
Machst du ja ... ;)
Zitat von: HCS am 07 Januar 2016, 13:19:19
#3: PCA301
Funktioniert das schon? ... Steckdose habe ich schon mal vorsichtshalber hier liegen ;D
Wiki ... hmm ... ich schaus mir mal an wie man das macht .... dann kann ich das ja eintragen
PCA301 funktioniert bei mir generell schon so als, hmm, naja, PreAlpha
Das LGW kann mit den Dose sprechen, pairing funktioniert, Abfragen und Schalten aus FHEM heraus mit dem (ungeänderten) PCA301 Modul auch. Polling läuft auch.
Noch etwas Abrundung und Probebetrieb und ein paar Problemchen mit dem Senden über den RFM69 und dann denke ich, dass ich es in (alle Angaben wie immer ohne Gewähr) evtl. ein bis zwei Wochen als Beta veröffentlichen kann.
Ich analysiere auch gerade noch das "Frequenz-Thema", das es im PCA301-Sketch ja auch gibt. Ich kann mir einfach noch nicht so recht vorstellen, dass manche RFMs so weit mit der Frequenz daneben liegen, wie man sie verstellen muss. Mir fehlt nur etwas wirklich genaues zum Messen ...
Zitat von: HCS am 07 Januar 2016, 13:40:33
wie man sie verstellen muss. Mir fehlt nur etwas wirklich genaues zum Messen ...
Ein SDR mit RTL2832U-Chip und Wasserfalldiagramm reicht nicht ?
Zitat von: AxelSchweiss am 07 Januar 2016, 13:56:03
Ein SDR mit RTL2832U-Chip und Wasserfalldiagramm reicht nicht ?
Der Focus lag auf "wirklich genau" aber evtl. könnte ich ein SDR mit einem lokalen Radiosender kalibrieren, dann könnte es passen.
Zu blöd, dass mir der Rechner, auf dem es war, gestorben ist ...
Muss mal wieder installieren. Zumindest den RTL2832U habe ich noch :)
Hallo,
wie Geil ist das denn, möchte kurz von meinem Erfolgserlebnis berichten und Danke sagen.
Ich habe hier mitgelesen und gedacht OK das baue ich mal nach.
Habe mir vorgestern zwei ESP und drei RFM69 bestellt.
Heute geliefert worden.
Vor einer ca. einer Stunde den ESP mit dem https://github.com/nodemcu/nodemcu-flasher/tree/master/Win32/Release (https://github.com/nodemcu/nodemcu-flasher/tree/master/Win32/Release) auf WIN7Prof. programmiert auf 1.11, Wifi eingestellt.
Danach hab ich die sechs Kabel an dem RFM69 angebraten und mit dem ESP auf dem Steckboard verbunden.
Meinen noch konfigurierten vorherigen Raspi B+ angeschlossen und den ESP als Device in Fhem angelegt.
Ich konnte gar nicht so schnell gucken wie die alten Temperaturen von den ja noch vorhandenen Lacrosse TX29DTH aktualisiert waren ohne das IODevice zu ändern.
Dann habe ich gesehen das dann auch noch Automatisch ein KeyValueProtocol angelegt wurde
Es läuft sofort und ohne Probleme
Haben noch einen ESP und zwei RFM69 da liegen die werde ich dann auch noch verbauen ;D ;D
Danke
schönen Abend und ein tolles Rest Wochenende
Gruß Werner aus dem Westerwald
PS. Antenne habe ich einfach ein Stück Draht genommen, weiß nicht mal wie lang es ist ;D ;D
PPS. Ich habe diese ESP betellt http://www.ebay.de/itm/272088034431?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT (http://www.ebay.de/itm/272088034431?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT)
Zitat von: Intruder1956 am 09 Januar 2016, 17:22:52... möchte kurz von meinem Erfolgserlebnis berichten ...
Ja, so muss es sein: löten - flashen - empfangen - freuen ;D ;D
Jetzt kannst Du Dir noch einen BMP180 oder BME 280 dran packen um das Erlebnis zu steigern ;D
Danke für die Rückmeldung, "es funktioniert" - Meldungen liest man zwischen den Problemen auch gerne mal.
Nachtrag: wenn Du das Steckbrett nicht in einer Zigarrenkiste als Endlösung planst, dann beobachte mal den LGW-Platinen-Thread.
Hallo HCS,
den beobachte ich schon und warte nur darauf endlich zwei Platinen bestellen zu können 8) 8)
schönen Abend noch
Gruß Werner
Zitat von: HCS am 09 Januar 2016, 19:56:03
als Endlösung planst
streiche
Endlösung und benutze
endgültige Lösung :)
Ich komme leider nur teilweise voran.
Das LGW ist zusammengebaut, läuft und wird auch von FHEM erkannt (ich habe 2 RFM69CW (jetzt die 868MHz-Version) und einen BME280 angeschlossen).
Definiert habe ich es mit
define LaCrosseGateway JeeLink 192.168.0.28:81
Ein List des LGW:
Internals:
CFGFN
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 100
LaCrosseGateway_MSGCNT 131
LaCrosseGateway_TIME 2016-01-10 17:33:43
NAME LaCrosseGateway
NR 49876
PARTIAL
RAWMSG OK 9 15 1 4 33 80
STATE Initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.Gateway.1.11 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + 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-10 17:31:01 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
room LaCrosse
KeyValueProtocol wurde auch angelegt.
Über die serielle Schnittstelle kann ich auch sehen, dass wohl Daten ankommen...
Access point running: LaCrosseGateway_16446580
Searching RFMs and BMP
First RFM found: RFM69
Second RFM found: RFM69
BME280 found
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.11 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + BME280 {IP=192.168.222.1}]
Setup completely done
OK WS 0 4 4 208 40 255 255 255 255 255 255 255 255 0 3 212
OK 9 19 1 4 182 106
OK VALUES LGW 16446580 UpTimeSeconds=18,UpTimeText=0Tg. 0Std. 0Min. 18Sek. ,WIFI=WLAN4Me,MacAddress=18:FE:34:FA:F4:74,ChipID=16446580,ReceivedFrames=1,FramesPerMinute=1,RSSI=-51
OK 9 35 1 4 162 106
OK 9 15 1 4 32 80
OK 9 18 1 4 156 64
OK 9 27 1 4 146 106
OK 9 19 1 4 182 106
OK WS 0 4 4 207 40 255 255 255 255 255 255 255 255 0 3 212
OK VALUES LGW 16446580 UpTimeSeconds=28,UpTimeText=0Tg. 0Std. 0Min. 28Sek. ,WIFI=WLAN4Me,MacAddress=18:FE:34:FA:F4:74,ChipID=16446580,ReceivedFrames=6,FramesPerMinute=6,RSSI=-51
OK 9 27 130 4 143 125
OK 9 15 1 4 32 80
OK 9 18 1 4 156 64
OK 9 35 130 4 163 125
OK 9 19 1 4 182 106
OK 9 15 1 4 32 80
OK 9 18 1 4 156 64
OK 9 35 1 4 162 106
OK WS 0 4 4 207 40 255 255 255 255 255 255 255 255 0 3 212
OK VALUES LGW 16446580 UpTimeSeconds=38,UpTimeText=0Tg. 0Std. 0Min. 38Sek. ,WIFI=WLAN4Me,MacAddress=18:FE:34:FA:F4:74,ChipID=16446580,ReceivedFrames=14,FramesPerMinute=14,RSSI=-51
OK 9 19 1 4 182 106
OK 9 27 130 4 143 125
OK 9 15 1 4 32 80
OK 9 18 1 4 156 64
OK WS 0 4 4 208 40 255 255 255 255 255 255 255 255 0 3 212
OK VALUES LGW 16446580 UpTimeSeconds=48,UpTimeText=0Tg. 0Std. 0Min. 48Sek. ,WIFI=WLAN4Me,MacAddress=18:FE:34:FA:F4:74,ChipID=16446580,ReceivedFrames=18,FramesPerMinute=18,RSSI=-52
OK 9 19 1 4 182 106
OK 9 35 130 4 163 125
OK 9 15 1 4 32 80
OK 9 18 1 4 156 64
OK 9 35 1 4 162 106
OK WS 0 4 4 207 40 255 255 255 255 255 255 255 255 0 3 212
OK VALUES LGW 16446580 UpTimeSeconds=58,UpTimeText=0Tg. 0Std. 0Min. 58Sek. ,WIFI=WLAN4Me,MacAddress=18:FE:34:FA:F4:74,ChipID=16446580,ReceivedFrames=23,FramesPerMinute=23,RSSI=-52
OK 9 19 1 4 182 106
OK 9 15 1 4 32 80
OK 9 18 1 4 156 64
OK 9 19 1 4 182 106
OK 9 35 130 4 163 125
OK WS 0 4 4 207 40 255 255 255 255 255 255 255 255 0 3 212
OK VALUES LGW 16446580 UpTimeSeconds=68,UpTimeText=0Tg. 0Std. 1Min. 8Sek. ,WIFI=WLAN4Me,MacAddress=18:FE:34:FA:F4:74,ChipID=16446580,ReceivedFrames=28,FramesPerMinute=28,RSSI=-52
Es gelingt mir allerdings nicht, in FHEM ein Gerät zu sehen, dass ich weiter ausbauen könnte.
Ein ,,set LaCrosseGateway LaCrossePairForSec 60 ignore_battery" bringt mir kein neues Gerät (und zumindest der BME280 ist neu). Meine anderen LaCrosse-Sensoren hören derzeit noch auf einen normalen JeeLink, daher kann ich sie vermutlich z.Zt. nicht sehen.
LG
Holger
Das Problem hatte ich mit meiner WS1600 Wetterstation auch.
Trotz : define autocreate autocreate
(Schau mal ob das bei dir fehlt)
Ich habe mir dann wie folgt beholfen:
Im Logfile steht irgendwann etwas in dem Tenor:
JeeLink1: Unknown code XX , help me!
Wobei XX die ID der Wetterstation war.
Dann habe ich das Config eben von Hand eingetragen.
define Wetterstation LaCrosse XX
attr Wetterstation IODev JeeLink1
Dann war alles gut :)
EDIT:
Ich sehe gerade, irgendeine Wetterstation hast du auch "OK WS ..... ". Die 4 ist glaube ich die ID (in HEX ?)
Zitat von: Omega am 10 Januar 2016, 18:03:19
Access point running: LaCrosseGateway_16446580
Das LGW hat sich nicht mit dem wlan verbunden. Sicher das die IP-Konfiguration im LGW-Setup stimmt?
Da hatte ich das LGW an meine Arduino-IDE angeschlossen, um die serielle Schnittstelle verwenden zu können - vielleicht daher.
Ich habe eben gleich noch mal meine setup-Seite aufgerufen (192.168.0.28/setup). Komme drauf und es erfolgen auch Updates. Also bin ich in meinem normalen WLAN.
Löse ich in FHEM ein "set LaCrosseGateway reset" aus, erfolgt auch ein erneutes open. Die Verbindung ist also da.
OK, kannst Du nochmal erneut einen list von JeeLink device machen und anhängen?
:) gerne
Internals:
CFGFN
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 100
LaCrosseGateway_MSGCNT 3647
LaCrosseGateway_TIME 2016-01-10 19:39:46
NAME LaCrosseGateway
NR 49876
PARTIAL
RAWMSG OK 9 18 1 4 157 62
STATE Initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.Gateway.1.11 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + 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-10 18:30:41 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
room LaCrosse
Nachtrag: autocreate ist schon immer aktiv bei mir, hat auch immer funktioniert
So, ich bin weitergekommen.
Das LGW habe ich mal auf verbose 5 gesetzt, da habe ich dann auch die aktuellen Datensätze sehen können ohne eine serielle Schnittstelle bemühen zu müssen.
Nachdem ich etwas zum Aufbau des CaCrosse-Protokolls gefunden habe, habe ich zumindest den 1. Teil der Datensätze verstanden
(zumindest OK 9 id), wobei die ID hier dezimal ist. Aufgeführt werden alle meine Sensoren, die aber bereits definiert sind und dem bisherigen JeeLink-Device zugeordnet sind (wie ich auch schon vermutet hatte).
Der Datensatz, beginnend mit WS, ist der BME. Der Satzaufbau beginnt mit WS id 4. Bei mir war das die id 00. Die 4 steht für den Sensortype.
Jetzt händisch zugewiesen:
define LGW_Wetterstation LaCrosse 00
attr LGW_Wetterstation IODev LaCrosseGateway
und nach kurzer Zeit kommen die Daten.
Jetzt fehlt mir noch die Höhenkorrektur zum Druck - irgendwo habe ich das schon gesehen, kann es aber im Moment nicht finden.
Aufgefallen ist mir noch, dass ein definiertes stateFormat überschrieben wird
Definiert hatte ich
attr LGW_Wetterstation T: temperature H: humidity D: dewpoint P: pressure
(dewpoint wird bei mir automatisch angelegt).
Scheinbar wird die Anweisung auch akzeptiert, aber nach erneutem Aufruf von LGW_Wetterstation ist das wieder weg (den save habe ich nicht vergessen).
Internals:
CFGFN
DEF 00
IODev LaCrosseGateway
LASTInputDev LaCrosseGateway
LaCrosseGateway_MSGCNT 137
LaCrosseGateway_RAWMSG OK WS 0 4 4 202 42 255 255 255 255 255 255 255 255 0 3 212
LaCrosseGateway_TIME 2016-01-10 21:27:40
LaCrosse_lastRcv 2016-01-10 21:27:40
MSGCNT 137
NAME LGW_Wetterstation
NR 52006
STATE T: 22.6 H: 42 D: 9.0
TYPE LaCrosse
addr 00
battery_new 0
bufferedH 42
bufferedT 22.6
corr1 0
corr2 0
previousH 42
previousT 22.6
sensorType 4=LaCrosseGateway
Readings:
2016-01-10 21:27:40 battery ok
2016-01-10 21:27:40 dewpoint 9.0
2016-01-10 21:27:40 error 0
2016-01-10 21:27:40 humidity 42
2016-01-10 21:27:40 pressure 980
2016-01-10 21:27:40 state T: 22.6 H: 42
2016-01-10 21:27:40 temperature 22.6
Attributes:
IODev LaCrosseGateway
room LaCrosse
stateFormat T: temperature H: humidity D: dewpoint P: pressure
[/state]
Die Höhenkorrektur setzt man mit dem command h in den initCommands.
Beispiel: 220h legt 220m über NN fest.
Der interne Sensor des LGW ist immer ID 0 und tut so, als ob er eine Wetterstation wäre.
Zitatattr LGW_Wetterstation T: temperature H: humidity D: dewpoint P: pressure
So geht das auch nicht, sondern so:
attr LGW_Wetterstation
stateFormat T: temperature H: humidity D: dewpoint P: pressure
Zitat
So geht das auch nicht, sondern so:
attr LGW_Wetterstation stateFormat T: temperature H: humidity D: dewpoint P: pressure
Ja, habe ich aber nur hier falsch eingetragen. In der Oberfläche von FHEM habe ich es korrekt eingetragen. Du kannst es auch in dem list meines letzten Beitrages sehen - und das P in STATE nicht auftaucht.
Die initCommands beziehen sich doch auf die Radios <Wert>#<Radio-Nummer><command> - also 220#<Radio-Nummer>h
Welches Radio ist der BME280?
Kommt zwischen <Radio-Nummer><command> kein Leerzeichen?
Zitat von: Omega am 10 Januar 2016, 22:39:40
Ja, habe ich aber nur hier falsch eingetragen. In der Oberfläche von FHEM habe ich es korrekt eingetragen. Du kannst es auch in dem list meines letzten Beitrages sehen - und das P in STATE nicht auftaucht.
Das funktioniert bei mir. Habe Dein Stateformat bei mir gestetzt. Passt, bleibt erhalten, alles OK.
Zitat von: Omega am 10 Januar 2016, 22:39:40
Die initCommands beziehen sich doch auf die Radios <Wert>#<Radio-Nummer><command> - also 220#<Radio-Nummer>h
Nur manche, nicht alle. "h" ist z.B. eins, das sich nicht auf ein Radio bezieht, weil der BME 280 nichts mit einem Radio zu tun hat.
220h ist schon richtig.
Zitat von: Omega am 10 Januar 2016, 22:39:40
Welches Radio ist der BME280?
Keins, er wird ja nicht auf 868MHz empfangen und funktioniert sogar, wenn man kein Radio angeschlossen hat.
Zitat von: Omega am 10 Januar 2016, 22:39:40
Kommt zwischen <Radio-Nummer><command> kein Leerzeichen?
Nein, definitiv nicht.
Beispiel Frequenz und Höhe über NN
attr myJeeLink initCommands 220h 868295#1f 868310#2fHier als Beispiel meine aktuellen InitCommands:
868295#1f 3#1m 20#1t 2,868950,60i 8842#3r 220h 0a vRadio 1 auf 868295 MHz und Toggle 9K/17K mit 20 Sekunden
Radio 2 für PCA301 initialisiert (geht nur bei mir, ist noch nicht in der 1.11 enthalten)
Radio 3 macht 8842 kbps für die WS 1600
Höhe 220m über NN
Activity LED aus
v am Ende ruft die neu gesetzen Daten vom LGW ab, damit sie in FHEM (Model) aktualisiert werden.
Danke für deine Geduld (du wirst noch mehr davon brauchen ;) )
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.
Weitere Auffälligkeiten:
Im Log habe ich folgendes gefunden:
2016.01.11 10:27:29 3: KeyValueProtocol_LGW_16446580: unknown IODev specified
2016.01.11 10:27:33 1: configfile: KeyValueProtocol_LGW_16446580: unknown IODev specified
2016.01.11 10:27:40 2: Error messages while initializing FHEM: configfile: KeyValueProtocol_LGW_16446580: unknown IODev specified
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.
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.
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 ;D )
Zitat von: Omega am 11 Januar 2016, 11:24:14
Danke für deine Geduld (du wirst noch mehr davon brauchen ;) )
Habe mir zur Sicherheit noch eine Schachtel Geduld gekauft, bekommen wir schon hin ;)
Zitat von: Omega am 11 Januar 2016, 11:24:14
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.
Zitat von: Omega am 11 Januar 2016, 11:24:14Im 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.
Zitat von: Omega am 11 Januar 2016, 11:24:14Im 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.
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 ;D )) 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
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 8) 8)
Zitat von: Omega am 11 Januar 2016, 12:48:09
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 ;D )) hat sich mit deiner Antwort überschnitten.
Der ist mir entgangen, egal.
Zitat von: Omega am 11 Januar 2016, 12:48:09Dann ist ja momentan alles in Butter - danke noch mal
Prima.
Zitat von: Omega am 11 Januar 2016, 12:48:09und - das mit dem PCA301finde ich guuut - ich habe doch schon extra ein paar gekauft zum Üben 8) 8)
Mehr als in die Steckdose stecken kann man aktuell halt nicht üben ... ;D ;D ;D
Aber ich arbeite an dem Thema. Wenn ich geahnt hätte ....
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 ?
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
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
Zitat von: Omega am 15 Januar 2016, 10:59:05
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.
Zitat von: Wzut am 12 Januar 2016, 21:17:33
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
Zitat
Zusammenfassung: timeout 120,60 macht automatisch das, womit Du es manuell geregelt hast.
Super :D :D . Ich hatte schon befürchtet, mir einen Watchdog definieren zu müssen
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 :D
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 ;D
@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
Zitat von: HCS am 16 Januar 2016, 23:17:53
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. ;)
ZitatAuto-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. ;D
Gruß Friedrich
Zitat von: Omega-5 am 17 Januar 2016, 09:14:33
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.
< 5ms >< 50ms >
RTS (RST) 1 ----- ------------------------------------
0 |-----|
DTR (GPIO0) 1 ----------- ---------------
0 |------------------|
GPIO0 = low: flash
GPIO0 = high: run
Reset bei steigender Flanke an RST oder ENEN, RST und GPIO0 mit 10k Pullup und
RTS über 470 Ohm -> EN
DTR über 470 Ohm -> GPIO0
Zitat von: Omega-5 am 17 Januar 2016, 09:14:33
... 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 ... :)
Zitat von: Omega am 11 Januar 2016, 12:48:09
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 8) 8)
Zitat von: AxelSchweiss am 07 Januar 2016, 13:27:26
Zitat von: HCS am 07 Januar 2016, 13:19:19
#3: PCA301
Funktioniert das schon? ... Steckdose habe ich schon mal vorsichtshalber hier liegen ;D
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".
<RadioNr>,<Frequenz>,<Poll-Intervall>iBeispiel: 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:
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" commandEdit: Anhang gelöscht, siehe weiter unten
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:
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.
Zitat von: HCS am 16 Januar 2016, 23:17:53
NanoLGW
Das alles in das Gehäuse zu bekommen und drin zu verdrahten ist aber nichts für schwache Nerven ;D
@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
Zitat von: Omega am 17 Januar 2016, 15:39:53Zuerst 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.
Zitat von: Omega am 17 Januar 2016, 15:39:53
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.
Zitat von: Omega am 17 Januar 2016, 15:39:53
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.
Zitat von: PeMue am 17 Januar 2016, 15:49:17
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. ;D ;D
Evtl. bekommt man ja auch zwei rein und verzichtet komplett auf lokale Sensoren.
Zitat von: PeMue am 17 Januar 2016, 15:49:17
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.
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
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).
Zitat von: HCS am 17 Januar 2016, 10:50:21
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 (https://github.com/igrr/esptool-ck) Readme.md "Supported boards".
Gruß Friedrich
Zitat von: Omega am 17 Januar 2016, 18:14:04
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.
Zitat von: Omega-5 am 17 Januar 2016, 18:19:20
... 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
;D ;D 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
Zitat von: HCS am 17 Januar 2016, 22:14:17
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 vStatuszeile:
[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 :-)
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
Zitat von: Billy am 18 Januar 2016, 14:31:30
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 ;D
Zitat von: Billy am 18 Januar 2016, 14:31:30
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.
Das LGW ist doch zunächst mal losgelöst von einer FHEM-Installation. Erst über ein
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).
Zitat von: Omega am 18 Januar 2016, 15:40:12
Das LGW ist doch zunächst mal losgelöst von einer FHEM-Installation.
Richtig.
Zitat von: Omega am 18 Januar 2016, 15:40:12
Erst über ein
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.
Zitat von: Omega am 18 Januar 2016, 15:40:12
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, ... ;D
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 ...
Zitat von: HCS am 18 Januar 2016, 15:16:48
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.
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.
ZitatKommt, wenn Du die Dose lokal schaltest, der Lampenumschlag in FHEM schnell oder auch verzögert?
Ja auch dann!
Zitat
Zwei angekoppelte FHEMs in Verbindung mit PCA301 habe ich aber noch nicht ausprobiert. Sollte aber auch gehen, zumindest theoretisch, wie immer halt, ... ;D
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.
Zitat von: HCS am 18 Januar 2016, 15:16:48
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.
Zitat von: Billy am 18 Januar 2016, 16:19:46
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.
Ich glaube, dass (warum auch immer) die HF-Kommunikation mit dieser einen PCA301 gerade so halbwegs funktioniert.
Das ist aber nicht die, die am weitesten entfernt ist?Zitat von: Billy am 18 Januar 2016, 16:47:09
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!
Super. Kannst Du so etwas mitteilen, bevor oder nachdem ich einen Beitrag geschrieben habe anstatt mitten drin? ;D ;D ;D
Dann hat sich das Durchgestrichene oben erledigt.
Zitat von: Billy am 18 Januar 2016, 16:47:09
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.
Das entspricht nicht meinem Plan. Wenn etwas anderes die Dose schaltet, dann sollte das LGW eigentlich die Antwort der Dose hören und es an sein FHEM sofort übermitteln.
Das muss ich bei mir mal nachstellen. Habe ja in letzter Zeit zusehens mehr JeeLinks, die nichts mehr zu tun haben ... ;D
Allerdings ist es wohl auch (außer bei Tests) kein use case, dass man LGW und JeeLink-Sketch gleichzeitig betreibt.
Aber eine echte Basisstation, und ich vermute, dass es damit sich dann auch so verhält.
Zitat von: Omega am 18 Januar 2016, 16:36:41
Gleich der 1. Test war erfolgreich. Ich kann die Steckdose von beiden Seiten schalten, der jeweilige Schaltzustand wird auf auf beiden Seiten korrekt dargestellt.
Na also 8)
Zitat von: HCS am 18 Januar 2016, 16:58:07
Super. Kannst Du so etwas mitteilen, bevor oder nachdem ich einen Beitrag geschrieben habe anstatt mitten drin? ;D ;D ;D
Dann hat sich das Durchgestrichene oben erledigt.
Mea culpa, mea maxima culpa ;D ;D ;D hatte nicht erwartet dass das mit der Frequenzänderung so schnell die Lösung bringt.
ZitatDas entspricht nicht meinem Plan. Wenn etwas anderes die Dose schaltet, dann sollte das LGW eigentlich die Antwort der Dose hören und es an sein FHEM sofort übermitteln.
Das muss ich bei mir mal nachstellen. Habe ja in letzter Zeit zusehens mehr JeeLinks, die nichts mehr zu tun haben ... ;D
Allerdings ist es wohl auch (außer bei Tests) kein use case, dass man LGW und JeeLink-Sketch gleichzeitig betreibt.
Aber eine echte Basisstation, und ich vermute, dass es damit sich dann auch so verhält.
Ja ich könnte mir vorstellen, dass das für die Besitzer einer Basisstation von Bedeutung ist.
Falls sich die Basisstation im Zusammenspiel mit dem LGW wie ein Jeelink verhält.
Billy
Zitat von: Billy am 18 Januar 2016, 17:24:31
Falls sich die Basisstation im Zusammenspiel mit dem LGW wie ein Jeelink verhält.
@All: Ist hier jemand dabei, der eine Basisstation hat?
Hallo,
als erstes ein großes Dankeschön an HCS, für die Entwicklung des LaCrosseGateway.
Ich habe mir nun alle benötigten Teile 2xRadios und einen BME280 auf Breakout Board besorgt und alles zusammengesteckt.
Nun ist der stand folgender:
- Lacrosse Temperatursensoren liefern die richtigen Daten
- PCA301 Dosen lassen sich schalten aber ich bekomme momentan noch keine "Verbrauchswerte" (consumption, consumptionTotal, power) angezeigt
- Kann es sein, dass beim BME280 die readings temperature und humidity vertauscht sind?
[LaCrosseITPlusReader.Gateway.1.12 (1=RFM69 f:868295 t:20~3) + (2=RFM69 f:868990 r:6631) + BME280 {IP=192.168.x.x}]
Vielen Dank
Zitat von: woodgee am 20 Januar 2016, 14:37:50
- PCA301 Dosen lassen sich schalten aber ich bekomme momentan noch keine "Verbrauchswerte" (consumption, consumptionTotal, power) angezeigt
Das dauert mit den Werten eine Weile je nach dem angehängten Verbraucher.
Billy
Zitat von: HCS am 18 Januar 2016, 17:54:50
@All: Ist hier jemand dabei, der eine Basisstation hat?
Guten Morgen und
JA! :)
Allerdings habe ich bis jetzt die halbe Nacht hier alles erstmal gelesen um die Historie zu bewältigen und auf den aktuellen Stand zu kommen.
Wir hatten es ja im anderen Thread von der LaCrosse Relay Funktion und nun hab ich rund um die Welt Bauteile bestellt um das hier ebenfalls zu bauen. Hoffen wir mal das die Chinesen und Co ganz ganz schnell liefern, damit das Kribbeln in den Fingern nachlässt.
Wenn ich dann mal meine Bauteile bekommen und zusammen gelötet habe, dann hätte ich auch schon einen Enhancement Request bzgl. PCA301. Sofern ich es nicht übersehen habe liegt die Obergrenze der Geräte zur Zeit bei 16? Ich betreibe hier im Moment schon gute 30 Stück davon ... wenn man da also noch ein wenig nach oben (50) optimieren könnte? ;D
Die Anzahl der PCA301 Dosen ist allerdings auch der Grund warum ich die Basiseinheit z.Zt. nicht aktiv nutzen kann. Wenn es da was zu testen gibt bin ich natürlich sofort dabei! Zuerst muss aber erstmal die HW an Land kommen..
PS: Mein lieber Herr Gesangsverein, da hast du aber echt was los getreten 8)
PPS: Und das nanoGateway für PCA301 wäre natürlich auch interessant, das wäre ja ein super 'Relay' Ersatz, wobei es diese Option beim PCA301 Sketch noch nie gegeben hat :D
Nachtrag: Dabei fällt mir grad ein das ich noch eine zweite Wetterstation hier hab und zwar ebenfalls von Conrad die Profi Wetterstation slim (https://www.conrad.de/de/profi-wetterstation-slim-651345.html). Nachdem ich nach langem probieren irgendwann herausgefunden hatte das es von diesem optisch identischem Modell zwei technisch unterschiedliche Varianten gibt (TE738 USB nur zum laden /TE838 USB auch zum auslesen von Wetterdaten) frage ich mich natürlich nun ob man die externen Sensoren (Funk) für Regenmessung, Wind, Temperatur und Luftfeuchte mit dem LCG abgreifen kann. Hat hier wer schon Erfahrungen damit gemacht?
@HCS
Wo finde ich die LaCrosseGateway V1.12 für die PCA301?
Zitat von: oli82 am 21 Januar 2016, 09:13:43
Wo finde ich die LaCrosseGateway V1.12 für die PCA301?
Momentan hier: http://forum.fhem.de/index.php/topic,43672.msg393745.html#msg393745
Zitat von: HCS am 21 Januar 2016, 09:21:27
Momentan hier: http://forum.fhem.de/index.php/topic,43672.msg393745.html#msg393745
Alles klar. Danke.
Update hat nicht geklappt. daher die Frage.
Die Datei war wohl beim Download beschädigt worden.
Was mir bisher aufgefallen ist:
Im Log finde ich manchmal solche Hilferufe,
2016.01.18 22:23:18 3: LaCrosseGateway: Unknown code OK LS 7 0 9 121 2 199 85, help me!
2016.01.19 16:39:25 3: LaCrosseGateway: Unknown code OK CC 85 , help me!
2016.01.20 21:07:34 3: LaCrosseGateway: Unknown code OK LS 5 0 11 219 2 195 80, help me!
2016.01.21 03:27:07 3: LaCrosseGateway: Unknown code OK LS 15 0 15 35 6 24 82, help me!
mit denen ich nichts anfangen kann.
Steckdosen werden anscheinend – sobald erkannt – automatisch eingebunden. Im Log habe ich u.a. folgendes gefunden:
2016.01.21 07:48:13 3: PCA301 Unknown device 2ADE5B, please define it
2016.01.21 07:48:13 2: autocreate: define PCA301_2ADE5B PCA301 2ADE5B F8
2016.01.21 07:48:13 3: PCA301_2ADE5B: I/O device is LaCrosseGateway
2016.01.21 07:48:13 2: autocreate: define FileLog_PCA301_2ADE5B FileLog ./log/PCA301_2ADE5B-%Y.log PCA301_2ADE5B
Die Steckdose kenne ich nicht. Mittlerweile habe ich 2 von diesen Phantomdosen (bzw. 4, da das LGW ja auf 2 FHEM-Instanzen läuft). Auf der Setup-Seite sind diese Dosen nicht definiert (unter Plugs).
Besteht die Möglichkeit, über ein Attribut einzustellen, wann die Funktion ,,autocreate" aktive sein soll und wann nicht?
Die Version des LGW sehe ich über <ip>/setup. Schön wäre es, wenn es in der FHEM-Anzeige auch ein Reading oder Internal dazu geben könnte.
LG
Holger
Zitat von: Omega am 21 Januar 2016, 09:46:07
Im Log finde ich manchmal solche Hilferufe ...
Habe ich auch einige wenige.
Das Problem ist, dass es bei tausenden von empfangenen HF-Müll-Paketen pro Stunde manchmal vorkommt, dass der Müll eine korrekte Prüfsumme ergbit und somit vom Sketch akzeptiert wird. Beim LaCrosse Modul haben wir das dadurch gelöst, dass wir nur dann von einem neuen Sensor ausgehen, wenn er innerhalb eine bestimmten Zeit (z.B. 120 Sekunden) zwei mal empfangen wurde. Dadurch ist die Wahrscheinlichkeit, dass so etwas angelegt oder "hilfe-geloggt" wird, fast bei Null.
Siehe Deine Beispieldaten:
2016.01.18 22:23:18 3: LaCrosseGateway: Unknown code OK LS 7 0 9 121 2 199 85, help me!
2016.01.20 21:07:34 3: LaCrosseGateway: Unknown code OK LS 5 0 11 219 2 195 80, help me!
2016.01.21 03:27:07 3: LaCrosseGateway: Unknown code OK LS 15 0 15 35 6 24 82, help me!
Da hat das LevelSender Modul Pakete akzeptiert, die ein LeveSender mit ID 7, 5 und 15 wären, und das im Abstand von einem Tag.
Das oben beschriebene Verfahren hätte auch diesen Müll weggefiltert.
In LaCrosse habe ich es eingebaut, für LevelSender kann ich das noch einbauen, für das PCA301 Modul bin ich nicht der maintainer.
Zitat von: Omega am 21 Januar 2016, 09:46:07
Besteht die Möglichkeit, über ein Attribut einzustellen, wann die Funktion ,,autocreate" aktive sein soll und wann nicht?
Die Version des LGW sehe ich über <ip>/setup. Schön wäre es, wenn es in der FHEM-Anzeige auch ein Reading oder Internal dazu geben könnte.
LG
Holger
Zitat von: Omega am 21 Januar 2016, 09:46:07Besteht die Möglichkeit, über ein Attribut einzustellen, wann die Funktion ,,autocreate" aktive sein soll und wann nicht?
Ich glaube im autocreate Modul selbst schon.
Zitat von: Omega am 21 Januar 2016, 09:46:07
Die Version des LGW sehe ich über <ip>/setup. Schön wäre es, wenn es in der FHEM-Anzeige auch ein Reading oder Internal dazu geben könnte.
Den Wunsch könnte ich dadurch mit erfüllen, indem ich es im KVP (da wo auch RSSI, FramesPerMinute, usw. übermittelt werden) mitschicke.
Zitat von: waschbaerbauch am 21 Januar 2016, 04:30:50Sofern ich es nicht übersehen habe liegt die Obergrenze der Geräte zur Zeit bei 16? Ich betreibe hier im Moment schon gute 30 Stück davon ... wenn man da also noch ein wenig nach oben (50) optimieren könnte? ;D
Auch Du großer Schreck, bist Du sicher dass du 30 davon hast (in Worten: dreißig) oder 3,0 Stück ;D
Mit so was hatte ich nicht gerechnet, kann es aber hochsetzen. Es erhöht dummereise den memory footprint.
Zitat von: waschbaerbauch am 21 Januar 2016, 04:30:50PPS: Und das nanoGateway für PCA301 wäre natürlich auch interessant, das wäre ja ein super 'Relay' Ersatz, wobei es diese Option beim PCA301 Sketch noch nie gegeben hat :D
Die Idee, das NanoLGW als relay zu verwenden ist nicht schlecht. Das LGW hatte zwar u.A das Ziel, dass man genau keine Relays mehr braucht, aber warum nicht.
Muss es nur noch einbauen, ich nehme es mal auf die ToDo-Abteilung "Wunschliste"
Zitat von: waschbaerbauch am 21 Januar 2016, 04:30:50
Nachtrag: Dabei fällt mir grad ein das ich noch eine zweite Wetterstation hier hab und zwar ebenfalls von Conrad die Profi Wetterstation slim (https://www.conrad.de/de/profi-wetterstation-slim-651345.html).
Zumidest mit dem LGW und dem LaCrosse-Sketch wird das mindestens mittelfristig nichts werden, die sendet auf 433 MHz und der überwiegende Teil der 433MHz-Klamotten sendet OOK und das kann das LGW nicht.
Zitat von: HCS am 21 Januar 2016, 14:50:01
Auch Du großer Schreck, bist Du sicher dass du 30 davon hast (in Worten: dreißig) oder 3,0 Stück ;D
Mit so was hatte ich nicht gerechnet, kann es aber hochsetzen. Es erhöht dummereise den memory footprint.
Tut mir leid, aber aktuell sind es in der Tat schon 30 (DREIZIG!) Stück und die Tendenz ist da eher ansteigend. Es fing mal ganz harmlos mit ein paar FS20 Dosen an, bis mich das fehlende Feedback der FS20 Dosen genervt und der damalige PCA301 Preis von 14,95€ pro Dose überzeugt hatte Nägel mit Köpfen zu machen.
ZitatDie Idee, das NanoLGW als relay zu verwenden ist nicht schlecht. Das LGW hatte zwar u.A das Ziel, dass man genau keine Relays mehr braucht, aber warum nicht. Muss es nur noch einbauen, ich nehme es mal auf die ToDo-Abteilung "Wunschliste"
Merci.
ZitatZumindest mit dem LGW und dem LaCrosse-Sketch wird das mindestens mittelfristig nichts werden, die sendet auf 433 MHz und der überwiegende Teil der 433MHz-Klamotten sendet OOK und das kann das LGW nicht.
Ich hatte sowas befürchtet. Alles was ich bisher finden konnte war das die Wetterstation auf 433MHz Basis arbeitet. Von Protokollen hab ich bisher noch gar nichts gefunden. Die Wetterstation einzubinden ist (zumindest bei mir) nichts zwingendes/dringendes. Es war nur so eine Idee ob man die externen Sensoren irgendwie mit nutzen kann. Die Anlage ist mir damals bei einem Ausverkauf mit auf die Einkaufsliste geraten. ;D
KVP ist vermutl. das KeyValueProtocol. Für den normalen Betrieb wird das doch eigentlich gar nicht benötigt oder? Es wird ziemlich schnell ziemlich groß. Bin gerade am schauen, wie ich das etwas ,,eingebremst" bekomme.
Autocreate: würde ich ungerne global ausschalten wollen.
Bei LaCrosse findet doch nur ein autocreate statt, wenn ich explizit ein ,,set myJeeLink LaCrossePairForSec 60" eingebe. Nur dann wird ein neuer Sensor angelegt, wenn sich auch der JeeLink im Pairing-Modus befindet. Bei MySensors ist das mMn über den Inclusion-Mode auch so ähnlich gelöst. Oder Homematic. Alle setzen ein aktives autocreate voraus.
Wäre halt schön, wenn sich das LGW ähnlich verhalten würde (nice to have). Ein autocreate für die Steckdose findet nur statt, wenn neben dem Drücken des Pairingknopfes auch das LGW entsprechend eingestellt ist. Dann gäbe es auch keine Phantomdosen mehr.
Zitat von: Omega am 21 Januar 2016, 16:42:32
KVP ist vermutl. das KeyValueProtocol. Für den normalen Betrieb wird das doch eigentlich gar nicht benötigt oder? Es wird ziemlich schnell ziemlich groß. Bin gerade am schauen, wie ich das etwas ,,eingebremst" bekomme.
Kann man im Config-Frontend des LGW konfigurieren, in welchem Interval es gesendet wird oder ob gar nicht.
Die Einstellung ist "KV-Interval"
Ich habe aber noch eine Erwereiterung auf der ToDo, dass KVP die Daten, die sich nicht ändern, wie z.B. MacAddress, ChipID und dann auch die Versionsnummer nur am Anfang und danach nur noch sehr selten schickt.
Zitat von: Omega am 21 Januar 2016, 16:42:32
Wäre halt schön, wenn sich das LGW ähnlich verhalten würde (nice to have).
Das hat nichts mit dem LGW zu tun. Das LGW liefert Daten bei FHEM ab und was FHEM damit macht, hängt von Modulen wie JeeLink, LaCrosse, PCA301 und auch vom autocreate Modul ab.
Die Thematik ist exakt die gleiche, wenn man einen JeeLink oder einen SuperJee verwendet.
Wobei "
LaCrosseGateway: Unknown code OK LS 7 0 9 121 2 199 85, help me!" eh seltsam ist, ich verstehe gerade noch nicht, wie das zustande kommt.
Eigentlich muss das von einem logischen Modul wie LaCrosse, EMT7110, oder Level kommen, Level kann es aber nicht sein, das muss so was verstehen und JeeLink meldet so was nicht.
Also muss es eins der anderen sein, aber denen dürfte es nicht zugestellt werden. Ich muss das mal erforschen.
Kannst Du bitte mal einen list LaCrosseGateway anhängen, dass ich die matchlist usw. sehen kann?
Gerne
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 38225
LaCrosseGateway_TIME 2016-01-21 18:01:01
NAME LaCrosseGateway
NR 736
PARTIAL
RAWMSG OK VALUES LGW 16446580 UpTimeSeconds=265217,UpTimeText=3Tg. 1Std. 40Min. 17Sek. ,WIFI=WLAN4Me,MacAddress=18:FE:34:FA:F4:74,ChipID=16446580,ReceivedFrames=81405,FramesPerMinute=15,RSSI=-41,FreeHeap=22104
STATE Opened
TYPE JeeLink
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-20 21:45:23 state opened
Attributes:
devStateIcon Initialized:cul@green .*:cul@red
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,868950,120i 96h 0a v
room LaCrosse
timeout 120,60
Wow, ist schon super was jetzt alles mit dem LaCrosseGateway funktioniert!
Besteht vllt die Möglichkeit, die EC3000 auch noch zu integrieren?
Dann wäre das LaCrosseGateway die Eierlegendewollmichsau...
Gruß
Stefan
Zitat von: StefanW am 23 Januar 2016, 08:26:02
Besteht vllt die Möglichkeit, die EC3000 auch noch zu integrieren?
Dann wäre das LaCrosseGateway die Eierlegendewollmichsau...
Eier OK, Wolle und Milch auch OK, Sau=Schwein dann halt auch ;D ;D
Aber EC3000 - Hmmm....
Das muss ich mir mal anschauen.
Da spricht aber dagegen:
- Ich habe keine EC3000
- Nach WS 1800 habe ich mir fest vorgenommen, nichts mehr zu implementieren, das ich nicht besitze
- lt. Statistik gibt es nur 35 Installationen, die EC3000 verwenden, scheint nicht sehr beliebt zu sein (PCA301 sind es 184)
- Eine kurze Recherche im Forum sagt, dass die Reichweite nicht so gut wäre
- Der EC3000-Sketch ist echt abgefahren, den zu analysieren, was er macht und es im LGW nachzubilden wird lustig
Aber ich will es mal nicht komplett ausschließen, muss es mir mal in Ruhe anschauen, was das konkret bedeuten würde.
Die ganzen Einzelsketche komplett abdecken ist schon verlockend, da einige wohl eh keine Weiterentwicklung erfahren.
Sendet die EC3000 von sich aus oder muss die gepollt werden?
Gibt es Erfahrungen bezüglich der Genauigkeit?
Zitat von: HCS am 23 Januar 2016, 10:59:11
- lt. Statistik gibt es nur 35 Installationen, die EC3000 verwenden, scheint nicht sehr beliebt zu sein (PCA301 sind es 184)
Dann schrauben wir die Statistik mal für die PCA nach oben ;) +1
Zitat von: HCS am 23 Januar 2016, 10:59:11
Sendet die EC3000 von sich aus oder muss die gepollt werden?
Gibt es Erfahrungen bezüglich der Genauigkeit?
Die senden alle 5 Sekunden. Da man diese nicht schalten kann sind die auch für Geräte geeignet wo ich aus Sicherheitsgründen keine Schaltsteckdose haben möchte, z.B. Kühlschrank. Reichweite, naja ich sage mal genauso beschissen wie bei EM1000 und PCA301...
Bei mir verrichten de JeeLinks und JeeNodes gute Arbeit, daher bin ich an dem Projekt nicht so interessiert, zumal ich kein WLAN mag, das geht bei mir nachts aus. Davon abgesehen können diese ganzen 0815 WLAN Module kein IEEE 802.1X und ich habe keine Lust bei allen Geräten jeden Monat den WPA Key zu ändern. Option wäre ein extra WLAN und bla :-)
Gruß
Daniel
Zitat von: ext23 am 23 Januar 2016, 13:06:18
Davon abgesehen können diese ganzen 0815 WLAN Module kein IEEE 802.1X ...
Zumindest EAP-TLS sollte mit dem kommenden 2.1er arduino core für den 8266 gehen.
Aber wenn man das WLAN abschaltet, dann spielt es eh keine so große Rolle.
Man darf das LGW aber nicht nur in Zusammenhang mit WLAN sehen, man kann das WLAN wegkonfigurieren und es per USB an den Server stecken, dann ist es, als ob man einen etwas zu gut geratenen JeeLink hätte ...
Zitat von: ext23 am 23 Januar 2016, 13:06:18Reichweite, naja ich sage mal genauso beschissen wie bei EM1000 und PCA301...
Hmm, interessant, weil meine PCA301 gehen diagonal durchs Haus. Für mich würde das dann bedeuten, dass wenn die Reichweite ungefähr gleich ist, dass EC3000 gar nicht so schlecht ist.
ZitatHmm, interessant, weil meine PCA301 gehen diagonal durchs Haus. Für mich würde das dann bedeuten, dass wenn die Reichweite ungefähr gleich ist, dass EC3000 gar nicht so schlecht ist.
Also die Test's von Oweh vor 3 Jahren haben den EM1000 deutlich schlechter als den PCA301 bewertet.
Deswegen hab ich keine.
Hallo,
die kann ich bestätigen. Deshalb haben ubiquity-mpower und PCA301 bei mir den EC3000 abgelöst.
bzw um genauer zu sein: Ich hatte unerklärliche Ausfälle.
Nico
V1.13
Gerade eingecheckt, ist morgen beim Update dann dabei.
- Erase EEPROM: Ist jetzt 8266e
- Erkennung der Radios verbessert, speziell, wenn man das 1er nicht drauf hat
- Nach einem Reset mit Taster oder einem WDT-Reset funtioniert wifi jetzt
- KVP: Die Versionsnummer des Sketch hinzugefügt
- PCA301: es werden bis zu 50 Dosen unterstützt
- KVP: Daten wie z.B. MacAddress, ChipID usw., die sich nicht ändern, werden nur am Anfang und dann all 30 Minuten gesendet
Erste "offizielle" Beta der PCA301 Implementierung.
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".
<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 das Poll-Intervall zu ändern.
Um die Frequenz nachträglich zu ändern verwendet man das "f" Kommando, also z.B. 868960#2f (Radio Nummer passend zum Radio, das man bei der Initialisierung festgelegt hat)
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,120i 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
Es kann sein, das man die Frequenz etwas anpassen mus, wenn das Radio und/oder die Dosen nicht genau auf 868950 liegen.
Man erkennt das daran, dass man entweder gar keine Antwort von den Dosen oder eine verzögerte Antwort bekommt.
Werte von 868960 oder 960970 haben da in manchen Fällen Abhilfe gebracht.
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 50 Dosen unterstützt.
Das PCA301 Modul in FHEM funktioniert komplett wie bisher
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:
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
Hallo,
ich habe das mal eben nachgebaut mit zwei RFM69W Transceiver.
Zeigt aber nur einen an. Ist das normal? Oder wird die Anzeige erst upgedatet, sobald das erste Signal vom PCA301 empfangen wird?
model
[LaCrosseITPlusReader.Gateway.1.13 (1=RFM69 f:868300 r:17241) {IP=192.168.178.25}]
initCommands
1,868950,120 3#2m 20#2t 220h 0a v
Lacrosse werden empfangen, sogar sehr gut. Ich habe im Livesystem aber noch einen Jeelink auf einem anderen PI, möglicherweise mögen die sich nicht in Bezug auf PCA301.
LG
/robin
Zitat von: fh168 am 24 Januar 2016, 19:10:28
ich habe das mal eben nachgebaut mit zwei RFM69W Transceiver.
Zeigt aber nur einen an. Ist das normal? Oder wird die Anzeige erst upgedatet, sobald das erste Signal vom PCA301 empfangen wird?
Nein, das ist nicht normal, der muss angezeigt werden, egal ob etwas empfangen wurde oder nicht.
Entweder defekt oder nicht richtig angeschlossen. Vertausche mal den ersten mit dem zweiten um zu sehen, ob er OK ist.
Wenn Du keinen BMP180 oder BME280 dran hast, brauchst Du die 220h nicht.
ok, das sieht schon besser aus:
model
[LaCrosseITPlusReader.Gateway.1.13 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 t:20~179) {IP=192.168.178.25}]
Für alle anderen, die das nachbauen: ich hatte NSS auch parallel geschaltet, also auf die Pins achten! Jetzt flackert die blaue LED auf dem ESP8266.
Steckdose schalten aber noch nicht, Lacrosse geht ...
Zitat von: fh168 am 24 Januar 2016, 21:54:48
Klappt aber noch nicht ...
Deine initCommands sind falsch
1,868950,120 3#2m 20#2t 220h 0a vRichtig ist:
1,868950,120i 3#2m 20#2t 220h 0a v
Genau so falsch wie die, die ich in meine Anleitung geschrieben habe :o :-[
Ich korrigiere es ...
Bingo, klappt!
da passen 2 RFMs auf dem "Rücken" vom NodeMCU drauf. Ich mache mal morgen ein Foto. Und was mache ich jetzt mit meinen original Jeelinks ?
LG
/robin
Zitat von: fh168 am 24 Januar 2016, 22:02:50
Und was mache ich jetzt mit meinen original Jeelinks ?
Och gegen Porto nimmt die schon jemand ab ;)
ich würde eher sagen, die Jungs, die das hier immer so genial programmieren, denen würde ich sogar den Jeelink überlassen. Aber den NodeMCU werde ich erst mal noch in meiner Testumgebung hier belassen. Schauen wir mal.
Ja ich habe da auch eher nicht an mich gedacht ..
Ich warte ja jetzt sehnsüchtig auf die ganzen Bestellungen aus China um das mal nachzubauen hier. Danach könnte sich hier ein ähnliches Problem stellen ;D
Muss gleich mal einen Blick in den Platinen-Thread werfen, nicht das ich den Punkt verpasse wo man Vorbestellungen abgeben kann/muss.
PS: Deine 'Tapete' bringt mir auch noch mal den Zwegat ins Haus ;)
Hallo HCS,
großer Respekt für dieses Projekt. Das Gateway wird wohl auch meine JeeLinks arbeitslos machen. Bzgl. PCA301-Support habe ich noch zwei Fragen:
1. Ist es geplant, das Pollintervall für jede Dose getrennt konfigurierbar zu machen?
2. Ist es geplant, die Anzahl der Retries konfgurierbar zu machen?
Wenn ja, dann brauche ich nicht mein eigenes Süppchen zu kochen - habe nämlich für den JeeLink extra die Firmware sowie das FHEM-Modul angepasst, was ich gerne wieder verwerfen würde.
Gruß
Thomas
Zitat von: Thomas_Homepilot am 25 Januar 2016, 11:02:45
1. Ist es geplant, das Pollintervall für jede Dose getrennt konfigurierbar zu machen?
Das steht auf der Wunschliste aber ich muss mir mal in Ruhe überlegen, wie man das konfiguriert, weil ich langsam in einen Konflikt zwischen initCommands und Web-Config-Frontend des LGW gerate, was man eigentlich wo einstellen sollte.
Zitat von: Thomas_Homepilot am 25 Januar 2016, 11:02:45
2. Ist es geplant, die Anzahl der Retries konfgurierbar zu machen?
Bisher nicht, aber ich kann es gerne mal auf die Wunschliste setzen. Das wäre dann aber global und nicht pro Dose.
Und nur in gwissen Grenzen. Aktuell wird die Dose drei mal im Abstand von einigen hundert Millisekunden neu angefragt, wenn keine Antwort gehört wird und dann das Ganze wieder, wenn das Poll-Interval rum ist.
Beide Punkte wird es aber nicht kurzfristig geben, ich will den aktuellen Stand erst mal ein wenig stabilisieren und weitere Punkte, die auf der Wunschliste stehen, dazu mit überdenken, wie es weiter geht. Das sind z.B.:
- "phantom-PCAs", die aufgrund von empfangenem Datenmüll angelegt werden
- Konfigurationsseite: Kanäle in Hex anzeigen
- Fehler: Wenn ein PAC301-Sketch die Dosen pollt, dann hört das LGW die Antworten der Dosen nicht
- Relay-Funktionalität wie beim LaCrosse-Sketch
- PCA301: nur senden, wenn der Kanal wirklich frei ist
- PCA301: Wenn von einer Dose z.B. 15 Minuten keine Antwort mehr kam, dann nicht weiter pollen
- PCA301: nur die dosen pollen die gerade eingeschaltet sind
- PCA301: force on / force off (kindersicherung) nicht aus fhem heraus sondern im sketch
- OTA Firmware update verbessern (Progress, Erebnis, ...)
- Anzeige im WebFrontend, auf welchen DataPorts etwas verbunden ist
- SC16IS750 für eigene Erweiterungen, die per serielle Schnittstelle ans LGW angebunden werden
- Den stillgelegten DHT22 evtl. wieder ermöglichen
- EC3000, dann wären alle alten "JeeLink-Sketche" erschlagen
Diese Liste darf man nicht als "zugesicherte Eigenschaften" betrachten, es ist die Liste der Ideen, teils aus dem JeeLink-PCA301-Thread und es gibt noch keine konkreten Pläne, was davon wann gemacht wird und was evtl. auch nie.
Muss jetzt eh erst mal Skifahren gehen ... 8) 8)
Vielen Dank für die ausführliche Antwort und den Ausblick. Klingt perfekt - ich bin nicht ungeduldig 8)
Dann wünsch ich erstmal viel Spaß beim Skifahren und lass die Knochen heil! ;)
Zitat von: HCS am 25 Januar 2016, 12:28:51
Muss jetzt eh erst mal Skifahren gehen ... 8) 8)
Viel Spaß und komm gesund wieder! ;)
Zitat von: Thomas_Homepilot am 25 Januar 2016, 15:28:28
Dann wünsch ich erstmal viel Spaß beim Skifahren und lass die Knochen heil! ;)
Zitat von: waschbaerbauch am 25 Januar 2016, 15:59:29
Viel Spaß und komm gesund wieder! ;)
Danke!
Solange ich mir nicht den Linksklick-Mausfinger breche besteht kein Grund zur Besorgnis ;D ;D ;D
Hallo,
ich hätte da mal eine Frage oder vielleicht auch ein Problem.
Habe gerade versucht über das Setup Menu vom ESP das Ota Update durchzuführen von 1.11 auf 1.13
Meine Config wie folgt:
OTA-Server: =ip.Fhem Server
OTA-Port: 8083
OTA-url: /fhem/firmware/LaCrosseGateway.bin
Leider stürzt der ESP dabei ab und die Seite OTA Start kann nicht angezeigt werden, blaue LED blinkt nicht mehr
Strom ab, wieder dran nix, blaue LED blinkt nur kurz.
Dann per USB an den PC angeschlossen, ESP8266Flasher gestartet, flashen, alles ok.
Funktioniert das noch nicht mit dem OTA Update oder habe ich eine falsche Config ??
Gruß Werner
Zitat von: Intruder1956 am 25 Januar 2016, 20:12:37
Funktioniert das noch nicht mit dem OTA Update oder habe ich eine falsche Config ??
Also bei mir geht es, gerade nochmal getestet. War zwar ein Update von 1.13 auf 1.13 aber es lief.
So sieht es bei mir auf der OTA-Update page aus:
Server: 192.168.31.13
Port: 8083
url: /fhem/firmware/LaCrosseGateway.bin
list firmware:
Internals:
DEF firmware FHEM/firmware firmware
NAME firmware
NR 241
STATE firmware
TYPE HTTPSRV
Fhem:
directory FHEM/firmware
friendlyname firmware
infix firmware Bekommst Du auf <fhem-ip>:8083/fhem/firmware/LaCrosseGateway.bin einen Download oder das bin angezeigt?
So in der Form:
�@@�@��@������?��@�@���_���? K�@��� ��@�J�@LJ�@� usw. usw.
er zeigt mir an:
Die Webseite wurde nicht gefunden 404
gruß Werner
sorry hatte 8083 vergessen 8)
bei : http://192.168.178.40:8083/fhem/firmware/LaCrosseGateway.bin
geht er in Fhem
Gruß Werner
Dann habe ich aktuell erst mal keine Idee. Nochmal probieren wäre eine Option.
Nach dem Klick auf "Update and restart" ist erst mal alles tot im Browser
Nach einiger Zeit sollte das LGW anfangen zu blinken und sich wieder auf das wifi verbinden
Nicht F5 reload in Browser machen, sonst springt das nächste Update an
Im Browser mit "zurück" zurück gehen
ich denke ich habe den Fehler gefunden.
Habe bei dir gesehen du hast ein HTTPSRV (ist das define irgendwo beschrieben ??)
Das habe ich jetzt auch mal angelegt und siehe da, er bietet mir ein Download an
Gruß Werner
Zitat von: Intruder1956 am 25 Januar 2016, 22:44:10
Habe bei dir gesehen du hast ein HTTPSRV (ist das define irgendwo beschrieben ??)
http://forum.fhem.de/index.php/topic,43672.msg366148/topicseen.html#msg366148
Jetzt sind wir an dem Punkt, an dem ein Freiwilliger für das wiki gefunden werden muss ...
ok ;D
update hat geklappt
nur zeigt er mir beim start vom update http://192.168.178.70/ota_start "Seite kann nicht angezeigt werden" aber er macht sein update
Internals:
CFGFN
DEF firmware FHEM/firmware firmware
NAME firmware
NR 1398
STATE firmware
TYPE HTTPSRV
Fhem:
directory FHEM/firmware
friendlyname firmware
infix firmware
Attributes:
Danke
Zitat von: HCS am 25 Januar 2016, 22:48:58
Jetzt sind wir an dem Punkt, an dem ein Freiwilliger für das wiki gefunden werden muss ...
Habe eben den Antrag als Autor für das Wiki abgeschickt.
Zitat von: AxelSchweiss am 25 Januar 2016, 23:12:59
Habe eben den Antrag als Autor für das Wiki abgeschickt.
Super, dass Du das übernimmst.
Zitat von: Intruder1956 am 25 Januar 2016, 23:04:18
update hat geklappt
nur zeigt er mir beim start vom update http://192.168.178.70/ota_start "Seite kann nicht angezeigt werden" aber er macht sein update
Ja, wie oben in meinem Ausblick schon geschrieben, kann das OTA-Update optisch durchaus noch verbessert werden. :)
Für die Setup-Page habe ich es schon eingebaut, dass man nach dem Speichern und dem Reset wieder auf die Hauptseite des LGW umgeleitet wird.
Bei OTA ist das etwas schwieriger, anzuzeigen, was gerade passiert und dann wieder auf die Hauptseite zu kommen.
Moin HCS.
Seit 1.12 ist bei mir die blaue LED dauerhaft an. mit dem initCommand 0a sollte diese doch eigentlich aus gehen oder? Macht sie leider nicht :(
Zitat von: oli82 am 26 Januar 2016, 09:09:01
Seit 1.12 ist bei mir die blaue LED dauerhaft an. mit dem initCommand 0a sollte diese doch eigentlich aus gehen oder? Macht sie leider nicht :(
Meinst Du die LED auf dem ESP8266 oder die LED auf dem devkit?
wenn du mich so fragst...
glaub das ist die auf dem ESP.
Zitat von: oli82 am 26 Januar 2016, 09:37:26
wenn du mich so fragst...
glaub das ist die auf dem ESP.
OK. Die auf dem devkit steuere ich an oder lasse sie bei 0a dunkel.
Mit der auf dem ESP8266 habe ich nichts zu tun.
Ich habe mich aber auch schon gefragt, wann die leuchtet und was sie eigentlich signalisiert.
Allerding hab ich mich bisher nur gefragt und mir noch nicht drauf geantwortet ... ;D ;D
Wer Lust hat kann ja mal ein Forschungsprojekt starten, was die Bedeutung dieser LED auf dem ESP-12E ist.
Danke für die Info!
So ganz klar ist es nicht, was es mit der LED auf sich hat. da gibt es wohl ein paar unterschiedliche Versionen: LINK (http://www.esp8266.com/viewtopic.php?p=26154#p26154)
guten Morgen,
Ich musste heute Nacht noch das HTTPSRV Modul entfernen, weil es mir das Logfile vollgemüllt hat.
2016.01.25 22:35:31 1: define firrmware HTTPSRV FHEM/firmware firmware: Usage: define <name> HTTPSRV <infix> <directory> <friendlyname>
2016.01.25 22:36:05 3: firrmware: new ext defined infix:firmware: dir:FHEM/firmware:
2016.01.25 22:36:05 3: Registering HTTPSRV firrmware for URL /firmware and assigned link firmware ...
2016.01.25 22:36:05 1: in DEFINED
2016.01.25 22:36:05 1: in DEFINED
2016.01.25 22:36:11 1: in SAVE
2016.01.25 22:36:11 1: in SAVE
2016.01.25 22:37:57 1: in ATTR
2016.01.25 22:37:57 1: in ATTR
2016.01.25 22:38:14 1: in SAVE
2016.01.25 22:38:14 1: in SAVE
2016.01.25 22:50:29 1: in RENAMED
2016.01.25 22:50:29 1: in RENAMED
2016.01.25 22:50:32 1: in SAVE
2016.01.25 22:50:32 1: in SAVE
2016.01.25 22:50:39 1: PERL WARNING: Use of uninitialized value $directory in concatenation (.) or string at ./FHEM/02_HTTPSRV.pm line 178.
2016.01.25 22:50:47 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:50:49 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:50:53 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:50:54 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/01_FHEMWEB.pm line 1472.
2016.01.25 22:50:54 1: Error: firrmware has no TYPE
2016.01.25 22:50:54 1: Error: firrmware has no TYPE
2016.01.25 22:50:54 1: Error: firrmware has no TYPE
2016.01.25 22:50:54 1: Error: firrmware has no TYPE
2016.01.25 22:50:54 1: Error: firrmware has no TYPE
2016.01.25 22:50:54 1: Error: firrmware has no TYPE
2016.01.25 22:50:54 1: Error: firrmware has no TYPE
2016.01.25 22:50:54 1: Error: firrmware has no TYPE
2016.01.25 22:50:54 1: Error: firrmware has no TYPE
2016.01.25 22:50:54 1: Error: firrmware has no TYPE
2016.01.25 22:50:54 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:50:55 1: Error: firrmware has no TYPE
2016.01.25 22:51:05 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:51:21 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:51:24 1: Error: firrmware has no TYPE
2016.01.25 22:51:38 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:51:46 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:51:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:52:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:52:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:52:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:52:49 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:53:01 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:53:07 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:53:26 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:53:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:53:44 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:53:52 3: firmware: new ext defined infix:firmware: dir:FHEM/firmware:
2016.01.25 22:53:52 3: Registering HTTPSRV firmware for URL /firmware and assigned link firmware ...
2016.01.25 22:53:52 1: in MODIFIED
2016.01.25 22:53:52 1: in MODIFIED
2016.01.25 22:53:56 1: in SAVE
2016.01.25 22:53:56 1: in SAVE
2016.01.25 22:53:56 1: PERL WARNING: Use of uninitialized value in hash element at fhem.pl line 1430.
2016.01.25 22:54:02 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:54:13 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:54:19 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:54:30 1: in DELETEATTR
2016.01.25 22:54:30 1: in DELETEATTR
2016.01.25 22:54:32 1: in SAVE
2016.01.25 22:54:32 1: in SAVE
2016.01.25 22:54:36 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:54:49 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:54:50 1: in SAVE
2016.01.25 22:54:50 1: in SAVE
2016.01.25 22:54:54 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:55:13 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:55:25 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:55:30 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:55:48 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:55:49 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:56:01 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:56:05 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:56:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:56:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:56:39 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:56:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:57:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:57:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:57:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:57:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:57:51 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:58:08 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:58:29 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:58:29 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:58:46 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:59:04 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:59:05 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:59:23 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:59:40 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:59:41 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 22:59:58 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:00:17 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:00:18 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:00:35 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:00:49 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:00:52 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:00:53 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:00:54 3: firmware: new ext defined infix:firmware: dir:FHEM/firmware:
2016.01.25 23:00:54 3: Registering HTTPSRV firmware for URL /firmware and assigned link firmware ...
2016.01.25 23:00:54 1: in MODIFIED
2016.01.25 23:00:54 1: in MODIFIED
2016.01.25 23:00:57 1: in SAVE
2016.01.25 23:00:57 1: in SAVE
2016.01.25 23:01:09 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:01:27 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:01:29 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:01:47 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:02:04 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:02:05 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:02:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:02:39 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:02:41 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:02:56 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:03:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:03:17 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:03:31 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:03:49 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:03:56 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:04:07 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:04:25 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:04:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:04:42 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:05:03 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:05:08 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:05:20 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:05:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:05:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:05:45 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:05:49 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:05:54 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:06:12 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:06:21 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:06:29 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:06:46 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:06:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:07:04 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:07:21 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:07:33 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:07:38 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:07:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:08:09 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:08:15 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:08:33 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:08:45 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:08:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:09:08 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:09:24 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:09:25 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:09:43 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:10:00 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:10:01 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:10:18 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:26 1: Error: firrmware has no TYPE
2016.01.25 23:10:27 1: Error: firrmware has no TYPE
2016.01.25 23:10:27 1: Error: firrmware has no TYPE
2016.01.25 23:10:27 1: Error: firrmware has no TYPE
2016.01.25 23:10:27 1: Error: firrmware has no TYPE
2016.01.25 23:10:27 1: Error: firrmware has no TYPE
2016.01.25 23:10:27 1: Error: firrmware has no TYPE
2016.01.25 23:10:27 1: Error: firrmware has no TYPE
2016.01.25 23:10:27 1: Error: firrmware has no TYPE
2016.01.25 23:10:27 1: Error: firrmware has no TYPE
2016.01.25 23:10:27 1: Error: firrmware has no TYPE
2016.01.25 23:10:27 1: Error: firrmware has no TYPE
2016.01.25 23:10:41 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:10:41 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:10:57 1: Error: firrmware has no TYPE
2016.01.25 23:10:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:11:07 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:11:25 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:11:27 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:11:42 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:11:59 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:12:03 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:12:19 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:12:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:12:42 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:12:53 2: CUL_TX Unknown device 127, please define it
2016.01.25 23:12:53 1: in UNDEFINED
2016.01.25 23:12:53 2: autocreate: define CUL_TX_127 CUL_TX 127
2016.01.25 23:12:53 2: autocreate: define FileLog_CUL_TX_127 FileLog ./log/CUL_TX_127-%Y-%m.log CUL_TX_127
2016.01.25 23:12:53 2: autocreate: define SVG_CUL_TX_127 SVG FileLog_CUL_TX_127:temp4hum4:CURRENT
2016.01.25 23:12:53 1: in UNDEFINED
2016.01.25 23:12:53 1: in DEFINED
2016.01.25 23:12:53 1: in DEFINED
2016.01.25 23:12:53 1: in DEFINED
2016.01.25 23:12:53 1: in SAVE
2016.01.25 23:12:53 1: PERL WARNING: Use of uninitialized value $x in substitution (s///) at ./FHEM/01_FHEMWEB.pm line 2446.
2016.01.25 23:12:53 1: PERL WARNING: Use of uninitialized value $a[1] in join or string at ./FHEM/01_FHEMWEB.pm line 2447.
2016.01.25 23:12:53 1: PERL WARNING: Use of uninitialized value $a[2] in join or string at ./FHEM/01_FHEMWEB.pm line 2447.
2016.01.25 23:12:54 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:13:12 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:13:18 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:13:29 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:13:48 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:13:54 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:14:05 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:14:23 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:14:30 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:14:41 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:14:59 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:15:06 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:15:16 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:15:33 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:15:42 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:15:51 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:15:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:16:10 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:16:18 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:16:27 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:16:45 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:16:54 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:17:03 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:17:21 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:17:30 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:17:38 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:17:55 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:18:10 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:18:13 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:18:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:18:46 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:18:49 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:19:06 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:19:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:19:26 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:19:43 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:19:58 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:20:02 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:20:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:20:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:20:28 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:20:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:20:34 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:20:39 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:20:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:20:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:21:10 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:21:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:21:24 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:21:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:21:46 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:21:49 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:22:07 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:22:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:22:25 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:22:44 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:22:58 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:23:01 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:23:18 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:23:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:23:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:23:55 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:24:12 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:24:13 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:24:30 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:24:48 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:24:49 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:25:06 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:25:25 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:25:26 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:25:44 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:25:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:26:01 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:26:02 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:26:19 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:26:36 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:26:38 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:26:55 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:27:13 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:27:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:27:31 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:27:48 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:27:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:28:06 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:28:23 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:28:26 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:28:41 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:28:58 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:29:05 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:29:16 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:29:33 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:29:41 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:29:51 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:30:17 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:30:18 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:30:35 2: IT set AZ_Kamera on
2016.01.25 23:30:36 2: IT set WZ_Kamera on
2016.01.25 23:30:46 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:30:53 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:30:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:30:59 2: IT set AZ_Kamera off
2016.01.25 23:30:59 2: IT set WZ_Kamera off
2016.01.25 23:31:10 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:31:29 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:31:30 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:31:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:32:06 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:32:07 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:32:25 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:32:42 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:32:42 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:32:59 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:33:16 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:33:18 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:33:34 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:33:51 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:33:54 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:34:08 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:34:25 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:34:33 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:34:43 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:35:01 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:35:09 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:35:18 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:35:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:35:35 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:35:45 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:35:52 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:35:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:36:09 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:36:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:36:26 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:36:45 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:36:58 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:37:03 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:37:20 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:37:34 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:37:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:37:54 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:38:10 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:38:11 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:38:28 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:38:45 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:38:46 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:39:02 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:39:19 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:39:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:39:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:39:54 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:40:01 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:40:11 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:40:28 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:40:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:40:45 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:40:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:41:02 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:41:13 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:41:20 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:41:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:41:49 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:41:54 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:42:13 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:42:25 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:42:30 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:42:47 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:43:01 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:43:04 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:43:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:43:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:43:39 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:43:42 2: CUL_TX Unknown device 10, please define it
2016.01.25 23:43:42 1: in UNDEFINED
2016.01.25 23:43:42 2: autocreate: define CUL_TX_10 CUL_TX 10
2016.01.25 23:43:42 2: autocreate: define FileLog_CUL_TX_10 FileLog ./log/CUL_TX_10-%Y-%m.log CUL_TX_10
2016.01.25 23:43:42 2: autocreate: define SVG_CUL_TX_10 SVG FileLog_CUL_TX_10:temp4hum4:CURRENT
2016.01.25 23:43:42 1: in UNDEFINED
2016.01.25 23:43:42 1: in DEFINED
2016.01.25 23:43:42 1: in DEFINED
2016.01.25 23:43:42 1: in DEFINED
2016.01.25 23:43:42 1: in SAVE
2016.01.25 23:43:56 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:44:13 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:44:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:44:30 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:44:47 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:44:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:45:04 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:45:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:45:29 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:45:39 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:45:56 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:45:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:46:05 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:46:13 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:46:30 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:46:41 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:46:47 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:47:04 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:47:17 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:47:21 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:47:41 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:47:53 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:47:58 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:48:15 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:48:29 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:48:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:48:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:49:05 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:49:07 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:49:24 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:49:41 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:49:41 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:49:58 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:50:15 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:50:17 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:50:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:50:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:50:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:50:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:50:56 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:50:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:51:07 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:51:25 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:51:29 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:51:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:51:42 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:51:59 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:52:08 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:52:16 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:52:35 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:52:45 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:52:53 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:53:10 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:53:21 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:53:27 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:53:44 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:53:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:54:02 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:54:19 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:54:33 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:54:36 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:54:53 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:55:09 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:55:10 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:55:27 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:55:44 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:55:45 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:55:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:56:01 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:56:19 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:56:24 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:56:36 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:56:53 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:57:00 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:57:10 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:57:27 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:57:36 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:57:44 2: IT set AZ_Kamera on
2016.01.25 23:57:45 2: IT set WZ_Kamera on
2016.01.25 23:57:55 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:58:03 2: IT set AZ_Kamera off
2016.01.25 23:58:04 2: IT set WZ_Kamera off
2016.01.25 23:58:12 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:58:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:58:31 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:58:48 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:58:48 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:59:06 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:59:23 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:59:24 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:59:42 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.25 23:59:59 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:00:00 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:00:01 1: Error: firrmware has no TYPE
2016.01.26 00:00:16 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:00:33 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:00:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:00:51 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:00:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:01:08 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:01:13 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:01:25 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:01:42 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:01:52 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:02:02 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:02:19 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:02:28 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:02:36 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:02:53 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:03:04 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:03:10 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:03:27 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:03:40 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:03:44 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:03:59 1: Error: firrmware has no TYPE
2016.01.26 00:03:59 1: Error: firrmware has no TYPE
2016.01.26 00:03:59 1: Error: firrmware has no TYPE
2016.01.26 00:03:59 1: Error: firrmware has no TYPE
2016.01.26 00:03:59 1: Error: firrmware has no TYPE
2016.01.26 00:03:59 1: Error: firrmware has no TYPE
2016.01.26 00:03:59 1: Error: firrmware has no TYPE
2016.01.26 00:04:00 1: Error: firrmware has no TYPE
2016.01.26 00:04:04 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:04:16 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:04:21 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:04:38 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:04:52 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:04:55 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:05:02 1: Error: firrmware has no TYPE
2016.01.26 00:05:12 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:05:28 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:05:29 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:05:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:05:47 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:05:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:06:04 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:06:04 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:06:21 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:06:38 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:06:40 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:06:55 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:07:12 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:07:19 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:07:29 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:07:47 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:07:55 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:08:04 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:08:21 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:08:31 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:08:38 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:08:55 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:09:07 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:09:12 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:09:31 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:09:44 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:09:49 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:10:06 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:10:20 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:10:23 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:10:40 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:10:56 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:10:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:10:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:11:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:11:31 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:11:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:11:48 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:12:05 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:12:08 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:12:23 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:12:40 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:12:47 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:12:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:13:15 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:13:23 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:13:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:13:49 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:13:59 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:14:06 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:14:23 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:14:36 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:14:40 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:14:59 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:15:12 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:15:17 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:15:34 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:15:48 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:15:51 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:15:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:16:08 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:16:24 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:16:25 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:16:42 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:16:59 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:17:00 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:17:16 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:17:33 2: IT set AZ_Kamera on
2016.01.26 00:17:34 2: IT set WZ_Kamera on
2016.01.26 00:17:36 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:17:45 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:17:52 2: IT set AZ_Kamera off
2016.01.26 00:17:52 2: IT set WZ_Kamera off
2016.01.26 00:18:03 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:18:15 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:18:20 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:18:38 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:18:51 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:18:55 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:19:12 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:19:27 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:19:31 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:19:48 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:20:03 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:20:05 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:20:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:20:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:20:28 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:20:33 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:20:39 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:20:40 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:20:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:20:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:21:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:21:15 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:21:33 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:21:33 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:21:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:21:58 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:22:07 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:22:24 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:22:38 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:22:42 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:22:59 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:23:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:23:16 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:23:33 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:23:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:23:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:24:07 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:24:26 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:24:27 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:24:44 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:25:01 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:25:02 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:25:18 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:25:35 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:25:38 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:25:52 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:25:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:26:09 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:26:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:26:29 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:26:46 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:26:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:27:03 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:27:20 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:27:26 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:27:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:27:54 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:28:05 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:28:11 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:28:28 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:28:41 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:28:48 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:29:05 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:29:17 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:29:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:29:40 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:29:53 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:29:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:30:14 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:30:29 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:30:31 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4463.
2016.01.26 00:30:46 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 1276.
2016.01.26 00:30:46 3: Unregistering HTTPSRV firmware for URL /firmware...
was ist das denn wieder ??
Gruß Werner
Irgendwas stimmt bei deiner Definition nicht.
Hier mal meine:
define firmware HTTPSRV firmware FHEM/firmware LaCrosseGateway
und die des Gateways:
(http://www.oli82.de/files/fhem/LaCrosseGateway.png)
Zitat von: oli82 am 26 Januar 2016, 09:58:06
Danke für die Info!
So ganz klar ist es nicht, was es mit der LED auf sich hat. da gibt es wohl ein paar unterschiedliche Versionen: LINK (http://www.esp8266.com/viewtopic.php?p=26154#p26154)
Hmm....
GPIO1 ist TXD0 und mit dem CP2102 verbunden, leuchtet also, und wird dann dunkel (was sehr kurz immer ist), wenn Daten auf der seriellen Schnittstelle gesendet werden
GPIO2 ist der ChipSelect vom RFM69 #2, somit flackert sie, wenn dieses Radio angesprochen wird.
Wenn man ein devkit hat, bei dem sie an GPIO1 ist, macht das noch einen gewissen Sinn, allerdings wäre invertiert besser. Kurz dunkel werden, wenn Daten übertragen werden, ist auch doof.
Einen Tupfen schwarze Farbe drauf und gut ist.
Zitat von: Intruder1956 am 26 Januar 2016, 10:17:35
Zitat2016.01.25 22:35:31 1: define firrmware HTTPSRV FHEM/firmware firmware: Usage: define <name> HTTPSRV <infix> <directory> <friendlyname>
Die erste Zeile sagt es doch schon, dass die Definition des HTTPSRV falsch ist.
Hallo allerseits,
vorab ein dickes DANKE an HCS und alle anderen, die hier mitarbeiten!
Ich habe heute morgen drei PCA301 bekommen; einen ESP8266 mit RFM69HCW zusammengebacken; gefühlte 3 Monate damit zugebracht, zu verstehen, dass die PCAs nicht auf 17241 funken und das die HCW-Module nur eine Reichweite von einem Meter haben; und habe inzwischen alles sauber am Laufen und gleich noch zwei Steckdosen nachbestellt ;D
Da die Frage in diesem Thraed schonmal hoch kam und ich damit auch gekämpft habe: Man kann die RFM69HCW-Module scheinbar nutzen, ich musste allerdings den (kleinen) Booster einschalten, um die 3-4 Meter bis zu den PCAs zu überbrücken:
#define USE_BOOSTER 1
void HandlePCA301Send(unsigned long *data, byte size) {
if (size == 10 && pca301.IsInitialized()) {
rfm1.EnableReceiver(false);
#if USE_BOOSTER
rfm1.SetHFParameter(REG_PALEVEL, (RF_PALEVEL_PA0_OFF | RF_PALEVEL_PA1_ON | RF_PALEVEL_PA2_OFF | RF_PALEVEL_OUTPUTPOWER_11111));
#endif
byte payload[10];
for (int i = 0; i < 10; i++) {
payload[i] = data[i];
}
pca301.SendPayload(payload, false);
#if USE_BOOSTER
rfm1.SetHFParameter(REG_PALEVEL, (RF_PALEVEL_PA0_ON | RF_PALEVEL_PA1_OFF | RF_PALEVEL_PA2_OFF | RF_PALEVEL_OUTPUTPOWER_11111));
#endif
rfm1.EnableReceiver(true);
}
}
In wie weit es in DE erlaubt ist, den Booster zu nutzen, habe ich jetzt nicht gecheckt (mangels Verständnis und Ahnung der Materie), habe mich aber zurückgehalten den Booster voll aufzudrehen und bleibe bei max. +13dB.
Nochmal vielen Dank und beste Grüße
Chris
Hallo zusammen,
Ich kann mich nach dem Update über Serielle Schnittstelle nach Version v1.13 nicht mehr verbinden zum WLAN.
Ich bitte um Hilfe.
Zitat von: her1298 am 31 Januar 2016, 15:42:37
Ich kann mich nach dem Update über Serielle Schnittstelle nach Version v1.13 nicht mehr verbinden zum WLAN.
Was macht die LED beim Start?
Macht es den AccessPoint auf?
Wenn ja: kannst Du Dich auf den AccessPoint verbinden?
Wenn ja: kommst Du auf die Konfigurationsseite?
Wenn ja: stimmt die Konfiguration noch?
Was war die Version, die vor 1.13 drauf war?
@Her1298
Hattest Du vorher ein OTA-Update gemacht?
Hatte ich auch mal, einfach komplett neu flashen (akutelle Bin-Datei) mit NodeMCU-Flasher (s. Post 1), spart Nerven.
LG
/robin
Zitat von: AxelSchweiss am 13 Dezember 2015, 09:00:37
Habe diese DevKit
http://de.aliexpress.com/item/Update-Industry-4-0-New-esp8266-NodeMCU-v2-Lua-WIFI-networking-development-kit-board-based-on/32358722888.html?detailNewVersion=2 (http://de.aliexpress.com/item/Update-Industry-4-0-New-esp8266-NodeMCU-v2-Lua-WIFI-networking-development-kit-board-based-on/32358722888.html?detailNewVersion=2)
Moin!
Im Eifer des Gefechts hab ich mir glaube ich auch das obrige Devkit geordert anstatt dem ''NodeMCU DEVKIT 1.0'
Macht das einen Unterschied oder muss ich doch noch in deren Urlaub eine neue Bestellung mit dem NodeMCU DEVKIT 1.0 absetzen?
Danke für ne kurze Info
Mario
Zitat von: waschbaerbauch am 05 Februar 2016, 23:18:53
Moin!
Im Eifer des Gefechts hab ich mir glaube ich auch das obrige Devkit geordert anstatt dem ''NodeMCU DEVKIT 1.0'
Macht das einen Unterschied oder muss ich doch noch in deren Urlaub eine neue Bestellung mit dem NodeMCU DEVKIT 1.0 absetzen?
Also bei mir läuft das jetzt seit ca 1 Monat ... ohne Probleme mit einem Radio und einem BMP180
Auch das direkte Flashen via USB geht problemlos. OTA natürlich auch.
Danke! :)
Ich habe gerade die Version 1.14 hochgeladen. Diese unterstützt nun auch die Energie-Mess-Steckdose "Energy Count 3000"
Wichtig: EC3000 funktioniert nur mit RFM69, nicht mit RFM12
Die EC3000 sendet auf 868.300 kHz mit 20.000 kbps. Dafür wurde eine neue data rate hinzugefügt.
Sie kann mit 3r oder 20000r gesetzt werden. Wenn diese data rate gesetzt wird, wird auch automatisch der RFM69 auf den Empfang von EC3000 uminitialisiert.
EC3000 kann auch in einen data rate toggle mit einbezogen werden. Dazu gibt es nun das bit mit dem Wert 8 für 20.000 kbps
Um EC3000 dediziert mit einem der drei RFMs zu empfangen muss man einfach die data rate des gewünschten RFM setzen. Beispiel initCommand:
20000#2r
Um EC3000 in einen data rate toggle mit einzubeziehen muss im m command das 8-wertige bit gesetzt werden.
Wenn man z.B. mit dem zweiten Radio 17k Sensoren (TX29...) und EC3000 empfangen will (20 Sekunden toggle), wäre das initCommand:
9#2m 20#2t v
Ich habe das binary im FEHM/firmware Ordner umbenannt, von LaCrosseGateway.bin nach JeeLink_LaCrosseGateway.bin, dass es in das Namenschema vom JeeLink Modul passt.
Das bedeutet, dass man nun auf der config page des LGW den entsprechenden Eintrag anpassen muss:
OTA-url: /fhem/firmware/JeeLink_LaCrosseGateway.bin
Dafür gibt es mit etwas Glück bald die Möglichkeit, das LGW vom JeeLink Modul aus mit "set myJeeLink flash" upzudaten und man kann sich dann den HTTPSRV sparen.
Bah - der Zoll macht mich wahnsinnig ;D
Immerhin sind heute mal die Devkits angekommen - aber ohne RFM69 kann ich immer noch nicht anfangen zu spielen *hibbel* ...
Warten warten warten ...
Zitat von: waschbaerbauch am 09 Februar 2016, 16:25:37
Bah - der Zoll macht mich wahnsinnig ;D
Nicht immer auf den armen Zoll schieben, meine Bestellung liegt noch auf dem Flughafen in CN. (2016-02-01 22:27 厦门航站, 离开 --> g..gl-translate --> "Xiamen Terminal Urlaub"). 8)
Liegt wohl an dem Neujahrsfest "Jahr des Affen". ;)
http://www.chinarundreisen.com/das-chinesische-fruehlingsfest/termine.htm (http://www.chinarundreisen.com/das-chinesische-fruehlingsfest/termine.htm)
Gruß Friedrich
Zitat von: Omega-5 am 09 Februar 2016, 18:07:35
Liegt wohl an dem Neujahrsfest "Jahr des Affen". ;)
Also doch der Zoll ;D ;D ;D
Doch doch Zoll. Die sind schon in DE gelandet, wo genau kA - aber ohne Zoll kommen die nicht ins Land ;)
Bei anderen Bestellungen steht immerhin:
德国法兰克福, 到达互换局 (Frankfurt, Germany , to reach the office of exchange)
Da liegen sie gut. Nur was der eine Status mit 'zwei Berge' mir sagen will *g*
PS: Meine Sprachkenntnisse reichen nicht, was bedeutet denn:
鎿嶄綔瀹屾垚, DE (GoogleTrans sagt 'Na Zhan Hu Yue Shen Yao , DE') oder
璐х墿鐢靛瓙淇℃伅宸茬粡鏀跺埌, DE (GT: 'Lu Qi Dao х Yiuu indigo ℃ Dun Chen Tong stubble you receive , DE)
Ich weiss nicht, was ihr habt. Devkit ist mittlerweile da, BME280 ist heute gekommen. Jetzt müsste nur mal jemand den lahmen Layouter auf Trab bringen ;D ;D ;D
Zitat von: waschbaerbauch am 09 Februar 2016, 18:38:38
PS: Meine Sprachkenntnisse reichen nicht, was bedeutet denn:
鎿嶄綔瀹屾垚, DE
Deutsche Übersetzung: "Wenn LGW Projekt Du starten, auf Teile aus China musst warten"
Zitat von: PeMue am 09 Februar 2016, 22:25:13Jetzt müsste nur mal jemand den lahmen Layouter auf Trab bringen ;D ;D ;D
Ich finde inzwischen eh, dass mein Breadboard so was von modern art ist, dass es eine Schande wäre, das auf ein Platine zu löten ;D
Das OTA-Update direkt aus dem JeeLink Modul heraus scheint übrigens machbar, der Prototyp dazu funktioniert schon mal, zumindest in Kombination mit einem breadboard 8)
Zitat von: PeMue am 09 Februar 2016, 22:25:13
Ich weiss nicht, was ihr habt. Devkit ist mittlerweile da, BME280 ist heute gekommen. Jetzt müsste nur mal jemand den lahmen Layouter auf Trab bringen ;D ;D ;D
Devkits heute, BMP180 schon lange, aber keine RFM69CW :'(
Jaja, Geduld ist eine Tugend ::) ;)
Zitat von: HCS am 09 Februar 2016, 22:38:45
Deutsche Übersetzung: "Wenn LGW Projekt Du starten, auf Teile aus China musst warten"
Ich finde inzwischen eh, dass mein Breadboard so was von modern art ist, dass es eine Schande wäre, das auf ein Platine zu löten ;D
Ich warte doch auf die gelbe Flut. Der Briefträger munkelt schon das ich hier anfange Bomben zu bauen wegen der ganzen Einschreiben..
Wenn der wüsste das da immer noch 43 Sendungen ausstehen und nach den Ferien noch mal ~30 kommen ;D ;D ;D
Zitat von: HCS am 09 Februar 2016, 22:38:45
Ich finde inzwischen eh, dass mein Breadboard so was von modern art ist, dass es eine Schande wäre, das auf ein Platine zu löten ;D
Ich glaube nicht, dass Du dieses Kunstwerk noch ein zweites Mal zum laufen bekommen würdest ...
Zitat von: HCS am 09 Februar 2016, 22:38:45
Ich finde inzwischen eh, dass mein Breadboard so was von modern art ist, dass es eine Schande wäre, das auf ein Platine zu löten ;D
Einfach in Giesharz einbetten ... und für die Ewigkeit konservieren .... dann hat sich die Gehäusefrage gleich mit erledigt ;D
EDIT:
Und hat gleich IP69
Gießharz hat ja ein wenig was von Bernstein. Was denkt sich der Finder in 10.000 Jahren nur was das sein soll? ;D
Immerhin ließen sich die günstigen Devkits schon mit der LGW Firmware flashen und warten weiter 'geduldig' auf die RFM69CW. Sie werden schon vom FHEM anerkannt und hibbeln mit mir um die Wette ;)
Meine Tochter findet sie sich drehenden Würfel der Tracking App so toll, blöd das man die Abfrage nur alle 10 Minuten machen kann ;D
Edit: 10 Pakete soeben angekommen, aber KEIN RFM69CW dabei :'(
Zitat von: waschbaerbauch am 09 Februar 2016, 16:25:37
Bah - der Zoll macht mich wahnsinnig ;D
Immerhin sind heute mal die Devkits angekommen - aber ohne RFM69 kann ich immer noch nicht anfangen zu spielen *hibbel* ...
Warten warten warten ...
Bestell Dir doch welche bei Pollin - die haben sie vorrätig (in 433 und 868) und den Mehrpreis kannst Du mit dem geschonten Nervenkostüm verrechnen ;)
Gruß
Chris
Ahja, aber in den Mengen die ich hier beabsichtige zu bauen, da kommt mir die Regierung auf die Schliche ;)
PS: Bei meinen aktuell bestellten 8 RFM sind das immerhin schon 15€ Differenz. Das ist ja fast ne Kiste Erdinger :D
Wenn man in organisierter Armut lebt muss man sich halt in Geduld üben ;)
Edit: Das Warten hat ein Ende
Die RFM69 sind nun angekommen und ich wollte gleich mal los legen, da ist mir aufgefallen das sie bei dir auf den Bildern auf Leiterplatten aufgelötet sind. Ist das Marke Eigenbau oder kann/muss man sie noch extra erwerben?
Gruß
Mario
Das ist das Prototypingboard bzw der Adapter. Ich hab einfach Drahtbrücken verwendet und das Modul dann auf ein Steckbrett gesteckt.
Zitat von: waschbaerbauch am 12 Februar 2016, 15:28:04
Die RFM69 sind nun angekommen und ich wollte gleich mal los legen, da ist mir aufgefallen das sie bei dir auf den Bildern auf Leiterplatten aufgelötet sind. Ist das Marke Eigenbau oder kann/muss man sie noch extra erwerben?
Die kann man irgendwo in GB kaufen, für richtig viel Geld, aber weil:
Zitat von: waschbaerbauch am 12 Februar 2016, 12:50:53Wenn man in organisierter Armut lebt muss man sich halt in Geduld üben ;)
kommt das eher nicht in Frage ;D ;D ;D
Man braucht sie auch nicht unbeding. Auf die "PeMue-Platine" kommen die RFMs pur, ohne weitere Adapter drauf.
Auf dem Breadboard ist es halt angenehm, wenn man ständig neue Versuchsaufbauten macht, man kann es aber auch mit einem Stückchen Loachrasterplatine auf das breadboard adaptieren.
Oder einfach Kabel dran löten.
Wer reich ist, so wie ich 8) ;D 8) ;D
hier: http://www.ebay.co.uk/itm/RFM12B-RFM69-Breakout-Board-PCB-board-only-3-3Volt-/141890306429
Zwischenstand von mir: Es läuft nun schon ne ganze Weile im Beta Modus bei mir.
Nun möchte ich das Gebastel auflösen und in die finale Form mit Gehäuse bringen.
Dabei wollte ich ein OTA-Update von 1.07 und die aktuelle 1.14 machen, allerdings habe ich es nicht geschafft.
Obwohl in Fhem alles richtig ist, ich den Download im Browser durchführen kann und der Pfad im ESP auch stimmt, wollte er kein Update machen.
Ich habe das Update dann über UART/RS232 geflasht und es hat problemlos geklappt, sogar alle Einstellungen sind noch da *freu*
Zitat von: HCS am 12 Februar 2016, 16:09:20
Die kann man irgendwo in GB kaufen, für richtig viel Geld, aber weil:kommt das eher nicht in Frage ;D ;D ;D9
Genau und mangels Geduld auf weiter warten hab ich Stiftleisten zerlegt und passend gemacht was nicht passt ;)
Ein Aufbau mit 2xRFM69 und einer mit 3xRFM69.
Die erste Variante hat zumindest die TX25IT gefunden und einige PCA301 eingesammelt.
Variante 2 muss ich gleich noch konfigurieren und hoffe irgendwie noch die TFA Thermo-/Hygrosensor 30.3155 einzufangen.
Mit den 'normalen JeeLinks' werden sie alle anstandslos empfangen, beim LGW wirds wohl noch 'Jugend forscht' :)
Gruß
Mario
Zitat von: HCS am 12 Februar 2016, 16:09:20
Wer reich ist, so wie ich 8) ;D 8) ;D
hier: http://www.ebay.co.uk/itm/RFM12B-RFM69-Breakout-Board-PCB-board-only-3-3Volt-/141890306429
Klar, aber wie sagte auch immer Dagobert Duck : "nicht das Billigste, aber stets das Beste - wie Alles aus dem Hause Duck" :)
BTW: die Engländer arbeiten hoffensichtlich nahe der Lichtgeschwindigkeit: 24 Minuten nach der PayPal bezahlung hatte ich bereits eine "im Versand" Mail ....
Zitat von: Doublefant am 12 Februar 2016, 21:28:09
Obwohl in Fhem alles richtig ist, ich den Download im Browser durchführen kann und der Pfad im ESP auch stimmt, wollte er kein Update machen.
Hmm, seltsam, es gab auch schon den Fall, dass das funktioniert.
Aber lass mal, dieses Wochenende kommt eine neue OTA-Update Variante, bei der man es vom JeeLink-Modul aus schickt, ganz simpel mit "set myJeeLink flash", ohne HTTPSVR zu benötigen.
Version 1.15 geladen, ins Firmware Verzeichnis kopiert, Rechte gesetzt und OTA Update war erfolgreich :)
Edit: Kurzes Feedback
Vier NodeMCU erfolgreich geflasht. Allerdings bin ich immer nur auf den AccessPoint gekommen solange keine RFM69 auf dem Breadboard verdrahtet waren - ohne was dran lief es dann. Nach der Einrichtung der WiFi Daten dann wieder in den verdrahteten Teil des Breadboards gesteckt und lief.
OTA Update(s) liefen auch erfolgreich. Zwei FHEM Instanzen (jeweils auf eigenen Ports verbunden) liefen bisher auch.
- PCA301 wurden automatisch gefunden und per autocreate angelegt
- TX25IT Sensoren wurden automatisch erkannt und per autocreate angelegt
- TX30.3155 werden nicht erkannt und somit auch nicht angelegt (mit einem JeeLink allerdings schon)
- Levelsender werden ebenfalls nicht erkannt und auch nicht angelegt
2016-02-13 02:50:40 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 3 0 9 201 4 116 47
2016-02-13 02:50:40 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 3 0 9 201 4 116 47
2016-02-13 02:51:24 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 1 0 4 166 4 186 58
2016-02-13 02:51:24 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 1 0 4 166 4 186 58
2016-02-13 02:51:47 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 3 0 11 69 4 116 47
2016-02-13 02:51:48 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 3 0 11 69 4 116 47
2016-02-13 02:52:26 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 1 0 4 171 4 181 58
2016-02-13 02:52:26 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 1 0 4 171 4 181 58
2016-02-13 02:52:26 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 1 0 4 171 4 181 58
2016-02-13 02:52:26 JeeLink LaCrosseGateway.03 UNKNOWNCODE OK LS 1 0 4 171 4 181 58
2016-02-13 02:52:55 JeeLink LaCrosseGateway.03 UNKNOWNCODE OK LS 3 0 10 125 4 116 47
2016-02-13 02:52:55 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 3 0 10 125 4 116 47
2016-02-13 02:52:55 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 3 0 10 125 4 116 47
2016-02-13 02:53:29 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 1 0 4 176 4 181 58
2016-02-13 02:53:29 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 1 0 4 176 4 181 58
2016-02-13 02:54:02 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 3 0 11 29 4 116 47
2016-02-13 02:54:02 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 3 0 11 29 4 116 47
2016-02-13 02:54:31 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 1 0 4 176 4 181 60
2016-02-13 02:54:31 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 1 0 4 176 4 181 60
2016-02-13 02:55:09 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 3 0 10 190 4 116 47
2016-02-13 02:55:09 JeeLink LaCrosseGateway.03 UNKNOWNCODE OK LS 3 0 10 190 4 116 47
2016-02-13 02:55:09 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 3 0 10 190 4 116 47
2016-02-13 02:55:34 JeeLink LaCrosseGateway.03 UNKNOWNCODE OK LS 1 0 4 176 4 186 58
2016-02-13 02:55:34 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 1 0 4 176 4 186 58
2016-02-13 02:55:34 JeeLink LaCrosseGateway.01 UNKNOWNCODE OK LS 1 0 4 176 4 186 58
Ich vermute das die hier schon irgendwie 'anklopfen' aber warum auch immer nicht verarbeitet werden können wenn sie über das LGW ankommen.
Genug getestet für heute - bis später ;)
Moin!
Wenn die TFA Sensoren händisch angelegt werden, dann bekommen sie sofort Daten vom LGW. Werde versuchen zu ergründen warum autocreate hier nicht zieht.
Gruß
Mario
Zitat von: waschbaerbauch am 12 Februar 2016, 22:36:52
Vier NodeMCU erfolgreich geflasht. Allerdings bin ich immer nur auf den AccessPoint gekommen solange keine RFM69 auf dem Breadboard verdrahtet waren - ohne was dran lief es dann. Nach der Einrichtung der WiFi Daten dann wieder in den verdrahteten Teil des Breadboards gesteckt und lief.
Das ist ein seltsames Verhalten, das ich noch nie beobachtet habe. Ich teste es noch mal, habe schon länger keinen AP mehr gebraucht, weil die Konfigurationen beim mir alle stimmen.
Zitat von: waschbaerbauch am 12 Februar 2016, 22:36:52
- PCA301 wurden automatisch gefunden und per autocreate angelegt
- TX25IT Sensoren wurden automatisch erkannt und per autocreate angelegt
Gut.
Zitat von: waschbaerbauch am 12 Februar 2016, 22:36:52
- TX30.3155 werden nicht erkannt und somit auch nicht angelegt (mit einem JeeLink allerdings schon)
Die 30.3155 sind immer das Sorgenkind >:(
Ich habe hier aber zwei laufen, die das LGW verarbeitet.
Dass ein LaCrosser-Sensor per autocreate angelegt wird, muss er innerhalb 120 Sekunden zwei mal empfangen worden sein.
Evtl. liegen die ja mit der Frequenz daneben und kommen zu selten oder nicht?
Zitat von: waschbaerbauch am 12 Februar 2016, 22:36:52
- Levelsender werden ebenfalls nicht erkannt und auch nicht angelegt
Levelsender macht generell kein autocreate, weil, man hat die IDs ja beim Compilieren vergeben und kennt sie.
Zitat von: HCS am 13 Februar 2016, 11:11:46
Die 30.3155 sind immer das Sorgenkind >:(
Ich habe hier aber zwei laufen, die das LGW verarbeitet.
Dass ein LaCrosser-Sensor per autocreate angelegt wird, muss er innerhalb 120 Sekunden zwei mal empfangen worden sein.
Evtl. liegen die ja mit der Frequenz daneben und kommen zu selten oder nicht?
Ich schau mal ins Log für die 30.3155 und finde sie reporten eigentlich echt gut und häufig nachdem sie manuell definiert worden sind.
Die Frequenz war hier noch nie ein Problem, auch mit dem JeeLink selbst nicht. Alle 10 Stück liefern hier gute Daten bis ~ -40°C 8) ;D
2016-02-13_11:14:50 TFA.01 battery: ok
2016-02-13_11:14:50 TFA.01 temperature: 3.9
2016-02-13_11:14:50 TFA.01 humidity: 88
2016-02-13_11:15:00 TFA.01 battery: ok
2016-02-13_11:15:00 TFA.01 temperature: 4
2016-02-13_11:15:00 TFA.01 humidity: 88
2016-02-13_11:15:00 TFA.01 T: 4 H: 88
2016-02-13_11:15:05 TFA.01 battery: ok
2016-02-13_11:15:05 TFA.01 temperature: 3.9
2016-02-13_11:15:05 TFA.01 humidity: 88
2016-02-13_11:15:05 TFA.01 T: 3.9 H: 88
2016-02-13_11:15:10 TFA.01 battery: ok
2016-02-13_11:15:10 TFA.01 temperature: 4
2016-02-13_11:15:10 TFA.01 humidity: 88
2016-02-13_11:15:10 TFA.01 T: 4 H: 88
2016-02-13_11:15:15 TFA.01 battery: ok
2016-02-13_11:15:15 TFA.01 temperature: 3.9
2016-02-13_11:15:15 TFA.01 humidity: 87
2016-02-13_11:15:15 TFA.01 T: 3.9 H: 87
2016-02-13_11:15:20 TFA.01 battery: ok
2016-02-13_11:15:20 TFA.01 temperature: 4
2016-02-13_11:15:20 TFA.01 humidity: 88
2016-02-13_11:15:20 TFA.01 T: 4 H: 88
2016-02-13_11:15:25 TFA.01 battery: ok
2016-02-13_11:15:25 TFA.01 temperature: 4
2016-02-13_11:15:25 TFA.01 humidity: 88
2016-02-13_11:15:30 TFA.01 battery: ok
2016-02-13_11:15:30 TFA.01 temperature: 4
2016-02-13_11:15:30 TFA.01 humidity: 88
2016-02-13_11:15:40 TFA.01 battery: ok
2016-02-13_11:15:40 TFA.01 temperature: 4
2016-02-13_11:15:40 TFA.01 humidity: 88
2016-02-13_11:15:45 TFA.01 battery: ok
2016-02-13_11:15:45 TFA.01 temperature: 3.9
2016-02-13_11:15:45 TFA.01 humidity: 87
2016-02-13_11:15:45 TFA.01 T: 3.9 H: 87
2016-02-13_11:15:50 TFA.01 battery: ok
2016-02-13_11:15:50 TFA.01 temperature: 4
2016-02-13_11:15:50 TFA.01 humidity: 88
2016-02-13_11:15:50 TFA.01 T: 4 H: 88
2016-02-13_11:15:55 TFA.01 battery: ok
2016-02-13_11:15:55 TFA.01 temperature: 4
2016-02-13_11:15:55 TFA.01 humidity: 88
2016-02-13_11:16:00 TFA.01 battery: ok
2016-02-13_11:16:00 TFA.01 temperature: 4
2016-02-13_11:16:00 TFA.01 humidity: 88
2016-02-13_11:16:10 TFA.01 battery: ok
2016-02-13_11:16:10 TFA.01 temperature: 4
2016-02-13_11:16:10 TFA.01 humidity: 88
2016-02-13_11:16:20 TFA.01 battery: ok
2016-02-13_11:16:20 TFA.01 temperature: 4
2016-02-13_11:16:20 TFA.01 humidity: 88
2016-02-13_11:16:30 TFA.01 battery: ok
2016-02-13_11:16:30 TFA.01 temperature: 4
2016-02-13_11:16:30 TFA.01 humidity: 88
2016-02-13_11:16:40 TFA.01 battery: ok
2016-02-13_11:16:40 TFA.01 temperature: 4
2016-02-13_11:16:40 TFA.01 humidity: 88
2016-02-13_11:16:50 TFA.01 battery: ok
2016-02-13_11:16:50 TFA.01 temperature: 4
2016-02-13_11:16:50 TFA.01 humidity: 88
2016-02-13_11:17:00 TFA.01 battery: ok
Zitat von: HCS am 12 Februar 2016, 22:07:50
Aber lass mal, dieses Wochenende kommt eine neue OTA-Update Variante, bei der man es vom JeeLink-Modul aus schickt, ganz simpel mit "set myJeeLink flash", ohne HTTPSVR zu benötigen.
Mal ne Frage hierzu. Muss man irgendwas bei der Flash Definition im JeeLink Modul anpassen, oder geht das trotz der avrdude Konfiguration?
Zitat von: oli82 am 13 Februar 2016, 19:56:53
Mal ne Frage hierzu. Muss man irgendwas bei der Flash Definition im JeeLink Modul anpassen, oder geht das trotz der avrdude Konfiguration?
Das geht ohne jegliche Anpassung, es verwendet weder avrdude noch die Konfiguration davon.
Aber es funktioniert erst ab morgen weil der Fix für das JeeLink Modul erst morgen mit dem FHEM Update kommt. Und die Firmware auf dem LGW muss mindesten V1.15 sein. Man kann mir dieser Methode nicht von einer kleineren Version auf 1.15 updaten.
V1.15
Es gibt eine neue Variante für das OTA-Firmware-Update.
Mit
set myJeeLink flash
kann man die Firmware auf dem LGW aktualisieren. Dafür wird der HTTPSRV, der für die Variante, bei der man vom LGW-WebFrontend aus die Aktualisierung startet, nicht benötigt.
Voraussetzungen:
- FHEM muss auf dem aktuellen Stand von heute sein, da das JeeLink Modul angepasst wurde
- Die Firmware auf dem LGW muss mindestens V1.15 sein, man muss also die V1.15 nochmal mit einer der bisherigen Methoden draufschaffen, dass es zukünftig geht
- Das LGW muss auf der IP-Adresse, die im JeeLink Modul definiert ist, erreichbar sein
- Es wird kein avrdude benötigt
- Das Attribut "flashCommand" spielt keine Rolle
Nach einem "set myJeeLink flash" sieht das Ergebnis dann im Erfolgsfall so aus (dauert einige Sekunden, bis der Upload durch ist und es angezeigt wird):
flashing JeeLink myJeeLink210
detected Firmware: LaCrosseGateway.bin
hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
Mode is LaCrosseGateway OTA-update
myJeeLink210 closed
target: http://192.168.31.210/ota/firmware.bin
Sketch reports:
Start receiving 'firmware.bin'
Firmware size: 357680
Rebooting ESP8266 ...
OTA update finished
myJeeLink210 opened
Wer es testen will, kann sich die V1.15 per USB oder dem bisherigen OTA draufschaffen und dann mal einen "set myJeeLink flash" probieren.
Ändert zwar nicht aber es sollte durchlaufen.
Zitat von: HCS am 13 Februar 2016, 22:38:10
Aber es funktioniert erst ab morgen weil der Fix für das JeeLink Modul erst morgen mit dem FHEM Update kommt.
Danke. Das JeeLink Modul wurde mir schon Samstag Abend zum Update angeboten. Deshalb wollte ich mal nachfragen ;)
Zitat von: oli82 am 14 Februar 2016, 08:57:16
Danke. Das JeeLink Modul wurde mir schon Samstag Abend zum Update angeboten. Deshalb wollte ich mal nachfragen ;)
Das von gestern hatte noch einen Fehler, das von heute ist OK.
Ich wollte erst abwarten, bis die 1.15 und das JeeLink Modul durch das Update durch sind und dann damit nochmal testen, bevor ich die 1.15 ankündige.
Blöd, wenn es jemand schon vorher entdeckt :)
FTDI FT232RL vs. CP2102
Die letzten Tage habe ich eine interessante Beobachtung gemacht.
Ich hatte einen ESP-12E (also kein devkit) auf einem Breadboard per FTDI, auf dem ein FT232RL drauf ist, am Rechner angeschlossen.
Dabei hatte ich ständig Probleme:
- Upload ist nicht angesprungen, weil der ESP nicht in den Bootloader-Mode kam (manchmal)
- Upload ist nicht durchgelaufen (manchmal)
- Upload ist ohne Fehler durchgelaufen aber die Firmware ist nicht gelaufen (häufig)
Over all haben geschätzt höchstens 30% der Flash-Versuche (von geschätzten 100 insgesamt) zu einem lauffähigen Ergebnis geführt.
Das Ganze sowohl von einem Windows-Laptop aus als auch vom MacBook aus.
Den FTDI mit dem FT232RL gegen einen mit einem CP2102 getauscht und ab da keinerlei Probleme mehr.
Der FTDI mit dem FT232RL hat aber seit Ewigkeiten Arduinos ohne Probleme geflasht, der ist nicht defekt.
Wer also mit ähnlichen Problemen kämpft: mal mit einem CP2102 probieren.
Warum das so ist: keine Ahnung :(
Guten Morgen,
es funktioniert ;)
flashing JeeLink WlanJeeLink
detected Firmware: LaCrosseGateway.bin
hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
Mode is LaCrosseGateway OTA-update
WlanJeeLink closed
target: http://192.168.178.70/ota/firmware.bin
Sketch reports:
Start receiving 'firmware.bin'
Firmware size: 357680
Rebooting ESP8266 ...
OTA update finished
WlanJeeLink opened
Einen schönen Sonntag
PS: Vergesst nicht die Blumen für die Mädels ;) ;)
Gruß Werner
PPS: Ich habe dieses noch gefunden, nach Neustart im Logfile
Scalar value @spl[0] better written as $spl[0] at ./FHEM/36_JeeLink.pm line 259, <$fh> line 67.
ZitatIch wollte erst abwarten, bis die 1.15 und das JeeLink Modul durch das Update durch sind und dann damit nochmal testen, bevor ich die 1.15 ankündige.
Blöd, wenn es jemand schon vorher entdeckt :)
Habe es tatsächlich gestern im Rahmen eines Updates gesehen und dann auch gleich aktualisiert. Heute bekomme ich es aber beim "update check" nicht angeboten, da es anscheinend immer noch die Version 1.15 ist (obwohl geändert?).
Wo finde ich bitte jetzt die aktuelle 1.15? Danke (update force möchte ich deswegen nicht durchführen).
LG
Holger
flashing JeeLink LaCrosseGateway.01
detected Firmware: LaCrosseGateway.bin
hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
Mode is LaCrosseGateway OTA-update
LaCrosseGateway.01 closed
target: http://192.168.6.117/ota/firmware.bin
Sketch reports:
Start receiving 'firmware.bin'
Firmware size: 357680
Rebooting ESP8266 ...
OTA update finished
LaCrosseGateway.01 opened
---
flashing JeeLink LaCrosseGateway.02
detected Firmware: LaCrosseGateway.bin
hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
Mode is LaCrosseGateway OTA-update
LaCrosseGateway.02 closed
target: http://192.168.6.161/ota/firmware.bin
Sketch reports:
Start receiving 'firmware.bin'
Firmware size: 357680
Rebooting ESP8266 ...
OTA update finished
LaCrosseGateway.02 opened
-----
flashing JeeLink LaCrosseGateway.03
detected Firmware: LaCrosseGateway.bin
hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
Mode is LaCrosseGateway OTA-update
LaCrosseGateway.03 closed
target: http://192.168.6.108/ota/firmware.bin
Sketch reports:
Start receiving 'firmware.bin'
Firmware size: 357680
Rebooting ESP8266 ...
OTA update finished
LaCrosseGateway.03 opened
In meinem FHEM (Port 83) werden sie dann allerdings als disconnected geführt. Mit get LGWx initJeeLink gefolgt von einem set LGWx reset bekommt mein FHEM auch wieder mit das sie 'STATE = Initialized' sind.
Hallo waschbaerbauch,
das mit dem disconnected war bei mir auch, ich habe einfach einen moment gewartet ca. 5-10 sek. dann ist er selbst auf initialisiert gegangen.
Gruß Werner
Zitat von: Omega am 14 Februar 2016, 10:15:02
Habe es tatsächlich gestern im Rahmen eines Updates gesehen und dann auch gleich aktualisiert. Heute bekomme ich es aber beim "update check" nicht angeboten, da es anscheinend immer noch die Version 1.15 ist (obwohl geändert?).
Wo finde ich bitte jetzt die aktuelle 1.15? Danke (update force möchte ich deswegen nicht durchführen).
Die 1.15 war gestern schon aktuell, nur das JeeLink-Modul hat sich heute Nacht geändert.
Zitat von: Intruder1956 am 14 Februar 2016, 09:32:39
Scalar value @spl[0] better written as $spl[0] at ./FHEM/36_JeeLink.pm line 259, <$fh> line 67.
Ich schaue danach
Zitat von: waschbaerbauch am 14 Februar 2016, 10:42:17
In meinem FHEM (Port 83) werden sie dann allerdings als disconnected geführt. Mit get LGWx initJeeLink gefolgt von einem set LGWx reset bekommt mein FHEM auch wieder mit das sie 'STATE = Initialized' sind.
Nachdem die Firmware aktualisiert wurde, macht das LGW einen Reset.
Danach muss sich FHEM neu drauf verbinden.
Das dauert so lange, wie man das "timeout" Attribut von JeeLink device konfiguriert hat.
Wenn man das "timeout" Attribut von JeeLink device nicht gesetzt hat, passiert es nie.
Zitat von: Intruder1956 am 14 Februar 2016, 09:32:39
PS: Vergesst nicht die Blumen für die Mädels ;) ;)
Im Zeitalter der Emanzipation bekomme ich ESP-12Es von ihr und das mit den Blumen ist abgeschafft. ;D ;D ;D
Zitat von: HCS am 14 Februar 2016, 12:01:13
Nachdem die Firmware aktualisiert wurde, macht das LGW einen Reset.
Danach muss sich FHEM neu drauf verbinden.
Das dauert so lange, wie man das "timeout" Attribut von JeeLink device konfiguriert hat.
Wenn man das "timeout" Attribut von JeeLink device nicht gesetzt hat, passiert es nie.
Das ist die Erklärung! :)
Zitat
Im Zeitalter der Emanzipation bekomme ich ESP-12Es von ihr und das mit den Blumen ist abgeschafft. ;D ;D ;D
Hammer, hier lern ich was fürs Leben ;D
@HCS: fehlen die Dateien ESP8266OTA.h und ESP8266OTA.cpp im Quell-Code-ZIP?
Zitat von: habeIchVergessen am 14 Februar 2016, 14:14:32
@HCS: fehlen die Dateien ESP8266OTA.h und ESP8266OTA.cpp im Quell-Code-ZIP?
Jetzt sind sie drin.
Danke.
Hast du ggf. vergessen, in der Web-Oberfläche auch auf HTTP-POST umzustellen?
Zitat von: habeIchVergessen am 15 Februar 2016, 09:15:48
Hast du ggf. vergessen, in der Web-Oberfläche auch auf HTTP-POST umzustellen?
Nö, diese Variante funktioniert aktuell unverändert und ich will sie mittelfristig abschaffen, da es viel einfacher vom JeeLink Modul aus geht und zwei Varianten eigentlich nicht erforderlich sind.
Habe mir jetzt ein LGW mit 3x RFM69CW und 1x BMP180 zusammengelötet. Läuft auch, allerdings stoppt der Empfang von 2 EC3000 Steckdosen nach ein paar Stunden. Nur der Neustart des LGW hilft, um wieder für einige Zeit wieder was zu empfangen. Temp-Sensoren werden über Wochen ohne Probleme empfangen. Hat das Problem auch schon jemand beobachtet? Eine Idee woran das liegen könnte?
Zitat von: BlackFlag am 24 Februar 2016, 17:39:56
Läuft auch, allerdings stoppt der Empfang von 2 EC3000 Steckdosen nach ein paar Stunden. Nur der Neustart des LGW hilft, um wieder für einige Zeit wieder was zu empfangen. Temp-Sensoren werden über Wochen ohne Probleme empfangen. Hat das Problem auch schon jemand beobachtet? Eine Idee woran das liegen könnte?
Aktuell habe ich keinerlei Idee, meine zwei EC3000 liefern auf dem Produktivsystem seit einer Woche (da war der letzte Reboot) laut den Logs permanent Daten.
Da hilft nur rumprobieren.
Kannst z.B. mal ein anderes Radio für die EC3000 setzten, ob es dann OK ist.
Häng mal noch ein list vom jeelink device an.
Also ich habe schon Tage mit mir gehadert ob ich fragen soll oder nicht ..
Mit meinen LaCrosseGateways bin ich soweit echt zufrieden, aber irgendwie meinte die Dame des Hauses 'Wieso geht die Steckdose nicht mehr zu schalten?' ... uuuuund Action! :D
Ich hab ja nun eine Menge von den PCA301 hier laufen und mit den JeeLink Sticks (868950) lief das auch soweit alles recht gut. Als ich das LGW zusammengesteckt und geflasht hatte, da wurden ja auch fleißig Dosen eingesammelt, aber irgendwie werden die in letzter Zeit nicht mehr so recht oder besser schlecht empfangen. Ich hab mir hier nun schon die Finger puzzelig geschnitten (Antennen aus Draht in aller Herren Längen und Ausprägungen) und getippt ( Radio 1, 2 oder 3 mit 868900 - 869100 in 5er Schritten..) um irgendwie der Probleme Herr zu werden, aber im Moment zeigen mit die LGWs gefühlt den Mittelfinger ;D
Am Anfang dachte ich noch - ok vielleicht sind es doch Kontaktprobleme mit den Pinheader Stiften, aber selbst anlöten von Drähten die dann ins Breadboard kommen lösen diese Probleme nicht. Es ist ja nicht so als würden sie gar nichts empfangen, nur im Vergleich zu den USB JeeLinks deutlich zu wenig. Hat noch jemand Tipps für mich?
Danke und Gruß
Mario
Ich habe momentan auch leichte Empfangsprobleme.
Parallel teste ich ja auch viel mit MySensors - und die ganzen Teile liegen doch alle recht nahe beieinander (im Umkreis von 1 m habe ich 4 Sensoren, 3 davon nur ca. 30cm entfernt). Von daher vermute ich hier einen Zusammenhang.
Morgen werde ich mal das LGW woanders aufbauen - läuft ansonsten sehr stabil und klaglos - bis auf die 3 neuen PCA301-Dosen, die ich real gar nicht habe (Device löschen, Log löschen, Log im Filesystem löschen).
Zitat von: Omega am 24 Februar 2016, 22:49:06
bis auf die 3 neuen PCA301-Dosen, die ich real gar nicht habe (Device löschen, Log löschen, Log im Filesystem löschen).
Die Phantom-PCAs habe ich auf der Agenda. Bin nur noch nicht ganz schlau, wie ich zusätzlich zum CRC die Erkennung von Phantom-Paketen (==HF-Müll) verbessern kann.
Zitat von: waschbaerbauch am 24 Februar 2016, 21:08:21
aber irgendwie werden die in letzter Zeit nicht mehr so recht oder besser schlecht empfangen.
Dann arbeiten wir mal meinen Fragenkatalog ab:
Hast Du parallel auch eine Basisstation oder einen JeeLink-PCA301-Sketch laufen?
Sind es nur bestimmte PCAs, die betroffen sind oder geht mal die eine und mal die andere nicht?
Bedeutet "in letzter Zeit nicht mehr so recht", dass es auch mit dem LGW schon mal besser ging?
Bekommst Du Daten von den "Problemdosen", wenn Du sie vor Ort schaltest?
RFM12, RFM69CW oder RFM69HW, oder ... ?
Wie viele Dosen sind das insgesamt?
Zitat von: HCS am 25 Februar 2016, 07:33:08
Dann arbeiten wir mal meinen Fragenkatalog ab:
Hast Du parallel auch eine Basisstation oder einen JeeLink-PCA301-Sketch laufen?
Basisstation vorhanden, aber noch nie verwendet - die kann ja nur acht verwalten. Alle/beide JeeLink Adapter mit PCA301 Sketch aus der Konfiguration entfernt/disconnected. Aktuell habe ich zwei FHEM Instanzen laufen, eine als PROD und eine als EVAL. In der PROD sind drei LGW über Port 81 eingebunden, in der EVAL über Port 83 nur das 'LaCrosseGateway.01' - so kann ich dann besser sehen was an Daten ankommt auf diesem einen Gateway ohne immer gucken zu müssen bei jeder Dose von welchem Gateway denn die letzten Informationen eingetrudelt sind.
Die Konfiguration ist wie folgt:
LaCrosseGateway.01: [LaCrosseITPlusReader.Gateway.1.15 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868990 r:6631) + (3=RFM69 f:868300 r:9579) {IP=192.168.6.117}]
LaCrosseGateway.02: [LaCrosseITPlusReader.Gateway.1.15 (1=RFM69 f:868300 r:9579) + (2=RFM69 f:868980 r:6631) {IP=192.168.6.161}]
LaCrosseGateway.03: [LaCrosseITPlusReader.Gateway.1.15 (1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 r:9579) {IP=192.168.6.108}]
ZitatSind es nur bestimmte PCAs, die betroffen sind oder geht mal die eine und mal die andere nicht?
Beim ändern der Frequenzen scheinen einige irgendwie überall Daten zu senden, andere Dosen wiederum nur in bestimmten Bereichen. Aber selbst wenn ich Daten im FHEM Eventlog bekomme, dann kann ich die entsprechende Dose nicht (immer) via FHEM schalten. Ich muss allerdings zugeben, das ich bzgl. des schalten hier einen Tunnelblick hatte auf ein bis zwei Dosen hatte. Ich werde in meiner Mittagspause und heute Abend mal sehen ob ich da qualifiziertere Aussagen machen kann.
ZitatBedeutet "in letzter Zeit nicht mehr so recht", dass es auch mit dem LGW schon mal besser ging?
Subjektiv hätte ich spontan mit ja geantwortet, weil es beim ersten Zusammenstecken auf dem Breadboard sofort Daten gab und Dosen angelegt wurden. Da du aber sicherlich von V1.13 zu V1.15 nichts in dieser Richtung geändert hast ist das sicherlich Einbildung. Ich habe allerdings keine V1.13 Firmware mehr um diese zu flashen und das parallel zu testen.
ZitatBekommst Du Daten von den "Problemdosen", wenn Du sie vor Ort schaltest?
Gute Frage, kann ich grad nicht beantworten. Ich werde das mal mit in mein 'Testszenario' aufnehmen.
ZitatRFM12, RFM69CW oder RFM69HW, oder ... ?
Eine Charge von acht RFM69CW (AliExpress)
ZitatWie viele Dosen sind das insgesamt?
In Summe hatte ich 30 Dosen aktiv, am Wochenende aber mal 'aufgeräumt' und aktuell im Haus verteilt noch 23 aktiv.
Zitat von: HCS am 24 Februar 2016, 20:01:26
Häng mal noch ein list vom jeelink device an.
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF 192.168.1.82:81
DeviceName 192.168.1.82:81
FD 28
LGW2_MSGCNT 16
LGW2_TIME 2016-02-25 10:53:07
NAME LGW2
NR 93
PARTIAL
RAWMSG OK WS 0 4 4 166 255 255 255 255 255 255 255 255 255 0 3 237
STATE opened
TYPE JeeLink
model [LaCrosseITPlusReader.Gateway.1.15 (1=RFM69 f:0 r:17241) + (2=RFM69 f:868300 r:9579) + (3=RFM69 f:868300 r:20000) + BMP180 {IP=192.168.1.82}]
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-02-25 10:53:07 state opened
Attributes:
initCommands 20000#3r
room LaCrosse
timeout 120,60
Kann es sein, dass das LGW sich bei mir vielleicht zwichendurch mal resettet und dann die initCommands nicht gesetzt werden? Bei mir war der 3. RFM wieder mit den defaults initialisiert. Habe mal FHEM neu gestartet, dadurch ist das LGW wieder richtig initialisiert.
Bei der Gelegenheit mal die Frage, mit welchem FHEM-Befehl ich das LGW von Hand initialisieren kann, ohne FHEM neu starten zu müssen?
Und wo finde ich eine Liste aller initCommands, mit denen ich das LGW initialisieren kann?
Uff, wer viel fragt bekommt viel Antwort :)
Warum habe denn keine mails über diese neuen Beiträge vom Forum bekommen?
Zitat von: waschbaerbauch am 25 Februar 2016, 09:32:10
Die Konfiguration ist wie folgt:
LaCrosseGateway.01: [LaCrosseITPlusReader.Gateway.1.15 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868990 r:6631) + (3=RFM69 f:868300 r:9579) {IP=192.168.6.117}]
LaCrosseGateway.02: [LaCrosseITPlusReader.Gateway.1.15 (1=RFM69 f:868300 r:9579) + (2=RFM69 f:868980 r:6631) {IP=192.168.6.161}]
LaCrosseGateway.03: [LaCrosseITPlusReader.Gateway.1.15 (1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 r:9579) {IP=192.168.6.108}]
Das ist ein Szenario, das ich noch nie getestet habe und bei dem ich mir nicht sicher bin, ob es aktuell hinhaut.
Da könnte folgendes passieren: LGW1 kennt eine Dose, sendet eine Anfrage und hört keine Antwort, probiert es also drei mal. Und LGW2 hört etwas von der Dose, frägt bei der Dose nach und wird von LGW1 plattgebügelt, das gerade seinen zweiten Versuch macht. Und da dritte spielt auch irgendwie mit. Oder so ähnlich halt.
Kannst Du mal probieren, ob das mit genau nur einem LGW korrekt funktioniert?
Dein Eindruck, dass es ganz zu Beginn alles empfangen hat, würde das evtl. bestätigen, denn da lief vermutlich nur ein LGW.
Zitat von: BlackFlag am 25 Februar 2016, 11:02:04
(1=RFM69 f:0 r:17241)
Nanu, wie kommt denn die Frequenz auf Null für das erste Radio?
Zitat von: BlackFlag am 25 Februar 2016, 11:02:04
Readings:
2016-02-25 10:53:07 state opened
Sollte initialized sein. Es gab einen Bugfix im JeeLink-Modul, mach mal ein FHEM-Update.
Zitat von: BlackFlag am 25 Februar 2016, 11:02:04
Kann es sein, dass das LGW sich bei mir vielleicht zwichendurch mal resettet und dann die initCommands nicht gesetzt werden?
Das sollte es eigentlich nicht, aber wenn es stecken bleibt, dann startet es der interne watchdog neu.
Aber wenn FHEM sich (timeout hast Du ja korrekt gesetzt) wieder verbindet, müssen auch die initCommand neu geschickt werden.
Beobachte das nochmal mit dem aktuellen JeeLink Modul.
Das LGW übermittelt ja per KVP u.A wie lange es Up ist, da kann man sehen, ob es zwischendurch mal gebootet hat.
Zitat von: BlackFlag am 25 Februar 2016, 11:02:04
Bei der Gelegenheit mal die Frage, mit welchem FHEM-Befehl ich das LGW von Hand initialisieren kann, ohne FHEM neu starten zu müssen?
set LGW2 reset
Zitat von: BlackFlag am 25 Februar 2016, 11:02:04
Und wo finde ich eine Liste aller initCommands, mit denen ich das LGW initialisieren kann?
Hier:
<n>a set to 0 if the blue LED bothers
<n>c use one of the possible data rates (for transmit on RFM #1)
<n>d set to 1 to see debug messages
<8266>e Clear EEPROM
<n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515)
<n>h Altitude
<n,f,i>i Init PCA for Radio #<n> to <m>MHz and <i>s Interval
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #1)
<n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #2)
<n>#<x>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #x)
<n>o set HF-parameter e.g. 50305o for RFM12 or 1,4o for RFM69
<n>p payload on the serial port (1: all, 2: only undecoded data)
<n>r use one of the possible data rates (for RFM #1)
<n>R use one of the possible data rates (for RFM #2)
<n>#<x>r use one of the possible data rates (for RFM #x)
<x,x,...>s Send to PCA301 (must be 10 byte)
<x,x,...>S Send to CustomSensor
<n>t 0=no toggle, else interval in seconds (for RFM #1)
<n>T 0=no toggle, else interval in seconds (for RFM #2)
<n>#<x>t 0=no toggle, else interval in seconds (for RFM #x)
v show version
<n>w 0=no wifi
<n>z set to 1 to display analyzed frame data instead of the normal data
Zitat von: HCS am 25 Februar 2016, 21:43:46
Uff, wer viel fragt bekommt viel Antwort :)
Warum habe denn keine mails über diese neuen Beiträge vom Forum bekommen?
Das ist ein Szenario, das ich noch nie getestet habe und bei dem ich mir nicht sicher bin, ob es aktuell hinhaut.
Da könnte folgendes passieren: LGW1 kennt eine Dose, sendet eine Anfrage und hört keine Antwort, probiert es also drei mal. Und LGW2 hört etwas von der Dose, frägt bei der Dose nach und wird von LGW1 plattgebügelt, das gerade seinen zweiten Versuch macht. Und da dritte spielt auch irgendwie mit. Oder so ähnlich halt.
Kannst Du mal probieren, ob das mit genau nur einem LGW korrekt funktioniert?
Dein Eindruck, dass es ganz zu Beginn alles empfangen hat, würde das evtl. bestätigen, denn da lief vermutlich nur ein LGW.
LGW1 steht aktuell im Wohnzimmer, LGW2 oben im Dachgeschoss im derzeitigen Home-Office und LGW3 halt hinten im Anbau um den Rest vom Hof/Outdoor zu erreichen. LGW3 hab ich grad mal abgebaut, LGW2 im DG kann ich grad nicht mehr ran, dann weck ich bestimmt den Nachwuchs und das möchte ich grad nicht so kurz vorm Wochenende ;)
Ich probiere das mal mit LGW2 im DG und LGW1 im Wohnzimmer. Die Frage ist nun, müssen die LGWs komplett vom Strom oder reicht es aus sie aus dem FHEM zu entfernen? Wäre es sonst (um heute noch etwas zu machen) eine Möglichkeit alle beiden Radios vom LGW2 auf 'nicht PCA301' zu konfigurieren? Dann dürfte LGW2 doch auch schon nicht mehr in die Suppe spucken?!
Gruß
Mario
Zitat von: HCS am 25 Februar 2016, 21:43:46
Nanu, wie kommt denn die Frequenz auf Null für das erste Radio?
Sollte initialized sein. Es gab einen Bugfix im JeeLink-Modul, mach mal ein FHEM-Update.
Nach Update ist es jetzt initialized
Zitat von: HCS am 25 Februar 2016, 21:43:46
Das sollte es eigentlich nicht, aber wenn es stecken bleibt, dann startet es der interne watchdog neu.
Das LGW scheint nicht stecken zu bleiben. KVP lief durch. LGW läuft jetzt seit 20h, aber gestern um 23:08 (nach ca. 8h) hat es das letzte Mal was von den EC3000 empfangen.
Ein "set LGW2 reset" schickt wohl nur das initCommand neu, denn die Laufzeit des LGW wurde nicht auf 0 zurückgesetzt. Daher habe ich jetzt auf der Webseite des LGW ein "Save und restart" ausgeführt. Nun empfängt es wieder die EC3000 für ein paar Stunden.
Update: Hat gerade mal bis 13:43 gehalten. Jetzt habe ich wieder das LGW restartet und die EC3000 werden wieder empfangen. Ein list LGW2 zeigt, dass angeblich gar kein RFM mit eine Rate von 20000 initialisiert ist, empfängt die EC3000 aber trotzdem. Alles sehr merkwürdig.
model [LaCrosseITPlusReader.Gateway.1.15 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + (3=RFM69 f:868300 r:8842) + BMP180 {IP=192.168.1.82}]
Zitat von: BlackFlag am 26 Februar 2016, 12:08:20
Ein "set LGW2 reset" schickt wohl nur das initCommand neu, denn die Laufzeit des LGW wurde nicht auf 0 zurückgesetzt.
Korrekt, es wird nur die Verbndung zum LGW abgebaut und neu aufgebaut und initCommands geschickt.
Zitat von: BlackFlag am 26 Februar 2016, 12:08:20
Daher habe ich jetzt auf der Webseite des LGW ein "Save und restart" ausgeführt. Nun empfängt es wieder die EC3000 für ein paar Stunden.
Es gibt noch eine "Geheimvariante" wie man bei LGW einen Reset auslösen kann: 192.168.31.18/reset
Zitat von: BlackFlag am 26 Februar 2016, 12:08:20Alles sehr merkwürdig.
Allerdings.
Ein Unterschied ist, dass ich die EC3000 in einem toggle mir drin habe. Probier mal den hier (auch wenn es bei Dir keinen Sinn ergibt):
11#3m 20#3t
Zitat von: waschbaerbauch am 25 Februar 2016, 22:15:41
Die Frage ist nun, müssen die LGWs komplett vom Strom oder reicht es aus sie aus dem FHEM zu entfernen? Wäre es sonst (um heute noch etwas zu machen) eine Möglichkeit alle beiden Radios vom LGW2 auf 'nicht PCA301' zu konfigurieren?
Aus FHEM entfernen reicht nicht. Die arbeiten ganz ohne FHEM unbeeindruckt weiter.
Entweder von Strom trennen (die absoult sichere Methode) oder in FHEM wegkonfigurieren.
Aber inzwischen wird der Nachwuchs ja auch mal wach gewesen seine :)
Ok ich hatte weg konfiguriert und heute dann abbauen können. Da der Nachwuchs aber nicht nur wach war, sondern mich auch schon wieder infiziert hatte habe ich heute eher flach gelegen und arbeitgeberfreundlich meine Freizeit in Gesundheitspflege investiert. Soeben ist die nachgeholte Geburtstagsfeier zu Ende gegangen und morgen werde ich hoffentlich mehr Zeit und Energie haben dem Phänomen auf den Grund zu gehen..
Den Zoo werden wir schon noch bändigen :D :D :D
Ah so ... das ist also eine strukturierte Verkabelung ... aber ... alles schön symetrisch zusammengebunden :)
Das geht bestimmt schöner, aber für den Moment als Testcenter im Wohnzimmer muss das reichen :D
Schönes blaues Licht ... was macht den das blaue Licht? .... es leuchtet blau
8)
Und es zeigt die Spannung an und den aktuellen Stromverbrauch und den gesamten Verbrauch bis 9999mAh und die Zeit ;)
Die neuen Spielzeuge (http://www.aliexpress.com/item/New-USB-Charger-Doctor-Mobile-Power-Detector-Battery-Test-Voltage-Current-Meter/32515259322.html) vom Chinesen des Vertrauens ;)
Zu den Antennen: wenn ich richtig schätze und rechne, dann sind die 25cm lang.
868.350 kHz ist eine Wellenlänge von 34,5 cm und λ/4 wären 86mm
Wie kommst Du denn zu 25cm?
Und das Antennensignal durch das breadbord zu schicken ist sicher auch nicht förderlich.
Nachtrag: PCA301 sendet auf 868.950 und nicht auf 868.350 wie waschbaerbauch weiter unten völlig richtig angemerkt hat.
Also nicht verwirren lassen ...
Thema Antennen:
Ja das ist jetzt etwas verwirrend. Auf dem Foto sind ja nur die SIGNALduino|FHEMduino|PIRduino(AliRF) zu sehen. Die laufen ja mit dem Superhet auf 433MHz. Die Länge der Antennen beträgt hier 164mm inkl. dem Teil der im Breadboard steckt. Der Empfang der 433Mhz Signale läuft eigentlich gut.
Anbei sind jetzt mal die LGWs zu sehen. Die Experimente mit den Längen der Antennen kann man hier ggf. erkennen.
Beim LGW1 ist das Radio 3 mit direkt eingelöteter Antenne zu sehen, diese hat eine Länge von 86mm.
Für Radio 1 und Radio 2 hatte ich zuerst auch 86mm, dann aber aus dem erwähnten Grund der 'Verlängerung der Strecke' durch Breadboard und Aufbau des Adapters auf bis zu 77mm gekürzt. Vermutlich war das aber nicht so die beste Idee ;)
Bei den anderen LGWs hatte ich auch noch Längen von 164mm, 86mm, 82/83mm getestet - allerdings alles über den Weg des Breadboards und nicht fest angelötet.
Für Vorschläge (Nackenschläge) und Anleitung zur Verbesserung bin ich natürlich zu haben ;)
PS: Für die Längen hatte ich mich am Gummibaer-Blog orientiert.
ZitatIst keine Antenne dabei, kann sie aus Draht selbst hergestellt werden. Dabei sollte folgende Tabelle beachtet werden.
433 Mhz 164,7mm
868 Mhz 82,2mm
Zu den Frequenzen:
Ich hab da doch noch mal eine oder zwei Fragen..
@HCS
Du hattest geschrieben '868.350 kHz' wäre die korrekte Frequenz, aber laufen die PCA301 (lt. Wiki) nicht auf 868.950 kHz bzw. 868.960/868.970 kHz?
Die Antennen habe ich nun ohne Breadboard direkt auf dem RFM69CW angelötet und mich bei der Länge nach den 86mm gerichtet.
Zitat von: waschbaerbauch am 28 Februar 2016, 13:50:00
Du hattest geschrieben '868.350 kHz' wäre die korrekte Frequenz, aber laufen die PCA301 (lt. Wiki) nicht auf 868.950 kHz bzw. 868.960/868.970 kHz?
Klar, jetzt wo ich nicht mehr nüchtern bin sehe ich es auch ???
Natürlich sendet PCA301 auf 868.950. Keine Ahnung, wie ich auf 868.350 kam. Aber so oder so ist das das 35cm Band.
Zitat von: waschbaerbauch am 28 Februar 2016, 13:50:00
Die Antennen habe ich nun ohne Breadboard direkt auf dem RFM69CW angelötet und mich bei der Länge nach den 86mm gerichtet.
Jetzt sind wir gespannt, was mit den Antennen und genau nur einem LGW passiert.
Zitat von: HCS am 28 Februar 2016, 16:21:20
Klar, jetzt wo ich nicht mehr nüchtern bin sehe ich es auch ???
Ähm ja - okay *hust* PROST ;)
ZitatJetzt sind wir gespannt, was mit den Antennen und genau nur einem LGW passiert.
Ja das war ich auch! So ganz empfange ich noch nicht alles, aber eine ganze Menge Dosen. Nachdem ich ja zwischenzeitlich bei meinen Versuchen so gut wie nix mehr empfangen hatte kann ich jetzt wieder was empfangen, senden und ich bekomme sogar wieder Antworten auf den Status-Request. Eigentlich wollte ich das erst nur stecken damit ich die Teile dann quasi jungfräulich auf die Platinen auflöten kann, aber so ist es mir jetzt auch recht. Der WAF ist wieder gestiegen und ich darf weiter puzzeln 8)
Zitat von: HCS am 27 Februar 2016, 18:00:08
Ein Unterschied ist, dass ich die EC3000 in einem toggle mir drin habe. Probier mal den hier (auch wenn es bei Dir keinen Sinn ergibt):
11#3m 20#3t
Das scheint besser zu laufen. Seit gestern empfange ich nun die EC3000 ohne Unterbrechung (bis auf alle 30sek ;-). Was heißt das jetzt?
Ist hier jemand der dediziert einen RFM69 nur für die EC3000 ohne Toggle benutzt und damit keine Empfangsprobleme hat?
Zitat von: BlackFlag am 29 Februar 2016, 10:27:37
Was heißt das jetzt?
Das ist mir auch noch nicht klar. Dachte noch "wäre seltsam, wenn es dann geht". Aber es war der offensichtlichste Unterschied.
Zitat von: BlackFlag am 29 Februar 2016, 10:27:37
Ist hier jemand der dediziert einen RFM69 nur für die EC3000 ohne Toggle benutzt und damit keine Empfangsprobleme hat?
Ich kann mal ein Testsystem so einrichten und schauen, ob ich das reproduzieren kann.
Zitat von: HCS am 29 Februar 2016, 12:11:19
Ich kann mal ein Testsystem so einrichten und schauen, ob ich das reproduzieren kann.
Getan.
model [LaCrosseITPlusReader.Gateway.1.16 (1=RFM12 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + (3=RFM69 f:868300 r:20000) ...
initCommands 20000#3r vSeit heute 12:30 durchgehend Daten. Ich lasse es mal weiter laufen, glaube aber nicht, dass das noch ausfällt.
Nachtrag 01.03.16 12:14: Daten kommen nun seit 24 Stunden unterbrechungsfrei
Zitat von: HCS am 29 Februar 2016, 21:51:46
Seit heute 12:30 durchgehend Daten. Ich lasse es mal weiter laufen, glaube aber nicht, dass das noch ausfällt.
Nachtrag 01.03.16 12:14: Daten kommen nun seit 24 Stunden unterbrechungsfrei
Ich habe bei mir mal den 2. RFM69 für die EC3000 umkonfiguriert und seit dem empfange ich die EC3000 (mind. schon 24h) unterbrechungsfrei. Also entweder ist der 3. bei mir kaputt, oder in der Firmware stimmt was mit dem 3. nicht.
Noch mal eine Frage zur Initialisierung mit initCommands. Wird das initCommand auf dem LGW gespeichert, damit bei einem Neustart dieser sich so initialisiert wie vorher? Weil bei mir hat es sich irgendwie Teile der vorherigen Initialisierung gemerkt (dein InitCommand mit toggle, jetzt meiner mit dem 2. RFM69 auf 20000):
initCommands 34h 20000#2r 9579#3r
model [LaCrosseITPlusReader.Gateway.1.15 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:20000) + (3=RFM69 f:868300 t:20~11) + BMP180 {IP=192.168.1.82}]
Zitat von: BlackFlag am 02 März 2016, 10:20:22Also entweder ist der 3. bei mir kaputt, oder in der Firmware stimmt was mit dem 3. nicht.
Ich habe ja auch den dritten genommen, für meinen Test (der immer noch läuft)
Generell hatte ich auch mit dem dritten nie irgendwelche generellen Auffälligkeiten
Es gab aber auch schon beim JeeLink Sketch Fälle, bei denen berichtet wurde, dass ein RFM plötlich den Betrieb einstellt und es nach einer neuen Initialisierung wieder geht.
Du kannst ja mal die ChipSelects von Radio 2 und 3 vertauschen und schauen, ob es dann auf dem dritten funktioniert und auf dem zweiten nicht mehr.
Zitat von: BlackFlag am 02 März 2016, 10:20:22Noch mal eine Frage zur Initialisierung mit initCommands. Wird das initCommand auf dem LGW gespeichert, damit bei einem Neustart dieser sich so initialisiert wie vorher? Weil bei mir hat es sich irgendwie Teile der vorherigen Initialisierung gemerkt (dein InitCommand mit toggle, jetzt meiner mit dem 2. RFM69 auf 20000):
Alle Einstellungen (Frequenz, data rate, ...) bleiben auf dem LGW bis zu seinem nächsten Reset erhalten.
Ein
set myJeeLink reset macht nur einen Neuaufbau der Verbindung zum LGW und schickt die initCommands aber resettet das LGW nicht
Wenn initCommands geschickt werden, wird genau nur das gesetzt, was in den initCommands drin steht, der Rest bleibt, wie er ist.
Darum ist es sinnvoll, die komplette Konfiguration für alle drei RFMs in die initCommands zu packen, und nicht davon auszugehen, dass etwas, das der default des LGW ist, tasächlich noch so ist.
Ankündigung
Ab der kommenden Verison 1.16 wird das LGW den RFM12 nicht mehr unterstützen, nur noch den RFM69.
Grund: der RFM12 hat nur zwei Byte FIFO und kann von keinem Sensor ein Paket komplett im FiFO puffern.
Es wird aber zusehens unmöglich, es vom Timing her hinzubekommen (und in allen Varianten zu testen), den RFM12 passend abzufragen.
Der RFM69 hat einen 66 Byte großen FIFO, womit sich diese Problematik nicht stellt.
Vielen Dank für die Info, die ist extrem wichtig für mich. Da muss ich handeln!
Die Erklärung macht Sinn und es ist ein logischer Schritt, aber schade.
Erst die Abkündigung des DHT Sensors und nun auch noch die RFM12... never lucky :'(
Dennoch machst du eine tolle Arbeit, das Gateway ist ein super Teil, weiter so :)
Zitat von: Doublefant am 13 März 2016, 14:01:19
Erst die Abkündigung des DHT Sensors und nun auch noch die RFM12
Nunja, das ist ein 3EUR Bauteil und es gibt ja zum Glück ( :) :) ) noch keine Platinen von denen man den 12er wieder runter löten muss.
Dafür gibt es dann ab 1.16 die Möglichkeit, das LGW mit einem SubProzessor zu erweitern (z.B. einem Arduino pro mini) und an den kann man ja dann einen DHT dranpacken. Den SubProzessor kann man OTA mit einem simplen Upload über das LGW flashen und er bietet die Möglichkeit, alles was man sich schon immer gewünscht hat, dranzupacken und mit einem sehr einfachen seriellen Protokoll dem LGW zu übermitteln, das es dann an FHEM zustellt.
Und da sich aus der Erweiterung mit dem dafür verwendeten SC16IS750 noch einige Digitalports ergeben haben, besteht die Möglichkeit, einen vierten und fünften RFM69 anzuschließen.
Mein aktuelles Setup:
Radio #1 PCA301 (868.960 kHz / 6631 kbps)
Radio #2 WS 1600 (8.842 kbps)
Radio #3 EC3000 (20.000 kbps)
Radio #4 TX29xx und LevelSender (17.241 kbps)
Radio #5 TX35 und EMT7110 (9.579 kbps)
Mit diesem Gateway strebst du die Weltherrschaft an!? ;D ;D ;D
Zitat von: HCS am 13 März 2016, 23:48:47
Dafür gibt es dann ab 1.16 die Möglichkeit, das LGW mit einem SubProzessor zu erweitern (z.B. einem Arduino pro mini)
Wahnsinn, meine Trägheit das endgültige GW bis jetzt noch nicht zusammen zu löten wird auch noch belohnt :)
Zitat von: HCS am 13 März 2016, 23:48:47
Nunja, das ist ein 3EUR Bauteil und es gibt ja zum Glück ( :) :) ) noch keine Platinen von denen man den 12er wieder runter löten muss.
Habe den Hinweis verstanden: nächste Woche ist Urlaub angesagt, da will ich das Layout fertig machen ;)
Zitat von: HCS am 13 März 2016, 23:48:47
Dafür gibt es dann ab 1.16 die Möglichkeit, das LGW mit einem SubProzessor zu erweitern (z.B. einem Arduino pro mini) und an den kann man ja dann einen DHT dranpacken.
Ändert sich dadurch etwas am Schaltplan?
Gruß PeMue
Zitat von: waschbaerbauch am 14 März 2016, 00:02:00
Mit diesem Gateway strebst du die Weltherrschaft an!? ;D ;D ;D
Nein, lt. Hersteller hat LaCrosse nur eine Reichweite von 100 Metern ;D ;D
Zitat von: PeMue am 14 März 2016, 07:57:12
Habe den Hinweis verstanden
Ist schon OK so, wenn jemand einen 12er von der coolen Platine hätte runterlöten müssen, hätte ich ein noch schlechteres Gewissen.
Ich habe die 12er Unterstützung auch nicht explizit ausgebaut, es kann schon sein, dass es noch Szenarien gibt, wo es klappt, nur offiziell ist er nicht mehr drin und ich teste auch nicht mehr mit 12ern.
Gerade der Testaufwand, um alle Kombinationen und Features auch mit dem 12er zu testen und lauffähig zu bekommen, war erheblich.
Die Zeit kann ich sinnvoller in Bugfixes, Verbesserungen und Features investieren.
Zitat von: PeMue am 14 März 2016, 07:57:12
Ändert sich dadurch etwas am Schaltplan?
Nein, keine Änderung an der Grundplatine, das spielt sich alles auf einer optionalen AddOn-Platine ab, die auf die Pfosten gesteckt wird und SPI, I2C, Reset und Spannung braucht.
Servus,
ich habe eine Frage zum EC3000. Ich hätte gerne, dass dieser ähnlich wie die PCA301's funktiort, das heißt, dass ich diese um Mitternacht "resetten" kann, damit die consumption zurückgesetzt wird. Wenn ich das Reading manuell auf "0" setze, dann wirds beim nächsten Update der Steckdose wieder mit dem neuen Wert, der kontinuierlich wächst, überschrieben.
Hat dies jemand von euch irgendwie implementiert, oder muss ich wirklich noch ein userReading consumption_today anlegen, damit das klappt?
Zur Zeit habe ich meine EC3000-Steckdosen so integriert:
Internals:
DEF 7A1E
EC3000_lastRcv 2016-03-19 19:29:40
IODev myJeeLink
LASTInputDev myJeeLink
MSGCNT 3142
NAME EC3000_1
NR 334
STATE Jetzt 2.7 W, Max 390.8 W, Verbrauch 8.229 kwh
TYPE EC3000
addr 7A1E
myJeeLink_MSGCNT 3142
myJeeLink_RAWMSG OK 22 122 30 0 13 25 225 0 13 25 191 0 0 32 37 0 27 15 68 1 0
myJeeLink_TIME 2016-03-19 19:29:40
reception 0
resets 1
secondsOn 858559
secondsTotal 858593
Helper:
Dblog:
Consumption:
Logdb:
TIME 1458411938.5024
VALUE 8.229
Consumptioneuro:
Logdb:
TIME 1458411938.5024
VALUE 2.04
Consumptionmonth:
Logdb:
TIME 1458411938.5024
VALUE 14.299
Consumptionmontheuro:
Logdb:
TIME 1458411938.5024
VALUE 3.55
Consumptiontotal:
Logdb:
TIME 1458411938.5024
VALUE 14.299
Consumptiontotaleuro:
Logdb:
TIME 1458411938.5024
VALUE 3.55
Consumptionweek:
Logdb:
TIME 1458411938.5024
VALUE 14.299
Consumptionweekeuro:
Logdb:
TIME 1458411938.5024
VALUE 3.55
Consumptionyear:
Logdb:
TIME 1458411938.5024
VALUE 14.299
Consumptionyeareuro:
Logdb:
TIME 1458411938.5024
VALUE 3.55
Power:
Logdb:
TIME 1458411938.5024
VALUE 2.8
Powermax:
Logdb:
TIME 1458411938.5024
VALUE 390.8
State:
Logdb:
TIME 1458411938.5024
VALUE on
Readings:
2016-03-19 19:29:40 consumption 8.229
2016-03-19 19:29:40 consumptionEuro 2.04
2016-03-19 19:25:38 consumptionMonth 14.299
2016-03-19 19:29:40 consumptionMonthEuro 3.55
2016-03-19 19:25:38 consumptionTotal 14.299
2016-03-19 19:29:40 consumptionTotalEuro 3.55
2016-03-19 19:25:38 consumptionWeek 14.299
2016-03-19 19:29:40 consumptionWeekEuro 3.55
2016-03-19 19:25:38 consumptionYear 14.299
2016-03-19 19:29:40 consumptionYearEuro 3.55
2016-03-19 00:01:06 consumptionYesterday 7.687
2016-03-19 00:01:06 consumptionYesterdayEuro 1.91
2016-03-19 19:29:40 power 2.7
2016-03-19 19:29:40 powerMax 390.8
2016-03-19 19:29:40 state on
Attributes:
IODev myJeeLink
event-min-interval *:300
genericDeviceType outlet
room myJeeLink,z_Homekit
stateFormat Jetzt power W, Max powerMax W, Verbrauch consumption kwh
userReadings consumptionTotal:consumption monotonic {ReadingsVal($name,'consumption',0)},
consumptionWeek:consumption monotonic {ReadingsVal($name,'consumption',0)},
consumptionMonth:consumption monotonic {ReadingsVal($name,'consumption',0)},
consumptionYear:consumption monotonic {ReadingsVal($name,'consumption',0)},
consumptionEuro {euroBerechnen(ReadingsVal($name,"consumption","?"))},
consumptionTotalEuro {euroBerechnen(ReadingsVal($name,"consumptionTotal","?"))},
consumptionWeekEuro {euroBerechnen(ReadingsVal($name,"consumptionWeek","?"))},
consumptionMonthEuro {euroBerechnen(ReadingsVal($name,"consumptionMonth","?"))},
consumptionYearEuro {euroBerechnen(ReadingsVal($name,"consumptionYear","?"))}
Danke für eure Hilfe.
Beste Grüße
Andy
Zitat von: Andy89 am 19 März 2016, 19:35:54
ich habe eine Frage zum EC3000. Ich hätte gerne, dass dieser ähnlich wie die PCA301's funktiort, das heißt, dass ich diese um Mitternacht "resetten" kann, damit die consumption zurückgesetzt wird.
Die consumption wird in der Dose akkumuiliert und von ihr gesendet. Da man nicht wie bei PCA301 mit ihr reden kann, ist da nichts zu machen.
Das muss man mit einem eigenen Reading lösen oder man müsste im EC3000 Sketch was bauen.
Zitat von: HCS am 19 März 2016, 20:28:55
Die consumption wird in der Dose akkumuiliert und von ihr gesendet. Da man nicht wie bei PCA301 mit ihr reden kann, ist da nichts zu machen.
Das muss man mit einem eigenen Reading lösen oder man müsste im EC3000 Sketch was bauen.
das habe ich mir schon fast gedacht. Dann mach ich das mit einem Reading^^
Danke für die Antwort :)
Schönes Weekend noch
V1.16RFM12 entfallenWie schon angekündigt wird der RFM12 nicht mehr offiziell unterstützt, nur noch der RFM69
Bugfixes- Wenn WIFI deaktiviert war, wurde trotzdem der AP geöffnet
- PCA301: Habe Maßnahmen gegen die "Phantom-PCAs" getroffen.
Da ich immer zwei bis drei Wochen warten muss, bis bei mir mal eine auftritt, kann ich es
noch nicht zu 100% sagen, ob sie weg sind. Wer mit dieser Version immer noch welche bekommt, bitte melden.
Log im frontendSiehe auch LogPage.png
Mit "Command" kann man Befehle an das LGW senden. Sie entsprechen dem, was man mit "set myJeeLink raw ..." aus FHEM schicken kann.
Die obere Liste enthält die Daten, die an FHEM übermittelt werden (bzw. würden, wenn sich ein FHEM auf das LGW verbunden hat)
Die untere Liste enthält debug-Informationen. U.A. wird hier der letzte Systemstart aufgezeichnet.
Die verwendete SDK-Version und der letzte Reset-Grund werden ebenfalls ausgegeben
ErweiterungsmöglichkeitenDas LGW kann nun optional mit verschiedenen Komponenten erweitert werden.
Alle Komponenten werden automatisch erkannt, sofern angeschlossen.
Dazu wird ein SC16IS750 verwendet.
http://www.aliexpress.com/item/1x-Breakout-Board-for-SC16IS750-I2C-SPI-to-UART-IC/1327351219.html?spm=2114.30010308.3.38.HxdznQ&ws_ab_test=searchweb201556_9,searchweb201602_2_10034_507_10020_10001_10002_10017_10010_10005_10011_10006_10021_10003_10004_10022_10009_10008_10018_10019,searchweb201603_6&btsid=97b30f2b-e937-426b-8202-de585dd7ee97
Der SC16IS750 wird per I2C an das LGW angeschlossen und bietet eine serielle Schnittstelle und 8 Digital I/Os
Auf dieser Basis sind momentan folgende Erweiterugen möglich:
Alarmausgabe im LGWDazu wird an GPIO7 des SC16IS750 ein Summer angeschlossen.
Falls der Strom von 10mA, den die Ausgänge liefern, nicht reicht, ist noch eine Transistor-Schaltstufe vorzusehen
Ansteuerung über das JeeLink Modul in FHEM:
set myJeeLink211 raw 1,60b -> beep ... beep ... beep 60 Sekunden lang
set myJeeLink211 raw 2,300b -> beep beep ... beep beep ... beep beep 300 Sekunden lang
set myJeeLink211 raw 3,120b -> beep beep beep ... beep beep beep ... 120 Sekunden lang
set myJeeLink211 raw 0b -> beep stoppenRadio #4 und #5Es können zwei weitere RFM69 angeschlossen werden.
Schaltung siehe GW-Addon-With-Example.png
Radio #4 und #5 sind "vollwertig", sie können also alles, was die bisherigen drei auch können.
SubProzessorAn die serielle Schnittstelle des SC16IS750 kann optinal ein Arduino angeschlossen werden (z.B. ein Pro Mini)
Entweder ein 3.3V / 8MHz oder ein 5V / 16MHz, der aber dann auch mit 3.3V betrieben wird.
Wichtig: hier läuft alles mit 3.3V, also bitte nirgends 5V ins Spiel bringen.
Die Firmware kann über das LGW auf den SubProzessor (Voraussetzung: er hat einen Arduino bootloader) geflasht werden.
Dazu wird sie einfach hochgeladen auf <LGW-IP>/ota/addon.hex
Das LGW nimmt den Upload entgegen, wandelt das Intel-Hex in binary um und schickt es per STK500-Protokoll an den Arduino.
Den Upload kann man z.B. so durchführen:
curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@/myFolder/LGW-Addon.ino.hex; filename=addon.hex" http://192.168.31.211/ota/addon.hexDer Upload dauert etwas, danach sollte man bei Erfolg vom LGW so ein Protokoll zurückgeschickt bekommen:
Start receiving 'addon.hex'
File: /addon.hex Size: 21417
Starting flash
Sending sync
Enter program mode
Binary size is:7608
Leave Program Mode
Flash finishedMit dem SubProzessor kann man was auch immer an Daten messen, empfangen oder erfinden und sie auf zwei mögliche Arten am LGW abliefern:
KeyValueProtokoll:
Format: KV <Type> <Address> <Key>=<Value>,<Key>=<Value>,<Key>=<Value>, ...
Example: KV DHT 01 Temperature=21.5,Humidity=62
Das LGW übermittelt die Daten als KVP an FHEM und dort entsteht ein KVP Device, das die Daten darstellt.
LaCrosse:
Format: LC <Address> T=<Temperature>,H=<Humidity>
Examples: LC 9F T=21.5,H=62
LC 9F T=21.5
Das LGW setzt die Werte in das LaCrosse Protokoll um (wie z.B. ein TX29DTH) und schickt sie an FHEM
In FHEM entsteht ein LaCrosse Device (autocreate, LaCrossePairForSec ...), als ob es ein LaCrosse Sensor wäre.
Das angehängte LGW-Addon.ino ist ein einfaches Beispiel, das diese Technik veranschaulicht.
Es bindet den geliebten DHT22 an und sendet ihn als LaCrosse-Sensor (über das LGW) an FHEM und es misst die Spannung und sendet sie zusammen mit der UpTime des SubProzessors als KVP
LGW-Addon-With-Example.png ist die Schaltung des kompletten AddOn mit allen aktuell möglichen Optionen.
Der umrandete Bereich "Example" ist das zu LGW-Addon.ino passende Beispiel.
Wer jetzt noch über den Sinn des SubProzessors grübelt: er dient dazu, dass jeder mit einem eigenen Sketch Daten erfassen kann, ohne sich um die ganze Nummer, die das LGW macht (WiFi, Kommunikation mit FHEM, Frontend, OTA, ...), kümmern zu müssen.
Und er ist die Option für Dinge, die man aufgrund des Timings dem LGW nicht auch noch aufdrücken kann (z.B. OOK pollen)
Super!
Gleich aber mal die 1. Verständnisfrage: werden der BME280 und der SC16IS750 parallel angeschlossen oder müsste ich auf den BME280 verzichten?
Zitat von: Omega am 20 März 2016, 22:45:15
Verständnisfrage: werden der BME280 und der SC16IS750 parallel angeschlossen oder müsste ich auf den BME280 verzichten?
Musst nicht verzichten, funktioniert parallel.
Das AddOn läuft mit allem zusammen, was es bisher schon gab.
RESPEKT !!!
Das LGW wird ja langsam ein richtiges Monster :)
Mit dem SC16IS750 habe ich noch ein kleines Problem .... Auf der einen Seite ist mir schon klar das ohne ihn ein OTA Update des Sub Arduino nicht machbar wäre, auf der anderen Seite frage ich mich ob das wirklich unbedingt nötig ist.
Ich könnte mir auch eine Lösung vorstellen wo auf den SC16IS750 ganz verzichtet wird und der Arduino direkt am I2C Bus des ESP hängt, d.h. der Arduino die Hardware des SC16IS750 als Software nachbildet oder habe ich hier einen generellen Denkfehler ?
Zitat von: Wzut am 21 März 2016, 10:08:19
RESPEKT !!!
Das LGW wird ja langsam ein richtiges Monster :)
HäHä .... dann machen wir das doch noch monster-hafter .... :)
Lässt sich für den Debug-Output in dem neuen Log-Dialog noch eine Weiterleitung an einen Syslog-Server realisieren?
Die empfangenen Telegramme würde ich jedoch nicht weiterleiten .... das wird dann doch zuviel.
Zitat von: Wzut am 21 März 2016, 10:08:19
RESPEKT !!!
Mit dem SC16IS750 habe ich noch ein kleines Problem .... Auf der einen Seite ist mir schon klar das ohne ihn ein OTA Update des Sub Arduino nicht machbar wäre, auf der anderen Seite frage ich mich ob das wirklich unbedingt nötig ist.
Ich könnte mir auch eine Lösung vorstellen wo auf den SC16IS750 ganz verzichtet wird und der Arduino direkt am I2C Bus des ESP hängt, d.h. der Arduino die Hardware des SC16IS750 als Software nachbildet oder habe ich hier einen generellen Denkfehler ?
Dazu müsste das LGW auf dem I2C Bus heftig pollen. Den Ansatz hatte ich ursprünglich mal ausgetestet, das haut nicht hin.
Das praktische sind gerade die 64 Byte serial FIFO des SC16IS750. Da muss das LGW nur "ab und zu" mal nachschauen, ob vom SubProzessor was geliefert wurde.
Die Erweiterung mit Radio #4 und #5 benötigt chipselects, die der SC16IS750 in Form seiner 8 IOs reichlich bietet, dazu allein ist kein weiterer Prozessor erforderlich.
Ebenso der Buzzer für die Alarm-Ausgabe.
Ziel war, bestimmte Erweiterungen zu ermöglichen, ohne weitere Software auf einem zweiten Prozessor haben zu müssen und den SubProzessor ganz alleine in die Hand des Anwenders zu geben, falls er so etwas benötigt, wo er dann machen kann, was er will.
Bedeutet: ich werde auch nichts "offizielles" für den SubProzessor liefern.
Zitat von: Wzut am 21 März 2016, 10:08:19
Auf der einen Seite ist mir schon klar das ohne ihn ein OTA Update des Sub Arduino nicht machbar wäre, auf der anderen Seite frage ich mich ob das wirklich unbedingt nötig ist.
Fast nichts in FHEM ist "unbedingt nötig" ;D ;D
Aber wenn ich ein LGW per OTA updaten kann, ist es dann schon doof, dass ich für den SubProzessor mit Laptop und Kabel hinlaufen muss.
Zitat von: AxelSchweiss am 21 März 2016, 10:14:51
HäHä .... dann machen wir das doch noch monster-hafter .... :)
Lässt sich für den Debug-Output in dem neuen Log-Dialog noch eine Weiterleitung an einen Syslog-Server realisieren?
Die empfangenen Telegramme würde ich jedoch nicht weiterleiten .... das wird dann doch zuviel.
Das Log kannst Du ganz einfach selbst abrufen
mit: <LGW-IP>/getLogData
Besipiel: //192.168.31.211/getLogData
Liefert
DATA:OK 22 117 196 0 58 226 102 0 58 191 86 0 0 40 172 0 105 1 101 3 0 [75 C4 E2 66 00 00 BF 56 00 00 00 02 3B FC DC 00 69 01 65 4A A4 C4 F9 F2 4F 11 A4 F6 7C 03 A0 00 00 00 00 03 A0 38 09 21 27]
DATA:OK 9 11 130 4 173 125 [92 D5 97 7D 75]
DATA:OK EMT7110 84 81 8 207 0 36 0 1 1 199 1 [25 6A 54 51 40 02 00 24 C3 41 C7 9B]
SYS: AddOn: KV ADDON 01 Voltage=3.33,UpTime=4921
DATA:OK VALUES ADDON 01 Voltage=3.33,UpTime=4921
DATA:OK 9 38 1 4 67 65 [99 84 91 41 07]
DATA:OK 9 55 1 4 202 42 [9D C6 26 2A 19]
DATA:OK 9 41 1 4 177 53 [9A 46 01 35 41]
DATA:OK 22 126 67 0 65 236 34 0 65 231 116 0 0 32 103 0 48 0 134 1 0 [7E 43 EC 22 00 00 E7 74 00 00 00 01 C7 AC D7 00 30 00 86 00 57 E4 69 1E 46 8E D4 68 C7 04 10 00 00 00 00 04 10 18 0A DC F7]
DATA:OK 9 36 1 4 128 61 [99 05 52 3D 96]
DATA:OK WS 0 4 4 185 255 255 255 255 255 255 255 255 255 0 3 252DATA: für die obere Liste
SYS: für die untere Liste
Bei jedem Aufruf werden die seit dem letzten Abruf neu aufgelaufenen Logeinträge geliefert.
Intern werden maximal 40 Einträge gepuffert (aber kein Ringpuffer, weil die ersten 40 mit dem Bootlog erhalten bleiben müssen)
Aber die Abruferei nicht übertreiben, sonst zwingst Du das LGW in die Knie.
Und nicht von zwei Instanzen gleichzeitig abrufen, das nimmt das LGW ganz krumm.
So generell: das Log ist eher als Hilfsmittel bei der Fehlersuche gedacht.
Z.B. um bei PCA301 zu verfolgen, wann wer was wie frägt und antwortet oder um zu schauen, ob irgend welche Sensoren überhaupt empfangen werden und die Daten an FHEM geliefert werden.
Ahhh ... guck ... Danke
Mir ging es auch primär um ein klassisches Logging.
Warum ? .... Bei mir hängt das LGW via WLAN an einem Powerline-Backbone.
Und der ist alles andere als stabil (deswegen fliegt der auch so schnell wie möglich raus ... nach dem Kabelziehen .... irgendwann)
Dann würde ich die Reconnects und Fehler in meinem zentrale Syslog finden.
Die ganzen Telegramme via Syslog mitzuschreiben halte ich auch für Overkill.
Zitat von: AxelSchweiss am 21 März 2016, 11:29:29
Mir ging es auch primär um ein klassisches Logging.
Nun ist mir noch nicht ganz klar, ob das oben Beschriebene Dir hilft oder nicht.
Einen reconnect von FHEM auf das LGW kannst Du auch aus dem FHEM-Log rauslesen:
2016.03.21 09:07:10 3: Opening myJeeLink device 192.168.31.211:81
2016.03.21 09:07:10 3: myJeeLink device opened
Zitat von: HCS am 21 März 2016, 12:17:09
Nun ist mir noch nicht ganz klar, ob das oben Beschriebene Dir hilft oder nicht.
Nicht so ganz .... ist aber auch eher ein Luxus-Problem.
Ein Syslog-Adapter wäre eben schön .... dann hast du alle Logs zentral in einer Instanz und nach einem alt eingesessenen Standard.
Vor allen Dingen habe ich dann den Log-Output auch wenn das Device abgeschmiert ist (wobei das LGW bisher für PCA301 stabil läuft).
Zitat von: AxelSchweiss am 21 März 2016, 14:23:05
... (wobei das LGW bisher für PCA301 stabil läuft).
Das ist der entscheidende Punkt. ;D
Hast Du mit der 1.15 eigentlich "Phantom-PCAs" bekommen?
Falls ja, dann bitte mal beobachten, ob das mit der 1.16 weg ist.
Zitat von: HCS am 21 März 2016, 18:05:26
Das ist der entscheidende Punkt. ;D
Manchmal hat das auch Nachteile wenn die Software stabil ist. :(
Zitat von: HCS am 21 März 2016, 18:05:26
Hast Du mit der 1.15 eigentlich "Phantom-PCAs" bekommen?
Nö ... keine Phantome ... habe aber auch nur eine Steckdose dran.
Zitat von: AxelSchweiss am 21 März 2016, 18:09:33
Nö ... keine Phantome ... habe aber auch nur eine Steckdose dran.
Interessant. Die Phantome kamen glaube ich eher von HF-Müll, der ein korrektes CRC ergibt. Dürfte nicht davon abhängig gewesen sein, wie viele PCAs man hat.
OK, wir werden es sehen, ob sie weg sind.
Eine Dose wird nun erst dann an FHEM übermittelt, wenn sie nach einer Anfrage innerhalb des zulässigen Timeout geantwortet hat und nicht schon sobald von ihr mal was zu hören war.
Damit sollte es eigentlich sicher sein.
Phantome hatte ich ja schon öfters. Habe vor dem Update auf die 1.16 noch mal schnell 2 gelöscht und werde berichten, falls sich doch wieder was tut.
Ich habe das LGW mal mit einem "WeMOS D1 mini" aufgesetzt ... baut kleiner ;)
Drauf ist noch ein BME180 und ein Radio.
Läuft seit ca. 2 Monaten stabil ... mal von Reboots durch Firmwareupdates abgesehen.
Zitat von: AxelSchweiss am 23 März 2016, 14:20:18
Ich habe das LGW mal mit einem "WeMOS D1 mini" aufgesetzt ... baut kleiner ;)
Das ist aber niedlich. 8)
Ja .. ne ... quasi "portable".
Wenn man jetzt die Sendeleistung noch erhöht könnte die Antenne glatt als Tauchsieder durchgehen.
Zitat von: AxelSchweiss am 23 März 2016, 17:39:29
Ja .. ne ... quasi "portable".
Das ist portable: 8) https://forum.fhem.de/index.php/topic,43672.msg392970.html#msg392970
jep
Zitat von: HCS am 23 März 2016, 17:49:13
Das ist portable: 8) https://forum.fhem.de/index.php/topic,43672.msg392970.html#msg392970
Steht auch noch auf meiner Liste.
Schaut ihr mal über die erste Platine im ESP Board drüber?
Müsste noch vor Ostern fertig werden 8)
Gruß Peter
Zitat von: PeMue am 23 März 2016, 22:23:10
https://forum.fhem.de/index.php/topic,43672.msg392970.html#msg392970
Steht auch noch auf meiner Liste.
Bedeutet, dass Du eine Platine machen willst?
Zitat von: HCS am 25 März 2016, 06:16:14
Bedeutet, dass Du eine Platine machen willst?
Wenn Du mir nähere Infos (Außenmaße, Rastermaß, Link) vom verwendeten USB2seriell Adapter lieferst, dann ja ;D
(https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=49224;image)
Der Rest -> siehe Platinenthread ;)
Werbung :)
Wer ein LGW endültig und "ordentlich" aufbauen will und den Thread für die Platine noch nicht entdeckt hat, hier:
https://forum.fhem.de/index.php/topic,45594.0.html
Vielen Dank an PeMue, der das Layout für die Platine gemacht hat und gerade dazu aufgerufen hat, Bedarf zu melden, um einen Überblick über die benötigte Stückzahl zu bekommen.
Nachtrag: damit meine ich die "große" Platine, nicht die Nano-Geschichte, das ist nochmal ein anderes Thema.
Nicht dass es noch bei jemanden so endet: ;D ;D
(https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=49227)
Cool ...
Aber mit Kabelbindern hätte man das ordentlicher machen können :)
Wozu ist den der Buzzer da drauf?
Zitat von: AxelSchweiss am 25 März 2016, 12:35:56
Aber mit Kabelbindern hätte man das ordentlicher machen können :)
Ich habe Kabelkanäle geplant ...
Zitat von: AxelSchweiss am 25 März 2016, 12:35:56
Wozu ist den der Buzzer da drauf?
https://forum.fhem.de/index.php/topic,43672.msg427404.html#msg427404
Zitat von: PeMue am 25 März 2016, 11:39:54
Wenn Du mir nähere Infos (Außenmaße, Rastermaß, Link) vom verwendeten USB2seriell Adapter lieferst, dann ja ;D
Genial. Ja, kann ich machen.
Das größte Problem wir bestimmt die Liste der OnBoard-Senoren werden ;D ;D ;D
Zitat von: PeMue am 25 März 2016, 11:39:54
Der Rest -> siehe Platinenthread ;)
Wollen wir einen extra "Nano-LGW Platine" Thread machen um nicht zu viel Durcheinander zu haben?
Zitat von: HCS am 25 März 2016, 13:26:15
Wollen wir einen extra "Nano-LGW Platine" Thread machen um nicht zu viel Durcheinander zu haben?
Ein Mann, ein Wort. Ja, wir wollen (https://forum.fhem.de/index.php/topic,51329.msg429913.html#msg429913).
Die kommende Version 1.17 wird eine Kompromisslösung für den DHT22 bieten.
Man kann dann anstatt Radio #3 einen DHT22 anschließen. Die Software erkennt automatisch was dran ist.
Damit hat man nun die Wahl zwischen
2 Radios und ein DHT22
oder
3 Radios und kein DHT22
PeMue hat auch auf der Platine die optionale Bestückung eines DHT22 vorgesehen.
Zitat von: Wzut am 21 März 2016, 10:08:19
Ich könnte mir auch eine Lösung vorstellen wo auf den SC16IS750 ganz verzichtet wird und der Arduino direkt am I2C Bus des ESP hängt, d.h. der Arduino die Hardware des SC16IS750 als Software nachbildet oder habe ich hier einen generellen Denkfehler ?
Erst eben habe ich verstanden, was Du eigentlich genau gemeint hast. :o
Ich glaube Du hast keinen Denkfehler, weil wenn der Arduino sich genau wie ein SC16IS750 verhält, dürfte das LGW eigentlich keinen Unterschied merken.
Dazu müsste der Arduino-Sketch einen I2C slave mit Adresse 0x90 implementieren usw.
Vorteil: man könnte einen Puffer bereitstellen, der größer als die 64Byte des SC16IS750 ist
Nachteil: kein OTA
Oder man nimmt einen Tiny um den SC16IS750 zu ersetzen und hinten dran dann den Arduino wie gehabt.
Vorteil: OTA
Nachteil: Noch ein Prozessor, der programmiert werden muss.
Aber ob sich der ganze Aufwand lohnt, um ein 10EUR Bauteil zu ersetzten, ist fraglich.
guten morgen,
ich habe eine Frage zur Platine.
Habe ich etwas verpasst oder gibt es noch keine Platine für den ESP mit drei RFM69 ?
Gefunden habe ich jedenfalls noch nichts.
Wird es eine Platine wie oben im ersten Tread geben ?
Gruß Werner
siehe Bastelbude:
https://forum.fhem.de/index.php/topic,45594.msg373669.html#msg373669
wurden heute bestellt ;)
Gruß Peter
oh, habe es nicht damit in Verbindung gebracht.
Weil es völlig anders aussieht ;)
Dann wird es wohl zu spät für eine Bestellung sein.
hmm, dann warte ich halt
Gruß Werner
Zitat von: Intruder1956 am 01 April 2016, 11:20:02
Habe ich etwas verpasst
Ja:
https://forum.fhem.de/index.php/topic,43672.msg429857.html#msg429857
Zitat von: Intruder1956 am 01 April 2016, 11:37:25
Dann wird es wohl zu spät für eine Bestellung sein.
Rein rechnerisch sollte noch genau eine zu haben sein
ok, meine :)
gibt es eine Bauteilliste ?
ESP Dev und 3 x RFM69CW vorhanden.
Gruß Werner
Zitat von: Intruder1956 am 01 April 2016, 11:47:15
gibt es eine Bauteilliste ?
ESP Dev und 3 x RFM69CW vorhanden.
Platinen-Themen bitte im Platinen-Thread: https://forum.fhem.de/index.php/topic,45594.msg373669.html#msg373669
Zitat von: HCS am 28 März 2016, 09:38:31
Aber ob sich der ganze Aufwand lohnt, um ein 10EUR Bauteil zu ersetzten, ist fraglich.
Die 10 Euro sind mir relativ wurscht, zum einen wäre es Spaß an der Freude zum anderen habe ich das Ding nur in China gefunden und diese ewigen Wartezeiten beim bestellen nerven mich ( Bis das Ding ankommt habe ich vermutlich schon wieder vergessen wieso ich es überhaupt bestellt habe ... ) oder hast du einen Link in Deutschland griffbereit ? ( Watterott will fast 17 € und hat 0 Stück auf Lager : http://www.watterott.com/de/Breakout-Board-for-SC16IS750-I2C/SPI-to-UART-IC)
Zitat von: Wzut am 01 April 2016, 14:03:17zum einen wäre es Spaß an der Freude ...
Würdest Du einen SC16IS750-Clone auf Basis von Arduino oder AtTiny implementieren?
Dann könnte man es sich aussuchen, ob man sich einen SC16IS750 kaufen oder flashen will.
Falls ja, würde ich Dir ermitteln, was vom Befehlssatz ich verwende.
Zitat von: Wzut am 01 April 2016, 14:03:17... oder hast du einen Link in Deutschland griffbereit ? ( Watterott will fast 17 € und hat 0 Stück auf Lager
Leider nicht. Antratek hatte den auch mal lieferbar, jetzt aber nicht mehr.
Ach ja, was LGW 1.17 auch können wird: die serielle Schnittstelle des SC16IS750 transparent auf einem TCP-Port bereitstellen. also so in der Art von ser2net.
Zitat von: Wzut am 01 April 2016, 14:03:17
...zum anderen habe ich das Ding nur in China gefunden und diese ewigen Wartezeiten beim bestellen nerven mich..
Also meine sind aus China heute nach nur 12 Tagen angekommen ;)
Zitat von: waschbaerbauch am 01 April 2016, 18:42:10
Also meine sind aus China heute nach nur 12 Tagen angekommen ;)
Dann kannst ihm ja einen abgeben ::)
Mobil erstellt daher kurz gehalten
Wenn ich mehr bestellt hätte würde ich das glatt machen, aber dieses mal sind es nur zwei für den Eigenbedarf ;)
Zitat von: HCS am 01 April 2016, 15:43:33
Würdest Du einen SC16IS750-Clone auf Basis von Arduino oder AtTiny implementieren?
Dann könnte man es sich aussuchen, ob man sich einen SC16IS750 kaufen oder flashen will.
Falls ja, würde ich Dir ermitteln, was vom Befehlssatz ich verwende.
Ich würde zumindest gerne mal einen Versuch starten, also immer her mit den Protokoll Infos :)
Ich nehme mal an im ersten Schritt muss beim Reboot des ESP sich ein I2C Client auf 0x90 melden ?
Zitat von: Wzut am 02 April 2016, 19:44:17
Ich nehme mal an im ersten Schritt muss beim Reboot des ESP sich ein I2C Client auf 0x90 melden ?
Ja. Die Register, die angesprochen werden, kannst Du recht einfach aus der angehängten SC16IS750.cpp rauslesen.
Beispiel: in der Begin() wird in Register 0x07 der wert 0x55 geschrieben und danach gelesen und dann 0xAA geschrieben und zurückgelesen, um zu testen, ob ein SC16IS750 angeschlossen ist.
Dann wird Register 0x02 bit 0 gesetzt um den FiFo zu aktivieren.
Usw. Usw.
Wie das jeweilige Register genau arbeitet kann man im Datenblatt nachlesen, habe es mit ins ZIP gepackt.
Und fix sein, im Sketch, ich fahre den I2C Bus mit 1MHz Clock. :)
Zitat von: HCS am 28 März 2016, 09:38:31
Dazu müsste der Arduino-Sketch einen I2C slave mit Adresse 0x90 implementieren usw.
hmm irgendwie stehe ich gerade auf dem Schlauch , gestern Abend einen 3,3V / 8MHz Arduino Micro mit dem Beispiel Wire client-read Sketch betankt, A5 am D1 , A4 an D2 + 2x 4,7k als Pullup und : NICHTS :(
Ich hatte eigentlich die Hoffnung direkt nach Reset des ESP dessen Schreibversuche auf 0x90 zu sehen.
Kann ich das auch via Software Kommando an triggern oder muss ich für jeden Versuch jedesmal den Resettaster am DevKit drücken ?
Zitat von: Wzut am 04 April 2016, 11:44:50
Ich hatte eigentlich die Hoffnung direkt nach Reset des ESP dessen Schreibversuche auf 0x90 zu sehen.
Ich bin nicht sicher, ob ein Arduino IC2 slave 1MHz I2C clock kann. Ich befürchte, dass er maximal 400 kHz hinbekommt, wobei ch mir bei dem 8MHz Arduino nicht sicher bin ober der überhaupt die 400 kHz schafft.
Man kann übrigens problemlos auch einen 5V / 16MHz pro mini nehmen, das funktioniert auch (läuft dann mit 3.3V, was aber kein Problem ist)
Ich könnte in der setup page des LGW etwas einbauen, wo man die clock speed konfigurieren kann.
Zitat von: Wzut am 04 April 2016, 11:44:50
Kann ich das auch via Software Kommando an triggern ..
Aktuell nicht, aber ich könnte Dir in der kommenden Version was dafür einbauen.
Momentan wird beim Start einmal geprüft, ob ein SC16IS750 da ist, und wenn nicht, ist das Thema erledigt.
Zitat von: Wzut am 04 April 2016, 11:44:50
... oder muss ich für jeden Versuch jedesmal den Resettaster am DevKit drücken ?
Aktuell ja.
OK, dann ist alles klar. Ich musste bis jetzt nie die Datenrate bei I2C anfassen, habe mich da jetzt mal schlau gemacht :
http://playground.arduino.cc/Main/WireLibraryDetailedReference
und siehe da :
Zitat-sets the clock frequency that the TWI hardware will use if/when it is the master on the I2C bus. It is set in the source code to 100kHz, but theoretically at least you can reset this frequency by calling Wire.setclock(). The value passed is the bitrate from 400000L to 31000L. Wire.setclock(400000L); should set it to 400kHz. Wire.setClock() must be called after Wire.begin(). Wire.begin() initializes the bitrate to 100kHz.
Für die Arduinos ist laut div Foren wohl bei 800kHz das absolute Ende der Fahnenstange erreicht.
Zitat von: Wzut am 04 April 2016, 15:10:30
Für die Arduinos ist laut div Foren wohl bei 800kHz das absolute Ende der Fahnenstange erreicht.
Ich liebe den ESP8266. Es geht nichts über Rechenleistung, außer vielleicht noch mehr Rechenleistung ;D ;D ;D
Ich habe Dir mal eine Vorabversion gebildet, in der man die clock speed setzen kann und ein Kommando absetzen, um den SC16IS750 anzusprechen.
Auf der Setup-page kann man die clock speed einstellen
Auf der log-page bei "command" "1x" abschicken, dann wird der SC16IS750 angesprochen und je nachdem, ob er geantwortet hat, wird unten entweder "SC16IS750 detected" oder "no SC16IS750" ausgegeben.
OK THX, mit der einstellbaren Clock Speed sollte dann zumindest diese Hürde zu nehmen sein.
Werde vermutlich am Donnerstag Bericht erstatten, denn ich werde nicht vor morgen Abend zum basteln kommen.
Wie versprochen, gestern Abend war Bastelabend :
a. Die Log Webseite des GW bleibt leer, muss ich auf der Setupseite das Logging aktivieren ? Du hast in deinem Screenshot dort etwas eingetragen, hatte auch versucht das zu übernehmen doch leider auch ohne Erfolg.
b. den Clock Speed in der Setup Seite von 1.000.000 auf 100.000 gesetzt, noch immer kein Zeichen zu sehen. Ich habe dann in meiner Verzweiflung auf einem UNO den Wire Master Write Sketch geflasht und mit dem Slave verbunden. Ergebnis : ich sah die Zeichen vom Master, ergo kann der Micro I2C empfangen. Als nächstes habe ich auf den Micro den I2C Scanner Sketch geflasht, dieser finden den UNO Master unter der Adresse 7F. Verbinde ich den Micro aber mit dem ESP wird kein Master oder anderer Teilnehmer am Bus gefunden.
Die einzige Idee die ich nun noch habe ist am WE mal das LGW ganz vom ESP zu entfernen und mal schauen ob ich dann weiterkomme.
Zitat von: Wzut am 07 April 2016, 09:24:35
a. Die Log Webseite des GW bleibt leer, muss ich auf der Setupseite das Logging aktivieren ? Du hast in deinem Screenshot dort etwas eingetragen, hatte auch versucht das zu übernehmen doch leider auch ohne Erfolg.
Du meinst bei Flags? Nein, nichts eintragen. Das muss so gehen.
Schau mal in der Konsole vom Browser, ob es da Fehler zu sehen gibt.
Hast Du evtl. JavaScript im Browser deaktiviert?
Läuft das LGW ansonsten "normal" wie es laufen soll?
Zitat von: Wzut am 07 April 2016, 09:24:35
b. den Clock Speed in der Setup Seite von 1.000.000 auf 100.000 gesetzt, noch immer kein Zeichen zu sehen. Ich habe dann in meiner Verzweiflung auf einem UNO den Wire Master Write Sketch geflasht und mit dem Slave verbunden. Ergebnis : ich sah die Zeichen vom Master, ergo kann der Micro I2C empfangen. Als nächstes habe ich auf den Micro den I2C Scanner Sketch geflasht, dieser finden den UNO Master unter der Adresse 7F. Verbinde ich den Micro aber mit dem ESP wird kein Master oder anderer Teilnehmer am Bus gefunden.
OK, ich packe mir mal einen I2C-Receiver-Sketch auf einen Arduino und versuche es auch mal.
Die Pull-Ups auf SDA/SCL hast Du ja wohl nicht vergessen?
Hast Du sonst noch was an I2C dran (LM75, BMP180 oder so) und wird das erkannt?
Zitat von: HCS am 07 Dezember 2015, 09:19:54
OK. Bevor Du zu viel Arbeit in die falsche Richtung inverstierst, einige Gadanken und Unumgänglichkeiten dazu:
- Wenn DHT22 / DS1820 unterstützt werden, sollte das auf alle Fälle zusätzlich zu BMP180 gehen, sonst muss man auf den Luftdruck verzichten
- DHT22 / DS1820 würde ich auf einem GPIO abhandeln, es macht ja nur einer Sinn, nicht beide gleichzeitig
- Mögliche GPIO-Verwendung:
GPIO4 und 5 sind immer I2C, da kann ein BMP180, ein BME280 oder sonst ein I2C Baustein (z.B. LM75) dran.
GPIO10: (OneWire oder) DHT22 oder sonstwas wie z.B. ein OOK Radio
GPIO9 ist bereits der CS für den dritten RFM
GPIO0 muss ich mal noch ermitteln, was machbar ist, ohne den Bootvorgang zu gefährden, evtl. ein OOK Sender
Wenn man LaCrosse, Temp, Hum und Feuchte will, könnte man verwenden:
ein bis drei RFMs und einen BME280
ein bis drei RFMs, einen BMP180 und einen DHT22
Wenn man keine Feuchte will, dann: ein bis drei RFMs, einen BMP180
Wenn man nur die Temperatur will, dann: ein bis drei RFMs und einen (DS1820) LM75
Und das Ganze sollte so werden, dass diese Varianten vom Sketch erkannt werden, ohne dass man Ports konfigurieren
und die Firmware bilden muss.
Wenn der LM75 implementiert wird, dann würde ich auf die DS1820 Implementierung verzichten, weil man dann die Temperatur auf I2C hat und weniger Stress auf GPIO10.
1Wire wäre dann ganz raus.
Das LGW muss nun auch nicht die "AllSensorsYouCanFind" Plattform werden, der primäre Zweck ist der Empfang von LaCrosse.
Das sollte noch von der Architektur anders werden, aus der InternalSensors muss DHT und OneWire raus, weil ich die auch in anderen Projekten verwende (z.B. LaCrosse-Sketch) und es dort eher störend ist. Am besten wird man im LGW eine "LGWSensors" von der "InternalSensors" ableiten.
Hi,
verstehe ich das richtig dass man dann mit einem RMFxx LaCrosse-Sensoren (z.b. TX-35 oder TX-29-DTH) empfangen kann und die Daten per WLAN an FHEM überträgt und zusätzlich auf dem Gateway weitere Sensoren (Luftdruck, Temperatur, Hum) installiert und diese Daten dann auch in FHEM zur Verfügung stehen? Oder man installiert zwei oder drei RMF auf dem Gateway mit verschiedenen Frequenzen und kann dann 868mhz, 433mhz oder vielleicht z-wave gleichzeitig mit einem Gateway abdecken? :-)
Zitat von: Chris_Worms am 07 April 2016, 14:18:56verstehe ich das richtig dass man dann mit einem RMFxx LaCrosse-Sensoren (z.b. TX-35 oder TX-29-DTH) empfangen kann und die Daten per WLAN an FHEM überträgt und zusätzlich auf dem Gateway weitere Sensoren (Luftdruck, Temperatur, Hum) installiert und diese Daten dann auch in FHEM zur Verfügung stehen? Oder man installiert zwei oder drei RMF auf dem Gateway mit verschiedenen Frequenzen und kann dann 868mhz, 433mhz oder vielleicht z-wave gleichzeitig mit einem Gateway abdecken? :-)
Das hast Du richtig verstanden, wenn man
"433mhz oder vielleicht z-wave" wegstreicht.
Man kann 1 bis 3 RFM69 anschließen und mit denen unterschiedliche Sensoren empfangen bzw. PCA301 steuern. Siehe Liste unten.
Da die Sensoren teil unterschiedliche Frequenzen oder data rates haben und PCA301 einen RFM69 exklusiv für sich benötigt, kann man mehrere RFM69 anschließen, mit einer Hardware-Erweiterung sogar bis zu fünf Stück.
Zusätzlich kann einer dieser Sensoren direkt am LGW angeschlossen werden, im Wesentlichen eigentlich, um einen Luftdruck zu bekommen:
- BME280: Druck, Temperatur, Feuchte
- BMP180: Druck, Temperatur
- LM75: Temperatur
- DHT22: Druck, Temperatur (dann sind aber nur zwei RFM69 möglich)
Über eine optionale Erweiterung (SC16IS750) kann:
- ein eigener Prozessor (mit eigener Firmware) angeschlossen werden, der sonstnochwas empfängt und dem LGW übergibt
- etwas, wie z.B. ein NanoCUL angeschlossen werden, dessen serielle Schnittstelle transparent auf einem Port im Web bereitgestellt wird
- ein vierter und fünfter RFM69 angeschlossen werden
- ein Summer angeschlossen werden, um von FHEM aus das LGW einen Alarm ausgeben zu lassen
Alle diese Daten stellt das LGW per WiFi an FHEM zu, dort wird es von den entsprechenden Modulen (JeeLink, LaCrosse, PCA301, ...) ganz normal weiterverarbeitet.
Ein LGW kann bis zu drei FHEMs versorgen (unter berücksichtigung einiger Regeln) und ein FHEM kann sich bei mehreren LGWs bedienen.
Liste der unterstützen Sensoren (ohne Garantie und vermutlich nicht vollständig)
Von den Steckdosen (und Ausnahmen) mal abgesehen, geht es hier immer um LaCrosse IT+ 868 MHz
TX21IT 17.241 kbps
TX25-IT 17.241 kbps
TX27-IT 17.241 kbps
TX29-IT 17.241 kbps
TX29DTH-IT 17.241 kbps
TX37 17.241 kbps
TX35TH-IT 9.579 kbps
TX35DTH-IT 9.579 kbps
30.3143.IT 17.241 kbps
30.3144.IT 17.241 kbps
30.3147.IT 17.241 kbps
30.3155WD 9.579 kbps Kritisch bezüglich der Frequenz.
30.3156WD 9.579 kbps
30.3187.IT 17.241 kbps
WT440XH 17.241 kbps
WS 1600 (TX22) 8.842 kbps
WS 1080 17.241 kbps Hinweise im Forum beachten
EC3000 200.000 kbps Energiemess-Steckdose
EMT7117 9.579 kbps Energiemess-Steckdose
PCA301 6.631 kbps 868950 kHz
LevelSender 17.241 kbps
Ach ja, bevor ich so was wie im vorhergehenden Beitrag noch öfter mal schreiben muss :)
Gibt es jemand, der Lust hätte, ein LaCrosseGateway Wiki zu pflegen?
Ich würde ihn auch mit Informationshäppchen versorgen, Teil 1 siehe oben ;)
Vieles könnte man auch einfach aus den in Beitrag 1 verlinkten Artikeln zu den Versionen nehmen, da habe ich ja schon vieles beschrieben.
Okay, ich denke ich habe es verstanden. Das LGW könnte den JeeLink USB Stick am Pi ersetzen und zusätzlich könnte ich die im Vergleich zu HM oder Z-Wave (Fibaro Wall Plug) deutlich günstigeren PCA301 Schaltsteckdosen einsetzen (nur dass der Fibaro Wall Plug wesentlich besser aussieht).
Danke für Deine Arbeit! Ich glaube ich bin damit infiziert und schaue heute Abend wo ich die Elektronikbauteile herbekomme. :-D
Eine Idee hätte ich noch: Bisher wird das LGW mit Netzstrom betrieben, wäre es nicht möglich das mit Batterie (oder Akku) zu betreiben?
Zitat von: Chris_Worms am 07 April 2016, 15:49:29
Eine Idee hätte ich noch: Bisher wird das LGW mit Netzstrom betrieben, wäre es nicht möglich das mit Batterie (oder Akku) zu betreiben?
Das ist leider so nicht möglich.
Zum Einen benötigt das WLan Modul zu viel Leistung und zum anderen ist ein Deepsleep nicht möglich, da man je nach Sensorenanzahl und Verwendung ja recht zeitnahe Messwerte haben will.
Zitat von: Chris_Worms am 07 April 2016, 15:49:29
Danke für Deine Arbeit! Ich glaube ich bin damit infiziert und schaue heute Abend wo ich die Elektronikbauteile herbekomme. :-D
Hallo Chris,
kleine Werbung in eigener Sache: https://forum.fhem.de/index.php/topic,45594.msg373669.html#msg373669
Gruß Peter
Zitat von: PeMue am 07 April 2016, 17:05:06
kleine Werbung in eigener Sache
Immer diese PCB dealer ... ;D ;D
Zitat von: Chris_Worms am 07 April 2016, 15:49:29
Danke für Deine Arbeit!
Und für die von PeMue, die er in die Platine(n) investiert hat.
Damit kann man das dann gleich "in ordentlich" machen.
Wenn wir jetzt noch einen Wiki-Schreiber finden, wird es langsam ein Projekt-Team ... ;)
Zitat von: Chris_Worms am 07 April 2016, 15:49:29
Eine Idee hätte ich noch: Bisher wird das LGW mit Netzstrom betrieben, wäre es nicht möglich das mit Batterie (oder Akku) zu betreiben?
Wie oli82 schon geschrieben hat, keine Chance.
Wenn wir mal von 150mA im Schnitt ausgehen, dann sind das 3,6 Ah am Tag, selbst hervorragende AA-Akkus sind nach weniger als einem Tag leer.
Mit einer Autobatterie könnte man wohl eine Woche schaffen. ;D ;D
Zitat von: Chris_Worms am 07 April 2016, 15:49:29nur dass der Fibaro Wall Plug wesentlich besser aussieht.
Stimmt.
<Scherz Mode="Funny"> <!-- nicht dass jemand sich gleich welche kauft -->
Kennt jemand Frequenz, data rate und Protokoll, dann bauen wir es ein ;D ;D ;D
</Scherz>
Zitat von: Wzut am 07 April 2016, 09:24:35
b. den Clock Speed in der Setup Seite von 1.000.000 auf 100.000 gesetzt, noch immer kein Zeichen zu sehen. Ich habe dann in meiner Verzweiflung auf einem UNO den Wire Master Write Sketch geflasht und mit dem Slave verbunden. Ergebnis : ich sah die Zeichen vom Master, ergo kann der Micro I2C empfangen. Als nächstes habe ich auf den Micro den I2C Scanner Sketch geflasht, dieser finden den UNO Master unter der Adresse 7F. Verbinde ich den Micro aber mit dem ESP wird kein Master oder anderer Teilnehmer am Bus gefunden
Jetzt bin ich mal dazu gekommen, mich mit diesem Thema zu beschäftigen.
Ich habe die Initialisierung im LGW etwas angepasst, dass es bei I2C-Clock < 400kHz mit der Prüfung, ob ein SC16IS750 dran ist, etwas wartet. Ein echter SC16IS750 funtioniert nach Anlegen der Versorgungsspannung sofort, der "Arduino-Clone" muss ja erst mal booten und initialisieren.
Das Clock-Stretching im LGW habe ich auch noch angepasst, dass es mit dem Arduino besser hinhaut.
Damit habe ich es hinbekommen, mit einem ATmega328P einen SC16IS750-Clone zu bauen, den das LGW als SC16IS750 erkennt und zumindest mal die GPIOs des SC16IS750 zu emulieren. Mit mehr als 100 kHz Clock speed habe ich es aber nicht zuverlässig hinbekommen.
Um diesen Thread hier nicht damit zu zerfleddern schlage ich vor, Du machst irgendwo in der "Bastelecke" einen "SC16IS750-Software-Clone" Thread auf, wo wir das weiter diskutiern können. Ich hänge dann dort die Test-LGW-Version und den Quellcode für den Arduino an.
KeyValueProtocol: Bin gerade darüber gestolpert, dass es das Log in meiner 2. FHEM-Instanz (Data port 82) vollschreibt, obwohl ich den Parameter "KV-Intervall" auf off stehen habe.
In meiner 1. Instanz (Data port 81) ist das Log dagegen - wie zu erwarten - leer.
Gilt der Parameter "KV-Intervall" nicht global?
Zitat von: Omega am 11 April 2016, 23:40:26
KeyValueProtocol: Bin gerade darüber gestolpert, dass es das Log in meiner 2. FHEM-Instanz (Data port 82) vollschreibt, obwohl ich den Parameter "KV-Intervall" auf off stehen habe.
In meiner 1. Instanz (Data port 81) ist das Log dagegen - wie zu erwarten - leer.
Gilt der Parameter "KV-Intervall" nicht global?
Seltsam, das kann ich weder im Quellcode noch durch ein praktisches Experiment nachvollziehen. Wenn
KV-Interval: off dann geht auf keinem Port was raus.
Sorry, als ich das geschrieben habe, hätte ich wohl besser schon im Bett liegen sollen ;) -- oder eine andere Brille aufsetzen sollen 8)
In der 1. Instanz habe ich ein monatliches Log, dass aber aufgrund KV-Intervall off" nicht befüllt wird.
In der 2. Instanz ist es ein Jahreslog. Und das hat natürlich noch (alte) Daten gehabt. Ich habe da allerdings nicht auf den Zeitstempel geachtet sondern bin auch hier von einem Monatslog ausgegangen.
Tut mir leid für den Fehlalarm.
LG Holger
Zitat von: HCS am 10 April 2016, 11:43:06
Um diesen Thread hier nicht damit zu zerfleddern schlage ich vor, Du machst irgendwo in der "Bastelecke" einen "SC16IS750-Software-Clone" Thread auf
OK, kein Problem. Wird aber noch ein paar Tage dauern da ich z.Z. leider keine Zeit & Möglichkeit habe in der Richtung irgend etwas zu testen.
Zitat von: Wzut am 13 April 2016, 09:42:33
Wird aber noch ein paar Tage dauern da ich z.Z. leider keine Zeit & Möglichkeit habe in der Richtung irgend etwas zu testen.
Macht nichts, ich habe ja einen echten SC16IS750 ;D
Erstmal großes Lob für die ganzen Erweiterungen, das Ding wird ja echt zur eierlegenden Wollmilchsau. :-)
Ich habe mir jetzt ein Gateway mit 1x SC16IS750, 4x RFM69 & 1x BMP180 gebaut.
Klappt auch soweit ganz gut, nur irgendwie haut das des öfteren mit den initCommands nicht ganz hin.
So soll es sein:
1=RFM69 f:868300 r:17241 (30.3143.IT Sensoren)
2=RFM69 f:868300 r:9579 (TX35TH-IT Sensoren)
3=RFM69 f:868300 r:20000 (EC3000)
4=RFM69 f:868950 r:6631 (PCA301)
Da 1&2 ja automatisch gesetzt werden, sind meine initCommands für 3&4 folgende:
4,868950,120i 20000#3r
Nur werden leider des öfteren die initCommands nicht korrekt ausgeführt und ich kann nicht so ganz nachvollziehen, warum das so ist.
Gibt's da evtl ne bessere Möglichkeit oder Schreibweise die Commands zu setzen?
Gruß
Stefan
Zitat von: StefanW am 18 April 2016, 16:32:40
So soll es sein:
1=RFM69 f:868300 r:17241 (30.3143.IT Sensoren)
2=RFM69 f:868300 r:9579 (TX35TH-IT Sensoren)
3=RFM69 f:868300 r:20000 (EC3000)
4=RFM69 f:868950 r:6631 (PCA301)
Da 1&2 ja automatisch gesetzt werden, sind meine initCommands für 3&4 folgende:
4,868950,120i 20000#3r
Bist Du sicher, dass sie nicht gesetzt werden? Ohne ein v am Ende meldet das LGW die neue Konfiguration nicht zurück und in "model" ändert sich dann nichts.
4,868950,120i 20000#3r vUnd bei einem LGW sollte man auf alle Fälle das timeout Attribut setzen, sonst verbindet sich FHEM nicht neu auf das LGW, wenn es (oder das wlan) mal weg war.
Z.B.
attr myJeeLink timeout 60,60Zitat von: StefanW am 18 April 2016, 16:32:40das Ding wird ja echt zur eierlegenden Wollmilchsau. :-)
Wolle könnte das LGW auf Port 88 und Milch auf Port 89 bereitstellen, aber die Sau ist nach dem zerlegen in mehrere TCP-Pakete dann tot ;D ;D ;D
Zitat von: HCS am 18 April 2016, 16:56:31
Bist Du sicher, dass sie nicht gesetzt werden? Ohne ein v am Ende meldet das LGW die neue Konfiguration nicht zurück und in "model" ändert sich dann nichts.
4,868950,120i 20000#3r v
Und bei einem LGW sollte man auf alle Fälle das timeout Attribut setzen, sonst verbindet sich FHEM nicht neu auf das LGW, wenn es (oder das wlan) mal weg war.
Z.B.
attr myJeeLink timeout 60,60
Wolle könnte das LGW auf Port 88 und Milch auf Port 89 bereitstellen, aber die Sau ist nach dem zerlegen in mehrere TCP-Pakete dann tot ;D ;D ;D
Gute Frage, ich habe bis jetzt nur auf "model" geachtet.
Das v und timeout werde ich mal testen.
Vielen Dank
V1.17
DHT22
Totgesagte leben länger
Optional kann nun anstatt Radio#3 ein DHT22 angeschlossen werden.
Das LGW erkennt automatisch, ob man Radio3 oder einen DHT22 oder nichts hat
OTA-Update
Wenn man ein OTA-Update per upload angestoßen hat, kam es manchmal vor, dass das LGW dabei stehen geblieben ist
Help page
Das Frontend hat eine "Help-Page" bekommen, auf der die Commands, die man von FHEM aus senden kann, aufgeführt sind
Konfiguration
Es gibt zwei neue Einstellungen:
"Use MDNS"
legt fest, ob das LGW seine IP-Adresse per MDSN bekannt gibt. Nützt aber nur, wenn man einen Mac hat oder bei Windows einen Bonjour-Service laufen hat.
Ist eigentlich eh nur beim Entwickeln sinnvoll, kann also üblicherweise ausgeschaltet bleiben.
"SC16IS750-Clone"
ist vorerst mal für Wzut. Wenn aktiviert, wird die I2C clock auf 100 kHz runtergenommen und
es wird an einigen Stellen etwas auf die Bremse getreten, dass ein SC16IS70-Clone, der langsamer
als echte Hardware ist, mitkommt.
Sollte man ohne zwingenden Grund nicht aktivieren.
Serial bridge
Das LGW kann nun optional die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitstellen
Dazu gibt es die neuen settings "Serial bridge port" und "Serial bridge baud" auf der config page
Das LGW überträgt transparent die Daten der seriellen Schnittstelle an FHEM und umgekehrt.
Damit kann man z.B. einen NanoCUL an das LGW dran hängen und in FHEM verwenden.
Vorehensweise:
- Einen NanoCUL bauen, z.B. auf Basis eines Arduino Pro Mini, flashen und testweise in Betrieb nehmen. Keinen Arduino Nano nehmen, den USB-Port können wir nicht brauchen.
- Den NanoCUL an die serielle Schnittstelle des SC16IS70 anschließen
- Port und baud rate auf der Setup-Page des LGW festlegen, z.B. Port 85 und 38400 baud
- CUL in FHEM definieren: "define cul211 CUL 192.168.31.211:85 0000"
Dass sich das CUL-Device in FHEM neu auf das LGW verbindet, wenn dieses mal weg, gebootet, ... war, kann man sich diesen at definieren:
define cul211Reconnector at +*00:00:30 {\
my $deviceName = "cul211";;\
my $version = CommandGet("", $deviceName . " version");;\
my $gotAnswer = index($version, 'No answer') == -1;;\
\
if(!$gotAnswer) {\
fhem("set " . $deviceName . " reopen");;\
}\
\
}
Hi,
habe heute versucht den LGA in berieb zu nehmen leider ohne Erfolg.
nach mehrmaligem flashen bekomme ich immer nur folgende Ausgabe an der seriellen Schnittstelle:
***CLEARLOG***
This is line 5 of void setup(void)
LaCrosseITPlusReader.Gateway V1.17 Free heap: 23416
SDK: 1.5.1(e67da894)
Reset: Exception
Fatal exception:3 flag:2 (EXCEPTION) epc1:0x401002f0 epc2:0x00000000 epc3:0x0000 0000 excvaddr:0x4000fdc2 depc:0x00000000
Read settings
Starting I2C with 400000 kHz
Starting wifi
Start WIFI_STA
Exception (3):
epc1=0x401002f0 epc2=0x00000000 epc3=0x00000000 excvaddr=0x4000fdc2 depc=0x00000 000
ctx: cont
sp: 3fff42e0 end: 3fff4c80 offset: 01a0
>>>stack>>>
3fff4480: 40202599 00000030 00000008 ffffffff
3fff4490: 4021c481 00000000 00000030 3fff4590
3fff44a0: 00000484 00000484 000003fd 401004f4
3fff44b0: 00000000 00001000 000003fd 401072a8
3fff44c0: 40004b31 3fff44f0 0000001c 40241049
3fff44d0: 401065e6 40241131 3fff7324 000003ff
3fff44e0: 000003fd 3fff4590 3fff7324 000003fd
3fff44f0: ffffff00 55aa55aa 00000010 0000001c
3fff4500: 0000001c 000000e8 000000ea 000003ff
3fff4510: 40241520 3fff7324 3fff7324 000000ff
3fff4520: 00000001 3fff45b0 4024167b 00000008
3fff4530: 3fff7324 000000ff 3fff4590 00000000
3fff4540: 3fff73e4 3fff45f1 00000001 40241708
3fff4550: 3fff4590 3fff7324 3fff48e0 3fff3720
3fff4560: 3fff45b0 3fffd65c 3fff7324 3fff48e0
3fff4570: 40241744 3fff4bb4 00000000 4021e213
3fff4580: 4020ad78 3fff72e4 3fff72e4 4021e245
3fff4590: 3fff3c00 0000049a 0000049a 4010020c
3fff45a0: 3fff3730 00000000 3fff45dc 4010068c
3fff45b0: 3ffeb600 00000000 3fff3720 4021e168
3fff45c0: 3fff3730 00000000 3fff3720 40216e4c
3fff45d0: 3fff3c4c 00000497 00000497 4010020c
3fff45e0: 3fff48e0 3fff48e0 3fff4bb8 4010068c
3fff45f0: 3ffe8f90 00000000 3fff4ba8 4021e168
3fff4600: 3fff48e0 3fff48e0 3fff4bb4 402099a2
3fff4610: 3fff6c3c 0000000f 00000000 3fff6c54
3fff4620: 0000000f 00000000 3fff6c6c 0000000f
3fff4630: 00000000 3fff6c84 0000000f 00000000
3fff4640: 3fff6d3c 0000000f 00000000 3fff6d54
3fff4650: 0000000f 00000000 3fff6d6c 0000000f
3fff4660: 00000000 3fff6d84 0000000f 00000000
3fff4670: 3fff6d9c 0000000f 00000000 3fff6db4
3fff4680: 0000000f 00000000 3fff6dcc 0000000f
3fff4690: 00000000 3fff6de4 0000000f 00000000
3fff46a0: 3fff6dfc 0000000f 00000000 3fff6e14
3fff46b0: 0000000f 00000000 3fff6e2c 0000000f
3fff46c0: 00000000 3fff6e44 0000000f 00000000
3fff46d0: 3fff6e5c 0000000f 00000000 3fff6e74
3fff46e0: 0000000f 00000000 3fff6e8c 0000000f
3fff46f0: 00000000 3fff6ea4 0000000f 00000000
3fff4700: 3fff6ebc 0000000f 00000000 3fff6ed4
3fff4710: 0000000f 00000000 3fff6eec 0000000f
3fff4720: 00000000 3fff6f04 0000000f 00000000
3fff4730: 3fff6f1c 0000000f 00000000 3fff6f34
3fff4740: 0000000f 00000000 3fff6f4c 0000000f
3fff4750: 00000000 3fff6f64 0000000f 00000000
3fff4760: 3fff6f7c 0000000f 00000000 3fff6f94
3fff4770: 0000000f 00000000 3fff6fac 0000000f
3fff4780: 00000000 3fff6fc4 0000000f 00000000
3fff4790: 3fff6fdc 0000000f 00000000 3fff6ff4
3fff47a0: 0000000f 00000000 3fff700c 0000000f
3fff47b0: 00000000 3fff7024 0000000f 00000000
3fff47c0: 3fff703c 0000000f 00000000 3fff7054
3fff47d0: 0000000f 00000000 3fff706c 0000000f
3fff47e0: 00000000 3fff7084 0000000f 00000000
3fff47f0: 3fff709c 0000000f 00000000 3fff70b4
3fff4800: 0000000f 00000000 3fff70cc 0000000f
3fff4810: 00000000 3fff70e4 0000000f 00000000
3fff4820: 3fff70fc 0000000f 00000000 3fff7114
3fff4830: 0000000f 00000000 3fff712c 0000000f
3fff4840: 00000000 3fff7144 0000000f 00000000
3fff4850: 3fff715c 0000000f 00000000 3fff7174
3fff4860: 0000000f 00000000 3fff718c 0000000f
3fff4870: 00000000 3fff71a4 0000000f 00000000
3fff4880: 3fff71bc 0000000f 00000000 3fff71d4
3fff4890: 0000000f 00000000 3fff71ec 0000000f
3fff48a0: 00000000 3fff7204 0000000f 00000000
3fff48b0: 3fff721c 0000000f 00000000 3fff7234
3fff48c0: 0000000f 00000000 3fff724c 0000000f
3fff48d0: 00000000 3fff7264 0000000f 00000000
3fff48e0: 00000000 3fff652c 0000000f 00000000
3fff48f0: 3fff65e4 0000000f 00000000 3fff6484
3fff4900: 0000000f 00000000 3fff664c 0000000f
3fff4910: 00000000 3fff6664 0000000f 00000000
3fff4920: 3fff667c 0000000f 00000000 3fff6694
3fff4930: 0000000f 00000000 3fff66ac 0000000f
3fff4940: 00000000 3fff66c4 0000000f 00000000
3fff4950: 3fff66dc 0000000f 00000000 3fff66f4
3fff4960: 0000000f 00000000 3fff670c 0000000f
3fff4970: 00000000 3fff6724 0000000f 00000000
3fff4980: 3fff673c 0000000f 00000000 3fff6754
3fff4990: 0000000f 00000000 3fff6804 0000000f
3fff49a0: 00000000 3fff681c 0000000f 00000000
3fff49b0: 3fff6834 0000000f 00000000 3fff684c
3fff49c0: 0000000f 00000000 3fff6864 0000000f
3fff49d0: 00000000 3fff687c 0000000f 00000000
3fff49e0: 3fff6894 0000000f 00000000 3fff68ac
3fff49f0: 0000000f 00000000 3fff68c4 0000000f
3fff4a00: 00000000 3fff68dc 0000000f 00000000
3fff4a10: 3fff68f4 0000000f 00000000 3fff690c
3fff4a20: 0000000f 00000000 3fff6924 0000000f
3fff4a30: 00000000 3fff693c 0000000f 00000000
3fff4a40: 3fff6954 0000000f 00000000 3fff696c
3fff4a50: 0000000f 00000000 3fff6984 0000000f
3fff4a60: 00000000 3fff699c 0000000f 00000000
3fff4a70: 3fff69b4 0000000f 00000000 3fff69cc
3fff4a80: 0000000f 00000000 3fff69e4 0000000f
3fff4a90: 00000000 3fff69fc 0000000f 00000000
3fff4aa0: 3fff6a14 0000000f 00000000 3fff6a2c
3fff4ab0: 0000000f 00000000 3fff6a44 0000000f
3fff4ac0: 00000000 3fff6a5c 0000000f 00000000
3fff4ad0: 3fff6a74 0000000f 00000000 3fff6a8c
3fff4ae0: 0000000f 00000000 3fff6aa4 0000000f
3fff4af0: 00000000 3fff6abc 0000000f 00000000
3fff4b00: 3fff6ad4 0000000f 00000000 3fff6aec
3fff4b10: 0000000f 00000000 3fff6b04 0000000f
3fff4b20: 00000000 3fff6b1c 0000000f 00000000
3fff4b30: 3fff6b34 0000000f 00000000 3fff6b4c
3fff4b40: 0000000f 00000000 3fff6b64 0000000f
3fff4b50: 00000000 3fff6b7c 0000000f 00000000
3fff4b60: 3fff6b94 0000000f 00000000 3fff6bac
3fff4b70: 0000000f 00000000 3fff6bc4 0000000f
3fff4b80: 00000000 3fff6bdc 0000000f 00000000
3fff4b90: 3fff6bf4 0000000f 00000000 3fff6c0c
3fff4ba0: 0000000f 00000000 3fff6c24 0000000f
3fff4bb0: 00000000 00000000 00000000 00000000
3fff4bc0: 00000000 00000000 00000000 00000000
3fff4bd0: 00000000 00000000 00000000 feefeffe
3fff4be0: feefeffe feefeffe feefeffe feefeffe
3fff4bf0: feefeffe feefeffe feefeffe feefeffe
3fff4c00: feefeffe feefeffe feefeffe feefeffe
3fff4c10: feefeffe feefeffe feefeffe feefeffe
3fff4c20: feefeffe feefeffe feefeffe feefeffe
3fff4c30: feefeffe feefeffe feefeffe feefeffe
3fff4c40: feefeffe feefeffe feefeffe feefeffe
3fff4c50: feefeffe feefeffe feefeffe 3fff3c58
3fff4c60: 3fffdad0 00000000 3fff3c50 4021bd38
3fff4c70: feefeffe feefeffe 3fff3c60 40100718
<<<stack<<<
!▒
B▒▒!!▒▒
1▒ ▒&▒K▒SH▒kH
▒@▒▒Oֈ▒▒▒HN=▒▒HN%▒▒
***CLEARLOG***
woran kanns liegen?
Danke im Voraus
Komando zurück ...
Nachdem ich den ESP nochmals clean geflasht haben rennt es nun ...
Zitat von: noice am 19 April 2016, 22:21:10
Nachdem ich den ESP nochmals clean geflasht haben rennt es nun ...
Interessant.
Bei einem meiner devkits ist mir das auch schon (sehr selten) passiert und mit einem meiner usb-seriell-adapter mit FT232R drauf (Ziel: plain ESP-12E) passiert das ganz massiv.
Der serielle upload läuft ohne Fehler durch aber es läuft nicht richtig. Nochmal flashen und dann geht es.
Mit meinem CP2102 usb-seriell-adapter passiert das nie und bei OTA auch nie.
Siehe auch hier: https://forum.fhem.de/index.php/topic,43672.msg409629.html#msg409629
Es scheint wohl möglich zu sein, dass der Upload die firmware irgendwie mit gekippten bytes hochlädt, ohne dabei Fehler zu melden.
921600 Baud sind aber auch heftig, möglicherweise bekommt das nicht jede Betriebssystem-Hardware-Kombination sauber hin.
Welche Komponenten sind denn bei Dir im Spiel?
Also, das OTA-Update finde ich einfach Klasse – egal, wo das LGW verbaut ist, kann ich es ganz einfach auf den neuesten Stand bringen ;D.
Danke noch mal für das LGW und die unkomplizierte Nutzungsmöglichkeit.
Eine andere Kleinigkeit / Idee habe ich aber noch.
Die Setup-Seite kann ohne ein Passwort aufgerufen werden und zeigt dann auch noch das WLAN-Passwort im Klartext an. Ich fände es gut, wenn man die Möglichkeit hätte, den Zugriff auf die Setup-Seite abzusichern. Muss ja nicht jeder nutzen. Ich würde es gerne können.
Und das Passwort – wenn möglich – nur als *** anzeigen und erst über ein Auswahlfeld das Passwort im Klartext anzeigen lassen, wenn gewünscht.
Und falls einer sein Passwort vergisst, könnte er ja manuell flashen und hätte wieder Zugriff.
Zitat von: Omega am 20 April 2016, 09:30:23
Und das Passwort – wenn möglich – nur als *** anzeigen
Das sollte recht einfach machbar sein, dann werde ich aber SSID und Passwort versternen.
Zitat von: Omega am 20 April 2016, 09:30:23
Die Setup-Seite kann ohne ein Passwort aufgerufen werden ...
Das ist etwas aufwändiger. Ich glaube, dass es dann eher sinnvoll ist, das komplette Frontend abzusichern.
Wer die Konfiguration nicht sehen darf, soll vermutlich auch keinen Reset auslösen, kein OTA-Update anstoßen und auch nicht auf der Log-Page Kommandos absetzen.
Da könnte er ja ein 8266e absetzen, und sich dann ein neues Passwort konfigurieren, danach ist der Feind Admin und Du nicht mehr :)
Zitat von: Omega am 20 April 2016, 09:30:23
Und falls einer sein Passwort vergisst, könnte er ja manuell flashen und hätte wieder Zugriff.
Das hilft nicht, beim Flashen bleibt das EEPROM unberührt, und da steht das Passwort (und die restliche Konfiguration) drin.
Aber man kann (jetzt schon) über die serielle Schnittstelle ein "8266e" an das LGW senden, dann wird das EEPROM geleert und man hat die Konfiguration kompett zurückgesetzt.
Ich habe das alles mal in die Wunschliste reingeschrieben.
ZitatIch glaube, dass es dann eher sinnvoll ist, das komplette Frontend abzusichern
Stimmt. Im Prinzip vergleiche ich das mit meinem Router. Da muss ich mich auch zuallererst identifizieren.
Danach möchte man aber ggf. voller Stolz seinen Freunden zeigen, was man da so tolles hat – daher der Wunsch nach den ***.
Zitat von: HCS am 20 April 2016, 08:10:27
Interessant.
Bei einem meiner devkits ist mir das auch schon (sehr selten) passiert und mit einem meiner usb-seriell-adapter mit FT232R drauf (Ziel: plain ESP-12E) passiert das ganz massiv.
Der serielle upload läuft ohne Fehler durch aber es läuft nicht richtig. Nochmal flashen und dann geht es.
Mit meinem CP2102 usb-seriell-adapter passiert das nie und bei OTA auch nie.
Siehe auch hier: https://forum.fhem.de/index.php/topic,43672.msg409629.html#msg409629
Es scheint wohl möglich zu sein, dass der Upload die firmware irgendwie mit gekippten bytes hochlädt, ohne dabei Fehler zu melden.
921600 Baud sind aber auch heftig, möglicherweise bekommt das nicht jede Betriebssystem-Hardware-Kombination sauber hin.
Welche Komponenten sind denn bei Dir im Spiel?
Habe auch ein dev Kit v1. mit cp2102 ....
Habe bestimmt 10 mal mit verschiedenen bautraten und Programmen probiert zu flashen .. erst nachdem ich über nodemcu in standart einstellungen die default aufgespielt habe und dann nochmals deine v1.17 hat es dann funktioniert
Kann natürlich auch Zufall gewesen sein ;)
Aber davon abgesehen ... wirklich top Arbeit die hier geleistet wird ... danke für den LGW
Grüsse Mirko
PS: Passwortschutz wäre schon zu empfehlen 8)
Mobil erstellt daher kurz gehalten
Zitat von: noice am 20 April 2016, 13:06:33Kann natürlich auch Zufall gewesen sein ;)
Glaub ich dann doch nicht.
Zitat von: noice am 20 April 2016, 13:06:33
Habe bestimmt 10 mal mit verschiedenen bautraten und Programmen probiert zu flashen .. erst nachdem ich über nodemcu in standart einstellungen die default aufgespielt habe und dann nochmals deine v1.17 hat es dann funktioniert
Die serielle flasherei hat wohl noch ein paar Geheimnisse ... :o ::)
Wenn im EEPROM völlig abgefahrene Dinge stehen, könnte das LGW schon mal auf den falschen Pfad gelangen ...
Und eventuell überschriebt NodeMCU diesen Bereich im Flash (ja, das EEPROM ist einfach ein Bereich im flash-Speicher) und danach ist die Situation für das LGW besser.
Wir werden es beobachten müssen, ob mehr Anwender mit mehr ähnlichen Erfahrungen irgend wann die Erkenntnis zusammentragen.
Bei OTA kenne ich bisher nur zwei Varianten:
- wurde hochgeladen und dann ist es auch immer gelaufen
- der Upload ist erkennbar fehlgeschlagen.
Hi,
hat jemand eine gute Bezugsquelle für den Kauf des NodeMCU und RFM69, am liebsten mit Versand aus Deutschland?
Ansonsten würde der hier doch passen, oder?
http://www.ebay.de/itm/NodeMCU-ESP8266-ESP-12E-V1-0-Wifi-CP2102-IoT-Lua-267-/322067217829?hash=item4afcb3bda5:g:AVsAAOSwgApXA~Id
Den RFM69CW finde ich momentan nur bei Pollin, dann zu 10 € inkl. Versand.
Evtl. habt ihr da noch Vorschläge?
Die WS 1600 wäre immer noch eine gute Wahl? Oder würdet ihr da inzwischen ein anderes Model empfehlen?
Danke & Gruß,
Tobi
Zitat von: onkel-tobi am 22 April 2016, 21:27:37
http://www.ebay.de/itm/NodeMCU-ESP8266-ESP-12E-V1-0-Wifi-CP2102-IoT-Lua-267-/322067217829?hash=item4afcb3bda5:g:AVsAAOSwgApXA~Id
Das ist richtig
Zitat von: onkel-tobi am 22 April 2016, 21:27:37
Die WS 1600 wäre immer noch eine gute Wahl? Oder würdet ihr da inzwischen ein anderes Model empfehlen?
Meine WS 1600 läuft noch einwandfrei und ich bin zufrieden. Es gibt außer der WS 1080 aber auch keine Alternative, wenn das LGW sie empfangen soll und die ist ein Lotteriespiel, ob man die Version bekommt, die mit dem LGW zusammen geht.
RFM69CW: Pollin oder China
Zitat von: onkel-tobi am 22 April 2016, 21:27:37
Die WS 1600 wäre immer noch eine gute Wahl? Oder würdet ihr da inzwischen ein anderes Model empfehlen?
Die WS 1600 hat sicher das beste Preis Leistungsverhältnis.
Bei der Regenmenge hängt sie nach meiner Beobachtung teilweise 10 - 20 % hinterher.
Falls du mehr Geld investieren willst ist die Vantage sicher die bessere Wahl. Sie läuft ja mit dem Jeelink V3 und dem Key Value Protokoll.
Ob sich das auch auf dem LaCrosseGateway integrieren lässt müsste HCS beurteilen.
Gruß Billy
Zitat von: Billy am 22 April 2016, 22:52:10
Falls du mehr Geld investieren willst ist die Vantage sicher die bessere Wahl. Sie läuft ja mit dem Jeelink V3 und dem Key Value Protokoll.
Ob sich das auch auf dem LaCrosseGateway integrieren lässt müsste HCS beurteilen.
Ich glaube eher nicht, vor allem, weil ich keine habe.
Hi,
danke für eure Antworten,
leider waren die bei ebay dann ganz schnell weg...
Geht auch der hier?
http://www.ebay.de/itm/NodeMCU-ESP8266-ESP-12-L293-I-O-Breakout-Lua-WiFi-Internet-Things-LoLin-Arduino-/321863715724?
Danke & Gruß,
Tobi
Da ich kein V3 habe, kann ich es nicht bestätigen. Vermutlich ja.
Aber wenn es auf die Platine von PeMue soll, dann Nein.
Siehe hier: https://forum.fhem.de/index.php/topic,45594.msg430183.html#msg430183
Ist aber eh egal, sind doch auch nicht lieferbar.
Hallo,
kann mir jemand sagen, was ich falsch machen, wenn sich bei mir kein WLAN aufbaut? Ich habe die aktuelle Firmware (Seite 1) mehrfach draufgespielt (unterschiedliche Baudraten und Tools), jedoch bekomme ich kein neues WLAN mit der SSID LaCrosse... . Gewartet habe ich mehrere Minuten.
Restart per Knopf wie auch das Kabel von Notebook abgezogen. Kein Erfolg.
Über den seriellen Port bekomme ich nur sinnvolle Werte auf der Baudrate 74880.
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
ets_main.c
Auf der 57600 kommt nach dem Neustart nur:
BªiYUQ...PBIÊIÔeZE±VÕšË,©uiPÕ¥jš•VUŠQTiYªPÕÿ
Was kann ich noch machen.
Zitat von: joe.lee am 23 April 2016, 23:56:51
Über den seriellen Port bekomme ich nur sinnvolle Werte auf der Baudrate 74880.
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
ets_main.c
Das sieht so aus als ob die LGW firmware nicht drauf ist oder erst gar nicht anläuft.
Flashe mal NodeMCU drauf und schau, ob die läuft, und falls ja, dann danach das LGW nochmal.
Was hast Du denn als Hardware? (devkit / ESP12-E, ...) und was ist angeschlossen?
Aktuelle ncunode hatte ich auch schon drauf. Die läuft an. Danach habe ich 3x formatiert (Esplorer) und das Jeelink_LacrosseGateway draufgespielt.
Momentan ist nichts angeklemmt. Ich habe bewusst alles abgebaut, um sicher zugehen, dass die Stromversorgung nicht zu gering ist und die Spannung einbricht.
Ich habe ein devkit in der Version 1.0 oder 1.1.
Ich bin ein Stück weiter gekommen. Mein Bin-File war nur 16kB groß. Nach dem erneuten Download war es dann 400kB.
Jetzt öffnet sich ein AP aber nach dem verbinden kann ich die 192.168.222.1/setup nicht öffnen.
Mit einer eigenen Stromversorgung (1a Netzteil) und der Verbindung vom Smartphone konnte ich auf das Setup Meün zugreifen und die Zugangsdaten einrichten. Jetzt ist das Gerät in FHEM zu erreichen.
Keine Ahnung warum es über den PC nicht funktioniert hat.
Zitat von: Omega am 20 April 2016, 09:30:23
Die Setup-Seite kann ohne ein Passwort aufgerufen werden und zeigt dann auch noch das WLAN-Passwort im Klartext an. Ich fände es gut, wenn man die Möglichkeit hätte, den Zugriff auf die Setup-Seite abzusichern. Muss ja nicht jeder nutzen. Ich würde es gerne können.
Und das Passwort – wenn möglich – nur als *** anzeigen und erst über ein Auswahlfeld das Passwort im Klartext anzeigen lassen, wenn gewünscht.
Anbei mal eine Version zum Testen vorab.
Auf der Setup page bei "Frontend password" ein passwort eintragen.
Wenn man es leer lässt, funktioniert es wie bisher, also ohne Login.
Die Passwörter werden nun auch als Sterne angezeigt. Eine Umschaltung zwischen Stern und Klartext wird es aber eher nicht geben.
Super, dass du dich sofort daran gemacht hast. Danke.
Hab's natürlich sofort probiert.
Es geht in die richtige Richtung. Folgendes finde ich allerdings erwähnenswert:
Das Frontend Passwort muss ohne Kontrolleingabe (2. Passwortfeld) bzw. ohne Möglichkeit auf Umschaltung in Klartext vergeben werden. Ist ein potenzielles Risiko. Am PC könnte ich damit aber trotzdem gut zurechtkommen.
Müsste ich das aber so über's Handy eingeben, hätte ich meine Probleme, da die verschiedenen Handytastaturen (z.B. Swype) versuchen, Eingaben zum vermeintlich richtigen Wort umzuschreiben. Wenn ich das aber nicht kontrollieren kann (Sternchenanzeige), wird's schwierig.
Wenn du also noch Zeit und Lust hast ...
Grerade noch aufgefallen. Wenn man das Frontend Passwort einmal richtig eingegeben hat, wird es beim nächsten neuem Aufruf der Seite nicht mehr abgefragt. Das ist so bestimmt nicht geplant ;).
Zitat von: Omega am 24 April 2016, 22:43:23
Grerade noch aufgefallen. Wenn man das Frontend Passwort einmal richtig eingegeben hat, wird es beim nächsten neuem Aufruf der Seite nicht mehr abgefragt. Das ist so bestimmt nicht geplant ;).
Doch doch, das ist so geplant. Die Session bleibt so lange gültig bis man den Browser schließt oder sich oben in der Navigation explizit abmeldet.
Zitat von: Omega am 24 April 2016, 22:43:23
Das Frontend Passwort muss ohne Kontrolleingabe (2. Passwortfeld) bzw. ohne Möglichkeit auf Umschaltung in Klartext vergeben werden.
Kontrolleingabe könnte machbar sein, dann müsste ich aber wohl beim Speichern die komplette Seite verwerfen, wenn es nicht übereinstimmt und man müsste die anderen Änderungen auch nochmal eingeben.
Zwischen Passwort */Klartext hin und herschalten fehlt mir aktuell die Idee, wie man das machen kann.
Das Problem ist, dass ich kein jQuery und nichts im frontend zur Verfügung habe und jegliches html in PROGMEM strings im Quellcode hintippe.
Muss ich mal auf mich wirken lassen, aber wenn man dann noch eine Kontrolleingabe hat, dann ist das entsternen ja nicht unbedingt erforderlich.
Eins von beiden reicht ja.
ZitatDie Session bleibt so lange gültig bis man den Browser schließt oder sich oben in der Navigation explizit abmeldet
Stimmt – finde ich so auch gut.
ZitatZwischen Passwort */Klartext hin und herschalten
Idee:
- die jetzige Setup-Seite lassen wie sie ist (ggf. mit dem Unterschied, dass das Feld ,,Frontend password" nur zur *-Ausgabe verwendet wird)
- Eine zusätzliche Seite mit 3 Feldern
Frontend password alt
Frontend password neu
Frontend password neu
Eingaben in allen 3 Feldern grundsätzlich als *-Text anzeigen. Ist noch kein Passwort vergeben, bleibt 1. Feld leer. Die Eingaben in den beiden anderen Feldern müssen übereinstimmen. Wenn das der Fall ist, ist das neue Passwort gültig und kann gespeichert werden. Falls bereits ein Passwort vergeben war, muss das natürlich auch mit der Eingabe übereinstimmen. Ansonsten Fehlerhinweis. Falls ein Fehlerhinweis nicht möglich oder schwierig umzusetzen ist: Verweigern von ,,Save and restart". Dann merkt man schon, dass irgendwas nicht stimmt. Mit einem Text auf der Seite könnte man auch darauf vorsorglich hinweisen.
Das hat aber wirklich Zeit. Deine jetzige Lösung deckt ja bereits das Meiste ab.
Danke!
Holger
Zitat von: HCS am 24 April 2016, 23:40:12
Zwischen Passwort */Klartext hin und herschalten fehlt mir aktuell die Idee, wie man das machen kann.
Also vor 20 Jahren habe ich sowas mit etwas Java Script gemacht :)
Damit kannst du auch leicht vor dem Absenden der Seite prüfen ob PW1 und PW2 gleich sind und bei Ungleichheit das Formular erst gar nicht senden. ( ggf. kannst dann sogar noch andere Prüfungen einbauen)
Zitat von: Wzut am 25 April 2016, 09:35:46
Also vor 20 Jahren habe ich sowas mit etwas Java Script gemacht :)
JS wollte ich eigentlich aus der SetupPage raus halten um die Chance, dass die dann bei einigen auch nicht geht, zu minimieren.
Geht bei Dir inzwischen die Log-Page? Da ist nämlich JS drin.
Zitat von: Omega am 25 April 2016, 08:58:45
Eine zusätzliche Seite mit 3 Feldern
Frontend password alt
Frontend password neu
Frontend password neu
Ich denke, das "Frontend password alt" kann man sich sparen. Wenn man drin ist, hat man es ja gewusst und wenn man im Internet-Caffee den Browser in LGW angemeldet stehen lässt und geht, dann hat man halt Pech gehabt. ;D
Es nutzt auch nichts, denn solange man autentifiziert ist, kann man auf der Log-Page einen 8266e absetzen, dann kommt das LGW mit dem AccessPoint ohne Passwort und Konfiguration hoch und man kann es nach belieben neu konfigurieren.
Ich baue "Frontend password" und "Retype password" ein und prüfe serverseitig, ob sie übereinstimmen.
Zitat von: HCS am 06 Dezember 2015, 10:01:57
Quellcode verfügbar
hier: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip
Zum compilieren (wofür es eigentlich keinen Grund gibt, das binary reicht) ist (aktuell) folgende tool chain erforderlich:
- Arduino IDE V1.6.5 (nicht V1.6.6)
Der Inhalt ist aktuell die V1.17 ?
Habe gerade erfolglos versucht den Quellcode mit der Arduino IDE 1.6.5 durchlaufen zu lassen.
1. Fehler : in der I2CBase.h wird die arduino.h nicht gefunden -> Fix #include "Arduino.h"
2. Fehler : in der WebFrontend.cpp -> #include "Help.h" , eine Help.h habe ich aber nicht bzw. ich nicht in der .zip Datei
Kannst du die bitte ggf. hier mal direkt posten ?
Zitat von: Wzut am 27 April 2016, 17:55:47
Der Inhalt ist aktuell die V1.17 ?
Ja, die kürzlich angehängte 1.18 bin war nur eine Vorabversion um den Login zu testen
Zitat von: Wzut am 27 April 2016, 17:55:47
1. Fehler : in der I2CBase.h wird die arduino.h nicht gefunden -> Fix #include "Arduino.h"
Grrrr, immer der gleiche Fehler, der mir da passiert. Habe es korrigiert.
Zitat von: Wzut am 27 April 2016, 17:55:47
2. Fehler : in der WebFrontend.cpp -> #include "Help.h" , eine Help.h habe ich aber nicht bzw. ich nicht in der .zip Datei
Kannst du die bitte ggf. hier mal direkt posten ?
Ja, anbei. Und das script, das eine Version zusammenstellt, habe ich auch korrigiert.
BIG THX, mit der Help.h lief es ohne weitere Fehler durch. Gestern sind auch meine Wemos Minis aus China eingetroffen (der erste ist schon mit der V1.18 betankt), so das ich hoffentlich am WE dann auch die Zeit finde endlich mal weiter zu machen :)
Zitat von: noice am 20 April 2016, 13:06:33
Habe bestimmt 10 mal mit verschiedenen bautraten und Programmen probiert zu flashen .. erst nachdem ich über nodemcu in standart einstellungen die default aufgespielt habe und dann nochmals deine v1.17 hat es dann funktioniert
Hi,
scheine dasselbe Problem zu haben. Heute ,morgen habe ich den AP mal kurz gesehen, kam aber nicht auf die setup Seite, danach noch gefühlte 100 mal geflasht, aber ohne Erfolg.
Welche bin hast du dann vorher draufgespielt?
Danke & Gruß,
Tobi
Die standart .bin von nodemcu
Also einfach alles auf default setzen
Gesendet von meinem Valencia2_Y100pro mit Tapatalk
Zitat von: onkel-tobi am 30 April 2016, 20:11:39
scheine dasselbe Problem zu haben. Heute ,morgen habe ich den AP mal kurz gesehen, kam aber nicht auf die setup Seite, danach noch gefühlte 100 mal geflasht, aber ohne Erfolg.
Wenn Du den AP gesehen hast, hat Du nicht das "noice-Problem" sondern vermutlich das Problem, das ich vor zwei Stunden auch entdeckt und hoffentlich behoben habe, nämlich dass der AP aufgemacht wird und dann entweder kein connect drauf geht oder man trotz connect nicht auf das Frontend kommt und dass es sein kann, dass man mit einem anderen Rechner drauf kommt (hatte kürzlich schon mal jemand).
Wenn Du bis morgen Geduld aufbringen kannst, gibt es eine V1.18, mit der das besser gehen sollte.
Hi,
danke für eure Antworten.
Werde dann die v 1.18 probieren, eilt ja nicht.
Gruß,
Tobi
AP Mode bei neuen ESPs war bei mir auch immer ein Horror, da ich dann jedesmal das verhasste Tablet rauskramen mußte,
daher habe ich im Quellcode den Default für SSID und PW von --- auf test geändert.
Das offene WLAN mit test,test habe ich ganz schnell aktiviert/deaktivert und bekomme danach auch sofort gleich eine IP aus meinem Subnetz.
BTW: meine Arduino - ESP I2C Verbindung steht nun, @HCS würdest du bitte deine Beta für den Arduino Sketch posten ?
V1.18
Frontend-Passwort
Das Frontend kann man nun mit eine Passwort absichern. Festgelegt wird es auf der Setup-Page
Sterne
Passwörter werden nun nicht mehr im Klartext angezeigt
Access point nicht erreichbar
Es konnte vorkommen, dass man den AccessPoint (192.168.222.1) zwar sehen konnte, aber ein connect oder der Zugriff nicht funktioniert hat.
Das sollte nun zuverlässig gehen.
Ab morgen mit dem FHEM-Update oder jetzt gleich hier: https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin
Zitat von: Wzut am 01 Mai 2016, 15:14:20
BTW: meine Arduino - ESP I2C Verbindung steht nun, @HCS würdest du bitte deine Beta für den Arduino Sketch posten ?
Wo?
wie befohlen , hier : https://forum.fhem.de/index.php/topic,52895.0.html
Super Arbeit an alle Mitwirkenden!!!
Habe mich durchgekämpft und erhielt bei jeder Firmware die ich auf den Nodemcu geflashed habe ständig nur die "Endless Loop". Abstürze über Abstürze. Keine wirkliche Funktion.
Kein Erfolg das LGW zum laufen zu bringen. Mit der Originalfirmware und auch diversen Sketchen lief das Modul. Sobald ich aber in den "Wifi_STA-Mode" ging, stürzte er ab.
DIE LÖSUNG:
Löschen des kompletten Flash mit dem esptool.
./esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 115200 -ca 0x00000 -cd nodemcu -ce
Anschließendes flashen der Jeelink_LaCrosseGateway.bin
Und siehe da, es geht sofort.
Gruß
Uli
Zitat von: hummeruli am 01 Mai 2016, 21:54:08
DIE LÖSUNG:
Löschen des kompletten Flash mit dem esptool.
./esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 115200 -ca 0x00000 -cd nodemcu -ce
Gut dass Du das schreibst. Das bestätigt eine Vermutung, die ich schon einige Zeit habe.
Das Espressif SDK merkt sich die wifi settings irgendwo im flash. Bei WIFI_STA liest es die aus dem flash.
Scheinbar kann man ESPs haben, bei denen im flash etwas steht, das das SDK mit einer Exception 3 sterben lässt, wenn man WiFiMode::WIFI_STA setzt.
Nach einem flash erase ist man das los und nach der Variante "NodeMCU flashen" wohl manchmal auch.
Es gibt die Möglichkeit, mit WiFi.persistent(false) zu verhindern, dass die wifi settings in flash abgelegt werden.
Ich bin nur nicht ganz sicher, ob es dann auch keine lädt. Muss ich mal austesten, was nicht einfach ist, wenn man keinen ESP hat, der einen passenden das Problem hervorrufenden flash-Inhalt hat.
Für die 1.18 heute habe ich mich nicht getraut, das einfach mal zu setzen.
Woran kann es eigentlich liegen, dass ich weder in fhem mit "set raw 868960#2f" noch im Gateway-Log mit "868960#2f" die Frequenz ändern kann?
In FHEM: set <name> raw 868960#2f
Auf der Log-Page wäre 868960#2f richtig.
Must aber noch ein v hinterherschicken, dass das LGW seine neuen Settings an FHEM zurückmeldet
Zitat von: HCS am 01 Mai 2016, 23:28:30
In FHEM: set <name> raw 868960#2f
Auf der Log-Page wäre 868960#2f richtig.
Must aber noch ein v hinterherschicken, dass das LGW seine neuen Settings an FHEM zurückmeldet
Genau das Blöde "v" war es. Habe ich das überlesen?
Danke
Zitat von: hummeruli am 02 Mai 2016, 00:01:35
Habe ich das überlesen?
Garantiert ;D
Ich wünsche mir ja immer noch einen Mitarbeiter, der diese ganzen Punkte und Tips im wiki zusammenfasst ... ;)
Ich hatte am Wochenende probiert, das GW auf meinem Dev-Board zum Laufen zu bringen.
Die Verwendung des GPIO16 für die Blinking-LED hat bei mir erst mal zu Problemen geführt, da mein Board für "Deep-Sleep WakeUp" ausgelegt ist, sprich GPIO16 ist mit RST verbunden. Lies sich allerdings durch einen einfachen Hardware-Patch korrigieren.
Allerdings gab/gibt es weitere Probleme:
- Memory-Leak beim Warten auf Setup (1.17, 1.18)
- System-Crash nachdem der AP konfiguriert wurde (1.17, pre1.18)
- Setup wird scheinbar nicht im Flash gespeichert (1.18 1.Mai)
zu 1)
Während das GW auf den Setup wartet, reduziert sich ständig der verfügbare Heap
Setup completely done
OK VALUES LGW 15974242 UpTimeSeconds=17,UpTimeText=0Tg. 0Std. 0Min. 17Sek. ,WIFI=---,MacAddress=18:FE:34:F3:BF:62,ChipID=15974242,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=18904,Version=1.18,LD.Min=0,LD.Avg=0,LD.Max=0
OK VALUES LGW 15974242 UpTimeSeconds=27,UpTimeText=0Tg. 0Std. 0Min. 27Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=18360,LD.Min=36,LD.Avg=36,LD.Max=36
OK VALUES LGW 15974242 UpTimeSeconds=37,UpTimeText=0Tg. 0Std. 0Min. 37Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=17928,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=47,UpTimeText=0Tg. 0Std. 0Min. 47Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=17168,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=57,UpTimeText=0Tg. 0Std. 0Min. 57Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16752,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=67,UpTimeText=0Tg. 0Std. 1Min. 7Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16176,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=77,UpTimeText=0Tg. 0Std. 1Min. 17Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15760,LD.Min=0,LD.Avg=0,LD.Max=148
OK VALUES LGW 15974242 UpTimeSeconds=87,UpTimeText=0Tg. 0Std. 1Min. 27Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15328,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=97,UpTimeText=0Tg. 0Std. 1Min. 37Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14912,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=107,UpTimeText=0Tg. 0Std. 1Min. 47Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14496,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=117,UpTimeText=0Tg. 0Std. 1Min. 57Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14064,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=127,UpTimeText=0Tg. 0Std. 2Min. 7Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=13840,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=137,UpTimeText=0Tg. 0Std. 2Min. 17Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=13632,LD.Min=0,LD.Avg=0,LD.Max=14
zu 2) GW wird über den Browser konfiguriert. Ich habe für's Erste lediglich meine SSID sowie das Passwort eingetragen. SSID hat 14 Zeichen, Passwort ist 16 Zeichen lang.
Nach "Save&Reboot" wurde zuerst die Konfig nicht übernommen - ein HW-Reboot war notwendig.
Daran anschliessend loopt das System beim Versuch, den AP zu konfigurieren.
Das Log stammt von der pre1.18 Version und enthält die komplette Sequenz Initial Start, Setup, Soft-Restart, HW-Reboot sowie die anschliessende Loop.
***CLEARLOG***
This is line 5 of void setup(void)
LaCrosseITPlusReader.Gateway V1.18 Free heap: 21648
SDK: 1.5.1(e67da894)
Reset: Software Watchdog
Fatal exception:4 flag:3 (SOFT_WDT) epc1:0x402234c2 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
Read settings
Starting I2C with 400000 kHz
Starting wifi
Start WIFI_STA
HostName is: LaCrosseGateway
Using DHCP
Trying to connect to an AP
..............................
We got no connection :-(
AcessPoint: Starting ...
AcessPoint: running, SSID=LaCrosseGateway_15974242
Starting frontend
Starting OTA
Starting data port 1 on 81
Searching RFMs and Sensors
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.18 {IP=192.168.222.1}]
Setup completely done
OK VALUES LGW 15974242 UpTimeSeconds=17,UpTimeText=0Tg. 0Std. 0Min. 17Sek. ,WIFI=---,MacAddress=18:FE:34:F3:BF:62,ChipID=15974242,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=17952,Version=1.18,LD.Min=0,LD.Avg=0,LD.Max=0
OK VALUES LGW 15974242 UpTimeSeconds=27,UpTimeText=0Tg. 0Std. 0Min. 27Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=17408,LD.Min=35,LD.Avg=35,LD.Max=35
OK VALUES LGW 15974242 UpTimeSeconds=37,UpTimeText=0Tg. 0Std. 0Min. 37Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16976,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=47,UpTimeText=0Tg. 0Std. 0Min. 47Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16560,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=57,UpTimeText=0Tg. 0Std. 0Min. 57Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16144,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=67,UpTimeText=0Tg. 0Std. 1Min. 7Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15728,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=77,UpTimeText=0Tg. 0Std. 1Min. 17Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15312,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=87,UpTimeText=0Tg. 0Std. 1Min. 27Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14896,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=97,UpTimeText=0Tg. 0Std. 1Min. 37Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14480,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=107,UpTimeText=0Tg. 0Std. 1Min. 47Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14064,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=117,UpTimeText=0Tg. 0Std. 1Min. 57Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=13632,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=128,UpTimeText=0Tg. 0Std. 2Min. 8Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=13408,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=138,UpTimeText=0Tg. 0Std. 2Min. 18Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=13200,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=148,UpTimeText=0Tg. 0Std. 2Min. 28Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12976,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=158,UpTimeText=0Tg. 0Std. 2Min. 38Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12752,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=168,UpTimeText=0Tg. 0Std. 2Min. 48Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12528,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=178,UpTimeText=0Tg. 0Std. 2Min. 58Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12304,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=188,UpTimeText=0Tg. 0Std. 3Min. 8Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12080,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=198,UpTimeText=0Tg. 0Std. 3Min. 18Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12080,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=208,UpTimeText=0Tg. 0Std. 3Min. 28Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12080,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=218,UpTimeText=0Tg. 0Std. 3Min. 38Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12080,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=228,UpTimeText=0Tg. 0Std. 3Min. 48Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12080,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=238,UpTimeText=0Tg. 0Std. 3Min. 58Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12080,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=248,UpTimeText=0Tg. 0Std. 4Min. 8Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=11376,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=258,UpTimeText=0Tg. 0Std. 4Min. 18Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=11760,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=268,UpTimeText=0Tg. 0Std. 4Min. 28Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=11208,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=278,UpTimeText=0Tg. 0Std. 4Min. 38Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=11392,LD.Min=0,LD.Avg=0,LD.Max=21
OK VALUES LGW 15974242 UpTimeSeconds=288,UpTimeText=0Tg. 0Std. 4Min. 48Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=11392,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=298,UpTimeText=0Tg. 0Std. 4Min. 58Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=11392,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=308,UpTimeText=0Tg. 0Std. 5Min. 8Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=11392,LD.Min=0,LD.Avg=0,LD.Max=14
b��d䄆�����������ć䦦FC�愄����Ĩ䄥Ĥ熤D��ƄbŧĄ�E���Ĥb�d
***CLEARLOG***
This is line 5 of void setup(void)
LaCrosseITPlusReader.Gateway V1.18 Free heap: 21648
SDK: 1.5.1(e67da894)
Reset: Software/System restart
Fatal exception:0 flag:4 (SOFT_RESTART) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
Read settings
Starting I2C with 400000 kHz
Starting wifi
Start WIFI_STA
HostName is: LaCrosseGateway
Using DHCP
Trying to connect to an AP
..............................
We got no connection :-(
AcessPoint: Starting ...
AcessPoint: running, SSID=LaCrosseGateway_15974242
Starting frontend
Starting OTA
Starting data port 1 on 81
Searching RFMs and Sensors
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.18 {IP=192.168.222.1}]
Setup completely done
OK VALUES LGW 15974242 UpTimeSeconds=18,UpTimeText=0Tg. 0Std. 0Min. 18Sek. ,WIFI=---,MacAddress=18:FE:34:F3:BF:62,ChipID=15974242,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=17920,Version=1.18,LD.Min=0,LD.Avg=0,LD.Max=0
OK VALUES LGW 15974242 UpTimeSeconds=28,UpTimeText=0Tg. 0Std. 0Min. 28Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=17376,LD.Min=35,LD.Avg=35,LD.Max=35
OK VALUES LGW 15974242 UpTimeSeconds=38,UpTimeText=0Tg. 0Std. 0Min. 38Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16944,LD.Min=0,LD.Avg=0,LD.Max=16
OK VALUES LGW 15974242 UpTimeSeconds=48,UpTimeText=0Tg. 0Std. 0Min. 48Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16528,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=58,UpTimeText=0Tg. 0Std. 0Min. 58Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16112,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=68,UpTimeText=0Tg. 0Std. 1Min. 8Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15376,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=78,UpTimeText=0Tg. 0Std. 1Min. 18Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14960,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=88,UpTimeText=0Tg. 0Std. 1Min. 28Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14544,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=98,UpTimeText=0Tg. 0Std. 1Min. 38Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=13224,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=108,UpTimeText=0Tg. 0Std. 1Min. 48Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12880,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=118,UpTimeText=0Tg. 0Std. 1Min. 58Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12928,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=128,UpTimeText=0Tg. 0Std. 2Min. 8Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12920,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=138,UpTimeText=0Tg. 0Std. 2Min. 18Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12848,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=148,UpTimeText=0Tg. 0Std. 2Min. 28Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12464,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=158,UpTimeText=0Tg. 0Std. 2Min. 38Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12032,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=168,UpTimeText=0Tg. 0Std. 2Min. 48Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=11808,LD.Min=0,LD.Avg=0,LD.Max=5014
OK VALUES LGW 15974242 UpTimeSeconds=178,UpTimeText=0Tg. 0Std. 2Min. 58Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=11400,LD.Min=0,LD.Avg=0,LD.Max=16
OK VALUES LGW 15974242 UpTimeSeconds=188,UpTimeText=0Tg. 0Std. 3Min. 8Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=11176,LD.Min=0,LD.Avg=0,LD.Max=22
OK VALUES LGW 15974242 UpTimeSeconds=198,UpTimeText=0Tg. 0Std. 3Min. 18Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=11176,LD.Min=0,LD.Avg=0,LD.Max=14
b��d䄆�����������ć䦦FC�愄������䄥Ĥ熤D��ƄbŧĄ�E���Ĥb�d
***CLEARLOG***
This is line 5 of void setup(void)
LaCrosseITPlusReader.Gateway V1.18 Free heap: 21368
SDK: 1.5.1(e67da894)
Reset: Software/System restart
Fatal exception:0 flag:4 (SOFT_RESTART) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
Read settings
Starting I2C with 400000 kHz
Starting wifi
Start WIFI_STA
HostName is: LaCrosseGateway
Using DHCP
Trying to connect to an AP
..............................
We got no connection :-(
AcessPoint: Starting ...
AcessPoint: running, SSID=LaCrosseGateway_15974242
Starting frontend
Starting OTA
Starting data port 1 on 81
Searching RFMs and Sensors
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.18 {IP=192.168.222.1}]
Setup completely done
OK VALUES LGW 15974242 UpTimeSeconds=17,UpTimeText=0Tg. 0Std. 0Min. 17Sek. ,WIFI=---,MacAddress=18:FE:34:F3:BF:62,ChipID=15974242,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=17920,Version=1.18,LD.Min=0,LD.Avg=0,LD.Max=0
OK VALUES LGW 15974242 UpTimeSeconds=27,UpTimeText=0Tg. 0Std. 0Min. 27Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=17376,LD.Min=35,LD.Avg=35,LD.Max=35
OK VALUES LGW 15974242 UpTimeSeconds=37,UpTimeText=0Tg. 0Std. 0Min. 37Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16944,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=47,UpTimeText=0Tg. 0Std. 0Min. 47Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16528,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=58,UpTimeText=0Tg. 0Std. 0Min. 58Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16112,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=68,UpTimeText=0Tg. 0Std. 1Min. 8Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15696,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=78,UpTimeText=0Tg. 0Std. 1Min. 18Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15280,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=88,UpTimeText=0Tg. 0Std. 1Min. 28Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14864,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=98,UpTimeText=0Tg. 0Std. 1Min. 38Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14448,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=108,UpTimeText=0Tg. 0Std. 1Min. 48Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14032,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=118,UpTimeText=0Tg. 0Std. 1Min. 58Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=13600,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=128,UpTimeText=0Tg. 0Std. 2Min. 8Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=13376,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=138,UpTimeText=0Tg. 0Std. 2Min. 18Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=13168,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=148,UpTimeText=0Tg. 0Std. 2Min. 28Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=12944,LD.Min=0,LD.Avg=0,LD.Max=15
G��P�@HVlFfy�&�wZCP@��y��i��9˕T �V9��HP@�gB`FTo��%J�T�ZTe!�TE�g� �HZ*Q���T�^�G�
***CLEARLOG***
This is line 5 of void setup(void)
LaCrosseITPlusReader.Gateway V1.18 Free heap: 21648
SDK: 1.5.1(e67da894)
Reset: External System
Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
Read settings
Starting I2C with 400000 kHz
Starting wifi
Start WIFI_STA
HostName is: LaCrosseGateway
Using DHCP
Exception (3):
epc1=0x401002f0 epc2=0x00000000 epc3=0x00000000 excvaddr=0x4000b79a depc=0x00000000
ctx: cont
sp: 3fff42d0 end: 3fff4cf0 offset: 01a0
>>>stack>>>
3fff4470: feefeffe feefeffe feefeffe feefeffe
3fff4480: feefeffe 80af1999 feefeffe 3fff45e7
3fff4490: 00000484 00000484 000001fd 401004f4
3fff44a0: 00000000 00001000 000001fd 401072a8
3fff44b0: 40004b31 3fff44e0 0000001c 40241585
3fff44c0: 401065e6 4024166d 3fff7a1c 000001ff
3fff44d0: 000001fd 3fff45e7 3fff7a1c 000001fd
3fff44e0: ffffff00 55aa55aa 00000012 0000001c
3fff44f0: 0000001c 000000ef 000000ed 000001ff
3fff4500: 40241a5c 3fff7a1c 3fff7a1c 000000ff
3fff4510: 00000001 3fff4607 40241bb7 00000008
3fff4520: 3fff7a1c 000000ff 3fff45e7 00000000
3fff4530: 3fff7adc 3fff4648 00000001 40241c44
3fff4540: 3fff45e7 3fff7a1c 00000000 00000004
3fff4550: 3fff4607 3fffdd54 3fff7a1c 00000000
3fff4560: 40241c80 3fff586c 3fff5824 0000001c
3fff4570: 4020aff2 3fff5824 3fff586c 4020af32
3fff4580: 3fff3c00 0000056b 0000056b 4010020c
3fff4590: 3fff37a0 00000000 3fff464c 4010068c
3fff45a0: 3ffeb600 00000000 3fff3790 4021e610
3fff45b0: 3fff37a0 00000000 3fff3790 40216f80
3fff45c0: 3fff3cbc 00000568 00000568 4010020c
3fff45d0: 3fff4950 3fff4950 3fff4c28 4010068c
3fff45e0: ffffff00 2dffffff 3f002d2d 4021e66c
3fff45f0: 3fff5854 00000006 3fff4640 4021e6bb
3fff4600: 3fff3cbc 2d000144 00002d2d 4010020c
3fff4610: 3fff4680 ffffffff 3fff4658 4010068c
3fff4620: 00000010 3fff4c64 3fff4c4c 4021e610
3fff4630: 3fff4680 3fff4c64 3fff4c4c 40219013
3fff4640: 00000000 00000000 00000000 00000000
3fff4650: 3fff3a98 00000000 00000001 00000000
3fff4660: 00000000 00000000 3fff4c80 3fff3790
3fff4670: 3fff3a98 3fff4c28 3fff4b80 40209ba8
3fff4680: 3fff7334 0000000f 00000000 3fff734c
3fff4690: 0000000f 00000000 3fff7364 0000000f
3fff46a0: 00000000 3fff737c 0000000f 00000000
3fff46b0: 3fff7434 0000000f 00000000 3fff744c
3fff46c0: 0000000f 00000000 3fff7464 0000000f
3fff46d0: 00000000 3fff747c 0000000f 00000000
3fff46e0: 3fff7494 0000000f 00000000 3fff74ac
3fff46f0: 0000000f 00000000 3fff74c4 0000000f
3fff4700: 00000000 3fff74dc 0000000f 00000000
3fff4710: 3fff74f4 0000000f 00000000 3fff750c
3fff4720: 0000000f 00000000 3fff7524 0000000f
3fff4730: 00000000 3fff753c 0000000f 00000000
3fff4740: 3fff7554 0000000f 00000000 3fff756c
3fff4750: 0000000f 00000000 3fff7584 0000000f
3fff4760: 00000000 3fff759c 0000000f 00000000
3fff4770: 3fff75b4 0000000f 00000000 3fff75cc
3fff4780: 0000000f 00000000 3fff75e4 0000000f
3fff4790: 00000000 3fff75fc 0000000f 00000000
3fff47a0: 3fff7614 0000000f 00000000 3fff762c
3fff47b0: 0000000f 00000000 3fff7644 0000000f
3fff47c0: 00000000 3fff765c 0000000f 00000000
3fff47d0: 3fff7674 0000000f 00000000 3fff768c
3fff47e0: 0000000f 00000000 3fff76a4 0000000f
3fff47f0: 00000000 3fff76bc 0000000f 00000000
3fff4800: 3fff76d4 0000000f 00000000 3fff76ec
3fff4810: 0000000f 00000000 3fff7704 0000000f
3fff4820: 00000000 3fff771c 0000000f 00000000
3fff4830: 3fff7734 0000000f 00000000 3fff774c
3fff4840: 0000000f 00000000 3fff7764 0000000f
3fff4850: 00000000 3fff777c 0000000f 00000000
3fff4860: 3fff7794 0000000f 00000000 3fff77ac
3fff4870: 0000000f 00000000 3fff77c4 0000000f
3fff4880: 00000000 3fff77dc 0000000f 00000000
3fff4890: 3fff77f4 0000000f 00000000 3fff780c
3fff48a0: 0000000f 00000000 3fff7824 0000000f
3fff48b0: 00000000 3fff783c 0000000f 00000000
3fff48c0: 3fff7854 0000000f 00000000 3fff786c
3fff48d0: 0000000f 00000000 3fff7884 0000000f
3fff48e0: 00000000 3fff789c 0000000f 00000000
3fff48f0: 3fff78b4 0000000f 00000000 3fff78cc
3fff4900: 0000000f 00000000 3fff78e4 0000000f
3fff4910: 00000000 3fff78fc 0000000f 00000000
3fff4920: 3fff7914 0000000f 00000000 3fff792c
3fff4930: 0000000f 00000000 3fff7944 0000000f
3fff4940: 00000000 3fff795c 0000000f 00000000
3fff4950: 00000000 3fff6b14 0000000f 00000000
3fff4960: 3fff6cdc 0000000f 00000000 3fff6c24
3fff4970: 0000000f 00000000 3fff6d44 0000000f
3fff4980: 00000000 3fff6d5c 0000000f 00000000
3fff4990: 3fff6d74 0000000f 00000000 3fff6d8c
3fff49a0: 0000000f 00000000 3fff6da4 0000000f
3fff49b0: 00000000 3fff6dbc 0000000f 00000000
3fff49c0: 3fff6dd4 0000000f 00000000 3fff6dec
3fff49d0: 0000000f 00000000 3fff6e04 0000000f
3fff49e0: 00000000 3fff6e1c 0000000f 00000000
3fff49f0: 3fff6e34 0000000f 00000000 3fff6e4c
3fff4a00: 0000000f 00000000 3fff6efc 0000000f
3fff4a10: 00000000 3fff6f14 0000000f 00000000
3fff4a20: 3fff6f2c 0000000f 00000000 3fff6f44
3fff4a30: 0000000f 00000000 3fff6f5c 0000000f
3fff4a40: 00000000 3fff6f74 0000000f 00000000
3fff4a50: 3fff6f8c 0000000f 00000000 3fff6fa4
3fff4a60: 0000000f 00000000 3fff6fbc 0000000f
3fff4a70: 00000000 3fff6fd4 0000000f 00000000
3fff4a80: 3fff6fec 0000000f 00000000 3fff7004
3fff4a90: 0000000f 00000000 3fff701c 0000000f
3fff4aa0: 00000000 3fff7034 0000000f 00000000
3fff4ab0: 3fff704c 0000000f 00000000 3fff7064
3fff4ac0: 0000000f 00000000 3fff707c 0000000f
3fff4ad0: 00000000 3fff7094 0000000f 00000000
3fff4ae0: 3fff70ac 0000000f 00000000 3fff70c4
3fff4af0: 0000000f 00000000 3fff70dc 0000000f
3fff4b00: 00000000 3fff70f4 0000000f 00000000
3fff4b10: 3fff710c 0000000f 00000000 3fff7124
3fff4b20: 0000000f 00000000 3fff713c 0000000f
3fff4b30: 00000000 3fff7154 0000000f 00000000
3fff4b40: 3fff716c 0000000f 00000000 3fff7184
3fff4b50: 0000000f 00000000 3fff719c 0000000f
3fff4b60: 00000000 3fff71b4 0000000f 00000000
3fff4b70: 3fff71cc 0000000f 00000000 3fff71e4
3fff4b80: 0000000f 00000000 3fff71fc 0000000f
3fff4b90: 00000000 3fff7214 0000000f 00000000
3fff4ba0: 3fff722c 0000000f 00000000 3fff7244
3fff4bb0: 0000000f 00000000 3fff725c 0000000f
3fff4bc0: 00000000 3fff7274 0000000f 00000000
3fff4bd0: 3fff728c 0000000f 00000000 3fff72a4
3fff4be0: 0000000f 00000000 3fff72bc 0000000f
3fff4bf0: 00000000 3fff72d4 0000000f 00000000
3fff4c00: 3fff72ec 0000000f 00000000 3fff7304
3fff4c10: 0000000f 00000000 3fff731c 0000000f
3fff4c20: 00000000 00000000 3fff5824 0000000f
3fff4c30: 00000003 3fff5754 0000000f 00000006
3fff4c40: 3fff79a4 0000000f 00000003 3fff586c
3fff4c50: 0000000f 00000003 3fff7974 0000000f
3fff4c60: 00000006 3fff583c 0000000f 00000003
3fff4c70: 3fff57a4 0000000f 00000000 3fff4ef4
3fff4c80: 0000000f 00000000 3fff798c 0000000f
3fff4c90: 00000000 3fff79bc 0000000f 0000000f
3fff4ca0: feefeffe feefeffe feefeffe feefeffe
3fff4cb0: feefeffe 3fff5824 feefeffe feefeffe
3fff4cc0: feefeffe feefeffe feefeffe 3fff3cc8
3fff4cd0: 3fffdad0 00000000 3fff3cc0 4021c1e0
3fff4ce0: feefeffe feefeffe 3fff3cd0 40100718
<<<stack<<<
b��d䄆�����������ć䦦FC�愄������䄥Ĥ熤D��ƄbŧĄ�E���Ĥb�d
zu 3) Die aktuelle 1.18 speichert nicht die vorgegebenen Konfigurationswerte. Leider hilft hier auch kein HW-Reset...
Hier das Log eines kompletten Zyklus (Setzen SSID, Passwort + Save&Reboot):
***CLEARLOG***
This is line 5 of void setup(void)
LaCrosseITPlusReader.Gateway V1.18
Free heap: 22824 Flash size: 4194304 SDK: 1.5.1(e67da894)
Reset: External System
Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
Read settings
Starting I2C with 400000 kHz
Starting wifi
Start WIFI_STA
HostName is: LaCrosseGateway
Using DHCP
Trying to connect to an AP
..............................
We got no connection :-(
AcessPoint: Starting ...
AcessPoint: running, SSID=LaCrosseGateway_15974242
Starting frontend
Starting OTA
Starting data port 1 on 81
Searching RFMs and Sensors
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.18 {IP=192.168.222.1}]
Setup completely done
OK VALUES LGW 15974242 UpTimeSeconds=17,UpTimeText=0Tg. 0Std. 0Min. 17Sek. ,WIFI=---,MacAddress=18:FE:34:F3:BF:62,ChipID=15974242,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=18904,Version=1.18,LD.Min=0,LD.Avg=0,LD.Max=0
OK VALUES LGW 15974242 UpTimeSeconds=27,UpTimeText=0Tg. 0Std. 0Min. 27Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=18360,LD.Min=36,LD.Avg=36,LD.Max=36
OK VALUES LGW 15974242 UpTimeSeconds=37,UpTimeText=0Tg. 0Std. 0Min. 37Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=17928,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=47,UpTimeText=0Tg. 0Std. 0Min. 47Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=17168,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=57,UpTimeText=0Tg. 0Std. 0Min. 57Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16752,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=67,UpTimeText=0Tg. 0Std. 1Min. 7Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=16176,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=77,UpTimeText=0Tg. 0Std. 1Min. 17Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15760,LD.Min=0,LD.Avg=0,LD.Max=148
OK VALUES LGW 15974242 UpTimeSeconds=87,UpTimeText=0Tg. 0Std. 1Min. 27Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=15328,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=97,UpTimeText=0Tg. 0Std. 1Min. 37Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14912,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=107,UpTimeText=0Tg. 0Std. 1Min. 47Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14496,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=117,UpTimeText=0Tg. 0Std. 1Min. 57Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=14064,LD.Min=0,LD.Avg=0,LD.Max=15
OK VALUES LGW 15974242 UpTimeSeconds=127,UpTimeText=0Tg. 0Std. 2Min. 7Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=13840,LD.Min=0,LD.Avg=0,LD.Max=14
OK VALUES LGW 15974242 UpTimeSeconds=137,UpTimeText=0Tg. 0Std. 2Min. 17Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=13632,LD.Min=0,LD.Avg=0,LD.Max=14
b��d䄆�����������ć䦦FC�愄������䄥Ĥ熤D��ƄbŧĄ�E���Ĥb�d
***CLEARLOG***
This is line 5 of void setup(void)
LaCrosseITPlusReader.Gateway V1.18
Free heap: 22544 Flash size: 4194304 SDK: 1.5.1(e67da894)
Reset: Software/System restart
Fatal exception:0 flag:4 (SOFT_RESTART) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
Read settings
Starting I2C with 400000 kHz
Starting wifi
Start WIFI_STA
HostName is: LaCrosseGateway
Using DHCP
Trying to connect to an AP
..............................
We got no connection :-(
AcessPoint: Starting ...
AcessPoint: running, SSID=LaCrosseGateway_15974242
Starting frontend
Starting OTA
Starting data port 1 on 81
Searching RFMs and Sensors
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.18 {IP=192.168.222.1}]
Setup completely done
OK VALUES LGW 15974242 UpTimeSeconds=17,UpTimeText=0Tg. 0Std. 0Min. 17Sek. ,WIFI=---,MacAddress=18:FE:34:F3:BF:62,ChipID=15974242,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=18872,Version=1.18,LD.Min=0,LD.Avg=0,LD.Max=0
OK VALUES LGW 15974242 UpTimeSeconds=27,UpTimeText=0Tg. 0Std. 0Min. 27Sek. ,WIFI=---,ReceivedFrames=0,FramesPerMinute=0,RSSI=31,FreeHeap=18328,LD.Min=36,LD.Avg=36,LD.Max=36
Nachtrag: Bei 2) bleibt das Problem, dass man das System ohne ein komplettes Flash-Erase nicht mehr auf die Reihe bekommt. Selbst das Flashen einer anderen Version (1.17 -> pre1.18) ändert nichts an der Exception.
Zitat von: SusisStrolch am 02 Mai 2016, 11:01:47
... da mein Board für "Deep-Sleep WakeUp" ausgelegt ist, sprich GPIO16 ist mit RST verbunden. Lies sich allerdings durch einen einfachen Hardware-Patch korrigieren.
Was für ein Board ist das?
Zitat von: SusisStrolch am 02 Mai 2016, 11:01:47
zu 1)
Memory-Leak beim Warten auf Setup (1.17, 1.18)
Während das GW auf den Setup wartet, reduziert sich ständig der verfügbare Heap
Das ist kein memory leak. Das LGW puffert die ersten 40 Zeilen Log, bis sie jemand abruft. Mit jeder Zeile wird etwas mehr Heap gebraucht, wenn 40 Zeilen im Puffer sind, dann bleibt er (nahezu) konstant.
Zu 2) und 3)
Seltsame Sache. Wie viel flash hat das Board, das Du verwendest?
Die Firmware ist für einen 4M ESP-12E ausgelegt.
Der ESP8266 hat kein explizites EEPROM, der Arduino Core für den 8266 verwendet einen Teil des flash als EEPROM.
Ich habe den Verdacht, dass da etwas kollidiert.
Drum oben schon die Frage, was für ein Board das ist.
DHCP habe ich schon lange nicht mehr getestet.
Konfiguriere mal IP, Netmask und Gateway, ob es dann einen connect zum AP bekommt.
ZitatWas für ein Board ist das?
Eigenentwicklung - Gateway für Buderus EMS-Bus (https://www.mikrocontroller.net/topic/356289#3985837)
(Da bei der Platinenbestellung etwas schief ging, habe ich noch ca. 40 davon rumliegen...)
ZitatDas ist kein memory leak.
Ah - ok - hatte mir den Code bisher nicht im Detail angeschaut.
Es handelt sich im Prinzip um einen nackten ESP8266-12E, mit 32MBit Flash bestückt.
Für die Flash-Größe habe ich 4MBit (== 512kB) gewählt. Sollte eigentlich problemlos gehen, da ja der Boot-Loader bereits in deinem Image drinne ist.
--- Edit ---
Welchen Modell-Typ hast Du denn in deiner Arduino-IDE eingestellt?
Zitat von: SusisStrolch am 02 Mai 2016, 14:38:21
Welchen Modell-Typ hast Du denn in deiner Arduino-IDE eingestellt?
NodeMCU 1.0 (ESP-12E Module)
bzw. für einen plainen ESP-12E:
80 MHz CPU
Flash Size: 4M (3M SPIFFS)
Sorry für die doofe Frage - wo finde ich den denn Source für die 1.1.8?
Hast Du die in einem öffentl. Repo?
Zitat von: SusisStrolch am 02 Mai 2016, 15:52:56
Sorry für die doofe Frage - wo finde ich den denn Source für die 1.1.8?
Hast Du die in einem öffentl. Repo?
Ich meine, dass müsste das hier https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip sein.
Gruß PeMue
Zitat von: PeMue am 02 Mai 2016, 17:01:39
Ich meine, dass müsste das hier https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip sein.
Genau.
Danke.
Werde nach meinem Urlaub mal reinschauen..
Zitat von: HCS am 02 Mai 2016, 09:27:40
Garantiert ;D
Ich wünsche mir ja immer noch einen Mitarbeiter, der diese ganzen Punkte und Tips im wiki zusammenfasst ... ;)
Ich will mal nichts versprechen. Werde es mal anschauen.
Ich habe das Problem mit den PCA 301 leider auch.
Zuerst konnte ich meine Drei überhaupt nicht von meinem Jeelink Klone mit RFM 12 auf den LGW abrufen. Dann ging plötzlich das Abrufen der Werte und Statusanzeige, jedoch ohne Steuerungsmöglichkeit aus FHEM heraus.
Kann es sein, dass die 1.18 Probleme bei den PCA 301 macht?
LG
Uli
Zitat von: hummeruli am 02 Mai 2016, 22:00:01
Kann es sein, dass die 1.18 Probleme bei den PCA 301 macht?
Also bei mir nicht. Kann es sein dass Du PCA301 nicht initialisiert hast sonder einfach nur die Frequenz gesetzt?
Zeig mal einen list von Deinem JeeLink Modul.
Zitat von: HCS am 02 Mai 2016, 22:05:00
Also bei mir nicht. Kann es sein dass Du PCA301 nicht initialisiert hast sonder einfach nur die Frequenz gesetzt?
Zeig mal einen list von Deinem JeeLink Modul.
Habe das 2. Modul mit folgenden Parametern gesetzt "2,868950,120i".
Seltsamer Weise kann ich die Steckdosen jetzt auch per SET-Befehl "EIN" und "AUS" schalten. Über die "on","off" und "toggle" jedoch nicht.
Ein Restart und Update von FHEM brachte keine Änderung. Auch ein Reload des Browsers (Safari unter OS X) brachte nichts.
Jedoch das Öffnen von FHEM in einem anderen Browser (Chrome) brachte den Erfolg.
So ein Mist
Gruß
Zitat von: HCS am 02 Mai 2016, 09:27:40
Garantiert ;D
Ich wünsche mir ja immer noch einen Mitarbeiter, der diese ganzen Punkte und Tips im wiki zusammenfasst ... ;)
Ich würde auch gerne etwas mittelfristig (und wie die Zeit es zulässt) dazu beitragen wollen.
Vorschlag: Einen neuen Thread - "Aufbau Wiki: "LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino""?
Alternative: Offline (PM)
Offfen Themen:
- WiKi Titel (Siehe Vorgaben...)
- Struktur
- Inhalte
- was sonst dazu gehört...
Viele Grüße
Arthur
Zitat von: hummeruli am 02 Mai 2016, 22:27:48
Auch ein Reload des Browsers (Safari unter OS X) brachte nichts.
Zitat von: hummeruli am 02 Mai 2016, 22:27:48
Jedoch das Öffnen von FHEM in einem anderen Browser (Chrome) brachte den Erfolg.
Hmmm. Muss mal heute Abend auf Safari gehen :)
Aber wenn das so ist, dann ist es ein fhemweb oder sonstwas-Thema und eher nicht im Scope vom LGW.
Zitat von: amunra am 02 Mai 2016, 22:48:38
Ich würde auch gerne etwas mittelfristig (und wie die Zeit es zulässt) dazu beitragen wollen.
Super.
Zitat von: amunra am 02 Mai 2016, 22:48:38
Offfen Themen:
- WiKi Titel (Siehe Vorgaben...)
- Struktur
- Inhalte
- was sonst dazu gehört...
Viele Grüße
Arthur
- WiKi Titel (Siehe Vorgaben...)
-> LaCrosseGateway
- Struktur
-> Kann man grob aus Beitrag #1 ableiten
https://forum.fhem.de/index.php/topic,43672.msg355938.html#msg355938
Im Prinzip die unterstrichenen Überschriften
- Inhalte
Erst mal das aus Beitrag #1 mit den Erweiterungen der einzelnen Releases (im Beitrag #1 ist immer auf den Post verlinkt, wo ich sie beschrieben habe)
Wenn das so weit mal drin ist, haben wir bereits eine sehr gute Basis.
- was sonst dazu gehört...
-> Findet sich dann. Wenn ich hier etwas poste, von dem ich meine, dass es ins wiki sollte, kann ich das ja vermerken.
Es gibt im wiki bereits etwas über den JeeLink sketch, das kann man auch mal anschauen und ggf. zusammenfassen oder von dort etwas übernehmen.
Musst aber nicht in Stress geraten, mach das wie Du Zeit und Lust dazu hast.
Wenn Du Fragen hast, schreib mich vorerst mal per PM an. Wenn Du einen Thread dafür aufmachen willst, auch OK, wie es Dir lieber ist.
Danke.
Fragen werde ich sicher haben - ich melde mich mit einem Vorschlag.
Viele Grüße
Arthur
Zitat von: HCS am 03 Mai 2016, 08:58:10
Aber wenn das so ist, dann ist es ein fhemweb oder sonstwas-Thema und eher nicht im Scope vom LGW.
Ja natürlich, so sehe ich es auch. Nur hatte ich bis jetzt nicht solch ein Verhalten, weshalb ich auch den Fehler im Bereich des LGW gesucht habe.
Gerade ausprobiert. Geht bei mir auch mit Safari 9.1 auf OS X 10.11.4 einwandfrei.
Zitat von: HCS am 03 Mai 2016, 20:51:22
Gerade ausprobiert. Geht bei mir auch mit Safari 9.1 auf OS X 10.11.4 einwandfrei.
Den Safari 9.1 habe ich auch, jedoch OS X 10.9.5
Wo ich auch noch ein kleines Problem habe, ist wenn ich das LGW restarge oder neu an das Netzteil stecke, dann verliert er die Frequenzeinstellungen und Parameter wie zum Beispiel: 3,868950,120i für meine PCA301er. Allerdings bin ich mir auch nicht sicher, ob es gespeichert wird oder jedes mal neu übergeben werden muss.
Das userattr consumptionTotal scheint nicht mehr zu funktionieren wird nicht mit mehr aktualisiert
consumptionTotal:consumption monotonic {ReadingsVal($name,'consumption',0)}
könnte vieleicht so wieder funktionieren
consumptionTotal:consumption.* monotonic {ReadingsVal($name,'consumption',0)}
jedenfalls mußte ich meine gesamtem userReadings so umstellen
Zitat von: andre07 am 05 Mai 2016, 15:45:07
Das userattr consumptionTotal scheint nicht mehr zu funktionieren wird nicht mit mehr aktualisiert
justme1968 hat das im PCA301 Modul bereits angepasst. Nach dem 18.04.16 definierte PAC301 Instanzen sollten OK sein, nur die vorher schon vorhandenen müssen angepasst werden.
Hi,
dank der 1.18 funktioniert bei mir nun auch das LGW.
Den RFM69CW habe ich ebenfalls angeschlossen, bekomme aber bisher keine Daten.
Beim Start bekomme ich:
07:45:30: Starting frontend
07:45:30: Starting OTA
07:45:30: Starting data port 1 on 81
07:45:30: Searching RFMs and Sensors
07:45:30: Sending init String to FHEM
07:45:30: Setup completely done
Heißt das der RFM wurde nicht gefunden?
Danke & Gruß,
Tobi
Zitat von: onkel-tobi am 10 Mai 2016, 07:50:44
Heißt das der RFM wurde nicht gefunden?
Ja, so ist das wohl. Korrekt angeschlossen?
Sollte so aussehen(halt je nach dem, was an Hardware dran ist):
...
09:47:11: Searching RFMs and Sensors
09:47:11: Radio #1 found: RFM69
09:47:11: Radio #2 found: RFM69
09:47:11: BME280 found
09:47:12: Sending init String to FHEM
09:47:12: Setup completely done
OTA-Update - Frage
Es gibt aktuell zwei Varianten für das OTA-Update:
1. Die historische, bei der man sich in FHEM einen HTTPSRV definieren muss und dann vom Frontend des LGW aus das Update anstößt (siehe OTA.png)
(https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=52015;image)
2. Die seit längerem vorhandene Variante, bei der man von FHEM aus einfach einen "set myJeeLing flash" macht (kein HTTPSRV oder sonstwas erforderlich).
Alternativ kann man die Firmware auch einfach so auf das LGW hochladen:
curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@.\JeeLink_LaCrosseGateway.bin; filename=firmware.bin" http://192.168.31.211/ota/firmware.bin
Variante 1 würde ich gerne aus dem LGW ausbauen, da sie veraltet und unnötig ist.
Hat jemand damit ein Problem?
Falls ja, dann bitte hier melden und es beschreiben.
Hallo,
erstmal vielen Dank für die echt tolle Arbeit und die Zeit die Ihr hier reingesteckt habt.
Leider hab ich ein kleines Problem.
Der Aufbau ist recht simpel, NodeMCU und ein RFM69CW.
Sinn von dem ganzen soll sein den Empfanger für meine EC3000 "frei" Positionieren zu können.
Der Empfang ist echt super, alle Dosen da, nur stimmen die Werte leider nicht.
Aktueller Verbraucht passt, aber Gesamtverbrauch ist etwa um den Faktor 10-15 zu noch.
Und das nicht nur bei einer Dose, sondern bei allen.
Wenn ich die RAWMSG vergleiche (Normaler Jeelink und ESP) sehe ich auch einen deutlichen Unterschied, nur leider konnte ich noch nicht herausfinden wo dieser herkommt.
Hier mal ein Beispiel:
JeeLink_EC_TIME 2016-05-11 23:26:50
JeeLink_ESP01_RAWMSG OK 22 48 229 2 11 217 116 2 11 217 70 1 17 89 100 0 16 73 145 2 0
JeeLink_EC_RAWMSG OK 22 48 229 2 11 216 187 2 11 216 141 0 17 89 101 0 17 73 145 2 1
Die Nachrichten wurden Zeitgleich empfangen.
Ich hoffe mir ist noch zu Helfen 8)
Danke schon mal und Grüße
Christian
Zitat von: christianv77 am 12 Mai 2016, 19:24:21
Ich hoffe mir ist noch zu Helfen 8)
Mal sehen ;D
Ich habe gerade mal einen EC3000 Sketch gegen das LGW verglichen. Ich bekomme von der EC3000 auf beiden identische Werte.
Geh mal auf die Log-Page des LGW, trage bei "Command" 64z ein und schicke es ab.
Danach sollten im unteren Log solche Zeilen kommen.
22:43:35: EC3000 [7c a8 5 5 0 0 5 5 0 0 0 1 a6 56 5e 0 50 0 7d 44 d6 c4 ac 7c 4a c6 c4 ac 97 3 40 0 0 0 0 3 40 18 f 77 a7 ] CRC:OK ID:7ca8 TS:3409157 OS:3409157 W:8.00 max-W:12.50 Cons:7.69 Res.:1 Rec.:0 IsOn:1 CRC:f0b8ca. 20 Zeilen abwarten und dann mit 0z wieder abschalten.
Das Log (Copy -> Paste) hängst Du bitte mal hier ran, dass ich schauen kann, was da kommt und draus decodiert wird.
"Cons:" ist die Consumption. Mich interessieren die Zeilen, bei denen sie falsch ist.
Welche Version hat die LGW-Firmware?
Zitat von: HCS am 12 Mai 2016, 09:31:31
OTA-Update - Frage
Ich habe im Moment zwar kein use case, aber "ohne FHEM", und wer weiß was für Funktionen noch kommen? ;), ist ein Update nicht mehr "komfortabel" möglich.
Mehr fällt mir aktuell nicht ein.
Ich würde es auf "deprecated" setzten und abwarten was noch kommt. Am Ende musst Du entscheiden ;)
Welche Beweggründe hast Du die Funktion zu deaktivieren?
Viele Grüße
ArthurIch ziehe meine Anmerkung zurück, da die Variante 1 ohne FHEM /Web-Server auch nicht nutzbar ist. Es ist mir erst nach erneutem lesen klar geworden - Sorry.
Hi HCS,
danke für die schnelle Antwort, echt fix :)
Hier sind auch schon die Logs:
23:17:12: EC3000 [7b 7c 7 be 0 0 4f 82 0 0 0 6 f e5 95 0 0 48 d5 0 0 0 0 1 0 0 6 58 c8 26 80 0 0 0 1 1 20 20 4 9a 47 ] CRC:OK ID:7b7c TS:40372158 OS:1200002 W:0.00 max-W:1864.50 Cons:1221.30 Res.:2 Rec.:0 IsOn:0 CRC:f0b8
23:17:12: EC3000 [30 e5 27 fc 0 0 27 ce 0 0 0 3 fb 8b b 0 11 49 91 f 5e b4 c3 f2 25 4e 62 a0 1a 20 d0 0 0 0 f 20 d0 28 2 c4 47 ] CRC:OK ID:30e5 TS:34416636 OS:34416590 W:1.70 max-W:1883.30 Cons:17914.26 Res.:2 Rec.:0 IsOn:1 CRC:f0b8
23:17:13: EC3000 [47 49 af 4 0 0 f 7f 0 0 0 0 f9 85 c4 0 0 6 99 0 0 0 0 0 0 0 0 0 0 f d0 0 0 0 11 5 b0 30 7 cc 97 ] CRC:OK ID:4749 TS:16625412 OS:5967743 W:0.00 max-W:168.90 Cons:20286.33 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
23:17:14: EC3000 [75 40 5 ae 0 0 e9 75 0 0 0 8 5c 14 a3 0 3 4b de 1 aa c4 52 ef 45 43 54 45 c 26 80 0 0 0 0 26 70 38 c a2 7 ] CRC:OK ID:7540 TS:40371630 OS:40364405 W:0.30 max-W:1942.20 Cons:38.96 Res.:3 Rec.:0 IsOn:1 CRC:f0b8
23:17:14: EC3000 [7b 3b 2b e9 0 0 2b e9 0 0 0 9 e4 14 de 2 c2 5 82 69 3a 8 55 a5 85 6a a8 58 45 21 d0 0 0 0 8 21 d0 c8 0 5b e7 ] CRC:OK ID:7b3b TS:35466217 OS:35466217 W:70.60 max-W:141.00 Cons:9590.47 Res.:12 Rec.:0 IsOn:1 CRC:f0b8
23:17:14: EC3000 [49 90 38 31 0 0 e0 6a 0 0 0 2 5 5e bb 0 0 7d 9c 3e 62 c4 58 1c 56 8b 34 98 56 20 d0 0 0 0 1 0 70 30 e c8 47 ] CRC:OK ID:4990 TS:34420785 OS:516202 W:0.00 max-W:3215.60 Cons:1202.46 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
23:17:15: EC3000 [7b c6 59 47 0 0 59 47 0 0 0 0 dd 4c dc 5 ca 1b 25 76 f6 e8 61 94 86 38 58 60 89 26 80 0 0 0 a 26 80 18 1 43 a7 ] CRC:OK ID:7bc6 TS:40393031 OS:40393031 W:148.20 max-W:694.90 Cons:11934.49 Res.:1 Rec.:0 IsOn:1 CRC:f0b8
23:17:16: EC3000 [d8 4 37 ba 0 0 37 ba 0 0 0 0 aa 96 f6 0 a 20 a6 47 60 e6 4a 78 65 26 f6 81 bd 20 d0 0 0 0 6 20 d0 28 2 40 77 ] CRC:OK ID:d804 TS:34420666 OS:34420666 W:1.00 max-W:835.80 Cons:7161.38 Res.:2 Rec.:0 IsOn:1 CRC:f0b8
23:17:16: EC3000 [7b 7c 7 c3 0 0 4f 82 0 0 0 6 f e5 95 0 0 48 d5 0 0 0 0 1 0 0 6 58 c8 26 80 0 0 0 1 1 20 20 9 2d 7 ] CRC:OK ID:7b7c TS:40372163 OS:1200002 W:0.00 max-W:1864.50 Cons:1221.30 Res.:2 Rec.:0 IsOn:0 CRC:f0b8
23:17:17: EC3000 [30 e5 28 1 0 0 27 d3 0 0 0 3 fb 8b 13 0 11 49 91 f 5f 34 c3 f2 25 4e 62 a0 1a 20 d0 0 0 0 f 20 d0 28 0 3d e7 ] CRC:OK ID:30e5 TS:34416641 OS:34416595 W:1.70 max-W:1883.30 Cons:17914.26 Res.:2 Rec.:0 IsOn:1 CRC:f0b8
23:17:18: EC3000 [47 49 af 9 0 0 f 7f 0 0 0 0 f9 85 c4 0 0 6 99 0 0 0 0 0 0 0 0 0 0 f d0 0 0 0 11 5 b0 30 7 9e 7 ] CRC:OK ID:4749 TS:16625417 OS:5967743 W:0.00 max-W:168.90 Cons:20286.33 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
23:17:18: EC3000 [75 40 5 b3 0 0 e9 7a 0 0 0 8 5c 14 a5 0 3 4b de 1 aa e4 52 ef 45 43 54 45 c 26 80 0 0 0 0 26 70 38 c 70 27 ] CRC:OK ID:7540 TS:40371635 OS:40364410 W:0.30 max-W:1942.20 Cons:38.96 Res.:3 Rec.:0 IsOn:1 CRC:f0b8
23:17:20: EC3000 [49 90 38 36 0 0 e0 6a 0 0 0 2 5 5e bb 0 0 7d 9c 3e 62 c4 58 1c 56 8b 34 98 56 20 d0 0 0 0 1 0 70 30 3 ea e7 ] CRC:OK ID:4990 TS:34420790 OS:516202 W:0.00 max-W:3215.60 Cons:1202.46 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
23:17:21: EC3000 [7b c6 59 4c 0 0 59 4c 0 0 0 0 dd 4f c1 5 cd 1b 25 76 f9 d8 61 94 86 38 58 60 89 26 80 0 0 0 a 26 80 18 6 ec c7 ] CRC:OK ID:7bc6 TS:40393036 OS:40393036 W:148.50 max-W:694.90 Cons:11934.49 Res.:1 Rec.:0 IsOn:1 CRC:f0b8
23:17:21: EC3000 [d8 4 37 bf 0 0 37 bf 0 0 0 0 aa 96 fb 0 a 20 a6 47 60 e6 4a 78 65 26 f6 81 bd 20 d0 0 0 0 6 20 d0 28 f 44 37 ] CRC:OK ID:d804 TS:34420671 OS:34420671 W:1.00 max-W:835.80 Cons:7161.38 Res.:2 Rec.:0 IsOn:1 CRC:f0b8
23:17:23: EC3000 [47 49 af e 0 0 f 7f 0 0 0 0 f9 85 c4 0 0 6 99 0 0 0 0 0 0 0 0 0 0 f d0 0 0 0 11 5 b0 30 a bc a7 ] CRC:OK ID:4749 TS:16625422 OS:5967743 W:0.00 max-W:168.90 Cons:20286.33 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
23:17:24: EC3000 [75 40 5 b8 0 0 e9 7f 0 0 0 8 5c 14 a6 0 3 4b de 1 aa f4 52 ef 45 43 54 45 c 26 80 0 0 0 0 26 70 38 f 57 b7 ] CRC:OK ID:7540 TS:40371640 OS:40364415 W:0.30 max-W:1942.20 Cons:38.96 Res.:3 Rec.:0 IsOn:1 CRC:f0b8
23:17:25: EC3000 [49 90 38 3b 0 0 e0 6a 0 0 0 2 5 5e bb 0 0 7d 9c 3e 62 c4 58 1c 56 8b 34 98 56 20 d0 0 0 0 1 0 70 30 3 b8 77 ] CRC:OK ID:4990 TS:34420795 OS:516202 W:0.00 max-W:3215.60 Cons:1202.46 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
23:17:26: EC3000 [7b c6 59 51 0 0 59 51 0 0 0 0 dd 52 a9 5 cf 1b 25 76 fc b8 61 94 86 38 58 60 89 26 80 0 0 0 a 26 80 18 f b8 b7 ] CRC:OK ID:7bc6 TS:40393041 OS:40393041 W:148.70 max-W:694.90 Cons:11934.49 Res.:1 Rec.:0 IsOn:1 CRC:f0b8
23:17:26: EC3000 [d8 4 37 c4 0 0 37 c4 0 0 0 0 aa 97 0 0 a 20 a6 47 60 f6 4a 78 65 26 f6 81 bd 20 d0 0 0 0 6 20 d0 28 9 ba f7 ] CRC:OK ID:d804 TS:34420676 OS:34420676 W:1.00 max-W:835.80 Cons:7161.38 Res.:2 Rec.:0 IsOn:1 CRC:f0b8
23:17:27: EC3000 [7b 7c 7 cd 0 0 4f 82 0 0 0 6 f e5 95 0 0 48 d5 0 0 0 0 1 0 0 6 58 c8 26 80 0 0 0 1 1 20 20 3 68 57 ] CRC:OK ID:7b7c TS:40372173 OS:1200002 W:0.00 max-W:1864.50 Cons:1221.30 Res.:2 Rec.:0 IsOn:0 CRC:f0b8
23:17:27: EC3000 [30 e5 28 b 0 0 27 dd 0 0 0 3 fb 8b 24 0 11 49 91 f 60 44 c3 f2 25 4e 62 a0 1a 20 d0 0 0 0 f 20 d0 28 8 53 a7 ] CRC:OK ID:30e5 TS:34416651 OS:34416605 W:1.70 max-W:1883.30 Cons:17914.26 Res.:2 Rec.:0 IsOn:1 CRC:f0b8
23:17:28: EC3000 [47 49 af 13 0 0 f 7f 0 0 0 0 f9 85 c4 0 0 6 99 0 0 0 0 0 0 0 0 0 0 f d0 0 0 0 11 5 b0 30 e 14 f7 ] CRC:OK ID:4749 TS:16625427 OS:5967743 W:0.00 max-W:168.90 Cons:20286.33 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
23:17:29: EC3000 [75 40 5 bd 0 0 e9 84 0 0 0 8 5c 14 a8 0 3 4b de 1 ab 14 52 ef 45 43 54 45 c 26 80 0 0 0 0 26 70 38 f e4 a7 ] CRC:OK ID:7540 TS:40371645 OS:40364420 W:0.30 max-W:1942.20 Cons:38.96 Res.:3 Rec.:0 IsOn:1 CRC:f0b8
23:17:29: EC3000 [7b 3b 2b f8 0 0 2b f8 0 0 0 9 e4 18 eb 2 7f 5 82 69 3e 18 55 a5 85 6a a8 58 45 21 d0 0 0 0 8 21 d0 c8 1 5 b7 ] CRC:OK ID:7b3b TS:35466232 OS:35466232 W:63.90 max-W:141.00 Cons:9590.47 Res.:12 Rec.:0 IsOn:1 CRC:f0b8
23:17:30: EC3000 [49 90 38 40 0 0 e0 6a 0 0 0 2 5 5e bb 0 0 7d 9c 3e 62 c4 58 1c 56 8b 34 98 56 20 d0 0 0 0 1 0 70 30 a 20 a7 ] CRC:OK ID:4990 TS:34420800 OS:516202 W:0.00 max-W:3215.60 Cons:1202.46 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
Und hier mal das Log vom ESP Start:
23:22:30: This is line 5 of void setup(void)
23:22:30: LaCrosseITPlusReader.Gateway V1.18
23:22:30: Free heap: 23184 Flash size: 4194304 SDK: 1.5.1(e67da894)
23:22:30: Reset: External System
23:22:30: Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
23:22:30: Read settings
23:22:30: Starting I2C with 400000 kHz
23:22:30: Starting wifi
23:22:30: Start WIFI_STA
23:22:30: HostName is: LaCrosseGateway
23:22:30: Using DHCP
23:22:30: Trying to connect to an AP
23:22:30: .......
23:22:30: connected :-)
23:22:30: SSID: XXXXXXXXX
23:22:30: IP: XXX.XXX.XXX.XXX
23:22:30: Starting frontend
23:22:30: Starting OTA
23:22:30: Starting data port 1 on 81
23:22:30: Searching RFMs and Sensors
23:22:30: Radio #1 found: RFM69
23:22:30: Sending init String to FHEM
23:22:30: Setup completely done
Falsch sind irgend wie ALLE Cons Werte, immer um den Faktor 10-15 zu Hoch.
Hier mal von 4 Devices die "richtigen"
7BC6 OK 22 123 198 2 104 91 104 2 104 91 104 0 11 112 136 5 111 27 37 1 10 consumption 749.706 power 137.7 powerMax 694.9
7540 OK 22 117 64 2 104 8 61 2 103 236 4 0 0 152 47 0 3 75 222 3 3 consumption 38.959 power 0.3 powerMax 1942.2
4990 OK 22 73 144 2 13 59 6 0 7 224 106 0 1 72 15 0 0 125 156 3 1 consumption 83.983 power 0 powerMax 3215.6
7B7C OK 22 123 124 2 104 10 162 0 18 79 130 0 1 145 160 0 0 72 213 2 0 consumption 102.816 power 0 powerMax 1864.5
OK, dann mal gute Nacht für alle.
Muss leider Morgen wieder Früh raus.
Noch einen schönen Abend..... ;D
Zitat von: christianv77 am 12 Mai 2016, 19:24:21
Aktueller Verbraucht passt, aber Gesamtverbrauch ist etwa um den Faktor 10-15 zu noch.
Ja, mit Deinen Daten kann ich es nachvollziehen.
Das ist ein Fehler in der EC3000 decoder Routine im LGW, der nur dann auftritt, wenn im gesendeten Frame bestimmte bits gesetzt sind, die meine ECs interessanterweise nicht senden. Die müssten eigentlich maskiert werden, was der JeeLink-Sketch auch macht. Bei der Umsetzung im LGW ist mir das wohl durchgerutscht ::) Sorry :-[
Ich versuche mal am WE eine Test-Version zu erstellen, mit der Du probieren kannst, ob es bei Dir dann OK ist.
Zitat von: amunra am 12 Mai 2016, 23:15:05
Welche Beweggründe hast Du die Funktion zu deaktivieren?
Zitat von: amunra am 12 Mai 2016, 23:15:05
Ich ziehe meine Anmerkung zurück, da die Variante 1 ohne FHEM /Web-Server auch nicht nutzbar ist.
Ich erläutere sie trotzdem kurz:
- genau aus diesem Grund ;D
- die Funktionalität ist redundant und diese Variante ist die "schlechtere"
- Sie verbraucht Raum und Zeit
- Sie muss gewartet und bei jeder Release getestet werden
- Wenn sie jemand verwendet, muss evtl. Support dafür geleistet werden.
- Die Setup-Page wird entlastet, ansonsten muss (in Deinem wiki ;) ) beschrieben werden, warum man das (nicht) definieren muss
Der Gedanke war also schlicht: "muss man was drin haben, das man eigentlich nicht braucht und sich auch noch mit allem, was sich daraus als Folge ergibt, beschäftigen?"
Aber meine Frage hat immer noch Bestand. Wenn es handfeste Gründe gibt, warum jemand sie wirklich benötigt, dann kann sie auch drin bleiben.
Cool,
ich hab schon an mir gezweifelt .... ::)
So konnte ich wenigstens auch einen kleinen Beitrag zu deinem Projekt leisten 8)
Für weitere Tests stehe ich gerne zur Verfügung.
Und schon mal mein Herzlichsten Dank.
Ein schönes Wochenende @all
@HCS
Danke für die Auf-/Erklärung und Zustimmung Meinerseits in allen Punkten :)
Ich hatte fälschlicherweise in Erinnerung, dass man auf der LGW OTA WEB-Seite die Firmware auswählen und direkt hochladen konnte, was offensichtlich nicht der Fall ist ;)
So, Grundreflexe bei meinem ersten LGW mit devkit sind vorhanden:
LaCrosseITPlusReader.Gateway V1.18
Free heap: 23184 Flash size: 4194304 SDK: 1.5.1(e67da894)
Reset: Software/System restart
Fatal exception:0 flag:4 (SOFT_RESTART) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
Read settings
Starting I2C with 400000 kHz
Starting wifi
Start WIFI_STA
HostName is: LaCrosseGateway
Using DHCP
Trying to connect to an AP
...............
connected :-)
SSID: xxx
IP: 192.168.188.33
Starting frontend
Starting OTA
Starting data port 1 on 81
Searching RFMs and Sensors
Radio #1 found: RFM69
BMP180 found
LM75 found
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.18 (1=RFM69 f:868300 r:17241) + BMP180 + LM75 {IP=192.168.188.33}]
Setup completely done
OK WS 0 4 4 223 255 255 255 255 255 255 255 255 255 0 3 216
OK VALUES LGW 14067787 UpTimeSeconds=10,UpTimeText=0Tg. 0Std. 0Min. 10Sek. OK WS 0 4 4 223 255 255 255
255 255 255 255 255 255 0 3 216
Mal sehen, was fhem dazu sagt und was alles erkannt wird. Super Sache ;D
@HCS:
Vielleicht könntest Du noch im ersten Post bei der (erst-)Konfiguration eine Bemerkung reinschreiben, dass man SSID/WLAN Passwort bzw. die Adresse des DHCP Gateways braucht. Die Umschalterei zwischen den WLAN Netzen war etwas nervig 8)
Zitat von: PeMue am 14 Mai 2016, 20:15:11
So, Grundreflexe bei meinem ersten LGW mit devkit sind vorhanden:
Na denn, sieht ja schon mal gut aus.
Zitat von: PeMue am 14 Mai 2016, 20:15:11
...
Starting I2C with 400000 kHz
...
Gut, dass ich das init log mal wieder durchlesen durfte.
Interessant, was für einen Unsinn ich rauslogge.
400000 kHz I2C clock wäre ja echt cool wenn das gehen würde :o ;D ;D
Werde ich dann mal korrigieren.
Nochmal zwei (dumme?) Fragen:
- Wo finde ich eine Übersicht, was ich alles mit set <name> raw verdrehen kann?
- Wo sollten die Werte für den BMP180 bzw. den LM75 in fhem auftauchen? Beim KeyValueProtocol findet sich nichts ???
Danke + Gruß
PeMue
Zitat von: PeMue am 14 Mai 2016, 21:03:20
- Wo finde ich eine Übersicht, was ich alles mit set <name> raw verdrehen kann?
Im web-frontend des LGW auf der Help-Page
Zitat von: PeMue am 14 Mai 2016, 21:03:20
- Wo sollten die Werte für den BMP180 bzw. den LM75 in fhem auftauchen? Beim KeyValueProtocol findet sich nichts ???
In einem LaCrosse device mit der ID 0
Entweder manuell anlegen mit
define LGW_Sensors LaCrosse 00oder nach einem
set myJeeLink LaCrossePairForSec 120 ignore_batterysollte es von autocreate angelegt werden.
Ein KVP device mit den Statuswerten des LGW solltest Du bereits vom autocreate bekommen haben.
Zitat von: HCS am 14 Mai 2016, 21:10:03
Im web-frontend des LGW auf der Help-Page
Danke, stimmt, sogar mit Schreibfehler:
Example: set myJeeLin
k raw 2,120b ;D
Zitat von: HCS am 14 Mai 2016, 21:10:03
In einem LaCrosse device mit der ID 0
Entweder manuell anlegen mit
define LGW_Sensors LaCrosse 00
oder nach einem
set myJeeLink LaCrossePairForSec 120 ignore_battery
sollte es von autocreate angelegt werden.
Ein KVP device mit den Statuswerten des LGW solltest Du bereits vom autocreate bekommen haben.
Jawohl, habe ich mittlerweile. Die Frequenz nach den initCommands habe ich auch auf die PCA301 Frequenz gedreht bekommen (nach einem set myJeeLink reset.
[LaCrosseITPlusReader.Gateway.1.18 (1=RFM69 f:868960 r:6631) + BMP180 + LM75 {IP=192.168.188.33}]Allerdings mag er meine PCA301 immer noch nicht. Die hatte mit dem JeeLink und den Sketch eine Mittenfrequenz von A708, was immer auch das in MHz ist.
Edit1: Ok, mit manuellem Anlegen der PCA301 lässt das Teil sich schalten. Prima. Jetzt muss ich mal die Dinge, die das LGW angelegt hat in fhem sortieren und alles rauswerfen, was zu gesprächig ist ;)
Edit2: Kann das Ding auch HX2272 bzw. FS20?
(https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=52104;image)
Das wäre dann ja echt cool. Aber in diesem Fall brauchts für mich asap den Wiki Artikel 8)
Edit3: Dank steckbaren Modulen wird auch der BME280 erkannt, sehr schön!
Edit4: Ist das normal, dass die Werte mehrmals ins Log geschrieben werden?
2016-05-14_22:33:26 LaCrosse_00 error: 0
2016-05-14_22:33:26 LaCrosse_00 battery: ok
2016-05-14_22:33:26 LaCrosse_00 temperature: 26.4
2016-05-14_22:33:26 LaCrosse_00 humidity: 33
2016-05-14_22:33:26 LaCrosse_00 pressure: 1015
2016-05-14_22:33:36 LaCrosse_00 error: 0
2016-05-14_22:33:36 LaCrosse_00 battery: ok
2016-05-14_22:33:36 LaCrosse_00 temperature: 26.4
2016-05-14_22:33:36 LaCrosse_00 humidity: 34
2016-05-14_22:33:36 LaCrosse_00 T: 26.4 H: 34
2016-05-14_22:33:36 LaCrosse_00 pressure: 1015
2016-05-14_22:33:46 LaCrosse_00 error: 0
2016-05-14_22:33:46 LaCrosse_00 battery: ok
2016-05-14_22:33:46 LaCrosse_00 temperature: 26.4
2016-05-14_22:33:46 LaCrosse_00 humidity: 33
2016-05-14_22:33:46 LaCrosse_00 T: 26.4 H: 33
2016-05-14_22:33:46 LaCrosse_00 pressure: 1015
2016-05-14_22:33:56 LaCrosse_00 error: 0
2016-05-14_22:33:56 LaCrosse_00 battery: ok
2016-05-14_22:33:56 LaCrosse_00 temperature: 26.4
2016-05-14_22:33:56 LaCrosse_00 humidity: 33
2016-05-14_22:33:56 LaCrosse_00 pressure: 1015Auch mit event-min-interval scheint das Ganze nicht zu bändigen zu sein. Aber ich lasse das Ding mal durchlaufen ...
Zitat von: PeMue am 14 Mai 2016, 21:40:29
Danke, stimmt, sogar mit Schreibfehler:
Example: set myJeeLink raw 2,120b ;D
Korrigiert.
Zitat von: PeMue am 14 Mai 2016, 21:40:29
Allerdings mag er meine PCA301 immer noch nicht. Die hatte mit dem JeeLink und den Sketch eine Mittenfrequenz von A708, was immer auch das in MHz ist.
869.000 aber ich glaube nicht, dass das mit einem RFM69 auch so passt.
Ich bekommen meine alle mit 968960
Häng mal ein list von Deinem JeeLink device hier an.
Zitat von: PeMue am 14 Mai 2016, 21:40:29
Edit2: Kann das Ding auch HX2272 bzw. FS20?
Nein. Das ist noch ein Problem vom JeeLink Modul. Das ist für jede Menge sketches verwendbar und unterscheidet nicht, was aktuell dran ist und bietet immer alle möglichen Einstellungen an, egal ob das zu dem aktuellen Sketch passt.
Da wollte justme1968 mal dran, dass nur die gets und sets angeboten werden, die zu dem, was in Model steht auch passen.
Das ganz blöde dran ist, dass man sich damit auch noch sein Konfiguration im LGW, JeeLink-Sketch, ... zerschießen kann, weil es etwas schickt, das etwas ganz anderes berwirkt als der set bedeutet.
Das LGW versteht set:
LaCrossePairForSec, flash, raw und reset
und keinen der get
Zitat von: PeMue am 14 Mai 2016, 21:40:29
Edit3: Dank steckbaren Modulen wird auch der BME280 erkannt, sehr schön!
Na Dein LGW macht ja gleich jede Menge Bekanntschaften ;D ;D ;D
Edit1: Quotes sortiert, jetzt sollte es besser aussehen
Edit2: 868960 für meine PCAs
Zitat von: PeMue am 14 Mai 2016, 21:40:29
2016-05-14_22:33:26 LaCrosse_00 pressure: 1015
Prima, meiner misst aktuell 1017
Zitat von: PeMue am 14 Mai 2016, 21:40:29
Auch mit event-min-interval scheint das Ganze nicht zu bändigen zu sein. Aber ich lasse das Ding mal durchlaufen ...
event-on-change-reading
Zitat von: christianv77 am 12 Mai 2016, 19:24:21
Aktueller Verbraucht passt, aber Gesamtverbrauch ist etwa um den Faktor 10-15 zu noch.
Anbei eine Test-Version. Würdest Du damit bitte mal testen, ob es jetzt bei Dir passt?
@amunra: als MCP23008-Besitzer kannst Du mal die PushButtons mit dieser Version ausprobieren, wenn Du willst.
Fragen und Ergebnis dann im "Display-Thread"
@all:Das ist eine Test-Version und keine Release und sie ist nicht für den Produktivbetrieb gedacht.
Keine Anhnung, ob da gerade alles funktioniert.
Zitat
Anbei eine Test-Version. Würdest Du damit bitte mal testen, ob es jetzt bei Dir passt?
Getestet und für gut befunden 8)
Ich danke dir vielmals.
Das ganze läuft jetzt seit ca 10min und alle Werte passen.
Werde es jetzt mal so weiter laufen lassen und sehen ob sich noch was ergibt.
Dann bist du der erste der es Erfährt, versprochen :P
Weiterhin ein schönes Pfingstwochenende.....
Zitat von: christianv77 am 14 Mai 2016, 23:52:58
Das ganze läuft jetzt seit ca 10min und alle Werte passen.
Prima, ein Topic weniger auf der ToDo.
Wenn sich noch was ergibt, lass es mich wissen.
Was interessant ist: ich hatte im Rahmen dieser Fehlersuche einen original JeeLink mit dem EC3000 Sketch laufen und ein LGW, um die Werte zu vergleichen. Beide standen nebeneinander. Das LGW mit dem RFM69 hat einen deutlich besseren EC3000-Empfang. Der JeeLink Sketch hat es trotz Antennenpositionssuche nie geschafft, alle mein EC3000 gleichzeitig zu hören, je nach Antennenposition mal die einen und mal die anderen. Das LGW hat da keine Probleme.
Ich glaube, die Aussagen, dass EC3000 eine schlechte Reichweite hätte, die ich in irgend einem EC3000-Thread gelesen habe, resultiert nicht daraus, dass die EC3000 schlecht sind sondern daraus, dass der JeeLink Sketch nicht gut hört.
Zitat von: PeMue am 14 Mai 2016, 21:40:29
Auch mit event-min-interval scheint das Ganze nicht zu bändigen zu sein. Aber ich lasse das Ding mal durchlaufen ...
Wenn man den Befehl richtig anwendet, dann funktioniert es sogar ;D ;D ;D
Zitat von: HCS am 14 Mai 2016, 22:47:26
Häng mal ein list von Deinem JeeLink device hier an.
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF 192.168.188.33:81
DeviceName 192.168.188.33:81
FD 31
NAME PMLGW01
NR 355
PARTIAL
PMLGW01_MSGCNT 20
PMLGW01_TIME 2016-05-15 09:03:42
RAWMSG OK WS 0 4 4 193 36 255 255 255 255 255 255 255 255 0 3 252
STATE Initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.Gateway.1.18 (1=RFM69 f:868960 r:6631) + BME280 + LM75 {IP=192.168.188.33}]
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-05-15 09:00:53 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 1,868960,120i 240h v
room 9.1_Radio
timeout 30,30 8) 8) 8) Das Attribut flashCommand ist auch nicht wirklich notwendig, avrdude gibt es nämlich nicht auf meiner FritzBox ... 8) 8) 8)
Wünsche allen einen schönen Pfingstsonntag.
Gruß PeMue
Sieht gut aus der list. Bist doch 20 Meter höher als ich :)
Zitat von: PeMue am 15 Mai 2016, 09:12:08
8) 8) 8) Das Attribut flashCommand ist auch nicht wirklich notwendig, avrdude gibt es nämlich nicht auf meiner FritzBox ... 8) 8) 8
Dann must Du halt den Hex-Dump auf einem Mobilteil eintippen ;D ;D
Ist aber beim LGW egal, der "set myJeeLink flash" für das LGW verwendet kein avrdude und kein flashCommand, das wird nur bei JeeLink verwendet. Für das LGW macht es einen File-Upload, dazu benötigt man aber LWP::UserAgent.
Keine Ahnung, ob man das auf einer FritzBox haben kann.
Notfalls kann man die Firmware auch so zum LGW hochschicken:
curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@.\JeeLink_LaCrosseGateway.bin; filename=firmware.bin" http://192.168.31.211/ota/firmware.bincurl gibt es auch für Windows oder man nimmt etwas sinngemäßes.
Zitat von: HCS am 15 Mai 2016, 09:35:13
Notfalls kann man die Firmware auch so zum LGW hochschicken:
curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@.\JeeLink_LaCrosseGateway.bin; filename=firmware.bin" http://192.168.31.211/ota/firmware.bin
curl gibt es auf der FritzBox, zumindest von SolarView, sprich ich könnte ja mein set myJeeLink flash auf den curl Befehl "umbiegen", oder?
Zitat von: PeMue am 15 Mai 2016, 09:46:01
curl gibt es auf der FritzBox, zumindest von SolarView, sprich ich könnte ja mein set myJeeLink flash auf den curl Befehl "umbiegen", oder?
Nichts umbiegen. "set myJeeLink flash" verwendet auch kein curl.
Alles lassen wie es ist. Setzt doch in FHEM einfach mal einen "set myJeeLink flash" ab und schau, was passiert.
Dauert so ca. 30 Sekunden, dann solltest Du etwas in der Art sehen:
flashing JeeLink JeeLink211
detected Firmware: LaCrosseGateway.bin
hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
Mode is LaCrosseGateway OTA-update
JeeLink211 closed
target: http://192.168.31.211/ota/firmware.bin
Sketch reports:
Start receiving 'firmware.bin'
Firmware size: 412896
Rebooting ESP8266 ...
OTA update finished
JeeLink211 opened Danach dauert es dann nochmal ca. eine Minute bis der timeout 30,30 zum LGW neu connected hat.
Einen wunder schönen guten Morgen @all ;D
Sorry HCS, zu früh gefreut.......
Ein Ausreißer ist leider noch dabei, dieses mal allerdings in die Gegenrichtung 8)
CONS sollte 1272.154 sein, ist leider aber 79.107
Hier wieder die Logdaten:
09:47:03: EC3000 [47 49 e5 a7 0 0 f 7f 0 0 0 0 f9 85 c4 0 0 6 99 0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 11 5 b0 30 f cf f7 ] CRC:OK ID:4749 TS:16836007 OS:5967743 W:0.00 max-W:168.90 Cons:79.11 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
09:47:08: EC3000 [47 49 e5 ac 0 0 f 7f 0 0 0 0 f9 85 c4 0 0 6 99 0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 11 5 b0 30 b b2 f7 ] CRC:OK ID:4749 TS:16836012 OS:5967743 W:0.00 max-W:168.90 Cons:79.11 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
09:47:13: EC3000 [47 49 e5 b1 0 0 f 7f 0 0 0 0 f9 85 c4 0 0 6 99 0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 11 5 b0 30 f 1a a7 ] CRC:OK ID:4749 TS:16836017 OS:5967743 W:0.00 max-W:168.90 Cons:79.11 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
4749 OK 22 71 73 1 0 230 181 0 91 15 127 0 19 105 90 0 0 6 153 3 2 consumption 1272.154 power 0 powerMax 168.9
Zitat von: HCS am 15 Mai 2016, 07:50:39
Ich glaube, die Aussagen, dass EC3000 eine schlechte Reichweite hätte, die ich in irgend einem EC3000-Thread gelesen habe, resultiert nicht daraus, dass die EC3000 schlecht sind sondern daraus, dass der JeeLink Sketch nicht gut hört.
Die Aussage kann ich aber voll bestätigen!!!
Spitzenmässiger Empfang, selbst durch 1 Stahlbetondecke in den Keller hab ich damit jetzt alle EC3k
Grüße Christian
Zitat von: HCS am 15 Mai 2016, 09:53:03
Setz doch in FHEM einfach mal einen "set myJeeLink flash" ab und schau, was passiert.
Nein, aber mein fhem ist nicht ganz brandaktuell, muss ich mal aktualisieren:
flashing JeeLink PMLGW01
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: 192.168.188.33:81
log file: ./log/JeeLinkFlash.log
PMLGW01 closed
command: avrdude -p atmega328P -c arduino -P 192.168.188.33:81 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
sh: avrdude: not found
--- AVRDUDE ---------------------------------------------------------------------------------
PMLGW01 opened Jetzt teste ich erst mal meine selbstgelöteten BME20 :-\
Zitat von: christianv77 am 15 Mai 2016, 10:05:44
Sorry HCS, zu früh gefreut.......
Ein Ausreißer ist leider noch dabei, dieses mal allerdings in die Gegenrichtung 8)
Das ist schlecht und führt dazu, dass
Zitat von: christianv77 am 15 Mai 2016, 10:05:44
Einen wunder schönen guten Morgen @all ;D
für mich nun nicht mehr zutrifft :(
Dann werde ich mal mit deinen Log-Daten schauen, habe die Prozedur ja schon mal geübt ;D
Zitat von: PeMue am 15 Mai 2016, 10:06:16
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
Ja, das sieht nach einem deutlich zu alten 36_JeeLink.pm aus. Das kennt den Unterschied zwischen JeeLink und LGW noch nicht.
Interessant ist auch, dass das LGW nur mit LM75 auch die Feuchte ausgibt :o
(https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=52118;image)
Ich habe auch mal versucht, neue zu pairen, aber das hat auch nicht geholfen.
Die Frage eines Hardwerkers ist: Wie misst das LGW die Feuchte?
Zitat von: PeMue am 15 Mai 2016, 11:00:22
Die Frage eines Hardwerkers ist: Wie misst das LGW die Feuchte?
Es misst und sendet sie nicht. Das liegt in im LaCrosse-Modul begründet.
Entweder: FHEM neustart und dann das reading löschen, dann sollte es auch nicht mehr kommen
oder: das LaCrosse device löschen und neu anlegen.
Zitat von: christianv77 am 15 Mai 2016, 10:05:44
Sorry HCS, zu früh gefreut.......
Ein Ausreißer ist leider noch dabei, dieses mal allerdings in die Gegenrichtung 8)
CONS sollte 1272.154 sein, ist leider aber 79.107
Anbei ein neuer Anlauf.
Manchmal wünsche ich mir einen Compiler, der merkt, dass ich bits aus einem int32 links raus shifte ::)
Aber gut ist, dass bei Dir so ziemlich alle Consumptions vorkommen, die ein Problem sein könnten :)
Zitat von: HCS am 15 Mai 2016, 11:09:51
Es misst und sendet sie nicht. Das liegt in im LaCrosse-Modul begründet.
Entweder: FHEM Neustart ...
Ja, fhem Neustart hilft. Es ist ja auch nicht so, dass sich die Hardware so schnell ändert, aber ich teste halt, was so geht ;)
Zitat von: HCS am 15 Mai 2016, 20:34:11
Manchmal wünsche ich mir einen Compiler, der merkt, dass ich bits aus einem int32 links raus shifte ::)
Jaja, wer wünscht sich das nicht ab und zu .... :P
Zitat von: HCS am 15 Mai 2016, 20:34:11
Aber gut ist, dass bei Dir so ziemlich alle Consumptions vorkommen, die ein Problem sein könnten :)
Ich hab irgend wann mal ein ganzes Paket Lager-/Restbestände (so 30 Stück) bei unserem Ortsansässigem Elektronikfutzi gekauft.
Er meinte die Will keiner mehr und er braucht Geld^^
Naja, da merkt man eben doch den Unterschied zwischen Elektroniker und BWLer ... ::)
Aber dadurch kann ich dir wenigstens eine Umfangreiche Testumgebung bieten und dich noch ein wenig Vordern, bevor dir Langweilig wird 8)
Übrigens Test läuft,
bis jetzt echt super!!!Und nochmals vielen Dank für die Mühe die ich machen durfte ....
Du Leistes echt gute Arbeit mit dem Teil.
Viele Dank.
Grüße Christian
EDIT 1:
Leider doch nicht so super...
Sind wieder paar mehr die jetzt, wieder nach OBEN, abhauen.
Log folgt ... ;D
EDIT 2:
und die Logs:
22:19:11: EC3000 [7b c6 40 3e 0 0 40 3e 0 0 0 1 f8 7c 72 4 5b 1b 2d 6c 29 d8 58 3b 86 f1 b8 5e a6 26 c0 0 0 0 a 26 c0 18 6 8 37 ] CRC:OK ID:7bc6 TS:40648766 OS:40648766 W:111.50 max-W:695.70 Cons:11939.65 Res.:1 Rec.:0 IsOn:1 CRC:f0b8
22:19:12: EC3000 [47 49 95 f1 0 0 f 7f 0 0 0 0 f9 85 c4 0 0 6 99 0 0 0 0 0 0 0 0 0 0 10 10 0 0 0 11 5 b0 30 b c7 97 ] CRC:OK ID:4749 TS:16881137 OS:5967743 W:0.00 max-W:168.90 Cons:20286.33 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
22:19:13: EC3000 [30 e5 e ee 0 0 e c0 0 0 0 4 2 50 eb 0 11 49 91 a 96 22 4f 1a 23 75 2 8b ff 21 10 0 0 0 f 21 10 28 d 34 57 ] CRC:OK ID:30e5 TS:34672366 OS:34672320 W:1.70 max-W:1883.30 Cons:17914.38 Res.:2 Rec.:0 IsOn:1 CRC:f0b8
22:19:13: EC3000 [7b 7c ee ba 0 0 7d ab 0 0 0 6 3d 31 1a 0 0 48 d5 0 0 20 0 0 0 0 6 d4 b8 26 b0 0 0 0 1 1 20 20 9 be 7 ] CRC:OK ID:7b7c TS:40627898 OS:1211819 W:0.00 max-W:1864.50 Cons:1222.12 Res.:2 Rec.:0 IsOn:0 CRC:f0b8
22:19:14: EC3000 [7b 3b 12 e5 0 0 12 e5 0 0 0 a dc 74 6e 2 5c 5 82 64 99 8 51 cb 85 6d 68 54 60 22 10 0 0 0 8 22 10 c8 a fb 77 ] CRC:OK ID:7b3b TS:35721957 OS:35721957 W:60.40 max-W:141.00 Cons:9594.99 Res.:12 Rec.:0 IsOn:1 CRC:f0b8
22:19:15: EC3000 [49 90 1f 23 0 0 f6 b2 0 0 0 2 26 5f a2 0 0 7d 9c 45 b3 f4 56 1b 55 7d e4 45 39 21 10 0 0 0 1 0 70 30 f 50 27 ] CRC:OK ID:4990 TS:34676515 OS:521906 W:0.00 max-W:3215.60 Cons:1203.07 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
22:19:16: EC3000 [7b c6 40 43 0 0 40 43 0 0 0 1 f8 7e a0 4 60 1b 2d 6c 2c 8 58 3b 86 f1 b8 5e a6 26 c0 0 0 0 a 26 c0 18 b 95 d7 ] CRC:OK ID:7bc6 TS:40648771 OS:40648771 W:112.00 max-W:695.70 Cons:11939.65 Res.:1 Rec.:0 IsOn:1 CRC:f0b8
22:19:17: EC3000 [47 49 95 f6 0 0 f 7f 0 0 0 0 f9 85 c4 0 0 6 99 0 0 0 0 0 0 0 0 0 0 10 10 0 0 0 11 5 b0 30 6 e5 37 ] CRC:OK ID:4749 TS:16881142 OS:5967743 W:0.00 max-W:168.90 Cons:20286.33 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
22:19:48: EC3000 [30 e5 f 11 0 0 e e3 0 0 0 4 2 51 27 0 11 49 91 a 99 d2 4f 1a 23 75 2 8b ff 21 10 0 0 0 f 21 10 28 5 87 77 ] CRC:OK ID:30e5 TS:34672401 OS:34672355 W:1.70 max-W:1883.30 Cons:17914.38 Res.:2 Rec.:0 IsOn:1 CRC:f0b8
22:19:48: EC3000 [7b 7c ee dd 0 0 7d ab 0 0 0 6 3d 31 1a 0 0 48 d5 0 0 20 0 0 0 0 6 d4 b8 26 b0 0 0 0 1 1 20 20 d 83 b7 ] CRC:OK ID:7b7c TS:40627933 OS:1211819 W:0.00 max-W:1864.50 Cons:1222.12 Res.:2 Rec.:0 IsOn:0 CRC:f0b8
22:19:49: EC3000 [7b 3b 13 8 0 0 13 8 0 0 0 a dc 7c c0 2 5f 5 82 64 a1 58 51 cb 85 6d 68 54 60 22 10 0 0 0 8 22 10 c8 9 7e d7 ] CRC:OK ID:7b3b TS:35721992 OS:35721992 W:60.70 max-W:141.00 Cons:9594.99 Res.:12 Rec.:0 IsOn:1 CRC:f0b8
22:19:50: EC3000 [49 90 1f 46 0 0 f6 b2 0 0 0 2 26 5f a2 0 0 7d 9c 45 b3 f4 56 1b 55 7d e4 45 39 21 10 0 0 0 1 0 70 30 8 77 67 ] CRC:OK ID:4990 TS:34676550 OS:521906 W:0.00 max-W:3215.60 Cons:1203.07 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
22:19:51: EC3000 [7b c6 40 66 0 0 40 66 0 0 0 1 f8 8e 30 4 82 1b 2d 6c 3b 98 58 3b 86 f1 b8 5e a6 26 c0 0 0 0 a 26 c0 18 7 81 17 ] CRC:OK ID:7bc6 TS:40648806 OS:40648806 W:115.40 max-W:695.70 Cons:11939.65 Res.:1 Rec.:0 IsOn:1 CRC:f0b8
22:19:51: EC3000 [47 49 96 19 0 0 f 7f 0 0 0 0 f9 85 c4 0 0 6 99 0 0 0 0 0 0 0 0 0 0 10 10 0 0 0 11 5 b0 30 1 9d a7 ] CRC:OK ID:4749 TS:16881177 OS:5967743 W:0.00 max-W:168.90 Cons:20286.33 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
22:19:53: EC3000 [30 e5 f 16 0 0 e e8 0 0 0 4 2 51 2f 0 11 49 91 a 9a 62 4f 1a 23 75 2 8b ff 21 10 0 0 0 f 21 10 28 7 4b 7 ] CRC:OK ID:30e5 TS:34672406 OS:34672360 W:1.70 max-W:1883.30 Cons:17914.38 Res.:2 Rec.:0 IsOn:1 CRC:f0b8
22:19:53: EC3000 [7b 7c ee e2 0 0 7d ab 0 0 0 6 3d 31 1a 0 0 48 d5 0 0 20 0 0 0 0 6 d4 b8 26 b0 0 0 0 1 1 20 20 2 c4 17 ] CRC:OK ID:7b7c TS:40627938 OS:1211819 W:0.00 max-W:1864.50 Cons:1222.12 Res.:2 Rec.:0 IsOn:0 CRC:f0b8
22:19:54: EC3000 [7b 3b 13 d 0 0 13 d 0 0 0 a dc 7d f0 2 6b 5 82 64 a2 88 51 cb 85 6d 68 54 60 22 10 0 0 0 8 22 10 c8 e 3a e7 ] CRC:OK ID:7b3b TS:35721997 OS:35721997 W:61.90 max-W:141.00 Cons:9594.99 Res.:12 Rec.:0 IsOn:1 CRC:f0b8
22:19:55: EC3000 [49 90 1f 4b 0 0 f6 b2 0 0 0 2 26 5f a2 0 0 7d 9c 45 b3 f4 56 1b 55 7d e4 45 39 21 10 0 0 0 1 0 70 30 8 25 f7 ] CRC:OK ID:4990 TS:34676555 OS:521906 W:0.00 max-W:3215.60 Cons:1203.07 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
22:19:56: EC3000 [7b c6 40 6b 0 0 40 6b 0 0 0 1 f8 90 74 4 88 1b 2d 6c 3d d8 58 3b 86 f1 b8 5e a6 26 c0 0 0 0 a 26 c0 18 9 51 c7 ] CRC:OK ID:7bc6 TS:40648811 OS:40648811 W:116.00 max-W:695.70 Cons:11939.65 Res.:1 Rec.:0 IsOn:1 CRC:f0b8
22:19:57: EC3000 [47 49 96 1e 0 0 f 7f 0 0 0 0 f9 85 c4 0 0 6 99 0 0 0 0 0 0 0 0 0 0 10 10 0 0 0 11 5 b0 30 c bf 7 ] CRC:OK ID:4749 TS:16881182 OS:5967743 W:0.00 max-W:168.90 Cons:20286.33 Res.:3 Rec.:0 IsOn:0 CRC:f0b8
22:19:58: EC3000 [30 e5 f 1b 0 0 e ed 0 0 0 4 2 51 38 0 11 49 91 a 9a e2 4f 1a 23 75 2 8b ff 21 10 0 0 0 f 21 10 28 a 15 37 ] CRC:OK ID:30e5 TS:34672411 OS:34672365 W:1.70 max-W:1883.30 Cons:17914.38 Res.:2 Rec.:0 IsOn:1 CRC:f0b8
22:19:58: EC3000 [7b 7c ee e7 0 0 7d ab 0 0 0 6 3d 31 1a 0 0 48 d5 0 0 20 0 0 0 0 6 d4 b8 26 b0 0 0 0 1 1 20 20 c fc 47 ] CRC:OK ID:7b7c TS:40627943 OS:1211819 W:0.00 max-W:1864.50 Cons:1222.12 Res.:2 Rec.:0 IsOn:0 CRC:f0b8
22:19:59: EC3000 [7b 3b 13 12 0 0 13 12 0 0 0 a dc 7f 25 2 63 5 82 64 a3 b8 51 cb 85 6d 68 54 60 22 10 0 0 0 8 22 10 c8 6 25 47 ] CRC:OK ID:7b3b TS:35722002 OS:35722002 W:61.10 max-W:141.00 Cons:9594.99 Res.:12 Rec.:0 IsOn:1 CRC:f0b8
So sollte es sein:
7BC6 OK 22 123 198 2 104 91 104 2 104 91 104 0 11 112 136 5 111 27 37 1 10 consumption 749.706 power 137.7 powerMax 694.9
4990 OK 22 73 144 2 13 59 6 0 7 224 106 0 1 72 15 0 0 125 156 3 1 consumption 83.983 power 0 powerMax 3215.6
7B7C OK 22 123 124 2 104 10 162 0 18 79 130 0 1 145 160 0 0 72 213 2 0 consumption 102.816 power 0 powerMax 1864.5
4749 OK 22 71 73 1 0 230 181 0 91 15 127 0 19 105 90 0 0 6 153 3 2 consumption 1272.154 power 0 powerMax 168.9
30E5 OK 22 48 229 2 17 12 225 2 17 12 179 0 17 90 12 0 17 73 145 2 3 consumption 1137.164 power 1.7 powerMax 1883.3
Kann ich dir sonst noch irgend wie Helfen?
Zitat von: christianv77 am 15 Mai 2016, 22:06:04
Kann ich dir sonst noch irgend wie Helfen?
Ich kann das mit Deinen Daten diesmal (im Gegensatz zu den vorherigen Runden) nicht nachvollziehen.
Der Consumption Algorithmus liefert für alle den korrekten Wert.
Jetzt gibt es verscheidene Möglichkeiten:
Du hast den vorhergehenden Sketch wieder hochgeladen
oder
Ich habe den falschen Sketch angehängt
oder
Ein Problem, das ich aktuell nicht erkenne
Ich habe die Version nochmal gebildet und sie zur Sicherheit 1.19
B genannt (anbei)
Testest Du damit bitte nochmal?
Verwendest Du auf dem JeeLink diese Version?
https://forum.fhem.de/index.php/topic,11648.msg237746.html#msg237746
oder eine ältere?
Und wieder einmal ein wunder schöner guten Morgen,
mit Geschenken von HCS 8)
OK, Version ist geprutzelt und läuft .....
Er zeigt schon mal Version 1.19B an ;D
Ich werde dann Berichten.
@all noch einen schönen Pfingstmontag
EDIT 1:
OK, diesmal scheint echt ALLES zu passen.
Keine Ahnung was bei der letzten Version schief gelaufen ist ::)
War auf jeden Fall interessant, da bei der letzten Version andere Werte als vorher abgehauen sind ...
Aber egal, es läuft einwandfrei!!!!! 8)
1000x Dank !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Hallo HCS,
ich hätte auch einen Wunsch - kann man die LaCrosse-ID, mit der die internen Sensoren des Gateways übermittelt werden, konfigurierbar machen (statt hardcoded die 0 zu nehmen)? Dies wäre praktisch, wenn man mehr als ein Gateway benutzen möchte...
Danke für die tolle Arbeit!
Nico
Zitat von: Wallmeier am 16 Mai 2016, 18:13:54
ich hätte auch einen Wunsch - kann man die LaCrosse-ID, mit der die internen Sensoren des Gateways übermittelt werden, konfigurierbar machen (statt hardcoded die 0 zu nehmen)? Dies wäre praktisch, wenn man mehr als ein Gateway benutzen möchte...
Den Wunsch habe ich zur Sicherheit letzte Woche schon mal vorab erfüllt ;D
Hatte das gleiche Problem.
Kannst es, wenn Du willst, mal mit der Beta aus diesem Post ausprobieren:
https://forum.fhem.de/index.php/topic,43672.msg451172.html#msg451172
Zitat von: christianv77 am 16 Mai 2016, 10:00:57
OK, diesmal scheint echt ALLES zu passen.
Keine Ahnung was bei der letzten Version schief gelaufen ist ::)
War auf jeden Fall interessant, da bei der letzten Version andere Werte als vorher abgehauen sind ...
Aber egal, es läuft einwandfrei!!!!! 8)
Das ist die Hauptsache. Dann lasse ich EC3000 so wie es jetzt ist und es wird dann mit einer offiziellen 1.19 offiziell kommen ;D
Zitat von: HCS am 16 Mai 2016, 19:12:11
Den Wunsch habe ich zur Sicherheit letzte Woche schon mal vorab erfüllt ;D
Kannst es, wenn Du willst, mal mit der Beta aus diesem Post ausprobieren:
https://forum.fhem.de/index.php/topic,43672.msg451172.html#msg451172
Klappt bestens :)
Ganz herzlichen Dank!
Nico
Zitat von: HCS am 16 Mai 2016, 19:12:11
Den Wunsch habe ich zur Sicherheit letzte Woche schon mal vorab erfüllt ;D
Hatte das gleiche Problem.
Kannst es, wenn Du willst, mal mit der Beta aus diesem Post ausprobieren:
https://forum.fhem.de/index.php/topic,43672.msg451172.html#msg451172
Bedeutete das etwa das ich wieder pro Etage ein Gateway aufbauen kann und die sich nicht mehr untereinander hauen und stechen? ;)
Zitat von: waschbaerbauch am 17 Mai 2016, 10:55:13
Bedeutete das etwa das ich wieder pro Etage ein Gateway aufbauen kann und die sich nicht mehr untereinander hauen und stechen? ;)
Keine Ahnung, was sich bei Dir haut und sticht.
Um diese Änderung nochmal zu beleuchten: Wenn ein LGW interne Sensoren hat (BMP280, BMP180, DHT22, ...) dann sendet es die Daten des Sensors so, als ob es eine Wetterstation wäre (WS 1600 Format) an das LGW. Bisher hat es dafür die Sensor-ID 0 verwendet. Wenn man mehrere LGWs an ein FHEM angebunden hat, dann mischen sich deren Sensor-Daten auf dem LaCrosse device mit der ID 0. Um das zu vermeiden, kann man nun konfigurieren, mit welcher Sensor-ID die internen Sensoren gesendet werden sollen und die beiden LGWs unterschiedliche konfigurieren.
Das hat keinerlei Einfluss auf und nichts zu tun mit Daten, die von den Radios empfangen werden.
Ach ok - dann hab ich das in den falschen Hals bekommen. Ich meinte ja die (damals) nicht vorgesehene Funktion mehrere Gateways zu betreiben um z.B. PCA301 Dosen zu schalten / Verbrauchswerte zu empfangen. Also im FHEM würde ich dann ja das nahe liegende Gateway zum anfunken konfigurieren, aber welches der Gateways bzw. welche Gateways alle die Antwort bekommen und ans FHEM weiterleiten - da sollte das FHEM dann irgendwie doppelte ausfiltern ... oder so ;D
LGW (Version 1.18) verbindet sich nicht mehr mit meinem WLAN-Netzwerk.
Ich hatte heute mal den Strom abgeschaltet gehabt. Nach Wiederanschalten hatte das LGW keine Verbindung mehr mit meinem Netzwerk aufgebaut. Es ist nur erreichbar unter 192.168.222.1.
Habe mich dahin verbunden. Meine Daten waren noch da. Nach "Save und Restart" kam Fehlermeldung "Password do not match". In dem Feld "retype" (Passwortfeld für die Webseite) war auch nichts drin. Habe auch da mein Passwort eingetragen. Danach war ein Speichern und Restart möglich. Allerdings wird immer noch nicht die Verbindung zu meinem normalen WLAN aufgebaut, immer nur zu LaCrosseGateway_16446580 mit IP 192.168.222.1.
Ich bin momentan etwas ratlos, ich hoffe, du kannst mir weiterhelfen.
Danke
Holger
Update: Eben (2 Std. später) noch mal einen Reset ausgelöst. Jetzt hat das LGW sich endlich wieder mit meinem WLAN verbunden (ohne dass ich ansonsten etwas geändert habe). Ist schon komisch.
Zitat von: waschbaerbauch am 17 Mai 2016, 12:40:47
Ach ok - dann hab ich das in den falschen Hals bekommen. Ich meinte ja die (damals) nicht vorgesehene Funktion mehrere Gateways zu betreiben um z.B. PCA301 Dosen zu schalten / Verbrauchswerte zu empfangen.
Also audrücklich nicht vorgesehen ist es nicht und ich habe hier bei mir zwei LGWs laufen, die beide PCA301 machen, von denen ich aber nur drei Stück habe. Das funktioniert, beide LGWs haben die Werte und können schalten.
Ich glaube, dass es bei Dir schlicht die Menge und Situation ist.
Können wir das Thema eines Tages mal wieder aufgreifen?
Momentan habe ich auch keine Idee, wie ich Dein Szenario nachstellen kann, ohne mir noch hundert Dosen zu kaufen.
Klar können wir - ich hab doch nur 30 Dosen ;)
Zitat von: waschbaerbauch am 20 Mai 2016, 17:32:44
Klar können wir - ich hab doch nur 30 Dosen ;)
Ist halt satt Faktor 30 mehr als bei mir 8)
Naja heute sind erstmal Peters vorgeschlagene Gehäuse von Reichelt geliefert worden. Ein LGW konnte ich darin schon mal versenken, allerdings war ich noch so verwirrt von der Arbeit, das ich doch glatt versucht habe die mitgelieferten Schrauben durch die Löcher des PCB zu schrauben (man war das schwer) - bis ich dann gemerkt haben - OH, vielleicht sind die doch eher zum Gehäuse verschrauben von außen gedacht :D
noch eine Frage zur Konfiguration:
Wenn ich alles leer lasse, dann wird DHCP verwendet, oder verstehe ich das falsch?
(https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=52475;image)
Ich habe mal trotzdem Gateway und Netmask eingetragen und erhoffe mir eine dynamische Addressbelegung durch die Fritz Box.
Danke + Gruß
Peter
Zitat von: PeMue am 22 Mai 2016, 12:47:42..., oder verstehe ich das falsch?
So halb und halb :)
Wenn IP
oder Mask
oder Gateway leer ist (also nicht alle drei ausgefüllt sind) macht es DHCP.
Nur wenn alle drei ausgefüllt sind, verwendet es eine statische IP-Konfiguration.
Dazwischen gibt es nichts.
Verbesserungsvorschlag:
DHCP will be used, in case of one of the fields IP, mask or gateway remains empty.
Zitat von: PeMue am 22 Mai 2016, 18:27:46
Verbesserungsvorschlag:
DHCP will be used, in case of one of the fields IP, mask or gateway remains empty.
Der Vorschlag wurde geprüft, vom Produktmanager akzeptiert, von der Entwicklung als implementierbar bewertet und für die kommende Release 1.19 als Topic mit dem Status "Verbesserung" eingeplant.
Hallo,
darf ich ein kleines Veto anmerken?
Es kann IP/Mask OK, aber es kann sinnvoll sein kein GW einzutragen
Nico
Zitat von: santalaus am 24 Mai 2016, 21:35:03
... aber es kann sinnvoll sein kein GW einzutragen
Stimmt, kann es. Ich schreibe es mal auf die ToDo.
Zitat von: PeMue am 23 Mai 2016, 19:56:43
Mist, ein bisschen trocken und zu warm >:( >:(
humidity 35 2016-05-23 21:11:49
pressure 1015 2016-05-23 21:11:49
temperature 28.2 2016-05-23 21:11:49
Ja, ist nicht ideal, wenn der BME auf der Platine sitzt. Ist bei mir auch so. Wenn man ihn ein Stück weit weg setzt, wird es besser.
Aber Sensorwerte sind eh so ein Kapitel. Habe mal ein Experiment gemacht und einiges an ein Stelle gestellt und 30 Minuten gewartet, bis die Werte stabil sind. Siehe Bild.
Ergebnis:
Sensor Temp Hum Pressure
-----------------------------------------------
Wetter.net 1016
WS 1600 1016
1) LGW209 (DHT22) 23.3 49
2) LGW211 (DHT22 + BMP180) 24.1 48 1018
3) BME280 Links (Watterott) 22.5 51 1018
4) BME280 Rechts (China) 22.9 60 1018
5) TX38IT 20.9
6) 30.3155.WD 21.3 58
7) TX35DTH 21.6 56
8) Billig-Thermometer 21 49 Die Zahlen vorne findet man auf dem Bild, da wo der Pfeil hin zeigt, sitzt der Sensor.
Welche Temperatur und Feuchte nun wirklich an der Stelle herscht? Keine Ahnung. Ich habe absolut nichts, von dem ich sicher bin, dass es genau misst. :(
ich würde etwas zwischen 21 und 22 Grad vermuten.
Was auffällt:
- beide DHT22 liegen sehr hoch mit der Temperatur, und zumindest 2) steht frei in der Luft. Daraus resultiert dann die niedrige Feuchte.
- der Druck liefert bei allen passable und einheitliche Werte, evtl. liege ich mit meine Höhe ü. NN nicht ganz richtig.
- die beiden BME280 3) und 4) sind sich mit der Feuchte nicht einig.
3) und 4) werden von einer Testroutine abgefragt, die für die beiden BMEs jeweils eine Instanz der Klasse macht, die auch im LGW verwendet wird.
Somit ist sicher, dass die Sensoren unterschiedliche Werte liefern und nicht die Firmware seltsam rechnet.
Und da sie direkt nebeneinander stecken, können die tatsächlichen Werte kaum abweichen.
Je nachdem, welchen Wert man nun nimmt, kann man sich aussuchen, ob man gerade friert oder schwitzt ;D
Wer es noch nicht entdeckt hat: im LaCrosse Modul kann man Korrektur-Offsets für Temperatur und Feuchte definieren.
Die Moral von der Geschicht'
-> traue Deinem Sensor nicht
Zitat von: HCS am 26 Mai 2016, 10:30:17
Wer es noch nicht entdeckt hat: im LaCrosse Modul kann man Korrektur-Offsets für Temperatur und
stimmt, aber hier
36_LaCrosse.pm 10303 2015-12-29 22:07:01Z hcs-svn noch nicht, ich sollte doch mal aktualisieren ;D
Edit:Ich Schnarchzapfen habe versucht, dem JeeLink Modul die Korrektur unterzujubeln, was natürlich André erfolgreich zu verhindern wusste ;). Naja, jetzt ist fhem mal wieder aktuell ;D
Zitat von: PeMue am 26 Mai 2016, 10:53:40
36_LaCrosse.pm 10303 2015-12-29 22:07:01Z hcs-svn
noch nicht, ich sollte doch mal aktualisieren ;D
Das ist, wie wenn ich diese Platine verwenden würde: ;D ;D
https://forum.fhem.de/index.php?action=dlattach;topic=45594.0;attach=44927 (https://forum.fhem.de/index.php?action=dlattach;topic=45594.0;attach=44927)
Bilder einfügen geht nun leider nicht mehr :o
Aber Du warst ja der Erste, der es gemerkt hat ;D
V1.19
SDK
Arduino 1.6.9 / Espressiv 1.5.3 / Arduino Core Rev. 14405
MCP23008
I2C Adresse 0x27 -> A0,A1,A2 = 3.3V
|-------\/-------|
LGW D1 |1 SCL VDD 18| LGW 3.3V
LGW D2 |2 SDA GP7 17| PB7 --/ --- GND or Output
LGW 3.3V |3 A2 GP6 16| PB6 --/ --- GND or Output
LGW 3.3V |4 A1 GP5 15| PB5 --/ --- GND or Output
LGW 3.3V |5 A0 GP4 14| PB4 --/ --- GND or Output
LGW 3.3V |6 RES GP3 13| PB3 --/ --- GND or Output
|7 NC GP2 12| PB2 --/ --- GND or Output
|8 INT GP1 11| PB1 --/ --- GND or Output
LGW GND |9 VSS GP0 10| PB0 --/ --- GND or Output
|----------------|
Auf der config page kann für jeden der 8 IO Pins konfiguriert werden, ob:
Input
Eingang, wird per KVP an FHEM übermittelt
Beispiel: OK VALUES LGPB 211 GP2=0,GP3=1,GP4=0,GP5=0,GP6=0,GP7=0
Output
Kann von FHEM aus gesetzt werden.
Beispiel: set myJeeLink raw "MCP GP0=1,GP1=0"
OLED On
schaltet ein angeschlossenes Display ein
Beispiel: set myJeeLink raw "OLED On"
OLED Off
schaltet ein angeschlossenes Display aus
Beispiel: set myJeeLink raw "OLED Off"
IP-Konfiguration
Für eine statische Konfiguration reicht es nun, dass IP und Mask ausgefüllt sind
Settings im EEPROM
Beim Speichern auf der Setup page wird die belegte und maximale Größe der Settings ausgegeben.
Dient dazu, zu erkennen, ob es im EEPROM eng wird.
Init log
"Starting I2C with 400000 kHz" war falsch, das sind 400 kHz
ID der internen Sensoren
Die ID, mit der die internen Sensoren an FHEM übermittelt werden, kann nun auf der Setup page konfiguriert werden.
Sie kann entweder Dezimal (211) oder Hex (0xD3) angegeben werden.
EC3000: falsche consumption Werte
Es kam vor, dass für EC3000 falsche consumption Werte berechnet wurden
Display
Es kann ein OLED angeschlossen werden. Detail siehe auch hier: https://forum.fhem.de/index.php/topic,52921.0.html
Aktuell wird im Wesentlichen die oberste Zeile unterstützt.
Symbole von links nach rechts:
- WiFI connect erfolgreich
- Ein FHEM hat sich auf einen DataPort connected
- Ein FHEM hat sich auf den Prozessor an der uart bridge connected
- Rechts oben wird WiFi RSSI angezeigt. Weniger Minus ist besser.
Display ist noch etwas Beta und nicht fertig.
Der untere Teil und weitere Optionen kommen dann mit 1.20 oder so.
Ab morgen mit dem FHEM-Update oder für dringende Fälle sofort im Repo.
@amunra: Arbeit fürs wiki ;) :)
Zitat von: HCS am 28 Mai 2016, 22:19:16
@amunra: Arbeit fürs wiki ;) :)
Ja, ja... die Mitarbeiter drohen schon mit unbefristetem Streik, und! testen muss ich das ganze ja auch noch... ;) ;D
Zitat von: amunra am 28 Mai 2016, 22:25:17
und! testen muss ich das ganze ja auch noch... ;) ;D
Leg los, bin gespannt ob es funktioniert ;D ;D ;D
Zitat von: HCS am 26 Mai 2016, 11:13:00
Das ist, wie wenn ich diese Platine verwenden würde: ;D ;D
https://forum.fhem.de/index.php?action=dlattach;topic=45594.0;attach=44927 (https://forum.fhem.de/index.php?action=dlattach;topic=45594.0;attach=44927)
Aber jetzt sollte ich doch morgen OTA flashen können, oder?
36_JeeLink.pm 10927 2016-02-24 09:48:16Z justme1968
36_KeyValueProtocol.pm 9976 2015-11-22 17:46:25Z hcs-svn
36_LaCrosse.pm 10303 2015-12-29 22:07:01Z hcs-svn Gruß Peter
Edit:stressfrei (halt noch mal mit v1.8 ):
flashing JeeLink PMLGW01
detected Firmware: LaCrosseGateway.bin
hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
Mode is LaCrosseGateway OTA-update
PMLGW01 closed
target: http://192.168.188.35/ota/firmware.bin
Sketch reports:
Start receiving 'firmware.bin'
Firmware size: 412896
Rebooting ESP8266 ...
OTA update finished
PMLGW01 opened
Habe es eben mit OTA old Style geflasht.
Update funktioniert und die Masken werden auch sauber dargestellt.
Das eine Radio findet er und laut Debug-Log kommt da auch was rein.
Zitat von: PeMue am 28 Mai 2016, 22:35:09
stressfrei
Glückwunsch zu Deinem ersten OTA Update 8)
Zitat von: AxelSchweiss am 28 Mai 2016, 22:41:55
Habe es eben mit OTA old Style geflasht.
Was ist "OTA old Style" ?
Zitat von: HCS am 28 Mai 2016, 22:43:36
Was ist "OTA old Style" ?
Das was ihr abschalten wolt (Server, Port, URL) und gegen den Push-Request aus FHEM heraus ersetzten.
Daher "Old Style" ;D
Oder habe ich da was falsch verstanden?
Zitat von: AxelSchweiss am 28 Mai 2016, 22:49:41
Das was ihr abschalten wolt (Server, Port, URL) und gegen den Push-Request aus FHEM heraus ersetzten.
Daher "Old Style" ;D
Oder habe ich da was falsch verstanden?
Richtig verstanden. Hast aber Glück gehabt, dass ich es noch nicht abgeschaltet habe ;)
Dann sind ja jetzt beide Varianten getestet :)
Zitat von: HCS am 19 April 2016, 08:30:18
Serial bridge
Das LGW kann nun optional die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitstellen
Dazu gibt es die neuen settings "Serial bridge port" und "Serial bridge baud" auf der config page
Das LGW überträgt transparent die Daten der seriellen Schnittstelle an FHEM und umgekehrt.
Damit kann man z.B. einen NanoCUL an das LGW dran hängen und in FHEM verwenden.
Vorehensweise:
- Einen NanoCUL bauen, z.B. auf Basis eines Arduino Pro Mini, flashen und testweise in Betrieb nehmen. Keinen Arduino Nano nehmen, den USB-Port können wir nicht brauchen.
- Den NanoCUL an die serielle Schnittstelle des SC16IS70 anschließen
- Port und baud rate auf der Setup-Page des LGW festlegen, z.B. Port 85 und 38400 baud
- CUL in FHEM definieren: "define cul211 CUL 192.168.31.211:85 0000"
Ich habe einen ATMEGA328P mit Arduino Pro Mini Bootloader am SC16IS750 angeschlossen. Nun möchte ich die nanoCUL.hex Datei auf den ATMEGA flashen.
Kann man einen nanoCUL auf Basis eines Arduino Pro Mini über die Serial bridge des LGW flashen?
Zitat von: locutus am 29 Mai 2016, 01:00:03
Kann man einen nanoCUL auf Basis eines Arduino Pro Mini über die Serial bridge des LGW flashen?
Edit: Halt, Kommando zurück, so geht das nicht. Das funktioniert nur, wenn man tatsächlich eine AddOn CPU betreibt, aber nicht wenn man die serial bridge laufen hat.
Muss mal zwei starke Kaffee trinken und in mich gehen. avrdude über den Netzwerk-Port funktioniert nämlich auch nicht.
Bedeutet: aktuell keine Ahnung, wie es geht. Mich beschleicht das ungute Gefühl, dass ich an die Imlementierung ran muss.
Über die bridge nicht, aber man kann sie dem LGW hochladen und das flasht sie dann auf den Arduino.
Dazu wird sie einfach hochgeladen auf <LGW-IP>/ota/addon.hex
Das LGW nimmt den Upload entgegen, wandelt das Intel-Hex in binary um und schickt es per STK500-Protokoll an den Arduino.
Den Upload kann man z.B. so durchführen:
curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@/myFolder/nanoCUL.hex; filename=addon.hex" http://192.168.31.211/ota/addon.hex
Wichtig: addon.hex in meinem Beispiel ist immer addon.hex. Nur /myFolder/nanoCUL.hex wird angepasst (und die IP natürlich)
Der 328P muss wie in diesem Beispiel angeschlossen sein, also auch Reset über die 0,1uF
https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=48915
Der Upload dauert etwas, danach sollte man bei Erfolg vom LGW so ein Protokoll zurückgeschickt bekommen:
Start receiving 'addon.hex'
File: /addon.hex Size: 21417
Starting flash
Sending sync
Enter program mode
Binary size is:7608
Leave Program Mode
Flash finished
Also mit avrdude über den Netzwerk-Port hat es mehr oder weniger gut funktioniert ...
pi@raspberrypi:~ $ avrdude -p atmega328p -c arduino -P net:192.168.22.33:85 -b 57600 -U flash:w:addon.hex:i
ioctl("TIOCMGET"): Inappropriate ioctl for device
ioctl("TIOCMGET"): Inappropriate ioctl for device
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.03s
avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "addon.hex"
avrdude: writing flash (28064 bytes):
Writing | ################################################## | 100% 18.14s
avrdude: 28064 bytes of flash written
avrdude: verifying flash memory against addon.hex:
avrdude: load data flash data from input file addon.hex:
avrdude: input file addon.hex contains 28064 bytes
avrdude: reading on-chip flash data:
Reading | | 0% 0.00savrdude: stk500_recv(): programmer is not responding
Das Verifizieren ist fehlgeschlagen.
Zuvor muss im LGW die Baudrate auf 57600 eingestellt werden.
Zitat von: locutus am 29 Mai 2016, 10:09:47
Also mit avrdude über den Netzwerk-Port hat es mehr oder weniger gut funktioniert ...
Ja, und das "weniger gut" habe ich als "nicht funktionsfähig" deklariert.
Zitat von: locutus am 29 Mai 2016, 10:09:47
Zuvor muss im LGW die Baudrate auf 57600 eingestellt werden.
Ja. Das gehört auch in das Kapitel "geht nicht so recht"
Das ist alles noch nicht so, dass ich es als brauchbar betrachte.
- avrdude drängt sich gnadenlos auf den Port rein, obwohl da evtl. bereits ein FHEM drauf connected ist
- der verify und auch der flash können schiefgehen, weil sich ein FHEM einfach mal wieder drauf connected und nichts während dem Flash das verhindert
- Ich bin nicht sicher, ob die Bridge für einen flash immer durchgängig schnell genug ist. Bei STK500 kommt es auf das timing an, wenn man nicht rechtzeitig liefert, dann beschließt der bootloader, dass jetzt run ist
Darum wäre das, was ich zuerst dachte, eigentlich der bessere Weg, der in der addon-CPU Variante auch prima funktionert:
Das LGW bekommt die firmware per upload, speichert sie sich erst mal im SPIFFS und wenn das durch ist, dann wird es auf den Atmega "ausgeliefert"
Eigentlich sollte ich das auch in der Variante "Bridge" hinbekommen, das Schlimmste, nämlich das STK500 Protokoll zu implementieren und ein intel-HEX in binary umrechnen, um mit dem Arduino-bootloader zu komunizieren und ihn zu flashen, habe ich ja schon. Da die Frimware dann auf einem definierten Weg ankommt, kann das LGW den Port dichtmachen, dass während dem flash kein FHEM drauf rumturnt und die richtige baud rate für den flashen setzen.
Wenn das klappt, dann würde man genau den curl-Aufruf (oder etwas Sinngemäßes, was immer man will) verwenden, den ich weiter oben wieder durchgestrichen habe.
Klingt nach Arbeit, ist es wohl auch :(
Aber nur so wird es vermutlich was taugen.
kurze,weil noch nocht nicht alles getestet, Rückmeldung zu V1.19:
zunächst => bin jetzt schon begeistert.
- das Senden aus FHEM ist super fix (Echtzeit), man kann garnicht so schnel schauen wie die LED/LEDS an ist/sind.
- OLED an/aus per Pushbutton -> keine Auffälligkeiten festgestellt
- OLED an/aus per FHEM läuft offensichtlich noch nicht ;)
- Was sagt eigentlich der dBm Wert auf dem OLED aus, wenn keine WiFi-Verbindung hergestellt werden konnte?
- Pushbutton, hatte den Fall, dass der Status von 0 auf 1 aber nicht mehr auf 0 gesprungen ist - würde ich eher als "Verhalten beobachten" abhacken.
- OLED Ladebalken finde ich super... *schöne Spielerei ;)
... mehr kann ich, nach den kurzen Tests, nicht berrichten.
Zitat von: amunra am 29 Mai 2016, 13:08:13
- OLED Ladebalken finde ich super... *schöne Spielerei ;)
Kannst du da mal ein Filmchen mit dem Handy vom Startvorgang des LGW machen ? :P
Ich glaube langsam finde ich an dem Display auch gefallen.
Zitat von: amunra am 29 Mai 2016, 13:08:13
zunächst => bin jetzt schon begeistert.
Dann ist das erklärte Ziel erreicht und ich kann Urlaub machen ;D
Zitat von: amunra am 29 Mai 2016, 13:08:13
- OLED an/aus per FHEM läuft offensichtlich noch nicht ;)
Das sollte gehen.
set myJeeLink raw "OLED On"
set myJeeLink raw "OLED Off"
Die Anführungszeichen gehören mit dazu. Das ehemals mode=o gibt es nicht mehr.
Zitat von: amunra am 29 Mai 2016, 13:08:13
- Was sagt eigentlich der dBm Wert auf dem OLED aus, wenn keine WiFi-Verbindung hergestellt werden konnte?
In dem Fall ist das LGW ein AP und es ist die aktuelle Sendeleistung von +31 dBm
Zitat von: AxelSchweiss am 29 Mai 2016, 13:46:34
Kannst du da mal ein Filmchen mit dem Handy vom Startvorgang des LGW machen ? :P
Ich beantworte mal eine Frage, bevor sie gestellt wird ;D ;D
Frage: warum läuft der Balken beim Start nicht bis ganz nach rechts?
Antwort: ganz rechts ist der Moment, an dem das LGW beschließt, dass es keinen Connect bekommt.
Je früher der Progress also weg ist, um so besser :)
Zitat von: HCS am 29 Mai 2016, 13:52:07
Dann ist das erklärte Ziel erreicht und ich kann Urlaub machen ;D
Ähm :o, wie jetzt schon? :D ;)
Zitat von: HCS am 29 Mai 2016, 13:52:07
Das sollte gehen.
set myJeeLink raw "OLED On"
set myJeeLink raw "OLED Off"
Die Anführungszeichen gehören mit dazu. Das ehemals mode=o gibt es nicht mehr.
OK, zu kompliziert gedacht, ich habe es mit
set myJeeLink raw "OLED mode=o"versucht.
P.S: Wenn ein Pin des MCP23008 als Output Pin defniert ist, dann sollte er mMn (mein use case) "LOW" sein. Aktuell führt das dazu, dass die LEDs an sind. Oder kann ich das default Verhalten ändern?
Zitat von: AxelSchweiss am 29 Mai 2016, 13:46:34
Kannst du da mal ein Filmchen mit dem Handy vom Startvorgang des LGW machen ? :P
Anbei ein Bild - sollte es gut genug veranschaulichen ;)
Danke.
Na das hat doch was ... ich versuch mich da jetzt auch mal.
Zitat von: amunra am 29 Mai 2016, 14:09:00
P.S: Wenn ein Pin des MCP23008 als Output Pin defniert ist, dann sollte er mMn (mein use case) "LOW" sein. Aktuell führt das dazu, dass die LEDs an sind.
Nanu, ist das nicht so? Eigentlich werden alle Outputs auf LOW initialisiert.
Zitat von: amunra am 29 Mai 2016, 14:13:49
Anbei ein Bild - sollte es gut genug veranschaulichen ;)
Ich macht mich echt neidisch auf so ein Display, ich muss mal schauen, wo ich so ein Teil herbekomme ;)
Zitat von: amunra am 29 Mai 2016, 14:09:00
P.S: Wenn ein Pin des MCP23008 als Output Pin defniert ist, dann sollte er mMn (mein use case) "LOW" sein. Aktuell führt das dazu, dass die LEDs an sind. Oder kann ich das default Verhalten ändern?
Ich kann es nicht ganz klar erkennen auf Deinem Bild, aber gehen die LEDs vom MCP nach +3.3V?
Der Plan ist, dass sie nach GND gehen.
Zitat von: PeMue am 29 Mai 2016, 15:09:21
Ich macht mich echt neidisch auf so ein Display, ich muss mal schauen, wo ich so ein Teil herbekomme ;)
Meins habe ich von hier
http://www.aliexpress.com/item/1pcs-0-96-white-0-96-inch-OLED-module-New-128X64-OLED-LCD-LED-Display-Module/32640136921.html (http://www.aliexpress.com/item/1pcs-0-96-white-0-96-inch-OLED-module-New-128X64-OLED-LCD-LED-Display-Module/32640136921.html)
Allerdings hat er jetzt die Anzeige verändert.
Wichtig ist das du auf der Rückseite den Adress-Selector hast.
Es gibt zwei Arten von den Displays : eins mit der gelben Zeile oben und eins das komplett in einer Farbe ist.
Ebenso gibt es einen Typ den du von SPI(3,4) auf I2C umstellen kannst.
Zitat von: HCS am 29 Mai 2016, 15:15:29
Der Plan ist, dass sie nach GND gehen.
Du hast ja vollkommen Recht :o Kaum macht man es richtig, schon funktioniert es! 8) Danke.
Wiki
amunra hat das Wiki für das LGW geschrieben und veröffentlicht. 8) 8) 8) 8)
Vielen Dank amunra.
Wer mal drin schmökert, wird zweifelsfrei feststellen, dass das eine Menge Arbeit war, all die Informrmationen zusammenzutragen und aufzubereiten.
Zu finden ist es hier: http://www.fhemwiki.de/wiki/LaCrosseGateway
Wenn es sich jemand anschaut und auf Verbesserungspotenzial stößt - amunra freut sich bestimmt über eine PM mit Anregungen ;)
Zitat von: HCS am 30 Mai 2016, 10:58:52
amunra hat das Wiki für das LGW geschrieben und veröffentlicht. 8) 8) 8) 8)
Vielen Dank amunra.
Wer mal drin schmökert, wird zweifelsfrei feststellen, dass das eine Menge Arbeit war, all die Informrmationen zusammenzutragen und aufzubereiten.
ich hab mal eben nur "kurz" geblättert und war Ewigkeiten damit beschäftigt. Auf jeden Fall war das jede Menge Arbeit. Respekt und danke! 8) 8) 8)
Hey, danke an HCS, der sein Projekt sehr gut im Forum Thread dokumentiert hat. Ich habe lediglich ,,Kosmetik Arbeit" betrieben (gut ich musste die 41(43) Seiten Thread reviewen, um alle Probleme und Fragestellungen aufzuzeigen und zu klären.).
Das Wiki ist groß geworden, und es erschlägt einen vielleicht, mir war wichtig das keine wichtigen Informationen verloren gehen und man diese im Wiki findet.
Entgegen der Empfehlung des Produktmanagements ;)!, mich persönlich zu kontaktieren, würde sich die im Moment im Arbeitsleben befindliche Doku Abteilung darüber freuen, wenn sich auch freiwillige mit einem FHEM Wiki Account (z.B Wzut - danke ;) ) bei der Pflege des Wiki's einbringen könnten. ;)
Zitat von: amunra am 01 Juni 2016, 22:17:00
(z.B Wzut - danke ;) )
np, ist IMHO schneller direkt ein paar Buchtstaben zu ändern als erst umständlich langatmige PMs zu schreiben :)
Hallo amunra,
habe gerade ein paar Schreibfehler korrigiert. Ich muss mir das Wiki noch mal in einer ruhigen Minute genauer anschauen, aber es ist echt toll geworden.
Für mich als Merker:
- ggf. Beschaltung USB-seriell Wandler mit reinnehmen
- nanoLGW Platine ist mittlerweile fertig ;) (zumindest das Layout, wird aber vermutlich dieses Wochenende bestellt) -> neues Bild
- ggf. die Variablen in Klammern (einheitlich machen)
define <myJeeLink> JeeLink <IP-Adresse>:81
- MDSN oder MDNS?
Gruß PeMue
Hallo PeMue,
danke, ich habe die Punkte entsprechend angepasst.
Viele Grüße
Moin,
ich hatte bisher einen BMP180 dran und den jetzt gegen einen BME280 getauscht. Habe den LGW mit 34h initialisiert, aber der Druck ist nur 669 HPa. Wäre hier im Flachland auch für ein Tiefdruckgebiet zu wenig ;-). Mit dem BMP180 waren es noch korrekte 1016 hPa.
Weiterhin frage ich mich, ob im state nicht 3 Werte stehen sollten, oder wie bekomme ich da den Druck dazu? Nachfolgend mal das List des 00 Sensors.
BTW, vielen Dank für das Wiki. Super umfangreich. Leider darf ich nicht editieren, drum der Hinweis, dass manchmal JeeLik statt JeeLink verwendet wird.
Internals:
DEF 00
IODev LGW2
LASTInputDev LGW2
LGW2_MSGCNT 45
LGW2_RAWMSG OK WS 0 4 4 209 59 255 255 255 255 255 255 255 255 0 2 157
LGW2_TIME 2016-06-04 17:35:46
LaCrosse_lastRcv 2016-06-04 17:35:46
MSGCNT 45
NAME LaCrosse_00
NR 94
STATE T: 23.3 H: 59
TYPE LaCrosse
addr 00
battery_new 0
bufferedH 59
bufferedT 23.3
corr1 0
corr2 0
previousH 59
previousT 23.3
sensorType 4=LaCrosseGateway
Readings:
2016-06-04 17:35:46 battery ok
2016-06-04 17:35:46 error 0
2016-06-04 17:35:46 humidity 59
2016-06-04 17:35:46 pressure 669
2016-06-04 17:20:30 state T: 23.3 H: 59
2016-06-04 17:35:46 temperature 23.3
Attributes:
IODev LGW2
room LaCrosse,Logs
Zitat von: BlackFlag am 04 Juni 2016, 18:30:57
Weiterhin frage ich mich, ob im state nicht 3 Werte stehen sollten, oder wie bekomme ich da den Druck dazu?
attr LaCrosse_00 stateFormat T: temperature H: humidity P: pressureDas war der einfache Teil.
Zitat von: BlackFlag am 04 Juni 2016, 18:30:57
ich hatte bisher einen BMP180 dran und den jetzt gegen einen BME280 getauscht. Habe den LGW mit 34h initialisiert, aber der Druck ist nur 669 HPa.
Hmmm, Ratlosigkeit. Eine Variante wäre ein defekter BME280.
Hast Du die Möglichkeit, mit irgend einem Arduino Sketch mal zu testen, was der BME280 liefert?
Sieht bei mir alles gut aus, ich bekomme mit 220h (mein tatsächliche Höhe) in FHEM 1015 hPa und mit Deinen 34h bekomme ich 993 hPa
Das passt beides so weit.
Zitat von: HCS am 04 Juni 2016, 20:20:25
Hmmm, Ratlosigkeit. Eine Variante wäre ein defekter BME280.
Hast Du die Möglichkeit, mit irgend einem Arduino Sketch mal zu testen, was der BME280 liefert?
Ich kann den bei Gelegenheit mal testen, ja. Seit Stunden liefert der BME die gleichen Werte. Besteht also tatsächlich die Möglichkeit, dass er kaputt ist. Wäre aber ein blöder Fehler. Immerhin wird er ja richtig erkannt.
Danke für die Hilfe und den Tipp.
Zitat von: HCS am 04 Juni 2016, 20:20:25
attr LaCrosse_00 stateFormat T: temperature H: humidity P: pressure
Das war der einfache Teil.
Muss man dazu fhem neustarten? Ich habe das Attribut gesetzt, fhem neugestartet, aber es ist nur T und P da, sehr seltsam ???
Zitat von: PeMue am 05 Juni 2016, 18:56:31
Muss man dazu fhem neustarten?
Nö, wenn ich das stateFormat ändere ändert sich bei mir das state unmittelbar.
zu dämlich, ich hatte das reading state und nicht den STATE angeschaut 8) 8) 8)
[Offtopic/Hinweis]
Falls jemand mit dem Gedanken spielt sich PCA 301 anzuschaffen, der sollte jetzt bei elv vorbeischauen, die gibt es nämlich jetzt im Angebot.
Viele Grüße
Ich habe leider kleine Unstimmigkeit beim Flashen.
Ich habe eben gerade ein Update von FHEM gemacht (so ist mal wieder alles auf dem aktuellen Stand).
Danach wollte ich das LGW von 1.18 auf 1.19 aktualisieren. Da ich im Wiki gelesen habe, das das alte OTA abgekündigt ist, wollte ich gleich die aktuelle Variante probieren, wie im Wiki beschrieben (super, das es das jetzt gibt und dann auch so ausführlich! - danke).
Also:
set LaCrosseGateway flash
Folgende Meldung: --> No firmware detected. Please use the firmwareName parameter
Unter /opt/fhem/FHEM/firmware habe ich gesehen, dass die FW jetzt JeeLink_LaCrosseGateway.bin heißt.
Neuer Versuch:
set LaCrosseGateway flash JeeLink_LaCrosseGateway.bin
Folgende Meldung: --> The file './FHEM/firmware/JeeLink_JeeLink_LaCrosseGateway.bin.hex' does not exist
"JeeLink_" ist doppelt und wird wohl automatisch eingefügt,
also 3. Versuch:
set LaCrosseGateway flash LaCrosseGateway.bin
Folgende Meldung: --> The file './FHEM/firmware/JeeLink_LaCrosseGateway.bin.hex' does not exist
Und das stimmt, das File ,,JeeLink_LaCrosseGateway.bin.hex" habe ich nicht (das ,,.hex" hätte ich auch schon beim 2. Versuch sehen können ;).
Hat jemand eine Idee?
LG
Holger
Zitat von: Omega am 07 Juni 2016, 10:51:54
Hat jemand eine Idee?
set LaCrosseGateway flash LaCrosseGatewayWenn das JeeLink device aktuell mit einem LGW verbunden ist, muss das automatisch erkannt werden und es auch ohne "firmwareName parameter" funktionieren.
Und die Meldung, wenn es den korrekten Mode verwendet, sollte so aussehen:
flashing JeeLink JeeLink212
detected Firmware: LaCrosseGateway.bin
hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
Mode is LaCrosseGateway OTA-update
Zitat von: HCS am 07 Juni 2016, 11:16:46
Wenn das JeeLink device aktuell mit einem LGW verbunden ist, muss das automatisch erkannt werden und es auch ohne "firmwareName parameter" funktionieren.
Kann ich bestätigen:
Mit dem Befehl:
set myJeeLink flashErhalte ich dieses Ergebnis:
flashing JeeLink myJeeLink
detected Firmware: LaCrosseGateway.bin
hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
Mode is LaCrosseGateway OTA-update
myJeeLink closed
target: http://x.y.z.123/ota/firmware.bin
Sketch reports:
Start receiving 'firmware.bin'
Firmware size: 395024
Rebooting ESP8266 ...
OTA update finished
myJeeLink opened EDIT: Schau dir mal die Rechte der Datei an - passt das?
Soeben hat ein einfaches
set LaCrosseGateway flash ausgereicht, um das LGW erfolgreich zu flashen - super.
Im Nachhinein kann ich nur eine Vermutung äußern..
ZitatWenn das JeeLink device aktuell mit einem LGW verbunden ist, muss das automatisch erkannt werden und es auch ohne "firmwareName parameter" funktionieren.
Mein LGW ist mit 2 FHEM-Instanzen verbunden. Manchmal sehe ich folgendes: in der einen Instanz ist das LGW im Status "initialized", in der anderen Instanz im Status "opened" (wenn ich mich richtig erinnere). Funktioniert hat es aber immer in beiden Instanzen trotz der unterschiedlichen Stati.
Heute morgen meine ich mich zu entsinnen, dass der Status zumindest nicht auf "initialized" stand und meine Probleme vermutlich darauf zurückzuführen sind.
Vor dem eben durchgeführten Update habe ich extra den Status kontrolliert, er stand auf "initialized" und damit hat dann alles - wie beschrieben - funktioniert.
Danke für die Unterstützung
Holger
Hallo HCS,
auf der Suche nach einem Vergleich zwischen dem RFM69W und dem RFM69HCW ist mir im Datenblatt aufgefallen, das beide einen Temperatur-Sensor enthalten sollen.
Ist hier im 44-seitigem Thread schon mal die Anfrage gekommen, den vielleicht auch zu nutzen?
LG
/robin
Zitat von: fh168 am 10 Juni 2016, 07:55:16
auf der Suche nach einem Vergleich zwischen dem RFM69W und dem RFM69HCW ist mir im Datenblatt aufgefallen, das beide einen Temperatur-Sensor enthalten sollen.
Ist hier im 44-seitigem Thread schon mal die Anfrage gekommen, den vielleicht auch zu nutzen?
Der liefert aber dann die Betriebstemperatur des RFM und sicher nicht die Raumtemperatur, in dem das LGW steht.
ist mir klar.. aber ich sage mal so. kostet doch nix, platz ist da und ob da ein Wert mehr oder weniger übertragen wird. Und wer weiß, wo diese Gateways verbaut sind.
ok, war nur nur eine Anmerkung.
Zitat von: fh168 am 10 Juni 2016, 08:23:09
... aber ich sage mal so. kostet doch nix
Doch doch, kostet vier Stunden Entwicklung zu einem Stundensatz von EUR 120,-
Ich lasse den Vertrieb mal ein Angebot erstellen ;D ;D ;D
Zitat von: HCS am 10 Juni 2016, 08:41:46
Doch doch, kostet vier Stunden Entwicklung zu einem Stundensatz von EUR 120,-
Ich lasse den Vertrieb mal ein Angebot erstellen ;D ;D ;D
Bitte die Dokumentation nicht vergessen, die dauert doppelt so lange und kostet das 1,5 fache ;D ;D ;D
Zitat von: PeMue am 10 Juni 2016, 11:15:20
Bitte die Dokumentation nicht vergessen, ...
Dokumentation? Kenne ich nicht. Könntest Du das bitte etwas erläutern? ;D ;D
Zitat von: HCS am 10 Juni 2016, 12:15:44
Dokumentation? Kenne ich nicht. Könntest Du das bitte etwas erläutern? ;D ;D
Das ist das was die anderen so und so nicht verstehen :D
Mobil erstellt daher kurz gehalten
Hallo HCS,
ich würde gern an den I2C-Bus des LGW einen DS2482 (1-Wire Busmaster) anschließen. Könnest Du dafür noch eine Serial-Bridge implementieren?
Dann steht dem LGW noch die große Welt des 1-Wire zur Verfügung.
Gruß
kohlenmacher
Zitat von: kohlenmacher am 14 Juni 2016, 08:41:44
ich würde gern an den I2C-Bus des LGW einen DS2482 (1-Wire Busmaster) anschließen. Könnest Du dafür noch eine Serial-Bridge implementieren?
Kannst Du das etwas genauer erläutern, wie Du Dir das vorstellst?
Zitat von: HCS am 14 Juni 2016, 09:03:27
Kannst Du das etwas genauer erläutern, wie Du Dir das vorstellst?
Ähnlich der seriellen Schnittstelle des SC16IS750. Über einen TCP Port connectet sich ein Client direct mit dem 1-Wire Busmaster. Als Client kommt z.B. das Modul OWX_Async von FHEM in frage.
Du müsstest nur die Daten zum Busmaster weiterleiten und die Antwort zurück zum Client.
Mit https://github.com/jeelabs/esp-link (https://github.com/jeelabs/esp-link) und einem DS2480 (der hat eine serielle Schnittstelle anstatt I2C) habe ich das schon mal zum Laufen gebracht.
Gruß
kohlenmacher
Zitat von: kohlenmacher am 14 Juni 2016, 18:07:16
Mit https://github.com/jeelabs/esp-link (https://github.com/jeelabs/esp-link) und einem DS2480 (der hat eine serielle Schnittstelle anstatt I2C) habe ich das schon mal zum Laufen gebracht.
Dann müsste es doch gehen, den DS2480 an die serielle Schnittstelle des SC16IS750 zu hängen und gut ist?
Zitat von: HCS am 17 Juni 2016, 08:56:24
Dann müsste es doch gehen, den DS2480 an die serielle Schnittstelle des SC16IS750 zu hängen und gut ist?
Habe ich mir auch schon überlegt. Da ich den SC16IS750 aber sonst nicht brauche ...
Bin da Minimalist, nur das rein was benötigt wird. Und zusätzlich eine Fehlerquelle weniger in der Kette.
Zitat von: kohlenmacher am 17 Juni 2016, 11:54:08
Bin da Minimalist, nur das rein was benötigt wird.
So betrachte ich das beim Software-Schreiben auch ;D ;D ;D
Ich sehe da ein wesentliches Thema: der DS2482 hat irgend ein Protokoll auf dem I2C Bus und das muss irgendwie auf seriell über TCP umgesetzt werden.
Also eigentlich softwaretechnisch aus einem DS2482 einen DS2480 machen.
Und genau das ist mir aktuell völlig unklar, was da zu tun wäre.
Moin,
gibt's nen besonderen Trick, um die PCA301 anzulernen?
Irgendwie klappt das bei mir nicht...
Radio#4 ist für PCA301 initialisiert: 4,868950,120i
Autocreate ist on.
Zum Anlernen drücke ich die Taste an der PCA301 für 3 sec, bis die Lampe blinkt.
Es wird aber kein Device angelegt.
Versucht habe ich es auch mit anderen Frequenzen: 868950, 868960 und 960970.
Was könnte ich noch versuchen?
4,868950,120i v
4 ist richtig? Sonst auch mal mit einem anderen Radio versuchen.
Zitat von: StefanW am 19 Juni 2016, 06:26:18
Was könnte ich noch versuchen?
Schau mal auf der setup page vom LGW, ob bei "Plugs" die PCA eingetragen wurde.
Da muss etwas in der Art drin stehen: 03A094=1
Voraussetzung ist erst mal, dass das LGW die PCA gelernt hat.
Wenn das der Fall ist, muss sie nicht nochmal durch "lang Taste drücken" neu angelernt werden sondern sollte eigentlich bei einem manuellen Schaltvorgang and der Dose in FHEM dann angelegt werden.
Zitat von: amunra am 19 Juni 2016, 08:48:15
4,868950,120i v
4 ist richtig? Sonst auch mal mit einem anderen Radio versuchen.
Hmpf, da hätte ich auch selbst drauf kommen können...
Radio #2 genommen und es klappt auf Anhieb.
Anscheinend funktioniert Radio #4 nicht richtig, da ich damit auch keine LaCrosse-Sensoren empfange...
Mal auf Fehlersuche gehen.
Vielen Dank!
Hallo HCS,
kann es sein, dass im Quelltext der v1.19 die Datei KVPSensors.h fehlt?
Danke + Gruß
PeMue
Zitat von: PeMue am 28 Juni 2016, 08:49:49
kann es sein, dass im Quelltext der v1.19 die Datei KVPSensors.h fehlt?
Die Datei sagt mir absolut nichts. Was bringt Dich zu dieser Annahme?
Zitat von: HCS am 28 Juni 2016, 08:57:16
Die Datei sagt mir absolut nichts. Was bringt Dich zu dieser Annahme?
Sorry, war mein Fehler. Ich hatte zu viele verschiedene Projekte gleichzeitig offen >:(
Ich suche gerade, wo Du das KeyValueProtocol zusammenbaust ...
Zitat von: PeMue am 28 Juni 2016, 09:07:01
Ich suche gerade, wo Du das KeyValueProtocol zusammenbaust ...
String StateManager::GetKVP(bool full)
Hallo zusammen,
ich möchte den Thread eigentlich nicht noch weiter durcheinander bringen, aber bei 45 Seiten ändert das bestimmt auch nichts mehr. 8)
Nachdem ich mich knapp 2 Tage mit dem LGW beschäftigt habe, hängt mir immer noch die Kinnlade runter! Eure Arbeit ist echt klasse!!!
Eine Frage hätte ich: Besteht die Möglichkeit, die 8 Output-PINs des MCP23008 als HIGH (anstatt LOW) zu initialisieren?
Ideal wäre natürlich eine Wahlmöglichkeit auf der Setup-Seite, bspw. in der Dropdown-Box als "Output-Low" oder "Output-High".
Viele Grüße
Timo
Zitat von: timo74 am 28 Juni 2016, 22:01:13
Ideal wäre natürlich eine Wahlmöglichkeit auf der Setup-Seite, bspw. in der Dropdown-Box als "Output-Low" oder "Output-High".
Ich nehme es mal auf die Wunschliste, aber erst muss jetzt endlich das Display mal fertig werden, dann rückt das hier weiter nach vorne.
Wenn ich in zwei Wochen endlich Urlaub habe, dann habe ich hoffentlich mehr Zeit ...
Stabil und lange kann es schon, wenn es will 8)
2,6 Millionen empfangene Frames :)
Guten Abend ;)
Ich habe mir 3 PCA301 geholt, die ich gerne vom Raspberry aus steuern würde. Hier ist mein (derzeitiger) Stand jetzt jedoch, dass es mit dem JeeLink v3c (RFM69CW-Chip) nicht kompatibel ist. -> Zu wenig belesen und zu früh gefreut. (Status ist "opened" statt "Initialized" nach dem Flashen)
Darüber hinaus wollte ich gerne noch LaCrosse Sensoren in Betrieb nehmen. Diese Funktionieren an dem JeeLink auch wie gewünscht.
Nun war ich am Überlegen, was am sinnigsten ist um auch die Steckdosen abfangen zu können und bin leider erst jetzt auf das LGW gestoßen.
Ich habe mich hier die Tage dann mal belesen und wollte nun mal meine offenen Fragen loswerden:
- Man kann ja bis zu 3 RFM69CW anschließen -> Heißt man muss demnach den LGW in meinem Fall 2x als "JeeLink" definieren und unterschiedlich flachen, 1x LaCrosse & 1x PCA301 -> Hab ich mir selbst gerade durch den super Eintrag im Wiki beantworten können.
- Sind die PCA301 nun doch mit dem RFM69CW kompatibel? Der RFM12 wurde hier ja in der 1.16 rausgeworfen.
- Werden die Geräte (LaCrosse & PCA301) dann unter einem IODEV z.B. "JeeLink" Device im FHEM verbunden? Und man muss über die entsprechenden attr dann festlegen, über welchen RFM69CW er was ansprechen soll?
Vielen Dank schonmal für die Antworten und entschuldigt die zu blöden Fragen, aber ich wollte vermeiden nochmal umsonst was zu kaufen ;)
Zitat von: Hagenuck1 am 01 Juli 2016, 18:23:04(Status ist "opened" statt "Initialized" nach dem Flashen)
Hast Du es auf der Setup page konfiguriert und in FHEM entsprechend eingerichtet?
Zitat von: Hagenuck1 am 01 Juli 2016, 18:23:04
- Sind die PCA301 nun doch mit dem RFM69CW kompatibel? Der RFM12 wurde hier ja in der 1.16 rausgeworfen.
Das LGW unterstützt den RFM69 und kann damit auch PCA301.
Der PCA301-Sketch für den JeeLink kann nur RFM12.
Das hat nichts mit PCA301 und RFM12 oder 69 kompatibel zu tun, sondern hängt davon ab, für welchen RFM die Software geschrieben wurde.
Zitat von: Hagenuck1 am 01 Juli 2016, 18:23:04
- Werden die Geräte (LaCrosse & PCA301) dann unter einem IODEV z.B. "JeeLink" Device im FHEM verbunden? Und man muss über die entsprechenden attr dann festlegen, über welchen RFM69CW er was ansprechen soll?
Man hat ein LaCrosse Gateway, das man über die initCommands konfiguriert, was die angeschlossenen RFMs jeweils machen sollen.
An FHEM ist es über ein (genau nur eines) JeeLink Device angebunden, das die Daten dann an die nachgelagerten Module (PCA301, LaCrosse, ...) verteilt.
Hallo HCS,
ich betreibe zwei LGWs - eines mit RFM69 für meine EC3000, eines mit BMP180 für Outdoor.
Folgende (kosmetischen) Kleinigkeiten sind mir bisher aufgefallen:
° Das BMP180 LGW zeigt mir "Received Frames: 0" auf der Homepage an, obwohl es munter Daten an den Server liefert.
° Im Setup, Hostname werden illegale Zeichen nicht abgefangen (:, etc), sollte auf [0-9a-zA-Z-_] begrenzt werden...
Ich hätte noch zwei Vorschläge für die Erweiterung der Homepage:
a) Hostname im Kopf anzeigen (a la "LaCrosseGateway 1.xx - LGW-Meteo")
b) die erkannten Module (BMP180, RFM69) anzeigen
Zitat von: SusisStrolch am 05 Juli 2016, 13:42:48
° Das BMP180 LGW zeigt mir "Received Frames: 0" auf der Homepage an, obwohl es munter Daten an den Server liefert.
"Received Frames" ist die Anzahl Datenpakete, die von den Radios empfangen, checksummengeprüft und an FHEM weitergeleitet werden.
Ein LGW ohne Radios empfängt nichts, somit ist das immer Null.
Zitat von: SusisStrolch am 05 Juli 2016, 13:42:48
Im Setup, Hostname werden illegale Zeichen nicht abgefangen (:, etc), sollte auf [0-9a-zA-Z-_] begrenzt werden...
Ja, mit der Validierung hat es die Setup-Page nicht so sehr :(
-> ToDo-Liste
Zitat von: SusisStrolch am 05 Juli 2016, 13:42:48
a) Hostname im Kopf anzeigen (a la "LaCrosseGateway 1.xx - LGW-Meteo")
Meinst Du im Header aller Seiten des Frontends, also so wie das Menü?
Oder als Seitentitel (also im Tab des Browsers)?
Zitat von: SusisStrolch am 05 Juli 2016, 13:42:48
b) die erkannten Module (BMP180, RFM69) anzeigen
Der Punkt ist schon auf der ToDo-Liste drauf und wartet geduldig, bis seine Prio ausreicht, dass er endlich berücksichtigt wird.
Der Plan ist eine "Hardware"-Page, die das auflistet.
Zitat von: HCS am 05 Juli 2016, 18:01:19
"Received Frames" ist die Anzahl Datenpakete, die von den Radios empfangen, checksummengeprüft und an FHEM weitergeleitet werden.
Öhem... da habe ich nicht mitgedacht... :o Macht Sinn!
Zitat von: HCS am 05 Juli 2016, 18:01:19
Meinst Du im Header aller Seiten des Frontends, also so wie das Menü?
Oder als Seitentitel (also im Tab des Browsers)?
Beides wäre natürlich optimal. Primär dachte ich nur an den Seiten-Header der Homepage.
Zitat von: HCS am 05 Juli 2016, 18:01:19
Der Plan ist eine "Hardware"-Page, die das auflistet.
Hier gilt das Gleiche bei meiner Überlegung - einfach eine Zeile auf der Homepage, wie sie auch bei "v" zurück geliefert wird, so dass man einen schnellen Überblick hat. Eine Hardware-Seite ist natürlich optimal.
Nach langer Zeit habe ich wieder ein Phantomgerät (PCA301) im LGW.
Auf der Setup-Seite unter Plugs steht:
03604B=1,03A1F9=2,04412E=3,0451AE=3,44412E=3
Der letzte Eintrag (44412E=3) ist falsch - ähnelt verblüffend dem 3. Eintrag.
Ich vermute mal: einfach löschen und gut - frage aber doch lieber einmal zuviel ;)
LG
Holger
Zitat von: Omega am 11 Juli 2016, 11:18:51
Ich vermute mal: einfach löschen und gut
Genau
V1.20
Setup page
Für Hostname werden nun nur noch die Zeichen 0-9, a-z, A-Z, - und _ akzepiert
Hostname im Frontend
Im Frontend wird nun oben der Hostname des LGW und die IP-Adresse angezeigt.
Der Seitentitel (was auf dem Browser-Tab erscheint) wurde ebenfalls angepasst.
Display Status im KVP
Der Status vom Display (an/aus) wird im KVP an FHEM übermittelt (OLED=on)
Display on/off
"OLED On" und "OLED Off" ist nun nicht mehr case sensitiv
OLED start Modus
Einstellungsmöglichkeit ("Config"-Page) wie sich das OLED nach einem Start verhalten soll
Option: on / off / Anzahl Sekunden, nach denen es aus geht
Display-Statuszeile
Wenn sich FHEM vom DataPort oder der Serial-Bridge des LGW disconnectet, werden die Icons im Diplay nun auch wieder weggenommen
OTA-Update NanoCUL
Ein an die Serial-Bridge angeschlossener Arduino, also z.B. auch ein NanoCUL, kann nun ohne Baudratenänderung usw. per OTA geflasht werden.
Display
Das Display ist nun mehr oder weniger komplett implementiert.
Hier noch mal die Features:
Auf der Setup-Page kann für die Ports des MCP23008 nun bezüglich Display folgendes Konfiguriert werden:
OLED On, OLED Off, OLED mode=s, OLED mode=t, OLED mode=th, OLED mode=thp
Das Display kann folgende Seiten anzeigen:
t: Temperatur des internen Sensors
h: Feuchte des internen Sensors
p: Druck des internen Sensors
s: Statuswerte des LGW
f: von FHEM gesetzter Text
Mögliche Symbole:
t: Temperature
h: Humidity
p: Pressure
s: System
i: Info
w: Warning
e: Error
Beispiele:
set JeeLink212 raw "OLED On"
Schaltet das Display ein
set JeeLink212 raw "OLED Off"
Schaltet das Display aus
set JeeLink212 raw "OLED interval=20"
Legt fest, dass (je nach mode) alle 20 Sekunden die nächste Seite angezeigt wird.
Wenn Mode z.B. "thp" ist, dann wird 20 Sekunden Temperatur, dann 20 Sekunden Feuchte, dann 20 Sekunden Luftdruck, dann 20 Sekunden Temperatur, dann ...
set JeeLink212 raw "OLED mode=ths"
Zeigt nacheinander Temperatur, Feuchte und Systemdaten an
set JeeLink212 raw "OLED mode=thp"
Zeigt nacheinander Temperatur, Feuchte und Luftdruck an
set JeeLink212 raw "OLED mode=f"
Zeigt ausschließlich den von FHEM festgeleget Text an
set JeeLink212 raw "OLED mode=s"
Zeigt ausschließlich die Systemdaten an
set JeeLink212 raw "OLED show=Soll: 20.5,Ist: 19.2,,t"
Zeigt die übergebenen Texte an und links das Symbol für Temperatur
set JeeLink212 raw "OLED show=55%,,,h"
Zeigt nur den Text "55%" und das Symbol für Feuchte an
Da es nur ein Text ist, wird er größer dargestellt
set JeeLink212 raw "OLED show=Line 1,Line 2,Line 3"
Zeigt drei Texte aber kein Symbol an.
Es ist kaum möglich, alle Kombinationen hier darzstellen. Einfach etwas experimentieren, dann merkt man schnell, was es kann und macht.
Generell: OLED show kann bis zu drei Texte und optional ein Symbol.
Texte können auch weggelassen werden (z.b. "show=Hallo,,,i" zeigt "Hallo" und ein info-Symbol an)
Ist eingecheckt, sollte dann heute Nacht mit dem FHEM-Update ausgeliefert werden.
Zum Glück gibt es den HCS-Sommer
Zitat von: amunra am 13 Juli 2016, 21:56:19
Zum Glück gibt es den HCS-Sommer
Ein Sommermärchen ;D ;D
Der Beschreibung nach eher etwas greifbarer....;D
Klingt gut HCS! Ich muss nun nur noch 4 Wochen warten bis die Chinateile ankommen :(
Apropos NanoCul. Ein Betrieb von CUL am LGW ist dann dadrüber möglich oder kann der Chip auch anders angesteuert werden?
Gesendet von iPhone mit Tapatalk
Zitat von: Hagenuck1 am 14 Juli 2016, 11:12:54
Apropos NanoCul. Ein Betrieb von CUL am LGW ist dann dadrüber möglich oder kann der Chip auch anders angesteuert werden?
Man benötigt einen SC16IS750 und einen NanoCUL (also Arduino + CC1101).
Zitat von: HCS am 14 Juli 2016, 11:15:28
Man benötigt einen SC16IS750 und einen NanoCUL (also Arduino + CC1101).
Naja, eher das Modul mit dem SC16IS750, alleine funktioniert der nicht (da fehlt der Quarz) ;)
Zitat von: PeMue am 15 Juli 2016, 08:05:53
Naja, eher das Modul mit dem SC16IS750, alleine funktioniert der nicht (da fehlt der Quarz) ;)
Haste da zufällig mal nen Link für mich? Hatte nach dem Chip schon gesucht, aber beim Ali immer nur die Chips in sonst was für Stückzahlen gefunden ;) den müsste man dann aber auf ner extra Lochraster aufbauen oder? Hatte da auf deiner Platine noch nichts passendes zu gesehen.
Gibt's für den NanoCUL von irgendjemandem hier nicht auch ne Platine? Habe die Tage mal gesucht, aber so ganz erfolgreich war ich nicht.
Gesendet von iPhone mit Tapatalk
Nicht 100%ig gecheckt - aber http://www.aliexpress.com/item/IIC-SPI-to-serial-convert-SC16IS750-I2C-SPI-to-UART51-code-module/32693869330.html?ws_ab_test=searchweb201556_7,searchweb201602_1_10057_10056_10055_10049_10017_405_404_407_10058_10040,searchweb201603_4&btsid=956e0559-aa11-4bc8-bc5b-cc1f6865a09f könnte ggf helfen ;)
Kurzes Feedback zu V.1.20 - 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) (Soll heißen: ,,der absolute Hammer!")
DANKE HCS für deine Arbeit!
Ein paar Anmerkungen folgen...
Anbei mein LGW bestehend aus - LaCrosseGateway Platine (PeMue) + BME280 + OLED + 2 x RFM69CW + GIRA System 55 + MCP23008 (LED-Anzeige inkl. push buttons (Auf die ich ca. 2 Monate gewartet habe - Fast auch schon vergessen wofür ich die verwenden wollte - und heute geliefert wurden)) – ein paar Infos und Demo folgen im Display Thread.
Zitat von: Hagenuck1 am 15 Juli 2016, 19:18:44
Gibt's für den NanoCUL von irgendjemandem hier nicht auch ne Platine? Habe die Tage mal gesucht, aber so ganz erfolgreich war ich nicht.
8) 8) 8) Das sind die iPhones mit den Mickerdisplays 8) 8) 8)
ja, hier https://forum.fhem.de/index.php/topic,38561.msg313605.html#msg313605
Oder Du wartest auf die Erweiterungsplatine für die LGW Platine ...
Gruß PeMue
Edit: den Thread zur LGW Platine findest Du auch in der Bastelbude ;)
Zitat von: PeMue am 16 Juli 2016, 12:35:24
Oder Du wartest auf die Erweiterungsplatine für die LGW Platine ...
Gruß PeMue
Edit: den Thread zur LGW Platine findest Du auch in der Bastelbude ;)
Das klingt nach dem sinnigsten Plan, hatte das in dem Thread von dir mit der Platine entweder überlesen oder wieder vergessen ;) bei der Platine bräuchte man dann weiterhin einen Arduino oder ist geplant den Sender direkt per ESP8266 auf der LGW Platine anzusprechen?
Gesendet von iPhone mit Tapatalk
Zitat von: Hagenuck1 am 16 Juli 2016, 15:12:53
Das klingt nach dem sinnigsten Plan, hatte das in dem Thread von dir mit der Platine entweder überlesen oder wieder vergessen ;) bei der Platine bräuchte man dann weiterhin einen Arduino oder ist geplant den Sender direkt per ESP8266 auf der LGW Platine anzusprechen?
Hier https://forum.fhem.de/index.php/topic,45594.msg451267.html#msg451267 sind mal die ersten Ideen gesammelt.
Zitat von: HCS am 13 Juli 2016, 21:41:05
V1.20
OTA-Update NanoCUL
Ein an die Serial-Bridge angeschlossener Arduino, also z.B. auch ein NanoCUL, kann nun ohne Baudratenänderung usw. per OTA geflasht werden.
Könntest du das bitte noch mal kurz erläutern, wie ich den nanoCUL nun flashen kann?
Ich habe keine Doku dazu gefunden.
Gruß
Stefan
... wenn ich das richtig verstanden habe, nimmst Du den Port des LGW als serielle Schnittstelle, die Einstellung ist vermutlich 57600 baud. Sprich Du machst einen CULflash nicht über z.B. /dev/ttyUSB0 sondern halt über die IP Adresse bzw. den entsprechenden Port.
Gruß PeMue
Edit: siehe unten ;)
Zitat von: StefanW am 16 Juli 2016, 17:01:48
Könntest du das bitte noch mal kurz erläutern, wie ich den nanoCUL nun flashen kann?
Ich habe keine Doku dazu gefunden.
Gibt ja auch keine :(
Geschieht per upload auf das LGW, z.B. mit curl
curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@.\nanoCUL.hex; filename=addon.hex" http://192.168.31.212/ota/addon.hexDas LGW nimmt den upload entgegen und flasht ihn auf den arduino drauf.
Falls ein OLED angeschlossen ist, wird sogar ein progress angezeigt.
Der Ablageort des CUL hex files (.\nanoCUL.hex) und die IP-Adresse (192.168.31.212) muss angepasst werden, der Pfad hinten raus (/ota/addon.hex) bleibt immer wie er ist.
Muss nicht unbedingt curl sein, alles was einen multipart formdata upload kann geht auch.
Falls man mit linux auf Kriegsfuß steht, curl gibt es auch für windows.
Muss auch nicht unbeding CUL sein.
Jedes gültige Intel-Hex wird aktzeptiert, in binary umgewandelt und per STK500-Protokoll an den Arduino geliefert.
Es muss nirgends irgend eine baud rate ein-/umgestellt werden. Die 38400 oder was auch immer, die man evtl. im frontend eingestellt hat, können bleiben.
Danke!
Hat funktioniert. :)
@HCS ich hatte da nochmal ne kurze Frage. Auf deinem Breakboard hast du die RFM69 auf einer Breakout Platine mit 2,54er abständen aufgelötet. Ich habe schon überall gesucht, kann die aber nirgends finden. Kannst du da den entscheidenden Tipp geben? ;) ich würde es nämlich gerne solange die Bestellung für die Platinen noch nicht fertig ist schonmal so aufbauen ;)
Gesendet von iPhone mit Tapatalk
Zitat von: Hagenuck1 am 21 Juli 2016, 08:52:10
Ich habe schon überall gesucht, kann die aber nirgends finden. Kannst du da den entscheidenden Tipp geben? ;)
Gehe hier im Thread zurück auf Posting #365 von HCS , findest du :
http://www.ebay.co.uk/itm/RFM12B-RFM69-Breakout-Board-PCB-board-only-3-3Volt-/141890306429
@Hagenuck1
ich habe die Breakout Platine hier bestellt
http://www.digitalsmarties.net/products/rfm-board (http://www.digitalsmarties.net/products/rfm-board)
Gruß
trebron106
Danke für die schnellen Antworten :)
Habe die aus dem Link von Wzut nun bestellt. 4€ irgendwas gehen bei zwei Stück vorerst ja auch klar.
Der Link könnte eventuell ja auch im Wiki ergänzt werden, da fällt einem das unter Hardware dann ja direkt ins Auge.
Gesendet von iPhone mit Tapatalk
Die Doku-Abteilung hat mal wieder gearbeitet und mehr oder weniger ;) die V 1.20 dokumentiert (http://www.fhemwiki.de/wiki/LaCrosseGateway).
Ach,
Zitat von: StefanW am 16 Juli 2016, 17:01:48
Könntest du das bitte noch mal kurz erläutern, wie ich den nanoCUL nun flashen kann?
Ich habe keine Doku dazu gefunden.
Zitat von: HCS am 16 Juli 2016, 18:09:53
Gibt ja auch keine :(
Eigentlich schon, und zwar hier (http://www.fhemwiki.de/wiki/LaCrosseGateway#SubProzessor) ;) - oder fehlt etwas?.
Viele Grüße
Zitat von: amunra am 21 Juli 2016, 22:11:53
Die Doku-Abteilung hat mal wieder gearbeitet und mehr oder weniger ;) die V 1.20 dokumentiert (http://www.fhemwiki.de/wiki/LaCrosseGateway).
Super.
Zitat von: amunra am 21 Juli 2016, 22:11:53
Ach,Eigentlich schon, und zwar hier (http://www.fhemwiki.de/wiki/LaCrosseGateway#SubProzessor) ;) - oder fehlt etwas?.
Viele Grüße
Es fehlt eigentlich nichts aber es ist unter "SubProzessor" beschrieben.
Da es hier um die "Serial transparent bridge" geht, wurde es vermutlich nicht gefunden.
Evtl. würde bei "Serial transparent bridge" ein Hinweis, dass das OTA Update das gleiche wie das vom SubProzessor ist und ein Link dort hin helfen.
Zitat von: Hagenuck1 am 21 Juli 2016, 17:28:51
Habe die aus dem Link von Wzut nun bestellt. 4€ irgendwas gehen bei zwei Stück vorerst ja auch klar.
Da sieht man mal, was die PeMue-Platine für einen Schnäppchenpreis hat 8) ;D
Zitat von: HCS am 21 Juli 2016, 22:36:27
Da sieht man mal, was die PeMue-Platine für einen Schnäppchenpreis hat 8) ;D
Aber sowas von! Wobei der Händler da bestimmt ne Menge Gewinn pro Platine mit macht und PeMue und alle anderen hier ja so nett sind es in ihrer Freizeit zu machen :)
Gesendet von iPhone mit Tapatalk
Zitat von: HCS am 21 Juli 2016, 22:36:27
Es fehlt eigentlich nichts aber es ist unter "SubProzessor" beschrieben.
Da es hier um die "Serial transparent bridge" geht, wurde es vermutlich nicht gefunden.
Evtl. würde bei "Serial transparent bridge" ein Hinweis, dass das OTA Update das gleiche wie das vom SubProzessor ist und ein Link dort hin helfen.
Verstehe - ich habe es mal angepasst.
Ich glaube, dass ich mir auch mal einen SC16IS750 organisieren muss :)
Anbei Bild zu meinen Erfahrungen mit dem LaCrosseGateway im Zusammenhang mit dem PCA 301.
Hintergrund.
Überwachung der Gartenpumpen über Verbrauchswerte mit PCA 301
Die Pumpen laufen ca. 30 sec zur Zisternenspeisung bzw. Hauswasservbersorgung.
Diese Überwachung geht mit dem LGW (3 RFM69) nicht! War auch zu vermuten da das LGW ja auch mehr zu tun hat.
Siehe auch Anlage.
Mit dem Original Jeelink und dem PCA Sketch geht das problemlos.
Wollte die Erfahrung nur mal teilen, falls von Interesse.
Der Jeelink wird also für diesen Zweck nicht in Rente geschickt. ;)
Billy
Zitat von: Billy am 23 Juli 2016, 09:07:22
Die Pumpen laufen ca. 30 sec zur Zisternenspeisung bzw. Hauswasservbersorgung.
Diese Überwachung geht mit dem LGW (3 RFM69) nicht! War auch zu vermuten da das LGW ja auch mehr zu tun hat.
Siehe auch Anlage.
Mit dem Original Jeelink und dem PCA Sketch geht das problemlos.
Dann muss ich mal untersuchen, warum das nicht geht. Evtl. ist es ja hinzubekommen.
Zitat von: HCS am 24 Juli 2016, 22:10:37
Dann muss ich mal untersuchen, warum das nicht geht. Evtl. ist es ja hinzubekommen.
Das wäre super. Ich teste mal ab welcher minimaler Schaltzeit das bei mir auftritt.
Billy
@HCS
So jetzt mal das Ergebnis wenn sich ein Verbraucher mit 60W alle 5 Minuten für 2 Min einschaltet.
LGW reagiert jetzt häufiger aber nicht befriedigend.
Siehe Anlage.
Billy
Zitat von: Billy am 25 Juli 2016, 15:05:57
So jetzt mal das Ergebnis wenn sich ein Verbraucher mit 60W alle 5 Minuten für 2 Min einschaltet.
Wie hast Du denn PCA301 eigentlich initialisiert?
Die Dosen senden ja nicht freiwillig, sie müssen gepollt werden.
Falls Du die Initialisierung, die z.B. im Wiki beschrieben ist, verwendest, also
1,868950,120idann bedeutet das, dass die Dosen alle 120 Sekunden gepollt werden. Damit verpasst man natürlich öfter mal so kurze Einschaltzeiten.
1,868950,30i oder so in der Art wäre dann mal einen Versuch wert.
-> Abtasttheorem, Nyquist, Shannon usw.
Kennt jemand die Poll-Rate des JeeLink-PCA-Sketch?
Mea culpa,
da habe ich geschlafen. habe natürlich mit 1,868960,120i initialisiert.
Werde ich mal auf 1,868960,30i setzen.
ZitatKennt jemand die Poll-Rate des JeeLink-PCA-Sketch?
Soweit ich mich erinnere ist die hart auf 30 sec gesetzt. Aber Andre müsste das genauer wissen.
Billy
Ich habe einen Wunsch: :D
Nach einem Stromausfall ist das LGW (naturgemäß) schneller wieder oben als der Router, mit dem es sich verbinden soll.
Das führt leider dazu, dass gar keine Verbindung mehr zustande kommt (das Attribut timeout habe ich mit 120,60 definiert) – auch dann nicht, wenn der Router schon lange wieder bereit ist.
Im Systemlog habe ich dann seitenweise folgende Meldungen:
2016.07.26 08:33:48 3: Opening LaCrosseGateway device 192.168.0.28:81
2016.07.26 08:33:51 3: Can't connect to 192.168.0.28:81: Connection timed out
d.h., das LGW versucht zwar immer, sich zu verbinden, scheitert aber leider aus mir nicht bekannten Gründen.
Ich muss dann das LGW kurz stromlos machen. Danach funktioniert wieder alles ohne weitere Eingriffe.
Meine Idee: Ein Configparameter, bei dem eine Verzögerung (in Sekunden) definiert werden kann, bis dass LGW nach einen Neustart einen 1. Verbindungsversuch startet. So könnte ich sicherstellen, dass das Umfeld bereit ist, bevor das LGW ,,loslegt".
LG
Holger
Ich stelle mal ganz vorsichtig ein Feature-Request:
,,Eine Möglichkeit das LGW in einem reinen Transparent Bridge Mode ohne einen SC16IS750 zu betreiben."
Anforderungen:
- Die Serielle-Kommunikation eines an einen entsprechenden Port angeschlossenen Device durchzureichen.
- USB und WLAN Betrieb
- Web-Frontend (SSID, PW, Baud-Rate etc.)
- [Optional] OTA-Firmware-Update (nur für das LGW)
- ich hoffe ich habe nichts vergessen ;)
Einschränkungen (die in Kauf genommen werden):
- Kein MCP23008
- kein SC16IS750
- Keine RFM69CW's
- Kein BME/BMP
- Kein OLED (ok, vielleicht aber kein muss)
- Keine bisher von LGW unterstützte HW
@HCS: Meinst Du, dass so ein Modus mit LGW denkbar wäre? :D
Zitat von: Omega am 26 Juli 2016, 09:32:39
Ich habe einen Wunsch: :D
Nach einem Stromausfall ist das LGW (naturgemäß) schneller wieder oben als der Router, mit dem es sich verbinden soll. ...
Ja, es ist echt rasend schnell ... 8) ;D ;D
Ich denke, dass da folgendes passiert: Das LGW versucht nach dem Starten 15 Sekunden lang eine Verbindung zum konfigurierten AP aufzubauen. Wenn innerhalb dieser 15 Sekunden der AP irgendwann erreichbar wird, verbindet es sich. Wenn nicht, macht es seinen eigenen AP auf, dass man es konfigurieren kann. Und die 15 Sekunden reichen nicht, da Dein AP wohl länger braucht.
Zitat von: Omega am 26 Juli 2016, 09:32:39
Im Systemlog habe ich dann seitenweise folgende Meldungen:
2016.07.26 08:33:48 3: Opening LaCrosseGateway device 192.168.0.28:81
2016.07.26 08:33:51 3: Can't connect to 192.168.0.28:81: Connection timed out
d.h., das LGW versucht zwar immer, sich zu verbinden, scheitert aber leider aus mir nicht bekannten Gründen.
Nicht das LGW versucht sich zu verbinden sondern FHEM versucht sich auf das LGW zu verbinden.
Der Grund, warum das nun nicht geht ist klar: Das LGW konnte sich nicht mit dem wlan verbinden, also kann FHEM sich auch nicht mit dem LGW verbinden.
Zusammenfassung: das Problem ist, dass das LGW nach 15 Sekunden aufgibt und (dauerhaft) beschließt, dass es sich nicht mit dem wlan verbinden kann und der AP innerhalb der 15 Sekunden nicht betriebsbereit ist.
Ich könnte die Zeit (die 15 Sekunden) konfigurierbar machen, dass man das LGW z.B. 60 Sekunden probieren lassen kann.
Wenn man allerdings neu konfigurieren will, muss man dann halt 60 Sekunden warten, bis das LGW aufgibt und seinen eigenen AP auf macht.
Zitat von: HCS am 26 Juli 2016, 20:40:04
Ich könnte die Zeit (die 15 Sekunden) konfigurierbar machen, dass man das LGW z.B. 60 Sekunden probieren lassen kann.
Wenn man allerdings neu konfigurieren will, muss man dann halt 60 Sekunden warten, bis das LGW aufgibt und seinen eigenen AP auf macht.
Ich halte das für einen annehmbaren Kompromiss. Den Default-Wert von ,,15 Sekunden" würde ich jedoch lassen. Dies nur als Anmerkung meinerseits.
Zitat von: amunra am 26 Juli 2016, 18:33:27
Ich stelle mal ganz vorsichtig ein Feature-Request:
,,Eine Möglichkeit das LGW in einem reinen Transparent Bridge Mode ohne einen SC16IS750 zu betreiben."
Das werde ich nicht implementieren.
Ohne SC16IS750 muss eine soft serial her, die muss GPIOs verwenden, an denen sonst RFMs hängen, das komplette System muss diesen Modus beherrschen, das Frontend darf nur die passenden Einstellungen anbieten, und, und, und, und man muss es testen, supporten, ...
Das würde mehr oder weniger eine komplett neue Software, da bleibt fast nichts wie es ist.
Aber reine serielle bridges für den ESP8266 gibt es doch:
https://github.com/beckdac/ESP8266-transparent-bridge
https://github.com/jeelabs/esp-link
und bestimmt noch 10 weitere, die ich spontan nicht gefunden habe.
Zitat von: amunra am 26 Juli 2016, 20:58:52
Ich halte das für einen annehmbaren Kompromiss. Den Default-Wert von ,,15 Sekunden" würde ich jedoch lassen.
Ja, die config page bekommt eine Einstellung, und der default ist 15 Sekunden, damit bleib alles wie es war, solange man es nicht ändert.
Das ist kein Kompromiss, das ist die einzige Möglichkeit, dieses Szenario in den Griff zu bekommen.
Man muss dann mal mit der Stoppuhr messen, wie lange der AP braucht, bis er zum Leben erwacht, und dann im LGW etwas mehr als das einstellen.
Zitat von: HCS am 26 Juli 2016, 20:59:59
Das werde ich nicht implementieren.
Ohne SC16IS750 muss eine soft serial her, die muss GPIOs verwenden, an denen sonst RFMs hängen, das komplette System muss diesen Modus beherrschen, das Frontend darf nur die passenden Einstellungen anbieten, und, und, und, und man muss es testen, supporten, ...
Das würde mehr oder weniger eine komplett neue Software, da bleibt fast nichts wie es ist.
Ich habe es befürchtet :'( :-\ und verstehe es auch.
Zitat von: HCS am 26 Juli 2016, 20:59:59
Aber reine serielle bridges für den ESP8266 gibt es doch:
https://github.com/beckdac/ESP8266-transparent-bridge
https://github.com/jeelabs/esp-link
und bestimmt noch 10 weitere, die ich spontan nicht gefunden habe.
Ja, die kenne ich. Ich habe damit vor ca. 1 - 1 1/2 Jahren schon ein wenig experimentiert. Ich bin zu sehr von der Zuverlässigkeit und der einfachen Implementierung des LGWs verwöhnt und ein System wäre mir lieber. Ich wage erneut einen Versuch. Die Option, es mithilfe des SC16IS750 zu realisieren, die ich übrigens auch testen werde, bleibt ja immer noch. ;)
ZitatJa, die config page bekommt eine Einstellung, und der default ist 15 Sekunden, damit bleib alles wie es war, solange man es nicht ändert.
Das ist kein Kompromiss, das ist die einzige Möglichkeit, dieses Szenario in den Griff zu bekommen.
Super - danke.
Der Vorteil von Parametern - man kann es fast allen recht machen ;D
Zitat von: Omega am 26 Juli 2016, 22:24:31
Der Vorteil von Parametern - man kann es fast allen recht machen ;D
Ja fast, bis auf die, die dann nörgeln, dass man da so viel einstellen muss.
Ich sehe den Tag kommen, an dem es eine "Simple-Config-Page" und eine "Expert-Config-Page" geben muss ... ;D ;D
Zitat von: amunra am 26 Juli 2016, 21:11:45
Die Option, es mithilfe des SC16IS750 zu realisieren, die ich übrigens auch testen werde, bleibt ja immer noch. ;)
Das sollte funktionieren. Man muss keine Radios dran haben, geht auch ohne.
Ein devkit, ein SC16IS750 und irgend was an dessen Serielle sollte gehen.
Und dann hast Du WebFrontend, OTA für LGW und den angeschlossenen Prozessor, eigentlich alles was Du willst.
Eigentlich wollte Wzut hier https://forum.fhem.de/index.php/topic,52895.0.html einen SC16IS750 clone implementieren, dass man nicht so lange warten muss, bis er aus China kommt und mit einem 328p oder gar einem Tiny wäre es auch preiswerter.
Aber da scheint nichts draus zu werden.
Fortsetzung der DHT22 Problematik die hier https://forum.fhem.de/index.php?topic=52921.msg475715#msg475715 begonnen hat:
Nach zwei Tagen mit mit angeklemmten Analyzer hat der DHT22 dann doch noch aufgehört Daten zu liefern.
Er antwortet einfach nicht mehr. Man sieht, wie das LGW den wake up pulse absetzt, aber vom DHT kommt keine Antwort.
Kann sich so ein Ding aufhängen, die Lust verlieren oder was auch immer?
Mal die Fakten:
- ich habe ein weiteres LGW , an dem ein DHT22 dran ist, der wochenlang liefert
- Die DHTs gegeneinander getauscht hat das Problem nicht auf das andere LGW verlagert
- An diesem LGW läuft er mal ein paar Stunden, mal einige Tage
- aktuell nach etwas über zwei Tagen plötzlich keine Daten mehr
Hat jemand sachdienliche Hinweise?
Nach jeder Änderung drei Tage warten, ob er durchläuft, das wird eine lustige Fehlersuche ...
Nachtrag: von der Versorgungsspannung getrennt, neu verbunden und läuft wieder, siehe "GehtWieder.png"
3,3V ist die untere Grenze des Betriebsspannungsbereichs, dazu kommen noch Bauteiltoleranzen. Zuverlässig läuft dieser Sensor nur mit 5V.
Hi Damian!
Kann ich denn auf der von dir erworbenen Platine (-> https://forum.fhem.de/index.php/topic,52181.msg458753.html#msg458753) irgenwo die 5V abgreifen? Die müssen doch eigentlich vom Netzteil als VIN reinkommen.
Falls das nicht geht, kann ich mit einem Step-Wandler die notwendige Stabilisierung für den DHT22 erreichen?
Danke im Voraus,
Christian
Zitat von: weini am 29 Juli 2016, 00:04:43... irgenwo die 5V abgreifen? Die müssen doch eigentlich vom Netzteil als VIN reinkommen.
Die IOs des ESP8266 sind
nicht 5V tolerant. Den Data-Pin des DHT22 darf man nicht auf 5V pullen.
Bestenfalls den DHT mit 5V betreiben und IO mit 3.3V, aber ob das (besser) geht?
Oder den DHT22 an 5V, Data auch auf 5V pullup und dann mit einem bidirektionalen level shifter auf 3.3V adaptiert an den ESP dran.
Zitat von: weini am 29 Juli 2016, 00:04:43
... irgenwo die 5V abgreifen?
Die sollten am "vin" pin des devkit aufliegen.
Nachdem mein DTH22 die letzte Wochen nicht mehr zur Mitarbeit zu bewegen war habe ich jetzt wieder Daten. Das fuktioniert genau seit ich einen 10k Pullup auf 3,3V zusätzlich mit eingelötet habe.
Jetzt heißt es abwarten und beobachten, schließlich lief der DHT22 zu Beginn für mehrere Wochen auch ohne Pullup.
Ich halte euch auf dem Laufenden...
Zitat von: locutus am 28 Juli 2016, 21:56:56
3,3V ist die untere Grenze des Betriebsspannungsbereichs, dazu kommen noch Bauteiltoleranzen. Zuverlässig läuft dieser Sensor nur mit 5V.
Da das Datenblatt sagt, dass der Data-Out des DHT22 ein open collector ist, habe ich den DHT22 dann mal mit 5V versorgt, Data ist weiterhin auf 3.3V gezogen. Lief spontan, aber nach einem halben Tag ist er wieder stehen geblieben.
Jetzt habe ich mal eine neuen Theorie: die HF des ESP8266 wirft ihn aus der Bahn. Ich habe jetzt mal 0,1uF direkt am DHT22 aufgelötet.
Wir werden sehen ...
Zitat von: weini am 31 Juli 2016, 22:31:26
Nachdem mein DTH22 die letzte Wochen nicht mehr zur Mitarbeit zu bewegen war habe ich jetzt wieder Daten. Das fuktioniert genau seit ich einen 10k Pullup auf 3,3V zusätzlich mit eingelötet habe.
Jetzt heißt es abwarten und beobachten, schließlich lief der DHT22 zu Beginn für mehrere Wochen auch ohne Pullup.
Ja, das devkit hat ja schon einen 10K pullup drauf. Mit jetzt 5K werden höchstens noch die Flanken steiler.
Man darf sich aber nicht täuschen lassen. Als ich das letzte mal den Analyzer mit drauf gehängt habe, lief er zwei Tage, bis er ausgestiegen ist.
Und was auch als recht sicher betrachtet werden kann: wenn er ausgestiegen ist, dann ist rum, bis man die Spannungsversorgung trennt und wieder verbindet.
Zitat von: HCS am 31 Juli 2016, 22:38:36
Jetzt habe ich mal eine neuen Theorie: die HF des ESP8266 wirft ihn aus der Bahn. Ich habe jetzt mal 0,1uF direkt am DHT22 aufgelötet.
Wir werden sehen ...
Lief von gestern Abend 20:00 bis heute Nacht um 01:00, dann ist der DHT22 wieder ausgestiegen.
Aktuelle Variante ist:
- DHT22 über ca. 10cm Flachbandkabel an "PeMue-Platine" angeschlossen
- 5V Versorgung
- Data mit den 10K, die auf dem devkit sind, auf 3.3V hochgezogen
- 0,1uF direkt auf dem DHT22 auf den Spannungsversorgungs-Pins
Ich glaube, dass ich jetzt den DHT22 mal mit 5V und pullup auf 5V über einen ordentlichen Level-shifter (MOSFET) betreibe.
Oder kann ihn die Software tatsächlich mit einem ungünstigen Timing abstürzen lassen?
Mein Versuch mit zusätzlichem 10k pull-up hat leider auch nur für genau EINE Log-Meldung "OK WS..." gereicht, danach war wieder Ruhe.
Ich würde bei mir als nächstes folgenden Ansatz versuchen:
- DHT22 VCC über VIN speisen (also +5V)
- dann den pull-up analog zu dieser Anleitung realisieren: http://tansi.info/rp/interfacing5v.html
Kann nur etwas dauern, ich habe derzeit noch die Restarbeiten meiner Wohnungsanierung abzuschließen...
Zitat von: weini am 02 August 2016, 22:07:25
dann den pull-up analog zu dieser Anleitung realisieren: http://tansi.info/rp/interfacing5v.html
Das wird nicht gehen, weil wir sinngemäß den ganz unten beschriebenen I2C-Fall haben.
Ok, danke für die Info. Hatte dazu recherchiert aber nichts konkretes gefunden.
Zitat von: weini am 02 August 2016, 22:18:06
Ok, danke für die Info. Hatte dazu recherchiert aber nichts konkretes gefunden.
Wenn, dann etwas in der Art:
http://www.exp-tech.de/sparkfun-pegelwandler-bidirektional
Nur als Beispiel, bekommt man in eBay, China, Deutschland, und tausend anderen Shops.
Aber ich komme ins Zweifeln, ob das Ganze wirklich ein Hardware-Thema ist oder doch ein Software-Thema in der Art, dass der DHT22 durch ein grenzwertiges Timing zum Aussteigen gebracht wird.
Ich muss mal eine pure DHT22 Test-Firmware machen, damit lässt sich einfacher testen.
Habt ihr was gegen den PCA9306? ;)
Wir haben den in Industrieanwendungen eingesetzt und hatten nie Probleme.
http://www.nxp.com/documents/data_sheet/PCA9306.pdf (http://www.nxp.com/documents/data_sheet/PCA9306.pdf)
Gruß Friedrich
Zitat von: Omega-5 am 03 August 2016, 11:42:59
Habt ihr was gegen den PCA9306? ;)
Nein.
Um nur mal auszuprobieren, ob der DHT22 mit 5V Pegel an Data besser läuft, ist es aber herzlich egal, was man nimmt.
PCA9306, N-Kanal FET und zwei Rs, oder, oder
Hauptsache, es setzt den Pegel bidirektional um.
Irgendwo muss ich noch so einen FET shifter rumliegen haben. Wenn ich ihn finde, dann probiere ich mal mit 5V auf Data
Hallo Zusammen,
habe Euren interessanten Thread hier ebenfalls verfolgt und plage mich auch mit "so" einem Verhalten des des DHT22 in Verbindung
mit meinen Funksensor (allerdings Ub=3V6) herum:
Komischerweise fast immer zu bestimmten Zeiten ....
Werde mal Eure gesammelten Erfahrungen durchstudieren ....
Da die Aussetzer immer länger werden, könnte es in meinem Fall doch "nur" die Betriebsspannung,
im Zusammenspiel mit Umgebungstemperatur sein ...
http://iot-playground.com/forum/hardware-general/537-dht-22-humidity-value-stability-over-time (http://iot-playground.com/forum/hardware-general/537-dht-22-humidity-value-stability-over-time)
http://www.kandrsmith.org/RJS/Misc/Hygrometers/dht22_first_failure.html (http://www.kandrsmith.org/RJS/Misc/Hygrometers/dht22_first_failure.html)
ZitatOverall I am impressed with the DHT22, but if they do have reliability problems (I have one failure out of six devices) you may never feel inclined to trust them.
http://forum.arduino.cc/index.php?topic=355137.0 (http://forum.arduino.cc/index.php?topic=355137.0)
Nach weiteren versuchen mit neuer CR2032 Batterie mit 3V6 und 240ma kommt das Verhalten wesentlich in kürzeren Abständen.
Die 5Volt Versorung des DHT22 scheint angeraten zu sein, mit einem LiPo-Accu mit 3V7 dürfte es auch nicht wesentlich besser werden.
Es sei denn, die Temperatur steigt über 20 Grad... ;)
Batterie-Lebensdauer-Rechner: http://oregonembedded.com/batterycalc.htm (http://oregonembedded.com/batterycalc.htm)
Zitat von: juergs am 03 August 2016, 18:09:14
... habe Euren interessanten Thread hier ebenfalls verfolgt und plage mich auch mit "so" einem Verhalten des des DHT22 in Verbindung mit meinen Funksensor (allerdings Ub=3V6) herum.
Hm, vielleicht braucht der DHT22 einen Kondensator in der Nähe zur Stabilisierung?
Gruß PeMue
ich habe 100yF zur 3V6 Batterie hin, schon wegen des Funkmoduls. Probiere aber auch mal 100nF zum DHT hin ..
Erklärt aber nicht das "selektive" Erscheinungsbild ...
Zitat- power the DHT22 with 5V instead of 3v3 -> no changes
- adding a 100nF capacitor near device -> no changes
ZitatI can conclude that it is typical for DHT sensors. At the same time, BMP180 that I use in the same setup and couple of DS18B20 show correct temperature and are reliable (they do not measure humidity, though). I also have an I2C humidity sensor SHT21, but I have not tried it yet.
Höhrensagen ... werde mal am WoE meine eigenen Messungen starten.
Hallo HCS,
könntest Du bitte bei Gelegenheit die v1.20 https://forum.fhem.de/index.php/topic,43672.msg471910.html#msg471910 noch auf der ersten Seite verlinken (ich weiß mittleriweile, dass die auf S. 46 steht ;)).
Danke + Gruß
Peter
@HCS
Dir ist bekannt, dass der DHT22 ca. 2 Sekunden für die Verarbeitung der Messdaten benötigt?
Zitat von: PeMue am 03 August 2016, 21:44:32
Hallo HCS,
könntest Du bitte bei Gelegenheit die v1.20 https://forum.fhem.de/index.php/topic,43672.msg471910.html#msg471910 noch auf der ersten Seite verlinken (ich weiß mittleriweile, dass die auf S. 46 steht ;)).
Die ist doch im Repo eingecheckt und wird schon seit dem 13.07. mit dem FHEM Update ausgeliefert.
https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/firmware/
Zitat von: juergs am 03 August 2016, 18:09:14
.. und plage mich auch mit "so" einem Verhalten des des DHT22 in Verbindung mit meinen Funksensor (allerdings Ub=3V6) herum
Aber einem etwas anderen Verhalten. Wenn er bei mir nicht mehr will, dann ist rum und nichts außer von Ub trennen hilf ihm wieder auf die Sprünge. Wobei er jetzt gerade mal wieder seit zwei Tagen konstant läuft ::)
Das Ding ist vom ersten Tag bis heute ein "pain in the a..", ich habe nachts schon Alpträume in denen mich Monster-DHTs verfolgen :o ;D ;D
Zitat von: juergs am 03 August 2016, 21:13:09
ich habe 100yF zur 3V6 Batterie hin, schon wegen des Funkmoduls. Probiere aber auch mal 100nF zum DHT hin ..
Ich habe 100 nF direkt am DHT22 auf Ub drauf, das hat auch nicht geholfen.
Was seltsam ist, ist, dass er mal ein paar Stunden und mal ein paar Tage läuft, bis er aussteigt.
Und siehe die Analyzer-Shots weiter oben, er antwortet dann einfach nicht mehr.
Ach ja, bei dem anderen LGW, bei dem ich dachte, dass er stabil läuft, ist er die Tage auch nach drei Wochen ausgestiegen :o
Der Wünschelrutengänger hat unterhalb vom DHT auch nichts verdächtiges entdeckt.
Habe ich irgendwo "Temperatur" gelesen? Die letzten Tage ist es etwas kühler, als zu der Zeit, wo er immer nur einige Stunden geschafft hat. Das lässt sich aber testen, ich stelle ihn in den Backofen und wenn er keine Daten mehr liefert, dann aktiviere ich die pyrolytische Selbstreinigung >:(
Zitat von: locutus am 03 August 2016, 22:09:46
@HCS
Dir ist bekannt, dass der DHT22 ca. 2 Sekunden für die Verarbeitung der Messdaten benötigt?
Ja. Das LGW lässt die internen Sensoren alle 10 Sekunden messen.
Ich werde mal noch das Timing ändern. Lt. Datenblatt darf das Startsignal zwischen 0.8ms und 20ms liegen mit einem typischen Wert von 1ms. Und ich ziehe es genau 1ms runter. Eventuell probiere ich es mal mit etwas mehr, ob er dann besser hört.
Zitat von: PeMue am 03 August 2016, 21:44:32
könntest Du bitte bei Gelegenheit die v1.20 https://forum.fhem.de/index.php/topic,43672.msg471910.html#msg471910 noch auf der ersten Seite verlinken (ich weiß mittleriweile, dass die auf S. 46 steht ;)).
Jetzt habe ich gerade kapiert, was Du gemeint hast :-[
Yes, I can ;D
das schaffe ich ;D
Neu Erkenntnisse:
da ich die letzten Tage nicht @home war, kann ich jetzt für mich entwarnen:
Batteriespannung des Sende-Moduls Außenbereich: 2.90 Volt.
Mein zweites Modul hat 2.95 Volt (InnenBereich) und sendet noch ohne Probleme.
Da habe ich einen Vergleich, wenn die Spannung weiter nachlässt.
(Entladekurve scheint eher eine e-Funktion, wie linear zu sein)
Da das natürlich weit unter den Spezifikationen von 3.3 .. 6Volt liegt,
muss ich das Energiesparen des Sketches noch weiter optimieren, sofern das
mit einer CR2032-Batterie und dem Stromverbrauch des Sensors überhaupt möglich sein sollte.
Werde mal den Verbrauch und die ON-Zeiten für die Sensor-Messung ermitteln.
Die gleiche Funktionalität für den DS18B20 läuft jetzt schon 3 mal so lang ohne Probleme
und benötigt unter 10 yA im Sleep-Modus.
Also scheinen die "Aussetzer" eher ein Indiz für fehlende Power zu sein.
Grüße,
Jürgen
Auch komplett an 5V (FET level shifter) ist er gleich mal nach vier Stunden ausgestiegen. Ich glaube inzwichen eher nicht mehr so sehr daran, dass das ein Spannnugsversorgungsthema ist, zumindest wenn man nicht deutlich unter 3.3V liegt, was ja im Prinzip auch von juergs bestätigt ist, mit seinen 2.9V
Und möglicherweise gibt es zwei separate Probleme:
1. wird beim Start des LGW (manchmal, meistens, immer, ...) nicht erkannt.
Das könnte das zwei Sekunden-Thema sein. Wenn das LGW sehr schnell die wifi-Verbindung stehen hat, könnte es vorkommen, dass zu dem Zeitpunkt, an dem die Initialisierung und Erkennung des DHT22 stattfindet, noch keine zwei Sekunden rum sind, und dann antwortet er nicht und das LGW geht davon aus, dass keiner angeschlossen ist. Ich werde mal was einbauen, das die Initialisierung des DHT22 notfalls verzögert, wenn nach dem Start noch keine zwei Sekunden rum sind.
2. Läuft einige Stunden oder Tage und antwortet dann nicht mehr.
Möglicherweise gibt die DHT22 routine nach dem wake up den bus zu spät frei und der DHT reagiert manchmal beleidigt, weil der bus noch auf vdd genagelt ist. In einer Woche wissen wir es ...
Wenn man bei jeder Änderung eine Woche warten muss, ob es jetzt durchläuft, ist schon hart. :(
Wollte mich heute dran machen und den NanoMCU fertig machen und habe folgendes Problem:
Den 1. hatte ich bereits direkt nachdem er angekommen ist geflasht (nicht zuhause aber SSID & Passwort schon eingetragen und gespeichert)
Heute dann auf dem BreadBoard alles soweit verkabelt, Strom dran und das einzige, was der noch macht ist, dass beim Einstecken des Netzteils die blaue LED 1x blinkt und dann ca. alle 8 Sek. wieder blinkt. Nach ca. 1 Minute blinkt die rote LED dann ein paar mal. Verbinden mit dem WLAN tut es sich aber augenscheinlich nicht, da hier in der Fritz!Box kein Verbindungsversuch aufgelistet ist und auch in der Liste der WLAN Geräte nichts auftaucht. Das "LaCrosseGateway-..." WLAN wird allerdings auch nicht eröffnet.
Dann versucht neu zu flashen. 1x nur dem dem "esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 921600 -ca 0x00000 -cd nodemcu -cf JeeLink_LaCrosseGateway.bin" Befehl -> Er flasht, aber es ändert sich nichts und dann 1x mit vorangehendem löschen des Flashs "./esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 115200 -ca 0x00000 -cd nodemcu -ce" von Seite 36. Keine Änderung.
Dann den 2. NanuMCU ausgepackt. Erst war das LaCrosseGateway-... WLAN da, SSID & Pass hinterlegt. Dann gleiches Problem wie beim 1.
Feste IP oder ähnliches sind bei beiden malen nicht hinterlegt worden.
Ich bin gerade etwas überfragt, hat da jemand ähnliches Phänomen schon gehabt?
Zitat von: Hagenuck1 am 10 August 2016, 21:09:04
Wollte mich heute dran machen und den NanoMCU fertig machen und habe folgendes Problem:
Was ist ein NanoMCU?
Zitat von: Hagenuck1 am 10 August 2016, 21:09:04
Heute dann auf dem BreadBoard alles soweit verkabelt, Strom dran und das einzige, was der noch macht ist, dass beim Einstecken des Netzteils die blaue LED 1x blinkt und dann ca. alle 8 Sek. wieder blinkt. Nach ca. 1 Minute blinkt die rote LED dann ein paar mal. Verbinden mit dem WLAN tut es sich aber augenscheinlich nicht, da hier in der Fritz!Box kein Verbindungsversuch aufgelistet ist und auch in der Liste der WLAN Geräte nichts auftaucht. Das "LaCrosseGateway-..." WLAN wird allerdings auch nicht eröffnet.
Was gibt es denn beim Start auf der seriellen Schnittstelle aus?
NodeMCU meinte ich natürlich, hatte die Bezeichnung da irgendwie falsch im Kopf ;)
Was er seriell ausgibt muss ich nachher mal prüfen. Mittels "screen" dürfte das am Mac ja auch klappen oder?
Gesendet von iPhone mit Tapatalk
Zitat von: Hagenuck1 am 11 August 2016, 13:24:29
Mittels "screen" dürfte das am Mac ja auch klappen oder?
Ja, es dürfte. Ich verwende auf dem Mac das Programm CoolTerm.
http://freeware.the-meiers.org/CoolTerm_Screenshot.html
Zitat von: HCS am 11 August 2016, 13:04:32
Was gibt es denn beim Start auf der seriellen Schnittstelle aus?
Nach meinen Tests habe ich dank deiner Software nun raus bekommen, dass ohne RFM69 beide NodeMCU laufen. Mit RFM69 läuft nur der 2. das hatte ich gestern nicht ausgetestet.
Die folgende Meldung gibt der 1. mit RFM69 zur Vollständigkeit mit 115200 Baud aus:
ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset
load 0x4010f000, len 1264, room 16
tail 0
chksum 0x0f
csum 0x0f
~ld
Die RFM69 gegeneinander tauschen, ob der Fehler wandert
V1.21
DHT22
Nachdem der DHT22 mit dem geänderten Timing in einem Test-Sketch eine Woche gelaufen ist, habe ich die Änderungen in das LGW transferiert.
Siehe DHT22.png. Der DHT22 hat 293691 Messungen geliefert und in der Woche 25 Fehlmessungen hingelegt, ist aber durchgelaufen. Intervall war zwei Sekunden. Jetzt hoffen wir mal, dass es im LGW genauso läuft. Im LGW wird sichergestellt, dass nach einem power up mindestens zwei Sekunden rum sind, bevor der DHT2 angesprochen wird, dass er auch sicher bereit ist.
Startup-delay
Es gab den Wunsch, eine beim Start konfigurierbare Verzögerung einzubauen, weil Fritz langsamer als LGW ist.
Wunsch erfüllt, siehe Settings.png
Interner Drucksensor
Die Höhe über NN kann nun auch auf der Setup konfiguriert werden, man ist also nicht darauf angewiesen, dass ein FHEM es sendet.
Siehe Settings.png
Korrektur Temperatur und Feuchte
Für Temperatur und Feuchte kann nun jeweils ein Korrekturwert angegeben werden.
Der Wert kann entweder ein Offset sein oder prozentual.
Beispiele:
-5 macht aus 20°C 15°C
+3 macht aus 20°C 23°C
-10% macht aus 20°C 18°C
+20% macht aus 20°C 24°C
Siehe Settings.png
OLED mode=thps
Man kann auf der Setup-page nun auch thps (und ich gaube noch zwei neue) für dem MCP23008 konfigurieren.
Eingecheckt, kommt dann morgen mit dem Update.
Zitat von: HCS am 14 August 2016, 21:22:26
OLED mode=thps
Man kann auf der Setup-page nun auch thps (und ich gaube noch zwei neue) für dem MCP23008 konfigurieren.
ähm, ich habe schon in der Version 1.20 folgenden Befehl über fhem abgesetzt
set <LGWname> raw "OLED mode=thps"und Temperatur, Feuchtigkeit, Druck und Systemdaten sind durchgelaufen.
Irgendwie habe ich da vermutlich was nicht so ganz verstanden *kopfkratz*
Hallo allerseits.
Ich bin seit einiger Zeit hier am mitlesen. Für einen nicht-Elektroniker eine seeeehr trockene Materie....
Die wüste Gobi ist (aus meiner Sicht) sicher viel feuchter ;)
Aber es ist (zumindestens für mich) faszinierend was man mit FHEM, Homematic und MAX! so realisieren kann.
Die Wüste Gobi fasziniert mich eher weniger. :)
Top auch, was Ihr leistet mit der Entwicklung und der nun fertigen Platine. Ich bin echt neidisch das ich das nicht gelernt habe!
Und nein: Ich werde es auch mit meinen 51 Lenzen sicher nicht mehr hinbekommen :(
Wenn es noch möglich ist:
Ich würde gerne 2 Platinen mit den Kleinteilen (Wiederstände etc) haben wollen. Die NodeMCU und die RFMs habe ich bereits hier,
und laufen prima mit dem LGW (noch auf dem Breadboard) und meinen LC-Sensoren seit einer knappen Woche.
Die anderen Gimmicks (BME und BMP etc.) bräuchte ich (vorerst) nicht.
Für mich ist die LGW + LaCrosse funktionalität primär wichtig.... nur halt auf etwas "aufgeräumter" art auf diese geniale Platine.
Super wäre noch das 868MHz Radio für MAX! bzw. Homematic darauf.... aber ich darf ja noch träumen ;)
Leider kenne ich den Preis nicht, und an Wen ich das Geld und Wie überweisen soll. Wäre nett wenn man mir dies mitteilen würde.
BTW: (ja lasst mich noch ein wenig weiter träumen) ;D
Bei meiner Begeisterung was man mit dem ESP8266 alles so anstellen kann, bin ich auf folgendes gestossen:
https://www.openhardware.io/view/120/Happy-Bubbles-Bluetooth-Presence-Detector#tabs-instructions
Wäre es auch möglich, dies (also nur das BT) auf der Platine zu integrieren? Ich denke da an das PRESENCE Modul in FHEM, das man
mit einigen günstigen und kleinen BT-Tags realisieren könnte. Oder für die Alarmanlage..... oder oder oder...
Gruss
Alex
Zitat von: PeMue am 14 August 2016, 21:38:54
Irgendwie habe ich da vermutlich was nicht so ganz verstanden *kopfkratz*
Die Aussage kann ich voll unterstützen und durch nichts widerlegen ;D ;D
Man konnte es von FHEM aus senden aber nicht als Aktion für einen DI vom MCP23008 im Frontend konfigurieren.
Da hat es gefehlt.
Hallo Leute!
Ich bin beeindruckt von der Arbeit die ihr hier macht! Habe versucht nachzubauen, der Aufbau dürfte passen habe 3 rfm69 cw hängen am nodemcu! Sollten die von selbst erkannt werden oder muss ich das alles einstellen Frequenz und so?
Ich bekomme das:
OK VALUES LGW 8959100 UpTimeSeconds=832,UpTimeText=0Tg. 0Std. 13Min. 52Sek. ,WIFI=Linksys12004,ReceivedFrames=0,FramesPerMinute=0,RSSI=-62,FreeHeap=15704,LD.Min=0,LD.Avg=0,LD.Max=32,OLED=none
STATE
initialized
Im rawmsg
Vielleicht könnt ihr mir helfen und mir sagen wo der Wurm drinnen ist!
Danke!
Zitat von: Kawaci am 14 August 2016, 21:56:35
Sollten die von selbst erkannt werden oder muss ich das alles einstellen Frequenz und so?
Erkannt werden sie automatisch.
Was für Sensoren hast Du denn?
Geh mal auf die Log-Page vom Frontend und sende ein v.
Was kommt da als Antwort in der oberen Liste?
Und dann hier mal feste lesen, amunra hat da viel beschrieben: http://www.fhemwiki.de/wiki/LaCrosseGateway
Zitat von: HCS am 14 August 2016, 21:52:51
Die Aussage kann ich voll unterstützen und durch nichts widerlegen ;D ;D
Man konnte es von FHEM aus senden aber nicht als Aktion für einen DI vom MCP23008 im Frontend konfigurieren.
Da hat es gefehlt.
Ok, dann hätte ich das auch verstanden. Der Taster ist in diesem Fall ein Eingang und schaltet das Display in den entsprechenden Modus ;D
Zitat von: PeMue am 14 August 2016, 22:08:05
Ok, dann hätte ich das auch verstanden. Der Taster ist in diesem Fall ein Eingang und schaltet das Display in den entsprechenden Modus ;D
Genau.
Zitat von: bitbiter am 14 August 2016, 21:51:07
Wäre es auch möglich, dies (also nur das BT) auf der Platine zu integrieren? Ich denke da an das PRESENCE Modul in FHEM, das man
mit einigen günstigen und kleinen BT-Tags realisieren könnte. Oder für die Alarmanlage..... oder oder oder...
Das Thema muss ich mir mal eines Tages ganz in Ruhe mit Prio 5 anschauen, was das ist, bedeutet und werden könnte.
Zitat von: HCS am 14 August 2016, 22:07:45
Was für Sensoren hast Du denn?
Einen tx29dht-it
und noch eine von it+ aber ich fange mit beiden nicht wirklich was an wenn ich es nicht zum laufen bringe!
ZitatGeh mal auf die Log-Page vom Frontend und sende ein v.
Was kommt da als Antwort in der oberen Liste?
da kommt witzigerweise nur
" 22:27:36 MESZ: Command from frontend: 'v'"
raus!
Und nach nem neustart kommt das raus:
"
22:38:20 MESZ: This is line 5 of void setup(void)
22:38:20 MESZ: LaCrosseITPlusReader.Gateway V1.20
22:38:20 MESZ: Free heap: 24584 Flash size: 4194304 SDK: 1.5.3(aec24ac9)
22:38:20 MESZ: Reset: Software/System restart
22:38:20 MESZ: Fatal exception:0 flag:4 (SOFT_RESTART) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
22:38:20 MESZ: Read settings
22:38:20 MESZ: Starting I2C with 400 kHz
22:38:20 MESZ: Starting wifi
22:38:20 MESZ: Start WIFI_STA
22:38:20 MESZ: HostName is: LaCrosseGateway
22:38:20 MESZ: Using DHCP
22:38:20 MESZ: Trying to connect to an AP
22:38:20 MESZ: .......
22:38:20 MESZ: connected :-)
22:38:20 MESZ: SSID: Linksys12004
22:38:20 MESZ: IP: 192.168.1.111
22:38:20 MESZ: Starting frontend
22:38:20 MESZ: Starting OTA
22:38:20 MESZ: Starting data port 1 on 81
22:38:20 MESZ: Searching RFMs and Sensors
22:38:20 MESZ: Sending init String to FHEM
22:38:20 MESZ: Setup completely done
"
Danke für den link den habe ich schon mehrere male gelesen aber funken tuts noch immer nicht!
Zitat von: Kawaci am 14 August 2016, 22:28:53
Einen tx29dht-it
Der muss funktionieren, und zwar ohne irgend etwas zu konfigurieren.
Zitat von: Kawaci am 14 August 2016, 22:28:53
da kommt witzigerweise nur
" 22:27:36 MESZ: Command from frontend: 'v'"
raus!
Ja in der unteren Liste.
In der oberen Liste muss so eine Zeile auftauchen:
22:36:48: [LaCrosseITPlusReader.Gateway.1.21 (1=RFM69 f:868300 t:20~3) + (2=RFM69 f:868960 r:6631) + (4=RFM69 f:868300 r:20000) + (5=RFM69 f:868300 r:8842) + BMP180 + DHT22 + LM75 + SC16IS750 + OLED + MCP23008 {IP=192.168.31.211}]Also nicht genau die, aber eine, die mit "22:36:48: [LaCrosseITPlusReader.Gateway" beginnt.
Die interessiert mich.
22:38:20 MESZ: Starting data port 1 on 81
22:38:20 MESZ: Searching RFMs and Sensors
22:38:20 MESZ: Sending init String to FHEM
Schaltplan konsultieren und Verkabelung prüfen, da stimm wohl etwas nicht.
Das meinst
22:43:28 MESZ: OK VALUES LGW 8959100 UpTimeSeconds=320,UpTimeText=0Tg. 0Std. 5Min. 20Sek. ,WIFI=Linksys12004,ReceivedFrames=0,FramesPerMinute=0,RSSI=-68,FreeHeap=19192,LD.Min=0,LD.Avg=0,LD.Max=20,OLED=none
ZitatSchaltplan konsultieren und Verkabelung prüfen, da stimm wohl etwas nicht.
Danke dann isst hardware fehlen zum Glück habe ich es steckbar gemacht! ;)
Nein, meinte ich nicht.
Ich meinte "22:36:48: [LaCrosseITPlusReader.Gateway.1.21 ..."
Aber amunra hat Deine nachträgliche Änderung von Deinem Beitrag gesehene (ich nicht) und vermutlich recht.
Die RFM69 werden nicht erkannt. Hardware. Vermutlich falsch angeschlossen.
Ach ja, amunra, du ahnst, was jetzt zu tun wäre? :) ;)
@Kawaci: falls Du die SSID von Deinem Linksys geheim halten wolltest, nun ist sie public.
Wäre eine Überlegung wert, sie jetzt zu ändern ...
@HCS Danke werde ich machen!
Bei mir kommt nur das raus! sonst nichts! In fhem kommt zwar das [LaCrosseITPlusReader.Gateway.1.20 {IP=xxxxxxxxxx} aber nur das und nichts anderes!
Ich werde es nach diesem Schaltplan
http://www.fhemwiki.de/w/images/5/57/Lgw_Schaltplan_Devkit.png
nochmal kontrolieren und ausbessern!
Hab da noch ne frage! Muss der 2te gnd vom rfm 69 und der reset verbunden werden?
Zitat von: Kawaci am 15 August 2016, 22:02:33
Hab da noch ne frage! Muss der 2te gnd vom rfm 69 und der reset verbunden werden?
GND ja, Reset nein.
Am Anfang würde ich nur mit einem Radio starten, und nicht gleich mit einer ganzen Raumsonde... ;) ;D ;D
Ja werd es versuchen! Danke für die hilfe! Ich hab den 2.gnd verbunden der rest stimmt so wie ich es vekabelt habe! Jetzt nur noch starten und los gehts!
Zitat von: PeMue am 14 August 2016, 22:08:05
Ok, dann hätte ich das auch verstanden. Der Taster ist in diesem Fall ein Eingang und schaltet das Display in den entsprechenden Modus ;D
Am MCP23008 hängt ein Taster an den IOs 0-7 und schaltet das Display in den entsprechenden Modus?
Zitat von: Chris_Worms am 16 August 2016, 10:15:25
Am MCP23008 hängt ein Taster an den IOs 0-7 und schaltet das Display in den entsprechenden Modus?
Genau. Und was welcher Taster machen soll, wird auf der Setup-Page von Web-Frontend eingestellt.
Also z.B.
IO0: Display aus
IO1: Display an
IO2: mode "s"
IO3: mode "thp"
usw. oder wie halt gewünscht.
Zitat von: HCS am 16 August 2016, 10:48:23
Genau. Und was welcher Taster machen soll, wird auf der Setup-Page von Web-Frontend eingestellt.
Also z.B.
IO0: Display aus
IO1: Display an
IO2: mode "s"
IO3: mode "thp"
usw. oder wie halt gewünscht.
Okay, danke. Jetzt ist es klar und ich habe es verstanden :-)
Ich hoffe es wurde nicht schon einmal gefragt und ich hab es nur übersehen, aber im Wiki finde ich zum SC16IS750 das LGW Addon Bild wonach man Vin, A1, A2 und I2C/SPI auf 3,3V legen soll. Mein SC16IS750 hat allerdings nur A0 und A1 - ist das nur eine Verwechslung beim notieren?
Gruß Mario
Zitat von: waschbaerbauch am 16 August 2016, 14:39:00
Mein SC16IS750 hat allerdings nur A0 und A1 - ist das nur eine Verwechslung beim notieren?
Ja, sollte A0 und A1 sein. Da habe ich mich wohl glatt verschrieben.
Kein Problem, ich wollte nur zur Sicherheit mal nachfragen ;)
Hat aber nichts geknallt als ich es vorhin verwegen ausprobiert habe :D
Version 1.21 ist dokumentiert (http://www.fhemwiki.de/wiki/LaCrosseGateway)
(Den Projektstatus habe ich in der neuen Version unterschlagen ;) und ein paar andere Kleinigkeiten angepasst/korrigiert.)
Zum Thema "Startup-delay" war ich anfangs etwas verwirrt, weil zwei unterschiedliche Ansätze vorgeschlagen wurden.
Nach drei mal lesen ;o) habe ich es endlich und hoffentlich verstanden.
Es wäre nett wenn jemand drüber schaut und gegenprüft, ob ich das richtig wieder gegeben habe. Danke.
Zitat"Startup-delay"
ist aus meiner Sicht richtig wiedergegeben.
Danke für deinen Einsatz - finde ich prima.
Holger
Hey! Alles neu verlötet und jetzt funkt mit allen 3 rfm69! Hab noch einen dht22 gefunden brauch ich den auch nur anschliessen und gut ists oder muss ich da was im sertup machen?
Danke euch allen für die Hilfe! und gute Arbeit weiter so!
Von mir auch noch einmal ein ganz großes DANKESCHÖN an alle die das hier ermöglicht haben!
Meine Tochter findet das Display besonders schön und hat einen mega Spaß daran das LGW wieder und wieder mit dem Reset Taster booten zu lassen. Ist es vielleicht möglich statt dem Loading eine MyLittlePony Animation beim booten zu integrieren - dann bekommt sie ein eigenes LaCrosseGateway und meins darf wieder mit mir spielen!? ;)
Nur Spaß!
Zitat von: Kawaci am 16 August 2016, 23:13:57
Hab noch einen dht22 gefunden brauch ich den auch nur anschliessen und gut ists oder muss ich da was im sertup machen?
Wenn du den betreiben möchtest, dann musst du wohl auf einen RFM69 verzichten. Soweit ich noch auf einem aktuellen Stand bin, dann brauchst du für drei oder mehr RFM69
und DHT22 den SC16IS70.
Zitat von: amunra am 16 August 2016, 18:40:26
Es wäre nett wenn jemand drüber schaut und gegenprüft, ob ich das richtig wieder gegeben habe. Danke.
Ich war gerade nett. Ist korrekt.
Den Tippfehler kann man noch korrigieren: "Eine Anpassung kann für den
foglenden Fall sinnvoll sein:"
Zitat von: waschbaerbauch am 16 August 2016, 23:20:50
Wenn du den betreiben möchtest, dann musst du wohl auf einen RFM69 verzichten. Soweit ich noch auf einem aktuellen Stand bin, dann brauchst du für drei oder mehr RFM69 und DHT22 den SC16IS70.
Korrekt. Es geht nur alternativ Radio #3 oder DHT22, nicht beides zusammen.
Mit einem SC16IS750 als Erweiterung gehen dann zwei Radios mehr.
Also entweder 5 x RFM69 oder 4 x RFM69 (Radio 1,2,4,5) und ein DHT22.
Zitat von: amunra am 16 August 2016, 18:40:26
Es wäre nett wenn jemand drüber schaut und gegenprüft, ob ich das richtig wieder gegeben habe. Danke.
Mir ist noch etwas aufgefallen:
ZitatSC16IS750 I2C Adresse: 0x90 on board OI Erweiterung Kann anstatt RFM69 Radio#3 eingesetzt werden.
Ich dachte, der Trick dabei ist, dass mit dem SC16IS750 bis zu 5 Radios angeklemmt werden können (nur beim DHT22 entfällt Radio 3).
Den Schreibfehler Neu
estart habe ich selber schon korrigiert ;)
Zitat von: PeMue am 17 August 2016, 08:53:59
Mir ist noch etwas aufgefallen:Ich dachte, der Trick dabei ist, dass mit dem SC16IS750 bis zu 5 Radios angeklemmt werden können (nur beim DHT22 entfällt Radio 3).
Dann könnte man aus "OI Erweiterung" noch "IO Erweiterung" machen ;)
Es ist aber generell eigentlich nicht richtig, was da steht ("
Kann anstatt RFM69 Radio#3 eingesetzt werden." )
Die SC16IS750-Erweiterung kann man unabhängig davon, wie viele Radios und ob man einen DHT22 hat, machen.
Oder umgekehrt, wegen dem SC16IS750 muss Radio #3 nicht entfallen.
Der einzige Grund, warum Radio #3 nicht dran kommt ist, dass man einen DHT22 anschließen will (oder weil man keine drei Radios braucht)
Oder wie in deinem Beispiel 5 Radios und der Arduino mit DHT22?
Der Hinweis im WIKI (http://www.fhemwiki.de/wiki/LaCrosseGateway#Unterst.C3.BCtzte_Sensoren_und_Aktoren):
ZitatKann anstatt RFM69 Radio#3 eingesetzt werden.
ist um eine Zeile verrutscht. Ich passe es an.
Hier (https://forum.fhem.de/index.php/topic,43672.msg441446/topicseen.html#msg441446) steht es auch noch einmal...
@amunra
Dann bei den Sensoren bitte beim BME280 noch unter 'Link/Hinweise' korrigieren:
ZitatBei Einsatz von Breakout (GY-68) kein PullUp mit 4,7k Widerständen nötig. Verifizieren!
GY-68 ist imo nur der BMP180?!
Ich hätte noch einen Vorschlage wg. der Kalibrierung. Bei Luftdruck - und viel extremer - der Luftfeuchte geht die Messtemperatur des BMP/BME in die Ergebnisse mit ein.
Deshalb wäre es sinnvoll, die Kompensationsparameter bereits in die Temperaturmessung des BME/BMP Modules einfliessen zu lassen und nicht erst die abgeleiteten Werte zu korrigieren.
Auch wäre es schön, wenn beim Start die internen Kalibrierungsparameter ausgegeben würden.
Damit könnte man die BME/BMP Breakouts leichter identifizieren.
ZitatBei Einsatz von Breakout (GY-68) kein PullUp mit 4,7k Widerständen nötig. Verifizieren!
Ich würde es allgemeiner halten:
"Falls das verwendete Breakout bereits PullUp-Widerstände für SDA und SCL enthält, können R???? und R???? entfallen."
Zitat von: SusisStrolch am 17 August 2016, 10:04:41
Ich hätte noch einen Vorschlage wg. der Kalibrierung. Bei Luftdruck - und viel extremer - der Luftfeuchte geht die Messtemperatur des BMP/BME in die Ergebnisse mit ein.
Richtig.
Zitat von: SusisStrolch am 17 August 2016, 10:04:41
Deshalb wäre es sinnvoll, die Kompensationsparameter bereits in die Temperaturmessung des BME/BMP Modules einfliessen zu lassen und nicht erst die abgeleiteten Werte zu korrigieren.
Ja, das kling sinnvoll. Du meinst an die Register T1, T2, usw. rangehen?
Oder die damit zwischengerechnete kompensierte Temperatur korrigieren, bevor damit Druck und Feuchte weitergerechnet werden?
Allerdings ist das bei BME und BMP unterschiedlich und beim DHT22 völlig anders, der haut die Werte raus und man kommt da nicht zwischen Temperatur und Feuchte rein.
Das ist ein Projekt für jemanden, der seinen Sensor erschlagen hat :o
Zitat von: SusisStrolch am 17 August 2016, 10:04:41
Auch wäre es schön, wenn beim Start die internen Kalibrierungsparameter ausgegeben würden.
Damit könnte man die BME/BMP Breakouts leichter identifizieren.
Verstehe ich richtig: Die von Sensor ausgelesenen T1...T3, P1...P9 und H1...H6 rausgeben?
Ich finde es aber traunrig, dass man sich damit rumschlagen muss. Ich habe BMP180 und BME280, die wenn sie nebeneinander liegen, mehrer Grad unterschiedlich messen.
Sind die Chinesen so schlecht drauf oder warum liefert ein Sensor, der lt. Datenblatt
Humidity +-3%
Temperature +- 1°C
hat, so schlechte Werte?
Zitat von: HCS am 17 August 2016, 10:56:44
Ich finde es aber traunrig, dass man sich damit rumschlagen muss. Ich habe BMP180 und BME280, die wenn sie nebeneinander liegen, mehrer Grad unterschiedlich messen.
Sind die Chinesen so schlecht drauf oder warum liefert ein Sensor, der lt. Datenblatt
Humidity +-3%
Temperature +- 1°C
hat, so schlechte Werte?
Ich fürchte, die ursprüngliche Produktionsstätte der Dinger ist in Reutlingen ???
Aber ich möchte das auch noch irgendwie klären ...
Zitat von: PeMue am 17 August 2016, 11:15:58
Ich fürchte, die ursprüngliche Produktionsstätte der Dinger ist in Reutlingen ???
Ob die Chinesen in Reutlingen BMEs kaufen, wenn sie ein Breakout bauen und für einen Schleuderpreis raushauen?
Oder biegen sie etwas Blech um sonstnochwas und glauben, es ist ein BME280?
Hast Du BME280, die sicher von Bosch sind?
Ich hatte mal eine Messreihe mit BMP180 gemacht, beim JeeLink Sketch. Da war auch schon das Theater, dass Leute abenteuerliche Temperaturen bekommen.
Siehe hier: https://forum.fhem.de/index.php/topic,14786.msg334359.html#msg334359
Da war das absolut klare Ergebnis: "die messen unterschiedlich"
Zitat von: HCS am 17 August 2016, 10:56:44
Ja, das kling sinnvoll. Du meinst an die Register T1, T2, usw. rangehen?
Oder die damit zwischengerechnete kompensierte Temperatur korrigieren, bevor damit Druck und Feuchte weitergerechnet werden?
Letzteres, zumindest mal im ersten Ansatz.
Zitat
Allerdings ist das bei BME und BMP unterschiedlich und beim DHT22 völlig anders, der haut die Werte raus und man kommt da nicht zwischen Temperatur und Feuchte rein.
Hab' mir das BMP180 Datenblatt noch nicht angeschaut - und mein Letzter ist gegrillt, weil beim Breakboard GND und Vcc gegenüber dem Displayboard gedreht waren... :-\ :o
Zitat
Verstehe ich richtig: Die von Sensor ausgelesenen T1...T3, P1...P9 und H1...H6 rausgeben?
Exakt.
Zitat
Ich finde es aber traunrig, dass man sich damit rumschlagen muss. Ich habe BMP180 und BME280, die wenn sie nebeneinander liegen, mehrer Grad unterschiedlich messen.
Sind die Chinesen so schlecht drauf oder warum liefert ein Sensor, der lt. Datenblatt
Humidity +-3%
Temperature +- 1°C
hat, so schlechte Werte?
Mit den Dumps kann man ja auch hier mal vergleichen wie die Kalibrierungsparameter so aussehen.
Worst case haben alle China-Importe die Gleichen - was dann bedeuten würde, daß auf den Kalibrierungsprozess verzichtet wurde (und daher die Abweichungen kommen).
Meine 3 BMPs (davon zwei aus China) hatten nur 0,8° Abweichung. Dummerweise hat der Eine beim Kalibrieren der Luftfeuchte Flüssigkeit abbekommen, beim Anderen hats die Pegelwandler gegrillt, weil das Board andere Anschlüsse als das Display hat - und ich hab' nur auf die Farben geachtet - nicht die Beschriftung.
Mal ne andere Frage zum LCG...
Bei meinem gegrillten BME280 wird der On-Board Pegelwandler heiss, d.h. ich habe ständig Temperaturen um die 50°.
Obwohl ich dem LCG ein "set LCG.OLED LaCrossePairForSec 360 ignore_battery" verpasst habe, taucht der Sensor nicht auf. Die Daten selbst sind jedoch mit "verbose 5" im Log zu sehen:
LCG.OLED dispatch OK WS 2 4 5 237 12 255 255 255 255 255 255 255 255 0 3 239
Irgend eine Idee wo es da klemmt?
Zitat von: waschbaerbauch am 16 August 2016, 18:03:14
Kein Problem, ich wollte nur zur Sicherheit mal nachfragen ;)
Hat aber nichts geknallt als ich es vorhin verwegen ausprobiert habe :D
Das ist aber eine schöne Statusseite. Würdest du den Code bzw die Seite zur Verfügung stellen? :-)
Zitat von: SusisStrolch am 17 August 2016, 13:41:42
Irgend eine Idee wo es da klemmt?
Aktuell keine. Das hatten Andere aber auch schon. Das JeeLink Modul dispatch es ja laut Deinem Log das "OK WS 2 4 5 237 12 255 255 255 255 255 255 255 255 0 3 239"
Warum da kein Autocreate anspringt ist mir unklar.
Notfalls ein LaCrosse manuell mit ID 2 anlegen.
Zu den BMEs: ich muss mal einen separaten Test-Sketch machen, der zwei BMEs auf dem breadboard abfragt.
Das Fiasko ist: ich habe Berge von Kram, der Temperatur messen kann, aber nichts, vo dem ich sicher sagen kann, dass es die tatsächliche Temperatur liefert.
Ich muss mal mit einem BME280 zum Eichamt fahren ... ;D ;D ;D
Angehängt ein Plot (temp.png) mit den Werten von einem LGW, das einen DHT22 drauf hat und einem TX29DTH, der direkt daneben steht.
In der Konfiguration vom LGW ist folgende Korrektur gesetzt:
Temperature-correction: -3
Humidity-correction: +10
Das kommt ganz gut hin. Wie es bei "extremeren" Temperaturen aussieht, muss man aber noch abwarten.
Auf DHT22.png sieht man, dass der DHT22 die gleiche Temperatur wir das Dingsda im Hintergrund liefert, aber eine ganz andere Feuchte.
ZitatWorst case haben alle China-Importe die Gleichen - was dann bedeuten würde, daß auf den Kalibrierungsprozess verzichtet wurde
Der Gedanke ist grandios.
Zitat von: HCS am 17 August 2016, 14:19:55
Zu den BMEs: ich muss mal einen separaten Test-Sketch machen, der zwei BMEs auf dem breadboard abfragt.
Das Fiasko ist: ich habe Berge von Kram, der Temperatur messen kann, aber nichts, vo dem ich sicher sagen kann, dass es die tatsächliche Temperatur liefert.
Ich muss mal mit einem BME280 zum Eichamt fahren ... ;D ;D ;D
Hmm... wie wärs mit der zusätzlichen Implementierung des DS18B20? ;D
Den kann man problemloser kalibrieren (sofern im Metallgehäuse).
Eis/Salz-Mischung: -4°C
Eis/Wasser: 0°C
Fieberthermometer: ~36° (nein - nicht... in lauwarmem Wasser natürlich)
kochender Spiritus: ~72° (natürlich auf offener Flamme 8))
kochendes Wasser: ~ca. 100°
Damit hätte man ausreichend Messpunkte um den DS18B20 zu kalibrieren.
Und damit dann den BMP/BME zu vergleichen...
Edit:
sehe gerade (https://de.wikipedia.org/wiki/K%C3%A4ltemischung) daß man mit Wasser/Kochsalz auf unglaubliche -21° kommt. Da die Mischung stark gesättigt ist, kann man damit anschließend gleich die Luftfeuchte kalibrieren...
Zitat von: Chris_Worms am 17 August 2016, 14:05:07
Das ist aber eine schöne Statusseite. Würdest du den Code bzw die Seite zur Verfügung stellen? :-)
Ist zwar hier offtopic, aber ich dachte die Gateway Seite ist schon in meinem FTUI Post drin - wenn auch nicht jetzt diese aktuelle Version (damals noch JeeLink statt LaCrosseGateway) -> schau mal hier (https://forum.fhem.de/index.php/topic,37378.msg396065.html#msg396065), hier (https://forum.fhem.de/index.php/topic,37378.msg386691.html#msg386691) und hier (https://forum.fhem.de/index.php/topic,34233.msg386559.html#msg386559)
Zitat von: HCS am 17 August 2016, 10:08:43
Ich würde es allgemeiner halten:
"Falls das verwendete Breakout bereits PullUp-Widerstände für SDA und SCL enthält, können R???? und R???? entfallen."
Done.
Ach was mir grad einfällt - sollte noch wer RFM69 Radios benötigen - es gibt grad welche sehr günstig bei AliExpress (https://de.aliexpress.com/item/RFM69CW-HopeRF-868Mhz-Wireless-Transceiver-with-RFM12B-compatible-Footprint/32698808445.html)
Moin
Zwei kurze OT-Fragen:
@Waschbaerbauch
Wie bezahlst du bei Ali-Express? Mir war das bisher zu unheimlich mit der Kreditkarte!
@hcs
Du hast ja in Deinem Plot jeweils den aktuellen Wert stehen, wie geht das?
Danke und OT off
Gruss Christoph
Zitat von: pc1246 am 19 August 2016, 12:17:13
@hcs
Du hast ja in Deinem Plot jeweils den aktuellen Wert stehen, wie geht das?
attribut: "label" mit Wert "$data{currval1}::$data{currval2}::$data{currval3}::$data{currval4}::$data{currval5}::" definieren
Oben im Diagramm:
Temperatur <L1> °C
Feuchte <L2> rH
Zitat von: pc1246 am 19 August 2016, 12:17:13
Moin
Zwei kurze OT-Fragen:
@Waschbaerbauch
Wie bezahlst du bei Ali-Express? Mir war das bisher zu unheimlich mit der Kreditkarte!
Schon seit Jahren mit KK - noch nie Probleme gehabt - bei Paypal war das schon mal anders ..
Hallo Gemeinde
@Waschbaerbauch
ZitatAch was mir grad einfällt - sollte noch wer RFM69 Radios benötigen - es gibt grad welche sehr günstig bei AliExpress
ist der Verlinkte RFM69CW http://de.aliexpress.com/item/RFM69CW-HopeRF-868Mhz-Wireless-Transceiver-with-RFM12B-compatible-Footprint/32698808445.html?spm=2114.13010208.99999999.264.npwScR (http://de.aliexpress.com/item/RFM69CW-HopeRF-868Mhz-Wireless-Transceiver-with-RFM12B-compatible-Footprint/32698808445.html?spm=2114.13010208.99999999.264.npwScR)
schon der richtige?
Bzw. was ist der Unterschied zu diesem hier RFM69HW 868 Mhz + 20dBm HopeRF Wireless Transceiver (RFM69HW-868S2) für Remote/HM (//http:///HM)
Ich meine ausser dem Preis. 8)
Thomas
Zitat von: ThomasW am 19 August 2016, 13:06:44
Bzw. was ist der Unterschied zu diesem hier ...
- Der HW passt nicht auf die PeMue-Platine
- Der HW hat mehr Sendeleistung als in de-DE erlaubt
So - hab' jetzt mal 'nen 5er-Pack DS18B20 gebündelt und an einen ESPEasy gehängt.
Die DS18B20 sind nicht kalibriert. Streuung liegt bei +/- 0.1°C.
Der BME280 liegt so ca. 3°C über dem Mittelwert der DS18B20.
Wäre jetzt wirklich mal interessant, die Kalibrierwerte verschiedener BME's zu sammeln und zu vergleichen.
Ich bin gerade dabei, die Hardware-page für das Frontend zu bauen, da sind die Kalibrierdaten dann mit drauf.
Ist fast fertig, nur für den BMP180 fehlt es noch.
Ich hoffe, dass ich es am Wochenende fertig bekommen, dann haue ich die Version raus und wir können sammeln und vergleichen.
Schau mal Hardware1.png an, ob das so OK wäre.
Das sieht gut aus. Man muss keine Registerwerte shiften um einen Überblick zu bekommen.
Ich würde gerne die Differenz zwischen BME280 und dem Mittelwert der DS18B20 protokollieren. Anhand des Ergebnisses sollte man erkennen könne, ob eine einfache Offset-Anpassung reicht oder ob aufwändigere Massnahmen (prozentual oder über Geradenanpassung) notwendig sind, um Genauigkeiten im 0.5° Bereich zu erreichen.
Dummerweise sind die Messwerte der einzelnen Sensoren nicht zeitsynchron.
Hat jemand eine Idee, wie das geschickt im FHEM abgebildet werden kann?
Zitat von: SusisStrolch am 19 August 2016, 16:10:57
Hat jemand eine Idee, wie das geschickt im FHEM abgebildet werden kann?
Ich würde das mit event-min-interval (http://fhem.de/commandref#event-min-interval) machen ...
Gruß Peter
Hab's jetzt ganz brutal mit einem getriggerten userReadings für den BME gelöst. Da kann ich zur Not auch noch die Einzelwerte mit dem event-aggregator glätten.
attr BME280.1 userReadings delta:temperature.* { ReadingsVal("$name", "temperature", 0) - (
ReadingsVal("ESPEasy_ESP_Proto_4MB", "temperature.001D",0) +
ReadingsVal("ESPEasy_ESP_Proto_4MB", "temperature.009F",0) +
ReadingsVal("ESPEasy_ESP_Proto_4MB", "temperature.00C2",0) +
ReadingsVal("ESPEasy_ESP_Proto_4MB", "temperature.00DA",0) +
ReadingsVal("ESPEasy_ESP_Proto_4MB", "temperature.00E4",0) ) / 5;;
}
Morgen gehts dann ins Eisbad und unter den Fön.
Zitat von: HCS am 19 August 2016, 14:17:07
Ich bin gerade dabei, die Hardware-page für das Frontend zu bauen, da sind die Kalibrierdaten dann mit drauf.
Was aus meiner Sicht auch toll wäre (falls mit wenig Aufwand machbar) ist eine Art Debug Mode (im Frontend einstellbar), dass alle Werte der aufgelöteten Sensoren per KVP Protokoll rausgeschickt werden. Dann könnten wir sämtliche auf dem LGW verbauten Temperaturen/Luftfeuchtigkeiten/Drücke vergleichen ...
Gruß PeMue
Hmm, anscheinend gibts noch ein kleines Problem in der aktuellen Software (1.21).
Wenn beim BME280 die Luftfeuchte auf 100% geht, werden keine WS-Daten mehr gesendet.
Auf dem Display werden sie jedoch noch angezeit (OLED mode=tph).
Daten werden erst dann wieder gesendet, wenn die rH auf 99% zurück ist (siehe 11:34:31 im Log).
11:27:00: [LaCrosseITPlusReader.Gateway.1.21 (1=RFM69 f:868300 r:20000) + BME280 + SC16IS750 + OLED {IP=192.168.254.87}]
...
11:31:22: OK VALUES LGW 9171467 UpTimeSeconds=600,UpTimeText=0Tg. 0Std. 10Min. 0Sek. ,WIFI=xxxxxxxxxxx,MacAddress=5C:CF:7F:8B:F2:0B,ChipID=9171467,ReceivedFrames=242,FramesPerMinute=37,RSSI=-74,FreeHeap=21128,Version=1.21,LD.Min=0,LD.Avg=0,LD.Max=36,OLED=on
11:31:23: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 92 D4 00 08 48 33 79 B2 E8 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 06 80 57]
11:31:25: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 29 3 171 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 5C F7 03 AB 0A 7A 6F 20 F8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 08 BF 97]
11:31:26: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF 86 00 0F 9F FF 13 EC A8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 09 BC 77]
11:31:28: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 92 D8 00 08 48 33 79 B2 E8 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0F 2A 57]
11:31:30: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 29 3 169 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 5E CC 03 A9 0A 7A 6F 22 C8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 07 67 07]
11:31:31: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF 8D 00 0F 9F FF 13 ED 18 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0A 1A 37]
11:31:33: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 92 DC 00 08 48 33 79 B2 F8 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 06 33 D7]
11:31:36: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 29 3 169 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 60 A2 03 A9 0A 7A 6F 24 A8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 04 F3 77]
11:31:36: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF 95 00 0F 9F FF 13 ED 98 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 07 99 87]
11:31:38: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 92 E0 00 08 48 33 79 B2 F8 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 07 49 17]
11:31:40: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 29 3 170 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 62 77 03 AA 0A 7A 6F 26 78 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 09 42 C7]
11:31:41: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF 9C 00 0F 9F FF 13 EE 08 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0A 8D 07]
11:31:43: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 7 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 92 E4 00 07 48 33 79 B2 F8 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0F 0A 07]
11:31:45: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 30 3 172 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 64 4E 03 AC 0A 7A 6F 28 48 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 05 8C 07]
11:31:46: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF A4 00 0F 9F FF 13 EE 88 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 08 6E 37]
11:31:49: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 92 E7 00 08 48 33 79 B2 F8 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 02 C5 D7]
11:31:52: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 30 3 183 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 66 25 03 B7 0A 7A 6F 2A 28 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 07 F0 87]
11:31:52: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF AB 00 0F 9F FF 13 EE F8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0A 51 57]
11:31:54: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 7 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 92 EB 00 07 48 33 79 B3 08 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 01 35 F7]
11:31:56: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 30 3 180 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 67 FF 03 B4 0A 7A 6F 2B F8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 04 0C 47]
11:31:57: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF B3 00 0F 9F FF 13 EF 78 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0F 2D 87]
11:31:59: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 92 EF 00 08 48 33 79 B3 08 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 09 76 E7]
11:32:01: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 30 3 177 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 69 DA 03 B1 0A 7A 6F 2D D8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0B 89 27]
11:32:02: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF BA 00 0F 9F FF 13 EF E8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0A 38 37]
11:32:04: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 92 F2 00 08 48 33 79 B3 08 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 06 35 67]
11:32:06: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 30 3 178 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 6B B4 03 B2 0A 7A 6F 2F B8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 08 33 47]
11:32:07: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF C2 00 0F 9F FF 13 F0 68 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0A 86 F7]
11:32:09: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 92 F6 00 08 48 33 79 B3 08 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 01 53 67]
11:32:11: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 30 3 175 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 6D 8B 03 AF 0A 7A 6F 31 88 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0A BC E7]
11:32:12: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF C9 00 0F 9F FF 13 F0 D8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 01 DF D7]
11:32:14: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 7 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 92 FA 00 07 48 33 79 B3 18 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 09 A3 F7]
11:32:16: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 30 3 171 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 6F 61 03 AB 0A 7A 6F 33 58 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 00 D9 F7]
11:32:17: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF D1 00 0F 9F FF 13 F1 58 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 04 A3 07]
11:32:19: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 7 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 92 FD 00 07 48 33 79 B3 18 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0C 2F 37]
11:32:21: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 30 3 186 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 71 3B 03 BA 0A 7A 6F 35 38 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0C D6 A7]
11:32:22: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF D8 00 0F 9F FF 13 F1 C8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 01 B6 B7]
11:32:24: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 01 00 08 48 33 79 B3 18 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0A 37 B7]
11:32:26: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 31 3 187 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 73 18 03 BB 0A 7A 6F 37 18 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0D F9 87]
11:32:27: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF E0 00 0F 9F FF 13 F2 48 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0B 54 B7]
11:32:29: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 05 00 08 48 33 79 B3 18 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0D 51 B7]
11:32:31: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 31 3 177 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 74 F4 03 B1 0A 7A 6F 38 F8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 06 AE 57]
11:32:32: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF E7 00 0F 9F FF 13 F2 B8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 03 58 27]
11:32:34: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 09 00 08 48 33 79 B3 28 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 07 7B A7]
11:32:36: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 31 3 181 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 76 CE 03 B5 0A 7A 6F 3A C8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0B C7 F7]
11:32:37: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF EF 00 0F 9F FF 13 F3 38 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 01 94 B7]
11:32:39: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 0D 00 08 48 33 79 B3 28 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 00 1D A7]
11:32:41: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 31 3 196 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 78 AE 03 C4 0A 7A 6F 3C A8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0F 39 77]
11:32:42: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF F6 00 0F 9F FF 13 F3 A8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 03 31 47]
11:32:44: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 11 00 08 48 33 79 B3 28 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0E 07 E7]
11:32:46: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 31 3 185 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 7A 8D 03 B9 0A 7A 6F 3E 88 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0C 0D 67]
11:32:47: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 BF FE 00 0F 9F FF 13 F4 28 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 01 FF A7]
11:32:49: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 15 00 08 48 33 79 B3 28 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 09 61 E7]
11:32:51: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 31 3 177 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 7C 67 03 B1 0A 7A 6F 40 68 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 02 E2 87]
11:32:52: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 06 00 0F 9F FF 13 F4 A8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 03 47 A7]
11:32:54: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 19 00 08 48 33 79 B3 38 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0E B4 67]
11:32:56: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 31 3 185 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 7E 41 03 B9 0A 7A 6F 42 38 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 00 40 27]
11:32:57: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 0D 00 0F 9F FF 13 F5 18 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 00 E1 E7]
11:32:59: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 7 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 1D 00 07 48 33 79 B3 38 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 06 F7 77]
11:33:01: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 32 3 186 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 80 1E 03 BA 0A 7A 6F 44 18 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 00 01 E7]
11:33:02: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 15 00 0F 9F FF 13 F5 98 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0D 62 57]
11:33:04: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 21 00 08 48 33 79 B3 38 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 08 A8 A7]
11:33:06: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 32 3 192 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 81 FC 03 C0 0A 7A 6F 45 F8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0E 66 47]
11:33:07: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 1C 00 0F 9F FF 13 F6 08 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 00 76 D7]
11:33:09: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 25 00 08 48 33 79 B3 38 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0F CE A7]
11:33:11: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 32 3 182 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 83 D8 03 B6 0A 7A 6F 47 D8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0A 4B 57]
11:33:12: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 24 00 0F 9F FF 13 F6 88 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 02 95 E7]
11:33:14: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 29 00 08 48 33 79 B3 48 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0F 1B 07]
11:33:16: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 32 3 181 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 85 B4 03 B5 0A 7A 6F 49 B8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 07 57 B7]
11:33:17: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 2B 00 0F 9F FF 13 F6 F8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 00 AA 87]
11:33:19: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 2D 00 08 48 33 79 B3 48 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 08 7D 07]
11:33:21: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 32 3 194 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 87 93 03 C2 0A 7A 6F 4B 98 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 06 3C 37]
11:33:22: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 33 00 0F 9F FF 13 F7 78 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 05 D6 57]
11:33:24: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 31 00 08 48 33 79 B3 48 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 06 67 47]
11:33:26: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 32 3 183 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 89 70 03 B7 0A 7A 6F 4D 68 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0A 9A E7]
11:33:27: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 3A 00 0F 9F FF 13 F7 E8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 00 C3 E7]
11:33:29: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 35 00 08 48 33 79 B3 48 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 01 01 47]
11:33:31: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 32 3 187 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 8B 4E 03 BB 0A 7A 6F 4F 48 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 05 8B 77]
11:33:32: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 42 00 0F 9F FF 13 F8 68 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 04 E4 17]
11:33:34: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 39 00 08 48 33 79 B3 58 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 06 D4 C7]
11:33:36: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 32 3 185 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 8D 29 03 B9 0A 7A 6F 51 28 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 07 84 37]
11:33:37: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 49 00 0F 9F FF 13 F8 D8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0F BD 37]
11:33:39: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 3D 00 08 48 33 79 B3 58 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 01 B2 C7]
11:33:41: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 33 3 183 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 8F 06 03 B7 0A 7A 6F 53 08 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 00 24 07]
11:33:42: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 51 00 0F 9F FF 13 F9 58 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0A C1 E7]
11:33:44: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 41 00 08 48 33 79 B3 58 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0E 09 17]
11:33:46: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 33 3 188 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 90 E3 03 BC 0A 7A 6F 54 E8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0C 9C 87]
11:33:47: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 58 00 0F 9F FF 13 F9 C8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0F D4 57]
11:33:49: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 45 00 08 48 33 79 B3 58 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 09 6F 17]
11:33:51: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 33 3 183 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 92 BF 03 B7 0A 7A 6F 56 B8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0C A4 87]
11:33:52: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 60 00 0F 9F FF 13 FA 48 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 05 36 57]
11:33:54: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 49 00 08 48 33 79 B3 68 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 03 45 07]
11:33:56: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 33 3 189 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 94 9C 03 BD 0A 7A 6F 58 98 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 02 0B E7]
11:33:57: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 67 00 0F 9F FF 13 FA B8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0D 3A C7]
11:33:59: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 7 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 4D 00 07 48 33 79 B3 68 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0B 06 17]
11:34:01: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 33 3 179 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 96 77 03 B3 0A 7A 6F 5A 78 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0F 8E B7]
11:34:02: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 6F 00 0F 9F FF 13 FB 38 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0F F6 57]
11:34:04: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 50 00 08 48 33 79 B3 68 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0B 60 87]
11:34:06: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 33 3 189 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 98 56 03 BD 0A 7A 6F 5C 58 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 05 F8 17]
11:34:07: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 76 00 0F 9F FF 13 FB A8 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0D 53 A7]
11:34:09: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 54 00 08 48 33 79 B3 68 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0C 06 87]
11:34:11: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 33 3 188 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 9A 33 03 BC 0A 7A 6F 5E 38 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 04 3C 97]
11:34:12: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 7E 00 0F 9F FF 13 FC 28 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0F 9D 47]
11:34:14: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 7 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 58 00 07 48 33 79 B3 68 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0A 89 97]
11:34:16: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 34 3 186 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 9C 10 03 BA 0A 7A 6F 60 08 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0E 96 C7]
11:34:17: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 85 00 0F 9F FF 13 FC 98 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0F 57 87]
11:34:19: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 5C 00 08 48 33 79 B3 78 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0C B5 07]
11:34:21: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 34 3 179 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 9D E9 03 B3 0A 7A 6F 61 E8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 06 59 C7]
11:34:22: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 8D 00 0F 9F FF 13 FD 18 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0D 9B 17]
11:34:24: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 8 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 60 00 08 48 33 79 B3 78 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 0D CF C7]
11:34:26: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 34 3 183 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 9F C5 03 B7 0A 7A 6F 63 C8 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 06 2A A7]
11:34:27: OK 22 20 135 3 222 240 0 3 222 240 0 0 45 103 24 0 15 159 255 1 0 [14 87 F0 00 00 00 F0 00 00 00 00 0E 79 C0 94 00 0F 9F FF 13 FD 88 C4 19 0C A9 18 88 3E 3D E0 00 00 00 27 3D E0 18 0F 3E E7]
11:34:29: OK 22 32 248 3 222 240 0 3 222 240 0 0 67 182 131 0 7 72 51 5 0 [20 F8 F0 00 00 00 F0 00 00 00 00 08 36 93 64 00 07 48 33 79 B3 78 60 86 87 48 C8 77 B9 3D E0 00 00 00 3B 3D E0 58 05 8C D7]
11:34:31: OK 22 26 10 3 222 240 0 3 222 240 0 0 35 252 34 3 177 10 122 1 0 [1A 0A F0 00 00 00 F0 00 00 00 00 0A 09 A1 9F 03 B1 0A 7A 6F 65 98 4A 45 85 AF E7 31 2F 3D E0 00 00 00 1F 3D E0 18 0A 60 F7]
11:34:31: OK WS 2 4 4 230 98 255 255 255 255 255 255 255 255 0 3 237
Könnte man in WSBase.cpp nicht den Debug-Mode auswerten und - falls im Debug Mode - den Limit-Check für Temperatur und Luftfeuchte überspringen?
Edit:
Und im Sketch vielleicht die Debug.h hinzufügen oder das #include aus der PCA301 entfernen?
Ach ja - wg. Kalibrierung...
Es reicht nicht, den BME/BMP in ein Tütchen zu packen und dann in die Eis/Wasser-Mischung zu legen.
Man sollte ein (vorher 2 Std. bei 120° getrocknetes) Päckchen SilikaGel mit eintüten, da es andernfalls zu Kondensation am Sensor kommt (Taupunkt...).
Nach so einem Unfall hilft nur die "Reconditioning Procedure":
2 Std bei 120° backen
24 Std über einer gesättigte Salzlösung (75%rH) rehydrieren...
Hallo,
ich habe bei einem Gateway noch folgendes im Setup stehen (was ich nicht verstehe):
PCA301 (normally no need to change it)
Plugs: 055708=4
Das ist auch das Gateway, das die PCA301 "belauscht". Brauche ich das? Und wenn ja, was bedeutet das?
Danke + Gruß
PeMue
Zitat von: PeMue am 20 August 2016, 11:08:29
... Debug Mode (im Frontend einstellbar), dass alle Werte der aufgelöteten Sensoren per KVP Protokoll rausgeschickt werden. Dann könnten wir sämtliche auf dem LGW verbauten Temperaturen/Luftfeuchtigkeiten/Drücke vergleichen ...
Ich befürchte, dass das einiges an Aufwand bedeutet.
Aber ich bin auch nicht sicher, ob ich das LGW jetzt zu einer Sensor-Test-und-kalibier-Plattform ausbauen will.
Muss ich mir mal genauer anschauen, was das überhaupt bedeutet (mehrere Internal-Sensor-IDs konfigurieren, ...)
Zitat von: SusisStrolch am 20 August 2016, 14:06:02
24 Std über einer gesättigte Salzlösung (75%rH) rehydrieren...
Bin auch schon ganz dehydriert, muss erst mal ein Bier trinken ;D ;D ;D
Zitat von: SusisStrolch am 20 August 2016, 12:41:50
Könnte man in WSBase.cpp nicht den Debug-Mode auswerten und - falls im Debug Mode - den Limit-Check für Temperatur und Luftfeuchte überspringen?
Ich versuche gerade drauf zu kommen, warum 100% nicht als gültig betrachtet wird. Ich glaube, weil LaCrosse sagt, dass der Messbereich für die Feuchte von 1% bis 99% ist.
Falls niemand einen guten Grund kennt, warum 100% nicht gehen darf, setzte ich die Grenze auf 100%
Zitat von: SusisStrolch am 20 August 2016, 12:41:50
Und im Sketch vielleicht die Debug.h hinzufügen oder das #include aus der PCA301 entfernen?
Ich nehme sie raus.
Zitat von: PeMue am 20 August 2016, 19:18:36
Plugs: 055708=4
Brauche ich das? Und wenn ja, was bedeutet das?
Ja, wird gebraucht. Das LGW muss sich (nicht flüchtig) die Zuordnung von Kanal und ID der PCAs merken.
Plugs enthält die Liste der PCA301 (ID, in diesem Fall 055708), die das LGW gehört hat und die Kanäle (in diesem Fall 4), die es für die jeweilige ID vergeben hat. Wenn man mehrere PCAs hat, dann sind die hier alle aufgelistet.
Normalerweise muss man das nicht selbst pflegen oder ändern, aber wenn man z.B. die PCA mit der ID 055708 in die Tonne geworfen hat, weil sie defekt ist, kann man den Eintrag hier löschen, um den Kanal wieder verfügbar zu haben.
Das ist das übrigens das Verfahren, das die original PCA301 Basisstation auch macht. Sie vergibt für neu gehörte Dosen den nächsten freien Kanal.
Erst mal die gute Nachricht (der Rest im nächsten Post dann ...)
Der DHT22 scheint mit dem geänderten Timing der 1.21 nun stabil zu laufen.
Auf meinem 209er LGW liefert er seit einer Woche konstant Werte.
Am 16. August habe ich im LGW die neu eingebauten Korrekturwerte gesetzt (Temperature-correction: -3 und Humidity-correction: +10), sieht man schön, ab da passen die Werte zu dem TX29DTH, der direkt daneben steht. Ob das mit den Werten im Raum exakt übersinstimmt ist dann nochmal eine andere Frage.
Die heftigen Korrekturwerte sind wohl darin begründet, dass der DHT22 zwar in einer Gehäuseöffnung sitzt, aber wohl trotzdem von hinten etwas warm bekommt, da es im geschlossenen Gehäuse zu einer Erwärmung kommt.
Die Anordnung kann man auf dem Bild im Link sehen:
https://forum.fhem.de/index.php?action=dlattach;topic=45594.0;attach=51819
https://forum.fhem.de/index.php?action=dlattach;topic=45594.0;attach=51823
Nun zum BME280:
Ich habe einen Testaufbau mit zwei BME280 gemacht (siehe Aufbau.png)
Der linke BME (große Platine mit dem Jumper) hat die Adresse 0x77 und der rechte (Lila) ist 0x76
Die Test-Frimware, die ich gebastelt habe, misst beide BMEs jeweils nacheinander mit drei verschiedenen Libraries:
ADA: Adafruit-Lib (https://github.com/adafruit/Adafruit_BME280_Library)
MOD: embeddedadventures-Lib (https://github.com/embeddedadventures/BME280)
LGW: die Lib, die das LGW verwendet
Die Messwerte werden auf dem Display angezeigt (der Wert der LGW-Lib) und komplett auf einem Web-Frontend ausgegeben, von dem ich die nachfolgenden Ergebnisse genommen habe.
Beispielzeile:
0x77 MOD T:24.0 H:53 P:1021
0x77: Wert stammt vom linken BME
MOD: der Wert wurde von der embeddedadventures-Lib geliefert
T:24.0 H:53 P:1021: Temperatur, Feuchte und Luftdruck auf meine Höhe gerechnet
Kalibrierwerte der BMEs:
0x77 Calibration: T1:28230 T2:26332 T3:50 H1:75 H2:357 H3:0 H4:331 H5:0 H6:30 P1:38471 P2:-10836 P3:3024 P4:8996 P5:-34 P6:-7 P7:9900 P8:-10230 P9:4285
0x76 Calibration: T1:28268 T2:26147 T3:50 H1:75 H2:360 H3:0 H4:323 H5:0 H6:30 P1:37934 P2:-10868 P3:3024 P4:9986 P5:-10 P6:-7 P7:9900 P8:-10230 P9:4285
Werte, nachdem sich der Testaufbau einige Zeit an den Raum gewöhnen konnte:
0x77 ADA T:24.0 H:54 P:1021
0x77 MOD T:24.0 H:54 P:1021
0x77 LGW T:24.0 H:54 P:1021
0x76 ADA T:24.0 H:60 P:1021
0x76 MOD T:24.0 H:60 P:1021
0x76 LGW T:24.0 H:60 P:1021
Die Sensoren mal großflächig angehaucht:
0x77 ADA T:27.1 H:85 P:1022
0x77 MOD T:27.1 H:85 P:1022
0x77 LGW T:27.1 H:85 P:1022
0x76 ADA T:27.2 H:78 P:1022
0x76 MOD T:27.2 H:78 P:1022
0x76 LGW T:27.2 H:78 P:1022
Den Testaufbau mit einem Fön erwärmt:
0x77 ADA T:62.9 H:9 P:1021
0x77 MOD T:62.9 H:9 P:1021
0x77 LGW T:62.9 H:9 P:1021
0x76 ADA T:61.3 H:24 P:1021
0x76 MOD T:61.3 H:24 P:1021
0x76 LGW T:61.3 H:24 P:1021
Nach dem Fönen eine Stunde abkühlen lassen:
0x77 ADA T:24.5 H:51 P:1022
0x77 MOD T:24.5 H:51 P:1022
0x77 LGW T:24.5 H:51 P:1022
0x76 ADA T:24.5 H:59 P:1022
0x76 MOD T:24.5 H:59 P:1022
0x76 LGW T:24.5 H:59 P:1022
Meine Erkenntnisse:
Alle drei BME280, die ich besitze, haben unterschiedliche Kalibrierdaten, was erst mal ein gutes Zeichen ist.
Alle drei Libraries sind sich bezüglich der Werte einig, was auch gut ist.
Der Luftdruck stimmt durchweg sehr gut mit dem Luftdruck, denn die Wetterdienste für meinen Ort aktuell melden, überein -> ist also gut.
Die Temperatur, die die beiden Sensoren liefern, deckt sich recht gut, die Abweichung beim Fönen kann durchaus durch unterschiedliche Erwärmung wegen unterschiedlicher Bauform kommen (oder auch nicht ?).
Die Feuchte passt nicht. Da liegen sie bei den verschiedene Test in unterschiedlichen Richtungen auseinander.
Völlig irre ist, wenn man noch mehr vergleicht:
BME280 0x77 24.0 °C 54% rH
BME280 0x76 24.0 °C 60% rH
Das Billig-Messdingsda im Hintergrund auf dem Bild: 23 °C 52% rH
30.3155.WD 50cm daneben: 22.6 °C 60% rH
TX25IT interner Sensor: 23,2 °C
TX25IT externer Sensor: 24,4 °C
Weitere Erkenntnisse darf sich dann gerne jeder selbst noch aus den Messwerten ableiten.
Nach einigen Stunden im Kühlschrank:
0x77 ADA T:9.6 H:63 P:1024
0x77 MOD T:9.6 H:63 P:1024
0x77 LGW T:9.6 H:63 P:1024
0x76 ADA T:9.9 H:67 P:1024
0x76 MOD T:9.9 H:67 P:1024
0x76 LGW T:9.9 H:67 P:1024
Das Anzeigedingsda, dass immer dabei steht, meint 9 °C und 58%
Der Kühlschrank ist der Ansicht, dass es 7 °C sein sollten.
Offizielle Release wird heute nicht mehr.
Dass wir schon mal Kalibrierdaten vergleichen können anbei eine 1.22 Beta.
Ok - hier meine:
192.168.254.87 T1:27969 T2:25830 T3:50 H1:75 H2:355 H3:0 H4:337 H5:0 H6:30 P1:36041 P2:-10887 P3:3024 P4:6450 P5:-61 P6:-7 P7:9900 P8:-10230 P9:4284
192.168.254.89 T1:28213 T2:26878 T3:50 H1:75 H2:363 H3:0 H4:317 H5:0 H6:30 P1:37953 P2:-10687 P3:3024 P4:6315 P5:0 P6:-7 P7:9900 P8:-10230 P9:4285
Hmm, könnte man da noch die Raw-Values für T,P und H mit hinzunehmen?
Jetzt brauchen wir jemanden, der sie sammelt und vergleicht.
T1:28118 T2:26034 T3:50 H1:75 H2:363 H3:0 H4:315 H5:0 H6:30 P1:38073 P2:-10914 P3:3024 P4:9287 P5:58 P6:-7 P7:9900 P8:-10230 P9:4285
T1:28230 T2:26332 T3:50 H1:75 H2:357 H3:0 H4:331 H5:0 H6:30 P1:38471 P2:-10836 P3:3024 P4:8996 P5:-34 P6:-7 P7:9900 P8:-10230 P9:4285
T1:28268 T2:26147 T3:50 H1:75 H2:360 H3:0 H4:323 H5:0 H6:30 P1:37934 P2:-10868 P3:3024 P4:9986 P5:-10 P6:-7 P7:9900 P8:-10230 P9:4285
Zitat von: HCS am 19 August 2016, 12:32:33
attribut: "label" mit Wert "$data{currval1}::$data{currval2}::$data{currval3}::$data{currval4}::$data{currval5}::" definieren
Oben im Diagramm:
Temperatur <L1> °C
Feuchte <L2> rH
Hallo HCS
irgendwie hab ich das mit dem Label nicht verstanden.
Kannst du bitte einmal die ganze Zeile dies Beispiels posten?
Gruß Dieter
Zitat von: dieter114 am 22 August 2016, 17:43:55
Kannst du bitte einmal die ganze Zeile dies Beispiels posten?
http://www.fhemwiki.de/wiki/Creating_Plots
Die ganze Zeile der Attrubut-Definition
attr <plotName> label $data{currval1}::$data{currval2}::$data{currval3}::$data{currval4}::$data{currval5}::Siehe Anhang
Aber für einen Lehrgang in SVG ist das hier eigentlich der falsche Thread
Hallo,
hab das ganze jetzt auch mal auf einem Breadboard zusammengesteckt.
Habe 2 TFA IT+ Sensoren hier rum liegen, die ich mal testen wollte.
Also Batterien rein in den ersten, wird auch gleich gefunden und ein Device angelegt.
Nur der zweite will nicht so recht. Wird kein Device angelegt.
Anbei mal der Log vom LaCrosseGateway
LaCrosseGateway V1.20 LaCrosseGateway (192.168.1.98)
Home Setup OTA-Update Log Help Logout Reboot
Command: Enable logging
20:03:33: OK 9 8 129 4 220 106 [92 26 44 6A 78]
20:03:34: OK 9 8 1 4 180 106 [92 06 04 6A 88]
20:03:37: OK 9 8 129 4 220 106 [92 26 44 6A 78]
20:03:38: OK 9 8 1 4 180 106 [92 06 04 6A 88]
20:03:41: OK 9 8 129 4 221 106 [92 26 45 6A 8C]
20:03:42: OK VALUES LGW 759886 UpTimeSeconds=550,UpTimeText=0Tg. 0Std. 9Min. 10Sek. ,WIFI=WLAN-110C31,ReceivedFrames=136,FramesPerMinute=17,RSSI=-86,FreeHeap=21672,LD.Min=0,LD.Avg=0,LD.Max=85,OLED=none
20:03:42: OK 9 8 1 4 180 106 [92 06 04 6A 88]
20:03:45: OK 9 8 129 4 222 106 [92 26 46 6A A1]
20:03:46: OK 9 8 1 4 180 106 [92 06 04 6A 88]
20:03:49: OK 9 8 129 4 222 106 [92 26 46 6A A1]
20:03:50: OK 9 8 1 4 180 106 [92 06 04 6A 88]
20:03:52: OK VALUES LGW 759886 UpTimeSeconds=560,UpTimeText=0Tg. 0Std. 9Min. 20Sek. ,WIFI=WLAN-110C31,ReceivedFrames=141,FramesPerMinute=20,RSSI=-84,FreeHeap=21672,LD.Min=0,LD.Avg=0,LD.Max=86,OLED=none
20:03:53: OK 9 8 129 4 223 106 [92 26 47 6A 55]
20:03:55: OK 9 8 1 4 180 106 [92 06 04 6A 88]
20:03:57: OK 9 8 129 4 223 106 [92 26 47 6A 55]
20:03:59: OK 9 8 1 4 180 106 [92 06 04 6A 88]
20:04:01: OK 9 8 129 4 224 106 [92 26 48 6A CC]
20:04:02: OK VALUES LGW 759886 UpTimeSeconds=570,UpTimeText=0Tg. 0Std. 9Min. 30Sek. ,WIFI=WLAN-110C31,ReceivedFrames=146,FramesPerMinute=22,RSSI=-85,FreeHeap=21672,LD.Min=0,LD.Avg=0,LD.Max=87,OLED=none
20:04:02: OK 9 8 1 4 181 106 [92 06 05 6A 7C]
20:04:05: OK 9 8 129 4 225 106 [92 26 49 6A 38]
20:04:06: OK 9 8 1 4 180 106 [92 06 04 6A 88]
20:04:09: OK 9 8 129 4 225 106 [92 26 49 6A 38]
20:04:10: OK 9 8 1 4 180 106 [92 06 04 6A 88]
20:04:12: OK VALUES LGW 759886 UpTimeSeconds=580,UpTimeText=0Tg. 0Std. 9Min. 40Sek. ,WIFI=WLAN-110C31,ReceivedFrames=151,FramesPerMinute=25,RSSI=-84,FreeHeap=21672,LD.Min=0,LD.Avg=0,LD.Max=107,OLED=none
20:04:13: OK 9 8 129 4 225 106 [92 26 49 6A 38]
20:04:14: OK 9 8 1 4 180 106 [92 06 04 6A 88]
20:04:17: OK 9 8 129 4 226 106 [92 26 50 6A 95]
20:04:19: OK 9 8 1 4 181 106 [92 06 05 6A 7C]
20:04:21: OK 9 8 129 4 226 106 [92 26 50 6A 95]
20:04:22: OK VALUES LGW 759886 UpTimeSeconds=590,UpTimeText=0Tg. 0Std. 9Min. 50Sek. ,WIFI=WLAN-110C31,ReceivedFrames=156,FramesPerMinute=27,RSSI=-85,FreeHeap=21504,LD.Min=0,LD.Avg=0,LD.Max=100,OLED=none
20:04:23: OK 9 8 1 4 181 106 [92 06 05 6A 7C]
20:04:25: OK 9 8 129 4 227 106 [92 26 51 6A 61]
20:04:26: OK 9 8 1 4 180 106 [92 06 04 6A 88]
20:04:30: OK 9 8 129 4 227 106 [92 26 51 6A 61]
20:04:31: OK 9 8 1 4 180 106 [92 06 04 6A 88]
20:04:32: OK VALUES LGW 759886 UpTimeSeconds=600,UpTimeText=0Tg. 0Std. 10Min. 0Sek. ,WIFI=WLAN-110C31,ReceivedFrames=161,FramesPerMinute=30,RSSI=-85,FreeHeap=21504,LD.Min=0,LD.Avg=0,LD.Max=83,OLED=none
20:04:34: OK 9 8 129 4 227 106 [92 26 51 6A 61]
20:04:35: OK 9 8 1 4 180 106 [92 06 04 6A 88]
Debug log: Scroll Filter: 27 rows
20:01:42: This is line 5 of void setup(void)
20:01:42: LaCrosseITPlusReader.Gateway V1.20
20:01:42: Free heap: 24584 Flash size: 4194304 SDK: 1.5.3(aec24ac9)
20:01:42: Reset: External System
20:01:42: Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
20:01:42: Read settings
20:01:42: Starting I2C with 400 kHz
20:01:42: Starting wifi
20:01:42: Start WIFI_STA
20:01:42: HostName is: LaCrosseGateway
20:01:42: Using static IP
20:01:42: IP: 192.168.1.98
20:01:42: Mask: 255.255.255.0
20:01:42: Gateway: 192.168.1.1
20:01:42: Trying to connect to an AP
20:01:42: ......
20:01:42: connected :-)
20:01:42: SSID: WLAN-110C31
20:01:42: IP: 192.168.1.98
20:01:42: Starting frontend
20:01:42: Starting OTA
20:01:42: Starting data port 1 on 81
20:01:42: Searching RFMs and Sensors
20:01:42: Radio #1 found: RFM69
20:01:42: Sending init String to FHEM
20:01:42: Setup completely done
20:01:42: DataPort: #81 Client connected, IP=192.168.1.148 Port=53150
Theoretisch müsste doch jeder eine eigene ID bekommen. Doch meine zwei senden ihre Werte an das eine Device, welches angelegt wurde.
Also springt der Temp.Wert ständig zwischen innen und außen hin und her...
Hier noch der Teil aus der fhem.cfg
define myJeeLink JeeLink 192.168.1.98:81
attr myJeeLink flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
define KeyValueProtocol_LGW_759886 KeyValueProtocol LGW 759886
attr KeyValueProtocol_LGW_759886 IODev myJeeLink
attr KeyValueProtocol_LGW_759886 room KeyValueProtocol
define LaCrosse_08 LaCrosse 08
attr LaCrosse_08 IODev myJeeLink
attr LaCrosse_08 room LaCrosse
evtl. hat ja jemand einen Tipp
Gruß mattes
Anbei meine Daten (ich wollte jetzt nicht alle BME's BMP's rausholen, dann wäre ich vermutlich bis morgen früh noch nicht fertig :D)
Aufbau 1 (BME280 und BMP180 direkt nebeneinander)
BME280 OK T1:28254 T2:26397 T3:50 H1:75 H2:366 H3:0 H4:309 H5:0 H6:30 P1:38223 P2:-10805 P3:3024 P4:7170 P5:-82 P6:-7 P7:9900 P8:-10230 P9:4285
BMP180 OK AC1:8195 AC2:-1131 AC3:-13990 AC4:33698 AC5:25861 AC6:20326 B1:6515 B2:42 MB:-32768 MC:-11786 MD:2296
Aufbau 2 (ein zweiter BME280 - gleiche Position gleiche Stelle)
BME280 OK T1:28080 T2:26436 T3:50 H1:75 H2:355 H3:0 H4:336 H5:0 H6:30 P1:38436 P2:-10747 P3:3024 P4:6546 P5:-73 P6:-7 P7:9900 P8:-10230 P9:4285
Da kann ich ja mal versuchen, alle selber aufgelöteten BME280 zu testen ...
Werde dann mal sammeln gehen ;D
Gruß Peter
Zitat von: mattes1007 am 22 August 2016, 20:21:52
Theoretisch müsste doch jeder eine eigene ID bekommen.
Nicht unbedingt. Es gibt Sensoren, die eine feste ID haben, ich glaube TX37 ist so einer.
Batterien raus, eine Minute warten und wieder rein, ob sie dann eine andere ID haben.
Willst Du uns noch verraten, was für Sensoren das sind?
Zitat von: HCS am 22 August 2016, 21:32:42
Nicht unbedingt. Es gibt Sensoren, die eine feste ID haben, ich glaube TX37 ist so einer.
Batterien raus, eine Minute warten und wieder rein, ob sie dann eine andere ID haben.
Willst Du uns noch verraten, was für Sensoren das sind?
Das mit den Batterien hab ich schon zig mal versucht. Sind so kleine Sensoren ohne Display. Steht nur drauf IT+, TFA Dostmann,
V000R1
Ich würde ja die Daten sammeln. Allerdings scheint es wenig sinnvoll wenn nur die Calibration Values betrachtet werden.
Da finden wir nur die Streuung während der Fertigung / Kalibrierung heraus.
Die Temperatur wird ja (in 0ter Näherung) aus T2 * T' + T3 * T'² berechnet. T' ist der Wert den der AD-Wandler im BME/BMP liefert ( - T1).
(Gilt für beide Sensoren - beim BMP180 ist nur die Formel umgestellt)
Druck und Luftfeuchte sind da deutlich komplizierter.
Um da was genaueres sagen zu können bräuchte man meiner Meinung nach mindestens noch die Raw-Werte sowie die "kalibrierten".
Hab grad nen lustigen Fehler im BME280 Datenblatt gefunden:
1.7 Temperature sensor specification
Parameter Symbol Condition Min Typ Max Unit
Operating range T Operational -40 25 85 °C
Full accuracy 2. 0 3.65 °C
Und einen hätte ich noch... nur zum Probieren (kann momentan nicht selbst, da ich die ganze Woche auf Dienstreise bin).
Der BME wird mit folgenden Parametern initialisiert:
Humidity: oversampling x4
ctrl_meas: 0x3f
001 111 11
| | +--- mode: normal
| +----- oversampling ×16 (pressure)
+--------- oversampling ×1 (temperature)
Für das "config"-Register habe ich nix gesehen.
Das Datenblatt empfiehlt für Wettermessungen
Sensor mode: forced mode, 1 sample / minute
Oversampling settings: pressure ×1, temperature ×1, humidity ×1
IIR filter settings: filter off
In erster Näherung (ohne Forced Mode) könnte man ja mal zum Einen die kurzen Sampling-Parameter probieren, zum Anderen Register 0xF5 (config) explizit setzen:
config: 101 000 x 0
| | +-- not SPI
| +-------- filter off
+------------ inactive: 1000ms
Wär mal interessant was dann die Temp-Anzeige sagt...
Zitat von: SusisStrolch am 22 August 2016, 22:35:18
Ich würde ja die Daten sammeln. Allerdings scheint es wenig sinnvoll wenn nur die Calibration Values betrachtet werden.
...
Um da was genaueres sagen zu können bräuchte man meiner Meinung nach mindestens noch die Raw-Werte sowie die "kalibrierten".
Bin dran. Da die Hardware page dirket vom Start weg ausufert, habe ich ein refactoring vom drumrum begonnen, um die Daten venünftig bei zu bekommen, das nun auch ausufert. Kann also noch dauern.
Ich werde wohl die ADC-Werte, und die mit den Kalibrierwerten gerechneten Werte dazu rausgeben.
Zitat von: SusisStrolch am 22 August 2016, 23:53:56
Das Datenblatt empfiehlt für Wettermessungen ...
Kann ich probieren, allerdings ändert das mMn nur die Messhäufigkeit und nicht das Messverfahren.
Was das Datenblatt auch noch sagt:
"Absolute accuracy tolerance: +-3% rH"
"Absolute accuracy temperature: +-1 °C"
Zwei BME können also legal 6% rH und 2 °C auseinander liegen.
Mir ist aber noch nicht ganz klar, was aktuell unser Plan ist.
Ich fasse mal mein bisheriges Verständnis der Erkenntnisse zusammen:
Mein Testaufbau bekommt von drei Libs identische Werte
Die beiden BMEs nebeneinander liefern eine sehr unterschiedliche Feuchte
Die bisher gemledeten BMEs haben unterschiedliche Kalibrierdaten, was aber nicht unbedingt bedeutet, dass sie auch korrekt kalibriert sind.
Lt. Bosch können sie 6% rH und 2 °C auseinander liegen
Was leiten wir nun daraus ab?
Möglichkeiten:
1. Alle drei Libs initialisieren/arbeiten/rechnen falsch, das erklärt aber nicht, warum die beiden BMEs auf dem Testaufbau unterschiedliche Werte geben, dann müssten beide gleich falsch sein
2. Die Sensoren sind teilweise schlecht kalibriert
3. Wir bewegen uns großteils innerhalb der Toleranz und es gibt einige Außreißer
4. ?
5. ?
Wer war denn derjenige, der einen BME280 hat, von dem er meint, dass er acht Grad zu hoch liegt?
Den hätte ich gerne, um ihn auf dem Tester neben einen von meinen zu setzen.
Zitat von: HCS am 23 August 2016, 08:36:15
Was leiten wir nun daraus ab?
Möglichkeiten:
1. Alle drei Libs initialisieren/arbeiten/rechnen falsch, das erklärt aber nicht, warum die beiden BMEs auf dem Testaufbau unterschiedliche Werte geben, dann müssten beide gleich falsch sein
Nun, davon geh' ich nicht aus, da die verwendeten Algorithmen mit denen aus dem Bosch Repository übereinstimmen.
Zitat
2. Die Sensoren sind teilweise schlecht kalibriert
Das ist eher der Fall - und auch die Richtung, in die wir gehen sollten. Genau den Punkt zu finden, mit dem wir die BME/BMP etwas genauer hinbiegen können.
Zitat
3. Wir bewegen uns großteils innerhalb der Toleranz und es gibt einige Außreißer
Nun, die Toleranz der Messeinrichtung (H-Sensor, T-Sensor) können wir nicht beeinflussen. Die Physik dahinter bleibt jedoch gleich - d.h. die Kennlinie der Sensoren. Die eigentliche Toleranz kommt m.E. aus der Ungenauigkeit beim eigentlichen Kalibriervorgang.
Beispiel: Die Konstante T1 passt den 0-Punkt des Temperatur-Fühlers an, geht aber (gewichtet) quadratisch mit in die Ergebnisse ein.
Wenn wir bspw für T1 ein Delta mit angeben können (anstatt einfach nur ein Offset auf das kalibrierte Ergebnis) erreichen wir eine deutlich bessere Genauigkeit über den zulässigen Messbereich.
Kurz gefasst - Ziel ist es, eine saubere Anpassung für die Sensor-Daten zu finden.
Zitat von: SusisStrolch am 23 August 2016, 14:30:20
Kurz gefasst - Ziel ist es, eine saubere Anpassung für die Sensor-Daten zu finden.
Soweit richtig. Das würde bedeuten, dass man die Kalibrierwerte für T und H anpassen müsste, um zu einem richtigen Wert zu kommen.
Also den Sensor "nachkalibrieren"
Das ist aber bei jedem Sensor individuell anders und nur machbar, wenn man über eine bekannte, exakt ermittelte oder produzierte Temperatur und Feuchte verfügt, am besten unten, in der Mitte und oben im Messbereich.
Dann müsste man erst die Temperatur kalibrieren und wenn die korrekt ist, die Feuchte, da
rH und somit stark abhängig.
Einzig den Druck scheinen die BME280 richtig gut drauf zu haben, da liefern alle drei, die ich habe, hervorragende Ergebnisse.
Ich frag mich so langsam ob es so schlau war neulich nun doch die BME280 geordert zu haben um die BMP180/DHT22 Kombination abzulösen :-\
Zitat von: waschbaerbauch am 23 August 2016, 15:39:14
Ich frag mich so langsam ob es so schlau war neulich nun doch die BME280 geordert zu haben um die BMP180/DHT22 Kombination abzulösen :-\
Hast Du bei Bosch oder Fake geordert? ;) ;D ;D
Das kann man nur beantworten, wenn man eine Temperatur und Feuchte exakt kennt und schaut, ob der BME oder der DTH (oder beide) falsch liegt.
Zitat von: HCS am 23 August 2016, 15:28:16
Soweit richtig. Das würde bedeuten, dass man die Kalibrierwerte für T und H anpassen müsste, um zu einem richtigen Wert zu kommen.
Also den Sensor "nachkalibrieren"
Exakt.
Zitat
Das ist aber bei jedem Sensor individuell anders und nur machbar, wenn man über eine bekannte, exakt ermittelte oder produzierte Temperatur und Feuchte verfügt, am besten unten, in der Mitte und oben im Messbereich.
Ich gehe momentan davon aus, dass zwei Messungen ausreichen. Eine möglichst nahe bei 0°, für den anderen eine im Normalbereich, wobei die 0° Messung die Wichtigste ist.
Aus der Datensammlung mit den Messwerten kann man dann abschätzen, wo man drehen muss.
(T1 ist der 0° Offset des AD-Wandlers, T2 der Korrekturfaktor für die Messung. Die Linearität wird durch T3 bestimmt - und die war bei allen bisher auf 50 - also etwa 2% des linearen Anteil.)
Zitat
Dann müsste man erst die Temperatur kalibrieren und wenn die korrekt ist, die Feuchte, da rH und somit stark abhängig.
Genau.
Hallo
Meine pca301 steckdosen wollen nicht mehr nachdem ich mein nodemcu komplett neu bespielt habe mit Ver 1.21
erst erase und dann Firmware neu drauf gespielt
Bei initCommands 868295#1f 3#1m 20#1t 220h 0a v trudeln daten von sensoren (LaCrosse Tempsensoren) ein kann man gut im logmonitor vom LaCrosseGateway sehen.
Sobald ich jedoch auf
initCommands 1,868950,120i 220h 0a v für meine pca301 umstelle
wird nichts mehr empfangen logmonitor bleibt leer
auch ein probeweise umstellen auf 868960 868970 funktioniert nicht.
Hab auch versucht die Dosen aus Fhem zu löschen und zu pairen
was leider auch nicht geht.
Was kann ich noch machen damit das wieder funktioniert?
Andre
Irgendwie zickt der nanoCUL rum:
- heute hat er sich nicht OTA flashen lassen (vielleicht ist die Verbindung nicht so gut)
- er braucht nach dem Flashen einen harten Reset
Aber hier habe ich die Kalibrierwerte (vom selbergelöteten BME280, PMLGW03):
BME280 T1:28121 T2:26572 T3:50 H1:75 H2:360 H3:0 H4:324 H5:0 H6:30 P1:38843 P2:-10870 P3:3024 P4:12683 P5:-130 P6:-7 P7:9900 P8:-10230 P9:4285
Gruß PeMue
Zitat von: PeMue am 23 August 2016, 21:28:01
Aber hier habe ich die Kalibrierwerte (vom selbergelöteten BME280, PMLGW03):
BME280 T1:28121 T2:26572 T3:50 H1:75 H2:360 H3:0 H4:324 H5:0 H6:30 P1:38843 P2:-10870 P3:3024 P4:12683 P5:-130 P6:-7 P7:9900 P8:-10230 P9:4285
Und wie sind bei Dir die Temperaturabweichungen?
Zitat von: SusisStrolch am 23 August 2016, 21:46:36
Und wie sind bei Dir die Temperaturabweichungen?
Ziemlich hoch, da der BME280 im nanoLGW Gehäuse mit drin ist (siehe auch Plot). In der Nacht von Samstag auf Sonntag hatte ich den nanoLGW draußen vor der Haustüre und habe ihn um ca. 9 Uhr wieder reingeholt ...
Gruß PeMue
Zitat von: HCS am 23 August 2016, 16:37:59
Hast Du bei Bosch oder Fake geordert? ;) ;D ;D
Das kann man nur beantworten, wenn man eine Temperatur und Feuchte exakt kennt und schaut, ob der BME oder der DTH (oder beide) falsch liegt.
Gute Frage - auf jeden Fall sind die dann weiter gereist als ich bisher in meinem Leben ;)
Zitat von: PeMue am 23 August 2016, 21:56:32
Ziemlich hoch, da der BME280 im nanoLGW Gehäuse mit drin ist (siehe auch Plot).
Uhhh... ganz schlecht - da gibts ja keine Referenztemperatur...
Und Eiswasser fällt auch flach ;)
Zitat von: waschbaerbauch am 23 August 2016, 21:58:57
... weiter gereist als ich bisher in meinem Leben ;)
Stimmt, Du gehst eher in die Tiefe (beim Graben 8) 8) 8)). Bist Du eigentlich mittlerweile fertig (duckundweg)?
Zitat von: PeMue am 23 August 2016, 21:56:32
In der Nacht von Samstag auf Sonntag hatte ich den nanoLGW draußen vor der Haustüre
Das nennt man bei uns "stumarrest" - da hätte ich auch keine Lußt mehr vernünftigen Werte zu liefern.
Sorry, musste jetzt raus ;) ;) ;D
Zitat von: andre07 am 23 August 2016, 18:15:20
initCommands 1,868950,120i 220h 0a v für meine pca301 umstelle
wird nichts mehr empfangen logmonitor bleibt leer
Das ist doch mal nach dem ganzen Temperatur-Drama ein angenehmes Problem ;D ;D ;D
Die Dose mal von Hand schalten, dass sie gehört und im LGW neu gelernt wird.
Ich vermute, dann nach dem erase die PCAs vergessen sind. Ist auf der setup page bei "Plugs:" noch etwas eingetragen?
Zitat von: andre07 am 23 August 2016, 18:15:20
Meine pca301 steckdosen wollen nicht mehr nachdem ich mein nodemcu komplett neu bespielt habe mit Ver 1.21
erst erase und dann Firmware neu drauf gespielt
Warum hast Du denn ein erase gemacht?
Mit der 1.21 Version läuft (ein- und ausschalten etc.) bei mir:
- Backofen
- Kuehlschrank
- Kuehltruhe
- Spuelmaschine
etc.
immer noch.
Dies zur Info.
Parameter (initCommands)
attr myJeeLink initCommands 1,868950,30i 3#2m 20#2t 345h 0a v
Hallo
HCS
Auf der Setup page steht nichts mehr hab mir
die Channels aber notiert.Warum erase beim Ota ist
irgendwas schief gelaufen wollte nicht mehr
starten.
amunra
Werde mal dein werte eintragen und testen
Warum eigentlich 345h??
Gruss Andre
Das ist der Korrekturwert für den Druck meines BMEs. - ich Wohne ziemlich hoch. Entscheidend wird 30i sein - vermute ich.
Zitat von: PeMue am 23 August 2016, 22:11:51
Stimmt, Du gehst eher in die Tiefe (beim Graben 8) 8) 8)). Bist Du eigentlich mittlerweile fertig (duckundweg)?
Da hast du absolut Recht. Fertig ...
fertig?! Wird man bei einem Haus jemals wirklich fertig? ;)
Sollten die beiden BME280 ankommen, dann könnte ich 17h als Luftdruck beisteuern ;D
Blöde Frage:
Woher habt ihr denn eure Höhe (345m, 17m) bekommen?
Mit welcher Genauigkeit?
GoogleMaps GPS Daten oder doch GoogleEarth?
Zitat von: SusisStrolch am 25 August 2016, 10:08:13
Blöde Frage:
Woher habt ihr denn eure Höhe (345m, 17m) bekommen?
Mit welcher Genauigkeit?
Zum Beispiel von hier:
http://www.autospur.de/Staumeldungen/wie-hoch.html (http://www.autospur.de/Staumeldungen/wie-hoch.html)
In die Karte auf deinen Wohnort klicken -->
Zitat"Dieses Ort:
(5x.396163972986386, 6.853786470601335)
ist 56.22 Meter hoch"
Rate mal wo ich wohne. ;)
Gruß Friedrich
PS: Du hast 10 Versuche. ;D ;D ;D
Interessant - diese Seite kannte ich so noch nicht - man kann schön den damaligen Höhenabfall meines Grundstücks sehen :D
@Susi und Strolch: Die Hardware-Page im Frontend (aktueller Stand)
Die Werte (T, H und P) links sind mit den Kalibrierdaten gerechnet, aber nicht mit der im Frontend definierten Korrektur versehen.
Der Druck ist absolut, nicht mit der im Frontend oder FHEM definierten Höhe normalisiert.
Ganz rechts sind die ADC Werte.
Das Ganze sowohl für BME280 als auch BMP180
DHT22 und LM75 haben keine Kalibrierdaten, die liefern beide das Endergebnis.
Auf das 211er muss ich den BME280 wieder drauf setzten, dass der (für den Normalbetrieb nutzlose) Zoo wieder komplett ist.
Der LM75 kann zwar nur 0.5 Grad Schritte aber trotzdem muss ich da nochmal drauf schauen, der zeigt schon einen ganzen Tag lang 30.0 was mir verdächtig vorkommt.
Allerding habe ich schon seit Jahren in einem anderen Projekt mehrere LM75 laufen und die liegen auch alle ein bis zwei Grad falsch.
Hallo
Zu meinen Problem der nicht schaltenden Steckdosen was sich nun endlich erledigt hat.
Ich hatte im log der setup page beobachtet das ständig so alle 4 minuten
ein reboot ausgelöst wurde.
Ich bin darauf hin auf 1.18 zurück habe dort im Setup-page bei pca301
alles gelöscht reboot gemacht ..immer noch nicht funktioniert :-\
In Fhem dann alle Steckdosen entfernt und siehe die Steckdosen
tauchten in Fhem wieder und ließen sich wieder schalten.
die zuordnung der channel hatte sich aber geändert :-\
203F0CE=2,03A091=3 -> 03A091=2,03F0CE=1
Aber warum ist das passiert?
so, hier mal meine gesammelten Werke:
BMP180 OK AC1:8236 AC2:-1211 AC3:-14593 AC4:34510 AC5:24886 AC6:21863 B1:6515 B2:49 MB:-32768 MC:-11786 MD:2889 PMLGW02 Aliexpress Modul
BME280 OK T1:28407 T2:26717 T3:50 H1:75 H2:354 H3:0 H4:338 H5:0 H6:30 P1:37803 P2:-10680 P3:3024 P4:7197 P5:-25 P6:-7 P7:9900 P8:-10230 P9:4285 PMLGW02 Aliexpress BME280 Modul
BME280 OK T1:27877 T2:26233 T3:50 H1:75 H2:363 H3:0 H4:316 H5:0 H6:30 P1:38941 P2:-10878 P3:3024 P4:9540 P5:36 P6:-7 P7:9900 P8:-10230 P9:4285 BME breakout PeMue Los A
BME280 OK T1:28091 T2:26156 T3:50 H1:75 H2:365 H3:0 H4:312 H5:0 H6:30 P1:39061 P2:-11043 P3:3024 P4:8547 P5:14 P6:-7 P7:9900 P8:-10230 P9:4285 PMLGW02 Los A
BME280 OK T1:28121 T2:26572 T3:50 H1:75 H2:360 H3:0 H4:324 H5:0 H6:30 P1:38843 P2:-10870 P3:3024 P4:12683 P5:-130 P6:-7 P7:9900 P8:-10230 P9:4285 PMLGW03 Los A
BME280 OK T1:28220 T2:26334 T3:50 H1:75 H2:353 H3:0 H4:341 H5:0 H6:30 P1:36495 P2:-10766 P3:3024 P4:4748 P5:186 P6:-7 P7:9900 P8:-10230 P9:4285 nanoLGW HCS Los B
BME280 OK T1:28247 T2:26316 T3:50 H1:75 H2:350 H3:0 H4:348 H5:0 H6:30 P1:36458 P2:-10738 P3:3024 P4:4891 P5:187 P6:-7 P7:9900 P8:-10230 P9:4285 nanoLGW ucm73 Los B
BME280 OK T1:27939 T2:26616 T3:50 H1:75 H2:359 H3:0 H4:325 H5:0 H6:30 P1:36828 P2:-10691 P3:3024 P4:7187 P5:71 P6:-7 P7:9900 P8:-10230 P9:4285 nanoLGW RaspiLED Los B
BME280 OK T1:28457 T2:26499 T3:50 H1:75 H2:354 H3:0 H4:338 H5:0 H6:30 P1:36808 P2:-10787 P3:3024 P4:1584 P5:285 P6:-7 P7:9900 P8:-10230 P9:4285 nanoLGW RaspiLED Los B
BME280 OK T1:28217 T2:26539 T3:50 H1:75 H2:361 H3:0 H4:321 H5:0 H6:30 P1:37228 P2:-10770 P3:3024 P4:7474 P5:-51 P6:-7 P7:9900 P8:-10230 P9:4285 BME breakout PeMue Los B
BME280 OK T1:28189 T2:26489 T3:50 H1:75 H2:356 H3:0 H4:333 H5:0 H6:30 P1:37842 P2:-10868 P3:3024 P4:8163 P5:-69 P6:-7 P7:9900 P8:-10230 P9:4285 ADC: T=529672 H=32199 P=318242 PeMue Feinstaubsensor
BME280 OK T1:28241 T2:26673 T3:50 H1:75 H2:363 H3:0 H4:317 H5:50 H6:30 P1:37364 P2:-10610 P3:3024 P4:6172 P5:35 P6:-7 P7:9900 P8:-10230 P9:4285 ADC: T=526128 H=32768 P=354048 franky08
Hinten steht, wo die Dinger verbaut sind bzw. welche Aliexpress Lieferung das war. Der verschollene aus dem Labor ist aus unerfindlichen Gründen leider nicht dabei ;D
Gruß PeMue
Zitat von: PeMue am 27 August 2016, 19:48:14
so, hier mal meine gesammelten Werke:
Damit haben wir dann genug Werte, die mMn zu folgendem Ergebnis führen:
Die BMEs sind irgendwie kalibriert, aber eventuell nicht korrekt kalibriert.
Weitere Einreichungen sind vorerst mal nicht erforderlich.
Was auch als sicher betrachtet werden kann: an den original-Einbau-Positionen der BME280/BMP180 und DHT22 auf der PeMue-Platine werden die bereits von der Abwärme des ESP8266 und AMS1117 beeinflusst, besonders wenn im Raum absolut keine Luftbewegung herrscht.
Zitat von: andre07 am 25 August 2016, 21:18:45
die zuordnung der channel hatte sich aber geändert :-\
203F0CE=2,03A091=3 -> 03A091=2,03F0CE=1
Aber warum ist das passiert?
Die channels werden in der Reihenfolge vergeben, in der die Dosen gehört werden. Und nach dem totalreset hast Du ja wieder neu begonnen, was dann durchaus zu einer anderen Reihenfolge führen kann.
Es sollte aber funktionieren, auf der Setup-page die channels zu ändern und das setup zu speichern.
Oder nach einem totalreset die komplette Konfiguration wieder reinzupacken (203F0CE=2,03A091=3)
Moin!
Ich hab da mal eine bescheidene Frage..
In der Setup Seite kann man ja die WLAN SSID angeben. Ich hätte hier zwei SSIDs welche ich hinterlegen möchte. Das Passwort könnte ich identisch vergeben. Ist das irgendwie machbar - ggf. durch eine Adressierung wie bei einer Mail mit einer Trennung per Semikolon oder so?
Zitat von: waschbaerbauch am 28 August 2016, 08:16:26
Ich hab da mal eine bescheidene Frage..
Meine bescheidene Antwort :) :
Keine Ahnung aktuell, ob und wie das geht. Ich schreibe es mal in die ToDo in der Rubrik "Was man sich so alles wünscht"
USR-TCP232-T
Habe ihn mal angeschlossen. Generell funktioniert das aber einige Probleme sind da noch zu lösen:
-Parallelschaltung serielle Schnittstelle beim DevKit: das sieht die Spezifikation nicht vor. Erstaunlich, dass das läuft.
Aber vielleicht erklärt das ja auch einige berichtet Phänomene ("blockiert", ...).
Mit einem ESP8266 ist das dann aber kein Thema, weil man ja entweder den USR-TCP232 oder den seriell Wandler dranstecken kann aber nicht beides gleichzeitig muss.
- Erkennung ob der USR-TCP232 vorhanden ist.
Da fehlt mir noch eine Idee, wie man ihn erkennt. Das serielle Konfigurationsprotokoll scheidet aus, dazu muss man CFG auf low legen.
- wifi deaktivieren.
Wenn klar ist, dass ein USR-TCP232 vorhanden ist, muss wifi daktiviert werden. Das ist das kleinere Problem, wenn es erst mal erkannt wurde.
- Initialiserung (bekommt nichts von einem FEHM connect mit)
Das LGW erkennt, ob sich FHEM auf einen der Datenports (wifi) verbunden hat.
Sobald das passiert, sendet es an FHEM die Kennung "[LaCrosseITPlusReader.Gateway.1.22 ...", was FHEM zum Anlass nimmt, auf "initialized zu gehen
und die initCommands an das LGW zu schicken.
Eigentlich müsste in dem Fall hier das JeeLink device nach dem erfolgreichen Connect (wenn es auf "opened" geht) auf den Datenport dann ein "v" schicken, dass das LGW seine Kennung schickt. Das wäre eine (konfigurierbar zu machende) Erweiterung am JeeLink device. Müsste man justme1968 dazu überreden.
So in der Art eines Attributs "commandAfterConnect" in das man als Wert dann ein v einträgt.
Das kann man manuell gut durch ein "set JeeLink214 raw v" simulieren.
Erforderliche Einstellungen:
Internal sensors ID, Altitude, Temperature-correction, Humidity-correction, MCP23008 Konfiguration, OLED start mode, KV-Interval, KV-Identity
Diese Einstellungen kann man nur auf der Setup-Page setzen, da müsste ein Weg gefunden werden, es über die serielle Schnittstelle zu setzen und auch zu speichern.
Da ich nur kurz mal ausprobiert habe, bin ich nicht sicher, ob ich schon alle Probleme gefunden habe.
Meine Anmerkungen / Ideen (schnelldruchlauf - sorry, kurz angebunden)
Heute ist es ein USR-TCP232-T morgen USR-K2/2 (ist vielleicht eine bessere alternative :-\ ;)) etc. => ich würde die Erkennung vernachlässigen und auf der Config-Page eine Checkbox "USB/Seriel-Mode" anbieten.
Wird die Checkbox ausgewählt, ist ein STA-Mode (SSID/PW etc.) nicht möglich - ideal wäre es die Felder auszugrauen (nice to have).
Den AP für die "initial-konfiguration" würde ich lassen wie er ist - vor dem speichern wird geprüft, ob die o.g. Checkbox aktiv ist, falls ja, dann "Werte speichern und AP disablen".
Viel ändert man nach einer init-Einrichtung ja nicht bzw. kaum etwas und wenn es mal nötig ist, dann resetet man das LGW und richtet es neu ein - ist ja auch in paar sekunden erledigt.
Zitat von: HCS am 28 August 2016, 21:49:59
USR-TCP232-T
- Initialiserung (bekommt nichts von einem FEHM connect mit)
Das LGW erkennt, ob sich FHEM auf einen der Datenports (wifi) verbunden hat.
Sobald das passiert, sendet es an FHEM die Kennung "[LaCrosseITPlusReader.Gateway.1.22 ...", was FHEM zum Anlass nimmt, auf "initialized zu gehen
und die initCommands an das LGW zu schicken.
Wie erkennst das LGW das heute wenn ich das LGW in USB-Mode betreibe bzw. WiFi deaktiviere?
Ich denke, bei dem Ansatz (ja, nicht optimal) erübrigen sich einige/viele Themen?
Zitat von: amunra am 29 August 2016, 12:52:15
Heute ist es ein USR-TCP232-T morgen USR-K2/2 (ist vielleicht eine bessere alternative :-\ ;)) etc. => ich würde die Erkennung vernachlässigen und auf der Config-Page eine Checkbox "USB/Seriel-Mode" anbieten.
Du meinst siehe Anhang 8)
Da habe ich bereits gestern Nacht umgeschwenkt.
Zitat von: amunra am 29 August 2016, 12:52:15
Wird die Checkbox ausgewählt, ist ein STA-Mode (SSID/PW etc.) nicht möglich - ideal wäre es die Felder auszugrauen (nice to have).
Wird die Checkbox ausgewählt, dann wird man die Setup-Page nach dem nächsten reboot eh nicht mehr zu sehen bekommen ...
Zitat von: amunra am 29 August 2016, 12:52:15
Viel ändert man nach einer init-Einrichtung ja nicht bzw. kaum etwas und wenn es mal nötig ist, dann resetet man das LGW und richtet es neu ein - ist ja auch in paar sekunden erledigt.
Neu einrichten ist doof, weil man z.B. sein PCA301 Kanalzuordnung verliert.
Es wird die Möglichkeit geben, die Settings auch über die serielle Schnittstelle zu setzen, egal ob wifi gerade aktiv ist oder nicht.
Man wird dann auf der seriellen Schnittstelle sowas (so ungefähr, oder genau so, oder sonstwie) schicken können:
"SETUP UseWiFi false; IO0 OLED mode=thp; IO1 OLED Off; CorrT -2.5; ISID 211"
oder
"SETUP UseWiFi true"
oder
"SETUP Altitude 220; CorrT -2.5; CorrH -4;"
was die Settings entsprechend ändert und speichert (und vermutlich dann wie die Setup-Page einen reboot macht)
Zitat von: amunra am 29 August 2016, 12:52:15
Wie erkennst das LGW das heute wenn ich das LGW in USB-Mode betreibe bzw. WiFi deaktiviere?
Gar nicht. USB-Mode funktioniert stand heute genauso schlecht wie USR-TCP :o :o
Das LGW muss sich im "nicht wifi" Mode auch die ganzen debug Meldungen beim booten auf der seriellen schenken.
Es wird aber nichts dran vorbeiführen, das JeeLink device anzupassen, da es von einer JeeLink-Reset-Logik ausgeht und die beim ESP8266 halt eine andere ist.
Und da der USR-TCP kein RTS hat, geht es damit schon gar nicht.
Zitat von: HCS am 29 August 2016, 17:53:04
Gar nicht. USB-Mode funktioniert stand heute genauso schlecht wie USR-TCP :o :o
Sag ichs nicht? Aber dem Hardwarefuzzi glaubt ja wieder mal keiner :P
Wenn die Reset "Schrulle" weg ist, würde ich das Ganze so machen:
- Einrichten wie gehabt per Web Page (man muss sich einmal an seinen Router per WLAN anlernen, ansonsten funktioniert der grafische Setup halt nicht)
- dann einfach per Haken WiFi abschalten
Wenn man neu einrichten will, muss man halt per fhem wieder WiFi anschalten (ich hoffe, das geht ;)).
Gruß PeMue
Zitat von: HCS am 29 August 2016, 17:53:04
Du meinst siehe Anhang 8)
Da habe ich bereits gestern Nacht umgeschwenkt.
Ja, genauso ;)
Zitat von: HCS am 29 August 2016, 17:53:04
Neu einrichten ist doof, weil man z.B. sein PCA301 Kanalzuordnung verliert.
War mir nicht bewust, dass das LGW die "Zentrale" spielt. Ich war der Meinung, dass das LGW die Daten sammelt, FHEM speichert diese und gibt sie dem LGW zurück - und WEB-Config die Daten nur visualisien bzw. auch pushen kann.
Zitat von: HCS am 29 August 2016, 17:53:04
Es wird die Möglichkeit geben, die Settings auch über die serielle Schnittstelle zu setzen, egal ob wifi gerade aktiv ist oder nicht.
Man wird dann auf der seriellen Schnittstelle sowas (so ungefähr, oder genau so, oder sonstwie) schicken können:
"SETUP UseWiFi false; IO0 OLED mode=thp; IO1 OLED Off; CorrT -2.5; ISID 211"
oder
"SETUP UseWiFi true"
oder
"SETUP Altitude 220; CorrT -2.5; CorrH -4;"
was die Settings entsprechend ändert und speichert (und vermutlich dann wie die Setup-Page einen reboot macht)
Ich möchte jetzt nicht direkt den Produktmanager und die Entwicklungsabteilung zugleich unter Druck setzen bzw. einspannen, aber ein "save-settings"-Button wäre so langsam angebracht ;) (Prio: 10 auf der ToDo Liste - Vorschlag/Grundsatz: Funktionalität vor Komfort)
Zitat von: HCS am 29 August 2016, 17:53:04
Gar nicht. USB-Mode funktioniert stand heute genauso schlecht wie USR-TCP :o :o
Das LGW muss sich im "nicht wifi" Mode auch die ganzen debug Meldungen beim booten auf der seriellen schenken.
Zitat von: PeMue am 29 August 2016, 20:09:34
Sag ichs nicht? Aber dem Hardwarefuzzi glaubt ja wieder mal keiner :P
Fürs Protokoll ;): Da hat aber der Produktmanager vor einiger Zeit etwas anderes verprochen ;) Ich fasse zusammen, offensichtlich hat es bisher (bis jetzt) niemand genutzt und das ist der Grund warum die Beschwerden bis heute ausgeblieben sind :o ;) ;D
Zitat von: HCS am 29 August 2016, 17:53:04
Es wird aber nichts dran vorbeiführen, das JeeLink device anzupassen, da es von einer JeeLink-Reset-Logik ausgeht und die beim ESP8266 halt eine andere ist.
Und da der USR-TCP kein RTS hat, geht es damit schon gar nicht.
Ja, korrekt.
Zitat von: amunra am 29 August 2016, 21:57:22
Ich war der Meinung, dass das LGW die Daten sammelt, FHEM speichert diese und gibt sie dem LGW zurück - und WEB-Config die Daten nur visualisien bzw. auch pushen kann.
Nein. Das LGW verwaltet die ID-Kanal-Zuordnung selbst. Kann auch nur so sein, da sich ja bis zu drei FHEMs auf ein LGW verbinden können und dann Kanalsalat vorprogrammiert wäre.
Zitat von: amunra am 29 August 2016, 21:57:22
Da hat aber der Produktmanager vor einiger Zeit etwas anderes verprochen
Ich bin doch gerade dabei, das Versprechen wahr zu machen.
Falls Dir das noch nicht aufgefallen ist hier nochmal der Plan:
- Persistente Konfiguration, ob wifi genutzt werden soll -> done
- Wenn kein wifi, dann die debug Ausgaben beim Start auf der seriellen Schnittstelle unterdrücken -> 1.22
- Abfragen, Setzten und Speichern der Einstellungen auch über die serielle Schnittstelle -> 1.22
- Patch für das 36_JeeLink.pm bei justme1968 einreichen, um eine LGW-taugliche Initialisierung einstellen zu können
Die Vorschläge in Richtung "einmal per wifi konfigurieren und dann auf USB/Kabel umschwenken" habe ich verworfen.
Das führt mit Sicherheit innerhalb überschaubarer Zeit zu der Anfrage, ob das nicht auch ohne wifi in Gang zu bekommen ist.
Und: ein hardcore-wifi-Verweigerer wird, da er die Strahlungswerte nicht gewohnt ist, die Konfiguration nicht schnell genug hinbekommen, bevor sein Erbgut unwiederuflich geschädigt wurde ;D ;D ;D
Zitat von: PeMue am 29 August 2016, 20:09:34
Sag ichs nicht? Aber dem Hardwarefuzzi glaubt ja wieder mal keiner :P
Eigentlich hatte ich schon ganz zu Beginn den Wunsch, das LGW per Jumper von wifi auf USB umstellen zu können.
Falls der Hardwarefuzzi dazu eine Idee hat (ohne auf eine der möglichen Hardwares zu verzichten), wäre das auch noch was.
Evtl. GPIO13 pullup wenn man kein WiFi will, das könnte ich bei Start dann prüfen.
Dem MOSI sollte es doch egal sein, ob da ein pullup drauf ist, oder?
Zitat von: amunra am 29 August 2016, 21:57:22
..., aber ein "save-settings"-Button wäre so langsam angebracht ;)
Da zitiere ich Dich jetzt mal:
Zitat von: amunra am 29 August 2016, 12:52:15
Viel ändert man nach einer init-Einrichtung ja nicht bzw. kaum etwas und wenn es mal nötig ist, dann resetet man das LGW und richtet es neu ein - ist ja auch in paar sekunden erledigt.
und schließe mich Deiner Meinung von gestern an, dass man es nicht braucht.
Zitat von: HCS am 30 August 2016, 08:29:42
- Patch für das 36_JeeLink.pm bei justme1968 einreichen, um eine LGW-taugliche Initialisierung einstellen zu können
Und da mal einen Schritt weiter überlegt: ich habe schon öfter drüber nachgedacht, ob ich für das LaCrosseGateway ein eigenes physisches FHEM-Modul machen sollte (also ein 36_LaCrosseGateway.pm), das genau das untestützt, was das LGW macht und nicht eine Wunderwaffe für Alles ist, mit der man für das LGW recht viel falsch verstehen (und machen) kann.
Beispiele, was man nicht braucht:
- die ganzen tune_... Attribute
- die Beep... Attribute
- das flashCommand Attrbut
- alle gets
Was man brauchen kann, aber das Falsche macht:
- set beep (das LGW kann ja so was, das Modul sendet nur leider etwas für eine ganz andere Firmware)
Was man haben könnte aber im 36_JeeLink nicht bekommen wird:
- LGW-spezifische readings wie uptime, RSSI, ... direkt im 36_LaCrosseGateway
- Einstellungen, ob z.B. das KVP mit den LGW-Infos dispatched werden soll oder einem die readings im 36_LaCrosseGateway ausreichen
- Eventuell bekommt man es hin, das LGW von FHEM aus per USB zu flashen (alternativ zu OTA)
Und vermutlich vieles mehr und ein LaCrosseGateway ist halt nun mal ein LaCrosseGateway und kein JeeLink.
Jetzt werden sich einige fragen, wie man so blöd sein kann, sich das auch noch aufzuhalsen ;D
Ja, gute Frage, stelle ich mir auch gerade, aber das kann ja langsam entstehen und über die Zeit wachsen.
Für neu anzulegende LGWs ist es eh egal.
Eine bestehende Installation umzustellen würde bedeuten, dass man das bisherige JeeLink device (jetzt kommt's: am einfachsten in der fhem.cfg) in ein LaCrosseGateway umschreibt.
Meinungen dazu?
Manchmal frag ich mich echt was mit meinem Zeitmanagement nicht stimmt, aber ich bin voll für deinen Ansatz eines eigenen Moduls!
8) ;D ;)
Zitat von: waschbaerbauch am 30 August 2016, 14:13:24
Manchmal frag ich mich echt was mit meinem Zeitmanagement nicht stimmt
Mein Plan ist, mich mit der Implemetierungsgeschwindigkeit an BER zu orientieren ;D ;D ;D
Und schon stimmt das Zeitmanagement 8)
Das schaffst du sowieso nicht, dir fehlt ja jegliche Grundlage es zu verzögern und an allen Ecken und Enden Kohle zu schinden ;)
Hallo HCS,
mir ist aufgefallen, dass ab und zu der erste Druckwert nicht stimmt. Wie gibt denn das LGW den Druck raus, so wie es der Sensor misst? Und danach wird mit dem Höhenattribut im fhem Modul berechnet? Ich habe jetzt mal sukzessive die BME280 Platinen an ein LGW hingehängt und jetzt schon das zweite oder dritte Mal gesehen, dass der erste angezeigte Wert zu tief ist:
2016-08-30_19:33:57 LaCrosse_01 pressure: 992
2016-08-30_19:34:07 LaCrosse_01 temperature: 25.4
2016-08-30_19:34:07 LaCrosse_01 humidity: 39
2016-08-30_19:38:58 LaCrosse_01 pressure: 1021
Danke + Gruß
PeMue
Zitat von: PeMue am 30 August 2016, 19:44:32
Hallo HCS,
mir ist aufgefallen, dass ab und zu der erste Druckwert nicht stimmt. Wie gibt denn das LGW den Druck raus, so wie es der Sensor misst? Und danach wird mit dem Höhenattribut im fhem Modul berechnet?
Das LGW gibt den gemessenen Druck für die mit xxxh gesetzte Höhe normalisiert zurück.
Das kann es aber erst, wenn es die Höhe kennt und die kennt es erst, wenn FHEM die initCommands gesendet hat.
Aus diesem Grund habe ich auf der setup-Page die Einstellung Altitude eingebaut, dass das LGW nicht darauf angewiesen ist, dass es von FHEM irgend wann geschickt wird.
Je länger von FHEM keine initCommands kommen desto länger stimmt der Druck nicht (bei der bisherigen Variante)
Wenn man es auf der setup-Page gesetzt hat, kann man sich das 220h oder was auch immer in den initCommands schenken.
Höhenangaben herausfinden:
http://www.autospur.de/Staumeldungen/wie-hoch.html (http://www.autospur.de/Staumeldungen/wie-hoch.html)
http://embedded-lab.com/blog/bmp180/ (http://embedded-lab.com/blog/bmp180/)
sorry, wenn's off-topic sein sollte...
Hier mal ein paar Neuigkeiten von der Kalibrier-Front:
Betreibe den BME280 nun mit 1000ms Standby und IIR Filter == 4.
Erstes Zwischenergebnis:
Die Temperatur-Differenz zu meinem DS18B20 Bündel ging - ohne Positionsänderungen! - von ~1,7 auf 0,9 °C zurück.
Könnte es u.a. mit an der Verlustwärme des auf dem Breakout-Board verbauten Spannungsreglers hängen?
Anbei mal ein Screenshot - Update war um 15:00...
(Der Sprung um 15:02 rührt daher, dass ich einen Offset auf den DS18B20 Mittelwert entfernt habe, welcher zur Spreizung des Diagrammes verwendet wurde)
Zitat von: SusisStrolch am 31 August 2016, 15:16:55
Die Temperatur-Differenz zu meinem DS18B20 Bündel ging - ohne Positionsänderungen! - von ~1,7 auf 0,9 °C zurück.
Das ist ja schon mal gut.
Zitat von: SusisStrolch am 31 August 2016, 15:16:55
Könnte es u.a. mit an der Verlustwärme des auf dem Breakout-Board verbauten Spannungsreglers hängen?
Da müsste man mal die Stromaufnahme des Breakut messen, dann könnte man rechnen.
Aber bei maximal 714 µA lt. Datenblatt kann da ja eigentlich nicht viel sein.
Zitat von: SusisStrolch am 31 August 2016, 15:16:55
Die Temperatur-Differenz zu meinem DS18B20 Bündel ...
Ich habe mal zwei DS18B20 kalibriert. Beide als Kabelfühler, einer mit Metallhülse und einer mit Kunststoffhülse.
Für die Messungen aneinandergebündelt.
Zum Zeitpunkt der Kalibrierung hatte ich 996 hPa was einen Siedepunkt von ca. 99.5 °C ergibt.
Wie viel Salz in meinem Leitungswasser ist, kann ich nicht sagen, aber es war definitiv nicht das übrige Nudel-Koch-Wasser ;D ;D
Da sollte der reale Wert dann knapp unter Null sein, aber sicher nicht bei -0.4 °C
Eiswasser: Metallfühler: -0.4 °C Kunststofffühler: +0.1 °C
Kochendes Wasser: Metallfühler: 99.3 °C Kunststofffühler: 98.3 °CWas auch zu beobachten war: der Sensor mit der Kunststoffhülse reagiert erheblich langsamer auf Temperaturänderungen und braucht deutlich länger, bis er an dem Punkt angekommen ist, an dem die Messung stabil steht. Eigentlich auch logisch und zu erwarten.
Wenn man eine halbwegs brauchbare Linearität annimmt, kann man damit dann wohl mit einer Zweipunktkalibrierung auf +- 0.2 °C im Zimmertemperaturbereich kommen.
Als nächstes werde ich dann mal den SHT75 bei Kühlschranktemperatur, Zimmertemperatur und irgendwo bei 50°C (der kommt mir nicht in den Kochtopf) gegen den kalibrierten DS18B20 vergleichen und ihn in einer übersättigten Kochsalzatmosphäre auf die 75% rH testen.
Ich glaube, da stelle ich gleich alles mit rein, was rH kann.
Danach ist der SHT75 dann meine persönliche Referenz, nach der sich alle anderen Sensoren richten müssen. 8)
Ich habe mal das diff zu meinem Experimentiermodul angehängt.
Änderungen:
- BME280 in FORCED mode, Trigger via GetTemperature (das Delay hierdurch liegt bei ca. 14ms)
- In der Hardware-Page wird die Temperatur 2-stellig angezeigt
Das zusätzliche #include in ESP8266Tools.h ist notwendig, da es anscheinend eine Änderung in der neuesten IDE gab (IPAddress war undefiniert).
Probier mal aus, ob das zusätzliche Delay in GetTemperature einen Einfluß auf deine komplexeren Setup's hat.
Zitat von: HCS am 01 September 2016, 16:52:43
Das ist ja schon mal gut.
Da müsste man mal die Stromaufnahme des Breakut messen, dann könnte man rechnen.
Aber bei maximal 714 µA lt. Datenblatt kann da ja eigentlich nicht viel sein.
Ich habe mal zwei DS18B20 kalibriert. Beide als Kabelfühler, einer mit Metallhülse und einer mit Kunststoffhülse.
Für die Messungen aneinandergebündelt.
Ich habe 3 Stück mit Metallhülse sowie den BME280 mal ganz simpel auf einen Kühlkörper genagelt.
Zwar nicht ideal vom Wärmeübergang, allerdings deutlich besser als "in der Nähe".
Zitat
Da sollte der reale Wert dann knapp unter Null sein, aber sicher nicht bei -0.4 °C
Meine Charge DS18B20 streut nur um ca. 0,3° bei Raumtemperatur.
Im Eiswasser war das auch anders - je nach dem wo die Eiswürfel grade schwammen.
Deshalb jetzt der Kühlkörper - zur "Mittelwertbildung".
Zitat
Danach ist der SHT75 dann meine persönliche Referenz, nach der sich alle anderen Sensoren richten müssen. 8)
Kommt der mit ins LaCrosseGateWay?
ZitatErst mal die gute Nachricht (der Rest im nächsten Post dann ...)
Der DHT22 scheint mit dem geänderten Timing der 1.21 nun stabil zu laufen.
Auf meinem 209er LGW liefert er seit einer Woche konstant Werte.
Habe nach meinem Urlaub vor einer knappen Wochen gleich auf die 1.21 bestätigt und auch bei mir läuft der DHT22 jetzt (wieder) stabil.
Vielen Dank an alle für die tolle Unterstützung!
Zitat von: SusisStrolch am 02 September 2016, 10:43:39
BME280 in FORCED mode, Trigger via GetTemperature (das Delay hierdurch liegt bei ca. 14ms)
Habe ich mal übernommen.
Damit liegt der BME280 bei mir recht genau ein Grad zu hoch (im Vergleich zu SHT75 und kalibriertem DS18B20) -> schon besser als vorher.
Den DS18B20 habe ich in meiner Test-Firmware mit einer Zweipunktkalibrierung versehen.
Der SHT75 hat out of the box fast exakt das Ergebnis des kalibrierten DS18B20. Die Differenz bei verschiedenen Zimmertemperaturen ist max. 0.1 °C
Und seine Feuchte ist sehr plausibel aber die muss ich noch nachmessen.
Sensor type Temperature Humidity Pressure
BME280 25.6 54 991
BMP180 24.8 988
DHT22 24.6 63
LM75 23.0
SHT75 24.6 54
DS18B20 #1 24.5Was auch interessant ist: der DHT22 liegt mit der Temperatur gut, aber mit der Feuchte definitiv daneben.
Ach ja, die 991 hPa des BME280 stimmen, der BMP180 irrt sich.
Von den BMP180 habe ich einige, da sind auch welche dabei, bei denen der Druck passt aber die Temperatur weiter daneben liegt.
Zitat von: SusisStrolch am 02 September 2016, 10:54:05
Kommt der mit ins LaCrosseGateWay?
Kann ich noch nicht sagen. Ist kein I2C sondern Sensirion spezial Protokoll, aber auch mit Data und Clock.
Angeblich soll das parallel verträglich auf einem I2C-Bus funktonieren. Aber das muss ich erst noch ausprobieren.
Hallo,
1) benötige ich für das OLED display zwingend den MCP23008?
Oder dient dieser dazu von FHEM Seite in IO-PIns dynamisch zuzuweisen?
2) Wozu ein zweiter oder dritter RFM69?
3) Wo findet sich die Schematics zum Anschluss des Displays?
mfg,
Oliver
Zitat von: rendgeor am 05 September 2016, 05:18:11
1) benötige ich für das OLED display zwingend den MCP23008?
Oder dient dieser dazu von FHEM Seite in IO-PIns dynamisch zuzuweisen?
2) Wozu ein zweiter oder dritter RFM69?
3) Wo findet sich die Schematics zum Anschluss des Displays?
zu 1) bzw. 3) nein, das Display wird nur per SPI angeschlossen: 3,3 V, GND, SCL, SDA.
zu 2) das müsste dann der 4. bzw. 5. RFM69 sein: z.B. wenn Du verschiedene LaCrosse Sensoren hast bzw. LaCrosse Sensoren + PCA301 + EnergyCount 3000 bedienen willst.
Gruß PeMue
Hallo PeMu,
danke für deine schnelle Antwort.
D.h. es gilt weiterhin, dass man mit einem Sketch nicht verschiedene Sensoren bedienen kann?!
Warum kann der Sketch nicht zwischen den verschiedenen Protokollen toggeln?
Zitat von: rendgeor am 05 September 2016, 06:41:57
D.h. es gilt weiterhin, dass man mit einem Sketch nicht verschiedene Sensoren bedienen kann?!
Warum kann der Sketch nicht zwischen den verschiedenen Protokollen toggeln?
Bitte zwischen JeeLink (jeweils nur ein Sketch bzw. toggeln teilweise möglich, manche Sketche können aber nur RFM12B) und LaCrosseGateway (kann so gut wie alles, allerdings nur mit RFM69, da geht auch ein Display, der kann auch toggeln) unterscheiden. Ggf. siehe WIKI: http://www.fhemwiki.de/wiki/LaCrosseGateway
Gruß PeMue
Hallo PeMu,
ja, meine Fragen beziehen sich nur auf den LaCrosse Gateway.
Der RFM69 kann ja auch mit den PCA301 und den LaCross Temperatursensoren (z.B. TX35DTH) sprechen.
1) Daher nochmals präziser gefragt:
Brauche ich mehrere RFM69 Module damit ich parallel die Temperaturwerte empfangen & gleichzeitig die Steckdosen schalten kann?
Oder warum sonst sollten 3-5 Module betrieben werden?
2) Kann der Gateway auch empfangene Werte zwischenspeichern (falls FHEM nicht läuft)?
3) Kann der Gateway auch Werte im Display anzeigen OHNE dass der FHEM das Kommando dazu schickt?
danke im Vorraus,
Oliver
Zitat von: rendgeor am 05 September 2016, 09:08:18
1) Daher nochmals präziser gefragt:
Brauche ich mehrere RFM69 Module damit ich parallel die Temperaturwerte empfangen & gleichzeitig die Steckdosen schalten kann?
Ja. LaCrosse und PCA301 sind unterschiedliche Protokolle und unterschiedliche HF-Übertragung -> zwei RFM69
Zitat von: rendgeor am 05 September 2016, 09:08:18
2) Kann der Gateway auch empfangene Werte zwischenspeichern (falls FHEM nicht läuft)?
Nein.
Zitat von: rendgeor am 05 September 2016, 09:08:18
3) Kann der Gateway auch Werte im Display anzeigen OHNE dass der FHEM das Kommando dazu schickt?
Wenn man die MCP23008-Erweiterung dran hat, kann man damit das Display vor Ort steuern, ohne nur von FHEM aus.
Es kann aber nur die Werte von seinem eigenen Sensor (BME280, BMP180, DHT22, ...) anzeigen, keine Werte, die es von Sensoren (LaCrosse, ...) empfangen hat.
Alle drei RFMs haben ja eigene Puffer, so dass keine Austastzeiten der einzenlen Protokolle entstehen.
Sozusagen asynchron ... ansonsten bestünde die Gefahr, dass Protokolle verloren gingen je nach
Dauer der Abfrage bzw. Protokollumschaltung+ Initialisierung bei nur einem RFM.
Anbei meine Messungen mit allen drei Sensortypen im Vergleich.
Kurz vor 8:00 Uhr habe ich meinen Rollagen geöffnet.
Hier hat der DS18B20 (ohne Hülse), weil näher zum Fenster schön empfindlich reagiert.
Von den Absolutwerten scheinen alle drei Sensortypen ganz gut beisammen zu liegen.
Allerdings habe ich auch nicht auf 0.1 Grad genau kalibriert. ;)
Ich bin Batteriemäßig jetzt von 3V auf um die 4.1 Volt Lithium Accu (18650) ausgewichen.
Der DHT läuft ohne Probleme und etwas mehr RSSI ist dabei auch noch herausgesprungen.
Mal schauen, wie sich die Langzeit-Stabilität sich entwickelt.
Vielen Dank für Eure Anregungen.
Grüße,
Jürgen
So - nochmal ein letzte wüstes Bild...
Messumgebung:
5x DS18B20 im Metallgehäuse, auf Kühlkörper getaped, ESPEasy, 0.01° Auflösung (12 bit)
LGW.BME280: ohne direkte thermische Kopplung am gleichen Kühlkörper (systembedingt 0.1°C Auflösung)
ESPEasy.BME280: ohne direkte thermische Kopplung am gleichen Kühlkörper, 0.01° Auflösung (20bit)
ESPEasy.DHT22: ohne direkte thermische Kopplung am gleichen Kühlkörper, 0.01° Auflösung (16bit)
Delta-T wurde anhand des Mittelwert von vier DS18B20 gebildet.
Alle Messewerte sind "raw", d.h. ohne Kalibrierungsfaktor oder -offset.
DS18B20
Die Werte liegen eigentlich im +/1 Bit Zählfehlerbereich - bis auf den kleinen Ausreiser vom Sensor DA - der hat einen konstanten Offset von ca. 3x LSB.
Bei der Extremwert-Bestimmung (Eiswasser, kochendes Wasse bei 1013hPa) lagen die DS' im Mittel bei ~0,3° / 100,2° - eigentlich ein akzeptabler Wert um in diesem Falle ohne große Kalibrierung zu arbeiten.
BME280
Die beiden Sensoren liegen nur ~0.2°C auseinander - ausreichend genau für den Hausgebrauch.
Die Differenz zum DS liegt bei 0.4 - 0.6° - was eigentlich ein akzeptabler Wert ist.
Deutlich sichtbar ist die geringe Reaktionszeit bedingt durch die Bauform und Masse. Dies bedeutet wiederum, das die Bauart und -form des Shields selbst Einfluss auf die Temperaturdifferenz hat.
DHT22
Die Abweichung des DHT22 ist mit ~0.3° aktzeptabel. Allerdings sieht man bei deltaT und Absolutwerten, dass die 16bit anscheinend nicht durchgereicht werden - im Diagram ist ein 0.1°C Rauschen sichtbar.
Ich gehe mittlerweile davon aus, dass die extremen Abweichungen (>2°) der BME's von der direkten Umgebung der Sensoren (genauer: der Plazierung bzw. der Beschaltung) abhängig sind - nicht jedoch von der Grundgenauigkeit.
Der DHT22 liegt bei mir von der Temperatur auch sehr gut, aber rH stimmt nicht.
Der BME280 (FORCED mode) liegt konstant fast genau 1°C zu hoch und er wird durch nichts erwärmt.
Der SHT75 reagiert auf geringe Temperaturänderungen (0.5°C) extrem schnell, der (Metall-)DS18B20 braucht da teils 5 Minuten oder mehr, bis er bei der Temperatur angekommen ist. Aber dann decken sie sich wieder tadellos und dauerhaft.
Der LM75 liegt deutlich zu tief. Zwischen LM75 und dem BME280 beträgt die Differenz immerhin 2°C. Aber der LM75 kann eh nur 0.5°C-Schritte.
Aktuell bin ich recht sicher, dass der SHT75 stimmt (sowohl Feuchte als auch Temperatur) und der DS18B20 auch.
Es kann ja durchaus sein, dass bei es den BMEs gut und schlecht kalibrierte gibt. Bei den BMP180 habe ich das auch schon mal ermittelt (vor längerer Zeit). 6 Stück vermessen und einer lag deutlich daneben.
Das Ergebnis sah so aus:
#1: 22,2 / 1020 hPa
#2: 22,2 / 1022 hPa
#3: 22,5 / 1019 hPa
#4: 22,2 / 1021 hPa
#5: 22,7 / 1022 hPa
#6: 24,2 / 1022 hPa
@HCS da ich gerade im Platinen Thread gelesen habe, dass du in der 1.22 drei Modi, unter anderem einen LAN Modus einbauen wolltest und man das WLAN dann ja nicht mehr bräuchte habe ich da ne kleine Idee.
Ich weiß nicht, ob du den Amazon DASH Button Thread hier schon mitbekommen hast. Hier gibt es für 5€ nen IO Button, der per WLAN angebunden wird. Ich hatte als ich es gesehen habe direkt die Idee, ob das nicht mit dem LGW, der per LAN angeschlossen ist, kombinieren kann. Der LGW wurde dann einen WLAN Accesspoint öffnen und hier einfach die DHCP Requests abfangen, die die Buttons senden ins Internet mussten die laut aktuellem Stand gar nicht kommen und man könnte sich somit noch nen zusätzliches Endgerät (OpenWRT Router z.B.) sparen, das durchgehend laufen müsste. Justme1968 ist da auch ganz aktiv am mit entwickeln/ testen momentan.
Gesendet von iPhone mit Tapatalk
Mal eine Frage zum Bestücken des BME280.
Auf der Platine des Gateway ist ein Punkt aufgedruckt, der eigentlich mit dem Punkt auf der Unterseite des BME übereinstimmen müsste.
Leider bekomme ich keine Daten des Sensors. Ist dort ein Fehler in der Library des Bauteils? Ich Frage nur, da das Bild im Wiki dann nicht stimmt.
Der BME280 sollte ja nach dem I2C und Sensorscan beim Start des LGW aufgeführt werden oder irre ich mich da?
Zitat von: oli82 am 07 September 2016, 14:03:28
Auf der Platine des Gateway ist ein Punkt aufgedruckt, der eigentlich mit dem Punkt auf der Unterseite des BME übereinstimmen müsste.
Nein, das ist der Punkt, der rechts oben auf dem Gehäuse eingraviert ist (nicht mit der Bohrung unten verwechseln), siehe Bild.
Gruß PeMue
Schande über mein Haupt!
Ich habe einen BME280 bestellt und einen BMP280 geliefert bekommen.
Da kann das nicht funktionieren ;)
Zitat von: oli82 am 07 September 2016, 16:38:05
Ich habe einen BME280 bestellt und einen BMP280 geliefert bekommen.
open dispute? ;D ;D ;D
Zitat von: oli82 am 07 September 2016, 16:38:05
Ich habe einen BME280 bestellt und einen BMP280 geliefert bekommen.
Cool wäre, wenn ich einen BME280 bestelle und einen BMW750 geliefert bekomme ;D ;D ;D
Zitat von: Hagenuck1 am 07 September 2016, 13:29:42
@HCS da ich gerade im Platinen Thread gelesen habe, dass du in der 1.22 drei Modi, unter anderem einen LAN Modus einbauen wolltest und man das WLAN dann ja nicht mehr bräuchte habe ich da ne kleine Idee.
Halt halt. Das neue FHEM-Modul 36_LaCrosseGateway wird drei Modi unterstützen, um LGWs in der jeweiligen Anbindung optimal zu unterstützen.
Zitat von: Hagenuck1 am 07 September 2016, 13:29:42
Ich weiß nicht, ob du den Amazon DASH Button Thread hier schon mitbekommen hast. Hier gibt es für 5€ nen IO Button, der per WLAN angebunden wird. Ich hatte als ich es gesehen habe direkt die Idee, ob das nicht mit dem LGW, der per LAN angeschlossen ist, kombinieren kann. Der LGW wurde dann einen WLAN Accesspoint öffnen und hier einfach die DHCP Requests abfangen, die die Buttons senden ins Internet mussten die laut aktuellem Stand gar nicht kommen und man könnte sich somit noch nen zusätzliches Endgerät (OpenWRT Router z.B.) sparen, das durchgehend laufen müsste. Justme1968 ist da auch ganz aktiv am mit entwickeln/ testen momentan.
Sorry, aber irgendwie verstehe ich noch nicht, was das Ziel der Aktion sein soll.
Soll das LGW dann ein Gateway zur Anbindung dieser Buttons an FHEM sein?
Zitat von: HCS am 07 September 2016, 18:16:19
Halt halt. Das neue FHEM-Modul 36_LaCrosseGateway wird drei Modi unterstützen, um LGWs in der jeweiligen Anbindung optimal zu unterstützen.
Sorry, aber irgendwie verstehe ich noch nicht, was das Ziel der Aktion sein soll.
Soll das LGW dann ein Gateway zur Anbindung dieser Buttons an FHEM sein?
Den entscheidenden Teil habe ich natürlich vergessen, ja das war mein Gedanke, vorausgesetzt auch du hast Interesse an den günstigen Buttons. Würde sich ja wenn man das LGW sowieso in betrieb hätte könnte man es damit noch darum ergänzen die Buttons an FHEM anzubinden, ohne dass jeder auf seinem FHEM mit Python Scripts und den Berechtigungen "basteln" musste, damit man das betätigen der Buttons abfangen kann.
Gesendet von iPhone mit Tapatalk
Hallo
ich habe den Füllstandssensor https://forum.fhem.de/index.php?topic=23217.0 (https://forum.fhem.de/index.php?topic=23217.0) nachgebaut, und funktionierte auch mit einem normalen Jeelink. Da ich aber jetzt ein Lacross Gateway habe, und ich sowieso Reichweitenprobleme hatte, möchte ich den Levelsender eben auch über das Gateway laufen lassen.
Sehe ich das richtig, das dies noch nicht in der FW implementiert ist?
Ich hänge mal das Log mit an, evtl. sieht man da mehr?
15:51:09: LaCrosse [a7 95 fc fd 1d ] CRC:WRONG
15:51:09: LaCrosse [9b 6 77 37 2b ] CRC:OK S:92c NewBatt:0 Bit12:0 Temp:27.70 Hum:55 WeakBatt:0 CRC:43
15:51:12: LaCrosse [95 6 48 40 7a ] CRC:OK S:914 NewBatt:0 Bit12:0 Temp:24.80 Hum:64 WeakBatt:0 CRC:122
15:51:13: LaCrosse [6c 30 e1 d0 81 ] CRC:WRONG
15:51:14: LaCrosse [92 6 44 40 5c ] CRC:OK S:98 NewBatt:0 Bit12:0 Temp:24.40 Hum:64 WeakBatt:0 CRC:92
15:51:14: LaCrosse [9b 6 77 37 2b ] CRC:OK S:92c NewBatt:0 Bit12:0 Temp:27.70 Hum:55 WeakBatt:0 CRC:43
15:51:15: LaCrosse [95 86 52 3e c8 ] CRC:OK S:916 NewBatt:0 Bit12:0 Temp:25.20 Hum:62 WeakBatt:0 CRC:200
15:51:16: LaCrosse [98 6 58 3c 18 ] CRC:OK S:920 NewBatt:0 Bit12:0 Temp:25.80 Hum:60 WeakBatt:0 CRC:24
15:51:18: LaCrosse [61 40 92 9c 8f ] CRC:WRONG
15:51:20: LaCrosse [95 6 48 40 7a ] CRC:OK S:914 NewBatt:0 Bit12:0 Temp:24.80 Hum:64 WeakBatt:0 CRC:122
15:51:22: LaCrosse [92 6 44 40 5c ] CRC:OK S:98 NewBatt:0 Bit12:0 Temp:24.40 Hum:64 WeakBatt:0 CRC:92
15:51:22: LaCrosse [aa e3 9d 61 c0 ] CRC:WRONG
15:51:22: LaCrosse [9b 6 77 37 2b ] CRC:OK S:92c NewBatt:0 Bit12:0 Temp:27.70 Hum:55 WeakBatt:0 CRC:43
15:51:24: LaCrosse [95 86 52 3e c8 ] CRC:OK S:916 NewBatt:0 Bit12:0 Temp:25.20 Hum:62 WeakBatt:0 CRC:200
15:51:24: LaCrosse [98 6 58 3c 18 ] CRC:OK S:920 NewBatt:0 Bit12:0 Temp:25.80 Hum:60 WeakBatt:0 CRC:24
15:51:27: LaCrosse [78 70 ad bb fb ] CRC:WRONG
15:51:29: LaCrosse [95 6 48 40 7a ] CRC:OK S:914 NewBatt:0 Bit12:0 Temp:24.80 Hum:64 WeakBatt:0 CRC:122
15:51:30: LaCrosse [92 6 44 40 5c ] CRC:OK S:98 NewBatt:0 Bit12:0 Temp:24.40 Hum:64 WeakBatt:0 CRC:92
15:51:31: LaCrosse [9b 6 78 37 b2 ] CRC:OK S:92c NewBatt:0 Bit12:0 Temp:27.80 Hum:55 WeakBatt:0 CRC:178
15:51:32: LaCrosse [95 86 52 3e c8 ] CRC:OK S:916 NewBatt:0 Bit12:0 Temp:25.20 Hum:62 WeakBatt:0 CRC:200
Die Adresse 14,8,2C,16,20 sind TX29 Thermostate.
Die letzte gültige Raw Message mit dem normalen Jeelink sah so aus: OK LS 15 0 10 110 3 212 47 (wobei die Werte da völlig aus dem Ruder sind, da ich grad dran rumgebastelt hab)
Was mir auffäll ist die Länge der Nachricht, sie ist länger im Gegensatz zu ner TX29 Nachricht.
Gibt es da ne Möglichkeit, wie ich das ans laufen bekomme?
Gruß
Stivmaster
Zitat von: Stivmaster am 10 September 2016, 15:58:51
Sehe ich das richtig, das dies noch nicht in der FW implementiert ist?
Der LevelSender ist bereits seit Begin an implementiert. Funktioniert bei mir auch problemlos.
Bist Du sicher, das Du ihn mit dem JeeLink aktuell noch empfängst?
Wie hast Du denn das Log erzeugt?
Auf der configseite des esp. Dann muss ich mich noch mal hinsetzen und schauen warum es nicht geht. Das dumme ist nur, dass der rfm12 des levelsenders defekt war, und ich nun den des jeelinks umgelötet habe. Nachlieferung dauert noch (China)
Ich hätte noch einige 433 rfm 12 rumliegen. Meinst würd des funktionieren, wenn ich den rfm69 auf 433 umstell für Testzwecke?
Gesendet von meinem Nexus 5 mit Tapatalk
Zitat von: Stivmaster am 10 September 2016, 18:43:58
Meinst würd des funktionieren, wenn ich den rfm69 auf 433 umstell für Testzwecke?
Das würde ich nicht tun.
Zitat von: HCS am 10 September 2016, 18:27:35
Der LevelSender ist bereits seit Begin an implementiert.
Levelsender? Ich glaube, ich muss mal suchen gehen ;D
Zitat von: PeMue am 10 September 2016, 20:40:51
Levelsender? Ich glaube, ich muss mal suchen gehen ;D
Schau mal auf dem Grund vom Tank ;D ;D ;D
Oder hier: https://forum.fhem.de/index.php/topic,23217.0.html
Sorry, war mein Fehler, hatte übersehen dass es ein extra Analyze commando für den Levelsender gibt.
Der Fehler liegt ganz klar an meinem Sender, ist irgendwo ein Wackelkontakt drauf. Wenn ich die Baugruppe ein wenig hin und her bewege, fängt er mittendrin an zu senden.
Vor ein paar Tagen hatte ich die Situation, dass das LGW von meinen 2 FHEM-Instanzen aus nicht mehr erreichbar war und ich daher stundenlang folgende Meldungen im Log hatte (mein timeout Attribut enthält den Wert 120,60).
2016.09.10 18:12:35 3: Opening LaCrosseGateway device 192.168.0.28:81
2016.09.10 18:12:38 3: Can't connect to 192.168.0.28:81: Connection timed out
2016.09.10 18:13:38 3: Opening LaCrosseGateway device 192.168.0.28:81
2016.09.10 18:13:41 3: Can't connect to 192.168.0.28:81: Connection timed out
2016.09.10 18:14:42 3: Opening LaCrosseGateway device 192.168.0.28:81
2016.09.10 18:14:45 3: Can't connect to 192.168.0.28:81: Connection timed out
...
Aufgrund der Nichterreichbarkeit von FHEM zum LGW kam auch kein Reset auf der Schnittstelle zum Erfolg.
Leider kann ich nicht sagen, ob das LGW selber noch normal lief oder ob es sich aufgehängt hat.
Erst ein Aus- und Einschalten des LGW hat wieder zu einer funktionierenden Kommunikation geführt.
Schön wäre es, wenn auch auf Seiten des LGW geprüft wird, ob eine bidirektionale Kommunikation mit einem FHEM-Server möglich ist und – falls dies über einen definierbaren Zeitraum nicht möglich ist – einen eigenen Reset auslöst. Ein eigener Watchdog!?
LG
Holger
Zitat von: Omega am 12 September 2016, 09:58:14
Schön wäre es, wenn auch auf Seiten des LGW geprüft wird, ob eine bidirektionale Kommunikation mit einem FHEM-Server möglich ist und – falls dies über einen definierbaren Zeitraum nicht möglich ist – einen eigenen Reset auslöst. Ein eigener Watchdog!?
Das kommt dann demnächst dran, wenn ich das 36_LaCrosseGateway Modul erweitere. Da will ich die "timeout 120,60" Geschichte eh ändern auf "lebst Du noch - ja" was dann auch ermöglich, dass LGW rebooten zu lassen, wenn sich keiner mehr drum kümmert, ob es noch lebt. Das war jetzt aber nur das ganz grobe Grobkonzept.
Aktuell sollte eigentlich der WatchDog vom ESP8266 das LGW rebooten, wenn es komplett steht. Aber evtl. ist es ja auch mit gestorbenem DataPort noch im Kreis gelaufen.
V1.22
WiFi deaktivieren
Man kann nun mit einen 10k pullup auf 3.3V an MOSI == GPIO13 == D7 "jumpern", dass man kein wifi will.
Wenn voranden, wird WiFi sofort beim Start deaktiviert.
WiFi deaktivieren
Neue Konfiguration auf der setup page, ob wifi verwendet werden soll.
Wenn kein WiFi, dann werden die debug Meldungen beim Start unterdrücken.
LED
Wenn WiFi deaktiviert war, hat die LED keine aushgehenden Daten signalisiert
RSSI
Wenn WiFi deaktiviert ist, dann wird als RSSI nicht 31 sonder "Off" gesendet
BME280
Ich habe den Patch von SusisStrolch übernommen (FORCED mode)
Einstellungen abrufen
Man kann auf der seriellen Schnittstelle die aktuellen Einstellungen abrufen.
Das command ist 1g
Man bekommt dann so etwas zurück:
"SETUP ctSSID esesidee; ctPASS PasstWort; staticIP 192.168.31.211; staticMask 255.255.255.0; staticGW 192.168.31.1; HostName LGW211; StartupDelay 1; ISID 0xD3; Altitude 220; CorrT 0; CorrH 0; DataPort1 81; DataPort2 82; SerialBridgePort 85; SerialBridgeBaud 38400; UseMDNS true; IO0 OLED mode=s; IO1 OLED mode=thp; IO2 OLED On; IO3 OLED Off; oledStart 120; KVInterval 10; KVIdentity 211; PCA301Plugs 036180=3,03A094=1,035FF1=6;"
Einstellungen setzten
Man kann nun die Einstellungen, die man auf der setup page setzen kann, auch über die serielle Schnittstelle senden.
set myJeeLink213 raw "SETUP ..."
Das ... sind die gewünschten Einstellungen. Es müssen nicht alle Einstellungen gesendet werden sondern nur die, die man setzen will.
Es werden nur die Einstellungen gesetzt und im EEPROM gespeichert, es wird aber kein Reboot ausgelöst.
Einen Reboot kann man mit "set myJeeLink213 raw 8377e" auslösen (oder einfacher mit dem neuen Modul 36_LaCrosseGateway).
Mehrere Einstellungen können durch Semikolon getrennt angegeben werden.
Beispiel: set myJeeLink213 raw "SETUP UseWiFi false; IO0 OLED mode=thp; IO1 OLED Off; CorrT -2.5; ISID 213"
Die Namen der zu setzenden Variablen kann man sich oben rausinterpretieren (siehe "Einstellungen abrufen" 1g)
"Hardware page im Frontend"
Neue page "Hardware" im Frontend, die die erkannte Hardware anzeigt.
- mögliche / gefundene Hardware
- Kalibrierdaten von BME280 und BMP180
- Raw-Values für T, P und H
- ADC-Werte von BME280 und BMP180
"Humidity Plausibilität"
100% werden nun auch als gültig betrachtet
36_LaCrosseGateway.pm
Ab sofort gibt es ein neues FHEM device (physisches Modul) mit dem Namen "LaCrosseGateway", das dass LGW besser unterstützt.
Es kann alternativ als Ersatz für 36_JeeLink verwendet werden und soll es mittelfristig komplett ablösen (nur für LGW, nicht für die JeeLink-Sketche)
Der wesentliche Grund ist, dass das LGW inzwischen nur noch so ungefähr wie ein JeeLink funktioniert und mit einem eigenen Modul besser angesteuert werden kann.
Doku siehe commandRef. Hier die wesentlichen Punkte:
- Bekommt ein LGW auf "initialized", egal ob per WiFi, Kabel oder USB angebunden.
- Attribut "ownSensors" (dispatch / readings / both) mit dem festgelegt werden kann, ob die Werte des internen Sensors (Temperatur, ...)
dispatch: wie bisher an ein LaCrosse device weitergegeben werden
readings: als eigene Readings in diesem Device angelegt werden
both: beides
- Attribut "kvp" (dispatch / readings / both) mit dem festgelegt werden kann, ob die Statuswerte des LGW (RSSI, UpTime, ...)
dispatch: wie bisher an ein KVP device weitergegeben werden
readings: als eigene Readings in diesem Device angelegt werden
both: beides
- Aus set <LGW> reset wurde set <LGW> connect
da es schon immer keinen Reset gemacht hat, sondern nur versucht, die Verbindung zum LGW (neu) aufzubauen
- Neu: set <LGW> reboot
Sendet dem LGW ein Kommando (8377e), dass es einen Reboot macht.
Funktioniert natürlich nur, wenn eine Verbindung zum LGW aufgebaut ist.
- Neues Attribut disable
Wenn disable = 1 dann wird kein connect versucht und eingehende Daten werde nicht dispatched.
Damit kann man es zu Testzwecken mal vorübergehend abschalten, ohne die Definition löschen zu müssen.
- Neues Attribute mode (USB / WiFi / Cable)
Legt fest, ob das LGW per WiFi (default), USB oder Kabel(USR-TCP232) angebunden ist.
Daran wird festgemacht, wie bestimmte Dinge (Initialisierung, ...) erledigt werden müssen
- Alle Gets sind entfallen, da es keinen gab, der beim LGW Sinn macht.
- Entfallene Sets: beep, led, led-on-for-timer, setReceiverMode
- Entfallene Attribute: tune_..., Beep..., flashCommand
Das ist der erste Anlauf.
Man solle seinen bestehenden JeeLink define recht einfach in einen LaCrosseGateway define umbauen können.
Weitere Dinge wie: flashen eines LGW per USB / USR-TCP232, bessere Überwachung ob es noch lebt, einige der erst mal entfallenen sets (z.B. led) ... stehen auf der (unverbindlichen) Wunschliste
Super, was du alles auf die Beine stellst :) :)
Danke!
Holger
Hab grad mal die V1.22 geflasht - sieht sehr schön aus die Hardware Seite! :)
Zitat von: HCS am 12 September 2016, 21:52:06
V1.22
WiFi deaktivieren
Man kann nun mit einen 10k pullup auf 3.3V an MOSI == GPIO13 == D7 "jumpern", dass man kein wifi will. Wenn voranden, wird WiFi sofort beim Start deaktiviert.
Cool, da ist die Software schneller als die Hardware :o
Tolle Leistung, muss ich gleich mal probieren!
Danke + Gruß
Peter
Anlegen von zwei LCGs hat auch funktioniert, allerdings müsste da ggf. der Part in der commandref angepasst/erweitert werden:
Zitatdefine <name> LaCrosseGateway <device>
<device> specifies the serial port to communicate with the LaCrosseGateway. The name of the serial-device depends on your distribution, under linux it is something like /dev/ttyACM0 or /dev/ttyUSB0.
Hier könnte man noch den <device> Part um <IP>:<PORT> erweitern
PS: Ich werde in der Mittagspause gleich mal den ersten BME280 einbauen ;)
Nachtrag: BME280 statt DHT22 und BMP180 wird auch sofort erkannt. 8)
Den Bug von Peter kann ich bestätigen, meine aber das der vorher auch schon war. Da dachte ich aber das liegt wohl an meinem Browser.
Hallo HCS,
auf der Setup-Seite ist vermutlich noch irgend etwas ungewolltes, siehe Anhang (erste Zeile).
Kann das LGW auch über das USR-TCP232 geflasht werden? Oder geht das nur per WiFi?
Danke + Gruß
PeMue
Zitat von: waschbaerbauch am 13 September 2016, 12:23:29
Hier könnte man noch den <device> Part um <IP>:<PORT> erweitern
Ich habe es in der ToDo unter der Rubrik "Macht keinen Spaß aber leicht zu erfüllen" abgespeichert.
Zitat von: PeMue am 13 September 2016, 12:37:46
auf der Setup-Seite ist vermutlich noch irgend etwas ungewolltes
Damit kämpfe ich schon längere Zeit. Mal geht es, mal nicht und ich komme nicht dahinter, was da passiert.
Bisher ist nur klar, dass es mit den Comboboxen für den MCP23008 zu tun hat.
LGW rebooten und hoffen, dass es dann funktioniert.
Zitat von: PeMue am 13 September 2016, 12:37:46
Kann das LGW auch über das USR-TCP232 geflasht werden? Oder geht das nur per WiFi?
Über den USR-TCP232 geht es aktuell nicht, da er ja ohne RTS und DTR angeschlossen ist und somit Reset und BootMode nicht gesteuert werden können.
Ich überlege gerade, wie ich das aus dem neuen 36_LaCrosseGateway Modul heraus hinbekomme. Evtl. so eine Art Upload über die Serielle Schnittstelle was es erst mal im SPIFFS ablegt (so mache ich es auch bei der WiFi-Upload-Variante) von wo ich es dann ins Flash weiterschieben kann.
-> Version 1.xy falls das überhaupt so geht.
Aktuell liegen zwei BreadBoards mit BME280 gar nicht so weit auseinander hier - inwieweit das geeichten Instrumenten entspricht ist natürlich fraglich.
Readings
humidity 46 2016-09-13 14:27:44
pressure 1014 2016-09-13 14:27:44
state initialized 2016-09-13 14:19:58
temperature 29.6 2016-09-13 14:27:44
BME280 OK T=29.6 H=45 P=1014 Calibration: T1:28096 T2:26576 T3:50 H1:75 H2:355 H3:0 H4:336 H5:0 H6:30 P1:36819 P2:-10669 P3:3024 P4:6672 P5:-77 P6:-7 P7:9900 P8:-10230 P9:4285 ADC: T=542937 H=29747 P=348197
Readings
humidity 44 2016-09-13 14:28:01
pressure 1014 2016-09-13 14:28:01
state initialized 2016-09-13 14:28:00
temperature 29.5 2016-09-13 14:28:01
BME280 OK T=29.5 H=44 P=1014 Calibration: T1:28507 T2:26722 T3:50 H1:75 H2:353 H3:0 H4:343 H5:0 H6:30 P1:35354 P2:-10644 P3:3024 P4:3530 P5:125 P6:-7 P7:9900 P8:-10230 P9:4285 ADC: T=548552 H=30041 P=421886
Zitat von: HCS am 13 September 2016, 13:12:15
Über den USR-TCP232 geht es aktuell nicht, da er ja ohne RTS und DTR angeschlossen ist und somit Reset und BootMode nicht gesteuert werden können.
Das wäre doch eine Option für die v1.1 Platine, oder?
Gruß PeMue
Zitat von: PeMue am 13 September 2016, 14:53:22
Das wäre doch eine Option für die v1.1 Platine, oder?
Der USR-TCP232 hat doch gar kein RTS und DTR?
Ich befürchte, dass das eher mit Software gelöst werden muss.
Zitat von: waschbaerbauch am 13 September 2016, 14:24:49
humidity 46 /44
pressure 1014 / 1014
temperature 29.6 /29.5
Die decken sich gut. Kannst Du ermitteln, ob die 29.6 °C stimmen oder ob das zu hoch liegt?
Subjektiv ist das mit Sicherheit so - ich schwimme hier im Dachboden-Arbeitsraum in meiner eigenen Suppe ;)
Ich habe aber nichts was geeicht ist zum Vergleich. Was ich anbieten kann sind aktuelle Werte:
BME280-01: T=30.7 H=38 P=1012
BME280-02: T=30.8 H=39 P=1013
LaCrosse TFA: T: 29.8 H: 45 (30.3155.WD in der Abseite)
PS: Ich sehe grad in meinem China-Sammelsurium sind noch DS18b20 mit 'Stahlkappe' - wenn die genau(er) sein sollten bau ich davon gleich mal ein MySensorNode auf.
PPS: Nun (denke ich) habe ich einen ersten MySensor mit DHT22 und zwei DS18b20 mit 'Stahlkappe' aufgebaut. Morgen werde ich dann mal ein Rudel Daten haben..
Zitat von: HCS am 13 September 2016, 18:13:28
Der USR-TCP232 hat doch gar kein RTS und DTR?
Stimmt, da habe ich leider das Datenblatt nicht richtig im Kopf gehabt. Sorry.
Upgrade (FW) und Umstellung (Modul) erfolgreich umgesetzt.
Eine ganz tolle Sachen, vielen Dank und meinen größten Respekt!
;D ;D ;D
LCG.EG.BB
BME280 OK T=28.0 H=47 P=1014 Calibration: T1:28096 T2:26576 T3:50 H1:75 H2:355 H3:0 H4:336 H5:0 H6:30 P1:36819 P2:-10669 P3:3024 P4:6672 P5:-77 P6:-7 P7:9900 P8:-10230 P9:4285 ADC: T=537894 H=30094 P=346719
LCG.DG.BB
BME280 OK T=27.6 H=50 P=1014 Calibration: T1:28507 T2:26722 T3:50 H1:75 H2:353 H3:0 H4:343 H5:0 H6:30 P1:35354 P2:-10644 P3:3024 P4:3530 P5:125 P6:-7 P7:9900 P8:-10230 P9:4285 ADC: T=542832 H=31123 P=420359
MySensors
DS18b
temperature 26.9 2016-09-14 12:20:17
DS18b No.2
temperature1 26.8 2016-09-14 12:20:17
DHT22
temperature2 26.6 2016-09-14 12:12:46
humidity1 57.6 2016-09-14 12:20:16
TFA LaCrosse
state T: 27.3 H: 52
MOD.LCG.EG.BB.LABOR
BMP180 OK T=28.2 P=1013 Calibration: AC1:8597 AC2:-1181 AC3:-14523 AC4:34391 AC5:25353 AC6:20514 B1:6515 B2:47 MB:-32768 MC:-11786 MD:2605 ADC: T=29585 P=172552
DHT22 OK T=28.1 H=48
MOD.LCG.DG.PCB (im Gehäuse)
BMP180 OK T=38.9 P=1014 Calibration: AC1:8185 AC2:-1110 AC3:-14365 AC4:34145 AC5:25314 AC6:17881 B1:6515 B2:41 MB:-32768 MC:-11786 MD:2629 ADC: T=28758 P=166235
Jetzt fühle ich mich an die Flens Werbung erinnert: 'Der konnte aber viele Sprachen..' - 'Jo, genützt hats ihm aber nix!' ;)
Zitat von: waschbaerbauch am 14 September 2016, 14:01:06
... genützt hats ihm aber nix!' ;)
Doch, hat es. Ich würde mal vermuten, dass die tatsächliche Temperatur irgendwo bei 26.8 +- 0.2 liegt.
Und die BME280 liegen wie viele ihrer Art etwas zu hoch.
Aber: einen vernünftigen Vergleich bekommt man nur, wenn man das eine Stunde laufen lässt und sich nichts regt. Fenster zu, Tür zu und nichts bewegt sich. Nur dann haben alle Sensoren die Umgebungstemperatur angenommen, da sie unterschiedlich schnell auf Temperaturänderungen reagieren.
In meinem NanoLGW hat es übrigens gerade 48°C :o
Zitat von: HCS am 14 September 2016, 21:28:53
In meinem NanoLGW hat es übrigens gerade 48°C :o
Kommt hin:
LaCrosse_02 (nanoLGW) T: 43.7 H: 22 P: 1012
Zitat von: PeMue am 14 September 2016, 21:35:49T: 43.7 H: 22 P: 1012
Bei 22% rH kann es zumindest nicht rosten ;D ;D
Es hilft alles nix - ich muss euch fragen - ich komme einfach nicht drauf was ich nicht richtig bzw. verkehrt mache..
Mein LC-Gateway auf PCB funktioniert ja, auf BreadBoard eigentlich auch - eigentlich ...
Drei LCGs mit nodeMCU / RFM69CW laufen - zwei davon haben z.Zt. ein OLED und BME280, eins ein BMP180 und DHT22, zwei haben ein Piezo..
OLEDs zeigen alles an, Piezos piepsen, RFM69CW empfangen und senden, ebenso die 'lokalen' Sensoren.
Nun versuche ich mich schon immer wieder mal daran einen Arduino am SC16IS750 für die serielle Übertragung zu bewegen.
Zu Beginn dachte ich es liegt ggf. am fehlenden Bootloader der Arduino pro-mini (3,3V/8MHz und 5V/16MHz).
Heute habe ich es dann mal ausprobiert mit dem Arduino nano (5V/16MHz) diesem Ziel näher zu kommen.
Der serieller Port ist auf 85 eingetragen und das define habe ich dann wie folgt in FHEM konfiguriert:
Als SIGNALduino: define LCG.SIGduino SIGNALduino <IP>:85
Als CUL: define LCG.nanoCUL868 CUL <IP>:85 1234
Während des connects/reopen erscheint im OLED auch das Symbol des Chips, verschwindet dann aber wieder. Ich nehme an das in diesem Fall die Initialisierung nicht erfolgen kann, ich verstehe allerdings nicht wo hier mein Fehler liegt.. Den nanoCUL hab ich mit CUL-FW und aCUL-FW getestet, die pro-mini jeweils mit der passenden .hex aus dem aCUL-FW Package. Der SIGNALduino wird mit einem Superhet betrieben (Empfänger only).
Kann mir vielleicht jemand einen Tipp geben wo hier ggf. mein Denkfehler liegt?
PS: Die Spannung kommt beim einen BreadBoard von einem QUMOX Netzteil und beim anderen BreadBoard über ein 2A Netzteil das eine BreadBoard Spannungsversorgung speist.
Edit: Jetzt brat mir doch einer nen Storch .. Kaum droh ich mit Hilfe aus dem Forum, da arbeitet das Teil plötzlich mit dem SIGNALduino wie es soll. Ich habe jetzt mal einen Arduino aus einer anderen Charge mit anderem PCB genommen und die Verbindung scheint stabil - vielleicht liegt es auch am gewechselten WLAN - das werde ich fix noch mal antesten..
Edit2: Eine Änderung des WLANs ist nicht die Lösung, allerdings bekomme ich den SIGduino ab und an initialisiert und er empfängt dann auch Daten, bis er dann unvermittelt auf 'closed' geht. Gab es hier nicht irgendwo grad die Möglichkeit das über LAN statt WLAN zu machen? *such* ;D
Edit3: Ok, da hab ich wohl beim überlesen übersehen das es da um ein ganz anderes Thema ging. Mit meinem ENC28J60 Ethernet LAN Network Board (https://www.aliexpress.com/item/ENC28J60-LAN-Ethernet-Network-Board-Module-for-arduino-25MHZ-Crystal-AVR-51-LPC-STM32-3-3V/32299031978.html?spm=2114.01010208.3.11.wiYNwG&ws_ab_test=searchweb201556_10,searchweb201602_3_10057_10065_10056_10068_10037_10055_10054_10069_301_10059_10033_10058_10032_10073_10017_10070_9979_10060_10061_10052_10062_10053_10050_10051,searchweb201603_3&btsid=e81ab2c8-d6a7-4f95-89d0-f11629f0aaf5) komm ich da wohl nicht weit - dazu muss/soll es wohl ein USR-TCP232-T2 sein :D
Moin,
ist es Absicht das die Sourcen auf Sourceforge verschwunden sind?
Gruß Mario
Zitat von: waschbaerbauch am 18 September 2016, 18:48:54
ist es Absicht das die Sourcen auf Sourceforge verschwunden sind?
Da ist nicht nur das LGW nicht zu sehen, ich sehe ganz FHEM nicht mehr.
Mit einem SVN-Client sieht man es aber, es existiert also noch.
Was zum ... ;)
Mit der Anbindung eines nanoCULs bin ich aber dennoch nicht weiter gekommen. Immerhin läuft jetzt ein SIGNALduino stabil auf einem anderen BreadBoard. Der Status geht immer nur auf 'opened' und nicht auf 'initialized'. Bei der Version steht dann immer 'No answer' - eine Idee was ich noch machen könnte um einen selfCUL zur Zusammenarbeit zu überreden?
Zitat von: waschbaerbauch am 18 September 2016, 20:29:52
Der Status geht immer nur auf 'opened' und nicht auf 'initialized'. Bei der Version steht dann immer 'No answer' - eine Idee was ich noch machen könnte um einen selfCUL zur Zusammenarbeit zu überreden?
Hast Du den schonmal an USB in Betrieb gehabt? Wenn ja, liegt's eher am LGW, ansonsten am CUL.
Gruß Peter
wg "opened"-Status am sgd.
https://forum.fhem.de/index.php/topic,53510.msg451831.html#msg451831 (https://forum.fhem.de/index.php/topic,53510.msg451831.html#msg451831)
@Peter
Nein hatte ich noch nicht als nanoCUL am USB selbst laufen. Das liegt aber in der Hauptsache darin begründet, das ich mein FHEM ja virtualisiert habe und der Rpi mit dem Virtualhere im Wohnzimmer steht und ich auf dem Dachboden bastel - für eine weitere Virtualhere Lizenz war ich bisher zu geizig ;)
Jetzt wo ich das so schreibe denk ich mir grad - ach ich könnte ja auch noch ein FHEM auf einem Rpi installieren zum testen ::) manchmal ist man ja auch wie vernagelt ...
@juergs
Danke für den Link, aber das passt schon mit dem SIGNALduino - der Chip bleibt im Display stehen und im FHEM werden auch Daten angezeigt.
Da steht zum Glück nur 'state' auf 'opened und 'DevState' auf 'initialized'
PS: Am Ende werde ich wohl doch alle seriellen Geräte via ESP8266 via WiFi verbinden, ich dachte nur es wäre doch charmant nur eine Spannungsversorgung zu nutzen und zumindest ein serielles Gerät mit auf das LCG zu bringen.
Hast Du auf der setup page die baud rate für den Serial bridge port auf 38400 gesetzt?
Sodele - nachdem einige Menschen (ich zum Beispiel) den Kopf nur zum Haare schneiden haben - das Problem ist gelöst und sitzt zwischen den Ohren ... Der Fehler war letzten Endes dann die Initialisierung im Frontend des LCG. Ich hatte nun ja wirklich schon fast alle Werte mal eingetragen von 115200, 57600, 19200 und 9600 - war war es natürlich? Kaum trägt man 38400 ein schon funktioniert der ganze Sermon ??? :o
Bin ich aber auch erst drüber gestolpert nachdem ich meine gelöteten nanoCULs am Rpi2 mit einer Testlizenz von virtualhere zum ESXi durchgereicht hatte.
Kurios daran ist eigentlich nur das der SIGNALduino, seitdem ich hier gepostet hatte das er funktioniert, jetzt wieder rumzickt :D
Zitat von: HCS am 18 September 2016, 21:32:44
Hast Du auf der setup page die baud rate für den Serial bridge port auf 38400 gesetzt?
Ja jetzt ja ;)
Zitat von: waschbaerbauch am 18 September 2016, 21:38:59
... den Kopf nur zum Haare schneiden haben ...
Das mir der baudrate hat mir mein Frisör erzählt ;D ;D ;D
Zitat von: waschbaerbauch am 18 September 2016, 21:38:59
Kurios daran ist eigentlich nur das der SIGNALduino, seitdem ich hier gepostet hatte das er funktioniert, jetzt wieder rumzickt :D
Ich glaube, ich muss mal einen SIGNALduino flashen und anschließen. Aber erst in einer Woche. Klappt am Strand meistens nicht.
Nicht dass ich das in den Sand setze ;D ;D ;D
Viel schlimmer als der Sand ist ja das ich mir damit schon mindestens 2 Nächte um die Ohren geschlagen habe, weil die Maschine gewinnt nie! ;)
Nachdem ich hier noch mal alles sortiert und kontrolliert habe läuft auch der SIGNALduino wieder. Ab und an geht da der Chip im Display weg, kommt aber (im Moment) wieder. Ich meine im FHEM Device steht dann unter 'DevState' was von 'INACTIVE' oder sowas.
PS: Jetzt wo das überhaupt erstmal läuft kann ich auch mal wieder dazu übergehen den pro-mini zu überreden ;)
Edit: Man glaubt es kaum - der Arduino pro-mini 3,3V/8MHz läuft nun auch, nur den 5V/16MHz konnte ich (noch) nicht überreden - dazu muss ich vermutlich eine passende Firmware kompilieren :D
Würde sich diese Board eignen für das lcg? Denke schon oder?
http://www.electrodragon.com/product/nodemcu-lua-amica-r2-esp8266-wifi-board
(http://www.electrodragon.com/product/nodemcu-lua-amica-r2-esp8266-wifi-board/)
Muss man bei diesem Board was beachten?
Gruß und danke
Sascha
Von mobil gesendet daher kurze Antwort
Zitat von: sash.sc am 20 September 2016, 14:49:34
Würde sich diese Board eignen für das lcg? Denke schon oder?
http://www.electrodragon.com/product/nodemcu-lua-amica-r2-esp8266-wifi-board
(http://www.electrodragon.com/product/nodemcu-lua-amica-r2-esp8266-wifi-board/)
Muss man bei diesem Board was beachten?
Gruß und danke
Sascha
Von mobil gesendet daher kurze Antwort
Ja, eignet sich. Nein, man muss nichts beachten (außer richtig rum einlöten 8)).
Da ich beim Testen ständig zwischen zwei AP wechseln muss, habe ich mal einen kleinen Patch angehängt, welcher eine alternative SSID/Passwort erlaubt.
Falls keine Connection zur SSID möglich ist, wird mit SSID2 probiert bevor das LCG in den AccessPoint wechselt.
Edit:
Da fehlt noch ein Hauch "Polish" - aber fürs Testen reichts erst mal...
Edit2:
Screenshot angehängt...
Zitat von: PeMue am 20 September 2016, 16:48:24
Ja, eignet sich. Nein, man muss nichts beachten (außer richtig rum einlöten 8)).
Läuft. Hab erstmal die fw drauf geschmissen. Das Modul kommt morgen drauf. 8)
Von mobil gesendet daher kurze Antwort
Zitat von: SusisStrolch am 20 September 2016, 18:55:25
Da ich beim Testen ständig zwischen zwei AP wechseln muss, habe ich mal einen kleinen Patch angehängt, ...
OK. Schaue ich mir nächste Woche mal an, wenn ich wieder zurück bin.
Ich hätte da mal ein kleines Problem mit dem 36_LaCrosseGateway.pm Modul ::)
Vorhin ist mir ein Gateway durch meine eigene Dusseligkeit ausgefallen ... habs natürlich nicht sofort gemerkt.
Dann hat das Modul mir fleissig das Log zugemüllt
2016.09.22 20:02:47 3: CUL_HM set BZ.Temperatur.virt_Sensor1 virtTemp 22
2016.09.22 20:03:05 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:08 3: Can't connect to LaCrosseGateway2.cyberdyne.de:81: No route to host
2016.09.22 20:03:09 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:09 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:09 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:09 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:09 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:09 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:10 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:11 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:11 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:11 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:11 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:12 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:12 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:12 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:12 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:12 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:12 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:12 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:12 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:12 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:13 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:13 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:13 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
2016.09.22 20:03:13 3: Opening LaCrosseGateway2 device LaCrosseGateway2.cyberdyne.de:81
........
Sage und schreib 3 MB in einer Stunde.
Lässt sich dieser Output irgendwie zähmen?
Ich hätt ja nix dagegen wenn das einmal die Minute passiert .... aber vier mal pro Sekunde :o
Hallo,
habe auch das Problem, allerdings ein wenig mehr Einträge. Im Einsatz ist V1.22.
$ grep -c "2016.09.23 05:49:42 3: Opening FL_LCGW device 192.168.1.10:81" fhem-2016-09-23.log
1167
Internals:
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF 192.168.1.10:81
DeviceName 192.168.1.10:81
FD 79
FL_LCGW_MSGCNT 34650
FL_LCGW_TIME 2016-09-23 06:58:56
NAME FL_LCGW
NR 747
PARTIAL
RAWMSG OK 9 51 1 4 132 62
STATE initialized
TYPE LaCrosseGateway
model [LaCrosseITPlusReader.Gateway.1.22 (1=RFM69 f:868300 r:17241) + BME280 + SC16IS750 + OLED {IP=192.168.1.10}]
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:
2016-09-23 06:57:58 FramesPerMinute 26
2016-09-23 06:57:58 RSSI -89
2016-09-23 06:57:58 UpTime 0Tg. 9Std. 57Min. 5Sek.
2016-09-23 06:58:56 state initialized
Attributes:
event-on-change-reading state
icon it_wifi
initCommands 46h "OLED mode=thps" v
kvp readings
room 99_IOs
timeout 120,30
MfG
Edit:
Habe erst einmal verbose = 2 gesetzt ...
Zitat von: HCS am 21 September 2016, 09:48:54
OK. Schaue ich mir nächste Woche mal an, wenn ich wieder zurück bin.
Hmm, anscheinend haben die zwei Zeilen das Faß zum Überlaufen gebracht...
Genauer gesagt, nach einmaligem Aufruf der Setup-Page funktionieren die "großen" Seiten (log, hardware, setup) nicht mehr.
Auch gibt es ab und an mal eine Exception...
11:48:41: LaCrosseITPlusReader.Gateway V1.22jor
11:48:41: Free heap: 19016 Flash size: 4194304 SDK: 1.5.4(baaeaebb)
11:48:41: Reset: Exception
11:48:41: Fatal exception:29 flag:2 (EXCEPTION) epc1:0x4022b7ae epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
11:48:41: Starting I2C with 400 kHz
11:48:41: OLED found
11:48:41: SC16IS750 found
11:48:41: Startup delay: 2 seconds
11:48:41: Starting wifi
11:48:41: Start WIFI_STA
11:48:41: HostName is: LCG-Kombi
11:48:41: Using static IP
11:48:41: IP: 192.168.254.87
11:48:41: Mask: 255.255.255.0
11:48:41: Gateway: 192.168.254.1
11:48:41: Trying to connect to AP HeavenNo7
11:48:41: .....
11:48:41: connected :-)
11:48:41: SSID: HeavenNo7
11:48:41: IP: 192.168.254.87
11:48:41: Starting frontend
11:48:41: Starting OTA
11:48:41: Starting data port 1 on 81
11:48:41: Starting serial bridge on port 85 with 38400 baud
11:48:41: Searching RFMs and Sensors
11:48:41: Radio #1 found: RFM69
11:48:41: Configured altitude: 55
11:48:41: BME280 found
11:48:41: Sending init String to FHEM
11:48:41: [LaCrosseITPlusReader.Gateway.1.22jor (1=RFM69 f:868300 r:17241) + BME280 + SC16IS750 + OLED {IP=192.168.254.87}]
11:48:41: Setup completely doneSieht nach Memoryproblem aus - die Exception ist in "memset"...
Zitat von: AxelSchweiss am 23 September 2016, 00:03:10
Sage und schreib 3 MB in einer Stunde.
Lässt sich dieser Output irgendwie zähmen?
Ich hätt ja nix dagegen wenn das einmal die Minute passiert .... aber vier mal pro Sekunde :o
Morgen liefert das FHEM-Update die Erlösung aus.
Zitat von: SusisStrolch am 24 September 2016, 12:24:22
Sieht nach Memoryproblem aus - die Exception ist in "memset"...
Ja, das dachte ich bei dem Problem mit der zweiten Zeile Combos auch schon.
Muss mal forschen. Ich war aber schon mal recht sicher, dass es kein Problem vom TCP-Stack ist sondern tatsächlich der gebildete String schon geschreddert ist, bevor er an "send" übergeben wird.
Zitat von: SusisStrolch am 24 September 2016, 12:24:22
Hmm, anscheinend haben die zwei Zeilen das Faß zum Überlaufen gebracht...
Genauer gesagt, nach einmaligem Aufruf der Setup-Page funktionieren die "großen" Seiten (log, hardware, setup) nicht mehr.
Auch gibt es ab und an mal eine Exception...
11:48:41: LaCrosseITPlusReader.Gateway V1.22jor
11:48:41: Free heap: 19016 Flash size: 4194304 SDK: 1.5.4(baaeaebb)
11:48:41: Reset: Exception
11:48:41: Fatal exception:29 flag:2 (EXCEPTION) epc1:0x4022b7ae epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
11:48:41: Starting I2C with 400 kHz
11:48:41: OLED found
11:48:41: SC16IS750 found
11:48:41: Startup delay: 2 seconds
11:48:41: Starting wifi
11:48:41: Start WIFI_STA
11:48:41: HostName is: LCG-Kombi
11:48:41: Using static IP
11:48:41: IP: 192.168.254.87
11:48:41: Mask: 255.255.255.0
11:48:41: Gateway: 192.168.254.1
11:48:41: Trying to connect to AP HeavenNo7
11:48:41: .....
11:48:41: connected :-)
11:48:41: SSID: HeavenNo7
11:48:41: IP: 192.168.254.87
11:48:41: Starting frontend
11:48:41: Starting OTA
11:48:41: Starting data port 1 on 81
11:48:41: Starting serial bridge on port 85 with 38400 baud
11:48:41: Searching RFMs and Sensors
11:48:41: Radio #1 found: RFM69
11:48:41: Configured altitude: 55
11:48:41: BME280 found
11:48:41: Sending init String to FHEM
11:48:41: [LaCrosseITPlusReader.Gateway.1.22jor (1=RFM69 f:868300 r:17241) + BME280 + SC16IS750 + OLED {IP=192.168.254.87}]
11:48:41: Setup completely done
Sieht nach Memoryproblem aus - die Exception ist in "memset"...
Rätsel gelöst - Ursache waren nicht die zusätzlichen Optionen, sondern die Arduino-Umgebung.
Ich hatte statt der 2.3er Version den git-master am Rennen...
Läuft jetzt bereits 24h ohne Störungen...
Hallo zusammen,
Ich hätte da eine Verständnisfrage. Irgendwie bekomme ich es nicht hin, die Werte von angelernten LaCrosse Sensoren, auf das OLED Display zu bekommen. Den Thread habe ich jetzt einige Male gelesen und das Wiki auch. Wenn es um interne Werte vom Gateway oder Textlines geht, ist das ja klar. Aber
set myJeeLink raw "OLED mode=f" verstehe ich nicht. Das Display zeigt ausschließlich von Fhem festgelegten Text. Wo lege ich den Text denn fest? Muß hierzu ein Notify mit Variablen gebaut werden?
Vielleicht hätte jemand für mich eine Idee, wie ich das hinbekomme.
Vielen Dank schonmal.
Gruß Carsten
Zitat von: CarstenF am 30 September 2016, 13:52:14
Vielleicht hätte jemand für mich eine Idee, wie ich das hinbekomme.
Steht doch im Wiki (http://www.fhemwiki.de/wiki/LaCrosseGateway#Beispiele):
set myJeeLink raw "OLED show=Soll: 20.5,Ist: 19.2,,t"Gruß PeMue
So weit war ich ja schon. Jetzt steht Soll, 20,5 Grad und Ist 19,2 im Display. Ich hätte aber gerne die Werte meiner LaCrosse Sensoren im Wechsel und weiß nicht wie ich das anstelle. Sorry wenn ich mich da jetzt was blöde anstelle, aber ich blicke gerade nicht durch.....
Die Werte musst Du auslesen bzw. vorher aufbereiten und an das OLED senden. Dafür kannst du notify oder at oder einegene Routine oder... nutzen.
OK, das habe ich irgendwie also Information überlesen. Irgendwie hatte ich vermutet die Werte werden automatisch von den angelernten Sensoren übernommen. Dankeschön
Nur die Werte der internen Sensoren (falls vorhanden) werden automatisch angezeigt, die externen nicht.
Habe da einen kleinen Feature-Request für das FHEM Modul 36_LaCrosseGateway.pm
Es wäre super, wenn man anstatt der IP-Adresse auch den FQDN angeben könnte. Das mach insbesondere Sinn, weil man für das LGW ja auch im Setup einen Hostnamen vergeben kann.
Zitat von: weini am 01 Oktober 2016, 18:18:47
Habe da einen kleinen Feature-Request für das FHEM Modul 36_LaCrosseGateway.pm
Das liegt nicht an 36_LaCrosseGateway.pm
Das ist eher ein Firmware/DNS-Problem.
Mach mal einen nslookup auf die IP-Adresse vom LGW, was Du da bekommst.
ZitatDas liegt nicht an 36_LaCrosseGateway.pm
Völlig richtig, funktioniert nämlich wunderbar :) :) :)
Ich hatte es gestern versucht, da ging es nicht. Ich vermute, dass zu deim Zeitpunkt die Namesauflösung vom Raspi aus (mein FHEM Server) noch nicht funktioniert hat, von meinem Desktop aber sehr wohl.
Wie auch immer, Feature ist da! Vielleicht könntest du es bei Gelegenheit noch in der Doku erwähnen, da ist aktuell nur von IP-Adresse die Rede.
Whow, jetzt habe ich mir das ganze mal von Seite 1 an durchgelesen und bin total beeindruckt!
Kann man den Sketchup so erweitern das der auch MQTT-Nachrichten raushaut?
Das wäre doch eine klassische Anwendungsfalle dafür. Temperatur kommt per LaCrosse rein, zack raus als mqtt-Nachricht.
Zitat von: Bapt. Reverend Magersuppe am 13 Oktober 2016, 10:01:41
Kann man den Sketchup so erweitern das der auch MQTT-Nachrichten raushaut?
Sorry wegen der schlechten Nachricht: aktuell habe ich keine Pläne Richtung MQTT. Das wird es eher nicht geben.
MQTT macht aber auch keinen Sinn, um die Daten nach FHEM zu bringen, dafür gibt es ja bereits den Weg über das JeeLink / LaCrosseGateway device mit den nachgelagerten Modulen für LaCrosse, PCA301, EMT7110, Level, ... und MQTT wäre nur ein paralleler Pfad, um das zu erreichen, was bereits möglich ist.
Zitat von: HCS am 13 Oktober 2016, 10:16:30
Sorry wegen der schlechten Nachricht: aktuell habe ich keine Pläne Richtung MQTT. Das wird es eher nicht geben.
Oh wie schade. Da ist es wohl doch sehr mit fhem verheiratet und nicht universell einsetzbar. Da es nicht auf github liegt wird es wohl lizenzlich auch nicht möglich sein es zu forken ohne mit einem Bein auf der Anklagebank zu sitzen.
Zitat von: Bapt. Reverend Magersuppe am 13 Oktober 2016, 10:34:10
Oh wie schade. Da ist es wohl doch sehr mit fhem verheiratet und nicht universell einsetzbar.
Ja. Ich habe es genau und nur für FHEM geschrieben.
Zitat von: Bapt. Reverend Magersuppe am 13 Oktober 2016, 10:34:10
Oh wie schade. Da ist es wohl doch sehr mit fhem verheiratet und nicht universell einsetzbar. Da es nicht auf github liegt wird es wohl lizenzlich auch nicht möglich sein es zu forken ohne mit einem Bein auf der Anklagebank zu sitzen.
Der Quellcode ist veröffentlicht und open source, Du kannst damit machen, was Du willst - kopieren, optimieren, ruinieren, ...
Nur eben nicht erwarten, dass ich jeden Patch übernehme.
Zitat von: HCS am 13 Oktober 2016, 10:54:27
Ja. Ich habe es genau und nur für FHEM geschrieben.
Ich arbeite eben viel mit NodeRed und da gehts besser mit MQTT. Will ja auch kein Stress mit dem Autor machen wenn ich mich dran verüble. Also Du wärst nich sauer wenn man sich dran lang hangelt um das entsprechend anzupassen?
Zitat von: Bapt. Reverend Magersuppe am 13 Oktober 2016, 11:13:10
Ich arbeite eben viel mit NodeRed und da gehts besser mit MQTT. Will ja auch kein Stress mit dem Autor machen wenn ich mich dran verüble. Also Du wärst nich sauer wenn man sich dran lang hangelt um das entsprechend anzupassen?
Wie schon geschrieben, Du darfst Dir aus dem Quellcode machen was Du willst, aber ich werde in meine "offizielle" Version (zu 99,9x%) keine MQTT Implementierung übernehmen.
Das zieht nämlich (wenn man es für die Allgemeinheit tauglich machen will) eine Menge Implementierung, Konfiguration, Test, Dokumentation, ... nach sich.
Mal aus dem hohlen Bauch raus (kenne Deinen genauen use case nicht): denk mal drüber nach, ob ein alternatives IO-Device in FHEM (anstatt 36_JeeLink bzw. 36_LaCrosseGateway), das die Daten nicht an nachgelagerte FHEM-Module dispatched sondern per MQTT weitersendet, eine Alternative wäre.
Dann bräuchte man nicht zwei LGWs.
Moin
Ich habe jetzt das Carrierer-Board von Locutus. Wollte das jetzt eigentlich mit einem Wemos D1 betreiben. Aber ich finde jetzt keine Zeichnung wo das LGW mit einem Wemos abgebildet ist! D1-D8 sind soweit klar, RX, TX, RST und A0 auch. Nur den EN (CH_PD), den finde ich nicht! Kann mir jemand helfen?
Gruss und Danke Christoph
Zitat von: pc1246 am 18 Oktober 2016, 15:20:36
Nur den EN (CH_PD), den finde ich nicht! Kann mir jemand helfen?
Soweit ich noch weiß und den Schaltplan lese, ist EN / CH_PD bei den Wemos D0
Nimm RST, das geht auch.
Hallo zusammen.
habe da mal noch ne Frage. Ich wollte meinem LCG 2x RF69cw einpflanzen. Müssen an D1/d2 die beiden PullUp Widerständer von 4K7 dann verlötet werden? Oder nur wenn die anderen Sensoren mit verlötet werden.
Gruß Sascha
Hallo Sascha,
wenn Du ein breakout Bord mit Sensoren verlötet, sind die pull-ups mit drauf.
Gruß Peter
Habe nur nen fertigen nodemcu.
Von mobil gesendet daher kurze Antwort
Hab da mal ne blöde Frage... Hatte die Tage nen zweiten RFM69 auf nen Breakout gelötet, dann lt. Schaltplan verbunden.
Wollte das ganze dann Testen und habe dabei gesehen, dass auf dem LGW noch ne 1.17 oder so war, die ja keine Hardware Seite hatte. Dann habe ich durch nen "backup" Befehl das FHEM komplett zerschossen und die Sicherungen wollten auch nicht mehr.
Habe mittlerweile alles wieder eingerichtet und die alte fhem config wieder drin. Verbindung zum LGW wird nun auch aufgebaut, habe das dann nun auch auf die 1.22 aktualisiert. Hier wird mir jedoch auf der Hardware Seite unter "Hardware: Radio 1 & Radio 2 nichts angezeigt. Im LGW Log erscheint allerdings:
"DataPort: #81 received '1,868950,120i v'"
"PCA301: Initialized with 868950 kHz and 120 seconds poll"
Das LGW Device steht allerdings im LGW auf initialized & RAWMSG: "OK VALUES LGW 1302976 UpTimeSeconds=540,UpTimeText=0Tg. 0Std. 9Min. 0Sek. " -> Verbunden ist er also anscheinend und überträgt auch Daten.
Bin nun etwas verwirrt, weshalb bei meinen PCA301 Devices keine Daten mehr im FHEM bekommen ???
Zitat von: Hagenuck1 am 21 Oktober 2016, 21:03:45
Hab da mal ne blöde Frage... Hatte die Tage nen zweiten RFM69 auf nen Breakout gelötet, dann lt. Schaltplan verbunden.
Wollte das ganze dann Testen und habe dabei gesehen, dass auf dem LGW noch ne 1.17 oder so war, die ja keine Hardware Seite hatte. Dann habe ich durch nen "backup" Befehl das FHEM komplett zerschossen und die Sicherungen wollten auch nicht mehr.
Habe mittlerweile alles wieder eingerichtet und die alte fhem config wieder drin. Verbindung zum LGW wird nun auch aufgebaut, habe das dann nun auch auf die 1.22 aktualisiert. Hier wird mir jedoch auf der Hardware Seite unter "Hardware: Radio 1 & Radio 2 nichts angezeigt. Im LGW Log erscheint allerdings:
"DataPort: #81 received '1,868950,120i v'"
"PCA301: Initialized with 868950 kHz and 120 seconds poll"
Das LGW Device steht allerdings im LGW auf initialized & RAWMSG: "OK VALUES LGW 1302976 UpTimeSeconds=540,UpTimeText=0Tg. 0Std. 9Min. 0Sek. " -> Verbunden ist er also anscheinend und überträgt auch Daten.
Bin nun etwas verwirrt, weshalb bei meinen PCA301 Devices keine Daten mehr im FHEM bekommen ???
RFM69 falsch angeschlossen?
War mir recht sicher von nicht, aber da die Breakouts ja anders beschriftet sind als die Schaltpläne/ RFM69 hier mal die Auflistung (Hab momentan auch nur noch den ursprünglichen RFM dran):
LGW -> RFM69 (Breakout)
GND -> GND
D5 -> SCK
D6 -> SDO
D7 -> SDI
D8 -> SEL
Das war das, was ich aus dem Bild von deinem Breadboard so entnehmen konnte, aber da die Leitungen alle gelb waren.... :D
Hatte in dem Zuge des lötens auch die Leitungen durch unterschiedlich farbige ersetzt, so erschien mir das sicherer.
Zitat von: Hagenuck1 am 21 Oktober 2016, 21:15:19
GND -> GND
D5 -> SCK
D6 -> SDO
D7 -> SDI
D8 -> SEL
3.3V braucht er dann halt auch ;)
Zitat von: HCS am 21 Oktober 2016, 21:18:42
3.3V braucht er dann halt auch ;)
In der Tat, hatte ich gerade nur vergessen zu erwähnen ::)
Nach allem was Du beschrieben hast, läuft das LGW korrekt, FHEM verbindet sich drauf und es sendet das, was es weiß.
Nur erkennt es keinen RFM69 und das kann dann eigentlich nur ein RFM69-Problem sein.
Wenn es einen erkennt, dann muss das auf der Harware-Page stehen.
Defekt, doch falsch angeschlossen, ...
Zitat von: HCS am 21 Oktober 2016, 21:24:18
Defekt, doch falsch angeschlossen, ...
Mist :(
War die Verbindung, die ich oben geschrieben habe denn die richtige? Zu dem Breakout habe ich zumindest keinen Schaltplan gefunden....
Gesendet von iPhone mit Tapatalk
Zitat von: Hagenuck1 am 21 Oktober 2016, 22:07:32
War die Verbindung, die ich oben geschrieben habe denn die richtige?
Ja. SDO =
Serial
Data
Out = MISO =
Master
In
Slave (RFM69)
Out
SDI sinngemäß
Okay, Danke.
Habe den Fehler soeben gefunden. Er war grün und 10 cm lang:
(http://uploads.tapatalk-cdn.com/20161021/4d43dc00e5071f2cd5a090809e3f26cf.jpg)
Das nun auch beide 5/6 aus dem Paket defekt waren ist mir unbegreiflich....
Gesendet von iPhone mit Tapatalk
Hallo zusammen
Ich habe jetzt ein 868er carrier board von Damian am Laufen. Seltsamerweise ist, jetzt wo die RFM69 laufen, der BME280 nicht mehr da!? So als ob er da nicht mehr scannt, wenn er die RFMs gefunden hat? Version ist V1.22.
Gruss Christoph
Edit: Wenn ,am lange genug wartet geht er doch! War vorher, als die RFMs nicht liefen, anders, da war er gleich da!
Zitat von: pc1246 am 24 Oktober 2016, 22:40:15Edit: Wenn ,am lange genug wartet geht er doch! War vorher, als die RFMs nicht liefen, anders, da war er gleich da!
Das kann eigentlich nicht sein. Das LGW ermittelt beim Starten, welche Sensoren es findet, und danach nie wieder. Entweder ist er gleich da oder nie.
@pc1246: Macht es einen Unterschied, ob du einen Reboot des Moduls machst oder ob du es stromlos machst?
Ich habe mit meinem DHT22 noch immer einen kleinen Issue. Seit FW 1.22 wird er zwar zuverlässig erkannt, wenn das Modul stromlos war und dann neu Strom bekommt. Wenn ich aber einen Reboot mache, dann ist der DHT22 weg. Auch zig Reboots helfen nicht, er wird erst wieder gefunden wenn ich zwischenzeitlich den Strom unterbreche.
Hallo Holger,
Zitat von: Omega am 26 Juli 2016, 09:32:39
Nach einem Stromausfall ist das LGW (naturgemäß) schneller wieder oben als der Router, mit dem es sich verbinden soll.
Das führt leider dazu, dass gar keine Verbindung mehr zustande kommt (das Attribut timeout habe ich mit 120,60 definiert) – auch dann nicht, wenn der Router schon lange wieder bereit ist.
...
Meine Idee: Ein Configparameter, bei dem eine Verzögerung (in Sekunden) definiert werden kann, bis dass LGW nach einen Neustart einen 1. Verbindungsversuch startet. So könnte ich sicherstellen, dass das Umfeld bereit ist, bevor das LGW ,,loslegt".
welche Zeit hast Du denn eingestellt? Ich hatte vor kurzem einen Stromausfall und da waren dann alle meine drei LGWs nicht erreichbar. Ich versuche es mal mit 120 s, dann sollte WLAN wieder oben sein.
Danke + Gruß
Peter
Zitat von: PeMue am 25 Oktober 2016, 20:34:39
Ich hatte vor kurzem einen Stromausfall ...
Zahlt ihr eure Stromrechnungen nicht oder warum habt ihr dauernd keinen Strom? ;D ;D ;D
Die konfigurierte Zeit muss so lange sein, dass der AccessPoint tatsächlich erreichbar ist. Sonst gibt das LGW auf und macht seinen eigenen AP für 15 Minuten auf und versucht nie wieder den AP zu connecten.
Ich habe bei mir drei Minuten eingestellt ... das nervt aber das man dann bei jedem Boot drei Minuten warten muss >:(
Lässt sich das Timeout eventuell etwas anders definieren ?
- Das LGW versucht N Sekunden lang alle X Sekunden einen Connect aufzubauen.
Wobei man N und X via der GUI einstellen kann.
Das hätte den Vorteil das man bei einem Reboot nicht warten muss und im Falle eines Falles das LGW aber lange genug einen Connect versucht.
Eventuell ist das ja was für die nächste Firmwareversion.
EDIT: Biiite :)
Zitat von: HCS am 25 Oktober 2016, 09:15:41
Das kann eigentlich nicht sein. Das LGW ermittelt beim Starten, welche Sensoren es findet, und danach nie wieder. Entweder ist er gleich da oder nie.
Hallo HCS
Habe jetzt gerade noch einmal gestartet und da war der BME sofort da!? Keine Ahnung warum das gestern anders war. Kurze Frage zu den PCA's, nach welchem Schema findet das Gateway die? Ich habe 6 Stueck, 4 hat es gefunden, und der Jeelink kennt irgendwie noch vier weitere, sowie einen mit der Adresse 0000000.
Gruss Christoph
Zitat von: HCS am 25 Oktober 2016, 20:40:32
Zahlt ihr eure Stromrechnungen nicht oder warum habt ihr dauernd keinen Strom? ;D ;D ;D
Hm, vermutlich ist das Abschalten des einen Blocks des Kernkraftwerkes doch nicht ganz so rückwirkungsfrei :o
Leider habe ich ein paar Geräte, die nicht sauber wieder hochfahren:
- Radiowecker (ist verschmerzbar 8))
- Fußbodenzeizung im Bad (stellt dann auf warm)
- der USR-TCP braucht vermutlich auch noch etwas Überredung, um wieder zu spielen, warum auch immer
Der Rest funktioniert aber ...
Gruß Peter
Zitat von: weini am 25 Oktober 2016, 20:14:07
@pc1246: Macht es einen Unterschied, ob du einen Reboot des Moduls machst oder ob du es stromlos machst?
Ich habe mit meinem DHT22 noch immer einen kleinen Issue. Seit FW 1.22 wird er zwar zuverlässig erkannt, wenn das Modul stromlos war und dann neu Strom bekommt. Wenn ich aber einen Reboot mache, dann ist der DHT22 weg. Auch zig Reboots helfen nicht, er wird erst wieder gefunden wenn ich zwischenzeitlich den Strom unterbreche.
Sorry
Das habe ich gar nicht gesehen, das da noch ein post war! Ich kann das nicht so genau sagen, da ich doch teilweise massive Probleme habe, dass alles laeuft. Aber eben habe ich einen reboot gemacht, da ich ein Passwort vergeben habe, und da war "sofort" alles da.
Gruss Christoph
Zitat von: AxelSchweiss am 25 Oktober 2016, 20:49:33
- Das LGW versucht N Sekunden lang alle X Sekunden einen Connect aufzubauen.
Es versucht aktuell N=30 Sekunden lang alle X=0.5 Sekunden einen Connect aufzubauen.
Das kann man hochdrehen, aber dann wartet man halt genau diese lange Zeit, bis das LGW aufgibt und den AP auf macht, dass man es konfigurieren kann, wenn man noch keine SSID usw. konfiguriert hat oder sie ändern muss.
Um das Problem richtig zu lösen, müsste das LGW wissen, ob der AP in Kürze verfügbar ist oder ob das nie was wird.
Und um das zu wissen, müsste es einen Orakel-Server in Delphi abfragen.
Ich nehme es aber mal auf die Wunschliste.
Zitat von: pc1246 am 25 Oktober 2016, 20:50:46
Kurze Frage zu den PCA's, nach welchem Schema findet das Gateway die? Ich habe 6 Stueck, 4 hat es gefunden
Nach dem "oh ich habe da was gehört" Schema.
Bedeutet: das LGW lernt eine PCA dadurch, dass es sie irgendwann mal hört. Eine PCA sendet nur, wenn sie jemand fragt oder wenn man sie lokal schaltet.
-> Also die fehlenden mal lokal schalten, dann sollte das LGW sie hören und lernen.
Sobald es eine PCA gelernt hat, beginnt es, sie periodisch abzufragen.
Zitat von: pc1246 am 25 Oktober 2016, 20:50:46und der Jeelink kennt irgendwie noch vier weitere, sowie einen mit der Adresse 0000000.
Ich vermute, dass sich bei der 0000000 der JeeLink Sketch mal vertan hat.
Hallo HCS
Der 000000 taucht immer wieder auf, auch wenn ich den loesche! Zu Anfang hatte ich die/den FB/Monitor in Verdacht, nur meine habe ich schon ewig nicht benutzt. Evtl. hat ja ein Nachbar noch so eine Kombi, wobei ich bei den meisten schon war! Adresse ist uebrigens 7.
Gruss Christoph
Zitat von: HCS am 25 Oktober 2016, 20:40:32
Zahlt ihr eure Stromrechnungen nicht oder warum habt ihr dauernd keinen Strom? ;D ;D ;D
Die konfigurierte Zeit muss so lange sein, dass der AccessPoint tatsächlich erreichbar ist. Sonst gibt das LGW auf und macht seinen eigenen AP für 15 Minuten auf und versucht nie wieder den AP zu connecten.
Doch klar! Beim nächsten Stromausfall ;D ;D ;D
Zitat von: HCS am 25 Oktober 2016, 21:14:18
Es versucht aktuell N=30 Sekunden lang alle X=0.5 Sekunden einen Connect aufzubauen.
Das kann man hochdrehen, aber dann wartet man halt genau diese lange Zeit, bis das LGW aufgibt und den AP auf macht, dass man es konfigurieren kann, wenn man noch keine SSID usw. konfiguriert hat oder sie ändern muss.
Um das Problem richtig zu lösen, müsste das LGW wissen, ob der AP in Kürze verfügbar ist oder ob das nie was wird.
Und um das zu wissen, müsste es einen Orakel-Server in Delphi abfragen.
Den kann man ja eventuell bei Borland bestellen ;D
Ich muss aber auch drei Minuten warten wenn der AP schon arbeitet ... ich hätte jetzt gedacht das das LGW schon beim ersten positiven Versuch den Timeout nicht mehr weiter abarbeitet.
Ich also nach 0,5 Sekunden , trotz das ein Timeout von 180 Sekunden eingestellt ist, schon einen Connect habe.
Oder verstehe ich die Logik dahinter nicht ?
Meine Erfahrung: Als Startup-delay habe ich 150 Sekunden. So lange wartet derzeit das LGW gnadenlos, bis es einen Versuch startet, das definierte WLAN zu finden.
Stromausfall ist das eine - manchmal startet man aber einfach mal den Router neu (FW-Update, Parameteränderung, ...). Auch dann ist das WLAN weg. Mein ASUS-Router braucht i.d.R. gut 2 Min. bis er wieder bereit ist.
Eine Idee (k.A. ob umsetzbar): während der Delay-Zeit nicht einfach nur warten sondern in gewissen Zeitabständen einfach mal testen, ob das WLAN nicht doch bereits da ist und bereit, mit dem LGW zu reden.
Gruß
Holger
Da ich gerade den Patch von SusisStrolch für zwei SSIDs übernommen habe, muss man das dann auch berücksichtigen.
Dann wird es jetzt so:
Die Konfiguration "Startup-Delay" entfällt.
Das LGW versucht sofort den ersten konfigurierten AP zu erreichen und versucht das alle 0.5 Sekunden so lange, wie in Timeout dafür konfiguriert ist.
Wenn es ihn nach Timeout Sekunden nicht erreichen konnte, versucht es, sofern konfiguriert, den zweiten AP ebenfalls Timeout Sekunden lang zu erreichen.
Wenn es den nicht erreicht hat, dann macht es seinen eigenen AP auf, dass man es konfigurieren kann.
Ein unkonfiguriertes LGW (neu geflasht) öffnet dann nach 15 Sekunden (Default Timeouts) seinen AP, da keine SSIDs usw. konfiguriert sind.
Wenn ein konfiguriertes LGW dauerhaft keinen der konfigurierten APs mehr erreichen kann, dann muss man halt Timeouts in Summe warten.
Wer gegen den Plan etwas einzuwenden hat, der soll es jetzt sagen oder für immer schweigen ;D
-> Also die fehlenden mal lokal schalten, dann sollte das LGW sie hören und lernen.
Sobald es eine PCA gelernt hat, beginnt es, sie periodisch abzufragen.
Ich vermute, dass sich bei der 0000000 der JeeLink Sketch mal vertan hat.
[/quote]
Guten morgen
Also diesen It 0000000 habe ich auch laufend er müllt das Log zu .
Es handelt sich um einen Freetec Sensor ..
Autocreate aus und löschen und schon ist Ruhe
Gruss Markus
Zitat von: balki am 27 Oktober 2016, 09:42:13
Also diesen It 0000000 habe ich auch laufend er müllt das Log zu .
Es handelt sich um einen Freetec Sensor ..
Das ist interessant.
Zur Sicherheit: ihr empfangt den mit dem LGW?
Könnte ich da weitere Informationen bekommen, was das genau für ein Sensor ist und könnten wir mal die Rohdaten anschauen?
Eventuell kann man ihn ja erkennen und das LGW ihn ignorieren.
Der muss ja was senden, das wie eine PCA301 aussieht, sonst würde das LGW es nicht für PCA halten.
Zitat von: HCS am 27 Oktober 2016, 10:56:03
Das ist interessant.
Zur Sicherheit: ihr empfangt den mit dem LGW?
Könnte ich da weitere Informationen bekommen, was das genau für ein Sensor ist und könnten wir mal die Rohdaten anschauen?
Eventuell kann man ihn ja erkennen und das LGW ihn ignorieren.
Der muss ja was senden, das wie eine PCA301 aussieht, sonst würde das LGW es nicht für PCA halten.
Upps Hallo HCS
Da war es wohl noch zu früh für mich.
Ich hatte es auf der Arbeit nur überflogen . Zeitmangel :-)
Ich empfange dieses i0000000 über das LGW aber hier wird immer ein IT angelegt .weiss nicht wirklich ob hier hin gehört aber ich häng mal ein List dran
Internals:
00 1000
DEF 00000000 0100 1000
IODev minCUL
NAME IT_00000000
NR 151
STATE ???
TYPE IT
XMIT 00000000
XMITdimdown 00
XMITdimup 00
XMITon 0100
Code:
1 00000000
Readings:
2016-10-24 18:32:37 protocol SBC_FreeTec
Attributes:
IODev minCUL
ignore 0
room IT
verbose 0 Gruss Markus
Dein LCG nennt sich minCUL ? ???
Zitat von: waschbaerbauch am 27 Oktober 2016, 14:48:18
Dein LCG nennt sich minCUL ? ???
Nein, es ist wohl ein IT, das als IODev minCUL hat, das vermutlich am transparenten Datenport des LGW hängt, an dem ein miniCUL angeschlossen ist, der das schickt und somit das LGW auch als Übermittler der schlechten Nachricht nicht schuld ist.
Sowas dachte ich mir schon, wollte es aber nicht im Voraus 'unterstellen' ;)
Zu dem '00' Device meine ich mich zu erinnern das ich sowas auch mal hatte - sowie auch ein 'ff' Device.
So ganz zusammen bekomme ich das nicht mehr, aber ich meine das hatte bei mir etwas damit zu tun, das ich vier JeeLinks in Betrieb hatte (2x LaCrosse / 2x PCA301) und das es aufgrund der doppelten PCA301 Geschichte zu diesen Einträgen kam. Seit dem LaCrosseGateway ist mir das bisher nicht wieder untergekommen.
Zitat von: HCS am 27 Oktober 2016, 09:05:21
Wer gegen den Plan etwas einzuwenden hat, der soll es jetzt sagen oder für immer schweigen ;D
Plan ist gut. Ich hätte vermutlich die N Sekunden in zwei Hälften geteilt und eine Hälfte vor und die andere nach dem delay probiert. Kommt aber im Wesentlichen auf das selbe raus. Kann ich irgendwo nachschauen, wieviele connects notwendig waren?
Gruß PeMue
Zitat von: PeMue am 27 Oktober 2016, 18:47:20
Kann ich irgendwo nachschauen, wieviele connects notwendig waren?
Nein.
Zitat von: HCS am 28 Oktober 2016, 09:43:26
Nein.
Wäre es denkbar, diese in der nächsten Firmware Version irgendwo mit aufzunehmen (irgendwo bei RSSI), z.B.
Failed connects?
Danke + Gruß
Peter
Zitat von: PeMue am 29 Oktober 2016, 07:41:48
Wäre es denkbar, diese in der nächsten Firmware Version irgendwo mit aufzunehmen (irgendwo bei RSSI), z.B. Failed connects?
Ich glaube das wird nicht gehen.
Ich habe aber der Ablauf auch nicht korrekt beschrieben.
Das LGW "sagt" dem ESP, dass er eine Verbindung zu einem AP aufbauen soll. Das versucht er dann im Hintergrund so lange, bis es klappt.
Während der Zeit prüft das LGW (aktuell 15 Sekunden), ob inzwischen eine Verbindung da ist und macht erst weiter, wenn sie aufgebaut wurde oder es nach 15 Sekunden beschließt, dass das wohl nichts mehr wird und seinen eigenen AP aufmacht.
Das LGW weiß also nicht, wie und wie oft und wann der Core versucht, die Verbindung aufzubauen.
Aber wozu muss man das eigentlich wissen?
Zitat von: HCS am 29 Oktober 2016, 10:47:58
Das LGW "sagt" dem ESP, dass er eine Verbindung zu einem AP aufbauen soll. Das versucht er dann im Hintergrund so lange, bis es klappt.
renemt macht das in der Optolink Software so:
uint8_t wifiAttempts = 0;
WiFi.begin(ssid.c_str(), password.c_str());
while (WiFi.status() != WL_CONNECTED && wifiAttempts++ < 20)
{
Serial1.print('.');
delay(1000);
}
if (wifiAttempts == 21)
{
Serial1.printf("\n\nCould not connect to WiFi network '%s'.\n", ssid.c_str());
Serial1.println("Deleting configuration and resetting ESP to return to configuration mode");
SPIFFS.remove(_configFile);
yield();
ESP.reset();
}Sprich in Summe wird da für jeden Versuch 1 s gewartet bis zum nächsten Versuch.
Hier hätte ich auch nach der Hälfte der Versuche den delay eingebaut, um bei Stromausfall die Neukonfiguration zu vermeiden.
Zitat von: HCS am 29 Oktober 2016, 10:47:58
Aber wozu muss man das eigentlich wissen?
Als Merkmal, wie gut die Verbindung ist. Aber da kann man auch den RSSI nehmen. Mich hätte halt interessiert, wie lang der Router beim Stromausfall braucht, um wieder WLAN bereitzustellen. Aber deshalb einen Router Reset zu produzieren, ist mir das auch nicht wert ...
Gruß PeMue
Zitat von: PeMue am 29 Oktober 2016, 17:07:48
Sprich in Summe wird da für jeden Versuch 1 s gewartet bis zum nächsten Versuch.
Dieser Quellcode macht ziemlich genau das, was ich oben beschrieben habe.
WiFi.begin(ssid.c_str(), password.c_str());Sagt dem ESP, dass er eine Verbindung aufbauen soll und die Schleife danach schaut nur noch ein mal pro Sekunde, ob es bereits erledigt ist.
Es wird nicht mehrmals ein connect Versuch angestoßen. Das macht der ESP im Core alleine mit sich und den AP aus.
Was aber danach bekannt ist, ist die Zeit, die es gedauert hat, bis die Verbindung aufgebaut war. Die könnte ich auf der Hardware-page mit ausgeben.
Zitat von: HCS am 29 Oktober 2016, 21:03:19
Was aber danach bekannt ist, ist die Zeit, die es gedauert hat, bis die Verbindung aufgebaut war. Die könnte ich auf der Hardware-page mit ausgeben.
Das wäre doch was ... Dann stoße ich mal den
change request an ;)
Gruß PeMue
Zitat von: PeMue am 29 Oktober 2016, 23:04:31
Das wäre doch was ... Dann stoße ich mal den change request an ;)
Zu spät. Habes es vor eine halben Stunde eingebaut. ;D
Zitat von: HCS am 29 Oktober 2016, 23:05:32
Zu spät. Habes es vor eine halben Stunde eingebaut. ;D
Naja, das war eher für unsere Dokumentationsabteilung gedacht ;D
Nicht wirklich besonders wichtig - und vielleicht auch nur bei mir...
Mein LGW hat sich an der Zeitumstellung "verschluckt".
2016.10.30 02:47:03 2: ZWDongle_1 transmit NO_ACK for CB 16, target ZW_Bodentreppe
2016.10.30 02:00:45 3: Opening LaCrosseGateway device 192.168.0.28:81
2016.10.30 02:00:46 3: LaCrosseGateway device opened
2016.10.30 02:01:49 3: Opening LaCrosseGateway device 192.168.0.28:81
2016.10.30 02:01:50 3: LaCrosseGateway device opened
2016.10.30 02:02:52 3: Opening LaCrosseGateway device 192.168.0.28:81
2016.10.30 02:02:53 3: LaCrosseGateway device opened
2016.10.30 02:03:55 3: Opening LaCrosseGateway device 192.168.0.28:81
2016.10.30 02:03:56 3: LaCrosseGateway device opened
2016.10.30 02:04:59 3: Opening LaCrosseGateway device 192.168.0.28:81
2016.10.30 02:05:00 3: LaCrosseGateway device opened
Um 02:47 noch eine normale Meldung. Um 03:00 dann die Umstellung auf 02:00.
Ab 02:00 dann minütlich ein erfolgloser Verbindungsversuch.
und erst eine Std. später...
2016.10.30 02:59:55 3: Opening LaCrosseGateway device 192.168.0.28:81
2016.10.30 02:59:56 3: LaCrosseGateway device opened
habe ich den letzen - dann allerdings erfolgreichen - Verbindungsversuch.
Auf meiner 2. FHEM-Instanz genau das gleiche Verhalten.
LG
Holger
Ja, war bei mir auch auf allen FHEMs so. Ich denke, dass da eher das JeeLink- / LaCrosseGateway-Modul schuld ist.
Wenn man das timeout Attribut gesetzt hat, dann überwacht es den readingsTimestamp, ob timeout Sekunden lang vom LGW nichts mehr kam und baut dann die Verbindung neu auf. Und die Zeitumstellung verwirrt da scheinbar ein wenig.
Das Problem sollte sich aber irgendwann (hoffentlich vor der nächsten Zeitumstellung) eh erledigen, weil ich die Überwachung im LaCrosseGateway-Modul auf -> "Lebst Du noch" <- "Ja" umbauen will.
Auch bei mir bei allen drei LGWs so, hätte ich aber vermutlich gar nicht gemerkt ...
Gruß und schönen Sonntag.
PeMue
Bei mir steht im Log immer nur:
LaCrosseGateway2.cyberdyne.de:81 reappeared (LaCrosseGateway2)
Eine Disconnect-Meldung finde ich nirgends.
Anscheinend hat es auch noch Daten emfangen. Siehe Screenshot.
Daher scheint es wirklich nur die Verfügbarkeitsprüfung zu betreffen.
Zitat von: HCS am 27 Oktober 2016, 09:05:21
Da ich gerade den Patch von SusisStrolch für zwei SSIDs übernommen habe, muss man das dann auch berücksichtigen.
Moin
Gibt es das mit den zwei SSIDs schon irgendwie? Ich habe im Keller mit dem Wemos keinen Empfang mehr. Habe da aber noch ein anderes Netz!
Gruss Christoph
V1.23
Entwicklungsumgebung
Aktuelle Entwicklungsumgebung ist: Arduino 1.6.12 / Core 2.3.0
UseWifi
Die Einstellung "UseWiFi" auf der Setup page hat nicht funktioniert
SHT75
Das LGW unterstützt jetzt auch den SHT75
Er kann alternativ zu Radio #2 + Radio #3 verwendet werden.
Anschluss:
D3 (GPIO0) -> SHT75 DATA
D4 (GPIO2) -> SHT75 SCK
Den SHT75 würde ich aber nicht auf die Platine oder in ein Gehäuse mit rein setzen. Das wäre PVDS.
Ich habe ihn in einem Sensorgehäuse abgesetzt als externen Messfühler.
OLED-Konfiguration
Zusätzlich zu der "on/off/..." Konfiguration kann man nun auf der Setup-Page konfigurieren, ob das Display
direkt in einen bestimmten Modus (z.B. thp) gehen soll.
1.3" OLED
Das LGW unterstützt nun auch das 1.3" OLED I2C Display 128x64 Pixel mit SH1106 Chipsatz
Da ich leider keine Möglichkeit gefunden habe, zu erkennen, ob ich mit einem SSD1306 (0.96") oder einem SH1106 (1.3") Controller spreche, die beiden aber etwas unterschiedlich handhaben muss, muss man esauf der Setup-Page konfigurieren (Die Checkbox 1.3" ankreuzen)
Zwei SSIDs
Ich habe den Patch von SusisStrolch (sinngemäß) für zwei SSIDs übernommen.
Wenn man eine zweite SSID konfiguriert hat, dann wird, sofern nach dem konfigurierten Timout die erste nicht erreicht wird, versucht, die zweite zu erreichen.
Connectverhalten auf einen AP
Das ganze kommt aus dem Stromausfall-Thema, bei dem das LGW viel schneller als der AP bereit ist und bereits aufgibt, bevor der AP nach ein bis zwei Minuten bereit ist, einen Connect anzunehmen.
Man kann nun auf der Setup-Page für beide SSIDs einen Timeout konfigurieren.
120 bedeutet z.B. dass das LGW 120 Sekunden lang versucht, die SSID zu erreichen.
Diese Zeit war bisher hart in der Frimware auf 15 Sekunden festgelegt.
Dafür kann man dann das Startup-delay wieder auf 0 stellen.
Ich habe "Stromausfall" wie folgt simuliert und getestet:
- AP aus/ein, LGW bleibt an
- LGW aus/ein, AP bleibt an
- LGW + AP aus/ein
In allen drei Fällen kam die Verbindung wieder zustande und nach ein bis zwei Minuten sind wieder Daten in FHEM eingelaufen.
Connect Zeit
Die Zeit, die es gedauert hat, bis das LGW den connect zum AP hatte, wird nun auf der Hardware-Page ausgegeben
Committed ist's, das Update morgen liefert es dann aus oder Ungeduldige holen es sich schon jetzt aus dem Repository.
Anbei ein Schirmschuss von der setup-Page mit den Neuerungen und ein Vergleich 0.96" zu 1.3" OLED.
Uuuppss
Ich wollte aber nicht draengeln!
Wo ist denn das Haus auf dem grossen Display?!
Gruss Christoph
Zitat von: pc1246 am 30 Oktober 2016, 12:23:45
Wo ist denn das Haus auf dem grossen Display?!
Beim Erdbeben eingestürzt ;D ;D ;D
Nee. Als ich das Foto gemacht habe, hatte sich FHEM schlicht noch nicht auf das LGW verbunden. Kam dann kurz nach dem Foto.
Zitat von: HCS am 30 Oktober 2016, 12:26:31
Beim Erdbeben eingestürzt ;D ;D ;D
Hättest Du nur mal Deine Stromrechnung rechtzeitig bezahlt 8) 8) 8)
[quote}
... weil ich die Überwachung im LaCrosseGateway-Modul auf -> "Lebst Du noch" <- "Ja" umbauen will
[/quote]
Hast du das schon mit der 1.23 umgesetzt? Falls ja leide ich unter einer akuten Sehschwäche ;)
Auf diese Funktionalität habe ich immer schon gehofft.
Eigentlich schon ein älteres Problem, dass aber immer wieder mal auftaucht.
Ich habe 2 FHEM-Instanzen. LGW funktioniert auf beiden – meistens.
Hin und wieder habe ich aber das Problem, dass das LGW auf der 1. Instanz im Status ,,initialized" steht, in der 2. Instanz steht es aber nur auf ,,open" und eskommt zu keiner Verbindung.
2016.10.31 08:26:10 3: Opening LaCrosseGateway device 192.168.0.28:82
2016.10.31 08:26:11 3: LaCrosseGateway device opened
2016.10.31 08:27:17 3: Opening LaCrosseGateway device 192.168.0.28:82
2016.10.31 08:27:18 3: LaCrosseGateway device opened
2016.10.31 08:28:20 3: Opening LaCrosseGateway device 192.168.0.28:82
2016.10.31 08:28:21 3: LaCrosseGateway device opened
Das LGW ist im WLAN verbunden und auf der 1. Instanz bekomme ich auch Daten von den angebundenen Devices.
Hast du eine Idee dazu?
LG
Holger
Nachtrag:
Das ,,initialized" kam nicht, weil ich FHEM auf anderer HW neu aufgebaut hatte. Parallel dazu lief auch noch die alte Instanz. Das kann ja nicht gut gehen. :-[
Zitat von: Omega am 31 Oktober 2016, 08:35:37
Zitat
... weil ich die Überwachung im LaCrosseGateway-Modul auf -> "Lebst Du noch" <- "Ja" umbauen will
Hast du das schon mit der 1.23 umgesetzt? Falls ja leide ich unter einer akuten Sehschwäche ;)
Das ist noch nicht implementiert. Steht in der ToDo als Idee dieser Art:
- 36_LaCrosseGateway fragt LGW ob es noch lebt
- LGW Antwortet ja
- falls die Antwort ausbleibt, baut 36_LaCrosseGateway die Verbindung zum LGW neu auf
- Falls das LGW eine gewisse Zeit nicht gefragt wurde, macht es einen Reset
- Das Ganze in 36_LaCrosseGateway und im LGW konfigurierbar, ob und nach welcher Zeit.
Aber wie gesagt, es ist der Grob-Plan, muss es mal noch gründlich durchdenken und dann implementieren.
Das klingt doch schon recht durchdacht. Vor allem, dass das LGW selber über den Reset entscheidet und durchführt, finde ich gut. Bisher habe ich dann immer das "Knöpfchen" drücken dürfen, wenn ich von FHEM nicht mehr auf das LGW kam.
Evtl. könntest du ja die erfolgreiche Antwort als Reading in's LGW-Device schreiben.
LG
Holger
Ist es in der Version 1.23 neu, das mit "OLED mode=off" das OLED zwar abschaltet, aber die oberste Statusleiste eingeschaltet bleibt?
ein "OLED mode=off" gibt es nicht und ja, wenn Du das machst, dann bleibt die Statusleiste eingeschaltet.
Was es gibt: "OLED off"
Das ist ja cool. Das sollten wir als feature deklarieren. Dann darf ich nur die Buchstaben o und f nie im Mode für irgendwas verwenden.
Ja ähm - ja! :D
Das ja witzig, was bei Verwechslungen so alles im Eifer des Gefechts entdeckt wird :D :D :D
Ich wollte schon erst noch schreiben, dann das als 'mode=status' und 'mode=off' wieder restaurieren, aber das es ja dann eh 'OLED off' ist macht ggf ein 'OLED status' Sinn? ;)
PS: Wehe jetzt sucht wer nach OLED Streifen mit einer Zeile :D
@HCS
Könntest Du mir bitte verraten woher Du die "ArrayList.h" und "SHT75.h" her hast bzw. bereitstellen?
Die V 1.23 lässt sich nicht kompilieren.
Danke.
Zitat von: amunra am 01 November 2016, 19:00:26
@HCS
Könntest Du mir bitte verraten woher Du die "ArrayList.h" und "SHT75.h" her hast bzw. bereitstellen?
Die V 1.23 lässt sich nicht kompilieren.
Danke.
Argh :o Sorry!
Immer der gleiche Sch.....
Ich habe ein script, das die Auslieferung zusammenstellt und vergesse regelmäßig irgend welche neuen Files hinzuzufügen.
Habe das ZIP im Repo aktualisiert, nun sollte es gehen.
Zitat von: waschbaerbauch am 01 November 2016, 17:44:30
... macht ggf ein 'OLED status' Sinn? ;)
'OLED status' ist "OLED mode=s"
Man kann sich das Display in zwei Teile geteilt vorstellen. Die Statuszeile oben, die ist fix und den Bereich drunter, den kann man mit "OLED mode=..." und "OLED show=..." steuern.
Ja ich hatte auch grad noch mal ins Wiki geschaut 'mode=f' ist nur den vom FHEM gesendeten Text anzeigen. Da es den nicht gibt ist der Statusbalken da und Text halt blank ;)
@HCS
danke - läuft.
Hallo, ich habe 5x RFM69CW in der Bucht bei einem chinesischen Händler bestellt. Geliefert hat er nach langen 6 Wochen leider nur RFM69C (ohne W-Markierung - siehe Bild). Wenn ich das einfachste Setup 1x NodeMCU + 1 RFM69C nachbaue nach der Skizze in Post 1 dann funktioniert es nicht. Der NodeMCU bootet nicht mehr, ohne Anschluss des RFM69C bootet er korrekt. Welche Unterschiede gibt es zwischen diesen beiden Varianten? Die Datenblätter scheinen gleich zu sein.
Zitat von: reinni123 am 17 November 2016, 08:48:02
dann funktioniert es nicht. Der NodeMCU bootet nicht mehr, ohne Anschluss des RFM69C bootet er korrekt. Welche Unterschiede gibt es zwischen diesen beiden Varianten?
Ich würde behaupten, dass das ein RFM69CW ist. Das "W" steht oben bei GND.
Ich tippe eher auf falsch angeschlossen oder defekt.
Zitat von: HCS am 17 November 2016, 12:22:50
Ich würde behaupten, dass das ein RFM69CW ist. Das "W" steht oben bei GND.
Ich tippe eher auf falsch angeschlossen oder defekt.
Links neben dem "W" ist ein Kästchen, dort würde eine Markierung sein, wenn es ein RFM69CW wäre. Toll ausgedrückt, ne? :)
Aber ein Unterschied ist mir nach Vergleich der Datenblätter auch nicht erkennbar. Tippe auch auf falsch angeschlossen oder defekt. Bei mir haben auch beide Ausführungen funktioniert. Den ohne "W" gibt es auch bei Hoperf nicht mehr. Der RFM69CW ist wohl der Nachfolger.
Gruß Friedrich
Zitat von: Omega-5 am 20 November 2016, 10:58:45
Tippe auch auf falsch angeschlossen oder defekt.
Das ist mehr als plausibel.
GPIO15 = NSS ist downgepulled (cooles Wort), wenn das beim Booten von einem falsch angeschlossenen oder defekten RFM69 hochgezogen wird, dann versucht der ESP von einer SD-Karte zu booten.
Und da mit großer Wahrscheinlichkeit keine dran ist, bootet er dann nicht.
Also gab es mal eine RFM69C ohne W Variante in der Vergangenheit? Dann hat mir der China-Händler alte Chips verkauft.
Ich hab jetzt einen 2. Chip ausprobiert und der funktioniert. Also wahrscheinlich war der 1. wirklich defekt.
Zitat von: reinni123 am 20 November 2016, 19:16:00
Dann hat mir der China-Händler alte Chips verkauft.
Da würde ich mir wenig Sorgen machen. Ich habe viele, die exakt so bedruckt sind wie Deine und die funktionieren prima.
Guten Abend.
Seit Tagen versuche ich mich ans flashen des ATMEGA328-PU mit dem BOOTLoader "ATmegaBOOT_atmega328_8MHz.hex" vom Zip-Paket der
"carrier_board.zip" von Locutus . Irgendwie bekomme ich es auch mit Hilfe von Google nicht hin... *seufz*
Hätte bitte jemand einen Link zu einem Tutorial? Es wird mir nichts bringen zu sagen "nimm Xxxx dann passt des scho....".
Nick Gammons Seite (http://www.gammon.com.au/breadboard), die euch sicher auch bekannt ist, ist zwar recht hilfreich, aber auch die hilft mir nicht weiter.
Ich habe schon alles probiert, bis auf einen zus. Clock-Generator (hab leider keinen da) auf demBreadBoard, aber es soll ja auch mit Pin D9
des Arduinos funktionieren (Nano oder Mega256 vorhanden, leider KEIN UNO!), was aber leider auch nicht klappt. Und wenn ich das richtig verstehe,
kann letzteres daran liegen das der ATMEGA bereits einen UNO-Bootloader haben soll und dann ein Clock-Generator zwingend nötig ist?
Leider hänge ich hier fest und komm nicht weiter..... :'( :'( :'(
Grüsse aus dem Hessenländle
Alex
Eine Möglichkeit von vielen anderen .... für das Henne-Ei-Problem
http://www.fischl.de/usbasp/
oder sowas:
Low-Price (http://www.ebay.com/itm/USBASP-USBISP-AVR-Programmer-Adapter-10-Pin-Cable-USB-ATMEGA8-ATMEGA128-Arduino/310506909410?_trksid=p2047675.c100011.m1850&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D1%26asc%3D38530%26meid%3De51b90c68d42409fb5adfc2fc2b05be2%26pid%3D100011%26rk%3D2%26rkt%3D12%26sd%3D170813851774) plus 6pol-Adapter Adapter 6 Pin (http://www.ebay.com/itm/USBASP-10-to-6-pin-adapter-for-USBASP-USBISP-Programmer-Arduino-compatible-/131368077561?hash=item1e9625c8f9:g:1kEAAOSwGvhUH21S)
Oder ein freundlicher FHEM-User brennt Dir den Bootloader ;)
Vielleicht schreibst Du noch, was Du bisher probiert hast: Raspi/Windows?
Zitat von: bitbiter am 23 November 2016, 19:25:13
Leider hänge ich hier fest und komm nicht weiter..... :'( :'( :'(
Hallo Alex,
hast Du einen Programmer? Wenn nein, bräuchte man für Dich ein Tutorial, wie man mit einem Arduino Board einen Programmer emuliert.
Ich gehe mal davon aus, dass locutus' Board einen externen Quarz besitzt, so dass eine externe Taktquelle nicht notwendig ist.
Fazit: Mit den von Dir bisher bereitgestellten Informationen ist es schwer, das richtige Tutorial rauszusuchen.
Mit Programmer wäre die Sache wie folgt erledigt (Detaillierung würde folgen):
- Programmer anschließen
- mit avrdude den Bootloader brennen
- danach alles mit USB2seriell Adapter machen ...
Gruß PeMue
Hallo PeMue und Hallo Juergs.
nein einen programmer habe ich leider nicht.
Also probiert habe ich wie erwähnt: http://www.gammon.com.au/breadboard.
Ich dachte, laut genannter Seite, könnte man es auch mit einem Nano und einem Mega256 als Programmer zusammen mit dem Arduino IDE durchführen. Zusätzlich sind ja auf dieser Seite alle Infos UND Sketches die man braucht (Board-Detector / Board-Programmer). Nun denn..... Habe ich wohl gründlich missverstanden.
Das alles fand unter Windows statt und die Sketche wurden (erfolgreich) mit Arduino Software 1.62 geflasht.
USB->Serial Adapter habe ich auch hier...wüsste jetzt aber nicht wozu. Da ich mehrere habe (2 Stck): falls jemand einen braucht und nicht sehr geduldig ist wg. der langen Lieferzeiten aus China, kann er gerne einen einen oder beide zum Selbstkostenpreis + Versand haben. Noch original in Antistatik-Verpackung!). Oder gerne als "Kompensationsgeschäft" im Tausch gegen das flashen von 5 ATMEGA´s...Versand hin und zurück würde ich dann logischerweise übernehmen) Interessenten--> PN bitte ;)
Das sind die Adapter:
http://www.ebay.de/itm/322242184774?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
Nur mal zur Info: Ich habe Locutus´ Carrier Board-Platine hier mit all dem "Vogelfutter". EINEN habe ich mittlerweile zusammengelötet, fehlt nur noch der ATMEL.
Zu möglichen atomaren Auflösungen beim connecten mit der Stromquelle kann ich erst was sagen wenn der Rauchpilz verweht ist ;D Die SMD-Teile löten sind schon
eine gewaltige herausforderung... aber ich habe ja 4 Sets bestellt, in weiser Voraussicht das der eine oder andere evtl. in Flammen aufgehen könnte
Geht es denn u. U. auch mit dem Carrier-Board+Arduino oder anderes Tool zu flashen? DAS wäre ja noch eine Idee.
Gruss
Alex
Hallo Alex
Ich kann dir nicht so ganz folgen.
-Du hast das Board von locutus?
-Du willst den Atmega darauf flashen?
-Warum machst du es nicht so wie dort https://forum.fhem.de/index.php/topic,55705.msg473015.html#msg473015 beschrieben?
Gruss Christoph
Hallo pc1246
Zitat von: pc1246 am 24 November 2016, 16:48:18
-Du hast das Board von locutus?
Ja un einige der Kleinteile, aber nicht alle.
Zitat von: pc1246 am 24 November 2016, 16:48:18
-Du willst den Atmega darauf flashen?
Ich möchte den
BOOTLOADER auf ein ATMEGA328-PU
aus dem Zip-File von Locutus flashen (siehe https://forum.fhem.de/index.php/topic,55705.msg492073.html#msg492073)
Mein ATMEGA328-PU hat aber schon einen Bootloader drauf, der aber der falsche ist. Der ATMEGA ist NICHT von Locutus, sondern von Ebay!Zitat von: pc1246 am 24 November 2016, 16:48:18
-Warum machst du es nicht so wie dort https://forum.fhem.de/index.php/topic,55705.msg473015.html#msg473015 beschrieben?
Meinst du damit?
"curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@miniCUL_868MHZ.hex; filename=addon.hex" http://192.168.78.20/ota/addon.hex"Ich gehe davon aus, das o.g. Beispiel zum flashen der CUL-FIRMWARE ist und nicht des BOOTLOADERS eines ATMELS.
Ich bin leider Laie in Sachen Elektonik, sorry.
Gruss
Alex
Zitat von: bitbiter am 24 November 2016, 17:40:26
Mein ATMEGA328-PU hat aber schon einen Bootloader drauf, der aber der falsche ist.
Und was für einer ist da aktuell drauf?
Zitat von: bitbiter am 24 November 2016, 17:40:26
"curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@miniCUL_868MHZ.hex; filename=addon.hex" http://192.168.78.20/ota/addon.hex"
Ich gehe davon aus, das o.g. Beispiel zum flashen der CUL-FIRMWARE ist und nicht des BOOTLOADERS eines ATMELS.
Korrekt. curl kann keine bootloader aufspielen.
Zitat von: bitbiter am 24 November 2016, 17:40:26
Ich bin leider Laie in Sachen Elektonik, sorry.
Dann solltest Du mal über so etwas nachdenken: http://www.ebay.de/itm/8-Bit-Atmega328P-PU-DIP28-Atmel-Microcontroller-mit-UNO-Bootloader-fuer-Arduino-/221804691346?_trksid=p2141725.m3641.l6368
(ohne auf Preis oder sonst was zu achten als Beispiel)
Hallo HCS....
Zitat von: HCS am 24 November 2016, 20:51:18
Und was für einer ist da aktuell drauf?
UNO BOOTLOADER. Das sind die: https://www.amazon.de/gp/product/B00OYG1RM6/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1
Und laut Locutus haben die leider den falschen Bootloader. Das hat er mir auch bestätigt.
Zitat von: HCS am 24 November 2016, 20:51:18
Korrekt. curl kann keine bootloader aufspielen.
Ich wusste es nicht, aber ich dachte es mir schon.
Zitat von: HCS am 24 November 2016, 20:51:18
Dann solltest Du mal über so etwas nachdenken: http://www.ebay.de/itm/8-Bit-Atmega328P-PU-DIP28-Atmel-Microcontroller-mit-UNO-Bootloader-fuer-Arduino-/221804691346?_trksid=p2141725.m3641.l6368
(ohne auf Preis oder sonst was zu achten als Beispiel)
UNO Bootloader! Passt auch nicht.
Gruss
Alex
Zitat von: bitbiter am 24 November 2016, 21:21:17
Und laut Locutus haben die leider den falschen Bootloader. Das hat er mir auch bestätigt. Ich wusste es nicht, aber ich dachte es mir schon.UNO Bootloader! Passt auch nicht.
Das funktioniert bei mir auch mit dem UNO-Bootloader. Warum soll das nicht gehen? (außer der B-Command Thematik, mit der ich auch noch nie ein Problem hatte)
Hi HCS
Zitat von: HCS am 24 November 2016, 21:47:24
Das funktioniert bei mir auch mit dem UNO-Bootloader. Warum soll das nicht gehen? (außer der B-Command Thematik, mit der ich auch noch nie ein Problem hatte)
Nun denn, dann teste ich es mal mit dem UNO Bootloader. Wenn dann der Anschluss an das Netzteil keine Rauchschwaden aus dem Carrier-Board auslöst, habe ich vermutlich richtig gelötet. ;)
Danke und Gruss
Alex
Zitat von: bitbiter am 24 November 2016, 17:40:26
Ich gehe davon aus, das o.g. Beispiel zum flashen der CUL-FIRMWARE ist und nicht des BOOTLOADERS eines ATMELS.
Hallo Alex
Das war mir so auch nicht klar, Danke, und sorry fuer die Frage!
Gruss und viel Erfolg, Christoph
Hi pc1246...
Zitat von: pc1246 am 25 November 2016, 07:03:15
Das war mir so auch nicht klar, Danke, und sorry fuer die Frage!
Null Problemo
Zitat von: pc1246 am 25 November 2016, 07:03:15
Gruss und viel Erfolg, Christoph
Thx!
Gruss
Alex
Nachdem nun das Outdoor-PCB mich immer wieder hängen lässt habe ich mal ein Breadboard nach draußen gebracht - hier also der aktuelle Gehäuse Vorschlag ;)
Beste!!! ;D ;D
Abend alle.
ich rede nicht lange um den heißen Brei herum und frag einfach.
Besteht die Möglichkeit an das LaCrosseGateway einen DS18b20 anzuschließen?
um dann die Daten an FHEM zu übermitteln ?
Wahrscheinlich ja, würde nur ungern einen Arduino an die zusätzliche Serielle Schnittstelle hängen.
Direkt wie ein DHT wäre cool oder auch mehrere.
Gruß
Zitat von: seer am 29 November 2016, 20:23:34Besteht die Möglichkeit an das LaCrosseGateway einen DS18b20 anzuschließen?
Nein, geht nicht.
Wie kompliziert wäre es, das Intertechno-Protokoll zu implementieren?
Würde es in der Übertragung FHEM<->Gateway überhaupt funktionieren oder müsste man die Schnittstelle auch noch erweitern?
Zitat von: shaddi am 02 Dezember 2016, 19:13:17
Wie kompliziert wäre es, das Intertechno-Protokoll zu implementieren?
Meinst Du die "Baumarkt-Steckdosen"?
Zitat von: shaddi am 02 Dezember 2016, 19:13:17
Würde es in der Übertragung FHEM<->Gateway überhaupt funktionieren oder müsste man die Schnittstelle auch noch erweitern?
Müsste man erweitern.
Hallo HCS,
ich habe einen WLAN Lacrosse GW und du meintest, das man das Plugin verwenden sollte:
define jeelinkcross LaCrosseGateway 192.168.178.70:81
anstatt
define jeelinkcross JeeLink 192.168.178.70:81
Das lief bis zum 04.12 auch tacco mit folgender Config (2 RFM69w, oled, bmp180)
#define jeelinkcross JeeLink 192.168.178.70:81
define jeelinkcross LaCrosseGateway 192.168.178.70:81
attr jeelinkcross devStateIcon initialized:cul@green .*:cul@red
attr jeelinkcross group Transceiver
attr jeelinkcross icon cul
attr jeelinkcross initCommands 1,868950,120i 3#2m 20#2t 55h 0a v
attr jeelinkcross room System
attr jeelinkcross timeout 120,30
attr jeelinkcross verbose 1
Jetzt wird in dieser Konstellation nix mehr zum Fhem übertragen, die Daten von den Lacrosse werden jedoch
einwandfrei empfangen
09:08:53:
09:08:53: OK 9 40 1 4 201 106 [9A 06 25 6A BC]
09:08:53:
09:08:53: OK 9 63 1 4 204 33 [9F C6 28 21 99]
09:08:53:
09:08:53: OK WS 209 4 5 55 255 255 255 255 255 255 255 255 255 0 4 7
(version 1.22)
wenn ich jedoch die "das alte Plugin" wieder nehme, klappt die Übertragung zu fhem
define jeelinkcross JeeLink 192.168.178.70:81
RAWMSG
OK 9 20 1 4 196 38
STATE
initialized
TYPE
JeeLink
initMessages
jeelinkcross_MSGCNT
14
jeelinkcross_TIME
2016-12-06 09:25:38
model
[LaCrosseITPlusReader.Gateway.1.22 (1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 t:20~3) + BMP180 + OLED {IP=192.168.178.70}]
wurde irgendwas geändert? PCA301 schalten klappt bei beiden versionen.
LG
/robin
Zitat von: fh168 am 06 Dezember 2016, 09:12:26
wurde irgendwas geändert?
Nein, seit dem 26.09.2016 wurde an 36_LaCrosseGateway.pm nichts mehr geändert (siehe Anhang)
Bei mir funktioniert das auch stand heute noch problemlos (siehe temperatures.png).
seltsam, dann bleib ich erst mal beim Jeelink modul.
Hmm, das kam anscheinend mit dem letzten CUL update vom 4.12.
Ist bei mir genau so.
Ich kann kein Reconnect auf den CUL ausführen.
Zitat von: SusisStrolch am 06 Dezember 2016, 11:13:51
Hmm, das kam anscheinend mit dem letzten CUL update vom 4.12.
Ist bei mir genau so.
Ich kann kein Reconnect auf den CUL ausführen.
CUL ist aber ein anderes Thema. Meinst Du damit "set culXXX reopen" ?
Und was für ein CUL update?
00_CUL.pm oder CUL-Firmware?
ZitatCUL ist aber ein anderes Thema. Meinst Du damit "set culXXX reopen" ?
Genau diesen - der funktioniert seit dem 4.12. nicht mehr. Ist mir eben erst aufgefallen, als ich fh168's Mitteilung gelesen habe.
Zitat00_CUL.pm oder CUL-Firmware?
Die FHEM-Module - nicht die CUL-Firmware.
Muss mal im Log nachschauen welche genau das waren...
Zitat von: SusisStrolch am 06 Dezember 2016, 12:06:10
Genau diesen - der funktioniert seit dem 4.12. nicht mehr. Ist mir eben erst aufgefallen, als ich fh168's Mitteilung gelesen habe.Die FHEM-Module - nicht die CUL-Firmware.
Hmm, auch das funtioniert mit der auf heutigen Stand upgedateten FHEM-Version
set cul211 reopen
funktioniert bei mir.
Da darf man sich aber nicht verwirren lassen: wenn es beim ersten Mal nicht funktioniert hat, weil z.B. das LGW noch nicht da war, dann wartet DevIo, bis
NEXT_OPEN 1481026830
erreicht ist (ich glaube nach 60 Sekunden), und erst dann wird es wieder probiert.
Nun, bei mir hatte er seit 4.12. gewartet.
Der heutige Update hat anscheinend Abhilfe geschaffen - lööpt wieder...
Hallo HCS,
Zitat von: HCS am 30 Oktober 2016, 10:44:57
Connectverhalten auf einen AP
Das ganze kommt aus dem Stromausfall-Thema, bei dem das LGW viel schneller als der AP bereit ist und bereits aufgibt, bevor der AP nach ein bis zwei Minuten bereit ist, einen Connect anzunehmen.
Man kann nun auf der Setup-Page für beide SSIDs einen Timeout konfigurieren.
120 bedeutet z.B. dass das LGW 120 Sekunden lang versucht, die SSID zu erreichen.
Diese Zeit war bisher hart in der Firmware auf 15 Sekunden festgelegt.
Dafür kann man dann das Startup-delay wieder auf 0 stellen.
somit ist damit das Startup-delay obsoloet, es sei denn, man möchte vor dem Suchen noch etwas Zeitverzögerung einbauen?
Ich habe gestern das Firmware Update für den Co-Prozessor getestet, ich muss sagen, das gefällt mir saugut. Geht sogar unter Windows ;D Ich muss doch mal schauen, dass die Erweiterungsplatine vorankommt ...
Gruß PeMue
Zitat von: PeMue am 19 Dezember 2016, 09:38:55
somit ist damit das Startup-delay obsoloet, es sei denn, man möchte vor dem Suchen noch etwas Zeitverzögerung einbauen?
Genau so ist das. Das Startup-delay habe ich nicht mühevoll wieder ausgebaut, für den Fall, dass man es doch noch in irgend einem use case gebrauchen kann.
Die aktuell sinvolle Variante ist aber, es auf 0 zu setzen und die timeouts bei den SSIDs zu verwenden.
Zitat von: PeMue am 19 Dezember 2016, 09:38:55
Ich muss doch mal schauen, dass die Erweiterungsplatine vorankommt ...
Was Du berücksichtigen kannst:
Analog-Daten funktioniert, habe ich jetzt schon eine ganze Weile im Testbetrieb laufen.
Die soft-serial-bridge (anstatt Radio 2 und 3) funktioniert auch (mehr als 57600 Baud gehen da aber nicht) und ein angeschlossenes Nextion Display arbeitet mit dem 42_Nextion Modul zusammen. Zusätzlich zu dem, was über die bridge kommt, versorgt das LGW (falls konfiguriert) das Nextion-Display mit seinen eigenen Daten (RSSI, Temperature, Humidity, Pressure, ...).
Man kann die Firmware (also das .hmi File) auf die gleiche Methode wie beim add on cpu firmware update auf das Nextion hochladen (also curl ....) und ich werde in das 36_LaCrosseGateway Modul noch einen "set myLGW nextionUpload" einbauen.
Ist noch etwas Feintuning erforderlich, aber generell läuft es.
Ich mache demnächst einen Thread auf, wo ich mehr zu diesem Thema erläutere.
Zitat von: HCS am 26 Januar 2016, 09:53:31
OK. Die auf dem devkit steuere ich an oder lasse sie bei 0a dunkel.
Mit der auf dem ESP8266 habe ich nichts zu tun.
Ich habe mich aber auch schon gefragt, wann die leuchtet und was sie eigentlich signalisiert.
Allerding hab ich mich bisher nur gefragt und mir noch nicht drauf geantwortet ... ;D ;D
Wer Lust hat kann ja mal ein Forschungsprojekt starten, was die Bedeutung dieser LED auf dem ESP-12E ist.
Nachdem die Firmware v1.23 die LED auf dem ESP Modul immer angeschaltet läßt, habe ich mal Google bemüht:
http://www.esp8266.com/viewtopic.php?f=8&t=4205
Die Frage zur Verbesserung des WAF's war:
ZitatKann man im Arbeitszimmer die blauen Lichter abschalten?
(Ich habe einen LGW und einen nanoLGW im Betrieb).
Jetzt mal die Frage: Wie ist das bei Euch? Würde das per Software gehen, oder muss ich mit dem schwarzen Stift ran?
Schöne Weihnachten.
Danke + Gruß Peter
Zitat von: PeMue am 24 Dezember 2016, 14:40:08
Würde das per Software gehen, oder muss ich mit dem schwarzen Stift ran?
Dazu müsste ich die Serielle komplett abschalten, nur dann.
Ich könnte eine Option auf der Setup-Page einbauen, dass nach dem booten die Serielle abgeschaltet und GPIO2 HIGH gelegt wird.
Wenn man den USR-TCP232 drauf hat, ist das aber keine Option.Nachtrag: Unsinn, siehe nächster Beitrag.
Notfalls runterlöten.
Zitat von: HCS am 24 Dezember 2016, 16:30:13
Dazu müsste ich die Serielle komplett abschalten, nur dann.
Ich könnte eine Option auf der Setup-Page einbauen, dass nach dem booten die Serielle abgeschaltet und GPIO2 HIGH gelegt wird.
Wenn man den USR-TCP232 drauf hat, ist das aber keine Option.
Absoluter Unsinn, hatte wohl zu viel Weihnachtspunsch intus ;D ;D
GPIO2 ist der Chipselect von Radio #2.
Wenn kein Radio #2 angeschlossen ist, dann ist sie dunkel.
Wenn Radio #2 angeschlossen ist, dann leuchtet sie immer dann, wenn der RFM69 abgefragt wird, weil dann sein CS auf LOW gezogen wird, was in der main loop so oft passiert, dass es für das menschliche Auge nach dauerleuchten aussieht.
Ich glaube, da ist nichts zu machen.
Hallo HCS,
Ich bin mir relativ sicher, dass mit Versionen < 1.23 die LED nicht dauerhaft geleuchtet hat. Ich habe auch nur ein Radio verbunden. Kann es sein, dass durch die Unterstützung vom SHT75 in der 1.23 sich daran etwas geändert hat?
Frohe Weihnachten noch!
Nico
Zitat von: Wallmeier am 25 Dezember 2016, 10:21:15
Kann es sein, dass durch die Unterstützung vom SHT75 in der 1.23 sich daran etwas geändert hat?
Super Gedanke. Ja, gerade überprüft, so ist das tatsächlich.
Wenn man kein Radio #2 und keinen SHT75 hat, dann hinterlässt die Prüfung, was angeschlossen ist, den GPIO2 auf LOW, was die LED leuchten lässt.
Habe es geändert.
Wenn man aber ein Radio #2 dran hat, dann "sieht" man den Chip-Selecet-Verkehr, das lässt sich nicht ändern.
Ich denke (ohne Gewähr), dass ich noch dieses Jahr die 1.24 machen kann, die das und den Analogport und die Anbindung vom Nextion-Display drin hat.
V1.24
LED auf dem ESP-12E
Wenn man kein Radio #2 und keinen SHT75 hat, dann bleibt die LED jetzt wieder dunkel.
FHEM-Reconnect / alive
Der Reconnect vom LaCrosseGateway device in FHEM kann nun zwei Modi:
Den bisherigen, wenn man im Timeout-Attribut zwei Werte mit Komma getrennt angibt.
Einen neuen Mode, bei dem nicht mehr reading-timestamp geprüft wird, sondern im angegebenen Intervall das LGW gefragt wird, ob es noch lebt. Für den neuen Mode gibt man nur einen Wert an, z.B. 60 was bedeutet, dass alle 60 Sekunden beim LGW nachgefragt wird, ob es noch lebt. Falls die Antwort ausbleibt, wird versucht, die Verbindung zum LGW neu aufzubauen.
In dem neuen Attribut watchdog kann man optional eine Zeit in Sekunden angeben, die auf dem LGW einen watchdog aktiviert.
Der Watchdog prüft, ob er innerhalb der angegebenen Zeit vom LGW gefragt wurde und falls nicht, löst er einen Reboot auf dem LGW aus. Das Watchdog Intervall muss deutlich länger sein, als der Wert in Timeout. Logisch.
Hier bieten sich dann eher 5 Minuten (also watchdog 300) an.
Für den neuen Mode ist zwingend LGW Firmware 1.24 erforderlich, mit den älteren Versionen antwortet das LGW auf die "Alive-Anfrage" nicht und man hat ständig reconnects.
Analog-Port
Der Analogport A0 des ESP8266 wird nun als Reading im LaCrosseGatewayModul aufgeführt.
Um das zu aktivieren, muss man auf der Setup-page des LGW die Option "Send analog values"
ankreuzen. Siehe Analog1.png
Der Eingangsspannungsbereich von A0 ist 0V ... 1.0V, was zu einem Reading von 0 ... 1023 führt.
0=0V ... 1023=1V
In Analog2.png sieht man ein Beispiel, in dem ich einen TMP36 an A0 angeschlossen habe und in einem
userReading daraus ein Reading mit der Temperatur erzeuge.
Soft-Serial-Data-Port f. Nextion Display
Man kann nun anstatt Radio #2 und #3 eine weitere Serial-Bridge konfigurieren und daran ein Nextion Display anschließen.
Für weitere Informationen siehe den neuen Thread "LaCrosseGateway mit Nextion Display"
https://forum.fhem.de/index.php/topic,63443.0.html
Zitat von: HCS am 26 Dezember 2016, 23:28:12
LED auf dem ESP-12E
Wenn man kein Radio #2 und keinen SHT75 hat, dann bleibt die LED jetzt wieder dunkel.
Super, vielen Dank. Das Arbeitszimmer ist Nachts wieder nahezu dunkel, WAF wird ins Unermessliche steigen ...
Gruß PeMue
Zitat von: PeMue am 27 Dezember 2016, 09:44:56
Das Arbeitszimmer ist Nachts wieder nahezu dunkel
Wenn man ein Nextion dran hat, ist die LED auch dunkel und blinkt immer nur dann kurz auf, wenn das Nextion Daten an das LGW sendet.
Vielen Dank auch von mir – super!
Habe auch gleich eine Aktualisierung durchgeführt, verstehe aber leider nicht alles...
Zitat
In dem neuen Attribut watchdog ...
Ich habe kein solches Attribut (Update und shutdown restart habe ich zuvor durchgeführt).
Gebe ich im Attribut timeout nur einen Wert ein (so wie auch auf deiner Hardcopy zu sehen), kommt bei mir folgende Fehlermeldung:
Usage: attr LaCrosseGateway timeout <timeout,checkInterval>
Irgendwo klemmt es leider noch.
LG
Holger
Zitat von: Omega am 27 Dezember 2016, 10:47:14
Irgendwo klemmt es leider noch.
Ich würde mal drauf tippen, dass Du (warum auch immer) noch die alte Version hast.
Siehe Anhang.
Update habe ich zuvor durchgeführt. Meine Version (1. Zeile aus 36_LaCrosseGateway.pm):
# $Id: 36_LaCrosseGateway.pm 12881 2016-12-26 22:20:36Z HCS $
Sollte doch eigentlich passen. Shutdown restart habe ich mittlerweile sogar 2 x durchgeführt - dass kann es also auch nicht sein.
Zitat von: Omega am 27 Dezember 2016, 11:50:35
Update habe ich zuvor durchgeführt. Meine Version (1. Zeile aus 36_LaCrosseGateway.pm):
# $Id: 36_LaCrosseGateway.pm 12881 2016-12-26 22:20:36Z HCS $
Passt.
Was steht in Zeile 39?
Noch ein Hinweis zu der neuen Timeout-Variante: dafür ist zwingend LGW Firmware 1.24 erforderlich, mit den älteren Versionen antwortet das LGW auf die "Alive-Anfrage" nicht und man hat ständig reconnects.
Aber auf das Vorhandensein der Attribute hat das keinen Einfluss.
watchdog --> passt also auch.
Auch ein
reload 36_LaCrosseGateway.pm bringt das Attribut nicht zum Vorschein.
Firmwareupdate hat aber funktioniert. Das LGW meldet sich mit 1.24
Nachtrag:
Ich habe 2 FHEM-Instanzen. Auf beiden habe ich das gleiche Verhalten.
Zitat von: Omega am 27 Dezember 2016, 12:08:02
Firmwareupdate hat aber funktioniert. Das LGW meldet sich mit 1.24
OK.
Bin etwas ratlos, was bei Dir los ist.
Ich habe meine Produktivsysteme heute Morgen upgedatet (mit denen verhalte ich mich zum Test immer wie ein "normaler Anwender", warte also auf das FHEM Update) und bei beiden funktioniert das.
Ich glaube, da brauchen wir professionelle Hilfe ;D ;D
Hast Du einen set nextionUpload im LaCrosseGateway device?
Nein, den habe ich auch nicht.
Hätte ich beim Update heute eigentlich auch eine Datei "nextion.tft" erhalten sollen?
In meinem Verzeichnis habe ich auch noch eine 36_LaCrosse.pm. Wurde die ersetzt durch 36_LaCrosseGateway.pm oder wird die noch benötigt?
Zitat von: Omega am 27 Dezember 2016, 12:25:01
Nein, den habe ich auch nicht.
Das sieh alles so aus, als ob bei Dir noch die vorhergehende Version läuft.
Leg mal testweise ein weiteres LaCrosseGateway device an:
define lgwDummy LaCrosseGateway 192.168.31.99:85und schaue, ob das die neue Version ist.
Zitat von: Omega am 27 Dezember 2016, 12:25:01
Hätte ich beim Update heute eigentlich auch eine Datei "nextion.tft" erhalten sollen?
Nein. Die muss jeder selbst basteln und dort hin werfen, oder mit dem Attribut tftFile festlegen, wo sie ist.
Zitat von: Omega am 27 Dezember 2016, 12:25:01
In meinem Verzeichnis habe ich auch noch eine 36_LaCrosse.pm. Wurde die ersetzt durch 36_LaCrosseGateway.pm oder wird die noch benötigt?
36_LaCrosseGateway.pm ist das iodev für das LGW
36_LaCrosse.pm ist das device, das einen Sensor darstellt.
Man braucht beide.
define lgwDummy LaCrosseGateway 192.168.31.99:85
ist die neue Version.
Ich scheue im Moment ein bisschen davor, mein LGW einfach zu löschen und wieder neu zu definieren. Es hängt ja auch noch das KeyValueProtocol mit dran - dafür habe ich seinerzeit auch extra Einstellungen definiert.
Verwunderlich finde ich auch, dass das Verhalten in beiden FHEM-Instanzen identisch ist (eine läuft auf einem CT, die andere in einer VM).
Vom Verständnis her: Attribute, die in der SW definiert sind, müssten doch zur Anzeige/Auswahl kommen.
Dein LGW device ist aber nicht noch ein JeeLink device?
Zeig mal einen List von einem der devices.
Device oder Gateway?
Habe vorsichtshalber mal beide genommen...
Das Gateway
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 84
LaCrosseGateway_MSGCNT 727
LaCrosseGateway_TIME 2016-12-27 13:22:21
NAME LaCrosseGateway
NR 677
PARTIAL
RAWMSG OK 9 15 1 4 51 80
STATE initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.Gateway.1.24 (1=RFM69 f:868295 t:20~3) + (2=RFM69 f:868300 r:8842) + (3=RFM69 f:868950 r:6631) + BME280 + OLED {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-12-27 13:22:21 state initialized
Attributes:
devStateIcon initialized:cul@green .*:cul@red
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,868950,120i 96h 0a v
room LaCrosse
timeout 120,60
und ein Device
Internals:
CHANGED
DEF 23
IODev LaCrosseGateway
LASTInputDev myJeeLink
LaCrosseGateway_MSGCNT 96
LaCrosseGateway_RAWMSG OK 9 35 1 4 170 106
LaCrosseGateway_TIME 2016-12-27 13:24:27
LaCrosse_lastRcv 2016-12-27 13:24:44
MSGCNT 130
NAME LaCrosse_23
NR 684
STATE T_innen: 19.4 T_extern: 19.4
TYPE LaCrosse
addr 23
battery_new 0
corr1 0
corr2 0
myJeeLink_MSGCNT 69
myJeeLink_RAWMSG OK 9 35 1 4 170 106
myJeeLink_TIME 2016-12-27 13:24:44
previousH 106
previousH2 125
previousT 19.4
previousT2 19.4
sensorType 0=T(H)
Readings:
2015-11-23 16:24:43 H 0
2015-11-23 16:28:42 T 0
2016-12-27 13:24:44 battery ok
2015-11-23 16:24:43 humidity 0
2016-12-02 12:24:10 lastBatChange Fri Dec 2 12:24:10 2016
2016-10-25 20:15:53 rain 1178
2016-12-27 13:24:44 state T: 19.4
2016-12-27 13:24:44 temperature 19.4
2016-12-27 13:24:40 temperature2 19.4
2016-10-25 20:15:53 windGust 13.3
Attributes:
IODev LaCrosseGateway
alias Flur
event-min-interval batt.*:86400,T.*:900
event-on-change-reading .*
room LaCrosse
stateFormat T_innen: temperature T_extern: temperature2
Zitat von: Omega am 27 Dezember 2016, 13:26:25
TYPE JeeLink
Dachte ich es mir doch.
Das ist ein JeeLink device und kein LaCrosseGateway device.
Wenn Du die Vorzüge eines LaCrosseGateway device haben willst, muss Du auch ein solches definieren.
Sollte man aber von JeeLink zu LaCrosseGateway umbauen können, indem man es in der fhem.cfg umschreibt, dann muss man es nicht neu definieren.
;D
Das war es!
Direktes editieren der fhem.cfg hat dann ausgereicht, um endlich in den Genuss der neuen Attribute zu kommen.
Danke noch mal für deine Geduld.
LG
Holger
Hallo HCS,
ich habe mal eine (blöde) Frage - besteht die Möglichkeit in der Firmware noch eine weitere Serial Port Bridge einzubauen, die die UART-Schnittstelle des ESP selber nutzt? Ich habe am SC16IS750 bereits einen MiniCUL dran hängen und würde gerne noch HM-MOD-RPI-PCB anschließen, der wenn ich es richtig gesehen habe aber mit 115200 Baud betrieben wird und somit nicht an der Soft Serial laufen wird...
Gruß,
Nico
Mal ne kurze frage.
Anstatt ein nodemcu zu benutzen, würde da auch ein wemos d1 bzw d1 Mini funktionieren, oder muss das sketch dafür geändert werden?
Gruß Sascha
Von mobil gesendet daher kurze Antwort
Zitat von: Wallmeier am 29 Dezember 2016, 09:35:35
ich habe mal eine (blöde) Frage - besteht die Möglichkeit in der Firmware noch eine weitere Serial Port Bridge einzubauen, die die UART-Schnittstelle des ESP selber nutzt?
Eher nicht. Zumindest auf allen Boards wie NodeMCU, ... ist da schon der USB-Serial-Wandler (auf dem Board hart verdrahtet) angeschlossen und zwei serielle Schnittstellen stumpf parallel funktioniert nicht.
Zitat von: Wallmeier am 29 Dezember 2016, 09:35:35
Ich habe am SC16IS750 bereits einen MiniCUL dran hängen und würde gerne noch HM-MOD-RPI-PCB anschließen, der wenn ich es richtig gesehen habe aber mit 115200 Baud betrieben wird und somit nicht an der Soft Serial laufen wird...
.
Plan A: den HM-MOD-RPI-PCB an den SC16IS750 dran und den MiniCUL mit 38400 an die soft serial dran (nicht getestet)
Plan B: Auf die LGW-Version warten, die auf dem ESP32 läuft. Die wird (ohne SC16IS750) zwei Hardware-Serials haben.
Zitat von: sash.sc am 29 Dezember 2016, 13:30:00
Mal ne kurze frage.
Anstatt ein nodemcu zu benutzen, würde da auch ein wemos d1 bzw d1 Mini funktionieren, oder muss das sketch dafür geändert werden?
https://wiki.fhem.de/wiki/LaCrosseGateway#Bauteile
Bedeutet: ja
Habe es aber nie damit getestet, da ich keinen habe.
Zitat von: HCS am 29 Dezember 2016, 16:03:39
https://wiki.fhem.de/wiki/LaCrosseGateway#Bauteile
Bedeutet: ja
Für welchen Frageteil gilt denn das ja ;)? Ich meine, für den ersten ;)
Zitat von: PeMue am 29 Dezember 2016, 16:57:35
Für welchen Frageteil gilt denn das ja ;)? Ich meine, für den ersten ;)
Ja ;)
Frage: "Anstatt ein nodemcu zu benutzen, würde da auch ein wemos d1 bzw d1 Mini funktionieren?"
Antwort: Ja
Frage: "oder muss das sketch dafür geändert werden?"
Antwort: Nein
Frage: "Hat HCS den wemos mal getestet?"
Antwort: Nein
Frage: "Passt er auf die PeMue-Platine?"
Antwort: Nein
Frage: "Noch Fragen offen geblieben?"
Antwort: Nein
Hallo zusammen,
zu Weihnachten habe ich 2 PCA301 Steckdosen bekommen, die ich nun versucht habe einzubinden.
Ich habe einen nodemcu + RFM69, der bisher dazu dienste meine Wetterstation (WS1600) in FHEM zu integrieren. Da ich damit aber mit den battarien sowieso immer Stress habe und ich ja jetzt - sofern ich das richtig verstanden habe - einen weiteren RFM6ß bräuchte um beides zu empfangen, wollte ich nun erst einmal die Steckdosen einbinden.
Dazu habe ich das Attribut initCommands angepasst:
attr myJeeLink initCommands 1,868950,120i
Anschließend Pairing Modus gestartet und auf der Steckdose 3 Sekunden den Button gedrückt.
Leider passiert nichts.
Hat jemand noch einen Tipp für mich?
Danke & Gruß,
Tobias
Zitat von: onkel-tobi am 31 Dezember 2016, 11:21:22
Hat jemand noch einen Tipp für mich?
Meinst Du mit "Pairing Modus" LaCrossePairForSec? Das ist nicht erforderlich.
Das alleinige Ändern der initCommands bewirkt noch nichts. Geh mal auf das Webfrontend vom LGW und löse dort einen Reboot aus.
Wenn sich FHEM danach wieder verbunden hat, dann 3 Sekunden an der PCA drücken.
Falls es dann immer noch nicht geht, brauche ich mal einen List vom LaCrosseGateway-device.
Ist auf der Setup-page bei "Plugs" etwas eingetragen?
Hm, leider keine Veränderung. Durchgestartet hatte ich auch schon. Unter Plugins nichts eingetragen.
Hier das list:
Internals:
CFGFN FHEM/wetter.cfg
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF 192.168.178.81:81
DeviceName 192.168.178.81:81
FD 13
NAME myJeeLink
NR 156
PARTIAL
RAWMSG OK VALUES LGW 1302972 UpTimeSeconds=340,UpTimeText=0Tg. 0Std. 5Min. 40Sek. ,WIFI=blablubb,ReceivedFrames=7,FramesPerMinute=2,RSSI=-59,FreeHeap=15696,LD.Min=0,LD.Avg=0,LD.Max=17
STATE initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.Gateway.1.18 (1=RFM69 f:868300 r:17241) {IP=192.168.178.81}]
myJeeLink_MSGCNT 17
myJeeLink_TIME 2016-12-31 12:56:17
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-12-31 12:56:17 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 1,868950,120i
Gesendet von iPhone mit Tapatalk
Zitat von: onkel-tobi am 31 Dezember 2016, 13:04:12
model [LaCrosseITPlusReader.Gateway.1.18 (1=RFM69 f:868300 r:17241) {IP=192.168.178.81}]
Das LGW wurde nicht auf PCA301 initialisiert. Das läuft auf 17241 für LaCrosse.
Das sollte so aussehen:
model [LaCrosseITPlusReader.Gateway.1.18 (1=RFM69
f:868950 r:6631) {IP=192.168.178.81}]
Und LaCrosseITPlusReader V1.18 ist schon recht veraltet. Dein FHEM auch?
Oder wurde es nur nicht zurückgemeldet?
Häng mal ein v an die initCommands an:
initCommands 1,868950,120i vUnd dann nochmal LGW reboot.
Eventuell mal die Frequenz ändern, bei mit läuft es nur mit 868960 vernünftig.
Ansonsten auch mal hier lesen: https://wiki.fhem.de/wiki/LaCrosseGateway#Inbetriebnahme_von_PCA301
Generell: nach dem Ändern der initCommands einen Reset am LGW machen und dann warten, bis das LGW sich wieder verbunden hat.
Das macht es bei Dir aber nicht, da Du das timeout Attribut nicht gesetzt hast.
Also -> setzen, z.B. 120,30
Auch hier im Wiki zu lesen: https://wiki.fhem.de/wiki/LaCrosseGateway#Reconnect
Wenn das alles erledigt ist, das LGW mal stromlos machen, dass es wirklich kalt bootet und nicht noch irgend welche Konfigurations-Altlasten im Speicher dümpeln.
Hallo HCS,
Zitat von: HCS am 29 Dezember 2016, 15:56:54
Eher nicht. Zumindest auf allen Boards wie NodeMCU, ... ist da schon der USB-Serial-Wandler (auf dem Board hart verdrahtet) angeschlossen und zwei serielle Schnittstellen stumpf parallel funktioniert nicht.
Mist - das hatte ich übersehen :)
Zitat von: HCS am 29 Dezember 2016, 15:56:54
Plan A: den HM-MOD-RPI-PCB an den SC16IS750 dran und den MiniCUL mit 38400 an die soft serial dran (nicht getestet)
Plan B: Auf die LGW-Version warten, die auf dem ESP32 läuft. Die wird (ohne SC16IS750) zwei Hardware-Serials haben.
Da der MiniCUL auf dem CarrierBoard von Locutus sitzt und somit auf der Platine direkt mit SC16IS750 verbunden ist, scheidet Plan A leider aus...
Ich habe aber noch einen Plan C - einen weiteren SC16IS750 auf Adresse 0x92, der entweder für eine weitere Serial Bridge genutzt werden kann oder einen weiteren SubProcessor.
Anbei sind zwei Patches (gegen die Version 1.24):
- 2ndSerialBridge.patch: Fügt die Unterstützung für einen weiteren SC16IS750 hinzu (inkl. SerialBridge, SubProcessor und OTA-Update)
- SerialBridgeMultiClients.patch: baut auf dem ersten Patch auf und erlaubt beliebig viele Clients, die sich zu der SerialBridge verbinden können.
Wenn gewünscht, kann ich den zweiten Patch auch noch für die Soft Serial Bridge und den eigentlichen Daten-Port des LGW umsetzen...
Einen guten Rutsch ins neue Jahr,
Nico
Zitat von: Wallmeier am 31 Dezember 2016, 15:01:28
Ich habe aber noch einen Plan C - einen weiteren SC16IS750 auf Adresse 0x92, der entweder für eine weitere Serial Bridge genutzt werden kann oder einen weiteren SubProcessor.
OK, ich schaue mir Plan C mal an. Aber ich glaube, erst nächste Jahr ;D ;D
Hallo,
ich habe eine Frage zur korrekten Initialisierung bei folgendem Setup:
1x RFM69
1x BME280
1x OLED
Das Radio wird als #2 angezeigt, obwohl nur ein RFM69 für PCA301 angeschlossen ist.
Wie bekomme ich das auf die #1?
Das OLED soll die Temp/Hum/Pressure vom BME sowie die aktuelle Verbrauchszahl der PCA301 Dose auf einmal oder (wenn einfacher) nacheinander anzeigen.
Wie muss "initCommands" dafür aussehen?
List vom LGW:
Internals:
CHANGED
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF 192.168.84.40:81
DeviceName 192.168.84.40:81
FD 53
Klr.LGW_MSGCNT 213
Klr.LGW_TIME 2016-12-31 15:48:23
LaCrosseGW_MSGCNT 170
LaCrosseGW_TIME 2016-12-31 15:30:03
NAME Klr.LGW
NR 244
PARTIAL
RAWMSG OK WS 0 4 4 190 53 255 255 255 255 255 255 255 255 0 3 254
STATE initialized
TYPE LaCrosseGateway
model [LaCrosseITPlusReader.Gateway.1.24 + (2=RFM69 f:868300 r:9579) + BME280 + OLED {IP=192.168.84.40}]
.clientArray:
KeyValueProtocol
LaCrosse
PCA301
Helper:
Dblog:
Humidity:
Dblog:
TIME 1483195613.74736
VALUE 53
Temperature:
Dblog:
TIME 1483195693.8068
VALUE 21.4
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:
2016-12-31 15:48:23 humidity 53
2016-12-31 15:48:23 pressure 1022
2016-12-31 15:48:23 state initialized
2016-12-31 15:48:23 temperature 21.4
Attributes:
alias Keller LaCrosseGW
devStateIcon initialized:cul@green .*:cul@red
event-on-change-reading humidity,pressure,temperature
group 1_IODevs
icon cul_868
initCommands 1,868950,60i 92h 0a v
ownSensors readings
timeout 120,30
List der PCA301:
Internals:
DEF 06B953 01
IODev Klr.LGW
NAME Klr.Steckdose.Waschmaschine
NR 288
STATE 0.3
TYPE PCA301
addr 06B953
channel 01
.userReadings:
HASH(0x3f9a4b0)
Readings:
2016-12-24 14:06:39 consumption 1.14
2016-12-24 14:06:39 consumptionTotal 1.13
2016-12-26 18:14:34 power 0.3
2016-12-17 20:17:59 state on
Attributes:
IODev LaCrosseGW
alias Keller Waschmaschine
devStateIcon on:on:toggle off:off:toggle set.*:light_exclamation:off
event-on-change-reading power:1,consumption
group Strom
room Wohnung
stateFormat power
userReadings consumptionTotal:consumption.* monotonic {ReadingsVal($name,'consumption',0)}
webCmd on:off:toggle:statusRequest
Danke Euch & guten Rutsch!
Hi HCS,
danke für deine Antwort.
List ist nun:
Internals:
CFGFN FHEM/wetter.cfg
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF 192.168.178.81:81
DeviceName 192.168.178.81:81
FD 66
NAME myJeeLink
NR 156
PARTIAL
RAWMSG OK VALUES LGW 1302972 UpTimeSeconds=180,UpTimeText=0Tg. 0Std. 3Min. 0Sek. ,WIFI=TOSA24,ReceivedFrames=0,FramesPerMinute=0,RSSI=-63,FreeHeap=20208,LD.Min=0,LD.Avg=0,LD.Max=63
STATE initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.Gateway.1.18 (1=RFM69 f:868950 r:6631) {IP=192.168.178.81}]
myJeeLink_MSGCNT 18
myJeeLink_TIME 2016-12-31 16:26:52
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-12-31 16:26:52 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 1,868950,120i v
timeout 120,30
Sieht also eigtl. gut aus, oder?
Bekomme dann sogar folgendes:
16:24:38: Starting data port 1 on 81
16:24:38: Searching RFMs and Sensors
16:24:38: Radio #1 found: RFM69
16:24:38: Sending init String to FHEM
16:24:38: Setup completely done
16:25:38: DataPort: #81 Client connected, IP=192.168.178.88 Port=40722
16:25:41: DataPort: #81 received '1,868950,120i '
16:25:41: PCA301: Initialized with 868950 kHz and 120 seconds poll
16:25:41: DataPort: #81 received 'v '
Aber das entsprechende Gerät in FHEM kann ich nicht finden. Ein Update über set myJeeLink flash funktioniert auch nicht, da hängt sich FHEM auf (auch nach update auf aktuellste Version).
Gruß,
Tobi
Zitat von: HCS am 31 Dezember 2016, 15:11:57
OK, ich schaue mir Plan C mal an. Aber ich glaube, erst nächste Jahr ;D ;D
Na nun stell Dich mal nicht so an!
Ist ja noch so viel Zeit bis 23:59:59, und waehrend der zusaetzlichen Sekunde kannst Du ja die Korken knallen lassen!
;) ;) ;)
Gruss und guten Rutsch Christoph
Zitat von: onkel-tobi am 31 Dezember 2016, 16:30:45
List ist nun:
Internals:
...
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.Gateway.1.18 (1=RFM69 f:868950 r:6631) {IP=192.168.178.81}]
...
Sieht also eigtl. gut aus, oder?
Was mich stört ist der TYPE
JeeLink. Sollte das nicht TYPE
LaCrosseGateway sein? Außerdem ist V1.18 auch schon ein wenig älter.
Gruß Friedrich
Zitat von: Flexstarr am 31 Dezember 2016, 15:58:15
Das Radio wird als #2 angezeigt, obwohl nur ein RFM69 für PCA301 angeschlossen ist.
Wie bekomme ich das auf die #1?
Dann hast Du das Radio an GPIO2 angeschlossen. Wenn Du es an GPIO15 (D8) anschließt, wird es Radio #1
Zitat von: Flexstarr am 31 Dezember 2016, 15:58:15
Das OLED soll die Temp/Hum/Pressure vom BME sowie die aktuelle Verbrauchszahl der PCA301 Dose ... auf einmal anzeigen.
Das wird nicht gehen. Mit dem Nextion Display wäre das machbar. Siehe hier: https://forum.fhem.de/index.php?action=dlattach;topic=63443.0;attach=65245
Zitat von: Flexstarr am 31 Dezember 2016, 15:58:15
(wenn einfacher) nacheinander anzeigen.
Da musst Du Dir in FHEM etwas schreiben, das die Werte alle x Sekunden an das Display schickt.
So in der Art: set myLaCrosseGateway raw "OLED show=55%,,,h"
siehe https://wiki.fhem.de/wiki/LaCrosseGateway#Inbetriebnahme_von_OLED-Display
Zitat von: onkel-tobi am 31 Dezember 2016, 16:30:45
Aber das entsprechende Gerät in FHEM kann ich nicht finden.
Hast Du mal andere Frequenzen probiert? 868960 ist ein heißer Kandidat.
Zitat von: onkel-tobi am 31 Dezember 2016, 16:30:45
Ein Update über set myJeeLink flash funktioniert auch nicht, da hängt sich FHEM auf (auch nach update auf aktuellste Version).
Sicher? Das kann ein zwei Minuten dauern, bis die Firmware hochgeladen und verarbeitet ist, in denen sich in FHEM dann nichts mehr regt.
Danach kommt dann eine Zusammenfassung, was passiert sit.
Zitat von: Omega-5 am 01 Januar 2017, 13:32:12
Was mich stört ist der TYPE JeeLink. Sollte das nicht TYPE LaCrosseGateway sein?
Es muss nicht unbedingt, aber es bietet sich inzwischen an, für das LGW nicht das JeeLink device zu nehmen, sondern das LaCrosseGateway device, da das besser auf das LGW zugeschnitten ist.
Aber das ist sicher nicht sein PCA301-Problem.
Zitat von: pc1246 am 31 Dezember 2016, 17:26:27
Na nun stell Dich mal nicht so an!
Ist ja noch so viel Zeit bis 23:59:59
Ich habe ja bis 23:59:58 gebraucht, um den Patch zu patchen, dass ihn Tortoise verarbeitet :o
Zitat von: Wallmeier am 31 Dezember 2016, 15:01:28
2ndSerialBridge.patch: Fügt die Unterstützung für einen weiteren SC16IS750 hinzu (inkl. SerialBridge, SubProcessor und OTA-Update)
Habe ich in die 1.25 reingenommen und testweise mal einen weiteren NanoCUL drangehängt, läuft.
Das hast Du sauber eingebaut, gefällt mir sehr gut und ich habe nur ganz geringe kosmetische Anpassungen gemacht.
Zitat von: Wallmeier am 31 Dezember 2016, 15:01:28
SerialBridgeMultiClients.patch: baut auf dem ersten Patch auf und erlaubt beliebig viele Clients, die sich zu der SerialBridge verbinden können.
Schaue ich mir dann auch noch an.
Wenn ich beide drin habe, haue ich zeitnah eine 1.25 raus.
Zitat von: HCS am 01 Januar 2017, 22:39:02
Habe ich in die 1.25 reingenommen und testweise mal einen weiteren NanoCUL drangehängt, läuft.
Das hast Du sauber eingebaut, gefällt mir sehr gut und ich habe nur ganz geringe kosmetische Anpassungen gemacht.
Das freut mich zu hören :)
Zitat von: HCS am 01 Januar 2017, 22:39:02
Schaue ich mir dann auch noch an.
Wenn ich beide drin habe, haue ich zeitnah eine 1.25 raus.
Anbei noch ein weiterer Patch: SoftSerialBridgeMultiClients.patch . Dieser rüstet das Feature, dass sich mehrere Clients auf den Port verbinden können auch für die SoftSerialBridge nach. Das eigentliche TCP-Socket-Handling habe ich dafür in eine eigene Klasse TcpServer ausgelagert, die jetzt sowohl von der SerialBridge als auch der SoftSerialBridge genutzt werden.
Zitat von: Wallmeier am 01 Januar 2017, 23:15:44
Anbei noch ein weiterer Patch
Könntest Du die patches so erstellen, dass ich sie mit Tortoise verarbeiten kann?
Das würde es mir deutlich einfacher machen.
Betrifft dann aber nur noch den SoftSerialBridgeMultiClients.patch
Baut der auf dem SerialBridgeMultiClients.patch auf oder ersetzt der ihn komplett?
Die header der files anstatt so:
diff -Naur LaCrosseGateway_2ndSerialBridgeMultiClients/HardwarePageBuilder.cpp LaCrosseGateway/HardwarePageBuilder.cpp
--- LaCrosseGateway_2ndSerialBridgeMultiClients/HardwarePageBuilder.cpp Sat Dec 31 13:46:45 2016
+++ LaCrosseGateway/HardwarePageBuilder.cpp Sun Jan 1 22:08:44 2017
@@ -42,7 +42,7 @@
return result;
}
....
So:
--- HardwarePageBuilder.cpp
+++ HardwarePageBuilder.cpp
@@ -42,7 +42,7 @@
return result;
...
Zitat von: HCS am 01 Januar 2017, 23:40:27
Könntest Du die patches so erstellen, dass ich sie mit Tortoise verarbeiten kann?
Das würde es mir deutlich einfacher machen.
Klar doch - schaue ich mir heute Abend in Ruhe an, wie ich das diff Kommando aufrufen muss, damit es das Format liefert, so dass Tortoise direkt damit zurecht kommt.
Zitat von: HCS am 01 Januar 2017, 23:40:27
Betrifft dann aber nur noch den SoftSerialBridgeMultiClients.patch
Baut der auf dem SerialBridgeMultiClients.patch auf oder ersetzt der ihn komplett?
Aktuell baut der Patch SoftSerialBridgeMultiClients.patch auf den SerialBridgeMultiClients.patch auf. Wenn ich Dir den Patch eh heute Abend neu baue, kann ich ihn aber so bauen, dass er den SerialBridgeMultiClients.patch ersetzt. Wie ist es Dir lieber?
Zitat von: Wallmeier am 02 Januar 2017, 06:40:57
Aktuell baut der Patch SoftSerialBridgeMultiClients.patch auf den SerialBridgeMultiClients.patch auf. Wenn ich Dir den Patch eh heute Abend neu baue, kann ich ihn aber so bauen, dass er den SerialBridgeMultiClients.patch ersetzt. Wie ist es Dir lieber?
Dann wäre mir ersetzen lieber, weil ich dann nur einen durchkauen muss.
Passt das angehängte Format jetzt besser? Ich habe den Patch jetzt mittels tortoiseSVN erstellt... Oder benutzt Du tortoiseGIT?
Der angehängte Patch setzt auf den Patch 2ndSerialBridge.patch auf.
Zitat von: Wallmeier am 02 Januar 2017, 18:50:44
Passt das angehängte Format jetzt besser? Ich habe den Patch jetzt mittels tortoiseSVN erstellt... Oder benutzt Du tortoiseGIT?
Ich benutze tortoiseSVN. Jetzt geht der patch drauf, ohne dass ich ihn anpassen muss.
Build ist fehlerfrei und per OTA auf eins meiner Test-LGWs hochgeladen. Ohne jetzt viel getestet zu haben scheint es zu laufen.
Werde mal durchschauen, was Du gebaut hast und noch ein wenig testen.
Hast Du Lust, mir bei einem Problem zu helfen, mit dem ich schon seit Monaten kämpfe?
Auf der Setup-page passiert es immer mal wieder, dass die Combos für die MCP23008-Konfiguration nicht angezeigt werden.
Folgende Varianten (mit ein und der selben Firmware) treten auf (siehe auch Anhang):
- Funkktioniert
- Eine Zeile fehlt
- Beide Zeilen fehlen
Manchmal in Kombination mit wirren Zeichen ganz links oben auf der page.
Nach der aktuellen Erweiterung der setup-page habe ich das wieder massiv.
Ich hab mich da schon in's Koma geforscht ohne Ergebnis.
in
m_webserver.on("/setup", [this]() { wird ja das komplette html der setup-page gebildet.
Ich glaube, dass ich schon mal an dem Punkt war, dass der String schon bevor er in
m_webserver.send(200, "text/html", result); rein geht, kaputt ist und der WebServer somit nicht schuld ist.
Die etwas seltsame "GetMCPCombos und GetIOCombo - Konstruktion" ist auch ein Ergebnis der Problemsucherei.
Wenn es nicht spontan auftritt, einfach die setup-page einige mal reloaden.
Wenn man sich im browser den Seitenquelltext anschaut, dann fehlt der Teil einfach.
Kannst Du das bei Dir reproduzieren und hast Du irgend eine Idee, wo da das Problem liegt?
Das ich nur eine Zeile für den MCP23008 geliefert bekomme, habe ich bei mir auch - das war mir auch schon aufgefallen und dann habe ich beim meinem anderen Gateway mit der offiziellen 1.24 nachgesehen und dort war es auch. Wo ich es jetzt gerade nochmal wiederhole, bekomme ich beim Gateway mit der offiziellen 1.24 wieder beide Zeilen angezeigt...
Auf den ersten Blick sieht der Code vernünftig aus... Ich werde die Tage mal schauen, ob ich rausbekomme, woran es liegt...
Auf jeden Fall sehr komisch das Ganze...
Zitat von: HCS am 01 Januar 2017, 22:22:47
Hast Du mal andere Frequenzen probiert? 868960 ist ein heißer Kandidat.
Ja, habe alles aus dem Wiki ausprobiert.
Zitat
Sicher? Das kann ein zwei Minuten dauern, bis die Firmware hochgeladen und verarbeitet ist, in denen sich in FHEM dann nichts mehr regt.
Danach kommt dann eine Zusammenfassung, was passiert sit.
Nein. Als ich alles noch mal durchgestartet habe und das update via FHEM gestartet habe ging es dann doch, sorry...
Jetzt brauche ich erst mal einen neuen RFM69, da meine Frau doch wieder auf die Wetterstation bestanden hat ;)
Gruß & danke,
Tobi
Zitat von: Wallmeier am 02 Januar 2017, 22:26:34
Auf jeden Fall sehr komisch das Ganze...
Ja, mehr als komisch :o
Zitat von: Wallmeier am 02 Januar 2017, 22:26:34
Auf den ersten Blick sieht der Code vernünftig aus... Ich werde die Tage mal schauen, ob ich rausbekomme, woran es liegt...
Das wäre super. Ich habe ihn schon hundert mal gelesen und fünfzig mal umgeschrieben um dem Problem beizukommen.
Vermutlich bin ich in dem Code-Zweig schon betriebsblind ;D ;D
Zwischendurch habe ich mal auf einen Bug in der String-Klasse bei großen Strings getippt, aber das konnte ich auch nicht erhärten.
Das Blöde an der Sache ist, dass man seine MCP23008-Konfiguration verliert, wenn man in dem Zustand speichert.
Zitat von: onkel-tobi am 02 Januar 2017, 22:34:59
Jetzt brauche ich erst mal einen neuen RFM69, da meine Frau doch wieder auf die Wetterstation bestanden hat ;)
OK, dann melde Dich, wenn Du den zweiten RFM69 hast, dann schauen wir, ob wir rausfinden, was Dein Problem ist.
Zitat von: HCS am 02 Januar 2017, 22:40:16
Zwischendurch habe ich mal auf einen Bug in der String-Klasse bei großen Strings getippt, aber das konnte ich auch nicht erhärten.
Das Blöde an der Sache ist, dass man seine MCP23008-Konfiguration verliert, wenn man in dem Zustand speichert.
Die Sache hat mir keine Ruhe gelassen und ich habe ein wenig herum gespielt...
Ich habe einen kleinen Umbau gemacht:
// MCP23008
result += F("<tr><td> <label>MCP23008: </label> </td><td>");
// result += GetMCPCombos(&settings, 1);
result += GetIOCombo(0, settings.Get("IO0", "Input")) + " ";
result += GetIOCombo(1, settings.Get("IO1", "Input")) + " ";
result += GetIOCombo(2, settings.Get("IO2", "Input")) + " ";
result += GetIOCombo(3, settings.Get("IO3", "Input"));
result += F("<br>");
result += GetIOCombo(4, settings.Get("IO4", "Input")) + " ";
result += GetIOCombo(5, settings.Get("IO5", "Input")) + " ";
result += GetIOCombo(6, settings.Get("IO6", "Input")) + " ";
result += GetIOCombo(7, settings.Get("IO7", "Input"));
// result += GetMCPCombos(&settings, 2);
result += F("</td></tr>");
Der Unterschied ist, dass jetzt nicht mehr pro MCP-Zeile eine große String-Konkatenation gemacht wird, sondern pro IO.
Mit diesem Umbau haben sich die Symptome verändert - rufe ich die Setup-Seite jetzt direkt nach dem Boot des LGW auf, wird sie korrekt übertragen. Nachdem Bootvorgang des LGW hat dieses ca. 18 kB freien Heapspeicher (gerade gecheckt, da waren es genau 17888). Nach kurzer Zeit (und vermutlich einigen Empfangen Telegrammen) sinkt der freie Heapspeicher bei mir auf 15728. Dann wird auch die Setup-Seite nicht mehr korrekt übermittelt.
Ich habe die HTML-Seite, nachdem sie korrekt übertragen worden ist mal abgespeichert - sie hat eine Größe von 10.398 Bytes. Ich tippe darauf, dass sie schlicht zu groß geworden ist für den ESP :(
Und somit hat das Hinzufügen der Konfigurationsoptionen für die zweite Serial-Bridge das Problem weiter forciert...
Eine Lösungsidee könnte vielleicht sein, die Setup-Page aufzuteilen...
Der heap, der nach dem Booten verbraucht wird, geht ins Logging für die Log-Page, da wird ein Stück weit gepuffert, wenn es keiner abholt, dass man nach dem booten das boot log noch anschauen kann.
Könnte es sein, dass die String Klasse beim concat temporär deutlich mehr Speicher braucht, als die beiden Teile in Summe?
Nur so wäre zu erklären, dass es bei mir aktuell trotz 17848 freiem heap nicht funktioniert.
Ich glaube, ich schreibe mir mal einen String-Klasse-Tester, um auszuloten, wo da eigentlich die Grenzen sind.
Aber mit Deiner "Häppchen-Variante" und einer Erweiterung, dass beim Öffnen der Setup-Page der Buffer vom Logging geleert wird, könnte man es evtl. einfangen (falls es dann sicher reicht).
Aufteilen ist ein größerer Umbau, da aktuell stumpf die im (pseudo-)EEPROM abgelegte Konfiguration weggeworfen und die Neue reingepackt wird.
Hallo zusammen.
Habe mir das LCG zusammen gebaut. Habe die FW geflasht und dann erst in FHEM eingebunden. Hat soweit auch keine Probleme gemacht.
Dann habe ich mir 2 RFM69 C(W) drauf gelötet.
Habe das LCG dann nur als Stick konfiguriert, also WLAN ausgeschaltet.
Dann an den PI gesteckt, und danach ging dir Kirmesfahrt los. (open, disconnected, initializied und wieder von vorne).
Habe mal ein List dran gehängt von den verschiedenen Zuständen.
Habe das ganze auf einem WEMOS D1 Mini aufgebaut !!
Internals:
CFGFN
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
FD 4
LCG_S_MSGCNT 152
LCG_S_TIME 2017-01-03 12:36:12
NAME LCG_S
NR 44553
PARTIAL OK VALUES LGW 2640782 UpTimeSeconds=140,UpTimeText�?�������x��fx�����~f�`���f�����`�`�x ��f���fx��xfx`�`ff�f��f���� ��x��ff�f��f���f�����f~ff��x��f��f�昘x�x��x��fxf�fffx`� ���`��昆�������`���~~f���`���f�������f`�����ff �����f�怆�� ��fx��`ff�f������`�x��x� ��x��~� �x��~��� �����f�f�`�� f�ff�f����fxxf����~f~f�~f�����~� ���f�����`�x��`�� f���fx�ff ��������������x �� 怘��ff �����f�怆�� ��fx��`ff�f������`�x��x� ��x��~� �x��~��� �����f�f�`�� f�ff�f����fxxf����~f~f�~f�����~� ���f�����`�x��`�� f���fx�ff �������� �� ��� x� ��
RAWMSG OK 9 50 1 4 29 106
STATE initialized
TYPE LaCrosseGateway
model [LaCrosseITPlusReader.Gateway.1.24 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) {IP=Disabled}]
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-01-03 12:36:13 state initialized
Attributes:
room 99_receiver
Internals:
CFGFN
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
FD 43
LCG_S_MSGCNT 204
LCG_S_TIME 2017-01-03 12:39:53
NAME LCG_S
NR 44553
PARTIAL
RAWMSG OK VALUES LGW 2640782 UpTimeSecoivedFrames=305,FramesPerMinute=5=0,LD.Avg=0,LD.Max=19,OLED=none1.24 (1=RFM69 f:868300 r:17241) Disabled}]
STATE initialized
TYPE LaCrosseGateway
model [LaCrosseITPlusReader.Gateway.1.24 (1=RFM69 f:868300 r:17241) +isabled}]
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-01-03 12:39:53 state initialized
Attributes:
room 99_receiver
Internals:
CFGFN
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
FD 43
LCG_S_MSGCNT 206
LCG_S_TIME 2017-01-03 12:39:57
NAME LCG_S
NR 44553
PARTIAL ���f�怆�� ��fx��`ff�f����fxxf����~f~f�~f��� �����`�x��x� ��x��~� ���f�����`�x��x� ��x��~��� �����f�f�`�� f���fx��fxxf����~f~f�~f��� � ���f�����`�x��x� ���fx�ff �����f�怆�� ��fx��` �����`�x��x� ��xx� ��x��~��� �����f�f���������x�� ��� x� ����������������� `�� 怘�����f�ff��~�fxx � �ff���fff~�f~����~`���f�����`�`�x ��f���fx��xfxf�����f~ff���f��f�昘x�x��x���`���~~f���`���f��������������� ����x�xx� ����������� x��� 怘����������� �� 怘������� �� ��� x� �����f�怆�� ��fx��`ff�f����fxxf����~f~f�~f��� �����`�x��x� ��x��~� ���f�����`�x��x� ��x��~��� �����f�f�`�� f���fx��fxxf����~f~f�~f��� �����`�x��x� ��x��~� ���f�����`�x��x� ��x��~��� �����f�f�`�� f���fx�ff �����f�怆�� ��fx��`ff�f����fxxf����~f~f�~f��� �����`�x��x� ��x��~� ���f�����`�x��
RAWMSG OK 9 5 1 5 174 106
STATE initialized
TYPE LaCrosseGateway
model [LaCrosseITPlusReader.Gateway.1.24 (1=RFM69 f:868300 r:17241) +isabled}]
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-01-03 12:39:57 state initialized
Attributes:
room 99_receiver
Internals:
CFGFN
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
FD 43
LCG_S_MSGCNT 209
LCG_S_TIME 2017-01-03 12:40:22
NAME LCG_S
NR 44553
PARTIAL ���f�怆�� ��fx��`ff�f����fxxf����~f~f�~f��� �����`�x��x� ��x��~� ���f�����`�x��x� ��x��~��� �����f�f�`�� f���fx�ff �����f�怆�� ��fx��`ff�f��x� ��x��~��� �����f�f�`�� f���fx�ff ��x�ff���f�fx ���`��f�x��f 昆������x��fx�����~f�`���`�`ff�f��f�x� ��x��ff�f��f�����fxf�fffx`� ���`��昆������f`������ff������������� �� 怘����������� x��� 怘���������������� ~�� 怘��ff �����f�怆�� ��fx��`ff�f������`�x��x� ��x��~� �x��~��� �����f�f�`�� f�ff�f����fxxf����~f~f�~f�����~� ���f�����`�x��`�� f���fx�ff ���
RAWMSG ���f�怆�� ��fx��`ff�f����fxxf����~f~f�~f��� �����`�x��x� ��x��~� ���f�����`�x��x� ��x��~��� �����f�f�`�� f���fx��fxxf����~f~f�~f��� �����`�x��x� ��x��~� ���f�����`�x��x� ��x��~��� �����f�f�`�� f���fx�ff �����f�怆�� ��fx��`ff�f����fxxf����~f~f�~f��� �����`�x��x� ��xx� ��x��~��� �����f�f���������������� x�� 怘�OK 9 51 1 4 192 36
STATE initialized
TYPE LaCrosseGateway
model [LaCrosseITPlusReader.Gateway.1 (2=RFM69 f:868300 r:9579) {IP=DOK 9 62 1 4 173 46
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-01-03 12:40:22 state initialized
Attributes:
room 99_receiver
Internals:
CFGFN
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
FD 51
LCG_S_MSGCNT 213
LCG_S_TIME 2017-01-03 12:40:45
NAME LCG_S
NR 44553
PARTIAL [LaCrosseITPlusReader.Gateway.1 (2=RFM69 f:868300 r:9579) {IP=D
RAWMSG OK 9 5 1 5 177 106
STATE opened
TYPE LaCrosseGateway
model [LaCrosseITPlusReader.Gateway.1.24 (1=RFM69 f:868300 r:17241) +isabled}]
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-01-03 12:40:47 state opened
Attributes:
room 99_receiver
Internals:
CFGFN
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
FD 44
LCG_S_MSGCNT 221
LCG_S_TIME 2017-01-03 12:41:10
NAME LCG_S
NR 44553
PARTIAL
RAWMSG .24 (1=RFM69 f:868300 r:17241) +isabled}]
STATE opened
TYPE LaCrosseGateway
model [LaCrosseITPlusReader.Gateway.1 (2=RFM69 f:868300 r:9579) {IP=DOK VALUES LGW 2640782 UpTimeSecoin. 0Sek. ,WIFI=WLAN-DFB306,Rece5,RSSI=Off,FreeHeap=24872,LD.Min
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-01-03 12:41:10 state opened
Attributes:
room 99_receiver
Kann sich jemand darauf einen Reim machen `?
Habe auch die ganzen Lötungen kontrolliert. Soweit ist alles ok.
Gruß und Danke
Sascha
Zitat von: sash.sc am 03 Januar 2017, 12:42:01
Dann an den PI gesteckt, und danach ging dir Kirmesfahrt los. (open, disconnected, initializied und wieder von vorne).
Ich würde mal stark drauf tippen, dass Du ein USB-Port-Problem hast.
Wenn die Daten vom LGW mal durchkommen, dann sieht man, dass es korrekt initialisiert ist (beide RFM erkannt):
model [LaCrosseITPlusReader.Gateway.1.24 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) {IP=Disabled}]
Aber meistens kommt wohl vom USB-Port nur Schrott oder unvollständiger Kram.
model [LaCrosseITPlusReader.Gateway.1.24 (1=RFM69 f:868300
r:17241) +isabled}] Kannst Du es mal an einen Windows-Rechner stecken und mit einem Terminalprogramm loggen, was es sendet?
Asche auf mein Haupt. :o
Ich hatte noch ein MySensor Gateway auf dem gleichen USB konfiguriert. Hatte die Config nicht entfernt.
Musste diese auch manuell löschen, da sich das MySensor GW manuell nicht löschen ließ.
Nachdem ich es gelöscht hatte, läuft es jetzt auch ohne Probleme.
Kleine Ursache, große Wirkung.
Habe jetzt auch alle JeeLink Devices auf das LGW umgestellt.
Habe aber nochmal eine Frage. Wie kann ich das WLAN jetzt nachträglich wieder aktivieren, wenn ich das LGW dann doch noch woanders positionieren will ??
Gruß und Danke für die Unterstützung.
Sascha
Zitat von: sash.sc am 03 Januar 2017, 13:16:22
Asche auf mein Haupt. :o
kann man mit:
set LCG_S raw VolcanicEruptionauslösen ;D ;D ;D
Zitat von: sash.sc am 03 Januar 2017, 13:16:22Habe aber nochmal eine Frage. Wie kann ich das WLAN jetzt nachträglich wieder aktivieren, wenn ich das LGW dann doch noch woanders positionieren will ??
Das kann man mit:
set LCG_S raw "SETUP UseWiFi true"machen.
Zitat von: Wallmeier am 02 Januar 2017, 23:08:59
Ich tippe darauf, dass sie schlicht zu groß geworden ist für den ESP :(
Ja, so ist es wohl.
Aber Du hast mich wieder auf den richtigen Pfad zurückgeführt.
Ich habe
- Deine "in kleinen Häppchen an den großen String anfügen" Strategie noch etwas weiter getrieben
- Die Seite etwas byte-schonender gemacht
- Und ich leere und deaktiviere jetzt vor dem Aufbauen der page die log queue, was etwas mehr heap beschert
Damit bin ich zumindest an dem Punkt, dass sie fast immer korrekt funktioniert (zu 99%)
im Gegensatz zu bisher, wo sie zu 99% nicht funktioniert hat (zumindest auf meinem "all you can connect" lGW)
Zitat von: HCS am 01 Januar 2017, 22:14:35
Dann hast Du das Radio an GPIO2 angeschlossen. Wenn Du es an GPIO15 (D8) anschließt, wird es Radio #1
Das wird nicht gehen. Mit dem Nextion Display wäre das machbar. Siehe hier: https://forum.fhem.de/index.php?action=dlattach;topic=63443.0;attach=65245
Da musst Du Dir in FHEM etwas schreiben, das die Werte alle x Sekunden an das Display schickt.
So in der Art: set myLaCrosseGateway raw "OLED show=55%,,,h"
siehe https://wiki.fhem.de/wiki/LaCrosseGateway#Inbetriebnahme_von_OLED-Display
Danke @HCS, Radio #1 wird jetzt verwendet.
Wie muss denn initCommands aussehen, wenn Radio #1 gesetzt werden soll und das OLED Temp/Hum/Pressure anzeigen soll?
"1,868950,60i 0a v OLED mode=thps" funktioniert leider nicht.
Zitat von: Flexstarr am 03 Januar 2017, 21:23:05
Wie muss denn initCommands aussehen, wenn Radio #1 gesetzt werden soll und das OLED Temp/Hum/Pressure anzeigen soll?
"1,868950,60i 0a v OLED mode=thps" funktioniert leider nicht.
Ich würde in die initCommands nur
1,868950,60i 0a vohne Füße von Gänsen reinschreiben und die Initisierung des OLED auf der setup-page machen.
OLED start: on oder eine Zeit angeben
und bei mode thp eintragen.
Zitat von: Wallmeier am 02 Januar 2017, 23:08:59
Die Sache hat mir keine Ruhe gelassen und ich habe ein wenig herum gespielt...
Mir auch nicht, und die 99%-Lösung war mir dann doch zu wenig.
Ich denke, dass ich das setup-page-Problem nun endgültig gelöst habe.
Ich habe endlich rausgefunden, wie man das chunked Transfer-Encoding hinbekommt.
Damit muss das html nicht mehr in einen giga-String und kann in kleineren Portionen konstruiert und rausgeschickt werden.
Funktioniert generell so:
m_webserver.setContentLength(CONTENT_LENGTH_UNKNOWN);
m_webserver.send(200, "text/html", "");
m_webserver.sendContent("<p>Das</p>");
m_webserver.sendContent("<p>ist</p>");
m_webserver.sendContent("<p>cool</p>");
m_webserver.client().stop();Jetzt rückt die 1.25 in greifbare Nähe 8)
Das ist ja richtig cool :) Glückwunsch zu der sauberen Lösung!
V1.25
Zweite serial bridge
Man kann nun mit Hilfe eine zweiten SC16IS750 eine zweite serial bridge verwenden.
Damit kann man z.B. zwei nanoCUL oder sonstige serielle devices anschließen.
Der zweite SC16IS750 muss die I2C Adresse 0x92 haben.
Vielen Dank an Walleier für den Patch, der das hinzugefügt hat.
Mehrere Clients auf den Ports der serial bridges
Auf einen Port einer serial bridge können sich nun mehrere clients verbinden.
Vielen Dank an Walleier für den Patch, der das hinzugefügt hat.
setup page
Die Probleme der setup page sollten nun endlich behoben sein.
Hallo HCS
Habe gerade versucht die neue FW zu flashen. Das Gateway läuft bei mir als Stick.
Habe nach dem flashen folgende Meldung bekommen.
flashing LaCrosseGateway LCG_S
hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
Mode is LaCrosseGateway OTA-update
LCG_S closed
target: http:///dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600/ota/firmware.bin
ERROR: 500 No Host option provided at /usr/share/perl5/Net/HTTP/Methods.pm line 44.
LCG_S opened
Was heisst das ??
Guß
Sascha
Zitat von: sash.sc am 06 Januar 2017, 13:34:50
Was heisst das ??
Das bedeutet, dass Du noch einen Tag warten musst.
Aktuell kann das LaCrosseGateway-Modul nur über WiFi flashen.
ich habe aber gerade eingebaut, dass es das auch für ein lokal per USB angeschlossenes LGW (also Deine Variante) hinbekommt.
Ich denke, dass ich diese Version heute Abend einchecke, so dass es dann morgen mit dem Update ausgeliefert wird.
Hab heute meine LCG Armee auf Version 1.25 gebracht. Konnte bisher auf keinem den alten Bug mehr nachstellen ;)
LaCrosseGateway Modul
Also das Modul in FHEM meine ich damit.
Neuerungen:
set lgwXYZ reboot
Wenn das LGW per USB angebunden ist. wird nun ein harter Reset per RTS ausgelöst.
Bei per WiFi angebundenen LGWs wird wie bisher ein Reset-Wunsch an das LGW übermittelt.
FHEM-Log bei USB angebundenen LGWs
Da der bootloader des ESP8266 beim booten Meldungen mit der "falschen" baud rate schickt, wurde bei jedem booten so etwas ins FHEM-Log geschrieben:
lgwXYZ: Unknown code ے�eo>Il�ˀ������, help me!
Das wird nun unterdrückt.
Firmware upload für per USB angebundene LGWs
LGWs, die per USB mit deaktiviertem WiFi angebunden sind, können nun auch mit der aktuellen Firmware versorgt werden.
Dazu sind einige Voraussetzungen zu schaffen:
Python muss installiert sein.
apt-get install python
pyserial muss installiert werde:
wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py
pip install pyserial
Der mode muss auf USB eingestellt sein:
attr lgwUSB mode USB
Das Attribut usbFlashCommand muss vorhanden sein. Es wird automatisch generiert und sein Inhalt muss üblicherweise nicht angepasst werden.
Dann kann die Firmware mit
set lgwUSB flash
hochgeladen werden. Dazu wird der USB-Port aus der device definition verwendet.
Nach dem Upload bekommt man ein Protokoll das so aussehen sollte:
flashing LaCrosseGateway LGWusb
hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
Mode is LaCrosseGateway USB-update
command: ./FHEM/firmware/esptool.py -b 921600 -p /dev/ttyUSB0 write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 ./FHEM/firmware/JeeLink_LaCrosseGateway.bin > ./log/LaCrosseGatewayFlash.log
--- esptool ---------------------------------------------------------------------------------
esptool.py v2.0-dev
Connecting...
Detecting chip type... ESP8266
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Attaching SPI flash...
Configuring flash size...
Writing at 0x00000000... (3 %)
Writing at 0x00004000... (7 %)
Writing at 0x00008000... (10 %)
Writing at 0x0000c000... (14 %)
Writing at 0x00010000... (17 %)
Writing at 0x00014000... (21 %)
Writing at 0x00018000... (25 %)
Writing at 0x0001c000... (28 %)
Writing at 0x00020000... (32 %)
Writing at 0x00024000... (35 %)
Writing at 0x00028000... (39 %)
Writing at 0x0002c000... (42 %)
Writing at 0x00030000... (46 %)
Writing at 0x00034000... (50 %)
Writing at 0x00038000... (53 %)
Writing at 0x0003c000... (57 %)
Writing at 0x00040000... (60 %)
Writing at 0x00044000... (64 %)
Writing at 0x00048000... (67 %)
Writing at 0x0004c000... (71 %)
Writing at 0x00050000... (75 %)
Writing at 0x00054000... (78 %)
Writing at 0x00058000... (82 %)
Writing at 0x0005c000... (85 %)
Writing at 0x00060000... (89 %)
Writing at 0x00064000... (92 %)
Writing at 0x00068000... (96 %)
Writing at 0x0006c000... (100 %)
Wrote 458752 bytes at 0x00000000 in 6.5 seconds (560.8 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting...
--- esptool ---------------------------------------------------------------------------------
LGWusb opened
Ist eingecheckt, das Update morgen bringt es dann ins Haus.
Hört sich nach viel Aufwand an.! 8)
Lgw in wifi Modus bringen und dann über ota flashen.
Aber sehr gute Unterstützung hier!
Gruß und danke
Sascha
Von mobil gesendet daher kurze Antwort
Zitat von: sash.sc am 06 Januar 2017, 22:22:07
Hört sich nach viel Aufwand an.! 8)
:o
Aber evtl. habe ich es in meinem Beitrag nicht deutlich gemacht:
apt-get install python
wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py
pip install pyserialMuss man nur ein mal auf dem Server machen. Vier Befehle per copy paste in eine SHH-Sitzung kopieren, das war es dann.
Und falls man das noch nicht gemacht hat, halt noch das mode Attribut einmalig korrekt setzen.
Danach kann man immer und jederzeit einen "set lgwUSB flash" absetzen, ohne vorher nochmal irgend etwas machen zu müssen.
Nach meiner persönlichen Einschätzung hält sich der Aufwand doch sehr in Grenzen ;)
Zitat von: sash.sc am 06 Januar 2017, 22:22:07
Lgw in wifi Modus bringen und dann über ota flashen.
Das geht aber nur, wenn man den define des LaCrosseGateway-Device erst mal auf die TCP-Verbindung umschreibt, sonst hat ein "set lgwBlaBla flash" keine Ahnung, wie es das LGW per WiFi erreicht.
Ok. Hast mich überzeugt! 8)
Von mobil gesendet daher kurze Antwort
Ok. Hast mich überzeugt! 8)
Von mobil gesendet daher kurze Antwort
Ok. Hast mich überzeugt! 8)
Von mobil gesendet daher kurze Antwort
Habe da mal eine Frage bezüglich des keyvalueprotokoll.
Kann man den 10 Sekunden Takt des senden etwas entschärfen, bzw den sendeabstand verlängern?
Z.b. Auf 1 minuten oder länger oder einstellbar?
Gruß Sascha
Zitat von: sash.sc am 08 Januar 2017, 12:11:17
Kann man den 10 Sekunden Takt des senden etwas entschärfen, bzw den sendeabstand verlängern?
Ja, auf der setup page.
Die Einstellung hinter "KV-Interval:"
Hi zusammen,
habe meinen zweiten RFM69 nun erhalten und probiert ihn anzuschließen.
Wenn ich das richtig verstanden habe muss ich dazu folgendes machen:
- NSS RFM69#2 auf nodemcu D4
- GND und 3 V von nodemcu auf RFM69#2
- Alles andere (SCK, MOSI und MISO) greife ich vom RFM#1 ab
Ist das soweit korrekt? Falls ja muss ich anschließend noch was machen?
Es wird nämlich weiterhin nur ein RFM69 erkannt.
Gruß,
Tobi
Zitat von: onkel-tobi am 08 Januar 2017, 13:49:46
Ist das soweit korrekt?
Ja. NSS an GPIO2 = D4
Alles andere parallel zum ersten RFM69
Hi & danke!
Das funktioniert soweit, aber die Reichweite scheint ziemlich gering zu sein (aktuell bei mir ca. 1m).
Was ist denn so "normal"?
Antenne sollte ca. 8,2 cm lang sein hatte ich gelsen. Aber evtl. mache ich noch grundsätzlich etwas falsch? Meine WS1600 empfange ich zwar über ca. 10m Entfernung, aber da sind die Battarien ständig leer.
Auf dem LGW habe ich inzwischen V1.24, die PC301 werden unter Plugins angezeigt und schalten wie gesgt auch im 1m Bereich. Frequenzen habe ich 868960, 868950 und 868970 probiert.
List des Jeelink Devices aus FHEM:
Internals:
CFGFN FHEM/wetter.cfg
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF 192.168.178.81:81
DeviceName 192.168.178.81:81
FD 14
NAME myJeeLink
NR 156
NR_CMD_LAST_H 2
PARTIAL
RAWMSG OK VALUES LGW 1302972 UpTimeSeconds=420,UpTimeText=0Tg. 0Std. 7Min. 0Sek. ,WIFI=blablubb,ReceivedFrames=2,FramesPerMinute=0,RSSI=-55,FreeHeap=21824,LD.Min=0,LD.Avg=0,LD.Max=10,OLED=none
STATE initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.Gateway.1.24 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868960 r:6631) {IP=192.168.178.81}]
myJeeLink_MSGCNT 80
myJeeLink_TIME 2017-01-08 17:08:50
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:
2017-01-08 17:08:50 state initialized
XMIT_TIME:
1483891441.71755
1483891490.72287
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 2,868960,120i v
timeout 120,30
Gruß,
Tobi
Zitat von: onkel-tobi am 08 Januar 2017, 17:14:45
Das funktioniert soweit, aber die Reichweite scheint ziemlich gering zu sein (aktuell bei mir ca. 1m).
Was ist denn so "normal"?
"normal" kann man schwer definieren. Das hängt von unzähligen Faktoren wie Bausubstanz, Luftfeuchtigkeit, Antennenposition (5cm hin oder her machen teils den Unterschied), 70"-Fernseher (die in der Funkstrecke hängen) usw. ab.
Generell ist mein Erfahrung, dass LaCrosse-Sensoren (TX...it), PCA301, EMT7110, WS 1600 und EC3000 alles grob die gleiche Reichweite hat, zumindest mit dem LGW.
Und die ist definitiv mehr als 1m.
Bei mir im Haus (gute alte Bauweise ohne Stahlbeton) empfange ich teils vom Keller bis ins 1. OG und auf einer Etage 10m quer durch die Räume. Aber das ist halt alles relativ, ich hatte auch schon Probleme bei bestimmten Sensoren, die deutlich näher waren als welche, die empfangen wurden. In einem Fall war ein Drahtgeflecht (wie man es gaaaanz früher eingeputzt hat) in einer Wand schuld.
Darum das LGW, dass man ein zwei Stück an strategisch geschickten Positionen aufstellen kann.
Zitat von: onkel-tobi am 08 Januar 2017, 17:14:45
Antenne sollte ca. 8,2 cm lang sein hatte ich gelsen.
Das passt.
Zitat von: onkel-tobi am 08 Januar 2017, 17:14:45
Meine WS1600 empfange ich zwar über ca. 10m Entfernung, aber da sind die Battarien ständig leer.
Die halten bei meiner über ein Jahr, kann es aber gar nicht genau sagen, weil es so selten ist, dass ich sie wechseln muss.
Zitat von: HCS am 08 Januar 2017, 18:52:49
"normal" kann man schwer definieren. Das hängt von unzähligen Faktoren wie Bausubstanz, Luftfeuchtigkeit, Antennenposition (5cm hin oder her machen teils den Unterschied), 70"-Fernseher (die in der Funkstrecke hängen) usw. ab.
Generell ist mein Erfahrung, dass LaCrosse-Sensoren (TX...it), PCA301, EMT7110, WS 1600 und EC3000 alles grob die gleiche Reichweite hat, zumindest mit dem LGW.
Und die ist definitiv mehr als 1m.
Bei mir im Haus (gute alte Bauweise ohne Stahlbeton) empfange ich teils vom Keller bis ins 1. OG und auf einer Etage 10m quer durch die Räume. Aber das ist halt alles relativ, ich hatte auch schon Probleme bei bestimmten Sensoren, die deutlich näher waren als welche, die empfangen wurden. In einem Fall war ein Drahtgeflecht (wie man es gaaaanz früher eingeputzt hat) in einer Wand schuld.
Darum das LGW, dass man ein zwei Stück an strategisch geschickten Positionen aufstellen kann.
Hm, ok. Muss ich noch mal schauen und testen.
Zitat
Die halten bei meiner über ein Jahr, kann es aber gar nicht genau sagen, weil es so selten ist, dass ich sie wechseln muss.
Was für Batterien verwendest Du? Ich habe die WS nun seit Mai 2016 und schon 5 mal die Batterien wechseln müssen.
Gruß & Danke,
Tobi
Zitat von: onkel-tobi am 10 Januar 2017, 20:07:52
Hm, ok. Muss ich noch mal schauen und testen.Was für Batterien verwendest Du?
Die von Al?i.
Hallo,
Ich habe mir jetzt ein Gateway aus einem ESP und einem RFM69HW gebaut. Einbinden konnte ich ihn auch in FHEm.
Gibt es eine Möglichkeit das Gateway ohne Sensor zu testen?
Den RFM69 hat er scheinbar auch gefunden:
Internals:
CFGFN
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF 192.168.1.35:81
DeviceName 192.168.1.35:81
FD 32
NAME myLaCrosseGateway
NR 548
PARTIAL
RAWMSG OK VALUES LGW 2887997 UpTimeSeconds=350,UpTimeText=0Tg. 0Std. 5Min. 50Sek. ,WIFI=HasenpupsExtreme,ReceivedFrames=0,FramesPerMinute=0,RSSI=-67,FreeHeap=16688,LD.Min=0,LD.Avg=0,LD.Max=20,OLED=none
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model [LaCrosseITPlusReader.Gateway.1.25 (1=RFM69 f:868300 r:17241) {IP=192.168.1.35}]
myLaCrosseGateway_MSGCNT 35
myLaCrosseGateway_TIME 2017-01-17 17:18:16
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-01-17 17:18:16 state initialized
Attributes:
room LaCrosse
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
Zitat von: gloob am 17 Januar 2017, 17:16:34
Gibt es eine Möglichkeit das Gateway ohne Sensor zu testen?
Was willst Du denn noch testen?
Es ist konfiguriert, hat sich im wlan angemeldet, FHEM kann mit ihm kommunizieren, es hat den RFM69 erkannt und sendet seine Statuswerte an FHEM.
Alles prima.
Ob es einen Sensor empfangen kann, kann man nur testen, wenn man einen Sensor hat, der etwas sendet.
@HCS Würde das Gateway auch mit folgende Modulen funktionieren ? RFM95/96/97/98（W）
Anschlußmäßig sollte es keine Probleme geben, wenn ich mir die PIN Belegung anschaue.
Ich frage, weil die Teile auch eine Sendeleistung haben, die recht hoch ist ..... --> (LoRa)
http://www.kh-gps.de/lora.htm (http://www.kh-gps.de/lora.htm)
Gruß
Sascha
Zitat von: sash.sc am 21 Januar 2017, 17:43:42
@HCS Würde das Gateway auch mit folgende Modulen funktionieren ? RFM95/96/97/98（W）
Ich tippe stark auf nein, weil da ein anderes Modulationsverfahren verwendet wird.
Zitat von: sash.sc am 21 Januar 2017, 17:43:42
Ich frage, weil die Teile auch eine Sendeleistung haben, die recht hoch ist ..... --> (LoRa)
Das nützt ja nichts. LaCrosse-Sensoren werden eh nur empfangen, da spielt die Sendeleistung keine Rolle und bei PCA301 nützt es auch nichts, dass man eine weit entfernte Dose mit einer irren Leistung anbrüllt aber dann die Antwort nicht hört, da die PCA301 brav mit ihren +13dBm sendet.
Und in Deutschland ist es auch nicht erlaubt (siehe Bundesnetzagentur Vfg 30/2014), dass SRDs im Bereich von 868,000 - 868,600 MHz mit mehr als 25 mW senden.
Der RFM69CW sendet mit maximal +13 dBm, was ca. 20mW entspricht.
Ein RFM69HCW sendet mit +20dBm, was 100mW entspricht.
Das der rfm69hcw stärker auf der brust ist, weiß ich. Habe den an nen jeelink clone dran. 8)
Hatte evtl gehofft, den auf 433 mhz zum laufen zu bekommen. (Signalduino). Diese Hoffnung wurde aber schon zerschlagen.
Gruß Sascha
Von mobil gesendet daher kurze Antwort
Hat jemand einen Tipp für mich wie ich die Datenrate des ersten Moduls ändern kann? Irgendwie komm ich mit den Hinweisen aus dem Wiki nicht klar.
Zitat von: gloob am 24 Januar 2017, 21:20:32
Hat jemand einen Tipp für mich wie ich die Datenrate des ersten Moduls ändern kann? Irgendwie komm ich mit den Hinweisen aus dem Wiki nicht klar.
Beispiel: 9579#1r
setzt die data rate von Radio#1 auf 9579 kbps
Syntax ist: <n>#<x>m
<x> ist die Nummer vom Radio, <n> die gewünschte data rate.
Vielen Dank.
Ich denke mal n ist die Data Rate und x die Nummer vom Radio.
Sehe ich es richtig, dass ein Device Nachrichten von mehreren Gateways erhalten kann?
myLaCrosseGateway2_MSGCNT 61
myLaCrosseGateway2_TIME 2017-01-24 22:23:38
myLaCrosseGateway_MSGCNT 48
myLaCrosseGateway_TIME 2017-01-24 22:21:50
Zitat von: gloob am 24 Januar 2017, 22:24:50
Ich denke mal n ist die Data Rate und x die Nummer vom Radio.
Ja. Man sollte so was nicht "nebenbei" schreiben, dann kann es nur falsch werden.
Habe meinen Beitrag korrigiert.
Zitat von: gloob am 24 Januar 2017, 22:24:50
Sehe ich es richtig, dass ein Device Nachrichten von mehreren Gateways erhalten kann?
Ja. Wenn mehrere LGW oder auch ein LGW und ein JeeLink den selben Sensor empfangen können, dann bekommt es das LaCrosse device von beiden geliefert. Darum und aus weiteren Gründen sollte man die Events mit event-min-interval usw. etwas drosseln.
Kann es sein, dass die Watchdog-Funktion in der aktuellen Version nicht ganz funktioniert?
Habe auf FHEM-Seite das Attribut watchdog auf 300 stehen, der LGW meldet auch brav im Log das da immer wieder eine Anfrage rein kommt und er sie beantwortet.
Mein WLAN ist aktuell aber ein bisschen "bescheiden" und vergisst hin und wieder, welche Clients eingebucht sind. Das LGW gibt per Serial-Log weiterhin brav Text von sich, aber die FHEM-Anfragen bleiben logischerweise aus. Ich dachte, das LGW müsste ein Reset ausführen, wenn er $Watchdogtimer überschritten hat? Dachte erst, der ESP schmiert hin und wieder ab, hab dann erstmal das Seriell-Kabel wieder dran gefummelt..
Zitat von: shaddi am 03 Februar 2017, 08:37:15
Habe auf FHEM-Seite das Attribut watchdog auf 300 stehen, der LGW meldet auch brav im Log das da immer wieder eine Anfrage rein kommt und er sie beantwortet.
Gerade getestet:
timeout 30
watchdog 60
einige Minuten laufen lassen
dann das LaCrosseGateway device gestoppt, dass es nicht mehr mit dem LGW spricht und eine Minute später hat das LGW einen reset gemacht.
Aber evtl. ist das bei Dir eine besondere Situation.
Kannst Du mal aus dem frontend log die entscheidenden Passagen hier anhängen?
Nochmal zu Erläuterung:
timeout prüft alle x Sekunden, ob es vom LGW eine Antwort bekommt, wenn es ihm etwas schickt.
Falls es keine Antwort bekommt, baut es die Verbindung zum LGW neu auf, mehr nicht.
watchdog (geht nicht ohne auch timeout zu setzen und muss deutlich länger als timeout sein) sagt zusätzlich dem LGW, dass wenn es x Sekunden nicht gefragt wurde, es einen Reset machen soll.
ich nutze die großartige Lösung bereits (Wemos D1 Mini, BME180, RFM69CW). In der Bastelkiste liegen auch noch MCP23008 - toll, dass der Chip unterstützt wird. Ich würde gern ohne weitere Bridge (also den SC16IS750) einen Arduino Pro Mini (3.3V, 8MHz) mit aculw anschließen (steht schon zur Verfügung, läuft über einen ESP-01). Die Überlegung ist, das Witty-Cloud-Platinchen (mit muss nach der "witzigen Wolke" suchen;-) mit ESP-12F zu verwenden, weil man da den USB-Chip abtrennen kann, so dass die serielle Schnittstelle zur Verfügung steht. Hat das schon jemand versucht? Oder gibt es Timing-Probleme?
Zitat von: dramoe am 06 Februar 2017, 12:47:57
Hat das schon jemand versucht?
Sorry, verstehe nur Bahnhof.
Was willst Du machen?
Ich möchte die vorhandene serielle Schnittstelle, die über CH340 oder CP210x mit der USB verbunden ist, für die Anbindung eines CUL nutzen. Die Witty-Clouds bestehen aus 2 Platinen; man kann die Platine mit dem CH340 entfernen, so dass die serielle Schnittstelle zur Verfügung stehen würde. Allerdings könnte es sein, dass man diese Schnittstelle zu oft voraussetzt bzw. sich auch da Timing-Probleme einhandelt.
Zitat von: dramoe am 07 Februar 2017, 17:21:54
Ich möchte die vorhandene serielle Schnittstelle, die über CH340 oder CP210x mit der USB verbunden ist, für die Anbindung eines CUL nutzen.
Das geht nicht. Die bridge kann nicht über diese serielle Schnittstelle arbeiten.
Entweder SC16IS750 verwenden oder noch ein zwei Monate (+x) warten auf die auf den ESP32 portierte Version, die wird vermutlich zwei bridges nativ am ESP32 können, ohne dass man einen SC16IS750 benötigt.
Hallo,
ich habe eine Frage zur PCA301. Bei einiges Dosen wird das consumption nicht empfangen. Am Jeelink lag es nicht, das LGW macht es genauso wenig. Hat jemand noch eine Idee, kann man am LGW eventuell etwas genauer schauen ob diese werte ankommen? Ich habe schon die PCA Dosen gelöscht und neu anlegen lassen, bei einer hat es funktioniert bei den anderen beiden nicht. Ich stehe da ein bissel aufm Schlauch. Auch wenn nur 4 Watt fließen aber nach 5h sollte sich der Verbrauchswert wenigstens ein bissel rühern.
/Daniel
Zitat von: ext23 am 10 Februar 2017, 12:30:26
ich habe eine Frage zur PCA301. Bei einiges Dosen wird das consumption nicht empfangen. Am Jeelink lag es nicht, das LGW macht es genauso wenig. Hat jemand noch eine Idee, kann man am LGW eventuell etwas genauer schauen ob diese werte ankommen? Ich habe schon die PCA Dosen gelöscht und neu anlegen lassen, bei einer hat es funktioniert bei den anderen beiden nicht. Ich stehe da ein bissel aufm Schlauch. Auch wenn nur 4 Watt fließen aber nach 5h sollte sich der Verbrauchswert wenigstens ein bissel rühern.
Siehe hier: https://forum.fhem.de/index.php/topic,51236.msg439356.html#msg439356
Mhh ich hab jetzt nur im Log auf der WebGUI vom LGW geschaut, aber ich sehe nirgends eine Zeile mit PCA301. Ich sehe hier nur die HEX codes meiner ganzen EC3000. Mhh naja ich schau nochmal genauer hin, vielleicht habe ich da was übersehen.
Aber weil ich das gerade mit den 2 Watt lese, mhh da bin ich ja mit meinen 5 Watt nicht groß drüber, das könnte ja auch das Problem sein.
/Daniel
Zitat von: ext23 am 10 Februar 2017, 12:56:03
Aber weil ich das gerade mit den 2 Watt lese, mhh da bin ich ja mit meinen 5 Watt nicht groß drüber, das könnte ja auch das Problem sein.
Ja. Der hier hatte auch 5W: https://www.elv.de/topic/pca301-keine-gesamtwerte-bei-geringem-verbrauch.html
Meiner Meinung nach ist das ein Fehler der PCA301.
Und interessant ist, dass ELV das seit 16.01.2015 kein Stück weit interessiert hat.
Naja die verkaufen eben nur, kommt doch alles aus China was sollen die machen. Software Update geht ja schlecht, wenn es überhaupt geht und nicht ein shunt oder ähnlich getauscht werden müsste.
Preis und Qualität sind nun mal fest aneinander gebunden, das hat auch China mittlerweile begriffen.
So jetzt habe ich die Dose gefunden, ich war natürlich zu blöd den Filter zu benutzen...
Also die Werte die von der Dose kommen decken sich mit dem was FHEM anzeigt. Also renne ich da in genau dasselbe Problem.
Also am besten noch ein Heizlüfter parallel in die Dose stecken ^^
/Daniel
Wegen fünf Watt anfangen zu messen rentiert sich ja nun auch wirklich nicht ;D ;D ;D
ich habe vor einem Gefrierschrank zwei EMT7110 und eine EC3000 gestapelt.
Akkumulierter (von den Dosen gemeldeter) Verbrauch nach 20 Tagen
EC3000: 10.1 kWh
EMT7110 (1): 18.6 kWh
EMT7110 (2): 17.8 kWh
Was stimmt nun? -> möglicherweise nichts davon?
Wenn ich mir genug Mut angetrunken habe, hänge ich noch eine PCA301 mit dazu und schaue, was die dann für einen Wert würfelt.
Hallo HCS,
die Dosen haben einen Eigenverbrauch, den sie "wegrechnen". D.h. die nächste Dose misst den Verbrauch der vorherigen mit. Allerdings macht mich der Unterschied zwischen EC3000 und EMT7110 stutzig :o
Gruß PeMue
Kennt einer die Meßverfahren bei den verschiedenen Geräten? Ich denke mal viele machen das über ein Shunt oder? Also Wirkleistung. Gibt ja noch den Weg über Hall Sensoren aber in dieser Preisklasse wohl eher nicht.
Dann kommt alles aus China, ich glaube nicht das die da Widerstände benutzen die eine besondert kleine Toleranz haben, die kosten ja ein paar Cent mehr.
Aber der Unterschied ist schon ziemlich übel.
/Daniel
Die EC3000 ist ganz "oben".
Also Steckdose -> EMT7110 -> EMT7110 -> EC3000 -> Gefrierschrank
Dann müsste die EC3000 in 20 Tagen einen Eigenverbrauch von 8 kWh gehabt haben :o
Zitat von: ext23 am 10 Februar 2017, 16:52:36
Kennt einer die Meßverfahren bei den verschiedenen Geräten? Ich denke mal viele machen das über ein Shunt oder? Also Wirkleistung.
Noch nicht. Aber das würde der Grund dafür sein, dass das mit einer 100W Glühbirne alles gut aussieht und mit dem Kompressor von Gefrierschrank dann nicht.
Ich glaube, dass ich beide mal aufmache und schaue.
Oder auf schaue, ob auf dem Motor der cos phi drauf steht, dann könnte ich mal schauen, ob man es damit von EMT7110 nach EC3000 rechnen kann.
Dann wäre klar, dass wir Schein mit Wirk vergleichen.
Mach am besten mal ein Foto von, ich hatte die EC3000 schon offen und die PCA301 auch, aber aus anderen Gründen. Und ich Depp hab keine Bilder gemacht.
Zitat von: HCS am 10 Februar 2017, 13:03:16
Ja. Der hier hatte auch 5W: https://www.elv.de/topic/pca301-keine-gesamtwerte-bei-geringem-verbrauch.html
Meiner Meinung nach ist das ein Fehler der PCA301.
Ich bin jetzt schon bei 8 Watt... Also 6kWh im Monat zu unterschlagen ist schon eine Hausnummer.
/Daniel
Zitat von: ext23 am 12 Februar 2017, 11:14:05
Ich bin jetzt schon bei 8 Watt... Also 6kWh im Monat zu unterschlagen ist schon eine Hausnummer.
Definitiv. Das ist keine Unschönheit sondern ein kapitaler Bug.
Irgendwo habe ich was von "... bei einstelligen Verbrauchswerten" gelesen :o
Man muss einfach zu allem einen 10W shunt dazu hängen.
Wird zwar eine teure Messung, aber man weiß dann, wie sparsam man etwas betrieben
hätte ;D ;D
V1.26
Anpassungen für LGWNUI
- bei RSSI die Einheit nur senden, wenn auf der Setup-Page konfiguriert (wie bei LGW#temp, LGW#hum, LGW#pres).
- anstatt "page 0" die Seite LGW#main setzen.
- LGW#ver und LGW#up senden
- die Umschaltung auf die main page funktionierte nur, wenn auch ein OLED angeschlossen ist.
- uptime ohne Leerzeichen senden und die Sekunden weglassen
Wichtig
Spielt mal die V1.26 nicht auf, zumindest wenn ihr PCA301 verwendet
Ich habe den Verdacht, dass ich PCA301 in der 1.26 kaputt gemacht habe.
Muss ich aber noch genauer untersuchen.
Zitat von: HCS am 13 Februar 2017, 10:48:48
Spielt mal die V1.26 nicht auf, zumindest wenn ihr PCA301 verwendet
Ich habe den Verdacht, dass ich PCA301 in der 1.26 kaputt gemacht habe.
Bitte höflich um Entschuldigung. Es ist so.
Sowohl die Praxis als auch der Quellcode sagen übereinstimmend, dass PCA301 nicht mehr funktioniert.
Ich hoffe, dass ich es heute Nacht reparieren kann, dass wir morgen eine 1.27 haben, in der das wieder funktioniert.
Zitat von: PeMue am 10 Februar 2017, 16:44:00
Allerdings macht mich der Unterschied zwischen EC3000 und EMT7110 stutzig :o
Mich auch. Also habe ich jetzt mal selbst akkumuliert.
Die beiden EMT7110 und die EC3000 sind sich bezüglich Kompressorlaufzeiten und Leistung alle drei recht einig.
Nur beim akkumulierten Verbrauch haben sie völlig unterschiedliche Ansichten.
Aus den Plots ermittle ich:
Anzahl Kompressorläufe pro Tag: 24
Dauer eines Kompressorlaufs: 6 Minuten
Mittlere Leistung eines Kompressorlaufs: 165W
Die Messung läuft seit 22 Tagen.
Ergibt, wenn ich selbst akkumuliere: 21,8 kWh
Das deckt sich hervorragen mit den 21,9 bzw. 21,2 kWh der beiden EMT7110 aber nicht mit den 13 kWh der EC3000
Was ist da los?
V1.27
PCA301
PCA301 funktioniert wieder
Ist eingecheckt und wird morgen mit dem FHEM-Update ausgeliefert.
Hab ich es überlesen, oder gibt es irgendwo einen Hinweis wie man das Update auf einem Wemos über WLAN ausführen kann?
Vielen Dank für das Update. Werde es auf meinem Wemos testen. Bleiben die eingestellten Daten bei einem Update bestehen?
ZitatPer FHEM (OTA-Update)Voraussetzungen:Das LGW muss auf der IP-Adresse, die im LaCrosseGateway Modul definiert ist, erreichbar sein
- Es wird kein avrdude benötigt
- Das Attribut "flashCommand" spielt keine Rolle
Die LaCrosseGateway Firmware kann von LaCrosseGateway Device (LaCrosseGateway Modul) aus mit
set myLaCrosseGateway flash
Zitat von: gloob am 13 Februar 2017, 22:11:48
Bleiben die eingestellten Daten bei einem Update bestehen?
Ja
Gibt es eine Möglichkeit die Werte aus der Statusnachricht als readings zu erhalten?
RAWMSG OK VALUES LGW 275241 UpTimeSeconds=73035,UpTimeText=0Tg. 20Std. 17Min. 15Sek. ,WIFI=HasenpupsExtreme,ReceivedFrames=56837,FramesPerMinute=49,RSSI=-59,FreeHeap=18648,LD.Min=0,LD.Avg=0,LD.Max=24,OLED=none
Zitat von: gloob am 15 Februar 2017, 14:53:43
Gibt es eine Möglichkeit die Werte aus der Statusnachricht als readings zu erhalten?
Ja. Das Attribut "kvp" auf "readings" setzen
Vielen Dank. Die ReceivedFrames gibt es aber nicht oder?
Zitat von: gloob am 15 Februar 2017, 15:04:05
Vielen Dank. Die ReceivedFrames gibt es aber nicht oder?
Ich befürchte, dass ich die schlicht vergessen habe. Kann ich aber noch einbauen.
Habe das attr auf kvp gesetzt. Bis jetzt wurden aber keine readings angelegt. Auf der setup Page ist kvp auch aktiviert und auf 300 Sekunden eingestellt.
Gesendet von meinem SM-T560 mit Tapatalk.
Alles zurück......
Habe die Werte als reading direkt in den gateway readings erwartet. Die werden aber im keyvalueprotokoll angelegt.
Wäre es möglich die readings direkt ins gateway reading zu schreiben.?
Gruß Sascha
Dann setze das attr kvp auf "readings"
Zitat von: gloob am 15 Februar 2017, 15:21:06
Dann setze das attr kvp auf "readings"
Habe ich. Die readings werden im device keyvalueprotokoll angelegt und nicht im device LaCrosse gateway.
Gesendet von meinem SM-T560 mit Tapatalk
Also ich habe gerade bei mir folgendes ausgeführt:
attr myLaCrosseGateway kvp readings
und seitdem habe ich folgende readings im Gateway:
FramesPerMinute
RSSI
UpTime
initialized
Das KVP device habe ich danach einfach gelöscht.
NAME LCG NR 323 PARTIAL RAWMSG OK 9 5 1 4 131 106 STATE initialized TIMEOUT 0.5 TYPE LaCrosseGateway model [LaCrosseITPlusReader.Gateway.1.27 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) {IP=192.168.2.150}] 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-02-15 15:07:16 state initialized Attributes: devStateIcon initialized:WLAN_Status.1 disconnected:WLAN_Status.0 kvp readings room 99_receiver usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
Bei mir leider nicht
Gesendet von meinem SM-T560 mit Tapatalk
Zitat von: sash.sc am 15 Februar 2017, 15:31:44
Bei mir leider nicht
Seltsam.
Es gibt auch noch das Attribut "ownSensors", das man auf "readings" setzen kann (falls man einen BMP180, BME280, ... am LGW dran hat)
Funktioniert das?
So, habe jetzt mal etwas genauer hingeschaut.
Das alte KeyValueProtokoll war noch von gestern. Ich habe das LCG von USB auf WLAN umgestellt. Danach wurde das KVP nicht mehr im Log geschrieben.
Ich habe auch festgestellt, dass seit ca. 1,5h nix mehr in FHEM empfangen wurde.
Das habe ich an der LCG Time in den Internals gesehen.
Habe dann im LOG des LCG nachgeschaut. Dort werden fleißig Daten fast im Sekundentakt empfangen !!!
Wie gesagt, aber nix in FHEM. Sah ich auch an den Temp.Sensoren !!!
Habe das LCG gelöscht und einfach nochmal angelegt !!!
Jetzt läuft es, warum auch immer !!!!!
Ich weiß auch nicht, was strubbelig gewesen ist. Ich habe das Gateway von USB auf WLAN umgestellt, weil ich jetzt zum WE hin einen kleinen Umbau am RASPI machen werde, und 2. funktionierte über WLAN das FW Update.
Über USB ging es nicht.
2017.02.14 20:50:34 1: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 reappeared (LCG_S)
2017.02.14 20:50:31 1: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 disconnected, waiting to reappear (LCG_S)
sh: 1: ./FHEM/firmware/esptool.py: Permission denied
2017.02.14 20:48:15 1: CUL_WS UNDEFINED temp sensor detected, code 8
sh: 1: ./FHEM/firmware/esptool.py: Permission denied
sh: 1: ./FHEM/firmware/esptool.py: Permission denied
2017.02.14 20:38:50 3: Opening LCG device 192.168.2.150:81
2017.02.14 20:27:19 1: CUL_WS UNDEFINED unknown sensor detected, code 8
2017.02.14 20:20:26 3: UWZ Unwetterzentrale: Run.964 Done fetching data
Auszug aus dem LOG. habe mir die Rechte angeschaut, von esptool.py. Passt soweit alles. Schreib/Lesen gesetzt und FHEM und Dialout.
Gruß
Sascha
Habe da noch ne Frage.
Wie kann man diverse Devices auf ignore setzen?
Bekomme das Log voll mit Meldungen
2017.02.18 17:23:55 3 : LaCrosse: Unknown device 32, please define it
2017.02.18 17:24:16 3 : LaCrosse: Unknown device 32, please define it
2017.02.18 17:24:37 3 : LaCrosse: Unknown device 32, please define it
2017.02.18 17:24:47 3 : LaCrosse: Unknown device 32, please define it
Gruß und Danke
Sascha
Zitat von: sash.sc am 15 Februar 2017, 16:54:47
Auszug aus dem LOG. habe mir die Rechte angeschaut, von esptool.py. Passt soweit alles. Schreib/Lesen gesetzt und FHEM und Dialout.
Gib mal noch execute dazu.
Zitat von: sash.sc am 18 Februar 2017, 17:26:55
Wie kann man diverse Devices auf ignore setzen?
Da fällt mir aktuell nichts zu ein.
Ich müsste wohl ein ignoreDeviceIDs Attribut erfinden, in dem man IDs, die man ignorieren will (in deinem Beispiel 32), angeben kann.
Zitat von: HCS am 18 Februar 2017, 18:34:44
Gib mal noch execute dazu.
sollte so passen, oder ???
Mit dem ignore hätte was ..... ! 8)
Zitat von: sash.sc am 18 Februar 2017, 20:17:05
sollte so passen, oder ???
War das schon so oder ist es jetzt so und funktioniert.
Falls es nicht geht: ruf mal esptool.py auf der console auf, ob es da geht.
sollte so passen, oder ???
Mit dem ignore hätte was ..... ! 8)[/quote]
Habe es in die Wunschliste geschrieben.
Hatte bei der Installation des esptool.py direkt die entsprechenden Rechte vergeben !
Ich hatte das LCG 1x als USBStick und 1x WLAN Gateway angelegt. Da hatte ich beim umstellen auf WLAN ja ein paar Probleme gehabt.
Musste das LCG als WLAN receiver löschen und neu anlegen.
Danach funktionierte das "set LCG flash" ohne Probleme.
Danke für die Aufnahme des Ignore in die Wunschliste !!
Gruß
Sascha
Kurze Frage, was ist dieses KeyValureProtocol? Ich bekomme da immer Meldungen und auf der GUI des LGW kann man ja auch eine identity einstellen.
/Daniel
Zitat von: ext23 am 19 Februar 2017, 09:07:55
Kurze Frage, was ist dieses KeyValureProtocol? Ich bekomme da immer Meldungen und auf der GUI des LGW kann man ja auch eine identity einstellen.
Das LGW sendet seine Statusinformationen (FramesPerMinute, RSSI, UpTime, usw.) als KeyValue Paare an FHEM.
Das LaCrosseGateway-Modul in FHEM kann diese Informationen entweder als Readings darstellen oder an eine Instanz von einem KeyValueProtocol-Modul weitergeben () je nachdem, wie das Attribut "kvp" gesetzt ist, dass man sie dort als Readings hat.
Die KV-Identity, die man im LGW einstellt, ist die ID dieser Daten, mit der dann in FHEM (von AutoCreate) eine KeyValueProtocol Instanz angelegt wird.
Das KeyValueProtocol-Modul ist ein universelles Modul, das auch andere Module nutzen können, um nach einem einheitlichen Schema Readings zu erzeugen, ohne dass immer ein neues spezialisiertes Modul geschrieben werden muss.
Zitat von: HCS am 07 Februar 2017, 17:51:27
... oder noch ein zwei Monate (+x) warten auf die auf den ESP32 portierte Version, die wird vermutlich zwei bridges nativ am ESP32 können, ohne dass man einen SC16IS750 benötigt.
Wäre der https://www.itead.cc/wiki/PSH-C32 was zum probieren? Oder willst Du auf ein Breakout Board setzen?
Gruß PeMue
Zitat von: PeMue am 21 Februar 2017, 09:47:39
Wäre der https://www.itead.cc/wiki/PSH-C32 was zum probieren? Oder willst Du auf ein Breakout Board setzen?
Da habe ich noch keine so genau überlegte Meinung dazu.
Aber eigentlich dachte ich, dass wie mit dem 8266 bisher optional:
- ESP-32S + Beschaltung drum rum
- Eins der Breakouts (das "SparkFun ESP32 Thing" ist aktuell mein Liebling -> https://www.sparkfun.com/products/13907)
Den PSH-C32 muss ich mir mal anschauen. Scheint aber ganz interessant, weil er scheibar die erforderlichen PullUps/Downs schon drauf hat.
Hallo,
ich habe die LGW Variante von Locutus mit einem Display und BME280 in Betrieb
und habe den Luftdruck Messwert jetzt mit dem neuen Modul von mahowi an WU angebunden.
s.a. https://forum.fhem.de/index.php/topic,65587.0.html (https://forum.fhem.de/index.php/topic,65587.0.html)
Dabei bin ich darauf gestoßen, dass die Kurven bei Wunderground ziemlich grob aufgelöst sind.
Das kommt m.E. daher, dass
A) Ein Rundungsfehler im Modul WUup war, (ist mittlerweile optimiert) und
B) Das pressure Reading (gleiches gilt für humidity) des BME280 als int abgespeichert wird.
zumindest habe ich das nach Sichtung der Quellcodes BME280.h, DisplayValues.h in meiner laienhaften Art so interpretiert.
Das kann ja auch durchaus sinnvoll sein, weil die Messung sowieso nicht besonders genau ist und so kein Speicherplatz verschwendet wird.
Trotzdem sei die höfliche Nachfrage gestattet, die Auflösung zukünftig irgendwann zu erhöhen, falls nichts anderes dagegen spricht. ;)
Herzlichsten Dank!
Zitat von: Lucky2k12 am 23 Februar 2017, 20:44:30
Trotzdem sei die höfliche Nachfrage gestattet, die Auflösung zukünftig irgendwann zu erhöhen, falls nichts anderes dagegen spricht. ;)
Es spricht einiges dagegen.
Es macht keinen Sinn, die Auflösung höher als die Genauigkeit zu machen. Das spiegelt bestenfalls falsche Tatsachen vor.
Und das Datenblatt von Bosch sagt:
Humidity: Absolute accuracy +- 3% rH
Pressure: Absolute accuracy +- 1 hPa
Und um das zu tun, müsste dann auch noch das Protokoll zwischen Sketch und FHEM geändert werden.
Mit allen Konsequenzen für alle Sketche und Module, die es gibt und entstehenden Inkompatibilitäten zwichen alten und neuen Versionen dieser.
Sorry.
Ok, das leuchtet mir ein.
Danke für die ausführliche Antwort!
LaCrosseGateway Modul
OTA upload und Nextion upload
Auf nicht blockierend umgebaut
Filter Attribut
Ermöglicht es, einen Filter für die eingehenden Daten zu definieren.
Der Filter sitzt direkt zu Beginn der Verarbeitung, bedeutet, dass weggefilterte Daten sich verhalten, als ob sie nie von einem Sensor gesendet worden wären.
Der Filter ist eine regex.
Um auf unterschiedliche Typen von Sensoren (LaCrosse, EC3000, ...) zu filtern, muss man die entsprechende Kennung verwenden.
xx ist die ID des Sensors.
- LaCrosse sensor: OK 9 xx
- EnergyCount 3000: OK 22 xx xx
- EMT7110: OK EMT7110 xx xx
- LevelSender: OK LS xx
Beispiel: set lgw filter ^OK 22 117 196|^OK 9 49
Filter den LaCrosse Sensor mit der ID "49" und die EC3000 mit der ID "117 196"
Die IDs sind Dezimal anzugeben, genau so, wie sie auch im FHEM-Log stehen.
Statuswerte
Es werden nun auch readings für ReceivedFrames, FreeHeap und OLED erzeugt.
Das FHEM-Update liefert das ab morgen dann aus.
V1.28
Setup page
Die Option für einen SC16IS750 clone wurde entfernt.
Zitat von: HCS am 26 Februar 2017, 16:27:13
Die Option für einen SC16IS750 clone wurde entfernt.
...und ich bin Schuldig :-\ ;)
Habe ein LaCrosseGateway auf NodeMCU-Basis hier am Start zusammen mit zwei RFM69 für LaCrosse und PCA. Dazu einen BME280 über I2C.
Über das KeyValue-Protokoll kommen die Daten des BME280 auch sauber rein. Temperatur, Feuchte und Luftdruck erscheinen in den "Readings".
Frage: Warum nur "T: xxx H: yyy" im Feld STATE und dem DeviceOverview erscheinen tut, und nicht auch ein "P: zzz"?
Ist das gewollt? Mach ich was falsch?
Gruß,
--connaisseur
PS: Ein BMP180 zeigt das analoge Verhalten, nur das der natürlich kein "H: yyy"-Wert haben kann.
Zitat von: connaisseur am 01 März 2017, 20:32:26
Über das KeyValue-Protokoll kommen die Daten des BME280 auch sauber rein. Temperatur, Feuchte und Luftdruck erscheinen in den "Readings".
Die Werte des BME280 kommen nicht per KeyValue-Protokoll rein sondern so, als ob es ein LaCrosse-Sensor wäre.
Zitat von: connaisseur am 01 März 2017, 20:32:26
Mach ich was falsch?
Geht mit:
attr <device> stateFormat T: temperature H: humidity P:pressure
Danke!
Als Anfänger mit FHEM wieder was dazu gelernt. Funktioniert nun.
Hallo,
ich nutze das LGW nun schon ein paar Tage, aber mir ist aufgefallen, dass nach einiger Zeit alle EC3000 für ein paar Stunden ausfallen. Wartet man noch länger sind diese ganz weg. Nach einem reboot des LGW kommen diese sofort wieder, ist das bekannt?
Ich nutze PCA301 und EC3000
[LaCrosseITPlusReader.Gateway.1.25 (1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 r:20000) + (3=RFM69 f:868300 r:8842) {IP=192.168.0.48}]
/Daniel
Zitat von: ext23 am 02 März 2017, 11:10:37
ich nutze das LGW nun schon ein paar Tage, aber mir ist aufgefallen, dass nach einiger Zeit alle EC3000 für ein paar Stunden ausfallen. Wartet man noch länger sind diese ganz weg. Nach einem reboot des LGW kommen diese sofort wieder, ist das bekannt?
Da habe ich keinerlei Probleme. Siehe Anhang, die letzten 5 EC3000-Tage.
Ich habe PCA301, EC3000 und EMT7110 laufen, aktuell sogar für eine Vergleichsmessung, weil ich rausbekommen will, wem von denen ich eigentlich trauen kann :)
Kannst ja mal auf die 1.27 updaten, auch wenn ich nichts wüsste, was ich seit 1.25 geändert hätte, das das verbessert.
Mhh komisch, dann sollte ich mal ein anderes radio Modul benutzen. Nicht das eins irgendwie ein Problem hat.
Danke.
/Daniel
Zitat von: ext23 am 02 März 2017, 12:51:08
Mhh komisch, dann sollte ich mal ein anderes radio Modul benutzen. Nicht das eins irgendwie ein Problem hat.
Ich will jetzt aber ein Software-Problem, das nur in bestimmten Situationen auftritt, auch nicht völlig ausschließen.
Ich habe mein drei-RFMiges LGW so initialisiert:
3#1m 25#1t 20000#2r 3,868960,120i 220h 0a vKannst ja mal auf 1.27 gehen und ein anderes Radio verwenden.
Wenn das nicht hilft, dann müssen wir halt irgendwie weiter forschen.
Gut dann werde ich erst mal ein FW Flash machen. Die EC3000 brechen jetzt wirklich alle Nase lang weg. Als wenn da was stirbt.
Aber mit dem CURL klappt das irgendwie nicht:
root@server:/opt/fhem/FHEM/firmware# curl --http1.0 -# -o output.txt -H "Content_Type:multipart/form-data" -F "file=./JeeLink_LaCrosseGateway.bin; filename=firmware.bin" http://192.168.0.48/ota/firmware.bin
######################################################################## 100,0%
root@server:/opt/fhem/FHEM/firmware# cat output.txt
OTA update finished
root@server:/opt/fhem/FHEM/firmware#
Oder muss das Teil Stromlos gemacht werden?
/Daniel
Hallo Daniel,
willst Du das LGW neu flashen? Das geht aus FHEM:
set <LGW> flash
Die Firmware wird immer mit dem aktuellen FHEM Update ausgeliefert.
Gruß Peter
Nee geht nicht weil ich das per LAN UART Brücke dran habe. Daher wollte ich das per curl auf die WLAN IP machen. Das WLAN ist sonst aus.
Oder geht das etwa auch so?!?
/Daniel
Über USR-TCP geht überhaupt nicht.
-> per USB anschließen zum Flashen
OK also ist das curl Zeugs obsolet was in dem Wiki steht ja?
Mhh gut dann lass ich das, das Teil ist eingebaut da komm ich so schnell nicht mehr rann ;-) Das wird ein längeres Projekt dann.
/Daniel
WLAN anschalten, flashen, WLAN ausschalten?
curl geht für den externen Prozessor ...
Gruß PeMue
Das curl Zeugs geht, wenn das LGW per WiFi angebunden ist.
Ich hatte es extra hier geschrieben: https://forum.fhem.de/index.php/topic,45594.msg575426.html#msg575426
Zitat von: PeMue am 02 März 2017, 21:22:08
WLAN anschalten, flashen, WLAN ausschalten?
Aber wie bekommt man es ohne web frontend an?
Wlan ist ja an, sonst würde das ja mit curl nicht gehen, gut geht auch so nicht ;-)
Naja dann richte ich das Teil mal temporär mit der WLAN IP unter FHEM ein und versuche es so zu flashen.
/Daniel
Zitat von: HCS am 02 März 2017, 21:24:55
Das curl Zeugs geht, wenn das LGW per WiFi angebunden ist.
Ja doch, ist es doch ;-) sonst hätte ich doch nicht die Antwort das OTA erfolgreich war oder ;-) Nur ist danach die FW nicht drin...
Ist 192.168.0.48 die IP vom USR oder vom WiFi?
48 ist die WLAN IP, der USR Terminal Server hat die 72 und mit der 72 ist das Teil auch unter FHEM registriert.
/Daniel
Und WLAN kann man doch per raw abschalten und nach einem Neustart ist es doch wieder an.
/Daniel
Ich glaube ich hab den Fehler, das @ ist wichtig nach file=... das habe ich natürlich gelöscht...
root@server:/opt/fhem/FHEM/firmware# curl --http1.0 -# -o output.txt -H "Content_Type:multipart/form-data" -F "file=@./JeeLink_LaCrosseGateway.bin; filename=firmware.bin" http://192.168.0.48/ota/firmware.bin
######################################################################## 100,0%
root@server:/opt/fhem/FHEM/firmware# cat output.txt
Start receiving 'firmware.bin'
Firmware size: 442272
Rebooting ESP8266 ...
OTA update finished
root@server:/opt/fhem/FHEM/firmware#
Kaum macht man es richtig .....
"Firmwaredateiname (file=) und die IP-Adresse muss entsprechend angepasst werden."
Das sollte man im Wiki dann mal anpassen bei der nächsten Runde.
/Daniel
Zitat von: ext23 am 02 März 2017, 21:43:00
Ich glaube ich hab den Fehler, das @ ist wichtig nach file=... das habe ich natürlich gelöscht...
Du machst aber auch Sachen ...
Ist mir in dem ersten Post aber auch nicht aufgefallen.
Meldet es sich jetzt mit 1.27 als Version?
LaCrosseGateway V1.28 lgw01 (192.168.0.48)
Na dann bin ich ja mal gespannt. Aber ich glaube an keinen Software Fehler, ich vermute mal das ein Radio spinnt. Das Verhalten ist komisch und es lief ja nun durch seit vielen Tagen.
/Daniel
Zitat von: ext23 am 02 März 2017, 21:47:47
LaCrosseGateway V1.28 lgw01 (192.168.0.48)
Klar, 1.28
Mann, jetzt habe ich auch noch vergessen, was die aktuelle Version ist, die ich aktuell draußen habe :o :o
Ich gehe jetzt besser ins Bett ;D ;D
Gute Idee, ich auch, sonst geht noch was schief heute ;-)
Danke.
/Daniel
Ihr geht zu früh in's Bett... ;D
Nach einen Update auf FHEM 5.8 habe ich reichlich folgende Meldungen im Log..
192.168.0.28:81 reappeared (LaCrosseGateway)
Das LGW bleibt im Status opened, wechselt aber nicht auf initialized
Habe dann schnell auf die Version 1.28 upgedatet - brachte aber keine Verbesserung.
Mein FHEM im Status 5.7 läuft noch problemlos mit dem selben LGW.
LG
Holger (der jetzt auch in's Bett geht) :D
Zitat von: Omega am 02 März 2017, 23:53:43
Ihr geht zu früh in's Bett... ;D
Hättest Du Dir die 24/7 Lizenz der LGW Software gegönnt, wäre Dir das nicht passiert ;D ;D ;D
Zitat von: Omega am 02 März 2017, 23:53:43
Ihr geht zu früh in's Bett... ;D
Und wenn jemand keinen Priority-Wartungsvertrag hat, verlasse ich das Bett auch nicht noch mal ;D ;D
Aber mir ist kein generelles "5.8-Problem" bekannt. Meine sind alle auf dem aktuellen Trunk-Stand ohne Probleme.
Hilft ein?
- set myLGW connect
- set myLGW reboot
- FHEM Neustart
Wie ist das timeout Attribut gesetzt?
Guten Morgen,
@HCS: Also kurzer Status:
Ich habe jetzt anstelle von Radio2 das Radio3 auf EC3000 initialisiert, aber selbes Verhalten, es läuft ein paar Minuten dann sind alle EC3000 tot.
Mir ist aber eins aufgefallen, wenn ich auf der WebGUI des LGW das Log betrachte sehe ich immer noch die Logs der EC3000 mit einem aktuellen Zeitstempel, aber nur ein paar mal! (Obwohl FHEM seit Stunden nichts mehr anzeigt) Danach kommen keine neuen Einträge mehr. Als wenn der das aus irgend einem Buffer holt oder so, ka.
Können wir das irgendwie noch weiter untersuchen? Gibt es einen Debug Mode? Kann ich die Logs an einen Syslog Server schicken lassen von dem LGW?
Du machst ja in der Firmware keine zyklischen Schreibvorgänge auf dem ESP Flash so das da eventuell der Speicher oder so stirbt?
/Daniel
Zitat von: ext23 am 03 März 2017, 08:30:45
Mir ist aber eins aufgefallen, wenn ich auf der WebGUI des LGW das Log betrachte sehe ich immer noch die Logs der EC3000 mit einem aktuellen Zeitstempel, aber nur ein paar mal! (Obwohl FHEM seit Stunden nichts mehr anzeigt) Danach kommen keine neuen Einträge mehr. Als wenn der das aus irgend einem Buffer holt oder so, ka.
Der Zeitstempel wird vom web frontend hinzugefügt, weil das LGW keine Uhrzeit kennt.
Und ja, es gibt einen Buffer, in dem das LGW (glaube) 40 Einträge (nicht die letzten sondern die ersten 40 nicht abgeholten) puffert, hauptsächlich, um den Boot-Vorgang sehen zu können, auch wenn man erst später auf die Log-Seite geht.
Alles OK so weit.
Zitat von: ext23 am 03 März 2017, 08:30:45
Können wir das irgendwie noch weiter untersuchen?
Ich glaube, ich kann es jetzt untersuchen. Habe es gerade hin bekommen, dass mir das auf genau einem Test-LGW auch passiert ist.
Nach einigen Minuten war plötzlich eine Weile kompletter Stillstand und dann hat der Watchdog vom Core den ESP8266 neu gestartet.
Und das Log nach dem Neustart sagt, dass er zuletzt mit einer "Fatal exception:29" gestorben ist.
Danach hat es dann vier Minuten funktioniert und dann den EC3000 Betrieb eingestellt, der Rest lief aber korrekt weiter.
Ich versuche mal rauszubekommen, was bei dem LGW die Besonderheit ist, weil auf meinen anderen geht das problemlos.
Kannst Du mir mal noch eine Hardcopy der "Hardware Page" vom LGW (nachdem es von FHEM initialisiert wurde) anhängen?
Und noch was könntest Du probieren: wenn keine EC3000 Daten mehr kommen, dann auf der Log Page ein
17241#3r 20000#3rsenden (Command: ... [Senden]) und schauen, ob danach wieder EC3000 Daten kommen.
3r = Radio #3, wenn Du ein anderes verwendest, dann 2r oder 1r
Was ein Sch... Fehler :o >:(
08:44:52: OK 22 122 228 1 186 120 34 1 109 212 123 0 2 244 62 0 0 127 220 0 0 [7A E4 78 22 00 00 D4 7B 00 00 00 09 8A B4 73 00 00 7F DC 01 41 70 24 98 02 A6 A8 BA 04 1B A0 00 00 00 02 16 D0 00 02 75 77]
08:44:52: OK 22 117 196 2 4 34 231 2 3 255 215 0 1 148 0 0 105 1 95 3 0 [75 C4 22 E7 00 00 FF D7 00 00 00 06 31 42 E9 00 69 01 5F 47 45 34 FB BF 4F 51 84 F4 B9 20 40 00 00 00 01 20 30 38 0B 81 27]
08:44:52: OK 22 124 168 0 15 178 24 0 15 177 254 0 0 21 167 3 0 16 197 3 0 [7C A8 B2 18 00 00 B1 FE 00 00 00 01 30 7E 3C 03 00 10 C5 57 B7 E5 9E 8C 5A 79 C5 9F 0C 00 F0 00 00 00 00 00 F0 38 02 E9 47]
08:44:55: OK 22 123 216 1 37 195 104 1 37 174 76 0 0 105 23 0 44 0 62 0 0 [7B D8 C3 68 00 00 AE 4C 00 00 00 05 C5 DE BD 00 2C 00 3E 44 E3 54 5F 1B 45 EF 24 5F 15 12 50 00 00 00 00 12 50 08 0B F6 C7]
usw.
usw.
bis:
08:52:57: OK 22 117 196 2 4 36 204 2 4 1 188 0 1 148 1 0 105 1 95 3 0 [75 C4 24 CC 00 00 01 BC 00 00 00 06 31 56 B2 00 69 01 5F 47 59 04 FB BF 4F 51 84 F4 B9 20 40 00 00 00 01 20 40 38 0F CE F7]
08:53:02: OK 22 117 196 2 4 36 209 2 4 1 193 0 1 148 1 0 103 1 95 3 0 [75 C4 24 D1 00 00 01 C1 00 00 00 06 31 56 E6 00 67 01 5F 47 59 34 FB BF 4F 51 84 F4 B9 20 40 00 00 00 01 20 40 38 01 5A F7]
08:53:05: OK 22 123 216 1 37 197 82 1 37 176 54 0 0 105 24 0 45 0 62 0 0 [7B D8 C5 52 00 00 B0 36 00 00 00 05 C5 E7 66 00 2D 00 3E 44 EC 04 5F 1B 45 EF 24 5F 15 12 50 00 00 00 00 12 50 08 0C 73 67]
08:53:07: OK 22 117 196 2 4 36 214 2 4 1 198 0 1 148 1 0 104 1 95 3 0 [75 C4 24 D6 00 00 01 C6 00 00 00 06 31 57 1A 00 68 01 5F 47 59 64 FB BF 4F 51 84 F4 B9 20 40 00 00 00 01 20 40 38 04 A9 47]
Danach nichts mehr von EC3000 aber alle LaCrosse-Sensoren und auch die EMT7110 usw. kommen noch
Hardware Setup siehe Anhang.
Und ja, wenn ich das Kommando absetze läuft EC3000 wieder.
Aber es lief ja mit der 1.25er Tagelang ohne Ausfälle. An dem LGW habe ich derweil nichts gemacht mir ist nur aufgefallen das zuerst zwischendurch eine Zeit lang kein Signal kam (das fällt ja auf wenn es bei allen 3 EC3000 parallel passiert) und irgendwann ging es dann gar nicht mehr ohne ein Reboot. Läuft da irgend ein Counter über der durch den Reset nicht zurückgesetzt wird oder so? Zumindest wurde das Problem ja immer schlimmer. Aber macht ja auch kein Sinn wenn dieselbe FW auf den anderen Dingern bei dir läuft. Mhh naja, aber du kein Stress, also wenn es mal nicht geht ist es mir im Prinzip Hupe, jetzt ist erst mal Wochenende...
/Daniel
Zitat von: ext23 am 03 März 2017, 09:23:45
aber du kein Stress, also wenn es mal nicht geht ist es mir im Prinzip Hupe, jetzt ist erst mal Wochenende...
Nö, Stress ist hier erforderlich.
Ihn habe vor der Waschmaschine und dem Trockner jeweils eine EC3000 für den Aus/Arbeitet/Fertig Status.
Das läuft das seit Monaten ohne Probleme.
Aber wenn es da auftreten würde, dann macht meine Frau einen Supportfall auf, der es in sich hat ;D ;D
Ich versuche mal, der Sache auf die Spur zu kommen.
OK na wenn das so ist. Meine Chefin hat nicht solche hohen SLAs gebucht, also da muss schon mehr ausfallen bis ein emy ausgelöst wird ;-)
Zitat von: ext23 am 03 März 2017, 09:23:45
Aber es lief ja mit der 1.25er Tagelang ohne Ausfälle.
Ja, und ich habe in der 1.26 die SPI-Kommunikation mit den Radios umgebaut, dass es auf auch auf dem ESP32 läuft.
Ich vermute schon, dass ich da das Problem eingebaut habe.
Ist mir nur nicht aufgefallen, weil es genau auf denen LGWs, auf denen ich EC3000 laufen habe, funktioniert.
Kannst ja mal auf die 1.25 zurück gehen und schauen, ob es dann wieder stabil läuft. Die Info würde mir auch weiter helfen.
Nein das ist es ja gerade, das lief tagelang mit der 1.25 und dann sind die Probleme aufgetreten (mit der 1.25). Den Upgrade auf die 1.28 habe ich ja gestern erst gemacht. Also das muss was anderes sein.
/Daniel
Zitat von: HCS am 03 März 2017, 08:10:37
Und wenn jemand keinen Priority-Wartungsvertrag hat, verlasse ich das Bett auch nicht noch mal ;D ;D
Und Deine Frau hat sowohl 24/7 als auc den Priority-Wartungsvertrag!
Na dann sieh mal zu! ::) ::)
Gruss Christoph
Zitat
Hättest Du Dir die 24/7 Lizenz der LGW Software gegönnt, wäre Dir das nicht passiert ;D ;D ;D
Ich bin zwar kein Schwabe, aber einen Wartungsvertrag für eine Software, die ansonsten unglaublich stabil und fehlerfrei läuft....meine Hochachtung dafür an HCS.
,,set connect" und ,,LGW reboot" hatte ich gestern mehrfach probiert – ohne Ergebnis. Aber der FHEM restart hat dann eben das gewünschte Ergebnis gebracht.
Dabei ist mir aufgefallen, das das Reading pressure seit dem 26.01.17 nicht mehr aktualisiert wird (auf dem OLED wird es aber immer angezeigt und nach einem Reboot steht auch der aktuelle Wert im device – aber nie im dazugehörigen Filelog).
Erst nachdem ich das Attribut ,,dew_state absFeuchte 1" (was ja zunächst einmal nicht direkt mit dem LGW zu tun hat) gelöscht hatte, wurde das Reading wieder aktualisiert.
Erst mal ist alles wieder gut
LG
Holger
Zitat von: HCS am 03 März 2017, 08:10:37
Und wenn jemand keinen Priority-Wartungsvertrag hat, verlasse ich das Bett auch nicht noch mal ;D ;D
Zitat von: pc1246 am 03 März 2017, 10:10:04
Und Deine Frau hat sowohl 24/7 als auc den Priority-Wartungsvertrag!
Ja, aber nur solange ich das Bett nicht verlassen habe ;D ;D ;D ;D
Zitat von: HCS am 03 März 2017, 08:10:37
... Aber der FHEM restart hat dann eben das gewünschte Ergebnis gebracht.
Das hatte ich auch schon mal. Es kann wohl passieren, dass in FHEM DevIO ein wenig in Schieflage gerät, was dann zu dem Effekt führt.
Gibt es schon was Neues wegen der EC3000? Ich habe festgestellt, das Signal kommt wieder. Dauert aber eben durchaus mehr als 1 Tag.
Dann eine andere Frage, ich bekomme im FHEM log jetzt ständig aller paar Sekunden: "LaCrosse: Unknown device 11, please define it" Aber im Log vom LGW sehe ich nichts, da ist alles ruhig außer meine Steckdosen.
/Daniel
Zitat von: ext23 am 06 März 2017, 17:36:50
Gibt es schon was Neues wegen der EC3000? Ich habe festgestellt, das Signal kommt wieder. Dauert aber eben durchaus mehr als 1 Tag.
Leider nicht. Das ist ein ganz übles Problem. Es ist nun wohl definitiv so, dass der RFM69 irgend wann aufhört zu empfangen. Wenn man ihn neu initialisiert (das war der "17241#3r 20000#3r" Test), dann läuft er wieder eine Weile.
Warum das passiert und warum es nur auf auf manchen LGW passiert und warum es nur mit EC3000 passiert habe ich aber noch nicht herausgefunden.
Und ich habe zwei LGW, mit exakt gleicher Ausstattung (3xRFM69) und Konfiguration und auf dem einen geht es und auf dem anderen nicht.
Das Problem ist aber auch, dass es auf dem LGW, auf dem ich es nachvollziehen kann, manchmal auch mehr als ein paar Minuten funktioniert.
Das macht die Testerei extrem unhandlich :(
Genug gejammert ;D Ich arbeite an dem Problem, kann aber aktuell aufgrund völliger Ratlosigkeit keine Prognose abgeben.
Zitat von: ext23 am 06 März 2017, 17:36:50
Dann eine andere Frage, ich bekomme im FHEM log jetzt ständig aller paar Sekunden: "LaCrosse: Unknown device 11, please define it" Aber im Log vom LGW sehe ich nichts, da ist alles ruhig außer meine Steckdosen.
Dann wäre ja zu vermuten, dass es nicht vom LGW kommt, sondern von einem anderen Device, das LaCrosse als Client hat.
Hast Du sonst noch was am Laufen (JeeLink, Signalduino, ...)?
Aber es lief bei mir wie gesagt einige Tage sehr gut. Ich habe aber einen EC3000 an eine andere Stelle verfrachtet und das könnte sich decken mit dem Zeitpunkt wo ich die Aussetzer habe. Könnte es sein, dass sich der RFM irgendwie aufhängt wenn er unsaubere Signale empfängt?
Ich hab eben nochmal geschaut, das ist wirklich so. Am 28.02. habe ich einen meiner drei EC3000 an eine Stelle gehangen, die ich würde mal sagen funktechnisch am weitesten entfernt ist von den 3 Geräten. Und exakt ab diesem Tag habe ich auch die Aussetzer.
Btw. ein reinitialize falls zu lange keine Daten komme wäre doch ein Workaround oder?
Wegen dem anderen LaCrosse Gerät muss ich mal schauen, vielleicht der panstamp sonst habe ich ja nur noch CUL und TRX433 dran.
/Daniel
Zitat von: ext23 am 07 März 2017, 12:09:18
Könnte es sein, dass sich der RFM irgendwie aufhängt wenn er unsaubere Signale empfängt?
Das ist recht plausibel, weil das LGW, mit dem ich teste, genau an der Reichweitengrenze von fast allen EC3000 steht.
Guter Hinweis.
Das könnte ich aber testen, muss es nur heute Abend zu den EC3000 hin tragen (das geht remote noch nicht) und schauen, ob es dann nicht mehr auftritt.
Zitat von: ext23 am 07 März 2017, 12:09:18
Btw. ein reinitialize falls zu lange keine Daten komme wäre doch ein Workaround oder?
Ja, das ist die Notlösung. Aber eigentlich würde ich lieber das Problem verstehen und die Ursache beheben als die Symptome zu unterdrücken.
Hi HCS,
Wird Zeit für Dein neues Projekt: fhem Roboter auf ESP32 Basis ;-)
Gruß Arnd
Diverse RasperryPi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, WifiLight ...
Zitat von: RaspiLED am 07 März 2017, 18:01:12
Wird Zeit für Dein neues Projekt: fhem Roboter auf ESP32 Basis ;-)
Nicht mehr nötig, muss nicht in den Keller, habe das Problem wohl gefunden ;D
Ich habe die AGC mit dem rauchenden Colt in der Hand erwischt ;D ;D
Nachdem ich ein paar mal im Zustand "geht nicht mehr" die Register des RFM69 rausgedumpt habe, ist mir aufgefallen, dass er eigentlich noch arbeitet aber in RegLna (0x18) entweder 0x28 oder 0x30 drin steht, was bedeutet, dass die AGC den LNA auf Max gain -36dB bzw. Max gain -48dB gesetzt hat, was bedeutet, dass schon ein heftig starkes Signal kommen muss, dass es da durch geht. Wenn da aber nichts durch kommt, dann bekommt die packet engine nichts und setzt den LNA nicht zurück. Ein Teufelskreis.
Eigentlich sollte RegLna, nachdem ein Paket empfangen wurde, wieder auf 0x08 stehen, da AutoRxRestartOn gesetzt ist.
Scheinbar gibt es den Fall, dass ein Paket nur so halb empfangen wird, die packet engine kein "payload ready" signalisiert und der RFM69 dann in diesem Zustand verbleibt.
Das dürfte auch der Grund sein, warum es manchmal (selten) auch wieder von selbst funktioniert. Ein mal ein Signal, das stark genug ist, und die packet engine hat den LNA wieder auf gemacht und es funktioniert wieder so lange, bis sich der RFM69 die Tür zuhaut.
Ich habe jetzt testweise mal die AGC deaktiviert, damit lief es die ganze Nacht über konstant.
Die AGC zu deaktivieren ist zwar auch nicht genau das, was ich mir vorstelle, aber vieleicht bekomme ich ja noch raus, warum der RFM69 sich mit aktiver AGC das antut.
@ext23: probier mal bitte mit der angehängten Test-Version, ob das bei Dir auch funktioniert.
Ach ja: wenn jemand
fundierte Erfahrungen mit der AGC auf dem RFM69 hat, dann her damit.
Zitat von: HCS am 08 März 2017, 07:57:01
Ich habe die AGC mit dem rauchenden Colt in der Hand erwischt ;D ;D
AGC = Automatic Gain Control?
Zitat von: HCS am 08 März 2017, 07:57:01
Ach ja: wenn jemand fundierte Erfahrungen mit der AGC auf dem RFM69 hat, dann her damit.
Das Thema wurde hier https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/rfm69-reception-issues-due-to-broken-agc/ schon mal diskutiert, wie fundiert das ist, kann ich nicht beurteilen ...
Zitat von: PeMue am 08 März 2017, 09:47:13
wie fundiert das ist, kann ich nicht beurteilen ...
Ja, der spricht über "mein" Problem. Warum hast Du das gefunden und ich nicht. OK, wenn man erst mal das Problem kennt, kennt man auch die keywords, die man suchen muss. :)
Und er hat dann auch die AGC abgedreht und "max gain" konfiguriert, so wie ich gestern Abend.
Und das LGW empfängt die fünf EC3000 immer noch, seit 19 Stunden 8)
Ich stimme da sehr mit ihm überein, dass ein schrottig empfangenes Paket (das muss noch nicht mal von einer EC3000 gekommen sein) die AGC runter zieht und da stehen lässt.
Eigentlich müsste die packet engine den LNA gain nicht nur dann zurücksetzen, wenn der payload abgeholt wurde, sondern auch, wenn sie ein Paket verworfen hat.
Ich bin recht sicher, dass es sie auch im zweiten Fall meistens macht, aber scheinbar gibt es Fälle, in der sie es vergisst.
Danke für den Link, hatte schon Angst, dass ich mir nur einbilde, dass der RFM69 ein Fehlverhalten an den Tag legt :)
Ich muss nur noch testen, was jetzt passiert, wenn das LGW direkt neben einer EC3000 steht. Weit weg geht super ...
OK ich hab die FW mal aufgespielt. Schauen wir mal. Sag mal diese initialization, kann man die nicht auch speichern im LGW? Wenn ich den LGW neu starte schnallt das FHEM manchmal nicht und schickt somit die init strings nicht neu. Oder es dauert einfach nur lange.
/Daniel
Zitat von: ext23 am 08 März 2017, 11:28:53
Oder es dauert einfach nur lange.
Hast Du das timeout Attribut vom LaCrosseGateway device gesetzt?
Ich hatte mich mal ohne Erflog daran versucht, dass man die initCommands alternativ auch auf der Config-Page des LGW definieren kann, habe es aber nicht zum Laufen bekommen und auf das ESP32 LGW vertagt.
Zitat von: HCS am 08 März 2017, 12:07:25
Hast Du das timeout Attribut vom LaCrosseGateway device gesetzt?
Danke, das war die fehlende Info für mich. Mit timeout und watchdog wird nun mein LGW nach Neustart wieder richtig initialisiert :)
Für mich auch ja ;-) gleich mal auf 60 gesetzt.
Zitat von: HCS am 08 März 2017, 07:57:01
@ext23: probier mal bitte mit der angehängten Test-Version, ob das bei Dir auch funktioniert.
Sieht gut aus, keine Ausfälle bis jetzt.
/Daniel
V1.29
EC3000
Das Problem, dass EC3000 bei bestimmten Empfangssituationen ausgestiegen ist, wurde behoben.
Moin zusammen - lange nix mehr geschrieben - das soll sich nun ändern..
Ich hatte ja mal das Outdoor LCG mit der Haribo Gehäuse Variante ersetzt und war nun endlich mal dazu gekommen mich um das 'verwirrte' LCG zu kümmern. Was soll ich sagen, es ist infektiös ;)
Ich habe das LCG neu geflasht, ich habe es wie hier (http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/131-loeschen-des-gesamten-flashspeichers) beschrieben gelöscht und nochmal neu geschrieben. Aus mir unerfindlichen Gründen scheint es meine WLAN Zugangsdaten noch zu kennen (oder vielleicht doch nicht?) und meldet sich an der Fritzbox an, bekommt aber keine IP Adresse.
Hat wer einen Tipp für mich was ich verkehrt mache und/oder wie ich das LCG wieder in den Normalbetrieb bekomme?
Zitat von: waschbaerbauch am 14 März 2017, 21:41:49
... und/oder wie ich das LCG wieder in den Normalbetrieb bekomme?
esptool --port COM3 erase_flashDanach ist der ESP8266 in einem Zustand wie bei der Auslieferung, sollte also keinerlei Konfiguration und firmware haben.
Anstatt COM3 halt den passenden Port
Hallo HCS.
Mir ist letzten aufgefallen, nachdem ich das Timeout und den Watchdog über die Attribute festgelegt habe, dass das LCG irgendwann Abends ausgestiegen ist und bis Morgens nicht wieder verbunden wurde.
Nachdem ich beide Atrribute wieder gelöscht habe und das LCG manuell verbunden, läuft die Verbindung wieder stabil, ohne Aussetzter.
Ich habe mich nur gewundert, dass mit Watchdog und Timeout, die automatische Verbindung nicht zustanmde gekommen ist.
Schonmal sowas vorgekommen ?!?!?! Bei irgendwem ??
Gruß
Sascha
Zitat von: sash.sc am 15 März 2017, 17:20:21
Mir ist letzten aufgefallen, nachdem ich das Timeout und den Watchdog über die Attribute festgelegt habe, dass das LCG irgendwann Abends ausgestiegen ist und bis Morgens nicht wieder verbunden wurde.
Welche Werte hatten timeout und watchdog?
Standart Vorgaben. Time out von 60 sec. und watchdog von 300, oder so.
Hatte ich hier im Forum gelesen.... [emoji6]
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 15 März 2017, 17:42:14
Standart Vorgaben. Time out von 60 sec. und watchdog von 300, oder so.
Sollte eigentlich gehen. Da ist mir nichts bekannt.
Zitat von: HCS am 16 März 2017, 21:06:00
Sollte eigentlich gehen. Da ist mir nichts bekannt.
Das LCG blieb dann auf "opened" stehen anstatt auf "initilized" zu gehen.
Zitat von: sash.sc am 16 März 2017, 21:24:40
Das LCG blieb dann auf "opened" stehen anstatt auf "initilized" zu gehen.
das hatte ich auch mal. Nicht reproduzierbar.
Ich denke, das passiert, wenn die Verbindung zum LGW aufgebaut wurde aber die Antwort mit der Initialisierung nicht durch kam.
Dann denkt das LaCrosseGateway-Modul, dass alles gut ist und macht nichts weiter.
Muss mal überlegen, ob nach einer gewissen Zeit "opened" das LGW die Verbindung trennen und neu aufbauen sollte, um einen neuen Versuch zu machen.
Zitat von: HCS am 15 März 2017, 17:10:09
esptool --port COM3 erase_flash
Danach ist der ESP8266 in einem Zustand wie bei der Auslieferung, sollte also keinerlei Konfiguration und firmware haben.
Anstatt COM3 halt den passenden Port
Vielen Dank für den Hinweis! Die ESPTOOL.exe hat bei mir zwar nicht funktioniert, aber sie hat mich auf den richtigen Weg gebracht.
Auf der Suche nach einer aktuellen esptool.exe bin ich über den NodeMCU PyFlasher (https://github.com/marcelstoer/nodemcu-pyflasher/releases/tag/v0.2.0) gestolpert, die .bin, 'Erase flash o yes, wipes all data' und schon hatte ich wieder Zugriff! :)
PS: COM3 war aber korrekt ;)
Zitat von: HCS am 17 März 2017, 19:52:50
das hatte ich auch mal. Nicht reproduzierbar.
Ich denke, das passiert, wenn die Verbindung zum LGW aufgebaut wurde aber die Antwort mit der Initialisierung nicht durch kam.
Dann denkt das LaCrosseGateway-Modul, dass alles gut ist und macht nichts weiter.
Muss mal überlegen, ob nach einer gewissen Zeit "opened" das LGW die Verbindung trennen und neu aufbauen sollte, um einen neuen Versuch zu machen.
Mein Gateway ist gerade auch im Zustand opened.
Ich habe schon einen reboot probiert, aber danach geht es wieder auf opened.
Beim letzten Mal hat nur geholfen, den Strom zu unterbrechen.
Es scheint soweit trotzdem alles zu funktioneren, allerdings geht dann die Verbindung zum CUL sehr viel häufiger (alle paar Minuten) verloren.
Micky
Edith:
Ich habe gestern am FHEM-Server gearbeitet und dabei mal gebootet. Seit dem ist der Status auf Initialized ...
Zitat von: micky0867 am 18 März 2017, 17:16:48
Ich habe gestern am FHEM-Server gearbeitet und dabei mal gebootet. Seit dem ist der Status auf Initialized ...
Ja, so war es bei mir auch. Ich glaube, dass FHEM da in einen Zustand gerät, wo die Kommunikation nicht mehr richtig funktioniert.
Da es aber so gut wie nie auftritt, hatte ich noch keine Chance, es mal genauer zu untersuchen.
Moin HCS
Seit der 1.29 habe ich das Phaenomen auch! Bei mir passiert es reproduzierbar wie es aussieht! Bisher half auch nur ein spannungslos machen des GW, aber ich kann mich gerne als Versuchskaninchen zur Verfuegung stellen.
Kann man eigentlich irgendwie zurueck, sprich finde ich die vorherigen Versionen irgendwo? Das zweite mit 1.25 laeuft konstant durch, auch mit zwei Clients!
Gruss Christoph
Zitat von: pc1246 am 08 April 2017, 17:18:49
Bei mir passiert es reproduzierbar wie es aussieht!
Und was muss man tun, um es zu reproduzieren?
Bei mir tritt das auch mit der 1.29 nicht auf, im Anhang eins meiner LGWs, das ist seit einem Monat up und initialized.
Zitat von: pc1246 am 08 April 2017, 17:18:49
Kann man eigentlich irgendwie zurueck, sprich finde ich die vorherigen Versionen irgendwo?
Angehängt ist die Version 1.25
Meins hat sich vor einigen Tagen wieder aufgehangen. Genauer gesagt nur der cul... War immer nur auf opened, bis ich den Stecker gezogen habe. LGW booten und Server booten haben nix gebracht.
Ich habe die V1.28 und einen BME280 drauf.
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Zitat von: micky0867 am 08 April 2017, 19:55:31
bis ich den Stecker gezogen habe.
Welchen Stecker?
Den Stecker vom Netzteil.
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Zitat von: micky0867 am 08 April 2017, 19:55:31
Genauer gesagt nur der cul... War immer nur auf opened, bis ich den Stecker gezogen habe.
Da würde ich mal stark drauf tippen, dass sich die CUL-Firmware verabschiedet hatte.
Opened hat man, sobaled das CUL device in FHEM den Port vom LGW, den man definiert hat, öffnen kann.
Initalized bekommt man, wenn dort ein CUL geantwortet hat.
Die gleiche Situation hat man z.B. wenn man die Baudrate für den CUL im WebFrontend des LGW falsch eingestellt hat. Man bleibt auf opened, weil man zwar mit der dem Port kommunizieren kann, aber der CUL nichts versteht und nicht antwortet.
Zitat von: HCS am 08 April 2017, 18:20:39
Und was muss man tun, um es zu reproduzieren?
Also ich ziehe den Stecker vom GW, dann connecte ich den CUL neu, und das haelt dann ungefaehr einen Tag! Da der nur so da ist, ist mir das anfaenglich gar nicht aufgefallen.
Ich mach jetzt mal die 1.25 drauf und beobacht. Die 1.29 hebe ich mir auf!
Gruss Christoph
Ah ich sehe gerade, Du redest vom GW, das funktioniert durchgehend, nur der CUL meldet sich ab!
Gruss Christoph
Hier geht es zur Portierung des LGW auf den ESP32: https://forum.fhem.de/index.php/topic,70338.0.html
@pc1246 und @micky0867
Verstehe ich das jetzt richtig, dass bei beiden das Porblem ist, dass der CUL auf opened bleibt aber das LGW korrekt läuft und initialized ist?
Wie schon geschrieben, wenn der CUL opened ist, dann ist der Port auf dem LGW erreichbar aber üblicherweise antwortet der an den ESP8266 angeschlossene CUL nicht.
In dem Fall mal auf dem ProMini des CUL einen Reset drücken, ob es dann wieder funktioniert.
Moin HCS
Genau, der CUL geht irgendwann auf opened, und bleibt dann auch so. Letztendlich hilft nur spannungslos machen! Habe jetzt wieder die 1.25 drauf, lass uns mal bis morgen abend warten! Dann kann ich gerne wieder die 1.29 aufspielen, um das gegenzutesten!
Gruss Christoph
Moin
Kurzer Zwischenstand. Mit der 1.25 bleibt der CUL, bis jetzt, am Leben! Mal sehen, was er heute abend sagt!
Gruss Christoph
Hi,
wo holt sich das Gateway denn seine Zeit her (LaCrosseGateway_TIME)?
Mein's ist ca. 5 Stunden zurück.
Leider auch alles Readings von Devices, die darüber empfangen werden.
Internals:
CFGFN
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF 10.1.1.57:81
DeviceName 10.1.1.57:81
FD 14
LaCrosseGateway_MSGCNT 858
LaCrosseGateway_TIME 2017-04-17 12:28:52
NAME LaCrosseGateway
NR 53764
PARTIAL
RAWMSG OK 9 39 1 4 223 106
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model [LaCrosseITPlusReader.Gateway.1.29 (1=RFM69 f:868300 r:17241) {IP=10.1.1.57}]
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-04-17 12:28:52 state initialized
Helper:
Attributes:
room LaCrosse
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
Hab leider nichts gefunden, wo ich einstellen könnte, bzw. wo es seine Zeit herbekommt.
Cheers
mi.ke
Zitat von: mi.ke am 17 April 2017, 17:48:15
wo holt sich das Gateway denn seine Zeit her (LaCrosseGateway_TIME)?
von fhem.pl TimeNow() und die nimmt die perl time()
Entweder geht die Uhr von deinem FHEM-Server falsch oder die Zeitzone stimmt nicht.
Was bekommst Du, wenn Du in fhem
{TimeNow()}eingibst?
Alles klar.
Vielen Dank, die einfachen Sachen sind manchmal am schwersten.
Die Zeit auf meinem Testsystem geht nach dem Mond.
Sorry für die dummy Frage.
Cheers
mi.ke
Moin zusammen
Wuensche schoene Ostern gehabt zu haben. Also mit der 1.25 bleibt der CUL konstant am Leben! Wenn gewuenscht, kann ich morgen gerne noch einmal die 1.29 zur Verifikation aufspielen!
Gruss Christoph
Zitat von: pc1246 am 17 April 2017, 19:34:15
Also mit der 1.25 bleibt der CUL konstant am Leben!
Seltsam, ich habe ein LGW mit V1.29, das inzwischen 41 Tage uptime hat und über das ein CUL läuft, der immer noch initialized ist und das Log des anhängenden FS20 device hat durchgehend Daten bis heute.
Zitat von: pc1246 am 17 April 2017, 19:34:15
Wenn gewuenscht, kann ich morgen gerne noch einmal die 1.29 zur Verifikation aufspielen!
Ja, das wäre gewünscht. Ich wäre gerne ganz sicher, dass es ein 1.29 Thema ist, bevor ich etwas suche, das ich nicht nachvollziehen kann.
guten morgen,
auch mein LaCrosseGateway hängt sich seit dem ich die V. 1.29 installiert habe in unregelmässigen Abständen auf.
Er steht dann auf Disconnectet. Komme über Web nicht ran auch ein reopen über Fhem funktioniert nicht
Kann nur den Stromstecker abziehen und wieder aufstecken, erst dann lebt er wieder .
Gruß Werner
Zitat von: Intruder1956 am 22 April 2017, 08:48:27
guten morgen
Jetzt ist er nicht mehr so gut ;D ;D
Zitat von: Intruder1956 am 22 April 2017, 08:48:27
auch mein LaCrosseGateway hängt sich seit dem ich die V. 1.29 installiert habe in unregelmässigen Abständen auf.
Er steht dann auf Disconnectet. Komme über Web nicht ran auch ein reopen über Fhem funktioniert nicht
Kann nur den Stromstecker abziehen und wieder aufstecken, erst dann lebt er wieder .
Das scheint zumindest kein generelles Problem zu sein, da ich hier LGWs mit 1.29 habe, die bisher immerhin 45 Tage geschafft haben.
Kannst Du mal den Inhalt der hardware page vom Frontend anhängen, dass ich sehe, was da so dran und drin ist?
Was immer gerne ein Problem ist, ist die Spannungsversorgung. Hat sich außer der LGW-Version sonst noch irgend etwas verändert?
Das ist übrigens ein anderes Problem als das von pc1246, der mir noch sagen wollte, ob sein Problem mit der 1.29 nun wieder auftritt.
Ach ja, mit welcher Version ist das noch nicht aufgetreten?
Hier die gewünschte Seite
LaCrosseGateway V1.29 LaCrosseGateway (192.168.178.71)
Home Setup Hardware OTA-Update Log Help Reboot
ESP8266 present :-) Core: 2_3_0 SDK: 1.5.3(aec24ac9) free heap: 15120 Reset: External System -> Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
WiFi -63 dBm Mode: Station Time to connect: 3.9 s
Radio #1 RFM69 868295 kHz toggle: 20 seconds > 17.241 / 9.579
Radio #2 RFM69 868950 kHz data rate: 6631 kbps
Radio #3 RFM69 868300 kHz data rate: 8842 kbps
Radio #4 ---
Radio #5 ---
SHT75 ---
BME280 OK T=27.6 H=30 P=995 Calibration: T1:28397 T2:27371 T3:50 H1:75 H2:348 H3:0 H4:351 H5:0 H6:30 P1:36418 P2:-10378 P3:3024 P4:6292 P5:-7 P6:-7 P7:9900 P8:-10230 P9:4285 ADC: T=538799 H=28013 P=369688
BMP180 ---
DHT22 ---
LM75 ---
SC16IS750 (0x90) ---
SC16IS750 (0x92) ---
MCP23008 ---
OLED ---
DataPort #1 81 FHEM connected
DataPort #2 82
DataPort #3 83
Serial-bridge #1 ---
Serial-bridge #2 ---
Soft-bridge ---
Nextion ---
Analog port Disabled 4= 3 mV
An der Stromversorgung kann es nicht liegen, habe nichts am System geändert außer Update gemacht.
Das habe ich im Logfile gefunden
2017.04.09 17:41:27 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.11 05:43:27 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.13 00:28:55 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.16 03:02:56 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.18 09:10:09 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.20 01:22:42 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.22 06:26:40 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
Es fällt auf, das er sich alle 2 Tage aufhängt.
gruß Werner
Zitat von: Intruder1956 am 22 April 2017, 10:11:47
Hier die gewünschte Seite
Sieht alles normal aus.
Zitat von: Intruder1956 am 22 April 2017, 10:11:47
Es fällt auf, das er sich alle 2 Tage aufhängt.
Spiel mal die 1.25 drauf, ob es damit wirklich nicht ist:
https://forum.fhem.de/index.php/topic,43672.msg617956.html#msg617956
ok,
1.25 geflasht und werde es beobachten
gruß Werner
Moin,
ich hatte heute mal wieder ein Ausfall nach vielen Tagen. EC3000 wurden nicht mehr empfangen. PCA301 wurden zwar empfangen, aber ich könnte kein Status abfragen oder die Dosen schalten.
Nach einem reboot der LGW lief wieder alles.
/Daniel
Guten morgen.
Habe es jetzt auch im Urlaub gehabt, dass sich das lgw aufgehangen hat. Lief ca. 20 tage ohne probleme.
Habe es gestern gesehen, da uptime bei 14 Stunden stand.
Ist auch die v1. 29 drauf.
Gruß Sascha
Gesendet von dem teuren ding in meiner hand
Moin
Sorry, dass ich mich so lange nicht gemeldet habe. Aber mein Auto ist gestorben, und so habe ich die letzte Woche nur mit Autos verbracht! Spiele jetzt gleich die 1.29 nochmal auf!
Gruss Christoph
Zitat von: PeMue am 25 Oktober 2016, 20:34:39
Ich hatte vor kurzem einen Stromausfall und da waren dann alle meine drei LGWs nicht erreichbar. Ich versuche es mal mit 120 s, dann sollte WLAN wieder oben sein.
Unser Netz scheint recht instabil, heute wieder gegen 13:30 Uhr fast 20 min. der Strom weg. Allerdings waren danach alle LGWs wieder funktionsfähig - dank korrekt eingestelltem Delay.
Gruß PeMue
Zitat von: PeMue am 24 April 2017, 21:57:49
Allerdings waren danach alle LGWs wieder funktionsfähig - dank korrekt eingestelltem Delay.
Das ist gut. Welche Version hast Du drauf?
Zitat von: HCS am 25 April 2017, 07:59:46
Das ist gut. Welche Version hast Du drauf?
Sind alle noch auf der "Uralt"-Version v1.24.
Gruß PeMue
Moin zusammen
Ich denke, dass ich durch Zufall das Problem erkannt habe. Es sieht so aus, dass das Problem dann auftritt, wenn mehrere fhems auf das GW zugreifen. Mein Testsystem ist derzeit nicht am Netzwerk, und die 1.29 laeuft stabil! Werde noch ein wenig warten und dann das Testsystem wieder online nehmen!
Gruss Christoph
moin,
bei mir ist es so, wie ich es diese Woche beobachtet habe
der LGW hängt sich nicht mehr auf mit der 1.25 aber, ich habe jetzt ständig im Logfile folgende Meldung
2017.04.28 06:54:58 3: CUL_433 IT_set: Kueche_Kaffee on
2017.04.28 07:18:59 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:18:59 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:19:01 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:19:02 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:19:24 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:19:24 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:19:26 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:19:27 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:20:18 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:20:21 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:20:24 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:20:24 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:20:29 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:22:32 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:23:13 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:23:13 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:23:16 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:23:16 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:24:04 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:24:04 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:24:07 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:24:08 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:24:14 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:24:16 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:30:00 3: UNIRoll set Bad_Rollo up
2017.04.28 07:30:00 3: UNIRoll set WZ_RollGross up
2017.04.28 07:30:00 3: UNIRoll set Schlaf_Rollo up
2017.04.28 07:30:01 3: UNIRoll set Kueche_Rollo up
2017.04.28 07:30:01 3: UNIRoll set WZ_Rollo_Tuer up
2017.04.28 07:31:19 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:31:22 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:32:54 2: CUL_433 IT: 00000000000000000000000000000000000000000000000000000 not defined (Address: 0000000000000000000000000000000000000000000000 Unit: 0000000 Switch code: 00 GroupCode: 0)
2017.04.28 07:39:13 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:39:13 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:50:20 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:50:22 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:50:58 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:51:00 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:51:40 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:51:41 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:53:19 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:53:22 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:54:23 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:55:27 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 07:55:40 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:55:42 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 08:11:56 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 08:11:56 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 08:28:21 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 08:28:21 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 09:07:13 3: CUL_433 IT_set: Kueche_Kaffee off
2017.04.28 09:29:22 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 09:29:22 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 09:29:38 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 09:29:38 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 09:53:45 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 09:53:45 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 10:08:47 3: MyJeeLink: Unknown code OK LS 14 0 4 46 2 209 116, help me!
2017.04.28 10:37:48 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 10:37:48 1: 192.168.178.71:81 reappeared (WlanJeeLink)
2017.04.28 10:57:03 3: CUL_433 IT_set: AZ_Kamera on
Gruß Werner
Zitat von: pc1246 am 28 April 2017, 11:26:12
... wenn mehrere fhems auf das GW zugreifen.
OK, den Fall habe ich hier nicht laufen.
Zitat von: pc1246 am 28 April 2017, 11:26:12
Ich denke, dass ich durch Zufall das Problem erkannt habe. Es sieht so aus, dass das Problem dann auftritt, wenn mehrere fhems auf das GW zugreifen. Mein Testsystem ist derzeit nicht am Netzwerk, und die 1.29 laeuft stabil! Werde noch ein wenig warten und dann das Testsystem wieder online nehmen!
Was greift denn wie zu?
FHEM 1 auf einen DataPort (z.B. 81) und FHEM 2 auf einen weiteren DataPort (z.B. 82) ?
Und ein oder zwei FHEM-CUL-devices auf den in "Serial bridge 1" konfigurierten Port?
Am besten mal einen SchrimSchuss von der Hardware-page machen, wenn das Testsystem wieder online ist.
Zitat von: Intruder1956 am 28 April 2017, 12:35:40
... aber, ich habe jetzt ständig im Logfile folgende Meldung
2017.04.28 07:18:59 1: 192.168.178.71:81 reappeared (WlanJeeLink)
Uff, ich auch :o :o
Dann werde ich es wohl mal untersuchen.
Zwei fhem auf den seriellen, der ja auch abstuerzt!
Gruss Christoph
Ich habe auch 2 FHEM-Instanzen, die auf das LGW zugreifen (1.29).
Mist. Während ich das schreibe, ist das LGW gerade auf beiden FHEMs disconnected. Per WLAN nicht erreichbar. Das LGW läuft aber, ich sehe die permanent wechselnden Displayseiten und die FileLogs erhalten auch noch Werte der Sensoren - obwohl disconnected.
Aber nicht in alle Logs wird geschrieben. Der BME280 vom LGW liefert schon seit dem 25.04. keine Daten mehr.
Der Watchdog zieht nicht, da das LGW noch läuft. Per FHEM kann ich das LGW nicht neu starten, da es über's WLAN nicht mehr erreichbar ist.
Das LGW ist nicht mehr im WLAN zu sehen.
Merkwürdig. Also: Reset
Und danach läuft sofort wieder alles.
Eigentlich hatte ich schreiben wollen, dass ich auch hin und wieder mal die "disconnected, waiting to reappear" Meldungen habe und dann oft nur ein shutdown restart hilft.
LG
Holger
Hi.
Ich verwende ein WeMos D1mini Modul beim LGW mit v1.29.
Der analog Port ist ja für 1024=1000mV programmiert.
Beim D1mini sind aber 3300mV am analog Port für einen Wert von 1024 erforderlich.
Es wäre toll, wenn im Setup der Korrekturwert parametriert werden könnte :)
lg
Zitat von: heka am 29 April 2017, 11:23:52
Beim D1mini sind aber 3300mV am analog Port für einen Wert von 1024 erforderlich.
Es wäre toll, wenn im Setup der Korrekturwert parametriert werden könnte :)
Ist gerade auf die Wunschliste für die 1.30 gekommen.
Moin
Wie immer sitzt das Problem 50cm vor der Tastatur! Wenn man natuerlich im einen fhem den CUL als homematic-device haben moechte, und im anderen als slow-RF, dann muss man sich nicht wundern!
Habe jetzt mal beide gleich eingestellt, melde mich uebermorgen dazu wieder!
Gruss und schoenen Feiertag
Christoph
So. Musste jetzt das lgw/lcg auf die 1.25 zurück flashen. Das Gateway läuft max. 5 Tage und hängt sich dann weg. Ist auch dann nicht mehr über das Netzwerk erreichbar.
Gruß Sascha
Gesendet von dem teuren ding in meiner hand
Zitat von: pc1246 am 30 April 2017, 17:46:24
Wenn man natuerlich im einen fhem den CUL als homematic-device haben moechte, und im anderen als slow-RF, dann muss man sich nicht wundern!
Ja, das klappt nicht so gut.
Aber ein generelles Problem habe ich ausgemacht und gerade geändert.
Das ESP8266 SDK kann per default nur fünf TCP-Verbindungen gleichzeitig.
Zwei FHEM und auf zwei Serial-Bridges etwas verbunden plus das WebFrontend oder weitere FHEMs auf den Bridges dann ist rum und es klemmt dann nicht unbedingt auf dem letzen Port sondern generell irgendwo.
Habe gerade mit einiger Mühe dem SDK beibringen können, dass ich bis zu 10 geichzeitige TCP-Verbindungen will.
Das kann aber durchaus seltsame Effekte hervorgerufen haben, da ich den Eindruck habe, dass die Probleme im Wesentlichen bei Anwendern aufteten, die mit mehreren FHEMs drauf zugreifen.
Zitat von: heka am 29 April 2017, 11:23:52
Beim D1mini sind aber 3300mV am analog Port für einen Wert von 1024 erforderlich.
Es wäre toll, wenn im Setup der Korrekturwert parametriert werden könnte :)
Der Korrekturwert wird aber nur die Anzeige auf der hardware-page anpassen.
Der ADC hat einen Wertebereich von 0 bis 1024, daran ändern auch Spannungsteiler vor dem Analog-In nichts.
Bedeutet: die Werte, die an FHEM übermittelt werden, ändern sich nicht, da das der ADC-Wert ist und nicht eine daraus gerechnete Spannung.
Zitat von: HCS am 01 Mai 2017, 21:45:02
Der Korrekturwert wird aber nur die Anzeige auf der hardware-page anpassen.
Der ADC hat einen Wertebereich von 0 bis 1024, daran ändern auch Spannungsteiler vor dem Analog-In nichts.
Bedeutet: die Werte, die an FHEM übermittelt werden, ändern sich nicht, da das der ADC-Wert ist und nicht eine daraus gerechnete Spannung.
Ist mir klar.
Ich nutze oft den direkten IP link zum LGW. Daher wäre es praktisch, trotzdem die Korrektur im LGW zu parametrieren.
Vielleicht erweiterst Du ja Mal das LGW um eine Analogwertanzeige im LCD ;) Ab dann ist es sowieso sinnvoll.
lg
Zitat von: heka am 02 Mai 2017, 11:10:09
Ich nutze oft den direkten IP link zum LGW. Daher wäre es praktisch, trotzdem die Korrektur im LGW zu parametrieren.
Ja, mache ich.
Zitat von: heka am 02 Mai 2017, 11:10:09
Vielleicht erweiterst Du ja Mal das LGW um eine Analogwertanzeige im LCD ;)
Dann zeige ich dort den rohen Wert von ADC an ;D ;D ;D
Zitat von: HCS am 01 Mai 2017, 21:45:02
Der ADC hat einen Wertebereich von 0 bis 1024, ...
Und bevor jetzt jemand die Hand hebt: ein 10 bit ADC hat natürlich einen Wertebereich von 0 ... 1023 :)
Zitat von: Intruder1956 am 28 April 2017, 12:35:40
aber, ich habe jetzt ständig im Logfile folgende Meldung
2017.04.28 07:18:59 1: 192.168.178.71:81 disconnected, waiting to reappear (WlanJeeLink)
2017.04.28 07:18:59 1: 192.168.178.71:81 reappeared (WlanJeeLink)
Das hatte ich ja nun auch mit genau einem meiner drei Produktiv-LGW.
Und die Ursache war schlicht, dass das LGW genau an der Reichweitengrenze des WLAN stand und tatsächlich die Verbindung verloren und wieder aufgebaut hat.
War dann auch mal einige Stunden Ruhe (wenn die HF-Bedingungen gerade besser waren) und dann wieder schlechter.
Was meint denn das WebFrontend zu RSSI?
Hallo,
also gerade mal im Logfile geschaut, in diesem Monat ist Ruhe.
Kein disconnect mit der V.1.25
UpTimeSeconds: 1022227
UpTimeText: 11Tg. 19Std. 57Min. 7Sek.
WIFI: FritzServer
MacAddress: 5C:CF:7F:12:64:AE
ChipID: 1205422
ReceivedFrames: 720734
FramesPerMinute: 43
RSSI: -71
FreeHeap: 15304
Version: 1.25
LD.Min: 0
LD.Avg: 0
LD.Max: 36
OLED: none
Gruß Werner
Moin
Mal ein kurzer Zwischenstand nach gut 7 Tagen! Beide fhem sind immer noch connected, beide sagen eine uptime von ueber 7 Tagen! Also lag es bei mir wohl an den unterschiedlichen Definitionen, was ja auch die 1.25 in die Knie gezwungen hat!
Gruss Christoph
Zitat von: pc1246 am 07 Mai 2017, 20:00:39
Also lag es bei mir wohl an den unterschiedlichen Definitionen, was ja auch die 1.25 in die Knie gezwungen hat!
Ja, das ist definitiv ein Grund, der Probleme verursachen kann.
Und dann kann ich aktuell nur einen weiteren Grund ausmachen, nämlich, dass aktuell nur maximal fünf TCP-Verbindungen gleichzeitig gehen, was ich für die kommende 1.30 mal auf 10 hochgesetzt habe.
Auf dem Schnipsel unten sieht man, dass zwei FHEM auf den DataPorts und auf jeder der beiden serial bridges (an denen jeweils ein CUL dran ist) zwei FHEMs connected sind.
Das geben zusammen sieben TCP-Verbindungen (2 x FHEM->DataPort + 2 x 2 FHEM->bridge + das Frontemd, das auch eine braucht, wenn man drauf schaut)
Das läuft so weit aktuell mit der 1.30 problemlos. In beiden FHEMs stehen alle sechs Devices konstant auf Initialized.
SC16IS750 (0x90) OK
SC16IS750 (0x92) OK
MCP23008 OK
OLED OK Off
DataPort #1 81 FHEM connected
DataPort #2 82 FHEM connected
DataPort #3 ---
Serial-bridge #1 85 2 client(s) connected
Serial-bridge #2 86 2 client(s) connectedDie Analog-Konfiguration habe ich auch eingebaut, Setup-Page siehe Analog1.png und Hardware-Page siehe Analog2.png
Gibt es eigentlich Temperatur/Feuchtigkeits Sensoren die nicht beim einlegen der Batterie ständig ihre ID ändern? Ich habe seit gestern einen neuen Sensor auf dem Balkon und scheinbar gibt es in nähere Umgebung einen Sensor mit der gleichen ID. Die Temperaturwerte springen ständig zwischen 2 Positionen hin und her.
Ist mir nicht bekannt, am einfachsten halt noch mal neu die Batterie einlegen und hoffen das du eine ID bekommst die noch nicht vergeben ist in der Umgebung. Wenn dann mal eine hast beim Batteriewechsel erst im FHEM 'change battery' abfeuern..
Okay.
Gibt es irgendwo eine Übersicht wie die Werte im Log zu verstehen sind und wie sie kodiert sind?
14:20:35: OK 9 18 1 4 205 35 [94 86 29 23 7D]
9 = Nachrichtenlänge
18 = ID
1 = Batterie ok?
4 = ?
205 = ?
35 = Humidity
Was bedeuten die Werte in der eckigen Klammer?
Irgendwie habe ich seltsame Sprünge bei einem Sensor bei der Temperatus:
2017-05-10_14:44:03 LaCrosse_BK battery: ok
2017-05-10_14:44:03 LaCrosse_BK temperature: 23.6
2017-05-10_14:44:03 LaCrosse_BK humidity: 33
2017-05-10_14:44:07 LaCrosse_BK battery: ok
2017-05-10_14:44:07 LaCrosse_BK temperature: 21.6
2017-05-10_14:44:07 LaCrosse_BK T: 21.6
2017-05-10_14:44:19 LaCrosse_BK battery: ok
2017-05-10_14:44:19 LaCrosse_BK temperature: 23.6
2017-05-10_14:44:19 LaCrosse_BK humidity: 33
2017-05-10_14:44:19 LaCrosse_BK T: 23.6 H: 33
2017-05-10_14:44:23 LaCrosse_BK battery: ok
2017-05-10_14:44:23 LaCrosse_BK temperature: 21.6
2017-05-10_14:44:23 LaCrosse_BK T: 21.6
2017-05-10_14:44:36 LaCrosse_BK battery: ok
2017-05-10_14:44:36 LaCrosse_BK temperature: 23.6
2017-05-10_14:44:36 LaCrosse_BK humidity: 33
2017-05-10_14:44:36 LaCrosse_BK T: 23.6 H: 33
Die Temperatur spring zwischen 23,6 und 21,6 hin und her.
Im Log des Gateways sehe ich allerdings solche Sprünge bei den Nachrichten nicht.
14:43:13 OK 9 18 1 4 212 33 [94 86 36 21 E8]
14:43:19 OK 9 8 1 4 192 106 [92 6 16 6A 3F]
14:43:21 OK 9 18 1 4 212 33 [94 86 36 21 E8]
14:43:27 OK 9 8 1 4 192 106 [92 6 16 6A 3F]
Kann es sein, dass das LaCrosse Device irgendwie die Messages von 2 unterschiedlichen Sensor IDs bekommt?
Ich hatte die ID vom Device von 8 auf 12 händisch im DEF geändert, nachdem ich den Sensor des Nachbarn durch einen eigenen ersetzt habe.
Zitat von: gloob am 10 Mai 2017, 14:01:06
Gibt es eigentlich Temperatur/Feuchtigkeits Sensoren die nicht beim einlegen der Batterie ständig ihre ID ändern?
Die willst Du nicht wirklich. Wenn Dein Nachbar plötzlich mit der gleichen ID aufschlägt, bist Du erledigt, wenn Deiner keine andere bekommen kann.
Ich habe mal irgendwo gelesen, dass jemand in den Sensor einen Elko gesetzt hat, um die Zeit vom Batteriewechsel zu überbrücken.
Schnell wechseln -> ID bleibt, langsam raus rein, wenn man eine neue ID will.
Zitat von: gloob am 10 Mai 2017, 14:22:00
Gibt es irgendwo eine Übersicht wie die Werte im Log zu verstehen sind und wie sie kodiert sind?
// OK 9 56 1 4 156 37 ID = 56 T: 18.0 H: 37 no NewBatt
// OK 9 49 1 4 182 54 ID = 49 T: 20.6 H: 54 no NewBatt
// OK 9 55 129 4 192 56 ID = 55 T: 21.6 H: 56 WITH NewBatt
// OK 9 ID XXX XXX XXX XXX
// | | | | | | |
// | | | | | | --- Humidity incl. WeakBatteryFlag
// | | | | | |------ Temp * 10 + 1000 LSB
// | | | | |---------- Temp * 10 + 1000 MSB
// | | | |-------------- Sensor type (1 or 2) +128 if NewBatteryFlag
// | | |----------------- Sensor ID
// | |------------------- fix "9"
// |---------------------- fix "OK"Und wenn das LGW konstante Werte sendet und in FHEM die Werte springen, dann ist ein weiterer Sensor im Spiel.
Wie kann es aber sein, dass die Werte im LGW nicht springen aber im FHEM Device? FHEM bekommt doch nur das, was das LGW sendet.
Zitat von: gloob am 10 Mai 2017, 14:22:00
Was bedeuten die Werte in der eckigen Klammer?
Das sind die Rohdaten, die der Sensor sendet.
* .- [0] -. .- [1] -. .- [2] -. .- [3] -. .- [4] -.
* | | | | | | | | | |
* SSSS.DDDD DDN_.TTTT TTTT.TTTT WHHH.HHHH CCCC.CCCC
* | | | || | | | | | | || | | |
* | | | || | | | | | | || | `--------- CRC
* | | | || | | | | | | |`-------- Humidity
* | | | || | | | | | | |
* | | | || | | | | | | `---- weak battery
* | | | || | | | | | |
* | | | || | | | | `----- Temperature T * 0.1
* | | | || | | | |
* | | | || | | `---------- Temperature T * 1
* | | | || | |
* | | | || `--------------- Temperature T * 10
* | | | | `--- new battery
* | | `---------- ID
* `---- START = 9Daraus macht das LGW dann "OK 9 18 1 4 205 35" was es an FHEM sendet.
Zitat von: gloob am 10 Mai 2017, 14:22:00Kann es sein, dass das LaCrosse Device irgendwie die Messages von 2 unterschiedlichen Sensor IDs bekommt?
Ich hatte die ID vom Device von 8 auf 12 händisch im DEF geändert, nachdem ich den Sensor des Nachbarn durch einen eigenen ersetzt habe.
So ungefähr sieht es aus, aber mir ist echt unklar, wie das LaCrosse Device in FHEM das machen sollte.
FHEM neu starten.
list LaCrosse_BKhier anhängen
Hallo,
Ich habe mir einen NodeMcu bestellt und will den am WE flashen. Ich hba emir auch drei RFM69CW, 868MHz Module bestellt.
Nun habe ich vorab noch einige Fragen:
Kann ich mit demselben Gateway sowohl Lacross Thermostate als auch PCA301 und EC3000 Steckdosen benutzen.
Also für jedes RFM69CW Modul eigene Geräte? Wie wird das konfiguriert?
Bei einem normalen Jeelink geht ja immer nur entweder oder.
Könnte man darüber auch Intertechno Dosen schalten? Also als CUL Ersatz?
Danke schon mal.
LG Johannes
Zitat von: Malifitz am 12 Mai 2017, 17:25:16
Kann ich mit demselben Gateway sowohl Lacross Thermostate als auch PCA301 und EC3000 Steckdosen benutzen.
Ja
Zitat von: Malifitz am 12 Mai 2017, 17:25:16
Wie wird das konfiguriert?
https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x
Zitat von: Malifitz am 12 Mai 2017, 17:25:16
Könnte man darüber auch Intertechno Dosen schalten? Also als CUL Ersatz?
Nein
Zitat von: HCS am 12 Mai 2017, 18:26:27
Intertechno steuern?
Nein
Müsste das nicht mit mit einem zusätzlichen 433 MHz CUL auf der Platine am seriellen Port klappen?
Gesendet von iPhone mit Tapatalk
Hey HCS,
Danke für die Antwort. Die Wiki Seite hab ich natürlich geflissentlich übersehen. :-[
Und auch Danke für die tolle Arbeit hier! Da ich absolut keine Ahnung von Mikrocontroller Programmierung habe kann ich ich nur ahnen wie viel Arbeit es ist, so eine Firmware zu erstellen.
Ich hab den Chip grad angeschlossen und los gehts....
Die Anleitung im ersten Thread ist sau gut und auch für nicht Bastler verständlich.
Das Aufspielen der Firmware hat problemlos funktioniert und fhem hat das Gateway auch erkannt.
Jetzt muss ich noch die Füße stillhalten, bis die RF Chips kommen.
Kann man den Wemos D1 mini 1zu1 gegen den Node NodeMcu austauschen, oder muß man da noch andere Dinge beachten?
Zitat von: Malifitz am 13 Mai 2017, 01:47:27
Die Anleitung im ersten Thread ist sau gut und auch für nicht Bastler verständlich.
Das Aufspielen der Firmware hat problemlos funktioniert und fhem hat das Gateway auch erkannt.
Jetzt muss ich noch die Füße stillhalten, bis die RF Chips kommen.
Kann man den Wemos D1 mini 1zu1 gegen den Node NodeMcu austauschen, oder muß man da noch andere Dinge beachten?
Ich nutze einen Wemos und bin zufrieden:
https://forum.fhem.de/index.php?topic=65361.0
Zitat von: Malifitz am 13 Mai 2017, 01:47:27
Kann man den Wemos D1 mini 1zu1 gegen den Node NodeMcu austauschen, oder muß man da noch andere Dinge beachten?
Geht problemlos, musst nur die richtigen PINs nehmen. Der Wemos hat ein paar weniger!
Gruss Christoph
Danke für die Info.
Ich bestelle mir mal zwei,drei zum testen.
Und mit den NodeMcu teste ich dann mal EasyESP und MySensors aus :)
V1.30
Anzahl TCP-Connections
Es wurden nur maximal fünf TCP-Connections (Summe aus Data-Ports, Serial-Bridges, Frontend, ...) unterstützt
Das wurde nun auf 10 erhöht.
WS1600 (TX22IT) - Pakete mit Error-Flag
Die Pakete vom TX22IT werden nun auch dann an FHEM weitergeleitet, wenn das Error-Flag gesetzt ist (was der Fall ist, wenn man keinen Wind- und/oder Regensensor dran hat)
In diesem Fall werden die Wind und Regendaten unterdrückt.
Konfiguration Analogport
Es kann nun auf der Setup-Page konfiguriert werden, welche Spannung anliegt, wenn der ADC 1023 liefert. Auf einem DevKit sind das 1000 mV,
bei Boards die Spannungsteiler vor A0 haben sonstwas halt.
Dies wird auf der Hardware-Page entsprechend berücksichtigt.
Gerade eingecheckt, wird dann morgen vom FHEM-Update ausgeliefert.
Zitat von: Malifitz am 13 Mai 2017, 01:47:27
Die Anleitung im ersten Thread ist sau gut und auch für nicht Bastler verständlich.
Naja, nur fast "sau gut" ;D
Habe sie gerade nochmal angeschaut (und geändert).
Da ist immer die Rede vom JeeLink Modul in FHEM. Das sollte man aber nicht mehr nehmen, da es inzwischen ein spezialisiertes Modul 36_LaCrosseGateway gibt, das das LGW besser unterstützt.
Hallo HCS.
Habe gestern ein verbindungsabbruch zum gateway gehabt.
Habe dann nachgeschaut. Es war noch im Netzwerk erreichbar. Habe dann über fhem ein connect abgesetzt. Wurde auch entsprechend angezeigt.
Ich habe jedoch keine Daten in fhem bekommen. Habe mich dann auf das gateway eingeloggt und mir das log angeschaut. Es wurden fleißig Daten empfangen. In fhem kam jedoch nix an.
Erst ein Neustart von fhem hat fhem dazu gebracht wieder Daten vom gateway zu empfangen.
Also.
1. Fhem hat keine Daten empfangen
2. Connect ausgeführt, wurde auch mit intakter Verbindung angezeigt.
3. Keine Daten in fhem
4. Log vom lcg kontrolliert, Daten kamen im log an.
5. Restart von fhem durchgeführt, dann kamen auch die Daten dort an.
Gruß Sascha
Gesendet von meinem SM-T560 mit Tapatalk
Zitat von: sash.sc am 14 Mai 2017, 15:26:55
1. Fhem hat keine Daten empfangen
2. Connect ausgeführt, wurde auch mit intakter Verbindung angezeigt.
3. Keine Daten in fhem
4. Log vom lcg kontrolliert, Daten kamen im log an.
5. Restart von fhem durchgeführt, dann kamen auch die Daten dort an.
Was als Ergebnis ergibt, dass das LGW nichts dafür konnte.
Keine Ahnung, wo es in Deinem FHEM geklemmt hat.
Was hat in dem Zustand ein verbose 5 beim LaCrosseGateway-Device im log ergeben?
Da müssten dann solche Zeilen auftauchen:
2017.05.14 19:31:00 5: lgw211: dispatch OK 9 4 1 4 184 52
Habe nur verbose 3 eingestellt gehabt.
Besteht die Möglichkeit, alle Meldungen in ein LOG umzuleiten ??
Habe mal ein LOG angelegt, aber die DISPATCH/RAWMSG Meldungen gehen natürlich nicht ins LOG.
Gruß
Sascha
Zitat von: HCS am 13 Mai 2017, 19:43:02
V1.30
...
Wollte gerade ein update des Gateways über FHEM machen und hinterher habe ich immer noch 1.29 als Version.
2017-05-15 14:39:06 Global global Started not blocking
2017-05-15 14:39:06 Global global flashing LaCrosseGateway myLaCrosseGateway
2017-05-15 14:39:06 Global global hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
2017-05-15 14:39:06 Global global Mode is LaCrosseGateway OTA-update
2017-05-15 14:39:06 Global global myLaCrosseGateway closed
2017-05-15 14:39:06 Global global target: http://192.168.1.33/ota/firmware.bin
2017-05-15 14:39:06 Global global Upload started, please wait a minute or two ...
2017-05-15 14:39:15 Global global
2017-05-15 14:39:15 Global global --- LGW reports ---------------------------------------------------------------------------
2017-05-15 14:39:16 Global global Start receiving 'firmware.bin'
2017-05-15 14:39:16 Global global Firmware size: 442928
2017-05-15 14:39:16 Global global Rebooting ESP8266 ...
2017-05-15 14:39:16 Global global
2017-05-15 14:39:16 Global global OTA update finished
2017-05-15 14:39:16 Global global ----------------------------------------------------------------------------------------------------
2017-05-15 14:39:16 Global global myLaCrosseGateway opened
2017-05-15 14:39:16 Global global FinshedMuss ich noch mehr machen außer:set gateway flashEdit: Wenn man vorher ein Update von FHEM macht, klappt es natürlich auch :-X
Hallo,
bin jetzt von einer NodeMCU mit 1x RFM69 und FW 1.05 auf ein LGW für Nexion von Locutus umgestiegen und hab da jetzt so ein paar Probleme.
Das "neue" LGW hat 3x RFM69 und einen CUL868 und ist mit FW 1.29 ausgerüstet. Inbetriebname mit Konfiguration auf mein WLAN hat auch soweit geklappt, konnte das LGW auch in meinem FHEM konfigurieren. Nach einer gewissen Zeit (scheint unterschiedlich) kann ich das Web-Frontend des LGW aber nicht mehr erreichen, es kommt zu einem Timeout. FHEM empfängt aber noch weiter Daten vom LGW.
Was ist denn da faul?? Wo kann ich suchen?
Gruß
Olly
Zitat von: Olly am 15 Mai 2017, 21:11:10
bin jetzt von einer NodeMCU mit 1x RFM69 und FW 1.05 auf ein LGW für Nexion von Locutus umgestiegen
Das hier?
https://forum.fhem.de/index.php/topic,55705.msg618396.html#msg618396
Wo finde ich denn einen Schaltplan davon, um mal zu sehen, was da wie dran ist?
Zitat von: Olly am 15 Mai 2017, 21:11:10
Nach einer gewissen Zeit (scheint unterschiedlich) kann ich das Web-Frontend des LGW aber nicht mehr erreichen
Wiel lang ist die Zeit denn ungefähr?
Zitat von: Olly am 15 Mai 2017, 21:11:10
Nach einer gewissen Zeit (scheint unterschiedlich) kann ich das Web-Frontend des LGW aber nicht mehr erreichen, es kommt zu einem Timeout. FHEM empfängt aber noch weiter Daten vom LGW.
Was ist denn da faul?? Wo kann ich suchen?
- Häng mal den Inhalt der Hardware-Page vom WebFrontend hier an (solange es noch läuft)
- Danach Update auf LGW V1.30 machen
- Wie viele FHEMs greifen wie auf was vom LGW zu? (DatePorts, Bridges, Nextion, ...)
Zitat von: HCS am 16 Mai 2017, 09:14:05
Wo finde ich denn einen Schaltplan davon, um mal zu sehen, was da wie dran ist?
das müsste dieser da sein: https://forum.fhem.de/index.php?action=dlattach;topic=55705.0;attach=75855;image
Gruß PeMue
Moin
Ich hatte das zu Anfang auch mal eine Zeit lang. Aber ich weiss nicht mehr was der Grund war, und warum es wieder aufgehoert hat! Lag aber nicht an den zwei fhem's, da hatte ich nur eins!
Gruss Christoph
Zitat von: HCS am 16 Mai 2017, 09:14:05
Das hier?
https://forum.fhem.de/index.php/topic,55705.msg618396.html#msg618396
Wo finde ich denn einen Schaltplan davon, um mal zu sehen, was da wie dran ist?
Wiel lang ist die Zeit denn ungefähr?
- Häng mal den Inhalt der Hardware-Page vom WebFrontend hier an (solange es noch läuft)
- Danach Update auf LGW V1.30 machen
- Wie viele FHEMs greifen wie auf was vom LGW zu? (DatePorts, Bridges, Nextion, ...)
Hallo HCS,
ja, das verlinkte Board ist es. Schaltplan ist dieser: https://forum.fhem.de/index.php?action=dlattach;topic=55705.0;attach=75855;image
Die Zeit, nach der es nicht mehr erreichbar ist, ist unterschiedlich. So ab 15 Minuten aufwärts. Dachte erst, dass das Web-Interface wie beim AP-Mode einfach abgeschaltet wird, liest sich aber im Wiki-Artikel nicht so.
Ich hab dann gestern Abend noch ein Update auf die V1.30 gemacht und zusätzlich mein WLAN mal sichtbar gemacht (das ist normalerweise hidden). Bis ich heute Morgen um 7:30h aus dem Haus gegangen bin lief es noch. Ich schaue dann heute Abend noch mal.
Es greift übrigens nur 1 FHEM Instanz drauf zu.
Falls es heute Abend wieder nicht geht, kann ich auch den Inhalt der Hardware-Page mal anhängen.
Gruß
Olly
So, aktueller Status:
Über den Tag ist das Web-Interface "verschütt" gegangen. LGW ist heute Abend nicht mehr per Browser zu erreichen.
Bis 21 Uhr konnte ich aber über FHEM mit dem LGW kommunizieren (Abfrage der Version des miniCUL, KeyValueProtocol sendet Werte an FHEM...). Dann war plötzlich Schluß, LGW und der darauf verbaute CUL sind jetzt disconnected. Die Uptime war jetzt ca. 24 Std.
Hier die Infos von der Hardware-Page (nach einem Neustart des LGW):
LaCrosseGateway V1.30 LaCrosseGateway (192.168.140.70)
Home Setup Hardware OTA-Update Log Help Logout Reboot
ESP8266 present :-) Core: 2_3_0 SDK: 1.5.3(aec24ac9) free heap: 15648 Reset: External System -> Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
WiFi -62 dBm Mode: Station Time to connect: 11.4 s
Radio #1 RFM69 868300 kHz data rate: 17241 kbps
Radio #2 ---
Radio #3 ---
Radio #4 RFM69 868300 kHz data rate: 20000 kbps
Radio #5 RFM69 868300 kHz data rate: 111 kbps
SHT75 ---
BME280 ---
BMP180 ---
DHT22 ---
LM75 ---
SC16IS750 (0x90) OK
SC16IS750 (0x92) OK
MCP23008 ---
OLED ---
DataPort #1 81
DataPort #2 ---
DataPort #3 ---
Serial-bridge #1 85 0 client(s) connected
Serial-bridge #2 ---
Soft-bridge ---
Nextion ---
Analog port Disabled ADC=61 U=4294967295 mV (0 ... 0 mV)
Edit: Jetzt nach ein paar Minuten ist das Web-Interface wieder nicht erreichbar. FHEM bekommt aber noch Werte vom LGW.
Gruß
Olly
Zitat von: Olly am 16 Mai 2017, 21:43:16
Über den Tag ist das Web-Interface "verschütt" gegangen. LGW ist heute Abend nicht mehr per Browser zu erreichen.
Bis 21 Uhr konnte ich aber über FHEM mit dem LGW kommunizieren (Abfrage der Version des miniCUL, KeyValueProtocol sendet Werte an FHEM...). Dann war plötzlich Schluß, LGW und der darauf verbaute CUL sind jetzt disconnected. Die Uptime war jetzt ca. 24 Std.
Kannst Du mal testweise das CUL-Device in FHEM deaktivieren, dass es sich nicht mehr auf das LGW verbindet?
Ich sehe da zwar kein generelles Problem, bei mir laufen gegen ein Test-LGW zwei FHEMs, die jeweils beide CUL des LGW und jeweils einen DataPort belegen.
Aber irgend wie müssen wir das jetzt versuchen einzugrenzen.
Oder Du packst mal die V1.25 drauf, es gab ja schon mal von jemand die Aussage, dass er mit 1.29 Probleme und 1.25 keine Probleme hat (was ich auch nicht nachvollziehen konnte)
Hier hängt sie dran: https://forum.fhem.de/index.php/topic,43672.msg617956.html#msg617956
Darfst aussuchen, was Du lieber zuerst probieren willst. :)
Noch eine Option:
mit
esptool --port COM3 erase_flash
den ESP8266 mal komplett leeren (da ist EEPROM und alles danach weg) und dann die 1.30 nochmal aufspielen und über den AccessPoint wieder konfigurieren.
Anstatt COM3 die entsprechende Schnittstelle verwenden.
esptool.py findest Du in /opt/fhem/FHEM/Firmware
Musst aber Python 2.7 und pyserial installiert haben.
apt-get install python
wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py
pip install pyserial
OK,
ich probiere das einfachste zuerst: Ich hab grad mal das CUL-Device und alles was in FHEM damit zu tun hat auskommentiert.
Mal schauen was passiert. Nächste Sache wäre wohl ein Versuch mit der V1.25.
Gruß
Olly
Zwischenstand:
Heute Morgen könnte ich das Web-Interface im ersten Versuch nicht erreichen (vom Tablet aus). Etwas später ging es dann aber, das kann am Tablet gelegen haben.
Werte, z. B. KeyValueProtokoll kommen in FHEM noch an.
Ich schaue dann mal wie der Status heute Abend ist.
Gruß
Olly
Zitat von: HCS am 13 Mai 2017, 19:43:02
Konfiguration Analogport
Es kann nun auf der Setup-Page konfiguriert werden, welche Spannung anliegt, wenn der ADC 1023 liefert. Auf einem DevKit sind das 1000 mV,
...
Funktioniert super :)
Beim WeMos
D1mini sind das
300 mV im Setup. Das liefert dann die richtige mV Angabe auf der Hardware Page.
So,
das Gateway ist lt. KeyValueProtocol heute Morgen um 9:33h nach 12h 41min Betrieb wieder ausgefallen.
Ich hab dann jetzt mal die 1.25er Firmware aufgespielt. Allerdings hab ich die EEPROM-Werte noch nicht gelöscht, das LGW kannte seine Konfig noch.
Ich berichte dann wieder.
Gruß
Olly
Hallo HCS,
leider ist der Effekt mit der Version 1.25 noch genau so da :-[
Hat ebenfalls wieder heute Vormittag die Verbindung zu FHEM verloren. Ebenso nicht mehr per Ping und auch nicht per Web-Interface erreichbar.
Ich hab nach dem Problem mal etwas gegoogelt... Nutzt du das hier: https://github.com/esp8266/Arduino ?? Hab im LGW auf der Hardwarepage was von SDK 1.5.3 gelesen. Dann könnte das -> https://github.com/esp8266/Arduino/issues/2330 interessant sein.
BTW: Hab jetzt noch mal das EEPROM gelöscht und schaue jetzt mal, ob das ggf. was hilft.
Gruß
Olly
Zitat von: Olly am 19 Mai 2017, 22:24:20
Dann könnte das -> https://github.com/esp8266/Arduino/issues/2330 interessant sein.
Das ist sehr interessant und möglicherweise das Problem, das bei Dir auftritt.
Aber es muss trotzdem bei Dir besonder Umstände geben, die dazu führen, das ist ja kein generelles Problem, das grundsätzlich bei jedem auftriit.
Drum noch ein paar weitere Fragen:
- DHCP oder eine statische IP?
- Bist Du absolut sicher, dass kein anderes Gerät gleiche IP verwendet?
- Was für einen Access Point hast Du?
- Bricht die Verbindung von FHEM zum LGW auch dann irgend wann weg, wenn Du zuvor nie mit dem Browser auf dem Web-Frontend warst?
- Mit welchen Browsern auf welchen Betriebssystemen greifst Du zu?
- Kannst Du das LGW noch pingen, wenn es auftritt?
Zitat von: HCS am 20 Mai 2017, 20:44:22
Das ist sehr interessant und möglicherweise das Problem, das bei Dir auftritt.
Aber es muss trotzdem bei Dir besonder Umstände geben, die dazu führen, das ist ja kein generelles Problem, das grundsätzlich bei jedem auftriit.
Drum noch ein paar weitere Fragen:
- DHCP oder eine statische IP?
- Bist Du absolut sicher, dass kein anderes Gerät gleiche IP verwendet?
- Was für einen Access Point hast Du?
- Bricht die Verbindung von FHEM zum LGW auch dann irgend wann weg, wenn Du zuvor nie mit dem Browser auf dem Web-Frontend warst?
- Mit welchen Browsern auf welchen Betriebssystemen greifst Du zu?
- Kannst Du das LGW noch pingen, wenn es auftritt?
Hallo HCS,
tja, was bei mir besonders ist .... gute Frage.
Ich habe eine statische IP vergeben, die definitiv nicht wo anders vergeben ist. AccesPoint ist von Trenda (W301A).
Zugriff habe ich von meinem Android Tablet mit Chrome und von 2 verschiedenen Windows7 Systemen mit IE11 oder Firefox 53.0.2 getestet.
Wenn das Web-Interface nicht mehr erreichbar ist, kann ich auch nicht mehr auf die IP pingen.
Ob die Verbindung auch wegbricht, wenn ich vorher nicht auf das Web-Interface zugreifen kann ich gar nicht sagen, hab das bisher immer aufgerufen.
Interessant ist aber, dass FHEM immer noch Daten bekommt, wenn ich schon nicht mehr pingen kann und auch das Web-Interface nicht mehr erreichbar ist.
Gruß
Olly
Gesendet von meinem Nexus 7 mit Tapatalk
Gestern bin ich gleich zwei mal drauf gestoßen, wie es dazu kommt (Auszug):
2017.05.19 01:31:18 1: 192.168.31.209:81 reappeared (lgw209)
2017.05.19 01:31:18 1: 192.168.31.210:81 reappeared (lgw210)
2017.05.19 01:35:48 1: 192.168.31.210:81 reappeared (lgw210)
2017.05.20 01:31:19 1: 192.168.31.209:81 reappeared (lgw209)
2017.05.20 01:31:19 1: 192.168.31.210:81 reappeared (lgw210)
Das passierte jede Nacht pünktlich um 01:31:xx
Grund: ich habe einen at, der jede Nacht um 01:30:00 mit "set xyz deleteOldDays 30" ein DbLog (ca. 3.5 Mio. records) aufräumt und der braucht etwas über eine Minute und blockiert FHEM so lange. Die LaCrosseGateway-Devices in FHEM habe ich mit einem Timeout von 30 Sekunden konfiguriert.
Da FHEM länger als die 30 Sekunden blockiert ist, bekommt das LaCrosseGateway-Devices die Antwort auf die ALIVE Anfrage vom LGW nicht rechtzeitg und löst einen reconnect aus.
Gestern Abend hatte ich dan plötzlich massiv "reappeared" Einträge im Log, im Minutentakt.
Grund: meine Interetverbindung war ausgefallen und eins meiner Module, die ins Internet greifen, hat FHEM alle paar Minuten für eine längere Zeit blockiert, da es blocking auf einen Timeout gewartet hat (OK, muss ich ändern). Gleiches Thema, die ALIVE antworten vom LGW werden nicht rechtzeitig gesehen und es kommt zu reconnects.
Die Moral von der Geschicht: blockiere FHEM nicht.
Wer also auf solche "unerklärliche" "reappeared" stößt (hatte gerade kürzlich jemand berichtet) sollte mal checken, ob er etwas hat, das FHEM länger blockiert als der Timeout des LaCrosseGatway-Device eingestellt ist.
Bevor nun "reappeared-Panik" aufkommt: es gibt natürlich auch welche, die gerechtfertigt sind, wenn z.B. der AccessPoint mal weg war, das LGW neu bootet usw.
Ach ja, wer das Watchdog Attribut gesetzt hat, was ja bewirkt, dass das LGW einen Reboot macht, wenn es zu lange nichts von FHEM hört, der hat in so einem Fall natürlich auch noch jede Menge LGW reboots dazu.
Hallo HCS,
ich habe gestern das LGW neu gestartet und extra nicht auf das Web-Interface zugegriffen. Leider ist es auch jetzt nicht mehr erreichbar bzw. sendet es keine Daten mehr an FHEM.
Zitat von: HCS am 21 Mai 2017, 08:47:36
Ach ja, wer das Watchdog Attribut gesetzt hat, was ja bewirkt, dass das LGW einen Reboot macht, wenn es zu lange nichts von FHEM hört, der hat in so einem Fall natürlich auch noch jede Menge LGW reboots dazu.
Das könnte mir doch im Moment zumindest etwas helfen, damit die beiden wieder miteinander sprechen. Wobei es das Problem nicht löst.
Gruß
Olly
Gesendet von meinem Nexus 7 mit Tapatalk
Edit: Ohne das ich was gemacht habe empfängt FHEM zur Zeit wieder Daten vom LGW. Ich Raff es nicht...😣
Zitat von: Olly am 19 Mai 2017, 22:24:20
Dann könnte das -> https://github.com/esp8266/Arduino/issues/2330 interessant sein.
Es gibt seit dieser Woche einen Prototyp vom Arduino Core, der das SDK 2.1.0 verwendet, in dem das von Dir verwiesene "ARP-Problem" behoben sein soll.
Ich habe mal einen LGW-Prototyp auf diesem SDK compiliert und nach einigen kleineren Anpassungen zum Laufen bekommen.
Angehängt eine V1.31 Beta-Test-Version. Mit der könntest Du mal probieren, ob damit das Problem bei Dir weg ist.
Musst natürlich alle "lebenserhaltende Maßnahmen", die Du eventuell ergriffen hast, für den Test rückgängig machen.
Eigentlich wollte ich ja die Firmware anhängen, aber ich bekomme es den ganzen Tag schon nicht gespeichert >:(
Ich poste jetzt mal den Text und schaue, ob ich sie dann dran bekomme
Edit 1: nö, nicht mal das schnöde png bekomme ich dran
Edit 2: nun hat es geklappt.
So, jetzt ist auch der Anhang dran.
Hallo HCS,
ich war in der Zwischenzeit auch nicht untätig. Mit dem gesetzten Watchdog hat es dann das Gateway resettet, wenn die Kommunikation zu FHEM unterbrochen war. Schon Mal ein Schritt in die richtige Richtung aber ist natürlich keine Lösung für das Problem. Auch für den integrierten CUL ist das nicht so dolle.
Ich hab dann Mal einen anderen AccessPoint ausprobiert, hätte noch so ein "SteckdosenDing" was als Repeater, AccessPoint oder Client arbeitet.
Damit läuft das LGW schon deutlich besser. Bis heute Mittag keine Aussetzer oder reboots. Sowohl FHEM hat Zugriff als auch das Web-Interface ist erreichbar. Läuft jetzt 2 Tage und 5 Stunden. Wobei gerade wo ich dies schreibe wieder kein Zugriff auf das Web-Interface möglich ist 😥
CUL und KeyValueProtocol sind aber aus FHEM noch erreichbar.
Ich werde dann auch deine Beta Mal ausprobieren.
Danke & Gruß
Olly
Gesendet von meinem Nexus 7 mit Tapatalk
Gibt es beim FHEM Modul eine Änderung? Seit dem heutigen Update steht als State "Opened" da und nicht mehr "Initialized"
habe auch heute Update gemacht, alles OK
state initialized 2017-05-29 11:03:32
Gruß
Zitat von: gloob am 29 Mai 2017, 10:21:21
Gibt es beim FHEM Modul eine Änderung? Seit dem heutigen Update steht als State "Opened" da und nicht mehr "Initialized"
Die Frage ist: Änderung gegen wann und welches (36_JeeLink oder 36_LaCrosseGateway)?
Das LaCrosseGateway-Modul hat sich 2017-04-23 20:29:13Z zuletzt geändert.
Hallo HCS,
ich habe gestern Abend die 1.31 auf meinem LGW installiert und ihn wieder mit meinem "Problem-AccessPoint" verbunden. Effekt ist so wie mit der 1.25 bzw. 1.30: Nach kurzer Zeit hat bereits der Watchdog zugeschlagen und das Gateway resettet. Ebenso war auch das Web-Interface nach kurzer Zeit wieder nicht erreichbar.
Scheint also so, dass mein Problem nicht mit der neuen IDE behoben wird.
Ich hab das jetzt wieder mit meinem Zweit-AccessPoint verbunden. Schaue dann mal, wie gut das da läuft.
Gruß
Olly
Gesendet von meinem Nexus 7 mit Tapatalk
Zitat von: Olly am 30 Mai 2017, 20:49:06
Scheint also so, dass mein Problem nicht mit der neuen IDE behoben wird.
Das ist schade.
Mit diesem Problem hast Du definitiv ein Alleistellungsmerkmal :)
Zitat von: PeMue am 25 Mai 2017, 11:37:22
mittlerweile sind fast 100 der LGW Platinen verschickt.
Wenn man dann noch die "Konkurenzplatinen" und die "platinenlosen" dazu nimmt, sind so viele LGW in Betrieb, dass ein generelles Problem sicher schon bei anderen auch aufgetreten wäre.
Was man auch so langsam nicht völlig ausschließen kann, ist ein Hardware-Problem
- Lötstelle, die nach einiger Betriebszeit bei Erwärmung ein Problem macht
- Der ESP8266 hat irgend ein Hardwareproblem
- Die Spannungsversorgung macht Probleme
Um sicher zu erkennen, ob das ein Problem in Deiner Netzwerkumgebung ist, müsste man das LGW mal in einer Umgebung laufen lassen, in der andere LGWs ohne Probleme funktionieren.
Oder Du besorgst Dir ein DevKit um mal ein zweites LGW in Betrieb zu nehmen. Es läuft auch ohne angeschlossene RFMs, wir wollen ja nur wissen, ob das WebFrontend erreichbar bleibt.
Hier z.B.:
http://www.watterott.com/de/NodeMcu-Lua-WIFI-Board-Based-on-ESP8266-CP2102-Module
http://www.exp-tech.de/nodemcu-v2-lua-based-esp8266
Das kannst Du pur wie es ist flashen und in Betrieb nehmen, empfängt dann halt keine Sensoren aber sendet KVP vor sich hin und stellt das WebFrontend bereit.
Ich stochere aber nur im Nebel rum. Um der Sache auf die Spur zu kommen, werden wir nicht drum rum kommen, einige Dinge zu testen um mögliche Ursachen auszuschließen.
Moin
Ich habe noch devkits, die mir der nette Chinese falsch geschickt hat. Da kann ich eins zum Selbstkostenpreis abgeben!
Gruss Christoph
P.S.: Bei mir laufen die Beiden seit Wochen problemlos!
Zitat von: pc1246 am 31 Mai 2017, 09:32:58
Ich habe noch devkits, die mir der nette Chinese falsch geschickt hat. Da kann ich eins zum Selbstkostenpreis abgeben!
Gruss Christoph
P.S.: Bei mir laufen die Beiden seit Wochen problemlos!
Das wäre ein super Test. Nachweislich korrekt funktionierende Hardware in die "Olly-Umgebung" bringen, was dann passiert.
Und der "netter Chinese" -Preis ist vermutlich weniger als wir in diesem Thread schon Strom verbraucht haben ... ;D ;D
@pc1246: würdet Du es ihm dann in bereits geflashtem Zustand geben, dass wir auch da ein Fehlerquelle ausschließen können?
@HCS
Klar, probiere den dann auch vorher aus, damit er dann nicht einen defekten erhaelt. Das Problem hatte ich schon mal mit einem Nano, allerdings erst nach dem Aufloeten gemerkt!
@Olli
Ich schau mal nach was der mich gekostet hat, war irgendwas um die €3,-
Gruss Christoph
Ui....
da ist man ein paar Stunden nicht online und hier gibt's ne Menge neues.
Erst mal vielen Dank, dass ihr mir bei meinem scheinbar doch recht extravaganten Problem helfen wollt.
An Probleme mit der Spannungsversorgung hab ich auch schon gedacht. Hab das LGW an 2 verschiedenen USB-Netzteilen (eins mit 2A) und einer USB-Powerbank probiert. Effekt bei allen gleich.
Hardwaredefekt will ich nicht ausschließen, nur warum treten die Probleme in meinem "normalen" Netz früher auf als im Testnetz???
Danke an pc1246 für das Angebot zu den Devkits. Ich habe selbst einige NodeMCU zu liegen. Einer davon ist bevor ich das LGW von Locutus bekommen habe ja auch bereits mit einem RFM69CW gelaufen, allerdings noch mit einer uralt FW (1.05). Diesen NodeMCU hab ich jetzt auch mal mit der 1.31 geflasht und in mein "Problem-Netz" gebracht. Ich werde mal schauen, was damit passiert.
Gruß
Olly
Na dann laeuft es ja bei Dir!
War ja nur gut gemeint. Ich hatte ja auch mal so ein seltsames Problem, lag dann aber an mir selbst, da zwei fhems was unterschiedliches vom GW wollten.
Viel Erfolg noch
Gruss Christoph
Zitat von: pc1246 am 31 Mai 2017, 22:56:17
Na dann laeuft es ja bei Dir!
War ja nur gut gemeint. Ich hatte ja auch mal so ein seltsames Problem, lag dann aber an mir selbst, da zwei fhems was unterschiedliches vom GW wollten.
Viel Erfolg noch
Gruss Christoph
Hallo Christoph,
vielen Dank auf jeden Fall für das Angebot. Ist ja immer gut, wenn man Hilfe angeboten bekommt. Ich werde erst Mal meine Möglichkeiten ausschöpfen.
Gruß
Olly
Gesendet von meinem Nexus 7 mit Tapatalk
So,
aktueller Status:
Das LGW von Locutus läuft in meinem Testnetz seit ca. 24h, ist immer noch per Web erreichbar.
Die NodeMCU in meinem Problemnetz war gestern Abend um 23:30 schon nicht mehr per Web erreichbar, die letzte Meldung vom KeyValueProtocol ist um 2 Uhr nachts reingekommen. Seit dem ist Funkstille 😥
Das Verhalten tritt also genauso mit der NodeMCU auf.
Es scheint irgendwie mit dem AccessPoint zusammen zu hängen, denn beide AccessPoints hängen LAN-seitig im gleichen Netz, spannen nur jeder sein eigenes WLAN auf.
Ich werde jetzt erst Mal schauen, wie stabil das im Testnetz wirklich läuft.
Gruß
Olly
Gesendet von meinem Nexus 7 mit Tapatalk
Hallo,
Das Keyvalueprotokoll müllt mir mein Log-Verzeichnis zu.
Kann man das ausschalten? Es wird immer wieder neu angelegt!!!
Den Nutzen bei einem laufenden System kann ich aktuell nicht nachvollziehen. Mir wäre aktuell sehr lieb, es einfach weg zu bekommen.
Vielen Dank vorab!
Manuel
Zitat von: mele am 05 Juni 2017, 09:49:06
Hallo,
Das Keyvalueprotokoll müllt mir mein Log-Verzeichnis zu.
Kann man das ausschalten? Es wird immer wieder neu angelegt!!!
Den Nutzen bei einem laufenden System kann ich aktuell nicht nachvollziehen. Mir wäre aktuell sehr lieb, es einfach weg zu bekommen.
Vielen Dank vorab!
Manuel
Hallo,
du kannst es auf der Setup-Page vom LGW deaktivieren (KV-Intervall auf Off setzen).
Gruß
Olly
Edit: UPS, HCS war schneller....
Gesendet von meinem Nexus 7 mit Tapatalk
Vielen Dank euch. Habs erledigt!
Moin,
ich habe ein ähnliches Problem.
Ich habe mir diesen Stick hier gekauft:
http://www.ebay.de/itm/282483481108?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
mit V1.27.
Eingesteckt, eingerichtet lief...
Update auf die aktuelle Version gemacht über FHEM, danach wurde der BMP180 nicht mehr erkannt und ich komme so gut wie nie auf die Weboberfläche des Sticks.
Im WLan wird er dann auch nicht angezeigt.
Das passiert bereits nach kurzer Zeit.
Also ich hab mit meinem Gateway mit der V29, V30 usw keine Probleme.
Meine Gateways bestehen nur aus einem Funkmodul und einem Wemos. Vielleicht liegt es doch an der Hardware.
Zitat von: Starsurfer am 07 Juni 2017, 06:34:57
Ich habe mir diesen Stick hier gekauft:
http://www.ebay.de/itm/282483481108?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
Das sieht ja spannend aus. Sind da RFM69HW drauf?
Hat das nur eine Antenne? Da sind doch zwei RFM drauf?
Und der Titel der Auktion ist auch interessant:
ZitatWlan Lacrosse CUL-Gateway 868 Mhz für FHEM - 2 x RFM69CW's & BMP180
Was ist da wie CUL?
Vorschlag (wenn Du willst):
Pack es in einen Umschlag/Karton und schicke es mir zusammen mit einem frankierten Rücksendeaufkleber und ich lasse es bei mir in einer Umgebung laufen, in der mindesten 6 Produktiv- und Test-LGW problemlos laufen und wenn es rumzickt, kann ich mal drauf debuggen und schauen, was da vor sich geht.
Zitat von: gloob am 07 Juni 2017, 06:48:31
Vielleicht liegt es doch an der Hardware.
Die Optik drängt den Verdacht auf :)
Macht das den ein Unterschied ob CW oder HW?
Sorry wegen der Frage, aber ich fange mit FHEM gerade erst an.
Wenn ich heute Abend zu Hause bin werde ich Mal schauen, ob man auf den Dingern was erkennen kann. Antenne ist nur eine drauf.
Habe ich die Möglichkeit das Ding per arduino IDE zu debuggen?
Ansonsten kann ich dir den ja Mal zuschicken.
Welches wäre den der richtige Stick um intetechno Steckdosen, Lacrosse Sensoren und hometatik zu benutzen?
Kleine Rückmeldung,
das Ding läuft jetzt ab und zu muss aber ständig von FHEM angepingt werden:
2017.06.07 19:50:39 5: LaCrosseGateway01: dispatch OK 9 9 129 4 221 52
2017.06.07 19:50:40 5: LaCrosseGateway01: dispatch OK 9 22 129 4 213 51
2017.06.07 19:50:44 5: LaCrosseGateway01: dispatch OK 9 9 129 4 222 52
2017.06.07 19:50:44 5: LaCrosseGateway01: dispatch OK 9 22 129 4 213 51
2017.06.07 19:50:46 5: LaCrosseGateway01: dispatch OK WS 0 4 5 80 255 255 255 255 255 255 255 255 255 0 3 244
2017.06.07 19:50:46 5: LaCrosseGateway01: dispatch OK VALUES LGW 3200573 UpTimeSeconds=6926,UpTimeText=0Tg. 1Std. 55Min. 26Sek. ,WIFI=LB-SD,ReceivedFrames=2248,FramesPerMinute=26,RSSI=-57,FreeHeap=16984,LD.Min=0.21,LD.Avg=0.21,LD.Max=22.32,OLED=none
2017.06.07 19:50:48 5: LaCrosseGateway01: dispatch OK 9 9 129 4 222 52
2017.06.07 19:50:48 5: LaCrosseGateway01: dispatch OK 9 22 129 4 213 51
2017.06.07 19:50:49 5: SW: "WATCHDOG Ping"
2017.06.07 19:50:49 1: 192.168.178.147:81 reappeared (LaCrosseGateway01)
2017.06.07 19:50:52 5: SW: v
2017.06.07 19:51:02 5: SW: "WATCHDOG Ping"
2017.06.07 19:51:39 5: SW: "WATCHDOG Ping"
2017.06.07 19:51:39 1: 192.168.178.147:81 reappeared (LaCrosseGateway01)
2017.06.07 19:51:42 5: SW: v
Die TX 29 Sensoren werden nach einer gefühlten Ewigkeit auch angezeigt.
Zitat von: Starsurfer am 07 Juni 2017, 14:12:51
Macht das den ein Unterschied ob CW oder HW?
Eigentlich sollten beide funktionieren
Aber: Bundesnetzagentur Vfg 30/2014 sagt, dass SRDs im Bereich von 868,000 - 868,600 MHz mit maximal 25 mW senden dürfen.
Der RFM69CW sendet mit maximal +13 dBm, was ca. 20mW entspricht.
Ein RFM69HW sendet mit +20dBm, was 100mW entspricht.
Zitat von: Starsurfer am 07 Juni 2017, 14:12:51
Antenne ist nur eine drauf.
Wie soll das denn gehen?
Zwei Radios und nur eine Antenne :o
Kannst Du mal den Inhalt der Hardware-Page hier anhängen?
Und einen "list LaCrosseGateway01"
Zitat von: Starsurfer am 07 Juni 2017, 14:12:51
Welches wäre den der richtige Stick um intetechno Steckdosen, Lacrosse Sensoren und hometatik zu benutzen?
Keine Ahnung.
Mit dem, was Du hast, kannst Du LaCrosse, EC3000 und PCA301 empfangen.
Mit einem weiter ausgebauten LGW auch Homematic und / oder FS20
Intertechno nicht.
Wie mache ich das den mit der Hardware Page?
Internals:
Alive 2017-06-08 04:52:41
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF 192.168.178.147:81
DeviceName 192.168.178.147:81
FD 37
LaCrosseGateway01_MSGCNT 220
LaCrosseGateway01_TIME 2017-06-08 04:52:50
NAME LaCrosseGateway01
NR 119
PARTIAL
RAWMSG OK 9 9 1 4 178 65
STATE opened
TIMEOUT 0.5
TYPE LaCrosseGateway
model [LaCrosseITPlusReader.Gateway.1.30 (1=RFM69 f:868300 r:17241) + (3=RFM69 f:868300 r:8842) + BMP180 {IP=192.168.178.147}]
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-06-08 06:08:38 state opened
Helper:
Attributes:
icon cul
room Büro,KeyValueProtocol
timeout 120
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
verbose 5
Zitat von: Starsurfer am 08 Juni 2017, 06:12:21
Wie mache ich das den mit der Hardware Page?
Du gehst auf die (Web)-Seite Deines LGWs, loggst Dich ein (falls ein Passwort gesetzt ist, was hoffentlich der Fall ist ;)) und klickst Da auf Hardware, siehe Bild.
Gruß PeMue
Zitat von: PeMue am 08 Juni 2017, 06:44:30
falls ein Passwort gesetzt ist, was hoffentlihc der Fall ist
Wenn man seiner Frau nicht misstraut und IP:80 vom LGW nicht nach draußen weiterleitet, ist das übetriebener Sicherheitswahn ;D ;D
Aber jeder natürlich wie er will.
Zitat von: Starsurfer am 08 Juni 2017, 06:12:21
model [LaCrosseITPlusReader.Gateway.1.30 (1=RFM69 f:868300 r:17241) + (3=RFM69 f:868300 r:8842) + BMP180 {IP=192.168.178.147}]
Die Hardware wurde ja komplett erkannt, auch der BMP180.
Was für einen AccessPoint hast Du?
Hardware Page:
ZitatESP8266 present :-) Core: 2_3_0 SDK: 1.5.3(aec24ac9) free heap: 14984 Reset: Software/System restart -> Fatal exception:0 flag:4 (SOFT_RESTART) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
WiFi -38 dBm Mode: Station Time to connect: 5.3 s
Radio #1 RFM69 868300 kHz data rate: 17241 kbps
Radio #2 ---
Radio #3 RFM69 868300 kHz data rate: 8842 kbps
Radio #4 ---
Radio #5 ---
SHT75 ---
BME280 ---
BMP180 OK T=33.4 P=1015 Calibration: AC1:9015 AC2:-1175 AC3:-14237 AC4:34059 AC5:25869 AC6:18550 B1:6515 B2:46 MB:-32768 MC:-11786 MD:2291 ADC: T=28360 P=171232
DHT22 ---
LM75 ---
SC16IS750 (0x90) ---
SC16IS750 (0x92) ---
MCP23008 ---
OLED ---
DataPort #1 81
DataPort #2 ---
DataPort #3 ---
Serial-bridge #1 ---
Serial-bridge #2 ---
Soft-bridge ---
Nextion ---
Analog port Disabled ADC=3 U=4294967295 mV (0 ... 0 mV)
Fritzbox 6390 als Router und eine 7270v3 als Repeater beide gleiche SSID und Passwort.
Liegt es eventuell am Repeater, das er damit Probleme hat?
Wie gesagt er scheint zu senden, scheint aber unregelmäßig nicht erreichbar zu sein.
Zitat2017.06.08 17:44:11 1: 192.168.178.147:81 reappeared (LaCrosseGateway01)
2017.06.08 17:44:14 5: SW: v
2017.06.08 17:44:15 5: LaCrosseGateway01: dispatch OK WS 0 4 5 63 255 255 255 255 255 255 255 255 255 0 3 248
2017.06.08 17:44:15 5: LaCrosseGateway01: dispatch OK 9 9 1 4 176 61
2017.06.08 17:44:15 5: LaCrosseGateway01: dispatch OK VALUES LGW 3200573 UpTimeSeconds=85304,UpTimeText=0Tg. 23Std. 41Min. 44Sek. ,WIFI=LB-SD,ReceivedFrames=45680,FramesPerMinute=24,RSSI=31,FreeHeap=17224,LD.Min=0.21,LD.Avg=63.19,LD.Max=18394.90,OLED=none
2017.06.08 17:44:15 5: LaCrosseGateway01: dispatch OK 9 38 1 4 173 61
2017.06.08 17:44:15 5: LaCrosseGateway01: dispatch OK 9 22 1 4 205 51
2017.06.08 17:44:15 5: LaCrosseGateway01: dispatch OK 9 23 1 4 160 67
2017.06.08 17:44:17 5: SW: "WATCHDOG Ping"
2017.06.08 17:44:17 5: SW: "WATCHDOG Ping"
2017.06.08 17:44:18 5: SW: "WATCHDOG Ping"
2017.06.08 17:44:19 5: LaCrosseGateway01: dispatch OK 9 23 1 4 160 67
2017.06.08 17:44:19 5: LaCrosseGateway01: dispatch OK 9 22 1 4 205 51
2017.06.08 17:44:21 5: LaCrosseGateway01: dispatch OK 9 9 1 4 176 61
2017.06.08 17:44:23 5: LaCrosseGateway01: dispatch OK 9 38 1 4 173 61
2017.06.08 17:44:23 5: LaCrosseGateway01: dispatch OK 9 22 1 4 205 51
2017.06.08 17:44:25 5: SW: "WATCHDOG Ping"
2017.06.08 17:44:25 5: LaCrosseGateway01: dispatch OK WS 0 4 5 63 255 255 255 255 255 255 255 255 255 0 3 247
2017.06.08 17:44:25 5: LaCrosseGateway01: dispatch OK VALUES LGW 3200573 UpTimeSeconds=85746,UpTimeText=0Tg. 23Std. 49Min. 6Sek. ,WIFI=LB-SD,ReceivedFrames=45964,FramesPerMinute=34,RSSI=-38,FreeHeap=16824,LD.Min=0.21,LD.Avg=0.22,LD.Max=31.10,OLED=none
2017.06.08 17:44:27 5: LaCrosseGateway01: dispatch OK 9 23 1 4 160 67
2017.06.08 17:44:28 5: LaCrosseGateway01: dispatch OK 9 22 1 4 205 52
2017.06.08 17:44:31 5: LaCrosseGateway01: dispatch OK 9 38 1 4 173 61
2017.06.08 17:44:32 5: LaCrosseGateway01: dispatch OK 9 22 1 4 205 52
2017.06.08 17:44:32 5: SW: "WATCHDOG Ping"
2017.06.08 17:44:37 5: SW: "WATCHDOG Ping"
2017.06.08 17:44:40 5: SW: "WATCHDOG Ping"
2017.06.08 17:44:52 5: SW: "WATCHDOG Ping"
2017.06.08 17:45:01 5: SW: "WATCHDOG Ping"
2017.06.08 17:45:02 5: SW: "WATCHDOG Ping"
2017.06.08 17:45:05 5: SW: "WATCHDOG Ping"
2017.06.08 17:45:10 5: SW: "WATCHDOG Ping"
2017.06.08 17:45:19 5: SW: "WATCHDOG Ping"
2017.06.08 17:45:34 5: SW: "WATCHDOG Ping"
2017.06.08 17:45:37 5: SW: "WATCHDOG Ping"
2017.06.08 17:45:41 5: SW: "WATCHDOG Ping"
2017.06.08 17:46:10 5: SW: "WATCHDOG Ping"
2017.06.08 17:46:17 5: SW: "WATCHDOG Ping"
2017.06.08 17:46:17 5: SW: "WATCHDOG Ping"
2017.06.08 17:46:18 5: SW: "WATCHDOG Ping"
2017.06.08 17:46:25 5: SW: "WATCHDOG Ping"
2017.06.08 17:46:32 5: SW: "WATCHDOG Ping"
2017.06.08 17:46:37 5: SW: "WATCHDOG Ping"
2017.06.08 17:46:40 5: SW: "WATCHDOG Ping"
2017.06.08 17:46:52 5: SW: "WATCHDOG Ping"
2017.06.08 17:47:01 5: SW: "WATCHDOG Ping"
2017.06.08 17:47:02 1: 192.168.178.147:81 reappeared (LaCrosseGateway01)
2017.06.08 17:47:02 5: SW: "WATCHDOG Ping"
2017.06.08 17:47:05 5: SW: v
2017.06.08 17:47:05 5: SW: "WATCHDOG Ping"
2017.06.08 17:47:10 5: SW: "WATCHDOG Ping"
2017.06.08 17:47:18 2: ROOMMATE set rr_Sascha home
2017.06.08 17:47:19 5: SW: "WATCHDOG Ping"
2017.06.08 17:47:34 5: SW: "WATCHDOG Ping"
2017.06.08 17:47:37 5: SW: "WATCHDOG Ping"
2017.06.08 17:47:41 5: SW: "WATCHDOG Ping"
2017.06.08 17:48:10 5: SW: "WATCHDOG Ping"
2017.06.08 17:48:17 5: SW: "WATCHDOG Ping"
2017.06.08 17:48:17 5: SW: "WATCHDOG Ping"
2017.06.08 17:48:18 5: SW: "WATCHDOG Ping"
2017.06.08 17:48:25 5: SW: "WATCHDOG Ping"
2017.06.08 17:48:32 5: SW: "WATCHDOG Ping"
2017.06.08 17:48:37 5: SW: "WATCHDOG Ping"
2017.06.08 17:48:40 5: SW: "WATCHDOG Ping"
2017.06.08 17:48:52 5: SW: "WATCHDOG Ping"
2017.06.08 17:49:01 5: SW: "WATCHDOG Ping"
2017.06.08 17:49:02 5: SW: "WATCHDOG Ping"
2017.06.08 17:49:02 1: 192.168.178.147:81 reappeared (LaCrosseGateway01)
2017.06.08 17:49:05 5: SW: "WATCHDOG Ping"
2017.06.08 17:49:06 5: SW: v
2017.06.08 17:49:08 5: LaCrosseGateway01: dispatch OK WS 0 4 5 63 255 255 255 255 255 255 255 255 255 0 3 247
2017.06.08 17:49:08 5: LaCrosseGateway01: dispatch OK VALUES LGW 3200573 UpTimeSeconds=85756,UpTimeText=0Tg. 23Std. 49Min. 16Sek. ,WIFI=LB-SD,ReceivedFrames=45968,FramesPerMinute=33,RSSI=-38,FreeHeap=17192,LD.Min=0.18,LD.Avg=0.21,LD.Max=19.59,OLED=none
2017.06.08 17:49:08 5: LaCrosseGateway01: dispatch OK 9 23 1 4 160 67
2017.06.08 17:49:08 5: LaCrosseGateway01: dispatch OK 9 22 1 4 205 51
2017.06.08 17:49:08 5: LaCrosseGateway01: dispatch OK 9 9 1 4 176 61
2017.06.08 17:49:08 5: LaCrosseGateway01: dispatch OK 9 38 1 4 173 61
2017.06.08 17:49:08 5: LaCrosseGateway01: dispatch OK 9 23 1 4 160 67
2017.06.08 17:49:08 5: LaCrosseGateway01: dispatch OK 9 22 1 4 205 51
2017.06.08 17:49:08 5: LaCrosseGateway01: dispatch OK WS 0 4 5 63 255 255 255 255 255 255 255 255 255 0 3 247
2017.06.08 17:49:08 5: LaCrosseGateway01: dispatch OK VALUES LGW 3200573 UpTimeSeconds=85766,UpTimeText=0Tg. 23Std. 49Min. 26Sek. ,WIFI=LB-SD,ReceivedFrames=45974,FramesPerMinute=33,RSSI=31,FreeHeap=16912,LD.Min=0.20,LD.Avg=0.20,LD.Max=8.31,OLED=none
2017.06.08 17:49:08 5: LaCrosseGateway01: dispatch OK 9 9 1 4 176 61
2017.06.08 17:49:10 5: SW: "WATCHDOG Ping"
2017.06.08 17:49:11 5: LaCrosseGateway01: dispatch OK 9 38 1 4 172 61
2017.06.08 17:49:11 5: LaCrosseGateway01: dispatch OK 9 22 1 4 205 51
2017.06.08 17:49:12 5: LaCrosseGateway01: dispatch OK 9 23 1 4 160 67
2017.06.08 17:49:15 5: LaCrosseGateway01: dispatch OK 9 9 1 4 176 61
2017.06.08 17:49:15 5: LaCrosseGateway01: dispatch OK 9 38 1 4 173 61
2017.06.08 17:49:16 5: LaCrosseGateway01: dispatch OK WS 0 4 5 59 255 255 255 255 255 255 255 255 255 0 3 247
2017.06.08 17:49:16 5: LaCrosseGateway01: dispatch OK VALUES LGW 3200573 UpTimeSeconds=86037,UpTimeText=0Tg. 23Std. 53Min. 57Sek. ,WIFI=LB-SD,MacAddress=5C:CF:7F:30:D6:3D,ReceivedFrames=46132,FramesPerMinute=36,RSSI=-39,FreeHeap=16824,Version=1.30,LD.Min=0.20,LD.Avg=0.21,LD.Max=24.76,OLED=none
2017.06.08 17:49:19 5: SW: "WATCHDOG Ping"
2017.06.08 17:49:19 5: LaCrosseGateway01: dispatch OK 9 38 1 4 173 61
2017.06.08 17:49:20 5: LaCrosseGateway01: dispatch OK 9 22 1 4 205 51
2017.06.08 17:49:20 5: LaCrosseGateway01: dispatch OK 9 23 1 4 160 67
2017.06.08 17:49:23 5: LaCrosseGateway01: dispatch OK 9 9 1 4 176 61
2017.06.08 17:49:24 5: LaCrosseGateway01: dispatch OK 9 38 1 4 173 61
2017.06.08 17:49:26 5: LaCrosseGateway01: dispatch OK WS 0 4 5 59 255 255 255 255 255 255 255 255 255 0 3 248
2017.06.08 17:49:26 5: LaCrosseGateway01: dispatch OK VALUES LGW 3200573 UpTimeSeconds=86047,UpTimeText=0Tg. 23Std. 54Min. 7Sek. ,WIFI=LB-SD,ReceivedFrames=46137,FramesPerMinute=34,RSSI=-39,FreeHeap=16824,LD.Min=0.21,LD.Avg=0.21,LD.Max=18.51,OLED=none
2017.06.08 17:49:28 5: LaCrosseGateway01: dispatch OK 9 22 1 4 205 52
2017.06.08 17:49:28 5: LaCrosseGateway01: dispatch OK 9 23 1 4 160 67
2017.06.08 17:49:31 5: LaCrosseGateway01: dispatch OK 9 9 1 4 176 61
2017.06.08 17:49:32 5: LaCrosseGateway01: dispatch OK 9 22 1 4 205 51
2017.06.08 17:49:32 5: LaCrosseGateway01: dispatch OK 9 38 1 4 173 61
2017.06.08 17:49:34 5: SW: "WATCHDOG Ping"
2017.06.08 17:49:36 5: LaCrosseGateway01: dispatch OK 9 22 1 4 205 51
2017.06.08 17:49:36 5: LaCrosseGateway01: dispatch OK WS 0 4 5 58 255 255 255 255 255 255 255 255 255 0 3 247
2017.06.08 17:49:36 5: LaCrosseGateway01: dispatch OK VALUES LGW 3200573 UpTimeSeconds=86057,UpTimeText=0Tg. 23Std. 54Min. 17Sek. ,WIFI=LB-SD,ReceivedFrames=46143,FramesPerMinute=35,RSSI=-39,FreeHeap=16760,LD.Min=0.21,LD.Avg=0.21,LD.Max=25.08,OLED=none
2017.06.08 17:49:36 5: LaCrosseGateway01: dispatch OK 9 38 1 4 173 61
2017.06.08 17:49:37 5: LaCrosseGateway01: dispatch OK 9 23 1 4 160 67
2017.06.08 17:49:37 5: SW: "WATCHDOG Ping"
2017.06.08 17:49:39 5: LaCrosseGateway01: dispatch OK 9 9 1 4 176 61
2017.06.08 17:49:40 5: LaCrosseGateway01: dispatch OK 9 22 1 4 205 51
2017.06.08 17:49:41 5: LaCrosseGateway01: dispatch OK 9 38 1 4 172 61
2017.06.08 17:49:41 5: SW: "WATCHDOG Ping"
2017.06.08 17:50:10 5: SW: "WATCHDOG Ping"
2017.06.08 17:50:17 5: SW: "WATCHDOG Ping"
2017.06.08 17:50:17 5: SW: "WATCHDOG Ping"
2017.06.08 17:50:18 5: SW: "WATCHDOG Ping"
2017.06.08 17:50:25 5: SW: "WATCHDOG Ping"
2017.06.08 17:50:32 5: SW: "WATCHDOG Ping"
2017.06.08 17:50:37 5: SW: "WATCHDOG Ping"
2017.06.08 17:50:40 5: SW: "WATCHDOG Ping"
Ist mir als Laie gerade aufgefallen (da ich gestern eine Anfrage diesbezüglich hatte an HCS):
Radio 3 UND DHT22 können NICHT zusammen betrieben werden. Immer nur Radio 3 ODER DHT22. Inwieweit es ein BMP180 betrifft anstelle des DHT22... wäre das eine mögliche Fehlerquelle?
-------------------------------
Radio #1 RFM69 868300 kHz data rate: 17241 kbps
Radio #2 ---
Radio #3 RFM69 868300 kHz data rate: 8842 kbps
Radio #4 ---
Radio #5 ---
SHT75 ---
BME280 ---
BMP180 OK T=33.4 P=1015 Calibration: AC1:9015 AC2:-1175 AC3:-14237 AC4:34059 AC5:25869 AC6:18550 B1:6515 B2:46 MB:-32768 MC:-11786 MD:2291 ADC: T=28360 P=171232
-----------------------------------------
Gruss
Alex
Zitat von: bitbiter am 09 Juni 2017, 11:10:40
Radio 3 UND DHT22 können NICHT zusammen betrieben werden. Immer nur Radio 3 ODER DHT22. Inwieweit es ein BMP180 betrifft anstelle des DHT22... wäre das eine mögliche Fehlerquelle?
Nein. Alles was an I2C dran ist (BMP180, BME280, LM75, ...) hat nichts mit den Radios zu tun.
Der DHT22 ist ein Spezialfall, weil keine Ports mehr frei waren und aus diesem Grund man sich für Radio3 oder DHT22 entscheiden muss.
Arrrrggghh
Ich schmeiß das Ding gleich aus dem Fenster...
Hat zufällig jemand ein fertiges und getestetes Gateway über?
Angebote mit Preis bitte per PM an mich.
Zitat von: Starsurfer am 14 Juni 2017, 21:56:25Ich schmeiß das Ding gleich aus dem Fenster...
Das Angebot steht noch. Das interessiert mich nun doch, wo es da klemmt:
Zitat von: HCS am 07 Juni 2017, 12:59:04
Vorschlag (wenn Du willst):
Pack es in einen Umschlag/Karton und schicke es mir zusammen mit einem frankierten Rücksendeaufkleber und ich lasse es bei mir in einer Umgebung laufen, in der mindesten 6 Produktiv- und Test-LGW problemlos laufen und wenn es rumzickt, kann ich mal drauf debuggen und schauen, was da vor sich geht.
Zitat von: Olly am 01 Juni 2017, 21:13:59
Ich werde jetzt erst Mal schauen, wie stabil das im Testnetz wirklich läuft.
Hast Du Erkenntnisse?
Ich habe alles, was ich an AccessPoints aufbieten konnte, am Laufen.
Fritzbox 7390
Asus RT-AC66U
TP-Link TL-WR1043ND (aus der Altmetallkiste im Keller nochmal ausgegraben :) )
An allen drei laufen nun jeweils mehrere LGW seit mindestens vier Tagen.
Ich hätte ja so gerne ein Problem, aber es ist mir nicht vergönnt, eins zu haben ;D
Hallo HCS,
das LGW läuft jetzt seit über 5 Tagen im Testnetz durch, ohne Fehler. Die NodeMCU im eigentlichen WLAN steigt nach kurzer Zeit aus. Werde das bei Gelegenheit auch noch Mal in dem anderen Netz testen.
Denke das Problem ist mein Tenda AccessPoint bzw. dessen Konfiguration.
Gruß
Olly
Gesendet von meinem Nexus 7 mit Tapatalk
Moin
<Offtopic>
Ich hatte auch mal einen Tenda USB-WLAN-Stick. Zuerst war ich ganz begeistert, dann hat der irgendwann angefangen rumzuspinnen, bis er dann gar nicht mehr ging. Nur gemerkt hat man das eigentlich gar nicht! Bis ich dann irgendwann einen anderen probiert habe, und alles wieder glatt lief! Haengen da denn keine anderen Teilnehmer dran?
</Offtopic>
Meine beiden laufen inzwischen seit Ewigkeiten ohne Probleme!
Gruss Christoph
Tja, so ist das halt....wer billig kauft, kauft 2x.
Natürlich hängen an dem AccessPoint noch andere Geräte dran. Die funktionieren aber irgendwie
Ich hab schon überlegt auf Ubiquiti umzusteigen, weil man da auch mit mehreren APs mit gleicher SSDID ein WLAN-Netz aufbauen kann.
Gruß
Olly
Zitat von: Starsurfer am 15 Juni 2017, 15:42:02
attr myLaCrosseGateway initCommands 1,868950,120i 3#2m 20#2t 220h 0a v
ich beantworte das mal hier und nicht per PM, dass alle was davon haben.
Deine Radios sind:
Zitat
Radio #1 RFM69 868300 kHz data rate: 17241 kbps
Radio #2 ---
Radio #3 RFM69 868300 kHz data rate: 8842 kbps
Radio #4 ---
Radio #5 ---
aber Du intialisiert Radio #2 (3#2m 20#2t) und dann auch noch vermutlich unnötierweise auf einen data rate toggle.
Die korrekten initCommands für LaCrosse und PCA301 sind in Deinem Fall:
attr myLaCrosseGateway initCommands 3,868950,120i 220h 0a vOder um sicher zu sein, dass Radio #1 uminitailisiert wird, wenn es nicht den default hatte:
attr myLaCrosseGateway initCommands 3,868950,120i 17241#1r 220h 0a vDamit bleibt Radio #1 auf 17.241 für LaCrosse und Radio#3 wird für PCA301 initialisiert.
Aber ohne Antenne wird wohl eins von beiden nicht besonders gut gehen.
Die 220h musst Du auf die Höhe über NN anpassen, wo Du wohnst, dass der BMP180 den richtig normalisierten Luftdruck liefert. Wenn Dein Ort also z.B. auf 300 Metern Meereshöhe liegt, dann 300h.
Danke, das war genau das was ich gesucht hatte.
Nur wie schon per PM geschrieben, bekomme ich momentan wieder keine Wlan Verbindung zu Stande.
Hi Leute.
Ich habe seit 2-3 Tagen das Problem, dass meine PCA301 Steckdosen nicht immer schalten. Hat seit mindestens einem halben Jahr Problemlos funktioniert. Hat sich in letzter Zeit was geändert?
Hier mal meine Daten:
Habe einen NODEMCU 1.0:
Internals:
Alive 2017-06-12 20:25:21
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF 192.168.188.60:81
DeviceName 192.168.188.60:81
FD 63
LaCrosseGatewayWlanPCA_MSGCNT 57378
LaCrosseGatewayWlanPCA_TIME 2017-06-18 12:45:57
NAME LaCrosseGatewayWlanPCA
NR 193
PARTIAL
RAWMSG OK 24 1 4 3 42 221 1 0 38 0 1
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model [LaCrosseITPlusReader.Gateway.1.25 (1=RFM69 f:868960 r:6631) {IP=192.168.188.60}]
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-06-18 12:45:57 state initialized
Helper:
Attributes:
initCommands 1,868960,120i v
room Gateways
timeout 120,30
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
LaCrosseGateway V1.25
Radio #1 RFM69 868960 kHz data rate: 6631 kbps
Vielleicht kann mir jemand weiter helfen?
Ich habe die Hardware schon getauscht gegen einen anderen NodeMCU mit RFM69 aber leider das selbe.
Muss ich vielleicht alle Steckdosen neu anlernen?
Danke schonmal und lieben Gruss Daniel
Zitat von: 2P4u am 18 Juni 2017, 12:55:10
Hat sich in letzter Zeit was geändert?
Die LGW-Firmware 1.25 hast Du ja wohl schon eine Zeit lang drauf, 36_PCA301.pm hat sich zuletzt am 22.08.2016 geändert, wenn Du also nichts geändert hast, lautet die Antwort "Nein".
Was mal noch interessant wäre: was auf der Setup-Page ganz unten bei PCA301 steht.
Zitat von: 2P4u am 18 Juni 2017, 12:55:10
Muss ich vielleicht alle Steckdosen neu anlernen?
Du schreibst "nicht immer schalten", woraus ich schließe, dass es manchmal geht.
Somit sind sie im System bekannt und müssen eher nicht neu angelernt werden.
Zitat von: HCS am 18 Juni 2017, 18:36:35
Die LGW-Firmware 1.25 hast Du ja wohl schon eine Zeit lang drauf, 36_PCA301.pm hat sich zuletzt am 22.08.2016 geändert, wenn Du also nichts geändert hast, lautet die Antwort "Nein".
Was mal noch interessant wäre: was auf der Setup-Page ganz unten bei PCA301 steht.
Du schreibst "nicht immer schalten", woraus ich schließe, dass es manchmal geht.
Somit sind sie im System bekannt und müssen eher nicht neu angelernt werden.
Hi HCS.
Hier mal was unter Setup steht:
0D8B5F=7,01A1CF=1,03F03B=3,0441BD=8,032ADD=1,09543C=3,069778=25,0E7D04=4Ja ich habe 23 PCA301 Steckdosen in Betrieb.
Manche lassen sich gar nicht mehr schalten und andere nur spradisch.
Hast du einen Tipp?
Hier mal ein List von einem Device was nicht mehr geht:
Internals:
DEF 0441BD 08
IODev LaCrosseGatewayWlanPCA
LASTInputDev LaCrosseGatewayWlanPCA
LaCrosseGatewayWlanPCA_MSGCNT 87
LaCrosseGatewayWlanPCA_TIME 2017-06-19 06:25:49
MSGCNT 87
NAME PCA_Kaffee
NR 202
PCA301_lastRcv 2017-06-19 06:25:49
PCA301_lastSend 2017-06-19 07:00:00
STATE set-off
TYPE PCA301
addr 0441BD
channel 08
Readings:
2017-06-18 18:17:11 consumption 3.14
2017-06-18 18:17:11 consumptionTotal 3.98
2017-06-19 06:25:49 power 0.4
2017-06-19 07:00:00 state set-off
Attributes:
IODev LaCrosseGatewayWlanPCA
alexaName Kaffeemaschine
alias Kaffeemaschine
devStateIcon on:black_Steckdose.on off:black_Steckdose.off toggle:Update
room PCA301,alexa
userReadings consumptionTotal:consumption.* monotonic {ReadingsVal($name,'consumption',0)}
webCmd on:off:toggle:statusRequest
Wie man sieht hätte es heute um 7 Uhr ausgeschaltet werden sollen.
Hallo 2P4u
Das sieht irgendwie seltsam aus! Du hast nur 8 steckdosen, und zwei haben auch noch die gleiche Adresse (1)! Die im 2. post ist dem Gateway aber bekannt und scheint um 6:25 auch noch empfangen worden zu sein!
Hast Du das GW schon mal stromlos gemacht?
Gruss Christoph
Zitat von: 2P4u am 19 Juni 2017, 09:41:48
0D8B5F=7,01A1CF=1,03F03B=3,0441BD=8,032ADD=1,09543C=3,069778=25,0E7D04=4
Ja ich habe 23 PCA301 Steckdosen in Betrieb.
Das passt wirklich nicht zu 23 Dosen.
Mach das mal auf der Setup-Page leer und speichere es.
Dann die Dosen einmal Vorort schalten (nicht lang drücken zum pairing), dass das LGW sie wieder lernt.
Dann schauen, ob sie wieder eingetragen sind.
Syntax ist: <ID der Dose>=<Kanal>
Hi Zusammen.
Genau das ist das komische.
Ich werde heute mal schauen und versuchen ob das wieder passt.
Aber wie das ganze passiert ist kann ich nicht sagen.
Zitat von: Olly am 30 Mai 2017, 20:49:06
ich habe gestern Abend die 1.31 auf meinem LGW installiert und ihn wieder mit meinem "Problem-AccessPoint" verbunden. Effekt ist so wie mit der 1.25 bzw. 1.30: Nach kurzer Zeit hat bereits der Watchdog zugeschlagen und das Gateway resettet. Ebenso war auch das Web-Interface nach kurzer Zeit wieder nicht erreichbar.
Scheint also so, dass mein Problem nicht mit der neuen IDE behoben wird.
Im entsprechenden issue im ESP8266 git werden auch gerade Stimmen laut, die der Ansicht sind, dass das Espressif SDK 2.1.0 das ARP-Problem nicht beheben würde.
Das bedeutet, dass falls Dein Problem das ARP-Problem ist, die 1.31 es nicht behebt, weil es im Espressif SDK doch nicht behoben ist.
Ich beobachte mal, wie es dort weiter geht.
Zitat von: HCS am 21 Juni 2017, 09:15:47
Im entsprechenden issue im ESP8266 git werden auch gerade Stimmen laut, die der Ansicht sind, dass das Espressif SDK 2.1.0 das ARP-Problem nicht beheben würde.
Das bedeutet, dass falls Dein Problem das ARP-Problem ist, die 1.31 es nicht behebt, weil es im Espressif SDK doch nicht behoben ist.
Ich beobachte mal, wie es dort weiter geht.
Ah, OK das hätte ich noch gar nicht gesehen. Dann besteht ja doch noch etwas Hoffnung... [emoji3]
Mit meinem Test-AccessPoint läuft es übrigens sehr gut. Nach über 7 Tagen das erste mal ein Neustart des LGW, aber auch direkt wieder nutzbar (CUL). Von daher erst mal unkritisch
Gruß
Olly
Zitat von: Olly am 21 Juni 2017, 12:11:49
Ah, OK das hätte ich noch gar nicht gesehen.
https://github.com/esp8266/Arduino/issues/2330#issuecomment-309789719
Zitat von: HCS am 21 Juni 2017, 12:19:49
https://github.com/esp8266/Arduino/issues/2330#issuecomment-309789719
Danke für den Link, ich halte auch mal ein Auge drauf.
Moin zusammen
Mir ist gerade etwas in den sinn gekommen. Zugegebenermassen habe ich den Thread nicht durchsucht!
Ist es moeglich auf den CUL-Teil die Signalduino Firmware zu flashen? Mein 433er hat eigentlich eh Langeweile, und ich habe da ein Projekt im Auge (Siro-Motoren https://forum.fhem.de/index.php/topic,12227.msg657620.html#msg657620), womit ich den dann beschaeftigen koennte!
Danke und Gruss
Christoph
Zitat von: pc1246 am 10 Juli 2017, 09:10:10
Ist es moeglich auf den CUL-Teil die Signalduino Firmware zu flashen?
Da sollte nichts dagegen sprechen. Die bridge ist transparent, ihr ist es also egal, was da drüber geschickt wird.
OTA sollte auch gehen, solange ein Arduino mit optiboot dran ist.
Musst nur im WebFrontend vom LGW die richtige baud rate für den Signalduino einstellen.
So weit die Theorie, ausprobiert habe ich es bisher nicht.
Was noch zu klären wäre ist, ob das Signalduino Modul in FHEM irgend eine "Reconnect-Geschichte" kann, um die Verbindung ggf. wieder herzustellen (also sinngemäß wie das timeout Attribut vom LaCrosseGateway-Modul)
Hallo HCS
Mal sehen, Donnerstag habe ich nichts vor, da werde ich das mal angehen!
Gruss Christoph
Hallo HCS,
ich habe gerade gesehen, dass das RFM69CW und die LoRa Module von HopeRF dasselbe Pinout (https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-breakouts/downloads) 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 8)
Danke + Gruß
PeMue
Zitat von: PeMue am 13 Juli 2017, 17:32:15
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.
Zitat von: HCS am 13 Juli 2017, 18:11:23
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
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)? ;D
LG
Holger
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
Zitat von: Omega am 14 Juli 2017, 11:58:50
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.
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
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
Zitat von: Omega am 15 Juli 2017, 08:42:18
Gibt es eigentlich eine Möglichkeit, die Empfangsqualität der Devices zu erkennen - als Hilfsmittel, das besser geeignete LGW zuzuweisen?
Leider nicht
Zitat von: pc1246 am 19 Juli 2017, 21:34:56
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.
Zitat von: pc1246 am 19 Juli 2017, 21:34:56
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.
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
Zitat von: pc1246 am 21 Juli 2017, 00:31:01
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.
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
Zitat von: HCS am 21 Juli 2017, 16:53:43
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
@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?
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.
Zitat von: locutus am 22 Juli 2017, 13:40:25
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.
Das wäre in der LGW-Software vermutlich kein großes Thema, aber auf den bereits bestehenden Platinen vermutlich nicht so einfach zu ergänzen.
Aber dann könnte man den CUL nach belieben ein- / ausschalten.
Zitat von: locutus am 22 Juli 2017, 11:15:06
Schuld an dem Verhalten ist der Arduino Bootloader.
Das bedeutet aber, dass irgend wann von FHEM aus ein "B" geschickt wird. Das könnte man doch im CUL Modul unterdrücken, wenn man eine Konfigurationsoption hätte, dass es ein nano oder mini ist?
Zitat von: HCS am 22 Juli 2017, 18:32:33
Das bedeutet aber, dass irgend wann von FHEM aus ein "B" geschickt wird. Das könnte man doch im CUL Modul unterdrücken, wenn man eine Konfigurationsoption hätte, dass es ein nano oder mini ist?
Wenn ich mich recht erinnere, kann der Arduino Bootloader nicht per Software angesprungen werden. Wenn aber auf dem Arduino ein Optiboot Bootloader ist, sollte das eigentlich funktionieren. Der kann per Software-Reset in den Flashmodus springen. Zumindest meine ich das mal im nanoCUL Thread gelesen zu haben. So wie ich die LGW Schaltung im Kopf habe, ist sowieso kein Pin mehr frei, der für den Reset verwendet werden kann. Ich packe dieses Feature aber auf die Merkliste mit dem ESP32 ;D
Gruß PeMue
Zitat von: PeMue am 22 Juli 2017, 18:35:35
Wenn ich mich recht erinnere, kann der Arduino Bootloader nicht per Software angesprungen werden. Wenn aber auf dem Arduino ein Optiboot Bootloader ist, sollte das eigentlich funktionieren. Der kann per Software-Reset in den Flashmodus springen. Zumindest meine ich das mal im nanoCUL Thread gelesen zu haben. So wie ich die LGW Schaltung im Kopf habe, ist sowieso kein Pin mehr frei, der für den Reset verwendet werden kann. Ich packe dieses Feature aber auf die Merkliste mit dem ESP32 ;D
Gruß PeMue
Ich würde einen der noch freien IOs des SC16IS750 (den man in dem Fall eh hat) für den Power on/off nehmen.
Reset auslösen gibt es schon (an IO5), das hilft dem CUL aber nichts mehr, wenn er in diesem Zustand ist. Darum eine zusätzliche Power off/on Option.
Zitat von: HCS am 22 Juli 2017, 18:54:24
Ich würde einen der noch freien IOs des SC16IS750 (den man in dem Fall eh hat) für den Power on/off nehmen.
Ist notiert, siehe hier (https://forum.fhem.de/index.php/topic,45594.msg451267.html#msg451267). Somit "veraltet" Deine Papierversion langsam ein bisschen ;D
Gruß PeMue
Nur mal angenommen, der Zugriff auf das LGW ist weder per USB noch aus dem WLAN möglich. Flashen kommt auch nicht in Frage. Gibt es eine Möglichkeit, das LGW zurück in den AP-Modus zu versetzen?
Ich habe das beim IR-Gateway mit einem Taster (GPIO gegen GND) gelöst. Beim gedrückten Taster wird die Schaltung mit Spannung versorgt, Taster loslassen und Gateway startet im AP-Modus.
Zitat von: HCS am 22 Juli 2017, 18:23:28
Das wäre in der LGW-Software vermutlich kein großes Thema, aber auf den bereits bestehenden Platinen vermutlich nicht so einfach zu ergänzen.
Aber dann könnte man den CUL nach belieben ein- / ausschalten.
Bei den bestehenden Platinen wäre eine Freiluftverdrahtung angesagt.
Zitat von: locutus am 23 Juli 2017, 16:41:22
Nur mal angenommen, der Zugriff auf das LGW ist weder per USB noch aus dem WLAN möglich. Flashen kommt auch nicht in Frage. Gibt es eine Möglichkeit, das LGW zurück in den AP-Modus zu versetzen?
esptool.py --port COM3 erase_flashlöscht den kompletten flash, sowohl die firmware als auch die Settings. Danach ist der ESP8266 in dem Zustand, in dem er ausgeliefert wurde.
Falls das auch nicht mehr funktioniert, würde ich anstatt Taster eher die Sammelstelle für Elektroschrott sehen.
Anstatt COM3 dann den richtigen seriellen Port einsetzen.
Ich muß nochmal auf das Thema "CUL antwortet nicht" zurückkommen.
Ich habe 2 loctus' LaCrossGateways (433MHz, 868MHz) angebunden.
Die beiden gehen - wie schon vorher beschrieben - unregelmäßig in den Zombie-Status.
Um der Sache auf den Grund zu gehen habe ich HCS' reconnect-Test implementiert (läuft alle 2min,
frägt allerdings nach der Uptime des CUL) und Verbose für die miniCULs auf 5 hochgedreht.
defmod miniCUL433.reconnect at +*00:02:00 {\
my $deviceName = "miniCUL433";;;;\
my $response = CommandGet("", $deviceName . " " . "uptime");;;;\
my $gotAnswer = index($response, 'No answer') == -1;;;;\
Log 1, $deviceName . ": answer: " . $response;;\
\
if(!$gotAnswer) {\
Log 1, $deviceName . ": request reopen...";;\
fhem("set " . $deviceName . " reopen");;;;\
}\
\
}
attr miniCUL433.reconnect DbLogExclude .*
attr miniCUL433.reconnect disable 0
attr miniCUL433.reconnect room CUL
Hierbei fiel mir auf, dass das CUL-Modul extrem früh die "No answer" Mitteilung sendet.
Der 433er ist im Status "disconnected", der 868er zeigt "Initialized".
Hier der "Zombie":
2017.07.27 09:26:31.355 5: SW: t
2017.07.27 09:26:31.357 1: miniCUL433: answer: miniCUL433 uptime => No answer
2017.07.27 09:26:31.357 1: miniCUL433: request reopen...
...
2017.07.27 09:28:31.355 5: SW: t
2017.07.27 09:28:31.356 1: miniCUL433: answer: miniCUL433 uptime => No answer
2017.07.27 09:28:31.356 1: miniCUL433: request reopen...
Und hier der Aktive:
2017.07.27 09:26:49.963 5: SW: t
2017.07.27 09:26:50.006 5: CUL/RAW (ReadAnswer): 000B6EC3
2017.07.27 09:26:50.008 1: miniCUL868: answer: miniCUL868 uptime => 0 01:39:54
...
2017.07.27 09:28:49.963 5: SW: t
2017.07.27 09:28:50.024 5: CUL/RAW (ReadAnswer): 000BA942
2017.07.27 09:28:50.027 1: miniCUL868: answer: miniCUL868 uptime => 0 01:41:53
Edit: Log-Auszug wenn das Teil in den Zombie-Modus geht:
2017.07.27 12:02:56.210 5: CUL/RAW: /s5
2017.07.27 12:02:56.213 5: CUL/RAW: s5/4290C71A0
2017.07.27 12:02:56.215 5: CUL/RAW: s54290C71A0/04^M
2017.07.27 12:02:56.215 4: CUL_Parse: miniCUL433 s54290C71A004
2017.07.27 12:02:56.216 5: miniCUL433: dispatch s54290C71A004
2017.07.27 12:02:56.217 4: CUL_TCM97001 using longid: 1 model: NC_WS
2017.07.27 12:03:00.074 5: CUL/RAW: /sA
2017.07.27 12:03:00.077 5: CUL/RAW: sA/690C4F410
2017.07.27 12:03:00.080 5: CUL/RAW: sA690C4F410/2A^M
2017.07.27 12:03:00.081 4: CUL_Parse: miniCUL433 sA690C4F4102A
2017.07.27 12:03:00.081 5: miniCUL433: dispatch sA690C4F4102A
2017.07.27 12:03:00.082 5: miniCUL433: dispatch P7#A690C4F410
2017.07.27 12:03:00.082 4: SD_WS07_Parse SD_WS07 (P7#A690C4F410) length: 10
2017.07.27 12:03:00.082 5: SD_WS07 converted to bits: 10100110 1 001 000011000100 1111 01000001
2017.07.27 12:03:00.083 4: SD_WS07_TH decoded protocolid: 7 sensor id=A6, channel=2, temp=19.6, hum=65, bat=ok
2017.07.27 12:03:00.083 4: miniCUL433 using longid: 1 model: SD_WS07_TH
2017.07.27 12:04:31.355 5: SW: t
2017.07.27 12:04:34.360 1: 192.168.254.88:85 disconnected, waiting to reappear (miniCUL433)
2017.07.27 12:04:34.365 1: miniCUL433: answer: miniCUL433 uptime => No answer
2017.07.27 12:04:34.365 1: miniCUL433: request reopen...
2017.07.27 12:04:49.964 5: SW: t
2017.07.27 12:04:50.078 5: CUL/RAW (ReadAnswer): 000F139C^M
2017.07.27 12:04:50.081 1: miniCUL868: answer: miniCUL868 uptime => 0 02:11:44
2017.07.27 12:06:31.356 5: SW: t
2017.07.27 12:06:31.357 1: miniCUL433: answer: miniCUL433 uptime => No answer
2017.07.27 12:06:31.357 1: miniCUL433: request reopen...
2017.07.27 12:06:32.571 5: SW: V
2017.07.27 12:06:35.575 5: SW: V
2017.07.27 12:06:35.664 5: CUL/RAW (ReadAnswer): V 1.10.02 a-culfw Build: 171 (2015
2017.07.27 12:06:35.673 5: CUL/RAW (ReadAnswer): -10-29_21-49-43) miniCUL (F-Band: 43
2017.07.27 12:06:35.677 5: CUL/RAW (ReadAnswer): 3MHz)^M
2017.07.27 12:06:35.677 5: SW: ?
2017.07.27 12:06:35.720 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i
2017.07.27 12:06:35.728 5: CUL/RAW (ReadAnswer): G M R T V W X e m l t x^M
2017.07.27 12:06:35.728 3: miniCUL433: Possible commands: BCFiGMRTVWXemltx
2017.07.27 12:06:35.728 5: SW: X21
2017.07.27 12:06:35.730 5: SW: T01
2017.07.27 12:06:35.854 5: CUL/RAW (ReadAnswer): 0000^M
2017.07.27 12:06:35.854 5: GOT CUL fhtid: 0000
2017.07.27 12:06:35.857 1: 192.168.254.88:85 reappeared (miniCUL433)
2017.07.27 12:06:40.045 1: 192.168.254.88:81 reappeared (LCG.miniCUL433)
2017.07.27 12:06:49.963 5: SW: t
2017.07.27 12:06:50.138 5: CUL/RAW (ReadAnswer): 000F4E20^M
2017.07.27 12:06:50.141 1: miniCUL868: answer: miniCUL868 uptime => 0 02:13:44
2017.07.27 12:07:46.104 1: 192.168.254.88:81 reappeared (LCG.miniCUL433)
2017.07.27 12:08:31.355 5: SW: t
2017.07.27 12:08:34.359 1: 192.168.254.88:85 disconnected, waiting to reappear (miniCUL433)
2017.07.27 12:08:34.362 1: miniCUL433: answer: miniCUL433 uptime => No answer
2017.07.27 12:08:34.362 1: miniCUL433: request reopen...
2017.07.27 12:08:49.963 5: SW: t
2017.07.27 12:08:50.001 5: CUL/RAW (ReadAnswer): 000F888E^M
2017.07.27 12:08:50.004 1: miniCUL868: answer: miniCUL868 uptime => 0 02:15:43
2017.07.27 12:09:52.246 1: 192.168.254.88:81 reappeared (LCG.miniCUL433)
2017.07.27 12:10:31.355 5: SW: t
2017.07.27 12:10:31.357 1: miniCUL433: answer: miniCUL433 uptime => No answer
2017.07.27 12:10:31.357 1: miniCUL433: request reopen...
2017.07.27 12:10:31.565 5: SW: V
2017.07.27 12:10:34.570 5: SW: V
2017.07.27 12:10:37.574 5: SW: V
2017.07.27 12:10:40.579 1: Cannot init 192.168.254.88:85, ignoring it (miniCUL433)
2017.07.27 12:10:50.055 5: SW: t
2017.07.27 12:10:50.179 5: CUL/RAW (ReadAnswer): 000FC321^M
2017.07.27 12:10:50.183 1: miniCUL868: answer: miniCUL868 uptime => 0 02:17:43
2017.07.27 12:12:31.355 5: SW: t
2017.07.27 12:12:31.357 1: miniCUL433: answer: miniCUL433 uptime => No answer
2017.07.27 12:12:31.357 1: miniCUL433: request reopen...
Der miniCUL433 und der miniCUL868 liegen nebeneinander auf dem Schreibtisch und sind am gleichen AP angemeldet.
Das ist aber alles nur an den Symptomen rumkuriert.
Die eigentliche Frage ist, warum Dein CUL aussteigt.
Ich habe aktuell 13 Tage 12 Stunden Uptime vom CUL gemeldet.
Ich habe aber auch die "V 1.25.00 a-culfw" drauf.
Zitat von: SusisStrolch am 27 Juli 2017, 09:47:12
Hierbei fiel mir auf, dass das CUL-Modul extrem früh die "No answer" Mitteilung sendet.
Ich vermute, dass das recht schnell kommt, weil die IP-Verbindung zum Port vom LGW steht, da also auf keinen Timeout gewartet wird, aber der abgestürzte CUL sofort nichts antwortet womit dann für das LGW die Anfrage auch sofort beendet ist.
Was auch seltsam ist: alle Verbindungen (das LGW selbst und auch die Ports mit den CUL) werden häufig disconnected. Das ist nicht normal. Sieht irgendwie nach WiFi-Problemen aus.
Ich habe seit Wochen keinen disconnect/reconnect auf die LGWs oder CULs.
Es gibt auch nur wenig Gründe, warum das passiert:
- WiFi war weg
- LGW-Neustart
- FHEM-Neustart
Wenn man es mal rausfiltert sieht man, was ich meine:
2017.07.27 12:04:34.360 1: 192.168.254.88:85 disconnected, waiting to reappear (miniCUL433)
2017.07.27 12:06:35.857 1: 192.168.254.88:85 reappeared (miniCUL433)
2017.07.27 12:06:40.045 1: 192.168.254.88:81 reappeared (LCG.miniCUL433)
2017.07.27 12:07:46.104 1: 192.168.254.88:81 reappeared (LCG.miniCUL433)
2017.07.27 12:08:34.359 1: 192.168.254.88:85 disconnected, waiting to reappear (miniCUL433)
2017.07.27 12:09:52.246 1: 192.168.254.88:81 reappeared (LCG.miniCUL433)
Hallo in die Runde,
heute war mal wieder Basteltag und was sehe ich in meiner FHEM-Kiste,
einen LaCrosseGateway. Dann gleich mal testen, verbindet sich nicht mit dem Lan -
aber baut einen AP auf. Kein Problem braucht man ja nur konfigurieren.
Falsch gedacht - auf 192.168.222.1/setup wird weitergeleitet
auf 192.168.222.1/login - und ich habe kein Passwort. :o
Suchen brachte kein Ergebnis - Flashspeicher löschen und akt. PGM aufspielen
brachten auch nicht den gewünschten Erfolg, nun setze ich auf Euch.
Gruß
Thomas
Zitat von: ThomasW am 06 August 2017, 23:46:03
Flashspeicher löschen und akt. PGM aufspielen brachten auch nicht den gewünschten Erfolg, nun setze ich auf Euch.
Du hast den Flash mit
esptool --port <port> erase_flashgelöscht?
Und das lief ohne Fehlermeldung durch?
Danach kann kein Passwort mehr gesetzt sein.
Hallo HCS,
herzlichen Dank für deine schnelle Antwort.
Nein, es war der ESP8266Flasher (Start Adr.. 0x000) und ein Lösch.bin File die den Speicher bis zum ende vollschreiben sollte.
Diese ist ohne Fehlermeldung durchgelaufen.
Habe momentan ein anderes Problem, habe momentan keinen Zugriff auf den und auf das Gateway.
Beides liegt einige xxx Km von mir entfernt in einem Schubladen, komme erst wieder nächste Woche zum Basteln.
Werde dann nochmal den Speicher löschen und berichten.
Gruß
Thomas
Hallo,
ich habe mir vor einigen Wochen ein LacrosseGateway gebaut. Mit einem RFC69 Modul. Ziel war es die EC3000 Geräte damit zu empfangen.
Hat auch alles geklappt. Mit dem INIT String: 20000#1r v
Dann habe ich mir noch ein paar TX35 Sensoren geholt. Diese wollte ich damit auch empfangen. ALso habe ich mir einen Toggle Modus eingestellt:
10#1m 20#1t v
Das hat auch in den ersten Tagen gut funktioniert. Nun empfängt das Gateway leider nichts mehr. Weder TX35 noch EC3000.
Habe nun mal wieder als INI String 20000#1r v gesetzt. Und Siehe da: EC3000 geht wieder.
Danach wieder den Toggle Mode eingebaut und nichts.
Habe ich da beim INIT String was verkehrt?
Jemand eine Idee?
Danke
Gruß
Hermann
Zitat von: hermann1514 am 15 August 2017, 16:35:55
Habe ich da beim INIT String was verkehrt?
Eigentlich nicht, der stimmt so. Komisch ist auch, dass es ja mal funktioniert hat.
Ich muss das mal auf einem LGW bei mir ausprobieren, ob der Toggle EC3000 / LaCrosse so funktioniert.
Eigentlich sollte das gehen.
Alternativ kannst Du natürlich auch einen zweiten RFM69 dran packen.
Zitat von: hermann1514 am 15 August 2017, 16:35:55
Jemand eine Idee?
Ja. Das funktioniert tatsächlich nicht richtig, bzw. kommt der toggle manchmal nicht in Schwung.
Probier mal diese initCommands:
10#1m 20#1t 20000#1r vDamit läuft es bei mir.
"OK 9 ..." ist ein TX35
"OK 22 ..." ist eine EC3000
23:07:46: OK 22 158 228 0 25 202 144 0 1 140 91 0 0 0 35 0 9 0 10 1 0 [9E E4 CA 90 00 00 8C 5B 00 00 00 00 01 F1 DD 00 09 00 0A 0F 17 01 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 0A 1A 67]
23:07:51: OK 22 158 228 0 25 202 149 0 1 140 96 0 0 0 35 0 9 0 10 1 0 [9E E4 CA 95 00 00 8C 60 00 00 00 00 01 F1 E1 00 09 00 0A 0F 17 41 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 0B 92 D7]
23:07:56: OK 22 158 228 0 25 202 154 0 1 140 101 0 0 0 35 0 9 0 10 1 0 [9E E4 CA 9A 00 00 8C 65 00 00 00 00 01 F1 E6 00 09 00 0A 0F 17 91 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 06 E6 67]
23:08:01: OK 22 158 228 0 25 202 159 0 1 140 106 0 0 0 35 0 9 0 10 1 0 [9E E4 CA 9F 00 00 8C 6A 00 00 00 00 01 F1 EA 00 09 00 0A 0F 17 D1 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 06 DB 67]
23:08:02: OK 9 34 1 4 214 70 [98 86 38 46 BB]
23:08:12: OK 9 34 1 4 213 70 [98 86 37 46 22]
23:08:17: OK 9 34 1 4 214 70 [98 86 38 46 BB]
23:08:26: OK 22 158 228 0 25 202 184 0 1 140 131 0 0 0 35 0 8 0 10 1 0 [9E E4 CA B8 00 00 8C 83 00 00 00 00 01 F2 00 00 08 00 0A 0F 19 41 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 0A B9 87]
23:08:31: OK 22 158 228 0 25 202 189 0 1 140 136 0 0 0 35 0 9 0 10 1 0 [9E E4 CA BD 00 00 8C 88 00 00 00 00 01 F2 05 00 09 00 0A 0F 19 81 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 05 4E 07]
23:08:36: OK 22 158 228 0 25 202 194 0 1 140 141 0 0 0 35 0 9 0 10 1 0 [9E E4 CA C2 00 00 8C 8D 00 00 00 00 01 F2 09 00 09 00 0A 0F 19 C1 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 03 79 D7]
23:08:41: OK 22 158 228 0 25 202 199 0 1 140 146 0 0 0 35 0 8 0 10 1 0 [9E E4 CA C7 00 00 8C 92 00 00 00 00 01 F2 0E 00 08 00 0A 0F 1A 11 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 0C 68 77]
23:08:42: OK 9 34 1 4 214 70 [98 86 38 46 BB]
23:08:47: OK 9 34 1 4 213 70 [98 86 37 46 22]
23:08:57: OK 9 34 1 4 214 70 [98 86 38 46 BB]
23:09:06: OK 22 158 228 0 25 202 224 0 1 140 171 0 0 0 35 0 9 0 10 1 0 [9E E4 CA E0 00 00 8C AB 00 00 00 00 01 F2 25 00 09 00 0A 0F 1B 81 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 0A 99 37]
23:09:12: OK 22 158 228 0 25 202 229 0 1 140 176 0 0 0 35 0 9 0 10 1 0 [9E E4 CA E5 00 00 8C B0 00 00 00 00 01 F2 2A 00 09 00 0A 0F 1B D1 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 03 1A E7]
23:09:16: OK 22 158 228 0 25 202 234 0 1 140 181 0 0 0 35 0 9 0 10 1 0 [9E E4 CA EA 00 00 8C B5 00 00 00 00 01 F2 2E 00 09 00 0A 0F 1C 11 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 0A 06 07]
23:09:21: OK 22 158 228 0 25 202 239 0 1 140 186 0 0 0 35 0 10 0 10 1 0 [9E E4 CA EF 00 00 8C BA 00 00 00 00 01 F2 33 00 0A 00 0A 0F 1C 61 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 06 A6 E7]
23:09:22: OK 9 34 1 4 213 70 [98 86 37 46 22]
23:09:28: OK 9 34 1 4 214 70 [98 86 38 46 BB]
23:09:33: OK 9 34 1 4 214 70 [98 86 38 46 BB]
23:09:38: OK 9 34 1 4 214 70 [98 86 38 46 BB]
23:09:46: OK 22 158 228 0 25 203 8 0 1 140 211 0 0 0 35 0 9 0 10 1 0 [9E E4 CB 08 00 00 8C D3 00 00 00 00 01 F2 4A 00 09 00 0A 0F 1D D1 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 00 1F 97]
23:09:52: OK 22 158 228 0 25 203 13 0 1 140 216 0 0 0 35 0 9 0 10 1 0 [9E E4 CB 0D 00 00 8C D8 00 00 00 00 01 F2 4E 00 09 00 0A 0F 1E 21 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 02 9C A7]
23:09:56: OK 22 158 228 0 25 203 18 0 1 140 221 0 0 0 35 0 9 0 10 1 0 [9E E4 CB 12 00 00 8C DD 00 00 00 00 01 F2 53 00 09 00 0A 0F 1E 61 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 0B 5D E7]
23:10:02: OK 22 158 228 0 25 203 23 0 1 140 226 0 0 0 35 0 10 0 10 1 0 [9E E4 CB 17 00 00 8C E2 00 00 00 00 01 F2 58 00 0A 00 0A 0F 1E B1 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 07 F1 B7]
23:10:08: OK 9 34 1 4 213 70 [98 86 37 46 22]
23:10:13: OK 9 34 1 4 213 70 [98 86 37 46 22]
23:10:18: OK 9 34 1 4 214 70 [98 86 38 46 BB]
23:10:26: OK 22 158 228 0 25 203 48 0 1 140 251 0 0 0 35 0 10 0 10 1 0 [9E E4 CB 30 00 00 8C FB 00 00 00 00 01 F2 6F 00 0A 00 0A 0F 20 31 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 0E 29 87]
23:10:31: OK 22 158 228 0 25 203 53 0 1 141 0 0 0 0 35 0 9 0 10 1 0 [9E E4 CB 35 00 00 8D 00 00 00 00 00 01 F2 74 00 09 00 0A 0F 20 81 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 0F EA D7]
23:10:37: OK 22 158 228 0 25 203 58 0 1 141 5 0 0 0 35 0 10 0 10 1 0 [9E E4 CB 3A 00 00 8D 05 00 00 00 00 01 F2 79 00 0A 00 0A 0F 20 C1 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 0C 95 67]
23:10:41: OK 22 158 228 0 25 203 63 0 1 141 10 0 0 0 35 0 9 0 10 1 0 [9E E4 CB 3F 00 00 8D 0A 00 00 00 00 01 F2 7E 00 09 00 0A 0F 21 11 00 6D 00 00 00 00 00 01 90 00 00 00 00 00 10 18 0B 05 C7]
Danke,
ich habe gestern Abend das Ding einmal Stromlos gemacht und den alten INIT String eingetragen. Dann ging es wieder. Habe aber nun Deinen neuen STRING eingetragen. Läuft im Moment auch. Mal abwarten.
Ist es eigentlich auch möglich die "Technoline MA 10200 Mobile Alerts" Geräte mit dem LacrosseGateway einzubinden?
Danke.
Gruß
Hermann
Zitat von: hermann1514 am 16 August 2017, 09:32:58
Ist es eigentlich auch möglich die "Technoline MA 10200 Mobile Alerts" Geräte mit dem LacrosseGateway einzubinden?
Nein, die senden ein anderes Protokoll.
Hallo,
das Problem
Zitat von: ThomasW am 06 August 2017, 23:46:03
- und ich habe kein Passwort. :o
wurde Dank HCS
Zitat von: HCS am 07 August 2017, 22:08:01
esptool --port <port> erase_flash
und nochmaliges löschen des Flashspeichers gelöst.
Thomas
Hallo zusammen,
ich habe folgende Problem:
- ein LGW v1.1 aufgebaut (diskret, BME280, 2xRadio, Transistorflashschaltung)
- das Flashen der Firmware funktioniert ohne Probleme
- nur wird kein Acess Point aufgebaut
Auf der Konsole bekomme ich folgende Meldungen (57600 Baud):
[LaCrosseITPlusReader.Gateway.1.30]
(1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + BME280 {IP=Disabled}
OK 9 62 1 5 1 51
OK 9 8 1 4 227 66OK 9 62 1 5 1 52
OK VALUES LGW 13404285 UpTimeSeconds=10,UpTimeText=0Tg. 0Std. 0Min. 10Sek. ,WIFI=,MacAddress=18:FE:34:CC:88:7D,ReceivedFrames=3,FramesPerMinute=3,RSSI=Off,FreeHeap=23816,Version=1.30,LD.Min=0.14,LD.Avg=0.14,LD.Max=9.62,OLED=none
OK WS 0 4 5 30 48 255 255 255 255 255 255 255 255 0 3 219
OK 9 62 1 5 1 51
OK 9 8 1 4 227 66
OK 9 62 1 5 2 51
OK VALUES LGW 13404285 UpTimeSeconds=20,UpTimeText=0Tg. 0Std. 0Min. 20Sek. ,WIFI=,ReceivedFrames=6,FramesPerMinute=6,RSSI=Off,FreeHeap=23816,LD.Min=0.14,LD.Avg=0.14,LD.Max=15.01,OLED=none
OK WS 0 4 5 30 48 255 255 255 255 255 255 255 255 0 3 219
OK 9 8 1 4 227 66
OK 9 62 1 5 1 52
OK 9 62 1 5 2 51
OK 9 8 1 4 227 66
OK VALUES LGW 13404285 UpTimeSeconds=30,UpTimeText=0Tg. 0Std. 0Min. 30Sek. ,WIFI=,ReceivedFrames=10,FramesPerMinute=10,RSSI=Off,FreeHeap=23816,LD.Min=0.14,LD.Avg=0.14,LD.Max=14.95,OLED=none
OK WS 0 4 5 30 49 255 255 255 255 255 255 255 255 0 3 219
OK 9 62 1 5 1 52
OK 9 62 1 5 1 51
OK 9 8 1 4 227 66
OK VALUES LGW 13404285 UpTimeSeconds=40,UpTimeText=0Tg. 0Std. 0Min. 40Sek. ,WIFI=,ReceivedFrames=13,FramesPerMinute=13,RSSI=Off,FreeHeap=23816,LD.Min=0.14,LD.Avg=0.14,LD.Max=14.95,OLED=none
OK WS 0 4 5 30 48 255 255 255 255 255 255 255 255 0 3 219
OK 9 62 1 5 2 51
OK 9 8 1 4 227 66
OK 9 62 1 5 1 51
OK VALUES LGW 13404285 UpTimeSeconds=50,UpTimeText=0Tg. 0Std. 0Min. 50Sek. ,WIFI=,ReceivedFrames=16,FramesPerMinute=16,RSSI=Off,FreeHeap=23816,LD.Min=0.14,LD.Avg=0.14,LD.Max=14.94,OLED=none
OK WS 0 4 5 30 48 255 255 255 255 255 255 255 255 0 3 219
OK 9 62 1 5 1 51
OK 9 8 1 4 227 66
OK 9 62 1 5 1 51
Das heißt für mich:
- es ist die richtige Software drauf
- der BME280 und die Radios werden korrekt erkannt
- IP disabled heißt vermutlich, dass kein Zugriff auf einen Router möglich ist
Verbaut ist ein ESP12F, die Lötstellen sollten ok sein.
Habt ihr mir einen Tipp, wo ich noch suchen kann?
Danke + Gruß
PeMue
Zitat von: PeMue am 26 August 2017, 22:02:31
Habt ihr mir einen Tipp, wo ich noch suchen kann?
Schon mal im Wiki gestöbert (https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#USB) ? ;)
Vielleicht helfen die Hinweise?
Zitat von: PeMue am 26 August 2017, 22:02:31
- IP disabled heißt vermutlich, dass kein Zugriff auf einen Router möglich ist
Nein, es bedeutet, dass WiFi durch eine dieser Möglichkeiten deaktiviert ist:
- In den Settings
- PullUp an GPIO13
Schicke mal auf der seriellen Schnittstelle ein 1g.
Wenn in der Antwort "UseWiFi false;" vorkommen, ist es in den Settings deaktiviert.
Dann kannst Du es mit "SETUP UseWiFi true" einschalten.
Danach mit 8377e neu booten.
Hallo zusammen,
ja, ich habe das Wiki studiert, aber zu dem Punkt mit dem Pullup an GPIO13 bin ich nicht gekommen. R9 runtergelötet und das Ganze funktioniert as designed, in der alten Konfiguration natürlich auch ;). Gleich in FHEM eingebunden und das alte Gateway verkauft ;)
Danke für Eure Hilfe und sorry für meine Trotteligkeit. Ich werde beim R9 einen Kommentar einfügen bzw. im Layout no Wifi einfügen.
Gruß Peter
Hallo zusammen.
Habe seit heute ein Problem und kann es nicht eingrenzen !
Habe in der fhem.cfg ein include eingefügt und danach einen Neustart von FHEM gemacht. Hier geht es um die Anzeige der RSSI Werte in einen Chart. Diese habe ich ausgelagert ! Daher das Include.
Jetzt geht das LCG nur noch auf Status opened und lässt sich nicht mehr connecten.
Habe auch den PI schon komplett neu gestartet und das Gateway ebenfalls.
Das Gateway ist über die IP aus dem Netzwerk ohne Probleme erreichbar, das WebIf wird auch ohne Probleme aufgebaut.
Habe mal die Startsequenz aus dem Log
17:17:53: LaCrosseITPlusReader.Gateway V1.30
17:17:53: Free heap: 21720 Flash size: 4194304 Core: 2_3_0 SDK: 1.5.3(aec24ac9)
17:17:53: Reset: External System
17:17:53: Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
17:17:53: Starting I2C with 400 kHz
17:17:53: Configured altitude: 0
17:17:53: Searching RFMs and Sensors
17:17:53: Radio #1 found: RFM69
17:17:53: Radio #2 found: RFM69
17:17:53: Starting wifi
17:17:53: Start WIFI_STA
17:17:53: HostName is: LaCrosseGateway
17:17:53: Using static IP
17:17:53: IP: 192.168.2.150
17:17:53: Mask: 255.255.255.0
17:17:53: Gateway: 192.168.2.1
17:17:53: Connect 15 seconds to an AP (SSID 1)
17:17:53: ..............
17:17:53: connected :-)
17:17:53: SSID: WLAN-xxxx
17:17:53: IP: 192.168.2.150
17:17:53: Starting frontend
17:17:53: Starting OTA
17:17:53: Starting data port 1 on 81
17:17:53: Sending init String to FHEM
17:17:53: Setup completely done
17:17:57: DataPort: #81 received '"WATCHDOG Ping=300" '
17:17:57: DataPort: #81 Client connected, IP=0.0.0.0 Port=0
17:17:57: DataPort: #81 received 'v "WATCHDOG Ping=300" '
17:17:57: DataPort: #81 Client connected, IP=192.168.2.109 Port=34854
17:18:00: DataPort: #81 received 'v '
17:18:59: DataPort: #81 received '"WATCHDOG Ping=300" '
17:19:03: DataPort: #81 Client connected, IP=0.0.0.0 Port=0
17:19:03: DataPort: #81 received 'v "WATCHDOG Ping=300" '
17:19:03: DataPort: #81 Client connected, IP=192.168.2.109 Port=34884
17:19:03: DataPort: #81 received 'v '
17:20:03: DataPort: #81 received '"WATCHDOG Ping=300" '
17:20:03: DataPort: #81 Client connected, IP=0.0.0.0 Port=0
17:20:03: DataPort: #81 received 'v "WATCHDOG Ping=300" '
17:20:03: DataPort: #81 Client connected, IP=192.168.2.109 Port=34918
17:20:06: DataPort: #81 received 'v '
Hat jemand eine Idee ?
Gruß
Sascha
Edit: Nach einem erneuten Start von FHEM hat die Verbindung geklappt !!!
Bei mir funktioniert ein Reconnect auch nicht immer nach dem Abspeichern der .cfg Datei. Ich muss dann auch immer FHEM komplett neu starten.
Zitat von: gloob am 19 September 2017, 18:44:53
Bei mir funktioniert ein Reconnect auch nicht immer nach dem Abspeichern der .cfg Datei. Ich muss dann auch immer FHEM komplett neu starten.
Meinst Du damit "Edit files" -> "fhem.cfg" -> "Save fhem.cfg" ?
Uiiii, wenn das manche Leute lesen, dass jemand die fhem.cfg editiert ... ;D ;D ;D
OK, habe es mal ausprobiert. Funktioniert wirklich nicht. Keine Ahnung, was beim Speichern der fhem.cfg spezial ist.
Aber da gibt es noch mehr. Fronthem überlebt das auch nicht. Wenn ich mal Zeit habe muss ich mal forschen.
Ja manchmal manipuliere ich auch die CFG mit der Hand. Schande über mein Haupt. Natürlich sollte man wissen was man dort treibt.
Es ist nur schöner wenn die CFG Datei eine ordentlich Struktur hat. Speziell wenn man FHEM mal neu aufsetzen möchte oder Teile extrahieren will.
Zitat von: gloob am 19 September 2017, 19:29:37
Ja manchmal manipuliere ich auch die CFG mit der Hand. Schande über mein Haupt. Natürlich sollte man wissen was man dort treibt.
Es ist nur schöner wenn die CFG Datei eine ordentlich Struktur hat. Speziell wenn man FHEM mal neu aufsetzen möchte oder Teile extrahieren will.
Deswegen manchmal manuell bearbeiten.
[emoji6]
Gesendet von meinem E6653 mit Tapatalk
Zitat von: PeMue am 27 August 2017, 09:14:17
Ich werde beim R9 einen Kommentar einfügen bzw. im Layout no Wifi einfügen.
Erledigt, siehe Bild. Es macht manchmal durchaus Sinn, seine alten Beiträge noch mal zu lesen 8)
Gruß PeMue
Kann man eigentlich auch von den Radios verschiedene Frequenzen mischen? Also 1x 433 und 2x 868 mhz?
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 20 September 2017, 21:46:23
Kann man eigentlich auch von den Radios verschiedene Frequenzen mischen? Also 1x 433 und 2x 868 mhz? [/quote
Würde nichts nützen, weil das LGW keine Protokolle von 433 MHz Sensoren kann.
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
Zitat von: sash.sc am 22 September 2017, 20:07:33
Was mach eigentlich, das Attribut, um devices zu blocken ?????
Es freut sich seit 25.02.17 darauf angewendet zu werden.
Zitat aus der commandref:
Zitatfilter
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"
Zitat von: sash.sc am 22 September 2017, 20:07:33
Du hattest mal was gerschrieben, ob da evtl. ein Signalduino oder so in Betrieb ist ?
Nanu, wo habe ich denn so was geschrieben?
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
Zitat von: sash.sc am 22 September 2017, 21:17:13
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.
Danke
Gesendet von meinem E6653 mit Tapatalk
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
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
Zitat von: Dummbatz am 28 September 2017, 14:50:44
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.
Danke HCS,
werde ich prüfen.
LG
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 (http://www.ebay.de/itm/NodeMCU-ESP8266-ESP-12E-V1-0-Wifi-CP2102-IoT-Lua-267-NEW-/232451934506?hash=item361f37092a:g:cIsAAOSwnn9ZlZuc), einem RFM69CW (https://de.aliexpress.com/item/RFM69CW-HopeRF-868Mhz-Wireless-Transceiver-with-RFM12B-compatible-Footprint/32698808445.html?spm=a2g0s.9042311.0.0.Y4yyhj), 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
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
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.
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.
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
attr myLaCrosseGateway timeout 120,30kannst Du mal
attr myLaCrosseGateway timeout 60machen, 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?
Zitat von: reinni123 am 16 Oktober 2017, 12:21:17
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.:
attr myLaCrosseGateway timeout 60attr myLaCrosseGateway watchdog 300
Zitat von: HCS am 16 Oktober 2017, 12:36:11
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 .
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
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:
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]
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
Zitat von: heka am 16 Oktober 2017, 14:18:34
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'.
Ja,. genau solche Dinge meinte ich oben. Weil:
- USB-Kabel sind oft "nur" für Datenübertragung ausgelegt, wo natürlich keine hohen Ströme fleißen müssen
- Telefon-Ladegeräte müssen laden und sind ncht unbeding eine Konstantspannungsquelle, dem Telefon und seinem Akku ist ein kurzer Spannungseinbruch egal, einem Prozessor nicht
- Manche Ladegeräte legen irgend eine "Intelligenz" an den Tag, was für einen Prozessor, der ein konstante Spannung will, auch nicht sinnvoll ist.
Aber alles nur denkbare Probleme, die sich allerdings auch erst in Kombination (schlechtes Netzteil + schlechtes Kabel + schlechte Empfangssituation) dann manchmal auswirken.
Zitat von: marco-f am 16 Oktober 2017, 13:45:44
Uptimes von 38 Tagen wären bei mir Traumwerte. Ich glaube mein Rekord lag mal bei 12 Tagen.
Ja, und "nur" 38 Tage, weil ich vor 38 Tagen den Strom abstellen musste.
Wobei 38 Tage nicht das erforderliche Ziel sind. Der ESP8266 muss sich bei jeden boot sich mit dem AP verbinden.
Habe mal die usb Kabel ausgetauscht, gegen etwas bessere Qualität, wie die bei den Handys dabei sind.
Seit dem gibt es keine Probleme mehr.
Und seit dem ist auch der Ladestrom für das Handy bis zu 30% höher.
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 16 Oktober 2017, 16:14:34
Habe mal die usb Kabel ausgetauscht, gegen etwas bessere Qualität, wie die bei den Handys dabei sind.
Seit dem gibt es keine Probleme mehr.
Jetzt müssen wir herausfinden, woran man ein gutes USB-Kabel erkennt (also ohne Versuch und Irrtum)
Oder wie man die Qualität ermittelt.
OK, 2A drüber ziehen und den Spannungsabfall messen, ist aber vermutlich nicht für jeden durchführbar.
Ich habe z. B. Diese hier. Bin damit zufrieden.
Diese gibt es auch noch in anderen Längen.
OTISA 3Pack 1.8m Nylon Micro USB auf USB Kabel High Speed USB 2.0 Datenkabel für Android Smartphones Samsung /HTC / Nokia/ LG https://www.amazon.de/dp/B01MCYWK05/ref=cm_sw_r_cp_apap_7bAymczR1NriW
(//http:///HTC%20/%20Nokia/%20LG%20https://www.amazon.de/dp/B01MCYWK05/ref=cm_sw_r_cp_apap_7bAymczR1NriW)
Gesendet von meinem E6653 mit Tapatalk
Ich hab heute Nachmittag einen kleinen Reboot-Marathon hingelegt mit diversen Netzteilen und Kabeln. Ins Rennen geschickt wurden 5V 1A Handynetzteile von Asus, Samsung, HTC, ein Meanwell T-60B Schaltnetzteil mit 5V 5A und die USB 3.0 Ports meines PC's. Kombiniert wurde alles mit Micro-USB Kabeln von Samsung, Nokia, HTC und einem kurzen 10cm Kabel meiner Power-Bank.
Ergebnis: Eigentlich Nix! Sämtliche Netzteile in Kombination mit sämtlichen Kabeln brachten das gleiche Ergebnis, dass es immer wieder den Zustand gab, dass das LGW auf dem Display das Connected Symbol anzeigte, gleichzeitig ein RSSI von 30dBm ausgab und das LGW nicht im WLAN registriert war (siehe mein Bild von heute Mittag).
Das Einzige was heute wirklich auffiel - jeder zweite Connectversuch schlug fehl. In der Vergangenheit hatte ich dieses Gefühl auch schon das ein oder andere Mal, aber sporadisch gab es auch Ausnahmen, heute war es aber die Regel. D.h., LGW ist ordentlich verbunden, dann mach ich Strom ab & wieder dran, sende über FHEM einen Reboot oder drücke den Reset Button am NodeMCU und ich hab das oben beschriebene Fehlverhalten. Erneut Strom ab & wieder dran oder Reset Button - voila, erfolgreicher Connect. ???
Ich könnte jetzt mal noch versuchen mir ein spezielles Kabel zu bauen mit ordentlich Querschnitt zwischen MicroUSB Stecker und USB Buchse, oder mal mit nem Speicheroszi schauen was die 5V Schiene macht wenn ich das Teil starte, aber nach den Beobachtungen von heute Nachmittag glaube ich kaum dass ich damit noch irgendwas erreiche.
Zitat von: marco-f am 16 Oktober 2017, 20:48:33
Ich könnte jetzt mal noch versuchen mir ein spezielles Kabel zu bauen mit ordentlich Querschnitt zwischen MicroUSB Stecker und USB Buchse, oder mal mit nem Speicheroszi schauen was die 5V Schiene macht wenn ich das Teil starte, aber nach den Beobachtungen von heute Nachmittag glaube ich kaum dass ich damit noch irgendwas erreiche.
Glaube ich auch nicht.
Neuer Anlauf: steck es an einen Rechner und führe ein flash erase durch.
esptool.py --port COM3 erase_flashbzw.
esptool.py --port /dev/ttyWasAuchImmmer erase_flashDen Port entsprechend anpassen.
Das bringt es in den Zustand, wie es ab Werk war.
Danach firmware neu aufspielen und neu konfigurieren.
Der ESP8266 merkt sich einige "WiFi-Dinge" im flash, vielleicht ist da irgendwo der Wurm drin.
Hast Du einen Range-Extender in Betrieb?
Das soll angeblich auch mit dem ESP8266 manchmal ein Problem sein.
Zitat von: HCS am 16 Oktober 2017, 21:08:35
Neuer Anlauf: steck es an einen Rechner und führe ein flash erase durch.
Für Windows Nutzer geht das auch mit dem NodeMCU Flasher (http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/131-loeschen-des-gesamten-flashspeichers).
Gruß PeMue
Vielleicht hilft es, hier mein fhem listing vom LGW:
Internals:
Alive 2017-10-16 21:56:24
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF 192.168.10.38:81
DeviceName 192.168.10.38:81
FD 4
NAME myLaCrosseGateway
NR 48
PARTIAL
RAWMSG OK 9 3 1 4 214 106
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.30
myLaCrosseGateway_MSGCNT 749781
myLaCrosseGateway_TIME 2017-10-16 21:58:50
settings (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868980 r:6631) + BME280 + OLED {IP=192.168.10.38}]
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 21:58:50 analog 965
2017-10-16 21:58:50 state initialized
helper:
Attributes:
initCommands 2,868980,120i v
room CUL
timeout 180
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
watchdog 300
Zitat von: HCS am 16 Oktober 2017, 21:08:35Hast Du einen Range-Extender in Betrieb?
Das soll angeblich auch mit dem ESP8266 manchmal ein Problem sein.
Nein. Eine Fritz!Box 7490 im Keller und ein Linksys Access Point mit DD-WRT im OG, beides als getrennte Netzte mit verschiedenen SSIDs.
Platt machen und neu aufspielen werde ich wahrscheinlich heute Abend mal in Angriff nehmen, aber erstmal verfolge ich noch eine andere Spur.
Ich habe gestern Abend nach meinem letzten Posting noch ein paar interessante Beobachtungen gemacht. Ich hab, eher aus Verzweiflung, geschaut ob ich das Ganze nicht zur Fehlereingrenzung noch weiter minimieren kann. Zu Testzwecken hab ich dann mal den RFM69 entfernt, also nur noch NodeMCU und Display gestartet. Und siehe da ... plötzlich buchte sich der NodeMCU nach jedem Reboot sicher ins WiFi ein. :o Als ich dann den RFM69 wieder anschloss und alles gestartet habe lief mal zufällig keine Musik im Hintergrund und ich vernahm plötzlich kurzzeitig ein leises Summen. Und beim nächsten Reboot wieder. Ich entdeckte, dass das Summen immer dann auftritt wenn auf dem Display erscheint "Connect WiFi". Ich hab dann das LCD abgeklemmt, also nur NodeMCU mit RFM69 gestartet und auch hier waren plötzlich alle Startversuche erfolgreich.
Nach diesen Beobachtungen war für mich der 3,3V Festspannungsregler auf dem NodeMCU der Verursacher, denn mir nur einem weiteren Verbraucher klappte es immer. Später in der Nacht hatte ich dann den NodeMCU mal 15-20 Minuten stromlos und wollte ihn siegessicher nur mit dem RFM69 wieder starten, da leuchtete auf einmal am ESP ne fette blaue LED und er buchte sich wieder nicht ein. :o Nach einem Reboot klappte es dann, aber dieses Verhalten dass nach längerem Stromlos sein der ersten Bootvorgang fehlschlägt lies sich wiederherstellen. Und das immer in Verbindung mit der blauen LED am ESP, ich konnte also noch im Bootvorgang anhand der LED sehen ob es erfolgreich ist oder nicht.
Ich will mal sehen dass ich heute an meiner Spannungsversorgung n bissel was umbaue. Einerseits mal schauen ob es was ändert wenn ich nicht über die USB Buchse sondern über VIN versorge, andererseits mal die 3,3V für den RFM und das LCD über einen Zusätzlichen Spannungsregler erzeugen so dass der Regler auf dem NodeMCU wirklich nur den ESP versorgen muss.
P.S.: In der Zwischenzeit hab ich ausversehen das LGW aus der Ferne rebootet und es hat sich wieder nicht connected. :(
Ich habe begonnen, den BME680 in das LGW zu implementieren.
Der BME680 misst Temperatur, relative Luftfeuchte, Luftdruck und VOC (Volatile Organic Compounds)
Diskussion, Probleme und Fortschritte dazu siehe hier: https://forum.fhem.de/index.php/topic,78128.msg700815.html#msg700815
Ich habe einen Durchbruch erzielt. :) Ich kann den Fehler jetzt Ein- und Ausschalten und sogar austricksen.
Die Vermutung mit dem Problem auf der 3,3V Schiene war ne Sackgasse. Die Tatsache dass der NodeMCU allein mit dem RFM69 vorgestern eine Weile problemlos startete hatte andere Ursachen, die ich in dem Zeitpunkt aber noch nicht im entferntesten in Zusammenhang bringen konnte. Dazu später mehr ...
Zitat von: PeMue am 16 Oktober 2017, 21:15:36
Für Windows Nutzer geht das auch mit dem NodeMCU Flasher (http://s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/131-loeschen-des-gesamten-flashspeichers).
Das klappte nicht wirklich. Ich hab wie in der Anleitung genannt die ganzen Einträge gemacht, überall das x gesetzt und geflasht. Der NodeMCU schien auch leer zu sein, zumindest tat sich beim Start nichts mehr. Nachdem ich das LGW wieder geflasht hatte, waren aber sofort alle Setup-Einstellungen wieder drin. Also kann nicht alles gelöscht gewesen sein.
Zitat von: HCS am 16 Oktober 2017, 21:08:35
Neuer Anlauf: steck es an einen Rechner und führe ein flash erase durch.
esptool.py --port COM3 erase_flash
bzw.
esptool.py --port /dev/ttyWasAuchImmmer erase_flash
Das klingt immer so schon einfach. ;) Ich als Linux-DAU hab erstmal gefühlt zwei Stunden gebraucht um Python, pip und esptool auf den Raspberry zu bekommen. Aber dann konnte ich es damit löschen und nach dem LGW flashen war es diesmal wirklich jungfräulich.
WiFi Einstellungen vorgenommen, reboot und getestet. Zig Reboots, immer wieder Strom weggenommen, und immer startete es. :) Ein erstes Erfolgsgefühl stellte sich ein. Also alle Setup-Einstellungen wieder eingertragen und reboot ... :o :o :o ... Fehler war wieder da! Nun war ich mir schon ziemlich sicher dass es an irgendwelchen Einstellungen liegen musste und ich habe durchprobiert wann der Fehler wieder eintritt.
Das Ergebnis war das Startup Delay! Steht das bei 0, klappt der Reboot immer. Stelle ich das auf 30, dann schlägt jeder 2. Reboot fehl. Das dort was nicht hinhaut war mir schon vorgestern aufgefallen, da hab ich aber noch keinen Zusammenhang gesehen. Wiki sagt zum Delay "Mit diesen Konfigurationsprameter kann eine Verzögerung (in Sekunden) definiert werden, bis das LGW nach einen Neustart einen ersten Verbindungsversuch zum WiFi Access Point (Router: Fritzbox etc.) startet." - das macht es bei mir nicht! Trotz in meinem Fall eingetragenen 30 Sekunden reagiert das LGW sofort nach der Versorgung mit Spannung innerhalb des Delays auf Pings, es muss also sofort wieder eine Verbindung herstellen. Nach Ablauf der Delay-Zeit, wenn auf dem Display "Connect Wifi" erscheint, bricht dann die Verbindung zusammen und es ist der von mir beschriebene Fehler da.
Einzige Ausnahme ist, wenn man einen Dauer-Ping auf das LGW laufen hat, dann tritt dieser Fehler nicht auf. Das war auch der Grund warum ich vorgestern dachte dass NodeMCU + RFM69 alleine problemlos starten - da ich kein Display mit Anzeigen mehr hatte lief auf dem Rechner ein Dauerping weil ich daran sehen konnte in welchem "Zustand" an LGW gerade ist.
Meine erste Abhilfe jetzt lautet Startup-delay auf 0 setzen, aber das hat ja jetzt wieder was von Auswirkung statt Ursache bekämpfen. Beim nächsten Netzwischer hängt dann das LGW wieder in der Luft, weil der AP nicht so schnell startbereit ist.
Und jetzt hoffe ich dass dieses Phänomen reproduzierbar und behebbar ist.
MfG
Marco
Zitat von: marco-f am 18 Oktober 2017, 10:11:04
Das klappte nicht wirklich. Ich hab wie in der Anleitung genannt die ganzen Einträge gemacht, überall das x gesetzt und geflasht. Der NodeMCU schien auch leer zu sein, zumindest tat sich beim Start nichts mehr. Nachdem ich das LGW wieder geflasht hatte, waren aber sofort alle Setup-Einstellungen wieder drin. Also kann nicht alles gelöscht gewesen sein.
Sonderbar, ich hatte mal auf einem WeMos D1 mini mit ESPEasy geflasht und dann mit dieser Methode "leer" gemacht. Das hat funktioniert. Werde das mal mit dem LGW probieren ...
Gruß PeMue
Zitat von: marco-f am 18 Oktober 2017, 10:11:04
Meine erste Abhilfe jetzt lautet Startup-delay auf 0 setzen, aber das hat ja jetzt wieder was von Auswirkung statt Ursache bekämpfen. Beim nächsten Netzwischer hängt dann das LGW wieder in der Luft, weil der AP nicht so schnell startbereit ist.
Das funktioniert mit Startup-delay 0 trotzdem, aber Du musst eventuell den Timeout auf der Setup-page für die erste SSID hochsetzen, auf einen Wert, der länger als die Zeit von Deinem AP ist, bis er hochgefahren ist.
Genau dieses Thema habe ich in V1.23 erledigt. Siehe hier:
https://forum.fhem.de/index.php/topic,43672.msg512376/topicseen.html#msg512376
Zitat daraus:
ZitatV1.23
Connectverhalten auf einen AP
Das ganze kommt aus dem Stromausfall-Thema, bei dem das LGW viel schneller als der AP bereit ist und bereits aufgibt, bevor der AP nach ein bis zwei Minuten bereit ist, einen Connect anzunehmen.
Man kann nun auf der Setup-Page für beide SSIDs einen Timeout konfigurieren.
120 bedeutet z.B. dass das LGW 120 Sekunden lang versucht, die SSID zu erreichen.
Diese Zeit war bisher hart in der Frimware auf 15 Sekunden festgelegt.
Dafür kann man dann das Startup-delay wieder auf 0 stellen.
Ich habe "Stromausfall" wie folgt simuliert und getestet:
- AP aus/ein, LGW bleibt an
- LGW aus/ein, AP bleibt an
- LGW + AP aus/ein
In allen drei Fällen kam die Verbindung wieder zustande und nach ein bis zwei Minuten sind wieder Daten in FHEM eingelaufen.
Zitat von: marco-f am 18 Oktober 2017, 10:11:04
Und jetzt hoffe ich dass dieses Phänomen reproduzierbar und behebbar ist.
OK, das kann ich mal versuchen zu reproduzieren (und ggf. zu korrigieren).
Ich überlege gerade, wozu man das Startup-Delay überhaupt noch braucht.
Der Hammer, wie Du das rausexperimentiert hast, auf die Idee wäre ich nie gekommen 8)
Suchst Du gerade eine neue Stelle als Tester?
Ok, stelle ich mal den Timeout hoch. Für mich klang der Startup-Delay nur damals nach genau dem was ich gesucht habe, als eben nach einem Netzwischer das LGW nicht wieder hoch kam.
An teilweise haarsträubende Fehlersuchen gewöhnt man sich in 15 Jahren Nachrichtentechniker irgendwann. Das Problem ist nur immer nicht irgendwann den Enthusiasmus zu verlieren. ::)
Zitat von: marco-f am 18 Oktober 2017, 10:11:04
Und jetzt hoffe ich dass dieses Phänomen reproduzierbar und behebbar ist.
Zumindest reproduzierbar. Mit 30 Sekunden delay geht es tatsächlich nur jedes zweite mal :o
Ich werde der Sache mal auf den Grund gehen.
Zitat von: HCS am 19 Oktober 2017, 20:47:21
Zumindest reproduzierbar. Mit 30 Sekunden delay geht es tatsächlich nur jedes zweite mal :o
Ich werde der Sache mal auf den Grund gehen.
Puuh ... da bin ich ja schonmal beruhigt! 8) Ich hab mal eine kleine Testreihe gemacht ... ich hab das Gefühl der Fehler tritt auf sobald die Delay-Zeit zweistellig wird. 5 Sekunden, 8 Sekunden, 9 Sekunden ... alles klappt ... ab 10 Sekunden aufwärts kommt bei mir immer der Fehler durch.
Zitat von: marco-f am 19 Oktober 2017, 21:23:34
Puuh ... da bin ich ja schonmal beruhigt! 8) Ich hab mal eine kleine Testreihe gemacht ... ich hab das Gefühl der Fehler tritt auf sobald die Delay-Zeit zweistellig wird. 5 Sekunden, 8 Sekunden, 9 Sekunden ... alles klappt ... ab 10 Sekunden aufwärts kommt bei mir immer der Fehler durch.
Ich denke ich konnte das Problem beseitigen. Das ist ein recht seltsames Verhalten vom ESP8266, wenn man nach dem Programmstart lange genug WiFi nicht initialisiert.
In der nächsten Version wird es dann wohl gehen, dauert aber noch eine Weile, bis es die gibt.
Eilt ja aber nicht, da man sich das delay eh schenken kann.
Hier die Antwort für die Frage von dort:
Zitat von: Saharel am 29 Oktober 2017, 15:32:29
Das Webseiten Password und das WiFi Password könne per Serieller Verbindung in Klartext ausgelesen werden.
Wäre hier eine verschlüsselte Ablage im EEPROM möglich?
Mit viel Umbau und Kompatibilitätsproblemen zur aktuellen Version wohl ja, aber ich halte es für übertrieben.
Das werde ich nicht implementieren.
Zitat von: HCS am 25 Oktober 2017, 11:24:53
Ich denke ich konnte das Problem beseitigen. Das ist ein recht seltsames Verhalten vom ESP8266, wenn man nach dem Programmstart lange genug WiFi nicht initialisiert.
In der nächsten Version wird es dann wohl gehen, dauert aber noch eine Weile, bis es die gibt.
Eilt ja aber nicht, da man sich das delay eh schenken kann.
Ok, ich werde es testen! :)
Mein anderes Problem trat dieser Tage auch wieder vermehrt auf, aber diesmal entdeckte ich, mit den richtigen Suchbegriffen, dass der Fehler schon bekannt ist.
Zitat von: HCS am 19 September 2017, 19:01:08
Meinst Du damit "Edit files" -> "fhem.cfg" -> "Save fhem.cfg" ?
Uiiii, wenn das manche Leute lesen, dass jemand die fhem.cfg editiert ... ;D ;D ;D
OK, habe es mal ausprobiert. Funktioniert wirklich nicht. Keine Ahnung, was beim Speichern der fhem.cfg spezial ist.
Aber da gibt es noch mehr. Fronthem überlebt das auch nicht. Wenn ich mal Zeit habe muss ich mal forschen.
Ja, ich gehöre auch zu denen die gern in der fhem.cfg direkt rumoperieren. ;) Aber damit habe ich im Augenblick zumindest das Gefühl die Fehlfunktionen meines LGW zu kennen und kann entsprechend gegensteuern. Vielleicht wird das ja dann in der nächsten Version alles behoben!? ;)
Grüße,
Marco
Zitat von: HCS am 28 September 2017, 15:30:31
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.
So meine Rückmeldung zu dem Problem.
Also der Stick verbindet sich korrekt.
Aber er findet dann immer nur teilweise meine Funksensoren und die er dann findet dauern recht lange bis Sie erscheinen.
Wie kann ich das verändern ??
Ich habe 3 Technoline TX290TH-IT dran hängen.
Danke & Grüße
Zitat von: Dummbatz am 01 November 2017, 18:55:20
Aber er findet dann immer nur teilweise meine Funksensoren und die er dann findet dauern recht lange bis Sie erscheinen.
Wie kann ich das verändern ??
Ich habe 3 Technoline TX290TH-IT dran hängen.
Ich vermute, dass Du TX29DTH-IT meinst. Davon habe ich auch drei und keinerlei Probleme.
Häng mal einen list von LaCrosseGateway device an.
Hallo,
ist es möglich bei der nächsten Version den HTU21D(Temp/Humi) Sensor mit aufzunehmen?
Grüße Saharel
Zitat von: Saharel am 03 November 2017, 10:48:33
ist es möglich bei der nächsten Version den HTU21D(Temp/Humi) Sensor mit aufzunehmen?
Eher nicht. Das LGW kann schon genug Sensoren (LM75, BMP180, BME280, DHT11, DHT22, SHT75) und gerade kommt der BME680 dazu. Das sollte doch reichen.
Zitat von: HCS am 03 November 2017, 11:10:09
Eher nicht. Das LGW kann schon genug Sensoren (LM75, BMP180, BME280, DHT11, DHT22, SHT75) und gerade kommt der BME680 dazu. Das sollte doch reichen.
Hi,
anbei mal eine View auf meine eigenen Änderungen 8)
Über die Setup Page kann mann nun eine css url bestimmen (extern) und der HTU21D geht auch ;D
Falls du unterstützung beim Coden brauchst, sage bescheid.
Ich habe die Version 1.31 fork gennant, habe ab nicht vor irgendwas davon zu veröffentlichen, ist nur für mich intern.
Aufgrund der Problematik mit dem Arduino-CUL-Reset am LGW möchte ich das Thema SubProzessor-Bootloader aufgreifen.
Der hier angehängte Optiboot (https://github.com/Optiboot/optiboot) ist kompatibel zum Arduino Pro 3,3V 8 MHz Board. Ich habe die Baudrate auf 57600 halbiert. Somit ist es möglich den ATMEGA328P per avrdude mit Firmware zu füttern:
avrdude -p atmega328p -c arduino -P /dev/ttyUSB0 -b 57600 -U flash:w:addon.hex:i
Firmware flashen mithilfe von curl funktioniert nicht.
@HCS eine Ahnung warum nicht?
ISP-Programmer vorausgesetzt - hier die Fusebits für ATMEGA328P:
low_fuses=0xFF
high_fuses=0xDE
extended_fuses=0x05
unlock_bits=0x3F
lock_bits=0x0F
Bitte testen!
Zitat von: HCS am 03 November 2017, 04:32:43
Ich vermute, dass Du TX29DTH-IT meinst. Davon habe ich auch drei und keinerlei Probleme.
Häng mal einen list von LaCrosseGateway device an.
Danke für Deine Rückmeldung.
Ich scheine ein etwas größeres Problem zu haben, evtl. wäre es besser einen neuen Thread auf zu machen.
Mein List ergibt:
Internals:
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol
DEF 192.168.0.001:81
DeviceName 192.168.0.001:81
FD 4
NAME T_Gateway
NR 36
PARTIAL
RAWMSG OK WS 0 4 5 125 255 255 255 255 255 255 255 255 255 0
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
T_Gateway_MSGCNT 134706
T_Gateway_TIME 2017-11-04 13:29:49
model LaCrosseITPlusReader.Gateway.1.25
settings (1=RFM69 f:868300 r:17241) + LM75 {IP=192.168.0.1}]
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-11-04 13:29:49 state initialized
helper:
Attributes:
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
KA was man daraus erkennen kann...
Aber wenn ich mir die Sensoren ansehe ist da ein Unterschied bzw. anderes Verhalten.
In den Readings vom Sensor werden diese in Rot dargestellt.
Bei einem Sensor habe ich ein Reading drin das nennt sich Error und ich weiß nicht wo das herkommt.
Auch hier werden einige Readings nach einiger Zeit in Rot dargestellt.
Im Event Monitor kann ich aber sehen das alle 3 Sensoren Daten übertragen.
Bin gerade etwas ratlos....
LG
Hi,
rot bedeutet, dass der Wert während der Anzeige aktualisiert wurde.
Gruß
Olly
@Olly,
Danke
dann habe ich das Problem das nicht alle aktualisiert werden.
Wie kann ich der Sache auf die Spur kommen ?
Zitat von: Dummbatz am 04 November 2017, 14:59:34
@Olly,
Danke
dann habe ich das Problem das nicht alle aktualisiert werden.
Wie kann ich der Sache auf die Spur kommen ?
Ggf. erst mal den Abstand verringern. Vielleicht ist es ja ein Reichweitenproblem.
@HCS
Besteht die Möglichkeit eine Funktion einzubauen, die die empfangenen Daten über MQTT sendet ?
Sprich, das die Daten eines jeden empfangenen Sensors gesendet werden ?
Gruß
Sascha
Zitat von: sash.sc am 18 November 2017, 17:10:19
Besteht die Möglichkeit eine Funktion einzubauen, die die empfangenen Daten über MQTT sendet ?
Nein, MQTT wird es nicht geben.
Hi,
mir ist aufgefallen das am nextion Display der UpTime Wert nur mit dem letzten Wert der Home Seite des Gateways befüllt wird.
Solange ich die Webseite nicht aufrufe bzw. aktualisiere wird der Wert am nextion nicht aktualisiert.
Ist das so gewollt?
Zitat von: Saharel am 29 November 2017, 21:48:01
Hi,
mir ist aufgefallen das am nextion Display der UpTime Wert nur mit dem letzten Wert der Home Seite des Gateways befüllt wird.
Solange ich die Webseite nicht aufrufe bzw. aktualisiere wird der Wert am nextion nicht aktualisiert.
Ist das so gewollt?
Das war nicht gewollt. Ich nehme es auf die ToDo-Liste.
Hallo HCS,
für die Erweiterung mit SC16IS750 sollte es doch egal sein, welche Daten über die serielle Schnittstelle gesendet werden, oder?
franky08 hat hier (https://forum.fhem.de/index.php/topic,80226.msg726351.html#msg726351) ein Problem geschildert, das ich nicht nachvollziehen kann.
Filtert das LGW irgendwelche Sonderzeichen raus? Ist der SC16IS750 besonders dritisch beim Timing (Tx wird wohl nicht übertragen)?
Könntest Du Dir das bitte mal anschauen?
Danke + Gruß
PeMue
Zitat von: PeMue am 05 Dezember 2017, 16:27:51
für die Erweiterung mit SC16IS750 sollte es doch egal sein, welche Daten über die serielle Schnittstelle gesendet werden, oder?
So sollte es sein.
Zitat von: PeMue am 05 Dezember 2017, 16:27:51
franky08 hat hier (http://sc16is750) ein Problem geschildert, das ich nicht nachvollziehen kann.
url=http://SC16IS750 ;)
Kannst Du nochmal einen neuen Anlauf mit dem Link machen?
Zitat von: PeMue am 05 Dezember 2017, 16:27:51
Filtert das LGW irgendwelche Sonderzeichen raus?
Nicht dass ich wüsste
Zitat von: PeMue am 05 Dezember 2017, 16:27:51
Ist der SC16IS750 besonders dritisch beim Timing (Tx wird wohl nicht übertragen)?
Wenn man irre schnell Daten füttert (Richtung: serial device ->SC16IS750 -> FHEM ), kann es sein, dass man den recht kleinen fifo des SC16IS750 voll macht und dann Daten verliert.
Das LGW muss die Daten vom SC16IS750 "gelegentlich" aus dem fifo holen und an FHEM senden, kann das aber natürlich nicht hauptamtlich machen, es hat ja noch mehr zu tun.
Zitat von: HCS am 05 Dezember 2017, 17:12:33
Kannst Du nochmal einen neuen Anlauf mit dem Link machen?
Ups, sorry. Diesmal nicht mit Edit (hab's aber oben trotzdem korrigiert): https://forum.fhem.de/index.php/topic,80226.msg726351.html#msg726351
Gruß Peter
Ich habe dank der Platinen von PeMue nun auch ein LacrosseGateway laufen. Die Einbindung des Gateways selbst ging gut und auch meine Lacrosse-Sensoren (TX 29) funktionieren ohne Probleme.
Ich bekomme allerdings meine EC3000 Steckdosen nicht erkannt. Gibt es da irgendeine Magie, die ich in der Doku nicht entdeckt habe die man braucht, um die ans Laufen zu bekommen?
Mein Setup sieht wie folgt aus: NodeMCU/Devkit, 2x RFM69C(W) (der erste im Toggle Mode zwischen 17.241 und 9.579, der zweite exclusiv für EC3000 mit 868300 und 20.000 Data Rate). Ich habe noch per USB einen Jeelink am FHEM Server hängen, mit dem ich die Steckdosen bisher auslese. Der erreicht aber nicht alle Steckdosen, drum wollte ich den durch ein LGW erweitern oder durch zwei ersetzen (sollte ein LGW alle empfangen können natürlich nur eins).
Im Log sehe ich dauernd Einträge, die aussehen als ob sie von den Steckdosen kommen könnten (die ersten zwei Byte in den eckigen Klammern ähneln verdächtig den IDs der Steckdosen) - ich denke also mal, der Empfang klappt. Werden die EC3000 Devices überhaupt per autocreate angelegt? Falls nicht, wie legt man sie an? Falls doch, wie könnte man das Problem einkreisen?
Zitat von: schmadde am 06 Dezember 2017, 20:27:30
Ich bekomme allerdings meine EC3000 Steckdosen nicht erkannt. Gibt es da irgendeine Magie, die ich in der Doku nicht entdeckt habe die man braucht, um die ans Laufen zu bekommen?
Schau mal im Wiki nach, siehe https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Inbetriebnahme_von_Energy_Count_3000_.28EC3000.29
Gruß PeMue
Zitat von: PeMue am 06 Dezember 2017, 20:35:33
Schau mal im Wiki nach, siehe https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Inbetriebnahme_von_Energy_Count_3000_.28EC3000.29
Da steht halt auch nur drin, wie man das Radio konfigurieren muss, um die Daten zu empfangen. Ich glaube aber, dass der Empfang klappt (wenn ich wüsste, wie man die Zeilen im Log dekodiert, wäre ich sicher - aber da die ersten zwei Bytes in eckigen Klammern eigentlich immer eine mir bekannte Steckdosen-ID ist, bin ich recht sicher).
Beispiel: 20:44:24: OK 22 160 82 2 198 163 82 1 68 121 79 0 7 55 25 0 0 94 233 1 0 [A0 52 A3 52 00 00 79 4F 00 00 00 05 76 DB 2B 00 00 5E E9 00 12 06 3D 76 47 82 76 BF E0 2C 60 00 00 00 06 14 40 10 06 7B B7]
A0 52 ist die ID von der Messteckdose an meiner Spülmaschine.
Ich vermute, dass einfach die Devices im FHEM nicht da sind und sozusagen die Verknüpfung fehlt. Da wüsste ich aber nicht wie man das anlegt.
Wäre auch dankbar für einen Hinweis, ob zwei EC3000 Empfänger gleichzeitig überhaupt gehen - egal jetzt ob 2x LGW oder 1x LGW, 1x Jeelink. Die Zuordnung für Devices könnte ich ja dann manuell machen und einen Autocreate-Filter anlegen (den brauch ich sowieso bald, weil ich schon hunderte Geister-EC3000s habe und soweit ich das sehe auch welche vom Nachbarn).
Wie heissen die Devices eigentlich, wenn sie "autocreated" werden? Beim Jeelink immer EC3000_<ID_in_Hex>.
Zitat von: schmadde am 06 Dezember 2017, 20:42:36
Beispiel: 20:44:24: OK 22 160 82 2 198 163 82 1 68 121 79 0 7 55 25 0 0 94 233 1 0 [A0 52 A3 52 00 00 79 4F 00 00 00 05 76 DB 2B 00 00 5E E9 00 12 06 3D 76 47 82 76 BF E0 2C 60 00 00 00 06 14 40 10 06 7B B7]
Ja das ist eine EC3000
Zitat von: schmadde am 06 Dezember 2017, 20:42:36
Da wüsste ich aber nicht wie man das anlegt.
define Spuelmaschine EC3000 A052Bei mir werden die aber von autocreate angelegt, sobald sie das erste mal empfangen werden.
Zitat von: schmadde am 06 Dezember 2017, 20:42:36
Wäre auch dankbar für einen Hinweis, ob zwei EC3000 Empfänger gleichzeitig überhaupt gehen
Ja, das geht. FHEM verwirft Daten, die doppelt empfangen wurden, automatisch.
Zitat von: schmadde am 06 Dezember 2017, 20:42:36
Wie heissen die Devices eigentlich, wenn sie "autocreated" werden? Beim Jeelink immer EC3000_<ID_in_Hex>.
Genau so. Dem EC3000 Modul ist es egal, ob das von JeeLink oder LaCrosseGateway kommt.
Das Prinzip ist ja: irgend ein (oder mehrere) IODev (JeeLink oder LGW) empfängt die Daten und gibt sie an das EC3000-Modul weiter.
Ab da ist der weiter Verlauf dann immer gleich.
Ah jetzt verstehe ich. Danke @HCS für den Nachhilfeunterricht. Wenn die Devices genau gleich heissen und behandelt werden ist klar, dass sie nicht angelegt werden: es gibt sie ja bereits. Ich habe mal testweise das IODev einer Steckdose von Jeelink auf LGW umgestellt und siehe da: es scheint zu funktionieren.
Nachdem ich jetzt grade 70 (!) Geister-EC3000 aus meiner Config und dem Logverzeichnis getilgt habe, hab ich das Autocreate für alle devices die mit EC3000 anfangen abgeschaltet und werde in Zukunft die Dinger manuell anlegen. 63 haben übrigens noch nie ein Byte Daten empfangen und von den anderen 7 haben 5 nur einmal einen kompletten Datensatz im Log stehen gehabt. Da die Werte teils ziemlich unplausibel waren (>3,5kW Momentanleistung, zig MWh Gesamtverbrauch) denke ich dass es sich um Übertragungsfehler handelt.
Gibts nicht irgendeine Möglichkeit, solche Fehler rauszufiltern, bevor sie entstehen? Also Devices nur anlegen, wenn sie wenigstens einmal, besser zweimal gültige Daten empfangen haben?
Zitat von: schmadde am 06 Dezember 2017, 23:11:35
Also Devices nur anlegen, wenn sie wenigstens einmal, besser zweimal gültige Daten empfangen haben?
Schau Dir mal das autocreateThreshold attribut von autocreate an
aus der commandref:
ZitatautocreateThreshold
A list of <type>:<count>:<interval> triplets. A new device is only created if there have been at least count events of TYPE type in the last interval seconds.
attr autocreateThreshold LaCrosse:2:30,EMT7110:2:60
Bedeutet: LaCrosse devices werden nur angelegt, wenn der Sensor innerhalb 30 Sekunden zwei mal empfangen wurde.
Für Dich wäre das dann
attr autocreateThreshold LaCrosse:2:30,EC3000:2:30
Besten Dank, funktioniert hervorragend!
Noch ne Frage zum LGW. Ich habe mir ein Display mit SSD1306 Chip bestellt, leider hab ich wohl nicht aufgepasst und eins mit I2C/SPI alternativ bestellt. Da steht was im Wiki von "Platine muss modifiziert werden". Kennt jemand folgende Platine und weiss was man da machen muss? Vermutlich SMD Widerstände umlöten / hinzufügen:
(https://farm5.staticflickr.com/4686/27651693529_b696f6126b_z.jpg) (https://flic.kr/p/J8ua7H)Ssd1306 (https://flic.kr/p/J8ua7H)
Hallo schmadde,
HCS hat hier (https://forum.fhem.de/index.php/topic,52921.msg527670.html#msg527670) mal eine Abhanldung darüber verfasst.
Gruß PeMue
Hallo zusammen,
habe gerade das LaCrosseGateway auf Basis eines ESP 12E und RFM69CW aufgesetzt und in Fhem eingebunden - das klappte schon mal super! Vielen Dank an der Stelle für die tolle Arbeit.
Zur Aufgabenstellung: Mein Jeelink erreicht nicht alle Sensoren zuverlässig, da die TX29 über 2 Stockwerke verteilt sind. Daher ursprünglich die Idee einen Jeelink im Relay Betrieb einzusetzen (leider hat das nicht zuverlässig funktioniert) und so bin ich über das LaCrosseGateway gestolpert.
Jeelink, TX29 Sensoren und LaCrosseGateway sind nun auf einem raspberrypi 2 eingebunden.
1. Sollte ich nach dem pairing mittels LaCrosseGateway nun alle Sensoren doppelt sehen oder kommunizieren Jeelink und LaCrosseGateway irgendwie? Ein Device vom Type KeyValueProtocol und ein mir unbekannter LaCrosse Sensor wurden hinzugefügt aber mehr bisher nicht.
2. Kann man das LaCrosseGateway auch im Relay Betrieb einsetzen? Ich habe mal versuchshalber "1y" im Attribut initCommands des LaCrosseGateway übergeben und sehe auch im Device (siehe unten) Jeelink und LaCrosseGateway Einträge aber was das wirklich zu bedeuten ist mir nicht ganz klar.
3. Sollte relay Betrieb nicht implementiert sein, könnte man mehrere Gateways zusammenfassen ähnlich VCCU?
Wäre super wenn einer der Experten ein wenig Licht ins Dunkel bringen könnte.
Internals:
CFGFN
Clients LaCrosse
DEF 192.168.178.38:81
DeviceName 192.168.178.38:81
FD 21
NAME myLaCrosseGateway
NR 29368
NTFY_ORDER 50-myLaCrosseGateway
PARTIAL
RAWMSG OK 9 42 1 4 22 87
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.30
myLaCrosseGateway_MSGCNT 3611
myLaCrosseGateway_TIME 2018-01-06 18:12:02
nextOpenDelay 2
settings (1=RFM69 f:868300 r:17241) {IP=192.168.178.38}]
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:
2018-01-06 18:12:01 FramesPerMinute 65
2018-01-06 18:12:01 FreeHeap 17376
2018-01-06 18:12:01 OLED none
2018-01-06 18:12:01 RSSI -66
2018-01-06 18:12:01 ReceivedFrames 2264
2018-01-06 18:12:01 UpTime 0Tg. 0Std. 38Min. 35Sek.
2018-01-06 18:12:01 UpTimeSeconds 2315
2018-01-06 18:12:02 state initialized
helper:
Attributes:
Clients LaCrosse
group LaCrosse
icon cul_wlan
initCommands 1y 0#1r v
kvp both
mode WiFi
ownSensors both
room Gateways
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
Internals:
CHANGED
DEF 27
IODev myJeeLink
LASTInputDev myLaCrosseGateway
LaCrosse_lastRcv 2018-01-06 18:11:07
MSGCNT 9963
NAME Wasserwaechter_Bad
NR 52
STATE T: 21
TYPE LaCrosse
addr 27
battery_new 1
corr1 0
corr2 0
myJeeLink_MSGCNT 9750
myJeeLink_RAWMSG OK 9 39 130 2 183 125
myJeeLink_TIME 2018-01-06 18:11:07
myLaCrosseGateway_MSGCNT 378
myLaCrosseGateway_TIME 2018-01-06 18:11:07
previousH 106
previousH2 125
previousT 21
previousT2 -30.4
sensorType 0=T(H)
READINGS:
2018-01-06 18:11:07 Wasseralarm no
2018-01-06 18:11:07 battery ok
2018-01-06 17:12:56 state T: 21
2018-01-06 18:10:54 temperature 21
2018-01-06 18:11:07 temperature2 -30.5
Attributes:
IODev myJeeLink
event-min-interval state:60,temperature:600,temperature2:60,battery:3600
event-on-change-reading .*
room Sensoren
userReadings Wasseralarm { ReadingsNum("Wasserwaechter_Bad","temperature2",0) > -10 ? 'yes' : 'no' }
Vielen Dank, Sven
Zitat von: hoods am 06 Januar 2018, 18:25:10
1. Sollte ich nach dem pairing mittels LaCrosseGateway nun alle Sensoren doppelt sehen...
Nein. Ein Sensor ist durch seine ID eindeutig und wird nicht doppelt angelegt, auch wenn er von unterschiedlichen Devices empfangen wird.
Zitat von: hoods am 06 Januar 2018, 18:25:10
1. ...oder kommunizieren Jeelink und LaCrosseGateway irgendwie?
Nein, das wird in FHEM geregelt.
Wenn mehrere Devices (z.B. zwei LGW und ein JeeLink) den Sensor empfangen, eliminiert FHEM auch automatisch doppelt eingegangene Datenpakete
Zitat von: hoods am 06 Januar 2018, 18:25:10
2. Kann man das LaCrosseGateway auch im Relay Betrieb einsetzen?
Nein, das LGW kann das nicht.
Zitat von: hoods am 06 Januar 2018, 18:25:10
3. Sollte relay Betrieb nicht implementiert sein, könnte man mehrere Gateways zusammenfassen ähnlich VCCU?
Keine Ahnung, was VCCU ist, aber man kann beliebig viele LGWs laufen lassen, habe auch mehrere hier verteilt.
Der Doppelempfang von Daten wird in FHEM geregelt, siehe oben. Man muss bei mehreren LGWs, die man laufen hat, nichts weiter tun.
V1.31
UniversalSensor
Das LGW kann nun das UniversalSensor-Protokoll verarbeiten, das angelehnt an LaCrosse:
- Temperatur
- Feuchte
- Regenmenge
- Windrichtung
- Windstärke
- Windböen
- Luftdruck
- Zwei Gas-Werte
- Helligkeit
- Spannung
- Versionsnummer
- Einen drei Byte debug-Wert
mit CRC16 abgesichert empfangen und an das LaCrosse-Modul weiterreichen kann.
Damit ist es möglich, selbst entwickelte Sensoren anzubinden, ohne auf FHEM-Seite etwas tun zu müssen.
Das zu sendende Prtokoll siehe UniversalSensor.cpp
BME680
Ein per I2C angeschlossener BME680 (Adresse 0x76) wird automatisch erkannt und seine Werte (Temperatur, Luftfeuchtigkeit, Luftdruck und vom Gassensor gelieferter Widerstand) werden wie bei einem BME280 an das LGW und ggf. ein nachgelagertes LaCrosse-Device übermittelt.
Es findet keine IAQ-Berechnung statt, man muss also auf FHEM-Seite die Widwerstandswerte selbst in irgend einer Form interpretieren.
Nachkommastellen (optional) für den Luftdruck
Auf der Setup-Page des LGW kann nun konfiguriert werden, ob der Luftdruck mit Nachkommastellen übermittelt wird.
WiFi-Connect-Fehler bei Starup-Delay behoben
Mit einem Startup-Delay von 30 Sekunden schlug jeder zweite connect-Versuch zum AP fehl.
Ist eingecheckt, wird ab morgen vom FHEM-Update ausgeliefert.
ZitatNachkommastellen (optional) für den Luftdruck
Auf der Setup-Page des LGW kann nun konfiguriert werden, ob der Luftdruck mit Nachkommastellen übermittelt wird.
:) :)
Danke,
VG Frank
Hallo HCS,
Zitat von: HCS am 14 Januar 2018, 19:21:45
BME680
Ein per I2C angeschlossener BME680 (Adresse 0x76) wird automatisch erkannt und seine Werte (Temperatur, Luftfeuchtigkeit, Luftdruck und vom Gassensor gelieferter Widerstand) werden wie bei einem BME280 an das LGW und ggf. ein nachgelagertes LaCrosse-Device übermittelt.
Es findet keine IAQ-Berechnung statt, man muss also auf FHEM-Seite die Widwerstandswerte selbst in irgend einer Form interpretieren.
ZitatWenn ein BME280 vorhanden ist, wird dieser verwendet und sonst nichts, da man dann bereits Temperatur, Feuchte und Druck hat.
Ist kein BME280 vorhanden, wird geschaut, ob ein BMP180 vorhanden ist. Falls ja, haben wir Druck und Temperatur.
Dann wird geschaut, ob ein DHT22 vorhanden ist. Wenn ja, wird er zusätzlich verwendet, aber vom BMP180 dann nur noch der Druck.
Temperatur und Feuchte vom DHT22, dass dieses Wertepaar von einem Sensor stammt.
Wenn kein BMP180 und kein BME180 da ist, sondern nur ein DHT22, dann hat man Temperatur und Feuchte.
Wenn nichts vorhanden ist (also keiner der bisher genannten Sensoren), wird, falls vorhanden, der LM75 verwendet.
Wie ist das mit dem BME680? Wenn BME680 (auf 0x76) erkannt wird, dann wird nicht mehr nach einem zusätzlichen Sensor gesucht, korrekt? Dann würde ich nämlich auf den Platinen den BME680 fest auf 0x76 verdrahten und ggf. dem BME280 auf der LGW Platine fest 0x77 zuweisen ...
Danke + Gruß
PeMue
Zitat von: PeMue am 16 Januar 2018, 17:03:23
Wie ist das mit dem BME680? Wenn BME680 (auf 0x76) erkannt wird, dann wird nicht mehr nach einem zusätzlichen Sensor gesucht, korrekt? Dann würde ich nämlich auf den Platinen den BME680 fest auf 0x76 verdrahten und ggf. dem BME280 auf der LGW Platine fest 0x77 zuweisen ...
Das würde ich nicht tun.
Das LGW versucht auf 0x76 zuerst einen BME680 zu erkennen, und falls keiner da ist, versucht es auf 0x76 einen BME280 zu erkennen.
Unabhängig davon, also egal ob BME680, BME280 oder keiner erkannt wurde, versucht es einen BMP180 auf 0x77 zu erkennen.
Auf der Platine sollte sowohl BME680 als auch BME280 auf 0x76 gesetzt sein und man darf nur einen der beiden bestücken.
Zitat von: PeMue am 16 Januar 2018, 17:03:23
ZitatWenn ein BME280 vorhanden ist, wird dieser verwendet und sonst nichts, da man dann bereits Temperatur, Feuchte und Druck hat.
Ist kein BME280 vorhanden, wird geschaut, ob ein BMP180 vorhanden ist. Falls ja, haben wir Druck und Temperatur.
Dann wird geschaut, ob ein DHT22 vorhanden ist. Wenn ja, wird er zusätzlich verwendet, aber vom BMP180 dann nur noch der Druck.
Temperatur und Feuchte vom DHT22, dass dieses Wertepaar von einem Sensor stammt.
Wenn kein BMP180 und kein BME180 da ist, sondern nur ein DHT22, dann hat man Temperatur und Feuchte.
Wenn nichts vorhanden ist (also keiner der bisher genannten Sensoren), wird, falls vorhanden, der LM75 verwendet.
Das Zitat bezieht sich nicht auf das Suchen von Sensoren sondern darauf, welcher Wert von welchem erkannten Sensor genommen und alle 10 Sekunden ausgeliefert wird.
Besonders für den Fall, dass mehrere Sensoren vorhanden sind.
Zitat von: HCS am 16 Januar 2018, 17:10:02
Das würde ich nicht tun.
Ok, dann BME680 auf 0x76 bzw. BME280 auf 0x76, kein BMP180 (oder vielleicht kriege ich den noch drauf ??? den aber auf 0x77 (aber der sollte eh fest programmiert sein ???)).
Danke + Gruß
Peter
Hallo zusammen,
hätte auch noch ein Frage bezüglich dem Vorgehen einer "Ersetzung" eines JeeLinks für PCA301 zu dem LaCrosseGateway.
Ausgangssituation:
Habe 2 PCA301 Steckdosen im Keller. Seit ca. 1 Jahr Empfang per Jeelink (Leider Empfangsprobleme sobald die Tür zum Kellerraum geschlossen wird).
Meine Idee:
Ich setze im Keller das LaCrosseGateway ein um die PCA301 zu empfangen.
Den JeeLink lass ich weiter aktiv für den anderen Dosen OG, DG.
Habe das Gateway auch auf die neueste Version geflasht und in FHEM mit dem Attribute "initCommands 1,868950,120i v" belegt.
Mein Gateway hat nur 1 Radio.
Gateway wurde von FHEM erkannt.
Frage:
Wie sage ich nun FHEM/Gateway/PCA301 Dose im Keller, das sie doch bitte über das Gateway kommunizieren?
Per Schalter an der Dose habe ich die beiden Dosen schon geschaltet und gehofft, das dann das Gateway die Daten empfängt.
Das scheint leider so nicht zu funktionieren.
Kann mir jemand sagen, wie ich vorgehen muss wenn ich PCA301 Dosen bereits in FHEM integriert habe und diese dann vom Jeelink auf das Gateway "umziehen" will?
Gruß,
jostereo
Hallo jostero
Siehst du im WebIF des LCG die Steckdosen? Wenn ja, ist erstmal alles gut, ansonsten solltest du da noch mal nachlesen. Das Umstellen geschieht einfach, indem Du den Steckdosen das IODev vorgibst. Derzeit wird da noch der Jeelink drinstehen, das musst du gegen das LCG austauschen!
Gruss Christoph
Hi pc1246,
wenn ich im Gateway unter "Setup" da in das Textfeld "PCA301" schaue, ist dieses leer.
Das sollte denke ich nicht sein.
Unter Hardware steht bei "Radio #1" -> RFM69 868950 kHz data rate: 6631kps
Das sagt meiner Meinung schonmal aus das er das initCommand für PCA301 geschluckt hat.
Muss ich dann an den beiden PCA301 Dosen das Attribute "IODev" auf das Gateway umbiegen?
Da steht aktuell natürlich noch die JeeLinks drin.
Gruß,
jostereo
Hallo jostereo
Also die PCAs tauchen "eigentlich" von alleine in dem Fenster auf! Es wurde mal geschrieben man muss lange druecken, aber bei mir ging es auch so! Wenn sie dem GW bekannt sind, dann kannst Du dieses IO auch an die Devices antragen und sie schalten dann. Das hat bei mir wunderbar geklappt.
Verwehte Gruesse
Christoph
Wenn die PCA301 schon mal irgendwo angelernt waren (was sie ja wohl sind), reicht es, sie ein mal zu schalten, dass das LGW sie erkennt und mit Adresse und Kanal im webif aufführt. Solange das nicht geklappt hat, ist eine weitere Fehlersuche auf FHEM-Seite erst mal nutzlos.
Lange drücken muss man nur, wenn sie noch keinen Kanal haben oder man einen anderen bekommen will.
Zitat von: Saharel am 29 November 2017, 21:48:01
Hi,
mir ist aufgefallen das am nextion Display der UpTime Wert nur mit dem letzten Wert der Home Seite des Gateways befüllt wird.
Solange ich die Webseite nicht aufrufe bzw. aktualisiere wird der Wert am nextion nicht aktualisiert.
Ist das so gewollt?
Zitat von: HCS am 30 November 2017, 09:25:55
Das war nicht gewollt. Ich nehme es auf die ToDo-Liste.
Ich habe einen Workaround via fhem geschaffen.
Einfach alle 60 sec per HTTPMOD die Haupteite abfragen, geht aber nur wenn kein PW auf dem Webinterface hinterlegt ist.
Nicht schön aber funktioniert ;)
Zitat von: Saharel am 19 Januar 2018, 07:29:41
Ich habe einen Workaround via fhem geschaffen.
Einfach alle 60 sec per HTTPMOD die Haupteite abfragen, geht aber nur wenn kein PW auf dem Webinterface hinterlegt ist.
Ich habe es auf der ToDo, bin aber noch nicht dazu gekommen, es zu erledigen ...
Hallo HCS,
Zitat von: HCS am 14 Januar 2018, 19:21:45
UniversalSensor
Das LGW kann nun das UniversalSensor-Protokoll verarbeiten, das angelehnt an LaCrosse:
- Luftdruck
mit CRC16 abgesichert empfangen und an das LaCrosse-Modul weiterreichen kann.
eine Frage zur Luftdruckkorrektur. Bei Sensoren, die direkt vom LGW empfangen werden, kann eine barometrische Höhenkorrektur (z.B. als Parameter 240v) mitgegeben werden.
Ist diese Korrektur für den Universalsensor auch aktiv? Oder muss man das mit einem UserReading selbst erledigen?
Danke + Gruß
Peter
Zitat von: PeMue am 20 Januar 2018, 17:49:31
Hallo HCS,
eine Frage zur Luftdruckkorrektur. Bei Sensoren, die direkt vom LGW empfangen werden, kann eine barometrische Höhenkorrektur (z.B. als Parameter 240v) mitgegeben werden.
Ist diese Korrektur für den Universalsensor auch aktiv? Oder muss man das mit einem UserReading selbst erledigen?
Das LaCrosseGateway-device und auch das LaCrosse-device geben den Luftdruck genau so weiter und aus, wie es vom Sensor gesendet wird.
Das LGW kann man konfigurieren, dass es den Luftdruck für eine bestimmte Höhe normalisiert (setup page)
Im hdgucken-Sketch kann man den #define ALTITUDE vor dem compilieren auf die richtige Höhe anpassen, dann sendet er es auch auf diese Höhe normalisiert.
Zitat von: HCS am 21 Januar 2018, 19:10:07
Im hdgucken-Sketch kann man den #define ALTITUDE vor dem compilieren auf die richtige Höhe anpassen, dann sendet er es auch auf diese Höhe normalisiert.
Aber dann braucht man für jede unterschiedliche Höhe einen eigenen Sketch. Meine Idee war, dass der Sensor den gemessenen Druck (nicht normalisiert) weitergibt und in FHEM das Normalisieren passiert. Wenn es mit dem LGW nicht geht, dann halt per userReading.
Zitat von: HCS am 21 Januar 2018, 19:10:07
Das LGW kann man konfigurieren, dass es den Luftdruck für eine bestimmte Höhe normalisiert (setup page).
Wozu ist dann der Parameter h (z.B. 220h)? Überschreibt der dann den Wert der setup page? Oder ist das der Wert aus der setup page? Werden mit dem Parameter alle Drücke von Sensoren normalisiert? Oder nur, diejenigen die direkt vom LGW kommen?
Sorry die blöden Fragen, aber ich habe den Zusammenhang in den beiden FHEM Modulen noch nicht so ganz verstanden ::)
Danke + Gruß
Peter
Zitat von: PeMue am 21 Januar 2018, 20:13:35
Aber dann braucht man für jede unterschiedliche Höhe einen eigenen Sketch.
Ja, wenn er nicht in der Lage ist, per Konfiguration eine Höhe zu bekommen.
Zitat von: PeMue am 21 Januar 2018, 20:13:35
Meine Idee war, dass der Sensor den gemessenen Druck (nicht normalisiert) weitergibt und in FHEM das Normalisieren passiert. Wenn es mit dem LGW nicht geht, dann halt per userReading.
Bisher arbeitet das alles genau umgekehrt. Der Sensor normalisiert.
Wenn er das nicht macht, dann wird wohl ein UserReading erforderlich.
Zitat von: PeMue am 21 Januar 2018, 20:13:35
Wozu ist dann der Parameter h (z.B. 220h)? Überschreibt der dann den Wert der setup page? Oder ist das der Wert aus der setup page? Werden mit dem Parameter alle Drücke von Sensoren normalisiert? Oder nur, diejenigen die direkt vom LGW kommen?
Die 220h stammen noch aus JeeLink-Zeiten, der JeeLink-Sketch hat ja keine Konfiguration, also muss man ihm seine Höhe mitteilen.
Da das LGW eine Konfigurations-Seite hat, hat es dann einen Konfiguration für die Höhe bekommen, dass man es ihm nicht immer per 220h schicken muss. 220h macht aber nichts weiter als das, was man auf der LGW-Setup-Page setzt, aus der Ferne zu setzen.
Beim LGW hat mal also die Wahl, ob man die Höhe im LGW konfiguriert oder ob man sie von FHEM aus schicken will.
Wenn der hdgucken-Sensor auf einem ESP8266 läuft, könnte man ihm natürlich ein webif spendieren, um solche Dinge einzustellen.
Hallo HCS,
Zitat von: HCS am 21 Januar 2018, 20:56:25
Die 220h stammen noch aus JeeLink-Zeiten, der JeeLink-Sketch hat ja keine Konfiguration, also muss man ihm seine Höhe mitteilen.
d.h. FHEM teilt dem JeeLink mit, auf welcher Höhe er ist und der Sensor normalisiert? Das ist dann wohl auch das, was beim LGW auf der Konfigurationsseite passiert.
Also genau andersherum, als ich gedacht habe ::) ::) ::)
Naja, aber ein UserReading ist ja auch nicht so schwer zu erstellen.
Es macht ja wirklich keinen Sinn, dass mein Universalsensor denkt, er ist auf 53 m Höhe, dabei ist er ich 187 m höher ;D ;D ;D
Gruß PeMue
Gruß PeMue
Hallo Peter,
Zitat von: PeMue
Es macht ja wirklich keinen Sinn, dass mein Universalsensor denkt, er ist auf 53 m Höhe, dabei ist er ich 187 m höher ;D ;D ;D
jetzt, wo ich das hier gelesen habe, fällt mir ein, daß ich das mal kommunizieren wollte, mit der Höhe :o
Meine Builds und Sketches sind alle auf 53m "eingestellt, Berliner Umland halt ;)
Vielleicht könnte man das per serieller Konsole lösen oder aber viel schöner Webinterface. Mal schauen, ob ich da zeitnah was machen kann.
Gruß Thomas
Hallo Thomas,
Zitat von: hdgucken am 24 Januar 2018, 01:12:47
Meine Builds und Sketches sind alle auf 53m "eingestellt, Berliner Umland halt ;)
habe ich gesehen und auf 0 m (universal, Korrektur in FHEM) bzw. 240 m compiliert. Ich muss mal testen, was besser ist.
Zitat von: hdgucken am 24 Januar 2018, 01:12:47
Vielleicht könnte man das per serieller Konsole lösen oder aber viel schöner Webinterface. Mal schauen, ob ich da zeitnah was machen kann.
Mir wäre die Variante über die serielle Konsole lieber, das ist universeller und das könnte ggf. auch ein Atmega644 bzw. STM31F103x.
Etwa in dem Stil wie beim Jeelink:
220h<cr><lf> über die serielle Schnittstelle schicken und der Sensor liefert
altitude set to 220 m ...zurück ;) Alle anderen Kommandos werden ignoriert.
Gruß Peter
Zitat von: PeMue am 24 Januar 2018, 08:18:37
220h<cr><lf> über die serielle Schnittstelle schicken und der Sensor liefert
altitude set to 220 m ...
... und speichert die Höhe im EEPROM ab, dann muss man sie nur ein mal setzen und es ist für immer gut.
Hallo Peter, Hallo HCS,
Zitat von: PeMue
Mir wäre die Variante über die serielle Konsole lieber, das ist universeller und das könnte ggf. auch ein Atmega644 bzw. STM31F103x.
Etwa in dem Stil wie beim Jeelink:
220h<cr><lf> über die serielle Schnittstelle schicken und der Sensor liefert
altitude set to 220 m ...
zurück ;) Alle anderen Kommandos werden ignoriert.
Zitat von: HCS
... und speichert die Höhe im EEPROM ab, dann muss man sie nur ein mal setzen und es ist für immer gut.
Super Ideen ! Ich werde mich mal darum kümmern, kämpfe aber im Moment mit der STM32 Arduino Implementierung :(
Meine V2.2 läuft inzwischen, bis auf den RFM69, aber die I2C Implementierung scheint ja richtig verbugt zu sein,
gefällt mir noch nicht ganz, mal sehen, ob ich da was machen kann :o
Die SSD1306 Arduino Lib und die BH1750 Lib musste ich noch mal geringfügig anpassen, laufen aber jetzt 8)
Hab bei der ganzen Umstellung auf den STM32 auch noch ein paar kleine Fehler in der V2.2 gefunden,
wenn ich es schaffe, stelle ich die korrigierte Version heute Abend noch zur Verfügung ;)
Bis später ...
Edit:
habe die Fehler im Projekt Universalsensor (ESP8266) auf Github korrigiert !
Hallo Thomas,
weiterer Vorschlag (damit Dir nicht langweilig wird ;D ;D ;D):
Die ID könnte auch per serieller Schnittstelle konfigurierbar sein (bzw. auch ins EEPROM geschrieben werden).
Danke + Gruß
Peter
Hallo Peter,
Zitat von: PeMue
weiterer Vorschlag (damit Dir nicht langweilig wird ;D ;D ;D):
Die ID könnte auch per serieller Schnittstelle konfigurierbar sein (bzw. auch ins EEPROM geschrieben werden).
stimmt, ist notiert ;)
@HCS, nachdem ich ewig nichts mehr bei mir ändern musste habe ich mir heute das aktuelle LaCrosseGateway.zip vom SVN geholt.
Meine Arduino IDE 1.8.5 meckert an drei Stellen unter Linux die Groß / Kleinschreibung an :
RFM.h = spi.h -> SPI.h
TcpServer.h = WiFiclient.h & WiFiserver.h -> WiFiClient.h & WiFiServer.h
Zitat von: Wzut am 07 Februar 2018, 17:48:31
Meine Arduino IDE 1.8.5 meckert an drei Stellen unter Linux die Groß / Kleinschreibung an
Korrigiert und eingecheckt
Ich habe mir auch mal ein Gateway zusammengelötet in der minimal Ausstattung mit Nodemcu und einem rfm. Und dann die ws1600 vom Jeelink umgehangen, das funktioniert auch sehr gut. Allerdings hab ich jetzt bei der ws1600 die beiden zusätzlichen Readings pressure und gas1 , die auch im Abstand von 5-10 Sekunden aktualisiert werden. Woher kommen die denn jetzt?
In Fhem
RAWMSG
OK WS 26 1 3 241 255 0 124 255 255 255 255 0 0 0 34 133 234 254 148 32
Und im log
15:59:10: OK WS 26 1 255 255 255 0 124 255 255 255 255 255 255 0 34 133 234 254 148 32 [A6 81 20 7C 42]
Zitat von: sinus61 am 10 Februar 2018, 16:00:36
Allerdings hab ich jetzt bei der ws1600 die beiden zusätzlichen Readings pressure und gas1 , die auch im Abstand von 5-10 Sekunden aktualisiert werden.
Ja, das sollte nicht sein. Muss ich mal erforschen, wie das entsteht, habe sie bei mir auch gerade gesehen.
Zitat von: sinus61 am 10 Februar 2018, 16:00:36
Allerdings hab ich jetzt bei der ws1600 die beiden zusätzlichen Readings pressure und gas1 , die auch im Abstand von 5-10 Sekunden aktualisiert werden.
Ich habe gestern eine Version von 36_LaCrosse.pm eingecheckt, die das verhindert.
- FHEM update durchführen
- danach die readings löschen (deletereading xyz gas1)
Danke, funktioniert !
Upps, habe gerade von FHEM eine "leere Batterie" Meldung von einem LaCrosse Sensor (auf einem Larosse Gateway) bekommen :o :o :o
LaCrosse_02: battery: low
Ich ignoriere das mal ...
Gruß PeMue
Hallo,
ich hatte vor, mein LaCrosseGateway mit einem zweiten Funkmodule auszustatten. Das klappt jedoch nur bedingt.
Dafür hatte ich MISO, Mosi und SCK parallel zum bisheriegen Modul verschaltet und NSS an D4. Dann startet das Gateway jedoch nicht und die blaue LED am ESP leuchtet dauerhaft. Wenn ich NSS an D3 klemme, startet es und findet das zweite Modul an der dritten Stelle. Da ich jedoch an D3 einen Temperatur und Feuchtigkeitssensor betreibe, wollte ich D4 wie beschrieben verwenden.
Kann mir jemand sagen, was da falsch läuft?
Moin,
Ist D4 am Wemos D1 Mini nicht verbunden mit der LED und GPIO2 des ESP???
Wenn der beim Boot high ist, dann geht es doch in den Flash Mode, oder?
https://zoetrope.io/tech-blog/esp8266-bootloader-modes-and-gpio-state-startup/
https://wiki.wemos.cc/products:d1:d1_mini
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ich verwende ein NodeMCU.
Hallo Joe Lee,
Transceiver 1 NSS muss an D8
Transceiver 2 NSS muss an D4
Die rote LED auf dem Board flackert dann wenn was empfangen wird und die blaue LED auf dem 8266 Board leuchtet dann ständig.
LG
/robin
Hallo fh168
an D4 hatte ich das Funkmodul. Dann bootet das ESP nicht. Jedoch startet es (wie oben beschrieben, wenn ich D3 verwende. Heißt also Modul funktioniert grundsätzlich.
Da D3 jedoch mit einem DTH22 verbunden ist, sollte das Modul an D4.
seltsam, ich baute auch das gateway mit nodemcu und 2 transceiver, läuft einwandfrei.
Habe auch ein Testsystem laufen, auf dem vier Radios und u.A. ein DHT22(an D3) drauf sind
Zitat
LaCrosseGateway V1.31 LGW211 (192.168.31.211)
Home Setup Hardware OTA-Update Log Help Reboot
ESP8266 present :-) Core: 2_3_0 SDK: 1.5.3(aec24ac9) free heap: 15120 Reset: External System -> Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
WiFi -43 dBm Mode: Station Time to connect: 4.0 s
Radio #1 RFM69 868300 kHz data rate: 17241 kbps
Radio #2 RFM69 868300 kHz data rate: 9676 kbps
Radio #3 ---
Radio #4 RFM69 868300 kHz data rate: 8842 kbps
Radio #5 RFM69 868300 kHz data rate: 20000 kbps
SHT75 ---
BME680 OK T=22.6 H=52 P=1004.5 G=60120
BME280 ---
BMP180 OK T=26.5 P=1004.4 Calibration: AC1:7056 AC2:-1035 AC3:-14588 AC4:32129 AC5:25256 AC6:21883 B1:6515 B2:35 MB:-32768 MC:-11786 MD:2664 ADC: T=30699 P=153487
DHT22 OK T=24.3 H=45
Hallo,
da bei mir meine ESP8266 immer wieder das WLAN verlieren, wollte ich mal einen Versuch mit einem NodeMCU mit ESP8285 drauf starten. http://www.vvdoit.com/new-nodemcu-m-development-board-based-on-esp-m2-from-esp8285-serial-wifi-wireless-module-compatible-with-nodemcu-diy-lua-iot-p1292428.html (http://www.vvdoit.com/new-nodemcu-m-development-board-based-on-esp-m2-from-esp8285-serial-wifi-wireless-module-compatible-with-nodemcu-diy-lua-iot-p1292428.html)
Das Ding soll ja "voll kompatibel" zu einem ESP8266 sein.
Flashen der LaCrosseGateway.bin klappt auch wunderbar, und es wird auch der Accesspoint aufgebaut.
Nur leider werden meine Einstellungen (SSID, Kennwort, etc.) nicht gespeichert.
Nach Save&reboot ist alles genau so wie vorher.
Hat jemand eine Idee, woran das liegen könnte?
Gruß
Stefan
Da ich keinen ESP8285 habe, kann ich es leider weder probieren noch etwas dazu sagen.
Wie viel Speicher hat der denn?
Das kann, so wie es sich anhört, nur etwas mit der EEPROM-Simulation zu tun haben.
Kannst Dir ja mal eine Testfirmware machen, die
EEPROM.begin
EEPROM.write
EEPROM.end
reboot
EEPROM.begin
EEPROM.read
EEPROM.end
testet.
Der 8285 hat ein DIO Flashmemory. Das muss im Binary eingestellt sein.
DIO lässt sich auch problemlos mit den 8266ern verwenden.
Muss in der IDE vorm kompilieren eingestellt werden.
Nachtrag: 1M Memory.
Die Arduino-IDE hat den 8285 als eigenes Generic Board mit den passenden Presets.
V1.32
BMP280
Das LGW unterstützt nun auch optional den BMP280 auf der Adresse 0x76
Danke an voddow für den Patch.
WS1600 und WS1080 haben kein gas und pressure
Beide senden nun keine Phantasiewerte mehr für gas und pressure an FHEM
Nextion: aktulaisierung von Uptime
Am nextion Display wurde der UpTime Wert nur aktualisiert, wenn man im Browser die Home-Seite des LGW aktualisiert hat.
Trat nur auf, wenn im Setup "KV-Interval" auf "off" stand.
Ist eingecheckt, das FHEM-Update liefert es dann morgen aus.
Bin ich hier richtig ? Gibt es ein Update wie mache ich das ?
PCA301 läuft gut. Ein Thermometer auch. Das 2. Technoline TX 29 DTH - IT will nciht gefunden werden. Auch mit ignore Battery ...
War auch ein kampf vor Monaten das 1. Thermometer ans laufen zu bekommen
Internals:
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol:CapacitiveLevel
DEF 192.168.2.25:81
DeviceName 192.168.2.25:81
FD 121
LaCrossePair 2
NAME myLaCrosseGateway
NR 22
NTFY_ORDER 50-myLaCrosseGateway
PARTIAL
RAWMSG OK VALUES LGW 1259235 UpTimeSeconds=30,UpTimeText=0Tg. 0Std. 0Min. 30Sek. ,WIFI=Home-Wlan,ReceivedFrames=2,FramesPerMinute=2,RSSI=-45,FreeHeap=17296,LD.Min=0,LD.Avg=0,LD.Max=15,OLED=none
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.22
myLaCrosseGateway_MSGCNT 5824
myLaCrosseGateway_TIME 2018-08-27 20:40:42
nextOpenDelay 2
settings (1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 t:20~3) {IP=192.168.2.25}]
.attraggr:
.attrminint:
.clientArray:
KeyValueProtocol
LaCrosse
PCA301
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
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2018-08-27 20:40:42 state initialized
helper:
Attributes:
initCommands 1,868950,120i 3#2m 20#2t 55h 0a v
room Zentral
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
verbose 2
Wenn Du nur TX29DTH-IT hast macht der toggle "3#2m 20#2t" keinen Sinn.
Danke aber irgendwie geht es nun doch .. nach paar Stunden taucht auch der 2, aus.
Habe nun nur das Problem das meien PCA301 oft nicht funktionieren.. Muss den Gateway neu aucf Connect stellen das 1-3 mal ..
Sehr unzuverlässig... jemand eine Idee ? Vielleicht doch neues Firmware?
Habe nun das timeout und watchdog gefunden aber hilft auch nicht. Gateway ist da aber die pca301 wollen nichts senden. Nach paar Minuten ODER manuell reconnect geht es dann direkt.
Im Log habe ich nun immer so etwas:
2018.09.12 19:24:02 1: 192.168.2.25:81 reappeared (myLaCrosseGateway)
2018.09.12 19:26:02 1: 192.168.2.25:81 reappeared (myLaCrosseGateway)
2018.09.12 19:28:02 1: 192.168.2.25:81 reappeared (myLaCrosseGateway)
Moin Chris
Mach doch mal ein update auf die neueste Version (https://forum.fhem.de/index.php/topic,43672.msg820228.html#msg820228)!
Ich meine mich zu erinnern, dass es in der Gegend um Deine Firmware (V1.22) etwas holperig war!?
Gruss Christoph
danke habe flash ausgeführt wurde auch etwas gemacht.
Leider wenn ich status der PCA301 anfordere .. versucht er es immer wieder aber klappt nicht mehr :(
Vielleicht ist wirklich noch eine einstellung falsch ?
Hier nochmal das list
Internals:
Alive 2018-09-13 10:20:24
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol:CapacitiveLevel
DEF 192.168.2.25:81
DeviceName 192.168.2.25:81
FD 125
NAME myLaCrosseGateway
NR 22
NTFY_ORDER 50-myLaCrosseGateway
PARTIAL
RAWMSG OK VALUES LGW 1259235 UpTimeSeconds=140,UpTimeText=0Tg. 0Std. 2Min. 20Sek. ,WIFI=Home-Wlan,ReceivedFrames=23,FramesPerMinute=9,RSSI=-67,FreeHeap=18776,LD.Min=0.16,LD.Avg=0.16,LD.Max=2.29,OLED=none
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.32
myLaCrosseGateway_MSGCNT 17146
myLaCrosseGateway_TIME 2018-09-13 10:20:58
nextOpenDelay 2
settings (1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 t:20~3) {IP=192.168.2.25}]
.attraggr:
.attrminint:
.clientArray:
KeyValueProtocol
LaCrosse
PCA301
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
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2018-09-13 10:20:58 state initialized
helper:
Attributes:
initCommands 1,868950,120i 3#2m 20#2t 55h 0a v
room Zentral
timeout 60
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
verbose 2
watchdog 300
Edit: habe 6 PCA301 davon gehen 3 sofort die anderen 3 nicht. Reichweite kann normal nicht das Problem sein...
Moin
Kannst du mal auf die Weboberflaeche Deines Gateways gehen! (192.168.2.25)
Auf einer der 6 Seiten kann man sehen welche PCAs vom Gateway erkannt werden. Da sollten die 6 eigentlich aufgefuehrt sein!
Autocreate hast du an? Die PCAs werden erkannt, wenn Du sie einmal betaetigst, wenn ich mich recht entsinne!
Gruss Christoph
Hmm ne also ich sehe da nur folgendes:
LaCrosseGateway V1.32 LaCrosseGateway (192.168.2.25)
Home Setup Hardware OTA-Update Log Help Reboot
aber Nirgendwo stehen Geräte aufgelistet
Unter Setip PCA301 steht folgendes: 069694=1,469794=1,26DA21=2,079696=1,077005=5,26E487=6,03F02F=4,06B950=4
Es ist so als ob er von den 6 Geräten 2 einfach vergessen hat .. die gehen nicht. Alle anderen funktionieren. Wenn ich nun diese wieder ON drücke .. dann werden die sicher wieder funktionieren. Nur wie lange..
Schieb ich es mal auf das Firmware Update und beobachte es.
Zitat von: ChrisW am 13 September 2018, 16:59:54
Hmm ne also ich sehe da nur folgendes:
LaCrosseGateway V1.32 LaCrosseGateway (192.168.2.25)
Home Setup Hardware OTA-Update Log Help Reboot
aber Nirgendwo stehen Geräte aufgelistet
Unter Setip PCA301 steht folgendes: 069694=1,469794=1,26DA21=2,079696=1,077005=5,26E487=6,03F02F=4,06B950=4
Es ist so als ob er von den 6 Geräten 2 einfach vergessen hat .. die gehen nicht. Alle anderen funktionieren. Wenn ich nun diese wieder ON drücke .. dann werden die sicher wieder funktionieren. Nur wie lange..
Schieb ich es mal auf das Firmware Update und beobachte es.
Moin
Also ich sehe insgesamt 8 PCAs! Wobei manche den gleichen Kanal haben, was etwas seltsam ist. Vielleicht ist es ja auch so, dass Dein Gateway irgendwann nicht mehr erreichbar ist. Hast Du Dir mal das Wiki hierzu durchgelesen, insbesondere https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Reconnect ?
Gruss Christoph
hi, ja timeout .. habe ich gesetzt.
Ich kann die 6 Geräte alle schalten nur empfangen kann ich die 2 Geräte nicht... Hab auch mal Manuell geschaltet.
Die 2 anderen sind vielleicht die Thermometer?
Zitat von: ChrisW am 13 September 2018, 16:59:54
069694=1,469794=1,26DA21=2,079696=1,077005=5,26E487=6,03F02F=4,06B950=4
Das passt überhaupt nicht.
Das Format ist <ID der PCA>=<Kanal> und es kann nicht drei Stück mit Kanal 1 geben.
Wie auch immer das zustande kam, wirf es mal komplett raus und speichere die Konfiguration und lass dann das LGW sie neu lernen.
Also die Dosen die Kanäle neu einlernen lassen wie hier beschrieben:
https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Inbetriebnahme_von_PCA301
"button an der Dose "3 Sekunden" drücken"
Für alle 6 nacheinander machen.
Dann im LGW nochmal kontrollieren, was eingelernt wurde.
Okay die Zeile aus dem Webinterface löschen ?? Und die Geräte in Fhem per delete löschen?
genau
Hallo zusammen,
nachdem mein WiFi AP sich heute morgen irgendwie vernagelt hat und alle Clients rausgeflogen sind hat auch das LGW versucht eine neue Verbindung herzustellen. Und dabei kam es zu einer sehr interessanten Anzeige (siehe Anhang). :o Ist noch die LGW v1.30, falls das von Belang ist.
MfG
Marco
Zitat von: marco-f am 17 September 2018, 10:22:02
Und dabei kam es zu einer sehr interessanten Anzeige (siehe Anhang).
Das LGW gibt halt alles und noch mehr ... ;D
Ist das reproduzierbar?
Zitat von: HCS am 17 September 2018, 20:34:44
Das LGW gibt halt alles und noch mehr ... ;D
Ist das reproduzierbar?
Ja. Ich hab soeben mal den AP vom Netz getrennt, daraufhin erlosch am LGW Display das FHEM Symbol, das WiFi Symbol blieb aber erhalten (da hätte ich auch erwartet dass es erlischt, weil ja das WiFi weg war) und nach einer Weile begann der Verbindungsaufbau und lief wieder munter über die 100% hinaus.
Hi, ich habe aus ein Wemos D1 Mini und ein RFM69W eine kleine LaCrosse Gateway gebaut. Geflashed mit der neuesten (1.32) Firmware scheint es auch sein Dienst zu tun und empfängt auch Daten von meinen Temperatur Sensor.
Die Einbindung in FHEM klappt allerdings nicht.
Es ist als LaCrosseGateway definiert aber es steht dauernd auf Disconnected.
Im Log steht:
2018.10.05 15:21:11 1: LaCrosseD1: Can't connect to http://192.168.100.134:81: Das Argument ist ungültig
Ich hab vor der Einrichtung ein FHEM Update gemacht, die Module sollten also aktuell sein.
Was mache ich falsch?
Hallo thinman,
bitte poste mal Deine Definition des Gateways in FHEM.
Gruß PeMue
Sorry, hätte ich schon gleich machen sollen...
define LD1 LaCrosseGateway http://192.168.100.134:81
attr LD1 devStateIcon initialized:cul_wlan@green .*:cul_wlan@red
attr LD1 initCommands 1,868950,120i 3#2m 20#2t 55h 0a v
attr LD1 room WetterStation
attr LD1 timeout 120,30
attr LD1 usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
Hallo,
lass mal das http:// in der Definition weg, siehe Beispiel im commandref (https://fhem.de/commandref.html#LaCrosseGateway).
Gruß PeMue
Bin ich ein blinde Depp... :o
Seit zwei Tage beschäftige ich damit und mir ist kein einzige Mal aufgefallen, dass ich beim copy/paste nicht nur die IP Adresse erwischt habe.
Vor laute Bäume, das einfachste im Wald nicht gesehen. ;D
Besten Dank PeMue!
Hmmm, es hat ein Tag sehr gut funktioniert, jetzt gibt es wieder eine neue Problem:
Seit heute Morgen empfängt das Gateway keine Daten mehr vom Außensensor und trennt sich ständig vom FHEM Server.
Debug Log vom LaCrosse:
07:43:24: DataPort: #81 Client disconnected
07:43:24: DataPort: #81 Client connected, IP=192.168.100.67 Port=54248
07:43:26: DataPort: #81 received 'v'
07:43:55: DataPort: #81 Client disconnected
07:43:55: DataPort: #81 Client connected, IP=192.168.100.67 Port=54250
07:43:58: DataPort: #81 received 'v'
Die Port Nummer zählt konstant hoch.
Im FHEM Resource Monitor kommt andauernd folgende Meldung:
LaCrosseGateway LD1 opened
LaCrosseGateway LD1 CONNECTED
LaCrosseGateway LD1 CONNECTED
LaCrosseGateway LD1 opened
LaCrosseGateway LD1 CONNECTED
LaCrosseGateway LD1 CONNECTED
...
Im FHEM Log steht:
Datum:Uhrzeit 1: 192.168.100.134:81 reappeared (LD1)
Datum:Uhrzeit 1: 192.168.100.134:81 reappeared (LD1)
Datum:Uhrzeit 1: 192.168.100.134:81 reappeared (LD1)
...
Der RSSI vom Gateway ist -70. Sollte eigentlich noch okay sein und war gestern als es noch funktioniert hat genau so.
Ein reboot des Gateways hat nicht geholfen.
Hat jemand ein Idee woran das liegen könnte?
Ich habe zwar noch eine Platine von PeMue V1.2 hier verfügbar, aber leider zurzeit nur ein RFM69HW Modul - die CW Variante habe ich nachbestellt. Da ich nur Empfangen möchte (LaCrosse) ist es ja grundsätzlich ok. Ich habe nun einen Wemos D1 Mini (Standard-Variante) mit dem 1.31 Image geflasht und "kurz" alles nach dem NodeMCU Beispiel aus dem Wiki zusammengelötet. OLED + BME280 werden erkannt, aber nicht das RFM69HW Modul. Ich finde im Internet die unterschiedlichsten Verkabelungsvarianten - hat hier jemand eine funktionale Variante im Einsatz und kann mir einen Tipp geben?
Zurzeit:
Wemos RFM69HW
3.3V -> 3.3V
GND -> GND
D5 -> SCK
D6 -> MISO
D7 -> MOSI
D8 -> NSS
Wie man das am späten Abend immer so richtig macht, habe ich das Modul vorher natürlich _nicht_ getestet und sofort verlötet ;)
Danke vorab.
Zitat von: dmq am 10 Oktober 2018, 23:46:53
Wemos RFM69HW
3.3V -> 3.3V
GND -> GND
D5 -> SCK
D6 -> MISO
D7 -> MOSI
D8 -> NSS
Das müsste so passen, siehe auch der Schaltplan (https://forum.fhem.de/index.php?action=dlattach;topic=45594.0;attach=65634) der v1.0 LGW Platine (S. 2 rechts oben).
Gruß PeMue
Danke Dir. Ok, dann ist vielleicht das Board kaputt. Ich muss mir das heute Abend noch einmal näher ansehen.
Ich komme leider nicht weiter. Bin mir leider nicht ganz sicher, wie ich feststelle, ob der RFM69HW kaputt ist. Es kommt auf jeden Fall Spannung an dem Board an - 3.36V - an verschiedenen anderen Stellen auf dem Board messe ich ebenfalls Spannung. Auf MISO, MOSI und SCLK kann ich keine Spannung messen - auch über längere Zeit nicht. Auf NSS / Slave Select messe ich 3.2V.
Die Software gibt mir folgende Ausgabe (den BME280 habe ich wieder entfernt, OLED1306 ist noch aktiv).
LaCrosseGateway V1.32 LaCrosseGateway (0.0.0.0)
Home Setup Hardware OTA-Update Log Help Reboot
ESP8266 present :-) Core: 2_3_0 SDK: 1.5.3(aec24ac9) free heap: 15336 Reset: External System -> Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
WiFi 31 dBm Mode: Accespoint Time to connect: 0.0 s
Radio #1 ---
Radio #2 ---
Radio #3 ---
Radio #4 ---
Radio #5 ---
SHT75 ---
BME680 ---
BME280 ---
BMP280 ---
BMP180 ---
DHT22 ---
LM75 ---
SC16IS750 (0x90) ---
SC16IS750 (0x92) ---
MCP23008 ---
OLED OK On
DataPort #1 81
DataPort #2 ---
DataPort #3 ---
Serial-bridge #1 ---
Serial-bridge #2 ---
Soft-bridge ---
Nextion ---
Analog port Disabled ADC=846 U=4294967295 mV (0 ... 0 mV)
Kann ich hier softwareseitig noch was erkennen? Soll ich mal ESP-Easy oder einen eigenen Sketch laden?
Hallo,
es sieht so aus, als ob das RFM69 nicht erkannt wird. Hast Du ggf. ein OLED Display mit SPI (https://www.youtube.com/watch?v=jSqiJxKfHaY), um die SPI Schnittstelle zu testen? Oder den Blink Sketch mit 1 s Blinkzeit modifizieren, dass er die SPI Pins durch"klackert" und mit dem Multimeter messen (Input und Output beachten).
Gruß PeMue
Hallo PeMue,
gute Ideen. Ich habe tatsächlich noch ein paar SPI OLEDs. Ich habe es verkabelt und den Adafruit OLED SPI example Sketch angepasst und hochgeladen. Läuft. Hmm - ich war mir recht sicher, dass ich beim löten nichts zerstört habe. An ein DoA will ich auch nicht so wirklich glauben.
Kannst Du mir ggf. sagen, wie ich die Antenne verlöten muss - neben dem Ant-Pin muss ich die Antenne doch zusätzlich noch auf GND legen, oder? Aber damit wird es wahrscheinlich nichts zu tun haben. Notfalls muss ich dann halt auf die CW Variante warten und deine Platine nehmen. Das Bauteil ist zwar nicht so teuer, aber es wurmt mich schon.
Das DIO00 <--> GPIO04 <--> D2 wird nicht unbedingt benötigt, oder?
Viele Grüße und danke Dir für deine Zeit und Mühe,
dmq
Das mit der Antenne hat sich geklärt. Das was ich meinte war fürs remote mounting gedacht. Bei der einfachen Antenne reicht einfach der ANT Pin.
He. Da mich das natürlich ziemlich genervt hat, habe ich im Endeffekt das Modul noch einmal ausgelötet und im Anschluss Kabel an das Modul gelötet. Siehe da: funktioniert. Im Anschluss habe ich es wieder auf die Platine gelötet: funktioniert ;D Da war dann wohl irgendwo eine unsaubere Lötstelle.
Hallo,
Zitat von: dmq am 11 Oktober 2018, 21:34:06
Kannst Du mir ggf. sagen, wie ich die Antenne verlöten muss - neben dem Ant-Pin muss ich die Antenne doch zusätzlich noch auf GND legen, oder?
ähm, eher nein. Ein einfacher Draht am ANT Pin reicht. Aber das hast Du auch schon rausbekommen. Irgendwo steht auch die Länge, ich meine, im ersten Post der LGW Platine.
Zitat von: dmq am 13 Oktober 2018, 00:22:25
Da war dann wohl irgendwo eine unsaubere Lötstelle.
Shit happens sometimes 8) 8) 8)
Gruß Peter
Hallo,
ich hoffe ich bin hier richtig mit meiner Frage, denn ich verzweifele langsam bei meiner Fehlersuche:
Ich habe schon länger ein LaCrosseGateway mit der aktuelle Softwareversion 1.32 in Betrieb, an dem mehrere PCA301 Steckdosen laufen.
Funktioniert alles super.
Jetzt habe ich an das Gateway zusätzlich einen DHT22 (an D3) angeschlossen. Dieser wird vom Gateway auch erkannt, was ich über die Webschnittstelle sehen kann. Temperatur und Feuchte werden dort angezeigt. Siehe Anhang.
Allerdings wird der DHT22 in FHEM nicht angezeigt.
FHEM steht auf autocreate und das Pairing am LaCrosseGateway mit 120s habe ich mehrfach versucht.
Natürlich habe ich es auch mit Neustarts versucht.
Bisher hatte ich keinen Erfolg.
Hier mal ein List vom LaCrosseGateway und vom KeyValueProtocol.
Internals:
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol:CapacitiveLevel
DEF 192.168.178.51:81
DeviceName 192.168.178.51:81
FD 44
NAME myLaCrosseGateway
NR 1422
NTFY_ORDER 50-myLaCrosseGateway
PARTIAL
RAWMSG OK VALUES LGW 2237843 UpTimeSeconds=510,UpTimeText=0Tg. 0Std. 8Min. 30Sek. ,WIFI=FritzBox-EG,ReceivedFrames=140,FramesPerMinute=7,RSSI=-27,FreeHeap=19056,LD.Min=0.11,LD.Avg=0.11,LD.Max=0.74,OLED=none
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.32
myLaCrosseGateway_MSGCNT 38697
myLaCrosseGateway_TIME 2018-10-14 12:09:19
nextOpenDelay 2
settings (1=RFM69 f:868950 r:6631) + DHT22 {IP=192.168.178.51}]
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
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2018-10-13 17:28:03 analog 11
2018-10-14 12:09:19 state initialized
helper:
Attributes:
initCommands 1,868950,120i 3#2m 20#2t 220h 0a v
room LaCrosse,PCA301
timeout 120,30
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
Internals:
DEF LGW 2237843
ID LGW_2237843
IODev myLaCrosseGateway
LASTInputDev myLaCrosseGateway
MSGCNT 15063
NAME KeyValueProtocol_LGW_2237843
NR 1425
STATE Initialized
TYPE KeyValueProtocol
model LGW
myLaCrosseGateway_MSGCNT 15063
myLaCrosseGateway_TIME 2018-10-14 12:10:49
READINGS:
2018-10-05 12:21:47 ChipID 2237843
2018-10-14 12:10:49 FramesPerMinute 1
2018-10-14 12:10:49 FreeHeap 18888
2018-10-14 12:10:49 LD.Avg 0.11
2018-10-14 12:10:49 LD.Max 0.54
2018-10-14 12:10:49 LD.Min 0.11
2018-10-14 12:08:38 MacAddress 2C:3A:E8:22:25:93
2018-10-14 12:10:49 OLED none
2018-10-14 12:10:49 RSSI -25
2018-10-14 12:10:49 ReceivedFrames 141
2018-10-14 12:10:49 UpTimeSeconds 600
2018-10-14 12:10:49 UpTimeText 0Tg. 0Std. 10Min. 0Sek.
2018-10-14 12:08:38 Version 1.32
2018-10-14 12:10:49 WIFI FritzBox-EG
Attributes:
IODev myLaCrosseGateway
room KeyValueProtocol
Ich habe schon jede Menge gegooglet und auch hier im Forum gesucht, bin aber bis jetzt nicht zum Erfolg gekommen.
Daher hoffe ich auf Tipps hier.
Sollte noch etwas fehlen liefere ich das gerne nach.
Vielen Dank im Voraus,
Jogi
Hallo Jogi,
d.h. es ist in FHEM kein Reading vorhanden? Falls doch, ggf. mit stateFormat probieren.
Dein Gateway hat nur ein Radio, d.h. es sollte funktionieren.
Gruß Peter
Zitat von: PeMue am 14 Oktober 2018, 12:41:04
Hallo Jogi,
d.h. es ist in FHEM kein Reading vorhanden? Falls doch, ggf. mit stateFormat probieren.
Dein Gateway hat nur ein Radio, d.h. es sollte funktionieren.
Gruß Peter
Hallo Peter,
vielen Dank für die Antwort, aber ich verstehe nicht, was Du damit meinst. Sind vielleicht doofe Fragen aber ich weiß es nicht besser.
Wo müsste ich das Reading finden, wenn es eins gibt?
Und wo und wie soll ich dann stateFormat probieren?
Was muss ich machen, wenn es kein Reading gibt?
Gruß,
Jogi
Hallo Jogi,
Zitat von: Jogi am 14 Oktober 2018, 12:48:53
Wo müsste ich das Reading finden, wenn es eins gibt?
in Deinem
myLaCrosseGateway hast Du das Reading nicht, siehe Dein List oben bzw.:
READINGS:
2018-10-13 17:28:03 analog 11
2018-10-14 12:09:19 state initializedSo wie es aussieht, wird das LGW sauber erkannt. Geh' doch einfach mal in den Event Monitor und setze einen Filter mit
myLaCrosseGateway.* und schau mal, was das so ankommt.
Gruß Peter
Zitat von: PeMue am 14 Oktober 2018, 13:56:59
und schau mal, was das so ankommt.
Da kommt eigentlich gar nichts. Ich habe den Event Monitor jetzt eine Stunde laufen lassen. Da kommt keine einzige Meldung zum LaCrosseGateway.
Auch beim Schalten der PCA301 Steckdosen -was einwandfrei funktioniert und auch Verbrauchsdaten liefert- nicht.
Nur wenn ich das LGB boote bekomme ich diese Meldung:
2018-10-14 15:46:41 LaCrosseGateway myLaCrosseGateway CONNECTED
2018-10-14 15:46:54 LaCrosseGateway myLaCrosseGateway opened
2018-10-14 15:46:54 LaCrosseGateway myLaCrosseGateway CONNECTEDVielleicht noch eine Info, von der ich nicht weiß, ob sie wichtig ist. Ich habe auch noch einen Jeelink in meinem System. Der empfängt die Daten von LaCrosse Temperaturfühlern (funktioniert auch einwandfrei). Ich weiß nicht, ob das irgendwie zusammen hängt und sich beeinflusst.
Hallo Jogi,
ich würde an Deiner Stelle das LGW löschen und noch einmal neu definieren. Ggf. nach dem Löschen FHEM noch mal neu starten. Nach dem neu definieren nochmal pairen.
Gruß Peter
Zitat von: PeMue am 14 Oktober 2018, 16:06:59
ich würde an Deiner Stelle das LGW löschen und noch einmal neu definieren. GGf. nach dem Löschen FHEM noch mal neu starten. Nach dem neu definieren nochmal pairen.
Alles klar, vielen Dank.
Dann werde ich mein System mal vorsichtshalber vorher sichern und das in den nächsten Tagen mal versuchen.
Schönen Sonntag noch,
Jogi
Zitat von: Jogi am 14 Oktober 2018, 12:13:10
Daher hoffe ich auf Tipps hier.
Du hast im LGW als "Internal sensors: ID:" 0 definiert.
Trag hier mal eine gültige LaCrosse ID ein, die noch von keinem Deiner Sensoren verwendet wird, z.B. 0x33 (das ist 51 Dezimal, ich nehme immmer das letzte Oktett der IP, dann ist klar, welches LaCrosse-Device das LGW ist)
"Save and Restart"
Nachdem sich FHEM neu verbunden hat:
set myLaCrosseGateway LaCrossePairForSec 60 ignore_batteryDann solltest Du nach ca. 30 Sekunden im Room "LaCrosse" ein neues LaCrosse-Device mit dem Name LaCrosse_33 bekommen, das die Werte des DHT22 hat.
Zitat von: HCS am 14 Oktober 2018, 20:20:18
Du hast im LGW als "Internal sensors: ID:" 0 definiert.
Trag hier mal eine gültige LaCrosse ID ein, die noch von keinem Deiner Sensoren verwendet wird, z.B. 0x33 (das ist 51 Dezimal, ich nehme immmer das letzte Oktett der IP, dann ist klar, welches LaCrosse-Device das LGW ist)
"Save and Restart"
Nachdem sich FHEM neu verbunden hat:
set myLaCrosseGateway LaCrossePairForSec 60 ignore_battery
Dann solltest Du nach ca. 30 Sekunden im Room "LaCrosse" ein neues LaCrosse-Device mit dem Name LaCrosse_33 bekommen, das die Werte des DHT22 hat.
SUPER, das war es!
Vielen Dank, Du hast mir sehr weiter geholfen.
Gruß,
Jogi
Ich habe ein Wemos D1 Mini auf dem der LaCrosse Gateway läuft (mit ein RFM69CW und ein Nextion Display).
Besteht der Möglichkeit ein Mikroschalter an der D1 anzuschließen so, dass der Gateway diese Event an FHEM weiterleitet und ich darauf reagieren kann?
Falls ja, brauchte ich dafür Zusatzhardware?
Zitat von: thinman am 16 Oktober 2018, 08:03:14
Falls ja, brauchte ich dafür Zusatzhardware?
Ja, einen MCP23008
Siehe hier:
https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#MCP23008_2
https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Inbetriebnahme_von_MCP23008
Damit hast Du 8 IOs, die Du als Ein- oder Ausgang verwenden kannst.
Ausgänge kannst Du dann von FHEM aus setzen
Eingänge setzten in FHEM ein Reading im zugehörigen KVP-Device, auf das man reagieren kann.
Die Konfiguration im LGW kannst Du auf der Setup-Page anschauen (Bereich MCP23008)
Dann muss ich nochmal Platz im Gehäuse machen.
Ich habe gehofft, dass ich vielleicht eine der freie GPIOs auf der Wemos dafür verwenden kann.
Wegen ein Schalter ist der MCP23008 ein ziemliche overkill aber wenn es anders nicht geht muss ich diesen Weg gehen.
Besten Dank!
Zitat von: thinman am 16 Oktober 2018, 09:26:11
Wegen ein Schalter ist der MCP23008 ein ziemliche overkill aber wenn es anders nicht geht muss ich diesen Weg gehen.
8 Schalter anschließen und schon ist es kein overkill mehr ;D
;D ;D ;D
Ich überleg mir dann wofür ich 8 Schalter benutzen könnte... ;D
Hallo zusammen,
ich habe mal eine Frage. Sind die LaCrosse Sensoren direkt mit eine Empfänger gepairt und senden nur an diesen Empfänger die Daten oder senden die Sensoren einfach die Daten raus und jeder kann es empfangen?
Hintergrund ist folgender:
Ich habe seit einiger Zeit Probleme mit meinem selbst gebauten JeeLink-Clone. Verbindung bricht häufig ab, 1 mal am Tag ein Reset ist eigentlich normal, manchmal muss ich den JeeLink-Clone sogar von der Spannung trennen damit er wieder funktioniert.
Deshalb habe ich mich entschlossen das LaCrosseGateway in der Minimum-Variante zu bauen. Hat auch so weit funktioniert, das RFM69HW Modul wird auch erkannt.
LaCrosseGateway V1.32 LaCrosseGateway (von mir gelöscht)
Home Setup Hardware OTA-Update Log Help Logout Reboot
ESP8266 present :-) Core: 2_3_0 SDK: 1.5.3(aec24ac9) free heap: 15536 Reset: Software/System restart -> Fatal exception:0 flag:4 (SOFT_RESTART) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
WiFi -52 dBm Mode: Station Time to connect: 4.2 s
Radio #1 RFM69 868300 kHz data rate: 17241 kbps
Radio #2 ---
Radio #3 ---
Radio #4 ---
Radio #5 ---
SHT75 ---
BME680 ---
BME280 ---
BMP280 ---
BMP180 ---
DHT22 ---
LM75 ---
SC16IS750 (0x90) ---
SC16IS750 (0x92) ---
MCP23008 ---
OLED ---
DataPort #1 81 FHEM connected
DataPort #2 ---
DataPort #3 ---
Serial-bridge #1 ---
Serial-bridge #2 ---
Soft-bridge ---
Nextion ---
Analog port Disabled ADC=1 U=4294967295 mV (0 ... 0 mV)
Wenn ich jetzt aber das Log anschaue kommen keine Signale vom Sensor an, nur die Verbindung zum WLAN wird angezeigt
DATA:OK VALUES LGW 10439008 UpTimeSeconds=2182,UpTimeText=0Tg. 0Std. 36Min. 22Sek. ,WIFI=X,ReceivedFrames=0,FramesPerMinute=0,RSSI=-51,FreeHeap=17240,LD.Min=0.10,LD.Avg=0.13,LD.Max=428.80,OLED=none
DATA:OK VALUES LGW 10439008 UpTimeSeconds=2192,UpTimeText=0Tg. 0Std. 36Min. 32Sek. ,WIFI=X,ReceivedFrames=0,FramesPerMinute=0,RSSI=-53,FreeHeap=17000,LD.Min=0.10,LD.Avg=0.10,LD.Max=0.32,OLED=none
DATA:OK VALUES LGW 10439008 UpTimeSeconds=2202,UpTimeText=0Tg. 0Std. 36Min. 42Sek. ,WIFI=X,ReceivedFrames=0,FramesPerMinute=0,RSSI=-53,FreeHeap=16760,LD.Min=0.10,LD.Avg=0.10,LD.Max=0.27,OLED=none
usw.
Habe ich jetzt Empfangsprobleme (Antenne ist am RFM69HW dran) oder taucht hier erst etwas auf wenn ich die Sensoren aktiv vom FHEM angefragt werden? Es sind 3 Sensoren in der Nähe.
Das Gateway ist ins FHEM eingebunden und liefert auch keine Fehlermeldungen. Ich kann nur die vorhandenen Sensoren nicht ins FHEM einfügen (set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery).
Mit dem JeeLink Clone bekomme ich weiter Werte geliefert. Muss ich das erst entfernen?
Vielen Dank schon mal für die Unterstützung
Gruß
Michael
Zitat von: Juggernaut am 26 Oktober 2018, 10:02:34
Sind die LaCrosse Sensoren direkt mit eine Empfänger gepairt und senden nur an diesen Empfänger die Daten oder senden die Sensoren einfach die Daten raus und jeder kann es empfangen?
nein und nein oder ja
Schau dir mal einen Sensor an , wenn der von mehr als einem Device versorgt wird sieht man das schön an den Internals ,
hier ein Bsp von mir mit drei Empfängern :
Internals:
CHANGED
DEF 36
IODev JeeLink
JeeLink2_MSGCNT 4
JeeLink2_RAWMSG OK 9 54 1 4 209 106
JeeLink2_TIME 2018-10-26 07:44:50
JeeLink_MSGCNT 1062
JeeLink_RAWMSG OK 9 54 1 4 191 106
JeeLink_TIME 2018-10-26 10:25:12
LASTInputDev LCGW
LCGW_MSGCNT 1158
LCGW_TIME 2018-10-26 10:25:12
LaCrosse_lastRcv 2018-10-26 10:25:12
MSGCNT 1159
NAME 1_FT_Bad
NR 67
STATE 21.4 °C
TYPE LaCrosse
addr 36
battery_new 0
corr1 0
corr2 0
previousH 106
previousT 21.5
sensorType 0=T(H)
Helper:
DBLOG:
temperature:
Log_db:
TIME 1540542069.42298
VALUE 21.4
READINGS:
2018-10-05 12:06:37 battery ok
2018-10-26 10:21:09 temperature 21.4
Zitat von: Juggernaut am 26 Oktober 2018, 10:02:34
Hallo zusammen,
ich habe mal eine Frage. Sind die LaCrosse Sensoren direkt mit eine Empfänger gepairt und senden nur an diesen Empfänger die Daten oder senden die Sensoren einfach die Daten raus und jeder kann es empfangen?
Hintergrund ist folgender:
Ich habe seit einiger Zeit Probleme mit meinem selbst gebauten JeeLink-Clone. Verbindung bricht häufig ab, 1 mal am Tag ein Reset ist eigentlich normal, manchmal muss ich den JeeLink-Clone sogar von der Spannung trennen damit er wieder funktioniert.
Deshalb habe ich mich entschlossen das LaCrosseGateway in der Minimum-Variante zu bauen. Hat auch so weit funktioniert, das RFM69HW Modul wird auch erkannt.
LaCrosseGateway V1.32 LaCrosseGateway (von mir gelöscht)
Home Setup Hardware OTA-Update Log Help Logout Reboot
ESP8266 present :-) Core: 2_3_0 SDK: 1.5.3(aec24ac9) free heap: 15536 Reset: Software/System restart -> Fatal exception:0 flag:4 (SOFT_RESTART) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
WiFi -52 dBm Mode: Station Time to connect: 4.2 s
Radio #1 RFM69 868300 kHz data rate: 17241 kbps
Radio #2 ---
Radio #3 ---
Radio #4 ---
Radio #5 ---
SHT75 ---
BME680 ---
BME280 ---
BMP280 ---
BMP180 ---
DHT22 ---
LM75 ---
SC16IS750 (0x90) ---
SC16IS750 (0x92) ---
MCP23008 ---
OLED ---
DataPort #1 81
DataPort #2 ---
DataPort #3 ---
Serial-bridge #1 ---
Serial-bridge #2 ---
Soft-bridge ---
Nextion ---
Analog port Disabled ADC=1 U=4294967295 mV (0 ... 0 mV)
Wenn ich jetzt aber das Log anschaue kommen keine Signale vom Sensor an, nur die Verbindung zum WLAN wird angezeigt
DATA:OK VALUES LGW 10439008 UpTimeSeconds=2182,UpTimeText=0Tg. 0Std. 36Min. 22Sek. ,WIFI=X,ReceivedFrames=0,FramesPerMinute=0,RSSI=-51,FreeHeap=17240,LD.Min=0.10,LD.Avg=0.13,LD.Max=428.80,OLED=none
DATA:OK VALUES LGW 10439008 UpTimeSeconds=2192,UpTimeText=0Tg. 0Std. 36Min. 32Sek. ,WIFI=X,ReceivedFrames=0,FramesPerMinute=0,RSSI=-53,FreeHeap=17000,LD.Min=0.10,LD.Avg=0.10,LD.Max=0.32,OLED=none
DATA:OK VALUES LGW 10439008 UpTimeSeconds=2202,UpTimeText=0Tg. 0Std. 36Min. 42Sek. ,WIFI=X,ReceivedFrames=0,FramesPerMinute=0,RSSI=-53,FreeHeap=16760,LD.Min=0.10,LD.Avg=0.10,LD.Max=0.27,OLED=none
usw.
Habe ich jetzt Empfangsprobleme (Antenne ist am RFM69HW dran) oder taucht hier erst etwas auf wenn ich die Sensoren aktiv vom FHEM angefragt werden? Es sind 3 Sensoren in der Nähe.
Das Gateway ist ins FHEM eingebunden und liefert auch keine Fehlermeldungen. Ich kann nur die vorhandenen Sensoren nicht ins FHEM einfügen (set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery).
Mit dem JeeLink Clone bekomme ich weiter Werte geliefert. Muss ich das erst entfernen?
Vielen Dank schon mal für die Unterstützung
Gruß
Michael
Was sind es denn für Sensoren? Möglicherweise ist die Datanrate nicht richtig eingestellt.
ZitatWas sind es denn für Sensoren? Möglicherweise ist die Datanrate nicht richtig eingestellt.
Das sind die TX29DHT-IT. An die Datenrate hab ich nicht gedacht, ist aber richtig eingestellt. Das ist es leider nicht :'(
Die Internals zeigen leider nur einen Device an welches die Sensoren versorgt. Ich wusste auch gar nicht das der Sensor von mehreren Devices versorgt werden kann :-[
JLLaCrosse = JeeLink-Clone
LaCrosseGateway = Das LGW
Internals:
CHANGED
DEF 0D
IODev JLLaCrosse
JLLaCrosse_MSGCNT 1692
JLLaCrosse_RAWMSG OK 9 13 1 4 103 66
JLLaCrosse_TIME 2018-10-26 11:35:38
LASTInputDev JLLaCrosse
LaCrosse_lastRcv 2018-10-26 11:35:38
MSGCNT 1692
NAME LC1_Aussen
NR 45
STATE T: 12.7 °C, F: 66.0 %rF, TP: 6.5 °C
TYPE LaCrosse
addr 0D
battery_new 0
corr1 0
corr2 0
previousH 66
previousT 12.7
sensorType 0=T(H)Das KeyValueProtcol vom Gateway kommt auch an, die UpTime wird alles 10 Sekunden aktualisiert.
Mir ist auch gerade aufgefallen das ich den Pair Befehl falsch geschrieben hatte, es passiert aber auch nichts wenn ich
set LaCrosseGateway LaCrossePairForSec 120 ignore_battery eingebe.
Im Log vom Gateway (LGW to FHEM) taucht aber nur diese aktive WLAN Verbindung auf, keine Sensoren. Die müsste ich ja eigentlich sehen wenn die Sensoren von jedem in Reichweite empfangen werden können. Ich habe irgendwie das Gefühl das zwar das RFM69HW Modul erkannt wird, das aber kein Daten ans Gateway liefert. Kann ich das irgendwie prüfen?
Gruß Michael
Die empfangen Daten würdest du auch ohne FHEM im Gateway sehen. Hast du mal die Antenne gewechselt?
Moin Juggernaut
Zeig doch mal ein list Deines GWs. Dann kann man evtl. mehr sehen. Und das falsch schreiben wuerde dir nicht passieren, wenn Du die Weboberflaeche benutzen wuerdest. Dann haettest Du bei Set das passende Komando ausgewaehlt, 60 eingetragen und Set gedrueckt!
Gruss Christoph
Hier das list vom Gateway.
Internals:
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol:CapacitiveLevel
DEF [i]von mir gelöscht[/i]:81
DeviceName [i]von mir gelöscht[/i]:81
FD 4
LaCrosseGateway_MSGCNT 753
LaCrosseGateway_TIME 2018-10-26 13:56:13
NAME LaCrosseGateway
NR 60
NTFY_ORDER 50-LaCrosseGateway
PARTIAL
RAWMSG OK VALUES LGW 10439008 UpTimeSeconds=8772,UpTimeText=0Tg. 2Std. 26Min. 12Sek. ,WIFI=X,ReceivedFrames=0,FramesPerMinute=0,RSSI=-49,FreeHeap=17432,LD.Min=0.10,LD.Avg=0.10,LD.Max=0.38,OLED=none
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.32
nextOpenDelay 2
settings (1=RFM69 f:868300 r:17241) {IP= [i]von mir gelöscht[/i]}]
Helper:
DBLOG:
state:
myDbLog:
TIME 1540547651.60635
VALUE LaCrossePairForSec 120 ignore_battery
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
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2018-10-26 13:56:13 state initialized
helper:
Attributes:
icon scc_868
room LaCrosse
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]Das mit dem falsch schreiben ist mir passiert weil ich den Befehl aus dem Wiki kopiert habe und mein Gateway nicht so heißt wie im Wiki.
ZitatHast du mal die Antenne gewechselt?
Noch nicht. Werde morgen den Lötkolben wieder anheizen.
Zitat von: Juggernaut am 26 Oktober 2018, 14:02:38
Hier das list vom Gateway.
Solange auf der Log-Page des LGW nicht solche
15:26:54: OK 9 57 1 4 94 106 [9E 55 18 6A DC]
15:26:54: OK 9 41 1 4 186 58 [9A 46 10 3A F5]
15:26:55: OK 9 37 1 4 199 56 [99 46 23 38 94]
15:26:55: OK 9 12 1 4 160 70 [93 05 84 46 01] Einträge auftachen, brauchst Du in FHEM überhaupt nicht kämpfen.
Wenn das LGW nichts schickt, dann geht in FHEM nichts.
Zitat von: Juggernaut am 26 Oktober 2018, 14:02:38
settings (1=RFM69 f:868300 r:17241) {IP= von mir gelöscht}]
868300 kHz mit einer DataRate von 17241 passt für Deine TX29DHT
Das ist ein "RFM69-Problem"
Ich erinnere mich dunkel, dass schon mal jemand einen hatte, der erkannt wurde aber nichts empfangen hat.
Oder Du hast die Antenne auf GND gelötet.
Hab mal die Antenne getauscht und auch noch mal geschaut das ich nicht an GND bin. Das passt so weit.
Leider nach wie vor nichts von den Sensoren zu sehen im LGW Log.
Ich werde als nächstes mal meinen JeeLink-Clone "Prototyp" schlachten und es mit dem RFM69W probieren. Bei dem weiß ich nämlich das der Chip funktioniert und auch Daten empfängt (gerade noch mal getestet ;) )
Vielleicht liegt es auch daran das ich am Gateway einen RFM69HW habe, wobei laut Datenblatt macht das keinen Unterschied solange ich damit nur empfange.
Es läuft! ;D
Ich habe den RFM69HW Chip gegen den RFM69W ausgetauscht. Es hat auf Anhieb funktioniert und liefert jetzt auch Werte im LGW Log sowie im FHEM Device selbst. Dort sehe ich 2 InputDev's.
Ob es jetzt am Typ liegt oder ob ich nur einen defekten Chip hatte weiß ich nicht, das hab ich nicht probiert.
Vielen Dank für euer Hilfe!!!!
Anbei noch das Log und ein list wie es jetzt aussieht.
LGW to FHEM
06:01:56: OK VALUES LGW 10439008 UpTimeSeconds=52391,UpTimeText=0Tg. 14Std. 33Min. 11Sek. ,WIFI=X,ReceivedFrames=21237,FramesPerMinute=21,RSSI=-53,FreeHeap=19584,LD.Min=0.09,LD.Avg=0.12,LD.Max=123.22,OLED=none
06:01:57: OK 9 34 1 4 179 51 [98 86 03 33 1E]
06:01:58: OK 9 13 1 4 55 78 [93 44 79 4E 54]
06:02:01: OK 9 9 1 4 184 50 [92 46 08 32 09]
06:02:05: OK 9 34 1 4 178 51 [98 86 02 33 EA]
06:02:06: OK 9 13 1 4 55 78 [93 44 79 4E 54]
list von einem Device
Internals:
CHANGED
DEF 0D
IODev JLLaCrosse
JLLaCrosse_MSGCNT 6233
JLLaCrosse_RAWMSG OK 9 13 1 4 55 78
JLLaCrosse_TIME 2018-10-30 06:04:33
LASTInputDev JLLaCrosse
LaCrosseGateway_MSGCNT 6519
LaCrosseGateway_TIME 2018-10-30 06:04:33
LaCrosse_lastRcv 2018-10-30 06:04:33
MSGCNT 6573
NAME LC1_Aussen
NR 45
STATE T: 7.9 °C, F: 78.0 %rF, TP: 4.3 °C
TYPE LaCrosse
addr 0D
battery_new 0
corr1 0
corr2 0
previousH 78
previousT 7.9
sensorType 0=T(H)
Helper:
DBLOG:
battery:
myDbLog:
TIME 1540875184.69724
VALUE ok
dewpoint:
myDbLog:
TIME 1540875767.18764
VALUE 4.3
humidity:
myDbLog:
TIME 1540875767.18764
VALUE 78
temperature:
myDbLog:
TIME 1540875767.18764
VALUE 7.9
Zitat von: Juggernaut am 30 Oktober 2018, 06:18:12
Ich habe den RFM69HW Chip gegen den RFM69W ausgetauscht. Es hat auf Anhieb funktioniert und liefert jetzt auch Werte im LGW Log sowie im FHEM Device selbst. Dort sehe ich 2 InputDev's.
Ob es jetzt am Typ liegt oder ob ich nur einen defekten Chip hatte weiß ich nicht, das hab ich nicht probiert.
Ich denke nicht, dass es am Typ gelegen hat. Ich habe schon Gateways mit dem RFM69HW aufgebaut und die laufen ohne Probleme.
So, ich frage jetzt trotzdem, auch auf die Gefahr hin, bereits Geschriebenes überlesen zu haben ::)
1. Gibt es eine Möglichkeit, den Sendeintervall des internen Sensors zu verlängern? Ich benötige die Daten nicht alle 10 Sekunden, eher alle 3 bis 5 Minuten. Theoretisch bräuchte ich die gar nicht, da es in dem Raum schon einen Sensor gibt...
2. Kann ich die Datenrate der Radios bereits in der Weboberfläche selbst mitgeben? Meine initCommands sind 20000#2r 590h 0a v, was meistens, aber nicht immer übernommen wird. Ich muss dann auf der Weboberfläche nochmal 20000#2r eingeben, damit Radio 2 die EC3000 empfängt.
Prinzipiell lassen sich die Sourcen mit den genannten Wünschen neu gestalten, ich möchte mich jedoch nicht von der Standardversion abkoppeln. Lassen sich die Wünsche zB. im Reiter "Setup" bei den "Flags" dem Gerät mitgeben?
Ich betreibe den LGW über einen USB-Seriell-Wandler (CP2102) zum Empfang der Daten und nutze die WLAN-Verbindung nur notgedrungen administrativ.
Viele Grüße, Ricardo
Hab mir einen TX25-it Sensor gekauft der hat 2 Kanäle 1. Intern 2. per Kabel .. leider bekomme ich diesne nicht in FHEM ... Manuell per Code oder auch per Anlernen nicht
Hier mein list vom Wlan Gateway
Hoffe jemand hat noch eine idee ?? Andere Lacrosse laufen PCA301 auch ..
Internals:
Alive 2018-11-06 17:42:23
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol:CapacitiveLevel
DEF 192.168.2.25:81
DeviceName 192.168.2.25:81
FD 99
LaCrossePair 2
NAME myLaCrosseGateway
NR 22
NTFY_ORDER 50-myLaCrosseGateway
PARTIAL
RAWMSG OK VALUES LGW 1259235 UpTimeSeconds=40,UpTimeText=0Tg. 0Std. 0Min. 40Sek. ,WIFI=Home-Wlan,ReceivedFrames=2,FramesPerMinute=2,RSSI=-67,FreeHeap=18512,LD.Min=0.15,LD.Avg=0.16,LD.Max=2.35,OLED=none
STATE opened
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.32
myLaCrosseGateway_MSGCNT 1060
myLaCrosseGateway_TIME 2018-11-06 17:42:53
nextOpenDelay 2
settings (1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 t:20~3) {IP=192.168.2.25}]
.attraggr:
.attrminint:
.clientArray:
KeyValueProtocol
LaCrosse
Level
PCA301
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
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2018-11-06 18:06:15 state opened
helper:
Attributes:
initCommands 1,868950,120i 3#2m 20#2t 55h 0a v
room Zentral
timeout 60
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
verbose 2
watchdog 300
Edit: als ich Mode auf wifi gesetzt habe ... danach scheint es zu klappen. Gerät wurde gefunden
Zitat von: kpwg am 04 November 2018, 09:50:04
1. Gibt es eine Möglichkeit, den Sendeintervall des internen Sensors zu verlängern? Ich benötige die Daten nicht alle 10 Sekunden, eher alle 3 bis 5 Minuten. Theoretisch bräuchte ich die gar nicht, da es in dem Raum schon einen Sensor gibt...
Aktuell nicht, Du kannst nur 0 bei "Internal sensors: ID:" eintragen, dann wird es nie gesendet.
Eine Konfiguration wäre da nett, ich nehme es in die Wunschliste (ohne Chance auf kurzfristige Realisierung) auf.
Wenn es nur um das Logging usw. geht, kann man es aber auch mit event-on-change-reading drosseln.
Zitat von: kpwg am 04 November 2018, 09:50:04
2. Kann ich die Datenrate der Radios bereits in der Weboberfläche selbst mitgeben? Meine initCommands sind 20000#2r 590h 0a v, was meistens, aber nicht immer übernommen wird. Ich muss dann auf der Weboberfläche nochmal 20000#2r eingeben, damit Radio 2 die EC3000 empfängt.
Das habe ich vor längerer Zeit mal probiert, die initCommands auf der setup-page des LGW konfigurierbar zu machen, die beim Start des LGW ausgeführt werden.
Hatte es aber nicht zum Laufen bekommen.
Ich kann mal bei Gelegenheit einen neuen Anlauf machen. Oder Du einen Patch bei mir einwerfen.
Zitat von: HCS am 07 November 2018, 11:38:18
Aktuell nicht, Du kannst nur 0 bei "Internal sensors: ID:" eintragen, dann wird es nie gesendet.
Dann mache ich irgendwas falsch. Ich bekomme trotzdem in sehr kurzen Intervallen Daten geschickt. Ober kann ich das nur verhindern, wenn kein Sensor direkt am LGW angeschlossen wurde? Aktuell habe ich noch einen BMP180 dran; testweise auslöten am Produktivsystem ist "ungeschickt" ;)
Zitat von: kpwg am 08 November 2018, 16:50:20
Dann mache ich irgendwas falsch. Ich bekomme trotzdem in sehr kurzen Intervallen Daten geschickt.
Seltsam, wir hatten das gerade kürzlich umgekehrt, der Anwender hatte reklamiert, dass er keine Daten von den internen Sensoren bekommt.
Hatte keine ID eingetragen. Nachdem er eine gesetzt hatte, hat es dann funktioniert.
Aber möglicherweise sendet es das LGW auch bei ID 0 und FHEM dispatched es dann nur nicht.
Wenn kein Sensor angschlossen ist, sendet es nichts. Habe hier eins ohne, da geht nichts raus.
Sieht man auf der log page bei "LGW to FHEM:", ob
17:02:35: OK WS <ID> 4 4 165 62 255 255 255 255 255 255 255 255 0
geschickt werden.
Zitat von: HCS am 08 November 2018, 17:04:49
Wenn kein Sensor angschlossen ist, sendet es nichts. Habe hier eins ohne, da geht nichts raus.
Sieht man auf der log page bei "LGW to FHEM:", ob
17:02:35: OK WS <ID> 4 4 165 62 255 255 255 255 255 255 255 255 0
geschickt werden.
Dann haben wir es schon. Da baue ich nochmal einen "nackten" LGW mit zwei RFM69, damit Ruhe wird ;)
Danke für den Support!
Hi,
ich habe vor einiger Zeit mit fhem angefangen.
Zuerst mit einem CUL und eine rFS20 Steckdose. Das hat problemlos funktioniert.
Jetzt habe ich ein paar PCA301 Steckdosen erhalten und wollte die mit dem MINI LGW (2x RFM69) anbinden.
Ein vorhandener Lacrosse TX29DTH liess sich schnell anlernen.
Hat auch Temperatur und Feuchtigkeit angezeigt.
Nur die PCA 301 wollten nicht gefunden werden.
Nachdem ich jetzt mit den Parametern ein bisschen rumgespielt habe empfange ich auch keine Temperatur mehr ;-(
Was muss ich einstellen, damit ich auf dem einen RFM69 die Steckdosen steuern möchte und auf dem anderen RFM69 den Temperatur Sensor anbinden möchte.
Soweit ich heraus gefunden habe, möchte Lacrosse 868,300 MHz mit 17241kbps (toggeln brauche ich nicht -> 0t)
Die PCAs: 868,960 MHz mit 6631 kbps (?!)
Somit müsste ich ein initcommand mit :
attr myLGW initCommands 4m 868300f 0t 1M 868960F 0T
senden?
Hinzu kommt das der LGW ständig in den Status "disconnected" geht.
Das LGW hängt direkt neben dem AP.
list myLGW
Internals:
CFGFN
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol:CapacitiveLevel
DEF 192.168.178.7:81
DeviceName 192.168.178.7:81
FD 22
NAME myLGW
NR 289
NTFY_ORDER 50-myLGW
PARTIAL
RAWMSG OK VALUES LGW 5124548 UpTimeSeconds=34180,UpTimeText=0Tg. 9Std. 29Min. 40Sek. ,WIFI=ASUS,ReceivedFrames=1103,FramesPerMinute=0,RSSI=-45,FreeHeap=17624,LD.Min=0.16,LD.Avg=0.16,LD.Max=0.86,OLED=none
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.32
myLGW_MSGCNT 28266
myLGW_TIME 2018-11-13 21:35:15
nextOpenDelay 2
settings (1=RFM69 f:868300 r:8842) + (2=RFM69 f:868960 r:17241) {IP=192.168.178.7}]
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
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2018-11-13 21:35:15 state initialized
Sorry wenn das alles DAU Fehler sind. Im Wiki ist das alles nicht so einfach - für einen Neuling
MM
Moin
Kannst Du bitte codetags (Das " # " ueber den smilies) benutzen. Das geht auch nachtraeglich.
Und dann ist attr myLGW initCommands 4m 868300f 0t 1M 868960F 0Tirgendwie nicht ganz richtig! Schau Dir das im Wiki noch mal genauer an, Absatz 3.10 https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Inbetriebnahme_von_PCA301 (https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Inbetriebnahme_von_PCA301).
attr myLGW initCommands 1,868950,120i 1#2m v sollte passen, bin mir aber auch nicht 100% sicher!
Gruss Christoph
Hi Christoph,
hat nicht gepasst, aber ich habe solange initcommands geschickt, bis es passte.
Ist jetzt nicht die elegante Lösung und werde ich mal demnächst nochmal in einem Rutsch konfigurieren.
Aber so richtig schlau werde ich aus den ganzen Dokumentationen noch nicht.
Aber das geht natürlich nur, wenn der LGW dauernd connected ist und nicht nach absetzten eines Befehls sofort in den Zustand disconnected geht.
Ein Ping auf den LGW findet dann diesen nicht! Also liegt es am LGW und nicht am FHEM Server.
Was muss ich machen damit der sich nicht immer aus dem Netz hängt?
Gruß
Christoph
Zitat von: marsmaennchen am 14 November 2018, 23:37:03
Was muss ich machen damit der sich nicht immer aus dem Netz hängt?
Nichts besonderes. Erreichst Du denn die Weboberfläche? Dort kannst Du auch viel sehen und einstellen und die Initialisierung im Reiter "Log" durchführen. Wie ist die Uptime? Startet der LGW immer wieder neu oder klemmt es mit der Übertragung?
Viele Grüße, Ricardo
Wisst ihr was ich hasse?
Tagelang bastel ich rum und stelle Fragen hier im Forum und irgendwann läuft es einfach und ich weiss nicht was ich gemacht habe.
Das lese ich übrigens öfter hier im Forum.
Danke für Eure Hilfe.
eingestellt ist jetzt übrigens:
(1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 t:20~3) , timeout auf 60,30
Den Toggle brauche ich nicht, aber solange ich kein komplettes init Command habe, werde ich die Finger davon lassen.
MM
Hallo,
vom LaCrossGateway/JeeLink wird jetzt das WH24 Protokoll auch empfangen (https://forum.fhem.de/index.php/topic,93280.msg859226.html#msg859226).
pejonp
Moin,
mein LGW hat ein
2018.11.21 00:05:09 3: myLGW: Unknown code OK CC 237 39 122 85 126 49 160 68 71 191 148 125 202 93 180 111 21 140 107 221 53 176 122 158 244 223 40 17 154 246 240 20 214 142 135 196 69 46 185 104 46 195 , help me!
empfangen.
Seitdem ist wieder alles verstellt. :-[
Was muss ich machen damit der LGW folgende Einstellung für PCA301 und TX29 DTH hat:
Der eine RFM69 (PCA301) sollte so wie ich aus den verschiedenen Foren gelesen habe :
Frequenz 868960, Datenrate 6631
der andere RFM69 (für den Temperatur Sensor)
Frequenz 868300, Datenrate 17241
Ich habe mit ein bisschen probieren auf folgendes Ergebnis geschafft:
settings (1=RFM69 f:868960 r:99672039) + (2=RFM69 f:868300 r:9579) {IP=
Also ziemlich durcheinander.
Jetzt lässt sich aber nichts mehr ändern
Wenn ich jetzt z.B.
attr LGW_S initCommands 1 6631#1r v
passiert gar nichts.
Es gibt aber auch so viele verschiedene Einstellmöglichkeiten
Ich habe echt versucht mich durch Wiki/commandref zu lesen, Listen sind dort teilweise zu finden, aber leider bekomme ich das nicht hin.
Könnt ihr mich bitte unterstützen.
Erstmal mit dem richtigen commando und dann wie ich das selber erstellen kann.
Was kann ich direkt im LGW einstellen (myip/LOG) und wo finde ich die Befehle dazu?
Danke
MM
Moin
Also mein init sieht so aus:
1,868950,120i 3#2m 20#2t v
Ich brauche das toggle auch nicht, aber habe es einfach aus dem Wiki uebernomen!
Du soltest Dein GW nochmal komplett resetten, um erstmal wieder auf Anfang zurueck zu kommen. (https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#LaCrosseGateway_zur.C3.BCcksetzen)
Fuer die PCAs ist das init etwas anders als fuer die restlichen Sensoren!
Wieso bestehst Du eigentlich immer auf die Frequenz 868960 bei PCA, die habe ich noch nirgendwo gelesen?
1,868950,120i 17241#2r 868300#2f v bin ich der Meinung sollte passen! Der erste Empfaenger fuer PCA mit Intervall 120 Sekunden, der zweite Empfaenger fuer TX29 mit 868300Hz und datarate 17241!
Das kann man sich sehr gut auf der Helpseite des Gateways ansehen!
Gruss Christoph
Hi Christoph,
ich hatte beim ersten mal Probleme mit 868950, mit 868960 lief es.
Jetzt habe ich geresetted (das war das Schnellste) und den Rest so konfiguriert wie du geschrieben hast.
DANKE!
Lief auf Anhieb.
Ich habe die Parameter jetzt auch direkt im LGW eingegeben und nicht wie sonst über FHEM.
Dieselben Parameter hatte ich vorher auch über FHEM versucht, da hatte ich aber Probleme.
Dann schaue ich mal was die "ESP RGBWW Wifi Led Controller" Aktion so in Zukunft gibt ;-)
Gruß
Christoph
also ich hatte nun Zeit und habe die Zeile gelöscht + Delete in FHEM auch RAW 0c und 2c gemacht alles leer alles weg.
Dose 1 Taster paar Sekunden gedrückt Dose taucht auf . Schalten ON / OFF Status wird ausgeführt Gerät schaltet aber in fhem status wird nicht aktualisiert. steht immer nur seton ..
Im Gateway in der Zeile taucht das Gerät auch auf.
Dose 2 taster paar Sekunden gedrückt taucht auch in Fhem auf funktioniert zu 100% richtig.
Bin echt gerade soweit alles zu verkaufen :(
Zitat von: ChrisW am 24 November 2018, 10:56:22
Dose 1 Taster paar Sekunden gedrückt Dose taucht auf . Schalten ON / OFF Status wird ausgeführt Gerät schaltet aber in fhem status wird nicht aktualisiert. steht immer nur seton ..
Das kenne ich nur, wenn die PCA301 sich gerade so an der Reichweitengrenze befindet, so dass sie das LGW hört aber das LGW die Dose nicht.
Kommt im LGW-Log nach einem set statusRequest so eine Zeile, die mit OK 24 beginnt?
19:52:56: OK 24 3 4 3 97 128 1 0 59 0 1 [03 04 03 61 80 01 00 3B 00 01 ED 0C]
also Reichweite ist echt das Problem ... gerade mal 5m dann klappt alles sobald es 6-7m sind nicht mehr :(
Hallo Chris,
Zitat von: ChrisW am 26 November 2018, 19:59:03
also Reichweite ist echt das Problem ... gerade mal 5m dann klappt alles sobald es 6-7m sind nicht mehr :(
prüfe doch mal am LGW die Antennenlänge oder die Verlegung der Antenne.
Gruß Peter
2018-12-09 16:38:43 LaCrosseGateway LGW UpTime: 0Tg. 1Std. 36Min. 52Sek.
2018-12-09 16:38:43 LaCrosseGateway LGW UpTimeSeconds: 5812
2018-12-09 16:38:43 LaCrosseGateway LGW RSSI: -70
2018-12-09 16:38:43 LaCrosseGateway LGW FramesPerMinute: 41
2018-12-09 16:38:43 LaCrosseGateway LGW ReceivedFrames: 3654
2018-12-09 16:38:43 LaCrosseGateway LGW FreeHeap: 17320
2018-12-09 16:38:43 LaCrosseGateway LGW OLED: none
2018-12-09 16:38:45 LaCrosse LaCrosse_25 battery: ok
2018-12-09 16:38:45 LaCrosse LaCrosse_25 temperature: 21.2
2018-12-09 16:38:45 LaCrosse LaCrosse_25 humidity: 48
2018-12-09 16:38:46 EC3000 EC3000_7C0C consumption: 27.513
2018-12-09 16:38:46 EC3000 EC3000_7C0C power: 0
2018-12-09 16:38:46 EC3000 EC3000_7C0C powerMax: 1593.4
2018-12-09 16:38:46 EC3000 EC3000_7C0C off
2018-12-09 16:38:46 CustomSensor bme680_cc iaq: 244
2018-12-09 16:38:46 CustomSensor bme680_cc gas: 895320
2018-12-09 16:38:46 CustomSensor bme680_cc gas-kohm: 895.4
@PeMue
LGW-V1.3-Platine mit BME680 funktioniert! :) :) :)
Sogar in Korrelation mit meinem ersten BME680 CustomSensor!
Der Part:
CustomSensor bme680_cc iaq: 244
2018-12-09 16:38:46 CustomSensor bme680_cc gas: 895320
2018-12-09 16:38:46 CustomSensor bme680_cc gas-kohm: 895.4
Kommt wohl vom internen LGW-BME680 Sensor?
Wie meldet sich ein Externer bezüglich ID?
Grüße,
Jürgen
Hallo Jürgen,
Zitat von: juergs am 09 Dezember 2018, 16:45:43
LGW-V1.3-Platine mit BME680 funktioniert! :) :) :)
Sogar in Korrelation mit meinem ersten BME680 CustomSensor!
super, habe aber auch nichts Anderes erwartet.
Zitat von: juergs am 09 Dezember 2018, 16:45:43
Der Part:
CustomSensor bme680_cc iaq: 244
2018-12-09 16:38:46 CustomSensor bme680_cc gas: 895320
2018-12-09 16:38:46 CustomSensor bme680_cc gas-kohm: 895.4
Kommt wohl vom internen LGW-BME680 Sensor?
Ja, der kommt vom internen Sensor. Allerdings berechnet HCS da keinen IAQ Wert, sondern gibt nur den Widerstandswert aus.
Zitat von: juergs am 09 Dezember 2018, 16:45:43
Wie meldet sich ein Externer bezüglich ID?
Die müsstest Du entweder direkt im (Universalsensor-)Sketch angeben oder kannst diese m.Wn. über die serielle Schnittstelle konfigurieren.
Gruß Peter
Hallo Peter,
das mit der ID war jetzt klar. Über Serielle zu konfigurieren.
Allerdings geht aus:
https://wiki.fhem.de/wiki/Universalsensor (https://wiki.fhem.de/wiki/Universalsensor)
nicht die Definition in fhem.cfg hervor. Autocreate (nicht) aktiv?
2018.12.09 19:43:34 4: LaCrosse: Unknown device 76, please define it
2018.12.09 19:43:36 5: LGW: dispatch OK WS 112 5 5 90 18 255 255 255 255 255 255 255 255 0 38 253 0 0 211 1 189 225 0 0 4 30 246 255 255 255 196 240
2018.12.09 19:43:36 4: LaCrosse: Unknown device 70, please define it
2018.12.09 19:43:37 5: LGW: dispatch OK 9 8 1 4 206 106
2018.12.09 19:43:37 4: LaCrosse: Unknown device 08, please define it
2018.12.09 19:43:37 5: LGW: dispatch OK 9 37 1 4 189 49
2018.12.09 19:43:37 4: LaCrosse: Unknown device 25, please define it
2018.12.09 19:43:41 5: LGW: dispatch OK 9 8 1 4 206 106
2018.12.09 19:43:41 4: LaCrosse: Unknown device 08, please define it
2018.12.09 19:43:42 5: LGW: dispatch OK 9 37 1 4 189 49
2018.12.09 19:43:42 4: LaCrosse: Unknown device 25, please define it
2018.12.09 19:43:44 5: LGW: dispatch OK WS 118 4 4 224 38 255 255 255 255 255 255 255 255 0 3 252 0 76 57 0 0 0
2018.12.09 19:43:44 4: LaCrosse: Unknown device 76, please define it
2018.12.09 19:43:45 5: LGW: dispatch OK 9 8 1 4 206 106
2018.12.09 19:43:45 4: LaCrosse: Unknown device 08, please define it
2018.12.09 19:43:46 5: LGW: dispatch OK 9 37 1 4 189 49
2018.12.09 19:43:46 4: LaCrosse: Unknown device 25, please define it
Das hier scheint der externe "UniversalSensor" zu sein:
2018.12.09 19:43:36 5: LGW: dispatch OK WS 112 5 5 90 18 255 255 255 255 255 255 255 255 0 38 253 0 0 211 1 189 225 0 0 4 30 246 255 255 255 196 240
2018.12.09 19:43:36 4: LaCrosse: Unknown device 70, please define it
Mit "device 70" = hex 70 = dez. 112. ... Ob diese Wahl ok war?
Ganz zu schweigen von den anderen LaCrosse-Sensoren, die so bei mir sonst noch herumschwirren ...
Zitat von: juergs am 09 Dezember 2018, 19:57:26
Allerdings geht aus:
https://wiki.fhem.de/wiki/Universalsensor (https://wiki.fhem.de/wiki/Universalsensor)
nicht die Definition in fhem.cfg hervor. Autocreate (nicht) aktiv?
Nein, wir haben mehrere Universalsensoren. Einen von Dirk und den Anderen von Thomas auf dem nanoLGW.
set <LGW> LaCrossePairForSec 300 in Verbindung mit autocreate aktiv sollte das richten.
Gruß Peter
Zitat von: PeMue am 09 Dezember 2018, 20:02:11
Nein, wir haben mehrere Universalsensoren. Einen von Dirk und den Anderen von Thomas auf dem nanoLGW.
set <LGW> LaCrossePairForSec 300 in Verbindung mit autocreate aktiv sollte das richten.
Gruß Peter
Hallo Peter,
ja, 300 macht Sinn, meine 120 waren wohl zu wenig beim Sendeintervall des BME-Sensors ...
Zitat2018.12.09 20:09:04 5: protocol does not match, ignore received package (AAAAAAAAAAAAAAAA80DA) Reason: Not a hideki protocol
2018.12.09 20:09:04 5: LGW: dispatch OK 9 37 1 4 190 49
2018.12.09 20:09:04 4: LaCrosse: Unknown device 25, please define it
2018.12.09 20:09:04 5: LGW: dispatch OK 9 8 1 4 205 106
2018.12.09 20:09:04 4: LaCrosse: Unknown device 08, please define it
2018.12.09 20:09:05 5: LGW: dispatch OK WS 118 4 4 222 38 255 255 255 255 255 255 255 255 0 3 252 0 77 21 0 0 0
2018.12.09 20:09:05 4: LaCrosse: Unknown device 76, please define it
2018.12.09 20:09:06 5: LGW: dispatch OK WS 112 5 5 92 18 255 255 255 255 255 255 255 255 0 39 3 0 0 233 1 176 194 0 0 4 30 246 255 255 255 9 26
2018.12.09 20:09:06 4: LaCrosse: Unknown device 70, please define it
Irgendwas scheint noch nicht richtig konfiguriert zu sein ... autocreate ist aktiv.
Fhem-Update gemacht und die neueste LGW-Binary geflasht.
Vielleicht ist hdguckens UniversalSensor-Sketch aus seinem git-Repo nicht das aktuelle...
Schaue die Threads noch mal in den nächsten Tagen durch....
Grüße + vielen Dank für die tolle Arbeit, die hier alle leisten,
Jürgen
Hallo Jürgen,
der Sketch im git-Repo ist der aktuelle.
Versuch mal mit ignore_battery:
set <LGW> LaCrossePairForSec 300 ignore_battery
Bei den normalen LaCrosse Sensoren ist das Bit "battery new" nach Batteriewechsel für eine Weile gesetzt,
autocreate funktioniert nur, solange das Bit gesetzt ist oder "ignore_battery" angegeben ist.
Gruß Thomas
Hallo Thomas,
kaum macht man es richtig, schon gehts. :D :)
Super, danke für den Problemlöser (schon x-mal gehört + gesehen):
set <LGW> LaCrossePairForSec 300 ignore_battery
Es geht jetzt !
War wohl gestern etwas Betriebsblind nach dem Aufbau und Fehlersuche der HW ...
Grüße,
Jürgen
Zu früh gefreut,
mit externem Sensor auf ID: 70 und internem Sensor auf ID:76
ist dem LGW-internen BME der IAQ abhandengekommen ...
(Gehe mal davon aus, daß GAS1 = IAQ ist.)
Es scheint, der R-Wert tritt an Stelle des IAQ ...
Prüfe morgen mal nach, ob der Sensor, ohne LGW, "normale" Werte liefern kann ...
BME680 OK T=23.3 H=37 P=1032.6 G=9344
War eigentlich der Meinung, gestern hätte er richtige Werte übertragen....
Grüße,
Jürgen
Hallo Jürgen,
Zitat von: juergs am 10 Dezember 2018, 20:37:40
mit externem Sensor auf ID: 70 und internem Sensor auf ID:76
ist dem LGW-internen BME der IAQ abhandengekommen ...
(Gehe mal davon aus, daß GAS1 = IAQ ist.)
gas1 müsste der IAQ sein, gas2 der Widerstand.
Gruß Peter
Zitat von: PeMue am 10 Dezember 2018, 20:45:48
Hallo Jürgen,
gas1 müsste der IAQ sein, gas2 der Widerstand.
Gruß Peter
Hallo Peter, hatte ich nach den Werten auch zugeordnet :)
Ist wohl passiert , nach dem der zweite Sensor dazugekommen ist, oder der Sensor wäre defekt.
Reset bzw. Stromlos machen der LGW hatte keinen Effekt.
Gehe dann im nächsten Schritt noch mal auf "Anfang" und checke das nach.
Jürgen
Hallo Jürgen, Hallo Peter,
sorry, hab heute erst wieder reingeschaut :-[
Geht es denn inzwischen wie es soll ? Gas1 ist der IAQ, der ist anfangs "0", Werte kommen nach dem Einschalten bzw. Neustart erst nach einigen Minuten !
Gas2 liefert aber von Anfang an die Widerstandswerte.
Gruß Thomas
Zitat von: hdgucken am 16 Dezember 2018, 20:13:42
Hallo Jürgen, Hallo Peter,
sorry, hab heute erst wieder reingeschaut :-[
Geht es denn inzwischen wie es soll ? Gas1 ist der IAQ, der ist anfangs "0", Werte kommen nach dem Einschalten bzw. Neustart erst nach einigen Minuten !
Gas2 liefert aber von Anfang an die Widerstandswerte.
Gruß Thomas
Hallo Thomas,
danke fürs Draufschauen.
In meinen Flashes LGW + UniversalSensor von der letzten Woche scheint der Universal-Senor über die LGW zu gehen.
Allerdings zeigt die LGW mit integrierten BME680 nur Gas1 mit dem Widerstand, aber kein IAQ an.
hier (https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=110525;image)
Gas2 zeigt dauerhaft "0" an .
Habe jeweils 2 Platinen, aber noch zu wenig RFMs zum Komplettieren und muss noch auf die Lieferung
der bestellten Module warten.
Habe mir den Code der LGW mal angeschaut und zumindest gesehen, dass HCS die BSEC-Lib nicht benutzt.
Erschien mir aber heute zu aufwendig, den Code von HCS diesbezüglich zu analysieren.
Mache ich, wenn etwas mehr Zeit zur Verfügung habe, schaue ich mir das in Ruhe an. ;)
Grüße,
Jürgen
Hallo Jürgen,
Zitat von: juergs
Allerdings zeigt die LGW mit integrierten BME680 nur Gas1 mit dem Widerstand, aber kein IAQ an.
Gas2 zeigt dauerhaft "0" an .
Habe mir den Code der LGW mal angeschaut und zumindest gesehen, dass HCS die BSEC-Lib nicht benutzt.
Das stimmt, HCS macht das nicht mit der offiziellen BSEC Soft.
Die LGW's mit BME680 geben deshalb auch nur den Widerstandswert und keinen IAQ aus !
Somit alles ok bei Dir ;)
Bei meinen LGW's gibts da auch Schwierigkeiten:
Erstes LGW mit OLED Display und BME680: Gas Werte liegen "nur" irgendwo zwischen 7 und 8 kOhm, kommen aber kontinuierlich.
Zweites LGW mit Nextion Display und BME680: Gas Werte liegen auch nur zwischen 7 und 8 kOhm, kommen aber nur für eine unterschiedliche lange Zeit (einige Stunden),
dann springt der Gas Wert auf 808,37 kOhm. Siehe Bild unten. Dieser LGW stürzt auch oft ab, da hilft dann nur komplett aus/ein :o
Die Ermittlung des Widerstandswertes scheint noch nicht 100% zu funktionieren. Hatte schon mal kurz geschaut, aber auch noch keine Lösung.
Gruß Thomas
Seit dem Update heute keine Verbindung mehr zum DataPort vom Gateway möglich, Rollback auf Revision 17131 war nötig.
2019.01.10 11:33:35 3: NTFY return: LC_WLAN_GTW:http://192.168.178.50:81
/: malformed or unsupported URL
Zitat von: Saharel am 10 Januar 2019, 17:43:57
Seit dem Update heute keine Verbindung mehr zum DataPort vom Gateway möglich, Rollback auf Revision 17131 war nötig.
2019.01.10 11:33:35 3: NTFY return: LC_WLAN_GTW:http://192.168.178.50:81
/: malformed or unsupported URL
Bei mir sind alle LGW verbunden mit der
36_LaCrosseGateway.pm 18150 2019-01-05 22:34:15Z HCS $
Zeig mal einen list vom LaCrosseGateway device
VOR UPDATE
Internals:
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol:CapacitiveLevel
DEF 192.168.178.50:81
DeviceName 192.168.178.50:81
FD 4
LC_WLAN_GTW_MSGCNT 14
LC_WLAN_GTW_TIME 2019-01-15 21:28:38
NAME LC_WLAN_GTW
NR 70
NTFY_ORDER 50-LC_WLAN_GTW
PARTIAL
RAWMSG OK 9 0 1 4 176 44
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.32
nextOpenDelay 2
settings (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868950 r:6631) + OLED {IP=192.168.178.50}]
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
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2019-01-15 21:28:38 state initialized
helper:
Attributes:
devStateIcon initialized:10px-kreis-gruen disconnected:10px-kreis-rot
icon hue_filled_bridge_v2
initCommands 2,868950,120i v,a0
room 02_Eingang
timeout 120,30
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
verbose 5
watchdog 300
NACH UPDATE
Internals:
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol:CapacitiveLevel
DEF 192.168.178.50:81
DeviceName 192.168.178.50:81
NAME LC_WLAN_GTW
NR 70
NTFY_ORDER 50-LC_WLAN_GTW
PARTIAL
STATE initialized
TIMEOUT 1
TYPE LaCrosseGateway
devioLoglevel 4
nextOpenDelay 2
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
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2019-01-15 21:18:52 state initialized
helper:
Attributes:
devStateIcon initialized:10px-kreis-gruen disconnected:10px-kreis-rot
icon hue_filled_bridge_v2
initCommands 2,868950,120i v,a0
room 02_Eingang
timeout 120,30
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
verbose 0
watchdog 300
LOG:
2019.01.15 21:23:04 3: Opening LC_WLAN_GTW device 192.168.178.50:81
2019.01.15 21:23:04 5: HttpUtils url=http://192.168.178.50:81
/
2019.01.15 21:23:04 1: LC_WLAN_GTW: Can't connect to 192.168.178.50:81
: http://192.168.178.50:81
/: malformed or unsupported URL
@Saharel
Auch Du darfst gerne die Codetags benutzen! (Das # ueber den Smilies. Kann (muss) man auch nachtraeglich anwenden!)
Das ist echt bloed, wenn man so einen Post ansieht!
Kann es sein, dass Du ein Problem im Netzwerk hast? Ich musste, aufgrund von Problemen, das Gateway komplett neu starten!
Gruss Christoph
also ich werd damit einfach nicht warm.. ich geb mein ganzes Zeugs ab hab Sticks, Gateway Steckdosen und Thermostate wenn jemand Intresse hat ..
Schade aber ich bekomme es nicht schön zum laufen für meine "Ansprüche"
Zitat von: ChrisW am 16 Januar 2019, 11:31:08
also ich werd damit einfach nicht warm.. ich geb mein ganzes Zeugs ab hab Sticks, Gateway Steckdosen und Thermostate wenn jemand Intresse hat ..
Schade aber ich bekomme es nicht schön zum laufen für meine "Ansprüche"
Was hast du denn genau alles abzugeben?
Zitat von: pc1246 am 15 Januar 2019, 21:44:09
@Saharel
Auch Du darfst gerne die Codetags benutzen! (Das # ueber den Smilies. Kann (muss) man auch nachtraeglich anwenden!)
Das ist echt bloed, wenn man so einen Post ansieht!
Kann es sein, dass Du ein Problem im Netzwerk hast? Ich musste, aufgrund von Problemen, das Gateway komplett neu starten!
Gruss Christoph
Danke # gesetzt 8)
Das problem besteht nur mit der aktuellen version der LaCross Module. Mach ich einen restore funktioniert alles. Reboot hab ich auch schon probiert, daran liegt es nicht.
Hm okay
Ich bin nicht ganz auf Stand, zugegebenermassen. Habe auf beiden noch V1.30! Aber Netzprobleme nehmen die schon immer krumm!
Bei mir hilft dann auch nur Powercut, reboot ist irgendwie nicht das Gleiche!
Gruss Christoph
P.S.: bin morgen wieder zu Hause, evtl. finde ich da mal Zeit einen hoch zu ziehen.
Zitat von: Saharel am 15 Januar 2019, 21:19:59
VOR UPDATE
initCommands 2,868950,120i v,a0
timeout 120,30
watchdog 300
initCommands 2,868950,120i v,a0ergibt keinen Sinn, das sollte wohl
2,868950,120i 0a vsein, was aber eher nicht Dein Problem verursacht.
"timeout" in Kombination mit "watchdog" sollte nur eine Angabe haben.
timeout 120
watchdog 300
Zitat von: Saharel am 15 Januar 2019, 21:19:59
LOG
2019.01.15 21:23:04 3: Opening LC_WLAN_GTW device 192.168.178.50:81
2019.01.15 21:23:04 5: HttpUtils url=http://192.168.178.50:81
/
2019.01.15 21:23:04 1: LC_WLAN_GTW: Can't connect to 192.168.178.50:81
: http://192.168.178.50:81
/: malformed or unsupported URL
Das Problem kann ich inzwischen nachvollziehen, seltsamerweise nur auf einer FHEM-Installation, bei den anderen geht es ???
Ich habe gerade eine geänderte Version von 36_LaCrosseGateway.pm eingecheckt, probier bitte mal mit der, ob es damit funktioniert.
Hallo HCS,
ich habe ein Phänomen mit der LGW V1.32 mit angeschlossenem OLED + BME280.
Temperatur und Luftdruck wird korrekt angezeigt, aber Luftfeuchte = 0 (auch bei getauschtem Sensor).
Gäbe es da noch etwas zu beachten/konfigurieren?
Grüße,
Jürgen
Einiges sicher 5 PCA301 1x das Lacrosse / Jeelink Wifi Gateway. Dann noch die 2 Sticks. Schick einfach mal eine Nachricht. Bin noch nicht dazu gekommen alles zusammenzusuchen.
Zitat von: juergs am 17 Januar 2019, 13:03:04
ich habe ein Phänomen mit der LGW V1.32 mit angeschlossenem OLED + BME280.
Temperatur und Luftdruck wird korrekt angezeigt, aber Luftfeuchte = 0 (auch bei getauschtem Sensor).
Was meint denn das WebFrontend vom LGW auf der Hardware-Page?
Zitat von: juergs am 17 Januar 2019, 13:03:04
... LGW V1.32 mit angeschlossenem OLED + BME280.
Temperatur und Luftdruck wird korrekt angezeigt, aber Luftfeuchte = 0 (auch bei getauschtem Sensor).
Gäbe es da noch etwas zu beachten/konfigurieren?
...
Ich habe genau die Kombi am Laufen.
Bekomme sowohl Temp und Luftdruck, als auch Luftfeuchte (wobei ich eben gesehen habe, dass Pressure gar nicht mit in state steht).
Zeig doch mal ein List von dem definierten Sensor.
Hier erst mal ein Bild (https://forum.fhem.de/index.php/topic,78619.msg890013.html#msg890013).
ZitatWas meint denn das WebFrontend vom LGW auf der Hardware-Page?
Der BME280 wird erkannt. Temperatur und Druck kommen ja, nur die Feuchte = 0 .
Zitat von: juergs am 18 Januar 2019, 09:36:11
Der BME280 wird erkannt. Temperatur und Druck kommen ja, nur die Feuchte = 0 .
Kannst Du mal bitte die "BME280"-Zeile aus der Hardware-Page posten?
Also das:
BME280 OK T=25.2 H=37 P=1021.9 Calibration: T1:28118 T2:26034 T3:50 H1:75 H2:363 H3:0 H4:315 H5:0 H6:30 P1:38073 P2:-10914 P3:3024 P4:9287 P5:58 P6:-7 P7:9900 P8:-10230 P9:4285 ADC: T=530988 H=26825 P=293127Oder noch besser die komplette Seite.
Hallo HCS,
habe noch mal die LGW-Firmware geflasht und habe leider im OLED die Anzeige LGW1.32
aber ein WLAN-Accespoint erscheint nicht.
Könnte auch ein Hardware-Problem sein, weil scheinbar OLED initialisiert und dann resettet.
Versuche mal alles zu Löschen, zu kontrollieren, um wieder ein Konfigurationszustand zu erreichen ...
Binary: D:\fhem\fhem-5.9\contrib\arduino\36_LaCrosseGateway\Release\JeeLink_LaCrosseGateway.bin
Sorry dafür.
Jürgen
Zitat von: HCS am 17 Januar 2019, 10:37:43
Das Problem kann ich inzwischen nachvollziehen, seltsamerweise nur auf einer FHEM-Installation, bei den anderen geht es ???
Ich habe gerade eine geänderte Version von 36_LaCrosseGateway.pm eingecheckt, probier bitte mal mit der, ob es damit funktioniert.
Super läuft!
Zitat von: juergs am 18 Januar 2019, 21:45:00
Hallo HCS,
habe noch mal die LGW-Firmware geflasht und habe leider im OLED die Anzeige LGW1.32
aber ein WLAN-Accespoint erscheint nicht.
Könnte auch ein Hardware-Problem sein, weil scheinbar OLED initialisiert und dann resettet.
Versuche mal alles zu Löschen, zu kontrollieren, um wieder ein Konfigurationszustand zu erreichen ...
Binary: D:\fhem\fhem-5.9\contrib\arduino\36_LaCrosseGateway\Release\JeeLink_LaCrosseGateway.bin
Sorry dafür.
Jürgen
Hallo,
ab und zu ist man doch noch über das Verhalten des ESP8266 überrascht:
1.) An GPIO2 habe ich nur 1.29 Volt gemessen.
2.) Möglicherweise hatte das Einlöten der Antenne_2 einen Schluss nach Masse.
3.) Das Flashen unter Windows mit dem NodeMCU-Flasher_x64 brachte ein Erfolg: OLED zeigt "LGW V1.32", kein AP, keine serielle Ausgabe
3.) Dann Flashen mit esptool.exe und vorher "erase_flash" -> kein Erfolg.
4.) Arduino-IDE mit Webserver-Sample geflasht -> geht. AP kommt.
5.) LGW-Version 1.31 mit älterer NodeMCU-Flasher-Version geflasht: AP kommt, BME 280 wird nicht erkannt, mit Mode "thps" nur "0" bei allen Messwerten.
6.) LGW-Version 1.32 mit neuester NodeMCU-Flasher-Version (x64) geflasht: Werte aus 5 übernommen: Meßwerte kommen, außer wieder 0%rH, alle anderen ok.
ESP8266 present :-) Core: 2_3_0 SDK: 1.5.3(aec24ac9) free heap: 17080 Reset: External System -> Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
WiFi -44 dBm Mode: Station Time to connect: 6.5 s
Radio #1 RFM69 868300 kHz data rate: 17241 kbps
Radio #2 RFM69 868300 kHz data rate: 9579 kbps
Radio #3 ---
Radio #4 ---
Radio #5 ---
SHT75 ---
BME680 ---
BME280 ---
BMP280 OK T=21.9 P=1002.9 Calibration: T1:28357 T2:26454 T3:50 P1:37253 P2:-10589 P3:3024 P4:6859 P5:-206 P6:-7 P7:15500 P8:-14600 P9:6000 ADC: T=523200 P=337504
BMP180 ---
DHT22 ---
LM75 ---
SC16IS750 (0x90) ---
SC16IS750 (0x92) ---
MCP23008 ---
OLED OK On
DataPort #1 81
DataPort #2 ---
DataPort #3 ---
Serial-bridge #1 ---
Serial-bridge #2 ---
Soft-bridge ---
Nextion ---
Analog port Disabled ADC=2 U=4294967295 mV (0 ... 0 mV)Zumindest läuft das Ganze wieder ??? ::)
Grüße,
Jürgen
PS: Aha, der vermeintliche BME280 ist als BMP280 erkannt worden ... (Anfängerfehler? Auf dem Breakout steht:
BME280/BMP280)
https://goughlui.com/2018/08/05/note-bosch-sensortec-bmp280-vs-bme280-sensor-confusion/ (https://goughlui.com/2018/08/05/note-bosch-sensortec-bmp280-vs-bme280-sensor-confusion/)
ZitatIf you try to buy a Bosch Sensortec BME280 module on eBay, there's a good chance you will get the lesser BMP280 instead. The reason seems to be sellers that don't know what they are selling, a supply chain that doesn't understand the difference between a BME280 and the BMP280 and a PCB break-out design that is shared between the two types of sensors. As a result, buying these sensors can get quite frustrating, as the sellers often get away with it.
Zitat von: juergs am 19 Januar 2019, 14:17:45
PS: Aha, der vermeintliche BME280 ist als BMP280 erkannt worden ... (Anfängerfehler? Auf dem Breakout steht: BME280/BMP280)
Wollte ich auch gerade anmerken.
Da kann man dann halt keine Feuchte erwarten.
Ich nutze das LGW mit den EC3000 Energymessdosen (ca 20 Stück)
Mir ist aufgefallen das alle EC3k's mit der der ID 6xxx bzw 68xx nicht empfangen werden.
Setze ich den output im Log auf 64z sehe ich die 6xxx und 68xx ids.
13:57:01: Command from frontend: '64z'
13:57:02: EC3000 [68 21 f0 0 0 0 5d 9a 0 0 0 f a9 7e 24 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3d e0 0 0 0 1 7 30 20 2 51 b7 ] CRC:OK ID:6821 TS:64942080 OS:7560602 W:0.00 max-W:0.00 Cons:147.56 Res.:2 Rec.:0 IsOn:0 CRC:f0b8
13:57:02: EC3000 [68 c4 75 f4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9 50 d 1f f7 ] CRC:OK ID:68c4 TS:30196 OS:36864 W:0.00 max-W:0.00 Cons:0.00 Res.:149 Rec.:0 IsOn:0 CRC:f0b8
13:57:03: EC3000 [5d 95 f0 0 0 0 82 c4 0 0 0 7 ad c0 9 4 7d 9 3 4e 1a 6 5d 9b 63 81 6 6e b0 3d e0 0 0 0 1b 8 40 38 c ab 37 ] CRC:OK ID:5d95 TS:64942080 OS:8684228 W:114.90 max-W:230.70 Cons:2049.05 Res.:3 Rec.:0 IsOn:1 CRC:f0b8
13:57:04: EC3000 [7f ed f0 0 0 0 f0 0 0 0 0 0 e7 12 7 0 c 0 c 19 d4 34 4f b7 45 0 a4 50 12 3d e0 0 0 0 9 3d e0 18 0 dd 27 ] CRC:OK ID:7fed TS:64942080 OS:64942080 W:1.20 max-W:1.20 Cons:675.30 Res.:1 Rec.:0 IsOn:1 CRC:f0b8
13:57:04: EC3000 [7f e7 f0 0 0 0 22 2c 0 0 0 5 c7 60 24 0 0 15 d3 49 b 4 c1 95 4c ae 24 b0 a1 3d e0 0 0 0 b 18 a0 10 d b5 27 ] CRC:OK ID:7fe7 TS:64942080 OS:25829932 W:0.00 max-W:558.70 Cons:847.15 Res.:1 Rec.:0 IsOn:0 CRC:f0b8
13:57:04: EC3000 [68 54 76 53 0 0 76 53 0 0 0 0 0 88 99 0 b 0 10 8 89 90 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 48 b ee 17 ] CRC:OK ID:6854 TS:30291 OS:30291 W:1.10 max-W:1.60 Cons:0.01 Res.:4 Rec.:0 IsOn:1 CRC:f0b8
13:57:04: EC3000 [68 37 76 80 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 50 4 c6 47 ] CRC:OK ID:6837 TS:30336 OS:0 W:0.00 max-W:0.00 Cons:0.00 Res.:5 Rec.:0 IsOn:0 CRC:f0b8
13:57:06: EC3000 [7e c3 f0 0 0 0 f0 0 0 0 0 1 6c f2 79 0 4 4 bd 73 f8 17 46 fc 6a 77 57 3e d1 3d e0 0 0 0 3 3d e0 8 9 ab 57 ] CRC:OK ID:7ec3 TS:64942080 OS:64942080 W:0.40 max-W:121.30 Cons:230.34 Res.:0 Rec.:0 IsOn:1 CRC:f0b8
13:57:06: EC3000 [4a 60 f0 0 0 0 48 8a 0 0 0 5 9 28 34 6 85 c 45 85 a0 28 5c f1 85 62 98 62 6c 3d e0 0 0 0 13 34 d0 38 7 a 67 ] CRC:OK ID:4a60 TS:64942080 OS:55396490 W:166.90 max-W:314.10 Cons:1440.21 Res.:3 Rec.:0 IsOn:1 CRC:f0b8
13:57:07: EC3000 [68 21 f0 0 0 0 5d 9a 0 0 0 f a9 7e 24 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3d e0 0 0 0 1 7 30 20 2 51 b7 ] CRC:OK ID:6821 TS:64942080 OS:7560602 W:0.00 max-W:0.00 Cons:147.56 Res.:2 Rec.:0 IsOn:0 CRC:f0b8
13:57:07: EC3000 [68 c4 75 f9 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9 50 d 4d 67 ] CRC:OK ID:68c4 TS:30201 OS:36864 W:0.00 max-W:0.00 Cons:0.00 Res.:149 Rec.:0 IsOn:0 CRC:f0b8
13:57:08: EC3000 [5d 95 f0 0 0 0 82 c9 0 0 0 7 ad c2 46 4 7a 9 3 4e 1c 46 5d 9b 63 81 6 6e b0 3d e0 0 0 0 1b 8 40 38 d 4d e7 ] CRC:OK ID:5d95 TS:64942080 OS:8684233 W:114.60 max-W:230.70 Cons:2049.05 Res.:3 Rec.:0 IsOn:1 CRC:f0b8
13:57:09: EC3000 [7f e7 f0 0 0 0 22 2c 0 0 0 5 c7 60 24 0 0 15 d3 49 b 4 c1 95 4c ae 24 b0 a1 3d e0 0 0 0 b 18 a0 10 d b5 27 ] CRC:OK ID:7fe7 TS:64942080 OS:25829932 W:0.00 max-W:558.70 Cons:847.15 Res.:1 Rec.:0 IsOn:0 CRC:f0b8
13:57:09: EC3000 [68 54 76 58 0 0 76 58 0 0 0 0 0 88 9e 0 c 0 10 8 89 e0 0 c 0 e ae dc 78 8 d8 13 77 b8 49 d7 5d 25 f0 5 71 ] CRC:WRONG ID:6854 TS:9303640 OS:225834584 W:1.20 max-W:1.60 Cons:3517772.00 Res.:210 Rec.:0 IsOn:0 CRC:3b15
13:57:11: EC3000 [4a 60 f0 0 0 0 48 8f 0 0 0 5 9 2b 8b 6 e4 c 45 85 a0 58 5c f1 85 62 98 62 6c 3d e0 0 0 0 13 34 d0 38 9 5a 37 ] CRC:OK ID:4a60 TS:64942080 OS:55396495 W:176.40 max-W:314.10 Cons:1440.21 Res.:3 Rec.:0 IsOn:1 CRC:f0b8
13:57:11: EC3000 [7e c3 f0 0 0 0 f0 0 0 0 0 1 6c f2 7b 0 4 4 bd 73 f8 17 46 fc 6a 77 57 3e d1 3d e0 0 0 0 3 3d e0 8 a 18 57 ] CRC:OK ID:7ec3 TS:64942080 OS:64942080 W:0.40 max-W:121.30 Cons:230.34 Res.:0 Rec.:0 IsOn:1 CRC:f0b8
13:57:12: EC3000 [7f ed f0 0 0 0 f0 0 0 0 0 0 e7 11 ff 0 2 0 2 19 d3 b4 4f b7 45 0 a4 50 12 3d e0 0 0 0 9 3d e0 18 d 1c 67 ] CRC:OK ID:7fed TS:64942080 OS:64942080 W:0.20 max-W:0.20 Cons:675.30 Res.:1 Rec.:0 IsOn:1 CRC:f0b8
13:57:12: EC3000 [68 21 f0 0 0 0 5d 9a 0 0 0 f a9 7e 24 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3d e0 0 0 0 1 7 30 20 2 51 b7 ] CRC:OK ID:6821 TS:64942080 OS:7560602 W:0.00 max-W:0.00 Cons:147.56 Res.:2 Rec.:0 IsOn:0 CRC:f0b8
13:57:12: EC3000 [68 c4 75 fe 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9 50 0 6f c7 ] CRC:OK ID:68c4 TS:30206 OS:36864 W:0.00 max-W:0.00 Cons:0.00 Res.:149 Rec.:0 IsOn:0 CRC:f0b8
13:57:13: EC3000 [5d 95 f0 0 0 0 82 ce 0 0 0 7 ad c4 83 4 7a 9 3 4e 1e 86 5d 9b 63 81 6 6e b0 3d e0 0 0 0 1b 8 40 38 7 9f 27 ] CRC:OK ID:5d95 TS:64942080 OS:8684238 W:114.60 max-W:230.70 Cons:2049.05 Res.:3 Rec.:0 IsOn:1 CRC:f0b8
13:57:14: EC3000 [7f e7 f0 0 0 0 22 2c 0 0 0 5 c7 60 24 0 0 15 d3 49 b 4 c1 95 4c ae 24 b0 a1 3d e0 0 0 0 b 18 a0 10 d b5 27 ] CRC:OK ID:7fe7 TS:64942080 OS:25829932 W:0.00 max-W:558.70 Cons:847.15 Res.:1 Rec.:0 IsOn:0 CRC:f0b8
13:57:14: EC3000 [68 54 76 5d 0 0 76 5d 0 0 0 0 0 88 a4 0 b 0 10 8 8a 40 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 48 c 65 67 ] CRC:OK ID:6854 TS:30301 OS:30301 W:1.10 max-W:1.60 Cons:0.01 Res.:4 Rec.:0 IsOn:1 CRC:f0b8
13:57:14: EC3000 [68 37 76 8a 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 50 9 b6 77 ] CRC:OK ID:6837 TS:30346 OS:0 W:0.00 max-W:0.00 Cons:0.00 Res.:5 Rec.:0 IsOn:0 CRC:f0b8
13:57:16: EC3000 [7e c3 f0 0 0 0 f0 0 0 0 0 1 6c f2 7d 0 4 4 bd 73 f8 17 46 fc 6a 77 57 3e d1 3d e0 0 0 0 3 3d e0 8 e cd 57 ] CRC:OK ID:7ec3 TS:64942080 OS:64942080 W:0.40 max-W:121.30 Cons:230.34 Res.:0 Rec.:0 IsOn:1 CRC:f0b8
13:57:16: EC3000 [4a 60 f0 0 0 0 48 94 0 0 0 5 9 2f 38 7 90 c 45 85 a0 98 5c f1 85 62 98 62 6c 3d e0 0 0 0 13 34 d0 38 d 7f 17 ] CRC:OK ID:4a60 TS:64942080 OS:55396500 W:193.60 max-W:314.10 Cons:1440.21 Res.:3 Rec.:0 IsOn:1 CRC:f0b8
13:57:17: EC3000 [7f ed f0 0 0 0 f0 0 0 0 0 0 e7 12 0 0 2 0 3 19 d3 c4 4f b7 45 0 a4 50 12 3d e0 0 0 0 9 3d e0 18 2 65 b7 ] CRC:OK ID:7fed TS:64942080 OS:64942080 W:0.20 max-W:0.30 Cons:675.30 Res.:1 Rec.:0 IsOn:1 CRC:f0b8
13:57:17: EC3000 [68 21 f0 0 0 0 5d 9a 0 0 0 f a9 7e 24 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3d e0 0 0 0 1 7 30 20 2 51 b7 ] CRC:OK ID:6821 TS:64942080 OS:7560602 W:0.00 max-W:0.00 Cons:147.56 Res.:2 Rec.:0 IsOn:0 CRC:f0b8
13:57:17: EC3000 [68 c4 76 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9 50 0 f7 67 ] CRC:OK ID:68c4 TS:30211 OS:36864 W:0.00 max-W:0.00 Cons:0.00 Res.:149 Rec.:0 IsOn:0 CRC:f0b8
13:57:18: EC3000 [5d 95 f0 0 0 0 82 d3 0 0 0 7 ad c6 c2 4 80 9 3 4e 20 c6 5d 9b 63 81 6 6e b0 3d e0 0 0 0 1b 8 40 38 3 65 17 ] CRC:OK ID:5d95 TS:64942080 OS:8684243 W:115.20 max-W:230.70 Cons:2049.05 Res.:3 Rec.:0 IsOn:1 CRC:f0b8
13:57:19: EC3000 [7f e7 f0 0 0 0 22 2c 0 0 0 5 c7 60 24 0 0 15 d3 49 b 4 c1 95 4c ae 24 b0 a1 3d e0 0 0 0 b 18 a0 10 d b5 27 ] CRC:OK ID:7fe7 TS:64942080 OS:25829932 W:0.00 max-W:558.70 Cons:847.15 Res.:1 Rec.:0 IsOn:0 CRC:f0b8
13:57:19: EC3000 [68 54 76 62 0 0 76 62 0 0 0 0 0 88 aa 0 c 0 10 8 8a a0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 48 9 b9 c7 ] CRC:OK ID:6854 TS:30306 OS:30306 W:1.20 max-W:1.60 Cons:0.01 Res.:4 Rec.:0 IsOn:1 CRC:f0b8
13:57:19: EC3000 [68 37 76 8f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 50 7 8e 27 ] CRC:OK ID:6837 TS:30351 OS:0 W:0.00 max-W:0.00 Cons:0.00 Res.:5 Rec.:0 IsOn:0 CRC:f0b8
13:57:21: Command from frontend: '0z'
5d95,7fed,7fe7,7ec3,4a60 werden an fhem gesendet und funktionieren perfekt.
6821,68c4, 6854, 6837 werden nicht im log angezeigt und nicht an fhem gesendet.
Zitat von: mrixs am 20 Januar 2019, 14:02:41
5d95,7fed,7fe7,7ec3,4a60 werden an fhem gesendet und funktionieren perfekt.
6821,68c4, 6854, 6837 werden nicht im log angezeigt und nicht an fhem gesendet.
Das ist seltsam.
Ich muss mal schauen, ob eine meiner EC3000 mit 68 anfängt, habe einige und mal das Programm studieren, ob es irgendetwas gibt, das die unterdrücken könnte.
Zitat von: mrixs am 20 Januar 2019, 14:02:41
5d95,7fed,7fe7,7ec3,4a60 werden an fhem gesendet und funktionieren perfekt.
6821,68c4, 6854, 6837 werden nicht im log angezeigt und nicht an fhem gesendet.
Schade, habe keine mit 6xxx
Ich habe nur: 75C4, 7AE4, 7BD8, 7E43, 972F und 9EE4 und die gehen auch alle.
Tauchen die 6xxx im WebFrontend vom LGW in der oberen Liste "
LGW to FHEM" auf?
Also in der Art:
13:21:18: OK 22 126 67 3 222 240 0 3 222 240 0 0 5 173 14 0 2 0 4 1 0 [
7E 43 F0 00 00 00 F0 00 00 00 00 0F D1 9D D4 00 02 00 04 02 03 80 53 D2 05 61 30 52 9F 3D E0 00 00 00 04 3D E0 18 0F 64 07]
aber an der markierten Stelle z.B.: 68 21
Ist auch mindestens eine der 6xxx sicher in der Reichweite vom LGW?Kann es nicht sein, der 64z hat sie ja gesehen.
Bin gerade etwas ratlos, weil ich in der LGW-Firmware nichts sehe, was die unterdrücken könnte.
Zitat von: HCS am 23 Januar 2019, 13:37:21
Tauchen die 6xxx im WebFrontend vom LGW in der oberen Liste "LGW to FHEM" auf?
Also in der Art:
13:21:18: OK 22 126 67 3 222 240 0 3 222 240 0 0 5 173 14 0 2 0 4 1 0 [7E 43 F0 00 00 00 F0 00 00 00 00 0F D1 9D D4 00 02 00 04 02 03 80 53 D2 05 61 30 52 9F 3D E0 00 00 00 04 3D E0 18 0F 64 07]
aber an der markierten Stelle z.B.: 68 21
21:49:56: OK 22 127 231 3 222 240 0 1 138 150 80 0 12 238 69 0 0 21 211 1 0 [7F E7 F0 00 00 00 96 50 00 00 00 05 D6 AF 20 00 00 15 D3 1E C6 64 B5 05 4B 1D 44 C1 95 3D E0 00 00 00 0B 18 A0 10 07 FF 47]
21:49:56: OK 22 127 237 3 222 240 0 3 222 240 0 0 10 79 132 0 32 0 37 1 0 [7F ED F0 00 00 00 F0 00 00 00 00 00 FE 3B 34 00 20 00 25 58 C6 74 4F B7 45 00 A4 50 12 3D E0 00 00 00 09 3D E0 18 01 04 C7]
21:49:56: OK 22 93 149 3 222 240 0 0 134 71 119 0 31 71 231 0 2 9 3 3 0 [5D 95 F0 00 00 00 47 77 00 00 00 07 E3 21 42 00 02 09 03 5D 76 36 60 51 65 D9 B6 38 10 3D E0 00 00 00 1B 08 60 38 0F 85 57]
21:49:56: OK 22 127 231 3 222 240 0 1 138 150 80 0 12 238 69 0 0 21 211 1 0 [7F E7 F0 00 00 00 96 50 00 00 00 05 D6 AF 20 00 00 15 D3 1E C6 64 B5 05 4B 1D 44 C1 95 3D E0 00 00 00 0B 18 A0 10 07 FF 47]
21:49:56: OK 22 126 195 3 222 240 0 3 222 240 0 0 3 137 120 0 4 4 189 0 0 [7E C3 F0 00 00 00 F0 00 00 00 00 01 BD 34 E4 00 04 04 BD 4D E4 77 B2 CD 7B 29 47 46 FC 3D E0 00 00 00 03 3D E0 08 07 7E 87]
21:49:56: OK 22 74 96 3 222 240 0 3 79 13 65 0 22 3 171 7 159 12 69 3 0 [4A 60 F0 00 00 00 0D 41 00 00 00 05 93 98 B8 07 9F 0C 45 5D 19 67 90 96 88 E4 F8 5C F1 3D E0 00 00 00 13 34 F0 38 09 C2 07]
21:49:56: OK 22 127 237 3 222 240 0 3 222 240 0 0 10 79 132 0 31 0 37 1 0 [7F ED F0 00 00 00 F0 00 00 00 00 00 FE 3B 43 00 1F 00 25 58 C6 84 4F B7 45 00 A4 50 12 3D E0 00 00 00 09 3D E0 18 04 95 B7]
21:49:56: OK 22 93 149 3 222 240 0 0 134 71 124 0 31 71 231 0 2 9 3 3 0 [5D 95 F0 00 00 00 47 7C 00 00 00 07 E3 21 43 00 02 09 03 5D 76 36 60 51 65 D9 B6 38 10 3D E0 00 00 00 1B 08 60 38 00 80 97]
21:49:56: OK 22 127 231 3 222 240 0 1 138 150 80 0 12 238 69 0 0 21 211 1 0 [7F E7 F0 00 00 00 96 50 00 00 00 05 D6 AF 20 00 00 15 D3 1E C6 64 B5 05 4B 1D 44 C1 95 3D E0 00 00 00 0B 18 A0 10 07 FF 47]
21:49:56: OK 22 126 195 3 222 240 0 3 222 240 0 0 3 137 120 2 47 4 189 0 0 [7E C3 F0 00 00 00 F0 00 00 00 00 01 BD 35 39 02 2F 04 BD 4D E4 C7 B2 CD 7B 29 47 46 FC 3D E0 00 00 00 03 3D E0 08 0F BA C7]
21:49:56: OK 22 74 96 3 222 240 0 3 79 13 70 0 22 3 171 7 170 12 69 3 0 [4A 60 F0 00 00 00 0D 46 00 00 00 05 93 9C 89 07 AA 0C 45 5D 1D 37 90 96 88 E4 F8 5C F1 3D E0 00 00 00 13 34 F0 38 0D DA 77]
21:49:57: OK 22 74 96 3 222 240 0 3 84 78 245 0 22 35 174 7 186 12 69 3 0 [4A 60 F0 00 00 00 4E F5 00 00 00 07 55 C4 45 07 BA 0C 45 59 D4 18 65 C9 85 1C 58 9A A9 3D E0 00 00 00 13 35 40 38 0B 23 87]
21:50:00: OK 22 127 231 3 222 240 0 1 139 234 140 0 12 241 119 0 0 21 211 1 0 [7F E7 F0 00 00 00 EA 8C 00 00 00 06 03 A2 FD 00 00 15 D3 15 53 F4 B7 7D 4B 96 04 B1 54 3D E0 00 00 00 0B 18 B0 10 06 62 D7]
21:50:01: OK 22 126 195 3 222 240 0 3 222 240 0 0 3 151 44 4 111 4 189 0 0 [7E C3 F0 00 00 00 F0 00 00 00 00 02 7D DB EE 04 6F 04 BD 4C 32 56 FC 08 70 39 07 24 32 3D E0 00 00 00 03 3D E0 08 03 22 37]
21:50:02: OK 22 74 96 3 222 240 0 3 84 78 250 0 22 35 174 7 186 12 69 3 0 [4A 60 F0 00 00 00 4E FA 00 00 00 07 55 C8 24 07 BA 0C 45 59 D7 F8 65 C9 85 1C 58 9A A9 3D E0 00 00 00 13 35 40 38 0A 46 67]
21:50:03: OK 22 93 149 3 222 240 0 0 139 137 53 0 31 83 156 0 2 9 3 3 0 [5D 95 F0 00 00 00 89 35 00 00 00 08 87 C0 5B 00 02 09 03 5A 8A D6 5B 5A 68 7D 26 DB E6 3D E0 00 00 00 1B 08 B0 38 0C 3D B7]
21:50:06: OK 22 127 231 3 222 240 0 1 139 234 140 0 12 241 119 0 0 21 211 1 0 [7F E7 F0 00 00 00 EA 8C 00 00 00 06 03 A2 FD 00 00 15 D3 15 53 F4 B7 7D 4B 96 04 B1 54 3D E0 00 00 00 0B 18 B0 10 06 62 D7]
21:50:07: OK 22 74 96 3 222 240 0 3 84 78 255 0 22 35 174 7 189 12 69 3 0 [4A 60 F0 00 00 00 4E FF 00 00 00 07 55 CC 01 07 BD 0C 45 59 DB C8 65 C9 85 1C 58 9A A9 3D E0 00 00 00 13 35 40 38 02 07 C7]
21:50:08: OK 22 93 149 3 222 240 0 0 139 137 58 0 31 83 156 0 2 9 3 3 0 [5D 95 F0 00 00 00 89 3A 00 00 00 08 87 C0 5C 00 02 09 03 5A 8A D6 5B 5A 68 7D 26 DB E6 3D E0 00 00 00 1B 08 B0 38 04 E1 97]
21:50:11: OK 22 127 231 3 222 240 0 1 139 234 140 0 12 241 119 0 0 21 211 1 0 [7F E7 F0 00 00 00 EA 8C 00 00 00 06 03 A2 FD 00 00 15 D3 15 53 F4 B7 7D 4B 96 04 B1 54 3D E0 00 00 00 0B 18 B0 10 06 62 D7]
21:50:11: OK 22 126 195 3 222 240 0 3 222 240 0 0 3 151 44 4 135 4 189 0 0 [7E C3 F0 00 00 00 F0 00 00 00 00 02 7D E0 68 04 87 04 BD 4C 36 D6 FC 08 70 39 07 24 32 3D E0 00 00 00 03 3D E0 08 04 B8 E7]
21:50:12: OK 22 74 96 3 222 240 0 3 84 79 4 0 22 35 175 7 185 12 69 3 0 [4A 60 F0 00 00 00 4F 04 00 00 00 07 55 CF DE 07 B9 0C 45 59 DF A8 65 C9 85 1C 58 9A A9 3D E0 00 00 00 13 35 40 38 00 12 27]
21:50:13: OK 22 93 149 3 222 240 0 0 139 137 63 0 31 83 156 0 2 9 3 3 0 [5D 95 F0 00 00 00 89 3F 00 00 00 08 87 C0 5D 00 02 09 03 5A 8A D6 5B 5A 68 7D 26 DB E6 3D E0 00 00 00 1B 08 B0 38 0E 77 87]
21:50:16: OK 22 127 231 3 222 240 0 1 139 234 140 0 12 241 119 0 0 21 211 1 0 [7F E7 F0 00 00 00 EA 8C 00 00 00 06 03 A2 FD 00 00 15 D3 15 53 F4 B7 7D 4B 96 04 B1 54 3D E0 00 00 00 0B 18 B0 10 06 62 D7]
21:50:16: OK 22 126 195 3 222 240 0 3 222 240 0 0 3 151 44 4 143 4 189 0 0 [7E C3 F0 00 00 00 F0 00 00 00 00 02 7D E2 AF 04 8F 04 BD 4C 39 16 FC 08 70 39 07 24 32 3D E0 00 00 00 03 3D E0 08 09 1B D7]
21:50:17: OK 22 74 96 3 222 240 0 3 84 79 9 0 22 35 175 7 176 12 69 3 0 [4A 60 F0 00 00 00 4F 09 00 00 00 07 55 D3 B9 07 B0 0C 45 59 E3 88 65 C9 85 1C 58 9A A9 3D E0 00 00 00 13 35 40 38 07 4B C7]
21:50:18: OK 22 93 149 3 222 240 0 0 139 137 68 0 31 83 156 0 2 9 3 3 0 [5D 95 F0 00 00 00 89 44 00 00 00 08 87 C0 5E 00 02 09 03 5A 8A D6 5B 5A 68 7D 26 DB E6 3D E0 00 00 00 1B 08 B0 38 01 35 87]
21:50:20: OK 22 127 231 3 222 240 0 1 139 234 140 0 12 241 119 0 0 21 211 1 0 [7F E7 F0 00 00 00 EA 8C 00 00 00 06 03 A2 FD 00 00 15 D3 15 53 F4 B7 7D 4B 96 04 B1 54 3D E0 00 00 00 0B 18 B0 10 06 62 D7]
21:50:21: OK 22 126 195 3 222 240 0 3 222 240 0 0 3 151 44 4 133 4 189 0 0 [7E C3 F0 00 00 00 F0 00 00 00 00 02 7D E4 F3 04 85 04 BD 4C 3B 56 FC 08 70 39 07 24 32 3D E0 00 00 00 03 3D E0 08 0D E1 67]
Die 68xx tauchen oben nicht auf. Deswegen hab ich die auch alle als defekt nach dem Umzug aussortiert. Bis mir aufgefallen ist das alle mit 68xx Id's sind. Erst wenn ich auf 64z umstelle tauchen die 68xx unten mit auf.
Ich bin leider kein Programmierer meine Kenntnisse sind 20Jahre alt noch aus Schulzeiten.
Was ist der Unterschied in der normalen Ausgabe und die '64z' Ausgabe? Kann man Testweise beide aktivieren?
In EC3000.cpp:
in der Funktion EC3000::GetFhemDataString(byte *payload) wird payload[1] auf 0x00 geprüft, das ist aber bei den 68xx IDs 0x00.
Hab die Prüfung nur auf payload[0] gelassen und die 68er gehen.
Warum die verschlüsselte payload0 und payload1 auf 0x00 geprüft werden weiß ich nicht.
Zitat von: mrixs am 25 Januar 2019, 23:00:56
In EC3000.cpp:
in der Funktion EC3000::GetFhemDataString(byte *payload) wird payload[1] auf 0x00 geprüft, das ist aber bei den 68xx IDs 0x00.
Hab die Prüfung nur auf payload[0] gelassen und die 68er gehen.
Warum die verschlüsselte payload0 und payload1 auf 0x00 geprüft werden weiß ich nicht.
Cool, dass Du das herausgefunden hast.
Die Prüfung soll verhindern, dass empfangene Daten, die auf der HF-Strecke so gekippt sind, dass die Prüfsumme trotzdem stimmt, an FHEM weitergegeben werden.
Eigentlich soll geprüft werden, ob der Sensor eine ID hat, aber an der Stelle geht das so nicht, weil, wie Du richtig erkannt hast, das noch die verschlüsselten Bytes sind und die bei den entschlüsselten "6ern" wohl Null sind.
Ich mache in den nächsten Tagen eine LGW-1.33-Beta, in der ich die Prüfung ändere (gehört eigentlich in die DecodeFrame nach DescramblePayload.
Hallo,
kurze Frage, ich hab jetzt einen BME680 angeschlossen, der wurde auch sauber erkannt. Wie bekomme ich die Werte jetzt in FHEM? Ich hab mein LGW seriell angebunden über die LAN Brücke. Also kein WLAN (V1.32).
In dem LGW settings attribut sehe ich: "(1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 r:9579) + (3=RFM69 f:868300 r:20000) + BME680 {IP=192.168.0.48}]"
Das mit dem autocreate wie im Wiki beschrieben funktioniert bei mir irgendwie nicht.
/Daniel
Zitat von: ext23 am 24 Februar 2019, 17:27:00
Das mit dem autocreate wie im Wiki beschrieben funktioniert bei mir irgendwie nicht.
set <LGW> LaCrossePairForSec 600sollte funktionieren.
Gruß Peter
Mhh leider auch mit 600 nicht anstelle von 120.
Muss ich nochmal alles neu starten.
Ignore_battery
Gesendet von meinem SM-G950F mit Tapatalk
OK dann geht es. Misst, der Parameter klang so als wenn man ihn weglassen kann...
Danke!
/Daniel
Nicht alles, wo ignore drin vorkommt, sollte man ignorieren ;D
stimmt, da war was (https://forum.fhem.de/index.php/topic,43672.msg870233/topicseen.html#msg870233) und im Wiki (https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Sensoren.2FAktoren_anlegen) steht es auch.
Gruß Peter
Wenn ich gerade mal hier bin.
Ich habe schon seit einiger Zeit eine LGW 1.33 Beta, die ich aber noch nicht veröffentliche, weil ich auf einem meiner LGWs seltsame reboots alle paar Tage habe. Das ist natürlich schwer und nur langwierig zu finden. Bin nicht sicher, ob der Umstieg auf den Core 2.4.2 da was verurscaht.
Aber wenn es jemand gerne Bata-testen will (z.B. PeMue den BH1750) dann hänge ich es hier mal als inoffizielle Version rein.
Die wesentlichen Änderungen:
- Die Entwicklungsumgebung wurde auf Core 2.4.2 umgestellt
- Konfiguration für das (bisher fix 10 Sekunden) Sende-Intervall der internen Sensoren
Auf der setup-page kann das Sendeintervall (Anzahl Sekunden) eingetragen werden.
Um es komplett zu deaktivieren kann man "off" eintragen
-Das Nextion hat beim Luftdruck immmer 2 Dezimalstellen angezeigt, egal was man im Setup bei "Pressure with decimals" eingetragen hatte.
Das richtet sich jetzt nach dem Setting "Pressure with decimals"
- Der BH1750 wird nun vom LGW unterstützt.
- EC3000 mit IDs, die mit 6 beginnen, haben nicht funktioniert
Zitat von: HCS am 24 Februar 2019, 19:03:35
Aber wenn es jemand gerne Beta-testen will (z.B. PeMue den BH1750) dann hänge ich es hier mal als inoffizielle Version rein.
Gerne, kann aber ein paar Tage dauern.
Zitat von: HCS am 24 Februar 2019, 19:03:35
Die wesentlichen Änderungen:
- Die Entwicklungsumgebung wurde auf Core 2.4.2 umgestellt
Warum gehst Du nicht gleich auf die 2.5.0? Mein Eindruck ist, dass wenn es vorher einige beta-Versionen gab, dass die Stabilität besser ist (ist aber seeehr subjektiv und die Meinung eines Hardware-Fuzzies, der wenig Ahnung vom Programmieren hat ;D).
Gruß Peter
Zitat von: PeMue am 24 Februar 2019, 19:25:00
Warum gehst Du nicht gleich auf die 2.5.0? Mein Eindruck ist, dass wenn es vorher einige beta-Versionen gab, dass die Stabilität besser ist (ist aber seeehr subjektiv und die Meinung eines Hardware-Fuzzies, der wenig Ahnung vom Programmieren hat ;D).
Mein Eindruck ist, dass es immer gleich viel Probleme in den Cores gibt, nur jedes mal andere :)
Als ich auf die 2.4.2 gegangen bin, war die 2.5.0 noch nicht released und ich habe die letzten 18 Tage nicht mehr geschaut.
Aber das mache ich jetzt gleich mal.
Dann stelle ich aber in Kürze die gegen 2.5.0 compilierte Version rein.
Kurze Frage zum BME680, also ich meine ich wohne nun in Berlin, da ist die Luft vermutlich immer schei**e, aber wenn ich Fenster offen hatte geht es auf 10kOhm, ist es aller Puma Käfig bin ich bei 6,5kOhm. Das ist so der normale Bereich ja?
Hat sich schon jemand eine Formel gebastelt, das zusammen mit Temp und Luftfeuchtigkeit einigermaßen sinnvoll zu wandeln?
/Daniel
Zitat von: PeMue am 24 Februar 2019, 19:25:00
Warum gehst Du nicht gleich auf die 2.5.0?
gesagt, getan :)
Angehängt die angekündigte V1.33 Beta zum Testen.
Die aktuelle Version mal vorher wegsichern, dass es notfalls einen Rückweg gibt.
- Die Entwicklungsumgebung wurde auf Core 2.5.0 umgestellt
- Konfiguration für das (bisher fix 10 Sekunden) Sende-Intervall der internen Sensoren
Auf der setup-page kann das Sendeintervall (Anzahl Sekunden) eingetragen werden.
Um es komplett zu deaktivieren kann man "off" eintragen
-Das Nextion hat beim Luftdruck immmer 2 Dezimalstellen angezeigt, egal was man im Setup bei "Pressure with decimals" eingetragen hatte.
Das richtet sich jetzt nach dem Setting "Pressure with decimals"
- Der BH1750 wird nun vom LGW unterstützt.
- EC3000 mit IDs, die mit 6 beginnen, haben nicht funktioniert
Edit1: aktualisiert auf V1.33 Beta 2
Zitat von: ext23 am 25 Februar 2019, 18:35:51
Hat sich schon jemand eine Formel gebastelt, das zusammen mit Temp und Luftfeuchtigkeit einigermaßen sinnvoll zu wandeln?
Mein letzter Stand war, dass Bosch schlicht nicht verraten will, wie man das rechnet.
Kannst ja aber mal forschen, ob es inzwischen was gibt (also außer der BSEC Software)
Ja richtig, das habe ich auch gelesen. Aber hätt ja sein können das sich da schon jemand etwas gebastelt hat, was ungefähr passt.
Scheint ja doch recht aufwendig zu sein. Es hat sicher schon jemand versucht, die BSEC Software mit ein paar Standard Werten zu füttern um Rückschlüsse auf die Formel zu ziehen.
/Daniel
Zitat von: HCS am 26 Februar 2019, 08:57:56
- Konfiguration für das (bisher fix 10 Sekunden) Sende-Intervall der internen Sensoren
Auf der setup-page kann das Sendeintervall (Anzahl Sekunden) eingetragen werden.
0 mit IDs, die mit 6 beginnen, haben nicht funktioniert
Danke für das Umsetzen dieses Wunsches. Scheinbar gibt es noch einen "Minuten-Bug". Bis 59sec ist alles sauber, ab 60sec kommen keine Pakete mehr vom internen Sensor. Kann das jemand reproduzieren?
Zitat von: kpwg am 26 Februar 2019, 11:31:18
Scheinbar gibt es noch einen "Minuten-Bug". Bis 59sec ist alles sauber, ab 60sec kommen keine Pakete mehr vom internen Sensor. Kann das jemand reproduzieren?
Ist bei mir nicht so. Habe einen BME280 dran und bekomme nach Uptime 1Tg. 1Std. 12Min. 25Sek immer noch alle 10 Sekunden, wie konfiguriert, die Werte.
Welcher Sensor?
Was als sensors: ID: eingetragen?
Was als sensors: Interval eingetragen?
Auf der Log-Page: als Filter
ok wseintragen, gehen da noch Daten raus?
Mist, ich hab das zu "diffus" beschrieben ???
Ich habe einen LGW mit 2x RFM69, BMP180 und DHT22. Sensor ID des Internen ist 01. Mit 00 tritt der Effekt genauso auf.
Mit der 1.33 von heute früh läuft alles gut, nur wenn ich den Intervall von voreingestellten 10sec über 59sec stelle, kommen keine Daten des internen Sensors in FHEM (aktuellster Stand) an. Ein empfangener TX29DTH-IT ist davon nicht betroffen.
Auf der Log-Seite kommen Pakete korrekt an:
12:56:16: OK WS 1 4 4 215 30 255 255 255 255 255 255 255 255 0 4 12 255 255 255 255 255 255 255 255 255
@ext23:
ja, hier:
https://forum.fhem.de/index.php/topic,96241.300.html
Zitat von: kpwg am 26 Februar 2019, 12:55:34
nur wenn ich den Intervall von voreingestellten 10sec über 59sec stelle, kommen keine Daten des internen Sensors in FHEM (aktuellster Stand) an.
Jetzt habe sogar ich das Problem verstanden ;D
Ich schaue es mir an.
Habe den Anhang im Beitrag weiter oben auf Beta 2 aktualisiert.
Nun sollte es gehen.
120 Sekunden eingestellt:
13:47:09: OK WS 211 4 4 170 45 255 255 255 255 255 255 255 255 0 40 112 0 113 188 255 255 255 255 255 255
13:49:10: OK WS 211 4 4 170 45 255 255 255 255 255 255 255 255 0 40 111 0 114 13 255 255 255 255 255 255
13:51:10: OK WS 211 4 4 170 45 255 255 255 255 255 255 255 255 0 40 112 0 114 13 255 255 255 255 255 255
13:53:10: OK WS 211 4 4 170 45 255 255 255 255 255 255 255 255 0 40 112 0 113 188 255 255 255 255 255 255
13:55:10: OK WS 211 4 4 170 45 255 255 255 255 255 255 255 255 0 40 112 0 114 13 255 255 255 255 255 255
13:57:10: OK WS 211 4 4 170 45 255 255 255 255 255 255 255 255 0 40 112 0 114 13 255 255 255 255 255 255
13:59:10: OK WS 211 4 4 170 45 255 255 255 255 255 255 255 255 0 40 111 0 114 13 255 255 255 255 255 255
600 Sekunden eingestellt:
14:09:44: OK WS 211 4 4 170 45 255 255 255 255 255 255 255 255 0 40 109 0 114 13 255 255 255 255 255 255
14:19:45: OK WS 211 4 4 171 45 255 255 255 255 255 255 255 255 0 40 108 0 114 13 255 255 255 255 255 255
14:29:44: OK WS 211 4 4 171 45 255 255 255 255 255 255 255 255 0 40 108 0 113 188 255 255 255 255 255 255
14:39:44: OK WS 211 4 4 171 45 255 255 255 255 255 255 255 255 0 40 107 0 114 13 255 255 255 255 255 255
14:49:44: OK WS 211 4 4 171 45 255 255 255 255 255 255 255 255 0 40 105 0 113 188 255 255 255 255 255 255
5 Sekunden eingestellt:
14:59:37: OK WS 211 4 4 171 45 255 255 255 255 255 255 255 255 0 40 104 0 114 13 255 255 255 255 255 255
14:59:42: OK WS 211 4 4 171 45 255 255 255 255 255 255 255 255 0 40 104 0 114 13 255 255 255 255 255 255
14:59:47: OK WS 211 4 4 171 45 255 255 255 255 255 255 255 255 0 40 104 0 114 13 255 255 255 255 255 255
14:59:52: OK WS 211 4 4 171 45 255 255 255 255 255 255 255 255 0 40 104 0 114 13 255 255 255 255 255 255
14:59:57: OK WS 211 4 4 171 45 255 255 255 255 255 255 255 255 0 40 104 0 114 13 255 255 255 255 255 255
15:00:02: OK WS 211 4 4 171 45 255 255 255 255 255 255 255 255 0 40 104 0 114 13 255 255 255 255 255 255
Zitat von: HCS am 26 Februar 2019, 08:57:56
gesagt, getan :)
- Der BH1750 wird nun vom LGW unterstützt.
Ups, jetzt muss ich irgendwie einen BH1750 an mein LGW dranschrauben oder mein nanoLGW fertigbestücken :o :o :o
Gruß Peter
Zitat von: HCS am 26 Februar 2019, 15:01:37
Habe den Anhang im Beitrag weiter oben auf Beta 2 aktualisiert.
Nun sollte es gehen.
Kann ich bestätigen- die neue Version lässt sich nun wie gewünscht einstellen.
Hi zusammen,
habe auch ein LCG mit 2 RFMs und aktuell PC301 eingebunden.
Würde nun auch gerne einen Temperatursensor (DHT-29) einbinden.
Allerdings stehe ich da etwas auf dem Schlauch:
Internals:
CFGFN FHEM/wetter.cfg
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF 192.168.x.x:81
DeviceName 192.168.x.x:81
FD 13
FUUID 5c5dae91-f33f-d748-735b-3afd4ad2e8891cf9
NAME myJeeLink
NR 183
PARTIAL
RAWMSG OK VALUES LGW 1302972 UpTimeSeconds=1830,UpTimeText=0Tg. 0Std. 30Min. 30Sek. ,WIFI=HA,ReceivedFrames=20,FramesPerMinute=2,RSSI=-74,FreeHeap=18544,LD.Min=0.15,LD.Avg=0.16,LD.Max=0.82,OLED=none
STATE initialized
TYPE JeeLink
initMessages
model LaCrosseITPlusReader.Gateway.1.32
myJeeLink_MSGCNT 24
myJeeLink_TIME 2019-04-26 08:28:30
settings (1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 r:9579) {IP=192.168.178.81}
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:
2019-04-26 08:28:30 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 1,868950,120i v
timeout 120,30
Ich hatte mal eine WS1600 und die über den 2 RFM angeschlossen, was ich nämlich nicht verstehe ist, dass die Settings die config des 2. RFM anzeigt, obwohl ich im init ja meiner Meinung nach keine config für den 2. RFM drin habe?
Ein LaCrossePairForSec bringt derzeit noch keinen Erfolg.
Kann mir jemand bitte einen Denkanstoß geben?
Müsste ich das initCommands erweitern, oder wird der 2. da nicht definiert einfach im Standard aktiviert und das sollte gehen?
Danke & Gruß,
Tobi
Zitat von: onkel-tobi am 26 April 2019, 08:39:35
habe auch ein LCG mit 2 RFMs und aktuell PC301 eingebunden.
Würde nun auch gerne einen Temperatursensor (DHT-29) einbinden.
Meiner Meinung nach gibt es keinen DHT-29. Meinst Du einen DHT22?
Zitat von: onkel-tobi am 26 April 2019, 08:39:35
was ich nämlich nicht verstehe ist, dass die Settings die config des 2. RFM anzeigt, obwohl ich im init ja meiner Meinung nach keine config für den 2. RFM drin habe?
Die Konfiguration zeigt alle Hardware an, die erkannt wurde, egal ob sie mit den Default-Einstellungen läuft oder über die initCommands auf irgend etwas abweichendes gesetzt wurde. Die Hardware ist vorhanden, egal ob und wie Du sie konfigurierst.
Zitat von: HCS am 26 April 2019, 08:48:08
Meiner Meinung nach gibt es keinen DHT-29. Meinst Du einen DHT22?
Sorry, meinte den TX29 DTH-IT.
Dann werde ich es mit Anpassung des initCommands noch mal probieren.
Gesendet von iPhone mit Tapatalk
Zitat von: onkel-tobi am 26 April 2019, 09:03:17
Dann werde ich es mit Anpassung des initCommands noch mal probieren.
Das wäre für Deinen Fall richtig:
initCommands 1,868950,120i 17241#2r vUnd falls der Sensor die Batterien schon längere Zeit drin hat, das ignore_battery beim LaCrossePairForSec nicht vergessen.
Hi,
leider funktioniert das nicht.
Um auszuschließen, dass mein altes Gerät nicht kaputt ist, habe ich mir auch noch einen neuen TX29DHT-IT bestellt.
Aber auch mit dem kein Erfolg :(
Hat noch wer eine Idee?
Hier noch das list für das lacrosse GW (jeelink def hab ich ja oben in meinem post schon drin):
Internals:
CFGFN FHEM/wetter.cfg
DEF LGW 1302972
FUUID 5c5dae92-f33f-d748-df20-52a0eb715fd69316
ID LGW_1302972
IODev myJeeLink
LASTInputDev myJeeLink
MSGCNT 2818
NAME KeyValueProtocol_LGW_1302972
NR 187
STATE Initialized
TYPE KeyValueProtocol
model LGW
myJeeLink_MSGCNT 2818
myJeeLink_RAWMSG OK VALUES LGW 1302972 UpTimeSeconds=2820,UpTimeText=0Tg. 0Std. 47Min. 0Sek. ,WIFI=HA,ReceivedFrames=64,FramesPerMinute=2,RSSI=-73,FreeHeap=20048,LD.Min=0.15,LD.Avg=0.16,LD.Max=14.14,OLED=none
myJeeLink_TIME 2019-05-02 21:36:33
READINGS:
2019-04-26 07:46:00 ChipID 1302972
2019-05-02 21:36:33 FramesPerMinute 2
2019-05-02 21:36:33 FreeHeap 20048
2019-05-02 21:36:33 LD.Avg 0.16
2019-05-02 21:36:33 LD.Max 14.14
2019-05-02 21:36:33 LD.Min 0.15
2019-05-02 21:22:03 MacAddress 5C:CF:7F:13:E1:BC
2019-05-02 21:36:33 OLED none
2019-05-02 21:36:33 RSSI -73
2019-05-02 21:36:33 ReceivedFrames 64
2019-05-02 21:36:33 UpTimeSeconds 2820
2019-05-02 21:36:33 UpTimeText 0Tg. 0Std. 47Min. 0Sek.
2019-05-02 21:22:03 Version 1.32
2019-05-02 21:36:33 WIFI HA
Attributes:
IODev myJeeLink
event-on-change-reading .*
room KeyValueProtocol
Danke & Gruß,
Tobi
Zitat von: onkel-tobi am 02 Mai 2019, 21:38:10
leider funktioniert das nicht.
Dann müsste ich mal die hardware-page und die log-page vom LGW sehen.
Und es wäre sinnvoll, das LGW per LaCrosseGateway device in FHEM anzubinden anstatt per JeeLink device.
Zitat von: HCS am 02 Mai 2019, 21:44:37
Dann müsste ich mal die hardware-page und die log-page vom LGW sehen.
log:
21:46:11: OK VALUES LGW 1302972 UpTimeSeconds=3360,UpTimeText=0Tg. 0Std. 56Min. 0Sek. ,WIFI=SSID,ReceivedFrames=72,FramesPerMinute=0,RSSI=-82,FreeHeap=19776,LD.Min=0.16,LD.Avg=0.16,LD.Max=1.01,OLED=none
21:46:11: OK 24 1 4 6 126 229 1 0 3 172 154 [01 04 06 7E E5 01 00 03 AC 9A 93 99]
21:46:11: OK 24 3 4 6 151 34 1 0 3 127 95 [03 04 06 97 22 01 00 03 7F 5F 34 79]
21:46:11: OK VALUES LGW 1302972 UpTimeSeconds=3390,UpTimeText=0Tg. 0Std. 56Min. 30Sek. ,WIFI=SSID,ReceivedFrames=74,FramesPerMinute=2,RSSI=-82,FreeHeap=19312,LD.Min=0.15,LD.Avg=0.16,LD.Max=0.84,OLED=none
21:46:33: OK VALUES LGW 1302972 UpTimeSeconds=3420,UpTimeText=0Tg. 0Std. 57Min. 0Sek. ,WIFI=SSID,ReceivedFrames=74,FramesPerMinute=2,RSSI=-76,FreeHeap=19680,LD.Min=0.15,LD.Avg=0.16,LD.Max=16.79,OLED=none
21:47:03: OK VALUES LGW 1302972 UpTimeSeconds=3450,UpTimeText=0Tg. 0Std. 57Min. 30Sek. ,WIFI=SSID,ReceivedFrames=74,FramesPerMinute=0,RSSI=-79,FreeHeap=19680,LD.Min=0.15,LD.Avg=0.16,LD.Max=14.68,OLED=noneHardware screenshot anbei.
Die config via jeelink habe ich schon ewig. Möchte mir ungerne meine PCA301 abschießen, aber das würde ich mir dann auch entsprechend mal anschauen.
Update:
Habe nun mal das jeelink device gelöscht und das LGW entsprechend definiert:
Internals:
CFGFN FHEM/wetter.cfg
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol:CapacitiveLevel
DEF 192.168.x.x:81
DeviceName 192.168.x.x:81
FD 84
FUUID 5ccd7b9e-f33f-daf3-3017-03db5a506ee8111e
NAME myLaCrosseGateway
NR 192
NTFY_ORDER 50-myLaCrosseGateway
PARTIAL
RAWMSG OK VALUES LGW 1302972 UpTimeSeconds=143649,UpTimeText=1Tg. 15Std. 54Min. 9Sek. ,WIFI=HA,ReceivedFrames=1985,FramesPerMinute=0,RSSI=-75,FreeHeap=20048,LD.Min=0.15,LD.Avg=0.16,LD.Max=12.91,OLED=none
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.32
myLaCrosseGateway_MSGCNT 41
myLaCrosseGateway_TIME 2019-05-04 13:59:35
nextOpenDelay 2
settings (1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 r:17241) {IP=192.168.178.81}]
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
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2019-05-04 13:59:35 state initialized
helper:
Attributes:
initCommands 6631#1r 17241#2r v
timeout 120,30
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE] 2>&1
verbose 5Das gute ist, die PC301 funktionieren wohl weiterhin, ohne dass ich etwas ändern musste. Allerdings bekomme ich die DHTs immer noch nicht gekoppelt :(
das debug log des LGW:
13:58:29: DataPort: #81 Client connected, IP=192.168.x.x Port=60368
13:58:29: DataPort: #81 received 'v '
13:58:29: DataPort: #81 received '6631#1r '
13:58:29: DataPort: #81 received '17241#2r v 'Gruß,
Tobi
Zitat von: onkel-tobi am 02 Mai 2019, 21:48:58
settings (1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 r:17241) {IP=192.168.178.81}]
Der zweite RFM69 ist richtig initialisiert.
Im Log (das recht kurz ist) taucht aber nichts vom TX29DTH auf.
Da die Initialisierung stimmt, gibt es eigentlich nur zwei plausible Gründe:
- Der Sensor sendet nicht (aber unwahrscheinlich, da Du ja zwei hast.)
- Der RFM69 ist defekt
Warum hast Du die PCA301-Initialisirung rausgenommen und kein "1,868950,120i" mehr drin?
Das mit dem defekten Radio kannst Du aber mal testen, indem Du das erste Radio für den TX29 verwendest.
initCommands 17241#1r v
Und danach das LGW mal stromlos machen, dass die RFMs sicher resettet werden.
Zitat von: HCS am 04 Mai 2019, 23:38:08
Warum hast Du die PCA301-Initialisirung rausgenommen und kein "1,868950,120i" mehr drin?
Hatte ich zum testen mal rausgenommen.
Zitat von: HCS am 04 Mai 2019, 23:38:08
Das mit dem defekten Radio kannst Du aber mal testen, indem Du das erste Radio für den TX29 verwendest.
initCommands 17241#1r v
Das hat geklappt. Ein device wurde erstellt, allerdings ein "unerwartetes", da es nur die Temperatur anzeigt und definitiv nicht mein TX29DTH-IT ist...
Der scheint weiterhin nicht erkannt zu werden...
Der 2. RFM geht inzwischen übrigens auch wieder. da war ein Kabel "gebrochen".
Update: Das Gerät welches sendet habe ich identifiziert. Es handelt sich um einen alten TX37-IT. Bezüglich der TX29DHT-IT frage ich mich, ob sich evtl die Frequenz od ähnliches ändert, wenn man die Batterien neu einlegt? Ich bekomme da dann nämlich SP6 angezeigt und anschließend eine Kombi aus 2 Stellen (A=, 18 oder so etwas).Das LCW empfängt aktuell nichts außer dem TX37, bzw. habe ich den testweise auch mal ausgesteckt.
Update 2: Ok, die beiden Stellen dienen wohl zur Identifizierung, insofern müsste die Frequenz gleichbleibend sein? Dann verstehe ich ehrlich gesagt die Welt nicht mehr, denn einer der beiden TX29 ist ja sogar neu :(
Danke & Gruß,
Tobi
Zitat von: onkel-tobi am 05 Mai 2019, 11:45:32
Dann verstehe ich ehrlich gesagt die Welt nicht mehr(
Ich auch nicht :)
Die TX29DTH sind eigentlich unproblematisch, habe mehrere von denen seit Jahren.
Und wenn der TX37 empfangen wird, der wie die TX29DTH mit einer DataRate von 17.241 läuft, sollte auf LGW-Seite alles OK sein.
Konfiguriere nochmal einen RFM69 auf 17241 und öffne die Log-Page und lass es einige Minuten laufen und poste den Inhalt.
Und die Hardware-Page dazu.
Und den TX37 während diesem Test auch laufen lassen
Hier das log:
21:27:59: OK VALUES LGW 1302972 UpTimeSeconds=60,UpTimeText=0Tg. 0Std. 1Min. 0Sek. ,WIFI=HA,ReceivedFrames=7,FramesPerMinute=7,RSSI=-89,FreeHeap=19952,LD.Min=0.12,LD.Avg=0.12,LD.Max=7.47,OLED=none
21:27:59: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:27:59: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:27:59: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:27:59: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:27:59: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:27:59: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:27:59: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:27:59: OK VALUES LGW 1302972 UpTimeSeconds=90,UpTimeText=0Tg. 0Std. 1Min. 30Sek. ,WIFI=HA,ReceivedFrames=14,FramesPerMinute=14,RSSI=-88,FreeHeap=17176,LD.Min=0.13,LD.Avg=0.14,LD.Max=179.47,OLED=none
21:27:59: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:27:59: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:03: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:07: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:11: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:15: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:19: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:23: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:25: OK VALUES LGW 1302972 UpTimeSeconds=120,UpTimeText=0Tg. 0Std. 2Min. 0Sek. ,WIFI=HA,ReceivedFrames=22,FramesPerMinute=15,RSSI=-85,FreeHeap=17864,LD.Min=0.13,LD.Avg=0.14,LD.Max=69.89,OLED=none
21:28:27: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:32: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:34: [LaCrosseITPlusReader.Gateway.1.32 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) {IP=192.168.178.81}]
21:28:37: [LaCrosseITPlusReader.Gateway.1.32 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) {IP=192.168.178.81}]
21:28:37: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:37: [LaCrosseITPlusReader.Gateway.1.32 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) {IP=192.168.178.81}]
21:28:40: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:44: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:48: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:55: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:28:55: OK VALUES LGW 1302972 UpTimeSeconds=150,UpTimeText=0Tg. 0Std. 2Min. 30Sek. ,WIFI=HA,MacAddress=5C:CF:7F:13:E1:BC,ReceivedFrames=29,FramesPerMinute=15,RSSI=-90,FreeHeap=18504,Version=1.32,LD.Min=0.14,LD.Avg=0.17,LD.Max=63.04,OLED=none
21:28:57: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:00: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:05: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:09: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:12: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:16: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:21: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:26: OK VALUES LGW 1302972 UpTimeSeconds=180,UpTimeText=0Tg. 0Std. 3Min. 0Sek. ,WIFI=HA,ReceivedFrames=36,FramesPerMinute=14,RSSI=-87,FreeHeap=18768,LD.Min=0.14,LD.Avg=0.16,LD.Max=63.86,OLED=none
21:29:26: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:28: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:32: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:36: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:41: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:44: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:49: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:53: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:29:54: OK VALUES LGW 1302972 UpTimeSeconds=210,UpTimeText=0Tg. 0Std. 3Min. 30Sek. ,WIFI=HA,ReceivedFrames=44,FramesPerMinute=15,RSSI=-88,FreeHeap=19688,LD.Min=0.15,LD.Avg=0.16,LD.Max=58.82,OLED=none
21:29:57: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:01: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:06: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:09: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:13: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:17: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:21: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:25: OK VALUES LGW 1302972 UpTimeSeconds=240,UpTimeText=0Tg. 0Std. 4Min. 0Sek. ,WIFI=HA,ReceivedFrames=51,FramesPerMinute=15,RSSI=-85,FreeHeap=20240,LD.Min=0.14,LD.Avg=0.16,LD.Max=58.69,OLED=none
21:30:25: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:30: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:33: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:39: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:41: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:46: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:50: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:53: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:30:55: OK VALUES LGW 1302972 UpTimeSeconds=270,UpTimeText=0Tg. 0Std. 4Min. 30Sek. ,WIFI=HA,ReceivedFrames=59,FramesPerMinute=15,RSSI=-83,FreeHeap=19832,LD.Min=0.14,LD.Avg=0.16,LD.Max=56.71,OLED=none
21:30:58: OK 9 8 129 4 186 106 [92 26 10 6A 1C]
21:31:02: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:05: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:10: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:14: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:18: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:22: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:24: OK VALUES LGW 1302972 UpTimeSeconds=300,UpTimeText=0Tg. 0Std. 5Min. 0Sek. ,WIFI=HA,ReceivedFrames=66,FramesPerMinute=15,RSSI=-86,FreeHeap=20056,LD.Min=0.14,LD.Avg=0.16,LD.Max=58.79,OLED=none
21:31:27: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:32: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:34: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:39: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:42: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:47: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:51: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:54: OK VALUES LGW 1302972 UpTimeSeconds=330,UpTimeText=0Tg. 0Std. 5Min. 30Sek. ,WIFI=HA,ReceivedFrames=73,FramesPerMinute=14,RSSI=-85,FreeHeap=19768,LD.Min=0.14,LD.Avg=0.16,LD.Max=60.20,OLED=none
21:31:55: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:31:58: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:32:02: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:32:06: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:32:10: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:32:15: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:32:19: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:32:24: OK 9 8 129 4 185 106 [92 26 09 6A B1]
21:32:24: OK VALUES LGW 1302972 UpTimeSeconds=360,UpTimeText=0Tg. 0Std. 6Min. 0Sek. ,WIFI=HA,ReceivedFrames=81,FramesPerMinute=15,RSSI=-85,FreeHeap=19704,LD.Min=0.14,LD.Avg=0.16,LD.Max=62.78,OLED=none
21:32:27: OK 9 8 129 4 185 106 [92 26 09 6A B1]
und hier das debug.log:
21:28:34: DataPort: #81 Client connected, IP=192.168.178.88 Port=49584
21:28:37: DataPort: #81 received '17241#1r v '
21:28:37: DataPort: #81 received 'v '
Wie man dem log entnehmen kann, habe ich nur den 1 RFM konfiguriert, daher wird der 2. scheinbar default mäßig auf 9579 gesetzt.
Danke & Gruß,
Tobi
HW page im anhang
Zitat von: onkel-tobi am 06 Mai 2019, 21:33:46
Wie man dem log entnehmen kann, habe ich nur den 1 RFM konfiguriert, daher wird der 2. scheinbar default mäßig auf 9579 gesetzt.
So ist das.
Da der TX37 vom LGW tadellos und durchgehend empfangen wird und vom TX29DTH absolut nichts zu sehen ist, kann man eigentlich nur zu dem Schluss kommen, dass der TX29DTH nichts sendet.
Oder es TX29DTH gibt, die ein bisher nicht bekanntes Protokoll senden.
Aber solange im LGW auf der Log-Page vom TX29DTH nichts auftaucht, brauchst Du in FHEM gar nicht weiter suchen, da kann nichts ankommen.
Schicke meine dann nun zurück.
Kann mir evtl. jemand einen (Amazon)-Link zur Verfügung stellen, von einem Temperatur- und Luftfeuchtigkeitssensor der sicher funktionieren sollte mit dem LacrosseGateway?
Danke & Gruß,
Tobi
Hallo Tobi,eigentlich sollte der TX29 DHT-IT (https://www.amazon.de/Technoline-Au%C3%9Fensender-Temperatur-Luftfeuchtesender-Display/dp/B00392XX5U/ref=as_li_ss_tl?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=tx+29+dht&qid=1559115292&s=garden&sr=1-1-fkmr0&linkCode=ll1&tag=vtrulez-21&linkId=a1a415cffab4413a1b75dbabaa6afa87&language=de_DE) funktionieren, zumindest verrichtet er bei mir treue Dienste. Sonst sollte der TFA30.3144.IT (https://www.amazon.de/TFA-Dostmann-30-3144-30-3144-it-Feuchte-Sender/dp/B001NOU264/ref=as_li_ss_tl?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=3144&qid=1559115135&s=garden&sr=1-1&linkCode=ll1&tag=vtrulez-21&linkId=85df15864f9617b84e48ed757249d1ac&language=de_DE) auch mitspielen - den habe ich aber nicht selbst in Betrieb.
Als Alternative gibt es noch den TX35 DHT-IT (https://www.amazon.de/TX-35-DTH-Farbe-Weiss/dp/B0062YRSZ8/ref=as_li_ss_tl?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=TX35DTH-IT&qid=1559115647&s=garden&sr=1-1&linkCode=ll1&tag=vtrulez-21&linkId=2e45c8a7e6a913901bbe4fc97fe2e51d&language=de_DE), der überträgt halt mit der geringeren Datenrate 9579.
Ich habe folgende hier:
(https://uploads.tapatalk-cdn.com/20190529/85f0b7d4fcd801cc94071165c03f5883.jpg)
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Hallo zusammen,
also es muss irgendwie an meinem Lacrosse GW liegen.
Ich habe 2 weitere TX 29 DHTs bekommen, die bei einem anderen Forumsmitglied liefen und bei mir bekomme ich im LCG log nichts angezeigt.
Was ich mir aber eben nicht erklären kann ist, wieso der TX37 gleichzeitig erkannt wird?!
Internals:
CFGFN FHEM/wetter.cfg
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol:CapacitiveLevel
DEF 192.168.11.1:81
DeviceName 192.168.11.1:81
FD 70
FUUID 5ccd7b9e-f33f-daf3-3017-03db5a506ee8111e
NAME myLaCrosseGateway
NR 192
NTFY_ORDER 50-myLaCrosseGateway
PARTIAL
RAWMSG OK VALUES LGW 1302972 UpTimeSeconds=79445,UpTimeText=0Tg. 22Std. 4Min. 5Sek. ,WIFI=HA,ReceivedFrames=29,FramesPerMinute=0,RSSI=-78,FreeHeap=19760,LD.Min=0.15,LD.Avg=0.16,LD.Max=2.34,OLED=none
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.32
myLaCrosseGateway_MSGCNT 22064
myLaCrosseGateway_TIME 2019-06-04 11:37:53
nextOpenDelay 2
settings (1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 r:17241) {IP=192.168.11.11}]
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
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2019-06-04 11:37:53 state initialized
helper:
Attributes:
initCommands 1,868950,120i 17241#2r v
timeout 120,30
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE] 2>&1
Auf HW Seite des GWs:
Radio #1 RFM69 868950 kHz data rate: 6631 kbps
Radio #2 RFM69 868300 kHz data rate: 17241 kbps
Hat noch irgendwer eine Idee?
Gruß,
Tobias
Hallo Tobias,
Zitat von: onkel-tobi am 04 Juni 2019, 11:50:59
Hat noch irgendwer eine Idee?
hast Du mal probiert, die beiden Kanäle zu tauschen? Ggf. ist die Antenne etwas kürzer/länger als sie sein soll.
Gruß Peter
Zitat von: onkel-tobi am 04 Juni 2019, 11:50:59
Hat noch irgendwer eine Idee?
Mach mal (nur um allen Eventualitäten vorzubeugen) die 1.33 drauf:
https://forum.fhem.de/index.php/topic,43672.msg911655.html#msg911655
Hi zusammen,
also so richtig verstanden habe ich es nicht, aber aktuell bekomme ich sie rein, dafür meine PC 301er nicht mehr.
Vor allem hatte ich das ja schon mal durchgetestet...Aber gut, die TX29 funktionieren in jd. Fall und es scheint doch was mit dem 2. RFM zu sein.
Werde wohl mal die Verdrahtung checken.
Danke & Gruß,
Tobi
Zitat von: onkel-tobi am 04 Juni 2019, 18:39:39
Werde wohl mal die Verdrahtung checken.
Das hier sagt aber klar aus, dass die Verdrahtung OK ist, sonst würde das LGW den RFM69 nicht erkennen:
Zitatsettings (1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 r:17241) {IP=192.168.11.11}]
Bestenfalls die Verdrahtung der Antenne könnte es sein, Schluss gegen Masse z.B.
Es gab aber auch schon mal Fälle, wo ein RFM69 auf der SPI ganz normal gearbeitet hat aber die HF-Seite nicht funktioniert hat.
Hallo zusammen,
ich versuche eben meine ersten LaCrosseGateway zu bauen.
Ich habe ein WeMOS D1 mini und wollte ein RFM69CW anschließen, finde aber nirgendwo ein Schaltplan. :-\
Welche Pins werden wo aufgelegt?
Die Einbindung des WeMOS D1 mini ins WLAN und FHEM waren erfolgreich. :D
Zitat von: -jato- am 23 Juni 2019, 13:28:45
Ich habe ein WeMOS D1 mini und wollte ein RFM69CW anschließen, finde aber nirgendwo ein Schaltplan. :-\ Welche Pins werden wo aufgelegt?
Einfach hier (https://forum.fhem.de/index.php/topic,45594.msg373669.html#msg373669) mal reinlesen, da gibt es Schaltpläne zu Hauf (handgezeichnete, farbige, usw.). Etwas mit Fritzing erstelltes gibt's leider nicht :o.
Gruß Peter
ZitatEinfach hier mal reinlesen, da gibt es Schaltpläne zu Hauf
Es gibt da zwar Schaltpläne aber alle mit ESP8266_DEVKIT. Mit WeMOS leider nichts...
Hi,
dann Google halt die GPIOs vom NodeMCU DevKit:
https://images.app.goo.gl/QuVRUM3qqf7tmKZa7
Und vom Wemos-D1:
https://images.app.goo.gl/kqiDMRFMV3S8aKxD9
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Zitat von: -jato- am 23 Juni 2019, 14:54:28
Es gibt da zwar Schaltpläne aber alle mit ESP8266_DEVKIT. Mit WeMOS leider nichts...
Ist doch egal ob Wemos oder DevKit.
Für SPI und den ersten RFM69 brauchst Du GPIO12, GPIO13, GPIO14 und GPIO15
siehe hier, steht ja im Schaltplan dran: https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Variante:_DEVKIT_1.0_Minimum
Und RaspiLED hat hier https://images.app.goo.gl/kqiDMRFMV3S8aKxD9 schon die Vorlage geliefert.
Das sind genau die vier blauen auf der linken Seite beim Wemos.
3.3V und GND wirst Du dann finden ...
Moin,
könnte man die Firmware 1.33 die es seit Februar im Thread als Beta gibt vielleicht releasen ? Ich hab gestern ein neues GW eingerichtet und erstmal die Default 1.32 installiert, dann jedoch noch die 1.33 drübergezogen. Die 1.33 läuft auf dem 1. LaCrosseGW problemlos und ich denke nach paar Monaten nun, wäre es langsam an der Zeit, oder :) ?
Danke,
Ronny
Zitat von: rcmcronny am 16 Juli 2019, 08:35:32
könnte man die Firmware 1.33 die es seit Februar im Thread als Beta gibt vielleicht releasen ?
Ja.
Zitat von: rcmcronny am 16 Juli 2019, 08:35:32
... und ich denke nach paar Monaten nun, wäre es langsam an der Zeit, oder :) ?
Nachdem von den 22 Anwendern, die sie heruntergeladen haben, nun einer nach vier Monaten eine Rückmeldung gegeben hat, kann ich sie ja beruhigt freigeben :)
Hi,
super :) Danke.
Ahh klar, ohne Feedback kein Release, verständlich :D
Ronny
V1.33
Core 2.5.0
Die Entwicklungsumgebung wurde auf Core 2.5.0 umgestellt
Sende-Intervall der internen Sensoren
Konfiguration für das (bisher fix 10 Sekunden) Sende-Intervall der internen Sensoren
Auf der setup-page kann das Sendeintervall (Anzahl Sekunden) eingetragen werden.
Um es komplett zu deaktivieren kann man "off" eintragen
Nextion: 2 Dezimalstellen beim Luftdruck
Das Nextion hat beim Luftdruck immmer 2 Dezimalstellen angezeigt, egal was man im Setup bei "Pressure with decimals" eingetragen hatte.
Das richtet sich jetzt nach dem Setting "Pressure with decimals"
BH1750
Der BH1750 wird nun vom LGW unterstützt.
EC3000
EC3000 mit IDs, die mit 6 beginnen, haben nicht funktioniert
Ist eingecheckt, das FHEM-Update liefert es dann morgen aus.
@HCS
Den Link im ersten Post solltest du bitte löschen. Der führt ins Leere.
ZitatDie Firmware befindet sich hier: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin
Moin und sorry
Ich habe letztens auch auf 1.33 hochgezogen, und seitdem laufen die Beiden meiner Meinung nach viel stabiler. Auch wenn ich meine WLAN Umgebung gepimpt habe!
Gruss Christoph
Zitat von: Omega-5 am 16 Juli 2019, 11:38:31
Den Link im ersten Post solltest du bitte löschen. Der führt ins Leere.
Habe ihn korrigiert
Nabend,
kurze Frage:
curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@.\JeeLink_LaCrosseGateway.bin; filename=firmware.bin" http://192.168.31.211/ota/firmware.bin
sollte noch funktionieren für ein FW update? Der läd das zwar hoch und macht ein Reboot aber die Version ist die alte. Warum kann man nicht ein kleines upload form einbauen wo man die FW hochladen kann?
/Daniel
Hallo Daniel,
warum so kompliziert ?
Einfach in fhem: "set [Name des LGM] flash" ausführen, dann wird das Update durchgeführt (ohne Parameter) 8)
Siehe Anhang...
Gruß Thomas
PS: fhem Update vorher durchgeführt ? Wenn nicht, ist das der Grund, warum die alte Firmware noch drauf ist, quasi die alte über die alte geflasht :o
In FHEM ist mein LGW über den LAN angebunden, nicht WLAN... Daher geht das nicht.
Ja der FW Dateiname ist etwas verwirrend, auch fehlt die Versionsnummer. Kann man das file noch irgendwo anders runterladen?
/Daniel
Zitat von: ext23 am 29 Juli 2019, 08:17:57
In FHEM ist mein LGW über den LAN angebunden, nicht WLAN... Daher geht das nicht.
OTA-Update geht nur über WLAN.
Sag ich ja ;-)
Deswegen muss ich es manuell machen, sonst müsste ich das temporär in FHEM mit der WLAN IP einbinden.
/Daniel
Es kann aber auch nicht gehen. Die OTA-Update-Routinen sind an das WiFi-Interface des LGW gebunden.
Der USR-TCP232 hängt auf der Seriellen Schnittstelle mit drauf und hat nichts, um den FlashMode (GPIO0) zu steuern.
Jupp das ist ja logisch brauch ja auch keiner. Würde ja reichen wenn das über ein Upload Form geht über die Webseite als mit CURL oder irgend welchen anderen Flash Tools.
Ist dass das richtige file? Wieso eigentlich JeeLink?!?
ed378e10d753458aade3e7c2eeb8d4dc JeeLink_LaCrosseGateway.bin
/Daniel
Können eigentlich 2 FHEM Instanzen parallel auf ein Gateway zugreifen um die Werte der empfangen Sensoren auszuwerten?
Es geht natürlich um die WLAN Version.
Ich denke nicht. Ausser die Daten des lcg würden über MQTT gehen.
Oder sehe ich das falsch?
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: gloob am 03 August 2019, 12:31:59
Können eigentlich 2 FHEM Instanzen parallel auf ein Gateway zugreifen um die Werte der empfangen Sensoren auszuwerten?
Können sie
Zitat von: sash.sc am 03 August 2019, 15:24:52
Ich denke nicht. Ausser die Daten des lcg würden über MQTT gehen.
Oder sehe ich das falsch?
Siehst Du falsch.
Auf der Setup-Page des LGW kann man bis zu drei data ports definieren. Einfach Portnummern eintragen, z.B. 81, 82 und 83 und bis zu drei FHEMs auf diese Ports verbinden, also das erste auf 81, das zweite auf 82.
Allerdings sollten die LaCrosseGateway devices in FHEM keine sich widersprechenden initCommands haben.
Danke für die Info
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: HCS am 03 August 2019, 20:07:56
Können sie
Siehst Du falsch.
Auf der Setup-Page des LGW kann man bis zu drei data ports definieren. Einfach Portnummern eintragen, z.B. 81, 82 und 83 und bis zu drei FHEMs auf diese Ports verbinden, also das erste auf 81, das zweite auf 82.
Allerdings sollten die LaCrosseGateway devices in FHEM keine sich widersprechenden initCommands haben.
Danke. Genau damit läuft es. ;D
Ich habe bei meinem LGW Wifi abgeschaltet (nutze TX & RX )
Das 36_ KeyValueProtocol erzeugt dann ein Reading WIFI ohne Wert.
Vorschlag :
readingsBulkUpdate($rhash, $key, $value) if ($value);
statt
readingsBulkUpdate($rhash, $key, $value);
ich wollte die Tage mal eben schnell mein etwas älteres LGW 1.31 um einen Luftdruck Sensor erweitern. Da ich beim Bestellen nicht auf gepasst habe, kam natürlich ein BMP280 statt des BME280. Naiv wie ich war, kein Problem der HCS unterstützt soviele Sensoren und Luftfeuchte brauch ich eh nicht. Leider hat das dann doch etwas länger gedauert bis ich Werte bekam bzw. er überhaupt erkannt wurde. Gescheitert bin ich nach langem suchen an der Zeile in BME280.cpp
if (Read8(BME280_REGISTER_CHIPID) == 0x60)
Ich habe die Abfrage auf == 0x58 geändert und etwas weiter unten das GetHumidity(); rausgeworfen.
@HCS, du könntest vllt. auch auf beide Werte prüfen und den BMP als BME für Arme durchgehen lassen :)
Zitat von: Wzut am 11 August 2019, 20:01:45
@HCS, du könntest vllt. auch auf beide Werte prüfen und den BMP als BME für Arme durchgehen lassen :)
Das LGW unterstützt doch seit V1.32 den BMP280
https://forum.fhem.de/index.php/topic,43672.msg820228.html#msg820228
Mist, das ist natürlich ein schönes Beispiel für das Rad nochmal erfinden und das nur weil ich nicht fragen wollte :(
Ich hatte im Wiki nachgeschaut und hier gesucht, aber anyway nur so lernt man dazu :)
Ich habe einen Test Wemos auf 1.33 hochgezogen , im zip File für 1.33 fehlen die UniversalSensor.h & .cpp
Habe die aus dem alten V1.31 benutzt
Zitat von: Wzut am 12 August 2019, 19:43:57
im zip File für 1.33 fehlen die UniversalSensor.h & .cpp
Ist ja ein Ding, die sind auf dem Weg ins Repository hoch aus dem ZIP rausgefallen, weil es ein Loch hatte ;D ;D
Habe sie wieder nachgefüllt.
Ich versuche aktuell ein Breakout-Board mit RFM69HCW (https://eckstein-shop.de/Adafruit-Wireless-RFM69HCW-Transceiver-Radio-Breakout-868-or-915-MHz) als Radio #1 in einem LGW zu nutzen. Ich bekomme aber kein Radio #1 unter Hardware angezeigt. Gehe ich richtig davon aus, dass das Funkmodul automatisch erkannt werden müsste?
Verkabelung:
D5 <-> SCK
D6 <-> MISO
D7 <-> MOSI
D8 <-> CS (?? - es gibt kein NSS auf dem Breakout-Board)
Geflasht habe ich den LGW-Sketch, welcher im FHEM/firmware-Verzeichnis liegt.
Bin für Debugging-Tipps sehr dankbar, das ist mein erster Gehversuch mit LGW.
Zitat von: TWry am 16 August 2019, 08:03:06
Verkabelung:
D5 <-> SCK
D6 <-> MISO
D7 <-> MOSI
D8 <-> CS (?? - es gibt kein NSS auf dem Breakout-Board)
D5 <-> SCK = GPIO14
D6 <-> MISO = GPIO12
D7 <-> MOSI = GPIO13
D8 <-> CS = NSS = GPIO15
Siehe auch hier: https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=41968
Mir scheint aber, dass zwichen VIN und dem RFM69 ein 3.3V Spannungsregler sitzt, was möglicherweise das Problem ist.
Du müsstest mal direkt am RFM69 messen, ob da 3.3V anliegen.
ZitatGehe ich richtig davon aus, dass das Funkmodul automatisch erkannt werden müsste?
Ja.
Zitat von: HCS am 16 August 2019, 08:51:34
Du müsstest mal direkt am RFM69 messen, ob da 3.3V anliegen.
Die liegen an, habe ich gemessen.
Zitat von: HCS am 16 August 2019, 08:51:34
Mir scheint aber, dass zwichen VIN und dem RFM69 ein 3.3V Spannungsregler sitzt, was möglicherweise das Problem ist.
Stimmt, man kann ~3-6V als Versorgungsspannung anlegen.
Hattest Du gesehen, dass es sich um einen RFM69
HCW handelt, nicht um einen RFM69CW (ohne H)? Ich habe leider keinen RFM69CW auf einem Breakout-Board bekommen und dachte dass es ein HCW auch tut... ::)
Zitat von: TWry am 16 August 2019, 08:56:44
Hattest Du gesehen, dass es sich um einen RFM69HCW handelt, nicht um einen RFM69CW (ohne H)? Ich habe leider keinen RFM69CW auf einem Breakout-Board bekommen und dachte dass es ein HCW auch tut... ::)
Der sollte eigentlich auch gehen, habe zwar nie einen gehabt aber ich glaube es haben schon einige Leute LGWs mit dem HCW aufgebaut.
@all: Falls das jemand bestätigen kann, bitte mal kurz melden.
Zitat von: HCS am 16 August 2019, 09:00:47
@all: Falls das jemand bestätigen kann, bitte mal kurz melden.
Ich hatte noch keine RFM69HCWs im Einsatz, werde aber am Wochenende mal nachschauen, ob ich so ein Modul habe. Ein breakout (ohne Spannungsregler) für das RFM95 Modul (könnte/müsste pinkompatibel sein) ist in Hardware vorhanden ...
Gruß Peter
Zitat von: PeMue am 16 August 2019, 09:22:36
Ein breakout (ohne Spannungsregler) für das RFM95 Modul (könnte/müsste pinkompatibel sein) ist in Hardware vorhanden ...
Ohh, wo, wie?
Das könnte ich auch gebrauchen, tatsächlich für den RFM95.
Und ja, RFM95 und RFM69HCW sollten vom pinout gleich sein.
RFM95? LORA WAN?
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: sash.sc am 16 August 2019, 09:48:19
RFM95? LORA WAN?
RFM95? LORA
WAN?
Für einen Eigenbau-Pegel-Sensor der sehr weit weg sitzt.
Spread Spectrum Modulation für die Datenübertragung aber kein LoRa WAN.
D. H. RFM95 am Sender in Empfänger dran, und die Kiste überträgt die Daten über eine größere Entfernung. Von welcher Strecke reden wir hier?
Gruß Sascha
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: sash.sc am 16 August 2019, 10:27:57
Von welcher Strecke reden wir hier?
50 Meter, erst mal quer durch ein Gebäude durch und dann in ein weiteres Gebäude rein in den Keller, wo der Empfänger sitzt.
Das hat der RFM69 mit FSK nicht geschafft.
Ich wollte eigentlich einen Sensor mit bme280 und nem Licht Sensor bauen, der ein bißchen weiter weg ist. Mit nem RFM95 würde es ja klappen. Hat schon jemand einen Sensor mit den beiden Komponenten verbaut? Bzw gebaut?
Gruß Sascha
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: sash.sc am 16 August 2019, 12:23:17
Ich wollte eigentlich einen Sensor mit bme280 und nem Licht Sensor bauen, der ein bißchen weiter weg ist. Mit nem RFM95 würde es ja klappen. Hat schon jemand einen Sensor mit den beiden Komponenten verbaut? Bzw gebaut?
Nein, ist aber auf meiner ToDo Liste.
Gruß Peter
Zitat von: sash.sc am 16 August 2019, 12:23:17
Ich wollte eigentlich einen Sensor mit bme280 und nem Licht Sensor bauen, der ein bißchen weiter weg ist. Mit nem RFM95 würde es ja klappen. Hat schon jemand einen Sensor mit den beiden Komponenten verbaut? Bzw gebaut?
Zitat von: PeMue am 16 August 2019, 12:37:01
Nein, ist aber auf meiner ToDo Liste.
Da hätte ich evtl. ansatzweise etwas.
Das LGW kann Stand heute den RFM95.
WICHTIG: nicht für LaCrosse, EC3000, PCA301, usw.
Man baut ein ganz normales LGW und verwendet bei einem Radio (z.B. Radio#1) einen RFM95 anstatt einem RFM69.
Das LGW erkennt den RFM95 automatisch und man sollte auf Hardware-Page des LGW das hier sehen:
Radio #1 RFM95 868250 kHz LoRaFür den SensorMan nimmt z.B. einen Arduino Pro Mini 3,3V 8MHz und packt einen RFM95 dran
3.3V -> 3.3V
GND -> GND
NSS -> 10
MOSI -> 11
MISO -> 12
SCK -> 13
Man schreibt einen Arduino-Sketch, der die RFMxx.cpp/.h, die beim LGW dabei ist, verwendet.
Dieses Beispiel sendet Temperatur, Feuchte und Luftdruck so, dass es dem LGW und FHEM als Wetterstation erscheint:
#include "Arduino.h"
#include "SPI.h"
#include "RFMxx.h"
RFMxx rfm(11, 12, 13, 10);
void setup() {
Serial.begin(57600);
delay(100);
SPI.begin();
rfm.Begin();
Serial.println("Radio: " + rfm.GetRadioName());
if(rfm.IsConnected() && rfm.GetRadioType() == RFMxx::RadioType::RFM95W) {
rfm.InitializeLoRa();
rfm.SetFrequency(868250);
}
}
void loop() {
uint8_t sensorID = 0xAA;
float measuredTemperature = 22.2;
uint8_t measuredHumidity = 33;
uint16_t measuredPressure = 999;
char buffer[128];
sprintf(buffer, "OK WS %i 2 %i %i %i %i %i %i %i %i %i %i %i %i %i %i",
sensorID,
(uint8_t)((uint16_t)(round(measuredTemperature * 10 + 1000)) >> 8),
(uint8_t)(round(measuredTemperature * 10 + 1000)),
measuredHumidity,
255, 255, // no Rain
255, 255, // no WindDirection
255, 255, // no WindSpeed
255, 255, // no WindGust
0, // Flags
(uint8_t)((uint16_t)round(measuredPressure * 10) >> 8),
(uint8_t)((uint16_t)round(measuredPressure * 10)));
rfm.SendString(buffer);
delay(5000);
}Die measured... muss man natürlich noch mittels angeschlossener Sensoren messen ;)
Nach einem "set myLGW LaCrossePairForSec 60 ignore_battery" bekommt man ein LaCrosse_AA device.
_AA weil sensorID = 0xAA;
Und da drin die Daten:
Internals:
DEF AA
FUUID 5d58e660-f33f-4c99-8eb4-7f1b15186b16fd18
IODev lgw215
LASTInputDev lgw215
LaCrosse_lastRcv 2019-08-18 09:11:37
MSGCNT 817
NAME LaCrosse_AA
NR 184
STATE T: 22.2 H: 33
TYPE LaCrosse
addr AA
battery_new 0
bufferedH 33
bufferedT 22.2
corr1 0
corr2 0
lgw215_MSGCNT 817
lgw215_TIME 2019-08-18 09:11:37
previousH 33
previousR 0
previousT 22.2
sensorType 2=NodeSensor
READINGS:
2019-08-18 09:11:37 battery ok
2019-08-18 09:11:37 error 0
2019-08-18 09:11:37 humidity 33
2019-08-18 09:11:37 pressure 999
2019-08-18 09:11:37 temperature 22.2
Attributes:
IODev lgw215
room LaCrosseDas alles geht Stand heute.
Nun die schlechte Nachricht: illuminance würde auch fast gehen, das 36_LaCrosseGateway.pm und auch das 36_LaCrosse.pm kann sie. Nur ist der payload-string im LGW für den RFM95 aktuell zu kurz dafür, weil die erst ganz hinten kommt. Das müsste ich im LGW noch anpassen, dann sollte das auch funktionieren.
Die gute Nachricht: für den BME280 und den BH1750 kann man wohl sehr einfach die Libs aus dem LGW in den Sketch oben einbauen, dann hat man die Werte.
Die schlechte Nachricht: Zeit habe ich eigentlich so gut wie keine.
Ach übrigens: für die Einhaltung der 1%-Regel ist jeder selbst verantwortlich, mein Beispiel oben verletzt sie definitiv.
Danke für die Info.
Gesendet von meinem MI 9 mit Tapatalk
Hallo HCS,
Zitat von: HCS am 18 August 2019, 09:32:08
Die schlechte Nachricht: Zeit habe ich eigentlich so gut wie keine.
ginge das auch mit einem seriellen Interface (z.B. mit 57600 baud)? Ich würde dann auf dem LGW nur die Definition der Schnittstelle machen und die Weiterverarbeitung selber (z.B. per ECMD, o.ä.). Wenn nicht, programmiere ich mir etwas selber und mache mir auch das Interface selber (Platine ist schon in groben Zügen fertig).
Danke + Gruß
Peter
Zitat von: PeMue am 18 August 2019, 11:00:45
Hallo HCS,
ginge das auch mit einem seriellen Interface (z.B. mit 57600 baud)?
Nein, das Problem liegt nicht hinter dem LGW sondern im LGW.
Da muss ich ran, hilft nichts.
Aber Du hast ja einen Softwarewartungsvertrag ... ;) ;D
Lass mich erst mal schauen, was ich eigentlich ändern muss.
Zitat von: HCS am 18 August 2019, 11:21:05
Da muss ich ran, hilft nichts.
OK, war dran.
Den erforderlichen Umbau im LGW und der verwendeten RFMxx.cpp/.h habe ich betamäßig hinbekommen.
Und dann auch noch den Sensor eurer Träume test-implementiert (also mit BH1750 und BME280)
Alle libs (RFMxx, BH1750 und BME280) kann man dem LGW-Source (wenn ich die 1.34 dann veröffentliche) klauen.
Der Sensor sieht dann so aus:#include "Arduino.h"
#include "SPI.h"
#include "Wire.h"
#include "RFMxx.h"
#include "I2CBase.h"
#include "BH1750.h"
#include "BME280.h"
RFMxx rfm(11, 12, 13, 10);
BH1750 bh1750;
BME280 bme280;
void setup() {
Serial.begin(57600);
delay(250);
Wire.begin();
Serial.println(bh1750.TryInitialize(0x23) ? "BH1750 OK" : "no BH1750");
Serial.println(bme280.TryInitialize(0x76) ? "BME280 OK" : "no BME280");
SPI.begin();
rfm.Begin();
Serial.println("Radio: " + rfm.GetRadioName());
if(rfm.IsConnected() && rfm.GetRadioType() == RFMxx::RadioType::RFM95W) {
rfm.InitializeLoRa();
rfm.SetFrequency(868250);
}
}
void loop() {
uint8_t sensorID = 0xAA;
float measuredTemperature = bme280.GetTemperature();
uint8_t measuredHumidity = bme280.GetHumidity();
uint16_t measuredPressure = bme280.GetPressure();
uint32_t measuredLUX = bh1750.GetIlluminance();
char buffer[255];
sprintf(buffer, "OK WS %i 5 %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i %i",
sensorID,
(uint8_t)((uint16_t)(round(measuredTemperature * 10 + 1000)) >> 8),
(uint8_t)(round(measuredTemperature * 10 + 1000)),
measuredHumidity,
255, 255, // no Rain
255, 255, // no WindDirection
255, 255, // no WindSpeed
255, 255, // no WindGust
0, // Flags
(uint8_t)((uint16_t)round(measuredPressure * 10) >> 8),
(uint8_t)((uint16_t)round(measuredPressure * 10)),
255, 255, 255, 255, 255, 255, // no Gas
(uint8_t)(measuredLUX >> 16),
(uint8_t)(measuredLUX >> 8),
(uint8_t)(measuredLUX),
12, // version 1.2
255, // no voltage
255, 255, 255); // no debug info
rfm.SendString(buffer);
delay(5000);
}Ergibt im FHEM:Internals:
CFGFN
DEF AA
FUUID 5d58e660-f33f-4c99-8eb4-7f1b15186b16fd18
IODev lgw215
LASTInputDev lgw215
LaCrosse_lastRcv 2019-08-18 21:15:50
MSGCNT 3305
NAME LaCrosse_AA
NR 184
STATE T: 25.7 H: 59
TYPE LaCrosse
addr AA
battery_new 0
bufferedH 59
bufferedT 25.7
corr1 0
corr2 0
lgw214_MSGCNT 797
lgw214_TIME 2019-08-18 20:05:54
lgw215_MSGCNT 2508
lgw215_TIME 2019-08-18 21:15:50
previousH 59
previousR 0
previousT 25.7
sensorType 5=UniversalSensor
OLDREADINGS:
READINGS:
2019-08-18 21:15:50 battery ok
2019-08-18 21:15:50 error 0
2019-08-18 21:15:50 humidity 59
2019-08-18 21:15:50 lux 1400
2019-08-18 21:15:50 pressure 986
2019-08-18 21:15:25 state T: 25.7 H: 59
2019-08-18 21:15:50 temperature 25.7
2019-08-18 21:15:50 version 1.2
Attributes:
IODev lgw215
room LaCrosse
Zitat von: Wzut am 07 August 2019, 16:50:22
Ich habe bei meinem LGW Wifi abgeschaltet (nutze TX & RX )
Das 36_ KeyValueProtocol erzeugt dann ein Reading WIFI ohne Wert.
Vorschlag :
readingsBulkUpdate($rhash, $key, $value) if ($value);
statt
readingsBulkUpdate($rhash, $key, $value);
Ist eingecheckt.
V1.34
RFM95
Payload kann jetzt bis zu 250 byte lang sein
Einstellungen für RFM95 auf der SetupPage
-SpreadingFactor (default SF7)
-Bandbreite (default 125 kHz)
WICHTIG: das LGW unterstützt den RFM95, aber nur für eigene Sensoren.
Für LaCrosse, PCA301, EC3000, usw. wird ein RFM69 benötigt.
Zitat von: HCS am 07 September 2019, 21:19:59
V1.34
RFM95
Payload kann jetzt bis zu 250 byte lang sein
Einstellungen für RFM95 auf der SetupPage
-SpreadingFactor (default SF7)
-Bandbreite (default 125 kHz)
WICHTIG: das LGW unterstützt den RFM95, aber nur für eigene Sensoren.
Für LaCrosse, PCA301, EC3000, usw. wird ein RFM69 benötigt.
Gibt es einen link wie der RFM95 angeschlossen wird? Also an welchen Pins.
Zitat von: sash.sc am 16 August 2019, 12:23:17
Ich wollte eigentlich einen Sensor mit bme280 und nem Licht Sensor bauen, der ein bißchen weiter weg ist. Mit nem RFM95 würde es ja klappen. Hat schon jemand einen Sensor mit den beiden Komponenten verbaut? Bzw gebaut?
Mit dem LGW 1.34, das ich gerade eingecheckt habe, funktioniert der angehängte Sender, der einen BME280 und einen BH1750 verwendet.
Zitat von: gloob am 07 September 2019, 21:27:48
Gibt es einen link wie der RFM95 angeschlossen wird? Also an welchen Pins.
Genua so, wie man auch einen RFM69 anschließen würde.
MISO,MOSI,SCK,NSS,3.3v,GND
Zitat von: HCS am 07 September 2019, 21:31:26
Genua so, wie man auch einen RFM69 anschließen würde.
MISO,MOSI,SCK,NSS,3.3v,GND
Okay. DIO0, DIO1, DIO2 werden also nicht genutzt.
Das Gateway scheint zumindest schonmal zu laufen.
Radio #1 RFM95 868200 kHz LoRa SF=0 BW=7 kHz
Gibt es Debug Möglichkeiten wenn der Empfänger nix vom Sensor "sieht"
Im Sensor sieht es gut aus, hab Random Werte senden lassen:
21:55:11.361 -> no BH1750
21:55:11.361 -> no BME280
21:55:11.361 -> Radio: RFM95
21:55:11.361 -> Setup finished
21:55:11.361 -> L:38 T:232.00 H:19 P:158
21:55:16.579 -> L:68 T:175.00 H:197 P:114
21:55:21.829 -> L:80 T:188.00 H:109 P:120
21:55:27.029 -> L:143 T:102.00 H:47 P:102
21:55:32.274 -> L:52 T:142.00 H:79 P:160
Zitat von: gloob am 07 September 2019, 21:43:25
Radio #1 RFM95 868200 kHz LoRa SF=0 BW=7 kHz
Nanu, warum funktioniert denn der Default nicht?
Geh mal auf die setup-Page und stell SF7 und Bandwidth 125 ein und schau dann nochmal auf der Hardware-Page
So wäre korrekt für den Sensor:
Radio #1 RFM95 868200 kHz LoRa SF=7 BW=125 kHz
Zitat von: HCS am 07 September 2019, 21:57:29
Nanu, warum funktioniert denn der Default nicht?
Geh mal auf die setup-Page und stell SF7 und Bandwidth 125 ein und schau dann nochmal auf der Hardware-Page
So wäre korrekt für den Sensor:
Radio #1 RFM95 868200 kHz LoRa SF=7 BW=125 kHz
Da kann ich einstellen, was ich will. Die Daten werden nicht übernommen. Auf der Arduino Console sehe ich nur:
OK VALUES LGW 6144624 UpTimeSeconds=20,UpTimeText=0Tg. 0Std. 0Min. 20Sek. ,WIFI=HasenpupsExtreme,ReceivedFrames=0,FramesPerMinute=0,RSSI=-52,FreeHeap=25944,LD.Min=0.64,LD.Avg=0.65,LD.Max=2.69,OLED=none
OK VALUES LGW 6144624 UpTimeSeconds=30,UpTimeText=0Tg. 0Std. 0Min. 30Sek. ,WIFI=HasenpupsExtreme,ReceivedFrames=0,FramesPerMinute=0,RSSI=-52,FreeHeap=23760,LD.Min=0.64,LD.Avg=0.65,LD.Max=1.60,OLED=none
!�
JJ!!ŠH...
1Œ8ø½ÖˆK¥SˆˆkH ÊX ÌŸÖ옜!HN=˜!HN=èEÍkç̯m
***CLEARLOG***
LaCrosseITPlusReader.Gateway V1.34
Free heap: 29296 Flash size: 4194304 Core: 2_5_0 SDK: 3.0.0-dev(c0f7b44)
Reset: Software/System restart
Fatal exception:0 flag:4 (SOFT_RESTART) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
Starting I2C with 400 kHz
Configured altitude: 0
Searching RFMs and Sensors
Radio #1 found: RFM95
Starting wifi
Start WIFI_STA
HostName is: LaCrosseGateway
Using DHCP
Connect 15 seconds to an AP (SSID 1)
.......
connected :-)
SSID: HasenpupsExtreme
IP: 192.168.1.171
Starting frontend
Starting OTA
Starting data port 1 on 81
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.34 (1=RFM95 f:868200 LoRa SF=0 BW=7 kHz) {IP=192.168.1.171}]
Setup completely done
OK VALUES LGW 6144624 UpTimeSeconds=10,UpTimeText=0Tg. 0Std. 0Min. 10Sek. ,WIFI=HasenpupsExtreme,MacAddress=2C:F4:32:5D:C2:70,ReceivedFrames=0,FramesPerMinute=0,RSSI=-58,FreeHeap=26424,Version=1.34,LD.Min=64.00,LD.Avg=61.89,LD.Max=127.43,OLED=none
OK VALUES LGW 6144624 UpTimeSeconds=20,UpTimeText=0Tg. 0Std. 0Min. 20Sek. ,WIFI=HasenpupsExtreme,ReceivedFrames=0,FramesPerMinute=0,RSSI=-53,FreeHeap=25632,LD.Min=0.64,LD.Avg=0.65,LD.Max=2.69,OLED=none
OK VALUES LGW 6144624 UpTimeSeconds=30,UpTimeText=0Tg. 0Std. 0Min. 30Sek. ,WIFI=HasenpupsExtreme,ReceivedFrames=0,FramesPerMinute=0,RSSI=-55,FreeHeap=25536,LD.Min=0.64,LD.Avg=0.64,LD.Max=1.53,OLED=none
OK VALUES LGW 6144624 UpTimeSeconds=40,UpTimeText=0Tg. 0Std. 0Min. 40Sek. ,WIFI=HasenpupsExtreme,ReceivedFrames=0,FramesPerMinute=0,RSSI=-53,FreeHeap=25152,LD.Min=0.64,LD.Avg=0.65,LD.Max=1.52,OLED=none
Ich hab die Bin aus dem Release Ordner geflasht.
Zitat von: gloob am 07 September 2019, 22:00:44
Da kann ich einstellen, was ich will. Die Daten werden nicht übernommen. Auf der Arduino Console sehe ich nur:
Ich hab die Bin aus dem Release Ordner geflasht.
Hmmm...
Wenn Du die Settings speicherst, was steht denn dann da direkt nach dem speichern?
Also so etwas in der Art:
Settings saved
625 Byte (max. 1024) and 43 values (max. 50)
Reboot, please wait a moment ...
Zitat von: HCS am 07 September 2019, 22:08:26
Hmmm...
Wenn Du die Settings speicherst, was steht denn dann da direkt nach dem speichern?
Also so etwas in der Art:
Settings saved
625 Byte (max. 1024) and 43 values (max. 50)
Reboot, please wait a moment ...
Sieht nach zu wenig Bytes aus:
Settings saved
404 Byte (max. 1024) and 30 values (max. 50)
Reboot, please wait a moment ...Ich hab nochmal selbst kompiliert in der Arduino IDE, aber sieht nicht anders aus.
Zitat von: gloob am 07 September 2019, 22:09:54
Sieht nach zu wenig Bytes aus:
Settings saved
404 Byte (max. 1024) and 30 values (max. 50)
Reboot, please wait a moment ...
Nee, ist OK. Die Größe ist abhängig davon, was man alles so eingetragen hat.
Wollte nur sehen, ob es evtl zu viel ist.
Dann muss ich mal das bin flashen und schauen, ob ich das reproduzieren kann.
Aber dieses WE wohl eher nicht mehr :-(
Zitat von: HCS am 07 September 2019, 22:14:21
Nee, ist OK. Die Größe ist abhängig davon, was man alles so eingetragen hat.
Wollte nur sehen, ob es evtl zu viel ist.
Dann muss ich mal das bin flashen und schauen, ob ich das reproduzieren kann.
Aber dieses WE wohl eher nicht mehr :-(
Kein Problem.
Ich hab jetzt selber mal paar Logs eingefügt.
Folgende Werte werden unabhängig von der GUI beim Starten gesetzt:
22:19:23.804 -> set power level: 17
22:19:23.840 -> set band width: 7
22:19:23.840 -> set spreading factor: 7
22:19:23.840 -> set spreading factor: 7
22:19:23.840 -> set band width: 7
Habe das bin mal schnell auf eins meiner LGW geflasht (von FHEM aus)
Auf der Hardware-Page steht genau das, was ich auf der Setup-Page gespeichert habe.
Seltsame Geschichte ...
Zitat von: HCS am 07 September 2019, 22:26:24
Habe das bin mal schnell auf eins meiner LGW geflasht (von FHEM aus)
Auf der Hardware-Page steht genau das, was ich auf der Setup-Page gespeichert habe.
Seltsame Geschichte ...
Fehler gefunden. Mein RFM1_SS hängt auf der 16 und nicht auf der 15. Habs jetzt im Sketch Define geändert und dann läuft es. Ich geh jetzt mal davon aus, die Setup Werte kommen aus dem SPIFFS und die Hardware Werte aus dem Sensor per GET.
F�E⸮X⸮@AIdI⸮⸮ Mѳ⸮CQ@⸮⸮ UW⸮⸮F ⸮T֍⸮a\⸮%H⸮aH⸮⸮c⸮VpJ⸮⸮⸮⸮eK⸮⸮⸮⸮T⸮⸮ޅH⸮[⸮n⸮ `\K⸮@⸮⸮u⸮.iF⸮_⸮⸮
22:31:06.002 -> ***CLEARLOG***
22:31:06.002 -> LaCrosseITPlusReader.Gateway V1.34
22:31:06.002 -> Free heap: 34920 Flash size: 4194304 Core: 2_5_2 SDK: 2.2.1(cfd48f3)
22:31:06.002 -> Reset: External System
22:31:06.035 -> Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
22:31:06.035 -> Starting I2C with 400 kHz
22:31:07.181 -> Configured altitude: 0
22:31:07.217 -> Searching RFMs and Sensors
22:31:07.217 -> set power level: 17
22:31:07.217 -> set band width: 7
22:31:07.217 -> set spreading factor: 7
22:31:07.217 -> set spreading factor: 7
22:31:07.217 -> set band width: 7
22:31:07.217 -> Radio #1 found: RFM95
22:31:07.318 -> Starting wifi
22:31:07.318 -> Start WIFI_STA
22:31:07.388 -> HostName is: LaCrosseGateway
22:31:07.388 -> Using DHCP
22:31:07.498 -> Connect 15 seconds to an AP (SSID 1)
22:31:07.988 -> .......
22:31:11.807 -> connected :-)
22:31:11.807 -> SSID: HasenpupsExtreme
22:31:11.807 -> IP: 192.168.1.171
22:31:11.807 -> Starting frontend
22:31:11.807 -> Starting OTA
22:31:11.807 -> Starting data port 1 on 81
22:31:12.810 -> Sending init String to FHEM
22:31:12.810 ->
22:31:12.810 -> [LaCrosseITPlusReader.Gateway.1.34 (1=RFM95 f:868200 LoRa SF=7 BW=125 kHz) {IP=192.168.1.171}]
22:31:12.847 -> Setup completely done
22:31:14.376 -> OK WS 170 5 12 128 213 255 255 255 255 255 255 255 255 0 1 14 255 255 255 255 255 255 0 0 138 12 255 255 255 255 -24
22:31:14.917 -> OK VALUES LGW 6144624 UpTimeSeconds=10,UpTimeText=0Tg. 0Std. 0Min. 10Sek. ,WIFI=HasenpupsExtreme,MacAddress=2C:F4:32:5D:C2:70,ReceivedFrames=1,FramesPerMinute=1,RSSI=-53,FreeHeap=30224,Version=1.34,LD.Min=1.73,LD.Avg=1.73,LD.Max=1.73,OLED=none
Gute Frage nur, warum er trotzdem den RFM95 erkannt hat.
Wäre natürlich traumhaft, wenn man die Pins auch über die GUI ändern könnte. ;)
Sensor geht jetzt auch in FHEM:
defmod LaCrosse_AA LaCrosse AA
attr LaCrosse_AA IODev myLaCrosseGateway_RFM95
attr LaCrosse_AA room LaCrosse
setstate LaCrosse_AA T: 61 H: 80
setstate LaCrosse_AA 2019-09-07 22:48:40 battery ok
setstate LaCrosse_AA 2019-09-07 22:48:40 error 0
setstate LaCrosse_AA 2019-09-07 22:48:40 humidity 80
setstate LaCrosse_AA 2019-09-07 22:49:15 lux 159
setstate LaCrosse_AA 2019-09-07 22:49:15 pressure 2400
setstate LaCrosse_AA 2019-09-07 22:48:40 state T: 61 H: 80
setstate LaCrosse_AA 2019-09-07 22:48:40 temperature 61
setstate LaCrosse_AA 2019-09-07 22:49:15 version 1.2
Zitat von: gloob am 07 September 2019, 22:32:24
Ich geh jetzt mal davon aus, die Setup Werte kommen aus dem SPIFFS und die Hardware Werte aus dem Sensor per GET.
Korrekt. Nur dass die Werte der Hardware-Page nicht aus dem Sensor sondern aus dem RFM95 kommen.
Da wird er angefragt, was aktuell gesetzt ist.
Zitat von: gloob am 07 September 2019, 22:32:24
22:31:35.281 -> OK WS 170 5 8 222 161 255 255 255 255 255 255 255 255 0 3 242 255 255 255 255 255 255 0 0 121 12 255 255 255 255 -27
22:31:40.511 -> OK WS 170 5 11 14 224 255 255 255 255 255 255 255 255 0 7 148 255 255 255 255 255 255 0 0 142 12 255 255 255 255 -30
Dann sollte ein "LaCrossePairForSec 60 ignore_battery" ein LaCrosse device "LaCrosse_AA" anlegen
Zitat von: gloob am 07 September 2019, 22:32:24
Gute Frage nur, warum er trotzdem den RFM95 erkannt hat.
Wenn der GPIO16 beim Start LOW ist, ist der Chip selektiert und der RFM95 antwortet.
Also geht das LGW davon aus, dass er da ist.
Muss irgedwie in der Art was sein, und später ist er vielleich HIGH und dann kommt keine Antwot mehr.
Zitat von: gloob am 07 September 2019, 22:32:24
Wäre natürlich traumhaft, wenn man die Pins auch über die GUI ändern könnte. ;)
Nicht alle Träume gehen in Erfüllung ;D
Zitat von: HCS am 07 September 2019, 21:19:59
V1.34
RFM95
WICHTIG: das LGW unterstützt den RFM95, aber nur für eigene Sensoren.
Für LaCrosse, PCA301, EC3000, usw. wird ein RFM69 benötigt.
Erstmal danke für deine Arbeit.
Verstehe ich das richtig, dass für einen RFM95 ein 2. Gateway genommen werden muss?
Oder geht am Gateway auch eine mischbestückung?
Also 1 rfm69 und 1 RFM95?
Gruß Sascha
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: sash.sc am 08 September 2019, 11:28:30
Erstmal danke für deine Arbeit.
Verstehe ich das richtig, dass für einen RFM95 ein 2. Gateway genommen werden muss?
Oder geht am Gateway auch eine mischbestückung?
Also 1 rfm69 und 1 RFM95?
Gruß Sascha
Gesendet von meinem MI 9 mit Tapatalk
Mischbestückung sollte auch klappen, wenn du eine Platine hast wo beides drauf passt. Ansonsten musst du "freiluft" verdrahten
Danke für die Info
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: sash.sc am 08 September 2019, 11:39:47
Danke für die Info
Gesendet von meinem MI 9 mit Tapatalk
Falls du Interesse hast, ich habe noch Platinen für LaCrosseGateway mit RFM95 abzugeben.
https://forum.fhem.de/index.php?topic=103573
Zitat von: sash.sc am 08 September 2019, 11:28:30
Oder geht am Gateway auch eine mischbestückung?
Also 1 rfm69 und 1 RFM95?
Ja, geht.
Radio #1 RFM69 868300 kHz data rate: 17241 kbps
Radio #2 RFM95 868200 kHz LoRa SF=7 BW=125 kHzEin beliebiges Radio kann ein RFM95 sein.
Hallo zusammen,
ich habe den LGW mehr oder weniger gut seit einiger Zeit laufen.
Leider "vergisst" er hin und wieder seine Konfiguration und ich muß im LGW in der command Zeile das Kommando "1,868950,120i 17241#2r 868300#2f v" absetzen.
Nach kann ich wieder Temperatur erfassen und die PCA301 schalten.
Gibt es irgendwo eine Möglichkeit diese Daten fest einzubrennen?
LG
Mm
Zitat von: HCS am 07 September 2019, 21:30:04
Mit dem LGW 1.34, das ich gerade eingecheckt habe, funktioniert der angehängte Sender, der einen BME280 und einen BH1750 verwendet.
Wie würde man denn hier die Batteriespannung übertragen und anzeigen?
Im Sketch gibt es ja:
255, // no voltagekann ich dort einfach die Batteriespannung als Int Wert eintragen? Wie kann man sie allerdings in FHEM anzeigen lassen im Sensor Device?
Aktuell haben in einen Universalsensor in FHEM
sensorType
5=UniversalSensor
ERLEDIGTMan kann ja auch mal in die Datei schauen und die FHEM Webseite aktualisieren ;)
if (@bytes > 26 && $bytes[26] != 0xFF) {
$voltage = $bytes[26] / 10;
}setstate LaCrosse_AA T: 24 H: 42
setstate LaCrosse_AA 2019-09-11 18:12:27 battery ok
setstate LaCrosse_AA 2019-09-11 18:12:27 error 0
setstate LaCrosse_AA 2019-09-11 18:12:27 humidity 42
setstate LaCrosse_AA 2019-09-11 18:12:27 lux 0
setstate LaCrosse_AA 2019-09-11 18:12:27 pressure 1012
setstate LaCrosse_AA 2019-09-11 18:12:27 state T: 24 H: 42
setstate LaCrosse_AA 2019-09-11 18:12:27 temperature 24
setstate LaCrosse_AA 2019-09-11 18:12:27 version 1.2
setstate LaCrosse_AA 2019-09-11 18:12:27 voltage 2.8
Zitat von: marsmaennchen am 08 September 2019, 22:35:44
Gibt es irgendwo eine Möglichkeit diese Daten fest einzubrennen?
In die initCommands eintragen.
Hallo HCS,
irgendwann in der Vergangenheit, muss so um die Version 1.30 rum gewesen sein, hatte ich schonmal gezeigt, dass das LGW bei Connect WiFi bei einem Problem mit dem AP in der Lage ist über die 100% hinaus zu connecten, und ich bilde mir ein damals sollte das zur nächsten Version gefixt werden. Diese Woche fiel mir auf Version 1.33 kann das immer noch ...
MfG,
Marco
Moin HCS,
ich habe das deswegen immer im LGW eingetragen, weil ich nicht das richtige INIT comand gefunden habe, das mir die Parameter so einstellt:
(1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 r:17241)
Was nehme ich da ?
LG
MM
Zitat von: marsmaennchen am 13 September 2019, 12:35:41
ich habe das deswegen immer im LGW eingetragen, weil ich nicht das richtige INIT comand gefunden habe, das mir die Parameter so einstellt:
(1=RFM69 f:868950 r:6631) + (2=RFM69 f:868300 r:17241)
Was nehme ich da ?
attr <name> initCommands 1,868950,120i 17241#2r v
Zitat von: marco-f am 13 September 2019, 11:11:41
dass das LGW bei Connect WiFi bei einem Problem mit dem AP in der Lage ist über die 100% hinaus zu connecten
Ich kann das nicht nachvollziehen.
Ausgangszustand:Das LaCrosseGateway-Device in FHEM hat einen timeout von 10s (attr timeout ist 10)
Das LGW ist mit WiFi verbunden
RSSI oben rechts ist -45 dBm
Ich schalte WiFi am AccessPoint ausDas FHEM-Symbol oben links verschwindet
RSSI oben rechts geht auf 31 dBm (weil es seinen AP aktiviert und nun mit +31dBm sendet)
WiFi-Symbol bleibt (das ist falsch, sollte ausgehen)
Das LaCrosseGateway-Device in FHEM geht auf disconnected
Ich schalte WiFi am AccessPoint wieder einRSSI oben rechts geht auf -45 dBm
Das LaCrosseGateway-Device in FHEM verbindet sich und geht auf initialized
Das FHEM-Symbol oben links erscheint
Es kommt keinerlei Progress irgendwann bei dem Test.
Ein Progress kann nur dann kommen, wenn das LGW bootet.
Was hast Du denn bei "SSID / Password" ganz rechts als Zeit angegeben?
Zitat von: HCS am 14 September 2019, 19:02:03
Was hast Du denn bei "SSID / Password" ganz rechts als Zeit angegeben?
Muss wohl mehr als 255 sein, so kann ich es nachvollziehen.
Ist geändert, und das WiFi-Symbol, das nicht verschwindet, ebenso.
V1.35
WiFi-Symbol im OLED
Wenn das LGW die Verbindung zum AccessPoint verloren hat, ist das WiFi-Symbol im OLED links oben nicht verschwunden.
Progress im OLED
Wenn das LGW eine Verbindung zum AccessPoint versucht hat und der Timeout auf der Setup-Page auf mehr als 255 eingestellt war, ist der Progress über 100% hinaus gegangen.
Gerade eingecheckt, wird also erst morgen vom Server ausgeliefert.
Hi,
Zitat von: HCS am 14 September 2019, 19:02:03
Ausgangszustand:
Das LaCrosseGateway-Device in FHEM hat einen timeout von 10s (attr timeout ist 10)
Das LGW ist mit WiFi verbunden
RSSI oben rechts ist -45 dBm
Soweit bei mir auch, nur hab ich timeout 60.
Zitat
Ich schalte WiFi am AccessPoint aus
Das FHEM-Symbol oben links verschwindet
RSSI oben rechts geht auf 31 dBm (weil es seinen AP aktiviert und nun mit +31dBm sendet)
WiFi-Symbol bleibt (das ist falsch, sollte ausgehen)
Das LaCrosseGateway-Device in FHEM geht auf disconnected
Ja, kann ich so auch bestätigen. Wenn jetzt der Zugang aber längere Zeit weg ist, bzw. bei mir ist das Problem dass sich ganz sporadisch der AP vernagelt und zwar noch die SSID sendet aber man sich nicht mehr verbinden kann, dann beginnt das LGW irgendwann einen Neustart, dann kommt die normale Startprozedur und hierbei tritt dann das Phänomen auf.
Zitat
Ich schalte WiFi am AccessPoint wieder ein
RSSI oben rechts geht auf -45 dBm
Das LaCrosseGateway-Device in FHEM verbindet sich und geht auf initialized
Das FHEM-Symbol oben links erscheint
Wenn ich dann auch innerhalb dieses Phänomens (z.b. bei Connect WiFi (1) 222%) den AP wieder zuschalte verbindet er sich dann auch wieder richtig wie von Dir beschrieben.
Zitat
Was hast Du denn bei "SSID / Password" ganz rechts als Zeit angegeben?
150
Das alles hab ich gerade unter der v1.34 getestet.
MfG
Marco
Moin,
mit "set LGW flash" erhalte ich immer nur die Version 1.33
ZitatHCS:
V1.35
Gerade eingecheckt, wird also erst morgen vom Server ausgeliefert.
Die Zip Datei auf dem Server lässt sich auch nicht entpacken.
MM
Zitat von: marsmaennchen am 18 September 2019, 14:23:51
mit "set LGW flash" erhalte ich immer nur die Version 1.33
update in FHEM vergessen?
Zitat von: marsmaennchen am 18 September 2019, 14:23:51
Die Zip Datei auf dem Server lässt sich auch nicht entpacken.
Du meinst die hier?
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip
Habe ich gerade heruntergeladen und erfolgreich entpackt.
Moin,
wie
:'(
Zitatupdate in FHEM vergessen
:-\
Natürlich, ich habe nicht daran gedacht, dass ich dafür ein Update machen muss, danke!
MM
Hi zusammen,
ich habe das Gateway seit Jahren problemlos im Einsatz, es läuft wie ein Uhrwerk, einen großen Dank an den/die Entwickler.
Leider musste ich jetzt erschreckend feststellen, dass noch Version 1.14 läuft.
Die Neuen Funktionen brauche ich nicht, ich will an der Hardware nichts ändern oder anpassen, allerdings ist in dieser Version das Webinterface nicht abgesichert.
...shame on me... aber besser spät als nie...
Nun wollte ich ein Update durchführen. Am einfachsten OTA. Allerdings erscheint im Webinterface nach dem aufrufen ota_start nur die Meldung "failed" und das obwohl ich Fhem so eingerichtet habe, dass die neue Firmware per http erreichbar ist (wenn ich die Adresse im Browsereingebe wird mir ein Download angeboten).
Jemand eine Idee?
Weiterhin habe ich in Fhem das Attribut "attr LaCrosseGateway8266 flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE] "gefunden, weiß aber leider nicht ob das überhaupt noch aktuell nutzbar ist, im Wiki habe ich nichts gefunden.
Hilft nur noch das Gerät platt zu machen und das Fhemdevice sowie das Gateway neu einzurichten, oder gibt es eine Möglichkeit, dass ich alle Einstellungen behalten kann?
Grüße
Hallo,
Zitat von: Doublefant am 03 Oktober 2019, 12:30:20
Nun wollte ich ein Update durchführen. Am einfachsten OTA. Allerdings erscheint im Webinterface nach dem aufrufen ota_start nur die Meldung "failed" und das obwohl ich Fhem so eingerichtet habe, dass die neue Firmware per http erreichbar ist (wenn ich die Adresse im Browsereingebe wird mir ein Download angeboten).
Jemand eine Idee?
fhem aktualsieren und dann
set <LGW> flashZitat von: Doublefant am 03 Oktober 2019, 12:30:20
Weiterhin habe ich in Fhem das Attribut "attr LaCrosseGateway8266 flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE] "gefunden, weiß aber leider nicht ob das überhaupt noch aktuell nutzbar ist, im Wiki habe ich nichts gefunden.
Das ist meines Wissens noch ein Relikt des JeeLinks.
Zitat von: Doublefant am 03 Oktober 2019, 12:30:20
Hilft nur noch das Gerät platt zu machen und das Fhemdevice sowie das Gateway neu einzurichten, oder gibt es eine Möglichkeit, dass ich alle Einstellungen behalten kann?
siehe oben
Gruß Peter
Hi Peter,
danke für die Hilfestellung, leider hat es nicht funktioniert. Fhem update habe ich durchgeführt und anschließend neugestartet.
sobald ich "set LaCrosseGateway8266 flash" eintippe erscheint folgendes in der Console:
flashing JeeLink LaCrosseGateway8266
detected Firmware: LaCrosseGateway.bin
hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
Mode is LaCrosseGateway OTA-update
LaCrosseGateway8266 closed
target: h ttp://xxx.xxx.xxx.xxx/ota/firmware.bin
ERROR: 404 Not FoundLaCrosseGateway8266 opened
Grüße
Doublefant
p.s. das Leerzeichen beim http habe ich nachträglich hier eingefügt damit es nicht als Hyperlink erkannt wird
Zitat von: Doublefant am 03 Oktober 2019, 20:49:40
leider hat es nicht funktioniert.
Häng mal bitte das Ergebnis von
list LaCrosseGateway8266hier an.
sehr gerne:
Internals:
.triggerUsed 1
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF 192.xxx.xxx.xxx:81
DeviceName 192.xxx.xxx.xxx:81
FD 12
FUUID 5c730363-f33f-e904-87cd-789608f9cb1405fc
LaCrosseGateway8266_MSGCNT 15119
LaCrosseGateway8266_TIME 2019-10-04 10:46:50
NAME LaCrosseGateway8266
NR 185
PARTIAL
RAWMSG OK 9 24 1 4 202 49
STATE initialized
TYPE JeeLink
initMessages
model LaCrosseITPlusReader.Gateway.1.14
settings (1=RFM69 f:868315 r:9579) + BMP180 {IP=192.168.1.109}
.attraggr:
.attrminint:
.clientArray:
KeyValueProtocol
LaCrosse
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:
2019-10-04 10:46:50 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
group Gateways
initCommands 868315f 0t 1r 112h v
room 99_System,LaCrosse,Startseite,Wetter
timeout 300,120
Zitat von: Doublefant am 04 Oktober 2019, 10:49:20
sehr gerne:
Internals:
TYPE JeeLink
Dachte ich es mir. Ist noch ein JeeLink device. Das solltest Du durch ein LaCrosseGateway device ersetzen.
https://fhem.de/commandref.html#LaCrosseGateway
Die vier Attribute, die Du dann wieder setzen musst, hast Du ja jetzt schon als Backup hier gespeichert :)
Und dann noch mal "set flash" versuchen, wenn es dann immer noch nicht geht, musst Du wohl oder übel das LGW ein mal per USB auf die aktuelle Version flashen.
Hi,
ich habe das Device in Fhem gelöscht und neu als LaCrosseGateway definiert.
Leider hat sich nichts geändert, die Fehlermeldung ist nun zwar anders formatiert und es steht "...update stated..." in der Console, jedoch kommt direkt darauf folgend wieder die 404 Not Found Meldung. Ergibt für mich keine Sinn, denn ich kann die passende Datei weiterhin über HTTP im Browser runterladen.
Schade, es war ein Versuch wert.
Dann werde ich es doch demontieren und über USB mein Glück versuchen.
Trotzdem vielen Dank für eure Hilfe, tolles Device, keep up the good work! 8)
Hallo zusammen,
zum einen tritt bei mir das gleiche Phänomen wie bei Doublefant auf.
Started not blocking
flashing LaCrosseGateway LGW
hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
Mode is LaCrosseGateway OTA-update
LGW closed
target: http:///dev/ttyUSB1@57600/ota/firmware.bin
Upload started, please wait a minute or two ...
ERROR: 500
No Host option provided at /usr/share/perl5/Net/HTTP/Methods.pm line 40.
LGW opened
Finshed
Zum anderen habe ich hier einen WEMOS im NodeMCU Formfaktor, der keinen Access Point mit der LGW Firmware aufspannt. Demnach müsste GPIO13 (D7) ein High-Level für No-WiFi aufweisen. Das ist aber nicht der Fall. Tosmota z.B. baut einen AP auf. Die Ursache ist mir bisher schleierhaft.
***CLEARLOG***
LaCrosseITPlusReader.Gateway V1.35
Free heap: 29704 Flash size: 4194304 Core: 2_5_0 SDK: 3.0.0-dev(c0f7b44)
Reset: External System
Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
Starting I2C with 400 kHz
SC16IS750 (0x90) found
SubProcessor Reset
Configured altitude: 0
Searching RFMs and Sensors
Radio #1 found: RFM69
Starting wifi
Start WIFI_STA
HostName is: LaCrosseGateway
Using DHCP
We got no connection :-(
AccessPoint: Starting ...
AccessPoint: running, SSID=LaCrosseGateway_14973577
Starting frontend
Starting OTA
Starting data port 1 on 81
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.35 (1=RFM69 f:868300 r:17241) + SC16IS750 (0x90) {IP=192.168.222.1}]
Setup completely done
OK VALUES LGW 14973577 UpTimeSeconds=10,UpTimeText=0Tg. 0Std. 0Min. 10Sek. ,WIFI=,MacAddress=84:F3:EB:E4:7A:89,ReceivedFrames=1,FramesPerMinute=1,RSSI=31,FreeHeap=27048,Version=1.35,LD.Min=0.71,LD.Avg=0.71,LD.Max=1.71,OLED=none
Zitat von: locutus am 05 Oktober 2019, 13:34:38
zum einen tritt bei mir das gleiche Phänomen wie bei Doublefant auf.
Das ist ein anders Problem.
Zitat von: locutus am 05 Oktober 2019, 13:34:38
target: http:///dev/ttyUSB1@57600/ota/firmware.bin
Du hast das LGW per USB angebunden.
Dass es nicht über WiFi das Update machen will, musst Du das Attribut mode auf USB einstellen.
Zitat von: locutus am 05 Oktober 2019, 13:34:38
Zum anderen habe ich hier einen WEMOS im NodeMCU Formfaktor, der keinen Access Point mit der LGW Firmware aufspannt.
Laut Log macht es aber einen auf:
Zitat von: locutus am 05 Oktober 2019, 13:34:38
We got no connection :-(
AccessPoint: Starting ...
AccessPoint: running, SSID=LaCrosseGateway_14973577
[LaCrosseITPlusReader.Gateway.1.35 (1=RFM69 f:868300 r:17241) + SC16IS750 (0x90) {IP=192.168.222.1}]
Laut Log ja, funktechnisch leider nein! Sehr eigenartig, denn x-beliebige andere Firmware auf diesem Wemos stellt einen AP bereit. Messtechnisch kann ich keinen Fehler feststellen. Das Überschreiben des Speichers mit blank_4MB.bin bringt letztlich die LGW-Firmware auch nicht zum Funken.
Hallo,
ich habe seit ein paar Tagen das Problem, dass mein LGW irgendwie nicht richtig funktioniert. Ich kann absolut nicht eingrenzen, wann das genau passiert ist und was ich zuvor gemacht habe.
Das LGW startet neu mit folgender Ausgabe im debug Log:
17:38:15: LaCrosseITPlusReader.Gateway V1.35
17:38:15: Free heap: 28960 Flash size: 4194304 Core: 2_5_0 SDK: 3.0.0-dev(c0f7b44)
17:38:15: Reset: Exception
17:38:15: Fatal exception:29 flag:2 (EXCEPTION) epc1:0x402391b0 epc2:0x00000000 epc3:0x00000000 excvaddr:0x04f5a302 depc:0x00000000
17:38:15: Starting I2C with 400 kHz
17:38:15: Configured altitude: 0
17:38:15: BME280 found
17:38:15: Searching RFMs and Sensors
17:38:15: Radio #1 found: RFM69
17:38:15: Radio #2 found: RFM69
17:38:15: Radio #3 found: RFM69
17:38:15: Starting wifi
17:38:15: Start WIFI_STA
17:38:15: HostName is: FZ-LacrosseGateway
17:38:15: Using static IP
17:38:15: IP: 192.168.x.xx
17:38:15: Mask: 255.255.255.0
17:38:15: Gateway: 192.168.x.xx
17:38:15: Connect 15 seconds to an AP (SSID 1)
17:38:15: .......
17:38:15: connected :-)
17:38:15: SSID: xx
17:38:15: IP: 192.168.x.x
17:38:15: Starting frontend
17:38:15: Starting OTA
17:38:15: Starting data port 1 on 81
17:38:15: Starting data port 2 on 82
17:38:15: Sending init String to FHEM
17:38:15: Setup completely done
17:39:10: DataPort: #81 Client connected, IP=192.168.2.xx Port=44670
und danach startet das LGW neu und es fängt von vorne an...
mein list vom FHEM-Device:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF 192.168.x.xx:81
DeviceName 192.168.x.xx:81
FUUID 5db5a6ce-f33f-61f0-2fe2-446d3764ba8b73dc
FVERSION 36_JeeLink.pm:0.147070/2017-07-13
NAME myJeeLink
NEXT_OPEN 1573316053
NR 48
PARTIAL
RAWMSG OK 9 45 1 3 68 57
STATE disconnected
TYPE JeeLink
initMessages
model LaCrosseITPlusReader.Gateway.1.35
myJeeLink_MSGCNT 617
myJeeLink_TIME 2019-11-09 17:13:11
settings (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + (3=RFM69 f:868300 r:8842) + BME280 {IP=192.168.2.22}
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:
2019-11-09 17:13:13 state disconnected
Attributes:
event-on-change-reading .*
initCommands 1,868960,30i 20000#2r 17241#3r 538h 0a v
room Geräte->JeeLink,z_System->z_Module
timeout 120,60
wenn ich als initCommands nur "538h 0a v" angebe, dann startet das LGW nicht neu, aber ich bekomme keine PCA301 Updates mehr.
Sobald aber als initCommand wieder das "1,868960,30i 20000#2r 17241#3r 538h 0a v" drin ist, statert das LGW neu, sobald FHEM scheinbar den initCommand senden will. Im debugLog sieht man nämlich nicht mehr, dass die Parameter ankommen.
Ich weiß gerade nicht, was ich falsch mache -.-
Ich hoffe, dass ihr mir helfen könnt.
Danke!
Beste Grüße
Andy
edit: habe den kompletten Debug Log vom LGW eingefügt
Zitat von: Andy89 am 09 November 2019, 17:17:49
Ich hoffe, dass ihr mir helfen könnt.
Schwierig, sieht nämlich alles gut und richtig aus.
Was steht denn auf der setup-page vom LGW in der PCA301-Zeile?
Zitat von: HCS am 10 November 2019, 18:15:30
Schwierig, sieht nämlich alles gut und richtig aus.
Was steht denn auf der setup-page vom LGW in der PCA301-Zeile?
sorry, dass ich erst jetzt antworte. habe irgendwie keine Benachrichtigung bekommen... ???
das steht in der PCA301 Zeile:
01A3F5=4,0440F9=2,038439=3,03891A=1,2B8439=3,019DFC=5,038998=6,0355CC=9,06E018=8,0696A1=3,0384F9=3,06B90B=2,0654C0=1,067950=4,13895A=1,0B55CC=7,2B8C39=3,078439=3,038479=19,138439=7,03C539=3,0654C6=8,03D43B=3,039439=3,0451F9=2,0697B1=3,1755CC=7,03C998=6,578439=7,0655C0=1,065EC0=1,0386BB=75,03C439=3
Zitat von: HCS am 10 November 2019, 18:15:30
Schwierig, sieht nämlich alles gut und richtig aus.
Was steht denn auf der setup-page vom LGW in der PCA301-Zeile?
nochmal ich. ich habe die PCA Zeile nun gelöscht. Und meine alte initCommands Konfiguration wieder reingemacht. Und danach konnte ich wieder alle Geräte nach einem statusRequest sehen und schalten.
Danke für den Hinweis mit der PCA301 Zeile :) :) :) :)
Hoppla, jetzt haben doch zwei meiner LGWs kritische Batteriespannung gemeldet :o:
am 12.09.2019: LaCrosse_02: battery: low und
am 14.11.2019: LaCrosse_08: battery: low
Ist das ein Messfehler, oder wird die Spannung gar nicht gemessen?
Danke + Gruß
Peter
Zitat von: PeMue am 18 November 2019, 21:43:17
Ist das ein Messfehler, oder wird die Spannung gar nicht gemessen?
Sensoren wie z.B. die TX29DTH überwachen die Batteriespannung und senden im Protokoll ein Flah mit, wenn sie niedrig ist.
Hatte es gerade letzte Woche bei meiner WS1600 (TX22). Hat "low batt" gesendet. Batterien getauscht und gut war es wieder.
Zitat von: HCS am 19 November 2019, 17:07:08
Sensoren wie z.B. die TX29DTH überwachen die Batteriespannung und senden im Protokoll ein Flah mit, wenn sie niedrig ist.
Jupp, aber LaCrosse_02 sind die Sensoren von meinem LGW :o (und ich dache eigentlich, dass LaCrosse_08 auch so einer ist, ist er aber nicht).
Sprich beim LGW (der von einem USB Netzteil gespeist wird) wird die Versorgungsspannung gemessen und das Flag bei Unterschreiten auch gesetzt?
Danke + Gruß
Peter
Zitat von: PeMue am 19 November 2019, 21:12:46
Jupp, aber LaCrosse_02 sind die Sensoren von meinem LGW :o (und ich dache eigentlich, dass LaCrosse_08 auch so einer ist, ist er aber nicht).
Sprich beim LGW (der von einem USB Netzteil gespeist wird) wird die Versorgungsspannung gemessen und das Flag bei Unterschreiten auch gesetzt?
Nein. Das LGW sendet für seine gemessenen Werte immer LowBatteryFlag=false und NewBatteryFlag=false
Hm mein LGW ist nur paar Minuten auf open danach verliert er die Verbindung .. auch komme ich auf das Webinterface nicht mehr drauf 404 .. jemand eine Idee?
Zitat von: ChrisW am 01 Dezember 2019, 11:30:40
Hm mein LGW ist nur paar Minuten auf open danach verliert er die Verbindung .. auch komme ich auf das Webinterface nicht mehr drauf 404 .. jemand eine Idee?
Meinst Du den AccessPoint, den das LGW öffnet?
Falls ja, ist das normal, der wird nach 15 Minuten wieder geschlossen.
Naja irgendwie läuft es jetzt. Aber Reichweite von meinem sind vielleicht 5m .. einige kann ich ON/ OFF schalten aber bekomme kein Status zurück
Ich möchte das LGW gerne per javascript auslesen, unabhängig von fhem. Bisher mache ich das periodisch über http://xx.xx.xx.xx/getLogData, aber da gibt es regelmäßig timeouts oder socket hang up und auch die Doku sagt, das sollte man nicht machen. Ich würde mich also gerne an Port 81 anflanschen, aber ich finde nirgends eine Dokumentation, wie das Protokoll aussieht. Jemand einen Hinweis?
Hi zusammen,
ich habe da mal eine kurze Frage:
Bei mir läuft eine NODEMCU mit der LaCrosseGateway Firmware. Soweit alles gut. Das Gateway ist in FHEM eingebunden und erfasst auch die meisten Geräte. Aber einige nicht, da die Entfernung wohl zu groß ist.
Nun habe ich ein weiteres Gateway mit einem WEMOS gebastelt. Auch dieser funktioniert gut und erfasst die anderen Geräte.
Als Empfänger habe ich bei beiden Gateways ein RFC69 Modul eingebaut, der im Togglemodus LaCrosse Geräte und EC3000 Stromzähler erkennt.
Ich habe irgendwo gelesen, dass man eine ID anpassen muss? Ist das wirklich notwendig? Soweit läuft bei mir nun alles - auch ohne "andere" ID.
Danke.
Gruß
Hermann
Zitat von: hermann1514 am 10 Dezember 2019, 12:20:45
Ich habe irgendwo gelesen, dass man eine ID anpassen muss?
Wüsste nicht, was man da anpassen soll. Wo steht das denn?
Keine Ahnung, was da gemeint ist.
Zitat von: fhem_mit_blick am 09 Dezember 2019, 20:39:47
Ich möchte das LGW gerne per javascript auslesen, unabhängig von fhem. Bisher mache ich das periodisch über http://xx.xx.xx.xx/getLogData, aber da gibt es regelmäßig timeouts oder socket hang up und auch die Doku sagt, das sollte man nicht machen. Ich würde mich also gerne an Port 81 anflanschen, aber ich finde nirgends eine Dokumentation, wie das Protokoll aussieht. Jemand einen Hinweis?
Willst du das Logging auslesen oder die Sensordaten, die an FHEM übergeben werden?
Auf den Dataports (also z.B. 81) bekommt man nur die Sensordaten.
Zitat von: HCS am 10 Dezember 2019, 21:41:28
Wüsste nicht, was man da anpassen soll. Wo steht das denn?
Keine Ahnung, was da gemeint ist.
Das hier steht im WIKI...hat aber wohl dann zu meinem Setup keine Auswirkungen - oder?
Internal Sensors "Sensor-ID"
Bei Einsatz von mehr als einem LaCrosseGateway, muss die LaCrosse-ID, mit der die internen Sensoren des Gateways übermittelt werden, angepasst werden. Hierbei ist darauf zu achten, dass die LaCrosse-ID nur einmal auf einer FHEM Instanz vorkommen darf. Die ID kann entweder Dezimal (211) oder Hex (0xD3) angegeben werden.
Detailinformationen: Wenn ein LGW interne Sensoren hat (BME280, BMP180, DHT22, ...) dann sendet es die Daten des Sensors so, als ob es eine Wetterstation wäre (WS 1600 Format) an das LGW. Bisher hat es dafür die Sensor-ID 0 verwendet. Wenn man mehrere LGWs an einem FHEM angebunden hat, dann mischen sich deren Sensor-Daten auf dem LaCrosse device mit der ID 0. Um das zu vermeiden, kann man nun konfigurieren, mit welcher Sensor-ID die internen Sensoren gesendet werden sollen und die beiden LGWs unterschiedlich konfigurieren.
Die Anpassung der LaCrosse-ID hat keinerlei Einfluss auf die Daten, die von den Radios empfangen werden.
Zitat von: hermann1514 am 17 Dezember 2019, 10:33:05
Bei Einsatz von mehr als einem LaCrosseGateway, ...
Hast Du mehr als eins, das interne Sensoren hat?
Zitat von: HCS am 17 Dezember 2019, 12:16:42
Hast Du mehr als eins, das interne Sensoren hat?
Ich habe 2 Gateways mit jeweils einem RFM69....
Zitat von: hermann1514 am 18 Dezember 2019, 10:54:29
Ich habe 2 Gateways mit jeweils einem RFM69....
OK, um es kurz zu erklären:
Ein LGW kann Statusinformationen (Uptime usw.) an FHEM übermitteln.
Dass FHEM weiß, welches LGW es ist, kann man auf der Setup-Page vom LGW die "KV-Identity" konfigurieren, und die sollte bei jedem LGW eine andere sein.
Wenn man Sensoren am LGW angeschlossen hat (BMP180, BME280, ...) dann sendet das LGW die Daten der Sensoren an FHEM als ob es ein LaCrosse Sensor wäre.
LaCross-Sensoren haben eine ID, mit der sie Identifiziert werden.
Die ID, die es für diese Werte sendet, konfiguriert man in "Internal sensors".
Auch die muss bei jedem LGW unterschiedlich sein und darf zusätzich keine sein, die ein LaCrosse-Sensor, den man in Betrieb hat, verwendet.
Alles klar, danke für die Info.
Gruß
Hermann
Hallo,
Zitat von: HCS am 07 September 2019, 21:19:59
V1.34
RFM95
Einstellungen für RFM95 auf der SetupPage
-SpreadingFactor (default SF7)
-Bandbreite (default 125 kHz)
WICHTIG: das LGW unterstützt den RFM95, aber nur für eigene Sensoren.
Für LaCrosse, PCA301, EC3000, usw. wird ein RFM69 benötigt.
wenn ich den RFM95 durch einen RFM69HCW ersetze, geht das auch oder ist dann die max. Sendeleistung zu hoch? Wird das Radio überhaupt erkannt (aber die Syntax sollte zum RFM69CW sehr ähnlich sein)?
Danke + Gruß
Peter
Zitat von: PeMue am 19 Januar 2020, 18:06:29
wenn ich den RFM95 durch einen RFM69HCW ersetze, geht das auch oder ist dann die max. Sendeleistung zu hoch? Wird das Radio überhaupt erkannt (aber die Syntax sollte zum RFM69CW sehr ähnlich sein)?
Habe es nie probiert, aber eigentlich sollte es funktionieren.
Moin,
habe heute auch mal wieder ein Gateway (https://forum.fhem.de/index.php/topic,55705.0.html) in Betrieb genommen, habe aber Probleme das WLAN Netzwerk einzurichten.
Es spannt zwar sein AP auf, aber ich kann mich mit keinem Gerät drauf verbinden. Habe es mit verschiedenen Handys und Tablets getestet.
Habe den Nodemcu schon ein paar mal gelöscht und auch schon ESPEasy drauf gemacht, wo der AP einwandfrei funktioniert. Aber mit der V1.35 bekomme ich es einfach nicht hin.
17:07:20.121 -> LaCrosseITPlusReader.Gateway V1.35
17:26:06.078 -> ***CLEARLOG***
17:26:06.078 -> LaCrosseITPlusReader.Gateway V1.35
17:26:06.078 -> Free heap: 29656 Flash size: 0 Core: 2_5_0 SDK: 3.0.0-dev(c0f7b44)
17:26:06.125 -> Reset: External System
17:26:06.125 -> Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
17:26:06.125 -> Starting I2C with 400 kHz
17:26:06.379 -> SC16IS750 (0x90) found
17:26:07.281 -> Configured altitude: 0
17:26:07.328 -> Searching RFMs and Sensors
17:26:07.328 -> Radio #1 found: RFM69
17:26:07.328 -> Starting wifi
17:26:07.328 -> Start WIFI_STA
17:26:07.382 -> HostName is: LaCrosseGateway
17:26:07.382 -> Using DHCP
17:26:07.382 ->
17:26:07.382 -> We got no connection :-(
17:26:07.382 -> AccessPoint: Starting ...
17:26:07.428 -> AccessPoint: running, SSID=LaCrosseGateway_14253914
17:26:07.428 -> Starting frontend
17:26:07.428 -> Starting OTA
17:26:07.428 -> Starting data port 1 on 81
17:26:07.428 -> Starting serial bridge on port 85 with 38400 baud
17:26:08.431 -> Sending init String to FHEM
17:26:08.431 ->
17:26:08.431 -> [LaCrosseITPlusReader.Gateway.1.35 (1=RFM69 f:868300 r:17241) + SC16IS750 (0x90) {IP=192.168.222.1}]
17:26:08.485 -> Setup completely done
Zitat von: Starsurfer am 04 Februar 2020, 17:14:36
habe heute auch mal wieder ein Gateway (https://forum.fhem.de/index.php/topic,55705.0.html) in Betrieb genommen, habe aber Probleme das WLAN Netzwerk einzurichten.
Es spannt zwar sein AP auf, aber ich kann mich mit keinem Gerät drauf verbinden. Habe es mit verschiedenen Handys und Tablets getestet.
Das ging mir auch so, mit einem Notebook unter Windows 10 funktionierte dann der Connect problemlos.
Ich habe alle Geräte durch, die ich hier mit WLAN habe.
Hat zufällig jemand noch eine V1.30?
Zitat von: Starsurfer am 05 Februar 2020, 09:28:08
Hat zufällig jemand noch eine V1.30?
Ja, SVN hat sie: https://svn.fhem.de/trac/export/14273/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip
Zitat von: Starsurfer am 05 Februar 2020, 09:28:08
Hat zufällig jemand noch eine V1.30?
nimm doch die v1.30 (https://svn.fhem.de/trac/export/14273/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip) aus dem SVN :D
Gruß Peter
Wer sucht, der findet ::)
Zitat von: Starsurfer am 05 Februar 2020, 09:28:08
Ich habe alle Geräte durch, die ich hier mit WLAN habe.
Ich nicht, da wäre ich tagelang beschäftigt ;D 8)
Mit einem Windows 10 Laptop und einem MacBook mit Catalina funktioniert das bei mir ohne Probleme.
Mein Telefon mit Android 9 wollte aber nicht.
Das Problem ist, dass es per DHCP keine IP-Adresse bekommt.
Wenn ich für die Verbindung zum AP dem Telefon eine statische IP konfiguriere (192.168.222.2) dann funktioniert es auch damit.
Kannst es ja mal mit einem Deiner Geräte mit einer statischen IP versuchen.
Mit der v1.30 hat es geklappt.
Danke
Hallo, ich habe mit das LaCrosseGateway auf Lochraster nachhgebaut inkl. Display + RFM69 und bin begeistert wie gut es sofort funktionierte. Hatte bisher immer nur eine Lösung eines selbst gebauten CUL-Sticks bzw. JeeLink am USB-Port. Nun habe ich aber noch ein paar Fragen, die hier im Forum noch nicht gelesen hatte.
1. Ich würde gerne neben dem RFM69 auch einen CC1101 und RFM12 bzw. 12B mit 433 MHz einsetzen um ältere Wetter/Funkempfänger abfragen zu können. Wäre das möglich oder muß es immer ein RFM69 sein. Könnte man den dann ggf. auf 433MHz konfigurieren. - Ich habe auch schon einen RFM12s und RFM12B angeschlossen, allerdings wird er nicht erkannt.
2. Lassen sich wirklich nur die gelisteten Module wie z. B. der DHT22 und nicht andere z.B. auch DHT11 verwenden ?
3. Hat jemand zufällig noch eine Platine übrig oder gibt es in naher Zukunft mal wieder eine Mitbestellungsmöglichkeit ggf. einen Ansprechpartner dafür?
Vielen Dank im Voraus und viele Grüße, Dirk
Zitat von: zie26 am 12 Mai 2020, 08:52:04
1. Ich würde gerne neben dem RFM69 auch einen CC1101 und RFM12 bzw. 12B mit 433 MHz einsetzen um ältere Wetter/Funkempfänger abfragen zu können. Wäre das möglich oder muß es immer ein RFM69 sein. Könnte man den dann ggf. auf 433MHz konfigurieren. - Ich habe auch schon einen RFM12s und RFM12B angeschlossen, allerdings wird er nicht erkannt.
Wird nicht erkannt weil nicht unterstützt. Weder CC1101 noch die 12er werden unterstützt und das LGW kan eh keins der Protokolle, die auf 433 MHz gesendet werden.
Zitat von: zie26 am 12 Mai 2020, 08:52:04
2. Lassen sich wirklich nur die gelisteten Module wie z. B. der DHT22 und nicht andere z.B. auch DHT11 verwenden ?
Der DHT11 sollte auch funktionieren.
Und der BMP180, BME280, BMP280, LM75, SHT75 und BH1750
Zitat von: zie26 am 12 Mai 2020, 08:52:04
3. Hat jemand zufällig noch eine Platine übrig oder gibt es in naher Zukunft mal wieder eine Mitbestellungsmöglichkeit ggf. einen Ansprechpartner dafür?
https://forum.fhem.de/index.php/topic,45594.0.html
Zitat von: HCS am 12 Mai 2020, 09:00:00
Wird nicht erkannt weil nicht unterstützt. Weder CC1101 noch die 12er werden unterstützt und das LGW kan eh keins der Protokolle, die auf 433 MHz gesendet werden.
Der DHT11 sollte auch funktionieren.
Und der BMP180, BME280, BMP280, LM75, SHT75 und BH1750
https://forum.fhem.de/index.php/topic,45594.0.html
Vielen Dank für die schnelle Antwort, wie würde ich denn die Wettersender die auf 433MHZ funken noch erreichen bzw. abfragen können. Habe u.a noch ein Funk-Regenmengenesser WS 7058, der wohl auf 433MHz funkt. Hatte die Idee, die älteren Temperatursender usw. so zu prüfen ob sie überhaupt noch senden und welche Daten sie verschicken. Gibt es da überhaupt noch Unterstützung für 433MHz ? :-[
Zitat von: zie26 am 12 Mai 2020, 09:09:45
Gibt es da überhaupt noch Unterstützung für 433MHz ? :-[
https://wiki.fhem.de/wiki/SIGNALduino
Zitat von: HCS am 12 Mai 2020, 09:12:46
https://wiki.fhem.de/wiki/SIGNALduino
Oh, das ist genau was ich suche, wenn ich die Bwschreibung so lese, vielen Dank für die Unterstützung.
Zitat von: zie26 am 12 Mai 2020, 13:08:04
Oh, das ist genau was ich suche, wenn ich die Bwschreibung so lese, vielen Dank für die Unterstützung.
Eine Frage hätte ich noch zum LaCrosseGateway. Ich habe auch ein kleines OLEd-Display (SSD1306) mit am Gateway,
es zeigt auch immer abwechselnt Temperatur/Luftfeuchte und System an, wie es soll.
Allerdings zeigt er bei der Temperatur und Luftfeuchte nur sporadisch mal die Temperatur des DHT11, welchger verbaut ist an.
Auf der Webgui stehen für den DHT11 immer brav Werte da, sie werden aber nur sehr selten mal im Display angezeigt, 90% kommt 0 °C und 0% Luftfeuchte.
Kann man das irgendwo definieren ggf. auch die im FHEM empfangenen Daten der empfangenen Wettersender ?
Da habe ich in der Beschreibung leider nix gefunden.
Zitat von: zie26 am 14 Mai 2020, 12:09:26
Da habe ich in der Beschreibung leider nix gefunden.
Hast Du hier https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Inbetriebnahme_von_OLED-Display schon mal geschaut?
Gruß Peter
Zitat von: PeMue am 14 Mai 2020, 12:39:09
Hast Du hier https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Inbetriebnahme_von_OLED-Display schon mal geschaut?
Gruß Peter
Hallo Peter, ja das hatte ich mir schon angeschaut und auch schon mal getestet was alles so möglich ist. Beim SSD1306 gibt es ja die Möglichkeit abwechselnd Temperatur/Luftfeuchte usw. anzeigen zu lassen, Das funktioniert generell ja alles, nur warum zeigt er mit vielleicht 10 oder 15 mal 0°C 0% Luftfeuchte und dann kommt mal für 1-3mal die Temperatur des DHT11 ?
Grüße Dirk
Zitat von: zie26 am 14 Mai 2020, 12:55:33
Das funktioniert generell ja alles, nur warum zeigt er mit vielleicht 10 oder 15 mal 0°C 0% Luftfeuchte und dann kommt mal für 1-3mal die Temperatur des DHT11 ?
Hast Du mal die Daten geloggt und angeschaut, ob die Temperatur/Feuchte stimmt? Entweder steigt der Sensor sporadisch aus (dann ist der Log bzw. die Anzeige Null) oder die Anzeige zeigt Null während die Messung sinnvolle Werte anzeigt. Letzteres wäre dann eher ein Softwareproblem, was ich aber bei HCS's Programmier"zaubereien" eher ausschließe ;).
Gruß Peter
Zitat von: PeMue am 14 Mai 2020, 14:30:25
was ich aber bei HCS's Programmier"zaubereien" eher ausschließe ;).
Wir wollen jetzt aber nicht übertreiben :)
Aber mal loggen ist ein guter Plan.
Zitat von: HCS am 14 Mai 2020, 14:35:29
Wir wollen jetzt aber nicht übertreiben :)
Aber mal loggen ist ein guter Plan.
Da würde ich auf jeden Fall zustimmen, ich finde es echt genial was das LaCrosseGateway kann.
Leider bin ich aber bei dem Anzeigeproblem noch nicht wirklich weiter, da ich auch erst auf ein Kontaktproblem,
an dem Sockel des DHT11 dachte, hab ich ihn jetzt fest eingebaut. Ergebnis ist leider das gleiche, er zeigt keine Temperatur/Luftfeuchte oder nur sporadisch. Ich hab mal ein Bild davon drangehangen.
Hallo Dirk,
hast Du denn die Daten schon in FHEM? Wenn ja, logge doch mal für einen kurzen Zeitraum alle Werte mit, um zu schauen, was über die Zeit passiert. Es reicht ja schon ein Blick in die Datei/Datenbank ...
Gruß Peter
Zitat von: PeMue am 14 Mai 2020, 17:02:35
Hallo Dirk,
hast Du denn die Daten schon in FHEM? Wenn ja, logge doch mal für einen kurzen Zeitraum alle Werte mit, um zu schauen, was über die Zeit passiert. Es reicht ja schon ein Blick in die Datei/Datenbank ...
Gruß Peter
Hallo Peter,
ich danke Dir für deine Unterstützung, grundsätzlich habe ich in FHEM die Daten, die der RFM69 empfängt drin. Wenn ich das richtig verstanden hab, empfängt der DHT auf dem Gateway seine Temperatur und Luftfeuchte und das sollte er dann auf dem Display zeigen. Später will ich dann die Daten aus FHEM noch mit ausgeben, das ist aber derzeit noch nicht so wichtig. Im Log sieht man zu den Zeiten, wenn er etwas ausgibt keinen Unterschied zu sonst. Könnte es auch sein, das die Konfiguratioin bzw. die Werte im FHEM die Ausgabe auf dem Gateway-Display behindern oder beeinflussen ? Wäre auch komisch, nur so eine Idee. Grüße Dirk
Zitat von: zie26 am 14 Mai 2020, 22:02:15
Hallo Peter,
ich danke Dir für deine Unterstützung, grundsätzlich habe ich in FHEM die Daten, die der RFM69 empfängt drin. Wenn ich das richtig verstanden hab, empfängt der DHT auf dem Gateway seine Temperatur und Luftfeuchte und das sollte er dann auf dem Display zeigen. Später will ich dann die Daten aus FHEM noch mit ausgeben, das ist aber derzeit noch nicht so wichtig. Im Log sieht man zu den Zeiten, wenn er etwas ausgibt keinen Unterschied zu sonst. Könnte es auch sein, das die Konfiguratioin bzw. die Werte im FHEM die Ausgabe auf dem Gateway-Display behindern oder beeinflussen ? Wäre auch komisch, nur so eine Idee. Grüße Dirk
Ohje, Peter du hattest Recht, wenn die TEmperatur usw. angezwigt werden kommtim Log auf dem Gateway folgeende Zeile:
OK WS 0 4 4 216 40 255 255 255 255 255 255 255 255 0 255 255 255 255 255 255 255 255 255 255 255
Sie kommt dann sehr verschieden oft 2-3mal und dann ist sie wieder weg. Irgendwann erscheint sie wieder und da steht dann auch wieder Temp/Feuchte auf dem Display. Wie bekommt man diese Zeile zustande und vor allem dauerhaft ;-) ?
Grüße, Dirk
Zitat von: zie26 am 15 Mai 2020, 07:25:47
OK WS 0 4 4 216 40 255 255 255 255 255 255 255 255 0 255 255 255 255 255 255 255 255 255 255 255
Das ist das interne Protokoll (Key Value Protokoll) des Gateways, da drin sollten die Werte für die Sensoren (Temperatur, etc.) codiert sein. Warum das Display dann keine Werte anzeigt, da muss ich passen. Welche Firmware hast Du bzw. poste doch mal Deine FHEM Konfiguration.
Gruß Peter
Zitat von: PeMue am 17 Mai 2020, 12:46:59
Das ist das interne Protokoll (Key Value Protokoll) des Gateways, da drin sollten die Werte für die Sensoren (Temperatur, etc.) codiert sein. Warum das Display dann keine Werte anzeigt, da muss ich passen. Welche Firmware hast Du bzw. poste doch mal Deine FHEM Konfiguration.
Gruß Peter
Hallo Peter, ich konnte mittlerweile das Problem lösen. Da ich eh einen BME280 einsetzen wollte hatte ich ihn im Netz bestellt, der ist nun gestern eingetroffen, interessanter Weise funktioniert die Ausgabe auf dem Display, damit nun dauerhaft. Beim DHT war es ja nur sporadisch. Jetzt muß ich nur noch rausbekommen wie ich die Daten aus dem FHEM auf das Diplay zaubere.
Noch eine andere Frage, ich hatte gelesen, das man ggf, einen ArduinioNanao seriell an das Gateway anbinden kann. Funktioniert das direkt, mit RX unb TX oder muz ich das über den I2C SC16IS740 lösen. Würde gerne meinen Signalduino mit CC1101 mit an das Gateway hängen.
Vielen Dank und viele Grüße, Dirk
Zitat von: zie26 am 17 Mai 2020, 17:46:52
Beim DHT war es ja nur sporadisch.
Ich bin mir recht sicher, dass es daran lag, dass Dein DHT11 nur manchmal ein Messergebnis geliefert hat.
Zitat von: zie26 am 17 Mai 2020, 17:46:52
Jetzt muß ich nur noch rausbekommen wie ich die Daten aus dem FHEM auf das Diplay zaubere.
https://forum.fhem.de/index.php/topic,43672.msg471910/topicseen.html#msg471910
Zitat von: zie26 am 17 Mai 2020, 17:46:52
Noch eine andere Frage, ich hatte gelesen, das man ggf, einen ArduinioNanao seriell an das Gateway anbinden kann. Funktioniert das direkt, mit RX unb TX oder muz ich das über den I2C SC16IS740 lösen. Würde gerne meinen Signalduino mit CC1101 mit an das Gateway hängen.
Das geht nur über einen SC16IS740, mit Einschränkungen bei der baut rate.
Zitat von: HCS am 17 Mai 2020, 18:33:54
Ich bin mir recht sicher, dass es daran lag, dass Dein DHT11 nur manchmal ein Messergebnis geliefert hat.
https://forum.fhem.de/index.php/topic,43672.msg471910/topicseen.html#msg471910
Das geht nur über einen SC16IS740, mit Einschränkungen bei der baut rate.
Vielen Dank, da werde ich mal noch rumprobieren. Wenn ich jetzt noch ein RFM69 433MHz Modul mit an das Geteway hänge, sollte ich dann auch die alten 433MHz Wetterstationssender empfangen können oder wird 433MHz gar nicht mehr unterstützt ?
Grüße Dirk
Zitat von: zie26 am 18 Mai 2020, 17:53:28
Wenn ich jetzt noch ein RFM69 433MHz Modul mit an das Geteway hänge, sollte ich dann auch die alten 433MHz Wetterstationssender empfangen können oder wird 433MHz gar nicht mehr unterstützt ?
Nein, das wurde meines Wissens noch nie unterstützt. Du kannst also den Lötkolben kalt lassen ;).
Gruß Peter
Hallo zusammen,
ich benutze schon seit längerer Zeit das LaCrossegateway für meine Thermeter und für die EC3000 Strommessgeräte. Klappt soweit auch gut. Aber:
Ein Gateway ist auf Basis ESP826 mit RFM69 aufgebaut. Da hatte ich zeitweise - und später auch öfters - dass sich das Geteway von FHEM disconnected hat. Ein normales "reopen" in FHEM hat dann geholfen. Die Ausfälle wurden dann später immer öfter, so habe ich mir dann ein weiteres Gateway mit einem WEMOS D1 mini gebaut. Erst sah alles gut aus, aber auch hier disconnected sich das Gateway (unregelmäßig) von FHEM. AUch hier reicht ein einfaches "reopen" in fhem um die Verbindung wieder herszustellen.
Ist das Problem bekannt? Kann ich da was ändern?
Die Geräte sind im WLAN stabil erreichbar.
Vielen Dank für einen Hinweis.
Gruß
Hermann
Zitat von: hermann1514 am 19 Mai 2020, 07:53:14
Ist das Problem bekannt?
Nein. Aber dass das LGW die Verbindung mal verliert, weil das wlan kurz zuckt, kann durchaus passieren.
Zitat von: hermann1514 am 19 Mai 2020, 07:53:14
Ein normales "reopen" in FHEM hat dann geholfen.
Meinst Du mit "reopen" ein set myLGW connect?
Zitat von: hermann1514 am 19 Mai 2020, 07:53:14
Kann ich da was ändern?
Ja, das Attribut timeout im LaCrosseGateway-Device setzen, z.B. auf 60, dann wird die Verbindng automatisch wieder hergestellt.
Siehe Commandref
Hallo zusammen,
ich war ja nun aus diversen Gründen schon länger nicht mehr hier, aber heute dachte ich mir - mach mal ein Firmware Upgrade von LCG1.32 auf LCG1.35. Das funktioniert erstmal gut, aber sobald ich mich mit meiner FHEM Instanz auf das LCG verbinde (WiFi mode) startet dieses neu und die FHEM Instanz kommentiert dies folgerichtig mit 'disconnected'. Nach dem definierten Timeout in der FHEM Instanz verbindet sie sich wieder zum Gateway und hübsch im Loop den nächsten Neustart aus.
Dieses Phänomen konnte ich nun an zwei Gateways nachstellen und traue mich gar nicht die 1.35 auf die weiteren zu bringen.
Hat jemand eine Idee was ich übersehen oder vergessen habe?
Edit: Mit V1.33 trifft dieses Phänomen bei mir noch nicht auf.
Zitat von: waschbaerbauch am 04 Juli 2020, 13:40:38
Hat jemand eine Idee was ich übersehen oder vergessen habe?
Nicht die gerigste. Bei mir laufen alle mit 1.35 ohne jegliches Problem.
Kannst mal ein flash erase probieren und dann komplett neu flashen und konfigurieren.
ich habe das gleiche Problem - ich weiß aber nicht seit wann, da ich nur noch LaCrosse Temperatursensoren mit dem LGW nutze. Bin extra auf v1.33 runter
debug Log
19:55:41: LaCrosseITPlusReader.Gateway V1.33
19:55:41: Free heap: 30312 Flash size: 4194304 Core: 2_5_0 SDK: 3.0.0-dev(c0f7b44)
19:55:41: Reset: Software Watchdog
19:55:41: Fatal exception:4 flag:3 (SOFT_WDT) epc1:0x40201383 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
19:55:41: Starting I2C with 400 kHz
19:55:41: Configured altitude: 0
19:55:41: BME280 found
19:55:41: Searching RFMs and Sensors
19:55:41: Radio #1 found: RFM69
19:55:41: Radio #2 found: RFM69
19:55:41: Radio #3 found: RFM69
19:55:41: Starting wifi
19:55:41: Start WIFI_STA
19:55:41: HostName is: LaCrosseGateway
19:55:41: Using DHCP
19:55:41: Connect 15 seconds to an AP (SSID 1)
19:55:41: .......
19:55:41: connected :-)
19:55:41: SSID: xxx
19:55:41: IP: 192.xx.xx.22
19:55:41: Starting frontend
19:55:41: Starting OTA
19:55:41: Starting data port 1 on 81
19:55:41: Sending init String to FHEM
19:55:41: Setup completely done
19:59:11: LaCrosseITPlusReader.Gateway V1.33
19:59:11: Free heap: 30200 Flash size: 4194304 Core: 2_5_0 SDK: 3.0.0-dev(c0f7b44)
19:59:11: Reset: Software Watchdog
19:59:11: Fatal exception:4 flag:3 (SOFT_WDT) epc1:0x40201383 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
19:59:11: Starting I2C with 400 kHz
19:59:11: Configured altitude: 0
19:59:11: BME280 found
19:59:11: Searching RFMs and Sensors
19:59:11: Radio #1 found: RFM69
19:59:11: Radio #2 found: RFM69
19:59:11: Radio #3 found: RFM69
19:59:11: Starting wifi
19:59:11: Start WIFI_STA
19:59:11: HostName is: LaCrosseGateway
19:59:11: Using DHCP
19:59:11: Connect 15 seconds to an AP (SSID 1)
19:59:11: .......
19:59:11: connected :-)
19:59:11: SSID: xxx
19:59:11: IP: 192.xx.xx.22
19:59:11: Starting frontend
19:59:11: Starting OTA
19:59:11: Starting data port 1 on 81
19:59:11: Sending init String to FHEM
19:59:11: Setup completely done
LGW to FHEM:
9:55:41: [LaCrosseITPlusReader.Gateway.1.33 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + (3=RFM69 f:868300 r:8842) + BME280 {IP=192.xx.x.22}]
19:55:42: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:55:42: OK 9 29 1 4 38 70 [97 44 62 46 97]
19:55:43: OK WS 0 4 5 39 34 255 255 255 255 255 255 255 255 0 3 240 255 255 255 255 255 255 255 255 255
19:55:43: OK VALUES LGW 661226 UpTimeSeconds=10,UpTimeText=0Tg. 0Std. 0Min. 10Sek. ,WIFI=xxx,MacAddress=5C:CF:7F:0A:16:EA,ReceivedFrames=3,FramesPerMinute=3,RSSI=-45,FreeHeap=26968,Version=1.33,LD.Min=12.13,LD.Avg=12.13,LD.Max=12.13,OLED=none
19:55:44: OK 9 25 1 4 214 54 [96 46 38 36 71]
19:55:44: OK 9 45 1 3 116 65 [9B 42 84 41 9B]
19:55:45: OK 9 23 1 4 161 77 [95 C5 85 4D 31]
19:55:46: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:55:47: OK 9 29 1 4 38 70 [97 44 62 46 97]
19:55:49: OK 9 28 1 4 142 89 [97 05 66 59 CD]
19:55:49: OK 9 45 1 3 116 65 [9B 42 84 41 9B]
19:55:50: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:55:52: OK 9 25 1 4 214 55 [96 46 38 37 40]
19:55:53: OK 9 45 1 3 116 65 [9B 42 84 41 9B]
19:55:53: OK WS 0 4 5 38 34 255 255 255 255 255 255 255 255 0 3 240 255 255 255 255 255 255 255 255 255
19:55:53: OK VALUES LGW 661226 UpTimeSeconds=20,UpTimeText=0Tg. 0Std. 0Min. 20Sek. ,WIFI=xxx,ReceivedFrames=13,FramesPerMinute=13,RSSI=-44,FreeHeap=18488,LD.Min=0.54,LD.Avg=0.58,LD.Max=18.89,OLED=none
19:55:54: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:55:54: OK 9 23 1 4 161 77 [95 C5 85 4D 31]
19:55:55: OK 9 29 1 4 38 70 [97 44 62 46 97]
19:55:56: OK 9 25 1 4 214 55 [96 46 38 37 40]
19:55:57: OK 9 28 1 4 142 89 [97 05 66 59 CD]
19:55:58: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:56:00: OK 9 25 1 4 214 55 [96 46 38 37 40]
19:56:02: OK 9 45 1 3 116 65 [9B 42 84 41 9B]
19:56:02: OK 9 23 1 4 161 77 [95 C5 85 4D 31]
19:56:03: OK WS 0 4 5 38 35 255 255 255 255 255 255 255 255 0 3 240 255 255 255 255 255 255 255 255 255
19:56:03: OK VALUES LGW 661226 UpTimeSeconds=30,UpTimeText=0Tg. 0Std. 0Min. 30Sek. ,WIFI=xxx,ReceivedFrames=22,FramesPerMinute=22,RSSI=-43,FreeHeap=21336,LD.Min=0.54,LD.Avg=0.57,LD.Max=19.89,OLED=none
19:56:04: OK 9 29 1 4 38 70 [97 44 62 46 97]
19:56:06: OK 9 28 1 4 142 89 [97 05 66 59 CD]
19:56:06: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:56:09: OK 9 25 1 4 214 55 [96 46 38 37 40]
19:56:10: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:56:10: OK 9 23 1 4 161 77 [95 C5 85 4D 31]
19:56:10: OK 9 45 1 3 116 65 [9B 42 84 41 9B]
19:56:12: OK 9 29 1 4 38 69 [97 44 62 45 C4]
19:56:13: OK 9 25 1 4 214 54 [96 46 38 36 71]
19:56:13: OK WS 0 4 5 38 35 255 255 255 255 255 255 255 255 0 3 240 255 255 255 255 255 255 255 255 255
19:56:13: OK VALUES LGW 661226 UpTimeSeconds=40,UpTimeText=0Tg. 0Std. 0Min. 40Sek. ,WIFI=xxx,ReceivedFrames=31,FramesPerMinute=31,RSSI=-44,FreeHeap=14160,LD.Min=0.54,LD.Avg=0.58,LD.Max=19.01,OLED=none
19:56:14: OK 9 28 1 4 142 89 [97 05 66 59 CD]
19:56:14: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:56:17: OK 9 29 1 4 38 70 [97 44 62 46 97]
19:56:17: OK 9 25 1 4 214 54 [96 46 38 36 71]
19:56:18: OK 9 8 1 4 146 106 [92 05 70 6A FA]
19:56:19: OK 9 23 1 4 161 77 [95 C5 85 4D 31]
19:56:19: OK 9 45 1 3 116 65 [9B 42 84 41 9B]
19:56:21: OK 9 29 1 4 38 69 [97 44 62 45 C4]
19:56:21: OK 9 25 1 4 214 55 [96 46 38 37 40]
19:56:22: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:56:22: OK 9 28 1 4 142 89 [97 05 66 59 CD]
19:56:23: OK WS 0 4 5 38 35 255 255 255 255 255 255 255 255 0 3 240 255 255 255 255 255 255 255 255 255
19:56:23: OK VALUES LGW 661226 UpTimeSeconds=50,UpTimeText=0Tg. 0Std. 0Min. 50Sek. ,WIFI=xxx,ReceivedFrames=42,FramesPerMinute=42,RSSI=-44,FreeHeap=4368,LD.Min=0.54,LD.Avg=0.56,LD.Max=18.87,OLED=none
19:56:25: OK 9 29 1 4 38 69 [97 44 62 45 C4]
19:56:25: OK 9 25 1 4 214 55 [96 46 38 37 40]
19:56:26: OK 9 8 1 4 146 106 [92 05 70 6A FA]
19:56:27: OK 9 23 1 4 161 77 [95 C5 85 4D 31]
19:56:28: OK 9 45 1 3 116 65 [9B 42 84 41 9B]
19:56:29: OK 9 29 1 4 39 69 [97 44 63 45 30]
19:56:30: OK 9 25 1 4 214 54 [96 46 38 36 71]
19:56:30: OK 9 8 1 4 146 106 [92 05 70 6A FA]
19:56:31: OK 9 28 1 4 142 89 [97 05 66 59 CD]
19:56:33: OK WS 0 4 5 38 35 255 255 255 255 255 255 255 255 0 3 240 255 255 255 255 255 255 255 255 255
19:56:33: OK VALUES LGW 661226 UpTimeSeconds=60,UpTimeText=0Tg. 0Std. 1Min. 0Sek. ,WIFI=xxx,ReceivedFrames=51,FramesPerMinute=51,RSSI=-44,FreeHeap=8952,LD.Min=0.54,LD.Avg=0.56,LD.Max=17.78,OLED=none
19:56:33: OK 9 29 1 4 38 69 [97 44 62 45 C4]
19:56:34: OK 9 25 1 4 214 54 [96 46 38 36 71]
19:56:34: OK 9 8 1 4 146 106 [92 05 70 6A FA]
19:56:35: OK 9 23 1 4 161 77 [95 C5 85 4D 31]
19:56:36: OK 9 45 1 3 116 65 [9B 42 84 41 9B]
19:56:37: OK 9 29 1 4 39 69 [97 44 63 45 30]
19:56:38: OK 9 25 1 4 214 55 [96 46 38 37 40]
19:56:38: OK 9 8 1 4 146 106 [92 05 70 6A FA]
19:56:39: OK 9 28 1 4 142 89 [97 05 66 59 CD]
19:59:11: [LaCrosseITPlusReader.Gateway.1.33 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + (3=RFM69 f:868300 r:8842) + BME280 {IP=192.xx.xx.22}]
19:59:12: OK 9 8 1 4 146 106 [92 05 70 6A FA]
19:59:13: OK 9 45 1 3 121 64 [9B 42 89 40 EA]
19:59:13: OK 9 25 1 4 214 55 [96 46 38 37 40]
19:59:14: OK WS 0 4 5 37 35 255 255 255 255 255 255 255 255 0 3 240 255 255 255 255 255 255 255 255 255
19:59:14: OK 9 29 1 4 42 70 [97 44 66 46 14]
19:59:14: OK VALUES LGW 661226 UpTimeSeconds=10,UpTimeText=0Tg. 0Std. 0Min. 10Sek. ,WIFI=xxx,MacAddress=5C:CF:7F:0A:16:EA,ReceivedFrames=5,FramesPerMinute=5,RSSI=-46,FreeHeap=26056,Version=1.33,LD.Min=36.53,LD.Avg=36.53,LD.Max=36.53,OLED=none
19:59:14: OK 9 23 1 4 161 77 [95 C5 85 4D 31]
19:59:15: OK 9 28 1 4 142 89 [97 05 66 59 CD]
19:59:16: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:59:17: OK 9 45 1 3 121 64 [9B 42 89 40 EA]
19:59:19: OK 9 29 1 4 42 70 [97 44 66 46 14]
19:59:21: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:59:22: OK 9 25 1 4 214 55 [96 46 38 37 40]
19:59:23: OK 9 29 1 4 42 70 [97 44 66 46 14]
19:59:23: OK 9 23 1 4 161 77 [95 C5 85 4D 31]
19:59:24: OK 9 28 1 4 142 89 [97 05 66 59 CD]
19:59:24: OK WS 0 4 5 37 35 255 255 255 255 255 255 255 255 0 3 240 255 255 255 255 255 255 255 255 255
19:59:24: OK VALUES LGW 661226 UpTimeSeconds=20,UpTimeText=0Tg. 0Std. 0Min. 20Sek. ,WIFI=xxx,ReceivedFrames=15,FramesPerMinute=15,RSSI=-46,FreeHeap=20320,LD.Min=0.54,LD.Avg=0.65,LD.Max=19.76,OLED=none
19:59:25: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:59:26: OK 9 45 1 3 121 64 [9B 42 89 40 EA]
19:59:27: OK 9 29 1 4 43 70 [97 44 67 46 E0]
19:59:29: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:59:30: OK 9 25 1 4 214 55 [96 46 38 37 40]
19:59:31: OK 9 45 1 3 122 64 [9B 42 90 40 47]
19:59:31: OK 9 29 1 4 43 69 [97 44 67 45 B3]
19:59:31: OK 9 23 1 4 161 77 [95 C5 85 4D 31]
19:59:32: OK 9 28 1 4 142 89 [97 05 66 59 CD]
19:59:33: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:59:34: OK WS 0 4 5 37 34 255 255 255 255 255 255 255 255 0 3 240 255 255 255 255 255 255 255 255 255
19:59:34: OK VALUES LGW 661226 UpTimeSeconds=30,UpTimeText=0Tg. 0Std. 0Min. 30Sek. ,WIFI=xxx,ReceivedFrames=25,FramesPerMinute=25,RSSI=-46,FreeHeap=14880,LD.Min=0.54,LD.Avg=0.58,LD.Max=30.15,OLED=none
19:59:35: OK 9 45 1 3 121 64 [9B 42 89 40 EA]
19:59:35: OK 9 29 1 4 43 69 [97 44 67 45 B3]
19:59:37: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:59:39: OK 9 25 1 4 214 55 [96 46 38 37 40]
19:59:39: OK 9 45 1 3 122 64 [9B 42 90 40 47]
19:59:40: OK 9 29 1 4 43 70 [97 44 67 46 E0]
19:59:41: OK 9 28 1 4 142 89 [97 05 66 59 CD]
19:59:41: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:59:44: OK 9 29 1 4 43 70 [97 44 67 46 E0]
19:59:44: OK 9 45 1 3 122 64 [9B 42 90 40 47]
19:59:44: OK WS 0 4 5 38 35 255 255 255 255 255 255 255 255 0 3 240 255 255 255 255 255 255 255 255 255
19:59:44: OK VALUES LGW 661226 UpTimeSeconds=40,UpTimeText=0Tg. 0Std. 0Min. 40Sek. ,WIFI=xxx,ReceivedFrames=35,FramesPerMinute=35,RSSI=-46,FreeHeap=17912,LD.Min=0.54,LD.Avg=0.58,LD.Max=22.03,OLED=none
19:59:46: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:59:47: OK 9 25 1 4 214 55 [96 46 38 37 40]
19:59:48: OK 9 23 1 4 161 77 [95 C5 85 4D 31]
19:59:48: OK 9 29 1 4 43 70 [97 44 67 46 E0]
19:59:48: OK 9 45 1 3 122 64 [9B 42 90 40 47]
19:59:49: OK 9 28 1 4 142 89 [97 05 66 59 CD]
19:59:49: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:59:53: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:59:54: OK WS 0 4 5 38 34 255 255 255 255 255 255 255 255 0 3 240 255 255 255 255 255 255 255 255 255
19:59:54: OK VALUES LGW 661226 UpTimeSeconds=50,UpTimeText=0Tg. 0Std. 0Min. 50Sek. ,WIFI=xxx,ReceivedFrames=43,FramesPerMinute=43,RSSI=-47,FreeHeap=12656,LD.Min=0.54,LD.Avg=0.57,LD.Max=22.41,OLED=none
19:59:55: OK 9 25 1 4 214 55 [96 46 38 37 40]
19:59:56: OK 9 23 1 4 161 77 [95 C5 85 4D 31]
19:59:56: OK 9 29 1 4 44 70 [97 44 68 46 79]
19:59:57: OK 9 45 1 3 122 64 [9B 42 90 40 47]
19:59:57: OK 9 8 1 4 145 106 [92 05 69 6A 57]
19:59:57: OK 9 28 1 4 142 89 [97 05 66 59 CD]
20:00:00: OK 9 29 1 4 44 70 [97 44 68 46 79]
ein erase_flash und neuflashen von v1.33 mit neuer Initialisierung brachte mir keinen Erfolg :(
Kann ich sonst irgendwie helfen, den Fehler zu finden?
Beste Grüße
Andy
edit:
diesmal ein anderer Fehler:
20:08:17: Fatal exception:28 flag:2 (EXCEPTION) epc1:0x40235882 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
edit:
in Grafana hab ich mir mal die LaCrosse Daten angeschaut und das Problem ist seit dem 19.6. da - falls dir dieser Zeitpunkt etwas bringt....
Zitat von: Andy89 am 08 Juli 2020, 20:00:54
edit:
in Grafana hab ich mir mal die LaCrosse Daten angeschaut und das Problem ist seit dem 19.6. da - falls dir dieser Zeitpunkt etwas bringt....
Wann wurde das letzte FHEM-Update durchgeführt?
Die Frage gilt auch für den waschbaerbauch
Wenn ich das edit von waschbaerbauch richtig interpretiere, geht es mit 1.33 auch nicht.
Gestern habe ich das Update gemacht. Habe mittlerweile wieder auf v1.35 geupdatet nach einem erase_flash, aber auch mit ständigen Reboots
Zitat von: Andy89 am 10 Juli 2020, 05:17:27
Gestern habe ich das Update gemacht. Habe mittlerweile wieder auf v1.35 geupdatet nach einem erase_flash, aber auch mit ständigen Reboots
FHEM-Update habe ich auch gestern gemacht, da haben wir also den gleichen Stand.
Verwendest Du auf FHEM-Seite das LaCrosseGateway-Modul oder das jeelink-Modul?
Zitat von: HCS am 10 Juli 2020, 07:08:52
FHEM-Update habe ich auch gestern gemacht, da haben wir also den gleichen Stand.
Verwendest Du auf FHEM-Seite das LaCrosseGateway-Modul oder das jeelink-Modul?
das jeelink Modul - vielleicht sollte ich auf das LGW Modul wechseln.
Ich habe mal die UpTimeSeconds vom KeyValueProtocol des LGW geplottet - komisch ist, dass die Zeiten deutlich kürzer sind, wenn jemand zuhause ist.
Zitat von: Andy89 am 10 Juli 2020, 14:27:06
das jeelink Modul - vielleicht sollte ich auf das LGW Modul wechseln.
Das solltes Du auf alle Fälle machen.
Zitat von: Andy89 am 10 Juli 2020, 14:27:06
Ich habe mal die UpTimeSeconds vom KeyValueProtocol des LGW geplottet - komisch ist, dass die Zeiten deutlich kürzer sind, wenn jemand zuhause ist.
Seltsam. Hast wohl einen negativen Einfluss auf RISC Prozessoren ;D
ich habe nun auf das LGW Modul gewechselt:
defmod myJeeLink LaCrosseGateway 192.xxx.xxx.22:81
attr myJeeLink event-on-change-reading .*
attr myJeeLink initCommands 17241#1r 60h 1d v
attr myJeeLink kvp both
attr myJeeLink room Geräte->JeeLink,z_System->z_Module
attr myJeeLink timeout 120,60
attr myJeeLink usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE] 2>&1
scheinbar habe ich den negativen Einfluss aber dennoch ;D ich habe gestern nach meinem Beitrag auf das LGW Modul geändert, jedoch hat das nichts gebracht. Ich kann nun auch nicht ausschließen, ob das nicht schon Ewigkeiten so ist, denn die 5 LaCrosse Temperatursensoren haben dennoch einen schönen Plot. Und da ich keine PCA301 mehr darüber schalte, fällt es einfach nicht mehr auf, wenn das LGW neustartet.
Gibt es einen Wert im LGW, den ich mir näher anschauen sollte?
Zitat von: Andy89 am 11 Juli 2020, 08:26:24
attr myJeeLink initCommands 17241#1r 60h 1d v
Nimm mal aus den initCommands das 1d raus.
Zitat von: Andy89 am 11 Juli 2020, 08:26:24
Gibt es einen Wert im LGW, den ich mir näher anschauen sollte?
Dein LGW bezieht die IP per DHCP.
Ändere das mal auf der Setup-Page vom LGW auf eine statische IP.
Also IP-Address, Netmask und Gateway eintragen.
Außer, dass ich eine statische IP verwende, sehe ich jetzt keinen Unterschied mehr zwichen unseren Setups.
Übrigens, ein klein wenig länger bis zum ersten reboot ist eigentlich schon denkbar, siehe angehängen SchirmSchuss von einem meiner LGWs ;)
Zitat von: HCS am 09 Juli 2020, 22:38:02
Wann wurde das letzte FHEM-Update durchgeführt?
Die Frage gilt auch für den waschbaerbauch
Wenn ich das edit von waschbaerbauch richtig interpretiere, geht es mit 1.33 auch nicht.
Sorry war anderweitig beschäftigt.
Ich habe ein FHEM brandneu als Docker aufgesetzt und eine Bestandsinstallation. Aktualisiert wurden beide Instanzen am 04.07.2020.
Beide Installationen verhalten sich gleich.
Version 1.32 läuft, alles darüber nicht. Ich dachte zuerst V1.33 läuft, aber ich konnte keine einwandfreie Funktion nachstellen. Daher hatte ich das Edit wieder gestrichen.
ZitatVerwendest Du auf FHEM-Seite das LaCrosseGateway-Modul oder das jeelink-Modul?
LaCrosseGateway-Modul
Init LCG1:
1,868950,120i 9579#2r
Init LCG2:
1,868950,120i 9579#2r 0a
Init LCG3:
1,868950,120i 9579#2r 17241#3r 0a
00:47:20: LaCrosseITPlusReader.Gateway V1.35
00:47:20: Free heap: 28976 Flash size: 4194304 Core: 2_5_0 SDK: 3.0.0-dev(c0f7b44)
00:47:20: Reset: Exception
00:47:20: Fatal exception:29 flag:2 (EXCEPTION) epc1:0x402391a3 epc2:0x00000000 epc3:0x00000000 excvaddr:0x02687303 depc:0x00000000
00:47:20: Starting I2C with 400 kHz
00:47:20: Configured altitude: 17
00:47:20: BMP180 found
00:47:20: Searching RFMs and Sensors
00:47:20: Radio #1 found: RFM69
00:47:20: Radio #2 found: RFM69
00:47:20: Starting wifi
00:47:20: Start WIFI_STA
00:47:20: HostName is: PROD-LCG-UG-BB
00:47:20: Using static IP
00:47:20: IP: 192.168.6.55
00:47:20: Mask: 255.255.254.0
00:47:20: Gateway: 192.168.6.1
00:47:20: Connect 15 seconds to an AP (SSID 1)
00:47:20: ..............
00:47:20: connected :-)
00:47:20: SSID: ARMAGEDDON
00:47:20: IP: 192.168.6.55
00:47:20: Starting frontend
00:47:20: Starting OTA
00:47:20: Starting data port 1 on 81
00:47:20: Starting data port 2 on 82
00:47:20: Starting data port 3 on 85
00:47:20: Sending init String to FHEM
00:47:20: Setup completely done
Zitat von: waschbaerbauch am 12 Juli 2020, 00:20:55
Version 1.32 läuft, alles darüber nicht. Ich dachte zuerst V1.33 läuft, aber ich konnte keine einwandfreie Funktion nachstellen. Daher hatte ich das Edit wieder gestrichen.
ich habe jetzt auch mal auf v1.32 gewechselt und seit 4:22h läuft das LGW ohne Probleme. Was mir gleichzeitig aufgefallen ist, ist dass der FreeHeap nahetz konstant ist und sich nicht so stark verändert. Ich hab mal ein Screenshot angehängt.
Moin
Nur mal so als Idee, da ich ja auch ewig Probleme hatte!
Ist Euer Netzwerk OK? Ich hatte einen Stoerer drin, der aus irgendeinem Grund den Verkehr behindert hat, aber nur teilweise.
Seitdem das weg ist, laufen meine LGWs ohne Aussetzer. Ich wundere mich immer wieder wenn ich an dem Einen vorbeilaufe und immer noch alles ok auf dem Display ist!
Gruss Christoph
Zitat von: pc1246 am 14 Juli 2020, 14:21:27
Ist Euer Netzwerk OK? Ich hatte einen Stoerer drin, der aus irgendeinem Grund den Verkehr behindert hat, aber nur teilweise.
ich würde sagen ja, aber komplett ausschließen kann ich das natürlich nicht. Wie bist du denn an deinen Störer gekommen?
Beste Grüße
Andy
Zitat von: pc1246 am 14 Juli 2020, 14:21:27
Ist Euer Netzwerk OK? Ich hatte einen Stoerer drin, der aus irgendeinem Grund den Verkehr behindert hat, aber nur teilweise.
Kann man natürlich nicht zu 100% sagen/ausschließen, aber alles Andere läuft wie Butter und es ist hier für mich sehr einfach nachzustellen wann das Problem auftritt (V1.33 und höher) und wann nicht mehr (V1.32). Sobald eine FHEM Instanz auf ein Gateway zugreift/verbindet wird vom Gateway ein Reboot ausgelöst. Man kann es auf dem OLED auch gut verfolgen, Symbol für FHEM Verbindung taucht auf und es rebootet.
Zitat von: waschbaerbauch am 14 Juli 2020, 22:24:36
Kann man natürlich nicht zu 100% sagen/ausschließen, aber alles Andere läuft wie Butter und es ist hier für mich sehr einfach nachzustellen wann das Problem auftritt (V1.33 und höher) und wann nicht mehr (V1.32). Sobald eine FHEM Instanz auf ein Gateway zugreift/verbindet wird vom Gateway ein Reboot ausgelöst. Man kann es auf dem OLED auch gut verfolgen, Symbol für FHEM Verbindung taucht auf und es rebootet.
ist bei mir exakt genauso (nur ohne Display). Seit 3,1 Tagen läuft das LGW nun unter v1.32 stabil ohne Reconnect
Hallo HCS,
zwischen welchen Firmwareversionen hast Du die Arduino IDE (sehe ich eher unkritisch) bzw. die ESP8266 Board Version geändert? Ich habe den Fall, dass beim Optolink der Access Point nur bis v2.5.0 (https://github.com/pemue-git/vitotronic_interface#notes-on-compiling) aufgemacht wird. Vielleicht haben wir hier etwas in einer ähnlichen Richtung?
Gruß Peter
Okay ich habe jetzt einen komplett frischen nodeMCU genommen und https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin?rev=20162 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin?rev=20162) diese Firmware geflashed. Jetzt kann ich ohne Probleme verbinden und es wird kein Reboot ausgelöst ??? :o
PS: Ich habe es mit dem ESP Easy Flasher geschafft :D
Was mir hierbei noch aufgefallen ist:
- Die IP Adresse zur Konfiguration lautet nicht mehr 192.168.222.1 sondern 192.168.244.1
- Nach dem initialen eintragen der WiFi Daten kann man speichern und restarten, aber man muss manuell resetten am nodeMCU - später funktioniert es
- Die Data Ports 82 und 83 fehlen in der Grundkonfiguration
PPS: Es wird natürlich nach dieser Reihenfolge auch kein Reboot mehr ausgelöst ;)
Ein weiteres LGW ließ sich zwar löschen und flashen, aber irgendwie zickt der DHCP bei der Vergabe der IP Adresse - kann aber auch an meinem Handy liegen - ich prüfe ;)
PC mit WiFi geht und macht auch 192.168.222.1 statt dem erwarteten 192.168.244.1 wie beim ersten Gateway ???
PS: Keine Ahnung warum, aber es rebootet trotzdem - ich werde weiter testen, sobald ich Gelegenheit habe ..
Zitat von: waschbaerbauch am 15 Juli 2020, 22:35:04
Okay ich habe jetzt einen komplett frischen nodeMCU genommen und https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin?rev=20162 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin?rev=20162) diese Firmware geflashed. Jetzt kann ich ohne Probleme verbinden und es wird kein Reboot ausgelöst ??? :o
Das ist ja spannend. Was ist denn der Unterschied zwischen dem neuen und dem "gebrauchten" NodeMCU?
Zitat von: waschbaerbauch am 15 Juli 2020, 22:35:04
- Die IP Adresse zur Konfiguration lautet nicht mehr 192.168.222.1 sondern 192.168.244.1
Lt. Quellcode ist es immer noch 192.168.222.1
Zitat von: waschbaerbauch am 15 Juli 2020, 22:35:04
- Nach dem initialen eintragen der WiFi Daten kann man speichern und restarten, aber man muss manuell resetten am nodeMCU - später funktioniert es
Ja, passiert manchmal, ist ein uralter ESP8266 core bug.
Zitat von: waschbaerbauch am 15 Juli 2020, 22:35:04
- Die Data Ports 82 und 83 fehlen in der Grundkonfiguration
Das ist gewollt. Kaum jemand benötigt mehr als einen Data Port und da macht es keinen Sinn, dass dann gleich drei davon konfiguriert sind und vor sich hinarbeiten.
Zitat von: PeMue am 15 Juli 2020, 16:24:45
zwischen welchen Firmwareversionen hast Du die Arduino IDE (sehe ich eher unkritisch) bzw. die ESP8266 Board Version geändert?
Ab LGW 1.33 ist es Core 2.5.0
Ich vermute mal, dass das Problem aus den Tiefen des Cores kommt, weil sich von 1.32 -> 1.33 eigentlich nichts geändert hat, das da eine Rolle spielen würde.
@waschbaerbauch: ich habe es jetzt einfach mal gegen den Core 2.7.2 compiliert. Kannst Du den angehängten Test mal auf das "gebrauchte" NodeMCU flashen, das die Probleme macht?
Nachtrag: das ist eine Test-Version. Wer die verwendet ist dann ggf. selbst schuld gewesen ;) :)
Werde ich gleich mal testen.
Die frische kam 'von mir bisher unbespielt' aus meinem kleinen Lagerbestand ;)
Die gebrauchte ist schon einige Monde mit der V1.32 und den Vorgängern in Betrieb gewesen.
Warum das so ist kann ich nicht sagen, aber ich bin ja stets gewillt Ursachenforschung zu betreiben.
Der Unterschied beim zweiten Gateway mit identischer Vorgehensweise leuchtet mir halt nicht so ein, aber dann musste ich halt auch mal zu Bett.
Melde mich sobald ich die Test Binary geflasht habe.
@HCS
das Gateway rebootet nicht mehr, allerdings initialisiert auch nix mehr..
PS: Zwei Verbindungen rebooten auch nicht, aber kein initialized.
Zitat von: waschbaerbauch am 17 Juli 2020, 21:28:48
das Gateway rebootet nicht mehr, allerdings initialisiert auch nix mehr..
Kann ich nicht nachvollziehen.
Habe ein LGW sinngem. wie deins zusammengestöpselt.
- Altes NodeMCU das schon alles Mögliche drauf hatte
- zwei Radios
- initCommands für PCA301 und 9579
- Die Test-1.36 von hier drauf: https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=138588
Funktioniert, initialisiert und up seit 2 Tagen 19 Stunden
Hmm, ich habe da ein Problem mit dem Update...
Wollte die 1.36-Test flashen.
Also habe ich die LaCrosseGateway_1.36_Test.bin runtergeladen und nach FHEM/firmware/ kopiert. Rechte geprüft / gesetzt, anschließend nach JeeLink_LaCrosseGateway.bin kopiert.
Daran anschließend "set flash" im LCG-Device ausgeführt.
Ergebnis:
2020-07-23 10:23:44.948 Global global Started not blocking
2020-07-23 10:23:44.978 Global global flashing LaCrosseGateway LCG.miniCUL433
2020-07-23 10:23:45.002 Global global hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
2020-07-23 10:23:45.028 Global global Mode is LaCrosseGateway OTA-update
2020-07-23 10:23:45.061 Global global LCG.miniCUL433 closed
2020-07-23 10:23:45.084 Global global target: http://192.168.254.63/ota/firmware.bin
2020-07-23 10:23:45.113 Global global Upload started, please wait a minute or two ...
2020-07-23 10:23:59.083 Global global
2020-07-23 10:23:59.106 Global global --- LGW reports ---------------------------------------------------------------------------
2020-07-23 10:23:59.129 Global global Start receiving 'firmware.bin'
2020-07-23 10:23:59.149 Global global ERROR: UPLOAD_FILE_WRITE
2020-07-23 10:23:59.169 Global global ERROR: UPLOAD_FILE_WRITE
2020-07-23 10:23:59.188 Global global ERROR: UPLOAD_FILE_WRITE
2020-07-23 10:23:59.210 Global global ERROR: UPLOAD_FILE_WRITE
2020-07-23 10:23:59.230 Global global ERROR: UPLOAD_FILE_WRITE
2020-07-23 10:23:59.249 Global global ERROR: UPLOAD_FILE_END
2020-07-23 10:23:59.268 Global global
2020-07-23 10:23:59.288 Global global ERROR: OTA update failed
2020-07-23 10:23:59.310 Global global ----------------------------------------------------------------------------------------------------
2020-07-23 10:23:59.364 Global global LCG.miniCUL433 opened
2020-07-23 10:23:59.384 Global global Finshed
Wieder die 1.35 nach JeeLink_LaCrosseGateway.bin kopiert und "set flash":
2020-07-23 10:31:24.618 Global global Started not blocking
2020-07-23 10:31:24.647 Global global flashing LaCrosseGateway LCG.miniCUL433
2020-07-23 10:31:24.671 Global global hex file: ./FHEM/firmware/JeeLink_LaCrosseGateway.bin
2020-07-23 10:31:24.695 Global global Mode is LaCrosseGateway OTA-update
2020-07-23 10:31:24.723 Global global LCG.miniCUL433 closed
2020-07-23 10:31:24.746 Global global target: http://192.168.254.63/ota/firmware.bin
2020-07-23 10:31:24.772 Global global Upload started, please wait a minute or two ...
2020-07-23 10:31:38.973 Global global
2020-07-23 10:31:39.004 Global global --- LGW reports ---------------------------------------------------------------------------
2020-07-23 10:31:39.024 Global global Start receiving 'firmware.bin'
2020-07-23 10:31:39.044 Global global Firmware size: 519664
2020-07-23 10:31:39.066 Global global Rebooting ESP8266 ...
2020-07-23 10:31:39.085 Global global
2020-07-23 10:31:39.105 Global global OTA update finished
2020-07-23 10:31:39.126 Global global ----------------------------------------------------------------------------------------------------
2020-07-23 10:31:39.161 Global global LCG.miniCUL433 opened
2020-07-23 10:31:39.203 Global global Finshed
LCG kommt jetzt mit 1.35 hoch.
Wo klemmt es hier?
Zitat von: SusisStrolch am 23 Juli 2020, 10:34:54
Wo klemmt es hier?
Das Problem ist, dass der Core von der "Menge Programm" größer geworden ist und beim OTA-Update die hochgeladene Firmware nicht mehr ins SPIFFS passt.
Habe nur noch keine Lösung gefunden.
Mit dieser Version (die es ja gar nicht gibt) geht aktuell nur flashen per USB
Ok, dachte ich mir bereits.
Danke für die Info.
Zitat von: waschbaerbauch am 14 Juli 2020, 22:24:36
Kann man natürlich nicht zu 100% sagen/ausschließen, aber alles Andere läuft wie Butter und es ist hier für mich sehr einfach nachzustellen wann das Problem auftritt (V1.33 und höher) und wann nicht mehr (V1.32). Sobald eine FHEM Instanz auf ein Gateway zugreift/verbindet wird vom Gateway ein Reboot ausgelöst. Man kann es auf dem OLED auch gut verfolgen, Symbol für FHEM Verbindung taucht auf und es rebootet.
Moin und sorry fuer die spaete Antwort
Gekommen bin ich darauf, als ich immer wieder Probleme hatte einige Netzwerkswitche zu administrieren.
Dann habe ich sukzessiv alles ausgeschaltet bis der Spuk vorbei war. Was mir vorher aber schon lange aufgefallen war, schrieb ich glaube ich auch in diesem Thred, das Fritzbox-WLAN.
Seitdem ich das verbannt habe bin ich wesentlich zufriedener! Es haengt stark mit der Anzahl der Teilnehmer zusammen, wenige FB super, viele FB Schrott!
Ich habe zwei LGWs am Laufen mit 1.33 und die schmieren so gut wie nie ab. Frueher eigentlich staendig!
Gruss Christoph
Hallo Zusammen,
mir ist nach einem Reset der EC3000 Steckdose aufgefallen, dass der Internals "SecontsON" auf 4096 steht und von da an gezählt wird sobalt der Verbraucher dran ist.
Das Bedeutet auch, wenn an der Steckdose während des resets berteits etwas angeschlossen ist, und dieser Verbraucher ist immer am laufen, ist der Wert SecontsON immer größer als der Wert secondsTotal ist.
Vermuttlich passiert das in LGW, weil wenn ich mir den Log anschaue steht es nur in dem Anteil das an FHEM gesendet wird (0 0 16 0) aber nicht in den emfangenen Daten (eckige Klammern).
15:47:43: OK 22 43 219 0 0 5 132 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 05 84 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 09 FA 47]
15:47:44: OK 22 43 219 0 0 3 199 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 03 C7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 0C F1 87]
15:47:44: OK 22 43 219 0 0 3 204 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 03 CC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 08 8C 87]
15:47:44: OK 22 43 219 0 0 3 209 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 03 D1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 0C 24 D7]
15:47:44: OK 22 43 219 0 0 3 214 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 03 D6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 01 06 77]
15:47:54: OK 22 43 219 0 0 5 142 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 05 8E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 04 8A 77]
15:48:20: OK 22 43 219 0 0 5 157 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 05 9D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 0A 67 77]
15:48:20: OK 22 43 219 0 0 5 162 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 05 A2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 05 20 D7]
15:48:24: OK 22 43 219 0 0 5 152 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 05 98 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 04 5F 27]
15:48:32: OK 22 43 219 0 0 5 177 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 05 B1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 0B CD D7]
15:48:34: OK 22 43 219 0 0 5 137 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 05 89 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 09 A8 D7]
15:48:34: OK 22 43 219 0 0 5 182 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 05 B6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 06 EF 77]
15:48:36: OK 22 43 219 0 0 5 147 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 05 93 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 00 22 27]
15:48:43: OK 22 43 219 0 0 5 192 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 05 C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 0F 25 37]
15:48:44: OK 22 43 219 0 0 5 187 0 0 16 0 0 0 0 0 0 0 0 0 21 0 [2B DB 05 BB 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 50 06 BD E7]
Zitat von: w6s8 am 09 Februar 2021, 16:19:12
mir ist nach einem Reset der EC3000 Steckdose aufgefallen, dass der Internals "SecontsON" auf 4096 steht und von da an gezählt wird sobalt der Verbraucher dran ist.
Das Bedeutet auch, wenn an der Steckdose während des resets berteits etwas angeschlossen ist, und dieser Verbraucher ist immer am laufen, ist der Wert SecontsON immer größer als der Wert secondsTotal ist.
Kann ich nicht nachvollziehen.
Habe gerade an einer EC3000, an der konstant ca. 80-85W gezogen wird, einen Reset gemacht, also so lange auf den Leuchtbutton gedrückt, bis er aufgehört hat zu blinken und konstant geleuchtet hat.
Danach haben secondsOn und secondsTotal beide bei 0 begonnen.
Siehe angehängten ScreenShot.
Mehrmals versucht, immer OK.
Werde aber trotzdem mal das Programm studieren, ob es irgend eine Situation geben kann, in der das auftritt.
Danke!
Ich habe gerade noch ein reset gemacht (Screenshot 2021-02-12 084324.png) und bei mir ist es da, wieso auch immer.
Die Werte im Log von LGW (Screenshot 2021-02-12 084848.png) passen doch auch nicht zusammen, oder?
Meine Eckdaten: WeMos D1 MINI mit LaCrosseGateway V1.35
Die Komponente: 1=RFM69 f:868310 r:20000) + BMP180 + DHT22 + OLED
Ich werde versuchen am Wochenende einfach einzelne Komponenten abzuklemen, ob das etwas bringt.
so, ich habe etwas experementiert: Sobald OLED-Display nicht mehr angeschlossen ist, werden die korrekten Werte geliefert.
Dann habe ich einen anderen (aber gleichen) OLED angeschlossen und der Fehler war wieder da.
Vielleicht hilft das beim suchen.
beim Display handelt es sich um ganz normalen 0,96'', 2 Farbigen (Gelb/Blau) i2c OLED mit fester Adresse 0x78 aus China
Ich nutze das LacrosseGateway nun schon recht lange (ca. 3 Jahre wenn ich mich nicht irre) und habe das Problem, dass es sich immer mal wieder aufhängt und dann so lange keine Daten mehr aufzeichnet, bis ich es bemerke und neu starte. Das kann Wochen und Monate dauern, bis ich mal wieder wissen will wie kalt es draussen ist ohne raus gehen zu müssen und fest stelle, dass schon lange keine Daten mehr kommen.
Ich habe nun vor ein paar Tagen die aktuelle Firmware aufgespielt und einen Nagios-Monitor auf die IP-Adresse und HTTP Port 80 gesetzt. Der antwortet aber immer noch, liest nur keine Werte mehr (Status in fhem "disconnected"). Das Attribut timeout ist auf 120,30 gesetzt, hilft aber nicht, genauso wenig wie ein reboot über fhem.
Habt Ihr eine Idee wie ich das debuggen kann oder wenigstens einen halbwegs brauchbaren nagios Monitor drauf setzen?
Ich nutze den in Verbindung mit zwei RFM69 (einer für Lacrosse Sensoren, einer für EC3000) und einem DHT22 - der ESP ist ein AFAIR originaler NodeMCU, gesockelt, Netzteil irgendein Handynetzteil, das 1,5A liefern kann. Ich würde das ganze gerne demnächst mit einem OLED Display, einem dritten RFM69 für PCA301 und einem seriellen Port für meine ETA Heizung (lese ich derzeit direkt vom Banana Pi aus) versehen, aber erstmal muss das stabil laufen.
Irgendwelche Ideen für Debugging?
Aus dem Log:
2021.02.14 12:51:12 1: 192.168.50.13:81 disconnected, waiting to reappear (myLGW)
2021.02.14 12:53:22 1: 192.168.50.13:81 reappeared (myLGW)
2021.02.14 14:50:52 1: 192.168.50.13:81 disconnected, waiting to reappear (myLGW)
2021.02.14 14:52:52 1: 192.168.50.13:81 reappeared (myLGW)
2021.02.14 15:12:05 1: 192.168.50.13:81 disconnected, waiting to reappear (myLGW)
2021.02.14 15:14:22 1: 192.168.50.13:81 reappeared (myLGW)
2021.02.14 15:54:46 1: [Freezemon] myFreezemon: possible freeze starting at 15:54:45, delay is 1.001 possibly caused by: tmr-LaCrosseGateway_OnConnectTimermyLGW)
2021.02.14 19:08:08 1: [Freezemon] myFreezemon: possible freeze starting at 19:08:07, delay is 1.004 possibly caused by: tmr-LaCrosseGateway_OnConnectTimermyLGW) tmr-HMLAN_KeepAlive(HMLAN1)
2021.02.14 22:45:42 1: [Freezemon] myFreezemon: possible freeze starting at 22:45:41, delay is 1.001 possibly caused by: tmr-HMLAN_KeepAlive(HMLAN1) tmr-LaCrosseGateway_OnConnectTimer(myLGW)
2021.02.15 06:59:49 3: Opening myLGW device 192.168.50.13:81
2021.02.15 06:59:50 1: myLGW: Can't connect to 192.168.50.13:81: Connection timed out
2021.02.15 07:14:55 1: 192.168.50.13:81 reappeared (myLGW)
Letztes Lebenszeichen vom Sensor war gestern 15:18:
2021-02-14_15:17:27 Seitenterasse temperature: 0.6
2021-02-14_15:18:19 Seitenterasse battery: ok
2021-02-14_15:18:19 Seitenterasse temperature: 0.6
2021-02-15_07:15:35 Seitenterasse battery: ok
2021-02-15_07:15:35 Seitenterasse temperature: -9.6
2021-02-15_07:15:35 Seitenterasse T: -9.6
2021-02-15_07:16:27 Seitenterasse battery: ok
2021-02-15_07:16:27 Seitenterasse temperature: -9.6
Moin
Erstmal kurz zum Posten: Ueber den Smilies ist eine Raute ( # ) damit kann man solche Log-Auszuege in Codetags setzen. Das freut alle Mitleser, und besonders die am Handy! Das geht auch nachtraeglich!
Zu Deinem Problem, wie ist denn Deine WLAN Konfiguration? Bei mir hat sich das extrem verbessert, seitdem ich von der Fritzbox weg bin! Die hat das Problem mit "vielen" Teilnehmern!
Keiner weiss genau was "viel" ist, aber viele erleben das Problem!
Meine beiden haben ein Display, und wenn ich da vorbeigehe, und sehe, dass wieder mal das eine Symbol nicht da ist, dann greife ich ein. Aber seit dem Weggang von der FB ist das massiv weniger geworden. Meistens nur dann wenn das Netz, durch Router-update, weg ist. Dann gibt es wohl keinen reconnect.
Gruss Christoph
Zitat von: schmadde am 15 Februar 2021, 16:30:25
Habt Ihr eine Idee wie ich das debuggen kann oder wenigstens einen halbwegs brauchbaren nagios Monitor drauf setzen?
Nö, keine Ahnung von nagios.
Die Frage ist erst mal, was da überhaupt passiert, also ob das LGW tatsächlich aussteigt oder einfach nicht mehr erreichbar ist.
Mit den aktuellen Mitteln sollte man eigentlich einen Fehlertoleranten Betrieb hinbekommen.
Dazu gibt es die Attribute timeout und watchdog
Beispiel:
attr lgw209 timeout 120
attr lgw209 watchdog 1200timeout 120 legt fest, dass FHEM alle 120 Sekunden das LGW anfrägt, "ob es noch lebt"
Das LGW antwortet mit einem "ich lebe noch"
Wenn die Antwort ausbleibt, wird die Verbindung zum LGW geschlossen und neu aufgebaut.
watchdog 1200 legt fest, dass das LGW, wenn 1200 Sekunden lang keine "lebst Du noch" Anfrage von FHEM gekommen ist, es sich selbst rebootet.
Die beiden Werte kann man in sinnvollen Grenzen nach den eigenen Bedürfnissen festlegen.
Überwachung: da wäre (keine Ahnung, wie man das in nagios macht) das denkbar:
Auf der Setup-page vom LGW einen zweiten DataPort (z.B. 82) öffnen
Auf diesem schickt das LGW alle Daten, die an FHEM gehen, parallel raus.
Einen TCP-Client auf den Port 82 setzen und die eingehenden Daten mitlesen
Wenn z.B. eine gewisse Zeit keine Zeile mehr kommt, die mit "OK 22" beginnt, dann wird kein EC3000 mehr empfangen.
Oder die "LGW ALIVE" Meldungen auswerten, das ist die Antwort auf die "Lebst Du noch?" Anfrage von FHEM.
In meinem Fall (siehe Anhang) ist timout auf 30 gesetzt, was aber für einen "Normalbetrieb" etwas zu kurz ist.
Beispiel, was (ist ein Test-LGW, das nur EC3000 empfängt) da so an Daten kommen sollte ist angehängt.
Ich habe einen Unifi UAP-AC-Pro Accesspoint der Sichtkontakt zum LGW hat und keine 5 Meter entfernt ist. Ich schliesse ein Problem dort eher aus. Es gibt zwar noch eine alte Fritzbox, deren 2,4GHz WLAN als secondary definiert ist, die ist aber 2 Stockwerke weiter oben und hat kaum Empfang und da ist auch nichts mehr angeschlossen ausser dem LAN Kabel und keine User aktiv - die dient nur dem dortigen Fernseher als AP, bis die Unifi 6 LR wieder lieferbar sind.
Ich gebe zu, dass Debugging mit so wenig Infos nicht möglich ist, aber kann man das irgendwie sinnvoll monitoren?
Zitat von: schmadde am 15 Februar 2021, 17:42:50
Ich gebe zu, dass Debugging mit so wenig Infos nicht möglich ist, aber kann man das irgendwie sinnvoll monitoren?
Du hast meinen Beitrag übersehen?
Zitat von: HCS am 15 Februar 2021, 17:39:55
Die Frage ist erst mal, was da überhaupt passiert, also ob das LGW tatsächlich aussteigt oder einfach nicht mehr erreichbar ist.
Wenn ich das so genau wüsste - Ich weiss nur, dass das LGW auf HTTP Anfragen auf Port 80 noch korrekt antwortet. Dieser Nagios-Monitor liefert jedenfalls immer noch o.k. zurück.
Aber im FHEM ist es "disconnected".
timeout habe ich schon auf "120,30" gesetzt, das hat nix geholfen. Ich habe jetzt auch den watchdog gesetzt und hoffe das hilft.
Zitat von: schmadde am 15 Februar 2021, 17:48:00
timeout habe ich schon auf "120,30" gesetzt, das hat nix geholfen. Ich habe jetzt auch den watchdog gesetzt und hoffe das hilft.
Und das ",30" dann aus timeout rausgenommen?
Siehe auch https://fhem.de/commandref.html#LaCrosseGateway
Zitat von: HCS am 15 Februar 2021, 17:51:23
Und das ",30" dann aus timeout rausgenommen?
Siehe auch https://fhem.de/commandref.html#LaCrosseGateway
Moin
Das lese ich heute zum ersten Mal!
Siehe auch im Wiki: https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Reconnect
Das koennte so einiges erklaeren!
Gruss Christoph
Zitat von: pc1246 am 15 Februar 2021, 20:11:14
Das lese ich heute zum ersten Mal!
Hatte ich schon mal gelesen :)
https://forum.fhem.de/index.php/topic,43672.msg546877/topicseen.html#msg546877
Aber das Wiki wäre wohl anzupasen, da brauchen wir dann wieder mal jemand, der sich aufopfert :)
Zitat von: HCS am 15 Februar 2021, 17:51:23
Und das ",30" dann aus timeout rausgenommen?
Siehe auch https://fhem.de/commandref.html#LaCrosseGateway
Ja, habe ich, vielen Dank für die Tipps. Das Monitoring auf Port 82 lässt sich so mit nagios nicht umsetzen. Ich finde leider auch kein passendes Pattern im fhem-logfile auf das ich check_logfile ansetzen könnte. Evtl. kann ich den "Freezemon" eine Mail schicken lassen, da muss ich mich mal wieder tiefer in fhem reingraben.
Noch eine Frage zum SC16IS750 Serial Port: den muss ich einfach mit SPI Kabel anschliessen, ggfs in Reihe zu einem OLED Display, das noch dazukommt, auf der Platine ist kein Platz dafür vorgesehen? Gibts irgendwelche Beispiele wie ich den seriellen Port aus einem FHEM Modul oder einem externen Script ansprechen kann? Ich habe aktuell ein Perl Script das noch nicht in FHEM integriert ist mit dem ich meine Heizung auslesen kann und konnte sie auch mal steuern. Ich habe aber immer wieder Probleme mit den USB-Serial Konvertern und wollte eigentlich einen Arduino oder ESP32 mit einem richtigen UART dranhängen, aber jetzt wo ich gesehen habe, dass das LGW eine Serielle Schnittstelle übers Netz bereitstellen kann würde ich erstmal das versuchen. Ist das möglich?
Zitat von: schmadde am 15 Februar 2021, 16:30:25
2021.02.14 12:51:12 1: 192.168.50.13:81 disconnected, waiting to reappear (myLGW)
2021.02.14 12:53:22 1: 192.168.50.13:81 reappeared (myLGW)
2021.02.14 14:50:52 1: 192.168.50.13:81 disconnected, waiting to reappear (myLGW)
2021.02.14 14:52:52 1: 192.168.50.13:81 reappeared (myLGW)
2021.02.14 15:12:05 1: 192.168.50.13:81 disconnected, waiting to reappear (myLGW)
2021.02.14 15:14:22 1: 192.168.50.13:81 reappeared (myLGW)
Dieser Auzug aus dem Log sieht übrigens eher nach WiFi-Zirkus aus.
Der Arduini-Core oder eher das darunterliegende Espressif-IDF hatte definitiv Probleme im Bereich WiFi.
In den letzten Versionen wurde da aber einiges gemacht.
Weiter oben hat es auch schon mal von irgend jemand die vorhandenen WiFi-Probleme beseitigt.
Ich kann mal ein LGW gegen den aktuellen Core 2.7.4 compiliert bereitstellen, dann könntest Du schauen, ob es stabiler wird.
Allerdings habe ich damit noch das Problem, dass der 2.7.4 Core größer geworden ist und man aktuell nicht per OTA von LGW 1.35 auf 1.36 kommt.
Diese Version müsste man also per USB auf das LGW hochladen.
Zitat von: schmadde am 16 Februar 2021, 08:25:15
Noch eine Frage zum SC16IS750 Serial Port: den muss ich einfach mit SPI Kabel anschliessen, ggfs in Reihe zu einem OLED Display, das noch dazukommt
Parallel zum OLED, nicht in Reihe, siehe auch hier: https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Variante:_DEVKIT_1.0_Maximalausbau
Und es ist I2C und nicht SPI
Zitat von: schmadde am 16 Februar 2021, 08:25:15
Gibts irgendwelche Beispiele wie ich den seriellen Port aus einem FHEM Modul oder einem externen Script ansprechen kann? Ich habe aktuell ein Perl Script das noch nicht in FHEM integriert ist mit dem ich meine Heizung auslesen kann und konnte sie auch mal steuern. Ich habe aber immer wieder Probleme mit den USB-Serial Konvertern und wollte eigentlich einen Arduino oder ESP32 mit einem richtigen UART dranhängen, aber jetzt wo ich gesehen habe, dass das LGW eine Serielle Schnittstelle übers Netz bereitstellen kann würde ich erstmal das versuchen. Ist das möglich?
Ich befürchte, dass das nichts wird. Das LGW stellt die serielle Schnittstelle des SC16IS750 auf einem TCP-Port bereit.
Um sie zu nutzen, muss irgend etwas als TCP-Client damit arbeiten. Dein Script müsste also einen TCP-Client implementieren, der mit dem Port vom LGW kommuniziert.
Der UseCase ist eigentlich eher, dass man etwas wie einen CUL an den SC16IS750 hängt und das entsprechende FHEM-Modul ihn dann verwendet.
Eine Serielle Schnittstelle, die dann auf einem Rechner wieder als solche bereitgetsellt wird (also so, wie es die gängigen USB->TCP Ports machen) war und ist nicht der Plan.
Und ich glaube, dass so etwas besser für Dein Vorhaben geeignet wäre.
Zitat von: HCS am 16 Februar 2021, 08:04:42
Hatte ich schon mal gelesen :)
https://forum.fhem.de/index.php/topic,43672.msg546877/topicseen.html#msg546877
Aber das Wiki wäre wohl anzupasen, da brauchen wir dann wieder mal jemand, der sich aufopfert :)
Moin
Okay, dass das schon so lange da steht!? Kurze Frage noch, 2016 hast Du geschrieben, dass man das mit dem Komma behalten kann. In der commandref taucht das gar nicht mehr auf.
Geht/ging es trotzdem noch?
Gruss Christoph
Zitat von: pc1246 am 16 Februar 2021, 09:48:08
Okay, dass das schon so lange da steht!? Kurze Frage noch, 2016 hast Du geschrieben, dass man das mit dem Komma behalten kann. In der commandref taucht das gar nicht mehr auf.
Geht/ging es trotzdem noch?
Ja, die alte Variante geht auch noch, taugt aber halt nicht so arg.
In der commandref wollte ich niemand neu dazu animieren, die alte Variante noch in Betrieb zu setzen.
Zitat von: HCS am 16 Februar 2021, 09:00:03
Dieser Auzug aus dem Log sieht übrigens eher nach WiFi-Zirkus aus.
Der Arduini-Core oder eher das darunterliegende Espressif-IDF hatte definitiv Probleme im Bereich WiFi.
In den letzten Versionen wurde da aber einiges gemacht.
Weiter oben hat es auch schon mal von irgend jemand die vorhandenen WiFi-Probleme beseitigt.
Ich kann mal ein LGW gegen den aktuellen Core 2.7.4 compiliert bereitstellen, dann könntest Du schauen, ob es stabiler wird.
Welchen Arduino Core sollte man denn auf dem NodeMCU/ESP8266 haben? Ich nehme mal an, der wird nicht mitgeflasht beim OTA Update vom LGW. Bei mir ist wenn ich das richtig interpretiere 2.5.0 drauf, ich habe daran noch nie was gemacht, sollte der neuer sein und wo bekomme ich ihn her (bin ESP Newbie).
Grade ist das LGW wieder abgeschmiert, diesmal hat es nichtmal mehr gepingt. Ich hab jetzt mal ein stärkeres Netzteil hingehangen (5V 3A) und werde ein Display einlöten um zu sehen wieviel da noch lebt.
Zitat von: HCS am 16 Februar 2021, 09:00:03
Der UseCase ist eigentlich eher, dass man etwas wie einen CUL an den SC16IS750 hängt und das entsprechende FHEM-Modul ihn dann verwendet.
Eine Serielle Schnittstelle, die dann auf einem Rechner wieder als solche bereitgetsellt wird (also so, wie es die gängigen USB->TCP Ports machen) war und ist nicht der Plan.
Und ich glaube, dass so etwas besser für Dein Vorhaben geeignet wäre.
Hm. o.k. dann werde ich wohl doch einen extra Arduino oder ESP hernehmen. Doof nur, dass man den einzigen UART meist nicht sinnvoll verwenden kann weil der fürs Flashen und debuggen gebraucht wird. Das Problem hatte ich auch schon am Raspberry an dem die Heizung aktuell hängt. Netzverbindung bräuchte ich nichtmal, weil das serielle Kabel der Heizung bis ins Serverrack reicht.
Zitat von: schmadde am 16 Februar 2021, 10:32:20
Welchen Arduino Core sollte man denn auf dem NodeMCU/ESP8266 haben? Ich nehme mal an, der wird nicht mitgeflasht beim OTA Update vom LGW.
Da muss man genau nichts machen, das ist in die Firmware reincompiliert und wird somit auch mit geflasht.
Zitat von: schmadde am 16 Februar 2021, 10:32:20
Grade ist das LGW wieder abgeschmiert, diesmal hat es nichtmal mehr gepingt. Ich hab jetzt mal ein stärkeres Netzteil hingehangen (5V 3A) und werde ein Display einlöten um zu sehen wieviel da noch lebt.
Ja, mach mal.
Dass es ständig stirbt ist eher nicht normal.
Ich habe LGWs schon Monate laufen gehabt, verbinden sich halt ab und zu mal neu mit WiFi, weil die Verbindung weg war, aber das war es dann.
Ich mache die Tage mal eine LGW 1.36 Beta, must sie dann nur per USB flashen, sonst ist nichts weiter zu tun.
@w6s8: Das OnSeconds-Problem habe ich auch gefunden, hat nichts mit dem OLED zu tun, ist eher Zufall.
Das behebe ich auch mal in der oben angekündigten Beta.
@schmadde: anbei eine Beta LGW 1.36
Kann man nicht per OTA auf das LGW hochladen, nur per USB
Kannst mal damit testen, ob Deine Probleme weg sind oder weniger werden.
Bei mir ist sie jetzt fast 9 Tage ohne crash, reconnect oder sonstwas gelaufen und empfängt aktuell 7 Stück EC3000
Das LGW besteht (auf einem Breadbord zusammengestöpselt) aus einem NodeMCU-Board + RFM69CW + 0.96" OLED
@w6s8: Das OnSeconds-Problem ist in dieser Version auch behoben.
Danke, ich werde die FW dann hochladen, wenn das LGW das nächste mal ausfällt. Aktuell läuft es stabil, seit ich das stärkere Netzteil hingehangen habe. Empfängt über zwei RFM69CW Neun EC3000 Steckdosen und drei Lacrosse Sensoren. Beim nächsten Absturz werde ich das Display einlöten und evtl noch ein drittes Funkmodul für die PCA301 Dosen die hier noch rumliegen.
@HCS: Danke! Ich habe die LGW_1_36_Beta.bin aufgespielt und es sieht gut aus!
Meins ist heute mal wieder abgestürzt, habe nun die 1.36 geflasht (musste mich mal wieder richtig ärgern über apples "alle software muss von uns kommen" mantra) und hoffe das läuft stabiler.
Stürzt leider immer noch 1x am Tag ab, keine Ahnung warum. Ich möchte mir jetzt ein neues LGW löten mit der zweiten Platine die ich noch habe und dann mit Display, 3. Radio und BME280 statt DHT22.
In meiner Bastelkiste sind noch 4 RFM69C Radios. Die WIKI seite spricht immer von RFM69CW - was ist der Unterschied, kann ich die trotzdem nehmen?
Zitat von: schmadde am 03 April 2021, 18:01:43
In meiner Bastelkiste sind noch 4 RFM69C Radios. Die WIKI seite spricht immer von RFM69CW - was ist der Unterschied, kann ich die trotzdem nehmen?
Sicher, dass es keine CW sind?
Auf der bedruckten Seite, wo der Typ steht, ist ein Rechteck mit einem W dahinter.
Ist in dem Rechteck eine Markierung?
Sollte aber so oder so gehen.
Zitat von: HCS am 04 April 2021, 09:16:01
Sicher, dass es keine CW sind?
Auf der bedruckten Seite, wo der Typ steht, ist ein Rechteck mit einem W dahinter.
Ist in dem Rechteck eine Markierung?
Sollte aber so oder so gehen.
Sicher bin ich nicht, drum frag ich ja. Aber da ist ein Rechteck mit einem W dahinter und keine Markierung. Also wohl kein "CW" - wo ist der Unterschied?
Habe mal ein Bild angehängt.
https://lowpowerlab.com/wp-content/uploads/2016/09/LowPowerLab_transceivers-1.png
Hier sieht man schön, das C und CW einen anderen Formfaktor haben.
Zitat von: gloob am 04 April 2021, 15:20:40
https://lowpowerlab.com/wp-content/uploads/2016/09/LowPowerLab_transceivers-1.png
Hier sieht man schön, das C und CW einen anderen Formfaktor haben.
Ich seh auf dem Bild überhaupt keinen RFM69C, meiner hat auch den passenden formfaktor. Ich Werde es einfach ausprobieren.
Zitat von: gloob am 04 April 2021, 15:20:40
https://lowpowerlab.com/wp-content/uploads/2016/09/LowPowerLab_transceivers-1.png
Hier sieht man schön, das C und CW einen anderen Formfaktor haben.
Die C und "nicht C" Modelle haben eine unterschiedliche Form.
Das C steht für Compatible und bedeutet, dass es die gleiche Form wir ein RFM12 hat.
Ich glaube (mehr aber nicht), dass ich mal gelesen habe, dass das W für Worldwide delivery steht, was immer es bedeuten mag.
Ich habe hier aber auch welche in Benutzung, die keine W-Markierung haben. Funktionieren.
Stimmt ihr habt recht. Hab irgendwie rein C und W verwechselt.
Jetzt nochmal eine dumme Frage, weil ichs diesmal richtig machen will: Der BME280 scheint so zur Montage vorgesehen zu sein, dass die Druckdose (und vermutlich das Ding das die Temperatur misst) nach unten zeigt und so zwischen beinen Platinen hängt - gibt das nicht einen Hitzestau der die Messwerte verfälscht? Bzw: seit ich den Gehäusedeckel auf meinem "alten" LGW mit dem DHT22 drauf habe messe ich auch zu hohe Temperaturen, vermutlich muss ich noch Lüftungslöcher vorsehen.
Wie habt Ihr das gemacht? Ich nutze die schwarzen Gehäuse für die die LGW Platine designed ist, glaube von Reichelt waren die. Es ist recht schwierig hier saubere und optisch ansprechende Löcher reinzubekommen, schon der Micro-USB-Port sieht abenteuerlich aus :(
Gibts da einen Trick, montiert Ihr die Sensoren extern oder wie habt Ihr das Problem gelöst?
EDIT: und noch eine Frage die ich mir nicht selbst beantworten konnte: ich möchte einen BME280 und ein SD1306 Display anschliessen, ich finde aber nur 1x SDA/SCL beschriftet auf der Platine. Gibts da irgendeinen zweiten Abgriff oder muss ich das irgendwie vom Sensormodul durchschleifen? Geht das überhaupt?
Zitat von: schmadde am 05 April 2021, 16:25:41
Gibts da einen Trick, montiert Ihr die Sensoren extern oder wie habt Ihr das Problem gelöst?
Extern ist der einzige Weg, die Temepratur zu messen, die außerhalb vom Gehäuse herrscht.
Alles andere ergibt zu hohe Werte.
Zitat von: schmadde am 05 April 2021, 16:25:41
1x SDA/SCL beschriftet auf der Platine. Gibts da irgendeinen zweiten Abgriff oder muss ich das irgendwie vom Sensormodul durchschleifen? Geht das überhaupt?
Ein mal I2C (also SCL und SDA) von der Platine abgreifen und alle I2C-Sensoren parallel dran.
Jetzt muss ich leider noch ein paar Fragen loswerden, die ich in der Wiki-Seite nicht beantwortet gefunden habe. Ich habe diese Platine jetzt mit einem nackten ESP-12E Modul bestückt und nicht mit einem NodeMCU. Offenbar sollte man sich da besser auskennen, bevor man das versucht, aber jetzt isses nunmal drauf. Folgende Fragen sind dabei aufgetaucht:
- Man braucht offenbar einen Spannungsregler damit die 5V aus der Micro-USB Buchse am ESP ankommen. Ich vermute, das Ding kommt auf die Rückseiten nach "IC1C", richtig? Welches Modell in welcher Baugröße nimmt man da?
- Ich sehe auf dem Bild der Platine einiges "Gemüse" bestückt - was muss alles bestückt sein und welche Teile genau braucht man da?
- zum Flashen muss dann GPIO0 auf GND gezogen werden? Sonst noch was? Ein USB-Serial Converter mit 3,3V Pegel ist hier richtig? Auf welchen Wert muss man den Parameter "cd" beim esptool setzen?
Und noch was hat mich beschäftigt: für die LED1 habe ich eine 1206 aus der Kiste hernehmen wollen. Die scheint zu groß, welche Größe soll da rein? und auf welcher Seite sind Anode und Kathode?
Danke schonmal
EDIT: Habe es in der Stückliste aus dem anderen Thread https://forum.fhem.de/index.php/topic,45594.0.html gefunden. Das meiste jedenfalls.
Ob man beim Flashen noch irgendwas kurzsschliessen muss ist mir allerdings noch nicht ganz klar.
Hi,
gibt es eigentlich die Möglichkeit, dass das Lacrosse Gateway direkt die Daten per MQTT liefern kann?
Gruß
Hermann
Zitat von: hermann1514 am 12 April 2021, 10:34:36
gibt es eigentlich die Möglichkeit, dass das Lacrosse Gateway direkt die Daten per MQTT liefern kann?
Nein.
Hi Forum.
Da ich nur ,,Nutzer" bin eine kurze Frage:
Kann mir jemand ein wlan Gateway verkaufen mit dem ich pca Steckdosen und Lacrosse Sensoren abgreifen kann für mein fhem.
Danke.
Ich bin da auf ein kleines Problem gestoßen:
wenn ich meine Temperatur-Feuchte-Sensoren anlege, bekommen sie eine Adresse und die wird in der fhem.cfg gespeichert. Wenn ich nun die Batterie tausche und dies per replaceBatteryForSec einleite, wird eine neue Adresse verwendet, aber nicht in der fhem.cfg gespeichert. Das System läuft nun so lange, bis es zu einem Neustart kommt. Dann wird der Sensor nicht mehr erkannt, weil er eine neue Adresse hat und FHEM ihn auf der alten Adresse von der fhem.cfg sucht. Mache ich da etwas falsch?
Uwe
Zitat von: LAN-Opfer am 24 April 2021, 11:33:22
Ich bin da auf ein kleines Problem gestoßen:
wenn ich meine Temperatur-Feuchte-Sensoren anlege, bekommen sie eine Adresse und die wird in der fhem.cfg gespeichert. Wenn ich nun die Batterie tausche und dies per replaceBatteryForSec einleite, wird eine neue Adresse verwendet, aber nicht in der fhem.cfg gespeichert. Das System läuft nun so lange, bis es zu einem Neustart kommt. Dann wird der Sensor nicht mehr erkannt, weil er eine neue Adresse hat und FHEM ihn auf der alten Adresse von der fhem.cfg sucht. Mache ich da etwas falsch?
Uwe
Die neue Adresse mußt du selbst speichern.
Müsstest du aber daran sehen, dass in der Webansicht hinter "Save Config" ein ? erscheint.
Hallo,
ich habe mal eine kurze Frage. Ich habe schon länger ein LGW v1.35 mit einem NodeMCU Devkit 1.0 laufen (welches sich hier und da mal aufhängt und bis zum Reset nichts mehr macht) und habe heute ein zweites minimales LGW v1.35 mit einem Wemos D1 Mini aufgebaut.
Beim Einrichten fiel mir jetzt auf, dass das NodeMCU LGW in seiner Weboberfläche unter Hardware im Eintrag ESP8266 anzeigt "Reset: External System -> Fatal exception:0 flag:6 (EXT_SYS_RST) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000".
Kann mir jemand sagen was das heißt!?
MfG,
Marco
Zitat von: marco-f am 27 Mai 2021, 12:25:33
Kann mir jemand sagen was das heißt!?
"Reset: External System" bedetet, dass der Reset per Harware ausgelöst wurde (Reset-Button, ...)
"Fatal exception:0 flag:6 (EXT_SYS_RST)" bedeutet, dass der Start kein restart nach einem Crash war
Der Rest ist debug-Info für den Entwickler.
https://www.espressif.com/sites/default/files/documentation/esp8266_reset_causes_and_common_fatal_exception_causes_en.pdf (https://www.espressif.com/sites/default/files/documentation/esp8266_reset_causes_and_common_fatal_exception_causes_en.pdf)
Hallo,
ich habe damit angefangen ein großteil der FSK Sensoren vom LaCrosseGateway und JeeLink in den Signalduino zu übernehmen.
https://forum.fhem.de/index.php/topic,122474.0.html
Ich kann dazu noch vom TX38IT Raw Nachrichten vom LaCrosseGateway oder JeeLink gebrauchen.
Vom LevelSender habe ich bis jetzt auch noch keine raw Nachrichten gefunden. Wird der überhaupt noch verwendet?
Gruß Ralf
Zitat von: Ralf9 am 29 August 2021, 23:13:06
Wird der überhaupt noch verwendet?
Meiner ist seit Jahren ohne Probleme in Betrieb :)
ZitatMeiner ist seit Jahren ohne Probleme in Betrieb
Ich könnte davon einige raw Nachrichten mit den dazugehörigen FhemDataString "OK LS .." gebrauchen.
Gruß Ralf
Zitat von: Ralf9 am 01 September 2021, 19:07:36
Ich könnte davon einige raw Nachrichten mit den dazugehörigen FhemDataString "OK LS .." gebrauchen.
Eventuell hilft auch das hier weiter:
// Message-Format
// --------------
// .- [0] -. .- [1] -. .- [2] -. .- [3] -. .- [4] -. .- [5] -.
// | | | | | | | | | | | |
// SSSS.DDDD LLLL.LLLL LLLL.TTTT TTTT.TTTT VVVV.VVVV CCCC.CCCC
// | | | | | | | | | | | | | | | | | | | | | |
// | | | | | | | | | | | | | | | | | | | | `--------- CRC
// | | | | | | | | | | | | | | | | | | | |
// | | | | | | | | | | | | | | | | | | `----- Voltage * 0.1V
// | | | | | | | | | | | | | | | | `---------- Voltage * 1V
// | | | | | | | | | | | | | | | |
// | | | | | | | | | | | | | | `----- Temperature T * 0.1 |
// | | | | | | | | | | | | `---------- Temperature T * 1 | +40 �C
// | | | | | | | | | | `---------------- Temperature T * 10 |
// | | | | | | | | | |
// | | | | | | | | `----- Level * 1 |
// | | | | | | `----------- Level * 10 | 0,5cm steps
// | | | | `---------------- Level * 100 |
// | | | |
// | | `----- ID (0 .. 15)
// | |
// `----- START (IT+=9, LevelSender=11)
// OK LS 1 0 5 100 4 191 60 = 38,0cm 21,5�C 6,0V
// OK LS 1 0 8 167 4 251 57 = 121,5cm 27,5�C 5,7V
// OK LS ID X XXX XXX XXX XXX XXX
// | | | | | | | | |
// | | | | | | | | `--- Voltage * 10
// | | | | | | | `------- Temp. * 10 + 1000 LSB
// | | | | | | `----------- Temp. * 10 + 1000 MSB
// | | | | | `--------------- Level * 10 + 1000 MSB
// | | | | `------------------- Level * 10 + 1000 LSB
// | | | `------------------------ Sensor type fix 0 at the moment
// | | `--------------------------- Sensor ID ( 0 .. 15)
// | `----------------------------- fix "11"
// `--------------------------------- fix "LS"
Die LevelSenderLib.cpp hilft um die Perl Routinen zum wandeln der RAW-Nachrichten nach OK LS .. einzubauen.
Zum Testen der Perl Routinen sind die RAW Nachrichten hilfreich.
Bei dem TX38 habe ich jetzt die RAW Nachrichten von Hand zusammen gebaut.
Das von Hand zusammenbauen der RAW Nachrichten wäre beim LevelSender aufwendiger und mühsamer als beim TX38
Der LevelSender wird anscheinend inzwischen nur noch von sehr wenigen verwendet.
Um die RAW Nachrichten (HEX-Strings) zu bekommen muss man in den debugmodus gehen. Das geht über den set Befehl.
set JeeLink raw 1d
oder
set LaCrosseGateway raw 1d
Hallo,
ich habe einen LaCrosseGateway V1.35 mit 2 RFM69 (LaCrosse,PCA301) in fhem eingereichtet. Anstatt eines dritten RFM69 ist ein Temperatursensor DHT22 verbaut. Leider komme ich mit dem Wiki nicht klar, wie nun die Werte des DHT22 an fhem übermittelt werden können bzw. wie ich ein Device für den DHT22 definieren muss.
Ich hoffe jemand kann mir hier helfen.
Danke und Gruß
Ingo
Internals:
Alive 2021-11-15 17:10:40
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol:CapacitiveLevel
DEF 192.168.XXX.XXX:81
DeviceName 192.168.XXX.XXX:81
FD 75
FUUID 5e067610-f33f-c7cb-a008-3e12f57665ecd6f3
LaCrosseGateway_MSGCNT 1519
LaCrosseGateway_TIME 2021-11-15 19:05:49
NAME LaCrosseGateway
NR 1212
NTFY_ORDER 50-LaCrosseGateway
PARTIAL
RAWMSG OK 24 10 4 10 15 182 1 0 0 20 136
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.35
nextOpenDelay 2
settings (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868950 r:6631) + DHT22 {IP=192.168.XXX.XXX}]
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
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2021-11-15 19:05:47 FramesPerMinute 3
2021-11-15 19:05:47 FreeHeap 25640
2021-11-15 19:05:47 OLED none
2021-11-15 19:05:47 RSSI -72
2021-11-15 19:05:47 ReceivedFrames 90
2021-11-15 19:05:47 UpTime 0Tg. 2Std. 0Min. 26Sek.
2021-11-15 19:05:47 UpTimeSeconds 7226
2021-11-15 19:05:49 state initialized
helper:
Attributes:
initCommands 2,868950,120i v
kvp both
room 999_Gateway
timeout 120,30
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE] 2>&1
Edit: habe das Attribut ownSensors gefunden. Jetzt werden die Readings des DHT22 angezeigt.
Zitat von: karpate am 15 November 2021, 19:18:56
Ich hoffe jemand kann mir hier helfen.
Ja, ich.
Auf der Setup-Page des LGW bei "Internal sensors: ID:" eine ID vergeben (die keiner der echten Sensoren hat) (1-255), idealerweise HEX angeben
Beispiel: 0x0A
Im LaCrosseGateway device das Attribut ownSensors auf dispatch oder both setzen
Ein device für den Sensor anlegen mit: define myInternalLgwSensor LaCrosse 0A
Die ID muss die von der LGW-Konfiguration sein, aber ohne das 0x am Anfang
@HCS Danke :D
Hallo zusammen,
ich habe ein Problem.
Nach dem letzten FHEM update werden die Werte der "Wetterstation", also die internen Daten des BME680 Sensors nicht mehr in FHEM angezeigt.
Ich vermute es hängt mit dem Update folgender Dateien zusammen:
- SD_Protocols.pm
- SD_ProtocolData.pm
- 14_SD_WS.pm
- 14_SD_WS07.pm
- 14_SD_WS09.pm
Im "Event monitor" bekomme ich folgendes angezeigt:
JeeLink LaCrosseGateway UNKNOWNCODE OK WS 0 4 4 219 24 255 255 255 255 255 255 255 255 0 4 14 0 32 37 255 255 255 255 255 255
Die Daten der anderen Temperatur Sensoren sowie der PCA301 Steckdosen kommen alle korrekt an.
Was kann ich tun, damit die Daten des interne Sensors wieder korrekt in FHEM übergeben werden?
Dankeschön und Gruß
Ich habe das Problem mit den UNKNOWN CODE Meldungen auch, allerdings von diversen TX29 Sensoren. (Es gingen nur noch die beiden Sensoren auf dem LaCrossGateway selbst)
Das Problem kam offenbar nach meinem Update am 18.01.22
Ich habe jetzt per Restore das Backup vom 18.1.22 eingespielt und es geht wieder (zumindest bei den Sensoren die ich nicht in der Zwischenzeit "zerbastelt" hab)...
Vielleicht kann jemand der Wissenden hier Licht ins Dunkle bringen. Mir ist es nach 3h Analyse nicht gelungen
Auszug Logfile
2022.01.19 12:24:53 5: LaCrosseGateway_1: dispatch OK VALUES LGW 1754803 UpTimeSeconds=1070,UpTimeText=0Tg. 0Std. 17Min. 50Sek. ,WIFI=xxxxx,ReceivedFrames=1362,FramesPerMinute=85,RSSI=-57,FreeHeap=17272,LD.Min=0.88,LD.Avg=0.93,LD.Max=50.92,OLED=none
2022.01.19 12:24:53 3: LaCrosseGateway_1: Unknown code OK VALUES LGW 1754803 UpTimeSeconds=1070,UpTimeText=0Tg. 0Std. 17Min. 50Sek. ,WIFI=xxxxx,ReceivedFrames=1362,FramesPerMinute=85,RSSI=-57,FreeHeap=17272,LD.Min=0.88,LD.Avg=0.93,LD.Max=50.92,OLED=none, help me!
2022.01.19 12:24:53 5: LaCrosseGateway_1: dispatch OK 9 36 1 4 174 50
2022.01.19 12:24:53 3: LaCrosseGateway_1: Unknown code OK 9 36 1 4 174 50, help me!
2022.01.19 12:24:53 5: LaCrosseGateway_1: dispatch OK 9 14 1 4 185 45
2022.01.19 12:24:53 3: LaCrosseGateway_1: Unknown code OK 9 14 1 4 185 45, help me!
2022.01.19 12:24:53 5: LaCrosseGateway_1: dispatch OK 9 56 1 4 143 59
2022.01.19 12:24:53 3: LaCrosseGateway_1: Unknown code OK 9 56 1 4 143 59, help me!
2022.01.19 12:24:54 5: LaCrosseGateway_1: dispatch OK 9 37 129 4 191 48
2022.01.19 12:24:54 3: LaCrosseGateway_1: Unknown code OK 9 37 129 4 191 48, help me!
2022.01.19 12:24:54 5: LaCrosseGateway_1: dispatch OK 9 23 1 4 156 49
2022.01.19 12:24:54 3: LaCrosseGateway_1: Unknown code OK 9 23 1 4 156 49, help me!
2022.01.19 12:24:55 5: LaCrosseGateway_1: dispatch OK 9 33 1 4 184 48
2022.01.19 12:24:55 3: LaCrosseGateway_1: Unknown code OK 9 33 1 4 184 48, help me!
2022.01.19 12:24:56 5: LaCrosseGateway_1: dispatch OK 9 29 1 4 160 49
2022.01.19 12:24:56 3: LaCrosseGateway_1: Unknown code OK 9 29 1 4 160 49, help me!
2022.01.19 12:24:56 5: LaCrosseGateway_1: dispatch OK WS 0 4 4 205 255 255 255 255 255 255 255 255 255 0 3 254
2022.01.19 12:24:56 3: LaCrosseGateway_1: Unknown code OK WS 0 4 4 205 255 255 255 255 255 255 255 255 255 0 3 254, help me!
list LaCrosseGateway_1
Internals:
Alive 2022-01-19 13:39:31
Clients 1
DEF 192.168.1.11:81
DeviceName 192.168.1.11:81
FD 6
FUUID 5c853237-f33f-6c57-f9b9-3ccb3b5048d3a746
LaCrosseGateway_1_MSGCNT 4412
LaCrosseGateway_1_TIME 2022-01-19 13:40:24
NAME LaCrosseGateway_1
NR 89
NTFY_ORDER 50-LaCrosseGateway_1
PARTIAL
RAWMSG OK 9 27 1 4 130 57
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.30
nextOpenDelay 2
settings (1=RFM69 f:868300 r:17241) + (4=RFM69 f:868300 r:20000) + BMP180 + SC16IS750 (0x90, 0x92) {IP=192.168.1.11}]
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
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2022-01-19 13:40:18 pressure 1020
2022-01-19 13:40:24 state initialized
2022-01-19 13:40:18 temperature 23.1
helper:
Attributes:
Clients 1
disable 0
initCommands 43h
ownSensors both
room Gateways,HWR,LaCrosse,System
timeout 60
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
verbose 5
watchdog 300
Und hier einer der Sensoren als Beispiel:
list LaCrosse_1D
Internals:
DEF 1D
FUUID 5da88ab8-f33f-6c57-fff3-cb9a358bc36c41c0
IODev LaCrosseGateway_1
LASTInputDev LaCrosseGateway_1
LaCrosseGateway_1_MSGCNT 23
LaCrosseGateway_1_TIME 2022-01-19 15:53:57
LaCrosse_lastRcv 2022-01-19 15:53:57
MSGCNT 23
NAME LaCrosse_1D
NR 324
STATE T: 18.4 H: 48 D: 7.2
TYPE LaCrosse
addr 1D
battery_new 0
corr1 0
corr2 0
previousH 48
previousT 18.4
sensorType 0=T(H)
READINGS:
2022-01-19 15:51:05 IODev LaCrosseGateway_1
2022-01-19 15:53:57 battery ok
2022-01-19 15:53:57 dewpoint 7.2
2022-01-19 15:53:57 humidity 48
2022-01-19 15:52:53 state T: 18.4 H: 48 D: 7.2
2022-01-19 15:53:57 temperature 18.4
Attributes:
IODev LaCrosseGateway_1
alias Temp_Kueche
doAverage 1
doDewpoint 1
genericDeviceType thermometer
homebridgeMapping CurrentRelativeHumidity=humidity
CurrentTemperature=temperature
StatusLowBattery=battery,values=ok:BATTERY_LEVEL_NORMAL;/^.*/:BATTERY_LEVEL_LOW
095c46e2-278e-4e3c-b9e7-364622a0f501:dewpoint,name=Taupunkt,format=FLOAT,unit=CELSIUS,maxValue=30,minValue=-30,minStep=.1
history:size=1024
icon temp_temperature
room Homekit,Kueche,LaCrosse,Temperaturen
Gruß Handfest
Ich habe das gleiche Problem mit den internen BME280.
Die TX29DHT laufen bei mir noch.
Die internen Sensoren werden auch als LaCrosse angelegt, nur wurde da nichts geändert.
Leider ist mein letztes Update zu lange her um den Fehler einzugrenzen.
Wann war euer letztes Update, bevor der Fehler aufgetaucht ist?
ZitatWann war euer letztes Update, bevor der Fehler aufgetaucht ist?
Bei mir am 23.12.2021
Gruß Handfest
Leider komme ich nicht weiter mit der Ursachensuche :(
2022.01.20 18:30:38 5: LaCrosseGateway: dispatch OK WS 0 4 4 190 47 255 255 255 255 255 255 255 255 0 4 5 255 255 255 255 255 255 255 255 255
2022.01.20 18:30:38 3: LaCrosseGateway: Unknown code OK WS 0 4 4 190 47 255 255 255 255 255 255 255 255 0 4 5 255 255 255 255 255 255 255 255 255, help me!
Ich habe erstmal das Update zurückgespielt und nun läuft es wieder.
Weiter habe ich einen neuen Thread eröffnet
https://forum.fhem.de/index.php?topic=125603 (https://forum.fhem.de/index.php?topic=125603)
Grüße
Bernd
Die Lösung steht im vorher geposteten Thread.
Wann sie per Update kommt, kann ich nicht sagen.
Zitat von: frober am 20 Januar 2022, 21:47:20
Die Lösung steht im vorher geposteten Thread.
Wann sie per Update kommt, kann ich nicht sagen.
Ich gehe mal davon aus, dass sie am Wochenende (ohne Garantie) kommt
Leider erst jetzt - war gerade viel zu tun...
Danke @HCS: Läuft nach dem Update jetzt auch bei mir wieder fehlerfrei
Gruß Handfest
Ich hab mir vor kurzem die Platinen von PeMue zugelegt welche es noch zu bestücken gilt.
Da hier ja oft die Wetterstation WS 1600 angeführt wird, hätt ich gleich mal dazu eine Frage. Benötigt man bei der WS 1600 zwingend das Display zum Betrieb oder würden auch die Sensoren ausreichen?
Viele Grüße
Brasletti
Zitat von: Brasletti am 16 Februar 2022, 20:06:11
Da hier ja oft die Wetterstation WS 1600 angeführt wird, hätt ich gleich mal dazu eine Frage. Benötigt man bei der WS 1600 zwingend das Display zum Betrieb oder würden auch die Sensoren ausreichen?
die gehen auch ohne Display, die Werte werden halt dann nur in FHEM angezeigt
Gruß PeMue
Ich find' das Projekt echt mega - vielen dank an die Authoren!
Allerdings hätte ich einen "kleinen" Feature-Request:
Damit das Gateway auch ohne "spezielles" FHEM device auskommt - bzw. wie in meinem Fall: Damit das Gateway auch an HA verwendbar ist, habe ich den Code um einen MQTT-Client erweitert.
Damit werden im Moment alle empfangenen LaCrosse-Sensoren inkl. deren Daten WeakBat, NewBat, Temp, Hum und einem (NTP) "Empfangszeitstempel" jeweils unter der Topic der Sensor-ID gepublished.
Das ganze funktioniert wunderbar (und auch an jedem MQTT broker)!
Da ich aber kein SW Entwickler bin, ist das ganze recht "pfuschig".
Außerdem sind bisher die Topics, der MQTT-server und MQTT-Port sowie Username & Passwort hart codiert - d.h. (noch) nicht übers Setup einstellbar.
Außerdem möchte ich in Zukunft auch noch die "lokalen" Sensordaten publishen.
Würde man das Feature in das offizielle Repository zu übernehmen, könnten andere (nicht FHEM-Nutzer) das Gateway ebenfalls verwenden.
Ich stelle auch gerne meinen funktionalen Pfuschcode zur Verfügung;) - Nur wird nicht jeder meine Topics und server-ip, etc. nutzen :D.
In ein paar Tagen habe ich die Features sicherlich implementiert - Allerdings "unkonventionell" ringepfuscht.
Falls jemand interesse hat...
Nur so eine Idee.
Falls jemand sich für den Code interessiert (Wie gesagt: Enthält den MQTT-Publish der LaCrosse-Sensoren)...
Ein paar Änderungen waren notwendig um den "Read" der Settings aus dem EEPROM zu prüfen - Hatte zu Beginn das falsche ESP8266-Board ausgewählt; Damit hatte das lesen aus dem EEPROM nicht funktioniert ::) (Ohne Worte)
Riesen Dank für die Implementierung dieses Features.
Ich persönlich würde es auch sehr begrüßen, wenn das Gateway MQTT kann. Bisher ist FHEM scheinbar die einzige Plattform die das Gateway über Wifi nutzen kann.
Hi, mittlerweile habe die den Code erweitert, so dass die wichtigsten settings, wie MQTT server, port, username, pw usw ebenso über den Browser konfiguriert werden, wie der Rest der Einstellungen des Gateways. Siehe Screenshot.
Bei mir läuft das Gateway mittlerweile zuverlässig und meldet brav alle Werte über MQTT an Mosquitto und HA.
Außerdem sucht der ESP jetzt nach der stärksten BSSID für eine gegebene SSID - War bei mir fürs Mesh wichtig.
Wenn ich heute abend noch Muße habe, lade ich den aktuellen Sketch hoch.
Danke für deine Arbeit,
ich würde es begrüßen wenn du den Sketch veröffentlichen würdest.
Gruß
trebron106
Heute nur kurz der Link zum Repository:
https://github.com/Rainerlan/LaCrosseGatewayMQTT
Vielleicht kann's noch jemand brauchen...
Hallo,
ich bin gerade dabei ein LGW einzurichten.
Die Einrichtung verlief erfolgreich, Fhem und TX29 DTH-IT.
Jetzt tritt aber ein Problem auf, der TX29 DTH-IT verliert nach ca. 12h die Verbindung zum LGW und ich kann das Teil nicht mehr mit dem LGW koppeln.
Kann mir hier jemand helfen?? Ich bin kein Programmierer!
Vielen Dank!!
VG FW
Hallo Zusammen,
ich nutze den LaCrosseGateway schon recht lange und dieser funktioniert super.
Nun bin ich vor kurzem umgezogen und ich habe nun Probleme einige PCA301 Steckdosen und Thermometer zu empfangen.
Ist es möglich ein zweiten LaCrosseGateway als ,,Repeater" zu nutzen?
Kann man im FHEM mehrere LaCrosseGateways anbinden?
Vielleicht hatte hier schon mal jemand ein ähnliches Problem und kann mir einen Tip geben, wie ich da am besten ansetze.
Dankeschön!!
Hallo woodgee,
man kann problemlos 2 LaCrosse Gateway's in fhem einbinden, habe ich hier auch so gemacht.
Jeder LGW läuft dann völlig unabhängig für sich. Dadurch solltest Du Deine Empfangsprobleme auf jeden Fall lösen können ;)
Gruß Thomas
Hallo Thomas,
danke für deine Rückmeldung!
Was ich noch nicht ganz verstehe, es gibt das ,,IODev" bei den PCA301 Steckdosen.
Die beiden LaCrosseGateways überschneiden sich funktechnisch.
Als ,,IODev" trage ich den LaCrosseGateway ein, welcher der Steckdose oder dem Thermometer am nächsten ist?
Oder ist das FHEM völlig egal und es sendet und empfängt auf beiden Gateways?
Grüße und danke
Zitat von: woodgee am 08 November 2022, 21:34:11
Als ,,IODev" trage ich den LaCrosseGateway ein, welcher der Steckdose oder dem Thermometer am nächsten ist?
Ja, wobei du in der Weboberfläche vom LGW siehst welcher empfangen wird. Mit Ausnahme von deinem alten LGW, das sind vermutlich noch alle registriert.
Hallo,
hate jemand noch eine Idee warum der Empfang eines TX35DTH-IT Thermometers nur ca. 3-4 Meter beträgt (bei Sichtverbindung) ?
Habe schon das RF69CW Modul gewechselt, Antenne ist ca. 82 mm lang.
attr lgw initCommands 1r 9579 v
attr lgw mode WiFi
attr lgw timeout 120,30
Betreibe die Thermometer aktuell mit JEELINK, dort sind ca. 20 m und auch Wände kein Problem.
86 mm wäre die richtige Antennenlänge bei 868 MHz.
Ob das aber soviel ausmacht!?
Zitat von: bt047265@gmail.com am 06 Februar 2023, 22:35:01
attr lgw initCommands 1r 9579 v
Das ergibt irgendwie keinen Sinn.
Siehe hier: https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Liste_aller_initCommands
richtiger wäre z.B.: attr lgw initCommands 9579#1r v
Hallo,
ja die Länge wird bestimmt nicht die Ursache des schlechten Empfangs sein. Habe nochmal das InitCommands modifiziert:
868300#1f 9579#1r v
Aber leider auch keine Verbesserung. Ich werde es nochmal mit einem neuen RFM69 Modul neu aufbauen.
Danke
Es war wirklich das verwendete RF69CW Modul. Ich hatte nochmal ein RF69HCW bestellt und mit dem ist der Epmfang identisch zu dem bisher verwendetem JEELINK USB.
Das HCW hat eine höhere Sende-/Empfangsleistung. Bei mir funktioniert das problemlos auch mit dem CW (ca 20m durch mehrere Wände).
Hat mal die Antenne angepasst?
Laut dem Rechner hier https://www.entwicklertools.de/tools/technik-tools/antennen-rechner/ (https://www.entwicklertools.de/tools/technik-tools/antennen-rechner/) müsste diese sogar 88mm lang sein.
Zitat von: frober am 18 Februar 2023, 10:42:51
Das HCW hat eine höhere Sende-/Empfangsleistung.
Nein, nur eine höhere Sendeleistung, die im Fall von bt047265 keine Rolle spielt, weil in seinem Szenario nichts gesendet wird.
Zitat von: frober am 18 Februar 2023, 10:42:51
rechner/[/url] müsste diese sogar 88mm lang sein.
Bei 3-4 Metern Reichweite, die er hatte, ist es völlig egal, wie lang die Antenne ist, das geht sogar ohne deutlich weiter :)
Zumindest wenn der RFM69 nicht defekt oder eines dieser China-Wunderwerke ist, bei denen nur jeder dritte richtig funktioniert.
Zitat von: HCS am 25 Februar 2021, 08:58:50@schmadde: anbei eine Beta LGW 1.36
Kann man nicht per OTA auf das LGW hochladen, nur per USB
Hallo @HCS,
ich möchte demnächst mein LaCrosseGateway mit der MQTT Version von @Rainerlan_2 flashen. Dabei ist mir aufgefallen, dass die Version noch auf der 1.35 basiert.
Kannst Du eine aktuelle (z.B. 1.36-Beta) Codebasis zur Verfügung stellen oder die letzten Änderungen seit 1.35 durchgeben? Dann könnte man gleich eine aktuellere Version kompilieren.
Unabhängig davon:
Danke für Deine Arbeit, das LaCrosseGateway ist bei mir schon seit Jahren zuverlässig im Dauereinsatz.
Zitat von: Rainerlan_2 am 13 August 2022, 13:37:37Hi, mittlerweile habe die den Code erweitert, so dass die wichtigsten settings, wie MQTT server, port, username, pw usw ebenso über den Browser konfiguriert werden, wie der Rest der Einstellungen des Gateways. Siehe Screenshot.
@Rainerlan_2 scheint leider nicht mehr aktiv zu sein. Kann mir jemand sagen, wie ich seine Version installiert bekomme? Das Binary (https://github.com/Rainerlan/LaCrosseGatewayMQTT/tree/main/binaries) ist acht oder neun MB groß und passt bei mir nicht. Oder muss ich mir dafür einen NodeMCU mit mehr Flash-Speicher organisieren?
Das Erstellen des korrekten Binaries hat jetzt doch geklappt mit dem folgenden Befehl:
elf2bin.py -a /pfad/zu/LaCrosseGateway.ino.elf -f 80 -e /pfad/zu/eboot.elf -m dio -s 4M -o LaCrosseGateway.bin -p ./xtensa-lx106-elf/bin
elf2bin stammt aus dem esp8266 Arduino Github Repo (https://github.com/esp8266/Arduino). Dann mit esptool.py geflasht.
MQTT funktioniert jetzt fein für Temperaturen, allerdings vermisse ich die EC3000 Werte. Hat jemand einen Tipp?
Update 19.09.23:
Einmal neu installieren von Python und Update der ArduinoIDE haben Wunder bewirkt, das Gateway wurde ohne Murren kompiliert und läuft auf dem Wemod D1mini. Jetzt muss ich das Ding noch zusammenlöten und dann sind meine Sensoren wieder eingebunden :)
Grüße Martin
Hallo TWry,
vielen Dank für deine Erklärung zur Erstellung des Binaries. Hast du die unter Windows oder unter Linux erstellt?
Ich will mir das Binary für einen Wemos D1Mini erstellen, aber da erhalte ich unter Windows leider eine Fehlermeldung:
elf2bin.py -a ..\..\LaCrosseGatewayMQTT-main\binaries\LaCrosseGateway.ino.elf -f 80 -e ..\bootloaders\eboot\eboot.elf -m dio -s 4M -o LaCrosseGatewayMQTT.bin -p ./xtensa-lx106-elf/bin
Creating BIN file "LaCrosseGatewayMQTT.bin" using "..\bootloaders\eboot\eboot.elf" and "..\..\LaCrosseGatewayMQTT-main\binaries\LaCrosseGateway.ino.elf"
Traceback (most recent call last):
File "D:\Programmieren\Arduino-master\tools\elf2bin.py", line 256, in <module>
sys.exit(main())
File "D:\Programmieren\Arduino-master\tools\elf2bin.py", line 234, in main
wrapper(
File "D:\Programmieren\Arduino-master\tools\elf2bin.py", line 232, in wrapper
write_bin(out=out, args=args, **kwargs)
File "D:\Programmieren\Arduino-master\tools\elf2bin.py", line 107, in write_bin
entry = int(get_elf_entry( elf, args.path ))
File "D:\Programmieren\Arduino-master\tools\elf2bin.py", line 43, in get_elf_entry
result = subprocess.run(
File "C:\Users\Martin\AppData\Local\Programs\Python\Python38\lib\subprocess.py", line 489, in run
with Popen(*popenargs, **kwargs) as process:
File "C:\Users\Martin\AppData\Local\Programs\Python\Python38\lib\subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "C:\Users\Martin\AppData\Local\Programs\Python\Python38\lib\subprocess.py", line 1307, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] Das System kann die angegebene Datei nicht finden
Hab ich mit Python 3.8 eine falsche Version? Oder woran kann das sonst liegen?
Grüße Martin
Zitat von: malutz am 29 August 2023, 19:23:41D1mini. Jetzt muss ich das Ding noch zusammenlöten und dann sind meine Sensoren wieder eingebunden :)
Hat jemand mal ein .bin der MQTT-Version für mich zum flashen? Ich bekomme es mit meinen Versionen weder unter ArduinoIDE noch mit Platformio sauber durchkompiliert.
@malutz: Hast du EC3000 am Laufen?
Danke!
Zitat von: TWry am 26 Juli 2023, 08:58:43Das Erstellen des korrekten Binaries hat jetzt doch geklappt mit dem folgenden Befehl:
elf2bin.py -a /pfad/zu/LaCrosseGateway.ino.elf -f 80 -e /pfad/zu/eboot.elf -m dio -s 4M -o LaCrosseGateway.bin -p ./xtensa-lx106-elf/bin
elf2bin stammt aus dem esp8266 Arduino Github Repo (https://github.com/esp8266/Arduino). Dann mit esptool.py geflasht.
MQTT funktioniert jetzt fein für Temperaturen, allerdings vermisse ich die EC3000 Werte. Hat jemand einen Tipp?
@malutz @TWry
Da ich zu dusslig war das ganze selber zu kompilieren hat mit malutz freundlicherweise sein Binary zur Verfügung gestellt.
VIELEN DANK AN MALUTZ DAFÜR!
Flashen eines ESP ging dann auch problemlos!
Und dann kam der
Kulturschock. Irgendwie eben sehr fhem-like, sei's drum, ein typisches
WorksForMe-Ding. Das Ding hat bei mir einen AccessPoint aufgemacht, hat aber entgegen der Anleitung keine IP per DHCP an ausgegeben. Na pfeif drauf. Also habe ich mir 192.168.222.2 gegeben, konnte mich verbinden und das Ding dann in mein WLAN bringen.
Dann auf die
Oberfläche um das Ding zu konfigurieren. Kulturschock, achso, sagte ich schon.
Funktionell nennt man sowas dann wohl, wenn es denn tut, ok. MQTT-Server konfiguriert.
Aber Hey! Das Modul empfängt schon ein paar Temperatursensoren, laut ID sind das nicht nur meine. Im MQTT-Explorer (https://mqtt-explorer.com/) findet man die Temperaturwerte auch wieder.
Von EC3000 leider keine Spur.
@TWry nun zum EC3000. Meine Steckdose direkt daneben wurde irgendwie nicht erkannt. Auch nicht auf der seriellen Konsole. Auf der Wikiseite steht was von
20000r. Aber wo gibt man das ein? Dachte erst auf der seriellen Konsole, aber da tat sich gar nichts. Nee, man geht auf der Webconfig auf
Log und gibt dort bei Command
20000r ein. Wenn der Empfang stimmt krümeln auch nach einiger Zeit Daten rein. Am besten gibt man bei Filter die HexAdresse der Steckdose ein.
Dann bekommt man solche Daten auf der Logconsole, aber nicht per MQTT.
19:29:51: OK 22 186 205 3 222 240 0 3 222 240 0 0 9 117 241 0 0 0 0 1 0 [BA CD F0 00 00 00 F0 00 00 00 00 05 0A 8D 37 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3D E0 00 00 00 08 3D E0 10 00 11 D7]
Meine Teststeckdose ist in diesem Fall die
BA CD. Der Rest der Datenkrümel ist noch zu ermitteln.
Per MQTT werden diese Daten leider nicht versendet. Wie man am Format unten sieht bringt das auch nicht richtig was.
Selbst wenn man den Sketch dazu bringt auch die EC3000-Daten per MQTT zu versenden wäre da wohl noch einiges an Skripting am auswertenden System zu machen.
Ich denke, wenn man das vernünftig machen möchte, müsste man das anders aufziehen. Aber das hat in diesem Forum wahrhaftig nichts zu suchen.