IO-Homecontrol Devices über Tahoma Box einbinden

[MaxAut]

Guten Morgen!

Wie bereits per Email geschrieben liegt es nicht an den 13 gleichzeitigen Befehlen; das ist ein zusätzliches Problem; Es funktionieren die ersten 10 ja auch schon nicht. Ich schicke Dir gleich noch das Log mit Verbose 4, wie per Email ausgemacht.

Zu den 4 Punkten:

1. Verzögerung: --> finde ich schlecht, weil dadurch das Verhalten für den Anwender unresponsive wird. Wenn ich klicke, will ich auch unmittelbar eine Reaktion haben.
2. Gruppen: --> Es gibt ja ohnehin die Gruppen aus dem Tahoma Device, das ist, zumindest für mich, völlig ausreichend! Ich fasse manche Gruppen dann noch mit Structures zusammen; es wäre schön, würde der Status dann kumuliert angezeigt werden. Bei unterschiedlichen Werten müsste man halt einen Standardwert zurückgeben; das würde bei mir allerdings kaum vorkommen, da ich ja die Gruppen primär über die Structures steuere, und damit überall der selbe Status zu erwarten ist.
3. Dim mit Devices als Parameter: Super Idee!
4. Nächster Befehl erst wenn vorheriger abgearbeitet: Das finde ich ganz schlecht. Warum? Ich habe 21 Fenster, mit jeweils einer Außenmarkise. Das Schließen der Markise dauert beispielsweise etwa 10 Sekunden. Würde ich nun alle 21 Fenster einzeln ansteuern, würde es 210 Sekunden dauern bis alle Markisen unten sind. Jetzt kommt das bei mir nicht vor, weil ich ohnehin mit den Tahoma Gruppen steuere, und eine solche Gruppe für Dich ein Device ist, aber dennoch. Queuing wäre m.E. ab dem 11. Befehl sinnvoll.

[MaxAut]

Hallo!

Alter Thread, aufgewärmt . Ich habe seit einigen Tagen das Problem, dass FHEM alle 5 Minuten für 5-10 Sekunden blockiert. Im Log sieht das dann so aus:

Code Auswählen Erweitern

2016.10.10 15:24:14 1: Perfmon: possible freeze starting at 15:24:07, delay is 7.939
2016.10.10 15:29:12 1: Perfmon: possible freeze starting at 15:29:07, delay is 5.92
2016.10.10 15:34:13 1: Perfmon: possible freeze starting at 15:34:08, delay is 5.767
2016.10.10 15:39:15 1: Perfmon: possible freeze starting at 15:39:08, delay is 7.817
2016.10.10 15:44:15 1: Perfmon: possible freeze starting at 15:44:08, delay is 7.895
2016.10.10 15:49:16 1: Perfmon: possible freeze starting at 15:49:08, delay is 8.562

Apptime sagt (nach 10 Minuten Laufzeit) Folgendes dazu:

Code Auswählen Erweitern

name             function    max  count    total  average maxDly
          tmr-tahoma_readStatusTimer       HASH(0xb28f38)   9132    263    34695   131.92    196 HASH(AAAtahoma1)


Hast Du eine Idee dazu?

Liebe Grüße,
Max

[mike3436]

Hast Du eine Idee dazu?

Normalerweise wird alle 2s ein getEvents Kommando abgesetzt, um Statusänderungen zu erfragen.
Im Modul wird zusätzlich alle 300s anstatt eines getEvents ein refreshAllStates+getStates aufgerufen.
Das hatte ich mal aus Sicherheitsgründen implementiert, falls durch getEvents nicht alle Statusänderungen erfasst werden.
Dies macht jetzt anscheinen bei dir Probleme.

Ersetze mal testweise den Code in der Funktion tahoma_readStatusTimer:

Code Auswählen Erweitern

sub tahoma_readStatusTimer($)
{
  my ($hash) = @_;
  my $name = $hash->{NAME};

  my ($seconds) = gettimeofday();
  $hash->{refreshStateTimer} = $seconds + 10 if ( (!defined($hash->{refreshStateTimer})) || (!$hash->{logged_in}) );
 
  if( $seconds < $hash->{refreshStateTimer} )
  {
    Log3 $name, 4, "$name: refreshing event";
    tahoma_getEvents($hash, 1);
  }
  else
  {
    Log3 $name, 4, "$name: refreshing state";
    # tahoma_refreshAllStates($hash, 0);                 # <<< auskommentiert
    # tahoma_getStates($hash, 1);                             # <<< auskommentiert
    tahoma_getEvents($hash, 1);                               # <<< neu
    $hash->{refreshStateTimer} = $seconds + 300;
  }

  InternalTimer(gettimeofday()+2, "tahoma_readStatusTimer", $hash, 0);
}

LG Rolf

[MaxAut]

hmmm ... ist besser geworden, aber nicht weg; heute um 16:00 habe ich apptime gestartet und danach bewusst FHEM nicht angegriffen.

Hier das Log seitdem:

Code Auswählen Erweitern

2016.10.11 16:02:53 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/98_apptime.pm line 24.
2016.10.11 16:02:53 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/98_apptime.pm line 58.
2016.10.11 16:44:49 1: Perfmon: possible freeze starting at 16:44:48, delay is 1.974
2016.10.11 16:53:24 1: Perfmon: possible freeze starting at 16:53:23, delay is 1.399
2016.10.11 17:01:46 1: Perfmon: possible freeze starting at 17:01:45, delay is 1.763
2016.10.11 17:08:09 2: AAAtahoma1: http request failed: Server closed connection without sending any data back
2016.10.11 17:08:09 1: Perfmon: possible freeze starting at 17:08:07, delay is 2.674
login start
tahoma_autocreate begin
tahoma_autocreate end, new=0
2016.10.11 17:08:12 3: updateDevices
tahoma_autocreate begin
tahoma_autocreate end, new=0
2016.10.11 17:08:12 3: updateDevices
2016.10.11 17:08:24 1: Perfmon: possible freeze starting at 17:08:12, delay is 12.159
2016.10.11 17:11:58 1: Perfmon: possible freeze starting at 17:11:55, delay is 3.863
2016.10.11 17:27:58 1: Perfmon: possible freeze starting at 17:27:57, delay is 1.06
2016.10.11 17:42:40 2: AAAtahoma1: http request failed: Server closed connection without sending any data back
2016.10.11 17:42:40 1: Perfmon: possible freeze starting at 17:42:38, delay is 2.52
login start
tahoma_autocreate begin
tahoma_autocreate end, new=0
2016.10.11 17:42:43 3: updateDevices
tahoma_autocreate begin
tahoma_autocreate end, new=0
2016.10.11 17:42:43 3: updateDevices
2016.10.11 17:42:53 1: Perfmon: possible freeze starting at 17:42:43, delay is 10.076
2016.10.11 17:44:15 1: Perfmon: possible freeze starting at 17:44:14, delay is 1.912
2016.10.11 17:56:28 3: CUL_HM set Lichterkette on
2016.10.11 18:02:06 1: Perfmon: possible freeze starting at 18:02:05, delay is 1.709
2016.10.11 18:10:16 1: Perfmon: possible freeze starting at 18:10:14, delay is 2.103
2016.10.11 18:15:13 1: Perfmon: possible freeze starting at 18:15:12, delay is 1.817


Und hier der Output von apptime:

Code Auswählen Erweitern

name             function    max  count    total  average maxDly
          tmr-tahoma_readStatusTimer      HASH(0x10dcc68)  12490   4025   288040    71.56   2099 HASH(AAAtahoma1)

Liebe Grüße,
Max

[mike3436]

Ich habe auch mal perfmon geladen, und bei mir kommen die grossen blockierenden Zeiten > 10s nur beim Einloggen und dem folgendem Lesen des Setup und der States.
apptime kommt nach dem Start bei mir nicht über 500ms obwohl mehrere refreshAllStates+getStates aufgerufen wurden.

Code Auswählen Erweitern

                                name             function    max  count    total  average maxDly
          tmr-tahoma_readStatusTimer      HASH(0x19726a0)    489    696    35701    51.29    139 HASH(tahoma1)

Ich denke, es geht kein Weg mehr vorbei an der Überarbeitung des Moduls bezüglich asynchroner Abarbeitung!
Der Server reagiert zeitweise träge und blockiert so FHEM!
Ich hatte schon angefangen, aber wegen Zeitmangel wieder abgebrochen.

LG Rolf

[MaxAut]

Ich fürchte meine 49 Velux Produkte und die 12 in Tahoma definierten "Räume" um das vernünftig in Gruppen steuern zu können, machen die Sache nicht einfacher/schneller .

Ich bin kein Programmierer, aber wenn ich dennoch irgendwie behilflich sein kann (beispielsweise als Tester) dann sehr gerne!

Liebe Grüße,
Max

[webundstyle]

Hallo,

ich habe zwei Rollos über die Tahoma Box in Fhem dirn. "Meo Fenster" geht "Meo Tür" geht nicht (via Homekit bzw via Fhem Web). Sind beides die gleichen Motoren.
Über die Tahoma oder per IO Schalter gehen beide. Hier die Konfig:

Fenster (geht):

Code Auswählen Erweitern

2016.10.20 11:30:51 3: tahoma_applyRequest data={"label":"Meo Fenster - Positionieren auf 100 % - iPhone","actions":[{"deviceURL":"io://1202-6008-2347/1419502","commands":[{"name":"setClosure","parameters":[100]}]}]}
2016.10.20 11:31:14 3: tahoma_applyRequest data={"label":"Meo Fenster - Positionieren auf 0 % - iPhone","actions":[{"deviceURL":"io://1202-6008-2347/1419502","commands":[{"name":"setClosure","parameters":[0]}]}]}



Internals:
   COMMANDS   dim:slider,0,1,100 close:noArg delayedStopIdentify down:noArg getName:noArg identify:noArg my:noArg open:noArg setClosure setDeployment setMemorized1Position setName setPosition setSecuredPosition startIdentify:noArg stopIdentify:noArg up:noArg wink
   DEF        DEVICE io://1202-6008-2347/1419502
   INTERVAL   2
   IODev      tahoma1
   NAME       tahoma_1419502
   NR         68
   NTFY_ORDER 50-tahoma_1419502
   STATE      dim0
   SUBTYPE    DEVICE
   TYPE       tahoma
   dataTypes  core:NameState,core:RSSILevelState,core:ClosureState,core:OpenClosedState
   device     io://1202-6008-2347/1419502
   fid        1419502
   inControllable io:RollerShutterGenericIOComponent
   inLabel    Meo Fenster
   inPlaceOID c82d9f9b-4f7a-445d-9693-0b01d8cfd699
   inType     1
   Readings:
     2016-10-20 11:31:35   devicestate     open
     2016-10-20 11:31:35   position        0
     2016-10-20 11:31:35   state           dim0
   Helper:
     readingNames:
       hash(0x3f61e90)
       hash(0x3f61f08)
       hash(0x3f61f80)
       hash(0x3f61ff8)
Attributes:
   IODev      tahoma1
   alias      RollerShutter Meo Fenster
   genericDeviceType blind
   homebridgeMapping CurrentPosition=dim::position,invert=1,minValue=0,maxValue=100 TargetPosition=dim::position,invert=1,minValue=0,maxValue=100,minStep=10
   room       Homekit,tahoma
   userReadings position {ReadingsNum($name,'state',50)}
   webCmd     dim


Tür (geht nicht):

Code Auswählen Erweitern

2016.10.20 11:30:10 3: tahoma_applyRequest data={"label":"Meo Tür - Positionieren auf 0 % - iPhone","actions":[{"deviceURL":"io://1202-6008-2347/15514408","commands":[{"name":"setClosure","parameters":[0]}]}]}
2016.10.20 11:30:10 2: tahoma1: http request failed: Bad Request



Internals:
   COMMANDS   dim:slider,0,1,100 close:noArg delayedStopIdentify down:noArg getName:noArg identify:noArg my:noArg open:noArg setClosure setDeployment setMemorized1Position setName setPosition setSecuredPosition startIdentify:noArg stopIdentify:noArg up:noArg wink
   DEF        DEVICE io://1202-6008-2347/15514408
   INTERVAL   2
   IODev      tahoma1
   NAME       tahoma_15514408
   NR         69
   NTFY_ORDER 50-tahoma_15514408
   STATE      dim0
   SUBTYPE    DEVICE
   TYPE       tahoma
   dataTypes  core:NameState,core:RSSILevelState,core:ClosureState,core:OpenClosedState
   device     io://1202-6008-2347/15514408
   fid        15514408
   inControllable io:RollerShutterGenericIOComponent
   inLabel    Meo Tür
   inPlaceOID c82d9f9b-4f7a-445d-9693-0b01d8cfd699
   inType     1
   Readings:
     2016-10-20 11:30:23   devicestate     open
     2016-10-20 11:30:23   position        0
     2016-10-20 11:30:23   state           dim0
   Helper:
     readingNames:
       hash(0x3f64db8)
       hash(0x3f64e30)
       hash(0x3f64ea8)
       hash(0x3f64f20)
Attributes:
   IODev      tahoma1
   alias      RollerShutter Meo Tür
   genericDeviceType blind
   homebridgeMapping CurrentPosition=dim::position,invert=1,minValue=0,maxValue=100 TargetPosition=dim::position,invert=1,minValue=0,maxValue=100,minStep=10
   room       Homekit,tahoma
   userReadings position {ReadingsNum($name,'state',50)}
   webCmd     dim

Kann mir jemand helfen?

Danke!!!

[mike3436]

Hallo,

ich kann grundsätzlich keine zwischen beiden devices Unterschiede erkennen, und somit auch keinen Grund für einen "Bad Request".
Einziger infrage kommender Versuch: mal 'Tür' durch 'Tuer' ersetzen

Ansonsten benötige ich mal das FHEM log mit attribut verbose 4 auf tahoma1 und dann vielleicht 2 Versuche, die Rollade zu verfahren - ggf. auch per PM

[webundstyle]

hi,

du bist ja geil!  Jetzt gehts....es war tatsächlich das "ü" in Tür.....

Vielen Dank!

[mike3436]

Hallo, die Umlautproblematik ist mir bisher unbekannt!
Ich habe mehrere Devices und Räume mit Umlauten (Küche, Büro, usw.)
Den Namen 'Meo Tür' hast du aber über die Somfy App vorgegeben, oder.
Somit ist alles gleich wie bei mir auch, komisch, ...

[scooty]

Hallo,

erst einmal vielen Dank für das Modul!

Durch DG-Ausbau mit Velux-Fenstern und -Rolläden ist nun also auch eine Tahoma-Box eingezogen.
Einbindung in FHEM problemlos dank dieses Moduls!
[thumbsup]

Ein, zwei kurze Fragen noch:
Bin auch durch meiner Homematic/Zwave-Komponenten die Mimik 100=offen/0=closed gewöhnt.
Hier hattet ihr ja schon 'mal über ein mögliches Attribut "levelInverse" geschrieben. Wäre klasse, wenn das kommen könnte (open/close braucht nicht invertiert zu werden).

Gibt es irgendwo einen Doku über die möglichen "set"-Befehle und ihrer Parameter für die Tahoma Devices?
Beim Dachfenster-Rolladen habe ich z.B.

dim
close
delayedStopIdentify
down
getName
identify
my
open
refreshMemorized1Position
setClosure
setDeployment
setMemorized1Position
setName
setPosition
setSecuredPosition
startIdentify
stopIdentify
up
wink

zur Auswahl, von denen mir einige rein von ihrer "Benamsung" her leider nicht viel sagen.

Ach so, falls es noch jemand für seine Rolläden gebrauchen kann:
Icons für verschiedene Positionen eines Dachfenster-Rollos

Viele Grüße,
Andreas

[mike3436]

Hallo,

ich habe habe ab Modul Version 205 zusätzlich zum selbst definierten 'dim' die gesamte Palette aller verfügbaren Kommandos der einzelnen Devices verfügbar gemacht, egal ob hinter jedem Kommando da ein für uns nützlicher ein Sinn hinter steck oder nicht. Und ich kann auch nur Vermutungen anstellen, was sich hinter jedem Kommando verbirgt - aber das lasse ich lieber. Generell macht es aber Sinn, da ich nicht alle Devices kenne und so jeder die Möglichkeit hat, alle Funktionen der eigenen Devices anzusteuern.

Und das levelinverse steht auf der todo Liste ...

[webundstyle]

Hallo, die Umlautproblematik ist mir bisher unbekannt!
Ich habe mehrere Devices und Räume mit Umlauten (Küche, Büro, usw.)
Den Namen 'Meo Tür' hast du aber über die Somfy App vorgegeben, oder.
Somit ist alles gleich wie bei mir auch, komisch, ...

hi,

ja über die somfy!

grüße

[webundstyle]

hi,

ich habe Probleme meine Markise zu steuern (via apple home app). Also sie geht raus und rein...aber das icon läd und läd und bekommt keinen finalen Status...

Code Auswählen Erweitern

Internals:
   COMMANDS   dim:slider,0,1,100 close:noArg delayedStopIdentify deploy:noArg down:noArg getName:noArg identify:noArg my:noArg open:noArg refreshMemorized1Position:noArg setClosure setDeployment setMemorized1Position setName setPosition setSecuredPosition startIdentify:noArg stopIdentify:noArg undeploy:noArg up:noArg wink
   DEF        DEVICE io://1202-6008-2347/16118265
   INTERVAL   2
   IODev      tahoma1
   NAME       tahoma_16118265
   NR         70
   NTFY_ORDER 50-tahoma_16118265
   STATE      Initialized
   SUBTYPE    DEVICE
   TYPE       tahoma
   dataTypes  core:NameState,core:PriorityLockTimerState,core:StatusState,core:RSSILevelState,core:DeploymentState,core:OpenClosedState
   device     io://1202-6008-2347/16118265
   fid        16118265
   inControllable io:HorizontalAwningIOComponent
   inLabel    Kinder Balkon
   inPlaceOID 8e3e51a0-2696-4445-96ff-cc6915e201d2
   inType     1
   Readings:
     2016-10-30 14:27:54   devicestate     open
     2016-10-30 14:27:54   position        100
   Helper:
     readingNames:
       hash(0x3ecd450)
       hash(0x3ecd4c8)
       hash(0x3ecd540)
       hash(0x3ecd5b8)
       hash(0x3ecd630)
       hash(0x3ecd6a8)
Attributes:
   IODev      tahoma1
   alias      Markise Kinder
   genericDeviceType blind
   homebridgeMapping CurrentPosition=dim::position,invert=1,minValue=0,maxValue=100 TargetPosition=dim::position,invert=1,minValue=0,maxValue=100,minStep=10
   room       Homekit,tahoma
   userReadings position {ReadingsNum($name,'state',100)}
   webCmd     dim


kann jemand helfen?

danke und grüße

[mike3436]

Hallo Leute,

ich habe das Modul überarbeitet und mit Versionsnummer 0207 eingecheckt.
Es kann dann über Update aktualisiert werden.

Neue Features sind:

• attibut blocking 1 muss nicht mehr verwendet werden, aber die jetzt implementierte Asynchronität von Abfrage und Antwort führt trotzdem manchmal zum Blockieren
• attribut levelInvert 1 führt zum invertieren der RollerShutter Position
• Alle gemeldeten Stati werden jetzt als Reading aufgeführt.

LG Rolf