Erweiterung structure

[tobias.faust]

Hallo Rudi,

ich mach mal hier weiter. Ich habe deinen Vorschlag aufgenommen und das Verhalten von structure kann man nun einstellen. Entweder wie ich es benötige, oder so wie du angedacht hattest: die structure nimmt erst dann einen wert an wenn alle devices denselben status haben.
Schau bitte mal drüber, die commandref ist sicherlich auch noch überarbeitungswürdig, mein englisch ist nicht das allerbeste....

[tobias.faust]

Hi Rudi,

ich habe das Modul bei meinem Teil noch minimal überarbeitet, ebenso die commandref.
Als neue Attributnamen für eine Struktur habe ich folgende:
clientstate_behavior
   -> "absolute" oder "relative"
   absolute: die Structure erhält erst dann einen Status, wenn alle zugehörigen devices denselben Status haben. Die structure erhält genau diesen Status. Ansonsten "undefined"
   relative: je nach Einstellung von "clienstate_priority" hat die structure immer den höchsten priorisierten Status der zugehörigen devices.
clientstate_priority
   -> hier kann man, wie schon beschrieben, einstellen, welcher Status aller devices höher priorisiert wird und demzufolge, welchen Status die structure annehmen soll.

bsp:
clientstate_behavior: relative
clientstate_priority: on off

dummy1: state: off
dummy2: state: off
dummy3: state: on
dummy4: state: off

die structure hat "on". Wäre clientstate_behavior=absolute, hätte die structure den status "undefined"

Alle Devices einer structure erhalten folgendes Attribut:
<struct-type>_map
  -> hier stellt man ein, welches Reading des Devices für die Structure  relevant ist, und ob ein mapping vorgenommen werden soll (mapping ähnlich zu eventmap)

Ich würde mir wünschen wenn bzgl der Namensgebung der Attribute noch konkrete Vorschläge kommen würden. Ansonsten poste ich hier den aktuellen Stand und Rudi kanns einchecken.

[Erwin]

Hi Tobias,

mein Vorschlag zur Namensgebung:

client_logic: "AND" "OR" "EXOR" ... zumindest hab ich deine erklärung so verstanden.
client_values: <2 strings>, der erste definiert logisch 1 der zweite logisch 0, alle anderen strings (state values) werden in der Berechnung als undefined berücksichtigt.
                     z.b. "on","off" oder "hot", "cold" ....

l.g. erwin

[Rudolf Koenig]

Hallo Tobias,

> ich mach mal hier weiter. Ich habe deinen Vorschlag aufgenommen und das
> Verhalten von structure kann man nun einstellen

Habs jetzt eingecheckt. Im Code habe ich die Umalute entfernt, und versucht die
Zeilenbreite bei 80 zu belassen. Hab das ergebnnis nur Kurz getestet.


> Schau bitte mal dr�ber, die commandref ist sicherlich auch noch
> �berarbeitungsw�rdig, mein englisch ist nicht das allerbeste....

Habs auch eingecheckt. Hat mich mehr gestoert, dass div. andere Autoren
vergessen <ul> zu schliessen, damit rueckt das ganze commandref.html
stetig nach rechts, und ich muss den Uebeltaeter hinterherrennen. Die
vergesslichen diesmal sind:
- HTTPSrv
- STV
Wuerde nicht erwaehnen, wenn ich das zum ersten mal korrigieren wuerde.

Gruss,
Rudi

[tobias.faust]

Hallo Rudi,

danke, habe sogar noch einen Fehler entdeckt. Kannst du bitte nochmal nachbessern??
Ansonsten tuts bei mir bestens...

--- 98_structure.pm     2012-09-30 18:45:15.000000000 +0200
+++ FHEM/98_structure.pm        2012-09-30 18:51:51.000000000 +0200
@@ -171,6 +171,7 @@
           # zustand wenn der Status auf dem in der Struktur definierten
           # umdefiniert werden muss
           # bsp: on:An
+          $devstate = ReadingsVal($d, "state", undef);
           if(defined($devstate) && $devstate eq $value[0]){
             $devstate = $value[1];
             push(@clientstate, $devstate);

[Rudolf Koenig]

> danke, habe sogar noch einen Fehler entdeckt. Kannst du bitte nochmal
> nachbessern??

Habs eingecheckt.

[Erwin]

Hi Tobias,

ich hab da eine Frage zum structure:

ist es gewollt, dass die Atributes, die im structure device gesetzt werden, in die einzelnen Geräte propagiert werden?
...ich finde das eher störend. z.B. will ich eine structure im Floorplan zeigen, und dann hab ich dieselben Floorplan attributes in allen devices der struktur.....

ich hab da auch noch ein Verständnisproblem mit dem structexclude:
wenn ich im device structexclude setzte, dann  wird der status der structur nicht in die devices propagiert, soweit ok - allerdings funktioniert dann auch die Gegenrichtung nicht mehr:  Ändert sich <state> im device wird das nicht an die structur propagiert...

ich habs bisher nur mit dummy devices versucht...

danke erwin

Am Montag, 10. September 2012 15:03:05 UTC+2 schrieb tobias.faust:

[Rudolf Koenig]

> ist es gewollt, dass die Atributes, die im structure device gesetzt werden,

> in die einzelnen Ger�te propagiert werden?

Ja.

> wenn ich im device structexclude setzte, dann wird der status der structur
> nicht in die devices propagiert, soweit ok - allerdings funktioniert dann

> auch die Gegenrichtung nicht mehr: �ndert sich <state> im device wird das

> nicht an die structur propagiert...

??? Dieses Geraet soll ja auch nicht Teil der Struktur sein....

Btw. diese Frage waere in fhem-users besser aufgehoben.

[Erwin]

Danke Rudolf,

... ich überleg mir was anderes.
l.g. erwin

Am Freitag, 5. Oktober 2012 12:00:18 UTC+2 schrieb Rudolf Koenig:

> ist es gewollt, dass die Atributes, die im structure device gesetzt werden,

> in die einzelnen Ger�te propagiert werden?

Ja.


> wenn ich im device structexclude setzte, dann  wird der status der structur
> nicht in die devices propagiert, soweit ok - allerdings funktioniert dann

> auch die Gegenrichtung nicht mehr:  ï¿½ndert sich <state> im device wird das

[tobias.faust]

On Friday, October 5, 2012 11:54:35 AM UTC+2, Erwin wrote:

Hi Tobias,

ich hab da eine Frage zum structure:

ist es gewollt, dass die Atributes, die im structure device gesetzt werden, in die einzelnen Geräte propagiert werden?
...ich finde das eher störend. z.B. will ich eine structure im Floorplan zeigen, und dann hab ich dieselben Floorplan attributes in allen devices der struktur.....

auch von mir ein: Ja
 

ich hab da auch noch ein Verständnisproblem mit dem structexclude:
wenn ich im device structexclude setzte, dann  wird der status der structur nicht in die devices propagiert, soweit ok - allerdings funktioniert dann auch die Gegenrichtung nicht mehr:  Ändert sich <state> im device wird das nicht an die structur propagiert...

Na deswegen gibts ja structexclude, solange dieses gesetzt ist, wird das device ausgelassen. So kann man mittels trigger/notify´s dynamisch die devices an oder ausschalten

[Erwin]

Hi Tobias,

danke für die Erklärung, schaut soo aus, als ob mein Problem nicht zur Lösung passt.... ;-))

was ich brauche, ist ein logisches OR von mehreren devices states.
Ich hab das jetzt mit einem kurzen code snippet gelöst.

#### WLANStatus-Summary
# returns 1 if one of the members is 1 else returns 0
# called from WLANstatus_nf notify
####
sub mydevsum(@) {
  my (@devnames) = @_;
  #my @devnames = ("AliceatHome","ErwinatHome","LisaatHome","PhilipatHome","ToniatHome");
  my $status = 0;
  foreach(@devnames) {
    # $status = ReadingsVal($_, "state", 0);
    $status = Value($_);
    last if ($status == 1);  # break if one is true
  }
  return ($status == 1) ? 1 : 0;
}

Danke nochmal !
erwin

[UliM]

Hallo Tobias,
auch ich habe ne Menge Log-Einträge bei mehrstufigen Strukturen nach dem Schema
2012.10.06 22:47:44 1: ERROR: endless loop detected for ku_LichtAlle in Wohnung_Licht

wie auch von Rudi aufgezeigt: https://groups.google.com/d/msg/fhem-users/USS6ssZrhDY/8Y-Zxyzsn6MJ

Kannst Du das bitte bei Gelegenheit noch angehen?

Danke+Gruß,
Uli

[tobias.faust]

Ups, ich habe diese Fehlermeldungen noch nicht gesehen, auch den angegebene Beitrag nicht.

Ich schaue mir das natürlich an, Rudi hat ja schon einen simplen testfall geschildert.
Gruss

[tobias.faust]

Hier das update. damit funktioniert bei mir nun der testfall..

--- 98_structure.pm     2012-10-09 19:38:47.000000000 +0200
+++ FHEM/98_structure.pm        2012-10-09 19:40:18.000000000 +0200
@@ -225,6 +225,7 @@
     $newState = "undefined";
   }
 
+  delete($hash->{INSET});
 
   #eigenen Status jetzt setzen, nur wenn abweichend
   if(!defined($hash->{STATE}) || ($hash->{STATE} ne $newState)) {
@@ -235,10 +236,6 @@
     readingsUpdate($hash, "state", $newState);
     readingsEndUpdate($hash, 1);
   }
-  #Log 1, "devstate: ".$devstate." - minprio final: " . $minprio . "\n";
-  #Log 1, Dumper(%priority);
-  delete($hash->{INSET});
-
   undef;
 }

[UliM]

Hi Tobias,
im SVN scheint das nicht zu sein, und mit dieser Schreibweise kann ich nix anfangen - welche Zeilen sollen ersetzt/hinzugefügt werden? Vermute dass das ein diff ist - kann man das nach notepad++ einlesen?
Gruß, Uli

[tobias.faust]

Es ist ein diff. Rudi möchte es immer als diff.
Einfach in eine leere textdatei kopieren und mit DIFF verarbeiten.
Warscheinlich hat Rude gerade keine ZEit. Einfach mal warten....

[UliM]

Hi,
keine Ahnung wie man DIFF verarbeitet. Hab die Änderungen mal manuell ins pm übernommen.
Die
ERROR: endless loop detected
-Meldungen sind weg. Status der structure wird wie gewünscht gesetzt.
Allerdings hab ich hier nur clientstate_behavior relative, clientstate_priority on off - weiss also nicht, ob andere Konstellationen ggf negativ von diesem change beeinflusst werden.
Soweit also aus meiner Sicht prima.

Soll ich's einchecken?



Nun bleibt nur noch die lange Latte der Meldungen
2012.10.14 14:06:26 3: ez_LichtRegal: unknown attribute clientstate_behavior, choose one of room group comment alias eventMap IODev follow-on-for-timer:1,0 follow-on-timer do_not_notify:1,0 ignore:1,0 dummy:1,0 showtime:1,0 loglevel:0,1,2,3,4,5,6 model:dummyDimmer,dummySender,dummySimple,fs20as1,fs20as4,fs20bf,fs20bs,fs20di,fs20di10,fs20du,fs20fms,fs20hgs,fs20irl,fs20kse,fs20ls,fs20ms2,fs20pira,fs20piri,fs20piru,fs20rgbsa,fs20rst,fs20rsu,fs20s16,fs20s20,fs20s4,fs20s4a,fs20s4m,fs20s4u,fs20s4ub,fs20s8,fs20s8m,fs20sa,fs20sd,fs20sig,fs20sm4,fs20sm8,fs20sn,fs20sr,fs20ss,fs20st,fs20st2,fs20str,fs20su,fs20sv,fs20tc1,fs20tc6,fs20tfk,fs20tk,fs20ue1,fs20usr,fs20uts,fs20ws1,fs20ze Wohnung Wohnung_map fm_fav fm_groups fm_name fm_order fm_type fm_view fp_Grundriss fp_Media fp_Peter fp_PlotsPage fp_dark icon room_map setList structexclude webCmd or use attr global userattr clientstate_behavior
2012.10.14 14:06:26 3: ez_LichtVitrine: unknown attribute clientstate_behavior, choose one of room group comment alias eventMap IODev follow-on-for-timer:1,0 follow-on-timer do_not_notify:1,0 ignore:1,0 dummy:1,0 showtime:1,0 loglevel:0,1,2,3,4,5,6 model:dummyDimmer,dummySender,dummySimple,fs20as1,fs20as4,fs20bf,fs20bs,fs20di,fs20di10,fs20du,fs20fms,fs20hgs,fs20irl,fs20kse,fs20ls,fs20ms2,fs20pira,fs20piri,fs20piru,fs20rgbsa,fs20rst,fs20rsu,fs20s16,fs20s20,fs20s4,fs20s4a,fs20s4m,fs20s4u,fs20s4ub,fs20s8,fs20s8m,fs20sa,fs20sd,fs20sig,fs20sm4,fs20sm8,fs20sn,fs20sr,fs20ss,fs20st,fs20st2,fs20str,fs20su,fs20sv,fs20tc1,fs20tc6,fs20tfk,fs20tk,fs20ue1,fs20usr,fs20uts,fs20ws1,fs20ze Wohnung Wohnung_map fm_fav fm_groups fm_name fm_order fm_type fm_view fp_Grundriss fp_Media fp_Peter fp_PlotsPage fp_dark icon room_map setList structexclude webCmd or use attr global userattr clientstate_behavior
2012.10.14 14:06:26 3: ez_Schreibtisch: unknown attribute clientstate_behavior, choose one of room group comment alias eventMap IODev follow-on-for-timer:1,0 follow-on-timer do_not_notify:1,0 ignore:1,0 dummy:1,0 showtime:1,0 loglevel:0,1,2,3,4,5,6 model:dummyDimmer,dummySender,dummySimple,fs20as1,fs20as4,fs20bf,fs20bs,fs20di,fs20di10,fs20du,fs20fms,fs20hgs,fs20irl,fs20kse,fs20ls,fs20ms2,fs20pira,fs20piri,fs20piru,fs20rgbsa,fs20rst,fs20rsu,fs20s16,fs20s20,fs20s4,fs20s4a,fs20s4m,fs20s4u,fs20s4ub,fs20s8,fs20s8m,fs20sa,fs20sd,fs20sig,fs20sm4,fs20sm8,fs20sn,fs20sr,fs20ss,fs20st,fs20st2,fs20str,fs20su,fs20sv,fs20tc1,fs20tc6,fs20tfk,fs20tk,fs20ue1,fs20usr,fs20uts,fs20ws1,fs20ze Wohnung Wohnung_map fm_fav fm_groups fm_name fm_order fm_type fm_view fp_Grundriss fp_Media fp_Peter fp_PlotsPage fp_dark icon room_map setList structexclude webCmd or use attr global userattr clientstate_behavior
2012.10.14 14:06:26 3: ez_LichtRegal: unknown attribute clientstate_priority, choose one of room group comment alias eventMap IODev follow-on-for-timer:1,0 follow-on-timer do_not_notify:1,0 ignore:1,0 dummy:1,0 showtime:1,0 loglevel:0,1,2,3,4,5,6 model:dummyDimmer,dummySender,dummySimple,fs20as1,fs20as4,fs20bf,fs20bs,fs20di,fs20di10,fs20du,fs20fms,fs20hgs,fs20irl,fs20kse,fs20ls,fs20ms2,fs20pira,fs20piri,fs20piru,fs20rgbsa,fs20rst,fs20rsu,fs20s16,fs20s20,fs20s4,fs20s4a,fs20s4m,fs20s4u,fs20s4ub,fs20s8,fs20s8m,fs20sa,fs20sd,fs20sig,fs20sm4,fs20sm8,fs20sn,fs20sr,fs20ss,fs20st,fs20st2,fs20str,fs20su,fs20sv,fs20tc1,fs20tc6,fs20tfk,fs20tk,fs20ue1,fs20usr,fs20uts,fs20ws1,fs20ze Wohnung Wohnung_map fm_fav fm_groups fm_name fm_order fm_type fm_view fp_Grundriss fp_Media fp_Peter fp_PlotsPage fp_dark icon room_map setList structexclude webCmd or use attr global userattr clientstate_priority
2012.10.14 14:06:26 3: ez_LichtVitrine: unknown attribute clientstate_priority, choose one of room group comment alias eventMap IODev follow-on-for-timer:1,0 follow-on-timer do_not_notify:1,0 ignore:1,0 dummy:1,0 showtime:1,0 loglevel:0,1,2,3,4,5,6 model:dummyDimmer,dummySender,dummySimple,fs20as1,fs20as4,fs20bf,fs20bs,fs20di,fs20di10,fs20du,fs20fms,fs20hgs,fs20irl,fs20kse,fs20ls,fs20ms2,fs20pira,fs20piri,fs20piru,fs20rgbsa,fs20rst,fs20rsu,fs20s16,fs20s20,fs20s4,fs20s4a,fs20s4m,fs20s4u,fs20s4ub,fs20s8,fs20s8m,fs20sa,fs20sd,fs20sig,fs20sm4,fs20sm8,fs20sn,fs20sr,fs20ss,fs20st,fs20st2,fs20str,fs20su,fs20sv,fs20tc1,fs20tc6,fs20tfk,fs20tk,fs20ue1,fs20usr,fs20uts,fs20ws1,fs20ze Wohnung Wohnung_map fm_fav fm_groups fm_name fm_order fm_type fm_view fp_Grundriss fp_Media fp_Peter fp_PlotsPage fp_dark icon room_map setList structexclude webCmd or use attr global userattr clientstate_priority
2012.10.14 14:06:26 3: ez_Schreibtisch: unknown attribute clientstate_priority
......

bei jedem fhem-Start - wohl weil versucht wird, diese beiden Attribute von der structure auf die nächste structure-Ebene und v.a. auf alle devices zu vererben - und da gibt's die nicht.


Gruß, Uli

[tobias.faust]

die langen Logmeldungen beim Start müssten aber schon vor meinen Änderungen da gewesen sein. Hier hab ich mich nur an Rudis Implemantierung drangehangen.

[UliM]

Hi,
jain :)
Die Vererbung war schon vorher da, die Attribute c.s.behaviour und c.s.behaviour nicht.
Ist aber nicht so wild - kommt ja nur beim Start.
Gruß, Uli

[tobias.faust]

Hallo Rudi,

falls du es noch nicht getan hast, kannst du die miniänderung von oben (09.10) noch einchecken?

gruss
Tobias

[Rudolf Koenig]

> falls du es noch nicht getan hast, kannst du die mini�nderung von oben
> (09.10) noch einchecken?

Habs gemacht.

[Notausstieg]

Hallo zusammen,

hab das Feature gerade mal getestet da ich es sehr interessant finde, allerdings hat diese Implementierung noch ein Problem, wenn beide Geräte einen Status haben der nicht unter clientstate_priority spezifiziert ist (Bsp: Prozentwerte bei Dimmern). 

In diesem Fall steht im Logfile:

 

Update structure 'Gesamtes_Licht' to  because device 'Licht_Wohnzimmer' has changed

Wo dann eine Fehlermeldung auftritt: 

Usage: setstate where is either: - a single device name - a list seperated by komma (,) - a regexp, if contains one of the following characters: *[]^$ - a range seperated by dash (-) 

Kann man hier evtl. eine Variante fahren, das man z.B. einfach nur ein Prozentzeichen bei derf priority reinsetzt, was als eine art regexp gedacht ist um Prozentangaben zu filtern, da ich da jetzt ungern alle Prozentangaben von 0 bis 100 angeben wollte.

Viele Grüße

Markus

On Friday, October 19, 2012 9:30:48 AM UTC+2, Rudolf Koenig wrote:

> falls du es noch nicht getan hast, kannst du die mini�nderung von oben

[tobias.faust]

Ich habe das Problem noch nicht ganz verstanden.

Kannst du, analog zu Rudi von oben, ein minimalistisches Beispiel von Dummy-Devices posten anhand derer ich das nachvollziehen kann?
gruss

[UliM]

Hiho,
1. der große Schwung logmeldungen zu unknown attribute clientstate_behavior/unknown attribute clientstate_priority  beim Start ist leider noch immer da, siehe attachment (mehrfach versucht zu posten, kriege immer google-groups-Fehler 340, versuche es jetzt ohne attachment...). Wäre schön, wenn sich das beheben liesse.

M.E. sollten die Attribute

clientstate_behavior
clientstate_priority

von der Vererbung ausgenommen werden, wenn das untergeordnete Element nicht selbst eine structure ist, da diese Attribute per definitionem ja nur auf einer structure existieren, jedoch nie auf den enthaltenen devices.

2. Auch ist mein log voll von Meldungen wie

2012.12.02 09:37:49.678 3: Update structure 'ku_LichtAlle' to off because device 'ko_LichtKorridor' has changed
Kannst Du bitte den Loglevel dieser Meldung auf 4 setzen, also in Zeile 253. Das mach ich nach jedem update...

Gruß,
Uli

[tobias.faust]

Hi Uli,

Punkt 2, da lass ich mir etwas einfallen.
Punkt 1, da habe ich mich nur an Rudis Code gehangen..... Hast du ev. nen Patch?

Entweder war dein log zu groß oder du musst es umbenennen in txt

[UliM]

Hallo Tobias,

Am Mittwoch, 5. Dezember 2012 08:04:30 UTC+1 schrieb tobias.faust:

Punkt 1, da habe ich mich nur an Rudis Code gehangen..... Hast du ev. nen Patch?

Ui, nee :)
 

Entweder war dein log zu groß oder du musst es umbenennen in txt

Oh. Nochmal als zip anbei.

=8-)

[tobias.faust]

Um das mal einfach auszudrücken: ich weiß nicht warum.
Ich habe im Initialize nur folgendes hinzugefügt...

$hash->{AttrList}  = "clientstate_priority clientstate_behavior:relative,absolute";

sowie es sonst auch definiert wird.

[Ulrich Maass]

Hi,
schon klar.
Ich finde den Effekt logisch:
- structure vererbt Attribute an ihre "Kinder", das ist i.A. auch sehr praktisch.
- wenn ein "Kind" nicht vom Typ structure ist, kann das Kind die Attribute clientstate.* aber nicht haben -> Fehlermeldung

Deshalb meinte ich, dass clienstate.* von der Vererbung ausgenommen werden müssten.

=8-)

PS: Dass ich den Effekt logisch finde macht leider den Effekt nicht besser ;-)

[tobias.faust]

Hi Uli,
kannst du den Patch bitte mal testen?

- per Loglevel Attribut kann man nun einstellen ob man die Logs sehen will oder nicht
- die Attribute clientstate* und loglevel werden nun auch nicht weitergereicht

[Ulrich Maass]

Am 7. Dezember 2012 14:32 schrieb tobias.faust <tobias...@gmx.net>:

Hi Uli,
kannst du den Patch bitte mal testen?

Hallo Tobias,
das sieht sehr sehr gut aus :)
Ich würde mich freuen wenn Du's so einchecken würdest.
LG + schönen Advent,
Uli

[tobias.faust]

Hallo Rudi,

kannst du den Patch einchecken? Ich würds auch tun, möchte aber ungern unabgesprochen in fremden Modulen rumfrickeln

[Rudolf Koenig]

> kannst du den Patch einchecken?

Eingecheckt.