[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

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

Vorheriges Thema - Nächstes Thema

CoolTux

Kann es sein das der Fensterkontakt kein event-on-change-reading hat. Dann wäre es nämlich das alive Reading was warum auch immer das ganze aus löst.
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

dancatt

Zitat von: CoolTux am 14 April 2019, 18:38:07
Kann es sein das der Fensterkontakt kein event-on-change-reading hat. Dann wäre es nämlich das alive Reading was warum auch immer das ganze aus löst.

Habe das Attribut event-on-change-reading nicht gesetzt. War bis jetzt noch nicht nötig. actCycle steht auf 028:00, actStatus steht auf alive.
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

majestro84

In der aktuellen Dev. Version habe ich noch festgestellt das bei einen Brightness Fenster wenn es geöffnet ist und ASC down durch ist, es später dann beim schließen die Fahrt nicht nachgeholt wird. Ich muss die Rolllade dann vom Hand schließen. Dann habe ich noch Astro Rollläden die wenn die Fenster vorm ASC Up öffne in die comfort Position fahren soweit alles gut nur werden sie wenn das ASC Up durch ist nicht komplett geöffnet sondern bleiben in der comfort Position. Wenn ich dann sie Fenster wieder schließe fahren sie runter mit ASC das Window Close. Selfdefense ist im ASC aus geschaltet. Vielleicht kannst du da noch einmal gucken. Schönen Rest Sonntag noch
Gruß Alex
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

dancatt

Der Rollladen ist eben wieder hochgefahren. Hier mal ein ausführliches Log:


2019.04.15 12:30:57.674 5: CUL_HM 1_02_WZ_Tuerkontakt protEvent:CMDs_done
2019.04.15 12:30:57.677 5: CUL_HM 1_02_WZ_Tuerkontakt sent ACK:2
2019.04.15 12:30:57.723 4: AutoShuttersControl (asc_Rollladen) - Devname: 1_02_WZ_Tuerkontakt Name: asc_Rollladen Notify: [
  'alive: yes',
  'battery: ok',
  'contact: closed (to VCCU)',
  'sabotageError: off',
  'state: closed'
]

2019.04.15 12:30:57.862 4: AutoShuttersControl (asc_Rollladen) - Devname: 1_02_WZ_Rollladen_r Name: asc_Rollladen Notify: [
  'inhibit: set_off'
]

2019.04.15 12:30:57.915 5: CUL_HM 1_02_WZ_Rollladen_r protEvent:CMDs_pending pending:1
2019.04.15 12:30:57.934 4: AutoShuttersControl (asc_Rollladen) - Devname: 1_02_WZ_Rollladen_r Name: asc_Rollladen Notify: [
  'state: set_inhibit off'
]

2019.04.15 12:30:57.979 3: CUL_HM set 1_02_WZ_Rollladen_r inhibit off
2019.04.15 12:30:57.982 5: CUL_HM 1_02_WZ_Rollladen_r protEvent:CMDs_pending pending:1
2019.04.15 12:30:58.053 4: AutoShuttersControl (asc_Rollladen) - Devname: 1_02_WZ_Rollladen_r Name: asc_Rollladen Notify: [
  'ASC_ShuttersLastDrive: window day closed'
]

2019.04.15 12:30:58.116 4: AutoShuttersControl (asc_Rollladen) - Devname: asc_Rollladen Name: asc_Rollladen Notify: [
  'state: window day closed'
]

2019.04.15 12:30:58.142 5: CUL_HM 1_02_WZ_Rollladen_r protEvent:CMDs_pending pending:2
2019.04.15 12:30:58.161 4: AutoShuttersControl (asc_Rollladen) - Devname: 1_02_WZ_Rollladen_r Name: asc_Rollladen Notify: [
  '[b]level: set_100[/b]'
]

2019.04.15 12:30:58.223 4: AutoShuttersControl (asc_Rollladen) - Devname: 1_02_WZ_Rollladen_r Name: asc_Rollladen Notify: [
  '[b]state: set_100[/b]'
]

2019.04.15 12:30:58.267 3: CUL_HM [b]set 1_02_WZ_Rollladen_r pct 100[/b]
2019.04.15 12:30:58.271 5: CUL_HM 1_02_WZ_Rollladen_r protEvent:CMDs_pending pending:2
2019.04.15 12:30:58.326 4: CUL_HM 1_02_WZ_Tuerkontakt dupe: dont process

2019.04.15 12:30:58.447 4: AutoShuttersControl (asc_Rollladen) - Devname: asc_Rollladen Name: asc_Rollladen Notify: [
  'state: manual'
]

2019.04.15 12:30:58.461 4: CUL_HM 1_02_WZ_Tuerkontakt dupe: dont process
2019.04.15 12:30:58.473 5: CUL_HM 1_02_WZ_Rollladen_r protEvent:CMDs_processing... pending:1
2019.04.15 12:30:58.649 5: CUL_HM 1_02_WZ_Rollladen_r protEvent:CMDs_pending pending:1
2019.04.15 12:30:58.684 4: AutoShuttersControl (asc_Rollladen) - Devname: 1_02_WZ_Rollladen_r Name: asc_Rollladen Notify: [
  'deviceMsg: off (to VCCU)',
  'level: 0',
  'motor: stop:off',
  'pct: 0',
  'state: off',
  'timedOn: off'
]

2019.04.15 12:30:58.703 4: AutoShuttersControl (asc_Rollladen) - Devname: asc_Rollladen Name: asc_Rollladen Notify: [
  '1_02_WZ_Rollladen_r_PosValue: 0'
]

2019.04.15 12:30:58.768 4: CUL_HM 1_02_WZ_Rollladen_r dupe: dont process
2019.04.15 12:30:58.775 5: CUL_HM 1_02_WZ_Rollladen_r protEvent:CMDs_processing... pending:0
2019.04.15 12:30:59.049 5: CUL_HM 1_02_WZ_Rollladen_r protEvent:CMDs_done
2019.04.15 12:30:59.082 4: AutoShuttersControl (asc_Rollladen) - Devname: 1_02_WZ_Rollladen_r Name: asc_Rollladen Notify: [
  'deviceMsg: off (to VCCU)',
  'level: 0',
  'motor: up:off',
  'pct: 0',
  'state: off',
  'timedOn: off'
]

2019.04.15 12:30:59.101 4: AutoShuttersControl (asc_Rollladen) - Devname: asc_Rollladen Name: asc_Rollladen Notify: [
  '1_02_WZ_Rollladen_r_PosValue: 0'
]

2019.04.15 12:30:59.167 4: CUL_HM 1_02_WZ_Rollladen_r dupe: dont process
2019.04.15 12:31:25.289 4: AutoShuttersControl (asc_Rollladen) - Devname: residents Name: asc_Rollladen Notify: [
  'durTimerAbsence_cr: 5310',
  'durTimerAbsence: 88:29:49'
]

2019.04.15 12:31:32.112 5: CUL_HM 1_02_WZ_Rollladen_r protEvent:CMDs_done
2019.04.15 12:31:32.114 5: CUL_HM 1_02_WZ_Rollladen_r sent ACK:2
2019.04.15 12:31:32.153 4: AutoShuttersControl (asc_Rollladen) - Devname: 1_02_WZ_Rollladen_r Name: asc_Rollladen Notify: [
  'deviceMsg: on (to VCCU)',
  'level: 100',
  'motor: stop:on',
  'pct: 100',
  'state: on',
  'timedOn: off'
]

2019.04.15 12:31:32.173 4: AutoShuttersControl (asc_Rollladen) - Devname: asc_Rollladen Name: asc_Rollladen Notify: [
  '1_02_WZ_Rollladen_r_PosValue: 100'
]

2019.04.15 12:31:32.252 4: CUL_HM 1_02_WZ_Rollladen_r dupe: dont process
2019.04.15 12:32:28.300 4: AutoShuttersControl (asc_Rollladen) - Devname: residents Name: asc_Rollladen Notify: [
  'durTimerAbsence_cr: 5311',
  'durTimerAbsence: 88:30:52'
]

2019.04.15 12:32:54.460 4: AutoShuttersControl (asc_Rollladen) - Devname: tw_Altenglan Name: asc_Rollladen Notify: [
  'azimuth: 158.18',
  'elevation: 49.83',
  'twilight: 100',
  'twilight_weather: 100',
  'compasspoint: south-southeast'
]

2019.04.15 12:33:31.303 4: AutoShuttersControl (asc_Rollladen) - Devname: residents Name: asc_Rollladen Notify: [
  'durTimerAbsence_cr: 5312',
  'durTimerAbsence: 88:31:55'
]
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

CoolTux

Setze event-on-change Reading für battery, sabotageError und state. Dein Sensor sendet alle 24 Stunden ein alive inklusive dem Status aller Readings.
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

majestro84

Zitat von: CoolTux am 28 Februar 2019, 09:09:18
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.
Mal eine Frage wo finde ich den die angepasste Commandref?
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

CoolTux

Dafür musst Du die Commandref neu erstellen lassen

cd /opt/fhem
/usr/bin/perl contrib/commandref_join.pl

Alles aus dem Kopf. Bin gerade im Naturkundemuseum.
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

Wenn zwischendurch auch ein (normales) update gelaufen ist, sollte die mit help AutoShuttersControl in der aktuellen Fassung da sein :) .

@CoolTux:
Da grade Ferien sind, wollte ich nochmal bzgl. Comfort-Lüften darauf zurückkommen, dass der Rollladen nach dem Lüften nicht wieder schließen muß, wenn er am WE (sind hier grade Ferien) nach dem "unter-der-Woche"-Zeitpunkt oberhalb oder gleich der Offen-Position steht.
Geht darum, auch Lärm zu vermeiden... (Oder übersehe ich wieder eine Einstelloption?)(Betrifft hier twostate und threestate Sensoren gleichermaßen)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

majestro84

Danke für die Info Cooltux und Beta-User. Wieder einmal was dazu gelernt. Mit
/usr/bin/perl ./contrib/commandref_join.pl
hat es geklappt.

Gruß Alex
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

CoolTux

Zitat von: Beta-User am 16 April 2019, 12:19:41
Wenn zwischendurch auch ein (normales) update gelaufen ist, sollte die mit help AutoShuttersControl in der aktuellen Fassung da sein :) .

@CoolTux:
Da grade Ferien sind, wollte ich nochmal bzgl. Comfort-Lüften darauf zurückkommen, dass der Rollladen nach dem Lüften nicht wieder schließen muß, wenn er am WE (sind hier grade Ferien) nach dem "unter-der-Woche"-Zeitpunkt oberhalb oder gleich der Offen-Position steht.
Geht darum, auch Lärm zu vermeiden... (Oder übersehe ich wieder eine Einstelloption?)(Betrifft hier twostate und threestate Sensoren gleichermaßen)

Wenn ich Dich richtig verstehe dann ist das Fenster vor dem errechneten Sunrise geöffnet und wieder geschlossen worden. Korrekt? Wenn ja dann ist es richtig daß er wieder runter fährt, denn für ASC bedeutet es, es ist Nacht.
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

stefanpf

Das mit dem Lüften lässt sich ggf mit einer geschickt gewählten ASC_BlockingTime_beforDayOpen lösen.
Ich verwende dass derzeit mit 36000 Sekunden da das ASC Mode_Down=absent an der Stelle nicht ausgewertet wird und die Rollläden bleiben ab 22:00 anschließend oben.

Müssen ja nicht gleich 10h sein :)

Prof. Dr. Peter Henning

readingsUpdate(,state,manual) missed to call readingsBeginUpdate first.
2019.04.17 04:52:26 1: stacktrace:
2019.04.17 04:52:26 1:     main::readingsBulkUpdate            called by fhem.pl (4867)
2019.04.17 04:52:26 1:     main::readingsSingleUpdate          called by /opt/fhem/FHEM/73_AutoShuttersControl.pm (4227)
2019.04.17 04:52:26 1:     ASC_Dev::Readings::setStateReading  called by /opt/fhem/FHEM/73_AutoShuttersControl.pm (1892)
2019.04.17 04:52:26 1:     FHEM::AutoShuttersControl::EventProcessingShutters called by /opt/fhem/FHEM/73_AutoShuttersControl.pm (361)
2019.04.17 04:52:26 1:     FHEM::AutoShuttersControl::Notify   called by fhem.pl (3698)
2019.04.17 04:52:26 1:     main::CallFn                        called by fhem.pl (3618)
2019.04.17 04:52:26 1:     main::DoTrigger                     called by fhem.pl (3984)
2019.04.17 04:52:26 1:     main::Dispatch                      called by /opt/fhem/FHEM/00_CUL.pm (948)
2019.04.17 04:52:26 1:     main::CUL_Parse                     called by /opt/fhem/FHEM/00_CUL.pm (832)
2019.04.17 04:52:26 1:     main::CUL_Read                      called by fhem.pl (3698)
2019.04.17 04:52:26 1:     main::CallFn                        called by fhem.pl (745)


in Version 0.4.0.9

LG

pah

Beta-User

Zitat von: stefanpf am 17 April 2019, 01:15:24
Das mit dem Lüften lässt sich ggf mit einer geschickt gewählten ASC_BlockingTime_beforDayOpen lösen.
Ich verwende dass derzeit mit 36000 Sekunden da das ASC Mode_Down=absent an der Stelle nicht ausgewertet wird und die Rollläden bleiben ab 22:00 anschließend oben.

Müssen ja nicht gleich 10h sein :)
Danke für den Vorschlag. Zeigt zumindest auch, dass ich mit dem "Problem" nicht ganz alleine bin.

M.E. sollte das insgesamt unter Berücksichtigung der bekannten Vorgaben etwas dynamischer umgesetzt werden und stelle das als feature-Request mal zur Diskussion.
Die Gedanken dazu hatte ich vor längerem mal zusammengetragen
Zitat von: Beta-User am 05 März 2019, 09:28:108. (Hat vermutlich nichts mit der Entwicklerversion zu tun:)
Bei uns sind grade Ferien, also WE=true. Trotzdem sind wir heute alle recht früh aufgestanden, und da draußen schon hell war, wurden auch manuell die Rollläden gefahren (nach der frühesten allg. Aufsteh-Zeit). Irgendwann sind sie wieder runter, zu einer Zeit, von der ich erst nicht wußte, wo die herkommt.
Meine Vermutung: Die Blocking-time war abgelaufen (wenn man's nicht verstellt hat eine Stunde, oder?)...

Mein Wunsch: Wenn eine manuelle Öffnen-Fahrt auf offen (oder weiter als offen) gemacht wird, und das morgens nach der frühesten Öffnen-Zeit stattfindet, nicht mehr schließen. (Wo ich das schreibe: Eigentlich geht es nicht um die Zeit des manuellen Öffnens, sondern um den Ablauf der blocking-Time: liegt die nach dem frühesten Öffnen => betrachte die morgendliche Fahrt als erledigt...)
Ob man den Gedanken auf Abends entsprechend übertragen kann, wäre noch zu überlegen, wollte erst mal deine Rückmeldung haben, ob das sinnvoll ist, einigermaßen ohne Unfall umzusetzen wäre usw....
MaW: Öffnet ein User ein Fenster nach (frühester Öffnenzeit (ohne WE) - blockingTime_morgens) soll ASC davon ausgehen, dass die Nacht an dem Fenster vorbei ist...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

majestro84

Zitat von: Beta-User am 17 April 2019, 09:09:55
Danke für den Vorschlag. Zeigt zumindest auch, dass ich mit dem "Problem" nicht ganz alleine bin.

M.E. sollte das insgesamt unter Berücksichtigung der bekannten Vorgaben etwas dynamischer umgesetzt werden und stelle das als feature-Request mal zur Diskussion.
Die Gedanken dazu hatte ich vor längerem mal zusammengetragenMaW: Öffnet ein User ein Fenster nach (frühester Öffnenzeit (ohne WE) - blockingTime_morgens) soll ASC davon ausgehen, dass die Nacht an dem Fenster vorbei ist...
Finde ich gut den Vorschlag. Ich habe ja auch das Problem das sie nach dem day Open trotzdem wieder schließen passiert das bei nicht?
Server: Fujitsu ESPRIMO Q920 - aktuellen FHEM-Docker Image:Z-Wave (RollerShutter,DoorWindow,Socket,PIR,....) | ENIGMA2 | EGPM2LAN | BLE-Tag(PRESENCE) | HUE | alexa-fhem | Shelly | MQTT2
1.Pi-Zero:Viessmann(optolink) mit 89_VCONTROL300.pm
2.Pi3 Dongle Server: Zigbee2MQTT(CC1352P-2), Z-Wave(UZB1), BT

CoolTux

Zitat von: majestro84 am 17 April 2019, 09:33:33
Finde ich gut den Vorschlag. Ich habe ja auch das Problem das sie nach dem day Open trotzdem wieder schließen passiert das bei nicht?

Das sollte mit der neusten Entwicklerversion aber nicht mehr der Fall sein.
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