Modul für die Ansteuerung des MCP23017 I2C Portextender

Begonnen von klausw, 03 Mai 2014, 01:02:40

Vorheriges Thema - Nächstes Thema

timo74

Zitat von: linusd am 18 Mai 2014, 20:54:12
Hallo timo74,

da das von willibauss angesprochene Modul die Pins des RPI zur weiteren Verwendung bereitstellt
und ich in der Beschreibung von den Interrupts nichts gesehen habe, würde ich vermuten das diese auch nicht verdrahtet sind.
Vielleicht habe ich es aber auch nur übersehen!

Richtig. Aber die Idee von Klaus, alle INT-Ausgänge auf einen GPIO zu legen, klingt vielversprechend. Ich glaube, man spricht dann von einem maskierten Interrupt, oder?

Zitat von: linusd am 18 Mai 2014, 20:54:12
Sollen wirklich 128 Module in einer relativen Nähe zum RPI betrieben werden?

Ist halt wirklich relativ. :-). Ich plane (ähnlich wie willibaus) einige Reed-Kontakte und Bewegungsmelder anzuschließen. Dazu sollen später mal noch Rolladen-Steuerungen kommen. Alles in allem komme ich auf ca. 20 Eingänge und 40 Ausgänge. Und da etwas Reserven für die "spontanen Ideen an einem Samstag Vormittag" sicherlich nicht schlecht sind, passt das Modul eigentlich optimal.

Viele Grüße
Timo

linusd

Hi Timo,

was ich meinte ist, ob alle 128 Aktoren/Sensoren auf einer Etage liegen.
Wenn die sich über mehere Etage erstrecken, könnte man sich entwender mit dem Arduino (inkl. Netzer) oder einzelnen RPI's (inkl. FHEM2FHEM) einen dicken Kabelbnaum sparen.  ;)

Eine slebst gelötete Lösung mit dem MCP23017 in der Nähe der Aktoren/Sensoren könnte ebenfalls günstiger sein und via I²C die Anzahl der Leitungen zum RPI klein halten.

Ich plane etwas vergleichbares und komme auch auf >40 Geräte, aber über mehrer Etagen.
In der Kosten-Nutzen-Betrachtung habe ich mich für RPI's in den Etagen entschlossen, da ich Netzwerkkabel verlegt habe.

Gruß
Christian

willybauss

Bei mir sind es ca. 15 Fensterkontakte (Reedkontakte => Eingänge), sowie eine zentrale Licht- und Rollladensteuerung (Peha PHC), ca. 60 Ausgänge. Da muss ich nur zu jedem Lichtschaltereingang einen Relaiskontakt parallel legen, dann kann ich sämtliche Lichter und Rollläden im Haus schalten.

Dadurch, dass ich mit den Relais nur Lichtschalter-Tastendrücke simuliere, geht weiterhin alles über die Logik der PHC => keine "Datenverwirrung" über unqualifizierte Eingriffe in deren Busprotokoll. Mit dieser Lösung ist dann auch der Zugriff z.B. zum "Panikschalter" möglich, d.h. wenn der Homematic-Rauchmelder Alarm signalisiert, kann die PHC (über FHEM informiert) direkt die Fluchtwege frei schalten (Rollläden hoch und Lichter an).
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

volley

@KlausW: Macht es nicht Sinn, die beiden Interrupts A+B per Mirror (Register IOCON (0x0A) , Bit 6=1) zu koppeln, da beim Get sowieso immer beide Ports (A+B) gelesen werden.
Spart eine GPIO Leitung am Raspi pro MCP23017 ohne zusätzliches Löten ;)

linusd

Hallo Willy,

ZitatDa muss ich nur zu jedem Lichtschaltereingang einen Relaiskontakt parallel legen, dann kann ich sämtliche Lichter und Rollläden im Haus schalten.
Liefert Dir die zentrale Licht- und Rollladensteuerung (Peha PHC) den Schaltzustand an den RPI, wenn ein Schalter und nicht das Relais benutzt wurde?

ZitatDadurch, dass ich mit den Relais nur Lichtschalter-Tastendrücke simuliere, geht weiterhin alles über die Logik der PHC => keine "Datenverwirrung" über unqualifizierte Eingriffe in deren Busprotokoll.
Wenn Du kurz vor den Zetrale an die Leitungen gehst ist das I2C 23017 x8 - 128 GPIO Board sicher eine sher gute Lösung.

ZitatMit dieser Lösung ist dann auch der Zugriff z.B. zum "Panikschalter" möglich, d.h. wenn der Homematic-Rauchmelder Alarm signalisiert, kann die PHC (über FHEM informiert) direkt die Fluchtwege frei schalten (Rollläden hoch und Lichter an).
So etwas in der Art habe ich auch vor, aller Ding mit dem RPI und FHEM. 8)

Gruß
Christian

klausw

#35
Zitat von: volley am 22 Mai 2014, 23:36:00
@KlausW: Macht es nicht Sinn, die beiden Interrupts A+B per Mirror (Register IOCON (0x0A) , Bit 6=1) zu koppeln, da beim Get sowieso immer beide Ports (A+B) gelesen werden.
Spart eine GPIO Leitung am Raspi pro MCP23017 ohne zusätzliches Löten ;)
es macht vieles Sinn  8)

ich habe es mal eingebaut ...hoffe es funktioniert

die aktuelle Version ist jetzt im SVN und wird morgen per Update offiziell verteilt
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

willybauss

Zitat von: linusd am 23 Mai 2014, 14:19:59
Hallo Willy,
Liefert Dir die zentrale Licht- und Rollladensteuerung (Peha PHC) den Schaltzustand an den RPI, wenn ein Schalter und nicht das Relais benutzt wurde?
Nein, dazu müsste ich tatsächlich den PHC-Bus "anzapfen". Aber das ist für meine Zwecke nicht soooo wichtig. Mir genügt im Prinzip die Panikschaltung - alle Lichter an, oder die "Alles-Aus" Funktion. Danach ist der Zustand ja klar.
Vielleicht baut ja mal Jemand ein PHC-Modul für FHEM - wundert mich ohnehin, dass es das noch nicht gibt.
Zitat von: linusd am 23 Mai 2014, 14:19:59
Wenn Du kurz vor den Zetrale an die Leitungen gehst ist das I2C 23017 x8 - 128 GPIO Board sicher eine sher gute Lösung.
Meinst Du das hier  ;) ?
Zitat von: willybauss am 15 Mai 2014, 22:51:02
Hallo,


ich verfolge euer Projekt seit einiger Zeit, da ich demnächst was ähnliches brauchen könnte. Wird dieses fhem-Modul denn mit den 128 Ports dieser IO-Karte zurecht kommen? Wenn ja, dann wäre es genau das, was ich brauche, um meine Fensterkontakte zu kontrollieren und Lichter und Rollläden zu steuern.

Gruß

Willy
Zitat von: linusd am 23 Mai 2014, 14:19:59
So etwas in der Art habe ich auch vor, aller Ding mit dem RPI und FHEM. 8)
[confused]
Ich nehme ja auch den RPI und FHEM. Aber allein damit schaltet sich kein Licht und kein Rollladen. Da braucht es schon noch irgendwelche Aktoren - bei mir halt PHC.
[/confused]
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

linusd

ZitatIch nehme ja auch den RPI und FHEM. Aber allein damit schaltet sich kein Licht und kein Rollladen. Da braucht es schon noch irgendwelche Aktoren - bei mir halt PHC.
Nun.. , ich denke das man diese Erkenntins bei Nutzern von FHEM voraussetzten kann! ;)

ZitatDadurch, dass ich mit den Relais nur Lichtschalter-Tastendrücke simuliere, geht weiterhin alles über die Logik der PHC => keine "Datenverwirrung" über unqualifizierte Eingriffe in deren Busprotokoll.
Auf Grund dieser Aussage bin ich davon ausgegangen, dass Du eine entsprechende zentrale Regelung im Einsatz hast und RPI (ink.l FHEM) nur als eine Erweiterung/Fernsteuerung betrachtest.

ZitatMeinst Du das hier  ;) ?
Ich wollte Dir nicht den Eindruck vermittel, dass ich Dein vorgestelltes Modul als meine Idee verkaufe.

(Daher würde ich vorschlagen, dass wir uns in diesem Thread lieber wieder auf das Modul vom Klaus konzentrieren)

thobastian

Hallo !
wie schaut es mit dem MPC23S17 aus ? Ich bin relativ neu hier auf FHEM und habe das Gefühl, dass der mpc23s17 nicht einbindbar ist, oder?
Er wird über SPI angesteuert. Ist der nicht zum I2C ähnlich?

Schöne Grüße

klausw

Zitat von: thobastian am 26 Mai 2014, 15:17:42
wie schaut es mit dem MPC23S17 aus ? Ich bin relativ neu hier auf FHEM und habe das Gefühl, dass der mpc23s17 nicht einbindbar ist, oder?
Er wird über SPI angesteuert. Ist der nicht zum I2C ähnlich?
Sind zwar beides serielle Schnittstellen, aber nicht kompatibel. I2C hat eine bidirektionale Datenleitung und SPI 2 unidirektionale.
Allerdings sind die Registeradressen identisch. Alles was du machen musst, ist ein Modul schreiben das analog zum 00_RPII2C.pm arbeitet.
Dann kannst Du mit diesem Modul auch die SPI Variante ansteuern.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

linusd

#40
Hallo zusammen,

auf Basis des aktuellen Moduls, dass ich mir eben mit "update" geholt habe,  konnte ich meine (Beispiel-)Testkonfiguration erheblich optimieren.
Hierzu einen Dank an Klaus (neben dem Modul selbst) für den Tipp <readingsProxy> zu verwenden, aber auch an volley für seinen Vorschlag der zum Attribut <InterruptOut>
führte!  8)

Diese (Beispiel-)Konfiguration stelle ich Euch gerne nachstehend zur Verfügung:
Zur Erläuterung:

  • Pins: Es werden nur 5 Pins verwendet (VCC, GND, SCL, SDA und Interrupt)
  • Pins: Durch das verwendete Attribut <InterruptOut> genügt es (mit der Option "connected_active-low")  für den Interrupt entweder INTA oder INTB am RPI anzulegen
  • Input: Sensoren wie REED-Kontakte, Bewegungs- und Abstandmelder sind an den Ports A0-A3, A6, A7, B0 und B7 angeschlossen
  • Input: Die Signale der Sensoren an den Ports A1, A2, A7 und B0 werden mit <invert_input> invertiert, da ich z.B. nur ein "on" habe möchte wenn der REED-Kontakt öffnet oder der Bewegungsmelder aktiviert wird
  • Output: Ein 8 Kanal Relais ist an den Ports A4, A5 und B1-B7 angeschlossen, deren Schaltzustände am jeweiligen <readingsProxy> invertiert werden müssen.
    (Ein Invertierung des MCP23017-Ausgangsignals, wie zum Beispiel beim Input mit <invert_input>, ist nicht möglich. Somit hat ein aktiviertes Relais "LED=on" im Reading des Moduls den Zustand "off" )
  • Output: Es wird beim Boot mit <OnStartup> das Relais an A5 deaktiviert und das an B1 aktiviert, die übrigen verharren in ihrer letzten Schaltstellung
  • Output: In dieser Konfiguration bekommen die Schalter im FHEM auch mit, wenn <OnStartup> den Zustand ändert

Nur zum Test hatte ich (ganz bewusst) die Ein- und Ausgänge über die Bänke A und B verteilt. ;)
(Logik habe ich keine eingebaut, da ich nur zeigen möchte wie auf Ein- und Ausgänge zugegriffen werden kann.) 8)


###I2C-Device###
define i2cBus RPII2C 1..
attr i2cBus group MCP23017

###MCP23017-0x20###
define icMCP23017 I2C_MCP23017 0x20
attr icMCP23017 IODev i2cBus
attr icMCP23017 Interrupt A0,A1,A2,A3,A6,A7,B0,B7
attr icMCP23017 InterruptOut connected_active-low
attr icMCP23017 OnStartup A5=on,B1=off
attr icMCP23017 OutputPorts A4,A5,B1,B2,B3,B4,B5,B6
attr icMCP23017 Pullup A0,A1,A2,A3,A6,A7,B0,B7
attr icMCP23017 invert_input A1,A2,A7,B0
attr icMCP23017 group MCP23017

###Interrupt A&B####
define Interrupt RPI_GPIO 4
attr Interrupt active_low yes
attr Interrupt direction input
attr Interrupt interrupt both
attr Interrupt userReadings test {fhem ("get icMCP23017")}
attr Interrupt group MCP23017

###Sensoren (Input)####

#--Bank-A--#
define prxPortA0 readingsProxy icMCP23017:PortA0
attr prxPortA0 group InputPorts
attr prxPortA0 valueFn {($VALUE eq "on")?"off":"on"}

define prxPortA1 readingsProxy icMCP23017:PortA1
attr prxPortA1 group InputPorts
attr prxPortA1 valueFn {($VALUE eq "on")?"off":"on"}

define prxPortA2 readingsProxy icMCP23017:PortA2
attr prxPortA2 group InputPorts
attr prxPortA2 valueFn {($VALUE eq "on")?"off":"on"}

define prxPortA3 readingsProxy icMCP23017:PortA3
attr prxPortA3 group InputPorts
attr prxPortA3 valueFn {($VALUE eq "on")?"off":"on"}

define prxPortA6 readingsProxy icMCP23017:PortA6
attr prxPortA6 group InputPorts
attr prxPortA6 valueFn {($VALUE eq "on")?"off":"on"}

define prxPortA7 readingsProxy icMCP23017:PortA7
attr prxPortA7 group InputPorts
attr prxPortA7 valueFn {($VALUE eq "on")?"off":"on"}

#--Bank-B--#

define prxPortB0 readingsProxy icMCP23017:PortB0
attr prxPortB0 group InputPorts
attr prxPortB0 valueFn {($VALUE eq "on")?"off":"on"}

define prxPortB7 readingsProxy icMCP23017:PortB7
attr prxPortB7 group InputPorts
attr prxPortB7 valueFn {($VALUE eq "on")?"off":"on"}


####Aktoren (Output)####
#---A-Kanal-----

define prxPortA4 readingsProxy icMCP23017:PortA4
attr prxPortA4 group OutputPorts
attr prxPortA4 setFn {($CMD eq "on")?"PortA4 off":"PortA4 on"}
attr prxPortA4 setList on off
attr prxPortA4 valueFn {($VALUE eq "on")?"off":"on"}

define prxPortA5 readingsProxy icMCP23017:PortA5
attr prxPortA5 group OutputPorts
attr prxPortA5 setFn {($CMD eq "on")?"PortA5 off":"PortA5 on"}
attr prxPortA5 setList on off
attr prxPortA5 valueFn {($VALUE eq "on")?"off":"on"}

#---B-Kanal-----

define prxPortB1 readingsProxy icMCP23017:PortB1
attr prxPortB1 group OutputPorts
attr prxPortB1 setFn {($CMD eq "on")?"PortB1 off":"PortB1 on"}
attr prxPortB1 setList on off
attr prxPortB1 valueFn {($VALUE eq "on")?"off":"on"}

define prxPortB2 readingsProxy icMCP23017:PortB2
attr prxPortB2 group OutputPorts
attr prxPortB2 setFn {($CMD eq "on")?"PortB2 off":"PortB2 on"}
attr prxPortB2 setList on off
attr prxPortB2 valueFn {($VALUE eq "on")?"off":"on"}

define prxPortB3 readingsProxy icMCP23017:PortB3
attr prxPortB3 group OutputPorts
attr prxPortB3 setFn {($CMD eq "on")?"PortB3 off":"PortB3 on"}
attr prxPortB3 setList on off
attr prxPortB3 valueFn {($VALUE eq "on")?"off":"on"}

define prxPortB4 readingsProxy icMCP23017:PortB4
attr prxPortB4 group OutputPorts
attr prxPortB4 setFn {($CMD eq "on")?"PortB4 off":"PortB4 on"}
attr prxPortB4 setList on off
attr prxPortB4 valueFn {($VALUE eq "on")?"off":"on"}

define prxPortB5 readingsProxy icMCP23017:PortB5
attr prxPortB5 group OutputPorts
attr prxPortB5 setFn {($CMD eq "on")?"PortB5 off":"PortB5 on"}
attr prxPortB5 setList on off
attr prxPortB5 valueFn {($VALUE eq "on")?"off":"on"}

define prxPortB6 readingsProxy icMCP23017:PortB6
attr prxPortB6 group OutputPorts
attr prxPortB6 setFn {($CMD eq "on")?"PortB6 off":"PortB6 on"}
attr prxPortB6 setList on off
attr prxPortB6 valueFn {($VALUE eq "on")?"off":"on"}


Gruß
Christian

thobastian

Zitat von: klausw am 27 Mai 2014, 14:40:03
Sind zwar beides serielle Schnittstellen, aber nicht kompatibel. I2C hat eine bidirektionale Datenleitung und SPI 2 unidirektionale.
Allerdings sind die Registeradressen identisch. Alles was du machen musst, ist ein Modul schreiben das analog zum 00_RPII2C.pm arbeitet.
Dann kannst Du mit diesem Modul auch die SPI Variante ansteuern.
Ich habe mir Dein Modul angeschaut. Keine Chance. Das ist für mich viel zu schwierig. Gibt es hier nicht jemand, der daran interessiert ist ? Ich frage deshalb, weil mich das Konzept von FHEM überzeugt hat. Ich würde gerne eine FHEM Installation aufsetzen.Nur dazu benötige ich ein Modul für den SPI.

klausw

Zitat von: thobastian am 28 Mai 2014, 16:10:31
Ich habe mir Dein Modul angeschaut. Keine Chance. Das ist für mich viel zu schwierig. Gibt es hier nicht jemand, der daran interessiert ist ? Ich frage deshalb, weil mich das Konzept von FHEM überzeugt hat. Ich würde gerne eine FHEM Installation aufsetzen.Nur dazu benötige ich ein Modul für den SPI.
Die einfachste Lösung wäre, den MPC23S17 durch einen MPC23017 zu ersetzen ;)
Dann noch die Steuerleitungen anpassen und fertig. Ist halt ein bisschen Lötarbeit.

In Perl kommt man, besonders durch die Hilfe hier im Forum recht schnell rein (ich habe auch erst vor nem halben Jahr damit angefangen)
Das Modul umzustricken ist das kleinste Problem. Du musst ja nur den Hardwareteil ändern. Das ist nicht viel.
Das größere Problem ist es, eine passende Perl Bibliothek für den SPI Zugriff zu finden.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

IPPhoner2b

#43
Hallo Klaus,
nur mal ne Frage, kann es sein, dass mit dem Befehl "Active_low" bzw. "Active-low" was gemacht wurde?

Gibt da immer ne Fehlermeldung raus, habe den Text jetzt umbenannt, war allerdings vorher nicht so.
Bei Gelegenheit sonst bitte wieder zurückändern.


Komischerweise lief es auf einmal wieder, wie es vorher auch war, keine Ahnung was das jetzt war, habe von "_" auf "-" geändert, und dann wieder auf "_" zurück, und jetzt funktioniert es wieder  :o

Gruß
Chris

klausw

Hallo Chris,

Zitat von: IPPhoner2b am 30 Mai 2014, 19:58:21
nur mal ne Frage, kann es sein, dass mit dem Befehl "Active_low" bzw. "Active-low" was gemacht wurde?

Gibt da immer ne Fehlermeldung raus, habe den Text jetzt umbenannt, war allerdings vorher nicht so.
Bei Gelegenheit sonst bitte wieder zurückändern.


Komischerweise lief es auf einmal wieder, wie es vorher auch war, keine Ahnung was das jetzt war, habe von "_" auf "-" geändert, und dann wieder auf "_" zurück, und jetzt funktioniert es wieder  :o
Active_low heisst inzwischen invert_input. Hatte ich vergessen hier zu schreiben, aber im Commandref sollte es stimmen. Active_low war irreführend, da nur Input Pins invertiert werden können.

Grüße
Klaus
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280