70_VIERA.PM - Perfmon: possible freeze starting at ... , delay is 1.096

[mircoby]

Hallo,

ich beobachte folgendes Verhalten in Zusammenhang mit dem VIERA Modul.

Solange der Panasonic TV eingeschaltet ist (per Netzwerk erreichbar) funktioniert alles wie erwartet. Nach dem Ausschalten erhalte ich im Rhytmus der Viera Status Abfrage (120 Sekunden) logeinträge vom Perfmon mit dem Eintrag "Perfmon: possible freeze starting at ... , delay is 1.096".

Hier meine Konfiguration:

Code Auswählen Erweitern


define WzTV VIERA 192.168.10.50 120
attr WzTV event-on-change-reading state


So sieht das entsprechende Log mit verbose 5 aus:

2015.06.20 18:32:13 1: Perfmon: possible freeze starting at 18:32:12, delay is 1.096
2015.06.20 18:34:11 5: DEBUG: Volume with  to 192.168.10.50
2015.06.20 18:34:11 5: VIERA: Building XML SOAP (RenderingControl) for command Volume with value  to host 192.168.10.50:
POST /dmr/control_0 HTTP/1.1
Host: 192.168.10.50:55000
SOAPACTION: "urn:schemas-upnp-org:service:RenderingControl:1#GetVolume"
Content-Type: text/xml; charset="utf-8"
Content-Length: 379

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<u:GetVolume xmlns:u="urn:schemas-upnp-org:service:RenderingControl:1">
<InstanceID>0</InstanceID>
<Channel>Master</Channel>
<DesiredVolume></DesiredVolume>
</u:GetVolume>
</s:Body>
</s:Envelope>

2015.06.20 18:34:13 4: VIERA: GetStatusVol-Request NO SOCKET!
2015.06.20 18:34:13 1: Perfmon: possible freeze starting at 18:34:12, delay is 1.095
2015.06.20 18:36:11 5: DEBUG: Volume with  to 192.168.10.50
2015.06.20 18:36:11 5: VIERA: Building XML SOAP (RenderingControl) for command Volume with value  to host 192.168.10.50:
POST /dmr/control_0 HTTP/1.1
Host: 192.168.10.50:55000
SOAPACTION: "urn:schemas-upnp-org:service:RenderingControl:1#GetVolume"
Content-Type: text/xml; charset="utf-8"
Content-Length: 379

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<u:GetVolume xmlns:u="urn:schemas-upnp-org:service:RenderingControl:1">
<InstanceID>0</InstanceID>
<Channel>Master</Channel>
<DesiredVolume></DesiredVolume>
</u:GetVolume>
</s:Body>
</s:Envelope>

2015.06.20 18:36:13 4: VIERA: GetStatusVol-Request NO SOCKET!
2015.06.20 18:36:13 1: Perfmon: possible freeze starting at 18:36:12, delay is 1.094
2015.06.20 18:38:11 5: DEBUG: Volume with  to 192.168.10.50
2015.06.20 18:38:11 5: VIERA: Building XML SOAP (RenderingControl) for command Volume with value  to host 192.168.10.50:
POST /dmr/control_0 HTTP/1.1
Host: 192.168.10.50:55000
SOAPACTION: "urn:schemas-upnp-org:service:RenderingControl:1#GetVolume"
Content-Type: text/xml; charset="utf-8"
Content-Length: 379

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<u:GetVolume xmlns:u="urn:schemas-upnp-org:service:RenderingControl:1">
<InstanceID>0</InstanceID>
<Channel>Master</Channel>
<DesiredVolume></DesiredVolume>
</u:GetVolume>
</s:Body>
</s:Envelope>

2015.06.20 18:38:13 4: VIERA: GetStatusVol-Request NO SOCKET!
2015.06.20 18:38:13 1: Perfmon: possible freeze starting at 18:38:12, delay is 1.096
2015.06.20 18:40:11 5: DEBUG: Volume with  to 192.168.10.50
2015.06.20 18:40:11 5: VIERA: Building XML SOAP (RenderingControl) for command Volume with value  to host 192.168.10.50:
POST /dmr/control_0 HTTP/1.1
Host: 192.168.10.50:55000
SOAPACTION: "urn:schemas-upnp-org:service:RenderingControl:1#GetVolume"
Content-Type: text/xml; charset="utf-8"
Content-Length: 379

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<u:GetVolume xmlns:u="urn:schemas-upnp-org:service:RenderingControl:1">
<InstanceID>0</InstanceID>
<Channel>Master</Channel>
<DesiredVolume></DesiredVolume>
</u:GetVolume>
</s:Body>
</s:Envelope>

2015.06.20 18:40:13 4: VIERA: GetStatusVol-Request NO SOCKET!
2015.06.20 18:40:13 1: Perfmon: possible freeze starting at 18:40:12, delay is 1.096

Die Meldung sagt quasi aus, dass der TV nicht erreichbar ist (NO SOCKET). Das ist korrekt, sollte jedoch nicht zum "Hängen" des FHEM Servers führen.

Bei verbose 3 erhalte ich lediglich die Perfmon Meldungen, alle 2 Minuten:

2015.06.20 18:42:13 1: Perfmon: possible freeze starting at 18:42:12, delay is 1.087
2015.06.20 18:44:13 1: Perfmon: possible freeze starting at 18:44:12, delay is 1.085
2015.06.20 18:46:13 1: Perfmon: possible freeze starting at 18:46:12, delay is 1.087
2015.06.20 18:48:13 1: Perfmon: possible freeze starting at 18:48:12, delay is 1.101
2015.06.20 18:50:13 1: Perfmon: possible freeze starting at 18:50:12, delay is 1.101
2015.06.20 18:52:13 1: Perfmon: possible freeze starting at 18:52:12, delay is 1.089

Bei deaktiviertem Viera Modul ist das Logfile sauber.

Meine Frage ist nun ob dieses Verhalten bekannt ist und ob es ggf eine Einstellung (timeout?) gibt, welche dieses Problem beseitigt.

Vielen Dank für Eure Hilfe.

Schöne Grüße
Mirko

[TeeVau]

Hi, das Modul ist blockig, das Timeout für die socketverbindung liegt bei 2 Sekunden.
Ich bin gerade dabei das Modul aus non blocking umzustellen. Dafür brauche ich aber noch ein paar Tage aus privaten Gründen.
Es ist jedoch in Arbeit. Wenn du magst kannst du versuche. Das Timeout im sourcecode auf 1 Sekunde zu stellen. Ob es was bringt kann ich nicht sagen.

Ich selber haben das viel schlimmere Problem, dass hin und wieder die read Funktion Probleme macht und das Modul in der while Schleife hängen bleibt und damit fhem total lahmlegt. Zum Glück habe nur ich das Problem

Gedulde dich bitte noch etwas. Sobald ich das Modul geändert und bei mir getestet habe, stelle ich das Modul für einen vorab Test hier ins Forum.

Tobias

[mircoby]

Hallo Tobias,

danke für den Tip. Ich habe das Timeout mal auf 1 sec gestellt und werde es mal beobachten...

schönen Abend
Gruß Mirko

[tpm88]

Non Blocking wäre prima. Teste dann auch gerne.

Danke vorab
Tobias


Gesendet von iPad mit Tapatalk

[mircoby]

Hallo Tobias,

habe das timeout auf 1s über Nacht mal laufen lassen (TV aus). Grundsätzlich sind die freezes von der Anzahl her deutlich minimiert, allerdings nicht beseitigt, wie das Log zeigt:

2015.06.22 09:57:05 1: Perfmon: possible freeze starting at 09:57:04, delay is 1.002
2015.06.22 09:59:05 1: Perfmon: possible freeze starting at 09:59:04, delay is 1.005
2015.06.22 10:01:05 1: Perfmon: possible freeze starting at 10:01:04, delay is 1.007
2015.06.22 10:07:05 1: Perfmon: possible freeze starting at 10:07:04, delay is 1
2015.06.22 10:09:05 1: Perfmon: possible freeze starting at 10:09:04, delay is 1.002
2015.06.22 10:11:05 1: Perfmon: possible freeze starting at 10:11:04, delay is 1.004

Von daher würde ich ebenfalls befürworten auf non blocking umzustellen. Bis dahin werde ich das Modul wieder auskommentieren.

Freue mich auf ein Update und bin gerne bereit zu testen.

Schöne Grüße
Mirko

[TeeVau]

Code Auswählen Erweitern


                                name             function    max  count    total  average maxDly
                               wz_TV         VIERA_Define      4      1        4     4.00      0 HASH(wz_TV); wz_TV VIERA 192.168.178.31
                               wz_TV            VIERA_Get      0      6        0     0.00      0
                               wz_TV            VIERA_Set     13     13       13     1.00      0 HASH(wz_TV); wz_TV; volume; 17
                 tmr-VIERA_GetStatus      HASH(0x1f5c038)      2    153      113     0.74    146 HASH(wz_TV)


Sieht schon besser aus, oder? Das Polling wird nun mit BlockingCall ausgeführt. Die Set Befehle blockieren noch. Ich denke, dass die Probleme jedoch das Polling bereitet hat. Steuern wird man den Fernseher vermutlich nur dann wollen, wenn er auch an ist

Das Modul arbeitet direkt non blocking. Über ein Attribut "blocking" kann man noch den alten blockierenden Modus aktivieren. Für den Fall, dass es Probleme gibt.
Über eure Rückmeldung würde ich mich freuen. Hab das gerade nur kurz getestet, mit Erfolg.

Tobias

EDIT: Aktuelle Version unter http://forum.fhem.de/index.php/topic,38365.msg307353.html#msg307353

[mircoby]

Hi Tobias,

danke für das update, werde testen und berichten. Beim ersten Start erhalte ich folgende warnings:

2015.06.23 22:48:13 1: PERL WARNING: given is experimental at ./FHEM/70_VIERA.pm line 191, <$fh> line 34.
2015.06.23 22:48:13 1: PERL WARNING: when is experimental at ./FHEM/70_VIERA.pm line 192, <$fh> line 34.
2015.06.23 22:48:13 1: PERL WARNING: when is experimental at ./FHEM/70_VIERA.pm line 200, <$fh> line 34.
2015.06.23 22:48:13 1: PERL WARNING: when is experimental at ./FHEM/70_VIERA.pm line 208, <$fh> line 34.
2015.06.23 22:48:13 1: PERL WARNING: when is experimental at ./FHEM/70_VIERA.pm line 216, <$fh> line 34.
2015.06.23 22:48:13 1: PERL WARNING: when is experimental at ./FHEM/70_VIERA.pm line 224, <$fh> line 34.
2015.06.23 22:48:13 1: PERL WARNING: when is experimental at ./FHEM/70_VIERA.pm line 235, <$fh> line 34.
2015.06.23 22:48:13 1: PERL WARNING: when is experimental at ./FHEM/70_VIERA.pm line 241, <$fh> line 34.
2015.06.23 22:48:13 1: PERL WARNING: when is experimental at ./FHEM/70_VIERA.pm line 247, <$fh> line 34.
2015.06.23 22:48:13 1: PERL WARNING: when is experimental at ./FHEM/70_VIERA.pm line 265, <$fh> line 34.
2015.06.23 22:48:13 1: PERL WARNING: when is experimental at ./FHEM/70_VIERA.pm line 271, <$fh> line 34.
2015.06.23 22:48:13 1: PERL WARNING: when is experimental at ./FHEM/70_VIERA.pm line 277, <$fh> line 34.
2015.06.23 22:48:13 1: PERL WARNING: when is experimental at ./FHEM/70_VIERA.pm line 286, <$fh> line 34.
2015.06.23 22:48:13 2: VIERA: defined with host: 192.168.10.50 and interval: 120
...
2015.06.23 22:50:13 2: VIERA[NonBlocking-VIERA_GetDoIt()]: BlockingCall for WzTV start...
2015.06.23 22:52:13 2: VIERA[NonBlocking-VIERA_GetDoIt()]: BlockingCall for WzTV start...

Ich lasse es mal laufen und poste morgen das Log...

Gruß Mirko

[mircoby]

Hallo Tobias,

habe das update nun 2 Tage am laufen. Was ich beobachtet habe:

- Der TV ist ansprechbar / steuerbar
- Zyklische Meldung "2015.06.25 18:04:14 2: VIERA[NonBlocking-VIERA_GetDoIt()]: BlockingCall for WzTV start..." im Log
- zyklische Blockade / Perfmon meldung bei TV aus grundsätzlich weg
- 2 größere delays im Bereich von 20 sec. im direkten zeitlichen Zusammenhang mit dem Viera Modul. siehe Log

Auszug Log:

...
2015.06.25 18:02:14 2: VIERA[NonBlocking-VIERA_GetDoIt()]: BlockingCall for WzTV start...
2015.06.25 18:04:14 2: VIERA[NonBlocking-VIERA_GetDoIt()]: BlockingCall for WzTV start...
2015.06.25 18:06:18 1: Perfmon: possible freeze starting at 18:05:58, delay is 20.16
2015.06.25 18:06:18 2: VIERA[NonBlocking-VIERA_GetDoIt()]: BlockingCall for WzTV start...
2015.06.25 18:06:39 1: Perfmon: possible freeze starting at 18:06:19, delay is 20.477
2015.06.25 18:06:39 3: wz_Raffstore: Read callback: request type was Update,
header: HTTP/1.0 200 OK
X-Powered-By: PHP/5.3.6
Content-type: text/html
Connection: close
Date: Thu, 25 Jun 2015 16:05:36 GMT
Server: lighttpd/1.4.28, buffer empty,
Error read from http://*** timed out
2015.06.25 18:06:39 3: TempWS2300: Read callback: request type was Update,
header: HTTP/1.0 200 OK
X-Powered-By: PHP/5.3.6
Content-type: text/html
Connection: close
Date: Thu, 25 Jun 2015 16:05:40 GMT
Server: lighttpd/1.4.28, buffer empty,
Error read from http://*** timed out
2015.06.25 18:06:39 3: WindWS2300: Read callback: request type was Update,
header: HTTP/1.0 200 OK
X-Powered-By: PHP/5.3.6
Content-type: text/html
Connection: close
Date: Thu, 25 Jun 2015 16:05:36 GMT
Server: lighttpd/1.4.28, buffer empty,
Error read from http://*** timed out
2015.06.25 18:06:39 3: WindMaxWS2300: Read callback: request type was Update,
header: HTTP/1.0 200 OK
X-Powered-By: PHP/5.3.6
Content-type: text/html
Connection: close
Date: Thu, 25 Jun 2015 16:05:36 GMT
Server: lighttpd/1.4.28, buffer empty,
Error read from http://*** timed out
2015.06.25 18:08:18 2: VIERA[NonBlocking-VIERA_GetDoIt()]: BlockingCall for WzTV start...
2015.06.25 18:10:18 2: VIERA[NonBlocking-VIERA_GetDoIt()]: BlockingCall for WzTV start...
2015.06.25 18:12:18 2: VIERA[NonBlocking-VIERA_GetDoIt()]: BlockingCall for WzTV start...
...

Soweit meine Beobachtungen

Gruß Mirko

[TeeVau]

Hi Mirko,

ich bezweifle, dass das Blockieren noch vom VIERA Modul kommt. Mir selber sind auch noch Meldungen von Perfmon im Log aufgefallen. Darauf hin habe ich mal ausgeben lassen, wie lange die Funktion läuft, lediglich ein paar Millisekunden. Das lasse ich noch mal etwas laufen um sicher zu sein.
Ursächlich war die Funktion VIERA_connection() Grund des blockieren. Diese Funktion wurde durch VIERA_GetStatus() aufgerufen, und zwar nach dem eingestellten Interval (Bei mir 30 Sekunden, bei dir offensichtlich 120 Sekunden).
Das Nonblocking arbeitet nun so, dass in VIERA_GetStatus() ein Fork erstellt wird. Das heißt also die Funktion selber im Eltern-FHEM läuft lediglich ein paar Millisekunden. Die blockierende Funktion VIERA_connection() wird nun im Fork ausgeführt, behindert also das Eltern-FHEM nicht.

Die Loglevels habe ich jetzt so angepasst, dass Sie nicht mehr stören sollte. Die BlockingCall LOG Meldung war mit Level 2 ein Copy&Paste Fehler.

Du kannst die angehängte Version ja noch einmal Testen. Dann können wir vergleichen ob die Perfmon Meldung wirklich vom VIERA Modul kommt.

PS: starte doch, nachdem das Modul installiert ist, auch mal das Modul "apptime". Vielleicht helfen die Informationen davon auch. Apptime muss allerdings nach jedem FHEM start Manuell gestartet werden. einfach "apptime" in die FHEM Befehlszeile eingeben.
Tobias

EDIT: Beta entfernt, aktuelle Version wird per FHEM update verteilt.

[TeeVau]

Hi Tobias,

danke für das update, werde testen und berichten. Beim ersten Start erhalte ich folgende warnings:

Ich lasse es mal laufen und poste morgen das Log...

Gruß Mirko

Die Warnings müssten schon immer da sein. given/when verwende ich schon seit der 1. Version von dem Modul. Sollte zu vernachlässigen sein. Ich frag hier im Forum mal nach ob das ein Problem ist oder werden könnte. Kenne mich nicht gut genug mit Perl aus um zu beurteilen, ob die "experimental" Funktion vielleicht mal nicht mehr verfügbar sein könnte oder so.

[herrmannj]

perfmon kann nur als Indikator für "fhem-Blockaden" agieren.

Die beiden 20sec freeze oben sind natürlich brutal. Generell kommen aber auch andere Möglichkeiten in Betracht. Im Log siehst Du ja nur Module die da was reinschreiben.

Wenn also modul X was macht und sich im Log vereweigt, dann modul Y (notify, at, sub ...) was tut und fhem dabei 20 sec blockiert meldet perfmon nur das ein freeze gemessen wurde.

Im log kann das dann so aussehen als wäre Modul X der Verursacher weil der der letzte Eintrag eben von X kommt. Aber auchh nur weil Y nix ins log geschrieben hat. Von daher:
* perfmon ist der Indikator DAS ETWAS blockiert.
* Apptime hilft rauszufinden WER blockiert.

vg
joerg

[TeeVau]

Also die Funktionen, die FHEM blockieren können, laufen auf meinem System lediglich 1-2 ms. Die Blockaden kommen nicht vom VIERA Modul.

Joerg, kannst du mit den apptime Ausgaben etwas anfangen?
Mich macht total und maxDly etwas stutzig, bin mir aber nicht sicher, was die Werte wirklich aussagen:

Code Auswählen Erweitern

                name             function    max  count    total  average maxDly
tmr-VIERA_GetStatus      HASH(0x1c1f8a0)     17   3062     5089     1.66   2004 HASH(wz_TV)

Ich bau gerade noch die Layouts für remoteControl um. Dann gibt es auch die Farbcode Tasten und die remoteControl als SVG (Dafür muss ich noch ein paar Icons selber machen).
Leider kann man noch immer nicht den aktuellen Kanal auslesen, das ist sehr schade.

[TeeVau]

Hi Tobias,

danke für das update, werde testen und berichten. Beim ersten Start erhalte ich folgende warnings:

Ich lasse es mal laufen und poste morgen das Log...

Gruß Mirko

Kannst du mal bitte mit "perl -v" gucken welche Perl du aktuell verwendest?
Habe das given/when nun entfernt. Die Meldungen sollten dann also wegsein demnächst.

[TeeVau]

Hallo zusammen,

hiermit möchte ich die neue Version vom Modul zur Verfügung stellen. Bei mir läuft es seit ein paar Wochen stabil. Die größte Änderung ist, dass das Modul nun non Blocking arbeitet.
Weitere Änderungen:

• Layout für remotecontrol mit SVG Icons
• Layouts für remotecontrol mit Farbbuttons (rot, grün, blau, gelb)
• Eine Warnung, die bei bestimmten Perl Versionen auftreten kann, sollte nun weg sein (Warning wegen given/when)

Wenn ich nichts negatives höre, werde ich das Modul in 1 bis 2 Wochen einchecken, damit es per Update verteilt wird.
Habe zusätzlich einen Artikel im Wiki erstellt, wenn jemand noch Input dafür hat darf das gerne eingebracht werden. http://www.fhemwiki.de/wiki/VIERA

[peterchen89]

Hallo!

Danke für das tolle Modul! Habe die SVG Remotecontrol gemäß wiki angelegt (layout VIERA_TV_SVG). Leider fehlen mir noch ein paar Icons wie RC_VIERA_LINK.svg. Kannst du die vielleicht auch noch hier hochladen? Dankeschön!

Viele Grüße
Peter

[TeeVau]

Hi Peter,

Die icons habe ich ganz vergessen. Da musste ich ein paar selber generieren. Lade ich heute Abend hoch. Mit dem Update werden die natürlich dann automatisch installiert.

[TeeVau]

Im Anhang die fehlenden Icons.
Nachdem upload nicht vergessen:

Code Auswählen Erweitern

set WEB rereadicons

[peterchen89]

Danke!

[phantom]

Hallo TeeVau,

habe gerade das Modul 70_VIERA.pm inder non-blocking beta-version aus diesem Thread geladen und es funktioniert prima.  DANKE erst einmal.

Da ich mein Panasonic TV jedoch darüber nicht einschalten kann, habe ich als kleine Ergänzung das Einschalten über HDMI-CEC eingebaut. Leider bin ich nicht der Perl-Guru und recht neu bei FHEM, daher ist nur eine quick-and-dirty Lösung, siehe diff zu deinem Modul:

167c167
<   CommandAttr(undef,$name.' webCmd on:off') if( !defined( AttrVal($hash->{NAME}, "webCmd", undef)) );
---
>   CommandAttr(undef,$name.' webCmd off') if( !defined( AttrVal($hash->{NAME}, "webCmd", undef)) );
191c191
<   my $usage = "choose one of on:noArg off:noArg mute:on,off " .
---
>   my $usage = "choose one of off:noArg mute:on,off " .
198,204d197
<   # switch TV on via external command
<   if ($what eq "on"){
<     Log3 $name, 3, "VIERA: Set on via HDMI-CEC";   
<     my $ret = qx (echo "on 0" | /usr/local/bin/cec-client -s -d 1);
<     Log3 $name, 3, "VIERA: cec-client: $ret";   
<     return undef;
<   }


Dies erfordert einen laufenden cec-client; bei mir auf einem Raspberry Pi, der per HDMI am TV hängt (http://constey.de/2014/10/fernseher-ueber-hdmi-per-raspberry-pi-steuern-cec/)

Besser wäre im 70_VIERA.pm Modul aber eine allgemeinere Implementierung etwa als definierbares Attribut. Darin könnte dann jeder sein TV-On-Kommando unterbringen, ohne am Modul zu "schrauben".
Wenn du evtl. Lust und Zeit hast so etwas in der Art umzusetzen, wäre dies ein Vorschlag für eine kleine Erweiterung deines Moduls.

Gruß
Dirk

[TeeVau]

Ich schau mal nach meinem Urlaub.

[dantist]

Ich habe das Modul eben getestet, und es funktioniert wunderbar. Vielen Dank dafür! Wie ist denn der Status zur Non Blocking-Implementierung? Ich habe keine Beta installiert, nutze nur die Update-Funktion von fhem.

[TeeVau]

Ich bin etwas skeptisch mit dem einchecken. Ich bekomme ziemlich oft timeouts auf meiner FHEM Installation. Damit scheine ich generell der einzige zu sein, da zumindest sich hier im Thread niemand darüber beschwert hat bei der Vorabversion.
Ich möchte nicht ein großes Fass mit der non-blocking Implementation aufreißen und dafür verantwortlich sein, dass sich ggf. ein paar FHEM Installationen auf die Seite legen.

Meine Version des non-blocking ist eigentlich nicht ganz sauber, da alle 30 Sekunden ein neuer Fork erstellt wird. Das geht wohl ziemlich auf den Speicher und kann gerade bei kleinen Systemen mit weniger RAM Probleme machen.

[phantom]

Bei mir läuft das non-blocking-Modul aus der Beta vom Juni (s.o.).  Ich habe keine Probleme feststellen können.
Wo bzw. wie könnte ich die angesprochenen timeouts sehen?

läuft alles auf einem RasPi1B

[TeeVau]

Hi Phantom,
Hmm. Ich denke dann lade ich das mal hoch und warte ab ob meine Probleme bei anderen auftreten
Informationen zum Perfom findest du hier: http://www.fhemwiki.de/wiki/Perfmon

[peterchen89]

Wenn das Modul in der nonblocking Variante nun bei einigen stabil läuft wäre es doch mal an der Zeit es auch per Update zu verteilen, oder?

[TeeVau]

Guten Abend,

du hast vollkommen Recht. Ich habe das ziemlich schleifen gelassen. Bei mir, in der VM, läuft es noch immer mit Verbindungsabbrüchen. Aber das soll die Allgemeinheit nicht von der non Blocking Variante ausschließen

Code Auswählen Erweitern

# $Id: 70_VIERA.pm 10463 2016-01-11 18:03:07Z teevau $

Gerade frisch eingecheckt. Gibt es dann morgen mit dem fhem Update. Die notwendigen Icons sind ebenfalls enthalten und werden per Update verteilt.
Dann stimmt auch der Inhalt vom Wiki Eintrag.

Per attribut blocking kann man auch, bei Problemen, wieder auf die blocking Variante umstellen.

@Dirk
ich gucke mir mal an wie das andere Modul gelöst haben, dass durch ein fhem set Befehl system Befehle gestartet werden. Dann kommt es demnächst mit rein.


Tobias

[WolfgangV]

Hallo,

ich wollte nur mal anregen, das mit dem Hinweis auf das Attribut "blocking" ins Wiki aufzunehmen.
Ich rätsele schon mindestens ein halbes Jahr herum, warum mein Fernseher zwar im internen Netzwerk, nicht aber bei Fhem auftauchen wollte. Habe verschiedene Konfigurationen und Kabel ausprobiert, aber nichts hat geholfen.
Jetzt bin ich zufällig auf diesen Thread gestoßen und siehe da, mit dem "blocking"-Attribut funktioniert es plötzlich tadellos!


Gruß


Wolfgang

[challo]

Ich bekomme seit einiger Zeit eine Fehlermeldung beim Initialisieren des Plugins:
Hat jemand ähnliche Erfahrungen?

2020.06.16 22:37:06 1: reload: Error:Modul 70_VIERA deactivated:
Can't locate Crypt/Mode/CBC.pm in @INC (you may need to install the Crypt::Mode::CBC module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM/lib) at ./FHEM/70_VIERA.pm line 85, <$fh> line 94.
BEGIN failed--compilation aborted at ./FHEM/70_VIERA.pm line 85, <$fh> line 94.

2020.06.16 22:37:06 0: Can't locate Crypt/Mode/CBC.pm in @INC (you may need to install the Crypt::Mode::CBC module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM/lib) at ./FHEM/70_VIERA.pm line 85, <$fh> line 94.
BEGIN failed--compilation aborted at ./FHEM/70_VIERA.pm line 85, <$fh> line 94.

[mabula]

Hallo challo,

ich habe Ende letzten Jahres das Modul für neue TV's mit verschlüsselter Verbindung ergänzt. Dazu müssen einige Module auf dem rpi installiert werden. Siehe dazu die Commandref oder gib in die Suchanfrage im Forum die "99994" oder "VIERA funktioniert nur teilweise" ein.
Ich hoffe dies hilft dir weiter. (Dein System wurde schon länger nicht mehr aktualisiert)
Gruß H-J
Anbei der Link https://forum.fhem.de/index.php/topic,99994.msg988223.html#msg988223

[challo]

Vielen Dank für die Rückmeldung, werde ich testen.
Ich hatte nur im WIKI gelesen. Dort steht nichts dazu. In der Comandref stehts aber ja...