IO-Homecontrol Devices über Tahoma Box einbinden

[enno]

Moin zusammen,

welche Funktion hat das Attribut Interval im Modul? Ich habe es auf 1200 gesetzt aber keine Änderung im Verhalten der Rollobedienung bemerkt.

Code Auswählen Erweitern

Internals:
   BLOCKING   0
   Clients    :tahoma:
   DEF        ACCOUNT crypt:[...] crypt:[...]
   HTTPCookies JSESSIONID=A2766761A24014DD860093B691DBFEF6
   INTERVAL   1200
   NAME       TAHOMA
   NR         293
   NTFY_ORDER 50-TAHOMA
   STATE      Connected
   SUBTYPE    ACCOUNT
   TYPE       tahoma
   VERSION    0216

[pc1246]

Hallo Enno
Habe mal die nicht intuitive, aber gut funktionierende Suche, wenn man weiss wie es geht, des Forums verwendet.
https://forum.fhem.de/index.php/topic,28045.msg568908.html#msg568908
Da hat Mike es beschrieben!
Gruss aus dem verschneiten Braunschweig
Christoph

[mike3436]

Hallo Enno,

abweichend vom Protokoll der Tahoma Apps habe ich einen zyklischen Refresh der Stati aller Geräte im Modul eingebaut. Dies war früher fest alle 300s und ich habe es ab v0212 parametrierbar über das Attribut INTERVAL gemacht (0=deaktiviert). Gund war nur eine höhere Kompatibilität zur App zu erreichen, und so ggf. Probleme zu vermeiden - hat aber nichts spürbares verbessert. Ich habe aber im abgeschalteten Zustand bei mir schon das Problem gehabt, dass die angezeigten Rolladenpositionen nicht mit der Wirklichkeit übereinstimmten. Erst nach der nächsten Neupositionierung stimmte dann wieder alles. Von daher würde ich empfehlen, das Interval wieder zu aktivieren, aber nicht unter 300s zu setzen.

Generell gibt es immer Verbindungsabbrüche zum Server in unregelmässigen Abständen. Ich habe mal eine Auswertung darüber gefahren, und versucht, ein Muster zu erkennen, aber da ist nichts. Manchmal läuft das Tahoma Modul bzw. die Verbindung zum Server tagelang ohne Störung, manchmal gibt es mehrere Verbindungsabbrüche pro Tag, und ganz selten (bei Updates) ist der Server manchmal stundenlang nicht erreichbar.

Gruß Rolf

[enno]

Moin Rolf,

danke für die ausführliche Erklärung. Ich werde den Interval mal auf 3600 setzen. 

Gruss
  Enno

[Jack_n]

Hallo Rolf,

ich würde gerne einzelne Rollladendevices per notify disabeln wenn der Fensterkontakt am betroffenen Fenster den Status offen hat.

So wie es aussieht hat das disable aber keine Auswirkung, ich kann das Rollladendevice dennoch ansprechen.

Wird disable von FHEM gesteuert oder aus dem Modul ?

Schöne Ostern
Joachim

[droehn]

Hallo Rolf,

Erstmal feines Modul, vielen Dank Ich hänge mich mal an die ursprüngliche Frage von Enno an:

über ein Packet Capture auf der Firewall habe ich gesehen, dass das Modul alle 2 Sekunde 10 Anfragen an 178.32.15.131:443 abschiesst (und ebenso viele Antworten erhält). Ich glaube, das ist abhängig von der Anzahl der betriebenen Komponenten (in meinem Fall 4 => 2 Velux Fenster mit Rollläden).
Wenn man im FHEM Web Interface auf dem Connexoon Device mehrfach hintereinander refreshed, ändert sich die request_time in den Internals laufend im ca-2-Sekunden-Schritt. Das Setzen von Interval hat darauf keinen Einfluss - ich habe es auf allen Komponenten gesetzt, es wird trotzdem alle 2 Sekunden gefeuert.

Wenn ich das Connexoon Device auf disabled setze, dann ist (natürlich) Ruhe. Entferne ich das disabled Attribut, bleibt das Device stehen. Erst wenn ich die DEF öffne und auf modify klicke geht's wieder weiter. Das zuvor gesetzte Interval Attribut 300 wird dann in den Internals auf 0 gesetzt, obwohl im Attribut immer noch 300 steht. Ach ja, man kann interval nicht kleiner als 300 setzen. Gibt man was anderes ein, dann kommt die Meldung, dass der Interval auf 300 gesetzt wurde. Edit: hast Du ja oben beschrieben.
Grösser geht. Aber, wie gesagt, hat es offenbar keinen Einfluss auf die Frequenz der Requests.

Ist das alles so gewollt oder sind das Bugs? Ich habe - wie Enno - auch den Verdacht, dass durch die vielen Requests die übrige Performance leidet; bei mir lag heute das Netzwerk platt und es lief erst wieder, nachdem ich die FHEM Box abgeknipst habe.

Grüsse
Der Dröhn

[mike3436]

Hallo Dröhn,

ich habe bei mir nochmal den Datenverkehr mitgeschrieben, und es ist so dass nur alle 2s ein Event-Request an den Server geschickt wird. Dies wird einmal pro Modul-Instanz 'ACCOUNT' gemacht, wobei ich noch nie probiert habe, zwei oder mehr Instanzen anzulegen. Dieser 2s Takt kann ich natürlich parametrierbar machen, ist aber an die originale App angelehnt, und macht bei mir keinerlei Schwierigkeiten.

Was mir aufgefallen ist, dass jetzt pro Request immer eine neue HTTPS-Verbindung aufgebaut wird, und nach Erhalt der Daten wieder abgebaut wird. Dies ist natürlich unnötiger Overhead, den man (ich) abstellen sollte. Ich verwende hier das globale FHEM Modul HttpUtils und ich meine, das war früher anders, kann mich aber täuschen. Eigentlich sollte die https-Verbindung aufrecht gehalten werden, so dass der zyklische Datenverkehr nur aus einem Request und dem Response bestehen würde.

Ich analysiere das weiter, kann aber etwas dauern ...

Gruß Rolf

[droehn]

Hallo Rolf,

ich bin mir jetzt auch nicht mehr so sicher, ob mein Netzwerk wirklich durch Dein TAHOMA Modul gelitten hat - hab später noch andere Fehlerquellen in den Switches gefunden.
Jedenfalls, wenn es Dir was hilft, anbei ein Auszug meines Netzwerkverkehrs. Es sind alle 2 Sekunden 13 Aufrufe und 11 Responses:

• 192.168.6.11 ist meine FHEM Box
• 157.161.9.6 ist die Adresse von RIPE
• 178.32.15.131 gehört zu tahomalink

Code Auswählen Erweitern

19:51:07.741564 IP 192.168.6.11.51042 > 157.161.9.6.53: UDP, length 36
19:51:07.751745 IP 157.161.9.6.53 > 192.168.6.11.51042: UDP, length 157
19:51:07.753171 IP 192.168.6.11.58780 > 178.32.15.131.443: tcp 0
19:51:07.779942 IP 178.32.15.131.443 > 192.168.6.11.58780: tcp 0
19:51:07.780486 IP 192.168.6.11.58780 > 178.32.15.131.443: tcp 0
19:51:07.785410 IP 192.168.6.11.58780 > 178.32.15.131.443: tcp 189
19:51:07.811114 IP 178.32.15.131.443 > 192.168.6.11.58780: tcp 0
19:51:07.811988 IP 178.32.15.131.443 > 192.168.6.11.58780: tcp 1460
19:51:07.812231 IP 178.32.15.131.443 > 192.168.6.11.58780: tcp 1460
19:51:07.812503 IP 178.32.15.131.443 > 192.168.6.11.58780: tcp 1176
19:51:07.812636 IP 192.168.6.11.58780 > 178.32.15.131.443: tcp 0
19:51:07.812756 IP 192.168.6.11.58780 > 178.32.15.131.443: tcp 0
19:51:07.812984 IP 178.32.15.131.443 > 192.168.6.11.58780: tcp 1460
19:51:07.813020 IP 178.32.15.131.443 > 192.168.6.11.58780: tcp 169
19:51:07.813047 IP 192.168.6.11.58780 > 178.32.15.131.443: tcp 0
19:51:07.813442 IP 192.168.6.11.58780 > 178.32.15.131.443: tcp 0
19:51:07.813607 IP 192.168.6.11.58780 > 178.32.15.131.443: tcp 0
19:51:07.832469 IP 192.168.6.11.58780 > 178.32.15.131.443: tcp 126
19:51:07.855263 IP 178.32.15.131.443 > 192.168.6.11.58780: tcp 274
19:51:07.858137 IP 192.168.6.11.58780 > 178.32.15.131.443: tcp 283
19:51:07.882072 IP 178.32.15.131.443 > 192.168.6.11.58780: tcp 285
19:51:07.882115 IP 178.32.15.131.443 > 192.168.6.11.58780: tcp 31
19:51:07.883945 IP 192.168.6.11.58780 > 178.32.15.131.443: tcp 0
19:51:07.886300 IP 192.168.6.11.58780 > 178.32.15.131.443: tcp 0
19:51:07.919980 IP 178.32.15.131.443 > 192.168.6.11.58780: tcp 0
19:51:07.920449 IP 192.168.6.11.58780 > 178.32.15.131.443: tcp 0


Folgende tahoma Devices sind auf meiner FHEM Installation vorhanden:

• Tahoma Account
• Pod Box
• Dachfenster 1
• Rolladen 1
• Dachfenster 2
• Rolladen 2
• room All House

Grüsse
Der Dröhn

[odie13690]

Hallo zusammen,

Somfy will ja gern, dass alle ihre TaHoma(V1)-Box durch die aktuelle Version (V2) ersetzen. Ein entsprechendes Angebot haben wohl alle TaHoma(V1)-Nutzer erhalten.

Wenn ich es richtig verstanden habe, kommuniziert das FHEM-TaHomaModul direkt mit dem Server von Somfy. Daher dürfte es egal sein, welche TaHoma-Box lokal im Einsatz ist.

Kann ich also problemlos von V1 auf V2 wechseln und meine Somfy-Produkte weiter wie gewohnt über FHEM bedienen?

odie13690

[mike3436]

Hallo odie13690,
ich gehe davon aus, dass das Modul mit der Tahoma Box V2 zusammenarbeitet, da es auch mit der Connexxon zusammenarbeitet.
Ansonsten hätten schon Leute hier Fragen in dieser Hinsicht gestellt.
Aber wenn deine Box läuft, was erhoffst du dir mehr von der V2?

[odie13690]

Hallo Mike,
erhoffen nichts. Aber wie das immer so ist. Der Hersteller stellt die Weiterentwicklung ein und reduziert den Support auf das erforderliche Minimum. Das neue Modell bringt zukünftig vielleicht Neues, für mich Imteressantes, mit? Bin noch mit mir am hadern. Trotz großem Rabatt ist die neue Box noch immer teuer...

odie13690

[OpenSourceFan]

Hallo zusammen,

hat sich denn hier schon einmal jemand mit dem Somfy-Kalender beschäftigt? Das tahoma-Modul stellt ja die Befehle activateCalendar, deactivateCalendar und setCalendar bereit. Den Somfy-Kalender nutze ich z.Z. um damit meine Raffstore zeitgesteuert zu öffnen und zu schliessen, auch abhängig vom Sonnenauf- bzw. untergang. Nachdem ich nun Fhem über dieses Modul mit dem Somfyserver gekoppelt habe, könnte man dies freilich auch über einen Kalender in Fhem realisieren. Sobald aber die Internetverbindung einmal nicht steht, oder der Somfyserver Schluckauf hat, fürchte ich, das dann keine Befehle ausgeführt werden können und auch nicht zu einem späteren Zeitpunkt nachgeholt werden. Aus diesem Grund würde ich lieber die Kalenderprogrammierung im Somfy-Interface durchführen, auch wenn dies gelinde gesagt ein Graus ist.
<OT an> Warum unterscheiden sich eigentlich die Bedienkonzepte und der Funktionsumfang zwischen dem Somfy-Web-Interface und der Androidapp?  <OT aus>
Was ich also erreichen möchte: einen Kalender aus Fhem mit dem Somfy-Kalender zu synchronisieren, mindestens aber von Fhem aus EInträge in dem Somfy-Kalender zu schreiben. Hat das bereits jemand erfolgreich versucht?

Gruß Uwe

[mike3436]

Hallo Uwe,

ich habe mir den Kalender schon früher mal angeschaut, fand aber die Verwaltung in FHEM nicht sinnvoll. Ein grafisches Interface hierfür zu bauen, ist nicht meins! Und dem User die Tage in Textform aufzulisten und anzupassen, das macht wohl auch keinen Spass.

Der Kalender basiert auf Tagesabläufen. Diese Tagesabläufe müssen erst mal aus Szenen und ggf. Einzelkommandos (aufwändig) zusammengestellt werden.
Im Kalender können jetzt diese Tagesabläufe eingetragen werden. Dabei gibt es die Wochentagsmaske und den von...bis Bereich.

Man könnte jetzt über FHEM den aktuellen (oder beliebigen) Tag auf einen bestimmten Tagesablauf setzen - das wäre nicht so schwierig.
Dazu müsste ich die aktuellen Tagesabläufe in die FHEM Defines aufnehmen - nicht editierbar / einsehbar, aber am Namen identifizierbar.
Ob das auf Dauer gut geht, weis ich nicht: mein Kalender beinhaltet aktuell ca. 20 Eintäge, darin sind Einträge von 2017 und 2018.
Ich weis nicht ob der Server den Kalender aufräumt, d.h. die schon vergangenen Tage löscht, gleiche Tage zusammenfasst.

Der Aufwand für das ganze ist jedoch recht groß, und ich weis nicht ob sich das lohnt?
Für Mithilfe und andere Ideen bin ich offen.
Wer in seinem Modul 26_tahoma.pm in startup_pages die auskommentierten Zeilen getCalendarDayList und getCalendarRuleList aktiviert, der bekommt ab loglevel 4 die Tagesabläufe und Kalender aufgelistet.

Gruß Rolf

[mike3436]

@Jack_n
ich habe die 'disable' Funktion integriert.
Man kann die einzelnen tahoma DEVICE's disablen und sie werden dann weder direkt, noch über ROOM's oder GROUP's angesteuert.
Werden, sie innerhalb einer SCENE verwendet, dann wirkt das disable nicht!
Die Typen SCENE, GROUP und ROOM können auch mit disable versehen werden, und die direkte Ansteuerung dieses Typs wird dann abenfalls unterbunden.

Gruß Rolf

[mike3436]

@droehn
Das Problem mit dem überhöhten Datentransfer habe ich behoben.
Die TCP/IP-verbindung wurde nach jedem Aufruf automatisch geschlossen, da das nötige keepalive von mir nicht korrekt programmiert wurde.
Jetzt bleibt die Verbindung bestehen, solange der Server es zulässt (ca. 100s bzw. 50 getEvent-Aufrufe).
Die Änderung wurde als Version 0218 ins Subversion eingecheckt und kann von dort runtergeladen werden, bzw. wird dann morgen über 'Update' aktiv.

Gruß Rolf