Hallo,
da wohl wieder BBB (Rev C) im Handel sind, überlege ich von Rasppi auf BeagleBone Black umzusteigen. Ich lese z.Zt. einen Gaszähler über einen GPIO-Port aus (mittels des "RPI_GPIO"-Moduls) und möchte fragen, wie und mit welchem Aufwand dies mit dem BBB geht. Dabei möchte ich nur das Prinzip verstehen, in die Details arbeite ich mich später ein.
Gruß
Blueberry63
um den gpio zu schreiben (out:1/0) oder lesen (in:1/0) brauchst Du nicht viel. falls Du mit interrupt arbeitest hilft Dir mein nachfolgender tipp leider nciht.
auf dieser basis:
http://forum.fhem.de/index.php/topic,23769.0.html
könntest Du dir ganz einfach durch austauschen der `syscommand` befehlszeilen basteln was Du für den fremden gpio brauchst
LG, florian
@Florian,
Danke für die schnelle Antwort, aber das hilft mir wohl nicht weiter, da ich mit Interrupts auf dem Rasppi arbeite:
define gpio_pin11 RPI_GPIO 17
attr gpio_pin11 DbLogExclude .*Toggle.*,.*Counter.*,.*state.*
attr gpio_pin11 direction input
attr gpio_pin11 interrupt falling
attr gpio_pin11 pud_resistor up
Würde Dein Code denn auf einem BBB funktionieren oder ist er nicht nur für den Rasppi?
Gruß
Blueberry63
der code ist nur insoweit für den raspi daß der aufruf von /usr/local/bin/gpio hardcoded ist. nach ersetzen mit was auch immer für einem anderen programm für deinen bbb sollte es auch dort laufen.
das gpio modul macht nichts anderes als den exportierten filehandle Deines gpio-pins zu öffnen und offenzuhalten:
zeile 497:
sub RPI_GPIO_inthandling($$) { #start/stop Interrupthandling
das sollte auf dem bbb ähnlich gehen, mit wieviel gefummel das dann allerdings verbunden ist vermag ich nicht zu sagen.
evtl wäre ein arduino eine alternative (nur ein paar dollar...), der wird hardware-unabhängig unterstützt und bietet auch nen interrupt auf manchen pins
alles ohne garantie, habe mich selbst nicht eingehend mit dem interrupt handling auseinandergesetzt.
LG, florian
@alle:
könnte sich ein erfahrener Programmierer der Sache annehmen und ein Modul "BBB_GPIO" schreiben? Wenn ich Florian richtig verstehe, dann ist der Aufwand nicht serh hoch, wenn man das Modul "RPI_GPIO" als Basis nimmt.
Oder lohnt sich das Ganze nicht, weil kaum jemand FHEM auf dem BBB laufen hat?
Gruß
Blueberry63
Zitat von: blueberry63 am 11 Juni 2014, 11:04:58
@alle:
könnte sich ein erfahrener Programmierer der Sache annehmen und ein Modul "BBB_GPIO" schreiben? Wenn ich Florian richtig verstehe, dann ist der Aufwand nicht serh hoch, wenn man das Modul "RPI_GPIO" als Basis nimmt.
Oder lohnt sich das Ganze nicht, weil kaum jemand FHEM auf dem BBB laufen hat?
Gruß
Blueberry63
Also bei mir läuft schon seit über einem Jahr eine interrupt gesteuerte GPIO Abfrage auf dem BBB.
Diese dient zur Drucküberwachung meines Heizkreises. Bei Druckabfall wird eine E-mail Warnung erzeugt.
Basis ist "Setting up IO Python Library on BeagleBone Black" von Adafruit.
Inzwischen dürfte es auch andere Lösungen geben.
Zitatkönnte sich ein erfahrener Programmierer der Sache annehmen und ein Modul "BBB_GPIO" schreiben?
Für einen erfahrenen Modulschreiber sicher kein Problem. ;)
Gruss Billy
ich würde es ja selbst programmieren, aber das übersteigt bei weitem meine Kenntnisse :-[
Gruß
Blueberry63
P.S.: Es gibt ja auch noch den Cubietruck als beliebte Platform für FHEM, wenn ich das hier richtig mitbekommen habe. Könnte man das Modul nicht gleich so schreiben, daß es flexibel für viele dieses Einplatinen-Computer ist?
Naja, das RPI_GPIO könnte ich auch einfach modifizieren. Wegen so einer Kleinigkeit muss ja kein neues Modul her ;)
In Ansätzen könnte es bereits laufen (nur die GPIOs müssten vorher manuell exportiert werden).
Es kommt ganz darauf an, wie die Zugriffsrechte für die Dateien unter /sys/class/gpio beim BBB sind.
Beim Raspberry läuft dort alles unter root. Daher nutze ich das gpio utility von wiringpi (/usr/local/bin/gpio) um die GPIOs mit lese/schreibrechten für den FHEM User zu exportieren.
Wenn der fhem User beim BBB schon Zugriff auf die Dateien hat kann ich RPI_GPIO so erweitern, das es auch mit dem BBB funktioniert.
Also schau mal einer nach und gib mir Bescheid :)
Zitat von: klausw am 11 Juni 2014, 22:44:25
Naja, das RPI_GPIO könnte ich auch einfach modifizieren.
Es kommt ganz darauf an, wie die Zugriffsrechte für die Dateien unter /sys/class/gpio beim BBB sind.
Beim Raspberry läuft dort alles unter root. Daher nutze ich das gpio utility von wiringpi (/usr/local/bin/gpio) um die GPIOs mit lese/schreibrechten für den FHEM User zu exportieren.
Der Zugriff bei BBB ist wie beim Raspi normalerweise nur unter root.
Vielleicht hilft dieser Link weiter.
https://www.npmjs.org/package/onoff
Oder hier Accessing GPIO pins with non-root user
https://groups.google.com/forum/#!topic/beagleboard/7a5l2QXklgM
Billy
Zitat von: Billy am 12 Juni 2014, 08:37:58
Vielleicht hilft dieser Link weiter.
https://www.npmjs.org/package/onoff
Nicht so richtig. Hier werden, wenn ich nix überlesen habe, die GPIOs als superuser exportiert
Zitat von: Billy am 12 Juni 2014, 08:37:58
Oder hier Accessing GPIO pins with non-root user
https://groups.google.com/forum/#!topic/beagleboard/7a5l2QXklgM
Das ist auch nix, was ich in das Modul einbauen kann (mal abgesehen davon das ich nicht verstehe wie ich damit Userrechte der GPIOs ändern kann ;)).
eigentlich gibt es nur 3 Lösungen:
- es gibt ein Tool (ähnlich dem gpio utility von wiringpi für das raspberry) welches mit Userrechten die GPIOs exportieren kann.
Dieses könnte ich dann in das RPI2C Modul einbauen - die GPIOs werden vor FHEM Start exportiert (damit hätte ich dann gar nix zu tun)
in diesem Fall würde ich nur eine Überprüfung der Zugriffsrechte einbauen - ein script, das mit chroot läuft und das ich vom RPII2C aus Aufrufe (dieses müsste dann halt manuell installiert werden)
Nummer 1 ist vermutlich die einfachste Variante für den Anwender.
Lasst euch was einfallen ;)
Ich baue es gern ein. Aber um die Sachen ausserhalb FHEM will ich mich eigentlich nicht kümmern.
@klausw
Also damit wir uns richtig verstehen ich habe damit kein Problem!
Ich wollte Blueberry63 nur einen Typ geben!
Bei mir habe ich das wie folgt vor dem fhem Start durch GPIO Initialisierung in rc.local gelöst!
# GPIO Initialisierung in rc.local
#---------------------------------------------------------------------
gpio=/sys/class/gpio
# Steckerleiste P9
# pin 12 --> gpio60 --> HK1
# pin 14 --> gpio50 --> HK2
# pin 16 --> gpio51 --> Frischwasser
echo 60 > /sys/class/gpio/export
echo 50 > /sys/class/gpio/export
echo 51 > /sys/class/gpio/export
# Bootwerte festlegen
echo low > /sys/class/gpio/gpio60/direction
echo low > /sys/class/gpio/gpio50/direction
echo low > /sys/class/gpio/gpio51/direction
# Rechte setzen, damit damit die gpio Scripte von fhem ausgeführt werden koennen
cd /sys/devices/virtual/gpio
chown -R fhem:root *
cd /sys/class/gpio
chown -R fhem:root *
Zitat von: Billy am 12 Juni 2014, 11:22:38
Bei mir habe ich das wie folgt vor dem fhem Start durch GPIO Initialisierung in rc.local gelöst!
# GPIO Initialisierung in rc.local
#---------------------------------------------------------------------
gpio=/sys/class/gpio
# Steckerleiste P9
# pin 12 --> gpio60 --> HK1
# pin 14 --> gpio50 --> HK2
# pin 16 --> gpio51 --> Frischwasser
echo 60 > /sys/class/gpio/export
echo 50 > /sys/class/gpio/export
echo 51 > /sys/class/gpio/export
# Bootwerte festlegen
echo low > /sys/class/gpio/gpio60/direction
echo low > /sys/class/gpio/gpio50/direction
echo low > /sys/class/gpio/gpio51/direction
# Rechte setzen, damit damit die gpio Scripte von fhem ausgeführt werden koennen
cd /sys/devices/virtual/gpio
chown -R fhem:root *
cd /sys/class/gpio
chown -R fhem:root *
Mit dieser Vorbereitung sollte das Modul RPI_GPIO direkt funktionieren (abgesehen von ein paar Fehlern im Log).
Aber muss direction nicht auf "in" oder "out" gesetzt werden?
Wenn das mal jemand von den BBB Nutzern testet und Rückmeldung gibt, dann kann ich auch noch die Möglichkeit einbauen auch "direction" im Modul zu ändern.
@klausw, Billy,
super, daß Ihr Euch schon Gedanken macht. Mangels BBB kann ich leider noch nicht helfen. Die Benutzerrechte auf dem OS bekäme ich auch umgesetzt. Ich werde mir jezt mal einen BBB bestellen und dann sehen wir weiter.
Gruß
Blueberry63
ich könnte moduländerungen auf dem cubie testen und so ggfs etwas beitragen. einen BBB hab ich nicht
Zitat von: epsrw1 am 12 Juni 2014, 14:57:35
ich könnte moduländerungen auf dem cubie testen und so ggfs etwas beitragen. einen BBB hab ich nicht
verhalten sich da die GPIOs vergleichbar zum BBB? Also können nur als root exportiert werden?
Zitat von: klausw am 12 Juni 2014, 12:56:48
Aber muss direction nicht auf "in" oder "out" gesetzt werden?
Antwort: da gibt es eine zweite Alternative!
To set a gpio as output, we set its direction as in or out. For outputs there is an alternative nomenclature where output direction can be set instead as high or low to help with glitch free operation.http://www.armhf.com/using-beaglebone-black-gpios/
Bin gerade im Urlaub deshalb kann ich auch nicht testen.
Schlage vor blueberry63 testet wenn er seinen BBB hat. Wir helfen dann soweit nötig.
Gruß Billy
es gibt ein vergleichbares ding für den cubie. die zahl der pins ist deutlich höher, ebenso ist deren verwendung weniger eingeschränkt beim cubie.
zielführend für einen kleinen überblick dürften folgende links sein:
http://hempel.dd-dns.de/cms/index.php/cubietruck-cubieboard-3/articles/die-gpio-am-cubietruck-verwenden.html (http://hempel.dd-dns.de/cms/index.php/cubietruck-cubieboard-3/articles/die-gpio-am-cubietruck-verwenden.html)
http://docs.cubieboard.org/tutorials/common/gpio_on_lubuntu (http://docs.cubieboard.org/tutorials/common/gpio_on_lubuntu)
http://www.cubieforums.com/index.php?topic=103.0 (http://www.cubieforums.com/index.php?topic=103.0)
http://linux-sunxi.org/Fex_Guide#.5Bgpio_para.5D (http://linux-sunxi.org/Fex_Guide#.5Bgpio_para.5D)
http://www.cubieforums.com/index.php?topic=2622.0 (http://www.cubieforums.com/index.php?topic=2622.0)
https://github.com/gootoomoon/WiringCB-python (https://github.com/gootoomoon/WiringCB-python)
wieviel von der sysconfig vorarbeit das WiringCB-python einem abnimmt kann ich im augenblick nicht testen da mein cubie vorübergehend anderweitig belegt ist.
ich vermute mal, beim BBB unterscheidet sich das nicht (außer in der pinbelegung)
Hallo,
melde mich wieder: der BBB ist angekommen und erfreulicherweise mit Debian Wheezy auf dem EMMC betankt. Man kann also direkt loslegen. Ich habe zwar erst am DO mehr Zeit, aber FHEM ist schon installiert. Ich werde also die nächsten Tage (spätestens DO) mal einen GPIO-Eingang testen (auf OS). Wenn das funktioniert, kann es mit FHEM weitergehen.
Gruß
Blueberry63
Zitat von: blueberry63 am 16 Juni 2014, 16:12:34
Hallo,
melde mich wieder: der BBB ist angekommen und erfreulicherweise mit Debian Wheezy auf dem EMMC betankt. Man kann also direkt loslegen. Ich habe zwar erst am DO mehr Zeit, aber FHEM ist schon installiert. Ich werde also die nächsten Tage (spätestens DO) mal einen GPIO-Eingang testen (auf OS). Wenn das funktioniert, kann es mit FHEM weitergehen.
Gruß
Blueberry63
Hast du FHEM im EMMC installiert?
Wo legst du deine Daten ab? d.h. die FHEM Logs? EMMC oder microSD?
Gruß Billy
@Billy,
wie ich schon sagte: Debian war schon im EMMC vorinstalliert. Ich habe nur die üblichen Anpassungen gemacht (Netzwerk, dpkg-reconfigure...) und dann FHEM installiert. Momentan läuft alles im EMMC. Im aktuellen System (Raspi) logge ich in eine Datenbank, die auf meinem NAS läuft (Cubietruck) und so werde es auch beibehalten. Im EMMC sind z.Zt. ca. 50% des Platzes belegt:
Filesystem Size Used Avail Use% Mounted on
rootfs 3.4G 1.6G 1.7G 49% /
udev 10M 0 10M 0% /dev
tmpfs 100M 584K 99M 1% /run
/dev/disk/by-uuid/1e1267fe-5439-487d-8883-e6fbb3894fd3 3.4G 1.6G 1.7G 49% /
tmpfs 249M 0 249M 0% /dev/shm
tmpfs 249M 0 249M 0% /sys/fs/cgroup
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 100M 0 100M 0% /run/user
/dev/mmcblk0p1 96M 72M 25M 75% /boot/uboot
Gruß
Blueberry63
Ich habe mal auf die schnelle ein "RPI_GPIO-Device" angelegt, bekomme aber sofort folgende Fehlermeldung auf der Konsole (und FHEM beendet sich):
Can't exec "/usr/local/bin/gpio": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 285, <$fh> line 47.
Can't use an undefined value as a symbol reference at ./FHEM/51_RPI_GPIO.pm line 314.
Gruß
Blueberry63
Zitat von: blueberry63 am 16 Juni 2014, 16:57:45
Ich habe mal auf die schnelle ein "RPI_GPIO-Device" angelegt, bekomme aber sofort folgende Fehlermeldung auf der Konsole (und FHEM beendet sich):
Can't exec "/usr/local/bin/gpio": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 285, <$fh> line 47.
Can't use an undefined value as a symbol reference at ./FHEM/51_RPI_GPIO.pm line 314.
Oh je, wer hat das wieder Programmiert B)
Das ist sicher der Block mit den Pullupeinstellungen...ich kann gerade nicht schauen.
Öffne die Datei bitte und suche
if ($attr eq 'pud_resistor')Dann alles was danach zwischen { und } kommt löschen.
Sorry, für die späte Antwort, aber im Moment fehlt mir die Zeit für FHEM.
Hiermit
Zitat
Öffne die Datei bitte und suche if ($attr eq 'pud_resistor')
Dann alles was danach zwischen { und } kommt löschen.
funktioniert jedenfalls das Anlegen des RPI_GPIO-Devices.
Das Testen der GPIO-Eingänge muß ich leider verschieben. Erst in 2 Wochen werde ich wieder Zeit haben, hier weiterzumachen.
Gruß
Blueberry63
Zitat von: blueberry63 am 23 Juni 2014, 09:07:58
Sorry, für die späte Antwort, aber im Moment fehlt mir die Zeit für FHEM.
Hiermit
funktioniert jedenfalls das Anlegen des RPI_GPIO-Devices.
Das Testen der GPIO-Eingänge muß ich leider verschieben. Erst in 2 Wochen werde ich wieder Zeit haben, hier weiterzumachen.
Ok, gib einfach Bescheid.
Ich werde, wenn ich Zeit finde schon ein paar Änderungen vorbereiten.
@Klaus,
noch eine kurze Bemerkung: mir wäre wichtig, daß ich die Eingänge Interrupt-gesteuert überwachen kann:
#############################
# GPIO fuer Gasmessung #
# (wiringpi wird benötigt ) #
#############################
define gpio_pin11 RPI_GPIO 17
attr gpio_pin11 DbLogExclude .*Toggle.*,.*Counter.*,.*state.*
attr gpio_pin11 direction input
attr gpio_pin11 interrupt falling
attr gpio_pin11 pud_resistor up
Gruß
Blueberry63
Hi Blueberry,
Zitat von: blueberry63 am 23 Juni 2014, 10:15:43
noch eine kurze Bemerkung: mir wäre wichtig, daß ich die Eingänge Interrupt-gesteuert überwachen kann:
#############################
# GPIO fuer Gasmessung #
# (wiringpi wird benötigt ) #
#############################
define gpio_pin11 RPI_GPIO 17
attr gpio_pin11 DbLogExclude .*Toggle.*,.*Counter.*,.*state.*
attr gpio_pin11 direction input
attr gpio_pin11 interrupt falling
attr gpio_pin11 pud_resistor up
Interrupt sollte funktionieren (es werden nur schreib/leserechte für die dateien interrupt und value benötigt).
Das Attribut
pud_resistor geht aber definitiv nicht, da es über wiringpi eingestellt wird (dafür habe ich auch keine Lösung für das BBB. Wie stellst Du aktuell den pulldown ein?).
Wichtig ist, das vor FHEM start der Pin schon als input definiert ist (dies würde in der neuen version aber vom Modul übernommen).
Grüße
Klaus
pud_resistor
... das muß ich mir auf dem BBB auch noch anschauen. Ggf. muß ich eben einen eigenen Pulldown-/Pullup-Widerstand verwenden.
Gruß
Blueberry63
Zitat von: klausw am 23 Juni 2014, 10:44:12
Hi Blueberry,
Interrupt sollte funktionieren (es werden nur schreib/leserechte für die dateien interrupt und value benötigt).
Das Attribut pud_resistor geht aber definitiv nicht, da es über wiringpi eingestellt wird (dafür habe ich auch keine Lösung für das BBB. Wie stellst Du aktuell den pulldown ein?).
Wichtig ist, das vor FHEM start der Pin schon als input definiert ist (dies würde in der neuen version aber vom Modul übernommen).
Grüße
Klaus
Hallo,
ich habe jetzt mal das Modul RPI_GPIO zur Verwendung am BBB ausgiebig getestet.
Alles funktioniert bestens! :) Auch der Interrupt! GPIO Eingang hängt über 1k an 3,3V und wird auf low gezogen!
Voraussetzung bei mir: --> Auszug aus der rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
# 1-wire fuer GPIO2 initialisieren
##echo BB-W1:00A0 > /sys/devices/bone_capemgr.9/slots
# startet den Dienst fhem nach 20 Sekunden
(/bin/sleep 20 && /etc/init.d/fhemgg start) # ein Dienst
# GPIO Initialisierung
#---------------------------------------------------------------------
gpio=/sys/class/gpio
# Steckerleiste P8
# ---------------------------------
# pin 13 --> gpio23 --> LED
echo 23 > /sys/class/gpio/export
# pin 15 --> gpio47 --> Relais
echo 47 > /sys/class/gpio/export
# pin 17 --> gpio27 --> Interrupt Eingang
echo 27 > /sys/class/gpio/export
# Bootwert PIN P8_13 gpio23 festlegen
echo out > /sys/class/gpio/gpio23/direction
echo 0 > /sys/class/gpio/gpio23/value
# ------------------------------------------
# Bootwert PIN P8_15 gpio47 festlegen
echo out > /sys/class/gpio/gpio47/direction
echo 0 > /sys/class/gpio/gpio47/value
# ------------------------------------------
# Bootwert PIN P8_17 gpio27 festlegen
echo in > /sys/class/gpio/gpio27/direction
# Rechte setzen, damit damit die gpio Scripte von fhem ausgeführt werden koennen
cd /sys/devices/virtual/gpio
chown -R fhem:root *
cd /sys/class/gpio
chown -R fhem:root *
# Rechte setzen, damit damit die I2c Module von fhem ausgeführt werden koennen
chown fhem /dev/i2c-*
chgrp dialout /dev/i2c-*
chmod +t /dev/i2c-*
chmod 660 /dev/i2c-*
exit 0
@Billy,
ich stehe kurz vor meinem Urlaub und kann daher nicht sofort testen. Aber ich kann ja trotzdem schon mal fragen:
- Es funktioniert mit der aktuellen Version des RPI_GPIO-Moduls?
- Wie ist Deine Device-Definition?
Danke auf jeden Fall für Deine Mühe.
Gruß
Blueberry63
Zitat von: Billy am 26 Juni 2014, 13:37:03
ich habe jetzt mal das Modul RPI_GPIO zur Verwendung am BBB ausgiebig getestet.
Alles funktioniert bestens! :) Auch der Interrupt! GPIO Eingang hängt über 1k an 3,3V und wird auf low gezogen!
Super, dann baue ich das GPIO Modul soweit um, das man ihr den Pin nur noch exportieren müsst. Direction kann dann auch im Modul selbst geschaltet werden.
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?
Grüße
Klaus
Zitat von: blueberry63 am 26 Juni 2014, 14:19:17
@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
ZitatWie 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
hier (http://forum.fhem.de/index.php/topic,24535.msg180159.html#msg180159) 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
Zitat von: klausw am 30 Juni 2014, 00:07:57
hier (http://forum.fhem.de/index.php/topic,24535.msg180159.html#msg180159) 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. :)
Zitatmit dieser sollte die gpio utility meldung weg sein
Ist weg! :)
Zitatausserdem 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.
Zitatgpio 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?
Hi Billy,
sehr schön.
Dann kann ich es ja fast schon einchecken.
Zitat von: Billy am 30 Juni 2014, 15:53:23
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).
Zitat von: Billy am 30 Juni 2014, 15:53:23
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
Hallo Klaus,
nur zum Verständnis. Nach einem shutdown von FHEM habe ich folgende Einträge in fhem.save.
Zitatsetstate 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
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
Zitat von: klausw am 30 Juni 2014, 17:50:36
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
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?
hier (http://forum.fhem.de/index.php/topic,24535.msg180346.html#msg180346) gibt es eine korrektur
hatte immer noch fehler drin :-/
Zitat von: Billy am 30 Juni 2014, 18:21:15
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
sub RPI_GPIO_fileaccess($$;$);in Zeile 28 sollte helfen.
Zitat von: klausw am 30 Juni 2014, 19:13:53
hier (http://forum.fhem.de/index.php/topic,24535.msg180346.html#msg180346) 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
Zitat von: Billy am 30 Juni 2014, 20:15:55
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 ;)
Zitat von: klausw am 30 Juni 2014, 20:29:53
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
versuchs mal damit
restoreOnStartup kann jetzt auf on,off oder last gesetzt werden
Zitat von: klausw am 01 Juli 2014, 17:54:15
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
Zitat von: Billy am 01 Juli 2014, 19:01:49
Was ist der Unterschied zwischen restoreOnStartup yes und restoreOnStartup last?
Gruß Günter
Keiner, ist nur noch die alte Einstellung...fliegt noch raus
Super....dann kanns ja fast hochgeladen werden ;D
Änderungen sind im Modul eingepflegt und werden inzwischen per update verteilt
@Klaus,
ich melde mich wieder zurück. Vielen Dank für die Arbeit, die Du Dir inzwischen gemacht hast.
Beim 1. Test heute bekomme ich folgende Meldung:
Zitat
configfile: gpio_p8_pin17: file /usr/local/bin/gpio doesnt exist
Bei meinen Nachforschungen bin ich auf die Zeile
my $gpioprg = "/usr/local/bin/gpio"; #WiringPi GPIO utility
in der "51_RPI_GPIO.pm" gestossen.
Muß auf dem BBB auch "wiring pi" installiert werden?
Gruß
Blueberry63
Zitat von: blueberry63 am 08 Juli 2014, 12:55:37
@Klaus,
ich melde mich wieder zurück. Vielen Dank für die Arbeit, die Du Dir inzwischen gemacht hast.
Beim 1. Test heute bekomme ich folgende Meldung:
Bei meinen Nachforschungen bin ich auf die Zeile
my $gpioprg = "/usr/local/bin/gpio"; #WiringPi GPIO utility
poste mal deine config
in der "51_RPI_GPIO.pm" gestossen.
Muß auf dem BBB auch "wiring pi" installiert werden?
Gruß
Blueberry63
Poste mal deine Config
Zitat von: blueberry63 am 08 Juli 2014, 12:55:37
@Klaus,
Beim 1. Test heute bekomme ich folgende Meldung:
configfile: gpio_p8_pin17: file /usr/local/bin/gpio doesnt exist
Hast du P8 pin 17 das entspricht beim BBB --> gpio27
in rc.local oder sonstwo beim booten mit
echo 27 > /sys/class/gpio/exportauch aktiviert?
ZitatMuß auf dem BBB auch "wiring pi" installiert werden?
nein.
Gruß Billy
Ich habe alles nach bestem Wissen erledigt:
Zitat
root@bbb:/sys/class/gpio# ls -al
total 0
drwxr-xr-x 2 root root 0 Jan 1 2000 .
drwxr-xr-x 57 root root 0 Jan 1 2000 ..
--w------- 1 fhem root 4096 Jul 8 12:45 export
lrwxrwxrwx 1 fhem root 0 Jul 8 12:46 gpio27 -> ../../devices/virtual/gpio/gpio27
lrwxrwxrwx 1 fhem root 0 Jul 8 12:46 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
lrwxrwxrwx 1 fhem root 0 Jul 8 12:46 gpiochip32 -> ../../devices/virtual/gpio/gpiochip32
lrwxrwxrwx 1 fhem root 0 Jul 8 12:46 gpiochip64 -> ../../devices/virtual/gpio/gpiochip64
lrwxrwxrwx 1 fhem root 0 Jul 8 12:46 gpiochip96 -> ../../devices/virtual/gpio/gpiochip96
--w------- 1 fhem root 4096 Jul 8 12:46 unexport
Gruß
Blueberry63
Ja das sieht gut aus. :)
Meine FHEM Definition sieht für P8Pin17 und interrupt so aus.
Vielleicht hilfts.
# --------------- P8_Pin17 RPI_GPIO 27 ----------------
define P8_Pin17 RPI_GPIO 27
attr P8_Pin17 direction input
attr P8_Pin17 event-on-update-reading state
attr P8_Pin17 interrupt both
attr P8_Pin17 poll_interval 10
attr P8_Pin17 room Test
Billy
Funktioniert es denn?
die Fehlermeldung kann auch kommen wen Du die pulldown option verwendest ...siehe commendref
Das war es, ich hatte
attr gpio_p8_pin17 pud_resistor up
gesetzt.
Bis jetzt habe ich nur das Setup gemacht, der Test mit angeschlossener Hardware steht noch aus (heute oder morgen).
Gruß
Blueberry63
@Klaus (und alle anderen)
Was lange währt, währt gut: gestern habe ich FHEM vom Rasppi auf den BBB umgezogen. Das Einlesen des Gaszählers über GPIO hat ohne Probleme funktioniert.
Vielen Dank für Eure Unterstützung!
Gruß
Blueberry63
Super! :)
So muß es sein.
Und spürst du die Leistungssteigerung im Vergleich zum Pi?
Gruß Billy
ZitatUnd spürst du die Leistungssteigerung im Vergleich zum Pi?
Meine Konstallation sieht jetzt folgerndermassen aus: NAS mit MySL-DB auf
Cubietruck, FHEM auf
BBB (mit DB auf dem NAS).
Anfangs hatte ich das NAS auf einer NSLU2 laufen und nachdem ich die NSLU2 durch den Cubietruck ersetzt hatte, ging die Post ab. Der Engpaß war wohl die DB auf der altersschwachen NSLU2.
Der BBB hat jetzt - gefühlt - nicht mehr so viel Performance-Gewinn gebracht, aber ich werde es beobachten.
Gruß
Blueberry63