Reportedstate und state untgerschiedlich

[Fixel2012]

Hi,

ich nutze das Reading reportedstate um im TabletUI den Rolladen status abzubilden.

Leider musste ich feststellen das bei zwei Rollläden das Reading reportedstate nicht mit dem Reading state nicht über ein stimmt.

Somit stimmt die aktuelle Position mit dem Reading reportedstate nicht über ein.

Meine Vermutung ist einfach, dass der Aktor(rollershutter 2) den Controller nicht erreichen kann. Da dies aber anders rum funktioniert, bin ich ein wenig verwundert. Die Route des Aktors habe ich schon gecheckt, dass sollte ok sein.

Werde morgen nochmal testen, ob es geht, wenn nicht alle Rollläden gleichzeitig hoch gehen. Vielleicht liegt es an den vielen gleichzeitig ankommenden Statusmeldungen der Aktoren.

Werde nochmal Berichten.

Wenn sonst wer Ideen hat, sind diese gerne Willkommen.

Schonmal Danke und Gruß,

Fixel

[rudolfkoenig]

Kannst du bitte sagen, jeweils was in den Readings steht? Eigentlich wird reportedstate automatisch auf state gesetzt.

[Fixel2012]

reportedState dim 35 2017-07-22 21:43:56

state on 2017-07-23 10:30:00

Hier die beiden Readings.

Das reportedstate Reading wurde das letze mal gestern Abend aktualisiert, obwohl der Rollladen um 10:30 hochgefahren wurde. für 10:30 müsste doch eigentlich auch ein Reportedatate Reading vorliegen.

[Fixel2012]

Hier nochmal ein List, das Phänomen tritt nur auf, wenn mehrere Rollläden gleichzeitig gesteuert werden. Wahrscheinlich kommt der Aktor nicht zur Zentrale durch (zu viel Funkverkehr?).

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        c72e3103 17
   IODev      ZWDongle_Fibaro
   LASTInputDev ZWDongle_Fibaro
   MSGCNT     743
   NAME       1OG.Bad
   NR         133
   STATE      up
   TYPE       ZWave
   ZWDongle_Fibaro_MSGCNT 743
   ZWDongle_Fibaro_RAWMSG 000400110a320221440000002e0000
   ZWDongle_Fibaro_TIME 2017-07-24 08:03:22
   ZWaveSubDevice no
   homeId     c72e3103
   isWakeUp
   lastMsgSent 1500874200.2512
   nodeIdHex  11
   READINGS:
     2017-02-11 16:35:10   CMD             ZW_APPLICATION_UPDATE
     2017-06-16 10:30:05   UNPARSED        SENSOR_BINARY 06300504220660
     2017-05-25 19:36:23   assocGroup_1    Max 16 Nodes ZWDongle_Fibaro
     2017-05-25 19:36:23   assocGroup_2    Max 16 Nodes
     2017-05-25 19:36:24   assocGroup_3    Max 1 Nodes ZWDongle_Fibaro
     2017-05-25 19:36:23   assocGroups     3
     2017-07-24 08:03:22   energy           0.46 kWh
     2017-02-11 16:35:25   model           FIBARO System FGR222 Roller Shutter Controller 2
     2017-02-11 16:35:25   modelConfig     fibaro/fgr222.xml
     2017-02-11 16:35:25   modelId         010f-0302-1000
     2017-06-05 15:18:38   neighborUpdate  done
     2017-05-29 21:45:41   position        35
     2017-07-24 07:30:15   power           0.0 W
     2017-06-05 02:07:35   protection      Local: unprotected RF: unprotected
     2017-07-23 21:42:29   reportedState   dim 35
     2017-07-24 07:30:00   state           on
     2017-07-24 07:30:01   timeToAck       1.409
     2017-07-24 07:30:01   transmit        OK

[krikan]

Tippe auf zu viel Funkverkehr und damit einhergehende Telegrammverluste, Wiederholungen. Sieht man normalerweise im verbose 5 Log von ZWDongle (zumindest die Indizien). timeToAck deutet auch darauf hin.

Reduziere zunächst Funknachrichten durch Löschen der vermutlich unnötigen Assoziation mit Assogroup 1. Damit hast Du schon einmal weniger Nachrichten.

Wenn es dann noch nicht funktioniert, zum gleichzeitigen Schalten structure mit erhöhtem async_delay nutzen.

Gruß, Christian

[Fixel2012]

Tippe auf zu viel Funkverkehr und damit einhergehende Telegrammverluste, Wiederholungen. Sieht man normalerweise im verbose 5 Log von ZWDongle (zumindest die Indizien). timeToAck deutet auch darauf hin.

Reduziere zunächst Funknachrichten durch Löschen der vermutlich unnötigen Assoziation mit Assogroup 1. Damit hast Du schon einmal weniger Nachrichten.

Gruß, Christian

Hi Christian,

die associationen mit Gruppe 1 sind tatsächlich nicht nötig. Mir war nicht bewusst in wie fern das den Funkverkehr belastet.

Mit associationdel

Code Auswählen Erweitern

<gruppe, in meinem Fall die 1> <NodeID des devices was bisher eingetragen ist>
kurz gesagt:

Code Auswählen Erweitern

set attr associationDel 1 15

sollte ich doch den Controller aus der Gruppe 1 entfernen können?



wenn ich anschließend mit get associationall abfrage, ist der controller allerdings immernoch in der Gruppe 1 zu sehen.
Mir ist nicht so ganz bewusst, ob ich nun die NodeID in Hex oder dezimal eingeben muss. Ich habe beides ohne Erfolg probiert.

Wenn es dann noch nicht funktioniert, zum gleichzeitigen Schalten structure mit erhöhtem async_delay nutzen.

Was genau kann man unter async_delay verstehen? Heißt das zumindest, dass das senden von Zwave befehlen zu mehreren Aktoren aus einem structure anders behandelt wird? Sprich weniger Funklast erzeugt?

Schon mal vielen Dank!

Gruß,
Fixel

[krikan]

die associationen mit Gruppe 1 sind tatsächlich nicht nötig. Mir war nicht bewusst in wie fern das den Funkverkehr belastet.

Dadurch verschickt der Aktor zusätzlich alle Nachrichten der Assogroup 1 an den Controller. Sollte unnötig sein, da diese Infos, wenn auch unter Umständen über andere Command Classes- bereits über Assogroup 3 kommen. Ob und wann jetzt tatsächlich beim FGRM Nachrichten über Assogroup 1 verschickt werden, habe ich nicht kontrolliert. Unnötige Assoziationen mit dem Controller mag ich einfach nicht, da die eine Problemursache sein können. 

Mit associationdel

Code Auswählen Erweitern

<gruppe, in meinem Fall die 1> <NodeID des devices was bisher eingetragen ist> sollte ich doch den Controller aus der Gruppe 1 entfernen können?

Code Auswählen Erweitern

set <device> associationDel 1 <ZWDongleDeviceDecimalId>
sollte funktionieren.

wenn ich anschließend mit get associationall abfrage, ist der controller allerdings immernoch in der Gruppe 1 zu sehen.

Dann hat etwas nicht funktioniert.

Mir ist nicht so ganz bewusst, ob ich nun die NodeID in Hex oder dezimal eingeben muss. Ich habe beides ohne Erfolg probiert.

Eigentlich sollte es überall Dezimal sein.

Was genau kann man unter async_delay verstehen? Heißt das zumindest, dass das senden von Zwave befehlen zu mehreren Aktoren aus einem structure anders behandelt wird? Sprich weniger Funklast erzeugt?

Baut eine zusätzliche Pause beim Versenden der Befehle an die einzelnen Aktoren ein. Kannst Du auch mit sleep-Kontrukten erreichen. structure ist aber mMn "schöner".

[Fixel2012]

Dann hat etwas nicht funktioniert.Eigentlich sollte es überall Dezimal sein.

Hier ein list, ich sehe nur die NodeID in Hex:

Code Auswählen Erweitern

Internals:
   CFGFN
   CallbackNr 0
   Clients    :ZWave:
   DEF        /dev/serial/by-id/usb-0658_0200-if00@115200
   DeviceName /dev/serial/by-id/usb-0658_0200-if00@115200
   FD         17
   MaxSendRetries 3
   NAME       ZWDongle_Fibaro
   NR         119
   PARTIAL
   RAWMSG     000400050a32022144000000400000
   ReadTime   1500887301.91916
   STATE      Initialized
   SendRetries 0
   SendTime   1500885672.88049
   TYPE       ZWDongle
   WaitForAck 0
   ZWDongle_Fibaro_MSGCNT 15270
   ZWDongle_Fibaro_TIME 2017-07-24 11:08:21
   homeId     c72e3103
   nodeIdHex  15
   nrNAck     0
   MatchList:
     1:ZWave    .*

[krikan]

Hier ein list, ich sehe nur die NodeID in Hex:

Ich meinte eigentlich die Nummern, die Du in den Befehlen angeben musst.

Das ZWDongle-Device enthält im Gegensatz zu den ZWave-Devices in den Internals nur den Hexwert, den Du umrechnen darfst.
Also 15hex=21dec.

[krikan]

Gerade getestet:
Die Aufnahme des Controllers in Assogroup 1 führt beim Schalten des FGRM über "set <device> dim %" nicht zu zusätzlichen Nachrichten. Also ist das hier nicht problemrelevant.
Wenn Du die Assoziation aber nicht brauchst, würde ich löschen. 

[Fixel2012]

Gerade getestet:
Die Aufnahme des Controllers in Assogroup 1 führt beim Schalten des FGRM über "set <device> dim %" nicht zusätzlichen Nachrichten. Also ist das hier nicht problemrelevant.
Wenn Du die Assoziation aber nicht brauchst, würde ich löschen. 

öhh, wollte gerade schreiben, dass ich alle gelöscht habe und nun mal schauen ob es besser läuft 

Dann muss ich wohl entweder ein structure einsetzen oder ein paar sleeps einbauen. Sleep würde ich vorziehen, ist einfach einfacher, auf die schnelle 

Wie viele und wie lange sollen die sleeps sein? reichen da 0,5 sek und das jeweils zwischen den set commands?

Nochmals danke auch für das testen meines Problems!

[krikan]

Dann muss ich wohl entweder ein structure einsetzen oder ein paar sleeps einbauen.

Ja, wenn die Annahme zutrifft, dass zu viel Funkverkehr mit Telegrammverlust das Problem ist und keine besseren Ideen kommen....

Sleep würde ich vorziehen, ist einfach einfacher, auf die schnelle  Wie viele und wie lange sollen die sleeps sein? reichen da 0,5 sek und das jeweils zwischen den set commands?

Kommt darauf an und kann ich nicht pauschal beantworten.  Tippe auf zu wenig
Mache doch einmal ein verbose 5 Log und schaue, ob es ein System bei eventuellen Retransmits und ähnlichem gibt. Dann würde ich mit verschiedenen Werten experimentieren. Vielleicht genügt es auch schon, die Aktoren in 2 Gruppen zu packen und nur dazwischen ein sleep einzubauen.
Am sichersten ist es bestimmt zwischen jeden Schaltbefehl für einen einzelnen Aktors eine längere Pause von x Sekunden per sleep/async_delay zu setzen, aber ob Du das willst!? So könntest Du es zumindest sicherer auf Kollisionen und Telegrammverluste zurückführen, wenn es dann problemlos funktioniert.

[rudolfkoenig]

reportedState dim 35 2017-07-22 21:43:56
state on 2017-07-23 10:30:00

Normaler Vorgang:
- in FHEM wird set ausgeloest, state wird gesetzt.
- Geraet meldet ACK, und den neuen Zustand. Fals dieser Zustand in FHEM als state-Event gemeldet wird, dann wird auch reportedState gesetzt.

In deinem Fall hat state einen neueren Zeitstempel als reportedState. Ich vermute, dass FHEM die Zustandsmeldung vom Geraet fuer den letzten "set" nicht empfangen hat.

[Fixel2012]

Normaler Vorgang:
- in FHEM wird set ausgeloest, state wird gesetzt.
- Geraet meldet ACK, und den neuen Zustand. Fals dieser Zustand in FHEM als state-Event gemeldet wird, dann wird auch reportedState gesetzt.

In deinem Fall hat state einen neueren Zeitstempel als reportedState. Ich vermute, dass FHEM die Zustandsmeldung vom Geraet fuer den letzten "set" nicht empfangen hat.

Das vermute ich auch weiterhin!

[Thomas_Homepilot]

Hallo,

habe ein ähnliches Problem mit zwei FGD211-Dimmern. Wenn ich ihn am schalter bediene wird reportedState korrekt gesetzt. Wenn ich ihn aus FHEM schalte, wird reportedState nicht verändert.
Habe die Assoziationen auch schon verändert - ohne Erfolg.
Hier das Listing:

Internals: DEF        db46f49f 14 IODev      ZWDongle_0 LASTInputDev ZWDongle_0 MSGCNT     101 NAME       Licht_SZO_Decke NR         403 STATE      dim 1 TYPE       ZWave ZWDongle_0_MSGCNT 101 ZWDongle_0_RAWMSG 0004000e06850303010001 ZWDongle_0_TIME 2017-08-15 10:19:30 ZWaveSubDevice no homeId     db46f49f isWakeUp lastMsgSent 1502785170.80055 nodeIdHex  0e .vclasses: ASSOCIATION 2 CONFIGURATION 1 FIRMWARE_UPDATE_MD 1 MANUFACTURER_SPECIFIC 1 MULTI_CHANNEL_ASSOCIATION 2 POWERLEVEL 1 SCENE_ACTIVATION 1 SWITCH_ALL 1 SWITCH_MULTILEVEL 1 VERSION    1 READINGS: 2017-06-16 20:22:23   CMD             ZW_APPLICATION_UPDATE 2017-07-12 22:44:10   UNPARSED        APPLICATION_STATUS 03220702 2017-08-15 10:19:30   assocGroup_1    Max 5 Nodes ZWDongle_0 2017-08-15 10:19:30   assocGroup_2    Max 5 Nodes 2017-08-15 10:19:30   assocGroup_3    Max 1 Nodes ZWDongle_0 2017-08-15 10:19:30   assocGroups     3 2017-08-15 10:19:09   config3WaySwitch Disable 2017-08-15 10:19:09   configADVANCEDImpulseLength 110 2017-08-15 10:19:09   configActiveFlashingAlarmTime 600 2017-08-15 10:19:09   configAlarm     ALARMFLASHINGDeviceWillTurnONAnd3 2017-08-15 10:19:09   configChangeOnOffBiStableKeys Disable 2017-08-15 10:19:10   configControlKey2Behaviour FrameGETIsSend1 2017-08-15 10:19:10   configDimmingStepAtAutomaticControl 1 2017-08-15 10:19:10   configDimmingStepAtManualControl 1 2017-08-15 10:19:10   configDoubleClickOption EnableDoubleClick 2017-08-15 10:19:10   configEnableDisableALLONOFF ALLONActiveALLOFFActive 2017-08-15 10:19:11   configInputsButtonSwitchConfiguration MonoStableInputButton 2017-08-15 10:19:12   configMaximumDimmerLevelControl 99 2017-08-15 10:19:13   configMinimumDimmerLevelControl 1 2017-01-17 20:42:08   configSavingStateBeforePowerFaillure StateSavedAtPowerFailureAll1 2017-08-15 10:19:14   configSavingStateBeforePowerFailure StateSavedAtPowerFailureAll1 2017-08-15 10:19:15   configSceneActivationFunctionality FunctionalityDeactivated 2017-08-15 10:19:16   configSeparationOfAssociationSending6 MapStatusToAllDevicesInGroup10 2017-08-15 10:19:18   configSynchronizingLightLevelFor18 Enable 2017-08-15 10:19:19   configTimeOfAUTOMATICMovingBetweenThe10 2 2017-08-15 10:19:20   configTimeOfMANUALLYMovingBetweenThe9 5 2017-08-15 10:19:21   configUpdatingTheDimmingLevelWithout40 1 2017-08-14 11:15:50   model           FIBARO System FGD211 Universal Dimmer 500W 2017-08-14 11:15:50   modelConfig     fibaro/fgd211.xml 2017-08-14 11:15:50   modelId         010f-0100-100a 2017-08-14 13:37:45   powerlvl        current 0 remain 0 2017-08-14 13:37:57   powerlvlTest    node 1 status 0 frameAck 0 2017-08-15 08:22:23   reportedState   off 2017-08-15 10:18:22   state           dim 1 2017-08-15 10:19:30   timeToAck       0.074 2017-08-15 10:19:30   transmit        OK Attributes: IODev      ZWDongle_0 alias      Schlafzimmer oben classes    MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION SWITCH_MULTILEVEL FIRMWARE_UPDATE_MD SWITCH_ALL POWERLEVEL MARK SWITCH_MULTILEVEL SCENE_ACTIVATION devStateIcon dim.0:light_light@green:on off:light_light@green:on dim..:light_light_dim_00@red dim.1.:light_light_dim_10@red dim.2.:light_light_dim_20@red dim.3.:light_light_dim_30@red dim.4.:light_light_dim_40@red dim.5.:light_light_dim_50@red dim.6.:light_light_dim_60@red dim.7.:light_light_dim_70@red dim.8.:light_light_dim_80@red dim.9.:light_light_dim_90@red dim.99:light_light_dim_100@red:off group      Beleuchtung room       Aktoren vclasses   ASSOCIATION:2 CONFIGURATION:1 FIRMWARE_UPDATE_MD:1 MANUFACTURER_SPECIFIC:1 MULTI_CHANNEL_ASSOCIATION:2 POWERLEVEL:1 SCENE_ACTIVATION:1 SWITCH_ALL:1 SWITCH_MULTILEVEL:1 VERSION:1 webCmd     dim 

Gruß
Thomas