Reportedstate und state untgerschiedlich

[throbin]

Hi,

ich habe seit einigen Tagen ebenfalls das Problem, dass reportedState nicht aktualisiert wird. Ich setze momentan UZB Stick mit der aktuellsten FW (Vers:5 Rev:22, Z-Wave 4.61 STATIC_CONTROLLER) ein. Als Rollo-Aktoren setze ich die "FIBARO System FGRM222 Roller Shutter Controller 2" in der Version "Lib 3 Prot 3.52 App 25.25" ein.
Ich nutze reportedState um daraus die aktuelle Position abzuleiten um damit bspw. zu prüfen, ob der Rollo unten oder oben ist. Dadurch muss ich die Befehle zum Öffnen/Schließen nur bei Bedarf absetzen.

Die Funktion "GetRolloPositionAsValue" dient zur Umrechnung der Position in einen dezimalen Wert (also ohne Prefix "dim" und gemappten State-Werten wie "zu/off"). Damit kann ich dann bspw. auch die Icons etc. umschalten und selbst-definiertes Reading "statePosition" für jeden Aktor zu setzen:

Code Auswählen Erweitern

userReadings statePosition { GetRolloPositionAsValue($name); }

Code Auswählen Erweitern



Die Funktion "WriteLogMessage" schreibt nur Texte ins Logfile.

sub GetRolloPositionAsValue($)
{
  my ($deviceName) = @_;
  my $t1 = ReadingsVal($deviceName,"reportedState","0");
 
  WriteLogMessage("GetRolloPositionAsValue for device $deviceName, reportedState returns: $t1");
 
  if(index($t1,"dim") >=0 )
  {
    my @valueTmp = split(" ", $t1);
    return $valueTmp[1];
  }
  else
  {
    return 0;
  }
}


Das ganze läuft timer-gesteuert, dabei werden einzelne Aktoren mit einem Delay von 2 Sekunden gesteuert umd evtl. Queue Probleme im Netz zu umgehen. Leider wird der reportedState nicht immer aktualisiert, STATE selbst dagegen schon (ist auch klar, weil man diesen durch das Absetzen des Commandos selbst setzt...). Im Log sieht man im Fehlerfall folgenden Traffic, wenn das Rollo hochgefahren wird (also open). Bei Herunterfahren prüfe ich dann auf den reportedState und da dieser "off" (also "0") ist, passiert nichts - Rollo bleibt über Nach geöffnet:

Code Auswählen Erweitern


2017.11.27 08:00:20.123 5: exec at command tmp_time10
2017.11.27 08:00:20.124 5: Cmd: >set zw_DG_Bad_Rollo dim 99<
2017.11.27 08:00:20.128 3: ZWave set zw_DG_Bad_Rollo dim 99
2017.11.27 08:00:20.129 5: ZWDongle_Write 001312032601632512 (dad62400)
2017.11.27 08:00:20.129 5: SW: 010a00131203260163251284
2017.11.27 08:00:20.133 1: GetRolloPositionAsValue for device zw_DG_Bad_Rollo, reportedState returns: off
2017.11.27 08:00:20.134 5: Starting notify loop for zw_DG_Bad_Rollo, 2 event(s), first is dim 99
2017.11.27 08:00:20.146 5: End notify loop for zw_DG_Bad_Rollo
2017.11.27 08:00:20.148 5: ACK received, WaitForAck=>2 for 010a00131203260163251284
2017.11.27 08:00:20.148 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.11.27 08:00:20.149 5: SW: 06
2017.11.27 08:00:20.151 5: ZWDongle_0: dispatch 011301
2017.11.27 08:00:20.195 4: ZWDongle_Read ZWDongle_0: rcvd 00131200 (request ZW_SEND_DATA), sending ACK
2017.11.27 08:00:20.195 5: SW: 06
2017.11.27 08:00:20.196 5: device ack reveived, removing 010a00131203260163251284 from dongle sendstack
2017.11.27 08:00:20.197 5: ZWDongle_0: dispatch 00131200
2017.11.27 08:00:20.197 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:12
2017.11.27 08:00:20.197 4: ZWDongle_0 transmit OK for CB 12, target zw_DG_Bad_Rollo
2017.11.27 08:00:20.198 1: GetRolloPositionAsValue for device zw_DG_Bad_Rollo, reportedState returns: off
2017.11.27 08:00:20.200 1: GetRolloPositionAsValue for device zw_DG_Bad_Rollo, reportedState returns: off
2017.11.27 08:00:21.453 4: ZWDongle_Read ZWDongle_0: rcvd 0004001206310504220347a700 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.11.27 08:00:21.453 5: SW: 06
2017.11.27 08:00:21.454 5: ZWDongle_0: dispatch 0004001206310504220347a700
2017.11.27 08:00:21.455 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:06310504220347a700 CB:00
2017.11.27 08:00:21.457 1: GetRolloPositionAsValue for device zw_DG_Bad_Rollo, reportedState returns: off
2017.11.27 08:00:21.458 5: Starting notify loop for zw_DG_Bad_Rollo, 2 event(s), first is power: 83.9 W
2017.11.27 08:00:21.463 5: End notify loop for zw_DG_Bad_Rollo
...
2017.11.27 08:00:55.432 4: ZWDongle_Read ZWDongle_0: rcvd 0004001306310504220000b600 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.11.27 08:00:55.432 5: SW: 06
2017.11.27 08:00:55.434 5: ZWDongle_0: dispatch 0004001306310504220000b600
2017.11.27 08:00:55.435 4: CMD:APPLICATION_COMMAND_HANDLER ID:13 ARG:06310504220000b600 CB:00
2017.11.27 08:00:55.438 1: GetRolloPositionAsValue for device zw_DG_DZ_Rollo_DFL, reportedState returns: off
2017.11.27 08:00:55.440 5: Starting notify loop for zw_DG_DZ_Rollo_DFL, 2 event(s), first is power: 0.0 W
2017.11.27 08:00:55.450 5: End notify loop for zw_DG_DZ_Rollo_DFL
...
2017.11.27 08:01:05.330 4: ZWDongle_Read ZWDongle_0: rcvd 0004001206310504220000b900 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.11.27 08:01:05.331 5: SW: 06
2017.11.27 08:01:05.333 5: ZWDongle_0: dispatch 0004001206310504220000b900
2017.11.27 08:01:05.333 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:06310504220000b900 CB:00
2017.11.27 08:01:05.337 1: GetRolloPositionAsValue for device zw_DG_Bad_Rollo, reportedState returns: off
2017.11.27 08:01:05.339 5: Starting notify loop for zw_DG_Bad_Rollo, 2 event(s), first is power: 0.0 W
2017.11.27 08:01:05.349 5: End notify loop for zw_DG_Bad_Rollo


Kann man sich auf den reportedState überhaupt verlassen? Gibt es eine Möglichkeit zu erkennen (wenn möglich per Perl-Funktion), ob der reportedState gesetzt wurde, bzw. empfangen wurde? Dass die Readings sich unterschieden kann man prüfen, aber woher weiß man, was richtig ist? Kann man das über das Datum vom Reading machen?

Alternative wäre man schaltet die Aktoren immer auf/ab, unabhängig von deren Position, aber das ist ganz so elegant und erzeugt unnötigen Traffic

Danke schon mal im Voraus für Hilfe!
LG

[rudolfkoenig]

2017.11.27 08:00:20.129 5: SW: 010a00131203260163251284
-> Daten ueber USB/Seriell rausgeschickt, SWITCH_MULTILEVEL set 99 an nodeId x12

2017.11.27 08:00:20.148 5: ACK received, WaitForAck=>2 for 010a00131203260163251284
-> Controller hat Empfang der Daten bestaetigt.

2017.11.27 08:00:20.148 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
-> Controller hat die Daten per Funk versendet

2017.11.27 08:00:20.197 5: ZWDongle_0: dispatch 00131200
-> Gegenstelle hat den Empfang der Daten bestaetigt

2017.11.27 08:00:21.455 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:06310504220347a700 CB:00
-> SENSOR_MULTILEVEL power von nodeId x12
...

Einen Fehler sehe ich nicht, die Gegenstelle hat kein status gemeldet.
Entweder, weil es nicht kann, es nicht konfiguriert ist (Association + Config) oder weil es unterwegs verloren ist. Da ich das Geraet nicht kennen, sind die ersten beiden Faelle hypothetisch.
Als Geraeteentwickler muesste ich auch ueberlegen, wann ich welchen Status melde, so ganz klar ist die Sache nicht.

Gibt es eine Möglichkeit zu erkennen (wenn möglich per Perl-Funktion), ob der reportedState gesetzt wurde, bzw. empfangen wurde?

reportedState ist ein state, was vom Geraet kommt. State gibt es z.Zt. fuer die Klassen SWITCH_BINARY, SWITCH_MULTILEVEL und SENSOR_BINARY. D.h. ob man ueberhaupt reportedState kriegt, haengt von den unterstuetzten Klassen ab. Danach gibt es die Huerden "Firmware im Geraet kann status senden", Geraetekonfiguration, "Geraet sendet _immer_ status", und Paketverlust.

[throbin]

Ok, dann kommt wohl nur der Paketverlust als Ursache in Frage. Alle anderen Punkte kann ich ausschließen (Associations, SWITCH_MULTILEVEL ist ebenfalls vorhanden), abgesehen davon funktioniert es bei den meisten Aktoren gleichen Typs ohne Probleme.
Danke für die Analyse!

[rudolfkoenig]

Alle anderen Punkte kann ich ausschließen

Fuer den Punkt "Geraet sendet _immer_ status" habe ich so meinen Zweifel, dafuer muesste man die Firmware kennen. Selbst als Firmware-Autor wuerde ich das nicht ausschliessen