Betatester für neues Modul AutoShuttersControl gesucht!

Begonnen von CoolTux, 01 September 2018, 12:10:35

Vorheriges Thema - Nächstes Thema

CoolTux

Zitat von: Deckoffizier am 28 September 2018, 08:51:40
Hallo,

bin noch am Suchen mein Uniroll Testrollladen hat heute morgen leider nicht mitgespielt.
Mein Siro Rollladen aber ja.

Kurze Frage ist das attr. für ASC_Pos_Cmd noch frei wählbar wie bisher ? Also hatte für Uniroll pos eingesetzt.

Gruß
Hans-Jürgen

Hallo Jürgen,

Ja klar, ist alles so geblieben wie bisher. Einzig der Präfix im Namen hat sich geändert. Also nur Kosmetik.
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

CoolTux

Guten Morgen,

Kurze Info. Ich bin aktuell dabei den kompletten Code für das erkennen von Devices von denen wir Events verarbeiten wollen neu zu schreiben. Warum?
Nun jemand kam auf die Idee man könnte ja 2 Roommates in das Roommate Attribut eintragen  ;D
Für das verarbeiten und erkennen der Priorität des Status beider Roommates habe ich eine super tolle Lösung gefunden. Leider war das nicht mehr kompatibel zu meiner Lösung zum erkennen von Devices von denen wir Events verarbeiten.
Also noch mal zurück auf Anfang. Ich habe für 2 von 3 Anforderungen eine Lösung. Um das dritte mache ich mir später Gedanken  :)


Grüße
Leon
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

CoolTux

Fertig. Und ich muss sagen es ist geiler geworden wie ich gedacht hätte  ;D  ;D
Der Code ist nun viel flexibler. Ich teste diese Version übers Wochenende und wenn alles ok ist gebe ich sie Montag frei.


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

Klingt ja vielversprechend...

Hast du zufällig auf Device:Reading umgebaut?

Noch was zur aktuellen Version und den Defaults: nach meinem persönlichen Geschmack sollte man die WE-Automatik auch in der Regel anschalten (also im define schauen, ob das Reading existiert, wenn nein auf "on" setzen).

Ansonsten war alles vom Verhalten her wie erwartet.
Ausnahme (aber nicht tragisch): An mind. einem Device habe ich trotz Löschen (mit "Delete" in FHEMWEB) noch ein paar von den alten userattr drin stehen, kann aber nicht sagen, woher das kommt.
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

Papaloewe

Zitat von: Beta-User am 29 September 2018, 15:21:19
An mind. einem Device habe ich trotz Löschen (mit "Delete" in FHEMWEB) noch ein paar von den alten userattr drin stehen, kann aber nicht sagen, woher das kommt.

Bei mir auch.
Wie bekomme ich das wieder sauber?

Danke & Gruß
Thomas

CoolTux

Zitat von: Papaloewe am 29 September 2018, 16:37:15
Bei mir auch.
Wie bekomme ich das wieder sauber?

Danke & Gruß
Thomas

Einfach rauslöschen aus userattr und dann wenn noch vorhanden auch die gelöschten als Attribut entfernen.
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

CoolTux

Zitat von: Beta-User am 29 September 2018, 15:21:19
Klingt ja vielversprechend...

Hast du zufällig auf Device:Reading umgebaut?

Noch was zur aktuellen Version und den Defaults: nach meinem persönlichen Geschmack sollte man die WE-Automatik auch in der Regel anschalten (also im define schauen, ob das Reading existiert, wenn nein auf "on" setzen).

Ansonsten war alles vom Verhalten her wie erwartet.
Ausnahme (aber nicht tragisch): An mind. einem Device habe ich trotz Löschen (mit "Delete" in FHEMWEB) noch ein paar von den alten userattr drin stehen, kann aber nicht sagen, woher das kommt.

Der User sieht von den Änderungen nichts. Passiert alles unter der Haube. Aber der Code ist weniger geworden und wie ich finde übersichtlicher. So wollte ich es eigentlich von Anfang an machen. Mir fehlte nur ein gedanklicher Anfang. Manchmal braucht etwas halt länger.
Ich weiß das Dir das Thema Device:Reading am Herzen liegt, aber ich werde dies nicht machen. Es ist so schon sehr schwierig gewesen Zuordnungen hin zu bekommen zum NOTIFYDEV und in welchen Zusammenhang dieses Device eigentlich zum Modul steht. Wenn ich da jetzt noch ne Trennung für Reading einbauen werde ich Probleme bekommen.
Um es mal anschaulich zu machen.
Im Internal NOTIFYDEV des Moduldevice stehen alle Devices drin auf dessen Event unser Modul triggern soll. Wir bekommen also einen Devicenamen und den Event. Doch im welchen Zusammenhang steht der Devicenamen zu unseren Rolläden. Das wissen wir nicht. Ist es ein Fensterkontakt oder ein Bewohner? Keine Ahnung. Also muss ich eine Interne Struktur für die Zuordnung schaffen, welche nach einem Reboot nicht nur erhalten bleibt sondern auch wieder sauber unser NOTIFYDEV befüllt ohne beim Start alle Rolläden und alle Attribute dessen Wert für unser NOTIFYDEV nötig ist durch zu gehen. Gerade beim oder nach einem Systemstart wäre das zu viel unnötige Last.


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

CoolTux

Guten Morgen,

Bei mir hat nun die Berechnung zu Sonnenaufgang und Untergang mit einbeziehen von Wochenende und nicht Wochenende super geklappt.


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

Zitat von: CoolTux am 30 September 2018, 07:08:58
Bei mir hat nun die Berechnung zu Sonnenaufgang und Untergang mit einbeziehen von Wochenende und nicht Wochenende super geklappt.
Auch hier keine Probleme, bin mal auf Mittwoch gespannt :) .
Zitat von: CoolTux am 29 September 2018, 16:55:15... muss ich eine Interne Struktur für die Zuordnung schaffen, welche nach einem Reboot nicht nur erhalten bleibt sondern auch wieder sauber unser NOTIFYDEV befüllt ohne beim Start alle Rolläden und alle Attribute dessen Wert für unser NOTIFYDEV nötig ist durch zu gehen. Gerade beim oder nach einem Systemstart wäre das zu viel unnötige Last.
Ist ja gut, du bist der Modulautor und darfst entscheiden, wie es gemacht wird.

Nur finde ich diese Argumentation nicht wirklich überzeugend. Denn ob du die erforderlichen Infos (z.B. zum Temperatur-Reading) jetzt aus zwei Attributen holst oder nur aus einem und ein split drüber jagst, dürfte von der Systemlast her gedacht kaum einen Unterschied machen, eher im Gegenteil.
Und spätestens bei mehreren Roommates stelle ich mir das unübersichtlich vor, wenn du die Device- und Reading-Angabe auf zwei Attribute verteilst. Ist aber nur meine Meinung :) ...
Schönes WE allseits jedenfalls noch.
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 30 September 2018, 08:58:11
Auch hier keine Probleme, bin mal auf Mittwoch gespannt :) .
Ist ja gut, du bist der Modulautor und darfst entscheiden, wie es gemacht wird.

Nur finde ich diese Argumentation nicht wirklich überzeugend. Denn ob du die erforderlichen Infos (z.B. zum Temperatur-Reading) jetzt aus zwei Attributen holst oder nur aus einem und ein split drüber jagst, dürfte von der Systemlast her gedacht kaum einen Unterschied machen, eher im Gegenteil.
Und spätestens bei mehreren Roommates stelle ich mir das unübersichtlich vor, wenn du die Device- und Reading-Angabe auf zwei Attribute verteilst. Ist aber nur meine Meinung :) ...
Schönes WE allseits jedenfalls noch.

Das freut mich das es auch bei Dir gut geklappt hat. Bin zuversichtlich was Mittwoch an geht  :D

Beim Thema Device:Reading darf man mir gerne einen Patch anbieten. Ich hoffe sehr das die Struktur nun so bleibt und ich nichts mehr im groben ändern muss. Somit steht es jedem frei mit der morgen hochgeladenen Version eine Möglichkeit an zu bieten.



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

C0mmanda

Moin,

gibt es eine Möglichkeit Rolläden zu "synchronisieren" bzw was muss ich einstellen damit dem so ist?
Hintergrund: Im Wohn-Esszimmer habe ich insgesamt 3 Rolläden welche zeitgleich hoch- und herunterfahren sollten. (Beschattung später ausgenommen).

Gibt es da eine Möglichkeit?
Danke für die Info und für die großartige Arbeit :)

Gruß

CoolTux

Die Verzögerungsattribute auf 0 stellen, Default ist 1
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

CoolTux

#462
Ich habe soeben eine Fehlerbereinigte Version ins Git geschoben. Nun sollte auch der Status der Roommates korrekt erkannt werden wenn es mehr wie einer ist.

Gaaanz wichtig bei dieser neuen Version. Leider muss noch mal Hand an die Attribute der Rolläden angelegt werden.

Als erstes vor dem einspielen der neuen Version bitte folgendes Reading löschen

deletereading  ASControl .monitoredDevs


Bitte nicht den Punkt vor monitoredDevs vergessen.
Danach neue Version einspielen und neustarten von FHEM.
Als letztes müssen noch mal alle Rolläden angefasst werden. Einfach bei den Rolläden auf das Attribut ASC_WindowRec klicken und dann auf attr klicken damit attr Rolladen ASC_WindowRec ausgeführt wird.
Das selbe macht Ihr bei den Roommates, ändert aber bei den Rolläden wo mehr wie 1 Roommate beteiligt ist das Attribut vom structur Device zu roommate1,roommate2 und so weiter.




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

CoolTux

Und bitte nicht vergessen zu berichten. Commandref ziehe ich heute noch 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

FunkOdyssey

Ich habe bei mir nirgends das versteckte Reading .monitoredDevs.
Das LIST zeigt mir nichts an. Und aufs deletereading kommt nicht die erwartete Antwort. Demnach gehe ich davon aus, dass bei mir das Reading nicht existiert.


Ich habe bisher weder Roommate nocht Fenstergriffkontakt mit ASC genutzt. Das dürfte der Grund sein, oder?