Global verfügbare Hashes oder Arrays anlegen

[pschlaeppi]

Guten Tag,

Ich bin kein Programmierer und betreffend PERL noch Anfänger und habe bisher noch nicht rausgefunden wie
ich im FHEM Umfeld global verfügbare Hashes oder auch Arrays anlegen kann und wie ich dann aus verschiedenen
Subroutinen direkt darauf zugreifen kann oder wie ich sie referenzieren/übergeben muss.

Anlegen/befüllen würde ich Sie über ne Routine die ich über eine Startsequenz über global:initialized starten würde beim hochfahren von FHEM.
Ausser es gibt auch hier ne bessere Lösung.

Ziel ist es pro Elevation Wert je einen Schlechtwetter und einen Schönwetter Brightness Wert zu hinterlegen
so das die Beschattung zum draussen halten der Hitze nur anspringt wenn es auch schön ist.

Wäre froh um ein bisschen Anschubhilfe und nen Tipp oder ein Snippet wie ich das hinkriege?

Grüsse Philipp

[amenomade]

Warum programmieren? Pack das einfach in einem dummy. Dann ist es überall verfügbar

[pschlaeppi]

Hallo amenomade,

Hatte ich mir auch schon überlegt aber auf Grund der Anzahl Readings die es dann gäbe, hätte ich es lieber anders gelöst.
Die bereitgestellten Werte habe ich aktuell in einem CSV File drin. Da hat es aktuell um die 120 Zeilen mit je 5 Werten drin.
Das würde demzufolge einen Dummy geben mit rund 600 Readings.

Habe mir auch gedacht das es durch abfragen eines Hashes oder eines Arrays schneller und resourcen schonender geht als
durch Dummy Zugriffe, habe aber keine Ahnung ob das so stimmt.

Grüsse Philipp 

[amenomade]

Ein Fhem Device ist nichts anderes als ein Hash...

[flummy1978]

Hallo Philipp,

auch ich würde es in diesem Fall wohl nicht anders machen, als mit einem Dummy um diese Werte dann entsprechend auszulesen - Wenn es so ist, dass Du diese "Liste" nie wieder brauchst oder anfassen willst, kannst Du sie ja in den hidden room schieben und sie tauchen kaum mehr auf.

Was mich allerdings interessiert:

Wie sind die Werte zustande gekommen? Wie hast Du diese Liste erstellt und wie willst Du sie weiter verarbeiten ?
Da es hier ein wenig OT wird, sonst auch gern per PN aber interessiert wäre ich daran dennoch

Viele Grüße
Andreas

[DS_Starter]

Hallo zusammen,

falls der TE sich etwas mit Programmierung in FHEM beschäftigen möchte, wäre die Verwendung des %data Hash eine Möglichkeit für sein Ansinnen.
FHEM stellt es zentral zur Verfügung Zitat: ...Der eigentliche Zweck von %data ist dem Nutzer eine Möglichkeit zum Speichern von temporären Daten im globalen Kontext zu ermöglichen.

https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Wichtige_globale_Variablen_aus_fhem.pl

Sicher verwenden (viele?) Module ebenfalls %data um Daten auszutauschen. Mache ich bei meinen teilweise auch.

Damit du nichts  kaputt machst, achte darauf deine Daten in einem eigenen "Namespace" in $data zu schreiben, also z.B.

Code Auswählen Erweitern


$data->{pschlaeppi}{reading1} = "bla";
$data->{pschlaeppi}{reading2} = "bla";
$data->{pschlaeppi}{reading3} = "bla";
$data->{pschlaeppi}{reading4} = "bla";
...


Zugriff entsprechend.
Das Ganze hätte aus meiner Sicht den Vorteil, dass die Daten wirklich nur temporär wären und nicht in fhem.save gespeichert. Nach einem Restart sind sie weg.

@Philip, sollte nur als Anregung dienen weil du im ersten Beitrag diese Möglichkeit explizit angefragt hattest. Aber wie gesagt, achte auf mögliche Konflikte mit anderen Modulen und als Anfänger besonders. Hilfreich wäre dann auch die Guidelines im Wiki zu lesen. Stehen gleich auf der Startseite rechts unten -> Developers Corner.

Grüße,
Heiko

[amenomade]

Du hast natürlich recht, das ist eine Möglickeit. Aber guck:

Ich bin kein Programmierer und betreffend PERL noch Anfänger und habe bisher noch nicht rausgefunden wie
ich im FHEM Umfeld global verfügbare Hashes oder auch Arrays anlegen kann und wie ich dann aus verschiedenen
Subroutinen direkt darauf zugreifen kann oder wie ich sie referenzieren/übergeben muss.

Anlegen/befüllen würde ich Sie über ne Routine die ich über eine Startsequenz über global:initialized starten würde beim hochfahren von FHEM.

Deswegen habe ich ein dummy empfohlen. Vorteile:
- ganz einfach zu ausfüllen und benutzen (ReadingsVal() oder in einigen Kontexten [<Device>:<Reading>])
- muss nicht bei jedem Start von Fhem ausgefüllt werden
- für das erste Ausfüllen, kann man aus der Excel Tabelle relativ einfach die setreadings Befehle basteln (ohne Schleife)

Einzige Nachteil: ein Device mit 600 Readings kann beim Display im Fhem-Frontend etwa schwierig sein (wobei... mein TVProgramm HTTPMOD hat 260 Readings, und ich merke nichts). Das muss man aber nicht (hidden room)

Mit dem data Hash muss man immer programmatisch rangehen. Und nach Restart sind die weg, wie Du sagst.

Aber gut. Der TE muss nach Bedarf entscheiden.

[DS_Starter]

@amenomade ... passt schon 
Sehe ich wie du.
Wollte Philipp  nur eine Möglichkeit zeigen falls er sich näher mit FHEM-Programmierung beschäftigen möchte.
Ansonsten Dummy und fertig. 

LG,
Heiko

[Damian]

Ich benutze Instanzvariablen, die sind pro Modul gekapselt und man muss nicht wissen wie die interne hash-Struktur aussieht. Damit  kann man weniger kaputt machen

[amenomade]

wie ich im FHEM Umfeld global verfügbare Hashes oder auch Arrays anlegen kann und wie ich dann aus verschiedenen
Subroutinen direkt darauf zugreifen kann oder wie ich sie referenzieren/übergeben muss.

[betateilchen]

Man könnte auch seinen eigenen globalen hash in der 99_myUtils.pm definieren und systemweit bekanntmachen.

Code Auswählen Erweitern


use vars qw(%betateilchen);


Das funktioniert natürlich auch auf gleiche Weise mit Arrays.

-

[pschlaeppi]

Hallo zusammen,

Herzlichen Dank für die vielen Tipps.
Wie ich den Posts entnehme, sind die Zugriffszeiten gleich da auch ein Device ein Hash ist. Demzufolge wohl beide gleich Resourcen Intensiv.
Werde demzufolge meine Daten noch etwas ausdünnen und reduzieren so das ich auf 300 Readings runter komme und das dann in einen Dummy
packen.
Ich sehe die Vorzüge die Ihr aufgeführt habt mit dem einfacheren Zugriff und nicht neu laden zu müssen beim booten. Die Werte sind ja selber auch statisch.
Da ich Sie aber schon in einem CSV habe, mache ich mir aber ne Routine die den Dummy löscht und neu einliest wenn ich die Werte anpassen will.

@DS Starter und @Betateilchen:
Habe mir die ganze Seite in ein PDF gedruckt und abgelegt für ne nächste Gelegenheit. Da ich recht viele eigene 99_myModule angelegt habe mit meinem
Code drin, ist dieser Ansatz mit dem myUtils sehr interessant und würde auch nichts anderes beeinflussen.

@flummy1978:

Was mich allerdings interessiert:
Wie sind die Werte zustande gekommen? Wie hast Du diese Liste erstellt und wie willst Du sie weiter verarbeiten ?
Da es hier ein wenig OT wird, sonst auch gern per PN aber interessiert wäre ich daran dennoch

Hatte mir noch bevor es ASC gab ne Rollo Steuerung gebastelt für meine Elero Rolladen. Morgens und Abends entweder Fixzeiten oder Helligkeits gesteuert. Fürs Shading habe ich für alle Fenster die Azimuth/Elevation Werte berechnet. Einflussgrössen sind Helligkeit, Azimuth/Elevation, Presence, Temperatur Aussen und Innen sowie Zeitspannen für jede Fassade (VonTag,Monat zu BisTag,Monat). Beschattung vor allem im Sommer ausser in der Küche. Alle 15 Minuten prüft die Steuerung alle Rollos und fährt Sie bei Bedarf. Regen und Wind werden sofort getriggert und gefahren. Jedes Rollo kann morgens, abends oder beide automatisch gefahren werden und die Beschattung kann Winter,  Sommer oder Beides gefahren werden.

An der Ost Fassade habe ich die Sonne natürlich bereits ab Elevation 1 in den Räumen und wenn die Beschattung dann bei den eingestellten 220 Brightness (Homematic) runter kommt, hat es bereits 2-3 Stunden rein gebrannt. Bei Elevation 1 ist die Helligkeit etwa 140 (schön Wetter). Normale Tageshelligkeit bei Schönwetter liegt über 220. An der Ost Fassade fahre ich nun von Nacht in den Shading Modus, dann ist aber Brightness erst so um die etwa 140.  Bis die Shading Helligkeit von 220 erreicht ist, sind es dann noch gegen 2 Stunden. Bei mir gibt es aktuell noch den MinShadeDuration den ich einstellen kann. Wenn der nun auf 30 Minuten steht, dann wird alle 30 Minuten neu geprüft. Damit stellt er dann nach 30 Minuten fest das es fürs Shading eigentlich noch zu dunkel ist und macht auf. Dann würde er erst wieder zu machen wenn wirklich über 220 ist. Ich kann jetzt den Min Shade rauf schrauben auf 2 Stunden, dann macht er aber auch nicht mehr auf wenn es schlecht Wetter und zu Dunkel ist. Wenn ich die Brightness auf 140 packe ist den ganzen Tag Dunkel ob schön oder nicht und die Rollos bleiben unten bis am Abend. Um das in den Griff zu kriegen muss ich also eine Elevation abhängige Sunny/Cloudy Tabelle haben. So kann bei jedem Elevation Wert dann direkt entschieden werden ob Schön- oder Schlechtwetter und ich kann meine MinShadeDuration auf 30 Minuten setzen. Im Moment ist Beschattung an der Ost Fassade noch auf manuell.

Die Werte habe ich aus den Logs. Habe mir dafür im letzten Sommer jeweils ein paar Tage in die Notizen geschrieben an denen das Wetter durchgängig schön oder Schlecht war. Ich habe nun die Daten aus den Logfiles geholt und die im Excel zusammengeführt. So habe ich mir nun so ne Tabelle zusammengezimmert wo ich bei den Elevation Werten von -3 bis 50 in 1er Schritten jeweils einen schön und schlecht Wetter Brightness Wert zum vergleichen habe. Nun bin ich gerade dabei meine Steuerung zu erweitern dass endlich auch die Ost Fassade dann so tut wie ich das möchte ohne manuelle Eingriffe.

Grüsse Philipp 

[flummy1978]

Hey,

die Vorschläge / Empfehlungen die hier erwähnt wurden, helfen mir sicherlich auch mal bei meinen Basteleien weiter, aber

@pschlaeppi:

Vielen herzlichen Dank für die lange und ausführliche Erklärung der Datenmenge. Das was Du da alles gebastelt hast, dürfte wohl das ASC Modul bei Dir vollkommen überflüssig machen, weil es explitzit auf DEINE Bedürfnisse angepasst ist und nicht allgemein gehalten. Ich weiß nicht ob Du zwingend an der Datenmenge festhalten willst, aber auch eine Möglichkeit wäre:

Ich gehe davon aus, je höher die Sonne steht (es also näher an Sommermitte ist)  umso geringer ist der Helligeitswert, der notwendig ist damit Du gerne beschatten würdest. Wäre es dann nicht für Dich eine Möglichkeit die Werte die Du hast in eine eigene Formel zu packen ? Ich meine die Werte werden sich ein wenig ähneln, oder ? Da könntest Du doch sicherlich pro 5° eine Wertereihe haben, die dann relevant wird. Je näher es an Juli ist umso höher gewichtet wird es: Mal angenommen, im Sommer MUSS der wert 220 erreichen, damit Du abschattest. Dann wäre dein Wert 220*0,95 (Juni/August) 220*0.85(Mai) 220 *0.7 April  ...... Das Ganze nur so als Beispiel ( Je nachdem wie nahe Du Deinen Tatsächlichen Zahlen kommst, mit so einer Berechnung ) Aber das würde Dir möglicherweise auch sehr seh viele Readings ersparen.  Die 0,95 -0,7 Werte würden sich natürlich aus Sonnenstand / Temperatur etc ergeben - Da müsste man wahrscheinlich ein wenig rumspielen...... Aber da Du ja alles in einer Excel hast, könntest Du wunderbar die Formel dann an allen Werten immerwieder testen. .... ist nur so eine Idee (weil mich auch 600 oder auch 300 Readings in einem Device "stören" würden   )


Ansonsten gefällt mir sehr, was Du da zusammen gesammelt hast Wäre da sicherlich auch mal an Näherem interessiert (das dann hier allerdings vollkommen OT wäre)

Viele Grüße
Andreas

[pschlaeppi]

Hallo zusammen,

@flummy1978

Wollte noch etwas mit dem Feedback warten auf deinen Input das man anstelle des Dummys mit 300-600 Werten eventuell auch mit einem Monatsabhängigen Faktor arbeiten könnte, bis ich das auch etwas dokumentieren kann. Wollte das auch zuerst nur als PN machen, habe aber dann festgestellt dass da keine Screenshots angehaengt werden können. Daher halt noch einmal in diesem Thema eine Antwort.

Ich habe nun die Zeit seit unserer letzten Konversation mal genutzt um das in meine Steuerung rein zu basteln und mal zu gucken was sich tut.
Hatte dann zuerst noch etwas Ärger mit der Katzen Funktion die nicht mehr Tat wie sie sollte. Jetzt läuft aber soweit ich bisher Erfahrungen
sammeln konnte alles bestens.
Ich habe mir dazu dann noch nen Plot gebastelt der das veranschaulicht.


Dein Vorschlag würde leider für mein Problem so wie ich es sehe nicht funktionieren. Die Helligkeits Werte bei einem schönen Tag sind über das ganze Jahr eigentlich immer so in etwa dieselben Werte. Bei mir auf der West Seite liegt das so zwischen 235 und 245 je nach Dunst den es noch hat. Sie steigen auch ähnlich steil an. Es beginnt halt einfach auf den Tag gesehen früher oder später. Die Werte Tabellen die ich aktuell verwende, habe ich mal am 28 August 2019 genommen für schön und den 1. September 2019 für Schlechtwetter.

Da drauf siehst du pro Fenster Unterschiedlich:
- Hilfslinien Elevation Start und Stop direkt aus dem Reading (grau)
- Hilfslinien Elevation Start und Stop direkt aus dem Reading (schwarz)
- mit "Allow" werte ich aus Proplanta noch die Wettecodes aus und hatte
  diese auch noch als "And" Kriterium nebst Elev, Azi und der Helligkeit drin.
  Habe aber in den letzten Tagen gemerkt das Proplanta da für die Schweiz
  deutlich daneben liegt und nicht stimmt. Yahoo war da genauer. Ne Schweizer
  Wetter Datenquelle habe ich noch keine gefunden, daher habe ich das Kriterium
  in der Zwischenzeit rausgeschmissen. Inzwischen fahre ich also nur noch Azi, Elev
  und Helligkeit.

- die blaue Kurve ist der aktuelle Aussen gemessene Helligkeits Wert.
  Da ich an jeder Fassade Bewegungsmelder habe, habe ich für jede Fassade ne leicht
  andere Kurve, was du an dem Unterschied zwischen FensterPergola(Süd) und der
  Türe Terasse(Ost) sehen kannst.
- die beiden Pinken Kurven sind die Werte aus der Tabelle für Sunny und Cloudy.
- Die Schwarze fettere Linie ist der Shade Limit. Da habe ich das Delta zwischen
  Sunny und Cloudy aus der Tabelle genommen und das Limit in der Mitte festgelegt.
  Bei ShadeLimit -5 und drunter geht der Rollo nicht mehr runter. Bei ShadeLimit und
  darüber geht das Rollo zu. An allen Fassaden ausser dem Osten ist der Shade Limit
  ein gerader Wert. An der Ost Fassade aber gibts die Werte Tabelle die von -3 bis 50
  in 1er Schritten geht. Das ist der Einschnitt den du bei TuereTerasse siehst.

Wenn die blaue Kurve zwischen der linken Kurve in Pink und dem schwarzen ShadeLimit
verläuft, wird zugemacht (Gestern).
Ist die blaue Kurve zwischen ShadeLimit und der rechten pinken
Kurve, bleibt offen (Heute).

Screenshots findest du:
- Readings Group der Bedienung
- Readings Group der Einstellungsmöglichkeiten eines Rollo.
- Tuere Terasse Vorgestern wo das Rollo sofort vom geschlossenen in den Shade fährt
- Türe Terasse Heute wo es zuerst Wolkig war und dann aber schön wurde, also erst später auf Beschattung ging
- Fenster Pergola wo du die ShadeLimit als Gerade siehst. Hier soll in der Regel auch erst Mitte Tag beschattet werden.

Hoffe das zeigt meine Problemlösung etwas anschaulicher und sonst gerne nachhaken.

Grüsse Philipp