70_VIERA.pm - Mehrere Geräte verwalten und so...

[mimue]

Hallo Mabula,

ich habe seit einigen Tagen das Modul "am Wickel", ich habe zwei Panasonic Geräte ( TX40CX700 und TX58DXW734 ), die über WLAN im Netz eingebunden sind, und beide als DLNA Server ständig in Bereitschaft, also ansprechbar sind.

Sobald die Geräte optisch aus sind ( Kein Bild, kein Ton, gelbe LED zeigt Bereitschaft ), erzeugt VIERA in jedem Intervall eine Meldung: "... TV answered with 400 Bad Request. Seems to be on but delivering no data"

Schalte ich die Geräte ein, egal ob über Fernbedienung oder Modul, unterbleibt diese Meldung. Es scheint also, daß 70_VIERA.pm die http-Meldung 400 fälschlicherweise als eingeschaltet aber keine Lust zu antworten interpretiert.

Bei der Gelegenheit störte mich, daß alle Log-Einträge schlicht mit VIERA: gekennzeichnet sind, das ist bei mehreren Geräten nicht sonderlich hilfreich. Ich habe mal spasseshalber alle Vorkommen von VIERA: und VIERA[ in Lognachrichten durch $hash->{NAME} ersetzt. Das sieht deutlich besser aus.

Was ebenfalls auffällt, ist, daß es für die readings und set | get offenbar keinen Unterschied macht ob das Gerät an oder aus ist. Für die programmatische Steuerung wäre es aber schon hilfreich, wenn die readings zwischen eingeschaltet (Bild und Ton an) und bereit (Bild und Ton aus) unterscheiden könnten.

Da die Fernbedienungsfunktionen durchweg als Impulsgeber (toggle) funktionieren, und nicht als Kippschalter, müßte eine Überwachungsroutine über den tatsächlichen Zustand Buch führen.

Man könnte auch ein OFF oder remoteControl POWER senden, und prüfen ob im nächsten Intervall 400 gemeldet wird, das würde dann auf OFF deuten, könnte aber auch eine Fehlersituation anzeigen, also nicht eindeutig

Auch würde ich gern das Layout meine Fernbedienung besser abbilden (beide Geräte verwenden die Gleiche - N2QAYB001010. Leider habe ich noch nicht verstanden an welcher Stelle das relevante Mapping vorkommt.

Ich helfe gern bei der Umsetzung meiner Wünsche aktiv mit, ansonsten wäre ich für ein paar hilfreiche Anmerkungen dankbar.

MiMue

Ergänzung vom 13. 12. 2019:

Die Geräte haben eine Anzeige die wahlweise gelb (Bereitschaft) oder grün (an=Bild&Ton) leuchten. Im ioBroker werden diese korrekt wiedergegeben, es muß also eine Möglichkeit geben die im Status zu erkennen.

Im 70_VIERA.pm ist auf Zeile 176 ein Fehler: Anstatt

Code Auswählen Erweitern

if(int(@args) < 3 && int(@args) > 6) {
muß es heißen

Code Auswählen Erweitern

if(int(@args) < 3 || int(@args) > 6) {,
sonst wird die Fehlermeldung niemals ausgegeben, und Geräte werden verstümmelt angelegt. N.B. die Zahl der Argumente wird wohl kaum jemals gleichzeitig kleiner 3 und größer 6 sein

[mimue]

Sobald die Geräte optisch aus sind ( Kein Bild, kein Ton, gelbe LED zeigt Bereitschaft ), erzeugt VIERA in jedem Intervall eine Meldung: "... TV answered with 400 Bad Request. Seems to be on but delivering no data"

Schalte ich die Geräte ein, egal ob über Fernbedienung oder Modul, unterbleibt diese Meldung. Es scheint also, daß 70_VIERA.pm die http-Meldung 400 fälschlicherweise als eingeschaltet aber keine Lust zu antworten interpretiert.

So, ich habe noch mal ein wenig "gegraben", es gibt wohl allerlei Projekte zum Thema Network Remote Control (NRC) für VIErA (so meldet sich das Gerät selbst).

Grundsätzlich wird ein Riesenaufwand ( im Schnitt 15 Zeilen XML ) getrieben um einen Befehl abzusetzten, der aus einem Schlüsselwort besteht. Die Schlüsselwörter sind offenbar alle durch "sniffing" bekannt geworden, die umfangreichste Sammlung fand ich bei samuelmatis auf GitHub. Offenbar gibt es tatsächlich nur zwei Werte, die sich explizit abfragen lassen: Mute und Volume.

Somit ergibt sich für mich folgendes Bild:

Ist das Gerät abgeschaltet (stromlos) ist es natürlich auch im Netzwerk nicht vorhanden. Das heißt ein timeout sollte sich in den readings als "absent" wiederfinden.

Ist das Gerät eingeschaltet aber nicht bereit (gelbe LED leuchtet) antwortet es auf Ansprache mit "400 bad request", das sollte sich in den readings als "present" und "off" wiederfinden, bei Mute und Volume sollte "unknown" oder "?" erscheinen, da der Zustand nicht feststellbar ist. War der letzte Zustand "present" und "on" ist "400 bad request" genau das, ein Anfragefehler, und sollte entsprechend gemeldet/geprüft werden.

Ist das Gerät eingeschaltet und bereit (grüne LED leuchte, Bild und Ton verfügbar) werden Anfragen mit "200 OK" beantwortet, die Werte für Volume und Mute werden zurückgegeben und können in die readings übernommen werden. Unter presence bleibt present stehen, bei state sollte nun "on" gemeldet werden.

Außerdem scheinen die Schlüsselwörter je nach suffix (_ON, _OFF, _ONOFF) verschiedene Reaktionen hervorzurufen. _ON bildet eine betätigte Taste ab, _OFF eine losgelassene, _ONOFF ein einmaliger Impuls aus _ON gefolgt von _OFF.

Ob meine Feststellungen sich auf andere/alle Panasonic Geräte übertragen lassen, kann ich leider nicht feststellen, das müssten die jeweiligen Besitzer selbst beisteuern. Meine Geräte können beispielsweise keine Verschlüsselung, das bleibt also außerhalb meiner Reichweite.

[mabula]

Hallo mimue,
habe deine Kommentare erst heute gelesen. Leider im Moment wenig Zeit. Werde mich aber diese Tage genauer damit beschäftigen. Habe das Modul erst übernommen und eigentlich nur die Verschlüsselung hinzugefügt. Deine Themen sprechen teils noch das alte Modul an. Aber deine Ideen sind gut.
Gruß
HJB

[mimue]

Hallo Mabula,

Danke für die Rückmeldung. Was meinst Du mit "altes Modul" ? Ich verwende für meine Erkundungen

Code Auswählen Erweitern

$Id: 70_VIERA.pm 20638 2019-12-01 17:50:40Z mabula $

Melde Dich, wenn Du mehr Zeit hast, bis dahin habe ich vermutlich noch ein paar Unstimmigkeiten ergründet und kann Dir meine provisorischen Änderungen als .diff zur Verfügung stellen.

Bis dahin,

MiMue

[mabula]

Hallo MiMue,
habe eine Lösung gefunden, war einfacher als ich dachte. Die Antwort war in der Protokollnotiz enthalten, die mein Vorgänger erstellt hat. Ich verwende die noch existierende Netzwerkverbindung und die Weigerung die Statusanfrage zu beantworten. Die Testversion ist unter dem Thema 99994 im 5. Beitrag zu finden. Ob dies alle Firmwareversionen abdeckt?
Zu deiner Frage zur Fernbedienung. Im Modul sind 2 exemplarische Layouts enthalten. Man kann selbst beliebige Layouts erstellen. Hilfreiche Definitionen und Code siehe Zeilen: 80,81,156,157 und ab 1284. Das eigenen Layout lässt sich einfach in 99_myUtils einbetten.
Bitte Kommentare hier schreiben.
Danke für deinen Einsatz.
Gruß HJB

[mimue]

Die Testversion ist unter dem Thema 99994 im 5. Beitrag zu finden.

Halo mabula,

Danke für die Nachricht, allerdings stehe ich bei "99994 im 5. Beitrag" auf dem Schlauch, könntest Du das etwas präzisieren ? In GitHub und fhem finde ich nur die Version, die ich bereits habe.

Die Frage nach den Codes hat sich inzwischen erledigt. Ich war gedanklich noch bei einer Linux Anwendung namens LIRC, die Fernbedienungen emuliert, allerdings mit Ausgabe über IR. Inzwischen habe ich verstanden, daß tatsächlich Text gesendet wird, daher auch meine Anmerkung bezüglich overhead. Das scheint wohl eine Eigenart von SOAP zu sein. Vermutlich werden solche Protokolle unter der Anname kostenloser unendlicher Bandbreite und Speicherkapazität ersonnen.

Inzwischen habe ich noch eine Baustelle aufgemacht: Wenn ein Gerät angelegt wird, wird es zwar erstellt, da aber das Reading "presence" abgefragt wird, bevor es überhaupt angelegt wurde, läßt sich das Gerät nicht über das Modul einschalten, sondern muß manuell eingeschaltet werden, damit die Sache floriert.

Wenn ich die betreffende Zeile auskommentiere, geht es, allerdings hat die Abfrage ja wohl eine Bedeutung, es muß also sichergestellt werden, daß "presence" angelegt wird _bevor_ die Abfrage zum ersten Mal durchlaufen wird.

Zeile 276

Code Auswählen Erweitern

return "VIERA: Device is not present or reachable, power on or check ethernet connection" if(ReadingsVal($name,"presence","absent")ne "present" && $what ne "?");>

MiMue

[mabula]

Hallo MiMue,
Thema 99994 ist im Klartext der Forumsbeitrag "Thema: panasonic viera funktioniert nur teilweise". An dieser Stelle habe ich die ersten Testversionen für die verschlüsselte Verbindung eingestellt. Ich wollte jetzt kein weiteres Thema mit Downloads aufmachen.
Die neue Baustelle wird so bleiben. Bei state off wird kein Kommando gesendet. Mit der neuen Version wird dein Thema allerdings verschwinden, hier sollte der state dormant (LED orange) erkannt werden.

Gruß HJB

[mimue]

Danke für die Aufklärung, mabula,

für solche Fälle hat man anno 1989 am CERN HTML erfunden. Ein einfaches Link https://forum.fhem.de/index.php/topic,99994.0.html wäre hilfreich gewesen.

Für "Download"-Baustellen gibt es Versionskontrolle über GIT/SVN etc. einfach den aktuellen Status in GitHub einstellen. Dort können dann interessierte oder Betroffene auch Meldungen und Vorschläge einstellen.

MiMue

[mimue]

Hallo mabula,

inzwischen haben es Deine Änderungen in den update Zyklus geschafft. Ich habe gerade Version 1.27 erhalten und probiere ein wenig damit herum. Einiges ist realisiert wie vorgeschlagen, anderes kann noch verbessert werden.

Nach einem set sollte, unabhängig vom timer, sofort ein getstatus nachgeschoben werden, damit der Zustand unverzögert aktualisiert wird.

Die Visulalisierung über das devStateIcon könnte man mit beispielsweise

Code Auswählen Erweitern

attr <device> devStateIcon .*dormant:StandBy .*on:Restart .*off:Shutdown oder ähnlich realisieren.

Bei set volume im web-frontend läßt sich keine Lautstärke einstellen.

Mehr wenn ich ein wenig ausgiebiger getestet habe. Erstmal Danke & besinnliche Feiertage.

MiMue

[mabula]

Hallo MiMue,

Wieso stehst Du nicht mehr zu deinem Originalbeitrag und hast ihn geändert. War doch ein toller Beitrag!!!

Fehlermeldungen über return beim set Befehl verhalten sich mystisch. Je nach ,,falschem" Kommando erscheint die Meldung in einer extra HTML Box oder im Fenster des Browsers und überschreibt die Voreinstellungen des set Befehls. Mit ,,set <name> ?" im status on wird die Vorbelegung wieder hergestellt. Bei mir erscheint dann auch wieder der Slider bei Volume.  Dies tritt allerdings nur auf, wenn ein falscher Befehl eingegeben wird. Im Status off wird nur ? erlaubt und im Status dormant nur ein on_off Befehl. Eine bessere Lösung habe ich nicht gefunden https://forum.fhem.de/index.php/topic,105926.0.html.
Ein get status wird bereits überall bei jedem Befehl nachgeschoben, der eine Statusänderung bewirkt. Bei on_off macht es keinen Sinn, denn die Zeit der Statusänderung hängt von der Komplexität des Netzwerks und dem Router ab. Dieser muss zuerst die Änderung erkennen und bekannt geben.
Status ist für mich ein zentrales reading, da gehört der Zustand vermerkt. Das attr kann jeder nach eigenem Gusto einfügen.
Zur Verschlüsselung steht in der Commandref, dass das Modul dies selbst erkennt (Encryption → no oder yes). Nur neue TVs ab 2019 verlangen eine verschlüsselte Kommunikation.
Mit Netzanschluss hast Du wohl Netzwerkanschluss gemeint. Denn der Netzanschluss ist bei solchen Geräten fast niemals aus, außer man zieht den Stecker.
Presence hat für mich die ursprüngliche Bedeutung, nämlich Anwesenheit (Mensch sitzt vor dem TV oder nicht).
Es ist zwar die Zeit der Wunschkonzerte, aber nicht jeder Wunsch wird erfüllt.

Gruß
HJB

[mimue]

Hallo Mabula, schön, daß Dir der Beitrag gefallen hat

mir kam er beim zweiten Durchlesen und neuen Beobachtungen etwas vorschnell ( -laut ?? ) vor. Ich habe daher einiges zur genaueren Untersuchung zurückgestellt, stehe aber natürlich dazu, sonst hätte ich beim ersten Mal nicht auf <enter> gedrückt.

Ich habe für mich jetzt mal webCmd durch devStateIcon ersetzt:

Code Auswählen Erweitern

# mimue  CommandAttr(undef,$name." webCmd on_off") if( !defined( AttrVal($hash->{NAME}, "webCmd", undef)) );

  CommandAttr(undef,$name." devStateIcon dormant:StandBy:on_off on:Restart:on_off off:Shutdown") if ( !defined( AttrVal($hash- {NAME}, "devStateIcon", undef)) );




Außerdem habe ich nach set on_off ein get status eingefügt

Code Auswählen Erweitern

elsif ($what eq "on_off"){
    Log3 $name, 3, "$name: Set on_off";
    VIERA_Encrypted_Command($hash, "POWER");
    VIERA_Encrypt_Answer($hash);
    sleep 0.4;                                        # wofür benötigt das Ding (TV/Modul) soviel Zeit ??
    VIERA_GetStatus($hash, 1);
  }



Es gibt einen Effekt, den ich noch nicht erklären kann, der aber zu Fehlhandlungen führt: Die verzögerte Einstellung der "readings" habe ich mit dem GetStatus "erschlagen", aber die "internals" werden erst mit einem reload des Browsers aktualisiert. Wieso ??

Da ich das Modul zur programmatischen Kommunikation einsetzen möchte, bin ich natürlich durch die Verzögerungen erst mal in die Irre gelaufen.

Mit Netz meine ich Netz und nicht Netzwerk. Zum Testen habe ich das Gerät physisch vom Stromnetz getrennt und wieder verbunden. Inzwischen habe ich auch den Netzschalter gefunden (habe ich noch nie gebraucht). Wenn ich das Teil vom Netz trenne und wieder verbinde, nimmt es den status quo ante (LED grün/orange) wieder ein. Schalte ich über den Netzschalter aus und ein, ist _immer_ LED grün.

Inzwischen habe ich noch folgendes gefunden: Das Gerät sagt ziemlich viel über sich selbst, wenn man es ordentlich fragt:

Statusabfrage mit Browser:

Code Auswählen Erweitern

http://192.168.x.x:55000/dmr/ddd.xml,
http://192.168.x.x:55000/dmr/sdd_0.xml
http://192.168.x.x:55000/dmr/sdd_1.xml
http://192.168.x.x:55000/dmr/sdd_2.xml

http://192.168.x.x:55000/nrc/ddd.xml,
http://192.168.x.x:55000/nrc/sdd_0.xml


Wobei dmr nur antwortet wenn LED grün, nrc immer, solange das Teil mit dem Netzwerk verbunden ist.

Da ich die Dinge gern übersichtlich behalte, würde ich es bevorzugen, wenn so wenig wie möglich zusätzlich als Status definiert wird.

Etwa

Netzspannung an, Netzwerkverbindung vorhanden, power off= LED orange = Bereit = Present
Netzspannung an, Netzwerkverbindung vorhanden, power on= LED grün = Ein = Present
Netzspannung aus || Netzspannung an, Netzwerkverbindung nicht vorhanden = Timeout = Absent = Aus

Die Stati reduzieren sich damit auf Absent | Present Ein | Present Bereit

Aber das bleibt natürlich jedem selbst überlassen.

Present kann eigentlich nicht die Anwesenheit einer Person vor der "Glotze" bedeuten, dafür fehlt ein Sensor. Eher ist es sinnhaft damit die Verfügbarkeit des Gerätes für Netzwerkteilnehmer zu bezeichnen.

Die Zeit der Statusänderung hängt im wesentlichen von der eingestellten Zeitschleife ab, bei mir 60s, schiebe ich die Abfrage direkt nach (plus 0,4s - wofür ?? ) habe ich die Antwort gleich und kann in Skripten auf Wartezeiten verzichten. Im Übrigen zeigt die Erfahrung, daß Menschen ungeduldig werden, wenn die Technik nicht sofort reagiert. Da werden dann schon mal Tasten und Knöpfe gedrückt, bis gar nichts mehr geht ( Im Grunde eine menschliche DOS Attacke ) Daher auch mein voreiliger letzter Post.

Was mich an der Visualisierung extrem stört, ist der Schieberegler, der ist für Laien kaum als solcher zu erkennen, reizt also auch nicht dazu ihn zu schieben. Hat aber scheinbar bislang außer mir niemanden gestört...

Was ich hier beitrage sind keine Wünsche, ich bin alt genug um meine Probleme selbst zu lösen. Foren wie dieses leben davon, daß man Erkenntnisse (oder was man dafür hält) teilt, was jeder mit den Informationen anfängt, bleibt ihm selbst überlassen

Nochmals besinnliche Feiertage

MiMue

P.S. noch ein link https://forums.indigodomo.com/viewtopic.php?f=134&t=17875&start=15

[mabula]

Hallo MiMue,

nicht jeder versteht Satire. Im Klartext, dein Originalbeitrag Nr. 8 war von der Formulierung her völlig daneben.
Nach dem Motto:

hast du gefunden noch keine Feinde,
schau nach in der Forumfangemeinde!

Die 400 ms kommen wie bereits beschrieben von der Latenz des Netzwerks und natürlich vom Prozessor des TVs, der benötigt seine Zeit für boot, wake-up oder shut down. Ob die 400 ms immer reichen? Da dieser Aufruf nicht periodisch erfolgt und Prozessorleistung durch sleep vergeudet, werd ich auf deinen Wunsch hin, in die nächste Version eine Statusabfrage einbauen.
Das webCmd kann ruhig stehen bleiben, dies ist nicht im Konflikt mit devStateIcon. Ich habe das bei mir persönlich mit:
attr <name>  devStateIcon off:it_television@red on:it_television@green:on_off dormant:it_television@orange:on_off
realisiert.
Was antwortet denn der TV bei deinen Abfragen? Und was benötigt man davon konkret?

Gruß
HJB

PS: Ich würde 2-mal Luft holen, bevor ich Enter drücke!

[mimue]

Prima mabula, jetzt hast Du ja Dampf abgelassen, jetzt sind die Feiertage gerettet.

Allerdings solltest Du Deine gewagten Annahmen bezüglich Netzwerk-Latenz und Prozessorleistung eines modernen Smart-TV nochmals überdenken.

Da bei Betätigen von NRC_POWER-ONOFF niemand bootet und das Gerät als DLNA-Server aktiv bleibt, denke ich, daß es eher am Modul liegt. Daß Du mir ein Netzwerk zutraust, das so komplex ist, daß Deine Annahmen Hand und Fuß hätten, ehrt mich. Es ist aber eher kleinwüchsig, und die "Latenzen" halten sich in überschaubaren Grenzen.

Wie bereits im letzten Post ausgeführt, "wünsche" ich mir keine Änderungen, ich mache lediglich auf Unstimmigkeiten aufmerksam, was Du daraus machst, bleibt Dir überlassen.

Was der TV sagt, wenn man ihn mit den zitierten Abfragen konfrontiert, kannst Du ganz leicht mit Cut, Paste und Enter herausfinden

LG MiMue