[Q] Hilfe gesucht: Loewe Connect ID DR+ Smart-TV mit FHEM steuern

Begonnen von der.einstein, 08 April 2017, 15:40:50

Vorheriges Thema - Nächstes Thema

viegener

Wenn alle einverstanden sind würde ich im nächsten Schritt versuche das Auslesen und Verwalten der Channellist zu vervollständigen.
- Auslesen
- Verwalten
- Zugriffsfunktionen
--> Find name for UUID / channelnum(caption)
--> find UUID for channelnum
--> dump channellist
- channellist attribute handling
- ...
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

der.einstein

#152
@viegener:
Ja, gerne.

Ich würde mir mal anschaun, wie man einen beliebigen Sender einstellt (Zaptomedia oder so). Hierfür braucht man dann den Locator. Der kann aber auch eine URL eines Streams sein.

Würde es dann wieder als Diff Patch posten?

Grüße.

der.einstein

#153
Hoffe, ihr habt die Änderungen noch nicht eingepflegt.
Hier die Änderungen von oben gegen v30 mit zusätzlich ZapToMedia implementiert als "switchto"

--- 82_LoeweTV_v39.pm 2017-09-24 20:29:30.753264808 +0200
+++ 82_LoeweTV.pm 2017-09-24 20:46:25.891961722 +0200
@@ -371,7 +371,7 @@ sub LoeweTV_Set($@) {
         return;
     
     } elsif( lc $cmd eq 'remotekey' ) {
-        return "$cmd needs argument remote key" if ( ( scalar( @args ) != 1 ) || ( $args[0] !~ /^\d+$/ ) );
+        return "$cmd needs argument remote key" if ( ( scalar( @args ) != 1 ) );
         @actionargs = ( 'InjectRCKey', $args[0] );   
     
     } elsif( lc $cmd eq 'connect' ) {
@@ -624,6 +624,7 @@ sub LoeweTV_SendRequest($$;$$$) {
     my $name = $hash->{NAME};
   
     my $ret;
+    my $alphabet;
   
     Log3 $name, 5, "LoeweTV_SendRequest $name: ";
     
@@ -683,9 +684,16 @@ sub LoeweTV_SendRequest($$;$$$) {
                                         'm:AccessStatus' => sub {LoeweTV_ParseRequestAccess($hash, $_->text_only('m:AccessStatus'));},}
                                     ],
                                     
-        "InjectRCKey"           =>  [sub {$content='<InputEventSequence>
-                                        <RCKeyEvent alphabet="l2700" value="'.$actPar1.'" mode="press"/>
-                                        <RCKeyEvent alphabet="l2700" value="'.$actPar1.'" mode="release"/>
+        "InjectRCKey"           =>  [sub {
+    if ( index($actPar1, "hdr" ) != -1 )
+   {
+    $actPar1 =~ s/hdr// ;
+    $alphabet = "l2700-hdr" ;
+   }
+    else { $alphabet = "l2700" ; } ;
+    $content='<InputEventSequence>
+                                        <RCKeyEvent alphabet="'.$alphabet.'" value="'.$actPar1.'" mode="press"/>
+                                        <RCKeyEvent alphabet="'.$alphabet.'" value="'.$actPar1.'" mode="release"/>
                                         </InputEventSequence>'},{"ltv:InjectRCKey" => sub {$hash->{helper}{lastchunk} = $_->text_only();}},],
                                         
         "GetDeviceData"         =>  [sub {$content='';},


Somit kann mit "set MyLoewe switchto locator" auf einen anderen Kanal geschalten werden. Das klappt erstaunlich gut und außerdem schneller als mit der Fernbedienung. Der Locator muss in diesem Fall zwingend ein Channel sein. Durch GetMediaItem kann ich aus einer UUID den Locator bekommen.

Cool wäre es jetzt, wenn man aus einer Dropdownliste "ARD" oder ähnliches auswählen könnte.

Es gibt auch noch die Funktion "ZapToApplication". Damit kann ich zu einer bestimmten Website springen. Ist das von Interesse?

Was könnte man sinnvollerweise als Text aus FHEM auf dem TV anzeigen?  ;D Also via "SetActionField"...

Grüße.

CoolTux

@der.einstein
Ich habe die Vermutung das Dein Patch falsch erstellt ist. Du darfst nicht ein patch von Deiner geänderten Version gegen die alte Version erstellen, sondern immer von der alten gegen die neue
diff -up oldfile newfile > /path/to/patchfile.patch

Deswegen dachte ich auch Johannes hätte Deine Version schon eingespielt.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

Version 0.0.34
Ich habe der.einstein seinen Patch eingepflegt
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

viegener

Geht ja gut voran - ich habe auch noch eine

Version 0.0.35

Die Channels werden jetzt eingelesen mit Medieninfo
per attribut maxchannels kann man die Anzahl jetzt begrenzen
mit get showchannellist kann man eine Textversion der Channelliste zur Anzeige bringen

Bitte (mindestens) diese Version für weitere diffs nehmen, es ist ziemlich viel dazugekommen und auch verschoben
(Ich wollte alle channelfunktionen in einem Block haben, denn langsam wird das Modul lang)

Ja ich habe meine Änderungen natürlich in die 34 gemerged und nicht einfach überschrieben...
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

der.einstein

@CoolTux: Ja, hatte ich vermutlich falsch rum gemacht :-D

@viegener: Natürlich sollte der Patch für die aktuelle Version sein, aber wie auch du, ist es für mich auch doof alles 2mal zu machen. Beim nächsten mal wird alles besser :-)

Bleibt zu konstatieren, dass es voran geht.

Aufnahmen zu setzen würde ich mal als nächstes angehen. Wichtig wäre hier für mich, wie in FHEM normalerweise die Zeiten angegeben werden. Beim LoeweTV muss es dann ja als Epoch UTC plus Dauer in Sekunden ankommen. Was ist hier bei FHEM die Konvention?

Gesendet von meinem LG-D855 mit Tapatalk

viegener

Zitat von: der.einstein am 20 September 2017, 12:41:57
@viegener: Natürlich sollte der Patch für die aktuelle Version sein, aber wie auch du, ist es für mich auch doof alles 2mal zu machen. Beim nächsten mal wird alles besser :-)



War von mir nicht als Vorwurf gemeint, aber das mergen ist immer sehr aufwändig, wenn Blöcke verschoben werden.

Generell bevor es zu weit geht wäre es mir wichtig, dass noch mehr Tests und die Grundstruktur passt, denn es stehen noch ein paar ganz grundsätzliche Dinge an

- Regelmässiges Abfragen der Daten / Presence Status
- Fehlerbehandlung SOAP-Fault / leere Rückgaben / AccessDenied or pending
- Keep-Alive auf dem socket (ich habe das Gefühl, dass bei der Channellist --> ca. 200 Abfragen bei mir hier deutlich performance zu gewinnen wäre
- Log messages anpassen (verbose level)

Gerade bei der Fehlerbahndlung habe ich ein Problem: Wenn der Client nicht akzeptiert wird, sendet mein Fernseher eine gültige Soap-Nachricht mit allen Tags aber ohne die eigentlichen Daten zurück - Nicht einfach zu erkennen und nicht dokumentiert
Passiert das bei Dir auch?
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

der.einstein

@viegener: Nein, hab ich noch nicht gesehen. Ich krieg dann immer nur den HTTP Fehler 200(?). In der API steht so ein Verhalten ja nur für das GetDeviceData, schon möglich, dass das bei anderen Responses auch so gehandhabt wird. Hast du bestimmt schon gemacht, aber der Vollständigkeit halber: Hast du mal gecheckt, ob es für dein Chassis eine neue Firmware gibt?

Am Ende der API gibt es noch eine Funktion, um die Settings des TV auszulesen, unter anderem, ob Wake-On-LAN gesetzt ist. Ich weiß jetzt auch nicht, was da zurückkommt, wenn der TV WOL gar nicht erst unterstützt. Könnte uns das was helfen, dann darauf basierend den TV unterschieldich im Modul zu behandeln?

Grüße.

CoolTux

@Johannes,
In den Zeilen 813-817

if ( defined( $refreadings->{$readName} ) ) {
        readingsBulkUpdate($hash, $readName, $refreadings->{$readName} );       
      } else {
        delete($hash->{READINGS}{$readName});
      }


Hier stößt mir das delete($hash->{READINGS}{$readName}); unangenehm auf.
Kurze Frage warum sollten hier bereits angelegte Readings wieder gelöscht werden? Sowas soll ja laut Developer Guide (inoffiziell) nicht gewünscht sein.
Und die zweite Frage, wenn doch nötig so wäre es besser dies über die FHEM Routine CommandDeleteReading zu machen, da Hash Manipulationen vermieden werden sollen.
Daher wenn nötig

if ( defined( $refreadings->{$readName} ) ) {
        readingsBulkUpdate($hash, $readName, $refreadings->{$readName} );       
      } else {
        CommandDeleteReading(undef,$readName);
      }


Wie denkst Du darüber?



Grüße
Leon
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

viegener

@cooltux: Oh Je - mein Code stösst unnangenehm auf - das will ich natürlich nicht  ;)

Aber ja, Du hast absolut recht, das ist eine alte Routine, die ich einfach per Copy/Paste übertragen habe. Ich hatte den Mechanismus um Readings aufzusammeln auch in anderen Modulen im Einsatz und er passt hier ja ebenfalls. Der Mechanismus wird bei mir benötigt, wenn es dynamische Readings gibt, die Abhängigkeit von extern sind. HTTPMod wäre ein Beispiel für ein Modul, das ebenfalls solche dynamischen Abhängigkeiten und meiner Erinnerung nach auch Readings entfernt.

Willst Du die Änderung machen?
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

CoolTux

Ich würde die Änderung machen. Komplett das delete weg oder magst lieber löschen. Ist Deine Routine also Deine Entscheidung  :)
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

viegener

Zitat von: CoolTux am 20 September 2017, 14:22:30
Ich würde die Änderung machen. Komplett das delete weg oder magst lieber löschen. Ist Deine Routine also Deine Entscheidung  :)

Ich mag die Variante mit CommandDeleteReading lieber, ich denke wir werden dynamische Readings bekommen...
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

CoolTux

Zitat von: viegener am 20 September 2017, 14:46:18
Ich mag die Variante mit CommandDeleteReading lieber, ich denke wir werden dynamische Readings bekommen...

Ist schon geändert und wird gleich hochgeladen
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net