[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.6.x

Begonnen von CoolTux, 27 April 2019, 08:04:52

Vorheriges Thema - Nächstes Thema

CoolTux

1. Das Wiki ist eine Anlaufstelle, aber nicht DIE Anlaufstelle. Die Commandref sollte immer die erste Lesestelle sein
2. Wenn im Wiki etwas nicht so ist wie im Modul dann gibt man im entsprechenden Thread Bescheid (hast Du ja jetzt gemacht, Danke dafür)
3. Deine Aussage liest sich wie ich editiere die fhem.conf. Da ich mich damit nicht auskenne kann ich dazu nichts sagen.

Checkliste:
Du liest die Commandref!!
Du hast die Commandref gelesen!
Du hast Rollo Devices!
Du hast EIN ASC Device!
Du hast das globale Attribut ASC entsprechend mit Wert in den Rollos vergeben!
Du hast danach nach den Rollos gescannt!
Du hast nun diverse Attribute ZUR AUSWAHL in den Rollo Devices!



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: magentouser am 05 Juni 2019, 15:36:50
auf https://wiki.fhem.de/wiki/AutoShuttersControl#Vorbereitung sind die werte beschrieben,
waren vor dem update (bei mir gestern) da und haben funktioniert. [...]
Schau mal in die aktuelle cref; die Attribute wurden zum Teil zusammengefaßt, die neuen Attribute sollten - soweit erforderlich - aus den alten Inhalten bereits gefüllt sein.

(Ansonsten für den Fall des config-editierens: meistens keine gute Idee...)



@CoolTux:
Ich habe (immer noch...) das Thema mit dem Wiki vorrangig im Auge, aber grade nicht die Ruhe, das alles durchzugehen, daher melde ich mich für das Gegenlesen der engl. cref mal vorerst ab (werde die aber ggf. nutzen, wenn ich das nochmal durchgehe und mich melden, wenn mir zu gegebener Zeit was auffällt).

Grundsätzlich dürfen wir aber davon ausgehen, dass Christoph Morrison da ganze Arbeit geleistet hat; es wäre daher m.E. am besten, diese Fassung zu publizieren und dann ggf. bei Bedarf (!) nachlaufend Korrekturen zu machen :) .
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

CoolTux

Bin ich voll und ganz bei Dir.
Aktuell habe ich Männergrippe und mich schon mal mit kalten nassen Sand eingerieben. Nur um schon mal ein Gefühl dafür zu bekommen. Probiere aber vorher die aktuelle englische cref ein zu pflegen.


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

magentouser

config edititieren, mache ich sonst nicht, aber wenn ein system bei manuellen änderungen versagen würde wärs nichts wert, aber fhem hat da bisher im gegensatz zu usern bisher keine probleme gesehen.
so viel dazu. PS bin halt kein mausschubser, nano ist mir noch am liebsten

wenn man eine neue version bringt sollte dies die alten werte eigentlich übernehmen und den neuen zuordnen, dies ist hier nicht passiert, ich habe nun eine backup der 73_Au... eingespielt und schon geht wieder alles.

kann man irgendwie dem fhem sagen das es dies nicht updaten soll. bisher hatte keines der plugins hier solche probleme verursacht.

D3ltorohd

Grüß dich @CoolTux

Ich hätte noch mal eine Frage zur Beschattung, es ist also nicht möglich anstelle der Sensorwerte, Werte aus Wettermodulen zu nehmen ? Ich brauche zwingend einen Sensor, der Temp und Helligkeit als Daten ausgeben kann ? Da der Pflanzensensor wohl nicht gleich funkt wie die zb Fensterkontakte, bräuchte ich hier ja wieder nen eigenen Empfänger, dann müsste ich vllt auf den Homematic Sensor ausweichen, welchen hast du da gemeint ? Kann man dann den Sensor mit einem Cul Stick betreiben, wie die Max Geräte ?

Gibt es vllt eine alternative, das ich Tags über auch noch mal feste Zeiten angeben kann ab denen der Rollo wieder zu fährt auf z.b. 70 % und später abends dann eben ganz runter fährt, so eine Zwischenzeit um die Beschattung eben zu einer festen Zeit ein zu stellen, das würde mir erst mal auch helfen.

EDIT: Ich hätte hier z.b. noch Wandthermostate von Max, könnte ich den für die Temp auch nehmen ? Kann ich ja sagen wenn es drin wärmer wie 20 Grad wird, beschatten ?
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

CoolTux

Im Grunde kannst Du jedes Device nehmen welches äquivalente Daten für Temperatur und Helligkeit liefert. Wenn Du Wetterdaten aus der Cloud hast welches das können.

Eine Zeitliche Begrenzung für die Beschattung gibt es so nicht.
Du kannst aber die Beschattung mittels set ControlShading off deaktivieren.
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

volschin

Du kannst dir einen Dummy als brightness Sensor anlegen und in diesen einen Wert größer als Shadow in eintragen, dann geht das Rollo runter sobald die Geo-Daten bzgl. Sonneneinfall stimmen.


Gesendet von iPhone mit Tapatalk
Intel NUC+Ubuntu 24.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7690, Echo Dots+Show8, HomeBridge

CoolTux

Zitat von: magentouser am 05 Juni 2019, 16:01:13
config edititieren, mache ich sonst nicht, aber wenn ein system bei manuellen änderungen versagen würde wärs nichts wert, aber fhem hat da bisher im gegensatz zu usern bisher keine probleme gesehen.
so viel dazu. PS bin halt kein mausschubser, nano ist mir noch am liebsten

wenn man eine neue version bringt sollte dies die alten werte eigentlich übernehmen und den neuen zuordnen, dies ist hier nicht passiert, ich habe nun eine backup der 73_Au... eingespielt und schon geht wieder alles.

kann man irgendwie dem fhem sagen das es dies nicht updaten soll. bisher hatte keines der plugins hier solche probleme verursacht.

Bisher hat sich der große Teil bezüglich der Übernahme der alten Daten (ja das Modul macht das) nicht beschwert. Scheint also weitestgehend zu klappen.
Du kannst das Modul gerne unter global vom Update excluden. Aber!
KLEINE WARNUNG!!! Mit dem nächsten Update entferne ich bereits die automatische Übernahme der Daten. Es sind bereits 1,5 Monate vergangen seit der Veröffentlichung der 0.6er Version und somit der neuen Attribute.
Das Modul selbst ist in der Beta Phase und sehr sehr schnelllebig aktuell, die meisten der User hier profitieren von dieser Schnelllebigkeit ja sie sind sogar Schuld durch Ihre nützlichen und guten Anforderungen.

Wenn Dir das zu viel ist kannst Du auch eine eigene Lösung verwenden oder Bernd seine Scriptlösung.


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

Vorab mal viel Genesungserfolg mit der Sandmethode!

Habe eben noch im Wiki zwei Hinweisboxen zu cref und wiki und zu den optionalen Angaben hier reingepfriemelt: https://wiki.fhem.de/wiki/AutoShuttersControl#Attribute
Wäre nett, wenn du bei Gelegenheit mal drübersehen könntest, ob das mit den Defaults so sachlich korrekt ist. In der d-cref im svn habe ich dazu nichts gefunden. Außerdem wäre es gut, dann den Standard auch tatsächlich entsprechend durchzuziehen. Auf die Schnelle paßt das z.B. bei rain/residents/temp/wind für das ASC-Device noch nicht.

(Ist aber nur ein Vorschlag, kann man auch anders machen, wenn jemand einen besseren hat...)


@magentouser:
Deine Enttäuschung ist zwar verständlich, aber dass hier noch heftig entwickelt wird, war doch einigermaßen gut zu erkennen => Risiko für Nacharbeit konnte man kaum übersehen.

Und es ist eine einmalige Aktion, das umzustellen; sollte nicht so viel Aufwand sein, und die neue Version hat auch ihre Vorteile ;D .
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

CoolTux

Zitat von: Beta-User am 05 Juni 2019, 16:20:02
Vorab mal viel Genesungserfolg mit der Sandmethode!
Die Sandmethode war nicht zur Genesung sondern um ein Gefühl für die kalte nasse Stelle unter der Erde zu bekommen. Männergrippe halt.  ;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

coolice

Hallo zusammen, hab seit Ewigkeiten wieder ein Update gemacht und prompt fahren die Rollos nicht mehr in die Beschattung.

List ASC Device
FUUID      5c4f4fb8-f33f-6642-e075-fc18994ae059b025
   FVERSION   73_AutoShuttersControl.pm:v0.6.14-s19487/2019-05-29 UNDER DEVELOP
   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
   NAME       AutoShuttersControl
   NOTIFYDEV  global,AutoShuttersControl,Rol.DG.bu,Rol.DG.bz,Rol.OG.bz,Rol.OG.ki,Rol.OG.ku,Rol.OG.sz,Rol.OG.wz.1,Rol.OG.wz.2,Rol.OG.wz.3,Rol.OG.wz.4,Rol.OG.wz.5,rgr_HomeSweetHome,OG.sz.FD,OG.wz.FD.5,OG.wz.FD.4,Twilight,OG.ku.FD,AG.balkon.BM,OG.wz.FD.1,OG.bz.FD,OG.ki.FD
   NR         368
   NTFY_ORDER 51-AutoShuttersControl
   STATE      manual
   TYPE       AutoShuttersControl
   VERSION    0.6.14
   OLDREADINGS:
   READINGS:
     2019-06-05 06:30:09   Rol.DG.bu_PosValue 100
     2019-06-02 19:03:14   Rol.DG.bu_lastPosValue 10
     2019-06-02 15:28:12   Rol.DG.bu_nextAstroTimeEvent  2.06.2019 - 21:45
     2019-05-19 21:45:02   Rol.DG.bz_lastPosValue 100
     2019-06-02 15:28:12   Rol.DG.bz_nextAstroTimeEvent  2.06.2019 - 21:45
     2019-06-05 06:15:15   Rol.OG.bz_PosValue 100
     2019-05-17 07:00:02   Rol.OG.bz_lastDelayPosValue 100
     2019-05-19 21:45:02   Rol.OG.bz_lastPosValue 100
     2019-06-02 15:28:12   Rol.OG.bz_nextAstroTimeEvent  2.06.2019 - 21:45
     2019-06-05 06:29:38   Rol.OG.ki_PosValue 100
     2019-05-19 21:45:02   Rol.OG.ki_lastPosValue 100
     2019-06-02 15:28:12   Rol.OG.ki_nextAstroTimeEvent  2.06.2019 - 21:45
     2019-06-05 06:29:34   Rol.OG.ku_PosValue 100
     2019-06-02 19:03:15   Rol.OG.ku_lastPosValue 30
     2019-06-02 15:28:12   Rol.OG.ku_nextAstroTimeEvent  2.06.2019 - 21:45
     2019-06-05 07:07:25   Rol.OG.sz_PosValue 100
     2019-05-29 18:56:25   Rol.OG.sz_lastPosValue 10
     2019-06-02 15:28:12   Rol.OG.sz_nextAstroTimeEvent  2.06.2019 - 21:45
     2019-06-05 06:29:45   Rol.OG.wz.1_PosValue 100
     2019-05-19 10:00:02   Rol.OG.wz.1_lastDelayPosValue 100
     2019-05-19 21:45:02   Rol.OG.wz.1_lastPosValue 100
     2019-06-02 15:28:12   Rol.OG.wz.1_nextAstroTimeEvent  2.06.2019 - 21:45
     2019-06-05 06:29:49   Rol.OG.wz.2_PosValue 100
     2019-06-02 19:03:15   Rol.OG.wz.2_lastPosValue 20
     2019-06-02 15:28:12   Rol.OG.wz.2_nextAstroTimeEvent  2.06.2019 - 21:45
     2019-06-05 06:29:49   Rol.OG.wz.3_PosValue 100
     2019-06-02 19:03:15   Rol.OG.wz.3_lastPosValue 20
     2019-06-02 15:28:12   Rol.OG.wz.3_nextAstroTimeEvent  2.06.2019 - 21:45
     2019-06-05 06:30:10   Rol.OG.wz.4_PosValue 100
     2019-05-18 10:00:03   Rol.OG.wz.4_lastDelayPosValue 100
     2019-05-19 21:45:03   Rol.OG.wz.4_lastPosValue 40
     2019-06-02 15:28:12   Rol.OG.wz.4_nextAstroTimeEvent  2.06.2019 - 21:45
     2019-06-05 06:29:32   Rol.OG.wz.5_PosValue 100
     2019-05-19 21:45:03   Rol.OG.wz.5_lastPosValue 100
     2019-06-02 15:28:12   Rol.OG.wz.5_nextAstroTimeEvent  2.06.2019 - 21:45
     2019-06-02 15:22:14   ascEnable       on
     2019-06-02 15:22:22   controlShading  on
     2019-06-02 15:22:31   hardLockOut     on
     2019-01-19 15:40:14   partyMode       off
     2019-03-08 05:47:06   rg_ASC_Rollaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \  ASC_Time_Down_Early => 'ASC_Time_Down_Early:15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00', \  ASC_Time_Down_Late  => 'ASC_Time_Down_Late:19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30', \  ASC_Time_Up_WE_Holiday => 'ASC_Time_Up_WE_Holiday:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',\  ASC_Time_Up_Early => 'ASC_Time_Up_Early:05:00,05:05,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',  \ _nextAstroTimeEvent  8.03.2019 - 19:28
     2019-06-02 15:28:07   room_Dachgeschoss-_Badezimmer_Rollladen Rol.DG.bz
     2019-06-02 15:28:07   room_Dachgeschoss-_Buero_Rollladen Rol.DG.bu
     2019-06-02 15:28:07   room_Obergeschoss-_Badezimmer_Rollladen Rol.OG.bz
     2019-06-02 15:28:07   room_Obergeschoss-_Kinderzimmer_Rollladen Rol.OG.ki
     2019-06-02 15:28:07   room_Obergeschoss-_Kueche_Rollladen Rol.OG.ku
     2019-06-02 15:28:07   room_Obergeschoss-_Schlafzimmer_Rollladen Rol.OG.sz
     2019-06-02 15:28:07   room_Obergeschoss-_Wohnzimmer_Rollladen Rol.OG.wz.1,Rol.OG.wz.2,Rol.OG.wz.3,Rol.OG.wz.4,Rol.OG.wz.5
     2019-01-19 15:40:14   selfDefense     off
     2019-06-05 07:07:04   state           manual
     2019-06-02 15:22:43   sunriseTimeWeHoliday on
     2019-06-02 15:28:07   userAttrList    rolled out
   helper:
     shuttersList:
       Rol.DG.bu
       Rol.DG.bz
       Rol.OG.bz
       Rol.OG.ki
       Rol.OG.ku
       Rol.OG.sz
       Rol.OG.wz.1
       Rol.OG.wz.2
       Rol.OG.wz.3
       Rol.OG.wz.4
       Rol.OG.wz.5
   monitoredDevs:
     AG.balkon.BM:
       Rol.DG.bu  ASC_BrightnessSensor
       Rol.DG.bz  ASC_BrightnessSensor
       Rol.OG.bz  ASC_BrightnessSensor
       Rol.OG.ki  ASC_BrightnessSensor
       Rol.OG.ku  ASC_BrightnessSensor
       Rol.OG.sz  ASC_BrightnessSensor
       Rol.OG.wz.1 ASC_BrightnessSensor
       Rol.OG.wz.2 ASC_BrightnessSensor
       Rol.OG.wz.3 ASC_BrightnessSensor
       Rol.OG.wz.4 ASC_BrightnessSensor
       Rol.OG.wz.5 ASC_BrightnessSensor
     OG.bz.FD:
       Rol.OG.bz  ASC_WindowRec
     OG.ki.FD:
       Rol.OG.ki  ASC_WindowRec
     OG.ku.FD:
       Rol.OG.ku  ASC_WindowRec
     OG.sz.FD:
       Rol.OG.sz  ASC_WindowRec
     OG.wz.FD.1:
       Rol.OG.wz.1 ASC_WindowRec
     OG.wz.FD.4:
       Rol.OG.wz.4 ASC_WindowRec
     OG.wz.FD.5:
       Rol.OG.wz.5 ASC_WindowRec
     Rol.DG.bu:
     Rol.DG.bz:
     Rol.OG.bz:
     Rol.OG.ki:
     Rol.OG.ku:
     Rol.OG.sz:
     Rol.OG.wz.1:
     Rol.OG.wz.2:
     Rol.OG.wz.3:
     Rol.OG.wz.4:
     Rol.OG.wz.5:
     Twilight:
       AutoShuttersControl ASC_twilightDevice
     rgr_HomeSweetHome:
       AutoShuttersControl ASC_residentsDev
       Rol.DG.bu  ASC_Roommate_Device
       Rol.OG.ku  ASC_Roommate_Device
       Rol.OG.sz  ASC_Roommate_Device
       Rol.OG.wz.1 ASC_Roommate_Device
       Rol.OG.wz.2 ASC_Roommate_Device
       Rol.OG.wz.3 ASC_Roommate_Device
Attributes:
   ASC_autoAstroModeEvening NAUTIC
   ASC_autoAstroModeMorning NAUTIC
   ASC_autoShuttersControlComfort on
   ASC_autoShuttersControlEvening off
   ASC_autoShuttersControlMorning off
   ASC_brightnessDriveUpDown 150:200
   ASC_expert 1
   ASC_residentsDev rgr_HomeSweetHome:state
   ASC_shuttersDriveOffset 0
   ASC_tempSensor AG.balkon.THSensor:temperature
   ASC_twilightDevice Twilight
   devStateIcon selfeDefense.terrace:fts_door_tilt created.new.drive.timer:clock .*asleep:scene_sleeping roommate.(awoken|home):user_available residents.(home|awoken):status_available manual:fts_shutter_manual selfeDefense.active:status_locked selfeDefense.inactive:status_open day.open:scene_day night.close:scene_night shading.in:weather_sun shading.out:weather_cloudy
   icon       fts_shutter_automatic
   room       Rollladen
   verbose    2


List von einem Rolladen
CUL_0_MSGCNT 23
   CUL_0_RAWMSG A0DC8A4103360FCF110340601C800::-58:CUL_0
   CUL_0_RSSI -58
   CUL_0_TIME 2019-06-05 06:29:49
   DEF        3360FC
   FUUID      5c4f4fb7-f33f-6642-0340-c3e35cec8ebef407
   IODev      CUL_0
   KG.HmUARTLGW_MSGCNT 20
   KG.HmUARTLGW_RAWMSG 05000057C8A4103360FCF110340601C800
   KG.HmUARTLGW_RSSI -87
   KG.HmUARTLGW_TIME 2019-06-05 06:29:50
   LASTInputDev KG.HmUARTLGW
   MSGCNT     43
   NAME       Rol.OG.wz.2
   NOTIFYDEV  global
   NR         309
   NTFY_ORDER 50-Rol.OG.wz.2
   STATE      hoch
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:C8 - t:10 s:3360FC d:F11034 0601C800
   protLastRcv 2019-06-05 06:29:49
   protRcv    23 last_at:2019-06-05 06:29:49
   protResnd  2 last_at:2019-06-03 22:24:47
   protSnd    23 last_at:2019-06-05 06:29:49
   protState  CMDs_done
   rssi_CUL_0 cnt:11 min:-61 max:-57 avg:-58.81 lst:-60
   rssi_at_CUL_0 cnt:23 min:-62.5 max:-54 avg:-57.28 lst:-58
   rssi_at_KG.HmUARTLGW cnt:20 min:-97 max:-83 avg:-87.5 lst:-87
   READINGS:
     2019-05-22 06:48:40   ASC_Enable      on
     2019-06-05 06:29:50   ASC_ShuttersLastDrive manual
     2019-06-02 15:28:12   ASC_Time_DriveDown AutoShuttersControl off
     2019-06-02 15:28:12   ASC_Time_DriveUp AutoShuttersControl off
     2019-06-05 06:29:13   CommandAccepted yes
     2018-04-22 21:02:11   D-firmware      2.3
     2018-04-22 21:02:11   D-serialNr      LEQ1434879
     2018-03-15 19:55:47   PairedTo        0xF11034
     2018-03-15 19:55:48   R-driveDown     25 s
     2018-03-12 16:31:35   R-driveTurn     0.5 s
     2018-03-15 19:55:48   R-driveUp       28 s
     2018-04-22 21:02:11   R-pairCentral   set_0xF11034
     2018-03-12 16:31:35   R-sign          off
     2018-03-15 19:55:48   RegL_01.        08:00 09:00 0A:00 0B:00 0C:FA 0D:01 0E:18 0F:05 10:00  30:06 57:24 00:00
     2019-06-02 15:28:09   associatedWith  AutoShuttersControl
     2019-06-05 06:29:49   deviceMsg       on (to VCCU)
     2019-06-05 06:29:49   level           100
     2019-06-05 06:29:49   motor           stop:on
     2019-06-05 06:29:49   pct             100
     2019-05-29 15:06:20   powerOn         2019-05-29 15:06:20
     2019-06-05 06:29:49   recentStateType info
     2019-06-05 06:29:49   state           on
     2019-06-05 06:29:49   timedOn         off
   helper:
     HM_CMDNR   200
     cSnd       11F110343360FC0201000000,11F110343360FC0201C80000
     dlvlCmd    ++A011F110343360FC0201C80000
     mId        0005
     peerFriend peerSens,peerVirt
     peerOpt    3:blindActuator
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
       rct        up
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +3360FC,00,01,00
       nextSend   1559708990.37211
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         3360FC
         00
         01
         00
     mRssi:
       mNo        C8
       io:
         CUL_0:
           -52
           -52
         KG.HmUARTLGW:
           -87
           -87
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         CUL_0
       flg        A
       ts         1559708989.84143
       ack:
         HASH(0x3f54cf8)
         C88002F110343360FC00
     rssi:
       CUL_0:
         avg        -58.8181818181818
         cnt        11
         lst        -60
         max        -57
         min        -61
       at_CUL_0:
         avg        -57.2826086956522
         cnt        23
         lst        -58
         max        -54
         min        -62.5
       at_KG.HmUARTLGW:
         avg        -87.5
         cnt        20
         lst        -87
         max        -83
         min        -97
Attributes:
   ASC        2
   ASC_Antifreeze off
   ASC_AutoAstroModeEvening none
   ASC_AutoAstroModeEveningHorizon none
   ASC_AutoAstroModeMorning none
   ASC_AutoAstroModeMorningHorizon none
   ASC_BlockingTime_afterManual 0
   ASC_BlockingTime_beforDayOpen 0
   ASC_BlockingTime_beforNightClose 0
   ASC_BrightnessSensor AG.balkon.BM:brightness
   ASC_Closed_Pos 0
   ASC_ComfortOpen_Pos 80
   ASC_Down   astro
   ASC_Drive_Offset 0
   ASC_Drive_OffsetStart -1
   ASC_GuestRoom none
   ASC_LockOut soft
   ASC_LockOut_Cmd none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Open_Pos 100
   ASC_Partymode off
   ASC_Pos_Reading pct
   ASC_Roommate_Device rgr_HomeSweetHome
   ASC_Roommate_Reading state
   ASC_Self_Defense_Exclude off
   ASC_Shading_Angle_Left 75
   ASC_Shading_Angle_Right 85
   ASC_Shading_Direction 238
   ASC_Shading_Min_Elevation 25
   ASC_Shading_Min_OutsideTemperature 21
   ASC_Shading_Mode always
   ASC_Shading_Pos 20
   ASC_Shading_StateChange_Cloudy 150
   ASC_Shading_StateChange_Sunny 200
   ASC_Shading_WaitingPeriod 1200
   ASC_ShuttersPlace window
   ASC_Time_Down_Early 15:30
   ASC_Time_Down_Late 21:45
   ASC_Time_Up_Early 07:00
   ASC_Time_Up_Late 09:00
   ASC_Time_Up_WE_Holiday 10:00
   ASC_Up     astro
   ASC_Ventilate_Pos 30
   ASC_Ventilate_Window_Open on
   ASC_WiggleValue 5
   IODev      CUL_0
   IOgrp      VCCU
   alarmDevice Actor
   alarmSettings alarm7,|set Rol.OG.wz.2 pct 100||0:00
   alexaName  Rollo Wohnzimmer 2
   alias      Rollo Wohnzimmer 2
   autoReadReg 4_reqStatus
   devStateIcon hoch:fts_shutter_10 runter:fts_shutter_100 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100
   event-on-change-reading .*
   eventMap   on:hoch off:runter
   expert     2_raw
   firmware   2.3
   genericDeviceType blind
   model      HM-LC-BL1PBU-FM
   peerIDs    00000000,
   room       Obergeschoss->Wohnzimmer,Rollladen
   serialNr   LEQ1434879
   subType    blindActuator
   userattr   ASC_Antifreeze:off,soft,hard,am,pm ASC_Antifreeze_Pos:5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BlockingTime_afterManual ASC_BlockingTime_beforDayOpen ASC_BlockingTime_beforNightClose ASC_BrightnessSensor ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_ComfortOpen_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Down:time,astro,brightness ASC_DriveUpMaxDuration ASC_Drive_Offset ASC_Drive_OffsetStart ASC_GuestRoom:on,off ASC_LockOut:soft,hard,off ASC_LockOut_Cmd:inhibit,blocked,protection ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Reading ASC_PrivacyDownTime_beforNightClose ASC_PrivacyDown_Pos ASC_RainProtection:on,off ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_Exclude:on,off ASC_Shading_Angle_Left ASC_Shading_Angle_Right ASC_Shading_Direction ASC_Shading_Min_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Mode:absent,always,off,home ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_ShuttersPlace:window,terrace ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WiggleValue ASC_WindParameters ASC_WindProtection:on,off ASC_WindowRec ASC_WindowRec_subType:twostate,threestate room_map structexclude
   webCmd     statusRequest:pct


Alle Rolladen die in die Beschattungsposition fahren sollen haben die gleichen Einstellungen.

Kann mir jemand auf die Sprünge helfen warum die Rollos nicht mehr wie vorher die Beschattungsposition bei erreichen der Parameter anfahren ?

CoolTux

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

JHo

Hallo Marko,

ich möchte nochmal wegen der Manuell-Erkennung nerven. Habe das ASC-Device wie vorgeschlagen nochmal entfernt und dann nach FHEM-restart unter neuen Namen neu aufgebaut. Das Ergebnis ist leider immer noch das gleiche: manuelle Fahrten werden ums Verrecken nicht erkannt. Und wenn dann doch mal, dann scheinbar nur ausnahmsweise, nicht reproduzierbar. Aber: wenn, dann nur bei meinen beiden ROLLO-Devices, nicht bei den ZWave-Aktoren.
Irgendwo scheint also (bei mir, weil ROLLO ja anderswo offenbar funktioniert) noch der Wurm drin zu sein. Um den zu finden, bitte ich dich nochmal um Hilfe:

1. Im fhem.log kommen Fahrbefehle für die ZWave-Aktoren an. Das ASC_Pos_Reading-Reading zeigt die angefahrene Position an. ZWave aktualisiert / bestätigt die Position aber nicht nochmal bei Fahrtende. Müsste es das? Macht Homematic das? Wie sieht diese Bestätigung aus?
Mehr als ein
ZWave set wohnzimmer.tuer.rolladen dim 2
kommt im fhem-log nicht an. Allerdings im Device-log:
2019-06-05_14:17:03 wohnzimmer.tuer.rolladen dim 2
2019-06-05_14:17:06 wohnzimmer.tuer.rolladen dim 2
2019-06-05_14:17:06 wohnzimmer.tuer.rolladen reportedState: dim 2
2019-06-05_14:17:07 wohnzimmer.tuer.rolladen power:  0 W

Die aktuelle, richtige Position wird im showShuttersInformation angezeigt, also bekommt ASC das ja mit... das Modul weiß doch die von sich selbst "gewünschte" Position - warum erkennt es denn trotzdem nicht, dass da ein Unterschied ist?


2. Bei meinen per ROLLO-Modul gesteuerten Uniroll-Gurtwicklern ist es ein wenig anders. Im fhem.log kommen nur die Fahrbefehle fürs Uniroll-Device an:
UNIRoll set rolladen.dg.rechts down gibt es da nicht. Auch hier wieder im Devicelog alles ausführlich:
2019-06-05_14:17:54 rollo.dg.rechts command: pct-80
2019-06-05_14:17:54 rollo.dg.rechts desired_pct: 80
2019-06-05_14:17:54 rollo.dg.rechts last_drive: drive-down
2019-06-05_14:17:54 rollo.dg.rechts drive-down
2019-06-05_14:17:54 rollo.dg.rechts drive-type: modul
2019-06-05_14:17:55 rolladen.dg.rechts stop
2019-06-05_14:17:55 rolladen.dg.rechts dim 99 21
2019-06-05_14:17:55 rolladen.dg.rechts oldPos: 2
2019-06-05_14:17:55 rolladen.dg.rechts oldstate: dim 99 21
2019-06-05_14:17:59 rollo.dg.rechts pct: 80
2019-06-05_14:17:59 rolladen.dg.rechts dim 99
2019-06-05_14:17:59 rolladen.dg.rechts stop 0
2019-06-05_14:17:59 rolladen.dg.rechts oldPos: 6
2019-06-05_14:17:59 rolladen.dg.rechts oldstate: stop 0
2019-06-05_14:17:59 rollo.dg.rechts pct-80

Die Position in showShuttersInformations stimmt mit der manuell angefahrenen überein, aber der Fahrgrund ist noch der letzte Automatische; die manuell angefahrene Position wird nie in "LastPosition" übernommen, wenn nochmal (manuell oder vom ASC) gefahren wird.


3. Selbst, wenn ich per setreading das Reading für die Position manuell setze, wird das nicht durch ASC erkannt. Egal ob ein ZWave oder ROLLO-Device. Müsste es dann nicht?


4. Und nochmal zum Verständnis: wie genau funktioniert denn die manuelle Fahrterkennung - wofür braucht es denn die DriveUpMaxDuration überhaupt? Die macht doch nur Sinn, wenn es - wie in Punkt 1 - eine Bestätigung der Position nach Ende der Fahrt gibt, die abgewartet werden soll.


Ich hoffe, ich nerve nicht allzu sehr...
Gute Besserung!
Jan
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120

CoolTux

Hallo Jan,

Zitat von: JHo am 05 Juni 2019, 21:18:26
Hallo Marko,

ich möchte nochmal wegen der Manuell-Erkennung nerven. Habe das ASC-Device wie vorgeschlagen nochmal entfernt und dann nach FHEM-restart unter neuen Namen neu aufgebaut. Das Ergebnis ist leider immer noch das gleiche: manuelle Fahrten werden ums Verrecken nicht erkannt. Und wenn dann doch mal, dann scheinbar nur ausnahmsweise, nicht reproduzierbar. Aber: wenn, dann nur bei meinen beiden ROLLO-Devices, nicht bei den ZWave-Aktoren.
Irgendwo scheint also (bei mir, weil ROLLO ja anderswo offenbar funktioniert) noch der Wurm drin zu sein. Um den zu finden, bitte ich dich nochmal um Hilfe:

1. Im fhem.log kommen Fahrbefehle für die ZWave-Aktoren an. Das ASC_Pos_Reading-Reading zeigt die angefahrene Position an. ZWave aktualisiert / bestätigt die Position aber nicht nochmal bei Fahrtende. Müsste es das? Macht Homematic das? Wie sieht diese Bestätigung aus?
Mehr als ein
ZWave set wohnzimmer.tuer.rolladen dim 2
kommt im fhem-log nicht an. Allerdings im Device-log:
2019-06-05_14:17:03 wohnzimmer.tuer.rolladen dim 2
2019-06-05_14:17:06 wohnzimmer.tuer.rolladen dim 2
2019-06-05_14:17:06 wohnzimmer.tuer.rolladen reportedState: dim 2
2019-06-05_14:17:07 wohnzimmer.tuer.rolladen power:  0 W

Die aktuelle, richtige Position wird im showShuttersInformation angezeigt, also bekommt ASC das ja mit... das Modul weiß doch die von sich selbst "gewünschte" Position - warum erkennt es denn trotzdem nicht, dass da ein Unterschied ist?

Was genau ist das "ASC_Pos_Reading-Reading"?

2019-06-05_14:17:03 wohnzimmer.tuer.rolladen dim 2
Dieses Event ist ein Event aus einem set Befehl, also nicht das was wir brauchen.
2019-06-05_14:17:06 wohnzimmer.tuer.rolladen reportedState: dim 2
Dieses Event ist in der Tat ein korrektes Event welches unter anderem kommt wenn man ein Reading setzt, oder besser ein Reading gesetzt wird.

DEVICE READINGNAME: WERT

Und genau so muss ein Event aussehen den wir für die Erkennung der manuellen Fahrt benötigen.
Wenn also im Attribut ASC_Pos_Reading zum Beispiel dim drin steht. Dann muss:
  Der verwendete Aktor entweder bekannt sein als von Haus aus unterstütztes Device oder dim sowohl als Reading als auch als set Befehl funktionieren.
In Deinem Fall wird der Aktor unterstützt mit
ZWave      => 'dim',
Bedeutet also das sofern Dein Aktor vom TYPE ZWave ist das der Fahrbefehl dim ist.
Nun kannst Du zum erkennen einer Fahrt und ablesen der Position das Attribut ASC_Pos_Reading setzen wie Du willst. Das Reading mit dem Namen den Du da setzt muss aber einen nummerischen Wert haben der die aktuelle Position wieder gibt.

Nur weil ASC die aktuelle Position in showShuttersInformation an zeigt heist das nicht das ASC die Fahrt mit bekommt. Es wird lediglich zum Zeitpunkt des get Aufrufes die Position abgefragt in dem das Zuständige Reading ausgelesen wird.

Zitat von: JHo am 05 Juni 2019, 21:18:26
2. Bei meinen per ROLLO-Modul gesteuerten Uniroll-Gurtwicklern ist es ein wenig anders. Im fhem.log kommen nur die Fahrbefehle fürs Uniroll-Device an:
UNIRoll set rolladen.dg.rechts down gibt es da nicht. Auch hier wieder im Devicelog alles ausführlich:
2019-06-05_14:17:54 rollo.dg.rechts command: pct-80
2019-06-05_14:17:54 rollo.dg.rechts desired_pct: 80
2019-06-05_14:17:54 rollo.dg.rechts last_drive: drive-down
2019-06-05_14:17:54 rollo.dg.rechts drive-down
2019-06-05_14:17:54 rollo.dg.rechts drive-type: modul
2019-06-05_14:17:55 rolladen.dg.rechts stop
2019-06-05_14:17:55 rolladen.dg.rechts dim 99 21
2019-06-05_14:17:55 rolladen.dg.rechts oldPos: 2
2019-06-05_14:17:55 rolladen.dg.rechts oldstate: dim 99 21
2019-06-05_14:17:59 rollo.dg.rechts pct: 80
2019-06-05_14:17:59 rolladen.dg.rechts dim 99
2019-06-05_14:17:59 rolladen.dg.rechts stop 0
2019-06-05_14:17:59 rolladen.dg.rechts oldPos: 6
2019-06-05_14:17:59 rolladen.dg.rechts oldstate: stop 0
2019-06-05_14:17:59 rollo.dg.rechts pct-80

Die Position in showShuttersInformations stimmt mit der manuell angefahrenen überein, aber der Fahrgrund ist noch der letzte Automatische; die manuell angefahrene Position wird nie in "LastPosition" übernommen, wenn nochmal (manuell oder vom ASC) gefahren wird.

2019-06-05_14:17:59 rollo.dg.rechts pct: 80
Das hier ist ein auswertbarer Event zum feststellen einer manuellen Fahrt.
Wenn Du das Attribut ASC_Pos_Reading auf pct stellst sollte es auch erkannt werden


Ganz wichtig ist aber immer. Es muss ein Event überhaupt kommen, ist bei der ja anscheinend der Fall. Wollte es nur noch einmal erwähnen. Also ruhig noch mal event-on- Attribute prüfen.

Zitat von: JHo am 05 Juni 2019, 21:18:26
3. Selbst, wenn ich per setreading das Reading für die Position manuell setze, wird das nicht durch ASC erkannt. Egal ob ein ZWave oder ROLLO-Device. Müsste es dann nicht?

Ja und Nein. Kommt immer drauf an wie alt die letzte Fahrt ist.

Zitat von: JHo am 05 Juni 2019, 21:18:26
4. Und nochmal zum Verständnis: wie genau funktioniert denn die manuelle Fahrterkennung - wofür braucht es denn die DriveUpMaxDuration überhaupt? Die macht doch nur Sinn, wenn es - wie in Punkt 1 - eine Bestätigung der Position nach Ende der Fahrt gibt, die abgewartet werden soll.
Es geht ja darum zu erkennen ob eine Fahrt manuell oder über ASC ausgelöst wurde. Der Event ist ja nunmal der selbe. Daher schaue ich nach erhalt des Events nach einem Timestamp, ist dieser alter wie die maximale Fahrdauer nach oben muss es ein manueller Fahrbefehl gewesen sein. Drüher bin ich pauschal von 60s von der maximalen Fahrzeit ausgegangen. Doch einige Markisen brauchen wohl länger, daher habe ich das anpassbar gemacht.




Poste bitte noch einmal ein list vom ASC Device
ein list vom Rollo mit ZWave Aktor
ein list von Rollo vom TYPE Rollo (Rollomodul)
und einen Ausschnitt vom Eventmonitor wie Du eine manuelle Fahrt machst.
Und stelle bitte im ASC Device debug auf 1 (mehr nicht)


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

coolice