Display für LaCrosseGateway

[amunra]

Großartig! Das wird ja ein ganz großes Mäusekino.

[HCS]

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. 

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-14 07:41:50
   TYPE       notify
   Readings:
     2016-05-12 15:19:53   state           active
Attributes:
   room       .Display

[amunra]

ein paar Varianten hätte ich im Angebot, die Du probieren könntest:

Code Auswählen Erweitern


Buttons211:PB0.*1
Buttons211:PB0:1
Buttons211:PB0:.*1

Vielleicht hilft/passt einer? Mein Favorit ist, wenn auch ungetestet, Zeile 2
Die doppelten Trigger wirst du per eigene perl routine oder per event-on-change los.

[HCS]

ein paar Varianten hätte ich im Angebot, die Du probieren könntest:

Code Auswählen Erweitern


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.

[amunra]

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

Code Auswählen Erweitern

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 214
Autocreate 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

[HCS]

... und OLED spricht auch schon mit mir ...

Bring jetzt nur keinen auf die Idee, dass an das LGW auch noch ein Lautsprecher dran sollte ... 

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.

[amunra]

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. Dafür kann diese 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.

[amunra]

Bring jetzt nur keinen auf die Idee, dass an das LGW auch noch ein Lautsprecher dran sollte ... 

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

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, ich konnte es einfach nicht lassen es mal zu probieren....

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.

[HCS]

- 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

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

[HCS]

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.

[amunra]

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.

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

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.

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

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.

[amunra]

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.

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

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

[HCS]

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

[HCS]

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?

[amunra]

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 bald­mög­lichst, 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.