Da amunra hier
https://forum.fhem.de/index.php/topic,45594.msg446513.html#msg446513
ein Beispiel für ein Display am LGW gezeigt hat, diskutieren wir das Thema mal, ob das ein Feature werden könnte und wenn ja, wie genau.
ach nun doch ... im Dezember warst du da noch anderer Meinung :
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?
anbei nochmal das damalige Foto
Zitat von: Wzut am 02 Mai 2016, 13:22:10
ach nun doch ... im Dezember warst du da noch anderer Meinung
1. Ich kann meine Meinung beliebig ändern
2. Noch habe ich keine konkrete Meinung
3. Dieser Thread dient der Meinungsbildung
@Wzut: Genau darauf habe ich mich bezogen und wollte keinesfalls damit Unruhe stiften ;) Ich fand die Idee damals schon interessant, und das nicht nur, weil ich die Displays in der Schublade hatte.
@HCS: Zunächst Danke für die Interesse und den neuen Thread. Die Einstellung verworfene, und damals vielleicht nicht benötigte/sinnlose, Dinge wieder aufzugreifen gut! – also, auch hier wieder Daumen hoch. ;)
So nun zum Thema – ich versuche es kurz zu machen, Details können bei Bedarf immer noch geklärt werden.
Bei dem Display handelt es sich um einen:
0.96" Yellow & Blue 128X64 OLED I2C IIC Serial LCD LED Display Module for Arduino
Angaben findet man z.B. hier (https://cloud.mail.ru/public/c6d69303181c/IIC-OLED%20module%20FZ1109%20FZ1112%20FZ1113%20.rar)
Ich habe leider keine Bezugsquelle mehr, weil die Beschaffung schon etwas länger (ca. 1 Jahr) zurück liegt. Preis lag damals bei ca. 5$. Original Bilder (vorhin zwischen durch mal geschossen) habe ich angehängt.
Verstanden habe ich, dass I2C Interface bevorzugt wird, was die Implementierung einfach macht/machen soll, dieses OLED erfüllt diese Voraussetzungen.
Das Display gibt es in zwei Varianten: ,,Yellow & Blue" und ,,Blue"
Beschaltung:
D1(GPIO5) = SCL und D2 (GPIO4) = SDA VCC=3,3V GRD=GND und wie auf den Bildern/Video zu sehen mit zwei 4,7K Widerständen an 3.3V für Stabilität gesorgt.
Kurzfassung: Entspricht einer BMP180/BME280 Beschaltung.
Was fehlt noch.....?
Software:
Ist eher uninteressant und würde es offen lassen, es ist ja eine Diskussion ,,ob" und ,,was" und ,,überhaupt"?
Versucht habe ich u8glib, nach ca. 1 Stunde aufgegeben, weil ich es nicht zum Laufen gebracht habe – was aber nichts heißen muss.
Am Ende ist es der Klassiker ,,ESP8266 Weather Station" geworden.
Warum?
Erfüllt ,,meine" bisherigen Anforderungen: ,,String Print" ,,BMP Print" ,,Fonts integrierbar" und mehr... .
Schlank und kein Overkill (wenn auch nicht so gut und breiter aufgestellt als u8glib) für mein Vorhaben und ich habe nur diese Display Variante!
Anforderungen:
Möglichst die bisherigen Funktionen nicht tangieren. Spricht, wird/soll es Laufzeitprobleme geben, dann ziehe ich die bisherige Basis-Funktionalität vor.
Warum dieses Display:
- Weil ich nichts anderes in der Bestellkiste gefunden habe.
- Aufgrund der Bauform des Displays würde dieses Display gut passen ;) *ja, kann man diskutieren
- Stromverbrauch gering *Ja, es gibt bessere, aber auch mit Abstrichen.
Nachteile: skip ;)
Grundsätzliches:
- Ich denke ein Display würde ein LGW aufwerten und die Sache rund machen. Es ist nicht vorgesehen/ausgelegt ihn in Batteriebetrieb zu betreiben.
Ideen:
- Boot Sequenz Darstellung (Wifi Verbindung erfolgreich ja/nein etc.).
- Darstellung von WiFi-Signalstäke
- Nach Boot Sequenz, Display nicht grundsätzlich aktiviert laufen lassen, sondern via ,,push Button" ein paar Informationen zu entlocken
- [Spielerei=auch nicht die Zielsetzung von LGW] Im Falle eines Terrassen Temp/Hum/Pres Sensors auch mal Zyklische Darstellung von Werten (Konfigurierbar über WEB oder aber auch Advanced-Mode Jahres abhängig: Winter nur Daten an FHEM übermitteln, keine Display Darstellung.... ) Detailierungsgrad kann man diskutieren.....
- Ich finde noch mehr mögliche Einsatzszenarien.... (Zeitbedingt nur Kurzfassung)
Ich hoffe jetzt können wir diskutieren?
Viele Grüße
Arthur
Zitat von: amunra am 02 Mai 2016, 22:23:06
Ich hoffe jetzt können wir diskutieren?
Wir können :)
Ich schreibe mal meine Gedanken (und mehr darf man da erst mal nicht reininterpretieren) zu dem Thema in ungeordneter und ungewichteter Reihenfolge runter.
Sind wir auf genau dieses Display gebunden (und wollen das) oder gehen auch andere Displays (ohne jedes explizit zu implementieren)
I2C ist OK, aber wie schon angesprochen, müssen wir auf die LoopTime der main loop achten, um nicht Timings von PCA301 usw. zu ruinieren. Besonders, wenn ein SC16IS750-Clone zum Einsatz käme und die I2C-Clock auf 100 kHz runter muss, ist die Kommunikation nicht mehr so rasend schnell
PushButton: in der Grundvariante eines LGW gibt es als einzig freien Port am ESP-12E noch den Analogeingang A0.
Da könnte ggf. ein Button dran oder über ein R-Netzwerk sogar mehrere (Up, Down, ...) um das Display oder sonstwas zu steuern.
Für die Idee, den LGW-Status (hat es einen Connect zum AP bekommen, RSSI, ...) darzustellen, was einem aktuell die LED hinblinkt, kann ich mich erwärmen
Temperatur, Feuchte und Luftdruck des internen Sensors dann halt auch, wenn man es cool findet
Wenn ich eine Display-Class Rumpfimplementierung bereitstelle, die ich mit neuen Log-Einträgen und neuen Werten des internen Sensors benachrichtige und ggf. mit Einstellungen der Setup-Page versorge, würde die dann jemand mit Leben füllen und ggf. auch pflegen?
Sehe ich auf Deiner Hardcopy den SerialMonitor von VisualMicro? Ich liebe das Tool :-)
Das Display hat ein immenses Potenzial für unsägliche Wünsche (kann dies und das noch drauf, ich will lieber Arial, kann es denn Charts für Temperatur und Feuchte)
Das darf nicht dahin führen, das wir irgend wann im Wesentlichen an einem LGD (LaCrosseDisplay) arbeiten
Kannst Du mir mal einen Link auf die Display-Lib posten, die Du eingebunden hast?
Zitat von: HCS am 05 Mai 2016, 08:50:35
Kannst Du mir mal einen Link auf die Display-Lib posten, die Du eingebunden hast?
IMHO habe ich das gleiche Display wie amunra und ich hatte die beiden eingebunden:
https://github.com/adafruit/Adafruit-GFX-Library
https://github.com/adafruit/Adafruit_SSD1306
Basisadresse das Displays : 0x3c
Ausgaben auf dem Display sind ja erst nach Wire.begin möglich, da ist aber das Thema WiFi, DHCP bereits komplett durch.
Wäre schön wenn man Wire.begin vllt. etwas vorziehen könnte.
Das könnte ja dieses Display sein?
http://www.ebay.de/itm/White-3-5V-0-96-I2C-Serial-128X64-OLED-LCD-LED-Display-Module-for-Arduino-M94-/301724405972?hash=item46402d10d4 (http://www.ebay.de/itm/White-3-5V-0-96-I2C-Serial-128X64-OLED-LCD-LED-Display-Module-for-Arduino-M94-/301724405972?hash=item46402d10d4)
Gruß Maxel
ich habe mir mal das hier gekauft
http://www.aliexpress.com/item/1Pcs-white-128X64-OLED-LCD-LED-Display-Module-For-Arduino-0-96-I2C-IIC-SPI-Serial/32610191383.html (http://www.aliexpress.com/item/1Pcs-white-128X64-OLED-LCD-LED-Display-Module-For-Arduino-0-96-I2C-IIC-SPI-Serial/32610191383.html)
Das sieht auf der Rückseite genau so aus. Es fehlt auch der Address-Selector.
Ich bekomme das Ding aber bis jetzt nicht zu laufen.
Man sollte mit den OLED aufpassen ... es gibt anscheinend verschiedene Chipsätze die sich aber im Aussehen sehr ähnlich sind.
Zitat von: HCS am 05 Mai 2016, 08:50:35
Sind wir auf genau dieses Display gebunden (und wollen das) oder gehen auch andere Displays (ohne jedes explizit zu implementieren)
Technisch natürlich nicht, wenn man u8glib nimmt dann sind nahezu keine Grenzen gesetzt - erhöht jedoch die Komplexität.
- alleine der Support der unterschiedlichen LCDs/OLEDs
- Code müsste generisch und über Web konfigurierbar sein - Stichwort "Komplexität" :-\
Tendenziell und vor allem zu Gunsten der Stabilität würde ich empfehlen sich auf 1-2 Displays festzulegen. Meine Meinung.
Zitat von: HCS am 05 Mai 2016, 08:50:35
I2C ist OK, aber wie schon angesprochen, müssen wir auf die LoopTime der main loop achten, um nicht Timings von PCA301 usw. zu ruinieren. Besonders, wenn ein SC16IS750-Clone zum Einsatz käme und die I2C-Clock auf 100 kHz runter muss, ist die Kommunikation nicht mehr so rasend schnell
Darauf zielte mein Hinweis mit Funktionalität "vor" Spielerei ab. Ich muss gestehen, dass ich die kritischen Pfade/Komponenten (gar)nicht bis ins Detail getestet habe. Je mehr man auf dem OLED darstellt, umso größer wird die looptime.
Zitat von: HCS am 05 Mai 2016, 08:50:35
Temperatur, Feuchte und Luftdruck des internen Sensors dann halt auch, wenn man es cool findet
Du meinst sicher die Betriebstermperatur des LGWs ;) (Oder, wie Du schon mal erwähnt hattest, man sorgt für die entsprechenden thermischen Voraussetzungen... ;)) - Advanced Mode an (Blende den Programmier- und Testaufwand aus): Über WEB konfigurierbar welche an LGW angebunden Sensoren auf dem OLED angezeigt werden sollen. Advanced Mode aus.
Zitat von: HCS am 05 Mai 2016, 08:50:35
Wenn ich eine Display-Class Rumpfimplementierung bereitstelle, die ich mit neuen Log-Einträgen und neuen Werten des internen Sensors benachrichtige und ggf. mit Einstellungen der Setup-Page versorge, würde die dann jemand mit Leben füllen und ggf. auch pflegen?
So, jetzt wird es spannend :) Freiwillige bitte vor.
Wenn auch ein wichtiger/fundamentaler Punkt, ich würde diesen Punkt "für mich persönlich" unbeantwortet lassen.
Hintergrund:
- Das Thema ist eher neu für mich und ich kann nicht zuverlässig die dafür notwendige Freizeit aufbringen, um das Thema voranzutreiben :/ - diese Herausforderung müssen wir sicher alle bewältigen.
Ich würde aber jetzt noch nicht die Flinte ins Korn werfen und eher den weiteren Diskussionsverlauf abwarten.
Zitat von: HCS am 05 Mai 2016, 08:50:35
Sehe ich auf Deiner Hardcopy den SerialMonitor von VisualMicro? Ich liebe das Tool :-)
Ja und Dito. ;)
Zitat von: HCS am 05 Mai 2016, 08:50:35
Das Display hat ein immenses Potenzial für unsägliche Wünsche (kann dies und das noch drauf, ich will lieber Arial, kann es denn Charts für Temperatur und Feuchte)
Das darf nicht dahin führen, das wir irgend wann im Wesentlichen an einem LGD (LaCrosseDisplay) arbeiten
Unterscheib. Meine Idee war ein paar Betriebsdaten zu entlocken – alles andere ist nice to have. Der Fokus sollte mMn bei Betriebsdaten liegen.
Zitat von: HCS am 05 Mai 2016, 08:50:35
Kannst Du mir mal einen Link auf die Display-Lib posten, die Du eingebunden hast?
Gerne.
Hier (http://blog.squix.org/2015/12/esp8266-weather-station-measuring.html) gibt es eigentlich alle Informationen.
Mein Ablauf war:
- Über den Arduino IDE Library Manager den SSD1306 Treiber und die ESP8266 Weather Station installiert
(http://up.picr.de/25448179kb.png)
- Aus dem entsprechenden Verzeichnis die Treiber und die Libs in das LGW-Projekt kopiert und eingebunden.
- LGW Code angepasst...
Falls Fragen aufkommen, dann bitte einfach melden.
Die von Wzut vorgeschlagene Adafruit sollte (ähm, er hat's bereits ausprobiert?!) auch funktionieren, man müsste den Funktionsumfang/ die Performance der beiden Libs abgleichen. Die habe ich bisher nicht im Einsatz gehabt - für meine Demo war Weather Station ideal (Läuft übrigens seit 4 Tagen ohne Probleme).
@Wzut: Mein Display ist auch über die Adresse 0x3c ansprechbar.
@Maxel: Sollte funktionieren (Keine Garantie). Manche Displays haben einen (Löt)Jumper mit dem man die Adresse bestimmen kann, das hat mein OLED nicht.
@AxelSchweiss: Wenn Du magst, dann kann ich dir gerne meine Firmware zusenden, um zu sehen, ob dein OLED hell wird? Ich muss nur schauen wie ich dir das bereitstellen kann.
P.S: @HCS – So jetzt haue ich noch einen raus ;). Wenn Du magst, dann kann ich dir gerne 1-2 von den OELD(s) zusenden (ich habe hier noch 3 liegen.) ;)
Zitat von: amunra am 05 Mai 2016, 23:04:50
Wenn Du magst, dann kann ich dir gerne 1/2 von den OELD(s) zusenden (ich habe hier noch 3 liegen.) ;)
Ein halbes? ;D ;D ;D
Nee, klar, super, dann muss ich nicht drei Wochen warten, bis ich was aus China bekomme.
Sonst geht es mir noch wie Wzut und ich habe vergessen, warum ich es bestellt habe ;D ;D ;D
Vielleicht ist meine Begeisterung ja unermesslich, wenn ich es live vor mir sehe :)
Ich melde mich per PM.
Zitat von: amunra am 05 Mai 2016, 23:04:50
@AxelSchweiss: Wenn Du magst, dann kann ich dir gerne meine Firmware zusenden, um zu sehen, ob dein OLED hell wird? Ich muss nur schauen wie ich dir das bereitstellen kann.
Zippen und hier anhängen. Würde sie auch gerne mal anschauen (also den Source)
Am besten Du hängst sowohl den Source als auch das bin dran.
PS: den ganzen Tag frage ich mich, ob ich wohl etwas zu Vatertag bekomme. Und kurz bevor er rum ist: ein OLED Display 8) 8) ;D
Aber im Ernst: ich bezahle es natürlich.
Zitat von: amunra am 05 Mai 2016, 23:04:50
@AxelSchweiss: Wenn Du magst, dann kann ich dir gerne meine Firmware zusenden, um zu sehen, ob dein OLED hell wird? Ich muss nur schauen wie ich dir das bereitstellen kann.
Cool ... vielleicht bekomme ich das Ding dann ja mal zum Laufen.
Wenn nix dagegen spricht hänge den Code doch als Zip an den Thread an oder schicke mir ne PN ... wenn man da ZIPs dranhängen kann.
:D :D :D
Wenn ich richtig gezählt habe – ich war nämlich heute Morgen spät dran und musste noch die Kinder in den Kindergarten bringen - und den horizontalen Schnitt richtig gesetzt habe, dann sind gerade 4096 Pixel inkl. Anschlußpins zu dir unterwegs. :D
Wegen dem Code melde ich mich, ich hoffe, dass ich heute Abend dazu komme? Eines Vorab, den habe ich in ca. 3 Stunden zusammengetackert, wehe ihr steht mit Mistgabel und Peitsche an meiner Haustür :D
Viele Grüße
Arthur
Zitat von: amunra am 06 Mai 2016, 09:18:45
... dann sind gerade 4096 Pixel inkl. Anschlußpins zu dir unterwegs.
Prima, dann kann ich ja die untere Hälfte mal implementieren.
Zitat von: amunra am 06 Mai 2016, 09:18:45
Eines Vorab, den habe ich in ca. 3 Stunden zusammengetackert, wehe ihr steht mit Mistgabel und Peitsche an meiner Haustür :D
Ganz entspannt bleiben, das ist nicht das entscheidende Kriterium. Ich werde es eh dann so implementieren, wie ich so was halt implementiere :)
Kaum zu fassen, jetzt ist es bei mir auch so weit :o ich denke gerade darüber nach, ob es Sinn macht, dem Display von FHEM aus Meldungen zu schicken ...
so dritter Anlauf >:( das FORUM will meine Dateien nicht :-[ :-\
vierter Anlauf, die Files liegen auf meinem Repo.
so bitte (siehe Anhang):
Ich habe mal durch den Code durchgekehrt und hoffe, dass ich nicht zu viel davon entfernt habe, wenn auch mein mini-Test erfolgreich war.
Hinweise:
- SDK 1.5.2 und nicht wie im original LGW SDK: 1.5.1(e67da894) - daher keine Aussage über Funktionalität und Stabilität in full blown Aussattung.
- OLED ist fest auf 0x3C eingestellt - im Terminal sieht man einen Scanner der alle I2C Devices auflistet (wird sicher nicht so bleiben - ist nur eine Hilfestellung - war nur ein dirty hack). Also, nichts mit Autoerkennung.
- Flip/Slide funktioniert bisher nur mit BME280 @AxelSchweiss: Solltest Du keinen haben, dann sollte dein OLED Test hoffentlich trotzdem etwas anzeigen (Bootvorgang).
- Bootvorgang wird, wenn auch nicht vollständig, auf dem OLED Dargestellt, ich habe in der Demo Version 2000 milisec. Delay eingebaut (siehe Funktion "oledDrawBoot"), damit man überhaut etwas sieht, den habe ich reausgenommen, also Speedy Gonzales Mode an, sprich schnell schauen was drauf steht.
... den Rest, nun ja ihr seid ja groß genug und werdet es herausfinden ;) sonst bei Fragen einfach hier melden.
Viel Spaß
Arthur.
EDIT: So, habe es doch noch geschafft die Files anzuhängen.
Du hast es geschafft, dass die Pixel heute bei mir angekommen sind 8)
Vielen Dank!
Jetzt brauche ich mal ein Zeit lang, um es kennen und lieben zu lernen ...
Na wer sagt's denn - dein Board sieht doch gleich besser aus ;)
Zitat von: HCS am 07 Mai 2016, 19:03:24
Du hast es geschafft, dass die Pixel heute bei mir angekommen sind 8)
Vielen Dank!
Gerne.
Zitat von: HCS am 07 Mai 2016, 19:03:24
Jetzt brauche ich mal ein Zeit lang, um es kennen und lieben zu lernen ...
Nur keinen Stress aufkommen lassen.
Viele Grüße
Arthur
Zitat von: HCS am 06 Mai 2016, 20:49:40
Kaum zu fassen, jetzt ist es bei mir auch so weit :o ich denke gerade darüber nach, ob es Sinn macht, dem Display von FHEM aus Meldungen zu schicken ...
Ich scheibe meine Gedanken gerade einfach mal so runter (Brainstorming mode an ;) ) ....
V 1.0:Alles in OLED Klassen/Framework/Funktionen (jedoch reglementiert) packen:
- Wetter Stationen (Wind, Hum, Temp...)
- Energie (PCA301...)
- Custom Devices (BMP180/BME180/DHT.....)
andere unterstützten Devices.
Die in FHEM erkannten/definierten Devices per Attribut (oder was auch immer) ShowOnOLEDDisplay=1 (oder so ähnlich) anzeigen zu lassen. Dafür müssten diverse Module angepasst werden.
Sonst kann es ein Attribut (comma separated values) am LaCrosseGateway Device sein. Du wirst aber sicher schon eine Idee haben wie man es realisiert.
Das Gerüst sollte statisch bleiben, alles andere ist mit Frust und riesen Support Aufwand verbunden.
KIS Prinzip: BME280 in FHEM erkannt -> willst Du es auf dem "Display sehen"
Ja/Nein. Punkt (Keine custom Schriftarten, Schriftgröße, Icons, BMP's etc....). In diesem Fall "custom device/am LGW angeschlossen"
Ja/Nein, über WEB konfigurierbar!
Wetterstation in FHEM erkannt -> willst Du es auf dem "Display sehen"
Ja/Nein. Punkt (Keine custom Schriftarten, Schriftgröße, Icons, BMP's etc....).
In Bezug auf Stabilität, aber auch Programmierung, wird das schon genug Aufwand generieren - Erfahrungen sammeln und weiter entwickeln.
V 2.0 (wenn überhaupt):- "Global" Schriftarten definieren.
- Custom BMP's Hum/Temp
- Custom .....
Display Konfigs (Silde-Frequenz,etc.) sollten über WEB (Später FHEM!?) konfigurierbar sein - Einstellungen gelten für alle Klassen.
Dies sind nur Ideen die ich in den Raum werfe...
Gruß
Arthur
P.S: Aber wie bereits geschrieben, probiere das Device erstmal aus.... und lass dir Zeit.
Ich habe mal ein grob-Konzept entworfen. Ob das alles so realisierbar ist, ohne zu viel Stress und andere Abläufe im LGW zu beeinträchtigen muss ich noch schauen. Aber es kann ja Stück für Stück da hin wachsen.
Konfiguration auf der Setup-Page des LGWOLED-Address: <Adresse> (default 0x3C) oder off für keins
eventuell Auto-Erkennung
Steuerung von FHEM ausset myJeeLink raw "OLED slide=20"
-> alle 20 Sekunden zur nächsten Page
set myJeeLink raw "OLED mode=ths"
set myJeeLink raw "OLED mode=thp"
set myJeeLink raw "OLED mode=o"
set myJeeLink raw "OLED mode=f"
usw. usw.
t: Temperatur
h: Feuchte
p: Luftdruck
s: Statuswerte
f: FHEM-Meldung
o: nichts (Display dunkel)
wenn mehrere Pages angewählt sind (z.B. thp), dann shiften sie durch
Um von FHEM aus etwas anzuzeigen (max. 3 Zeilen zu je 12 Zeichen) sendet man:
set myJeeLink raw "OLED print=Hi from FHEM\nCoffe is cold\n(27 °C)"
set myJeeLink raw "OLED mode=f"
Steuerung vom LGW ausMax vier Buttons (an A0 angeschlossen per Widerstandsnetzwerk)
senden KeyValueProtokoll an FHEM:
OK VALUES LGPB 211 PB1=0,PB2=1,PB3=0,PB4=0
AnzeigenDie oberste Zeile ist fix und zeigt den Titel der Page und/oder den Indicator
Boot:
Nur die "Meilensteine" in Kurzform
Das komplette boot-log kann man eh nicht lesen und wenn man Probleme sucht, nimmt man besser die Log-Page des frontend oder die Serielle
Betrieb:
5 mögliche Pages:
- Temperatur des internen Sensors (sofern vorliegend)
- Feuchte des internen Sensors (sofern vorliegend)
- Luftdruck des internen Sensors (sofern vorliegend)
- FHEM-Meldung
- Statuswerte
- Version
- RSSI
- Frames/Minute
- Heap
Das hätte folgende Vorteile:
- Man kann von FHEM aus etwas anzeigen lassen
- Die Funktion der Buttons ist nicht HCS-gegeben sondern man kann es in FHEM so verdrahten wie man möchte (notify, doif, ...)
- Die Konfiguration, was man eigentlich sehen will (im Rahmen der oben gegebenen Möglichkeiten) kann man in FHEM vornehmen
- Die Buttons können auch für was ganz anderes verwendet werden (Kellerlicht aus, Bierkühler an, ...)
- Es funktioniert mit den bereits vorhandenen Modulen in FHEM
Damit könnte man sich dann z.B. in FHEM so etwas konfigurieren:
Button 1: aus (set myJeeLink raw "OLED mode=o")
Button 2: Statuswerte (set myJeeLink raw "OLED mode=s")
Button 3: Sensordaten (set myJeeLink raw "OLED mode=thp")
Button 4: Pizza bestellen (set pizzaOrderDevice Calzone)
Oder das Display von 23:00 bis 05:00 dunkel schalten
Oder ...
Ich hoffe ihr habt erkannt, wo das hinläuft ...
Kennt eigentlich jemand einen Einbaurahmen für das Display?
Wenn das am Schluss wo steht, wo man es sehen kann, was ja Sinn macht, sollte es auch passabel aussehen.
Nachtrag: die slide-Frequenz hatte ich verdrängt und gerade mal noch oben reingeschrieben. Auf die Art können aber beliebigen sinnvolle Parameter gesetzt werden.
Zitat von: HCS am 08 Mai 2016, 12:01:12
Oder das Display von 23:00 bis 05:00 dunkel schalten
Oder ...
Wie wärs den mit einem Dunkelschalten nach vorgegebenen Zeitintervall.
Und mit einem Tastendruck wird wieder eingeschaltet ... bzw die Anzeige weiter geschaltet.
Dazu bräuchte man aber einen GPIO bzw. einen analogen GPIO.
Weil ... die OLEDs halten ja auch nicht ewig.
Was auch noch schick wäre ... die Anzeige wird bei neuem Inhalt (aber nur wenns von remote kommt) angeschaltet und danach nach obigem Muster.
Mein ich mal so ... quasi als Mitleser.
Zitat von: AxelSchweiss am 08 Mai 2016, 12:47:33
Wie wärs den mit einem Dunkelschalten nach vorgegebenen Zeitintervall.
Und mit einem Tastendruck wird wieder eingeschaltet ... bzw die Anzeige weiter geschaltet.
Genau das alles solltest Du Dir mit dem von mir beschriebenen Konzept einrichten können.
Man kann von FHEM aus steuern, was das Display tun soll und hat Events in FHEM, wenn ein Butten betätigt wurde.
LGW-Intern gibt es keinerlei Zusammenhang zwischen den Buttons und dem Display.
Ob Du das Display 2 Minuten nach Sonnenuntergang, mit einem at 10 Minuten nach einem Button-Press oder bei Neumond ausschaltest, ist Deine Konfiguration in FHEM
Genau das ist der Grund für das angedachte Konzept: aus der Diskussion "kann es Nachts oder Sonntags oder nur Luftdruck oder ..." rauszukommen.
Es macht von sich aus nichts dergleichen sondern man agiert oder reagiert in FHEM und lässt es etwas tun. Und zwar jeder das, was er gerne möchte.
Und dann gibt es halt noch ein default-Verhalten, wenn man nichts in FHEM implementiert.
Also mal für Dein Beisiel oben:
wenn ein Button gedrückt wurde, hast Du ein Event vom KVP-Device, damit schickst Du ein
set myJeeLink raw "OLED mode=thp"dass das Display angeht und die Sensordaten anzeigt und startest einen at, der nach 10 Minuten ein
set myJeeLink raw "OLED mode=o"schickt, dass das Display dunkel wird.
PS: auf das Protokoll set myJeeLink raw "OLED mode=thp" darf man sich jetzt mal nicht festbeißen, das ist die Idee, so oder so ähnlich wird man es schicken.
Cool ...
Sollte ja auch keine Kritik sein.
Muss mal zählen wieviele GPIO noch auf dem Gateway frei sind :)
Zitat von: HCS am 07 Mai 2016, 19:03:24
Jetzt brauche ich mal ein Zeit lang, um es kennen und lieben zu lernen ...
(https://forum.fhem.de/index.php?action=dlattach;topic=52921.0;attach=51825;image)
Ohne Steckbrett scheint es bei Dir nicht zu gehen ;)
Dann sammle ich mal fleißig Anregungen für die LGW Aufsteckplatine ...
Bin gerade bedingt durch Wasserrohrbruch bzw. die gestrigen Gartenaktivitäten etwas in der Zeit limitiert.
Wünsche noch einen schönen Sonntag.
Viele Grüße
Peter
Na dann wird auch dieser Aufsatz ein Erfolg :)
Zitat von: AxelSchweiss am 08 Mai 2016, 14:31:53
Sollte ja auch keine Kritik sein.
War ja auch keine.
Zitat von: AxelSchweiss am 08 Mai 2016, 14:31:53
Muss mal zählen wieviele GPIO noch auf dem Gateway frei sind :)
Ohne SC16IS750 abgesehen von dem Analog Port genau Null.
Zitat von: PeMue am 08 Mai 2016, 15:03:14Dann sammle ich mal fleißig Anregungen für die LGW Aufsteckplatine ...
Aufsteckplatine? Habe ich gerade Aufsteckplatine gelesen?
Wie cool ist das denn?
Das gehört in die Kategorie "was ich mich nie zu fragen getraut habe" ;D
Zitat von: PeMue am 08 Mai 2016, 15:03:14Bin gerade bedingt durch Wasserrohrbruch bzw. die gestrigen Gartenaktivitäten etwas in der Zeit limitiert.
Oh, üble Sache. Viel Erfolg.
Zitat von: PeMue am 08 Mai 2016, 15:03:14
Ohne Steckbrett scheint es bei Dir nicht zu gehen ;)
So ist es. Ich habe noch hundert Jumper wires und 1000 Zeilen Quellcode übrig, das muss verbraucht werden. ;D
Zitat von: Maxel am 08 Mai 2016, 15:44:03
Na dann wird auch dieser Aufsatz ein Erfolg :)
Wenn er die so super hin bekommt wie die untere dann garantiert.
Zitat von: HCS am 08 Mai 2016, 16:28:53
Ohne SC16IS750 abgesehen von dem Analog Port genau Null.
Na ... dann kann man da ja mindestens 10 Schalter dranbauen ... über Widerstandskaskaden :)
@HCS: Das hört sich alles schon super an... Bezüglich des Einbaurahmens, ein 3D Drucker wäre jetzt gut. Alternativ könnte man mit sowas arbeiten (http://www.schaeffer-ag.de/)?
Viele Grüße
Arthur
Zitat von: AxelSchweiss am 08 Mai 2016, 17:00:19
Na ... dann kann man da ja mindestens 10 Schalter dranbauen ... über Widerstandskaskaden :)
Eine Alternative wäre noch etwas wie der MCP23008, anstatt sich R-Netze zusammenzufrickeln.
Dann bliebe der Analogport auch noch frei für was wirklich analoges eines Tages.
Einfach an I2C mit dran
8 Inputs
Interne Pullups
Damit würde ich dann per KVP die 8 Eingänge bereitstellen.
Kann man einfach Taster gegen GND oder sonstwas anschließen.
Zitat von: HCS am 08 Mai 2016, 22:32:10
Eine Alternative wäre noch etwas wie der MCP23008, anstatt sich R-Netze zusammenzufrickeln.
Stimmt ... daran habe ich gar nicht gedacht. ::)
EDIT: Dann würde da ja sogar ein Tastenfeld dran passen ...
Zitat von: HCS am 08 Mai 2016, 22:32:10
Damit würde ich dann per KVP die 8 Eingänge bereitstellen.
Kann man nun davon ausgehen, dass der MCP23008 gesetzt ist?
Ich wäre dafür, da ich ein paar davon habe.
Viele Grüße
Arthur
Zitat von: amunra am 11 Mai 2016, 22:38:34
Kann man nun davon ausgehen, dass der MCP23008 gesetzt ist?
Eigentlich schon, ohne dass ich jetzt eine Garantie dafür gebe.
Nachdem ich einen in der Bastelkiste gefunden habe, habe ich es mal testweise implementiert.
Funktioniert prima.
Vorteil:
- bis zu 8 Buttons
- man kann mehrere Buttons gleichzeitig betätigen
- keine externe Beschaltung erforderlich
In FHEM stellt es sich dann so dar (der auto create hat das beim ersten Betätigen eines Buttons angelegt):
Internals:
(etwas ausgedünnt)
DEF LGPB 211
ID LGPB_211
IODev JeeLink211
JeeLink211_RAWMSG OK VALUES LGPB 211 PB0=0,PB1=0,PB2=0,PB3=0,PB4=0,PB5=0,PB6=0,PB7=0
NAME Buttons211
TYPE KeyValueProtocol
Readings:
2016-05-11 21:34:06 PB0 0
2016-05-11 21:34:06 PB1 0
2016-05-11 21:34:06 PB2 0
2016-05-11 21:34:06 PB3 0
2016-05-11 21:34:06 PB4 0
2016-05-11 21:34:06 PB5 0
2016-05-11 21:34:06 PB6 0
2016-05-11 21:34:06 PB7 0
Attributes:
IODev JeeLink211
event-on-change-reading PB0,PB1,PB2,PB3,PB4,PB5,PB6,PB7
room .Display
Dazu baut man sich dann solche notifies:
Internals:
CFGFN
DEF Buttons211:PB0.* set JeeLink211 raw "OLED mode=thp"
NAME tn0
NOTIFYDEV Buttons211
NR 392
NTFY_ORDER 50-tn
REGEXP Buttons211:PB0.*
STATE 2016-05-11 21:34:06
TYPE notify
Readings:
2016-05-10 21:03:02 state active
Attributes:
room .Display Und die Schaltung sieht schlicht so aus:
|-------\/-------|
LGW D1 |1 SCL VDD 18| LGW 3.3V
LGW D2 |2 SDA GP7 17| PB7 --/ --- GND
LGW 3.3V |3 A2 GP6 16| PB6 --/ --- GND
LGW 3.3V |4 A1 GP5 15| PB5 --/ --- GND
LGW 3.3V |5 A0 GP4 14| PB4 --/ --- GND
LGW 3.3V |6 RES GP3 13| PB3 --/ --- GND
|7 NC GP2 12| PB2 --/ --- GND
|8 INT GP1 11| PB1 --/ --- GND
LGW GND |9 VSS GP0 10| PB0 --/ --- GND
|----------------|Ganz unabhängig von einem Display hätte man damit, wenn man ein LGW ohne Radios und Sensoren sondern nur mit einem MCP23008 baut, einen 8 Kanal wifi digital port. :)
Da müssen ja nicht unbedingt PushButtons dran, über Optokoppler z.B. könnte man jedes beliebige Digitalsignal an FHEM übermitteln.
Die Umlaufzeit, also bis nach dem Betätigen eines Buttons die Änderung in FHEM ist, der notify reagiert hat und dessen command wieder beim LGW angekommen ist, liegt bei ca. 0,5 Sekunden.
Ich muss mal am WE noch einige Tests machen, aber das sieht gut aus.
Großartig! Das wird ja ein ganz großes Mäusekino. :D
Kann mir mal bitte jemand mit dem notify helfen?
Ich bekomme es nicht geregelt :(
Wenn ich einen Button am LGW betätige, dann sendet es zwei mal das KVP - wenn man ihn drückt und wenn man ihn loslässt.
Im Eventmonitor stellt sich das so dar:
2016-05-14 07:41:50 KeyValueProtocol Buttons211 PB0: 1
2016-05-14 07:41:50 KeyValueProtocol Buttons211 PB0: 0
In meinem notify will ich nur auf das event mit 1 reagieren.
So wie er aktuell ist, reagiert er auf beide. Ich habe schon alles, was das lateinische Alphabet hergibt, ausprobiert. ::)
Internals:
CFGFN
DEF Buttons211:PB0.* set JeeLink211 raw "OLED mode=thp"
NAME tn0
NOTIFYDEV Buttons211
NR 392
NTFY_ORDER 50-tn
REGEXP Buttons211:PB0.*
STATE 2016-05-14 07:41:50
TYPE notify
Readings:
2016-05-12 15:19:53 state active
Attributes:
room .Display
ein paar Varianten hätte ich im Angebot, die Du probieren könntest:
Buttons211:PB0.*1
Buttons211:PB0:1
Buttons211:PB0:.*1
Vielleicht hilft/passt einer? Mein Favorit ist, wenn auch ungetestet, Zeile 2 :D
Die doppelten Trigger wirst du per eigene perl routine oder per event-on-change los.
Zitat von: amunra am 14 Mai 2016, 10:13:43
ein paar Varianten hätte ich im Angebot, die Du probieren könntest:
Buttons211:PB0.*1
Buttons211:PB0:1
Buttons211:PB0:.*1
Vielen Dank!
1 und 3 funktionieren, 2 nicht.
Seltsam, ich könnte wetten, dass ich 1 probiert hatte ???
Egal, nun tut es was ich will.
Zitat@amunra: als MCP23008-Besitzer kannst Du mal die PushButtons mit dieser Version ausprobieren, wenn Du willst.
Fragen und Ergebnis dann im "Display-Thread"
*wow* sieht bisher gut aus und OLED spricht auch schon mit mir, und ich kann es von FHEM aus auch schon ein-/ausschalten 8) Danke.
Starting frontend
Starting OTA
Starting data port 1 on 81
Searching RFMs and Sensors
BME280 found
MCP23008-PushButtons found
Sending init String to FHEM
[LaCrosseITPlusReader.Gateway.1.19 + BME280 + OLED + Buttons {IP=10.10.10.91}]
Setup completely done
OK VALUES LGPB 14026921 PB0=0,PB1=0,PB2=0,PB3=0,PB4=0,PB5=0,PB6=0,PB7=0
OK WS 0 4 4 236 43 255 255 255 255 255 255 255 255 0 3 214
OK VALUES LGPB 14026921 PB0=1,PB1=0,PB2=0,PB3=0,PB4=0,PB5=0,PB6=0,PB7=0
OK VALUES LGPB 14026921 PB0=0,PB1=0,PB2=0,PB3=0,PB4=0,PB5=0,PB6=0,PB7=0
OK VALUES LGPB 14026921 PB0=0,PB1=0,PB2=1,PB3=0,PB4=0,PB5=0,PB6=0,PB7=0
OK VALUES LGPB 14026921 PB0=0,PB1=0,PB2=0,PB3=0,PB4=0,PB5=0,PB6=0,PB7=0
OK WS 0 4 4 236 44 255 255 255 255 255 255 255 255 0 3 214Autocreate hat nicht funktioniert, muss aber noch nichts heißen ... ich werde es mir in Ruhe anschauen, soll heißen - ausführliche Tests folgen.
Viele Grüße
Zitat von: amunra am 15 Mai 2016, 01:17:10... und OLED spricht auch schon mit mir ...
Bring jetzt nur keinen auf die Idee, dass an das LGW auch noch ein Lautsprecher dran sollte ... ;D
Das OLED gibt in dieser Test-Version einfach stumpf die von FHEM erhaltenen Kommandos aus. Ein "OLED mode=o" schaltet es dunkel, bei allen anderen Commands wird es hell und zeigt sie an.
Ist im Wesentlichen um die Kommunikation zu testen und zu sehen, wie sich die Verzögerung eines Umlaufs
"Button gedrückt -> KVP senden -> FHEM -> notify -> set myJeelink raw -> LGW -> Display"
anfühlt.
Da Buttons und Display unabhängig von einander arbeiten, will ich erst mal die Buttons zum Abschluss bringen und eine Release machen, dass der EC3000 Bug offiziell aus der Welt ist und dann mit dem Display weiter spielen.
Wenn Du das noch ein wenig testen würdest wäre super. Focus liegt auf den Buttons. Dann könnte ich evtl. dieses WE noch eine Release rauslassen, in der die PushButtons offiziell sind (natürlich ohne geistreiche Display-Funktionalität) und EC3000 gerettet ist.
so in aller Kürze (mal zwischendurch...) von mir die Erfahrungswerte zu der neunen Button-Funktion:
- Meine Taster (normale push Buttons) haben keinen Prellschutz, das macht sich durchaus (sehr oft) bemerkbar und zwar so, dass Tastendrücke nicht immer durchkommen. Man kann dem entgegenwirken und die Buttons entprellen (https://www.mikrocontroller.net/articles/Entprellung). Dafür kann diese (http://playground.arduino.cc/Code/Bounce) Adruino Lib verwenden - diese soll, wenn auch nicht zu 100%, Abhilfe schaffen.
- Ich habe noch etwas seltsame Effekte in FHEM, kann aber mit den zuvor genannten Punkt zusammenhängen, dass ,,alle" Buttons geschaltet werden, obwohl aktuell nur drei Buttons (im Moment keine mehr da :( – sind aber unterwegs ;)) angeschlossen sind
(http://up.picr.de/25549184ra.jpg)
Grundsätzlich funktioniert das schon ganz gut und die Daten kommen sonst zügig bei FHEM an.
Zitat von: HCS am 15 Mai 2016, 08:12:17
Bring jetzt nur keinen auf die Idee, dass an das LGW auch noch ein Lautsprecher dran sollte ... ;D
Na, schauen wir mal was da noch kommt, vielleicht auch noch ein Mikrofon damit man sich unterhalten kann... ;) Die ToDo Liste sollte aber eh schon lang sein...
Zitat von: HCS am 15 Mai 2016, 08:12:17
Das OLED gibt in dieser Test-Version einfach stumpf die von FHEM erhaltenen Kommandos aus. Ein "OLED mode=o" schaltet es dunkel, bei allen anderen Commands wird es hell und zeigt sie an.
Ist im Wesentlichen um die Kommunikation zu testen und zu sehen, wie sich die Verzögerung eines Umlaufs
"Button gedrückt -> KVP senden -> FHEM -> notify -> set myJeelink raw -> LGW -> Display"
anfühlt.
Ja, :D ich konnte es einfach nicht lassen es mal zu probieren.... ;)
Zitat von: HCS am 15 Mai 2016, 08:12:17
Da Buttons und Display unabhängig von einander arbeiten, will ich erst mal die Buttons zum Abschluss bringen und eine Release machen, dass der EC3000 Bug offiziell aus der Welt ist und dann mit dem Display weiter spielen.
Mach dir bitte keinen Stress, die anderen Themen gehen vor und ich bin im Moment auch etwas Land unter :-\
P.S: Ich lasse noch eine Idee hier (Prio: "ultra low" - Button Version 5.0 ;)), vielleicht musst Du das evtl. jetzt schon bei der Implementierung berücksichtigen? Es wäre gut per MCP23008 LED's zu steuern. Use case und Detials können wir gerne noch diskutieren. Wie bereits geschrieben nur eine "Idee".
P.P.S: Idee ist: 4 Buttons und 4 LED's. mit dem MCP23008 abzubilden.
Zitat von: amunra am 15 Mai 2016, 11:24:23
- Meine Taster (normale push Buttons) haben keinen Prellschutz, das macht sich durchaus (sehr oft) bemerkbar und zwar so, dass Tastendrücke nicht immer durchkommen.
Die buttons werden nur alle 125ms abgefragt, wenn das LGW gerade mit etwas beschäftigt ist, dann ist es sogar etwas länger.
Ganz kurz antippen geht also nicht. Ich verwende die PushButtons, von denen man einen auf diesem Bild sehen kann:
https://forum.fhem.de/index.php/topic,52921.msg448573.html#msg448573
Zitat von: amunra am 15 Mai 2016, 11:24:23... dass ,,alle" Buttons geschaltet werden, obwohl aktuell nur drei Buttons (im Moment keine mehr da :( – sind aber unterwegs ;)) angeschlossen sind
Das bekomme ich nicht hin. Ich habe vier PushButtons dran und auf denen eine Minute lang in allen Varianten von "geistreich betätigt" bis "wie bescheuert drauf rumgehämmert" gespielt. Ergebnis siehe Anhang.
Das "Schlimmste", was dabei passiert ist, ist, dass eine Betätigung kein Event ausgelöst hat.
Entprellen: ich habe jetzt nicht alle verlinkten Varianten durchgelesen, aber ich glaube, dass Software-Entprellungen entweder Interrupt-behaftet sind, oder heftig pollen müssen oder delays erzeugen. Nichts davon kommt in Frage.
Wenn man definiert, dass immer nur ein Button gedrückt sein darf, könnte man das natürlich prüfen und ggf. dann verwerfen und nicht an FHEM übermitteln. Das würde dann etwas mehr Sicherheit rein bringen.
Zitat von: amunra am 16 Mai 2016, 00:36:46
P.S: Ich lasse noch eine Idee hier (Prio: "ultra low" - Button Version 5.0 ;)), vielleicht musst Du das evtl. jetzt schon bei der Implementierung berücksichtigen? Es wäre gut per MCP23008 LED's zu steuern. Use case und Detials können wir gerne noch diskutieren. Wie bereits geschrieben nur eine "Idee".
P.P.S: Idee ist: 4 Buttons und 4 LED's. mit dem MCP23008 abzubilden.
In welchem use case würden LEDs vorkommen, wenn man ein Display hat?
Aber generell würden vier Button wohl reichen. Wenn ich überlege, was ich damit machen würde, wäre das z.B.:
- Display aus
- Statuswerte
- Temperatur -> Shift Feuchte -> Shift Druck -> ...
- Sonstwas
Alternative wäre einfach ein zweiter MCP23008 mit 8 Ausgängen, falls man so was haben will.
Das wäre vom aktuellen Stand aus fast einfacher zu realisieren als es aufzuteilen.
Mit einem ESP-12E und zwei MCP23008 kann man sich dann auch ein WIFI-IO mit 8 Eingängen und 8 Ausgängen bauen.
Zitat von: HCS am 16 Mai 2016, 10:25:28
Die buttons werden nur alle 125ms abgefragt, wenn das LGW gerade mit etwas beschäftigt ist, dann ist es sogar etwas länger.
Ganz kurz antippen geht also nicht.
Verhalten passt ganz gut mit meinen Testergebnissen.
Zitat von: HCS am 16 Mai 2016, 10:25:28
Ich verwende die PushButtons, von denen man einen auf diesem Bild sehen kann:
https://forum.fhem.de/index.php/topic,52921.msg448573.html#msg448573
Dito
Zitat von: HCS am 16 Mai 2016, 10:25:28
Das bekomme ich nicht hin. Ich habe vier PushButtons dran und auf denen eine Minute lang in allen Varianten von "geistreich betätigt" bis "wie bescheuert drauf rumgehämmert" gespielt. Ergebnis siehe Anhang.
Das "Schlimmste", was dabei passiert ist, ist, dass eine Betätigung kein Event ausgelöst hat.
Ich versuche es zu reproduzieren und genauer zu beschreiben wie ich es, doch recht oft, geschafft habe.
Zitat von: HCS am 16 Mai 2016, 10:25:28
Entprellen: ich habe jetzt nicht alle verlinkten Varianten durchgelesen, aber ich glaube, dass Software-Entprellungen entweder Interrupt-behaftet sind, oder heftig pollen müssen oder delays erzeugen. Nichts davon kommt in Frage.
Ja, das ist leider der Preis :(
Zitat von: HCS am 16 Mai 2016, 10:25:28
Wenn man definiert, dass immer nur ein Button gedrückt sein darf, könnte man das natürlich prüfen und ggf. dann verwerfen und nicht an FHEM übermitteln. Das würde dann etwas mehr Sicherheit rein bringen.
Mehrere Buttons gleichzeitig zu betätigen (habe ich bisher nicht versucht!) dürfte eher uninteressant sein, höchstens Sensoren in Firmware Modus zu versetzten. Spricht, wenn es die Performance steigert und Fehlerrate sinkt, dann ist es sinnvoll.
Zitat von: HCS am 16 Mai 2016, 10:58:52
In welchem use case würden LEDs vorkommen, wenn man ein Display hat?
OLED Informationen "aktiv" oder zyklisch abfragen - eher nicht für 7x24h Betrieb gedacht (Also eher etwas kurz darstellen).
LED Status - Informationen anzeigen (Alarm "aktiv" = "grün" | Es regnet/schneit = "blau" | Fenster auf "rot" | Verbindung zu FHEM/WLAN = "weiß" - evtl zyklisch blinken lassen)) - also alles was man beim vorbeigehen/hinschauen (ohne davor zu stehen) darstellen kann. Ich hoffe, das zeigt was gemeint ist.
Und natürlich LED Einsatz, wenn kein OLED verfügbar ist. ;)
Zitat von: HCS am 16 Mai 2016, 10:58:52
Aber generell würden vier Button wohl reichen. Wenn ich überlege, was ich damit machen würde, wäre das z.B.:
- Display aus
- Statuswerte
- Temperatur -> Shift Feuchte -> Shift Druck -> ...
- Sonstwas
Bei mehr als vier Buttons ist man(ich) eh überfordert ;) bzw. man müsste es beschriften, damit ich nach ein paar Tagen noch weiß was, was ist :(
Zitat von: HCS am 16 Mai 2016, 10:58:52
Alternative wäre einfach ein zweiter MCP23008 mit 8 Ausgängen, falls man so was haben will.
Das wäre vom aktuellen Stand aus fast einfacher zu realisieren als es aufzuteilen.
Mit einem ESP-12E und zwei MCP23008 kann man sich dann auch ein WIFI-IO mit 8 Eingängen und 8 Ausgängen bauen.
Ja, verstehe - bei kleineren Projekten (Taster mit vier Buttons und LED's) ein Overkill, aber immer noch besser als nichts, und das ist keine Kritik, sondern eher meckern auf hohem Niveau. ;)
P.S. Wie bereits geschrieben das MCP23008-LED Thema gerne auch später betrachten (V5.0 wenn überhaupt).
Zitat von: amunra am 16 Mai 2016, 23:24:37ch versuche es zu reproduzieren und genauer zu beschreiben wie ich es, doch recht oft, geschafft habe.
Ja, das wäre gut.
Wenn ich es auch produzieren könnte, hätte ich eine Chance, etwas dagegen zu tun.
Neue Strategie:
Man kann auf der Setup-Page des LGW für die 8 Ports des MCP23008 einstellen, was er jeweils tun soll.
Das kann sein:
"Input"
Der Port ist ein Eingang und sein Status wird per KVP an FHEM übermittelt.
Kennen wir ja schon.
"Output"
Der Port ist ein Ausgang und kann von FHEM aus gesetzt werden.
Beispiele:
set JeeLink211 raw "MCP GP6=1"
set JeeLink211 raw "MCP GP6=0,GP7=1"
"OLED mode=o"
Schaltet das Display dunkel
"OLED mode=s"
Display zeigt die Statuswerte des LGW
"OLED mode=thp"
Display zeigt die (internen) Sensordaten des LGW
Eine spätere Erweiterung der Auswahlmöglichkeiten ist denkbar, z.B.
"WiFi-Connect": Ausgang ist high, wenn die WiFi-Verbindung steht
"FHEM-Connect": Ausgang ist high, wenn sich ein FHEM auf das LGW verbunden hat
...
Das "versehentlich alle High-Problem" kann ich immer noch nicht reproduzieren.
amunra, wie bekommst Du das hin?
Zitat von: HCS am 21 Mai 2016, 08:34:29
Das "versehentlich alle High-Problem" kann ich immer noch nicht reproduzieren.
amunra, wie bekommst Du das hin?
Ich weiß, ich bin noch ein Test inkl. Logging etc. schuldig. Sorry für die angezogene Handbremse - ich melde mich baldmöglichst, bei mir ist im Moment Land unter (hoffe das ich Morgen, ähm gleich/nachher Zeit habe... ??? ) :-\
P.S.: Deine Strategie finde ich gut. Die Useability wird sich im prod Umfeld zeigen, aber bisher alles super.
So, da bin ich wieder...
Ich bin gerade fast verrückt geworden... ich habe ein ½ Stunde ,,alles" gegeben und ich konnte das Problem nicht nachstellen... bis mir ein Idee kam und ich konnte nun das Problem, was vermutlich kein ist, reproduzieren.
Jetzt kommt's: Es lag an der wackeligen Breadboard Verkabelung!. Wenn Du es reproduzieren möchtest, dann entferne von dem MCP23008 die GND Verbindung und stelle sie wieder her.
Hinweis: Mit dem VCC konnte ich dieses Verhalten bei nicht reproduzieren.
Problematisch ist, dass das LGW mit der Situation, dann so gar nicht zurechtkommt und ständig Daten sendet die wie folgt aussehen:
OK VALUES LGPB 14026921 PB0=0,PB1=0,PB2=0,PB3=0,PB4=0,PB5=0,PB6=0,PB7=0
OK VALUES LGPB 14026921 PB0=1,PB1=1,PB2=1,PB3=1,PB4=1,PB5=1,PB6=1,PB7=1
OK VALUES LGPB 14026921 PB0=0,PB1=0,PB2=0,PB3=0,PB4=0,PB5=0,PB6=0,PB7=0
OK VALUES LGPB 14026921 PB0=1,PB1=1,PB2=1,PB3=1,PB4=1,PB5=1,PB6=1,PB7=1
OK VALUES LGPB 14026921 PB0=0,PB1=0,PB2=0,PB3=0,PB4=0,PB5=0,PB6=0,PB7=0
Dann hilft nur noch ein Reset.
Vielleicht siehst Du, ja für den eigentlich unmöglichen Fall, ja eine Chance das im Programm abzufangen?
Viele Grüße
Arthur
Zitat von: amunra am 22 Mai 2016, 21:19:28
Ich bin gerade fast verrückt geworden... ich habe ein ½ Stunde ,,alles" gegeben und ich konnte das Problem nicht nachstellen...
So ging es mir auch.
Zitat von: amunra am 22 Mai 2016, 21:19:28
Es lag an der wackeligen Breadboard Verkabelung!. Wenn Du es reproduzieren möchtest, dann entferne von dem MCP23008 die GND Verbindung und stelle sie wieder her.
Super use case ;D ;D
Ich habe wenig Hoffnung, das einfangen zu können.
Ohne GND wird der MCP23008 wohl irgendwie noch parasitär über einen IO ein wenig versorgt und macht bei Wiederkehr von GND keinen Reset.
Aber er hat zu dem Zeitpunkt vermutlich eh seine Konfiguration verloren (Port-Direction, ...) und würde wohl einen ordentlichen Reset und danach das erneute Senden der Konfiguration benötigen.
Ich gehe jetzt einfach mal davon aus, dass es das in einem "normalen Umfeld" nicht gibt.
Ach ja, das hier:
https://forum.fhem.de/index.php/topic,52921.msg452953.html#msg452953
habe ich implementiert und es scheint soweit zu laufen.
Ich mache wohl ende der Woche eine 1.19, in der der MCP23008 offiziell drin ist und danach dann mit dem Display weiter.
Hilfe!
Grund: meine künstlerischen Fähigkeiten liegen bei Null.
Ist jemand in der Lage, ein 16x16 monchrome XBM zu malen, das ein FHEM-Häuschen darstellt und nicht wie mein Beispiel aussieht, also so, als ob das Häuschen ein Erdbeben der Stärke 7 miterlebt hätte?
Sonst wird das Symbol, dass sich ein FHEM auf das LGW verbunden hat, ein Quadrat :(
Ach ja, 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
WiFi RSSI
Ich fürchte, bei mir sieht das auch nicht besser aus (Konvertierung des fhem Logos) :(
Edit:
Nächster Versuch (mit Zeichnen) siehe Anhang.
Zitat von: PeMue am 26 Mai 2016, 19:06:53
Ich fürchte, bei mir sieht das auch nicht besser aus
Dass Du aber auch immmer Recht hast ;D ;D
fhem_logo.xbm sieht dem Original recht ähnlich, ist aber etwas zerfressen
Gefällt mir auf dem Display aber schon mal besser als meins.
Bis sich was Besseres ergibt, nehme ich das.
fhem_logo-4.xbm sieht fast wie meine Version aus.
Warum musste Rudi aber auch ausgerechnet den Schiefen Turm von Pisa nehmen ;D
Das ist auf 16x16 eine Herausforderung. Halbe Pixel wären hilfreich 8)
Edit: habe es noch ein wenig nachbearbeitet, keine Ahnung, ob es besser ist, anders auf alle Fälle ;D
Ähm, dann versuche ich es auch mal... ;)
#define fhemicon_width 16
#define fhemicon_height 16
const char fhemicon_bits[] PROGMEM = {
0x00, 0x00, 0x80, 0x01, 0xE0, 0x07, 0x38, 0x0C, 0x0E, 0x18, 0x0C, 0x30,
0x44, 0x76, 0x04, 0x20, 0x04, 0x30, 0x14, 0x10, 0x26, 0x14, 0xC6, 0x13,
0x06, 0x10, 0xFC, 0x15, 0x00, 0x1F, 0x00, 0x00, };
Zitat von: amunra am 26 Mai 2016, 22:08:27
Ähm, dann versuche ich es auch mal... ;)
Hat ein schönes Dach, schaut einem freundlich aus winzigen Augen an, nur der untere Rand ist noch etwas unkoordiniert.
Das wird noch lustig hier.
DSDXBMP ;D
Aktuell habe ich:
PeMue version "cleaned by HCS" (momentan mein Favorit)
0x00,0x01,0xE0,0x03,0x70,0x0E,0x1E,0x1C,0x07,0x30,0x46,0x62,
0x26,0xE4,0x06,0x20,0x06,0x20,0x16,0x32,0x12,0x32,0xE2,0x31,
0x02,0x30,0x02,0x10,0x7E,0x10,0x80,0x1Famunra
0x00, 0x00, 0x80, 0x01, 0xE0, 0x07, 0x38, 0x0C, 0x0E, 0x18, 0x0C, 0x30,
0x44, 0x76, 0x04, 0x20, 0x04, 0x30, 0x14, 0x10, 0x26, 0x14, 0xC6, 0x13,
0x06, 0x10, 0xFC, 0x15, 0x00, 0x1F, 0x00, 0x00HCS "das schiefe Haus für Lisa"
0x00, 0x00, 0x00, 0x00, 0x80, 0x03, 0x60, 0x04, 0x18, 0x18, 0xfc, 0x20, 0x06, 0x7f, 0x24, 0x20,
0x54, 0x24, 0x04, 0x2a, 0x14, 0x20, 0xe2, 0x14, 0x02, 0x13, 0x3e, 0x10, 0xc0, 0x1f, 0x00, 0x00Kannst sie ja mal nebeneinander auf Dein Display packen und vergleichen.
ich kann diese (http://4umi.com/web/javascript/xbm.php) Seite empfehlen, dort kann man hier und dort noch Feintuning betreiben ;)
Zitat von: amunra am 26 Mai 2016, 22:25:31
ich kann diese (http://4umi.com/web/javascript/xbm.php) Seite empfehlen, dort kann man hier und dort noch Feintuning betreiben ;)
Mit der Seite habe ich "das schiefe Haus für Lisa" gemalt. Die Seite ist die Höchststrafe ;D
Habe mir dann den hier runtergeladen: http://www.sibcode.com/junior-icon-editor/
Der Name von dem Ding ist peinlich aber man ganz passabel malen und er kann XBM speichern.
;D ;D ;D ;D - für Feintuning reichts ;D ;D :)
Ich möchte jetzt niemanden zu nahe treten, aber dein Favorit hat was von "kann mich bitte jemand ausschalten" ;) :D :D :D :D
Glücklich sieht das Haus jedenfalls nicht aus ;) ;) ;)
Zitat von: amunra am 26 Mai 2016, 22:34:34
;D ;D ;D ;D - für Feintuning reichts ;D ;D :)
Ich möchte jetzt niemanden zu nahe treten, aber dein Favorit hat was von "kann mich bitte jemand ausschalten" ;) :D :D :D :D
Glücklich sieht das Haus jedenfalls nicht aus ;) ;) ;)
EDIT: Es sei den Du möchtest eine fehlgeschlagene Verbindung darstellen ;D
Zitat von: amunra am 26 Mai 2016, 22:34:34
Glücklich sieht das Haus jedenfalls nicht aus ;) ;) ;)
Es kann auch nicht glücklich sein, wenn es schief da steht und nur -101dBm Signal hat ;D
Ich bereue jetzt schon, was ich mit dieser Schnapsidee angezettelt habe. Hätte einfach ein "F" wie FHEM ausgeben sollen.
ich habe noch ein Pixel am rechten Auge entfernt. ;)
0x00, 0x00, 0x80, 0x01, 0xE0, 0x07, 0x38, 0x0C, 0x0E, 0x18, 0x0C, 0x30,
0x44, 0x72, 0x04, 0x20, 0x04, 0x30, 0x14, 0x10, 0x26, 0x14, 0xC6, 0x13,
0x06, 0x10, 0xFC, 0x15, 0x00, 0x1F, 0x00, 0x00
Der aktuelle Stand sieht wie folgt aus - siehe Anhang.
Zitat von: amunra am 26 Mai 2016, 23:37:38
ich habe noch ein Pixel am rechten Auge entfernt. ;)
Du bist Chirurg im echten Leben?
Ich habe mir übrigens eine eigene Lib für das OLED geschrieben. Die "Weather Station" lib ist zwar schön, und das UI-Konzept nicht schlecht, aber die meisten Libs haben das Problem, dass sie so agieren, als gäbe es nichts außer dem Display, und recht hemmungslos auf dem I2C Bus agieren.
Ein einziger Display refresh sind 35ms :o Da muss ich gegensteuern, das LGW hat ja auch sonst noch was zu tun. Aber sie war eine gute Inspiration.
Ich hoffe (wie immer ohne Gewähr) am WE die 1.19 fertig zu haben, die dann zumindest den oberen (gelben) Teil vom Display kann und den MCP23008 komplett, wie ich es schon beschrieben habe, unterstützt.
Ich werfe jetzt mal ein Design in den Raum ;)
Zitat von: oli82 am 07 Juni 2016, 08:22:37
Ich werfe jetzt mal ein Design in den Raum ;)
Meinst Du den Einbaurahmen oder das, was das Display anzeigt?
Die Kombi aus beiden..
Ein einfacher Blindramen mit Lichtsensor, 4 Sensortasten und dem Display
Kurzer Erfahrungsbericht und ein paar Ideen die ich los werden möchte (Sinn/Zweck natürlich zur Diskussion gestellt) - bevor ich es vergesse:
- "OLED Off" ("on" nicht, weil man in den else Zweig springt) ist case sensitive. Um Fehler zu vermeiden wäre es gut, die Abfrage "Off/ofF/off/etc." in LC/UC zu konvertieren? Dies nur als Hinweis. Hat mich zum Glück nur ca. 10 Minuten gekostet bis ich darauf gekommen bin ;)
- OLED sollte seinen change (an/aus) Status an FHEM übermitteln - wenn FHEM Verbindung steht - wie ein Button. Zweck: OLED Statuserkennung on/off.
- Einstellungsmöglichkeit ("Config"-Page) wie sich das OLED nach einem Start verhalten soll Beispiel: 0="an"/x=nach Ablauf der angegebenen Sekunden "aus" Zweck: Man möchte den Startvorgang und evtl. Verbindung zum FHEM beobachten, dann soll sich das OLED schlafen legen, bis es natürlich aus FHEM oder per Button aus dem Schlaf geweckt wird.
Dumme Frage: welche Größe hat denn das Display?
Danke + Gruß
Peter
Maße sind rar bzw. habe ich bisher keine gefunden, die der Realität entsprachen.
Da hilft nur messen. Welche Maße interessieren dich?
Zitat von: amunra am 07 Juni 2016, 21:16:46
Da hilft nur messen. Welche Maße interessieren dich?
Eigentlich nur die Diagonale, der Link von Axel zeigt auf ein knapp 1 " großes Display, was ich als etwas klein empfinde ;)
Edit:Hier ein Link von Aliexpress:
https://cloud.mail.ru/public/c6d69303181c/IIC-OLED%20module%20FZ1109%20FZ1112%20FZ1113%20.rar
Ja es ist ein 0,96 " kleines Display ;)
PCB Maße ca. 2,9x2,6 cm - das Display ist ca. 2,6x1,5 cm groß/klein
anbei ein Vergleich 0,96 " und 2,8 " vielleicht erkennt man den Unterschied besser :D
Zitat von: PeMue am 07 Juni 2016, 21:52:40
... ein knapp 1 " großes Display, was ich als etwas klein empfinde ;)
Hast Du Angst, dass es mit dem Display so wie mit Deinem BME280 im Labor endet? ;D ;D ;D ;D
Um direkt schon die Richtung zu weisen: genau dieses Display ist gesetzt. Ein anderes Display kann man gerne anschließen, dann muss es aber zur aktuellen Software kompatibel sein (SSD1306 Controller) und eine Auflösung von 128 x 64 haben.
Zitat von: oli82 am 07 Juni 2016, 12:03:12
Die Kombi aus beiden..
Ein einfacher Blindramen mit Lichtsensor, 4 Sensortasten und dem Display
Der Rahmen um das Display beeinflusst ja zum Glück die Software nicht ;D
Ein Lichtsensor ist im LGW nicht vorgesehen, es sei denn, man will nur hell/dunkel, dann kann man sich was basteln und das resultierende Digitalsignal dem MCP23008 anvertrauen, womit es in FHEM zur Verfügung steht.
4 Tasten lassen sich Stand heute mit dem MCP23008 machen
Der Inhalt vom Display sieht eher nach einem room node oder einem Heizungsregler aus, beides wird das LGW eher nicht sein.
Mal eine Spielerei von mir, wie an der init-Seite vielleicht zu erkennen? :D ;)
https://youtu.be/A5cdBubW7x0 (https://youtu.be/A5cdBubW7x0)
LGW mit OLED 1306 und gleichzeitig Nextion 2,8 " Touch Display (Macht ja schon mal keinen Sinn...).
Meiner Einschätzung nach, etwas was PeMue eher vorschwebt - zumindest was die "größe" angeht :D ;)
@HCS ganz ruhig ;) es handelt sich nur um einen Prototypen ... ähm, vielleicht reiche ich irgendwann eine Entscheidungsvorlage ein? ;) ;) ;)
P.S.: Das Video ist nicht gut geworden - der Kontrast und die Farben na ja -Zitat PeMue: Die Grafikabteilung hat leider schon lange Wochenende...
Zitat von: amunra am 19 Juni 2016, 22:22:09
Mal eine Spielerei von mir, ...
Wir sind auf dem besten Weg zu einem neuen Frontend ...
Zitat von: HCS am 08 Juni 2016, 08:48:42
Hast Du Angst, dass es mit dem Display so wie mit Deinem BME280 im Labor endet? ;D ;D ;D ;D
Hab das jetzt erst gelesen ;D ;D ;D
Nein, kann gar noch nicht passieren, denn erst mal muss das Display bei mir ankommen. Im Übrigen sind auch Nachschub der BME280 unterwegs. Ich hoffe, ich brauche diesmal keinen
dispute :o
Hat jemand Lust, einen Satz XBM icons zu erstellen?
Anforderungen wären:
- 32 x 32
- monochrome
- Design stimmig über alle Icons hinweg
Benötigt wird:
- Temperature
- Humidity
- Pressure
- System
- Info
- Warning
- Error
Beispiel Error.xbm:
#define error_width 32
#define error_height 32
#define error_x_hot 0
#define error_y_hot 0
static const unsigned char error_bits[] = {
0x00,0x00,0x01,0x00,0x00,0x80,0x02,0x00,0x00,0x80,0x02,0x00,
0x00,0x40,0x04,0x00,0x00,0x40,0x04,0x00,0x00,0x20,0x08,0x00,
0x00,0x20,0x08,0x00,0x00,0x10,0x10,0x00,0x00,0x10,0x10,0x00,
0x00,0x08,0x20,0x00,0x00,0x88,0x23,0x00,0x00,0x84,0x43,0x00,
0x00,0x84,0x43,0x00,0x00,0x82,0x83,0x00,0x00,0x82,0x83,0x00,
0x00,0x81,0x03,0x01,0x00,0x81,0x03,0x01,0x80,0x80,0x03,0x02,
0x80,0x80,0x03,0x02,0x40,0x80,0x03,0x04,0x40,0x80,0x03,0x04,
0x20,0x80,0x03,0x08,0x20,0x00,0x00,0x08,0x10,0x00,0x00,0x10,
0x10,0x00,0x00,0x10,0x08,0x80,0x03,0x20,0x08,0x80,0x03,0x20,
0x04,0x80,0x03,0x40,0x04,0x00,0x00,0x40,0x02,0x00,0x00,0x80,
0xFE,0xFF,0xFF,0xFF,0x00,0x00,0x00,0x00};
Beispiel Temperature.xbm (kann man wohl nehmen, sieht ganz ordentlich aus):
#define temperature_width 32
#define temperature_height 32
#define temperature_x_hot 0
#define temperature_y_hot 0
static const unsigned char temperature_bits[] = {
0x00,0x00,0x00,0x00,0x00,0x80,0x01,0x00,0x00,0x40,0x02,0x00,
0x00,0x20,0x04,0x00,0x00,0x20,0x04,0x00,0x00,0x20,0xE4,0x00,
0x00,0x20,0x04,0x00,0x00,0x20,0x04,0x00,0x00,0xA0,0xE5,0x00,
0x00,0xA0,0x05,0x00,0x00,0xA0,0x05,0x00,0x00,0xA0,0xE5,0x00,
0x00,0xA0,0x05,0x00,0x00,0xA0,0x05,0x00,0x00,0xA0,0xE5,0x00,
0x00,0xA0,0x05,0x00,0x00,0xA0,0x05,0x00,0x00,0xA0,0xE5,0x00,
0x00,0xA0,0x05,0x00,0x00,0xA0,0x05,0x00,0x00,0xA0,0xC5,0x01,
0x00,0xB0,0x8D,0x00,0x00,0x90,0x89,0x00,0x00,0x88,0x91,0x00,
0x00,0x84,0x21,0x00,0x00,0xC4,0x23,0x00,0x00,0xC4,0x23,0x00,
0x00,0xC4,0x23,0x00,0x00,0x88,0x11,0x00,0x00,0x10,0x08,0x00,
0x00,0x20,0x04,0x00,0x00,0xC0,0x03,0x00};
Das sind die Icons, die man sich von FHEM aus zu einem gesendeten Text wünschen kann.
Beispiel:
set JeeLink212 raw "OLED show=Soll: 20.5 °C,Ist: 19.2°C,,t"
Ergebnis siehe Bild t.png
set JeeLink212 raw "OLED show=Futsch,,,e"
Ergebnis siehe Bild e.png
Der letzte Parameter gibt das gewünschte Bild an.
Es können bis zu drei Zeilen angegeben werden, wenn nur eine Zeile wie im "Futsch" Beispiel angegeben wird, dann wird der Text größer dargestellt.
Wenn man kein icon angibt, wird auch keins angezeigt und die komplette Breite für den Text verwendet.
Beispiel:
set JeeLink212 raw "OLED show=Guten Morgen HCS.,Der Kaffee ist schon,fertig. Gruß FHEM"
Ergebnis siehe Bild kaffee.png
Ja Ja Ja, genau so.... 8) 8) 8)
Anbei mein Vorschlag (ich kann es leider nicht testen) - vielleicht kannst Du etwas davon verwenden. Bei Verbesserungsvorschlägen einfach melden... ;)
Dein "Warning" würde ich lassen wie es.
Ich sehe Du hast 3 Zeilen vorgesehen, das sieht bei zwei Zeilen etwas unsymmetrisch aus, siehe Temp, aber das ist Feintuning. ;)
Viele Grüße
Zitat von: amunra am 26 Juni 2016, 22:42:34
Ja Ja Ja, genau so.... 8) 8) 8)
Klar, wie sonst ;D ;D ;D
Zitat von: amunra am 26 Juni 2016, 22:42:34
Anbei mein Vorschlag (ich kann es leider nicht testen) - vielleicht kannst Du etwas davon verwenden. Bei Verbesserungsvorschlägen einfach melden... ;)
Ich baue sie heute Abend mal ein und schaue sie live an.
Zitat von: amunra am 26 Juni 2016, 22:42:34
Ich sehe Du hast 3 Zeilen vorgesehen, das sieht bei zwei Zeilen etwas unsymmetrisch aus, siehe Temp, aber das ist Feintuning. ;)
Wenn man die mittlere Zeile leer lässt wird es wieder symmetrisch :)
set JeeLink212 raw "OLED show=Soll: 20.5 °C
,,Ist: 19.2°C
,t"
anbei ein Set Icons inkl. der von gestern (feingutuned/rumgedoktort, Pixcel weg usw.), und inkl. SSD1306_images.h
xbm_32_32.zip
error.xbm
humid2.xbm
humid3.xbm
info.xbm
psressure.xbm
SSD1306_images.h
system.xbm
system_2.xbm
USB-32.xbm
usb_connected.xbm
usb_disconnected.xbm
usb_off.xbm
usb_on.xbm
led_off.xbm
led_on.xbm
Zitat
Ach ja, das hier:
https://forum.fhem.de/index.php/topic,52921.msg452953.html#msg452953
habe ich implementiert und es scheint soweit zu laufen.
Ich mache wohl ende der Woche eine 1.19, in der der MCP23008 offiziell drin ist und danach dann mit dem Display weiter.
Ähm, blöde Frage: Gibt es diese überarbeitete 1.19 schon? Ich habe meine 1.19 mal getestet, "OLED mode=th" funktioniert damit (leider) noch nicht.
Gibt es den aktuellen Stand auf github?
Oder war damit gemeint, dass im verlinkten Post die MCP23008 Featueres aber noch nicht die Display Befehle aufgenommen werden?
Zitat von: weini am 27 Juni 2016, 22:36:56
Ähm, blöde Frage: Gibt es diese überarbeitete 1.19 schon?
Es gibt keine überarbeitete 1.19 sondern eine reguläre 1.19
siehe hier: https://forum.fhem.de/index.php/topic,43672.msg455540.html#msg455540
Zitat von: weini am 27 Juni 2016, 22:36:56
Gibt es den aktuellen Stand auf github?
Es gibt immer den "offiziellen" Stand hier: https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip
was aktuell der 1.19 entspricht
Zitat von: weini am 27 Juni 2016, 22:36:56
Oder war damit gemeint, dass im verlinkten Post die MCP23008 Featueres aber noch nicht die Display Befehle aufgenommen werden?
So ist es. Der MCP23008 ist implemetiert und kann als Ein-/Ausgang verwendet werden, das Display ist rundimentär implementiert, bedeutet, dass die Statuszeile oben funktioniert.
An der Darstellung von Werten, die man von FHEM aus sendet, bin ich gerade dran, das kommt in der 1.20, siehe hier:
https://forum.fhem.de/index.php/topic,52921.msg466150.html#msg466150
Und dann kommt der Teil, der die Daten des internen Sensors darstellt, also z.B. das "OLED mode=th"
Danke dir! Ich freue mich und werde gespannt & geduldig warten!
Nachdem ich nun wieder zig Seiten gelesen habe und keine wirkliche Antwort gefunden habe:
http://www.aliexpress.com/item/Yellow-blue-double-color-and-white-128X64-0-96-inch-OLED-LCD-LED-Display-Module-For/32276839548.html?spm=2114.13010608.0.58.xIhqsz
Ist dieses Modul kompatibel?
Gruß Mario
Kleine LGW OLED Demo gibt es hier (https://youtu.be/LsRkaM1qpaU) (720p HD) 8) ;)
,,Danke HCS für die Super Arbeit"
Habe heute die v1.20 bei mir installiert. Mit "OLED mode=th" wird auch wechselnd Temperatur und Luftfeuchte angezeigt. Allerdings bekomme ich als Wert immer nur 0.
Ich habe einen DHT-22 im LCG lokal angeschlossen. Dieser wird auch korrekt ausgewertet.
Anhand des Wiki-Eintrags bin ich mir gar nicht sicher, ob das mit v1.20 schon funktionieren sollte. In dem geposteten Video wird aber ein Temperaturwert angezeigt, deshalb meine Frage...
Zitat von: amunra am 23 Juli 2016, 17:32:20
Kleine LGW OLED Demo gibt es hier (https://youtu.be/LsRkaM1qpaU) (720p HD) 8) ;)
Jetzt habe ich auch gemerkt, warum man ein OLED haben muss ;D ;D ;D
Zitat von: weini am 23 Juli 2016, 23:06:11
Habe heute die v1.20 bei mir installiert. Mit "OLED mode=th" wird auch wechselnd Temperatur und Luftfeuchte angezeigt. Allerdings bekomme ich als Wert immer nur 0.
Das sollte eigentlich gehen, aber es kann natürlich sein, dass es mit einem DHT22 nicht geht. Das wäre dann ein Fehler, den ich beheben muss.
Ich habe es bisher nur mit einem BME280 getestet und ich vermute mal amunra auch, weil er einen Luftdruck hat.
Ich schaue es mir mal an und repariere es ggf.
Zitat von: waschbaerbauch am 16 Juli 2016, 17:01:08
Nachdem ich nun wieder zig Seiten gelesen habe und keine wirkliche Antwort gefunden habe:
http://www.aliexpress.com/item/Yellow-blue-double-color-and-white-128X64-0-96-inch-OLED-LCD-LED-Display-Module-For/32276839548.html?spm=2114.13010608.0.58.xIhqsz
Ist dieses Modul kompatibel?
Ich denke schon, aber garantieren kann ich es nicht.
Aber:
ZitatHinweis: Die neue Spurhaltungszahl für China-Pfosten Gewöhnliche Kleine Packet Plus Nur können es haben Schiff aus China ...
Wenn das Display auch so ein Kauderwelsch anzeigt, dann hat es einen guten Fun-Faktor ;D ;D
Zitat von: HCS am 23 Juli 2016, 23:12:40
Ich habe es bisher nur mit einem BME280 getestet und ich vermute mal amunra auch, weil er einen Luftdruck hat.
Korrekt - ich verwende den BME280 auf einer Breakout Platine.
Zum Thema OLED von waschbaerbauch:
Zitat von: HCS am 23 Juli 2016, 23:17:28
Ich denke schon, aber garantieren kann ich es nicht.
Aber:
Wenn das Display auch so ein Kauderwelsch anzeigt, dann hat es einen guten Fun-Faktor ;D ;D
Sehe ich auch so, kaufen - warten - probieren ;)
Wenn ich beim Testen mit dem DHT22 helfen kann, dann bitte Bescheid geben.
Gesendet von meinem SM-G900F mit Tapatalk
Zitat von: weini am 24 Juli 2016, 13:25:37
Wenn ich beim Testen mit dem DHT22 helfen kann, dann bitte Bescheid geben.
Bei mir funktioniert das auch mit dem DHT22.
Bist Du sicher, dass er wirklich Werte liefert?
Ja, definitiv! Ich habe ihn als LC-Sensor ja am Laufen und er überträgt einwandfrei. Nur auf dem Display bekomme ich 0-Werte.
Habe ich vielleicht bei der Konfiguration etwas verbummelt? Mein DHT22 hängt mit seinem DATA-Pin an D3 vom DevKit.
Muss ich im Setup noch irgendetwas einstellen?
Zitat von: weini am 24 Juli 2016, 22:29:46
Mein DHT22 hängt mit seinem DATA-Pin an D3 vom DevKit.
Korrekt
Zitat von: weini am 24 Juli 2016, 22:29:46
Muss ich im Setup noch irgendetwas einstellen?
Nein.
Irgend etwas muss bei Dir anders sein. Ich kann das aktuell weder praktisch noch im Quellcode nachvollziehen.
Wenn vom DHT22 Werte an FHEM geliefert werden, muss das auch auf dem Display gehen.
Kannst Du mal auf der Log-Page des LGW warten, bis in "LGW to FHEM" eine Zeile kommt, die mit
22:45:05: OK WS
beginnt
und bei "Command:" ein v abschicken. Dann muss in "LGW to FHEM" eine Zeile kommen, die mit
22:45:06: [LaCrosseITPlusReader.Gateway.1.20 (
beginnt.
Natürlich mit einer anderen Uhrzeit.
Beide mal posten.
So, jetzt wird es interessant:
Habe das LGW gerade wieder angesteckt. Wegen Wohnungsumbau liegt es aktuell im Schrank.
Ich bekomme tatsächlich keine Daten mehr vom DHT22, auch nicht als LC Device. Die letzte Meldung ist von gestern 20h, das war unmittelbar bevor ich von 1.19 auf 1.20 geflasht habe.
Habe gerade versucht, nochmal zu pairen, das hat aber nichts gebracht.
Hier der Output von "v":
23:13:26: [LaCrosseITPlusReader.Gateway.1.20 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + DHT22 + OLED {IP=192.168.0.113}]
Er erkennt den DHT22 also zumindest...
Zitat von: weini am 24 Juli 2016, 23:09:13
Ich bekomme tatsächlich keine Daten mehr vom DHT22, auch nicht als LC Device.
Dachte ich es mir doch.
Das Problem habe ich auch und bin noch etwas ratlos.
Ich habe zwei LGW mit DHT22. Auf einem funktioniert er permanent problemlos, auf dem anderen geht er mal und mal geht er nicht.
Neu pairen, flashen usw. kann man sich alles sparen, hilft nicht.
Ich habe die DHT22 auch schon über kreuz getauscht, ohne dass das Problem auf das andere LGW gewandert wäre.
Total verrückt: kürzlich habe ich den Logic-Analyzer auf den DHT22 mit drauf gehängt, dann lief er problemlos.
Logic-Analyzer wieder ab, lief immer noch. Am nächsten Tag kamen dann wieder keine Werte mehr.
Einer sitzt direkt auf der PeMue Platine drauf, der Problemfall ist mit 10 cm Kabel von der PeMue Platine abgesetzt.
Allerdings lief das auf dem BreadBoard mit Jumperkabeln auch problemlos.
Ich muss da nochmal mit dem Analyzer drauf und hoffen, dass es dann trotzdem nicht geht, um irgend welche sachdienliche Hinweise zu bekommen. Aktuell bin ich reichlich ratlos.
Zitat von: weini am 24 Juli 2016, 23:14:45
Hier der Output von "v":
23:13:26: [LaCrosseITPlusReader.Gateway.1.20 (1=RFM69 f:868300 r:17241) + (2=RFM69 f:868300 r:9579) + DHT22 + OLED {IP=192.168.0.113}]
Er erkennt den DHT22 also zumindest...
Ja, das hatte ich auch schon. Wurde erkannt, und kurz drauf hat er keine Werte mehr geliefert.
Hast du das Problem erst mit v1.20 bekommen?
Ich bin mir recht sicher, dass vor dem Upgrade mit der v1.19 das ganze zuverlässig funktioniert hat.
Wenn ich morgen ein wenig Luft habe, dann würde ich mal kurz auf die v1.19 zurückflashen und testen.
Zitat von: weini am 24 Juli 2016, 23:30:53
Hast du das Problem erst mit v1.20 bekommen?
Ich bin mir recht sicher, dass vor dem Upgrade mit der v1.19 das ganze zuverlässig funktioniert hat.
Wenn ich morgen ein wenig Luft habe, dann würde ich mal kurz auf die v1.19 zurückflashen und testen.
Die Probleme hatte ich auch schon mit der 1.19
Aber ich hatte sie mit der 1.19 mal zwei Wochen nicht, und dann wieder hartnäckig Probleme. Dann ging es wieder, ...
Wie gesagt, auf dem einen LGW läuft es problemlos, auf den anderen nur wenn es will. Und wann es will, ist völlig unvorhersehbar :o
Kann ich leider nachvollziehen, derzeit bekomme ich auch unter 1.19 keine Werte mehr vom DHT22.
Mir ist noch aufgefallen, dass ich nach einem Reboot auch keine Werte von meinem Funk-LC Sensor mehr bekommen habe.
Habe dann das LGW kurz stromlos gemacht und nach dem Reboot kamen die Werte wieder.
Es ist zum verzweifeln. Analyzer hängt auf dem DHT22 drauf und es läuft und läuft und läuft.
Ich lasse ihn jetzt drauf, bis es irgendwann nicht mehr geht >:(
So wie im Anhang ist der Korrekt-Fall.
Eventuell sollten wir das Thema in den LGW-Thread verlegen, mit dem Display hat es ja nichts zu tun, wie wir inzwischen wissen.
Sag mal, nur so eine Idee: Müsste Data vom DHT22 nicht mit 10k auf 3.3V gezogen werden? Ich habe an meinem Raspi auch direkt einen DHT22 an GPIO und die meisten Anleitungen im Netz empfehlen den Pull-Up, z. B. https://klenzel.de/1827
Ich kann das ggf. auch gerne testen, aber nicht mehr heute...
Das devkit hat einen pullup drauf
Schade auch...
Anbei meine Anmerkungen zu der bisher wirklich tollen Implementierung.
Vorab, es ist alles unkritisch und nice-to-have.
1) IP-Adresse und Anzeige der Version nach Boot/Reboot ist recht hektisch, 3-4 Sekunden mehr fände ich pers. entspannter ;).
2) Etwas nicht OLED spezifisches - Befehl "OLED show=Hallo,,,e"" auf der "Config"-page - Log - Command führt dazu, dass sich die WiFi Connection zum AP weghängt. Ich weiß, ziemlich ungeschickt sowas zu machen. ;)
Das LGW kann sich nach einem Reboot nicht mehr mit dem Router/AP verbinden.
FW drüber installieren hilft nicht. Was nur noch hilft ist, Wifi SSID und PW auf der "config-page" entfernen "save restart" und SSID und PW erneut eingeben.
Es ist nicht tragisch wenn man weiß, dass es so ist, und komplett sicher wird man das wohl nicht hinbekommen.
3) Den aktuellen OLED-Mode (t,h,p,show etc.) per KVP übertragen damit das nachfolgende Szenario (Beispiel) möglich ist:
1. OLED mode="thps"
2. Mode merken
3. "OLED show=Gewitter!!!,,,w"
4. Nach einem definierten Intervall den gemerkten Mode (siehe Punkt 2) wiederherstellen
Vermutlich würde aber auch ein "on-for-timer" ausreichen - Beispiel: "OLED show=55%,,,h,600" zeigt für 600 Sekuden den Text 55% mit Icon Humidity)
4) Gibt es einen Grund warum auf der "Config"-Page keine Mode Auswahlmöglichkeit für "thps" (Alternativ=all) gibt? Per raw geht ein "thps". Ich weiß, das ist wieder ein Fall - genau das nicht implementiert und ausgerechnet das möchte man haben ;)
Sonst alles Super... ich bin allerdings noch nicht durch mit allem was ich vorhabe ;)
P.S: 5) Dimmen kann man das OLED auch - Stichwort: "It has 256-step brightness control" ;)
Zitat von: amunra am 26 Juli 2016, 17:30:57
1) IP-Adresse und Anzeige der Version nach Boot/Reboot ist recht hektisch, 3-4 Sekunden mehr fände ich pers. entspannter ;)
Was dann dazu führen würde, dass das LGW 3-4 Sekunden später online ist
Zitat von: amunra am 26 Juli 2016, 17:30:57
2) Etwas nicht OLED spezifisches - Befehl "OLED show=Hallo,,,e"" auf der "Config"-page - Log - Command führt dazu, dass sich die WiFi Connection zum AP weghängt. Ich weiß, ziemlich ungeschickt sowas zu machen. ;)
Das LGW kann sich nach einem Reboot nicht mehr mit dem Router/AP verbinden.
FW drüber installieren hilft nicht. Was nur noch hilft ist, Wifi SSID und PW auf der "config-page" entfernen "save restart" und SSID und PW erneut eingeben.
Es ist nicht tragisch wenn man weiß, dass es so ist, und komplett sicher wird man das wohl nicht hinbekommen.
Also tatsächlich mit zwei Anführungszeichen am Ende?
Da muss ich mal ausprobieren, was da wie warum passiert.
Zitat von: amunra am 26 Juli 2016, 17:30:57
3) Den aktuellen OLED-Mode (t,h,p,show etc.) per KVP übertragen damit das nachfolgende Szenario (Beispiel) möglich ist:
1. OLED mode="thps"
2. Mode merken
3. "OLED show=Gewitter!!!,,,w"
4. Nach einem definierten Intervall den gemerkten Mode (siehe Punkt 2) wiederherstellen
Vermutlich würde aber auch ein "on-for-timer" ausreichen - Beispiel: "OLED show=55%,,,h,600" zeigt für 600 Sekuden den Text 55% mit Icon Humidity)
Kannst Du dir nicht in FHEM merken, was Du wann an das Display geschickt hast und wann Du das nicht mehr habe und was anderes haben willst?
Eigentlich ist doch der Vorteil der Ansteuerung von FHEM aus, dass man seine Logik dort programmiert und ich nicht ständig irgend welche Fälle ins LGW implementieren muss.
Wenn Du keine Direktverdrahtung im LGW definierst und alle Buttons über FHEM etwas auslösen, dann weiß man in FHEM, was das Display aktuell anzeigt.
Zitat von: amunra am 26 Juli 2016, 17:30:57
4) Gibt es einen Grund warum auf der "Config"-Page keine Mode Auswahlmöglichkeit für "thps" (Alternativ=all) gibt? Per raw geht ein "thps".
s, t, th, thp
Eigentlich müsste es dann s, t, h, p, st, sh, sp, th, tp, hp, sth, stp, ... (also alles ausmultipliziert) geben.
Aber thps kann ich mal noch hinzufügen.
Zitat von: amunra am 26 Juli 2016, 17:30:575) Dimmen kann man das OLED auch - Stichwort: "It has 256-step brightness control" ;)
Kannst auch einen handelsüblichen Dimmer vor das Steckernetzteil vom LGW machen, das dimmt dann auch gleich die blaue LED vom devkit mit runter ;D ;D ;D
Habe es mal auf der Wunschliste ganz unten (oben ist gut, unten ist schlecht) reingeschrieben
zu 1) Ja, das ist der Preis ;) Aber immer noch besser als drei mal rebooten um voll konzentriet die Info zu erhaschen. Ist natürlich etwas übertrieben, aber es ist mir tatsächlich schon ein paar mal passiert... "ähm was stand da gerade drauf..?" Ja, ich kann auch auf dem Router schauen und eigentlich vergibt man eine feste IP etc. ;)
zu 2) Ja.
zu 3) Ja, man kann sich etwas mit einem Dummy (oder was auch immer) bauen und ja, ich weiß das in die FW zu paken, ist sicher auch nicht optimal. Dazu gibt es auch so viele Konstellationen und man kann sich bei zwei Hände voll Aktionen sehr schnell verzetteln. Das das OLED ein Modus-Status schickt fände ich denoch gut, zumal nicht sicher gestellt ist, dass das Display die Message erhalten hat. Ich möchte das jetzt aber auch nicht bis ins kleinste durchdiskutieren. Ich schaue, ob ich irgendwo an die Grenzen stosse und melde mich dann...
zu 4) Ja, ein "thps" fehlt irgendwie. ;) "Ich" verspreche auch, nicht mit den anderen Varianten anzukommen ;)
zu 5) Danke.
...und wie bereits geschrieben alles Kosmetik nichts Weltbewegendes...
Hallo,
ich möchte mich vorab erstmal ganz herzlich für die tolle Umsetzung der Displayunterstützung bedanken!
Weiterhin wollte ich mal fragen, ob die beiden Punkte umsetzbar wären:
1. Neben den Messwerten auch einen Mode c (clock) zu implementieren. Das LGW kennt die aktuelle Uhrzeit gemäß der Logseite bereits...
2. Kann man die I/Os des SC16IS750 ähnlich konfigurierbar machen wie beim MCP23008. Oder kollidiert dies mit den teils fest vorgegebenen Belegungen (z.B IO7 Buzzer)?
Noch einen schönen Abend,
Nico
Zitat von: Wallmeier am 26 Juli 2016, 22:58:23
1. Neben den Messwerten auch einen Mode c (clock) zu implementieren. Das LGW kennt die aktuelle Uhrzeit gemäß der Logseite bereits...
Das LGW kennt die Urzeit leider nicht, die wird per JS lokal im Log bei der Ausgabe im Browser hinzugefügt.
-> Bedeutet: nicht machbar (oder genauer, um machbar zu sein müsste sich das LGW die Uhrzeit bei einem NTP-Server besorgen)
Zitat von: Wallmeier am 26 Juli 2016, 22:58:23
2. Kann man die I/Os des SC16IS750 ähnlich konfigurierbar machen wie beim MCP23008. Oder kollidiert dies mit den teils fest vorgegebenen Belegungen (z.B IO7 Buzzer)?
Für die bisherigen Ports, die eine konkrete Vewendung haben, definitiv nicht.
Das sind z.B. die zwei ChipSelects für Radio 4 und 5, der Buzzer, Reset für die AddOn-CPU
Ich wollte eigentlich die SC16IS750 IOs nicht für allgemeines freigeben sondern mir für Dinge, die evtl. noch kommen und nicht konfigurierbar sondern autoerkennbar sein sollen, aufheben.
Ich glaube, dass noch vier Stück ungenutzt sind. Müsste mal mit mir ringen, ob ich zwei davon dafür abgebe, aber das ist dann halt wieder recht wenig und man kommt nicht weit damit.
Zumal ich eine klare Trennung besser finde.
SC16IS750: Erweiterung mit fest vorgegebenen Komponenten
MCP23008: Taster und Lämpchen komplett vom Anwender konfigurierbar
Zitat von: weini am 25 Juli 2016, 19:35:06
Kann ich leider nachvollziehen, derzeit bekomme ich auch unter 1.19 keine Werte mehr vom DHT22.
Hier geht es dann weiter mit dem DHT22 -> https://forum.fhem.de/index.php/topic,43672.msg476609.html#msg476609
ZitatMail from Jay Lan (from aliexpress): Package is returned, please open the dispute a refund.
Und das war mein OLED Display >:( >:( >:(
Das Warten geht also weiter ...
Zitat von: PeMue am 01 August 2016, 14:22:30
Das Warten geht also weiter ...
Hoppla, da kam doch aus Obi-City heute ein Päckchen an. Vielen Dank, werde mich beim nanoLGW bei Dir revanchieren und sogleich mal die neue Firmware flashen und testen.
Gruß PeMue
Edit1:Coole Nummer:
[LaCrosseITPlusReader.Gateway.1.20 (1=RFM69 f:868960 r:6631) + (2=RFM69 f:868300 r:20000) + BME280 + OLED {IP=xxx.xxx.xxx.xx}]Edit2:So was Dummes, das LGW (und somit das Display) kennt die Korrekturfaktoren corr1 und corr2 nicht. D.h. ich muss mir bei der LGW Platine was einfallen lassen, wie die Sensoren besser platziert werden können :o
Zitat von: PeMue am 03 August 2016, 21:16:41
Edit2:
So was Dummes, das LGW (und somit das Display) kennt die Korrekturfaktoren corr1 und corr2 nicht. D.h. ich muss mir bei der LGW Platine was einfallen lassen, wie die Sensoren besser platziert werden können :o
Das mit den edits ist blöd, da bekommt man keine Benachrichtingung und entdeckt sie nur durch Zufall.
Darüber habe ich mir auch schon Gedanken gemacht. Eigentlich bräuchte das LGW selbst schon die Korrektur.
Das sollte implementierbar sein.
Und am besten geleich noch die Höhe über NN, dass das nicht erst dann stimmt, wenn ein FHEM die Höhe irgendwann ma gesetzt hat.
Ich sinniere aber gerade darüber, ob das ein offset sein sollte (wie beim 36_LaCrosse Modul, auch wenn es da in der CommandRef falsch als " correction factors" beschrieben ist) oder tatsächlich ein Faktor.
Die Frage ist: ist die Abweichung linear über den Temperaturbereich oder prozentual falsch?
Aktuell tendiere ich eher zu offset.
Zitat von: HCS am 11 August 2016, 13:12:10
Ich sinniere aber gerade darüber, ob das ein offset sein sollte (wie beim 36_LaCrosse Modul, auch wenn es da in der CommandRef falsch als " correction factors" beschrieben ist) oder tatsächlich ein Faktor.
Die Frage ist: ist die Abweichung linear über den Temperaturbereich oder prozentual falsch?
Aktuell tendiere ich eher zu offset.
Messreihe läuft mit dem LGW und einem Referenzsensor auf der Terasse. Mal sehen, ob es heute nacht auch wieder so a....kalt wird wie heute morgen. Dann sollte es sich leicht errechnen lassen.
Ich bin mir nicht sicher, wie die Luftfeuchte ermittelt wird. Aber vermutlich braucht es zwei Korrekturfaktoren ...
Gruß PeMue
Zitat von: PeMue am 11 August 2016, 20:19:05
Messreihe läuft mit dem LGW und einem Referenzsensor auf der Terasse.
Was ist denn der Referenzsensor?
Zitat von: HCS am 11 August 2016, 20:26:04
Was ist denn der Referenzsensor?
TFA 30.3150, bei Bedarf kann ich auch noch einen zweiten LGW rauslegen (der mit dem USRTCP232, der geht ja noch über WLAN) und einen BME280 mit längerem Kabel dranmachen ;)
Gruß PeMue
Jetzt schreibe ich extra einen neuen Beitrag, damit die Benachrichtigung auch kommt ;)
Ich habe das Display mit
set <LGW_name> raw OLED mode=thps"
konfiguriert. Dummerweise war das dann wieder weg, als ich das Ding auf die Terasse gelegt hat.
Kann ich in fhem sehen, ob das LGW disconnected war und dann per Notify die Sache wieder setzen?
Im Setup geht ja nur an, aus bzw. wie lange an ...
Danke + Gruß
PeMue
PS:
@amunra: Ich habe gerade mal das Wiki bemüht. Respekt für die tolle Dokumentation!
Kannst den "OLED mode=thps" in die initCommands setzen, dann wird es immer geschickt, wenn FHEM sich neu auf das LGW connected.
Zitat von: PeMue am 11 August 2016, 20:45:40
@amunra: Ich habe gerade mal das Wiki bemüht. Respekt für die tolle Dokumentation!
Kann es nur an HCS und dich weitergeben - ohne euren Berg Infos wäre es nicht entstanden ;)
@HCS: Dein init-OLED-Tipp baue ich noch ein, steht auf der ToDo-Liste ;)
Zitat von: HCS am 11 August 2016, 13:12:10
Aktuell tendiere ich eher zu offset.
Zumindest für die Temperatur würde ich das auch bestätigen (in dem gestrigen Temperaturbereich), siehe Anhang.
Gruß PeMue
Zitat von: waschbaerbauch am 16 Juli 2016, 17:01:08
Nachdem ich nun wieder zig Seiten gelesen habe und keine wirkliche Antwort gefunden habe:
http://www.aliexpress.com/item/Yellow-blue-double-color-and-white-128X64-0-96-inch-OLED-LCD-LED-Display-Module-For/32276839548.html?spm=2114.13010608.0.58.xIhqsz
Ist dieses Modul kompatibel?
Gruß Mario
Nachdem es nun angekommen ist - ja es funktioniert auf Anhieb! Der Preis ist zwar auf 3,19€ gestiegen, aber das dürfte zu verkraften sein ;)
Ich habe mir jetzt auch ein OLED SSD1306 gegönnt, bin aber unsicher wegen der Anschlüsse.
Auf meinem LGW steckt bereits ein BME280. Ich gehe davon aus, dass das OLED einfach parallel dazu angeschaltet wird (das OLED wird wohl über eine andere Adresse angesprochen) oder muss ich mich entscheiden zwischen OLED und BME?
Auf meinem OLED habe ich folgende Anschlüsse:
- GND
- VCC
- D0
- D1
- RES
- DC
- CS
Auf Seite 1 steht zu den Anschlüssen ja folgendes:
Zitat
Beschaltung:
D1(GPIO5) = SCL und D2 (GPIO4) = SDA VCC=3,3V GRD=GND und wie auf den Bildern/Video zu sehen mit zwei 4,7K Widerständen an 3.3V für Stabilität gesorgt.
Kurzfassung: Entspricht einer BMP180/BME280 Beschaltung.
Welche Verbindungen brauche ich bitte bei dieser Konstellation, d.h. bezogen auf die BME280-Anschlüsse (SDA, SCL, 3,3V, SD0, GND)?
Danke schon mal
Holger
Wenn man eine I2C OLED Variante hat, dann kann man es, wie Du richtig erkannt hast, Parallel zum BME anschließen.
Wenn deine PIN Belegungen richtig sind, dann hast Du die SPI OLED Variante (siehe hier (https://github.com/jandelgado/arduino/wiki/SSD1306-based-OLED-connected-to-Arduino)) und die wird vom LaCrosseGateway nicht unterstützt - wenn mir nichts entgangen ist.
EDIT1: Wenn ich das richtig lese und verstehe, dann kann der auch mit dem I2C-Protokoll betrieben werden, dann muss D0 an SCK/SCL und D1 an SDA (inkl. pull-up) + VCC und GND. das wars.
EDIT2: Aus dem Datenblatt:
ZitatThe I2C communication interface consists of slave address bit SA0, I2C-bus data signal SDA (SDA OUT/D2 for output and SDA IN/D1 for input) and I2C-bus clock signal SCL (D0).
und
ZitatBoth the data and clock signals must be connected to pull-up resistors.
Hat leider nicht funktioniert. Auch nicht, als ich nur das OLED angeschlossen hatte (es wird generell auf der Hardwareseite nicht erkannt).
Na ja, nicht so schlimm. Ich finde schon eine Verwendung dafür.
Für das LGW habe ich mir jetzt gleich die 1.3" Variante bestellt (diesmal aber wohl die richtige ;) ).
Danke für deine Unterstützung
Holger
Moin
@Omega: Das Gleiche ist mir auch passiert! Ich habe mir dann welche in Deutschland bestellt. Die waren gleich am naechsten Tag da und auch I2c! Der wesentlich hoehere Preis war mir dann auch egal!
@amunra: Kannst Du das mit den Pullups noch etwas genauer erklaeren? Dann kann ich die je eventuell doch noch einsetzen!
Gruss Christoph
Ich habe kein SPI OLED und kann daher eigentlich wenig dazu sagen. ;)
Auf Basis der oben verlinkten Seite (https://github.com/jandelgado/arduino/wiki/SSD1306-based-OLED-connected-to-Arduino) und dem dort verlinkten Datenblatt (https://www.adafruit.com/datasheets/SSD1306.pdf) vermute ich, dass es ein I2C/SPI OLED Display ist, welches in I2C-Mode oder SPI-Mode betrieben werden kann.
Auch diese Aussage:
ZitatAlthough it was sold as an I2C display, it turned out that it operates as an SPI device by default. If you look at the back side, you can see that it is in 4-wire SPI mode. I2C operation will be researched in another post later.
lässt vermuten, dass dies möglich ist.
Auf Seite 19 im Datenblatt steht etwas zu den Pullups, mehr kann ich dazu nicht sagen.
Adafruit verwendet für das 128x32-I2C-OLED Breakout PCB (https://github.com/adafruit/Adafruit-128x32-I2C-OLED-Breakout-PCB) ein 10k Wiederstand, ob das für das 1306 auch zutrifft?
Wie bereits geschrieben, genauere Informationen kann ich leider nicht geben. Da müsstet ihr mal recherchieren.
Viel Glück.
P.S: Es kann auch sein, dass sich das Display mit einer anderen Adresse meldet. Die Adresse sieht man evtl. in der LGW-Konsole (Bootvorgang) oder mit einem I2C-Scanner bzw. ich habe weiter oben eine LGW-Firmware gepostet, welche einen Scan durchführt und die ermittelten Adressen in der Konsole anzeigt.
EDIT: Dieses (https://learn.adafruit.com/monochrome-oled-breakouts/wiring-1-dot-3-128x64) hat Jumper, mit den man den Betriebsmode definieren kann.
Mal ein Abhandlung über die Pullup-Widerstände:
Bei I2C arbeiten der Master (ESP8266) und die Slaves (BMP180, OLED, ...) mit open drain Ausgängen.
Deshalb muss man SCL und SDA mit Pullup-Widerständen (üblicherweise im Bereich von 4,7K ... 10K) auf 3.3V ziehen.
Es reicht, wenn irgendwo im Bus die Pullups vorhanden sind. Wenn man bereits z.B. einen BMP180 oder BME280 angeschlossen hat, der auf einem Breakout-Board sitzt, dann sind da meistens auch Pullups mit drauf. Dann braucht man keine weiteren. Merkt man recht einfach daran, dass es funktioniert, obwohl man keine weiteren Widerstände verbaut hat. In diesem Fall kann man das I2C-Oled einfach mit dran hängen, und gut ist.
SPI / I2C:
Falls man ein OLED hat, das wie das in SSD1306-2.png aussieht, sollte man eigentlich die Widerstände umlöten können, um es auf I2C zu konfigurieren. Siehe auch angehängtes Schaltbild.
Also vermutlich (ohne Garantie) R3 runterlöten und auf die R1-Position löten und bei R8 eine Brücke drauf löten, da er lt. Schaltplan 0 Ohm hat.
Und generell an alle OLED-Besteller: wenn es mehr als vier Anschlüsse hat, dann Vorsicht.
Kann ja mal jemand probieren, oder es in einen Umschlag stecken und mir schenken, dann probiere ich es ;D
Nachtrag:
Wie man auf dem Schaltbild sieht, dieses OLED hat auch bereits Pullups für SCL und SDA drauf.
Na bitte und Danke HCS ;) ;D
Dann musst Du jetzt alle grünen und blauen like buttons bei meinem Beitrag klicken ;D ;D ;D
ich sage/schreibe es lieber. ;)
EDIT: Aber, wenn Du es magst dann drücke ich für dich..
Ich habe jetzt ein OLED aus D (weil es jetzt schnell gehen sollte) und dann gleich das mit 1.3". SUPER. Ein echter Hingucker.
So langsam muss ich mir doch mal Gedanken zu einem Gehäuse machen. :)
Beim China-Händler habe ich nachgefragt und folgende Antwort erhalten:
ZitatThe default interface is SPI. It supports IIC with the folowing settings.:
Tear down resistor R3 and weild it to the R1 position;
dc, cs pins have ground connection;
res pin controls via an IO to complete reset;
Resseting method: first use the RES pin to maintain a low level of 200ms;
then use the RES pin maintain high level to complete the reset operation;
then initialize the OLED, and you can use IIC.
Deckt sich z.T. mit den Erkenntnissen von HCS. Und sein Foto vom OLED sieht genau wie meines aus.
Wobei mir allerdings der Umstand mit der Reset-Leitung nicht wirklich klar ist. Außer der Verbindung müsste ja auch die Software aktiv werden.
Ich bin noch unentschlossen, ob ich mal versuchen soll, den Miniatur-Widerstand umzulöten oder ob ich das OLED einfach für irgend eine SPI-Lösung verwende.
LG
Holger
Moin
@HCS: Schick mir Deine Adresse per PM, dann gebe ich dir eins ab!
Gruss Christoph
P.S.: Mit Photos hilft leider auch nicht immer, da habe ich jetzt 5 falsche NodeMCU-Kits, da der Chinese die richtigen Bilder bei Ali hat, aber die falschen Kits schickt!
Ich habe auch diverse NodeMCUs (v0.9, v2, v3) und ESP12, ESP12e, z.T. mit den unterschiedlichsten Problemen. Nachdem ich aber das BIOS ESP8266_NONOS_SDK_V2.0.0 (http://bbs.espressif.com/viewtopic.php?f=46&t=2502) aufgespielt habe, sind meine Probleme alle weg.
Zitat von: Omega am 25 November 2016, 00:50:50
So langsam muss ich mir doch mal Gedanken zu einem Gehäuse machen. :)
Wenn Du eins gefunden hast, in das das man das OLED ohne Labsägearbeiten einbauen kann, dann gib mir bitte unbedingt Bescheid.
Zitat von: Omega am 25 November 2016, 00:50:50
Beim China-Händler habe ich nachgefragt und folgende Antwort erhalten:Deckt sich z.T. mit den Erkenntnissen von HCS. Und sein Foto vom OLED sieht genau wie meines aus.
Wobei mir allerdings der Umstand mit der Reset-Leitung nicht wirklich klar ist. Außer der Verbindung müsste ja auch die Software aktiv werden.
Eben. Ich frage mich, ob der China-Mann da recht hat. Warum soll nach dem Power-On-Reset nochmal ein Reset erforderlich sein, um die per Hardware gesetzte Konfiguration zu verarbeiten? Aber ausschließen, dass der SSD1306 so seltsam drauf ist, kann ich aktuell auch nicht.
pc1246 ist ja so nett und schickt mir eins von den Dingern, dann gehe ich der Sache mal auf den Grund und berichte.
Zitat von: amunra am 24 November 2016, 21:10:16
EDIT: Aber, wenn Du es magst dann drücke ich für dich..
Nee lass mal, war eher in Scherz.
Aber ich glaube, wenn ich hundert Klicks habe, darf ich ein FHEM 2.8 kostenlos runterladen ;D ;D
Oder sonstwas, keine Ahnung, zu was das eigentlich gut ist. :-\
Zitat von: HCS am 25 November 2016, 12:35:59
Nee lass mal, war eher in Scherz.
Ich hab das schon verstanden ;) ;) :) :)
Zitat von: HCS am 25 November 2016, 12:35:59
Aber ich glaube, wenn ich hundert Klicks habe, darf ich ein FHEM 2.8 kostenlos runterladen ;D ;D
Oder sonstwas, keine Ahnung, zu was das eigentlich gut ist. :-\
Du bekommst als FHEM Mitarbeiter des Jahres ein FHEM Wimpel (siehe Anhang) (Die Idee möchte ich übrigens nicht schlecht reden (https://forum.fhem.de/index.php?topic=52182.10) - ich finde sie gut!) 8) 8) 8) ;D
Zitat von: HCS am 25 November 2016, 12:30:49
Wenn Du eins gefunden hast, in das das man das OLED ohne Labsägearbeiten einbauen kann, dann gib mir bitte unbedingt Bescheid.
Och, eine Fräsmaschine würde es vermutlich auch schon tun ;)
Zitat von: HCS am 25 November 2016, 12:35:59
Aber ich glaube, wenn ich hundert Klicks habe, darf ich ein FHEM 2.8 kostenlos runterladen ;D ;D
Das würde dann wahrscheinlich noch auf der FritzBox funktionieren ;D
Zitat von: pc1246 am 25 November 2016, 06:47:10
@HCS: Schick mir Deine Adresse per PM, dann gebe ich dir eins ab!
Ist angekommen.
Um es auf I2C zu konfigurieren muss man R3 runterlöten und auf die R1-Position drauflöten und dann noch eine Brücke auf R8 löten (siehe OLED2.png).
D0 am OLED ist SCL und kommt an D1 vom ESP
D1 am OLED ist SDA und kommt an D2 vom ESP
China-Mann hat recht, ohne verzögerten Reset übernimmt es die Konfiguration beim Anlegen der Versorgungsspannung nicht.
Das kann man mit einem RC-Glied am RES-Pin erreichen. 10K nach 3.3V und 100nF nach GND (siehe OLED1.png).
Man kann da nehmen, was man gerade da hat, 1uF oder etwas bis 10uF sollte auch gehen.
So erkennt das LGW das OLED dann und es zeigt etwas an.
Leider ist das OLED defekt (siehe OLED3.png) und zeigt nur jede zweite Zeile an. Das muss aber schon ab Werk so gewesen sein, da das abgebrochene Eck nicht in der Verpackung war.
Ich vermute, dass es mit einem intakten OLED dann auch normal aussieht, aber das müsste mal noch jemand sicherstellen, der ein unbeschädigtes hat.
Ich kann leider nicht sicher sagen, ob sich das OLED generell noch anders verhält oder der Defekt am Displaglas dafür verantwortlich ist.
Schade, hatte mich schon gefreut, dass ich jetzt eins mehr habe :'(
Ich hab's riskiert und mein OLED umgelötet (den Widerstand umzulöten ist ja schon fast pervers – mir sind die Dinger echt zu klein).
Der Erfolg ist aber nur mäßig. Im Gegensatz zu dem originalen I2C-Display wird das Bild fast nie korrekt aufgebaut. Die Übertragung kommt mir deutlich langsamer vor. Selbst wenn ich nur das Status-Display anzeigen lasse, habe ich meistens irgendwelche Verschiebungen im Bild.
Der Umbau scheint sich also nicht wirklich zu lohnen.
Zumindest sind bei Dir alle Zeilen da. Das scheint dann bei mir doch dann an dem defekt am Glas zu liegen.
Den Effekt mit verschobenem Inhalt hatte ich (soweit ich es mit 64 Zeilen beurteilen konnte) nicht.
Der Umbau stellt es auf alle Fälle auf I2C um, sonst würde es überhaupt nichts anzeigen. Warum es sich dann aber anders verhält, ist mir ein Rätsel.
Hallo HCS
Sorry, da habe ich nicht aufgepasst, das Display kam mit abgebrochener Ecke an! Zum Nikolaus schaffe ich es nicht mehr, aber Du bekommst das andere auch! Ich will weder den Widerstand umloeten, noch irgendwelche zusaetzlichen Bauteile dazubasteln!
Gruss Christoph
P.S.: Willst Du die Ecke auch haben, die liegt glaube ich noch bei mir! ::)
Zitat von: pc1246 am 05 Dezember 2016, 08:39:36
Zum Nikolaus schaffe ich es nicht mehr, aber Du bekommst das andere auch! Ich will weder den Widerstand umloeten, noch irgendwelche zusaetzlichen Bauteile dazubasteln!
Wenn Du es unbedingt loswerden willst - OK. Dann experimentiere ich damit nochmal.
Zitat von: pc1246 am 05 Dezember 2016, 08:39:36
P.S.: Willst Du die Ecke auch haben, die liegt glaube ich noch bei mir! ::)
;D ;D ;D
Da ich mehr von c++ als vom Verglasen verstehe eher nicht ;D
Zitat von: pc1246 am 05 Dezember 2016, 08:39:36
Zum Nikolaus schaffe ich es nicht mehr, aber Du bekommst das andere auch!
Ist angekommen. Danke!
Und es ist heil.
Zitat von: pc1246 am 05 Dezember 2016, 08:39:36
Ich will weder den Widerstand umloeten, noch irgendwelche zusaetzlichen Bauteile dazubasteln!
Ich schon, was ich nun getan habe.
Funktioniert einwandfrei. Auch keine Probleme mit dem Bildaufbau oder geschreddertem Bild.
Das Geheimnis ist: man muss zusätzlich den DC-Anschluss auf GND legen.
Siehe Bild.
Nachtrag: den dunkleren Bereich in der Mitte gibt es in Echt nicht, da hat die Kamera wohl gerade einen Bildaufbau erwischt.
Hallo HCS
Freut mich, dann liegt es hier nicht sinnlos rum. Wo hast Du Deine NodeMCU's her? Ich habe hier noch 5 falsche rumliegen, die tun zwar, nur leider sind die ja etwas breiter (2,54mm)?
Gruss Christoph
Zitat von: HCS am 03 Dezember 2016, 09:14:21
China-Mann hat recht, ohne verzögerten Reset übernimmt es die Konfiguration beim Anlegen der Versorgungsspannung nicht.
Das kann man mit einem RC-Glied am RES-Pin erreichen. 10K nach 3.3V und 100nF nach GND (siehe OLED1.png).
Man kann da nehmen, was man gerade da hat, 1uF oder etwas bis 10uF sollte auch gehen.
Soll ich auf dem LGW v1.1 noch einen Pin spendieren und die 10k/300nF optional mit draufmachen?
Gruß PeMue
Zitat von: PeMue am 04 Januar 2017, 20:29:44
Soll ich auf dem LGW v1.1 noch einen Pin spendieren und die 10k/300nF optional mit draufmachen?
Hmmm, gute Frage.
Das rentiert sich nur, wenn sich genug Leute das falsche Display kaufen und dann auch noch in der Lage sind, den 0603 umzulöten, was realistisch betrachtet nur mit Heißluft oder einer SMD-Lötzange vernünftig machbar ist.
Deine Entscheidung ;)
Zitat von: pc1246 am 10 Dezember 2016, 18:41:52
Wo hast Du Deine NodeMCU's her? Ich habe hier noch 5 falsche rumliegen, die tun zwar, nur leider sind die ja etwas breiter (2,54mm)?
Sorry, das habe ich jetzt erst gesehen. Vermutlich hat es sich bereits erledigt.
Ich kann es gar nicht mehr ermitteln.
Aber die bekommt man inzwischen auch in DE zu einem akzeptablen Preis, dass man nicht mehr unbeding nach China muss.
http://www.exp-tech.de/nodemcu-v2-lua-based-esp8266
http://www.watterott.com/de/NodeMcu-Lua-WIFI-Board-Based-on-ESP8266-CP2102-Module
Hallo HCS
Naja, beim Chinesen habe ich ~€14,- fuer 5 (leider falsche) bezahlt, da kriege ich in D nur 2 Stueck!
Gruss Christoph
Hallo,
Ich benutze das Display nur innen um die Raumtemperatur mit einem DHT22 anzuzeigen.
Es wäre toll, wenn man die Temperatur ohne Symbol aber dafür noch etwas grösser darstellen könnte.
Dann könnte man das auch aus größerer Entfernung besser lesen.
Gruss
Zitat von: pc1246 am 06 Januar 2017, 15:38:03
Hallo HCS
Naja, beim Chinesen habe ich ~€14,- fuer 5 (leider falsche) bezahlt, da kriege ich in D nur 2 Stueck!
Gruss Christoph
Hi Christoph,
inwiefern meinst du das mit Falsche?
Ich habe meine NodeMCU (https://www.aliexpress.com/item/Update-Industry-4-0-New-esp8266-NodeMCU-v2-Lua-WIFI-networking-development-kit-board-based-on/32358722888.html?spm=2114.13010608.0.0.y9M9zw) von AliExpress. Sie passen auf die LCG Platine und auf die Breadboards.
Gruß
Mario
Moin Mario
Genau diese hatte mein Ali-Chinese auch abgebildet. Geschickt wurden aber die anderen, mit der schwarzen Rueckseite und dem rechteckigen (nicht quadratisch) Chip!
Bei Texaswurfverdrahtung, ist das kein Problem, auf einem Breadboard auch nicht, nur auf den Platinen passen die nicht, da sie um 2,54mm breiter sind!
Gruss Christoph