Ich habe eine weiteren MCP2307 über I2C betrieben und bekomme immer wieder Fehler im LOG.
Folgende Anschlüsse an RAspi:
* MCP23017 Erweiterungsboard für 7 Sensoren und 4 Ausgänge -Adresse (20 )
* 8 Kanal Relaisboard mit MCP23017 8 Ein und Ausgänge steuerbar -Adresse (21 )
* 1-wire Board -Adresse (18 )
* CUL Funkmodul -Adresse (50 )
Zu Beginn sieht eigentl. alles ganz ok aus.
Auszug aus Logfile:
2017.12.25 10:28:32 1: *** NT- Signal off ****************
2017.12.25 10:28:32 2: Messages collected while initializing FHEM: /var/log/fhem/fhem.save: Please define Diag_OWtemp1 first Please define FileLog_OWtemp1 first Please define OWAvail1 first Please define OWAvail1 first Please define OWAvail1 first Please define OWAvail1 first Please define OWTemp1Evt first Please define OWTemp1Evt first Please define OWtemp1 first Please define OWtemp1 first Please define OWtemp1 first Please define myOWServer first Autosave deactivated
2017.12.25 10:28:32 0: Featurelevel: 5.8
2017.12.25 10:28:32 0: Server started with 170 defined entities (fhem.pl:15377/2017-11-01 perl:5.014002 os:linux user:fhem pid:2094)
2017.12.25 15:29:33 3: MeinWetter: read from https://query.yahooapis.com:443 timed out
2017.12.25 19:32:31 3: i2cBus: HWaccess blockweise nach 0x21 schreiben, Reg: 0x13 Inh: 255, laenge: 2| -> syswrite failure: Input/output error
2017.12.25 19:32:31 3: icMCP_R8: failure in message from i2cBus
2017.12.25 19:32:31 3: Direction: i2cwrite I2Caddress: 0x21 Register: 0x13 Data: 0xFF received: undef
2017.12.25 19:32:33 3: i2cBus: HWaccess blockweise von 0x21 lesen, Reg: 0x12 -> syswrite failure: Input/output error
.
.
.
2017.12.26 06:19:27 3: icMCP_R8: failure in message from i2cBus
2017.12.26 06:19:27 3: Direction: i2cwrite I2Caddress: 0x21 Register: 0x13 Data: 0xFF received: undef
2017.12.26 06:19:27 3: i2cBus: HWaccess blockweise nach 0x21 schreiben, Reg: 0x12 Inh: 191, laenge: 2| -> syswrite failure: Input/output error
2017.12.26 06:19:27 3: icMCP_R8: failure in message from i2cBus
2017.12.26 06:19:27 3: Direction: i2cwrite I2Caddress: 0x21 Register: 0x12 Data: 0xBF received: undef
2017.12.26 06:19:27 3: i2cBus: HWaccess blockweise nach 0x21 schreiben, Reg: 0x13 Inh: 255, laenge: 2| -> syswrite failure: Input/output error
2017.12.26 06:19:27 3: icMCP_R8: failure in message from i2cBus
2017.12.26 06:19:27 3: Direction: i2cwrite I2Caddress: 0x21 Register: 0x13 Data: 0xFF received: undef
2017.12.26 06:19:27 3: i2cBus: HWaccess blockweise nach 0x21 schreiben, Reg: 0x12 Inh: 191, laenge: 2| -> syswrite failure: Input/output error
2017.12.26 06:19:27 3: icMCP_R8: failure in message from i2cBus
2017.12.26 06:19:27 3: Direction: i2cwrite I2Caddress: 0x21 Register: 0x12 Data: 0xBF received: undef
2017.12.26 06:19:27 3: i2cBus: HWaccess blockweise nach 0x21 schreiben, Reg: 0x13 Inh: 255, laenge: 2| -> syswrite failure: Input/output error
2017.12.26 06:19:27 3: icMCP_R8: failure in message from i2cBus
2017.12.26 06:19:27 3: Direction: i2cwrite I2Caddress: 0x21 Register: 0x13 Data: 0xFF received: undef
2017.12.26 06:20:02 1: *** NT- Signal off ****************
2017.12.26 09:00:00 3: alive_check: 1
Ab 6 Uhr ist dann wieder Ruhe mit Problemen. Das NT-Signal kam über das MCP an Adresse 0x20.
An 0x21 werden eigentl. nur die Ausgabe Ports verwendet, wobei 1-2 Ports jede Minute auf "on" gesetzt werden.
Aber was verursacht nun die Fehler ?
Laut Log wird auf Reg 0x12 0xBF geschrieben ( GPA0-7) - sprich für meine Relais der Port A6 auf 0 was stimmt aber
offensichtl. ab und zu nicht funktioniert.
Die Meldung: "Direction: i2cwrite I2Caddress: 0x21 Register: 0x13 Data: 0xFF received: undef" wird hier geschrieben oder gelesen. Die GPAB sind Eingabe Ports und sollten gelesen werden.
Meine Config:
### Interrupt A oder B #### Pin 16 -- GPIO23
define Inter23 RPI_GPIO 23
attr Inter23 direction input
attr Inter23 active_low yes
attr Inter23 interrupt both
attr Inter23 userReadings test {fhem ("get icMCP_R8");; return "ausgefuehrt"}
### MCP23017- Adresse 0x21
define icMCP_R8 I2C_MCP23017 0x21
attr icMCP_R8 IODev i2cBus
# output -relais ports
attr icMCP_R8 OutputPorts A0,A1,A2,A3,A4,A5,A6,A7
# können nicht invertiert. Bei Startup on= relais aus ; off= relais an
attr icMCP23017 OnStartup A0=on,A1=on,A2=on,A3=on,A4=on,A5=on,A6=on,A7=on
# Eingabe port definitionen -- mit pullup
attr icMCP_R8 Pullup B0,B1,B2,B3,B4,B5,B6,B7
attr icMCP_R8 Interrupt B0,B1,B2,B3,B4,B5,B6,B7
attr icMCP_R8 InterruptOut connected_active-low
Wie kann ich hier weitere Diagnose machen um herauszufinden, was falsch ist ?
Soweit hatten die Fehler sich nicht ausgewirkt, aber ich hatte bereits 1 FAll als ich einen Port/Relais
mit "set ... on-timer-on 1" gesetzt hatte, dass er nicht mehr zurückgesetzt wurde, was natürlich schlecht ist.
Hinweise willkommen.
https://forum.fhem.de/index.php/topic,13092.0.html
Teilerfolg.
Mittlerweile habe ich einige Fehler beseitigt.
Ich habe bei dem Start von FHEM die Zugriffsrechte auf /sys/class/gpio geprüft und festgestellt, dass hier eventuell ein Fehler war.
Ein Beschreibung wie dies wirklich korrekt gemacht werden soll, habe ich aber noch nicht gefunden.
Bekomme immer noch einen Fehler auf meine für die Interrupts verwendeten GPIO beim start von FHEM
2017.12.27 12:19:10 1: Including ./FHEM/rw_I2C_GPIO.cfg
2017.12.27 12:19:15 1: Can't open file: Interrupt, active_low
2017.12.27 12:19:16 1: Including ./FHEM/rw_I2C_Relais8.cfg
2017.12.27 12:19:21 1: Can't open file: Inter23, active_low
Fhem Configs:
###Interrupt A&B#### Pin 15 -- GPIO22
define Interrupt RPI_GPIO 22
attr Interrupt direction input
attr Interrupt active_low yes
attr Interrupt interrupt both
attr Interrupt userReadings test {fhem ("get icMCP23017");; return "ausgefuehrt"}
### Interrupt A oder B #### Pin 16 -- GPIO23
define Inter23 RPI_GPIO 23
attr Inter23 direction input
attr Inter23 active_low yes
attr Inter23 interrupt both
attr Inter23 userReadings test {fhem ("get icMCP_R8");; return "ausgefuehrt"}
Mein GPIO situation:
Kurzversion für Jessylite, das alles gemacht?
jessylite
sudo adduser fhem i2c
sudo adduser fhem gpio
sudo apt-get install wiringPi
reboot tut not
gpio -v
Zitat von: roli am 27 Dezember 2017, 12:34:21
Mittlerweile habe ich einige Fehler beseitigt.
bedeutet der I2C Zugriff läuft?
Zitat von: roli am 27 Dezember 2017, 12:34:21
Ich habe bei dem Start von FHEM die Zugriffsrechte auf /sys/class/gpio geprüft und festgestellt, dass hier eventuell ein Fehler war.
Ein Beschreibung wie dies wirklich korrekt gemacht werden soll, habe ich aber noch nicht gefunden.
fhem-hm-knecht hat es gut zusammengefasst, wobei wiringpi nicht notwendig ist
In der commandref ist auch beschrieben wie alles eingerichtet wird
So wie die Rechte deiner GPIOs aussehen hast du selbst dran rumgestellt.
Hat denn ein "sudo adduser fhem gpio" mit anschließendem Neustart nicht gereicht?
Funktioniert bei allen raspian Versionen (wenn du nicht gerade nen Kernelupgrade gemacht hast)
Ich vermute, es wird wohl an updates des systems liegen -- schade, dass wohl Teile hier immer mal wieder was umstellen und man es nicht merkt.
Also es gab keine Gruppe gpio mehr bei mir !
Ich versuche es jetzt wie im Beitrag : https://forum.fhem.de/index.php?topic=42788.0
und werde eine rules Datei hinzufügen -- sollte hoffentl. dann auch weitere GPIO Verwendungen abdecken.
Außer "Can't open " habe ich sonst keine Fehler mehr
Ich denke ich habe die Vorbereitung sudo adduser fhem gpio nicht mehr gelesen, da ich ja alles schon lange im Einsatz hatte.
Falls hier wirklich etwas passieren kann, wenn man module updated, dann sollte man dies eventuell als standard immer Prüfen, ob es die
Gruppe gpio mit dem user fhem noch gibt ?
Habe jetzt Test laufen gelassen und Problem ist weg !!!