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

[HCS]

und! testen muss ich das ganze ja auch noch... 

Leg los, bin gespannt ob es funktioniert 

[PeMue]

Das ist, wie wenn ich diese Platine verwenden würde: 
https://forum.fhem.de/index.php?action=dlattach;topic=45594.0;attach=44927

Aber jetzt sollte ich doch morgen OTA flashen können, oder?

Code Auswählen Erweitern

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 ):

Code Auswählen Erweitern

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

[AxelSchweiss]

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.

[HCS]

stressfrei

Glückwunsch zu Deinem ersten OTA Update 

Habe es eben mit OTA old Style geflasht.

Was ist "OTA old Style" ?

[AxelSchweiss]

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" 
Oder habe ich da was falsch verstanden?

[HCS]

Das was ihr abschalten wolt  (Server, Port, URL) und gegen den Push-Request aus FHEM heraus ersetzten.
Daher "Old Style" 
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 

[locutus]

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?

[HCS]

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

[locutus]

Also mit avrdude über den Netzwerk-Port hat es mehr oder weniger gut funktioniert ...

Code Auswählen Erweitern

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.

[HCS]

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.

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.

[amunra]

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.

[AxelSchweiss]

- OLED Ladebalken finde ich super... *schöne Spielerei

Kannst du da mal ein Filmchen mit dem Handy vom Startvorgang des LGW machen ? 
Ich glaube langsam finde ich an dem Display auch gefallen.

[HCS]

zunächst => bin jetzt schon begeistert.

Dann ist das erklärte Ziel erreicht und ich kann Urlaub machen 

- 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.

- 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

[HCS]

Kannst du da mal ein Filmchen mit dem Handy vom Startvorgang des LGW machen ? 

Ich beantworte mal eine Frage, bevor sie gestellt wird 

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 

[amunra]

Dann ist das erklärte Ziel erreicht und ich kann Urlaub machen 

Ähm , wie jetzt schon? 

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

Code Auswählen Erweitern

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?