OWLCD GPIO Ports

Begonnen von ext23, 05 Mai 2013, 15:29:49

Vorheriges Thema - Nächstes Thema

ext23

Hallo,

ich habe mein digitales Schlüsselbrett fertig gestellt und spiele nun ein bissel mit den GPIO Ports rum. Dazu habe ich mal 2 Fragen:

1. Kann ich ein GPIO Port nur kurz einen Impuls geben? Oder wie setzt man das am geschicktesten in FHEM um? Ich hab jetzt bzw. gpio 6 gesetzt dann ein sleep 2 und ein gpio 7 zum löschen des Bit, aber irgendwie wird das immer nichts, ka ob das zu dicht gesendet wird etc.

2. Kann ich ein Bitmuster für gpio übergeben? Problem ist ich möchte den aktuellen Wert der gpio nicht verlieren und da würde sich ja so eine Bitschiebeoperation anbieten. Anosnsten müsste ich vermutlich den dezimalwert jedes mal auslesen und dann bearbeiten oder geht das eleganter?

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Prof. Dr. Peter Henning

Zu 1:

Problem bei sleep ist, dass dadurch FHEM wohl lahmgelegt wird. Aus perl heraus besser mit "select", aus FHEM heraus mit einem at.

Zu beiden: Bitmuster und Kurzimpuls sind beide bishe rnicht vorgesehen. Wäre aber relativ leicht, dies in der Routine für "set" zu ändern.

Problem ist, dass ich derzeit sehr viele Baustellen habe, das damit in der Priorität erst einmal weit hinten wäre.

Vorschlag: Selbst ändern, ich kann das ggf. gerne übernehmen.

LG

pah

ext23

OK Danke, ich schau mal rein ob ich das selber hin bekomme.

Wegen dem sleep dachte ich, dass das FHEM sleep nicht blockiert, aber gut besser ganz vermeiden stimmt schon.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ntruchsess

FHEM läuft singlethreaded und wird daher von sleep oder select(undef,undef,undef,time)-aufrufen blockiert.

Wegen der Kurzimpulse: Wenn Du einen über USB angebundenen Arduino mit Firmata/FRM benutzen würdest, könntest Du auf Impulse ab ca. 20ms Länge reagieren. Reaktionszeit natürlich abhängig davon was sonst noch in FHEM installiert ist. Der Arduino überwacht mit Firmata/FRM seine Ports so schnell er kann und meldet Veränderungen aktiv. Änderungen gehen erst dann verloren, wenn FHEM nicht in der Lage ist die Nachrichten schnell genug abzuarbeiten, so dass der serielle Puffer vollläuft.

Gruß,

Norbert
while (!asleep()) {sheep++};

ext23

Naja es ging hier nicht ums Empfangen sondern ich möchte den Status mit FHEM setzen, also genau anders rum, und ein Atmega benutze ich nicht, ich hab das gängige 1-Wire LCD Modul dran.

Das mit dem Sleep, mhhh ich denke das blockiert nicht wenn man es im FHEM benutzt und nicht die Perl Funktion ?!?
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ext23

Moin,

so das mit dem "kurzen" Impuls habe ich dann doch über 2 aufeinander folgende ATs gelöst:

define Fester_Alarm_Bad notify bz_Fenster:.* {\
  if ("%" eq "open") { \
      fhem ("define Alarm_Bad_GPIO_on_@ at +00:30:00 set az_OW_LCD1 gpio 6") if (Value("Alarm_Bad_GPIO_on_@") eq "");;\
      fhem ("define Alarm_Bad_GPIO_off_@ at +00:30:05 set az_OW_LCD1 gpio 7") if (Value("Alarm_Bad_GPIO_off_@") eq "");;\
  }\
  if ("%" eq "closed") { \
    fhem ("delete Alarm_Bad_GPIO_on_@") if (Value("Alarm_Bad_GPIO_on_@") ne "");;\
    fhem ("delete Alarm_Bad_GPIO_off_@") if (Value("Alarm_Bad_GPIO_off_@") ne "");;\
  }\
}


Jetzt muss ich nur noch schauen wie ich das mache, dass mir die anderen GPIO sets erhalten bleiben.

Eine andere Sache noch, nach einem restart von FHEM werden die GPIO Ports von dem 1-Wire-LCD zurückgesetzt, soll das so? Passiert das durch den Bus Reset?

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ext23

Hallo pah,

ich muss den Thread nochmal hervorholen. Wegen der GPIOs. Könntest du das nicht doch mal irgend wann ändern das man die GPIO Ports direkt ansprechen kann? Ich habe bei mir zunehmend ein komisches Verhalten was alles darauf zurückzuführen ist, dass ich nicht immer vor dem setzen der GPIOs den alten Stand abfrage. Ich mach das momentan (Ich versuche es zumindest immer...) an allen Stellen so:


my $gpio = CommandGet("","az_OW_LCD1 gpio");
$gpio = substr($gpio,19,2);
$gpio = switchBit($gpio,1,0);
$gpio = switchBit($gpio,2,0);
fhem( "set az_OW_LCD1 gpio $gpio" );


Das funktioniert auch ja, aber wenn ich AT Alarme definiere, dann muss ich das da auch noch überall rein quetschen. Weil zwischen define at und der eigentlichen at Ausführung können sich ja die GPIOs wieder verändern und dann passt das alles wieder nicht...

Die Funktion für oben sieht dann so aus:

# Einzelne Bits setzen
# Benötigt für das 1-Wire LCD Controller Board
sub
switchBit($$$) {
  my ($old,$bit,$state) = @_;

  # Bit 4 ist ein Eingangsbit was nicht gesetzt werden kann, daher dieses Bit statisch auf 0 setzen
  my $mask = 0x01 << 3;
  $old &= ~$mask;

  $mask = 0x01 << $bit;

  if( $state ) {
    $old |=  $mask;
  } else {
    $old &= ~$mask;
  }

  $old &= 0x0F;
  return $old;
}


Also ich wäre dir sehr dankbar wenn du das Modul irgendwie so umbauen könntest, dass man die GPIO Ports einzeln setzen kann.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Prof. Dr. Peter Henning

Das Modul steht sowieso zur Überarbeitung an für die asynchrone OWX-Version. Da werde ich es einbauen - kann aber noch ein paar Tage dauern.

LG

pah

Prof. Dr. Peter Henning

OK, anbei die neue Version von OWLCD: 6.3beta.

Beta deshalb, weil der neue Befehl set <device> gpiobit <bit no.> <wert>, mit wert=on,off,0,1
noch nicht für das OWServer-Interface funktioniert.

Den alten Befehl set <device> alert habe ich rausgeworfen.

LG

pah

ext23

Nabend,

ich nutze OWX_ASYNC aber gpiobit bleibt bei mir ohne Wirkung.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Prof. Dr. Peter Henning

Tja, das wird auch so bleiben, tut mir leid. Die entsprechenden Routinen mit den Protothreads werde ich nicht anfassen und si emittelfristig sogar aus den Modulen herauswerfen. Dann sollte aber der Wechsel zum neuen asynchronen OWX das auch möglich machen.

LG

pah

ext23

Puh, so ganz komm ich da jetzt nicht mit ;-)

Also welche Konstellation muss ich verwenden das es funktioniert? Das OWX_ASYNC hatte ich nur genommen weil es damals so angepriesen wurde bzw. das OWX Modul blockiert hatte, aber so sicher bin ich mir da nicht mehr. Ich hab nur das LCD und i-Buttons an dem Bus, von daher ist es mir egal welche Module ich da benutze.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Prof. Dr. Peter Henning

OWX_ASYNC mit ALTEM OWLCD (aber ohne Zugriff auf einzelne Bits)

OWX mit NEUEM OWLCD.

Achtung: Das hier beachten https://forum.fhem.de/index.php/topic,68895.msg610092.html#msg610092

LG

pah

ext23

OK danke, dann werde ich es mal testen.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ext23

Funktioniert mit den GPIOs, das ist sehr schön, das erleichtert mir so einiges!

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)