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

[viegener]

Die default List gibt's ja auch bei mir. Aber ich glaube, da sie so lang ist gibt es ein Problem. Werden denn bei 100+ Einträgen beim aktuellen Code alle ResultFragments vom TV abgeholt, oder nicht? Wenn das nicht passiert, könnte es eventuell daran liegen, dass er danach blockiert.

Ja natürlich werden alle Resultfragmente geholt, aber es geht ja nicht nur um die Resultliste - für jeden Channel muss ja ein weiterer Request gemacht werden (getMediaItem) um die Infos abzurufen. Aber wie gesagt, das Problem liegt auf Loewe-Seite wenn er einfriert und das setzen des Attributs sollte bei Dir das Problem lösen.

[CoolTux]

Johannes, kurze Frage

Zeile 1038 ergibt für mich kein Sinn

Code Auswählen Erweitern


if ( ( defined( $hash->{actionQueue} ) ) && ( scalar( @{ $hash->{actionQueue} } ) ) ) {


Kann es sein das Du da ein > 0 vergessen hast?

Code Auswählen Erweitern


if ( ( defined( $hash->{actionQueue} ) ) && ( scalar( @{ $hash->{actionQueue} } ) > 0 ) ) {





Grüße

[viegener]

Johannes, kurze Frage

Zeile 1038 ergibt für mich kein Sinn

Code Auswählen Erweitern


if ( ( defined( $hash->{actionQueue} ) ) && ( scalar( @{ $hash->{actionQueue} } ) ) ) {


Meine Zeile macht schon Sinn, ist aber falsch

Entweder das von Dir vorgeschlagene >0 oder ein ! vor dem scalar wäre korrekt, willst Du fixen, ich kam seit einer Woche nicht wirklich zum testen...

[CoolTux]

 

Ich fixe es mal mit > 0



Grüße

[der.einstein]

Ich fixe es mal mit > 0



Grüße

Darf ich fragen was die Zeile macht, bzw. was die Änderung bewirkt?

Gesendet von meinem LG-D855 mit Tapatalk

[CoolTux]

Es ist eine Bedingung welche prüft ob die Anzahl der Elemente im Array größer 0 ist.
Also ob sich noch was in der actionQueue befindet.

[der.einstein]

Hier mal was komisches:
Wenn ich manuell get currentEvent ausführe, was mit meinem Patch auch Kanalnummer und Name als Reading aisgibt, kommen die ins FHEM Web.
Aber komisch nur, wenn ich dann die Seite refreshe, verschwinden genau diese Readings und die restlichen Readings, die ja auch aus get currentEvent sind, bleiben stehen. Anbei mal die Bilder vor und nach dem Refresh.
An was kann das liegen?


Gesendet von meinem LG-D855 mit Tapatalk

[CoolTux]

Wird wohl am nächsten Durchlauf liegen wo alle Readings gelöscht werden die nicht Bestandteil der Response sind.

[viegener]

Wird wohl am nächsten Durchlauf liegen wo alle Readings gelöscht werden die nicht Bestandteil der Response sind.

Ja, das liegt am nächsten Durchlauf, denn die Daten liefern dann wohl undef zurück, ich bin gerade mal dabei die Änderungen zu mergen.

[viegener]

OK, habe eine neue Version 48 mit den Änderungen von der.einstein hochgeladen
- habe die Aufrufe für currentEvent in eine getrennte routine ausgelagert, damit die Readings erhalten bleiben
- als Standrd wird weiterhin channellist default angenommen - wenn das Problem macht, könnten wir den timeout für den ersten Start des timers hochsetzen - beim neustarten von FHEM sollte das keine Probleme machen

Achso: Es lässt sich bei mir Laden aber testen konnte ich die FUnktionen nicht, da bräuchte ich Hilfe von jemand mit einem neueren Loewe...

[der.einstein]

Hallo Leute,
habe mal wieder etwas Zeit gehabt

Ich hab die "Loewe App" für Android installiert, meinen TV verbunden und den mal machen lassen. Das Ganze hab ich per Packet Capture mitgeschnitten und hinterher ausgewertet. Verwendete Software: tPacketCapture und PCAP Reader, Auswertung am Linux PC mit tcpick.
Am Anfang wird ein RequestAccess gemacht.
Der Gute (die App) holt zunächst mit "GetSettings" die Einstellungen ab, dann mit "GetDeviceData" den Rest. Er sendet eine leere "fcid" und "DeviceType" ist "------------". Dann holt er die "GetListOfChannelLists" und danach die einzelnen Listen. Für jede Liste auch nach "GetChannelList" die "GetMediaItem" Anfragen.
Dann holt er alle 10 sec "GetVolume" und "GetMute" ab. Bei Bedarf sendet er "InjectRCKey".
Einmal pro Minute (genau 67 sec) sendet er ein neues "RequestAccess" und kriegt nach 1 mal senden sofort "Accepted" zurück, muss also nicht 3 mal senden.
Bei dem Vorgehen blockiert mein TV nie

Ich hab auch nochmal mein angestaubtes Perl-Script rausgekramt und mit einem Shell-Script ein ähnliches Prozedere abgebildet. Dabei blockierte der TV bei mir auch nicht (lief über 1 Stunde). Vorher hatte er nach max 15 min nicht mehr reagiert.

Könnten wir das Vorgehen mal im FHEM Modul abbilden? Braucht man da einfach einen weiteren Timer, oder sollte man das Alter des letzten Readings für Access auslesen?

@cartzilla: Kannst du mal einen Patch für das Modul schreiben, um deine Einschaltroutine zu bekommen? Ich werd auch nochmal schaun, wie das die Loewe App macht, die kann das scheinbar auch.

Grüße.

[viegener]

Wenn ich mir das anschaue, erscheint der zentrale unterschied das ständige Neuaufrufen von GetAccess zu sein.. Ausserdem vielleicht das nur einmalige aufrufen von getDeviceData.

Dazu würde kein

Ich vermute  mal die Werte von fcid und Devicetype machen eher keinen Unterschied

[der.einstein]

Wenn ich mir das anschaue, erscheint der zentrale unterschied das ständige Neuaufrufen von GetAccess zu sein.. Ausserdem vielleicht das nur einmalige aufrufen von getDeviceData.

Dazu würde kein

Ich vermute  mal die Werte von fcid und Devicetype machen eher keinen Unterschied

Naja ständig macht er nicht RequestAccess. Eben 1 mal pro Minute.
Ständig trifft eher auf die Abfragen von Volume und Mute zu.

Ich Stimme dir zu, dass die FCID und der DeviceType wohl keinen Einfluss haben.

Ich hab mal etwas an der Timer Routine geschraubt, sodass er bei jedem 4ten Aufruf (bei 4x15sec=1min) ein RequestAccess absetzt. Damit hat der TV den ganzen Abend durchgehalten.
Scheint also irgendwas zu bringen.

Das regelmäßige Abholen der DeviceData macht auch nicht sooo viel Sinn, da wir da keine aktualisierten Werte erwarten.
Für GetDeviceData und GetChannelList würde es Sinn machen, die abzubolen, nachdem der TV einmal aus war und dann wieder an ist. Also 1 mal pro "Sitzung".

Was meint ihr?

Gesendet von meinem LG-D855 mit Tapatalk

[cartzilla]

@cartzilla: Kannst du mal einen Patch für das Modul schreiben, um deine Einschaltroutine zu bekommen? Ich werd auch nochmal schaun, wie das die Loewe App macht, die kann das scheinbar auch.

Grüße.

Die Änderungen sind in Antwort #304 alle angegeben. Darauf gab's leider bisher kein Feedback. Die Änderungen greifen ja auch in andere Routinen ein. Den Code sollten sich daher erst nochmal cooltux und viegener ansehen...

[viegener]

Naja ständig macht er nicht RequestAccess. Eben 1 mal pro Minute.
Ständig trifft eher auf die Abfragen von Volume und Mute zu.

Ich Stimme dir zu, dass die FCID und der DeviceType wohl keinen Einfluss haben.

Ich hab mal etwas an der Timer Routine geschraubt, sodass er bei jedem 4ten Aufruf (bei 4x15sec=1min) ein RequestAccess absetzt. Damit hat der TV den ganzen Abend durchgehalten.
Scheint also irgendwas zu bringen.

Das regelmäßige Abholen der DeviceData macht auch nicht sooo viel Sinn, da wir da keine aktualisierten Werte erwarten.
Für GetDeviceData und GetChannelList würde es Sinn machen, die abzubolen, nachdem der TV einmal aus war und dann wieder an ist. Also 1 mal pro "Sitzung".

Was meint ihr?

Gesendet von meinem LG-D855 mit Tapatalk

Ja, es braucht definitv keine eigene Timerroutine, ich würde aber den RequestAccess-Call gerne vom Alter des letzten Calls abhängig machen und dafür einen Parameter/Attribut spendieren.
Mein Vorschlag - Man stellt auch ein Interval für RequestAccess ein (accessInterval) und die Timerroutine prüft dann ob dieses Alter schon überschritten ist. Dazu muss accessInterval grösser als interval sein (ich brauche nicht alle 15 Sekunden den Mute/Volume-Wert, da diese bei mir sowieso sinnlos sind (Audio läuft über HDMI an einer 5.1-Anlage).

Die Channellist würde ich normalerweise gar nicht regelmässig holen, sondern nur auf Anforderung und wenn keine Daten da sind.

GetDeviceData ebenfalls, ich baue dafür in Module normalerweise ein reset ein, mit dem man dafür sorgen kann, dass alle Daten neu geholt werden.

Also
- accessInterval neues Attribut (> interval)
- deviceData und channellist werden geholt wenn keine passenden Daten vorhanden sind oder nach reset oder auf expllizite Anforderung (set/get)
- access token wird neu angefordert, wenn älter als accessInterval
- Volume und Mute status werden bei jedem Durchlauf timer-Routine abgeholt

Alles natürlich nur wenn "present"