[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.8.x

[Prof. Dr. Peter Henning]

 

[CoolTux]

Es wird nicht anders gehen. Ich denke Du hast zu viele Versionen ausgelassen und die alten Attribute sind mit neuen vermischt. Was anderes fällt mir dazu nicht ein.
Ich denke aber das es schnell gemacht ist.

[daelch]

Hallo CoolTux,

wann startest Du die Entwicklung der Jalousienunterstützung? Ich stehe dafür Gewehr bei Fuß um Informationen zu liefern oder Testkaninchen zu spielen. Ich könnte Dir auch einen Jalousieaktor zusenden, wenn das hilfreich ist.

Viele Grüße

[CoolTux]

Hallo CoolTux,

wann startest Du die Entwicklung der Jalousienunterstützung? Ich stehe dafür Gewehr bei Fuß um Informationen zu liefern oder Testkaninchen zu spielen. Ich könnte Dir auch einen Jalousieaktor zusenden, wenn das hilfreich ist.

Viele Grüße

Vielen Dank für Dein Angebot. Aktuell habe ich zu viel um die Ohren. Aber ich melde mich sobald ich die ersten Schritte mache.

[Prof. Dr. Peter Henning]

OK, auf eine Sache bin ich nach dem kompletten Neuaufsetzen gestoßen. Wenn das ASC-Device einen TempSensor kennt, funktioniert ein ascAPIget('OutTemp'). Allerdings nicht ein ascAPIget('Rollladendevice','OutTemp') - das liefert in diesem Fall immer -100.

M.E. ist das nicht ganz konsistent, denn wenn das Rollladendevice keinen eigenen TempSensor kennt, sollte der globale des ASC-Devices verwendet werden. Ist auch in dieser Form nur versteckt in der Commandref beschrieben - unter den Gettern für das Rollladendevice taucht dort OutTemp auf.

Ach ja: ich bekomme immer noch keine Shading-Bewegung, obwohl ich die Schwellen für die Rightness angesichts des trüben Tages nahe an die Null gesetzt habe.


Edit: Weitere Sucharbeit... Offenbar liefert ascAPIget('Rollladendevice','BrightnessAverage') immer den Wert 0, obwohl die Brightness der vorigen Events immer > 0 war.

LG

pah

[CoolTux]

Hallo Peter. Lass uns erstmal ein Problem angehen.
Also Thema Temperatur. Wenn ich bei mir ein

Code Auswählen Erweitern


{ ascAPIget('OutTemp','RolloKinZimSteven_F1') }

mache bekomme ich eine Temperatur. Vorausgesetzt das Attribut ASC_TempSensor ist im Rollodevice korrekt gesetzt.

[Prof. Dr. Peter Henning]

Sage ich doch. Der TempSensor muss auch in jedem Rollladendevice gesetzt sein, sonst gibt es immer -100. Das steht eben so nicht in der CommandRef, sondern dort taucht der Temperatursensor nur beim globalen ASC-Device auf.

Nachdem ich ihm beim Rollladendevice definiert habe, liefert er auch dort eine Temperatur, soweit ist dieses Problem also gelöst.

LG

pah

[Prof. Dr. Peter Henning]

OK, ich denke, ich habe den Fehler gefunden.

Du gehst im Modul davon aus, dass die Helligkeitswerte GROSS sind. Bei der Durchschnittsberechnung hast Du deshalb ein

Code Auswählen Erweitern

int( sum(@input) / @input );

Meine Helligkeitswerte sind aber klein - ich beziehe sie aus meiner PV-Anlage und rechne die solare Einstrahlung von W/m² in klx (1000 lx) um. Die Werte bewegen sich also derzeit alle im einstelligen Bereich, summiere ich über mehrere davon und dividiere durch N kann also durchaus eine Gleitkommazahl <1 herauskommen, die durch den "int"-Befehl zu Null vernichtet wird.

Workaround, ganz einfach: ich nehme als Helligkeitswert nicht Kilolux, sondern ein Userreading, das mit 1000 multipliziert ist.

Das ist aber noch nicht schön - denn ich will ja kontrollieren, über wie viele Helligkeitswerte (und somit über welche Zeit) gemittelt wird. Mein Vorschlag zur Korrektur:

Die Berechnung einer durchschnittlichen Helligkeit sollte aus dem Modul herausfliegen und dem User überlassen werden. Der kann sich z.B. überlegen, ob er einen zeitlichen Mittelwert bildet (dafür gibt es genügend Routinen in FHEM), oder z.B. einen Mittelwert über verschiedene Sensoren.

LG

pah

[CoolTux]

OK, ich denke, ich habe den Fehler gefunden.

Du gehst im Modul davon aus, dass die Helligkeitswerte GROSS sind. Bei der Durchschnittsberechnung hast Du deshalb ein

Code Auswählen Erweitern

int( sum(@input) / @input );

Meine Helligkeitswerte sind aber klein - ich beziehe sie aus meiner PV-Anlage und rechne die solare Einstrahlung von W/m² in klx (1000 lx) um. Die Werte bewegen sich also derzeit alle im einstelligen Bereich, summiere ich über mehrere davon und dividiere durch N kann also durchaus eine Gleitkommazahl <1 herauskommen, die durch den "int"-Befehl zu Null vernichtet wird.

Workaround, ganz einfach: ich nehme als Helligkeitswert nicht Kilolux, sondern ein Userreading, das mit 1000 multipliziert ist.

Das ist aber noch nicht schön - denn ich will ja den kontrollieren, über wie viele Helligkeitswerte (und somit über welche Zeit) gemittelt wird. Mein Vorschlag zur Korrektur:

Die Berechnung einer durchschnittlichen Helligkeit sollte aus dem Modul herausfliegen und dem User überlassen werden. Der kann sich z.B. überlegen, ob er einen zeitlichen Mittelwert bildet (dafür gibt es genügend Routinen in FHEM), oder z.B. einen Mittelwert über verschiedene Sensoren.

LG

pah

Hallo Peter,

Das bezieht sich nun aber auf die Beschattung. Denn nur für die Beschattung wird diese Art der Helligkeitsauswertung verwendet. Das ascAPIget sollte dennoch einen korrekten aktuellen Wert liefern und nicht -100.
Das mit dem Mitteln wollte ich aber in der Tat noch Variable machen. Bis dahin kannst Du versuchen in Zeile 5020 die > 3 in > 1 zu ändern. Dann bleibt lediglich ein einziger Wert im Array.


Grüße
Marko

[CoolTux]

@Peter
Was hältst Du davon das Attribut ASC_TempSensor um einen zweiten Wert zu erweitern. hinter der Temperaturangabe kommt ein :X und das X gibt ein Wert an um welchen das Array für den BrightnessAverage gefüllt sein soll.
In Deinem Fall wäre es dann wohl 1, so das immer nur der letzte Wert im Array steht und durch 1 geteilt wird. Bei einem Wert unter 0, also 0.6 zum Beispiel kommt beim int aber leider immer noch 0 raus.
Ich könnte es so machen das bei 0 automatisch mal 1000 gerechnet wird. Muss man halt in der Commandref fest halten.


Grüße

[Prof. Dr. Peter Henning]

Das mit dem angehängten :X fände ich brauchbar - aber das versteckte Multiplizieren mit 1000 eher nicht. Siehs doch mal so: Das ASC-Modul ist schon jetzt extrem komplex. Wenn Du da jetzt noch solche Sache wie eine Umskalierung von Werten mit einbaust (die man in dem jeweiligen device durch ein ein einfaches Userreading machen könnte), ist das Modul irgendwann so überfrachtet mit Trivialitäten, dass die eigentlichen Funktionen vollkommen in den Hintergrund treten.

LG

pah

[CoolTux]

Das mit dem angehängten :X fände ich brauchbar - aber das versteckte Multiplizieren mit 1000 eher nicht. Siehs doch mal so: Das ASC-Modul ist schon jetzt extrem komplex. Wenn Du da jetzt noch solche Sache wie eine Umskalierung von Werten mit einbaust (die man in dem jeweiligen device durch ein ein einfaches Userreading machen könnte), ist das Modul irgendwann so überfrachtet mit Trivialitäten, dass die eigentlichen Funktionen vollkommen in den Hintergrund treten.

LG

pah

Das mache ich das ganze ohne Umskalierung und nur mit dem zusätzlichen optionalen Parameter.

[kotaro]

Hallo,

ich habe eure Unterhaltung mitgelesen und wollte fragen, ob man dabei nicht ein Hinweiß im Wiki und Commandref geben kann?

Ich habe nämlich auch vor, mir ein Helligkeitssensor mittels Differenztemperatursensor zu bauen, welcher Werte eher also zwischen 0 und 4-8°C liefert. und je höher die Differenz, je höher die Sonneneinstrahlung. Also wäre es gut zu wissen, wie man kleine Werte integrieren kann. (Also müsste ich die Werte Sinnvollerweise mit 1000 Multiplizieren um diese nutzen zu können?)

[CoolTux]

Hallo,

ich habe eure Unterhaltung mitgelesen und wollte fragen, ob man dabei nicht ein Hinweiß im Wiki und Commandref geben kann?

Ich habe nämlich auch vor, mir ein Helligkeitssensor mittels Differenztemperatursensor zu bauen, welcher Werte eher also zwischen 0 und 4-8°C liefert. und je höher die Differenz, je höher die Sonneneinstrahlung. Also wäre es gut zu wissen, wie man kleine Werte integrieren kann. (Also müsste ich die Werte Sinnvollerweise mit 1000 Multiplizieren um diese nutzen zu können?)

Mit 1000 wärst Du auf einer sicheren Seite.
Commandref passe ich bei Gelegenheit an.

[roman1528]

Moin.

Warum bitte bei TempSensor ein :X für einen Brightness Mittelwert. Auch wenn es bei beiden um die Beschattung geht hat doch temp so gar nichts mit brightness zu tun.

Jeder normalo zieht seinen Helligkeitswert übrigens aus einem stinknormalen Lichtsensor. 0-XXXXX Lux. Bei HM sind es sogar schon Mittelwerte! Bei einem TLS sollte der User entscheiden können ob er Mittelwert haben möchte oder nicht.

Grüße^^