FGRM222: Position-Reading wird sporadisch nicht aktualisiert

[FunkOdyssey]

Hallo, ich habe mal wieder ein Problem mit den FGRM222 Roller Shutter von Fibaro.

Ich habe die Aktoren wie folgt konfiguriert:

Code Auswählen Erweitern

configReportsType: BlindPositionReportsSentToThe1
configRollerShutterOperatingModes: 1RollerBlindModeWithPositioning

Mit BlindPositionReportsSentToThe1 wird ein Reading "position" angelegt und als Fibaro CC-Kommando (was immer das auch ist) aktualisiert. Am Rande: Ändere ich dies auf BlindPositionReportsSentToThe0 ab, so wird nicht das Reading aktualisiert, sondern reportedState.

Insgesamt habe ich fünf dieser Aktoren im Einsatz. Und ich habe das immer wieder, dass das Reading nicht aktualisiert wird. Rekonstruieren kann ich das, wenn ich alle Shutter-Module gleichzeit fahre. Dann ist scheinbar eine Funklast vorhanden, die das position-Reading nicht durchlassen.

Da ich hier im Forum diverse Tipps gefunden habe, habe ich auch die Assoziationsgruppen testweise vollständig runtergefahren. Also nur das Notwendigste mit dem Z-Wave-Dongle verbunden. Leider ohne Erfolg.

Ist das normal, dass man keine fünf Z-Wave-Geräte gleichzeitig ansteuern kann? Ist das wirklich schon die Grenze, so dass man mit Problemen bei den Rückantworten rechnen muss?

Oder woran könnte das sonst noch liegen? Wie kann ich dem Problem auf die Spur kommen? Kann mir jemand helfen?

So etwas wie "timeToAck" sieht doch eigentlich ganz gut aus, oder?

Vielen Dank.

List:

Code Auswählen Erweitern

Internals:
   DEF        efbdf21a 7
   IODev      ZWDongle
   LASTInputDev ZWDongle
   MSGCNT     332
   NAME       zw_jal_wc
   NR         138
   STATE      0
   TYPE       ZWave
   ZWDongle_MSGCNT 332
   ZWDongle_RAWMSG 0004000703250300aa00
   ZWDongle_TIME 2019-01-06 17:15:12
   ZWaveSubDevice no
   cmdsPending 0
   homeId     efbdf21a
   isWakeUp   
   lastMsgSent 1546791312.50174
   nodeIdHex  07
   READINGS:
     2019-01-06 16:45:34   ASC_ShuttersLastDrive night close
     2019-01-06 16:45:02   ASC_Time_DriveDown  7.01.2019 - 16:45
     2019-01-06 16:45:02   ASC_Time_DriveUp  7.01.2019 - 08:46
     2018-11-16 17:50:39   assocGroup_1    Max 16 Nodes ZWDongle
     2018-11-16 17:50:39   assocGroup_2    Max 16 Nodes
     2018-11-16 17:50:39   assocGroup_3    Max 1 Nodes ZWDongle
     2018-11-16 17:50:39   assocGroups     3
     2018-10-12 21:34:15   configEnergyReports 10
     2018-10-12 21:34:16   configInRollerBlindModeOrVenetianBlind17 10
     2018-10-12 21:34:16   configInVenetianBlindModeTheParameter12 150
     2018-10-12 21:34:21   configManagingLamellasInResponseTo35 SetLamellasToTheirExtreme1
     2018-10-12 21:34:21   configMotorOperationDetection 10
     2018-10-12 21:34:21   configMotorOperationTime 240
     2018-10-12 21:34:21   configPeriodicPowerOrEnergyReports 3600
     2018-10-12 21:34:22   configPowerReports 10
     2018-11-15 16:56:45   configReportsType BlindPositionReportsSentToThe1
     2018-10-12 21:34:27   configResponseToFloodingAlarm NoReaction
     2018-10-12 21:34:27   configResponseToGeneralAlarm CloseBlind
     2018-10-12 21:34:27   configResponseToSmokeCOOrCO2Alarm OpenBlind
     2018-10-12 21:34:28   configResponseToTemperatureAlarm OpenBlind
     2018-10-12 21:34:28   configRollerShutterOperatingModes 1RollerBlindModeWithPositioning
     2018-10-12 21:34:28   configScenesAssociationsActivation AssociationsActivation
     2018-10-12 21:34:28   configSelfMeasurement SelfMeasurementInactive
     2018-10-12 21:34:28   configSetLamellasBackToPrevious13 1LamellasReturnToPreviouslySet1
     2018-10-12 21:34:29   configSwitchType MomentarySwitches
     2019-01-06 16:46:09   energy           0.14 kWh
     2018-10-12 21:34:29   mcaGroups       2
     2018-10-12 21:34:30   mca_1           Max 7 Nodes ZWDongle
     2018-10-12 21:34:30   mca_2           Max 7
     2018-10-12 18:46:32   model           FIBARO System FGRM222 Roller Shutter Controller 2
     2018-10-12 18:46:32   modelConfig     fibaro/fgrm222.xml
     2018-10-12 18:46:32   modelId         010f-0302-1000
     2018-11-16 17:49:01   neighborList    zw_heizstab zw_jal_hwr zw_dim_wegbeleuchtung zw_jal_diele zw_jal_kueche_gross zw_jal_kueche_klein
     2018-10-12 21:33:46   neighborUpdate  done
     2019-01-06 16:45:56   position        0
     2019-01-06 17:15:12   positionCalculated 0
     2019-01-06 16:45:56   power           0.0 W
     2019-01-06 17:15:12   reportedState   off
     2019-01-06 17:15:12   state           off
     2019-01-06 17:15:12   timeToAck       0.030
     2019-01-06 17:15:12   transmit        OK
Attributes:
   ASC        2
   ASC_Antifreeze off
   ASC_Antifreeze_Pos 15
   ASC_AutoAstroModeEvening none
   ASC_AutoAstroModeEveningHorizon none
   ASC_AutoAstroModeMorning none
   ASC_AutoAstroModeMorningHorizon none
   ASC_BlockingTime_afterManual 1200
   ASC_BlockingTime_beforDayOpen 3600
   ASC_BlockingTime_beforNightClose 3600
   ASC_BrightnessMaxVal -1
   ASC_BrightnessMinVal -1
   ASC_Brightness_Reading brightness
   ASC_Brightness_Sensor none
   ASC_Closed_Pos 0
   ASC_ComfortOpen_Pos 80
   ASC_Down   astro
   ASC_Drive_Offset 90
   ASC_GuestRoom none
   ASC_LockOut off
   ASC_LockOut_Cmd none
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Open_Pos 99
   ASC_Partymode off
   ASC_Pos_Reading position
   ASC_Roommate_Device none
   ASC_Roommate_Reading state
   ASC_Self_Defense_Exclude off
   ASC_Shading_Angle_Left 75
   ASC_Shading_Angle_Right 75
   ASC_Shading_Direction 180
   ASC_Shading_Min_Elevation 25
   ASC_Shading_Min_OutsideTemperature 18
   ASC_Shading_Mode off
   ASC_Shading_Pos 20
   ASC_Shading_StateChange_Cloudy 20000
   ASC_Shading_StateChange_Sunny 35000
   ASC_Shading_WaitingPeriod 1200
   ASC_ShuttersPlace window
   ASC_Time_Down_Early 16:45
   ASC_Time_Down_Late 21:00
   ASC_Time_Up_Early 08:30
   ASC_Time_Up_Late 09:15
   ASC_Time_Up_WE_Holiday 09:00
   ASC_Up     astro
   ASC_Ventilate_Pos 30
   ASC_Ventilate_Window_Open on
   ASC_WiggleValue 5
   ASC_WindowRec none
   ASC_WindowRec_subType twostate
   IODev      ZWDongle
   alias      WC Jalousie
   classes    MULTI_CHANNEL_ASSOCIATION MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION POWERLEVEL METER SWITCH_MULTILEVEL SENSOR_MULTILEVEL SWITCH_BINARY MANUFACTURER_PROPRIETARY PROTECTION MARK METER SENSOR_MULTILEVEL MANUFACTURER_PROPRIETARY SCENE_ACTIVATION SWITCH_MULTILEVEL SWITCH_BINARY
   comment    pct:position.* {ReadingsVal("$name","position",0)},
dim:position.* {ReadingsVal("$name","position",0)},
   devStateIcon 99:fts_window_2w 100:fts_window_2w 0:fts_shutter_100 1\d.*:fts_shutter_90 2\d.*:fts_shutter_80 3\d.*:fts_shutter_70 4\d.*:fts_shutter_60 5\d.*:fts_shutter_50 6\d.*:fts_shutter_40 7\d.*:fts_shutter_30 8\d.*:fts_shutter_20 9\d.*:fts_shutter_10 \d.*:fts_shutter_90
   event-on-change-reading .*
   genericDeviceType blind
   group      Erdgeschoss
   homebridgeMapping clear CurrentPosition=position,minValue=0,maxValue=99 TargetPosition=dim::position,minValue=0,maxValue=99,minStep=1
   neighborListPos 543.380002672574,16.272296769191087
   room       Homekit,Jalousien
   siriName   WC Jalousie
   stateFormat position
   userReadings positionCalculated
{
if (ReadingsVal($name,"state","") =~ "on") {"99"}
elsif (ReadingsVal($name,"state","") =~ "off") {"0"}
else {ReadingsNum("$name","state","")}
}

   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_BrightnessMaxVal ASC_BrightnessMinVal ASC_Brightness_Reading ASC_Brightness_Sensor 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_Drive_Offset 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_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_WindowRec ASC_WindowRec_subType:twostate,threestate
   vclasses   ASSOCIATION:2 CONFIGURATION:1 MANUFACTURER_PROPRIETARY:1 MANUFACTURER_SPECIFIC:1 METER:2 MULTI_CHANNEL_ASSOCIATION:2 POWERLEVEL:1 PROTECTION:2 SCENE_ACTIVATION:1 SENSOR_MULTILEVEL:2 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 VERSION:1
   webCmd     on:off:stop:dim

[rudolfkoenig]

Ist das normal, dass man keine fünf Z-Wave-Geräte gleichzeitig ansteuern kann?

Es gab frueher Probleme, wenn man fuer ein Geraet mehrere get Befehle abgesetzt hat (z.Bsp. mit getConfigAll), weil der Controller es nicht weiss, dass eine Antwort gesendet wird, und munter die naechste Frage aussendet, was u.U zu Kollision und Nachrichtenverlust fuehrt. Entweder haben die Protokolldesigner das nicht beruecksichtigt, oder die Aufgabe auf dem HA-Software geschoben. Das Problem haben wir in ZWave.pm geloest, indem wir bei get auf die Antwort warten befor das naechste Befehl losgeschickt wird. Allerdings gilt das nur fuer ein einzelnes Geraet, das zusammenfuehren der Warteschlangen der unterschiedlichen ZWave-Geraete ist einer meiner TODOs, die inzwischen ganz unten im Stapel ist

Bei set weiss ich aber nicht, ob es ueberhaupt eine Antwort gibt (ausser dem ACK, auf dem wird immer gewartet), und wenn ja, wieviele Nachrichten kommen, will sagen, ich haette nicht mal einen Plan, wann man den naechsten Befehl losschicken kann.

Als Ausweg faellt mir nur ein structure mit asyncDelay ein.

[FunkOdyssey]

Wow, das erschreckt mich jetzt ein wenig. So etwas bin ich von anderen Protokollen gar nicht gewohnt. Homematic läuft in solchen Konstellationen absolut problemlos.
Schade, dass es (vermutlich) am Z-Wave-Protokoll liegt. Aufs falsche Pferd gesetzt.

Als Ausweg faellt mir nur ein structure mit asyncDelay ein.

So etwas ähnliches habe ich bereits gemacht. Die Jalousien werden hier über das AutoShuttersControl (ASC)-Modul gesteuert. Ich habe schon Verzögerungen eingebaut, aber dennoch habe ich sporadisch das Problem, dass die Antworten scheinbar nicht ankommen.

Das Problem ist, dass das ASC-Modul halt die Positionswerte benötigt, da ansonsten beim nächsten Zeitpunkt nicht gefahren wird (weil ist lt. falschem Reading ja schon unten)

Ich versuche es gerade mit nem eigenen userreading (siehe List oben), welches sich positionCalculated aus dem Set-Befehl bastelt. Ist natürlich auch nicht perfekt, aber vielleicht hilft es. Ich werde das mal beobachten.

Ich werde aber vermutlich eine AT/DOIF anlegen, welches sich zyklische die Positionswerte holt (get jal position). Vielleicht klappt es ja so.

[dennis_n]

Ich hatte diese Probleme auch mal.
Seit ich structure mit asyncDelay benutze, sind alle Probleme weg. Eine Sekunde Verzögerung genügt schon.

Gruss
Dennis

[FunkOdyssey]

Hmm, so langsam glaube ich, dass es vielleicht doch gar nicht am Traffic liegt.

Am 27. Dezember wurden die Jalousien in folgender Reihenfolge runtergefahren:

Code Auswählen Erweitern

2018.12.27 16:45:02.109 3: ZWave set zw_jal_kueche_gross dim 0
2018.12.27 16:45:02.120 3: ZWave set zw_jal_kueche_klein dim 0
2018.12.27 16:45:57.172 3: ZWave set zw_jal_hwr dim 0
2018.12.27 16:45:59.132 3: ZWave set zw_jal_wc dim 0
2018.12.27 16:46:08.148 3: ZWave set zw_jal_diele dim 0

Nur bei zw_jal_wc und zw_jal_kueche_klein fehlt mir hier einmalig die Aktualisierung des Readings position.
Das kann man bei zw_jal_kueche_klein vielleicht noch mit Traffic argumentieren. Aber bei zw_jal_wc nicht, da hier sekundenlang keine andere Funklast vorhanden war.