structure & relativeKnown & state mapping

Begonnen von ThaBear, 04 Januar 2014, 01:29:19

Vorheriges Thema - Nächstes Thema

ThaBear

Moin,

ich denke beim state mapping im structure module stimmt was nicht ganz.
Konkret, die Abbruchbedingung in Zeile 211-214 bricht beim ersten fehlgeschlagenen Mapping ab, weil der ungemappte Wert natuerlich nicht Teil der known states ist. Das sind ja nur die gemappten Werte.

Beispiel:
structure:
clientstate_behavior relativeKnown
clientstate_priority on off

dimmer mapping: pct:0:off pct:10:on

Dimmer steht auf 10.

Das Mapping 10->on wird gar nicht ausgefuehrt, weil beim Evaluieren des ersten Mappings $devstate = 0 wird und die Bedingung abbricht.

Cheers,
M.

Ps: Sehr geil, dass nun Regex verwendet werden koennen.

Puschel74

Hallo,

BUG oder vermeintliche Fehler sollten eigentlich in dem Bereich gepostet werden wo sie auch gelesen werden.

Bereich Automatisierung --> due wilslt was automatisieren und sucht Hilfe oder Lösungen dazu.
Vermeintliche Fehler wird sich hier niemand anschauen - und schon garnicht die Maintainer.

Also entweder unter "Unterstützende Dienste" oder im Bereich "Fehlermeldungen" posten.
Wo eine Fehlermeldung ja auch offensichtlich hin gehört - aber der Admin hat ja genug Zeit zum verschieben.

Danke für das nächste Mal.

Grüße
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

rudolfkoenig

@ThaBear:
- Kann nicht sein, da @value==3 und /^0/ nicht auf 10 matched, und damit wird Zeile 211 nicht aufgerufen. Falls wirklich Probleme auftreten, dann die Definitionen und die Events komplett hier melden, ich versuche es nachzustellen. Was mich irritiert ist, dass beim match kein $ benutzt wird: damit funktioniert pct:1:on auch fuer pct==11, aber auch fuer pct==1 %. Ersteres mag ein Fehler sein, Letzteres Absicht. Seufz.
- Bitte nicht von BUG/Fehler in der Betreff reden, dass ist unhoeflich, auch wenn es stimmen sollte (was hier noch nicht belegt ist), siehe http://www.tty1.net/smart-questions_de.html#dontclaimbug

@Puschel74:
ThaBear war aufmerksam, und hat MAINTAINER.txt gelesen, sein Beitrag ist hier richtig aufgehoben. Falls ein Bereich Fehlermeldungen existiert, dann bitte ich es zuzumachen, den werde ich nicht lesen. Mehr als 90% der Anfaenger koennen Programmfehler nicht von Benutzerfehler unterscheiden, weiterhin muessten _alle_ Entwickler diesen Bereich lesen, womit wir wieder bei der google-gruppe waeren. Usw.

Puschel74

Hallo,

ok - wenn das hier richtig aufgehoben ist dann - sorry, mein Fehler.
Ich gelobe Besserung.

Ich habe mich auf den Bereich Fehlermeldungen unter <FHEM-Entwicklung> bezogen - aber dort wäre der Beitrag ja auch falsch gewesen.

Grüße
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

ThaBear

Moin,

ad Bug: Sorry.


for (my $i=0; $i<@gruppe; $i++) {
   @value = split(":", $gruppe[$i]);

   if(@value == 1) { # value[0]:.* -> .*
      $devstate = ReadingsVal($d, $value[0], undef);

   } elsif(@value == 2) { # state:value[0] -> value[1]
      $devstate = ReadingsVal($d, "state", undef);

      if(defined($devstate) && $devstate =~ m/^$value[0]/){
         $devstate = $value[1];
         $i=99999; # RKO: ??
      }

   } elsif(@value == 3) { # value[0]:value[1] -> value[2]
      $devstate = ReadingsVal($d, $value[0], undef);

      if(defined($devstate) && $devstate =~ m/^$value[1]/){
         $devstate = $value[2];
      }
   }
   if(defined($devstate)) {

      if(!$priority{$devstate} && $behavior eq "relativeKnown") {
         delete($hash->{INNTFY});
         return "";
      }

      $minprio = $priority{$devstate}
         if($priority{$devstate} && $priority{$devstate} < $minprio);
      $clientstate{$devstate} = 1;
}


Die Dimmer pct soll auf on/off gemappt werden. Der Einfachheit halber 0->off 10->on. On/off sind auch die clientstate_priority Werte der structure.

pct:0:off pct:10:on


Durchlauf fuer pct = 10:

In elsif @value == 3
$devstate = 10

Der Match auf pct:0:off schlaegt fehl -> $devstate bleibt 10

Jetzt muesste eigentlich die Schleife mit dem zweiten Mapping (pct:10:on) durchlaufen werden, aber fuer $devstate=10 gibt's logischerweise keine priority (!$priority{$devstate}), weswegen die Funktion abgebrochen wird.

Fuer den Fall, dass kein Mapping zutrifft und keine priority ermittelt werden kann, wird der structure State eh im 233-244 Block auf undefined gesetzt. Das finde ich logischer, als den state unveraendert zu lassen.

Cheers,
M.

Ps: Brauchst die Defs noch? Dauert noch einen Moment...

rudolfkoenig

Ich habe was gefixed und eingecheckt, bin aber nicht sicher, ob das was Du meinst.

ZitatPs: Brauchst die Defs noch? Dauert noch einen Moment...

Ja, um sicher zu sein. Und ich habs nicht eilig.

ThaBear

Moin,

yup, so muesste es gehen.
Ich werd's heut abends testen.

Cheers,
M.

ThaBear