WiringPI: GPIO 0,2,3 als Input und FHEM steht ?!?

[M_I_B]

Hallo liebe Leute,

habe ich da irgend etwas übersehen? Laut den Tabellen ist der physikalische PIN 11, 13, 15 (GPIO 0, 2, 3) für WiringPI der Port 0, 2 und 3.
Wenn ich die aber als Input definiere und ein Reload-CFG mache, kommt FHEM nicht mehr aus irgend einer Endlosschleife. Da holft dann nur ein Restart über die Konsole, nachdem die Definition auskommentiert wurde.
Im Übrigen funktionieren alle als Ausgang gesetzten Ports einwandfrei und wie erwartet...

Code Auswählen Erweitern

define Sense1 RPI_GPIO 0
attr Sense1 direction input
attr Sense1 alias Eingang 1

define Sense2 RPI_GPIO 3
attr Sense2 direction input
attr Sense2 alias Eingang 2

define Sense3 RPI_GPIO 2
attr Sense3 direction input
attr Sense3 alias Eingang 3

define BR RPI_GPIO 16
attr BR direction output
attr BR alias Öl- Brenner

define HP RPI_GPIO 20
attr HP direction output
attr HP alias Pumpe Heizung

define WP RPI_GPIO 26
attr WP direction output
attr WP alias Pumpe Speicher

define ZP RPI_GPIO 13
attr ZP direction output
attr ZP alias Pumpe Zirkulation

define res RPI_GPIO 19
attr res direction output
attr res alias (reserve)


Sind die irgendwie verboten oder gibt es andere Einschränkungen, die ich nicht gesehen habe resp. kenne?

Ein Schubs wäre nett ...

[klausw]

PIN 11, 13, 15 sind GPIO17,27,22
Es ist nicht die WiringPi Notation sondern die BCM GPIO Nummer.

[M_I_B]

... öhhh .. Ok, das klappt 

Ich habe mich wohl verwirren lassen, da das Ganze ja über die WPI läuft und dort die IO's anders bezeichnet sind...


Supi und Dank für die schnelle Hilfe... weiter geht's

[klausw]

... öhhh .. Ok, das klappt 

Ich habe mich wohl verwirren lassen, da das Ganze ja über die WPI läuft und dort die IO's anders bezeichnet sind...


Supi und Dank für die schnelle Hilfe... weiter geht's

Gern

Das Ganze läuft aber nicht mit WiringPi... Das ist nur eine zusätzliche Option.
Der Zugriff verfolgt eigentlich über das Filesystem

[M_I_B]

... öhhh, du verwirrst mich
Ich dachte, die WPi ist genau dafür gemacht, damit man aus FHEM heraus ohne große Klimmzüge auf die GPIO's zugreifen kann? Zumindest hatte ich das WiKi so verstanden.
Dann könnte ich die WPi also wieder entsorgen?

[klausw]

... öhhh, du verwirrst mich
Ich dachte, die WPi ist genau dafür gemacht, damit man aus FHEM heraus ohne große Klimmzüge auf die GPIO's zugreifen kann? Zumindest hatte ich das WiKi so verstanden.
Dann könnte ich die WPi also wieder entsorgen?

Die Wiki gehört überarbeitet, es werden noch freiwillige gesucht

Du kannst es drauf lassen, er stört sicher nicht, ist aber nicht notwendig. Bei Jessi Full ist es sowieso mit dabei.

[M_I_B]

Die Wiki gehört überarbeitet, es werden noch freiwillige gesucht

... ach 

Du kannst es drauf lassen, er stört sicher nicht, ist aber nicht notwendig. Bei Jessi Full ist es sowieso mit dabei.

Ok, wenn es keine Ressourcen frisst, lasse ich es drauf. Ist allerdings ein aktuelles Jessie lite und wurde von mir nachträglich installiert.
Hauptsache es geht jetzt und ich kann erkennen, ob der Brenner läuft, Thermoschutz ausgelöst hat oder auf Störung gegangen ist. Is zwar alles gestern auf Lochraster gefrickelt, aber für einen Prototyp reicht das locker...

[M_I_B]

... ähhh ja ... Nächstes Problem 

Die Eingänge tun ja jetzt vollkommen schmerzfrei. Nach einem "set In(x) readValue" tauchen auch die 4 Readings "Dblclick, Longpress, Pinlevel, state" auf. In meinem Fall interessiert mich nur "state".
Auf dem RPi der Steuerung ist das auch vollkommen ok. Dort wird die übliche Funzel angezeigt so wie in state, STATE, und Longpress jeweils on oder off.

Wenn ich aber nun einen wie ...

Code Auswählen Erweitern

define send_In1 notify In1 set call_xeon cmd set In1 $EVENT
... mache, um den Status der Eingänge an den Master zu übermitteln, taucht da im entsprechenden Dummy nicht on resp. off auf, sondern unerwartet entweder "Longpress: on|off" oder aber "Pinlevel: low". Also je nach Zustand ein anderes Reading... Nach weiteren Versuchen dann nur noch "Longpress: on|off"... Hä???

Ok, die Frage gehört ggf. in ein anderes Board, aber dann ist sie nach meinem Dafürhalten aus dem Zusammenhang gerissen...

Frage also: Wie bekomme ich da ein schnödes on|off rüber auf den Server, ohne den Klimmzug über DOIF machen zu müssen?

[klausw]

notify ist schon korrekt

nur wird bei deinem Beispiel jedes Event, das von In1 kommt verarbeitet
Für deinen Fall musst du das Suchmuster einfach um state erweitern
oder in In1 das eventonchangereading Attribut nutzen und nur state übermitteln.

[M_I_B]

... ich danke vielmals! Das mit $EVENT alles übermittelt wird, hatte ich irgendwie aus den Augen verloren 

... und kaum macht man's richtig, tut das auch