[Skript] Absolute Feuchte berechnen

paul53

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).

paul53

~~@ruhr70:~~

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.

ruhr70

~~@paul53:~~

~~@ruhr70:~~

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!

ruhr70

~~@paul53:~~

~~@Solear:~~

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 ;-)

Solear

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).

simpixo

Wo hast du die denn bestellt!? Kannst du den Shop nennen!? [emoji6]

Gesendet von meinem iPhone mit Tapatalk

Solear

Zum Beispiel bei Conrad https://www.conrad.de/de/prototypingkit … 41194.html

oder Eibtron http://www.eibtron.com/epages/eibtron.s ... s/873-5892

starfish

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).

Solear

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

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

paul53

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.

ruhr70

~~@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 ;-)

paul53

~~@ruhr70:~~

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.

ruhr70

danke!

ich schau mir das nachher an ;-)

Gesendet von iPhone mit Tapatalk

ruhr70

~~@paul53:~~

~~@ruhr70:~~

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.

paul53

~~@ruhr70:~~

Den Punkt, den Du meinst heisst im Beispiel myVariable und ist hinterher der id-Name. `
Ja, die id ist dann Instanz + 'myVariable'. Nur leuchtet mir nicht ein, weshalb in der Javascript-Instanz id-Name und Name (common.name) unterschiedlich sein sollten. Anders beim hm-rpc-Adapter, bei dem die ID die Seriennummer enthält.

Für überflüssig halte ich die Verwendung von common.desc = common.name.

Ich verwende Namen so, dass sie im gesamten ioBroker eindeutig sind und ermittle die id mit getIdByName(name). Deshalb enthalten die Namen in der Regel auch eine Raumbezeichnung, die Beschreibung (desc) erfolgt unabhängig vom Raum (ist in jedem Raum gleich) und erläutert / präzisiert die Funktion.

ruhr70

~~@paul53:~~

Ja, die id ist dann Instanz + 'myVariable'. Nur leuchtet mir nicht ein, weshalb in der Javascript-Instanz id-Name und Name (common.name) unterschiedlich sein sollten. Anders beim hm-rpc-Adapter, bei dem die ID die Seriennummer enthält. `

Ich finde es einfach lesbarer.

Der Datenpunkt:

Hat bei den unterschiedlichen Ansätzen folgende Namen:

(1) Bei Name = id:

javascript.1.Systeminfos.CUxD.http_error

(2) Bei einem individuellen Namen:

letzte Fehlermeldung Webseite CUxD

Mir persönlich gefällt es besser, dass ich lesbar beide Informationen zur Hand habe.

Für getidByName() ist es nicht geeignet/gedacht.

~~@paul53:~~

Für überflüssig halte ich die Verwendung von common.desc = common.name. `

Simpler Grund. Ich verwende immer den Namen und die Beschreibung. Wenn mir keine sinnvollere Beschreibung einfällt, ist sie halt gleich dem Namen und dient als Platzhalter, wenn da jemand mehr reinschreiben will.

Ein Beispiel, bei dem die Beschreibung ausführlicher ist:

        name: 'last new Bluetooth Devices',
        desc: 'Die Mac Adresse des zuletzt gefundenen Bluetooth Device (für History und Ereignislisten)',

~~@paul53:~~

Ich verwende Namen so, dass sie im gesamten ioBroker eindeutig sind und ermittle die id mit getIdByName(name).

Deshalb enthalten die Namen in der Regel auch eine Raumbezeichnung, die Beschreibung (desc) erfolgt unabhängig vom Raum (ist in jedem Raum gleich) und erläutert / präzisiert die Funktion. `

Ja, Dein System habe ich verstanden und es macht auch Sinn, wie Du es nutzt.

Du musst für Dich eine sinnvolle Namenskonvention festlegen und hast dass quasi "aus dem Kopf" immer die richtige id zur Hand, ohne zu suchen.

Vorteile, die ich sehe:

einfacherer Gerätetausch, z.B. bei defekt
bei sinvoller Namenskonvention findet man schnell die id

Ich schaue mir ja viele sinnvolle Sachen bei Dir ab. Hier mache ich mich für mich für einen anderen Weg entschieden.

Ich mag lesbare Namen ohne "." und "_". Die Punkte, die ich für meinen Anwendungsfall als Vorteil sehe, habe ich weiter oben beschrieben.

Das Schöne ist ja, dass iobroker Raum für verschiedene Ansätze lässt ;-)

lobomau

Ich habe die 3 von den 4 Scripten gleich bei mir aufgenommen (habe keine automatischen Fensteröffner, deswegen nur 3 v 4). Läuft super! :)

Ich hätte nur einen kleinen Wunsch. Auch die Einheiten hinzufügen, so wie es Ruhr70 auch hat. Eventuell kriege ich es selbst noch raus wie es geht…

ruhr70

~~@lobomau:~~

I

Ich hätte nur einen kleinen Wunsch. Auch die Einheiten hinzufügen, so wie es Ruhr70 auch hat. Eventuell kriege ich es selbst noch raus wie es geht… `

Bei mir werden die Einheiten per Skript angelegt.

Du kannst das bei Dir ganz einfach nachtragen:

den Datenpunkt in den Objekten raussuchen
auf das Zahnrad klicken
unter Unit die gewünschte Einheit einstellen

paul53

@ruhr70:

unter Unit die gewünschte Einheit einstellen

Das wird nicht genügen, wenn der Datenpunkt per Kurzform createState(name, init) erzeugt wurde (wie es die meisten machen). Dann hat der Datenpunkt den Typ 'mixed' und nur die minimale Anzahl an common-Attributen.

Der Typ muss von 'mixed' in 'number' geändert werden und die weiteren Attribute (desc, unit, min, max) müssen hinzugefügt werden.

Community Forum

NEWS

[Skript] Absolute Feuchte berechnen

Support us

672

32.4k

81.4k

1.3m