Hallo ihr Lieben, ich habe nach Jahren des Überlegens und Nachgrübeln nun endlich beschlossen mein Vorhaben Homeautomation anzugehen. Dazu habe ich mir in den letzten Wochen viele Gedanken über den Aufbau und die Details wie Vernetzung etc. (ich komme gleich nochmal dazu) gemacht. Und jetzt soll es losgehen aber je näher ich der Implementierung komme desto mehr Zweifel kommen mir an meinem Plan. Ich möchte hier mal (hoffentlich nicht zu) ausführlich vorstellen was ich zum einen vor habe und welche Ansätze ich verfolge. Also erstmal - was hab ich vor: Ich möchte in unserem Häuschen ein System aufbauen über dass ich z.B. die Rollläden steuern, die Lampen schalten, verschiedene Werte messen (Temp, Helligkeit, Feuchte) kann. Das ganze soll so aufgebaut sein, dass in den einzelnen Räumen "dumme" Datensammler (sorry, ich weiss nicht wie ich die Einheiten nennen soll) sitzen (z.B. AVR's) die Zentral über ein System, z.B. RasPi oder Linux-PC, mit Logik und "Intelligenz" komplettiert werden. Warum - um die Logik an einer stelle zu haben und dort Änderungen einmalig einspielen zu können und nicht für jede Zeitänderung zu der ein Rollladen schließen soll an die Raum-Einheiten zu müssen. Gesteuert wird das ganze über ein Webfrontend oder eine App am Tablet/Smartphone/PC (und dann auch per Webzugriff). Iststand: Ich habe in jedem Raum einen UP-Kasten (12x14cm), der die "dummen" Einheiten aufnimmt und die entsprechenden Leerrohre zu den Rollläden, Lichtschaltern etc. Sowie ein Leerrohr zur Zentrale von jedem Raum (Stern-Topologie). Alle wichtigen Stellen sind so per Leerrohr erreichbar. Thema Vernetzung: Meine ersten Überlegungen galten nun der Vernetzung - hier war ich sehr lange Feuer und Flamme für Ethernet (Kabel dazu habe ich bereits hier liegen). Jedoch bin ich die letzten Wochen immer wieder auf andere Realisierungen mit RS485, 1Wire, etc. gestoßen - dazu gleich Vorweg, Funk kommt für mich zu 100% nicht in Frage. Aber beim Einlesen in die Systeme (zuletzt RS485-Modbus) kam mir das Graußen mit welchen Problemen sich die Leute da rum schlagen und wie lange es dauert ein System stabil am Laufen zu haben. Seitdem ist Ethernet dann doch wieder Thema, da ich glaube hier ein gut unterstütztes und stabiles Netz aufbauen zu können. Und ich möchte nicht ein System von Grund auf mit Protokoll und allem drum und dran neu aufsetzen - dazu fehlt mir die Zeit und ehrlich gesagt auch die Lust - warum das Rad neu erfinden... "Dumme" Einheiten: Nun ging es um die "dummen" Einheiten in jedem Raum. Hier wollte ich gerne AVR/ATMEL µC einsetzen, da ich zum einen hier schon Anwendungen programmiert habe (Arduino Nano und auf einem Atmel Entwicklerboard) und mir die C Programmierung als Softwareentwickler geläufig ist. Außerdem laß ich oft, für diese Aufgaben wäre z.B. ein RasPi völlig übertrieben (obwohl ich auch schon mit diesem Gedanken gespielt hatte). Als ich auf das Pollin AVR-NET-IO gestoßen bin, hab ich mich gleich verliebt und gedacht, das wäre perfekt - da muss ich nichts mehr entwickeln, rufe einfach von der Zentrale zyklisch die Daten ab oder schreibe sie hinein und gut ist. Ich müsste mich hier weder um das Thema Vernetzung kümmern (Ethernetkabel legen anschliessen, fertig) und die µC's in den Räumen sind fertig programmiert und die Boards sind fertig zum Anschliessen der Sensoren und Aktoren. das hätte den Charme, dass ich mich auf das konzentrieren könnte was mir am meisten liegt - die zentrale Logik/GUI. Andererseits wären hier abgespeckte AVR-Boards mit ETH-Schnittstelle auch denkbar und bezahlbar. Was ich vermeiden möchte ist in eine Richtung zu rennen, in der ich in ein paar Monaten steckenbleibe und von neuem anfangen zu müssen. Daher wollte kurz meine Gedanken und mein Vorhaben beschreiben und an die, die bereits Erfahrungen gesammelt haben die Frage nach Ideen richten. Was mir nicht so zusagt ist ein fertiges System einzusetzen das hier und da nicht zu meinen Anforderungen passt und mit den Krücken dann leben zu müssen. Wäre super wenn Ihr mir ein paar Schubbser in die "richtige" oder besser gesagt in bereits erprobte Richtungen geben könntet. Liebe Grüße Sascha
Hatte auch schonmal ähnliche Gedanken. Letztendlich ist es aber kein Ethernet geworden, weil es einfach zu viel Strom im Vergleich zu lahmarschigen Alternativen (RS485, CAN, KNX) verheizt. Außerdem ist die Zentralisierung mir irgendwie nicht geheuer. Fällt das NetIO aus, fällt auch der WAF (Woman Acceptance Factor) schlagartig unter 0. Dezentrale Ansätze wie KNX haben grundsätzlich keinen Single Point of Failure (wenn man die Spannungsversorgung mal weglässt..)
Danke Horst für deine Antwort - ja ich gebe dir 150% recht, der WAF muss gewahrt sein, daher will ich das System auch so aufsetzen, das die grundlegenden Funktionen wie Licht/Rollladen etc. auf jeden Fall auch bei einem Komplettausfall weiterhin wie gewohnt funktionieren - ok bei Stromausfall mach ich eine Ausnahme ;-) Wobei ich auch schon über eine USV nachgedacht habe... Was meinst du mit "zu Stromhungrig"? Ich denke ein 32er Switch tut's für die Vernetzung. Und was muss ich unter "Single Point of Failure" verstehen?
:
Bearbeitet durch User
Sascha M. schrieb: > > Was meinst du mit "zu Stromhungrig"? Ich denke ein 32er Switch tut's für > die Vernetzung. Auch wenn der ENC28J60 vielleicht nicht das beste Beispiel für einen modernen Ethernet-Kontroller ist, werde ich nie vergessen, wie ich mir in Anfangstagen am zugehörigen Linearregler fast die Finger verbrannt habe. Das Dingen zieht halt einfach mal rund 200 mA. Klar ist das mit Schaltregler wesentlich besser, aber trotzdem sind 200 mA kein Pappenstiel. Es kostet halt einfach einiges an Energieaufwand einen kompletten TCP-IP-Stack am Laufen zu halten. Simplere Protokolle wie CAN, KNX, RS485 sind da wesentlich genügsamer. Neben den verteilten Knoten kommt dann auch noch wie du schon richtig sagst ein großer Switch dazu, bei dem ein aktiver Port auch nicht mit weniger als 0.5 Watt auskommt. (PS: ich warte schon auf die Klugscheißer, die mir gleich ein Modell zeigen wollen, was das unterbietet) Sascha M. schrieb: > Und was muss ich unter "Single Point of Failure" verstehen? Naja, wenn das NetIO abkackt, dann machen deinen 'dummen' Knoten halt nichts mehr. Muss also nur eine Komponente ausfallen, und alles geht nicht mehr. Bei KNX gibt es nicht diese einzige Zentrale, sondern jeder Sensor und Aktor senden und empfangen auch wenn keine Zentrale sie speziell abfragt.
Horst schrieb: > Auch wenn der ENC28J60 vielleicht nicht das beste Beispiel für einen > modernen Ethernet-Kontroller ist, werde ich nie vergessen, wie ich mir > in Anfangstagen am zugehörigen Linearregler fast die Finger verbrannt > habe. Das Dingen zieht halt einfach mal rund 200 mA. Klar ist das mit > Schaltregler wesentlich besser, aber trotzdem sind 200 mA kein > Pappenstiel. Es kostet halt einfach einiges an Energieaufwand einen > kompletten TCP-IP-Stack am Laufen zu halten. Simplere Protokolle wie > CAN, KNX, RS485 sind da wesentlich genügsamer. Ach, dass wusste ich nicht, dass der Chip derart hungrig ist, Danke für den Hinweis. Werde mich gerade in Hinsicht auf den Energiebedarf nochmal genauer einlesen in die unterschiedlichen Bussysteme. Gibt es hierfür irgendwo eine "Übersicht" - quasi so in der Art: System erforderliche Peripherie Quellcode / Stabilität AVR + CAN-Bus CAN CHip XY link zu den Queleln / ausgereifter Code ... Ich weis es gibt vermutlich 1000 Seiten und Threads zu den jeweiligen Bussen, aber das Problem dabei ist, dass es sehr viel Zeit in Anspruch nimmt sich durch zu arbeiten. Hatte erst kürzlich einen Modbus Thread durchgeackert - 60 Posts die super interessant waren, keine Frage. Aber danach sitzt man da und iss so schlaub wie zuvor, weil das Thema noch nicht zuende entwickelt ist, oder evtl. an einem Punkt dann einfach abreißt. Das ist dann immer enttäuschend wegen der investierten Zeit. > > Naja, wenn das NetIO abkackt, dann machen deinen 'dummen' Knoten halt > nichts mehr. Muss also nur eine Komponente ausfallen, und alles geht > nicht mehr. Bei KNX gibt es nicht diese einzige Zentrale, sondern jeder > Sensor und Aktor senden und empfangen auch wenn keine Zentrale sie > speziell abfragt. Das ist verständlich, aber im Moment für mich nicht so relevant, da ich zum einen wie gesagt die normale Bedienung parallel beibehalten will und zum anderen nicht alle Eventualitäten für Ausfälle abdecken möchte (aktueller Stand) ;-) Danke Dir für deine Antworten! Viele Grüße Sascha
Sascha M. schrieb: > Iststand: > Ich habe in jedem Raum einen UP-Kasten (12x14cm), der die "dummen" > Einheiten aufnimmt und die entsprechenden Leerrohre zu den Rollläden, > Lichtschaltern etc. Sowie ein Leerrohr zur Zentrale von jedem Raum > (Stern-Topologie). Alle wichtigen Stellen sind so per Leerrohr > erreichbar. Ist super - da lässt sich gut was machen. > Thema Vernetzung: > Aber beim Einlesen in die > Systeme (zuletzt RS485-Modbus) kam mir das Graußen mit welchen Problemen > sich die Leute da rum schlagen und wie lange es dauert ein System stabil > am Laufen zu haben. Könntest ja auch auf CAN setzen - aber wer sich SEIN System entwirft, braucht halt Zeit, Geduld, muss Rückschläge verkraften können,.... > Und ich möchte nicht ein System von Grund auf mit Protokoll und allem > drum und dran neu aufsetzen - dazu fehlt mir die Zeit und ehrlich gesagt > auch die Lust - warum das Rad neu erfinden... Ahja - warum nimmst Du dann nicht etablierte Technik wie z.B. KNX? Deinen Spieltrieb kannst Du dann immer noch mit RaspB u. Co. dranschustern. > Sensoren und Aktoren. das hätte den Charme, dass ich mich auf das > konzentrieren könnte was mir am meisten liegt - die zentrale Logik/GUI. Jup - KNX u. du kannst dich auf das wesentliche konzentrieren.
G. L. schrieb: > Sascha M. schrieb: >> Iststand: >> Ich habe in jedem Raum einen UP-Kasten (12x14cm), der die "dummen" >> Einheiten aufnimmt und die entsprechenden Leerrohre zu den Rollläden, >> Lichtschaltern etc. Sowie ein Leerrohr zur Zentrale von jedem Raum >> (Stern-Topologie). Alle wichtigen Stellen sind so per Leerrohr >> erreichbar. > Ist super - da lässt sich gut was machen. > > >> Thema Vernetzung: >> Aber beim Einlesen in die >> Systeme (zuletzt RS485-Modbus) kam mir das Graußen mit welchen Problemen >> sich die Leute da rum schlagen und wie lange es dauert ein System stabil >> am Laufen zu haben. > Könntest ja auch auf CAN setzen - aber wer sich SEIN System entwirft, > braucht halt Zeit, Geduld, muss Rückschläge verkraften können,.... Das ist richtig, aber je mehr Baustellen ich habe, desto weniger Land ist in Sicht. Es geht mir bei meinem System ums Entwickeln, aber irgendwo muss auch ein Fortschritt sichtbar sein um gewisse Personen (Stichwort WAF) von dem System zu begeistern und das geht am Besten mit Sicherheitsgewinn. > >> Und ich möchte nicht ein System von Grund auf mit Protokoll und allem >> drum und dran neu aufsetzen - dazu fehlt mir die Zeit und ehrlich gesagt >> auch die Lust - warum das Rad neu erfinden... > Ahja - warum nimmst Du dann nicht etablierte Technik wie z.B. KNX? > Deinen Spieltrieb kannst Du dann immer noch mit RaspB u. Co. > dranschustern. Wenn ich es richtig verstehe meinst du mit KNX die Schalter und Steckdosen (Empfänger) richtig? Oder ist damit der Bus und die Steuerung gemeint? Nun alles was ich in diesem Bereich bisher angeschaut hat durchaus seinen Reiz, aber erstens ist das wie im RC-Modellbau - ich kann mir ein fertig aufgebautes Modellschiff kaufen und hab ein nettes funktionierendes Spielzeug oder aber ich baue das Schiff selbst von Grund auf mit ein paar Gimicks, die sonst keine hat und kann am Ende evtl. Stolz auf das Resultat sein. Und Zweitens wird mir bei den Preisen ehrlich gesagt übel - wenn ich unseren Nachbarn sehe der ein Automationssystem von Anfang an eingebaut hat und was der dafür löhnen muss - selbst einfache ELV Systeme (ich weiß dass die sicher nicht der Weisheit letzter Schluss sind) bei denen einfache Schalter 40-50€ kosten sollen - das liege ich wenn ich Glück habe im 4 stelligen Bereich mit dem Komplettsystem. Die etablierte Technik ist mir zu kostspielig und hat zu wenig Egofaktor ;-D > >> Sensoren und Aktoren. das hätte den Charme, dass ich mich auf das >> konzentrieren könnte was mir am meisten liegt - die zentrale Logik/GUI. > Jup - KNX u. du kannst dich auf das wesentliche konzentrieren. Wie gesagt, wenn ich da nicht falsch informiert bin - lasse mich gerne eines besseren belehren, ist das zu kostspielig. Aber vielen Dank für deine Hinweise und Meinung.
:
Bearbeitet durch User
Sascha M. schrieb: > Wäre super wenn Ihr mir ein paar Schubbser in die "richtige" oder besser > gesagt in bereits erprobte Richtungen geben könntet. Nun, du bist hier nicht der erste der Fragt und Antworten wurden im Forum schon gegeben, du musst dir nur die Antworten aussuchen, die dir gefallen :-) Stichpunkte: - Verdrahtung (extra Kabel, 230V, PoE, ...) - Kommunikation (Funk, RS485, I2C, Ethernet, ...) - Zukunftssicherheit (es gibt schon rPi2...) Allgemein sagt man: Wenn man nicht alles per Funk macht, braucht mal Kabel. Wenn man Kabel braucht, muss man sie irgendwo lang legen. Da es keine 230V~ Kabel sind, sondern Informationstechnikkabel werden die in Leerrohren geführt, lege also Leerrohre. Wenn man Leerrohre hat (die nicht unbedingt direkt zum Sicherungskasten führen müssen, durch die man aber zur Zentrale kommt), dann muss man nicht auf nur einen Typ bauen, also nur Ethernet oder nur KNX, sondern kann nehmen, was am besten passt. Temperatur messen: Wozu ein AVR, einfach ein NTC am Kabel, fertig. Ein Problem ist nämlich immer die Stromversorgung. Ein NTC am Kabel braucht keine Stromversorgung, wenn man eine Stromversorgung braucht, braucht man ein Kabel, der NTC ist also in jeder Beziehung weniger Aufwand. Wenn man Strom hat, kann die eigentliche Kommunikation auf Wunsch auch per Funk erfolgen. Vor allem dann, wenn der Empfänger schon da ist, z.B. eine Funksteckdose. Die gibt es für 3 EUR/Stück, da kommt kein anderes System ran. Und selbst wenn man sich für ein Hyper-Dupa System entschieden hat, z.B: KNX oder DigitalStrom, kommt sofort etwas hinzu zur Hausautomation, was nicht dazu passt, z.B. Videoüberwachung and er Tür oder als Einbrecherschutz. Im Leerrohr alles kein Problem. Leg also Leerrohre, und such dir dann das jeweils für den Job BESTPASSENDSTE aus. Es ist nicht schlimm, wenn mehrere Systeme nebeneinander liegen, dann funktioniert wenigstens noch etwas, falls eines der System ausfällt. Und ob dann die Zentrale eine SPS; ein rPi oder ein PC ist, steht dir völlig frei. Und der Nachbesitzer kann es wieder ändern. Leerrohre sind das einzige, was flexibel ist, wenn sie dort enden, wo man sie braucht.
Was in Bezug Bussystem natürlich auch eine große Rolle spielt ist mein Kenntnisstand - der ist sehr rudimentär. Klar wäre es super den Bus von Grundauf zu verstehen mit allen Schichten aber das würde ich gerne vermeiden ;-) Zumal der Trial&Error Zeitverlauf sicher nicht ganz ohne sein dürfte. Ich Sachen µC, Elektronik, µP und "PC"-Software ist der Wissensstand schon einige Stufen weiter und den würde ich hier gerne Auffrischen und vertiefen... Das noch zum Hintergrund zu meinem Projekt
Hallo Michael Bertrandt - vielen lieben Dank für deine Ausführungen - was die Leerrohre angeht bin ich vollkommen einverstanden und habe das auch so ausgeführt, auch wenn mich damals alle für Verrückt erklärt haben als ich mehrfach mit Kofferraumladungen Leerrohrringen ankam :-D Alles liegt zentral in einem UG-Raum, in dem auch schon der Serverschrank wartet... Ich will aber nicht nur Temperatur messen - alle Ideen hier aufzuführen würde zu weit führen, aber das wichtigste: - Rollladensteuerung (vom Raum, zentral über z.B. ein Tablet, zentral über die Zentrale - z.B. per Zeitautomatik/Sonneneinstrahlung..., und von unterwegs - wer schonmal bei der Urlaubsantrittsfahrt 50km gefahren und dann aufgrund der Frage "hast du den Rollladen im Raum XY eigentlich runter gemacht" umdrehen drufte weiß was ich meine) - Lichtsteuerung (vom Raum, zentral Tablet/Zentrale, Automatik z.B. Anwesenheitssimulation) - Alarmanlage mit Erfassung diverser Zustände (Rollladen, Fenster, Licht, Scheibenbruch, Feuer, Rauch, Bewegung...) - Türklingel mit Kamerabild - diverse Geräte fernschalten und, was wichtiger ist, kontrollieren ob an oder aus (siehe oben Urlaubsgeschichte - Stichwort "Herd") - Heizungseinbindung (Stichpunkte: Warmwasserzirkulation bei Abwesenheit, Warmwasserbereitung bei längerer Abwesenheit, etc.) Das geht meiner Meinung nach nicht mehr mit Strippen in die Räume ziehen.
Bin gerade über einen Feldbus namens SmallCAN gestoßen der unter anderem für Hausautomatisierung entwickelt wurde um bestehende Systeme CAN (teuer) oder RS485 (Energiekosten) zu optimieren. Wäre das ein in Betracht kommendes System (habe leider hierzu im Forum nichts gefunden)? Hat das schonmal jemand eingesetzt?
Sascha M. schrieb: > Funk kommt für mich zu 100% nicht in Frage Schade, daß Du damit die beste und zukunftsträchtigste Verbindungsform von vornherein ausschließt. Bedenke: So kommst Du an jede unmögliche Stelle und kannst höchst flexibel abändern/erweitern. Aber da Du sicher weisst wo zukünftig die Musik spielt und die Leerrohre nunmal schon gelegt sind... Und die Frau womöglich allzu sensibel gegenüber elektromagnetischen Wellen ist ;-) Entweder setzt Du zeitsparend auf fertige Systeme (und es wird teurer, unflexibler, man kann nicht 100%ig alles selbst gestalten und ist auf div. Hersteller angewiesen) oder Du machst alles selbst = hast alles selbst in der Hand (und es langen eine Handvoll AVR Chips+Grips ;-) Das wird dann allerdings eine zeitraubende Geschichte, die nicht nur die Funktion, sondern auch den Spaß an der Sache im Mittelpunkt haben sollte. Dafür wird es schööön billig, schööön klein, schööön passend, schööön stromsparend, schööön kreativ, schööön herstellerunabhängig, mit allem was Du willst! Da Bluetooth Low Energy z.T. samt autarker Energieversorgung nun langsam in Fahrt kommt sind in Zukunft sicher noch viel bessere, smartere Systeme denkbar, einfach in der Anbindung ans Internet, inklusive mobiler Phone/Tablettbedienung- die langsam bezahlbar werden und jegliches Homecontrol-Kabelgewusel ins Zeitalter von Gestern verweisen. Womit wir aber leider schon wieder bei Funk wären ;-)
:
Bearbeitet durch User
Schwachsinn von Moby. Wenn man die Möglichkeit hat, Leerrohre in großem Maße zu verlegen, ist das wesentlich besser. Funk wird immer mehr Strom verbrauchen als Kabel, Funk wird immer unsicherer sein als Kabel, und "wer Funk kennt, nimmt Kabel" (in Bezug auf Nichtfunktionieren). Und alle Argumente, die da als Vorteil von Funk verkauft werden, sind auch bei Selbstbau von Kabelkomponenten gegeben (billig, kreativ, herstellerunabhängig). Lass dich also durch so einen Schwätzer bloß nicht verunsichern und nutze deine ganzen Leerrohre. P.S.: WIMRE ist Moby auch der, der in jeder zweiten Frage ankommt, und Assembler als das einzig wahre anpreist. Wenn ich mich irre, bitte ich schon jetzt um Entschuldigung.
Hei, da kann ich Horst nur beipflichten. Hab ich genauso gemacht: Viel Leerrohr... Allerdings spricht nichts dagegen, später auch mal Funk zu nutzen. (Mein Lieblingsspruch ist auch: Wer Funk kennt, nimmt Kabel!) Bei mir kommt z.B. enocean zum Einsatz. Da habe ich momentan noch alle Lichtschalter damit gemacht. Die werden dann sukzessive gegen selbstentwickelte "smarte" Lichtschalter ersetzt... ;-) Grüße, Tom
Warum oder? Das Schöne an offenen Systemen wie fhem und OpenHab ist doch, daß man sich nicht mehr entscheiden muß. Es geht beides - Funk UND Kabel. An den wichtigen, vorhersagbaren Stellen ein Leerrohr und die Kabellösung. Alles was unvorhergesehen dazukommt mit Funk. Z.B. Funk-Lichtschalter ans Kinder-Hochbett kleben. Enocean finde ich dafür auch klasse, montieren und danach nie Batterien wechseln. Die Funklösung wird auch bei Lampen immer mehr kommen, weil dort ein einfaches ein/aus nicht mehr reichen wird. Moderne Lampen können zusätzlich zum Dimmen die Farbtemperatur wechseln, dafür ist eine intelligente Ansteuerung zwingend. Und auch bei "normalen" gedimmten Led-Lampen ist Datenansteuerung sinnvoll. Die manchmal zu sehende Lösung: konventioneller Dimmer - dimmbares Led-Netzteil - Led-Lampe überzeugt jedenfalls nicht wirklich. Gruß, Stefan
Horst schrieb: > Funk wird immer unsicherer sein als Kabel, und > "wer Funk kennt, nimmt Kabel" (in Bezug auf Nichtfunktionieren). > > Und alle Argumente, die da als Vorteil von Funk verkauft werden, sind > auch bei Selbstbau von Kabelkomponenten gegeben (billig, kreativ, > herstellerunabhängig). Eindeutig JA, und Sascha hat ja schon Leerrohre. ABER: Wenn er mal was schalten will, wo nur 230V liegen, ist Funk (Funksteckdose, Funkdimmer, Funkgaragentor) immer noch besser, als irgendwas über die verseuchten 230V zu schicken (BSR X10, DigitalStrom, KNX auf 230V). Das erkennt man schon am Preis :-) Und: Funk hat den Vorteil, bewegliche und mehrere Sender zu haben. Das Beispiel Garaentoröffner kam schon, aber auch eine Zimmerbeleuchtung in der Mitte des Raumes (womöglich mit 3 unabhängig schaltbaren Lampen) lässt sich elegant bedienen, wenn man sie mit einem Funkempfänger ausstattet, an der Tür einen fest installierten und auf dem Couchtisch einen Sender hat, die Hauszentrale dasselbe Funkkommando senden kann und beispielsweise das Licht ausschaltet wenn man die Haustür zuschliesst, und die Hauszentrale das Funkkommando des Handsenders mitbekommen kann, also i.A. weiss ob es an oder aus ist, und derselbe fest installierte Funksender an der Tür kann auch die in der Steckdose befindliche Stehlmape schalten dank Funksteckdose. Es gibt also schon Anwendungen für Funk, preiswert und flexibel. 100% zuverlässig ist Funk aber nicht.
:
Bearbeitet durch User
Horst schrieb: > Schwachsinn von Moby. Funk wird immer unsicherer sein als Kabel Schwachsinn von Horst. Funk ist die Zukunft, nicht dieser elende energieschluckende Kabelverhau von heute. Mit einem ordentlichen, rückbestätigenden System ist Funk auch keine Spur unzuverlässiger. Allerdings könnte es sicherheitsmäßig von Vorteil sein, kein System von der Stange zu nehmen sondern etwas selbst zu entwickeln. > Und alle Argumente, die da als Vorteil von Funk verkauft werden, sind > auch bei Selbstbau von Kabelkomponenten gegeben (billig, kreativ, > herstellerunabhängig). Schwatz keinen Blödsinn, das sind die Vorteile wenn man alles selber macht. > ist Moby auch der, der in jeder zweiten Frage ankommt, und > Assembler als das einzig wahre anpreist Keine Sorge. Hier war von Asm nicht die Rede und wird es auch nicht, auch wenn an dessen Vorteilen natürlich was dran ist ;-)
:
Bearbeitet durch User
Hallo Sascha, ich habe mir vor 2 Jahre die selben Gedanken gemacht. Bin dann bei vielen Leerrohren mit RS485 hängen geblieben. RS485 aus dem Grund der auch schon genannt wurde. Benötigt wenig Strom und der Aufbau ist unkompliziert. Geschwindigkeit für meine Anwendungen vollkommend ausreichend. Die "dummen" Sensoren habe ich in herkömlichen Raumthermostate eingebaut, die dann auch von einem Zentralen Recher abgeholt und gespeichert werden. Nach und nach kamen dann die Lüfter dazu, auch die Fußbodenheizung etc. Das nächste wird dann der eBus der Heizung sein. Hier als Beispiel meine Senoren und InVenter Ansteuerungen. Beitrag "Hausbus mit RS485 / InVenter und Raumsensoren" Gruß
Ruhig Blut Moby und Horst iss ja wie n Glaubenkrieg hier :-D Danke für die rege Beteiligung!!! Bin diesbezüglich (Funk/Kabel) aber auf jeden Fall der Kabelanhänger. ABER für einzelne Anwendungen, z.B. die Lampe die man doch vergessen hat und nicht mehr erreicht, oder ein batteriebetriebenes Etwas das man steuern möchte kann ich mir Funk sehr gut vorstellen - aber 100%ig nicht für lebenswichtige Dinge - und eine Rollladen zu öffnen kann schneller nebensnotwendig werden als einem lieb ist, wenn die Hütte brennt und irgendwann der Strom für die Rollladenmotoren ausfällt... Aber anderes Thema. Hallo Jürgen H., das hört sich doch schon mal nicht schlecht an - 2 Jahre im Einsatz und du würdest es weiter empfehlen. Darf ich fragen welche Prozessoren zu einsetzt? PB klingt so nach µC vom Schlag 8051... Kannst du mir eine Bibliothek für den Arduino empfehlen um das ganze mal auf einem Breadboard ans Laufen zu bekommen - finde das immer sehr nice wenn so etwas im kleinen schonmal getestet werden kann - auch mit mehreren Teilnehmern.
OK, habe mich mal ein bisschen tiefer (immernoch an der Oberfläche) in die RS485 Thematik eingelesen. RS485 beschreibt ja den physikalischen Feldbus - aber kein Protokoll. Dieses Protokoll, z.B. Modbus ANSI ist nötig zum Datenaustausch und zur Sicherung der Datenübertragung, wenn ich das richtig verstehe. Hier habe ich auch eine Bibliothek von Nick Gammon gefunden - für den ersten Test. Was mir jetzt fehlt ist physikalisch noch das ein oder andere Bauteil um den Arduino an den RS485 Bus anzukoppeln. Was ich fand sind LTC1480CN8 (rel. teuer, knapp 5€ beim C) und SN75176BP (sau günstig, Stromfresser) und MAX485 (zig Ausführungen, keine Ahnung welche hier die "passende" ist, Halfdupelx sollte reichen, recht stromsparend - gefällt mir) oder sollte ich so ein Rs232 Rs485 Modul für n paar Euro nehmen? Irgendwelche Tipps für einen verwirrten Suchenden :-D
:
Bearbeitet durch User
Guten Morgen, nein das ist kein 8051 ;-) das war mal. Ich bin mittlerweile ein ARM bzw. STM Anhänger. Ich setze in diesem Projekt den F030 (Cortex-M0) ein. Der braucht verdammt wenig Strom und die Geschwindigkeit ist trotzdem enorm. Das mit der 485 hast du richtig verstanden. Das ist nur der Übertragungslayer, um das Protokoll musst du dich selbst kümmern. Aber brauchst du so "große" Protokolle wie ModBus etc.? Bei mir läuft ein ganz einfaches Protokoll so in der Richtung Adresse, Länge, Funktionscode, Daten, CRC. Das reicht für die meinsten Anwendungen. Ich hab den MAX481CSA eingesetzt, da dieser mit 3,3V kann und Strom technisch merke ich da nichts. Meist sind es auch die 120R Abschlusswiderstände die den Strom verursachen..... Aber darüber wurde hier schon viel und oft diskutiert. Aber wie hier schon gesagt wurde, mach dir mal gedanken um die Versorgung der Module. Das war bei mir auch das größte Problem. 230V in einer Anschlussdose sauber klein zu bekommen...... teuer, bzw. groß. Viel Spaß beim planen!
Sorry, hab dir schmarn erzählt...... es ist nicht der MAX481CSA sondern SN65HVD3082ED. Nur die Lib vom MAX habe ich im Schaltplan verwendet.
Guten Morgen Jürgen, danke dir für die Antwort - zur Frage ob ich ModBus brauche - hmm, ehrlich gesagt keine Ahnung. Das war eins der Protokolle über die ich des öfteren gelesen habe im Zusammenhang mit Hausbussen. Zum Verständnis das ganze Osi und Protokoll Thema ist schon so lange her - dieser Protokolllayer würde, wenn ich das richtig verstehe, wie folgt implementiert. Ich bediene die RS232 des ARM hinter der ja z.B. ein MAX485 die Umsetzung auf 485 vornimmt nicht wie normal über die serial.println() Befehle, da hier das RS232 Protokoll eingesetzt würde, sondern ich müsste die Schnittstelle quasi Bit für Bit verarbeiten und die empfangenen Pakete in deren Bestandteile z.B. Adresse, Länge, Funktionscode, Daten, CRC aufsplitten und verarbeiten. Beim Senden müssten die auf die Schnittstelle geschickten Bits quasi von meinem Code zusammengesetzt werden. Um so Dinge wie Baudrate kümmert sich aber hoffentlich noch eine library oder? Sehe ich das (ganz grob gesehen) richtig, oder bin ich auf dem falschen Dampfer :) Viele Grüße Sascha
Die Elektroinstallation eines Hauses sollte für eine Lebensdauer von 20-50 Jahren ausgelegt werden. Unabhängig von Selbstbau oder kommerziellen Lösungen und Komponenten sollte man sich Gedanken darüber machen, wie man auf dieser Zeitskala Wartungsarbeiten durchführen möchte. Nur ein paar Stickpunkte: - Bauteileverfügbarkeit - Entwicklungsumgebung (bei Selbstbau) - Konfigurationssoftware (bei kommerziellen Systemen) Man sollte sehr stark darauf achten, dass sich zumindest die benötigte Software auch in einer virtuellen Maschine betreiben lässt, damit man zumindest eine gewisse Unabhängigkeit von dem Betriebssystem seines Entwicklungs- und Konfigurationsrechners hat. Bei korrespondierender Hardware (Programmierschniepel für Mikrocontroller, Feldbusschnittstelle) sieht es da schon wesentlich heikler aus. Man schaue sich nur an, mit welchem Aufwand heutzutage solche wichtigen Systeme aus den 1980er oder 1990er Jahren gepflegt werden müssen, damit man nicht eine für den Betrieb oder die Wartung einer Anlage lebenswichtige Komponente verliert. Und es wäre naiv, anzunehmen, dass heutige Entwicklungssysteme nicht einer ähnlichen schleichenden Inkompatibilität unterworfen wären. Allerdings kann man auch sehr viel mit Emulatoren usw. machen, so dass man in den meisten Fällen die in der Ecke herumlärmende VAX abschalten kann. ;-) Wichtige Komponenten, d.h. insbesondere zentrale Baugruppen wie Raspberry Pi oder SPS, sollte man unbedingt als Ersatzteile auf Lager halten, zumindest um einen zügigen Austausch bei dunkler Bude machen zu können. Ansonsten könnte der persönliche WAF ganz gewaltig leiden, wenn man tagelang im Keller hockt und an der einzigen nicht per Haustechnik geschalteten Steckdose versucht, sich in die Firmware des schon vor 10 Jahren abgekündigten Microcontrollers einzuarbeiten und auf ein komplett anderes Modell eines anderen Herstellers zu portieren. Natürlich nachdem man die nur noch als BGA erhältlichen Pegelwandler im Kerzenlicht auf das defekte alte Board gefädelt hat.
Hallo Andreas Schweigstill Danke für den Denkanstoß - ich kenne das nur zu gut - SPS Baugruppen die nicht mehr reparabel waren, weil Prozessoren nicht mehr verfügbar waren, Druckmaschinenleitstände die zu Windows 7 Zeiten noch auf DOS Systemem mit Modula Betriebssoftware und Tokenring Netzwerk arbeiteten - gruselig :-) Aus den genannten Gründen, wird die Installation bei mir parallel arbeiten (Lichtschalter tun auch ohne das System) und die Zentrale wird austauschbar, da auf einem RasPi ein Linux läuft dass dann später auch auf dem RasPi F oder AnanasPi lauffähig sein wird. Aber genau dieses Thema hat mich bezüglich AVR-NET-IO etwas skeptisch werden lassen - was, wenn Pollin die Teile nicht mehr vertreibt - 5 Stück zuhause auf Lager legen - was wenn die 5 ausgetauscht wurden, dann ist das Lager leer. Andererseits wird das System dann eben umgebaut und dem Stand der Technik angepasst. Und zum Thema "das System muss auch wartbar sein, wenn der Entwickler nicht mehr lebt" - kann ich nur sagen, mir doch egal... :-D
Sascha M. schrieb: > - 5 Stück zuhause auf Lager > legen - was wenn die 5 ausgetauscht wurden, dann ist das Lager leer. Sofern kein Ausfallszenario (z.B. Blitzeinschlag) auftritt, bei dem sich spontan ein Bedarf an sechs oder mehr Austauschkomponenten auftritt, reicht es völlig aus, sich bei Reduktion des Lagerbestandes auf zwei Stück allmählich einmal Gedanken über eine neue Version zu machen. > Andererseits wird das System dann eben umgebaut und dem Stand der > Technik angepasst. Genau. Es wäre nicht sinnvoll, auf Komponenten zu bestehen, die wirklich 50 Jahre lang lieferbar sein sollen, weil das zum einen die Auswahl deutlich einschränkt und zum anderen irrsinnig teuer wäre. Natürlich könnte eine Handvoll prozessierte Wafer einkaufen und bei Dienstleistern wie Rochester Electronics einlagern lassen... Das muss aber nicht sein, denn schließlich will man ja ggf. auch in 10 oder 20 Jahren modernere Versionen einiger Komponenten haben. > Und zum Thema "das System muss auch wartbar sein, > wenn der Entwickler nicht mehr lebt" - kann ich nur sagen, mir doch > egal... :-D Und wer wartet Dein System nach dem Schlaganfall, den Du in zehn Jahren erleidest und der zu einer Lähmung oder Erblindung führt?
Andreas hat da schon recht. Hatte vor kurzen ein Problem mit einem alten 8051 von Siemens. Das System lief seit ca. 9 Jahren. Es war mir nicht mehr möglich das System mit Kompiler etc. zum laufen zu bringen. Deswegen werden die Lampen bei mir immer noch zu 90% über Stromstoß geschaltet. @Sascha: Nein um die Bits brauchst du dich nicht kümmern. Du bekommst immer ein Byte aus der Schnittstelle. Allerdings machen mich deine Fragen stutzig, ob du das so hinbekommst.
> > Und wer wartet Dein System nach dem Schlaganfall, den Du in zehn Jahren > erleidest und der zu einer Lähmung oder Erblindung führt? Das macht dann der hauptberuflich bei mir tätige HomeAutomation-Techniker, den ich ja dank meines Lottogewinns in 5 Jahren problemlos bezahlen kann...
Jürgen H. schrieb: > @Sascha: > Nein um die Bits brauchst du dich nicht kümmern. > Du bekommst immer ein Byte aus der Schnittstelle. Allerdings machen mich > deine Fragen stutzig, ob du das so hinbekommst. Mich auch!!! Daher wünsche ich mir eine Lib die ich verwenden kann :)
Kurze Frage dazu, wenn wir mal davon ausgehen, dass ein Kabelgebundenes Verfahren benutzt werden soll, macht es dann Sinn einfach pauschal in jedes UP-Kastel ein TP-Kabel zu verlegen ? Dann hat man die Freiheit jedwedes Signal, zur Not auch über nur weniger Adern rüberzuschicken. Oder spricht bei den anderen Protokollen etc. irgendwas dagegen bis auf den Kostenfaktor ? Klar, Saft muss Separat bereitgestellt werden, mir gehts nur um die Signale, egal ob man sich jetzt für Ethernet, 485, KNX, CAN , Morsen usw. entscheidet. THX und Gruß Jörch
Du kannst ein Lehrrohr und/oder ein Ethernetkabel vorsehen. Damit solltest du auf der sicheren Seite sein. Ich hab zu allen Vorgesehenen Plätzen ein CAT6 Kabel gezogen. Über das geht RS485 und auch die 12V, da die Leistung ja gering ist, seh ich da kein Problem.
Kleines Statusupdate für Leute die diesen Beitrag finden und selbst vor dem selben Problem stehen. Ich habe inzwischen mit der Gammon Library sehr intensive Versuche gefahren und bin mit dem RS485 Protokoll warm geworden. Aktuell laufen bei mir testweise zwei Arduino Nanos die über die Gammon Lib kommunizieren. Das Coole im Gegensatz zu Ethernet ist der extrem geringe Strombedarf - der Testaufbau kommt aktuell mit 0,5W aus dem USB Port aus ohne die CPU in denn Stromsparmodus zu setzen, was durchaus Sinn machen würde. Aktuell habe ich es so aufgebaut, dass dabei eine Struktur übertragen wird, die folgende Daten enthält: - Ziel Adresse - Absender Adresse - Befehlscode - Nutzdaten Der Empfänger sendet nach dem Empfang eines Befehlblocks eine Quittung an den Sender, damit ist sicher gestellt, dass die Befehle angekommen und verarbeitet wurden. Damit es keine Probleme mit Zugriffen auf den Bus gibt, habe ich mir überlegt, dass der Master die Slaves zyklisch pollt und somit Statusänderungen an den Slaves mitbekommt. Ein paar Fragestellungen sind aber noch offen: - welche serielle Schnittstelle - Software (dig. IO's) oder Hardware (integr. RS232) soll ich am Arduino verwenden. Aktuelle nutze ich Software seriell um die Hardware Schnittstelle noch zur Verfügung zu haben (ob ich diese jedoch brauche ist fraglich). Ich bin mir nicht sicher ob es Vorteile hätte die Hardware Schnittstelle zu verwenden. - Performance ist noch etwas lahm trotz 115kbaud - 0,2 bis 0,5s bis der Tastendruck übertragen wurde - Datenstruktur - größere Nutzdatenmengen zur Abfrage der Statuus der Slaves, d.h. variable Nutzdatengrößen entsprechend auswerten oder immer z.B. 10 Byte übertragen und bei Bedarf mehrere Blöcke nacheinander übertragen. Bis zum einsatzfähigen Prototyp ist es also noch eine Weile, aber ich bin inzwischen näher dran als bei Erstellung dieses Threads, dank eurer regen Beteiligung - vielen Dank hierfür. Was aber richtig Spaß gemacht hat, war der Moment als der Testaufbau das gemacht hat was er soll. viele Grüße
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.