Hi zusammen, ich hatte mit überlegt die anstehende Hausautomatisierung mit einem Raspberry Pi zu realisieren, da dieser von der Leistung her für meine Belange optimal erscheint. Alle schaltbaren Leitungen gehen bei mir sternförmig vom Schaltschrank aus und werden mittels Stromstoßrelais (12 V) geschaltet. Derzeit werden diese von diversen Tastern und Bewegungsmeldern angesteuert. Gibt es eine sinnvolle Möglichkeit diese rund 50 Relais und 70 Taster mit dem Raspberry zu verbinden? z.B. per USB I/O-Expander oder per I²C? Ich habe bislang nichts gefunden, was für diese Größenordnung geeignet wäre. Danke und schöne Grüße, Kai
Autsch... Na, wenn es denn unbedingt sein muss... Ich würde vom USB abraten, da zusätzliche Fehlerquelle (gibt hier ja eh schon genug durch Betriebssystem usw.). Also eine Ladung 8-bit-I/O-Expander für den I²C (z. B. PCF8574 und PCF8574A kombinieren, dann reicht die Anzahl I/Os - oder mit Expandern o. ä. arbeiten) und eine Handvoll Treiber (z. B. ULN2803). Zusätzlich würde ich mir über weitere Absicherungsmaßnahmen Gedanken machen, z. B. einen externen Watchdog (sofern der RPi keinen on board hat, was ich gerade nicht weiß, aber wovon ich nicht ausgehe).
i2c-Expander mit sehr vielen Pins gibts von cypress.com
Ups - habe gerade nochmal vom Schaltschrank abgezählt - ist doch noch was mehr: Ich benötige anscheinend rund 120 Eingänge (Flankenerkennung) und 62 Ausgänge (Relaistreiber) Patrick schrieb: > Autsch... > > Na, wenn es denn unbedingt sein muss... Klingt, als hättest du eine bessere Idee? Ich habe das mit I²C trotz mehrmaligem Anlauf nicht ganz verstanden: Können die angeschlossenen Geräte mitteilen "Taste 3 wurde gedrückt", ohne dass der Master pollen muss? USB hätte den Vorteil gehabt (sofern existent), dass ich eine fertige Lösung einfach nur anschließen muss. Ich sehe da keine zusätzliche Fehlerquelle. Ich hatte spaßeshalber schonmal überlegt eine USB-Tastatur umzufunktionieren :)
Kai Giebeler schrieb: > Ups - habe gerade nochmal vom Schaltschrank abgezählt - ist doch noch > was mehr: Ich benötige anscheinend rund 120 Eingänge (Flankenerkennung) > und 62 Ausgänge (Relaistreiber) > > Patrick schrieb: >> Autsch... >> >> Na, wenn es denn unbedingt sein muss... > > Klingt, als hättest du eine bessere Idee? > > Ich habe das mit I²C trotz mehrmaligem Anlauf nicht ganz verstanden: > Können die angeschlossenen Geräte mitteilen "Taste 3 wurde gedrückt", > ohne dass der Master pollen muss? negativ. USB: Imho zu kompliziert und sch## zu debuggen. Bei I2C reicht ein 2-Kanal-Oskar oder LA.
Informiere Dich mal über den Eltako 485er Bus. Das könnte eine Lösung sein: http://www.eltako.com/fileadmin/downloads/de/nachrichten/EltakoNachrichten_FTS092009.pdf
Also was auf der Basis von RS-485 wäre schon sinnvoll, das ist Technik die prinzipiell sogar funktionieren könnte. Und der Raspberry Pi hat auch die notwendige serielle Schnittstelle dafür. Du brauchst da also nur noch einen Pegelwandler. Das große Problem bei solchen Fertigrelais ist, das Protokoll herauszufinden. Eltako hat zumindest anscheindend das Funkprotokoll offengelegt. Vermutlich sprechen die dann auf RS-485 was ganz ähnliches. Aber RS-485 kann man trivial einfach abhören, somit sollte das Problem so oder so lösbar sein.
Das RS485 Protokoll von Eltako ist inzwischen schon recht gut bekannt. Die Informationen sind allerdings über viele Dokumente verstreut. Anbei eine aus meiner Sicht gute Zusammenfassung. Setzte selber die RS485 Dimmer von Eltako (FUD12NPN) ein, funktioniert problemlos.
Das Problem ist es gibt keine Flow Controll Pins also kann keine RS485 verwenden werden. Es geht nur über einen Umweg über einen Ftdi am USB Port.
Falls Du mit Flow Controll Pins die RE/DE Pins am Tranceiver meinst, man kommt auch ohne die aus, da die Eltakos nur empfangen und nicht senden.
Will man senden, kostet es einen Max, will man auch zuhören, noch Einen. Können von der Richtung her, fest verdrahtet sein. Hallo Thomas, hast Du schon die 14er Version, bzw Erfahrungen mit dem neuen Protokoll? Gruß Helmut
> hast Du schon die 14er Version, bzw Erfahrungen mit dem neuen Protokoll?
bisher noch nicht
Erstmal danke für die vielen Rückmeldungen! Die RS485-Module von Eltako sehen schon reizvoll aus. Anscheinend muss man aber die Taster in 10er-Gruppen zusammenfassen. Den Platz für die zusätzlichen Module habe ich leider nicht und der Aufwand 13 Busse zu verwalten finde ich auch nicht ohne (Zumindest verstehe ich die Doku so). Zudem bringen mir die Module zu viel Eigenlogik mit, die ich nicht benötige. Und ich vermute mal, dass ich den aktuellen Schaltzustand für die Schalter nicht abfragen kann? Ich habe nochmal über I²C nachgedacht: Zum Einen habe ich das Problem, dass recht viele Eingänge gepollt werden müssen und dass der Raspberry Pi nicht ohne Weiteres Interrupts entgegennehmen kann. Geschweige denn einer Unterstützung für Java ohne größere Krücken. Das RS485 hat mich auf die Idee gebracht einen ATMega per RS232 mit dem Raspberry zu verbinden und mit diesem dann per I²C die I/O-Expander anzusteuern (sofern diese ausreichen Adresswahl bieten :/). Der AVR kann alle Input-Expander pollen (Latenz müsste ich noch durchrechnen, aber ich denke das geht) und die Ergebnisse per RS232 an den Raspberry Pi schicken. Auf dem Pi kann dann ganz klassischer Code den COM-Port abfragen und sogar Interrupts auslösen. Also:
1 | RPi <-RS232-> ATMega <-I²C-> I/O-Expander <-> Relais-Treiber |
Das ließe sich gut debuggen, modular aufbauen, wäre bezahlbar und überfordert mein Know-How nicht unnötig :) Wäre das eine sinnvolle Lösung?
Für so eine Spielerei hat i2c mehr als genug Bandbreite. Dein AVR müßte ja sonst nichts mehr machen. 100kbit/sec. kann jeder i2c-Baustein. Du könntest also mehrere tausend Pins pro Sekunde mehrfach abfragen. Im AVR dann per Tabelle die Differenz bilden und schon hast du die Änderungen.
Hi! Mit einem externen Atmega wäre der MCP23S17 auch geeignet. 16 IOs pro IC, durch Adressen bis zu 8 Stück an einem CS. Gruss, Micha
>Im AVR dann per Tabelle die >Differenz bilden und schon hast du die Änderungen. naja, entprellen müsste man schon auch noch.. das könnt er auch gleich mit erledigen.. achso nachtrag: KNX wäre in summe günstiger, das will aber wohl keiner hören ;-)...
Micha ... schrieb: > Mit einem externen Atmega wäre der MCP23S17 auch geeignet. > 16 IOs pro IC, durch Adressen bis zu 8 Stück an einem CS. Ich Doof habe das Chip-Select voll vergessen, danke. Der MCP23S17 gefällt mir sehr gut! Robert L. schrieb: > naja, entprellen müsste man schon auch noch.. > > das könnt er auch gleich mit erledigen.. Ich denke, das werde ich altmodisch in Hardware machen. Um 120 Eingänge hinter den I/O-Expandern gleichzeitig zu entprellen muss ich schon tief in die Trickkiste greifen. Da kann der ATmega sich lieber um einen Failsafe und/oder einen Watchdog für den Raspberry kümmern. Dann gehen die wichtigsten Funktionen auch bei einem Systemausfall noch. > achso nachtrag: KNX wäre in summe günstiger, das will aber wohl keiner > hören ;-)... Ich höre es gerne, wenn etwas günstiger wird und dennoch was taugt - da ich aber eine bestehende funktionierende Sternverkabelung habe, kann ich mir nicht vorstellen, wie mir KNX da helfen kann. Schöne Grüße, Kai
>kann ich >mir nicht vorstellen, wie mir KNX da helfen kann. versteh ich nicht? Aktoren sind bei KNX "üblicherweise" sowieso zentral die eingänge machst dann über den ABB Konzentrator steuern würd ich es über loxone.. (also 4x konzentrator, 4x 16fach aktor, 1x loxone, 2x stromversorgung) kostet in summe ca. 3500€ (die hardware) dafür hat man dann was gescheites, wo man weiß dass es funktioniert, was einm in 20 jahren noch jemand (auch externer) erweitern kann und man hat viel zeit gespart .. aber: ich hab überlesen, dass du schon fertig bist, (also es nicht um einen neubau geht), du also genügend zeit hast, zum basteln, usw. wenn also "der weg, das ziel ist" (und das ziel nie erreicht werden muss) dann: frohes basteln...
Du könntest auch über Modbus TCP/UDP deine I/Os anbinden. Das Protokoll ist ziemlich einfach und gut dokumentiert. Modbus Koppler könnte ein Wago 750-352 sein. Daran gesteckt die entsprechenden Eingabebaugruppen 750-1406. http://www.wago.com/wagoweb/documentation/750/ger_dat/d07500352_00000000_0de.pdf http://www.wago.com/wagoweb/documentation/750/ger_dat/d07501405_00000000_0de.pdf Gruß Stephen
Kai Giebeler schrieb: > Gibt es eine sinnvolle Möglichkeit diese rund 50 Relais und > 70 Taster mit dem Raspberry zu verbinden? z.B. per USB I/O-Expander > oder per I²C? Möglichkeit 1: CAN Der CAN-Bus ist ähnlich wie RS485 ein differentieller Bus, aber die Controller haben viel mehr Eigenintelligenz, d.h. sie machen vieles selber, was Du bei RS485 selber nachprogrammieren musst. Als Controller für die Peripherieknoten empfehle ich PIC18F26K80 oder PIC24HJ64GP502. Die haben in 28 Pins alles, was Du brauchst, zusätzlich ist nur noch ein CAN-Transceiver (8-Pinner im SO08) erforderlich. Möglichkeit 2: Ethernet und TCP/IP Hier empfehle ich einen PIC18F67J60. Das ist eine Single-Chip-Lösung, die Prozessor, Ethernet-Controller und Ethernet-PHY auf einem einzigen Chip vereinigt. Es geht nicht billiger, und die Rechenleistung des PICs recht zum Schalten von Geräten völlig aus. fchk
Stephen schrieb: > Du könntest auch über Modbus TCP/UDP deine I/Os anbinden. Das Protokoll > ist ziemlich einfach und gut dokumentiert. > > Modbus Koppler könnte ein Wago 750-352 sein. Daran gesteckt die > entsprechenden Eingabebaugruppen 750-1406. > > http://www.wago.com/wagoweb/documentation/750/ger_... > > http://www.wago.com/wagoweb/documentation/750/ger_... > > Gruß Stephen Absolut! Ich bin nicht mit Wago verheiratet (recht teuer), aber die 750er I/Os in Kombi mit dem 750-342 Modbus/Tcp-controller sind einfach geil. Einfach zu programmieren (in meinem Fall ca. 50 Zeilen Python für AI, DI, DO), sehr kompakt, Hutschiene, Standard 24V DC, Anbindung mit Ethernet, Module einfach wie Lego zusammenklicken. Meine habe ich gebraucht bei ebay gekauft. Die digitalen IOs sind recht günstig. Die meisten Modbus/TCP-controller haben auch rudimentäre Webserver für monitoring und/oder Konfiguration integriert. Allerdings sollte man diese Dinger aus gewissen Gründen in einem gut gesicherten Netz betreiben ;-) Nebenbei gibt's auch Module von Beckhoff, Advantech (hab' ich auch schon getestet), Modicon, etc. Reine Geschmacks/Geldfrage. Beim raspi nutzt man einfach den Netzwerkanschluss, über sockets implementiert man dann das (simple und offene) Modbus-Protokoll. Vorteil im Gegensatz zur Nutzung von shift-Registern mit spi oder i2c sind elektrische Sicherheit ;-), Simplizität, nix löten, große Leitungslängen (Ethernet), störsicher. Nachteil ist der Preis ... Ein Zwischending wären hier die Platinen von Horter (horter.de). Da gibt's optogekoppelte (oder Relais) I/O auf Basis des schon oben erwähnten PCF8574 (I2C). Hab ich auch schon getestet, flutscht. Aber I2C zu programmieren ist ein Krampf im Vergleich zu Modbus. In der Summe, für eine Hausverdrahtung, würde ich aber trotzdem auf jeden Fall Modbus TCP nehmen (was sollte Modbus RS485 besser können?). So, es ist wohl Zeit mich endlich mal zu registrieren ..... Gruß aus Mainz, Philipp.
Hi Kai, Kai Giebeler schrieb: > Ich habe nochmal über I²C nachgedacht: Zum Einen habe ich das Problem, > dass recht viele Eingänge gepollt werden müssen und dass der Raspberry > Pi nicht ohne Weiteres Interrupts entgegennehmen kann. Mit der Standard-"Wheezy" von Raspbian soll er das können, sagt jedenfalls http://elinux.org/RPi_Low-level_peripherals . Ich habe das zwar noch nicht getestet, könnte mir aber vorstellen, daß man in /sys/class/gpio/gpio<pin>/uevent ein Programm oder Skript eintragen kann, das bei einem Interrupt aufgerufen wird, wenn sys.../edge auftritt. Mit sys.../active_low kann vermutlich ein Pull-Up-Widerstand ein- oder ausgeschaltet werden. Das wäre jedenfalls als Interface ziemlich Linux-ig -- man müßte halt mal ein wenig damit herumspielen, um es zu verifizieren. ;-) > Das RS485 hat mich auf die Idee gebracht einen ATMega per RS232 mit dem > Raspberry zu verbinden und mit diesem dann per I²C die I/O-Expander > anzusteuern (sofern diese ausreichen Adresswahl bieten :/). Der AVR kann > alle Input-Expander pollen (Latenz müsste ich noch durchrechnen, aber > ich denke das geht) und die Ergebnisse per RS232 an den Raspberry Pi > schicken. Auf dem Pi kann dann ganz klassischer Code den COM-Port > abfragen und sogar Interrupts auslösen. > > Also:RPi <-RS232-> ATMega <-I²C-> I/O-Expander <-> Relais-Treiber Wozu dann die I²C-Expander? Wenn da eh ein ATMega dazwischen ist, kannst Du doch auch ganz billige Schieberegister 74*595 und 74*165 nehmen -- so ein 74HC595 im DIP-Gehäuse kostet beim großen F ab zehn Stück gerade mal 23, und ein 74HC165 27 Eurocent. Also: RasPi <- I²C -> ATMega <-> Schieberegister <-> Relaistreiber Der ATMega hechelt dann die Inputs durch und meldet Änderungen daran an den RasPi mit einer Interrupt-Leitung, der RasPi zieht sich dann die Werte über RS-232 oder I²C -- oder der Mega wird gleich der Master. Wenn alles so klappt, wie ich mir das vorstelle, sollte ein Tastendruck jedenfalls in < 5 ms beim RasPi ankommen. An dieser Stelle könnte man sich noch viele spannende Sachen ausdenken. Zum Beispiel: das Ganze auf dem RasPi mit PostgreSQL-Notifications und PostgreSQL-Triggern machen und die Daten gleich aufzeichnen, vielleicht noch ein Django-Frontend draufsetzen und einen Touchscreen an den RasPi klemmen... oder direkt einen zweiten RasPi einplanen und das Ganze mit High Availability aufsetzen, oder den ATMega einen Teil der Schalterei durchführen lassen... ;-) HTH, Klaus
Danke für die Ergänzungen und Anregungen. Da sind ja doch einige Optionen bei, aus denen sich was machen lassen müsste!
Wir haben diversen Code für die Ansteuerung der I/O-Module von Beckhoff erstellt. Das geht je nach Wunsch über RS232, RS485 oder Ethernet. Das Grundkonzept sieht einen sog. Buskoppler vor, an welchen dann auf der Hutschiene die I/O-Module angeschlossen werden (rasten zusammen). Es gibt endlos solche Module für digital und analog, rein und raus ... alles industriell, also ggf. potentialgetrennt, etc. Wir steuern diese Buskoppler von Kameras mit eingebauten DSPs aus an ... Falls von Interesse ... (Muß zugeben, daß ich den Thread nicht vollständig durchgelesen habe, also nicht sauer sein, falls ich 'ne wichtige Bedingung nicht erfaßt habe.)
Philipp Braunbeck schrieb: > Nebenbei gibt's auch Module von Beckhoff, Advantech (hab' ich auch schon > getestet), Modicon, etc. Reine Geschmacks/Geldfrage. Oben nennst du Wago teuer, was ist denn günstiger und immernoch gut verwendbar? bzw was sind denn gute Preise für z.b. wago?
Hallo, ich habe das gleiche Projekt auf meinem Zeitplan. Meine Überlegungen sind zur Zeit den Raspberry als zentrale Einheit zu nutzen. Und jede Menge ATtinys als Relais oder IO Karten. Da ich keine großen Signalwege habe bin ich für I2C zu den Tinys. Ich überlege mir, einen externen Interruptcontroller aufzubauen. Die Tinys könnten dann einen Interrupt an den Controller melden. Dieser dann eine gesammelten an den Raspberry. Vorteil wäre, dass ich schnell herausbekomme welcher Busteilnehmer den Interrupt verursacht hat. Ich habe aber auch mal gelesen, dass der Raspberry (Debian) mittlerweile einen Interrupt bei Änderungen an den GPIOs auslösen kann. Die ganze Architecktur soll so aussehen, dass ich die Relaiskarten durch Adresswahljumper gegeneinader tauschen kann. Mein Problem: Die Zeit ;-)
Es gibt bei i2c traditionell nur eine einzige Rückmeldeleitung für Ereignisse. Der Bus war ja mal für eine eher einfache Busstruktur in Geräten der Unterhaltungstechnik vorgesehen. Da gabs dann vielleicht 10 Chips mit Busanschluß insgesamt und 3 von denen mußten irgendwas melden... Es hindert dich aber niemand daran, im Multi-Master-Mode von intelligenten I/O-Chips aus Ereignisse an den Cheffe zu schicken. Intelligente selbstprogrammierte Slaves sind bei den doch relativ hohen Preisen für viele Standard i2c-Chips sowieso eine interessante Option. Wie ich schon schrieb: Die I/O-Expander von Cypress sind relativ vielpinnig.
Nettes Thema ;-) ich bin auch am Überlegen ob mein RPi in den Schaltschrank wandern soll und bin grad am überlegen wie ich meine Inputs erhöhe. Unabhängig davon habe ich hier ein Interesanntes Projekt. Damit kann man die I/Os per REST API schalten und abfragen. Ist gut dokumentiert und kann mit JS, PHP oder Pyton individuell angepasst werden.Webiopi: http://code.google.com/p/webiopi/wiki/RESTAPI
Falls du noch nichts gefunden hast. Ich hab mir den MCP 23S17-E/SP bestellt. Das ist ein SPI I/O Expander mit 16 i/o's à 25mA. Du kannst dann am Raspberry 2^3 = 8 Portexpander dranhängen und dadurch 8*16 I/O's (sprich 128) steuern. Der ist zukünftig auch mit webiopi kompatibel, welches Zukünftig auch out-of-the-box Sensoren unterstützen wird. Falls du lieber i2c verwenden möchtest wäre der MCP 23S017 vielleicht was für dich. Grüße Lu
Hallo Lu, wirst du die I/O-Expander direkt an den Raspberry klemmen oder auch über ein Atmega gehen, wie weiter oben beschrieben? Mir ist der Vorteil mit dem Atmega nicht klar (bin Anfänger). Bin auf das super Tutorial von Erik Bartmann gestoßen: http://erik-bartmann.de//download/PiMeUp_MCP23S17_Teil%202.pdf und dachte mir, dass ich meine Rollo-Steuerung somit sehr einfach aufbauen kann. Die Steuerung soll 34 Taster und 17 Motoren (auf, ab) unterstützen. D.h. meine Komponenten-Liste sieht wie folgt aus - 1x RaspberryPI - 6x MCP 23S17-E/SP (3x für Intput (Taster), 3x Output (Relasis)) Somit habe ich die Möglichkeit bis zu 48 Tasten abzufragen und bis zu 48 Relais zu steuern. Wie sieht denn so eine Tastenentprellung und eine Relais-Treiberstufe am MCP2317 aus? Sind die o.g. Überlegungen zu naiv? Muss ich noch auf weitere Besonderheiten achten? Was meint Ihr dazu? Viele Grüße Olaf
Schön, dass ich nicht der Einzige bin :) Wie soll der Pi mitbekommen, dass Tasten gedrückt wurden ohne zu pollen? Deswegen hatte ich den ATMega dazwischen in Erwägung gezogen; der kann das Pollen der I/O-Expander übernehmen. Mit einer Anbindung per RS232 werden auf beiden Seiten Interrupts ausgelöst. Gruß, Kai
Hi Kai, man kann doch die Tasten per Endlosschleife abfragen (siehe Beispiel von Erik Bartmann). Das ganze in einen eigenen Thread ausgelagert und gut !? Im ATMega wird doch auch nur eine Endlosschleife programmiert und das Ergebniss dann in ein RS232-Protokoll übersetzt. Ich denke die Geschwindigkeit um alle Tasten abzufragen sollte nicht das Problem sein oder ist das der Grund wieso du auf eine "aktive" Benachrichtigung per Interrupt zurück greifst? Wieso also weitere Bausteine mit aufnehmen die gekauft, verdrahtet und programmiert werden müssen ;-) ? In einem oberen Beitrag schreibst Du: "...Zum Einen habe ich das Problem, dass recht viele Eingänge gepollt werden müssen und dass der Raspberry Pi nicht ohne Weiteres Interrupts entgegennehmen kann. Geschweige denn einer Unterstützung für Java ohne größere Krücken...." Da ich beruflich viel mit Java programmiere, wollte ich die Steuerung auch in Java realisieren. Was meinst Du mit "ohne größere Krücken"? Welche Einschränkungen gibt es wenn man Java als Programmiersprache verwendet? Viele Grüße, Olaf
Hi Olaf, bei der Abfrage der seriellen Schnittstellen kann ich auf eine der vielen verfügbaren Lösungen zurückgreifen. Bei SPI (o.A.) habe ich keine Erfahrung, wie das mit Java realisiert werden soll. Oder lässt sich das einfach per FileChannel auf das Device erledigen? Muss eine SPI-Schnittstelle konfiguriert werden (Wie z.B. die Baud-Rate, Parität, Stop-Bits, etc. bei der seriellen?); wenn ja, wie geht das? Die serielle Schnittstelle hat den Vorteil, dass wenn mal Not am Mann ist (oder auch zu Test- und Entwicklungszwecken) auch einfach ein Notebook angeschlossen werden kann. Ich muss rund 100 Eingänge abfragen, wovon rund 60 etwa 20 Mal pro Sekunde gepollt werden müssten. Das sind 1200 Abfragen pro Sekunde. Ich weiß nicht, ob der Pi das auch unter mittlerer Last Jitter"frei" hinbekommt. Der AtMega ist ja nahezu echtzeitfähig. Ein wenig mag das auch persönlicher Geschmack sein :) Schöne Grüße, Kai
Klaus Maus schrieb: > Mit der Standard-"Wheezy" von Raspbian soll er das können, sagt > jedenfalls http://elinux.org/RPi_Low-level_peripherals . Ich habe das > zwar noch nicht getestet, könnte mir aber vorstellen, daß man in > /sys/class/gpio/gpio<pin>/uevent ein Programm oder Skript eintragen > kann, das bei einem Interrupt aufgerufen wird, wenn sys.../edge > auftritt. Mit sys.../active_low kann vermutlich ein Pull-Up-Widerstand > ein- oder ausgeschaltet werden. Nein, das was man in "edge" eingetragen hat, lässt einen poll syscall aufwachen, der darauf wartet, dass die "value" Datei POLLPRI signalisiert, bzw. einen select syscall, der die "value" Datei im dritten fd_set hat. "active_low" ist nur syntactic sugar und kehrt überall die Bedeutung von high und low um. Für Pull-Up/Down gibt es AFAIK keine Userspace API. Mit "uevent" kann man nix sinnvolles machen. Denk an udev und du hast eine Ahnung davon wozu die Datei gut ist.
> mit EINEM > Raspberry Pi zu realisieren Eine Abfrage von vielen Zuständen über EINEN: Das heißt auch, daß alles finster ist, falls ein Fehler vorliegt oder der Blitz einschlägt? Wollt Ihr das wirklich?
Mit dem MCP23S17 als IO-expander kann man das Polling erheblich reduzieren wenn NUR seine Interruptausgänge periodisch abgefragt werden. Etwa so - Hey, der MSP23S17 hat seinen Interruptausgang auf High gesetzt, da schaun wir gleich nach was auf seinen IO-pins los ist.
oszi40 schrieb: >> mit EINEM >> Raspberry Pi zu realisieren > > Eine Abfrage von vielen Zuständen über EINEN: Das heißt auch, daß alles > finster ist, falls ein Fehler vorliegt oder der Blitz einschlägt? Wollt > Ihr das wirklich? Hindert einen doch niemand daran noch ein/zwei in der Schublade zu haben. Wenn noch ein Controller dazwischen ist kann der auch einen Notfallplan übernehmen. Licht an/aus schafft der locker. Den Controller dann in einen Sockel und dann kann man den zur Not auch tauschen. raspi schrieb > Mit dem MCP23S17 als IO-expander kann man das Polling erheblich > reduzieren wenn NUR seine Interruptausgänge periodisch abgefragt werden. > Etwa so - Hey, der MSP23S17 hat seinen Interruptausgang auf High > gesetzt, da schaun wir gleich nach was auf seinen IO-pins los ist. Wenn ich das mit dem ATmega umsetze würde der auf jeden Fall auf die Interrupts lauschen - da muss dann sogar gar nicht mehr gepollt werden. Der Pi müsste dann per eine Handvoll GPIOs dafür einsetzen da man die Interruptausgänge per I²C oder SPI meines Wissens nach nicht abfragen kann? ... je länger ich darüber nachdenke desto blöder erscheint mir das. Interrupts zu pollen statt einfach die neuen Werte einzulesen bringt ja gar keinen Mehrwert. Die von mir oben angegebene Rate ist viel zu hoch angesetzt - man liest die Tastenkonfiguration ja nicht Bit für Bit aus.
Ich bin auch gerade am experimentieren mit einem RPi für die Hausautomation. Die Wahl viel im Moment auf den MPC23017-E/SP für I/O, ein erster Test verlief positiv. Da (zumindest meiner Recherche nach) der RPi seine GPIO für Interrupts verwenden kann war die Idee, den Interrupt des MPC23017 auf den RPi zu führen - leider hatte ich noch keine Zeit dies zu testen. Als Relais habe ich ein F40527-05 ins Auge gefasst, aus folgenden Gründen: 1. Es gibt Sockel für die Hut-Schiene 2. mit dem Wechsler kann ich das Verhalten im stromlosen Zustand definieren (falls der RPi ausfällt) 3. Sofern der MPC23017 mit einer eigenen Spannungsversorgung (5V) versehen wird reicht dies um die Relais zu schalten
>Hausautomation
gibts da überhaupt vernünftige software für linux
oder muss man sich dass dann auch selber schreiben..
Aus technischer Sicht ist das hier ja recht interessant aber hat das mal jemand aus finanzieller Sicht betrachtet? Wieviel Geld habt ihr denn mit euren Systemen im Gegensatz zu KNX oder sonstigen Systemen gespart? Ich habe vor in den nächsten 3 Jahren zu bauen und hätte auch viel Spaß an einer Hausautomatisierung. Bekannte haben KNX Systeme im Einsatz aber da schreckt mich halt etwas der Preis ab, dafür weiss man aber, dass es funktioniert. Ein eigenes System wäre natürlich total cool aber auch halt etwas unsicher.
Kostentechnisch habe ich es noch nicht bis ins Detail kalkuliert, aber die Komponenten die ich bisher verglichen habe kosten ca. 10% bis 30% von der äquivalenten EIB/KNX-Lösung. Einen großen Vorteil sehe ich auch daran, dass nahezu alles integriert werden kann, auch Geräte/Module es im Bereich EIB/KNX nicht gibt. Wenn die Entwicklung mit eingerechnet wird rechnet sich das (zumindest als Lösung für einen Haushalt) nicht, aber ich denke diese Zeit wird hier bei den meisten als Hobby verbucht. Klar kann ich es fertig kaufen, aber dann entgeht mir der Spass das selbst zu bauen! BTW: Falls jemand Interesse hat das Projekt "Hausbus mit RPi" im Team zu entwickeln, würde ich mich freuen und gerne nach zeitlicher Verfügbarkeit beteiligen. Mein Know-How liegt vorwiegend im Bereich der SW und GUI, die HW habe ich inzwischen zwar dank der vielen RPi-Beispiele im Netz hinbekommen, aber da ist noch viel Platz für eine professionellere Lösung... und bis das Ganze von der Experimentierplatine auf dem Schreibtisch in den Verteilerkasten wandert ist noch ein weiter Weg :)
Hallo! Ich baue gerade etwas ähnliches und möchte OpenHAB(Java) auf RasberryPi einsetzen. Als Hausbus werde ich warscheinlich CAN einsetzen, weil I2C für größere Entfernungen nicht so geeignet ist. Mir geht es hauptsächlich auch um die Steuerung von Jalousien. Ich werde also ein CAN Binding für OpenHAB bauen und dann im Schaltschrank mehrere PIC Microcontroller mit Relaiskarten haben. vg Jürgen
Hi Marius, ich beschäftige mich auch gerade mit dem Thema Hausbus mit RPi. Wir bauen dieses Jahr und ich möchte mein RPi für die Hausautomatisierung einsetzen. Ob das nun sinnvoll ist, oder nicht, sei mal dahin gestellt. ;-) RPi und Interesse sind vorhanden. Know-How in der Softwareentwicklung und Elektronik ebenfalls. Allerdings stehe ich noch ganz am Anfang... Falls Du also Lust auf einen Austausch hast... ich bin dabei! Viele Grüße Jens
Hallo Jens, ich bin Momentan auch noch an der Findung des Grunddesigns für das Projekt und experimentiere fleißig herum... Ich habe für den Ideenaustausch ein kleines Wiki angelegt (im Moment noch leer, wartet aber daruf gefüttert zu werden): http://hausbus.ccmmss.de/ Bei Interesse bezüglich der Zugangsdaten bitte einfach kurze Mail an mm(at)ggoo.de (gilt auch für alle anderen die Interesse haben mitzubasteln!) Vg Marius
Ist es nicht ziemlich sinnlos, mit dem Raspi die Taster abzufragen und daraufhin die Relais zu betätigen, um dasselbe zu tun, was bisher die Taster erledigt haben? Was ist damit gewonnen ? Verloren ist die Betriebssicherheit, wenn der Raspi mal ausfällt. Lass die Taster doch einfach direkt dran an den Stromstoßrelais und gib dem Raspi zusätzlich die Möglichkeit umzuschalten. Mit den vielen Eingängen fragt doch lieber die Schaltzustände der Lampen und sonstigen Geräte ab. Dann kann man sehen welche Lampen angeschaltet sind und mit einem Stromstoß in den gewünschten Zustand bringen. Zum Beispiel abends alle Lampen ausschalten,die nicht anbleiben sollen. Oder bestimmte Lampen nach einer gewissen Zeit wieder abschalten. Oder ein Zufallsbeleuchtungsprogramm für den Urlaub. Nebenbei gibt es die Möglichkeit aufzuzeichnen, welche Lampen wie lange brennen.
Ausfallsicherheit ist natürlich schlechter. Das ist ganz klar. Wenn du aber die Taster mit dem RasPi abfrägst kannst du Szenen programmieren - so in Richtung EIB-KNX. Auch eine eine nette Spielerei wäre z.B. Dimmung über einen Taster - taste kurz an/aus länger dimmen
Ich kann mir die Szenen schon vorstellen, wenn das ganze Haus dunkel bleibt, weil am Raspi oder der sonstigen Steuerung etwas ausgefallen ist, inklusive der Szenen von Ehefrau und Kindern. Oder was meinst du für Szenen? Warum soll der Raspi das Dimmen übernehmen, wenn man die Dimmer auch direkt mit den Tasten bedienen kann? Mit einem Relais parallel zum Taster kann der Raspi natürlich auch dimmen, das macht aber nur Sinn, wenn er auch eine Rückmeldung vom Zustand des Dimmers bekommt und das ist schon nicht mehr so einfach.
Hallo! Ich interessiere mich ebenfalls, auf Basis von http://erik-bartmann.de//download/PiMeUp_MCP23S17_Teil%202.pdf bis zu 8*16 IO-Ports am Raspberry PI zu betreiben. Ich habe auch das EBook des Autoren gekauft, die Schaltung ist aber die gleiche. Er stellt es (evtl. auch auf seiner Webseite zum kostenlosen Download) mit SPI und I2C-Bus vor. Kann ich eigentlich wirklich 8 Geräte oder mehr direkt an die GPIO-Ports des Raspberry PIs hängen (die für I2C oder SPI zuständig sind), ohne weitere Verstärkung oder Treiber? Ich hoffe schon. Die Schaltung im oben genannten PDF betreibt ja die Pullup-Wiederstände der Taster, den Expander-Chip selbst, sowie die LEDs an den Ausgängen alle aus der knappen und empfindlichen 3,3V-Leitung des Raspberry PI. Kann ich den Schaltplan einfach so abändern, dass ich den MCP2317SP-Chip und den Rest einfach an 5V statt 3,3V hängen? Oder leitet er dann z.B. über den SO-Pin 5V in den Raspberry PI und grillt ihn? Wie könnte ich das verhindern? Wie kann ich den Raspberry am besten abtrennen? Wenn Optokoppler verwendet werden: Klappt das mit allen 4 Pins für SPI (SCLK, CS, MISO, MOSI, dabei bei MISO sicher den Optokoppler umgedreht einbauen) und den 2 für I2C? Angeblich ist ja irgendwas besonderes an den GPIO-Pins des Raspberry PIs dran, die für SPI/I2C verwendet werden... Könnte ich die Schaltung auch einfach an eine andere, unabhängige 5V Versorgung hängen? Vielen Dank für alle Antworten! Christian
Denke für Haussteuerung gibt es sehr viele Projekte... Schau vielleicht eher ob nicht eins davon bereits hat was du suchst und ob du es nicht weiterentwickeln kannst, als von 0 anzufangen... Bespiel: HAP: - https://code.google.com/p/hap/wiki/Basics Hier hängen Atmels via CAN an nen Server (bspw. Raspberry) incl. GUI config & ... FEHM - http://www.fischer-net.de ELV HW zum kaufen...
Hallo, habe meine Haussteuerung im gesamten Haus mit HAP (https://code.google.com/p/hap) laufen und will dabei auch nen Rasspberry als neues Interface einbinden. Könnten noch Supporter gebrauchen....
:
Bearbeitet durch User
Wenn du anstelle von 8x16 IO auch mit 7x16 IO leben kannst, dann kannst du auch die 2x7 Int Ausgaenge auf einem IO Expander raufgeben, und das freie INT_A geht in den R_PI und INT_B in den freien Pin des PORTA vom Portexpander. Der freie Pin vom PortB ist fuer dasselbe daisy chain fuer weitere Portexpander vorgesehen, z.B. wenn mit i2c switch/mux gearbeitet wird, oder ein 7x16 am 2ten i2c Port des RPI angeschlossen wird, mit interrupt controller. So hat man einen Int und man kann mit minimalen Aufwand den Port dann abfragen, ohne zu pollen.
Nachtrag, es geht hier um 120 IO, also dann waere 7x16 Expander als IO Expander mit jeweils INT_A und INT_B zusammengeschaltet auf den 8ten expander PORTA und PORTB des 8ten expanders als IO nehmen, sowie INT_B davon auf den noch freien Pin von PORTA geben, dann hat man 120 IO und eine Int Leitung sowie ein Port wo man lesen kann, welche Addresse auszulesen ist, ohne alle zu pollen. Abgesehen davon, in 10ms sind alle 8 Bausteine gepollt bei 400khz i2c.
Hallo, sollte hier Interesse an einer einfachen, kostengünstigen aber trotzdem zuverlässigen Lösung bestehen, kann ich auf eine eigene Entwicklung verweisen. Seit einigen Jahren betreibe ich mehrer Haussteuerungen nahezu störungsfrei. Aus Sicherheitsgründen ist es ein verteiltes System. In der Anlage befindet sich eine Abbildung des Prinzips. Ein und Ausgänge sind mehr als genug vorhanden. Ein Basismodul kann 32 Ausgänge und 52 Eingänge. Es sind bis zu 18 Basismodule über den Basisbus zu koppeln. Dazu sind dann Sensor- und Aktor-Module vorhanden, die jeweils 8 Taster oder 8 Relais anschalten. bei 70 Tastern und 50 Relais wären das also 2 Basismodule, 9 Aktormodule und 7 Sensormodule. Die Hardware habe ich bisher selbst entwickelt. Es gibt jetzt aber die Arduino-Module. Die teste ich derzeit. Ich gehe davon aus, das diese Module meinen Anforderungen entsprechen. Ein Basismodul ist dann für 15,00 € und ein Sensor oder Aktormodul für 3,00 € erhältlich. Evt. sind noch Treiber für die Relais erforderlich. Die Konfiguration erfolgt über einen PC, der aber nicht für den Betrieb zwingend ist. Der PC läuft bei den Haussteuerungen zum Logging, zur Betriebszeitenerfassung, Meldungen über die Soundkarte und die Anbindung an einen Webserver um die Anlage auch über andere PC, Tablet-PC oder Handys zu steuern.
Hallo Günter, ich würde mich durchaus für eine solche kostengünstige und stabile Version interessieren. danke fg Andi
Hallo, habe weitere Infos zu meiner Haussteuerung als neuen Beitrag unter: EasyHomeControll eingestellt. Dort kann ich dann auch weiter Infos und Antworten zu Fragen schreiben. Günter Knöpfel
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.