Steuerung für eine Zentrale Lüftungsanlage (KWL Kontrollierte Wohnraumlüftung)

Begonnen von SvenJust, 24 Januar 2018, 11:16:05

Vorheriges Thema - Nächstes Thema

Starsurfer

Moin,
schön erst einmal das es noch weiter geht :-) Wird immer besser.
Die Ausgabe des TFT's sieht interessant aus.

Ich habe die Sensoren direkt oben an den Ein-/Ausgängen platziert indem ich unter den Rohren Löcher gebohrt habe.

@herr_frei
Ich hätte auch Interesse an den Platinen, allerdings mangels Zeit, wäre ich an einer fertigen Platine interessiert.
FHEM Server: Fujitsu Esprimo q920 + LaCrosseGateway + HM-MOD-RPI-PCB WLAN + ConBee
HomeMatic HM-CC-RT-DN - Sonoff Tasmota
LaCrosse TX29DTH - Innr SP120 - Osram Smart+ Plug
Arduino Mega - MQTT - Pluggit 300
https://www.diy-robot-lawn-mower.com

Strubbel

Hallo zusammen,

nachdem meine pluggit 300 auch gerade den Geist aufgegeben hat, und mir die Reparaturvorschläge einigermaßen unkoordiniert und teuer vorkamen, bin ich mit Freude auf eure Threads gestoßen.
Auch ich wäre interessiert, wenn es irgendwie eine Möglichkeit gäbe so eine Platine zu bekommen, da ich eher aus der Hobby-Programmier-Ecke zu FHEM komme als über die Elektro-Hardware.

Vielen Dank aber auf jeden Fall schonmal für die ganze Mühe die ihr euch macht und auch noch teilt!
Strubbel


Starsurfer

FHEM Server: Fujitsu Esprimo q920 + LaCrosseGateway + HM-MOD-RPI-PCB WLAN + ConBee
HomeMatic HM-CC-RT-DN - Sonoff Tasmota
LaCrosse TX29DTH - Innr SP120 - Osram Smart+ Plug
Arduino Mega - MQTT - Pluggit 300
https://www.diy-robot-lawn-mower.com

herr_frei


SvenJust

Zitat von: Starsurfer am 01 Dezember 2018, 11:59:45
Huhu noch jemand da?

Ich habe mir zwischenzeitlich die zwei Platinen von Torsten (herr_frei) bei jlcpcb.com fertigen lassen und habe am WE die Bauteile (Widerstände, Optokoppler, Buchsen) auf der Arduino-Platine aufgebaut. Für die Verbindung zum LAN-Shield habe ich Buchsenleisten mit langen Pins verwendet. Mit einer weiteren Reihe gesteckter Buchsenleisten lässt sich auch das Display oberhalb von Torstens Platine anschließen. Kurzer Hinweis: Die Relais funktionieren nicht mit der Software von Ivan und meinem alten Softwarestand, da Torsten die Anschlüsse auf andere Arduino-Pins gelegt hat.

Für die nächsten Schritte würde ich gerne die Doku mit dem Schaltplan, der Software und der Platine auf einen einheitlichen Stand bringen.

VG Sven
FTUI, Raspberry PI/SSD, CUL CC1101, HMLAN, 10x HM-LC-Bl1PBU-FM, HM-LC-Sw4-WM (KWL Pluggit P300), HM-WDS30-OT2-SM (Sonnensensor), HM-Sec-SCo, LW-12 Wifi LED, CUL Selbstbau nanoCUL 433 (IT), Arduino (S0-Stromverbrauch), OW DS2480 (OWX_ASYNC) 8x DS18B20, MQTT (Fröling P4), MYSENSORS (Roto Rollläden)

herr_frei

Hallo Sven,

das hatte ich vergessen zu erwähnen... Sorry!

Die Idee, die Doku zu vervollständigen ist super. Ich würde mich gern dabei einbringen!

Torsten

Gesendet von meinem SM-G960F mit Tapatalk


azmodan2k

Hallo zusammen,

ich bin heute über das projekt gestolpert und habe sehr interessiert alle threads dazu gelesen, dies wird mein nächstes projekt zur erweiterung meines smarthomes.

Eine sache, die mir gleich aufgefallen ist ... ich finde es genial, dass ihr gleich auf mqtt gesetzt habt, aber warum beschränkt ihr das topic so stark? also einmal den prefix und im generellen das gesamt topic? eine, für mich, wirklich beispielhafte implementierung der topic steuerung findet man bei tasmota (wer es kennt, der wird wissen, was ich meine) ... dort setzt man replacements für device und topics (in eurem fall können die topic defs ja starr sein) und das wirklich wichtige, jedenfalls für mich, man kann diese replacements zur definition des gesamttopics verwenden.
also das soll keinerlei vorwurf für die implementierung sein, aber eventuell ein neuer punkt für die todo liste, sodass jeder, der die steuerung nachbaut, diese auch nach seinen sicherlich schon vorhanden regelungen für die topic def einbinden kann.
ich werde mir das repo mal runterladen und durch schauen, vielleicht ergibt sich mir eure verwendung der harten topics. über eine antwort würde ich mich dennoch freuen.

grüße
stefan

schreter

Hi Stefan,

Zitat von: azmodan2k am 09 Dezember 2018, 10:21:38
Eine sache, die mir gleich aufgefallen ist ... ich finde es genial, dass ihr gleich auf mqtt gesetzt habt, aber warum beschränkt ihr das topic so stark? also einmal den prefix und im generellen das gesamt topic? eine, für mich, wirklich beispielhafte implementierung der topic steuerung findet man bei tasmota (wer es kennt, der wird wissen, was ich meine) ... dort setzt man replacements für device und topics (in eurem fall können die topic defs ja starr sein) und das wirklich wichtige, jedenfalls für mich, man kann diese replacements zur definition des gesamttopics verwenden.

Das verstehe ich nicht ganz. Der Präfix des Topics ist doch konfigurierbar, der Rest sollte auch starr sein, damit man vernünftig Skripte kodieren kann. Noch zusätzlich die DeviceID als Teil des Topics zu schicken wäre sicherlich machbar, aber auch overkill (da es eh von Präfix abgeleitet ist). Wieviele Anlagen willst du denn anschliessen? Die meisten werden exakt eine haben. Ich habe die Konfiguration des Präfixes eingebaut, damit man besser testen kann (eine echte Anlage und ein Testsystem). Den Präfix kann man sogar per MQTT einstellen. Es ist IMHO absolut ausreichend...

Kannst du vielleicht Beispiele schicken, was du genau meinst und wie deiner Meinung nach die Topics aufgebaut werden sollten? Die tasmota kenne ich nicht und ich weiss nicht wonach ich suchen sollte. Ich habe lediglich irgendwelche Sonoff Switches mit Tasmota Firmware gefunden, aber keine Links dort auf was das sein sollte (allzu lange habe ich aber nicht gesucht). Die Beispieltopics in der Doku dort sehen aber gar nicht anders aus als bei uns - nur eine konfigurierbare Komponente im Pfad mit Namen des Switches. Das einzige Unterschied ist, dass der Name nicht auf erster, sonder an der zweiten Stelle steht. Es wäre vielleicht einer Überlegung wert die 'kwl' Komponente noch vor den Präfix zu schieben, aber aus Kompatibilitätsgründen ist dies nicht so ohne Weiteres möglich (ich wollte die Topics etwas aufräumen, aber wir brauchen dann trotzdem die alten zu unterstützen (sprich: in Migrationsphase 2x senden), damit es in bestehenden Systemen zu keinen Problemen kommt.

Danke & Gruss,

Ivan

azmodan2k

hallöchen,

ja beispiele hätte ich gleich mal mit anhängen können.
nochmal ganz kurz auf meine erste ausführung zurückkommend ... ich hatte irgendwo gelesen, dass der prefix nur xx zeichen lang sein darf, also kann ich maximal folgende gesamt topic konfigurieren (ich habe examplarisch mal nur eins aus eurer doku genommen)

<irgendeinTopicMitMaximalXXZeichen>/state/kwl/aussenluft/temperatur

was ich und sicherlich auch viele anderen möchten wäre z.B. folgendes:
- konfigurierbarer prefix - z.B. /SmartHome/Erdgeschoss/HWR
- konfigurierbare deviceID - z.B. Belueftung
- konfigurierbares gesamt topic - z.B. %prefix%/%deviceID%/

somit würden sich folgende topics ergeben

--> /SmartHome/Erdgeschoss/HWR/Belueftung/state/aussenluft/temperatur

ich habe mittlerweile knapp 60 komponenten die per mqtt arbeiten im haus verbaut und deshalb auch eine gewisse logik in meinem aufbau des mqtt topics ... damit lassen sich sinnvoll gruppen steuerungen abarbeiten und zwar basierend auf dem topic pfad ... bzw. subscriber können auch nur auf bestimmte teilabschnitte der hausautomatisierung per mqtt subscriben und reagieren.

ich hoffe, dass ich damit ein wenig klarer erklären konnte, was ich meine.

was denkt ihr dazu?

ps: mal noch ein screenshot von der firmware "tasmota" ... dies ist eine generelle firmware für sehr viele esp82 devices. sie ist frei konfigurierbar, welche devices an den esp angeschlossen sind ... deshalb auch verstärkt die unterstützung von dynamischen topic definitionen. es können pro esp xx devices konfiguriert werden ... deshalb auch die deviceID, hoffe damit wird es ein wenig klarer.

und der prefix steht bei tasmota in einem anderen zusammenhang, damit definiert man wo z.B. cmds oder stats als teil des topics steht ... also nicht verwirren lassen.

deviceID konfigurierbar zu machen ist bei euch sicherlich nicht zwingend nötig, da man meist nur eine kwl im haus verbaut hat. an meinem wemos in der garage sind 6 devices angeschlossen, d.h. es gibt 4 relais und 2 sensoren ... da ist es zwingend erforderlich, dass man konfigurierbare deviceIDs hat.
kleine beispiele für die verwendung der topic pfade. ich kann somit zb
- alle lampen im erdgeschoss auschalten
- alle lampen im erdgeschoss/wohnzimmer ausschalten
- ich kann den status von allen devices im obergeschoss abrufen und verarbeiten
- ich kann ein firmware update auf alle devices oder einen teil meiner struktur anstossen (bei euch kein passendes bespiel, aber ich wollte die möglichkeiten darstellen)

mqtt ist nicht nur durch sein protokoll und infrastruktur so stark, sondern auch durch die flexibilität über die topic definition. wenn man jetzt noch den schritt weiter geht, dann spare ich mehr sehr viel logik, die ich in fhem über attribute und konfiguration abbilden muss zwecks gruppierung oder sonst was, da ich diese ohne weiteres und vorallem ohne fhem, also wieder ein schritt weiter in richtung autark funktionierenden komponenten, über mqtt abbilden kann ... und vorallem ich kann mqtt mit alles was einen stecker hat auch entsprechend ansprechen.

danke und grüße
stefan

SvenJust

Hallo Stefan,

danke für Ausführungen zu den MQTT Topics, die ich durchaus nachvollziehen kann. Der Leitgedanke für den Aufbau der MQTT Topics in diesem Projekt ist ein Prefix für den Ort der Lüftungsanlage (d15), dann ein String für Kommando oder Status und nachfolgend eine Bezeichnung für den Sensor, Aktor oder Kommando der Steuerung. Die MQTT Topics sind in der Datei https://github.com/svenjust/room-ventilation-system/blob/master/Docs/mqtt%20topics/mqtt_topics.ods und im Sourcecode MQTTTopic.hpp dokumentiert.

Kompatibilität
Grundsätzlich sehe ich die Kompatibilität bei der Weiterentwicklung der Steuerung als einen der wichtigsten Punkte bei dieser Entwicklung, wenn die Steuerung bei unterschiedlichen Benutzern über einen langen Zeitraum eingesetzt werden soll. Wenn ein Update der Steuerung dazu führt, dass die übergeordnete Haussteuerung angepasst werden muss, ist die Akzeptanz bei den Nutzern gering und der Kommunikationsaufwand nach dem Update hoch. Durch die Änderung der MQTT Topics geht die Kompatibilität zu vorhandenen Programmversionen verloren.

Komplexität bei Nachbau und Inbetriebnahme
Der Nachbau und der erfolgreiche Einsatz dieser Steuerung ist nicht ganz trivial. Die Hardwareteile müssen beschafft, aufgebaut und an die Lüftungsanlage angeschlossen werden. Die Lüfter arbeiten mit 230V Netzspannung, der Aufbau muss gegen Feuchtigkeit, durch Installation am geeigneten Platz, gesichert werden. Die meisten Anwendern integrieren die Steuerung in die Haussteuerung. Eine freie Definition der MQTT Topics zur Laufzeit, wie bei Tasmota, erhöht die Komplexität auf der Softwareseite weiter. Eine Neudefinition der MQTT Topics im Sourcecode ist aber nach Belieben für jeden Anwender möglich ist.

Ich kann keine Verbesserung für alle Anwender erkennen, wenn die MQTT Topics geändert werden. Die Kompatibilität zur aktuellen Version geht verloren und die vorhandenen Anwender müssten ihre übergeordnete Steuerung anpassen. Durch den Aufbau des Programmcodes kannst Du problemlos für Dich MQTT Topics ändern, die zu Deinem Namensschema passen. Wenn Du mir einen Patch (ähnlich wie für UserConfig.h) lieferst, der eine benutzerspezifische Definition der MQTT Topics zum Zeitpunkt der Kompilierung, integriert, nehme ich den Patch gerne in den Sourcecode auf.

VG Sven
FTUI, Raspberry PI/SSD, CUL CC1101, HMLAN, 10x HM-LC-Bl1PBU-FM, HM-LC-Sw4-WM (KWL Pluggit P300), HM-WDS30-OT2-SM (Sonnensensor), HM-Sec-SCo, LW-12 Wifi LED, CUL Selbstbau nanoCUL 433 (IT), Arduino (S0-Stromverbrauch), OW DS2480 (OWX_ASYNC) 8x DS18B20, MQTT (Fröling P4), MYSENSORS (Roto Rollläden)

azmodan2k

Hi Sven,

danke für deine Ausführung.
Ich werde diese Wintersaison das Projekt Lüftersteuerung umsetzen, aber da werden sicherlich noch ein paar tage ins land gehen. ich ziehe mir mal das repo und schaue mal drüber, ob sich ein gesunder mittelweg finden lässt ... sofern ich was habe, sage ich dir gerne bescheid, sodass du drüber schauen kannst und deine beurteilung dazu abgeben kannst.

nochmals danke für eure initiative ... wirklich ein geiles projekt!

grüße
stefan

schreter

Hi Stefan,

Zitat von: azmodan2k am 10 Dezember 2018, 13:47:50
Ich werde diese Wintersaison das Projekt Lüftersteuerung umsetzen, aber da werden sicherlich noch ein paar tage ins land gehen. ich ziehe mir mal das repo und schaue mal drüber, ob sich ein gesunder mittelweg finden lässt ... sofern ich was habe, sage ich dir gerne bescheid, sodass du drüber schauen kannst und deine beurteilung dazu abgeben kannst.

Mein Vorschlag wäre eine Konfiguration des Typs constexpr FlashStringLiteral in KWLConfig einzubauen, per Default leer, die in UserConfig.hpp gesetzt werden kann und für alle Topics als Präfix verwendet wird. Das wäre der Mittelweg (die Topics sind eh aus mehreren Komponenten zusammengebaut, auf einen extra kommt es nicht an. Topicaufbau ist in NetworkClient.cpp verschalt, zur Zeit mit einem Präfix. Aber man kann zusätzlichen einbauen.

Gruss,

Ivan

vscope

Zitat von: SvenJust am 01 März 2018, 11:04:44
Ich habe meine Sensoren auch direkt neben den Pluggit Sensoren verbaut, allerdings weichen meine Messwerte auch stark von den Pluggit Werten ab. Ich vermute, Pluggit korrigiert die gemessenen Werte und rechnet die angezeigten Werte schön. Aktuelle Werte bei mir (mit Vorheizregister, welches die Außenluft von -7.2 auf -2.0 Grad aufheizt)

Außentemperatur Garten    -7.2
T1 Temperatur Außenluft   -2.0
T2 Temperatur Zuluft      16.8
T3 Temperatur Abluft      18.1
T3 Temperatur Abluft DHT  22.7
T4 Temperatur Fortluft     6.6

Die Temperatur "T3 Temperatur Abluft DHT" wird vor dem Abluftfilter gemessen, die Temperatur "T3 Temperatur Abluft" wird direkt hinter dem Filter gemessen, hier ist schon ein Unterschied von 4.6 Grad. Bei der Zuluft messe ich in den Zimmern direkt 22 Grad. Das Haus ist allerdings auch komplett auf 23 Grad aufgeheizt...
Danke.

Hallo Sven,
Nochmals Gratulation zu deinem tollen Projekt.
Meine Pluggit läuft noch auf meinem Homebrew ESP8266 Controller mit Webinterface zur Steuerung

Warum ich so ein altes Topic raushole.
Habe genau die gleiche Erfahrung gemacht.
Die Pluggit hat intern extreme Leckagen.

Habe bei mir den Sommerbypass im Winter komplett abgeklebt.
Das brachte schon mal Besserung.
Dann auch vorne die Einzelnen Kammern zum WT abgeklebt.
Das brachte auch noch was.
Nun ca. 82% effektiv in der Pluggit gemessen.
Werd mir jetzt ein eigenes Gehäuse aus Holz/EPS ohne Sommerbypass bauen. (nach dem Prinzip siehe PDF Explosionszeichnung https://www.master.ca/documents/produits/1Sell-sheet-silver-series-60h-v-90h-v-90h-v-ecm-hrv-90h-v-ecm-erv.pdf, simpel und strömungstechnisch optimal, ohne klappen fürs erste, bestehende lüfter gehäuse der p450 kann ich man sogar verwenden, müssen nur einer links und einer rechts eingeschoben werden, die defrost funktion (siehe pdf) ist dort schlau gelöst. die klappe fördert die abluft beim defrosten wieder ins haus, kein unterdruck...)
(Bei mir steht die Pluggit im einem wenig beheizten Raum 12Grad und da ist die Dämmung der Pluggit nach außen auch relevant)
Schätze mit einem guten Gehäuse schafft die Pluggit locker 90% bei 150m3 und braucht wenig strom.
Also falls du das Anbkleben noch nicht gemacht hast. Probiers aus. Dauert nicht lange und bringt einiges an zusätzlicher Effizienz.

lg

SvenJust

Hallo vscope!

Zitat von: vscope am 14 Dezember 2018, 22:30:12
Werd mir jetzt ein eigenes Gehäuse aus Holz/EPS ohne Sommerbypass bauen. (nach dem Prinzip siehe PDF Explosionszeichnung https://www.master.ca/documents/produits/1Sell-sheet-silver-series-60h-v-90h-v-90h-v-ecm-hrv-90h-v-ecm-erv.pdf, simpel und strömungstechnisch optimal, ohne klappen fürs erste, bestehende lüfter gehäuse der p450 kann ich man sogar verwenden, müssen nur einer links und einer rechts eingeschoben werden,

Ein sehr interessanter Ansatz, die gesamte Anlage selbstzubauen. Gibt es irgendwo im Netz mehr Informationen zu Deinem Projekt? Falls nicht, würde ich mich freuen, wenn Du uns hier auf dem Laufenden hältst...

VG Sven
FTUI, Raspberry PI/SSD, CUL CC1101, HMLAN, 10x HM-LC-Bl1PBU-FM, HM-LC-Sw4-WM (KWL Pluggit P300), HM-WDS30-OT2-SM (Sonnensensor), HM-Sec-SCo, LW-12 Wifi LED, CUL Selbstbau nanoCUL 433 (IT), Arduino (S0-Stromverbrauch), OW DS2480 (OWX_ASYNC) 8x DS18B20, MQTT (Fröling P4), MYSENSORS (Roto Rollläden)

Starsurfer

Da meine Anlage auf dem ungedämmten Dachboden steht, wollte ich mich mal ran setzten und das Gehäuse von außen mit Styrodurplatten verkleiden. Sollte auch schon einiges bringen. Ausserdem sind alle meine Rohre komplett in Dämmung eingepackt.

Aber ein komplett neues gedämmtes Gehäuse wäre sicherlich auch eine Alternative.
FHEM Server: Fujitsu Esprimo q920 + LaCrosseGateway + HM-MOD-RPI-PCB WLAN + ConBee
HomeMatic HM-CC-RT-DN - Sonoff Tasmota
LaCrosse TX29DTH - Innr SP120 - Osram Smart+ Plug
Arduino Mega - MQTT - Pluggit 300
https://www.diy-robot-lawn-mower.com