Mein Forum
Registrieren
Neu hier?
Baukonstruktionen
Fertighaus
Fenster
Dämmung
Dichtheit
Passivhaus
Schimmel
Energieausweis
Heizung
Pellets
Erdwärme
Warmwasser
Stromsparen
Solaranlagen
Photovoltaik
Lüftungsanlagen
Energiespartipps
Berechnungen
Teilen:
|
|
||
|
@taliesin Alles richtige Einwände. Aber genau deswegen läuft die Basis (Rolläden, Licht, Sensorik) komplett auf dem KNX Bus. Der wurde einmal parametriert und seitdem läuft er durch egal ob der Server gerade steht, Purzelbäume schlägt oder sonst etwas macht. Zum Homeassistant. Er läuft in einem eigenen völlig reduzierten OS (https://github.com/home-assistant/operating-system). Updates werden komplett vom Core Team übernommen. Und dass eben nicht nur für den Core (die Software HA), sondern auch für die darunter liegenden Schichten. (Supervisor + OS) Also nix mit ich betreibe einen beliebigen Server und mache dann keine Updates und nach 2 Jahren fällt alles auseinander. Ich betreue selbst in der Arbeit Kubernetes Cluster, also mir ist durchaus bewusst welcher Aufwand hinter professionellen Setups steckt. Genau deswegen möchte ich dass eben zu Hause nicht. Genau deswegen läuft die Basis auf KNX, ein Bus der seit 1994 standardisiert ist und auch in 15 Jahren noch vorhanden sein wird. Ich denke wir sind da in der Denke nicht so weit auseinander. |
||
|
||
|
Genau so lange wie es das tut, inklusive deiner genutzten integrations... und ich hab' immer noch nicht verstanden wofür ich den home-assistant brauch Mach ich eh auch genauso. Das SD-Karten-Thema ist eigentlich keines, lokal werden so gut wie keine Daten geschrieben, geht alles per MQTT ins Netz (wenn's eines gibt). Meine ersten RPi laufen seit 6 Jahren mit der ersten SD-Karte (sandisk ultra). Man könnte wenn man es wild treibt sogar / read-only mounten und /var auf einen USB-stick legen, finde ich aber reichlich unnötig. Diese Zentralisierung ist für mich ein no-go. Wenn einzelne Subsysteme mehr als ihre lokale Daten brauchen, z.B. die Heizung hätte gerne den Wetterbericht, dann holt die den aus dem Netz (LAN oder www) und wenn es nicht funktioniert hat das System seinen fallback. Das gilt auch für den Sensor, der nicht lokal angeschlossen ist. Das ist nicht sehr IOT-ig, keine Frage, aber loose coupling macht fail-safe. |
||
|
||
|
Ich denke es ist relativ sinnlos dich davon zu überzeugen. Ein letzter Satz nur, hier ist eine Visualisierung des gesamten Hauses (aller KNX Komponenten) in weniger als 3 Tagen entstanden. (mit Verläufen etc.) Mit ein paar Skripten ist das in der Qualität + Umfang und diesem niedrigen Zeitaufwand unmöglich zu machen. Es ist eben nicht wirklich sinnvoll das Rad selbst nochmal neu zu erfinden. Aber ich lasse jedem den eigenen Bastel Drang, meines wäre es nicht. Achja was das Argument "mal sehen wie lange es das tut" angeht. Das könnte ich dir hier bei jeder Hardware und Software Komponente um die Ohren hauen. Oder nutzt du kein Linux OS in irgendeiner Form, keinen RasPi, keine Python Libs? All diese Open Source Software und Hardware Komponenten wollen auch gepflegt werden. Wie lange das sein wird weiß keiner. |
||
|
||
|
Ich finde die Viritualisierung ziemlich cool und die Grundfunktionalitäten rennen auch ohne Server, sind ja im Endeffekt alles nur Spielereien. Und Nerds könnten mit Proxmox sogar einen Cluster bauen, falls mal ein System ausfällt. So weit will ich aber nicht gehen, Notfalls steht halt der Server, außer mir merkt es vermutlich eh keiner im Haus😉. |
||
|
||
|
Grundsätzlich ja, aber noch niedriger geht der stack nicht. Ich sag ja nicht, dass das nicht hübsch ist und auch gut funktioniert. Die Hauptfragestellung ist: Wozu? Find ich ja gut, spiele auch ... aber eben nur bei Systemen, wo's mir meine Frau nicht um die Ohren wickelt Ich versuche mal etwas Konstruktives zu sagen, mein 'smarthome', besteht aus: * ein paar Audioservern (Raspberry + Volumio) * der Überwachung der Heizung (NanoPK und UVR1611 für die Solarthermie) * der Auslesung meiner smart meter (Strom) dazu wird kommen: * Überwachung der Lüftung * Optimierung von Heizung und Solarthermie (NanoPK über modbus gesteuert) * ev. ein paar DALI-Leuchten Das Wozu: * Audio ist Spielerei, da ginge auch meist ein einfaches Radio * das Selbe bei DALI, nett wenn man 2-3 Szenen bauen kann, eine Lampe im Raum wird sicher einen Knopf haben um sie non-DALI-mäßig einzuschalten * der Rest ist die Überwachung der Hauptfunktionen im Haus Ich fände halt gut, wenn man in so einem smarthome thread innovative Steuerungsideen lesen könnte, statt dessen kommt immer die noch dickere Infrastruktur-Installation, für quasi nix. |
||
|
||
|
Deswegen steht bei uns genau 1 Mikro Controller Board und genau darauf läuft in Containern HA, InfluxDB und Grafana (alles vom HA Supervisor verwaltet). Dieses eine Ding wird gebackupt. Mehr braucht es nicht. Wenn es ausfällt juckt es nicht weil eben nur Visualisierung und unnötige aber geeky Spielereien. Aber egal was passiert, ich kann den Server jederzeit wiederherstellen. Was daran eine dicke Infrastruktur sein soll frage ich mich schon. Mich würde ja interessieren was für dich innovative Steuerungsideen sind. 😁 Bisher höre ich nur destruktives. Ja ein Smart Home ist immer Spielerei. Ich kann natürlich klassisch installieren. Möchte ich aber nicht. Wir schalten beispielsweise so gut wie nie mehr eine Lampe auf klassischem Weg an. Es wird immer eine Szene ausgewählt bzw sie aktiviert sich passend. Ja auch das ist Spielerei. Aber es macht uns Spaß. Genauso fahren wir seit Einzug keinen einzigen Rolladen mehr manuell oder per App. Die Rolläden werden automatisch vom KNX und dessen Aktoren plus Sensorik bewegt. (Wetterstation etc) Wir lieben es. Muss man es haben natürlich nicht. Aber es macht uns Spaß. 😉 Oder noch ein Beispiel. Ich werde kurz im Homeoffice per Push im Slack informiert dass die Wäsche fertig ist. Dann gehe ich kurz und hänge sie auf. Oder noch ein Beispiel, da ich immer wieder vergesse Fenster zu schließen (ja wir machen auch mit der KWL KWL [Kontrollierte Wohnraumlüftung] mal die Fenster auf), werde ich informiert das Ding zu zu machen. (aber eben nur wenn diese und jene und solche Bedingung). Ich könnte nun hunderte Beispiel aufzählen. Sind sie essentiell zum überleben? Nein. Machen sie uns Spaß. Jap! Für mich persönlich bedeutet Smart wenn sich aus den einzelnen Entitäten (Sensoren, Lichter, etc) und dessen Werten im Haus etwas im Zusammenspiel machen lässt. (Automation eben) Und da habe ich keine Lust diese Daten selbst zusammenzuführen. Denn möchte man das sauber machen braucht man mindestens eine State Machine und einen Eventbus. (rein aus Software Modellierungs Sicht) Möchte ich das selbst in Software umsetzen? Nein sicher nicht. Das hat in meinem Fall der HA Core schon hundert mal besser und eleganter gelöst als ich es je selbst in ein paar Skripten könnte. (als Beispiel hier die Struktur des HA Core https://developers.home-assistant.io/docs/architecture/core) Und genau mit diesem Unterbau hat man alle Möglichkeiten um die von dir geforderten innovativen Lösungen mit wenig Aufwand und sauber umzusetzen. Nicht mehr und nicht weniger. 😊 PS: Wer die volle Power von Homeassistant nutzen will und gerne mit Micro Controllern bastelt sollte sich mal https://esphome.io/ ansehen. 😁 |
||
|
||
|
Das macht die SPS, dann nehme ich diese mal im Thread auf, nachfolgend eine kurze Beschreibung. Der erste Schaltschrank sieht wie folgt aus:  Links oben sind die Mehrstockklemmen für die Netzspannung, darunter der Automatenblock für OG und darunter für EG. Links oben die Mehrstockklemmen für die Tastergruppen bzw. Tür- und Fensterkontakte. Jede Tastergruppe bzw. Kontakt ist mittels Cat7 Kabel in Sternverkabelung angebunden. Darunter befinden sich die Relays für Rollo (keins SMI) und schaltbare Steckdosen (z.B. Nachtkasterlbeleuchtung). Ganz unten befindet sich die SPS von WAGO.  Hier die SPS ein bisschen detailierter. Ganz links befindet sich die Steuereinheit , eine PFC100. Darauf läuft im Endeffekt ein Realtime-Linux-System. Die PFC100 hat zusätzlich noch zwei Ethernetschnittstellen verbaut und ein paar Applikationen verbaut (VPN, Firewall, Webinterface, ...). Daneben befinden sich als steckbare Module die Ein- und Ausgänge. Derzeit habe 182 digitale Eingänge, 62 digitale Ausgänge, zwei analoge Ausgänge, zwei RS-485-Schnittstellen (DMX, Modbus), einmal SMI_Bus und zwei Eingänge für PT100-RTDs verbaut. Die digitalen Eingänge werden in der Masse für die Taster, sowie auch für die Fensterkontakte verwendet. Es hängt aber auch der S0-Ausgang des Energiezählers der WPWP [Wärmepumpe] drauf. Die Ausgänge werden derzeit nur für die Relays verwendet. Die analog Ausgänge sind noch nicht verplant. Die DMX-Bus-Schnittstelle wird für die Ansteuerung der Beleuchtung verwendet. Modbus ist eh selbsterklärend, derzeit mal für die KWL KWL [Kontrollierte Wohnraumlüftung] vorgesehen. Der SMI-Bus dient der Ansteuerung der Raffs und ist sozusagen DALI für die Beschattung. Der Vorteil des Busses liegen in der einfachen Verkabelung (5 poliges NYM) und die Raffs melden die Position des Raffs sowie die Lamellenstellung retour. Die PT100-RTD habe ich auch noch nicht verwendet, nachdem ich alle Teile der Wago auf Ebay gekauft habe, waren diese dabei. Die Programmierung der SPS erfolgt über e!cockpit mit Codesys. Codesys ist nach IEC 61131-3 normiert und an Pascal angelehnt unterstützt aber in der letzten Version schon OOP. Für e!cockpit gibt es von WAGO eine Menge an Libs, wodurch für die Beschattung über SMI nur ein paar Zeilen Code (inkl. automatische Beschattung nach Sonnenstand, Schutz gegen Sturm, Tasterinterpretation, ...) erforderlich sind. Später mehr, die besser Seite möchte Fliesen legen.
|
||
|
||
|
Hallo berhan, hier gibt es dazu Erfahrungen und Preise: berhan's SmartHome Projekt |
||
|
||
|
Mein event bus ist MQTT für Überregionales einer am server, state change events sende ich 'manuell' (state property der Klasse), eine Zeile code:  Regionale events laufen über einen lokalen broker, keine Ahnung ob das super elegant ist, aber zumindest einfach. Und ich will ja gar nicht den home assistant schlecht machen ... mir gefällt einfach die getippte Zeile besser als mich über eine beliebige Anzahl von dialogs durch Konfigurationen zu kämpfen, die sehr viel mehr können als ich brauche. Auf einer Bildschirmseite sehe ich meist alles was es zu verstehen gilt und natürlich erfinde ich z.B. MQTT nicht selber. Ich hab mir mal so einen Feuchteregler HA-blueprint angesehen, weil ich sowas gerade für meinen Keller umsetze: https://community.home-assistant.io/t/switch-a-fan-based-on-absolute-humidity-differnece-between-two-humid-temp-sensors/305686 ... aber das ist ja nicht alles was man da braucht: • Kellertemperatur darf eine gewisses Minimum nicht unterschreiten • der Wärmeaustrag soll nicht beliebig hoch sein, d.h. es wäre wohl wünschenswert jahreszeitlich verschiedene Grenzen zu haben • das Einschalten sollte im erlaubten Zeitfenster stattfinden • die Laufzeit sollte ein Minimum haben, ebenso die Sperrzeit • die Innen- und Außenfeuchten sollte wohl an mehreren Stellen gemessen werden und irgendein Mittelwert oder Median verwendet werden Das hat immer noch alles auf 2 Seiten python code Platz, ich kenne HA nicht gut, aber da wird's ein paar Regeln zu konfigurieren geben ... Ein großer Unterschied, der eventuell auch den Einsatz des HA rechtfertigt, ist euer zentralistischer Ansatz (inklusive Verdrahtung). Erstens habe ich in meinem 1970er Haus keine sinnvolle Möglichkeit 100 Schläuche zusätzlich zu verlegen und zweitens will ich auch keine n000 Euro für eine KNX Installation ausgeben für Meine Raspberries sind eben auch genau die Sensoren und Aktoren vor Ort. Im Heizungsraum dient z.B. eine UVR1611 die über CAN am Raspi hängt als 230V-Schalter und PT1000 Interface. Ein selbstgebautes HAT (hardware attached on top) dient auf der Terrasse als 12V Lampenschalter (9 Stk), 1-wire interface für Temperatursensoren und gleichzeitig läuft am Rapsi Volumio und spielt über einen USB-DAC Musik zum Autoverstärker. Aber ... ich lern ja gerne mal was dazu, ich werde versuchen das Kellerentfeuchten mit dem HA zu lösen, mal schauen wie locker flockig das funktioniert. Vielleicht muss ich den dann ja ganz dringend einsetzen, weil er mich restlos überzeugt hat |
||
|
||
|
Mit dem ganzen HA-Gewürks ganz vergessen berhan für seine saubere Installation zu loben |
||
|
||
|
ist das sarkastisch?... tut mir leid das ich das so sagen muss, aber das ist keine Augenweide. Nicht von der internen Verdrahtung, noch auch nicht vom Anschluss her an den Klemmen. Ausserdem sind die FIs glaub ich nicht mal mit 6mm2 verbügelt und das mit steifen drähten, was nicht sein darf. Schaut von der Zuleitung bis zu den Automaten nicht sehr selektiv aus. Aber sorry, wenn ich Veteiler seh, dann muss ich auch immer was dazu sagen :D |
||
|
||
|
Sind 6 mm² und natürlich alles Litze, zu den Phönix Mehrstockklemmen alles 2,5 mm² auch Litze. Jeder RCD RCD [Fehlerstrom-Schutzschalter] hängt an einem eigenen Neozed über ein xymm-j 5x6. Warum soll ich mich mit einem Draht quälen😎. |
||
|
||
|
dann hat die Optik irritiert, da ich keine Adernendhülsen gesehen habe... :)... |
||
|
||
|
Noch eine Anmerkung, die Zugentlastung erfolgt direkt überm Kasten mit Bügelschellen. |
||
|
||
|
Die bei dem Bild sehen zu wollen ist auch verwegen |
||
|
||
|
Adernenhülsen nimmt man mit Kragen und den sieht man. Ansonsten kann es leicht sein(sogar auch mit Kragen beim biegen) dass Adern blank raussehen und somit kein Berührungsschutz da ist. Der Verteiler muss sowieso versperrt sein, da es keine Klemmen und Automatenabdeckungen gibt und überall spannungsführende Teile sind |
||
|
||
|
Sorry, berhan, wenn ich jetzt ein bisserl deinen thread kapere, aber sehe ich das richtig, dass man so eine Automatisierung wie die Kellerentfeuchtungsgeschichte von oben im HA nur mit der 'script' Komponente https://www.home-assistant.io/docs/scripts/ machen kann? Der eine blueprint (link oben) ist zumindest sowas. Teilweise sieht man den eh, den Rest hätte ich der Bildauflösung zugestanden, aber ok |
||
|
||
|
@denis Magst du was dazu sagen, ich finde keine anderen Möglichkeiten und da du den HA ja verwendest... |
||
|
||
|
Also hier sieht man obenrum schon wie angeschlossen ist. Da hat sich @uzi10 vielleicht gar nicht sooo vertan mit blanken Drähten usw |
||
|
||
|
🤫 psst das hab ich auch gesehen :D |
||
|
||
|
Nochmal, es wurden keine Drähte verbaut, habe ich im übrigen für 6 mm² gar nicht, sind alle in 6 mm² Litze gemacht worden. |
||
|
||
|
Aber fehlende Aderendhülsen sind glaube ich gemeint. |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]