IO-Homecontrol Devices über Tahoma Box einbinden

Begonnen von mike3436, 17 Oktober 2014, 22:07:36

Vorheriges Thema - Nächstes Thema

mike3436

Hallo Rippi,
ich habe mich mal vor längerem damit beschäftigt, bin aber mangels Dokumentation auch nicht zum Ergebnis gekommen.
Wahrscheinlich geht das, aber über eine andere, nicht öffentlich dokumentierte API.
Mit dem Set&Go Adapter geht das wohl, denn der ist für den Installateur gedacht.
Bei mir sind Rolladen Kabel glücklicherweise immer zu einer Steckdose geführt und dort an 230v geklemmt, und man kann sie hier trennen.
Meistens sind die aber in einer Unterputzdose auf 230V geklemmt.
Gruß Rolf
KNX Hausautomatisierung, RPi mit FHEM, Jeelink + LaCrosse, HM_LAN + KeyMatic, Somfy IO Rollladen mit Tahoma und KLF200, Buderus WPS mit USBTin und KM200

mike3436

Wenn ich mir die aktuell möglichen Kommandos des Device RollerShutter anschaue, dann haben sich diese erweitert. Ich weis aber nicht, ob diese bei der Tahoma und Connexoon identisch sind.
dim:slider,0,1,100 cancel:noArg advancedRefresh close:noArg delayedStopIdentify down:noArg getName:noArg identify:noArg my:noArg open:noArg refreshMemorized1Position:noArg setClosure setDeployment setMemorized1Position setName setPosition setSecuredPosition startIdentify:noArg stop:noArg stopIdentify:noArg up:noArg wink runManufacturerSettingsCommand keepOneWayControllersAndDeleteNode:noArg pairOneWayController sendIOKey:noArg setConfigState unpairAllOneWayControllersAndDeleteNode:noArg unpairAllOneWayControllers:noArg unpairOneWayController
Alle Befehle ohne ":noArg" benötigen mindestens einen weiteren Parameter, der mir aber erst mal nicht bekannt ist. Wenn der Befehl mehrere Parameter benötigt, so ist das Modul dafür nicht ausgelegt.
Wenn man sich das Login mit "verbose 4" anschaut, dann haben folgende Befehle 2 Parameter:
runManufacturerSettingsCommand
pairOneWayController
unpairOneWayController
KNX Hausautomatisierung, RPi mit FHEM, Jeelink + LaCrosse, HM_LAN + KeyMatic, Somfy IO Rollladen mit Tahoma und KLF200, Buderus WPS mit USBTin und KM200

rippi46

Hallo Mike3435,

Danke für deine Antwort. Leider habe ich das Problem, das die beiden Markisen an einer Stelle, die sehr schlecht zugänglich ist, elektrisch verbunden sind.
Deswegen wäre es schön, wenn man mit einem der vorhandenen Befehle die Markise in den Lernmodus versetzen könnte.

Die von dir genannten Befehle wären vermutlich das was man dafür verwenden könnte, wenn man die Parameter kennen würde.

Habe aber in der Zwischenzeit mein Problem gelöst.

Lösung:
ZitatSobald sich der Motor im Programmiermodus befinden muss die neue Fernbedienung angelernt werden. Das passiert meist durch einen kurzen Druck auf die "Prog"-Taste der neuen Fernbedienung. In dem Moment sendet die neue Fernbedienung ihren Schlüssel an alle Motoren, die sich im Programmiermodus befinden und die Motoren speichern den Schlüssen ein. Die Motoren bestätigen das mit einer kurzen Auf/Ab Bewegung.

Es ist also nicht die Fernbedienung die entscheidet welchen Motor sie steuert, sondern die Motoren entscheiden von welcher Fernbedienung (Schlüssel) sie sich steuern lassen.
Das Löschen einer Fernbedienung funktioniert auf dem identischen Weg, denn die Motoren verfolgen die Logik: Wenn ich den Schlüssel schon kenne, lösche ich ihn.

Da man eine Fernbedienung nur mit einer 2. Fernbedienung löschen kann (mit der 1. Fernbedienung versetzt man die Markise in den Lernmodus und und bei der 2. Fernbedienung drückt man kurz die Prog-Taste. Ist der Code vorhanden wird er gelöscht, ist er nicht vorhanden wird er aufgenommen) , war ich der Meinung, das es nur funktioniert wenn ich sie stromlos mache.

Zum Glück habe ich die Situo 5 io von Somfy die fünf Kanäle hat und jeder Kanal stellt eine "eigene" Fernbedienung dar. So konnte ich mit dem einen Kanal auf dem nur eine Markise bedient wurde, die Markise in den Lernmodus versetzen, und anschließend auf den 2. Kanal wechseln auf dem beide Markisen programmiert waren und dort dann kurz die Prog-Taste drücken um die 1. Markise zu löschen.

Hört sich kompliziert an aber es hat funktioniert.

Danke

Gruß rippi
FHEM, LMS, VDR ,Dell 9010 Ubuntu 20.04,Raspimatic, HM/HMIP, Max, Elro, Brennenstuhl u. Intertechno mit Connair.
Picoreplayer, Raspi IR-Lanadapter, Firmata(wifi), LaCrosse,
nanocul433, nanocul868, Signalduino, Connexoon,
MySensor-GW+Sensoren, RGBWW, Zigbee2mqtt,Xiaomi,Nextion,LEDMatrix,Alexa

tek

nutzt hier jemand evohome Stellantriebe? Wenn ich diese über FHEM oder Tahoma ansteuere habe ich immer ein "PeriodicOverride"  im Reading RAMSESSetPointOverrideModeState. Somit wird die Temperatureiinstellung automatisch nach einer Zeit überschrieben. Über den Befehl setSetpointOverride PermanentOverride bekomm ich immer ein "tahoma_dispatch error: Invalid JSON format or type in request body". Sieht für mich eher nach einem Tahoma problem aus? Hat da jemand ne Idee? Hab hierzu auch mal ein Ticket bei Somfy direkt eröffnet.

5hockwave

Hallo,
ich habe harmony und tahoma erfolgreich bei Fhem integriert und kann nun aus FHEM und auch aus FTUI den Fernseher einschalten und Rollos herunter fahren.
Aber wie kann ich mit der Harmony ein IO Plug an- oder ausschalten? Wo und wie muss ich die Verbindung herstellen?
Kann mir das jemand für doofe erklären?

Danke euch.

tek

#605
Zitat von: tek am 22 Oktober 2021, 20:53:57
nutzt hier jemand evohome Stellantriebe? Wenn ich diese über FHEM oder Tahoma ansteuere habe ich immer ein "PeriodicOverride"  im Reading RAMSESSetPointOverrideModeState. Somit wird die Temperatureiinstellung automatisch nach einer Zeit überschrieben. Über den Befehl setSetpointOverride PermanentOverride bekomm ich immer ein "tahoma_dispatch error: Invalid JSON format or type in request body". Sieht für mich eher nach einem Tahoma problem aus? Hat da jemand ne Idee? Hab hierzu auch mal ein Ticket bei Somfy direkt eröffnet.

Evohome sagt Sonfy ist schuld und Somfy sagt Evohome ist schuld... Beide werben mit Kompatibilität, liefern aber Schrott... Der Kunde ist mal wieder der Dumme...

tek

hab jetzt Stellantriebe von Somfy verbaut und mit der neuen Tahoma Switch verbunden. Es läuft auch alles wie es soll, aber die Stellantriebe lassen sich aus FHEM heraus nicht steuern... jemand Erfahrung damit?

Det20

Hallo,

seit einigen Tagen funktioniert das Tahoma Modul nicht mehr korrekt. Wenn ich FHEM frisch starte, dann funktioniert es (set ... down). Läuft FHEM aber einige Stunden und ich versuche es abends, dann geht es plötzlich nicht mehr. Das Log ist nicht auffällig:


2022.01.08 18:08:12 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/26_tahoma.pm line 1478.
2022.01.08 18:09:50 1: PERL WARNING: Use of uninitialized value $attrVal in concatenation (.) or string at ./FHEM/26_tahoma.pm line 1576.
2022.01.08 18:12:57 5: tahoma1: tahoma_UserAgent_NonblockingGet page=exec/apply
2022.01.08 18:12:57 5: tahoma1: tahoma_GetCookies looking for Cookies in header


Danach kommt nix mehr.

Das Geräte-Listing:


Internals:
   BLOCKING   0
   Clients    :tahoma:
   DEF        ACCOUNT xxx
   FUUID      5c434f53-f33f-4070-3f3b-62f8a62d99a8b9a4
   HTTPCookies JSESSIONID=5EE87D1D1883B89D017F6CB5A6DAE08C
   NAME       tahoma1
   NR         114
   NTFY_ORDER 50-tahoma1
   STATE      Connected
   SUBTYPE    ACCOUNT
   TYPE       tahoma
   VERSION    0223
   eventId    xxx
   gatewayId  xxx
   getEventsInterval 2
   getEventsTimer 1641616348
   getLoginIntervalMax 160
   getLoginIntervalMin 5
   getStatesInterval 0
   getStatesTimer 1641612155
   inGateway  0203-4680-5049
   inVersion 
   lastError  Not authenticated
   logged_in  0
   loginRetryTimer 5
   refreshStatesInterval 120
   refreshStatesTimer 1641616371
   request_active 0
   request_time 1641661977.72818
   socket     
   startup_done 1
   startup_run 7
   timeout    10
   url        https://www.tahomalink.com/enduser-mobile-web/enduserAPI/
   userAgent  TaHoma/10287 CFNetwork/901.1 Darwin/17.6.0
   HTTPCookieHash:
     JSESSIONID:
       Options    Path=/enduser-mobile-web; Secure; HttpOnly; SameSite=None
       Value      5EE87D1D1883B89D017F6CB5A6DAE08C
   helper:
     password   xxx
     username   xxx
     devices:
       HASH(0x69c3bc0)
       HASH(0x69ab3c0)
       HASH(0x69de148)
       HASH(0x69d36d0)
       HASH(0x6a17248)
       HASH(0x69dff78)
       HASH(0x6624650)
       HASH(0x6a1cc40)
       HASH(0x6a05ea8)
       HASH(0x69d6560)
       HASH(0x1fe3308)
       HASH(0x2131d00)
       HASH(0x66e6700)
       HASH(0x66e63e8)
       HASH(0x492a9b0)
       HASH(0x69d3e80)
       HASH(0x69f9210)
       HASH(0x68b0e80)
       HASH(0x69a1568)
       HASH(0x6a1fb30)
       HASH(0x66427f0)
       HASH(0x69fc130)
       HASH(0x50cbd10)
       HASH(0x69fbbf0)
       HASH(0x680bc48)
       HASH(0x67bd038)
       HASH(0x664d458)
       HASH(0x6879d70)
       HASH(0x6706520)
       HASH(0x687aaa8)
       HASH(0x6726778)
       HASH(0x6726148)
       HASH(0x687ac10)
       HASH(0x667f5e0)
       HASH(0x6680b78)
   paramHash:
     NAME       
     addr       https://www.tahomalink.com:443
     auth       0
     buf       
     code       401
     compress   1
     data       {"label":"EG Esszimmer - down  - iphone","actions":[{"deviceURL":"rts://0203-4680-5049/16751133","commands":[{"name":"down","parameters":[]}]}]}
     displayurl https://www.tahomalink.com/enduser-mobile-web/enduserAPI/exec/apply
     errno      101
     header     Content-Type: application/json
User-Agent: TaHoma/10287 CFNetwork/901.1 Darwin/17.6.0
Cookie: JSESSIONID=5EE87D1D1883B89D017F6CB5A6DAE08C
     host       www.tahomalink.com
     httpheader HTTP/1.1 401
Date: Sat, 08 Jan 2022 17:12:57 GMT
Server: overkiz
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Length: 66
Keep-Alive: timeout=5, max=50
Connection: Keep-Alive
     hu_blocking 0
     hu_filecount 1
     hu_port    443
     hu_portSfx
     hu_sslAdded 1
     keepalive  1
     loglevel   4
     nonblocking 1
     noshutdown 1
     page       exec/apply
     path       /enduser-mobile-web/enduserAPI/exec/apply
     protocol   https
     redirects  0
     timeout    10
     url        https://www.tahomalink.com/enduser-mobile-web/enduserAPI/exec/apply
     hash:
       COMMANDS   dim:slider,0,1,100 cancel:noArg close down identify:noArg my open rest stop test:noArg up openConfiguration
       DEF        DEVICE rts://0203-4680-5049/16751133
       FUUID      5c434f53-f33f-4070-42d6-bee41bfe0b615f7f
       IODev      tahoma1
       NAME       EG.Jalousien.Esszimmer
       NR         135
       NTFY_ORDER 50-EG.Jalousien.Esszimmer
       STATE      RTS
       SUBTYPE    DEVICE
       TYPE       tahoma
       device     rts://0203-4680-5049/16751133
       fid        16751133
       inClass    RollerShutter
       inControllable rts:RollerShutterRTSComponent
       inLabel    EG Esszimmer
       inPlaceOID f44a0645-ae92-4bee-9bb4-f0f676318086
       inType     1
       READINGS:
         2022-01-08 02:20:38   IODev           tahoma1
     sslargs:
   refresh_event:
Attributes:
   disable    0
   room       ...
   verbose    5


Bin ich der einzige oder hat sich da was geändert, zB der Agent?

mike3436

Hallo Det,
ich kann bei mir keine Auffälligkeiten entdecken, d.h. alles funktioniert normal.
Änderungen habe ich auch schon lange nicht mehr gemacht.

Du hast mit "verbose 5" aufgezeichnet, und die Ausgabe "tahoma1: tahoma_GetCookies looking for Cookies in header" ist wirklich die letzte tahoma1 Ausgabe!?
Dann müste das Programm während des logins  in dieser Routine hängenbleiben - warum auch immer.
Diesen Programmteil habe ich auch nur aus einem anderen FHEM Modul übernommen, und das hat bisher immer problemlos gearbeitet.
Du könntest mal die Routine tahoma_GetCookies um die nachfolgende 2. Log-Zeile erweitern, um dem Problem auf die Spur zu kommen.
    Log3 $name, 5, "$name: tahoma_GetCookies looking for Cookies in header";
    Log3 $name, 5, "$name: tahoma_GetCookies header=$header";
KNX Hausautomatisierung, RPi mit FHEM, Jeelink + LaCrosse, HM_LAN + KeyMatic, Somfy IO Rollladen mit Tahoma und KLF200, Buderus WPS mit USBTin und KM200

Det20

#609
Habe es fast jeden Tag. Hier das Ergebnis im Log:


2022.01.11 10:34:50 5: tahoma1: tahoma_GetCookies looking for Cookies in header
2022.01.11 10:34:50 5: tahoma1: tahoma_GetCookies header=HTTP/1.1 401
Date: Tue, 11 Jan 2022 09:34:50 GMT
Server: overkiz
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Length: 66
Keep-Alive: timeout=5, max=50
Connection: Keep-Alive


Was mich wundert ist der 401. Habe nun einen weiteren Set hinzugefügt, "connect":


  if( $hash->{SUBTYPE} eq "ACCOUNT") {
    $list = "cancel:noArg reset:noArg connect:noArg refreshAllStates:noArg getStates:noArg";

    if( $cmd eq "cancel" ) {
      tahoma_cancelExecutions($hash);
      return undef;
    }
    elsif ( $cmd eq "reset" ) {
      HttpUtils_Close($hash);
      $hash->{logged_in} = undef;
      $hash->{loginRetryTimer} = undef;
     
      return undef;
    }
    elsif( $cmd eq "connect" ) {
      HttpUtils_Close($hash);
      tahoma_connect($hash);
      return undef;
    }
    elsif( $cmd eq "refreshAllStates" ) {
      tahoma_refreshAllStates($hash);
      return undef;
    }
    elsif( $cmd eq "getStates" ) {
      tahoma_getStates($hash);
      return undef;
    }
  }


Nachdem ich dann "set ... connect" gemacht habe, ging es. Irgendwo verliert er unterwegs die Verbindung und weiss es nicht.

mike3436

Die http Antwort schein mir auch suspect - passt nicht zum login.

Es könnte sein, das aus irgend einem Grund der Timer aussetzt.
Der würde mit dem 'tahoma_connect' wieder aktiviert.
Die einzige 'RemoveInternalTimer($hash)' function, die mir suspect erscheint ist beim Attribut 'disable'
Ich kann mich nicht mehr erinnern warum das hier so gecoded ist, und es macht aus meiner sicht hier keinen Sinn.
Kommentiere das mal aus:

} elsif( $attrName eq "disable" ) {
    my $hash = $defs{$name};
    # RemoveInternalTimer($hash);
    if( $cmd eq "set" && $attrVal ne "0" ) {
    } else {
      $attr{$name}{$attrName} = 0;
    }
  } elsif( $attrName eq "blocking" ) {
KNX Hausautomatisierung, RPi mit FHEM, Jeelink + LaCrosse, HM_LAN + KeyMatic, Somfy IO Rollladen mit Tahoma und KLF200, Buderus WPS mit USBTin und KM200

Det20

Versuche ich mal. Ich disable tahoma über Nacht, nachdem ich dort einige Login Probleme hatte. Neu ist hier auch, dass ich als INet Provider nun Starlink nutze. Da ich dort noch optimiere (Fritzbox hinter SL-Router oder Dishy), haue ich ab und an mal die Internet Verbindung weg. Da ich Repeater-hinter-Repeater nutzen muss, ist das auch nicht so 100% stabil. Könnte auch daran liegen.

Det20

Sieht gut aus, damit funktioniert es bei mir nach einem Tag immer noch. Denke, kannst du einchecken. Kannst du mir einen Gefallen tun und die "set ... login" so oder vielleicht als "set ... reconnect" drin lassen? Falls es nicht mehr klappt, hätte ich einen Workaround und muss das Modul nicht extra vom Update excluden.

VG

mike3436

Neues Modul version 225 eingechecked.
Änderungen:

  • Befehl 'disconnect' schliesst Verbindung zum Server
  • Befehl 'reconnect' schliesst Verbindung zum Server und öffnet sie wieder
  • nur bei Tahoma ACCOUNT schliesst attr disabled die Verbindung und bei entferntem attr disabled wird die Verbindung wieder aufgebaut
  • Unterbinden von Steuerungsbefehlen, wenn Tahoma ACCOUNT disabled oder not logged_in

KNX Hausautomatisierung, RPi mit FHEM, Jeelink + LaCrosse, HM_LAN + KeyMatic, Somfy IO Rollladen mit Tahoma und KLF200, Buderus WPS mit USBTin und KM200

Det20