Umstieg von Rasppi auf BBB - GPIO-Ansteuerung

[Billy]

@Billy,

• Es funktioniert mit der aktuellen Version des RPI_GPIO-Moduls?
• Wie ist Deine Device-Definition?

Gruß
Blueberry63

Es funktioniert mit der aktuellen Version des RPI_GPIO-Moduls? --> Ja

Wie ist Deine Device-Definition?  --> Siehe Anlage

Gruß Billy

[Billy]

Wie sieht es mit den Rechten der /sys/class/gpio/export aus bevor der code der rc.local ausgeführt wird?
Ist die usergruppe gpio?

Auf die schnelle würde ich sagen die usergruppe ist root.

Gruß Billy

[klausw]

hier habe ich eine testversion hochgeladen.

mit dieser sollte die gpio utility meldung wer sein
ausserdem muss man direction und anfangs value nicht mehr in der rc.local setzen
das geht jetzt auch über die attribute (pinexport und chmod reicht)

grüße
Klaus

[Billy]

hier habe ich eine testversion hochgeladen.
mit dieser sollte die gpio utility meldung wer sein
ausserdem muss man direction und anfangs value nicht mehr in der rc.local setzen
das geht jetzt auch über die attribute (pinexport und chmod reicht)
grüße
Klaus

Hallo Klaus,
habe das ganze jetzt auf dem BBB ausgiebig getestet. Es Funktioniert.

mit dieser sollte die gpio utility meldung weg sein

Ist weg! 

ausserdem muss man direction und anfangs value nicht mehr in der rc.local setzen
das geht jetzt auch über die attribute (pinexport und chmod reicht)

Funktioniert zwar halte ich jedoch nicht für optimal! Siehe Auszug aus deinem anderen Link.

gpio wird nur exportiert wenn noch nicht vorhanden,
direction wird jetzt bei output pins erst gesetzt, wenn das erste mal ein value geschrieben werden soll (durch schreiben von high bzw. low in direktion wird der GPIO direkt gesetzt)

Dieses Verfahren ist zwar möglich, habe ich auch getestet erscheint mir aber zu umständlich oder ich habe es falsch verstanden.
Das bedeutet, dass nach einem reboot die GPIO's ohne weitere Massnahmen im undefinierten Zustand sind?
Zumindest war es bei meinem Test-BBB so.

Deshalb werde ich bei mir auch zukünftig die Bootwerte schon in der rc.local initialisieren.
Das stört das zusammenwirken mit deinem Modul ja nicht. Und bringt für mich mehr Sicherheit.

Ansonsten nochmals vielen Dank für deine tolle Arbeit.

Gruss Billy

By the way was kann ich mit set <name> blink erreichen ?  Parameter? Kein Eintrag in commandref?

[klausw]

Hi Billy,

sehr schön.
Dann kann ich es ja fast schon einchecken.

Dieses Verfahren ist zwar möglich, habe ich auch getestet erscheint mir aber zu umständlich oder ich habe es falsch verstanden.
Das bedeutet, dass nach einem reboot die GPIO's ohne weitere Massnahmen im undefinierten Zustand sind?
Zumindest war es bei meinem Test-BBB so.

Deshalb werde ich bei mir auch zukünftig die Bootwerte schon in der rc.local initialisieren.
Das stört das zusammenwirken mit deinem Modul ja nicht. Und bringt für mich mehr Sicherheit.

Du hast es falsch verstanden, bzw. ich habe es nicht komplett erklärt (und vielleicht funktioniert es auch noch nicht perfekt):

Ursprüngliches Problem:
Beim initialisieren von Outputs wurde direction auf output gesetzt. Das führte dazu, das gleichzeitig der value auf 0 gesetzt wurde.
d.h. bei Relais mit invertierter Logik werden diese erstmal kurz angesteuert, da der Pin von hochohmig auf masse wechselt.

derzeitige Lösung:
nachdem beim booten die Attribute (mit ausnahme von direction bei output) gesetzt wurden wird die StateFn aufgerufen.
Diese schreibt die Werte, die beim runterfahren gespeichert wurden. Dabei wird auch der value geschrieben (gleichzeitig mit direction)
Wenn es bei Dir nicht initialisiert wird schaue bitte nach, ob die states auch abgespeichert wurden (das sollte beim beenden von FHEM eigentlich passieren).

By the way was kann ich mit set <name> blink erreichen ?  Parameter? Kein Eintrag in commandref?

aber sicher stehts in der commandref...Augen auf! : The set extensions are also supported.

Grüße
Klaus

[Billy]

Hallo Klaus,

nur zum Verständnis. Nach einem shutdown von FHEM habe ich folgende Einträge in fhem.save.

setstate P8_Pin13 on
setstate P8_Pin13 2014-06-30 16:29:19 Pinlevel high
setstate P8_Pin13 2014-06-30 16:29:19 state on
setstate P8_Pin15 on
setstate P8_Pin15 2014-06-30 16:29:19 Pinlevel high
setstate P8_Pin15 2014-06-30 16:29:19 state on

Wenn ich dich jetzt richtig verstanden habe, sollten nach einem reboot des BBB durch fhem und dein Modul die GPIO
wieder auf diese Werte gesetzt werden?

Zumindest bei mir passiert das nicht. (direction und anfangs value in der rc.local nicht gesetzt.)
Alle Pinlevels sind bei mir nach dem Booten und hochfahren von fhem auf low.
Ich kann die GPIO auch nur setzten wenn ich nach dem booten in fhem das attribut direction nochmals aktiviere.
Deshalb auch meine Aussage dass das mir zu umständlich ist.

Hoffe ich habe mich verständlich ausgedrückt.

Gruß Billy

[klausw]

Hi Billy,

genau, die Werte in fhem.save sollten wiederhergestellt werden.
wenn diese nicht vorhanden sind, dann sollte das erste set die direction auf output setzen
das funktioniert bei mit auch

könntest Du das ganze mal mit verbose 5 wiederholen und das log hier posten

so wie es bei Dir derzeit funktioniert ist es natürlich umständlich

[Billy]

Hi Billy,
könntest Du das ganze mal mit verbose 5 wiederholen und das log hier posten
so wie es bei Dir derzeit funktioniert ist es natürlich umständlich

Hi Klaus siehe Anlage

[Billy]

Hi Klaus,

habe jetzt mal fhem nach shutdown von der Console gestartet.
Folgende Meldung:
--------------------------------------------
Starting fhem...
root@beaglebone:/etc/init.d# sh fhemgg startmain::RPI_GPIO_fileaccess() called too early to check prototype at ./FHEM/51_RPI_GPIO.pm line 520, <$fh> line 60.
--------------------------------------------

Vielleicht hilft das weiter?

[klausw]

hier gibt es eine korrektur
hatte immer noch fehler drin :-/

Starting fhem...
root@beaglebone:/etc/init.d# sh fhemgg startmain::RPI_GPIO_fileaccess() called too early to check prototype at ./FHEM/51_RPI_GPIO.pm line 520, <$fh> line 60.

Das ist was anderes, habe ich bei mir schon geändert, aber noch nicht im hochgeladenen file.
Ein

Code Auswählen Erweitern

sub RPI_GPIO_fileaccess($$;$);
in Zeile 28 sollte helfen.

[Billy]

hier gibt es eine korrektur
hatte immer noch fehler drin :-/

Hallo Klaus
mit dieser Version « Letzte Änderung: Heute um 19:45:35 von klausw »
wird nach reboot der alte FHEM Wert gesetzt!

Aber jetzt ist erstmal Fussball dran.

Gruß Billy

[klausw]

Hallo Klaus
mit dieser Version « Letzte Änderung: Heute um 19:45:35 von klausw »
wird nach reboot der alte FHEM Wert gesetzt!

Aber jetzt ist erstmal Fussball dran.

Gruß Billy

das sowieso B)

sehr schön, dann kannst du das setzen von value und direction ja jetzt aus der rc.local weglassen

immerhin eine Baustelle, die man schließen kann

[Billy]

sehr schön, dann kannst du das setzen von value und direction ja jetzt aus der rc.local weglassen

Hallo Klaus,
um endgültig mit meinem Main System auf dein GPIO-Modul umzusteigen fehlt mir noch ein Attribut
bei GPIO's die auf --> "direction output" gesetzt sind.
Das Attribut "bootvalue" 1 oder 0
Wenn gesetzt wird nach einem Reboot (Stromausfall) nicht das letzte state von FHEM übernommen,
sondern der gewünschte Bootwert.

Das ist bei kritischen Anwendungen und z.B. längerem Stromausfall für meine Anwendungen unabdingbar.

Gruß Billy

[klausw]

versuchs mal damit

restoreOnStartup kann jetzt auf on,off oder last gesetzt werden

[Billy]

versuchs mal damit
restoreOnStartup kann jetzt auf on,off oder last gesetzt werden

Hallo Klaus,
funktioniert super, würde sagen jetzt perfekt.

Was ist der Unterschied zwischen restoreOnStartup yes und restoreOnStartup last?
Gruß Günter