IO-Homecontrol Devices über Tahoma Box einbinden

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

Vorheriges Thema - Nächstes Thema

scooty

Vielen Dank,

"levelInvert" funktioniert wie gewünscht.
Auch die zusätzlichen Readings sind sehr angenehm.

Viele Grüße,
Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH1080 / IO Homecontrol

scooty

#121
Hallo Rolf,

habe leider noch ab und zu ein "Extrem-Blocking" ;):
2016.11.18 09:43:18.411 1: Perfmon: possible freeze starting at 09:43:17, delay is 1.411
2016.11.18 09:57:41.260 1: Perfmon: possible freeze starting at 09:43:28, delay is 853.26
2016.11.18 09:57:41.515 2: DG_TAHOMA01: tahoma_dispatch http request failed: Unauthorized
2016.11.18 09:57:41.567 2: DG_TAHOMA01: tahoma_dispatch http request failed: Unauthorized
...
2016.11.18 09:25:43.631 1: Perfmon: possible freeze starting at 09:25:41, delay is 2.63
2016.11.18 09:42:45.766 1: Perfmon: possible freeze starting at 09:26:00, delay is 1005.766
2016.11.18 09:42:46.053 2: DG_TAHOMA01: tahoma_dispatch http request failed: Unauthorized
2016.11.18 09:42:46.114 2: DG_TAHOMA01: tahoma_dispatch http request failed: Unauthorized
...
2016.11.22 11:24:30.459 3: DG_TAHOMA01: tahoma_refreshAllStates tahoma_getStates took 752.829074859619 ms
2016.11.22 11:24:35.401 3: DG_TAHOMA01: tahoma_getEvents took 597.220897674561 ms
2016.11.22 11:45:59.687 1: Perfmon: possible freeze starting at 11:29:08, delay is 1011.687
2016.11.22 11:46:00.016 2: DG_TAHOMA01: tahoma_dispatch http request failed: Unauthorized
2016.11.22 11:46:00.068 2: DG_TAHOMA01: tahoma_dispatch http request failed: Unauthorized
...

2016.11.23 12:00:00.115 3: ZWave set HZKG_WWZP on
2016.11.23 12:17:44.362 1: Perfmon: possible freeze starting at 12:01:14, delay is 990.361
2016.11.23 12:17:44.629 2: DG_TAHOMA01: tahoma_dispatch http request failed: Unauthorized
2016.11.23 12:17:44.688 2: DG_TAHOMA01: tahoma_dispatch http request failed: Unauthorized
...
2016.11.23 12:44:00.071 3: ZWave set HZKG_WWZP off
2016.11.23 13:03:03.717 2: DG_TAHOMA01: tahoma_dispatch http request failed: Unauthorized
2016.11.23 13:03:03.763 2: DG_TAHOMA01: tahoma_dispatch http request failed: Unauthorized
2016.11.23 13:03:03.764 1: Perfmon: possible freeze starting at 12:46:12, delay is 1011.764

Im Einsatz ist bei mir die wohl neueste Version
26_tahoma.pm 12591 2016-11-15 21:25:45Z mike3436
Attribut "blocking" ist bei mir nirgendwo gesetzt.

Kannst Du da noch 'was machen?

Vielen Dank und Grüße,
Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH1080 / IO Homecontrol

mike3436

Hallo Andreas,

ich werde das Modul wohl von der perl LWP::UserAgent auf die von Rudi entworfene httpUtil Library umstellen, mit der Hoffnung, das damit die Blockierer verschwinden.
Damit erlicht aber die Benutzung des Atttributs PROXY, welches von der httpUtil Library nicht unterstützt wird.
Das eigentliche Problem, die schlechte Erreichbarkeit bzw. Reaktion des somfy Servers wird damit wohl nicht verschwinden.

Falls ein anderer Entwickler das hier vielleicht mitließt:
macht das überhaupt Sinn, oder ist die in httpUtil verwendete Library IO::Socket::INET ebenfalls von Hängern im TCP-Stream betroffen?

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

scooty

Hallo Rolf,

vielen Dank für Deine Antwort.
Uih, das hört sich nach viel Aufwand an, umso dankbarer wäre ich, wenn Du das wirklich umsetzt.
Für Tests stehe ich natürlich gerne  zur Verfügung.

Bevor Du etwas machst, eine kurze Frage: Wie kann es denn überhaupt zu "Unauthorized" kommen?
Die Login-Informationen werden ja nicht geändert und sind in FHEM gespeichert.
Liegt das auch an der üblen Verfügbarkeit der somfy Server oder lohnt es sich eher, nach den Gründen für "Unauthorized" zu forschen, statt die Umstellung auf httpUtil anzugehen?

Viele Grüße,
Andreas

PS: Auf das Attribut "proxy" kann ich persönlich verzichten, habe es nämlich gar nicht im Einsatz.  ;)
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH1080 / IO Homecontrol

rudolfkoenig

Zitatmacht das überhaupt Sinn, oder ist die in httpUtil verwendete Library IO::Socket::INET ebenfalls von Hängern im TCP-Stream betroffen?

HttpNonblockingGet sollte kaum noch Haenger aufweisen, mit "attr global dnsServer" kann man sogar das DNS-Lookup auf nichtblockierend umstellen. Wenn doch ein Haenger auftritt, bitte melden :)

Proxy geht auch, wenn man ein transparentes proxy verwendet.

mike3436

#125
ZitatWie kann es denn überhaupt zu "Unauthorized" kommen?
Beim Login wird ein Cookie geliefert und dieses wird dann mit jedem Command gesendet.
Bricht die Verbindung ab, dann ist das Cookie veraltet und man muss ein neues Login starten.
Bei mir im Log taucht das "Unauthorized" bisher auch nicht auf.

Vielleicht ist die Ursache auch wirklich eine andere:
Die Meldung kann nach aktueller Analyse nur bei einem Blocking Request auftreten.
Wenn du das Attribut BLOCKING=0 gesetzt hast, dann wird dies nur noch beim GetDevices ausgeführt, das man über die FHEM Oberfläche auf dem tahoma ACCOUNT absetzen kann.
Eventuell auch von aussen getriggert.
KNX Hausautomatisierung, RPi mit FHEM, Jeelink + LaCrosse, HM_LAN + KeyMatic, Somfy IO Rollladen mit Tahoma und KLF200, Buderus WPS mit USBTin und KM200

Stril

Hallo!

Bei mir sieht es leider auch so aus, dass trotz "nonblocking" FHEM blockiert. Perfmon zeigt aktuell alle 2 Minuten zuverlässig einen Freeze von 4,5s.
Das Ganze sieht im Log dann so aus:


2016.11.24 11:32:28 4: tahoma1: refreshing event
2016.11.24 11:32:28 4: tahoma1: tahoma_getEvents
2016.11.24 11:32:28 5: tahoma1: tahoma_UserAgent_NonblockingGet page=getEvents

2016.11.24 11:32:33 4: tahoma1: tahoma_dispatch page=getEvents dataLen=2 dataLenTotal=2
2016.11.24 11:32:33 5: tahoma1: tahoma_dispatch data=[]
2016.11.24 11:32:33 5: tahoma1: tahoma_parseGetEvent
2016.11.24 11:32:33 3: tahoma1: tahoma_getEvents took 5225.50177574158 ms

2016.11.24 11:32:33 1: Perfmon: possible freeze starting at 11:32:29, delay is 4.604


Hat von euch schon jemand versucht, das Tahoma-Modul mit FHEM2FHEM in eine eigene Instanz auszulagern?

Bisher habe ich das Ganze leider noch nicht hinbekommen, aber eigentlich sollte das ja funktionieren und die Latenz wäre dann egal, oder?

Grüße
Phil

mike3436

Hallo Phil,

Irgendwie kommt mir das Log merkwürdig vor.
Das Attribut BLOCKING=0 muss explizit gesetzt werden, sonst wird weiter blockierend gearbeitet, und das sieht für mich so aus.

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

Stril

Hallo!

Das habe ich dann wohl falsch gemacht. Ich dachte, es reicht, "Blocking=1" herauszunehmen.

Ich beobachte jetzt mal, wie es läuft.

Vielen Dank

Grüße

Stril

Hallo!

Hatte mich zu früh gefreut. Gerade gab es wieder einen Freeze.

blocking=0

...und das Log:


2016.11.24 13:46:11 4: tahoma1: refreshing event
2016.11.24 13:46:11 4: tahoma1: tahoma_getEvents
2016.11.24 13:46:11 5: tahoma1: tahoma_UserAgent_NonblockingGet page=getEvents
2016.11.24 13:46:17 4: tahoma1: tahoma_dispatch page=getEvents dataLen=2 dataLenTotal=2
2016.11.24 13:46:17 5: tahoma1: tahoma_dispatch data=[]
2016.11.24 13:46:17 5: tahoma1: tahoma_parseGetEvent
2016.11.24 13:46:17 3: tahoma1: tahoma_getEvents took 5239.58301544189 ms
2016.11.24 13:46:17 1: Perfmon: possible freeze starting at 13:46:12, delay is 5.06


Hast Du dazu noch eine Idee?

Grüße
Phil

mike3436

Hallo Phil,

also bei mir kommen seit der Umstellung auf NONBLOCKING auch vereinzelt Meldungen - so 5 mal pro Tag.
Ich hatte dafür extra die Meldung tahoma_xxx took n ms eingefügt, die ab 500ms aktiviert wird.
Was bei dir die Ursache häufiger Blockierungen ist, kann ich auch nicht sagen.
Ich werde wie gesagt das Modul auf httpUtil umstellen, und hoffe, dass damit das Problem verschwindet.

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

Hallo,

ich habe eine neue Version V208 im 1. Beitrag angehängt.
Diese ist auf HttpUtils umgebaut und läuft bei mir stabil - aber erst seit heute.
Die Blockierungen sind bei mir jetzt verschwunden.

Bei der Umstellung ist bei mir auch das Umlautproblem aufgetreten, d.h. wenn der originale Name Umlaute beinhaltete, dann waren diese Devices nicht mehr steuerbar.
Die Funktion HttpUtil_NonBlockingGet leitet das Kommando dann nicht durch und liefert in einen Fehler zurück.
Dieses Problem wurde behoben (automatisches Ersetzen der Umlaute 'ÄÖÜäöüß' durch 'Ae oe ue ae oe ue ss').

Bitte mal testen und ggf. Probleme melden, bevor ich das fürs automatische update einchecke.

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

Stril

#132
Hallo!

Ich habe die neue Version eingespielt und teste jetzt mal.
Erste Rückmeldung:

Ich bekomme alle paar Sekunden folgende Meldung:


2016.11.28 10:41:04 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/26_tahoma.pm line 1210.
2016.11.28 10:41:04 1: stacktrace:
2016.11.28 10:41:04 1:     main::__ANON__                      called by ./FHEM/26_tahoma.pm (1210)
2016.11.28 10:41:04 1:     main::tahoma_UserAgent_NonblockingGet called by ./FHEM/26_tahoma.pm (312)
2016.11.28 10:41:04 1:     main::tahoma_getEvents              called by ./FHEM/26_tahoma.pm (361)
2016.11.28 10:41:04 1:     main::tahoma_readStatusTimer        called by fhem.pl (2866)
2016.11.28 10:41:04 1:     main::HandleTimeout                 called by fhem.pl (604)
2016.11.28 10:41:05 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/HttpUtils.pm line 372.
2016.11.28 10:41:05 1: stacktrace:
2016.11.28 10:41:05 1:     main::__ANON__                      called by FHEM/HttpUtils.pm (369)
2016.11.28 10:41:05 1:     main::HttpUtils_Connect2            called by FHEM/HttpUtils.pm (277)
2016.11.28 10:41:05 1:     main::__ANON__                      called by fhem.pl (679)
2016.11.28 10:41:06 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/26_tahoma.pm line 1210.
2016.11.28 10:41:06 1: stacktrace:
2016.11.28 10:41:06 1:     main::__ANON__                      called by ./FHEM/26_tahoma.pm (1210)
2016.11.28 10:41:06 1:     main::tahoma_UserAgent_NonblockingGet called by ./FHEM/26_tahoma.pm (312)
2016.11.28 10:41:06 1:     main::tahoma_getEvents              called by ./FHEM/26_tahoma.pm (361)
2016.11.28 10:41:06 1:     main::tahoma_readStatusTimer        called by fhem.pl (2866)
2016.11.28 10:41:06 1:     main::HandleTimeout                 called by fhem.pl (604)
2016.11.28 10:41:07 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/HttpUtils.pm line 372.
2016.11.28 10:41:07 1: stacktrace:
2016.11.28 10:41:07 1:     main::__ANON__                      called by FHEM/HttpUtils.pm (369)
2016.11.28 10:41:07 1:     main::HttpUtils_Connect2            called by FHEM/HttpUtils.pm (277)
2016.11.28 10:41:07 1:     main::__ANON__                      called by fhem.pl (679)



Die Freezes scheinen auch noch da zu sein:

2016.11.28 10:42:13 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/26_tahoma.pm line 1210.
2016.11.28 10:42:13 1: stacktrace:
2016.11.28 10:42:13 1:     main::__ANON__                      called by ./FHEM/26_tahoma.pm (1210)
2016.11.28 10:42:13 1:     main::tahoma_UserAgent_NonblockingGet called by ./FHEM/26_tahoma.pm (312)
2016.11.28 10:42:13 1:     main::tahoma_getEvents              called by ./FHEM/26_tahoma.pm (361)
2016.11.28 10:42:13 1:     main::tahoma_readStatusTimer        called by fhem.pl (2866)
2016.11.28 10:42:13 1:     main::HandleTimeout                 called by fhem.pl (604)
2016.11.28 10:42:13 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/HttpUtils.pm line 372.
2016.11.28 10:42:13 1: stacktrace:
2016.11.28 10:42:13 1:     main::__ANON__                      called by FHEM/HttpUtils.pm (369)
2016.11.28 10:42:13 1:     main::HttpUtils_Connect2            called by FHEM/HttpUtils.pm (277)
2016.11.28 10:42:13 1:     main::__ANON__                      called by fhem.pl (679)

2016.11.28 10:42:17 1: Perfmon: possible freeze starting at 10:42:15, delay is 2.137
[code]



mike3436

Hallo Phil,

ich habe nochmal ein Update der V0208 hochgeladen.
Die erste Warn-Meldung '26_tahoma.pm line 1210' ist erklärbar, und habe ich abgestellt.
Die erste Warn-Meldung 'HttpUtils.pm line 372' ist nicht ganz erklärbar, habe aber versucht, etwas zu ändern.

generell kommen bei mir die Warnungen nicht, aber das kann auch an den Umgebungseinstellungen liegen.
Auf was für einem System läuft das bei dir, und welche Perl Version hast du?

Und zum Blocker vventuell den Tipp von Rudi mal testen:
"attr global dnsServer"

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

Stril

#134
Hallo!

Aktuell nutze ich Ubuntu 14.05.5 LTS auf einem Intel NUC mit Perl 5.18.2

Die neue Version teste ich gleich. Die Perfmon-Meldungen scheinen übrigens gar nicht vom Tahoma-Modul gekommen zu sein. Tut mir Leid, wenn ich Dich auf eine falsche Fährte gebracht haben sollte.
Es muss etwas anderes sein...

Grüße
Phil