IO-Homecontrol Devices über Tahoma Box einbinden

mike3436 · 22 Juni 2016, 13:18:52

ZitatDanke für die Antwort. Ich frage mich nur, was sich geändert hat. Irgendwie blockiert das System jetzt eben auch "spürbar".

Sie mal in deinen PN nach!
Hast 'update' ausgeführt?
Welche Version verwendest du?

Bei mir reagiert das Modul nach wie vor normal schnell.

Stril · 22 Juni 2016, 16:17:01

Hallo!

Ich habe ein Update gemacht!
Aktuelle Tahoma-Version:
# $Id: 26_tahoma.pm 11684 2016-06-17 21:56:55Z mike3436 $

Ich habe keine Ahnung, was sich geändert hat...

Grüße
Phil

mike3436 · 22 Juni 2016, 23:25:51

Hallo Phil,

log mal mit 'verbose 3', dann werden alle nicht zyklischen Abfragen, sowie Fehler geloggt.
Vielleicht kommen wir so deinem problem auf die Spur.

Gruß Rolf

Stril · 23 Juni 2016, 10:50:15

Hallo!

Das habe ich gemacht - auch mit verbose 5.
Fehler gab es aber keine. Es wurde mir folgendes geloggt und dann kam die Pause:

Code Auswählen


2016.06.22 08:51:03 4: tahoma1: tahoma_login
login start
2016.06.22 08:51:03 5: tahoma_UserAgent_NonblockingGet page=login

Gruß
Phil

mike3436 · 23 Juni 2016, 16:54:38

ZitatFehler gab es aber keine. Es wurde mir folgendes geloggt und dann kam die Pause:

Wie lang war die pause?
Und fing dann das Login wieder von vorne an, ohne weitere Meldung?
Interessant sind oft auch die Meldungen davor und danach, um Rückschlüsse auf eine Ursache zu finden!
Und warum wird der Login gemacht - die Verbindung muss ja dann vorher abgebrochen sein.
Geht zu diesem Zeitpunkt die App auf deinem Pad?

Stril · 26 Juni 2016, 01:18:06

Hallo!

Sorry wegen der späten Antwort. Ich hatte auch wirklich etwas im Log übersehen:

Code Auswählen


2016.06.22 08:51:03 4: tahoma1: refreshing event
2016.06.22 08:51:03 4: tahoma1: tahoma_getEvents
2016.06.22 08:51:03 4: tahoma1: tahoma_login
login start
2016.06.22 08:51:03 5: tahoma_UserAgent_NonblockingGet page=login
2016.06.22 08:53:10 2: tahoma1: http request failed: Can't connect to www.tahomalink.com:443 (Die Wartezeit für die Verbindung ist abgelaufen)

--> Irgendwie scheint es ein Problem beim Connect zu geben und dann ist FHEM blockiert...

Siehst Du eine Möglichkeit, dass FHEM nicht blockiert wird, wenn z.B. die Internetverbindung einmal "wackelt"?

Gruß
Phil

mike3436 · 27 Juni 2016, 16:46:01

ZitatSiehst Du eine Möglichkeit, dass FHEM nicht blockiert wird, wenn z.B. die Internetverbindung einmal "wackelt"?

Eigentlich gibt es die Option schon:
wenn du das Attribut Blocking=0 setzt, dann werden nur noch wenige Serverzugriffe blockierend ausgeführt.
Leider ist das Login immer blockierend.
Ich werde das mal umschreiben, bzw. parametrierbar machen ...

Stril · 27 Juni 2016, 22:31:25

Hallo!
Hat das "nicht Blockieren" denn einen Nachteil?

Es wäre wirklich toll, wenn auch der Login ohne Lock laufen würde.

Grüße
Phil

mike3436 · 28 Juni 2016, 20:38:09

ZitatHat das "nicht Blockieren" denn einen Nachteil?

Nein, hat es (aus Anwendersicht) nicht , aber die Programmierung der Moduls ist aufwendiger und weniger gut testbar.
Aber bei dem jetzigen Stand gibt es wenig Unbekanntes, und so kann ich den Schritt einmal wagen.
Ich habe schon angefangen, aber das ganze dauert etwas ...
Und da das Modul jetzt im FHEM SVN liegt, muss die Veröffentlichung fehlerfrei über die Bühne gehen

@Alle
Ich benötige noch Infos über die verwendeten Devices (nur Rolladen?).
Die werden aus dem Setup gelesen, und das steht ab "VERBOSE 3" im FHEM.log
Daraus werden die Aliasnamen generiert, aber ich habe nur "RollerShutter", die Box alis "Pod" , und eine Fernbedienung habe ich als "RemoteController" angemeldet.
Ich benötige die Information von "controllableName" und zugehörige "uiClass".
Grund ist, dass bei der Gruppensteuerung über PLACE nicht alle Devices gesteuert werden sollen.
Aktuell funktioniert bei mir z.B. die Steuerung "ganzes Haus" nicht, weil das Device Pod auch positioniert wird, was zu einer Fehlermeldung seitens des Servers führt.
Ich könnte das jetzt auf RollerShutter limitieren, weis aber nicht ob das andere Stören würde!?

Schon bekannte Devices:

Code Auswählen


"controllableName" : "internal:PodComponent"
"uiClass":"Pod"

"controllableName":"io:RollerShutterGenericIOComponent"
"uiClass":"RollerShutter"

"controllableName" : "rts:RollerShutterRTSComponent"
"uiClass":"RollerShutter"

"controllableName":"io:IORemoteController"
"uiClass":"RemoteController"

Gruß Rolf

MaxAut · 28 Juni 2016, 20:46:51

Ich verwende Fenster, Rolladen und Markisen. Liebe Grüße, Max

Stril · 29 Juni 2016, 09:06:29

Hallo!

Ich habe auch nur "RollerShutter", "Pod" und eben die Räume.

Gruß
Phil

MaxAut · 29 Juni 2016, 09:25:45

Ich bin mir nicht ganz sicher welche Bezeichnung Du brauchst ... ich schicke Dir mal das inControllable Reading von den drei Typen die ich habe - hilft das?

Das ist die Markise (außen)
inControllable io:VerticalExteriorAwningIOComponent

Das ist die Rollo (innen)
inControllable io:VerticalInteriorBlindVeluxIOComponent

Und hier das Fenster:
inControllable io:WindowOpenerVeluxIOComponent

Wo ich die uiClass auslesen kann habe ich nicht gefunden ...

Liebe Grüße,
Max

MaxAut · 30 Juni 2016, 21:41:38

Ich habe ein neues Problem: Die Steuerung funktioniert nicht mehr, und im Log ist folgende Fehlermeldung zu sehen:

Code Auswählen

AAAtahoma1: tahoma_dispatch json string is faulty

Irgendwelche Ideen?

mike3436 · 30 Juni 2016, 22:23:30

ZitatAAAtahoma1: tahoma_dispatch json string is faulty

Dies kommt bei mir nur, wenn ich das zugehörige blocking attribut auf 0 gsetzt habe (ich arbeite ja gerade am nonblocking mode)

Code Auswählen

attr AAAtahoma1 blocking 1

wenn das aber bei dir korrekt gesetzt ist, dann brauche ich das log mit mindestens verbose 3 (gezippt per e-mail, bei PN kann man ja nichts anhängen)

Ich hatte heute auch öfter die Meldung

Code Auswählen

tahoma1: http request failed: Server closed connection without sending any data back

... und gestern auch - daneben auch mal öfter

Code Auswählen

tahoma1: http request failed: Can't connect to www.tahomalink.com:443
was aber wohl an meiner Internet Verbindung lag

mike3436 · 30 Juni 2016, 23:53:39

Analyse des FHEM.log ...
Ich bin erst mal beruhigt, das der Fehler 'json string is faulty' durch blocking 0 hervorgerufen wurde. Das Problem dabei ist, dass ich nicht die Ganze Antwort auf einmal bekomme, sondern nur Häppchen, die dann zusammengesetzt werden müssen, und ich nicht weis, wann das letzte Häppchen kommt, aber das wird noch ...

Dein Problem scheint aber wieder das alte zu sein: Du versuchst 13 PLACES gleichzeitig anzusteuern, und dann lehnt der Server das ab dem 11. Aufruf ab!

Code Auswählen


2016.06.30 23:02:55 3: tahoma_applyRequest data={"label":"KuecheMarkisen - Positionieren auf 100 %
2016.06.30 23:03:12 3: tahoma_applyRequest data={"label":"VorzimmerFenster - Positionieren auf 94 %
...
2016.06.30 23:03:17 3: tahoma_applyRequest data={"label":"EssenMarkisen - Positionieren auf 0 %
2016.06.30 23:03:17 3: tahoma_applyRequest data={"label":"CouchHintenMarkisen - Positionieren auf 0 %
2016.06.30 23:03:17 2: AAAtahoma1: http request failed: Bad Request

Das tahoma-Modul reagiert dann auf die "Bad Request" Antwort mit einem erneuten Login.

Die denke hier schon über eine Erweiterung nach:
1. Ich könnte eine Verzögerung einbauen und erst mal sammeln und dann einen Aufruf absetzen
2. Ich könnte die Möglichkeit eigener Gruppendefinitionen vorsehen, so dass Devices auch in mehreren Gruppen vorkommen können
3. Ich könnte die Möglichkeit von DIM auf dem Tahoma Device vorsehen, bei dem mehrere Devices mit Kennung oder Definition als Parameter übergeben werden
4. Ich könnte die Befehle queuen und erst absetzen, wenn der vorherige Befehl abgearbeitet wurde