Modul für die Ansteuerung des MCP23017 I2C Portextender

[Elektrofreak]

Danke für den Tipp! 

Das ist für mich auch ausreichend.

[R1F800]

Moinsen,
ich habe noch einmal eine Nachfrage bezüglich der Interruptauswertung / reset.

Ich habe Port A und Port B mit jeweils Eingängen versehen.
Jetzt ändert sich ein IO am MCP. Der Interrupt des Ports auch.
Dieses Signal nutze ich dann um das Auslesen aller an PORT A oder B  (INTA/INTB) zu initiieren. >> muss ich hierfür dann ein DOIF bauen oder kann ich das im INT Device dann ablegen?
wie resette ich den INTA bzw INTB nach dem Auslesen, oder passiert das dann durch den Auslesezyklus automatisch?

[klausw]

Moinsen,
ich habe noch einmal eine Nachfrage bezüglich der Interruptauswertung / reset.

Ich habe Port A und Port B mit jeweils Eingängen versehen.
Jetzt ändert sich ein IO am MCP. Der Interrupt des Ports auch.
Dieses Signal nutze ich dann um das Auslesen aller an PORT A oder B  (INTA/INTB) zu initiieren. >> muss ich hierfür dann ein DOIF bauen oder kann ich das im INT Device dann ablegen?
wie resette ich den INTA bzw INTB nach dem Auslesen, oder passiert das dann durch den Auslesezyklus automatisch?

Wenn du für die jeweiligen Eingänge Interrupt Erkennung aktiviert hast wird der entsprechende INTx Pin aktiv gesetzt.
Dieser aktiv, bis die Ports ausgelesen werden.
Direkt beim Auslesen der Ports werden die INTx zurück gesetzt.

Mit INT Device meinst du ein GPIO Device an welches der INTx angeschlossen wird?
Wenn ja:
Du hast 3 Möglichkeiten

• DOIF
• notify
• userReadings Attribut der GPIO Devices:
  temp {fhem "get MCPDevice"}

[R1F800]

...
Direkt beim Auslesen der Ports werden die INTx zurück gesetzt.

OK, aber was genau setzt die Interrupts zurück ... das Auslesen triggert im MCP den Reset? oder schickt Firmata beim Auslesen aktiv ein RESET ?

....
Mit INT Device meinst du ein GPIO Device an welches der INTx angeschlossen wird?
...

Ja ganz genau.

DOIF und notify habe ich jeweils hinbekommen.

Das userReading was Du beschreibst  ist dann kein eigenes Device sondern wird dann nur als Attribut bei dem INT GPIO Device gesetzt?

[klausw]

OK, aber was genau setzt die Interrupts zurück ... das Auslesen triggert im MCP den Reset? oder schickt Firmata beim Auslesen aktiv ein RESET ?

Firmata? Ich muss überlesen haben, das der MCP über einen Firmata angebunden ist.
Das ist aber sowieso egal. Firmata ist transparent für I2C.

Der MCP selbst setzt die INTx Ausgänge zurück wenn der jeweilige Port ausgelesen wird.

Das userReading was Du beschreibst  ist dann kein eigenes Device sondern wird dann nur als Attribut bei dem INT GPIO Device gesetzt?

Genau
Das Attibut wird hier für diesen Zweck missbraucht.
Es hat den Vorteil, das kein weiteres Device angelegt wird

[R1F800]

...
Genau
Das Attibut wird hier für diesen Zweck missbraucht.
Es hat den Vorteil, das kein weiteres Device angelegt wird

Ist denn die Anzahll der Devices so performancebeeinflussend ?

[klausw]

Ist denn die Anzahll der Devices so performancebeeinflussend ?

mit Sicherheit, aber das gilt auch für userreadings.
Aber die Beeinflussung ist verschwindend gering.

Ich mache das eher wegen Übersichtlichkeit. Ist einfach Geschmackssache.

[R1F800]

mit Sicherheit, aber das gilt auch für userreadings.
Aber die Beeinflussung ist verschwindend gering.

Ich mache das eher wegen Übersichtlichkeit. Ist einfach Geschmackssache.

Hallo, vielen Dank für die Erklärungen.

Nun noch eine weitere Frage... bei der Komplettierung meiner Schaltung (2x Portexpander mit einer einzelnen Bank zur Ansteuerunge eines 8fach Relaisboards, habe ich das Problem, dass ich die Ausgänge invertiert sind.
Das wäre als solches nicht so schlimm in FHEM, aber das Problem ist, dass wenn ich sagen wir PORTA7 auf ON setze (Relais fällt ab) Port A0-A6 bleiben auf OFF.  Schalte ich jetzt aber PORTA6 o.ä. ebenfalls auf ON fällt geht A7 wiedfer aif OFF.

Habe ich heir einen Denkfehler oder habe ich ein ATTR vergessen oder sowas ?

Gleiches gilt für die anderen Ausgänge   ... manchmal schaltet der Expander die anderen um, manchmal behält er den STATE des zuvor übermittelten bei ... ggf. ist das Problem woanders zu suchen?

[R1F800]

Code Auswählen Erweitern

Internals:
   DEF        0x22
   FIRMATA_SENDSTAT Ok
   FUUID      5fc508ca-f33f-31ee-942a-199b8afc46333796
   I2C_Address 34
   IODev      FIRMATA
   NAME       NanoPortexpander2
   NR         22
   STATE      Ok
   TYPE       I2C_MCP23017
   READINGS:
     2020-12-17 15:58:06   PortA0          on
     2020-12-17 12:15:46   PortA1          on
     2020-12-17 15:56:13   PortA2          off
     2020-12-17 12:15:46   PortA3          on
     2020-12-17 12:15:46   PortA4          on
     2020-12-17 12:15:46   PortA5          on
     2020-12-17 15:57:12   PortA6          on
     2020-12-17 12:15:46   PortA7          on
     2020-12-17 15:30:18   PortB0          off
     2020-11-30 16:24:24   PortB1          on
     2020-11-30 16:24:24   PortB2          on
     2020-11-30 16:24:24   PortB3          on
     2020-11-30 16:24:24   PortB4          on
     2020-11-30 16:24:24   PortB5          on
     2020-11-30 16:24:24   PortB6          on
     2020-11-30 16:24:24   PortB7          on
     2020-12-17 15:58:08   state           Ok
Attributes:
   IODev      FIRMATA
   Interrupt  B0,B1,B2,B3,B4,B5,B6,B7
   InterruptOut separate_active-low
   OnStartup  A0=on,A1=on,A2=on,A3=on,A4=on,A5=on,A6=on,A7=on
   OutputPorts A0,A1,A2,A3,A4,A5,A6,A7
   Pullup     B0,B1,B2,B3,B4,B5,B6,B7
   room       FIRMATA
   verbose    5

[R1F800]

So, ich habe was rausgefunden... vielleicht hatte ich einen Denkfehler, aber sie Sachlage zeigt sich wie folgt.

Ich schalte einen PORT Ausgang A0 auf 1
A2 und A6 als Beispiel ebenfalls

>>> es folgt ein unkontrolliertes verhalten; die Readings in fhem zu den OUTPUTS haben sich noch nciht aktualisiert. Diese bekommen scheinbar mein Command nicht mit

Ich schalte einen PORT Ausgang
A0 auf 1 >>> READINGS aktualisieren
A2 auf 1 >>> READINGS aktualisieren
A6 auf 1 >>> READINGS aktualisieren
A2 auf 0 >>> READINGS aktualisieren 
Und et voila .. keine willkürlichen Schaltvorgänge mehr.

Jetzt die spannende Frage ist wenn ich ein OUTPUT setze implizit eine manuell getriggerte Auslesung des MCP erforderlich (jedenfalls scheinen die SET commands ja auf die Readings keinen Einfluss zu haben)
Also, ist das ein BUG oder ist ein ein gewolltes Verhalten, dass ich zwingen auch bei OUTPUTS wie bei den INPUTS mit Interrupt den MCP neu auslesen muss....

[klausw]

Oje, das ist alles ne Weile her.
Ich glaube das liegt daran, dass Firmata als IODev die Befehle nicht quittiert. Das Thema gab es hier schonmal.
Meiner Meinung nach funktioniert es direkt am I2C des Raspberry.
Es ist kein Bug, aber auch kein Feature
Die Lösung wäre im Moment genau das, was du gemacht hast.
Ich könnte noch ein Attribut einführen, was dies automatisch macht.
Die bessere Lösung wäre meiner Ansicht nach die Quittierung seitens Firmata.

[R1F800]

...
Ich könnte noch ein Attribut einführen, was dies automatisch macht.
Die bessere Lösung wäre meiner Ansicht nach die Quittierung seitens Firmata.

Dein Vorschlag wäre super!
Aber ich gebe Dir Recht, dass die beste Lösung die Übernahme des Refresh eine aktive Quittierung seitens Firmata selbst wäre. >> Vielleicht lönnen wir das mit dem FIRMATA Entwickler gerne mal zusammen diskutieren.

Ich bin aktuell nur ein wenig irritiert über eine Fehlermeldung, die ich erst nach dem Umzug meines nano Firmata Clients von einem FHEM Server auf einen anderen hatte ...
Dort bekomme ich nach einem Neustart den Hinweis eines errors:
" Unhandled sysex command"
Keine Ahnung woher das kommt. ich habe mal die verbose auf 5 gedreht .... und dann kam beim LOG vor diesem Fehler folgendes zu Tage (sagt mir leider nicht viel)
READINGS:

Code Auswählen Erweitern


error  Unhandled sysex command 2020-12-27 12:02:56
state Initialized 2020-12-27 12:03:01

LOG:

Code Auswählen Erweitern

2020.12.27 12:05:48 3: FIRMATA: Firmata Firmware Version ConfiguredFirmataGarage2.ino V_2_10 (using Protocol Version V_2_06)
2020.12.27 12:05:48 5: FIRMATA FRM:>f069f7
2020.12.27 12:05:48 5: FIRMATA FRM:>f06bf7
2020.12.27 12:05:48 5: FIRMATA FRM:<f07155006e00680061006e0064006c0065
2020.12.27 12:05:48 5: FIRMATA: setup stage 2
2020.12.27 12:05:48 5: FIRMATA FRM:<006400200073007900730065007800200063
2020.12.27 12:05:48 5: FIRMATA: setup stage 2
2020.12.27 12:05:48 5: FIRMATA FRM:<006f006d006d0061006e006400f7
2020.12.27 12:05:48 3: FIRMATA: received message 'Unhandled sysex command'
2020.12.27 12:05:48 5: FIRMATA: setup stage 2

es scheint, als wäre bei der Initialisierung etwas krumm ...

[klausw]

Das ist sicher eine Frage für den Firmata Thread.
Ich habe keine Ahnung was da steht

[Byllyy]

Hallo zusammen,
ich versuche das Modul zur Ansteuerung von drei MCP23017 zu verwenden. Die MCP23017 sind über I2C verkabelt, die Adressen eindeutig vergeben und nach dem Beispiel von Antwort#40 konfiguriert.
Bei mir sind auf allen drei Modulen die Eingänge auf INTB.
Jetzt habe ich eine Frage zur Verwendung des Interrupt bei drei Modulen. Hier habe ich leider im Netz unterschiedliche Angaben gefunden, mal mit Pullup auf der INT Leitung, mal mit verschiedenen Attributen beim Interrupt.

Wie verkabel und konfiguriere ich den INT bei mehreren Modulen richtig?

Danke für eure Hilfe,
Byllyy

[R1F800]

Hallo zusammen,
ich versuche das Modul zur Ansteuerung von drei MCP23017 zu verwenden. Die MCP23017 sind über I2C verkabelt, die Adressen eindeutig vergeben und nach dem Beispiel von Antwort#40 konfiguriert.
Bei mir sind auf allen drei Modulen die Eingänge auf INTB.
Jetzt habe ich eine Frage zur Verwendung des Interrupt bei drei Modulen. Hier habe ich leider im Netz unterschiedliche Angaben gefunden, mal mit Pullup auf der INT Leitung, mal mit verschiedenen Attributen beim Interrupt.

Wie verkabel und konfiguriere ich den INT bei mehreren Modulen richtig?

Danke für eure Hilfe,
Byllyy

Hallo zusammen,
ich versuche das Modul zur Ansteuerung von drei MCP23017 zu verwenden. Die MCP23017 sind über I2C verkabelt, die Adressen eindeutig vergeben und nach dem Beispiel von Antwort#40 konfiguriert.
Bei mir sind auf allen drei Modulen die Eingänge auf INTB.
Jetzt habe ich eine Frage zur Verwendung des Interrupt bei drei Modulen. Hier habe ich leider im Netz unterschiedliche Angaben gefunden, mal mit Pullup auf der INT Leitung, mal mit verschiedenen Attributen beim Interrupt.

Wie verkabel und konfiguriere ich den INT bei mehreren Modulen richtig?

Danke für eure Hilfe,
Byllyy

Jeder MCP hat einen INT für Bank A und Bank B ... diese müssen entsprechend ausgelesen und verarbeitet werden. OHNE einen genaueren Hinweis was genau an den PORTS hängen solle kann ich nciht sagen, ob die alle 6 INT benötigst oder nicht.

ich gehe mal davon aus, nachdem ich nach Antowrt #40 gesucht habe (ein kurzer Hinweis hätte ja auch ausgrereicht)  hängen die MCPs an einem I2C des PI.

Im Einfachsten Fall benötigst Du drei IOs am PI .. im komplexesten 6 IOs