[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

[CoolTux]

ASC_WindParameters        -1


So könnte eine Angabe aussehen für einen Rollladen der nicht fahren soll wenn Wind Device im ASC Device als Attribut angegeben ist.

[CoolTux]

Ich bin nicht sicher und konnte das auch bisher nicht näher prüfen, aber mit der github-devel-Version scheinen manche Rollläden (am WE?) gar nicht zu fahren. Vielleicht hast du eine spontane Idee, ob es da einen Zusammenhang gibt?

Könnte eventuell diese Änderung sein
https://github.com/LeonGaultier/fhem-AutoShuttersControl/commit/3910a46c5d3286d281fe4efb559a7b60b3ff817f

[Beta-User]

ASC_WindParameters        -1

Finde das gut und m.E. sollte so als default ausgerollt werden.

Wenn ich dazu komme, gibt's auch wieder eine RG oder eine geänderte/ergänzte RG . (voraussichtlich aber erst am WE, muß auch mal schauen, ob ich da eine 2. Option reinbekomme, um das auszuschalten)

Könnte eventuell diese Änderung sein
https://github.com/LeonGaultier/fhem-AutoShuttersControl/commit/3910a46c5d3286d281fe4efb559a7b60b3ff817f

Weiß nicht; es betrifft schon vorrangig Rollläden, die einen Bewohner kennen, aber zum einen gibt es auch mind. einen, der keinen Bewohner hat, zum anderen wird mind. einer der Bewohner nicht "geschaltet", der steht auf absent.
Aber wie gesagt, bisher bin ich nicht dazu gekommen, mir das intensiver anzusehen.

[CoolTux]

Finde das gut und m.E. sollte so als default ausgerollt werden.

Findest Du, aber so sieht man doch wieder nicht die volle Syntax. Ich finde ausgerollt sollte die volle Syntax per default zu sehen sein. Und wer dann im ASC Device das Wind Attribut aktiviert (setzen eines Sensor Devices) und will das ein oder zwei Rollläden nicht fahren der kann dann -1 setzen.

[CoolTux]

Ich habe die aktuelle Entwicklerversion mal in mein Produktiv System geschoben. Die Übernahme der alten Attributsdaten ins neue Format lief schon mal reibungslos. Freu.

[Beta-User]

Findest Du, aber so sieht man doch wieder nicht die volle Syntax. Ich finde ausgerollt sollte die volle Syntax per default zu sehen sein. Und wer dann im ASC Device das Wind Attribut aktiviert (setzen eines Sensor Devices) und will das ein oder zwei Rollläden nicht fahren der kann dann -1 setzen.

M.E. kann durchaus die ganz einfache Variante ausgerollt werden. Im Prinzip muß der User dann nur einen (!) sinnvollen Grenzwert angeben, der Rest geht automatisch...

Erst, wenn was nicht ist wie erwartet, muß man feiner nachjustieren. Machen wir das anders, würde ich wetten, dass wir wir wieder eine größere Anzahl "Rumfummler" haben, die das ganze nicht verstehen wollen/können, da irgendwas ändern, aber eigentlich sonst gar nicht auf die Idee gekommen wären, überhaupt an irgendwas rumzuschrauben (abgesehen von der Grenzgeschwindigkeit und dem Einschalten an sich) .

U.A. deswegen doch der ganze Aufwand mit den defaults .

EDIT: Und an sich sollte die Automatik auch erst mal ausgeschaltet sein. Sonst muß der User das konfigurieren, obwohl er vielleicht erst mal nur morgens und abends die Rollläden komfortabler fahren will wie bisher.

Würde daher alles, was optional ist immer erst ausschalten!

[CoolTux]

M.E. kann durchaus die ganz einfache Variante ausgerollt werden. Im Prinzip muß der User dann nur einen (!) sinnvollen Grenzwert angeben, der Rest geht automatisch...

Erst, wenn was nicht ist wie erwartet, muß man feiner nachjustieren. Machen wir das anders, würde ich wetten, dass wir wir wieder eine größere Anzahl "Rumfummler" haben, die das ganze nicht verstehen wollen/können, da irgendwas ändern, aber eigentlich sonst gar nicht auf die Idee gekommen wären, überhaupt an irgendwas rumzuschrauben (abgesehen von der Grenzgeschwindigkeit und dem Einschalten an sich) .

U.A. deswegen doch der ganze Aufwand mit den defaults .

EDIT: Und an sich sollte die Automatik auch erst mal ausgeschaltet sein. Sonst muß der User das konfigurieren, obwohl er vielleicht erst mal nur morgens und abends die Rollläden komfortabler fahren will wie bisher.

Würde daher alles, was optional ist immer erst ausschalten!

Die Regen und Wind Automatik bleibt ja ausgeschalten, halt so lange bis ein entsprechendes Device gesetzt wurde. Aber ich werde mal das ganze default mäßig so setzen und dann schauen wir einmal. Also mit -1

[nils_]

nur als idee:
-1 finde ich immer nichtssagend. (auch wenn ich sowas bestimmt schon öfters mal irgendwo eingebaut habe )
wäre es nicht schöner/lesbarer, wenn da sowas wie "none" oder "unused" oder "undefined" oder oder oder.... stehen würde?

[Beta-User]

Die Regen und Wind Automatik bleibt ja ausgeschalten, halt so lange bis ein entsprechendes Device gesetzt wurde. Aber ich werde mal das ganze default mäßig so setzen und dann schauen wir einmal. Also mit -1

Schon klar, aber wenn ich an die Herangehensweise denke, die ich manchmal habe, finde ich das händische Einschalten besser:
Zum einen setzte ich Werte, die ich kenne, auch schon mal präventiv, ohne die Auswirkungen dabei immer im Blick zu haben. Zum anderen habe ich das auch jetzt so gemacht, dass ich erst mal eine Jalousie zu Testszwecken nutze, und hinterher erst den Rollout an alle mache... Ist einfacher, wenn man das pro Rollladen einschaltet (per regex oder RG, wenn's schnell gehen soll).

nur als idee:
-1 finde ich immer nichtssagend. (auch wenn ich sowas bestimmt schon öfters mal irgendwo eingebaut habe )
wäre es nicht schöner/lesbarer, wenn da sowas wie "none" oder "unused" oder "undefined" oder oder oder.... stehen würde?

Geht mir auch immer so, wenn ich die -1 irgendwo sehe. Ist aber eine verbreitete Sache, von daher: bin da leidenschaftslos.
Aber da wir so sowieso eine Prüfung vorneweg brauchen, können wir auch "none", "deactivated" oder sonst was nehmen...
(anders, wenn wir einen hohen Zahlenwert, z.B. 1000 nehmen würden; da könnten wir zwar direkt rechnen und es wäre für die meisten Fälle auch passend, aber was, wenn jemand mm/h oder ticks/5min als Einheit nutzt?)

[CoolTux]

Man war das noch mal ein Kraftakt. Ich habe zu Testzwecken schon mal ein Attribut aus den Rolläden umbenannt und die Werte des Attributes und derer die ich nun im neuen auch brauche ausgelesen und im neuen Attribut neu gesetzt. Danach lösche ich das alte. War gar nicht so einfach wie ich dachte. Aber nun passt es.
Ich teste heute und morgen in meiner Live und gebe morgen für Dich Beta-User eine Version zum testen.

[Beta-User]

Man war das noch mal ein Kraftakt.

Kann ich mir vorstellen. Hoffe, du hast auch den Eindruck, dass er sich gelohnt hat?

Dann warte ich mal, bis ich "darf" (und andere...). Mal schauen, am WE sollte eigentlich genug Zeit sein zum testen.

[CoolTux]

Ich werde noch etwas Zeit brauchen. Habe gerade bemerkt das ich wohl einen Designfehler habe. Das muß ich erstmal prüfen und ausmerzen.

Grüße

[CoolTux]

Bin offiziell am verzweifeln. Ich finde keine Möglichkeit wie ich erkenne ob ein Wert gegeben ist oder ich ein default setzen soll.

Code Auswählen Erweitern

device:reading temp:hysterese pos


Und nun nehmen wir mal an das man reading und hysterese optional setzen kann.
Wie würdet ihr den String versuchen zu analysieren?

[CoolTux]

Ich denke und hoffe das ich einen Weg gefunden habe.
In meiner kleinen Perl Testumgebung hat der Code schon mal funktioniert. Auch wenn ich ihn persönlich gruselig finde.

[Beta-User]

Danke für die Info.

Auch wenn das Problem gelöst zu sein scheint, kurz meine Gedanken zur Programmierlogik:
- Alle "Notdefaults" erst mal als Konstanten definieren, ggf. auch mit Hashes; so ist es einfacher zentral zu verwalten und zu ändern und nicht über den Code verteilt. (Als Beispiel kannst du mal den MySensors-Code ansehen; da ist das evtl. etwas exzessiv; my %static_types in MYSENSORS_DEVICE oder Constants.pm)
- Für die Dinge, die man dann im ASC-Device ändern kann, das ganze jeweils in eine Variable übernehmen (bei der Modulinitialisierung bzw. Änderung des Attributwerts)
- Dann beim Durchgehen der Rolladendevices (bzw. Änerungen dort) jeweils nachsehen, ob was lokal definiert ist und alternativ dann  die genannte Variable nehmen (Prüfung mit defined?).