Modul für ENIGMA2 Receiver

[Loredo]

Ich habe jetzt eine finale Version des Moduls eingecheckt, gibts dann morgen per Update Funktion für alle.

Wenn ich den Timestamp mit localtime() auswerte, ist das Ergebnis eine Stunde zu spät. In Zeile 1814 ziehst Du die Stunde auch ab ($t[2] -1). Warum ist das so? Liegt das am Receiver?

Ich weiß es nicht.

Was ist in der Sommerzeit?

Handhabt localtime() automatisch, dafür ist es da.

[karl0123]

Ich komme nochmal zurück auf das hier schonmal kurz diskutierte Problem mit dem Befehl PAUSE. Dieser funktioniert weder auf meiner 7020HD (OE2.0 original Image), noch auf meiner VUSolo (OE1.6 VTI Image) oder auf meiner neuen 7080HD (OE2.2 Merlin Image).

Das gleiche gilt auch für den Befehl PLAY. Die Boxen zeigen jeweils das Symbol für einen nicht funktionierenden Befehl, in dem Moment, wenn man einen der Befehle sendet.

[Simon74]

Soeben Play und Pause per Enigma-Modul auf einer ET9200 getestet, funktioniert hier einwandfrei.

[karl0123]

Ist es eigentlich gewollte, dass die Kapazität einer Festplatte ggf. in unterschiedlichen Einheiten angegeben wird? Eine 2TB Festplatte hat bspw. den Wert hdd2_capacity = 2. Eine 120 GB Festplatte am gleichen Receiver hat den Wert hdd1_capacity = 120. Ist das bei den Restwerten auch so? Dann ist das nicht wirklich vergleichbar bzw. sogar unbrauchbar.

[Loredo]

Die Werte werden so übernommen, wie sie die Enigma2 API liefert. Scheint als tue sie das nicht konsistent. Das müsstest du dem Enigma2 Team melden.

[Simon74]

Loredo, ein Problem gibts bei mir mit dem "input".
Dieser switcht bei jedem Abfrageintervall zwischen "tv" und "radio".
Ich vermute das mein Multibouquet das Problem ist.. ?

[Loredo]

Hm, das würde bedeuten, dass deine Box im Ergebnis von "getcurrent" bei jeder Abfrage einen anderen Wert für "servicereference" liefert.
Da kann ich so nicht wirklich viel ausrichten, denn es geht darum, dass die Box das aktuelle Programm über "getcurrent" liefert.
Du kannst aber vielleicht mal einen Mitschnitt des Logfiles mit gesetzten verbose=5 schicken. Vielleicht kann ich eine Abnormität erkennen. Denke aber es ist ein Fehler in der Box bzw. im Image.

[Simon74]

Hallo Loredo,

Hab nun den Status der Box beobachtet, ist ein akutelles openPLI.
Das Box WebIF liefert immer dasselbe beim betrachten von http://box-ip/web/getcurrent.

das würde bedeuten, dass deine Box im Ergebnis von "getcurrent" bei jeder Abfrage einen anderen Wert für "servicereference" liefert.

Also nein

Auch die Readings im Modul "servicename" und "servicereference" ändern sich nicht jedoch das Reading "input" (bei jeder Abfrage je nach eingestellter Intervallzeit).
Aufgefallen ist mir das ganze weil ich das Reading "input" für notifys verwenden wollte und mich wunderte warum da falsche Aktionen ausgeführt werden..

[Loredo]

Auch die Readings im Modul "servicename" und "servicereference" ändern sich nicht jedoch das Reading "input" (bei jeder Abfrage je nach eingestellter Intervallzeit).
Aufgefallen ist mir das ganze weil ich das Reading "input" für notifys verwenden wollte und mich wunderte warum da falsche Aktionen ausgeführt werden..

Das ist extrem seltsam, denn die Ableitung des Readings "input" erfolgt immer nach dem selben Schema. Dass sich dabei die anderen Readings nicht ändern sollen, kann ich nicht glauben. Denn sie dienen eindeutig als Eingangsgröße, um den input-Wert zu ermitteln (siehe https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/70_ENIGMA2.pm#l1576).
Es tut mir leid, aber ich weiß nicht, wo ich hier ansetzen sollte etwas zu beheben.

[UlfS]

Hallo Ihr,

kann es sein, dass es beim neuen Modul ein Problem gibt. Ich bin offensichtlich nicht der einzige User, dem das Logfile zugemüllt wird, das Enigma-Modul jede Menge Ports öffnet und FHEMWeb komplett lahmlegt.

Siehe http://forum.fhem.de/index.php/topic,30008.0.html

Ich habe bei mir das Enigma-Modul vorübergehend deaktivieren müssen, das Logfile des aktuellen Monats zu öffnen brauche ich (per Web) gar nicht probieren (per SSH und cat gehts natürlich).

Es kommen tausende von Zeilen im Log mit dem Vermerk "Accept failed (WEB: Too many open files)". Wenn man die offenen Dateien mit lsof -p ansieht, merkt man, dass das Enigma-Modul zig Verbindungen auf unterschiedlichen Ports mit dem Vermerk "close_wait" offen hält.

Passiert bei unterschiedlicher Hardware (siehe Link oben), bei mir läuft das auf einem RaspBerry B+, die Fehler sind erst seit einem Update vor ein paar Tagen aufgetaucht. Seit dem Deaktivieren des Enigma-Moduls ist wieder alles Ok.

Danke Euch, wenn ich helfen kann gerne, bezeichne mich aber als Anfänger (wobei ich mit FHEM schon einiges geschafft habe: diverse Homematic, Enigma, Sat, Stereo, Sonos, Presence per FritzBox, Automatisches Gartenwasser und Waschmaschinen-Benachrichtigung, Security-Status von Türen/Fenstern per Offen-Kontakt in Kombi mit Griffstatus).

Lg, Ulf

[Loredo]

Mir ist jetzt persönlich nichts bekannt.
Da das Modul für die Kommunikation auf die von FHEM bereitgestellten Funktionen HttpUtils zurück greift, dürfte hier etwas im Argen liegen. Mir ist aber auch da aktuell kein generelles Problem größerer Natur bekannt.


Edit: Was ihr aber probieren könnt ist, mit den angebotenen Attributen https=0 und http-method=POST/GET zu spielen. Grundsätzlich hatte Rudi schon einmal angemerkt, dass einige Dreamboxen/Images sich nicht dem HTTP Standard nach verhalten und offene Verbindungen eben nicht richtig schließen. Das führt dann insbesondere auf kleinen Maschinen, auf denen FHEM läuft, zu Schwierigkeiten. Bisher wurden die HttpUtils diesbezüglich von Rudi nicht optimiert/verbessert.

[justme1968]

ich verwende das enigma modul nicht, hatte aber mit der neuen version des hue moduls das auch httputils verwendet bis jetzt genau ein mal das gleiche problem.

ich vermute das es irgend eine art des verbindungsabruch gibt bei dem das socket auf fhem seite nicht geschlossen wird.

der einzige weg das genauer einzugrenzen ist erst mal rauszufinden wodurch es genau getigert wird.

gruss
  andre

[Loredo]

Ich find's jetzt nicht Adhoc hier im Forum, aber Rudi vertrat/vertritt die Meinung, dass er eine Verbindung nur schließen muss, wenn der Server ein ordnungsgemäßes http-close im Header mitschickt (lt HTTP Standard Spezifikation). Daher wollte er keine Fehlertoleranz in HttpUtils einbauen, weil er die Ansicht vertritt, dass auf Seiten der Server (sprich in diesem Fall Enigma2 Geräte oder eben der Hue Bridge) sichergestellt werden müsse, dass man sich dort an den HTTP Standard hielte.


Als Workaround fällt mir aktuell nur ein, dass man einen HAproxy als Reverse-Proxy dazwischen bauen kann. Der kann ein http-close forcieren, sofern es fehlt und macht dann FHEM/HttpUtils glücklich. Ist aber nur eine Theorie.


Weshalb es hauptsächlich bei kleinen/schwachen FHEM Maschinen auftaucht, könnte dann auch noch hiermit zusammen hängen:
http://stackoverflow.com/questions/410616/increasing-the-maximum-number-of-tcp-ip-connections-in-linux
http://serverfault.com/questions/10852/what-limits-the-maximum-number-of-connections-on-a-linux-server


Meine Vermutung ist, dass der Netzwerk-Stack bei einer leistungsfähigeren Maschine anders konfiguriert ist und entsprechend besser mit den gleichzeitigen Verbindungen umgehen kann bzw. die selbstständig(er) und rechtzeitig(er) schließt und somit die http-close Geschichte bei diesen Geräten dann nicht zum Tragen kommt.

[justme1968]

ich erinnere mich an die diskussion.

da ging es zum einen um das noshutdown im request. das lässt sich ja inzwischen setzen und zum anderen um das mit senden des close connection. das wird inzwischen gesetzt wenn die http version auf != 1.0 gesetzt ist.

ich glaube aber das beides nicht das problem ist. im normalfall funktioniert es mit der hue bridge ja. das socket wird in den httputils ja nach dem empfang der antwort und im fehlerfall mit close zu gemacht.

ich meine CLOSE_WAIT bedeutet das die fhem seite das socket nicht zu macht obwohl die gegenseite schon zu gemacht hat.

es muss irgend ein seltsamer zustand aufgetreten können bei dem diese close nicht durchlaufen werden.

[Loredo]

da ging es zum einen um das noshutdown im request. das lässt sich ja inzwischen setzen und zum anderen um das mit senden des close connection. das wird inzwischen gesetzt wenn die http version auf != 1.0 gesetzt ist.

Ja. Mit beiden Parametern hatte ich seinerzeit experimentiert. Es brachte jedoch keine Verbesserung. Letztlich bin ich bei explizitem noshutdown=1 und implizitem httpversion=1.0 geblieben.

Das einzige, was ich herausgefunden hatte im Bezug auf die Enigma2 Boxen war, dass einige sich unterschiedlich verhalten, je nachdem ob man ihnen die Daten per POST oder GET zuschiebt. Insbesondere macht es aber einen Unterschied, ob FHEM auf einer Fritzbox oder einem normalen x86 Rechner lief. Da ich hier kein wirklich nachvollziehbares Verhalten ableiten konnte, hatte ich eben das Attribut http-method für das Enigma2-Modul eingebaut, damit man es ggf. beeinflussen kann. Default ist GET, aber manchmal hilft eben POST je nach Server/Client Kombination. Auf einer Fritzbox wird automatisch POST verwendet (siehe https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/70_ENIGMA2.pm#l769).