[Skript] Absolute Feuchte berechnen
-
-
Danke!
Ich schau am Montag, ob es noch Karten und Zimmer gibt und es zeitlich passt (wahrscheinlich). Wäre eine coole Sache.
-
Die anderen Werte sind Abstandswerte, damit es nicht bei Grenzwerten hin- und herspringt. `
Ja, wobei die negativen Werte sowohl im if- wie auch im if else-Zweig unter der Berücksichtung von (trotz Offsetkorrektur) verbleibenden Ungenauigkeiten die Außentemperatur und der Aussenfeuchtegehalt immer niedriger sind als die zugehörigen Innenwerte.Die Differenz der subtrahierten Werte im if-Zweig verglichen mit dem if else-Zweig bildet die Hysterese. `
Hi Paul,
kannst Du ganz praktisch zu der Formel zur Lüftungsempfehlung was sagen.
Wenn ich bei der Übernahme Deiner Berechnung keinen Fehler gemacht habe, bekomme ich z.B. jetzt fürs Schlafzimmer eine Lüftungsempfehlung.
Werte Schlafzimmer:
Temperatur: 21,6°C
absolute Luftfeuchte: 8,2 g/kg
(und rel. Luftfeuchte: 51%, als ich vorher geschaut habe 46%)
Werte Aussen:
Temperatur: 17,7 °C
absolute Luftfeuchte: 5,4 g/kg
Bei 51%, bzw. 46% relative Luftfeuchtigkeit hätte ich vorher gesagt, dass der Wert optimal ist.
Nun bekomme ich die Empfehlung zu lüften.
(anscheinend im Grenzbereich, während ich das tippe (das Fenster ist auf Kipp) haben sich die Werte oben leicht geändert und die Empfehlung lautet nun false)
Wäre es gerade wirklich nützlich und empfohlen oder ist es einfach wg. der Formel, dass sie auch "reagiert", wenn es nicht kontraproduktiv wäre?
Ich danke Dir für Deine Mühe!
Viele Grüße,
Michael
-
Die Lüftungsempfehlung vergleicht nur die absolute Außen- und Innenfeuchte unter Berücksichtigung einer Hysteriese und der Mindesttemperatur innen.
Die Empfehlung bezieht sich also darauf, dass du die Luft innen trockener bekommst. Das Problem hat man aber nur im Bad, Keller, Wintergarten. Normal sollte die Feuchte in Wohnräumen bei 50-60% liegen als Wohlfühlfeuchte. Höhere Feuchte begünstigt Schimmel und rostendes Werkzeug, alles ab 70% ist zu hoch.
Mein Abwandlung des Scriptes von Paul hat deshalb eine mindest, und maximalfeuchte. Damit nur gelüftet wird wenn es tatsächlich zu feucht wird.
Gesendet von iPhone mit Tapatalk
-
Normal sollte die Feuchte in Wohnräumen bei 50-60% liegen als Wohlfühlfeuchte. Höhere Feuchte begünstigt Schimmel und rostendes Werkzeug, alles ab 70% ist zu hoch. `
Dem kann ich nur zustimmen, allerdings kann man über den gaaanz dicken Daumen sagen, dass eine Abkühlung um 10°C die relative Feuchte verdoppelt.Wenn es also im Sommer drausse 35°C ist und es ca. 40% Feuchte hat, habe ich immer Probleme meinem mir gesetzlich angetrauten Glück zu erklären, dass die Luft, wenn sie denn ins Haus kommt dort 80% Feuchte haben wird und dann im Keller niederschlagen wird.
Dafür habe ich dann die Lüftungsempfehlung (noch unter dashui) visualisiert. Damit im Sommer eben NICHT tagsüber gelüftet wird.
Gruß
Rainer
-
Werte Schlafzimmer:
Temperatur: 21,6°C
absolute Luftfeuchte: 8,2 g/kg
(und rel. Luftfeuchte: 51%, als ich vorher geschaut habe 46%)
Werte Aussen:
Temperatur: 17,7 °C
absolute Luftfeuchte: 5,4 g/kg
Bei 51%, bzw. 46% relative Luftfeuchtigkeit hätte ich vorher gesagt, dass der Wert optimal ist.
Nun bekomme ich die Empfehlung zu lüften.
(anscheinend im Grenzbereich, während ich das tippe (das Fenster ist auf Kipp) haben sich die Werte oben leicht geändert und die Empfehlung lautet nun false)
1. absolute Feuchte Aussen viel geringer als Innen –> Lüften
2. Temperatur Aussen viel geringer als Innen --> Lüften
3. Temperatur Innen 21,6 °C --> Lüften hängt vom programmierten Grenzwert für den Auskühlschutz (Werte ganz rechts) ab. Hier wird wohl der Grenzbereich liegen.
Für die Lüftungsempfehlung müssen alle 3 Bedingungen "Lüften" ergeben (UND-Verknüpfung).
-
Wäre es gerade wirklich nützlich und empfohlen oder ist es einfach wg. der Formel, dass sie auch "reagiert", wenn es nicht kontraproduktiv wäre?
Kontraproduktiv wird die Empfehlung zu lüften erst bei rel. Raumfeuchten um oder unter 30 % (trockener Mund, Atemwege). Man sollte bedenken, dass die Zimmerwände ein erhebliches Feuchtespeichervermögen haben und je trockener die Wände, desto länger bleibt es bei schwülem Wetter (im Sommer) angenehm im Raum (bei dann geschlossenen Fenstern). Trockene Wände erhält man nur bei niedriger durchschnittlicher absoluter Luftfeuchte.
-
Wäre es gerade wirklich nützlich und empfohlen oder ist es einfach wg. der Formel, dass sie auch "reagiert", wenn es nicht kontraproduktiv wäre?
Kontraproduktiv wird die Empfehlung zu lüften erst bei rel. Raumfeuchten um oder unter 30 % (trockener Mund, Atemwege). Man sollte bedenken, dass die Zimmerwände ein erhebliches Feuchtespeichervermögen haben und je trockener die Wände, desto länger bleibt es bei schwülem Wetter (im Sommer) angenehm im Raum (bei dann geschlossenen Fenstern). Trockene Wände erhält man nur bei niedriger durchschnittlicher absoluter Luftfeuchte.Danke für die Erläuterungen!
-
Nun habe ich mir schon 2 digitale Multisensoren von Texas Instruments besorgt:
Den "Texas Instruments CC2650".
…vielleicht wäre das mal für jemanden ein Projekt, einen Adapter für iobroker dafür zu schreiben.
Warum gleich einen Adapter ? Mit dem npm-Modul [https://www.npmjs.com/package/sensortag](https://www.npmjs.com/package/sensortag), das in der JS-Konfiguration mit installiert werden muss ("Zusätzliche NPM-Module"), sollten die benötigten Funktionen für JS zur Verfügung stehen.Hi Solar,
danke für den Tipp! Habe heute meinen Ti CC2650 erhalten und ein bisschen gespielt. Über das iPhone beeindruckend. Die Anbindung an ioBroker hat für einen ersten Test auch schon einmal funktioniert. Ich glaube ich werde mir davon noch ein - zwei bestellen
Hast Du schon was gemacht?
Ansonsten überlege ich mir, ob das nicht doch ein Thema für ein Adapter ist. So ganz trivial ist es mit JS auch nicht.
Viele Grüße,
Michael
[EDIT]
Was liefert der Sensor:
-
Zwei Tasten. Man kann abfragen, ob eine Taste gedrückt wurde
-
Umgebungstemperatur
-
IR-Temperatur (da weiss ich noch nicht, wofür
-
Luftfeuchtigkeit
-
Barometer
-
3-Achsen Beschleunigungssensor
-
3-Achsen Magnetfeldsensor
-
3-Achsen Gyroskop
-
Lichtsensor (in Lux)
-
I/O Service (schaltet einen Buzzer (recht leise), eine rote LED und eine grüne LED
Was ich noch nachschauen muss, ob man auch den Batteriestatus abfragen kann.
Was gesteht werden muss:
-
Reichweite
-
Batterielaufzeit
Bin auf jeden Fall schon einmal begeistert.
Hatte z.B. eine Möglichkeit gesucht einfache Statusanzeigen ohne ein Tablett, PC oder hue zu visualisieren. Kann mir da die LEDs ganz gut vorstellen.
Mal sehen
-
-
Ja bitte! Ich bin für einen Adapter!
Mir ist das Thema noch eine Nummer zu hoch mit JS. Meine beiden Sensoren liegen noch herum.
Mit dem iPhone habe ich auch das Problem, dass die Sensoren nach ein paar Minuten in den Ruhestand (oder aus?) gehen, nachdem ich die iPhone App geschlossen habe. Ich kann danach erst wieder darauf zugreifen, wenn ich die Sensoren per Hand anschalte. Das wäre etwas blöde…
edit zu deinem edit 8-) :
Die Batterien sollen 1 Jahr halten bei "Dauerfeuer", die Reichweite finde ich gut (mindestens 10m + schräg durch eine dicke Kellerdecke durch).
-
Wo hast du die denn bestellt!? Kannst du den Shop nennen!? [emoji6]
Gesendet von meinem iPhone mit Tapatalk
-
Zum Beispiel bei Conrad https://www.conrad.de/de/prototypingkit … 41194.html
oder Eibtron http://www.eibtron.com/epages/eibtron.s ... s/873-5892
-
ist das wirklich der richtige Ansatz? Ich habe hier einen Ablufwärmetauscher mit Entfeuchterfunktion verbaut. Bei dem Gerät werden für die Entfeuchtung die relative luftfeuchtigkeit innen und aussen als Entscheidungskriterium für die Richtung des Luftstroms verwendet. Spielt nicht jeweils die temperaturabhängige Aufnahmefähigkeit der Innen- bzw. Aussenluft die entscheidende Rolle? Ich kann mir nicht vorstellen, dass die Firma solch grundlegende Überlegungsfehler in ihr Hauptprodukt einbaut. Möglicherweise hat das auch mit dem Kondensieren am Wärmetauscher zu tun. Beim Gerät handelt es sich allerdings um eine passive Ausführung ohne Kühlmaschine (AC).
-
Das Gerät rechnet es sich sicher um intern. Dazu braucht es aber auch die Temperatur außen und innen.
Die relative Luftfeuchtigkeit zu vergleichen macht nur Sinn bei gleicher Außen und Innentemperatur.
Gesendet von iPhone mit Tapatalk
-
Hallo ruhr70,
seit der neuen javascript-Adapter-Version gibt es ja vermehrt Warnungen, wenn die Typen der States und Variablen nicht zweifelsfrei definiert werden. http://forum.iobroker.net/viewtopic.php?f=21&t=2903.
In diesem Skript ist mir bei den createStates etwas aufgefallen:
"lüften" : { "DpName" : "Lüftungsempfehlung", //"init": false, "dp": { "name": 'Lüftungsempfehlung', "desc": 'Lüftungsempfehlung', "type" : 'number', "role": 'boolean' } }Soll role da wirklich boolean sein und nicht Type? Denn der Adapter meckert:````
warn: javascript.2 Wrong type of javascript.2.Raumklima.Bad.Lüftungsempfehlung: boolean Please fix, while deprecated and will not work in next versions.Gruß Pix -
Die Datenpunktdeklaration von ruhr70 sieht nicht so gut aus - entspricht nicht dem Standard. So sieht mein Datenpunkt aus:
{ "common": { "name": "Wohnen.Lueften", "desc": "Lüftungsempfehlung", "type": "boolean", "states": "false:Nein;true:Ja", "role": "javascript", "read": true, "write": true, "def": false },Wurde allerdings auch im Reiter "Objekte" erstellt. Da passieren weniger Fehler, weil schon sinnvolle Vorgaben eingebaut sind.
-
@pix:Hallo ruhr70,
seit der neuen javascript-Adapter-Version gibt es ja vermehrt Warnungen, wenn die Typen der States und Variablen nicht zweifelsfrei definiert werden. http://forum.iobroker.net/viewtopic.php?f=21&t=2903.
In diesem Skript ist mir bei den createStates etwas aufgefallen:
"lüften" : { "DpName" : "Lüftungsempfehlung", //"init": false, "dp": { "name": 'Lüftungsempfehlung', "desc": 'Lüftungsempfehlung', "type" : 'number', "role": 'boolean' } }Soll role da wirklich boolean sein und nicht Type? Denn der Adapter meckert:````
warn: javascript.2 Wrong type of javascript.2.Raumklima.Bad.Lüftungsempfehlung: boolean Please fix, while deprecated and will not work in next versions.Gruß Pix `Da ist bei dem wirklich ein Vertipper passiert. Hatte ich bei mir heute schon korrigiert:
"lüften" : { "DpName" : "Lüftungsempfehlung", //"init": false, "dp": { "name": 'Lüftungsempfehlung', "desc": 'Lüftungsempfehlung', "type": 'boolean', "role": 'value' } }role ist ja eigentlich egal und nur zur Sortierung wichtig.
Ich habe es in Skript korrigiert und den Datenpunkt schnell in den Objekten angepasst.
Gut, dass Bluefox diese Warnung eingebaut hat. Ich hatte noch in anderen Skripten Fehler. Einmal beim Datentyp und einmal bei der Deklaration. Z.B. habe ich mal Float deklariert, wo es nur Number in den Objekte gibt.
Mir gefällt die Deklaration im Skript wesentlich besser, als in den Objekten, da für mich die Vorteile überwiegen:
-
Massendeklaration per Skript
-
Die Deklaration kann schnell wieder hergestellt werden, wenn man iobroker neu aufsetzt
Ich möchte nicht in den Objekten händisch passend zum Skript arbeiten. Lieber sorge ich dafür, dass alle Skripte sauber und vollständig sind.
Aber jeder, wie er mag
-
-
Lieber sorge ich dafür, dass alle Skripte sauber und vollständig sind. `
Wenn Du das so realisierst, kein Problem 8-)Dann solltest Du aber
"dp": { "name": 'Lüftungsempfehlung',die Zeile mit "name": "…", löschen, denn common.name wird bei createState(name, init, force, common) aus dem an die Funktion übergebenen Namen gebildet.
-
danke!
ich schau mir das nachher an
Gesendet von iPhone mit Tapatalk
-
Lieber sorge ich dafür, dass alle Skripte sauber und vollständig sind. `
Wenn Du das so realisierst, kein Problem 8-)Dann solltest Du aber
"dp": { "name": 'Lüftungsempfehlung',die Zeile mit "name": "…", löschen, denn common.name wird bei createState(name, init, force, common) aus dem an die Funktion übergebenen Namen gebildet. `
Aus der Beschreibung des Javascript-Adapters (ein Beispiel):
createState('myVariable', {name: 'My own variable', unit: '°C'}, function () {log('created');});So wie dort "name" verwendet wird, macht es mein Skript auch. Und alles steht auch dort, wo ich es erwarten würde.
"name" gehört dort zum Object common. Den Punkt, den Du meinst heisst im Beispiel myVariable und ist hinterher der id-Name.
