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

Begonnen von mircoby, 21 Juni 2015, 20:43:38

Vorheriges Thema - Nächstes Thema

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:

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


So sieht das entsprechende Log mit verbose 5 aus:
Zitat
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:

Zitat
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
FHEM 6.2 auf Intel NUC mit Ubuntu 20.04 LTS
BUSWARE CUL, HM-RC-12, HM-SEC-RHS, HM-WDS30-OT2-SM, HM-ES-PMSw1-DR, CCU3, Sourceforge/hausbus (Beleuchtung + Rolläden + Audio), YAMAHA_AVR

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
FHEM 5.8 dev (virtualisiert) / FBF 7390 (CUL 868MHz V 1.51 / panStick (AVR1))
FS20: fs20di,fs20pira,fs20sm8,fs20st2,fs20tfk,fs20ue1,fs20ws1
panStamp (AVR1): RGB Multi von ext23, 1W-DSxxxx, I/O Sketch, Spritzpumpe
Multimedia: Panasonic TV (VIERA), Kodi, Yamaha RX-V781, LMS
Sonstiges: XiaomiFlowerSen

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
FHEM 6.2 auf Intel NUC mit Ubuntu 20.04 LTS
BUSWARE CUL, HM-RC-12, HM-SEC-RHS, HM-WDS30-OT2-SM, HM-ES-PMSw1-DR, CCU3, Sourceforge/hausbus (Beleuchtung + Rolläden + Audio), YAMAHA_AVR

tpm88

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

Danke vorab
Tobias


Gesendet von iPad mit Tapatalk
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

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:

Zitat
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
FHEM 6.2 auf Intel NUC mit Ubuntu 20.04 LTS
BUSWARE CUL, HM-RC-12, HM-SEC-RHS, HM-WDS30-OT2-SM, HM-ES-PMSw1-DR, CCU3, Sourceforge/hausbus (Beleuchtung + Rolläden + Audio), YAMAHA_AVR

TeeVau


                                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
FHEM 5.8 dev (virtualisiert) / FBF 7390 (CUL 868MHz V 1.51 / panStick (AVR1))
FS20: fs20di,fs20pira,fs20sm8,fs20st2,fs20tfk,fs20ue1,fs20ws1
panStamp (AVR1): RGB Multi von ext23, 1W-DSxxxx, I/O Sketch, Spritzpumpe
Multimedia: Panasonic TV (VIERA), Kodi, Yamaha RX-V781, LMS
Sonstiges: XiaomiFlowerSen

mircoby

Hi Tobias,

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

Zitat
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
FHEM 6.2 auf Intel NUC mit Ubuntu 20.04 LTS
BUSWARE CUL, HM-RC-12, HM-SEC-RHS, HM-WDS30-OT2-SM, HM-ES-PMSw1-DR, CCU3, Sourceforge/hausbus (Beleuchtung + Rolläden + Audio), YAMAHA_AVR

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:
Zitat
...
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
FHEM 6.2 auf Intel NUC mit Ubuntu 20.04 LTS
BUSWARE CUL, HM-RC-12, HM-SEC-RHS, HM-WDS30-OT2-SM, HM-ES-PMSw1-DR, CCU3, Sourceforge/hausbus (Beleuchtung + Rolläden + Audio), YAMAHA_AVR

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.
FHEM 5.8 dev (virtualisiert) / FBF 7390 (CUL 868MHz V 1.51 / panStick (AVR1))
FS20: fs20di,fs20pira,fs20sm8,fs20st2,fs20tfk,fs20ue1,fs20ws1
panStamp (AVR1): RGB Multi von ext23, 1W-DSxxxx, I/O Sketch, Spritzpumpe
Multimedia: Panasonic TV (VIERA), Kodi, Yamaha RX-V781, LMS
Sonstiges: XiaomiFlowerSen

TeeVau

Zitat von: mircoby am 23 Juni 2015, 22:53:32
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.
FHEM 5.8 dev (virtualisiert) / FBF 7390 (CUL 868MHz V 1.51 / panStick (AVR1))
FS20: fs20di,fs20pira,fs20sm8,fs20st2,fs20tfk,fs20ue1,fs20ws1
panStamp (AVR1): RGB Multi von ext23, 1W-DSxxxx, I/O Sketch, Spritzpumpe
Multimedia: Panasonic TV (VIERA), Kodi, Yamaha RX-V781, LMS
Sonstiges: XiaomiFlowerSen

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:
                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.
FHEM 5.8 dev (virtualisiert) / FBF 7390 (CUL 868MHz V 1.51 / panStick (AVR1))
FS20: fs20di,fs20pira,fs20sm8,fs20st2,fs20tfk,fs20ue1,fs20ws1
panStamp (AVR1): RGB Multi von ext23, 1W-DSxxxx, I/O Sketch, Spritzpumpe
Multimedia: Panasonic TV (VIERA), Kodi, Yamaha RX-V781, LMS
Sonstiges: XiaomiFlowerSen

TeeVau

Zitat von: mircoby am 23 Juni 2015, 22:53:32
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.
FHEM 5.8 dev (virtualisiert) / FBF 7390 (CUL 868MHz V 1.51 / panStick (AVR1))
FS20: fs20di,fs20pira,fs20sm8,fs20st2,fs20tfk,fs20ue1,fs20ws1
panStamp (AVR1): RGB Multi von ext23, 1W-DSxxxx, I/O Sketch, Spritzpumpe
Multimedia: Panasonic TV (VIERA), Kodi, Yamaha RX-V781, LMS
Sonstiges: XiaomiFlowerSen

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
FHEM 5.8 dev (virtualisiert) / FBF 7390 (CUL 868MHz V 1.51 / panStick (AVR1))
FS20: fs20di,fs20pira,fs20sm8,fs20st2,fs20tfk,fs20ue1,fs20ws1
panStamp (AVR1): RGB Multi von ext23, 1W-DSxxxx, I/O Sketch, Spritzpumpe
Multimedia: Panasonic TV (VIERA), Kodi, Yamaha RX-V781, LMS
Sonstiges: XiaomiFlowerSen

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
FHEM 5.5 auf HP ProLiant MicroServer G7 N54L 8 GB Ubuntu 14.04 LTS.
1x HM-CFG-LAN, 1x HM-CFG-USB, 7x HM-CC-RT-DN, 5x HM-SEC-SC-2, 1x HM-SEC-SCo, 2x HM-TC-IT-WM-W-EU, 2x HM-LC-Sw1-Pl, 2x HM-ES-PMSw1-Pl, 4x HM-PB-2-WM55-2, 1x HM-PB-6-WM55, 1x HM-WDS10-TH-O, 1x CUL433, 6x Pollin Funksteckdose