[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

Begonnen von CoolTux, 28 Februar 2019, 09:09:18

Vorheriges Thema - Nächstes Thema

CoolTux

Wer möchte kann gerne einmal die Wind Integration testen.

https://github.com/LeonGaultier/fhem-AutoShuttersControl/tree/devel

Deutsche Commandref wurde an gepasst. Bitte lesen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Habe das eben mal installiert, sieht erst mal gut aus, ein setreading löst schon mal das Öffnen aus, schließen klappt auch, wenn die Jalousie offen war  :) .

Weiß noch nicht, ob ich die Reihenfolge intuitiv finden soll, ich hätte spontan den "Reaktionswert" an erster Stelle erwartet, und erst danach ggf. den Hyserese(ergebnis)-Wert (bzw. den auf x-10 gesetzt).

Schönheitsfehler in der cref: Eine Beschreibung von ASC_Wind_Pos fehlt, oder?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Zitat von: Beta-User am 28 Februar 2019, 19:14:18
Weiß noch nicht, ob ich die Reihenfolge intuitiv finden soll, ich hätte spontan den "Reaktionswert" an erster Stelle erwartet, und erst danach ggf. den Hyserese(ergebnis)-Wert (bzw. den auf x-10 gesetzt).
Es ist kurz vor acht Abends, ein Schreiendes etwas hüpft auf meinen dicken Dickbauch und meine Große stirbt gerade den Schnupfentod. Kannst Du bitte genau sagen was Du damit meinst  ;D



Zitat von: Beta-User am 28 Februar 2019, 19:14:18
Schönheitsfehler in der cref: Eine Beschreibung von ASC_Wind_Pos fehlt, oder?
Das ist in der Tat möglich. Danke Dir, reiche ich nach.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Zitat von: CoolTux am 28 Februar 2019, 19:42:45
Es ist kurz vor acht Abends, ein Schreiendes etwas hüpft auf meinen dicken Dickbauch und meine Große stirbt gerade den Schnupfentod. Kannst Du bitte genau sagen was Du damit meinst  ;D
Sorry, war etwas in Eile und auf dem Weg zum Sport gegen die Dickbaucherei nach der Kinderzeit...
Hoffe, die Kleinen sind im Bett und auf dem Weg der Besserung.

Zu deiner Frage: Gedanklich bin ich bei der Funktionsweise von THRESHOLD. Da reicht im Prinzip die Angabe eines Schwellenwertes, alles andere macht das automatisch. Da es Sinn macht, nicht gleich (gegenläufig) zu Schalten, wenn der Meßwert wieder unter die relevante Größe fällt, ist eine Hysterese zweckmäßig (in der aktuellen ASC-Modulversion: 50-30=20, bei THRESHOLD: 1).

Vom Prinzip finde ich das gedanklich einfacher, erst den "kritischen Wert" aufzuführen, also zu sagen, wann geschaltet werden soll und danach zu sagen, wie groß der Abstand sein soll, bis das nicht mehr gilt (als Abweichung nach unten).
Es würde also reichen, einen Zielwert von 50 (derzeitiger Wert aus dem jetzigen Modul) anzugeben, und nur optional eine Hysterese (die ich spontan eher bei 10 gesehen hätte, kann man aber diskutieren). Da kann es von mir aus aber auch der (immer noch als Option gedachte) untere Wert sein, die Denke in Abweichung liegt allerdings näher bei dem, was wir auch bei den Winkeln haben. Der eine Wert ("50") wäre dann nämlich auch wieder per ReadingsGroup leichter einzustellen...
Die Notation wäre dann wieder: 50[:10]

Über die Benennung sollte man dann nachdenken (min_max) paßt dann nicht, das wäre dann ggf. nur _max oder "..._threshold".

Was anderes noch: Warum eigentlich bei allen einzelnen Rollläden ein Wind-Device+Reading. Das ist bei mir gedanklich sehr nahe bei Astro, will heißen: am ganzen Standort gelten einheitliche Außenbedingungen (beim Modul einmal angeben), lediglich die Toleranz der einzelnen Rollläden ist unterschiedlich (also am Gerät einzustellen).
Bei Astro fand ich übrigens das automatische Auffinden des Astro-Devices ein nettes Gimmik. Könnte man hier ähnlich lösen (ich verwende im Moment auch noch weather, bis ich endlich irgendwann dazu komme, mal was lokales zusammenzulöten). Erst nach weather suchen, dann nach irgendwas, was ein Reading wind hat (da halt dann das erste im Array).

Wenn du eine Ausschaltbedingung am Rolladen brauchst: -1 zulassen bzw. als default verteilen, dass das erst mal inaktiv ist?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Ich glaube Du hast das nicht so ganz verstanden mit dem Reading ASC_Wind_minMaxSpeed 50:30

Der erste Wert gibt an ab welchen Wert wegen Wind gefahren werden soll. Also über 50. Der zweite gibt an ab welchen Wert wieder zurück gefahren werden soll. Also unter 30. Da gibt es nichts mit wie HRESHOLD.

Im übrigen war das ein Userwunsch das Wind Device und Reading in die Rolläden soll.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Sorry, wenn ich was mißverstanden haben sollte. In der Version 0.4.0.7 aus deinem Repo ist das in der cref noch so beschrieben:
ZitatASC_Wind_minMaxSpeed - min:max / Angabe von Minamaler und Maximaler Windgeschwindigkeit, durch doppel Punkt getrennt. Bsp.: schließen bei über max Wert und wieder auf vorherige Position fahren bei min Wert.
Also vorne der kleinere und hinten der größere Wert...

So hatte ich das hier getestet, und das hat auch funktioniert, allerdings hatte ich keine Werte zwischen min und max verwendet.

Dann nochmal die Bitte: den zweiten Parameter als Option. Ist er nicht angegeben, wird er errechnet. So kann man das via ReadingsGroup in den Standardfällen einfacher abbilden, nur wer was spezielles will, braucht einen zweiten Parameter (und den würde ich als Differenzwert nach unten nach wie vor besser finden). Ganz wie bei THRESHOLD (das ist eine Zielbeschreibung, keine Ist-Darstellung).

Das mit dem userwunsch ist mir entgangen, müßten wir mal suchen und ggf. nochmal nachhaken. Mein pers. Wunsch war es, die Grenzgeschwindigkeit(en) individuell festlegen zu können, aber die Windgeschwindigkeit an sich kommt nur aus einem Device und ist rund um das Haus ziemlich gleich...

Und wolltest du nicht mittelfristig sowieso nach Device:Reading umstellen und das eine oder andere Attribut einsparen? Warum dann noch bei neuen Features diese Großzügigkeit...?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Zitat von: Beta-User am 01 März 2019, 05:22:22
Sorry, wenn ich was mißverstanden haben sollte. In der Version 0.4.0.7 aus deinem Repo ist das in der cref noch so beschrieben: Also vorne der kleinere und hinten der größere Wert...

So hatte ich das hier getestet, und das hat auch funktioniert, allerdings hatte ich keine Werte zwischen min und max verwendet.

Dann nochmal die Bitte: den zweiten Parameter als Option. Ist er nicht angegeben, wird er errechnet. So kann man das via ReadingsGroup in den Standardfällen einfacher abbilden, nur wer was spezielles will, braucht einen zweiten Parameter (und den würde ich als Differenzwert nach unten nach wie vor besser finden). Ganz wie bei THRESHOLD (das ist eine Zielbeschreibung, keine Ist-Darstellung).

Das mit dem userwunsch ist mir entgangen, müßten wir mal suchen und ggf. nochmal nachhaken. Mein pers. Wunsch war es, die Grenzgeschwindigkeit(en) individuell festlegen zu können, aber die Windgeschwindigkeit an sich kommt nur aus einem Device und ist rund um das Haus ziemlich gleich...

Und wolltest du nicht mittelfristig sowieso nach Device:Reading umstellen und das eine oder andere Attribut einsparen? Warum dann noch bei neuen Features diese Großzügigkeit...?

Guten Morgen,

Nur kurz heute. Oben waren die Werte verdreht. Also noch mal ganz in Ruhe. So wie das Attribut heißt müssen die Werte gesetzt werden. Also 30:50. Bedeutet aber immer noch bei über 50 fährt er in den Wind protected bei unter 30 wieder zurück.

Pass auf dann machen wir es so. Device und Reading Global und Position und Geschwindigkeit in die Rolläden. Aber ich verstehe immer noch nicht was Du mit berechnen meinst. Soll ich da einfach sagen bei max minus 20 soll er zurück fahren. Aber ich kenne doch die Einheit nicht. Was ist wenn die da m/s nehmen. Das sind ja dann andere Werte da würde 20 wohl nicht reichen.

Das mit Device:Reading wird eine größere Aktion und wenn wir das es anders machen wollen. Also alles als Readings dann lass en wir das jetzt. Ich kann da noch mal was schauen weil ich da noch eine Idee hätte, aber will da nicht zu viel Energie reinsetzen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Guten Morgen zurück :D .

Dann also nochmal die wichtigste Rückmeldung von allen: Es scheint zu funktionieren, wie es in der cref steht, jedenfall, soweit ich das bisher beobachten konnte. Das war auch nie die Frage ;D .
Zitat von: CoolTux am 01 März 2019, 06:18:57
Pass auf dann machen wir es so. Device und Reading Global und Position und Geschwindigkeit in die Rolläden.
*Daumenhoch*

Zitat von: CoolTux am 01 März 2019, 06:18:57
Aber ich verstehe immer noch nicht was Du mit berechnen meinst. Soll ich da einfach sagen bei max minus 20 soll er zurück fahren.
Sorry, wenn es mir einfach nicht gelungen ist, das nachvollziehbar darzustellen. Aber so langsam scheinen wir uns zu verstehen... Im Prinzip: Ja, genau so, aber eben nur dann, wenn der User nicht ausdrücklich einen anderen Differenzwert vorgibt (daher den zweiten Wert als Option, und damit der User eine Chance hat zu verstehen, wie das Modul intern "denkt" eben als Differenz (Hysterese), nicht als Absolutwert).
Damit ist der "übliche Fall" (km/h) direkt abgedeckt, wer was anderes will, kann das einstellen, und zwar völlig unabhängig von "seiner" Einheit. Da wir in den meisten Fällen dann nur einen Wert (max) brauchen, können wir das den User häufig via ReadingsGroup einstellen lassen, nur wer spezielle Anforderungen hat, muß wirklich jeden Rolladen (ggf. über devspec) anfassen.
Ich finde nur 20 (km/h) als Differenz ziemlich groß, habe da aber zu wenig Erfahrung mit anderen Rollläden. Bisher hatte ich nur den Notfall geregelt, und der hieß halt: fahre hoch... Spontan hätte ich eher 10 (km/h) als Hysterese für ausreichend gehalten, komme aber auch von Jalousien her. Aber wenn man den Wert im Modul zentral hat, können wir damit ja auch "spielen" und dann die Erfahrungen und Rückmeldungen der anderen einfließen lassen ;) .

Zitat von: CoolTux am 01 März 2019, 06:18:57
Das mit Device:Reading wird eine größere Aktion und wenn wir das es anders machen wollen. Also alles als Readings dann lass en wir das jetzt. Ich kann da noch mal was schauen weil ich da noch eine Idee hätte, aber will da nicht zu viel Energie reinsetzen.
Auch da nochmal der Hinweis: Es ging nicht darum, dass allgemein (für alle bestehenden Attribute) jetzt so zu machen, sondern erst mal nur bei diesem einen neuen Attribut. Da wäre es m.E. kein großes Ding, aber wenn doch: Du bist der Modulautor ;) . Du darfst das entscheiden ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Zitat von: Beta-User am 01 März 2019, 07:03:50

Auch da nochmal der Hinweis: Es ging nicht darum, dass allgemein (für alle bestehenden Attribute) jetzt so zu machen, sondern erst mal nur bei diesem einen neuen Attribut. Da wäre es m.E. kein großes Ding, aber wenn doch: Du bist der Modulautor ;) . Du darfst das entscheiden ;D .
Das Problem ist das alle Devices welche relevant für die NOTIFYDEV sind gleich behandelt werden. Aber mit einem split könnte es gehen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Ähm, kann es sein, dass ich irgendwie die morgendliche Automatik versehentlich ausgeschaltet habe?

Ich hatte nach dem reinkopieren der Entwicklerversion nur ein relaod des ASC-Moduls gemacht. Heute morgen sind die Rolläden nicht gefahren, jetzt steht in den timern heute abend bzw. morgen früh.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Haste kaputt gemacht  ;D

Du musst bei diesem Modul immer ein kompletten FHEM neustart machen. Ein Reload zerstört die erstellten Objekte.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

 ;D
Dachte mir schon, dass es an der "Abkürzung" lag...

Bei der Gelegenheit des Neustarts wollte ich dann auch noch ein update fahren. Da hätte ich aber wieder die Version vom svn bekommen, also habe ich das gelassen, hätte zu lange gedauert, das wieder zu reparieren. Wäre es nicht eine Idee, eine update-file für die Entwickler- bzw. Testerversion von ASC zu nutzen?
Dann könnte man das "ganz normal" via update runterziehen und hätte diese Konflikte nicht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Zitat von: Beta-User am 01 März 2019, 10:00:46
Wäre es nicht eine Idee, eine update-file für die Entwickler- bzw. Testerversion von ASC zu nutzen?
Dann könnte man das "ganz normal" via update runterziehen und hätte diese Konflikte nicht.

Eine solch Idee ist in der Entwicklung. Erste Schritte sind dafür getan. Erzähle ich heute Abend mehr darüber  ;D
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Bin heute abend anderweitig unterwegs, Telco klappt daher bei mir nicht. Trotzdem viel Spaß!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Zitat von: Beta-User am 01 März 2019, 11:34:48
Bin heute abend anderweitig unterwegs, Telco klappt daher bei mir nicht. Trotzdem viel Spaß!

Schade. Wünsche Dir auch viel Spaß.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net