Display für LaCrosseGateway

[amunra]

Na wer sagt's denn - dein Board sieht doch gleich besser aus

Du hast es geschafft, dass die Pixel heute bei mir angekommen sind 
Vielen Dank!

Gerne.

Jetzt brauche ich mal ein Zeit lang, um es kennen und lieben zu lernen ...

Nur keinen Stress aufkommen lassen.

Viele Grüße
Arthur

[amunra]

Kaum zu fassen, jetzt ist es bei mir auch so weit  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.

[HCS]

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 LGW
OLED-Address: <Adresse> (default 0x3C) oder off für keins
eventuell Auto-Erkennung

Steuerung von FHEM aus
set 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 aus
Max vier Buttons (an A0 angeschlossen per Widerstandsnetzwerk)
senden KeyValueProtokoll an FHEM:
OK VALUES LGPB 211 PB1=0,PB2=1,PB3=0,PB4=0

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

[AxelSchweiss]

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.

[HCS]

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

Code Auswählen Erweitern

set myJeeLink raw "OLED mode=thp"
dass das Display angeht und die Sensordaten anzeigt und startest einen at, der nach 10 Minuten ein

Code Auswählen Erweitern

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.

[AxelSchweiss]

Cool ...
Sollte ja auch keine Kritik sein.
Muss mal zählen wieviele GPIO noch auf dem Gateway frei sind 

[PeMue]

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

[Maxel]

Na dann wird auch dieser Aufsatz ein Erfolg 

[HCS]

Sollte ja auch keine Kritik sein.

War ja auch keine.

Muss mal zählen wieviele GPIO noch auf dem Gateway frei sind 

Ohne SC16IS750 abgesehen von dem Analog Port genau Null.

Dann 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" 

Bin gerade bedingt durch Wasserrohrbruch bzw. die gestrigen Gartenaktivitäten etwas in der Zeit limitiert.

Oh, üble Sache. Viel Erfolg.

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. 

Na dann wird auch dieser Aufsatz ein Erfolg 

Wenn er die so super hin bekommt wie die untere dann garantiert.

[AxelSchweiss]

Ohne SC16IS750 abgesehen von dem Analog Port genau Null.

Na ... dann kann man da ja mindestens 10 Schalter dranbauen ... über Widerstandskaskaden 

[amunra]

@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?
Viele Grüße
Arthur

[HCS]

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.

[AxelSchweiss]

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

[amunra]

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

[HCS]

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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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