Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Wenn es nun nicht Pflicht wäre, könnte ich dann die Regelung nur mit Temperatursensoren und HS umsetzen? Reicht hier dann der Baustein im GLE aus?
Aber so wie ich das lese, werde ich wahrscheinlich auch auf die MDT-Aktoren umschwenken...
Vielen Dank für die Antworten!
Hendrik, ich hätte eigentlich gedacht, dass Du mit all Deinen lobenswerten Anstrengungen auch etwas gelernt hättest?
Oh, das hoffe ich doch. Hab ich nicht ein Lob für
Ich werde versuchen möglichst viel Intelligenz in die Geräte=dezentral zu packen. Nur was patu nicht geht kommt in eine zentrale Logik.
verdient?
Ausserdem schrieb ich:
Wenn doch geregelt werden soll (werde ich auch machen), kann das auch der Heizungsaktor (nicht jeder kann das; der von MDT kann das) machen (werde ich auch machen).
Sprich: Ich habe eine ERR. Aber ich habe nicht überall einen sündhaft teufen Schalter mit Display, in de mmeine Familie die Temperatur hochstelt, dann weils nicht schnell genug geht noch höher stellt, dann schwitzt, runter stellt, immernoch schwitzt (weils nicht schnell genug geht), weiter runterstellt usw. "Pilot induced Oscillations"
Ich denke, das ist im Sinne der ENEV, da es eine ERR ist. Ich weiss es aber nicht.
ERR via Visu nein
Das interessiert mich. Warum nicht?
du hast keine Stellmotoren, sondern elektrothermische Ventilantriebe.
Na komm, ob da jetzt ein Motor, irgendein bimetall oder ein Heinzelmännchen drin steckt und das Bus-Signal in eine Bewegung umzusetzen ;-)
Aber ich schreib's mir trotzdem hinter die Löffel, ist ja richtig.
Temperatursensoren über Knx und du kannst dir einen zusätzlichen Bus inkl. Gateways inkl. Arbeit sparen.
Ja, guter Punkt, macht mich nachdenklich.
Den zusätzlichen Bus und das Gateway möchte ich für die VOC Sensoren -die es als KNX nicht gibt- ohnehin haben.
Ansonsten gebe ich dir Recht.
Temperatursensoren habe ich aber in den meisten -vielleicht sogar allen Räumen, bin gerade unsicher- auch als KNX Geräte.
ERR ist Pflicht! Wir bleiben im Forum bei der Realität bitte.
Das habe *ich* nicht bestritten.
Ich habe nur gefragt, ob es jemand überprüft (das weiss ich nicht). Und ich halte es für vollkommen legitim dies anzusprechen.
Peter, die ENEV ist im Internet online. Wenn ihr euch in der Schweiz damit nicht auseinander setzen müsst, ist das prima. Bei uns in Deutschlands siehts halt anders aus. Vermutlich wäre das Ding in der Schweiz beim Bürger durchgefallen...
Ich denke mal, Sensor + MDT Aktor erfüllen sogar das, was die ENEV da fordert.
Henry. Nein es prüft niemand. Es prüft auch niemand, wie dick Deine Dämmung wirklich ist usw. usf. Letztlich ist es Dein Bauherrenproblem, die Abgabe der ENEV Berechnung hast Du ja dem Bauantrag beigefügt. Nachdem ich mir das aber in zwei ENEV Büros angeschaut habe, wra mir klar, das die allermeisten Häsuer wohl wesentlich schlechter sind als das, was da auf dem Papier berechnet wurde... Daber das ist eine ganz andere Sache.
Derzeit zwischen Kistenauspacken und Garten anlegen.
Baublog im Profil.
ich hatte am Donnerstag die Pläne eines EFH-Neubau's in Berlin in Händen auf konventionelle Elektroinstallation.
EG:
1x ERR Wohnen/Essen/Küche
1x ERR Windfang
1x ERR Gäste-WC
1. OG:
1x ERR Kinderzimmer
1x ERR Schlafzimmer
1x ERR Bad
DG:
1x ERR Studio
Alle Räumlichkeiten besitzten eine ERR. Es gibt keinen Keller.
Somit wurde alles auf KNX-ERR 1:1 umgesetzt und geplant.
Gäste-WC und Windfang auf BWM mit Temp.-Fühler
Alle anderen Räume mit Taster inkl. Temp.-Fühler
Aktorik MDT Heizungsaktor
Sollwert wird im Heizungsaktor vorgegeben
Nachtabsenkung via Zeitschaltuhr
Abwesenheit via Türschloss (2x Absperren)
Sollwertänderung und Anzeige Ist-Werte, sowie Ventilstellungen über Minivisu (KNX-Gerät, welches Webserver enthält).
Keine Logiken erforderlich
Kein zweites Bussystem erforderlich
Funktionalität bleibt komplett auf KNX-Geräten
Visu greift unabhängig auf Datenpunkte zu
Fensterkontakte zusammengefasst pro Raum wirken auf entsprechenden Kanal der ERR wg. Frostschutz (10 Grad).
Unkompliziert, kostengünstig, einfach und locker bedienbar, wie auch planbar. Kunde spart sogar noch die Löcher und die Installation der separat (vorher konventionell) geplanten Löcher für die RTRs auf 145cm ein, welche nun nicht mehr benötigt werden. Ebenso spart er die direkte Verkabelung vom konventionellen RTR zum Heizkreisverteiler, da nun alles via KNX-Bus läuft (auf dem grünen Kabel).
Komfortgewinn:
Gäste-WC / Windfang: Keine Bedienelemente in den Fliessen oder in der Wand. Licht geht ein bei Bedarf und alleine wieder aus. Für Gäste kein "Lichtschaltersuchen".
Übrige Räumlichkeiten: Kein zusätzlicher RTR auf 145cm
Fensterkontakte werden zusätzlich für Öffnungsanzeige verwendet. ("Hab ich ein Fenster vergessen zu schliessen, bevor ich gegangen bin?")
Fensterkontakte bei Terrassen-/Balkontür öffnen automatisch die Jalousie. (Wenn gewünscht).
Visualisierung auf SmartPhone für weitere Funktionen nutzbar (erweiterbar nach Kundenwunsch).
Kein extra Bediengerät/Touchpanel für Raumtemperaturregelung erforderlich (da eventuelle Bedienung über Visu läuft auf irgendeinem SmartPhone oder Pad).
Kein Designbruch bei den Bediengeräten (da nicht vorhanden)
Vorteil für die Planung:
Alle Funktionen auf KNX-Geräte-Basis mittels ETS (inkl. Fernwartung)
Durchgängiges Konzept ohne "Gepfriemel" in irgendwelchen "Gateways oder Controllern".
Visualisierungs-Endgeräte unabhängig und zukünftig ohne Aufwand austauschbar (Egal, ob Windoof, Android oder iOS))
Meine Strategie ist eben die Planung so übersichtlich und einfach zu halten, wie es geht. Siehe letzten Betrag zum Thema "EFH in Berlin". Das hat für alle Projekt-Beteiligten Vorteile.
Zudem sind nach meiner Strategie die Endgeräte austauschbar zu halten. Plant man das nicht so, wird man feststellen, dass bei Ausfall des "externen Controllers" Teile des Systems nicht mehr funktionieren. Das ist für mich ein NoGo!
Professionelle Leitsysteme setzen auf die DDC-Controller (hier dezentrale KNX-Geräte) auf. D.h.: Die Datenpunkte werden in das Leitsystem importiert und auf der "Visualisierung" angezeigt und bedient. Es sind keinerlei Logikfunktionen - auch keine RTR - im Leitsystem nachgebildet.
Warum macht man das so?
Systemsicherheit
Fällt das IP-Netzwerk oder einzelne Komponenten aus, so läuft die Gebäudeautomation störungsfrei weiter.
Wartbarkeit
Wird das Leitsystem gewartet, erweitert oder angepasst, so läuft die Gebäudeautomation störungsfrei weiter.
Bedenke: Der Errichter übergibt das fertige System an den Betreiber. Der Betreiber beauftragt seine Servicemannschaft, die dann das System wartet. Sind die Einzelsysteme nicht unabhängig zu warten, gibt es immer Ärger.
Zukunftssicherheit
Werden die Anzeigeeinheiten (Monitore, Server, Switche etc.) ersetzt oder erneuert, so läuft die Gebäudeautomation störungsfrei weiter.
Betriebssystemfreiheit
Egal auf welchem Endgerät: Die Visualisierung sollte (in meinen Augen "muss") darauf vorbereitet sein. Kommt es zu einem Wechsel der Firmeninternen Strategie von einem Betriebssystem auf ein neues umzusteigen oder dieses auch nur "upzudaten", so muss das Leitsystem hierfür geeignet sein ohne Anpassung weiter zu laufen.
Endgeräte-Offenheit
Egal welches Endgerät genutzt wird, sollte die Visualisierung hierfür ohne Zusatztools oder "APPs" ohne zusätzliche Kosten funktionsfähig sein.
Aufteilung der Zuständigkeiten
Sind die Funktionen in den Busgeräten, kann ich die Gebäudeautomation klar vom Leitsystem trennen. Das Leitsystem kann dann die Firma xyz unabhängig von mir nach der Übergabe der Datenpunkte unabhängig erstellen, austauschen, ersetzen. Der Schnittpunkt ist klar definiert.
In meiner kurzen Selbstständigkeit (seit Ende August) habe ich bereits 2 Projekte bekommen, in welchen Systemkomponenten von Visus augefallen sind, und dadurch die Gebäudeautomation in Mitleidenschaft gezogen wurde. Das ist nicht akzeptabel für den Endkunden und bringt nur Schwierigkeiten und Ärger (und mitunter unverhältnismässig hohe Kosten) mit sich.
Die Funktionen gehören in die DDC-Geräte (hier KNX-Busgeräte) - Die Visu ist als HMI zu nutzen. Punkt.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar