Betatester für neues Modul AutoShuttersControl gesucht!

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

Vorheriges Thema - Nächstes Thema

Papaloewe

und hier noch der List des Fenstekontaktes:
Internals:
   CFGFN     
   DEF        56B2CB
   HMLAN1_MSGCNT 35
   HMLAN1_RAWMSG E56B2CB,0000,F24FB12E,FF,FFAA,D1A61056B2CB123ABC0601C800
   HMLAN1_RSSI -86
   HMLAN1_TIME 2018-10-13 21:41:03
   HMUART_MSGCNT 39
   HMUART_RAWMSG 05010040D1A61056B2CB123ABC0601C800
   HMUART_RSSI -64
   HMUART_TIME 2018-10-13 21:41:03
   IODev      HMUART
   LASTInputDev HMLAN1
   MSGCNT     112
   NAME       EG.WZ.TFK.li
   NOTIFYDEV  global
   NR         518
   NTFY_ORDER 50-EG.WZ.TFK.li
   STATE      auf
   TYPE       CUL_HM
   hmusb_MSGCNT 38
   hmusb_RAWMSG E56B2CB,0000,0C730A92,FF,FFB0,D1A61056B2CB123ABC0601C800
   hmusb_RSSI -80
   hmusb_TIME 2018-10-13 21:41:03
   lastMsg    No:D1 - t:10 s:56B2CB d:123ABC 0601C800
   peerList   EG.WZ.HZ_WindowRec,
   protLastRcv 2018-10-13 21:41:03
   protRcv    47 last_at:2018-10-13 21:41:03
   protRcvB   16 last_at:2018-10-13 20:28:27
   protSnd    31 last_at:2018-10-13 21:41:03
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:35 min:-106 max:-82 avg:-88.14 lst:-86
   rssi_at_HMUART cnt:39 min:-77 max:-58 avg:-65.3 lst:-64
   rssi_at_hmusb cnt:38 min:-83 max:-65 avg:-73.81 lst:-80
   Helper:
     DBLOG:
       battery:
         myDbLog:
           TIME       1539459663.27707
           VALUE      ok
       state:
         myDbLog:
           TIME       1539459663.27707
           VALUE      auf
   READINGS:
     2018-10-13 09:39:22   Activity        alive
     2018-02-24 17:17:06   CommandAccepted yes
     2018-02-24 17:17:44   D-firmware      1.0
     2018-02-24 17:17:44   D-serialNr      OEQ0223451
     2018-02-24 17:17:45   PairedTo        0x123ABC
     2018-02-24 17:10:53   R-EG.WZ.HZ_WindowRec-expectAES off
     2018-02-24 17:10:53   R-EG.WZ.HZ_WindowRec-peerNeedsBurst on
     2018-02-17 13:15:35   R-cyclicInfoMsg on
     2018-02-24 17:17:46   R-eventDlyTime  20 s
     2018-02-24 17:17:46   R-msgScPosA     open
     2018-02-24 17:17:46   R-msgScPosB     closed
     2018-02-17 13:29:44   R-pairCentral   0x123ABC
     2018-02-17 13:15:35   R-sabotageMsg   on
     2018-02-24 17:17:46   R-sign          on
     2018-02-17 13:15:35   R-transmDevTryMax 6
     2018-02-24 17:17:46   R-transmitTryMax 6
     2018-02-24 17:17:06   aesCommToDev    ok
     2018-02-24 17:17:06   aesKeyNbr       00
     2018-10-13 21:41:03   alive           yes
     2018-10-13 21:41:03   battery         ok
     2018-10-13 21:41:03   contact         open (to vccu)
     2018-10-13 09:39:22   peerList        EG.WZ.HZ_WindowRec,
     2018-08-22 19:41:15   powerOn         2018-08-22 19:41:15
     2018-10-13 21:41:03   recentStateType info
     2018-02-17 13:29:46   sabotageAttack_ErrIoAttack cnt 1
     2018-10-13 21:41:03   sabotageError   off
     2018-10-13 21:41:03   state           open
     2018-02-24 16:27:48   trigDst_EG.WZ.HZ_Unit noConfig
     2018-10-13 20:28:28   trigger_cnt     176
   helper:
     HM_CMDNR   209
     mId        00C7
     regLst     ,0,1,4p
     rxType     28
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     io:
       newChn     +56B2CB,00,01,00
       nextSend   1539459663.30701
       prefIO     
       rxt        2
       vccu       vccu
       p:
         56B2CB
         00
         01
         00
     mRssi:
       mNo        D1
       io:
         HMLAN1:
           -86
           -86
         HMUART:
           -60
           -60
         hmusb:
           -80
           -80
     prt:
       bErr       0
       sProc      0
       sleeping   0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         HMUART
       flg        A
       ts         1539459663.21271
       ack:
         HASH(0xd5ab5f0)
         D18002123ABC56B2CB00
     rssi:
       at_HMLAN1:
         avg        -88.1428571428571
         cnt        35
         lst        -86
         max        -82
         min        -106
       at_HMUART:
         avg        -65.3076923076923
         cnt        39
         lst        -64
         max        -58
         min        -77
       at_hmusb:
         avg        -73.8157894736842
         cnt        38
         lst        -80
         max        -65
         min        -83
     shadowReg:
     tmpl:
Attributes:
   Fenster    TFK_FG
   IODev      HMUART
   IOgrp      vccu
   actCycle   002:50
   actStatus  alive
   autoReadReg 0_off
   devStateIcon auf:fts_window_2w_open_l@red zu:fts_window_2w@green
   event-on-change-reading state
   event-on-update-reading state,battery
   eventMap   closed:zu open:auf
   expert     1_allReg
   firmware   1.0
   group      Türen
   model      HM-SEC-SCo
   peerIDs    00000000,21CCA103,
   room       Wohnen
   serialNr   OEQ0223451
   subType    threeStateSensor
   userattr   Fenster Fenster_map structexclude

CoolTux

Dennoch ist im Moduldevice lockOut und PartyMode auf on

Und gibt es nun Events in FHEM wenn der Rolladen fährt? Wenn müssten Events vom Fensterkontakt kommen

Beim Fensterkontakt ist das hier Unsinn
event-on-change-reading state
event-on-update-reading state,battery


Wenn dann
event-on-change-reading state
event-on-update-reading battery
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

Papaloewe

Ok, da hast du recht.

Ich sehe gerade beim List des UM Fensterkontakt steht unter subtype threestatesensor?

CoolTux

Zitat von: Papaloewe am 13 Oktober 2018, 23:16:25
Ok, da hast du recht.

Ich sehe gerade beim List des UM Fensterkontakt steht unter subtype threestatesensor?

Das wird vom Modul nicht beachtet. Entscheidend ist was du als Attribut beim Rolladen hinterlegst.
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

Papaloewe

Zitat von: CoolTux am 13 Oktober 2018, 22:22:34

Beim Fensterkontakt ist das hier Unsinn
event-on-change-reading state
event-on-update-reading state,battery


Wenn dann
event-on-change-reading state
event-on-update-reading battery

Ja das war's, sorry und danke für den Hinweis!

CoolTux

#575
Ich habe am Wochenende die neue Version getestet. Sieht gut aus.
Hier könnt sie Euch über GitHub runterladen.

Neu ist das die Rolläden bei SelfDefense nach dem nach Hause kommen wieder in ihre alte Stellung fahren.

SelfDevence kann pro Rolladen gesteuert werden Attr ASC_Self_Devence_Exclude on/off bei on wird SelfDevence nicht angewand.

Das öffnen und schließen Morgens und Abends kann per Brightness konfiguriert werden.
Dazu muss im Moduldevice Attr ASC_brightnessMinVal gesetzt werden. Desweiteren muss korrekt
ASC_Time_Down_Early
ASC_Time_Down_Late
ASC_Time_Up_Early
ASC_Time_Up_Late
korrekt gesetzt werden. Und nur zwischen Down_Early und Down_Late wird die Brightness aus gewertet und wenn drunter dann runter gefahren Abends und wenn drüber dann hoch gefahren Morgens.

Und ich habe den einen oder anderen kleinen Bug gefixt.
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

Papaloewe

Bin wahrscheinlich gerade mal wieder blind, aber wo gebe ich das Device und das Reading für Brightness an?

CoolTux

Commandref bitte lesen.
Device im Rolläden und Brightness Wert im ASC Device.
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

Zitat von: CoolTux am 15 Oktober 2018, 06:21:45

Das öffnen und schließen Morgens und Abends kann per Brightness konfiguriert werden.
Dazu muss im Moduldevice Attr ASC_brightnessMinVal gesetzt werden. Desweiteren muss korrekt
ASC_Time_Down_Early
ASC_Time_Down_Late
ASC_Time_Up_Early
ASC_Time_Up_Late
korrekt gesetzt werden. Und nur zwischen Down_Early und Down_Late wird die Brightness aus gewertet und wenn drunter dann runter gefahren Abends und wenn drüber dann hoch gefahren Morgens.

Vielen Dank. Aber soll der Helligkeitswert (via ASC_brightnessMinVal) wirklich nur im Modul hinterlegt werden? Kann ich das gar nicht je Jalousie steuern?
So gibt es doch nun keine Möglichkeit mehr, das Hoch- und Runterfahren zu entzerren, oder? Ich fahre bspw. die Jalousien in einigen sensiblen Bereichen (Gäste-WC, einsehbare Räume) bereits bei einer geringeren Dämmerung runter.

CoolTux

Keine Ahnung. Kann mich da an keine genaue Anforderung erinnern  ;D
Sollte aber nicht so das Problem sein da noch was ein zu bauen. Ist ja vielleicht auch für die Beschattung ganz gut.
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

hexenmeister

Ich denke auch, dass getrennte Angaben für die Grenzhelligkeit sinnvoll ist. Es sind nicht nur Räume, wie WC/Bad, es sind auch unterschiedliche Lichtsituationen in Räumen. So wird in einem Raum oft schneller dunkler, weil z.B. vor dem Fenster ein Baum steht.

Noch eine Idee wäre, Rollläden früher zu schliessen, wenn im betroffenen Raum Licht angeht. Das könnte gleich auf Arten überwacht werden: rauminterne Lichtsensoren und Readings der Lampenaktoren. Halte Unterstützung für beides gleichzeitig für sinnvoll.
Ist natürlich nur ein Vorschlag, bei der Vielzahl der unterschiedlichen Einsatzszenarien kann man sich sicher vieles einfallen lassen ;)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

CoolTux

Zitat von: hexenmeister am 16 Oktober 2018, 07:26:41
Noch eine Idee wäre, Rollläden früher zu schliessen, wenn im betroffenen Raum Licht angeht. Das könnte gleich auf Arten überwacht werden: rauminterne Lichtsensoren und Readings der Lampenaktoren. Halte Unterstützung für beides gleichzeitig für sinnvoll.
Ist natürlich nur ein Vorschlag, bei der Vielzahl der unterschiedlichen Einsatzszenarien kann man sich sicher vieles einfallen lassen ;)

Darüber können wir uns dann gerne zu einem späteren Zeitpunkt unterhalten. Die Idee finde ich gut.
Jetzt baue ich erstmal noch die Brightness Werte pro Rolladen ein und dann testen wir erstmal ausgiebig. Danach wird die Abschattung in Angriff genommen.
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


hexenmeister

Zitat von: CoolTux am 16 Oktober 2018, 08:24:40
Darüber können wir uns dann gerne zu einem späteren Zeitpunkt unterhalten. Die Idee finde ich gut.

Sehe ich auch so. Schritt nach Schritt und nicht überstürzen :D
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

CoolTux

neue Version 0.1.80 habe ich soeben ins Git geladen. Nun kann man auch am Rolladen selbst die Brightness einstellen.


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