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

[cartzilla]

Du kannst Dir so zumindest der Plan alles sparen, wenn Du das Attribut interval setzt - wenn das alles dann regelmässig ausgeführt wird
regelmässig:
  - presence
  - deviceData und access
  - mute/volume
einmalig
- wenn channellist nicht da wird auch die geladen (default oder was im attribut steht)

Ist das nicht ein Problem mit einer einzigen generellen Intervallangabe?
Nach einem WakeUp sollte der Abfrageintervall doch ziemlich niedrig (alle paar Sekunden) sein, um nicht ewig auf erfolgreichen access zu warten. Setzt man das Intervall dann aber so kurz an, ist das eine ziemliche Rechnerbelastung durch die ständigen Abfragen, wenn der TV im Standby ist.

Wäre es nicht vorteilhaft das Modul so weiterzuentwicklen, dass es den Zustand TV present aber kein access (clientid = ?) gar nicht mehr geben kann, sprich bei einer Änderung der presence auf present automatisch ein get access (durch internen eventhandler) erfolgt ? get access also nur noch eine interne Methode ist!

[cartzilla]

Achte mal auf die Zeit, die dein TV zwischen wakeUp und get Access benötigt [emoji106]

Sind nur ein paar Sekunden bis nach einem wakeUp get presence eine presence = present liefert.
Diesmal hat das Modul (mit gesetztem attribut channellist) übrigens die Sendernamen nach dem get access korrekt automatisch eingelesen, komisch...

[viegener]

Ist das nicht ein Problem mit einer einzigen generellen Intervallangabe?
Nach einem WakeUp sollte der Abfrageintervall doch ziemlich niedrig (alle paar Sekunden) sein, um nicht ewig auf erfolgreichen access zu warten. Setzt man das Intervall dann aber so kurz an, ist das eine ziemliche Rechnerbelastung durch die ständigen Abfragen, wenn der TV im Standby ist.

Wäre es nicht vorteilhaft das Modul so weiterzuentwicklen, dass es den Zustand TV present aber kein access (clientid = ?) gar nicht mehr geben kann, sprich bei einer Änderung der presence auf present automatisch ein get access (durch internen eventhandler) erfolgt ? get access also nur noch eine interne Methode ist!

Ich habe das natürlich verkürzt dargestellt - die wahrheit steht im Code
Wenn der Loewe nicht "present" ist wird natürlich kein access/etc aufgerufen - das wäre ja auch ziemlich sinnfrei und kämme immer mit no route to host oder ähnlichem zurück

Und ja das Modul führt bereits automatisch ein getAccess durch wenn bisher noch nicht gemacht. Das Problem ist ja zu erkennen, wenn das aktuelle Token (access) nicht mehr gültig ist, denn das ist nicht nach festen Regeln der Fall und der Loewe antwortet bei mir dann auch gerne einfach mit leeren Listen und nicht mit einem Fehler

[der.einstein]

Hallo CoolTux oder viegener,
Könnt ihr bitte die Änderungen mit ins GitHub mergen?
Steht dem irgendwas entgegen?

Danke.

[viegener]

Hallo CoolTux oder viegener,
Könnt ihr bitte die Änderungen mit ins GitHub mergen?
Steht dem irgendwas entgegen?

Danke.

Sieht erstmal gut aus, ich mische die Änderungen mal ein 

[viegener]

Version 44 in github eingechecked - habe allerdings nur einen syntaxcheck gemacht - konnte die Befehle nicht wirklich ausprobieren
mit den Änderungen von der.einstein

[cartzilla]

Du kannst Dir so zumindest der Plan alles sparen, wenn Du das Attribut interval setzt - wenn das alles dann regelmässig ausgeführt wird
regelmässig:
  - presence
  - deviceData und access
  - mute/volume
einmalig
- wenn channellist nicht da wird auch die geladen (default oder was im attribut steht)

Habe jetzt mal versucht das Attribut interval in fhem.cfg zu setzen (Versuche mit den Werten 30 und 300) -> FHEM hängt sich komplett auf!

[cartzilla]

Version 44 in github eingechecked - habe allerdings nur einen syntaxcheck gemacht - konnte die Befehle nicht wirklich ausprobieren
mit den Änderungen von der.einstein

Funktioniert bei mir gut. Bin gerade dabei mich in Perl und FHEM-Modulprogrammierung etwas einzuarbeiten und habe daraufhin mir gleich den Code vorgenommen. Für set on folgender Vorschlag mit internalTimer:

Timerfunktion im entsprechenden Bereich deklarieren:

Code Auswählen Erweitern


sub LoeweTV_Activate($@);

Die eigentliche Timerfunktion mit Selbstreferenzierung (wenn nach Ablauf der Wartezeit, TV immer noch nicht präsent, dann einfach nochmals warten):

Code Auswählen Erweitern


# method to activate tv
sub LoeweTV_Activate($@) {

    my $hash = shift;

    LoeweTV_Presence($hash);
    if(LoeweTV_IsPresent( $hash )) {
      LoeweTV_SendRequest($hash,"RequestAccess" );
      LoeweTV_SendRequest($hash,"InjectRCKey", 22 );
    } else {
      InternalTimer( gettimeofday()+5, "LoeweTV_Activate", $hash, 1 );
    }

}


Das ganze als set on einbinden (entsprechenden Bereich so anpassen):

Code Auswählen Erweitern


...
    } elsif( lc $cmd eq 'on' ) {
        return "$cmd does not accept any arguments" if ( ( defined( $args[0] ) ) );
        LoeweTV_WakeUp_Udp($hash,$hash->{TVMAC},'255.255.255.255') if( defined($hash->{TVMAC}) );
        InternalTimer( gettimeofday()+5, "LoeweTV_Activate", $hash, 1 );
...


Bei mir klappt damit das Einschalten der Glotze.
PS: Es wäre wohl noch ganz gut, in LoeweTV_Activate einen Zähler einzubauen und bei einem gesetzten Maximalwert mit Fehler abzubrechen. Falls der WakeUp aus irgendeinem Grunde nicht klappt, gibt's ansonsten eine Endlosreferenzierung.

[CoolTux]

Code Auswählen Erweitern


sub LoeweTV_Activate($);
...


# method to activate tv
sub LoeweTV_Activate($) {

    my $hash = shift;
...

[cartzilla]

Noch eine Frage zur LoeweTV_TimerStatusRequest:
Am Anfang wird dort mit LoeweTV_IsPresent die presence abgefragt. Die liest doch aber nur die Variable aus und gibt daher nicht unbedingt den aktuellen Status wieder. Erst am Ende der Routine wird mit LoeweTV_Presence($hash) die Statusvariable aktualisiert. Sollte LoeweTV_Presence($hash) nicht besser am Anfang der Routine stehen, damit die Abfrage nicht auf einem veralteten Stand durchgeführt wird?

[der.einstein]

Noch eine Frage zur LoeweTV_TimerStatusRequest:
Am Anfang wird dort mit LoeweTV_IsPresent die presence abgefragt. Die liest doch aber nur die Variable aus und gibt daher nicht unbedingt den aktuellen Status wieder. Erst am Ende der Routine wird mit LoeweTV_Presence($hash) die Statusvariable aktualisiert. Sollte LoeweTV_Presence($hash) nicht besser am Anfang der Routine stehen, damit die Abfrage nicht auf einem veralteten Stand durchgeführt wird?

Sehe ich auch so. Ich würd's auch lieber am Anfang abfragen.

Gesendet von meinem LG-D855 mit Tapatalk

[viegener]

Sehe ich auch so. Ich würd's auch lieber am Anfang abfragen.

Gesendet von meinem LG-D855 mit Tapatalk

Presence-Abfrage ist asynchron, es am Anfang zu starten macht deshalb keinen Sinn, genau deshalb steht es am Ende.
Die weiteren Abfragen lassen sich aber so auch nicht in den BlockingCall für presence einbinden.

Deshalb prüfe letzten Status am Anfang - führe Operationen durch wenn present - und am Ende neue Präsenzabfrage starten, die hoffentlich vor dem nächsten Durchlauf aktiv ist.

Ich empfehle euch mal im wiki die Developer Infos durchzugehen und auch zu BLocking call zu lesen https://wiki.fhem.de/wiki/Blocking_Call
FHEM ist inhärent single threaded, damit sind alle blockierenden Operationen asynchron auszuführen (das gilt übrigens auch für die http-Abfragen)

[viegener]

Funktioniert bei mir gut. Bin gerade dabei mich in Perl und FHEM-Modulprogrammierung etwas einzuarbeiten und habe daraufhin mir gleich den Code vorgenommen. Für set on folgender Vorschlag mit internalTimer:

Timerfunktion im entsprechenden Bereich deklarieren:

Code Auswählen Erweitern


sub LoeweTV_Activate($@);

Die eigentliche Timerfunktion mit Selbstreferenzierung (wenn nach Ablauf der Wartezeit, TV immer noch nicht präsent, dann einfach nochmals warten):

Code Auswählen Erweitern


# method to activate tv
sub LoeweTV_Activate($@) {

    my $hash = shift;

    LoeweTV_Presence($hash);
    if(LoeweTV_IsPresent( $hash )) {
      LoeweTV_SendRequest($hash,"RequestAccess" );
      LoeweTV_SendRequest($hash,"InjectRCKey", 22 );
    } else {
      InternalTimer( gettimeofday()+5, "LoeweTV_Activate", $hash, 1 );
    }

}


Das ganze als set on einbinden (entsprechenden Bereich so anpassen):

Code Auswählen Erweitern


...
    } elsif( lc $cmd eq 'on' ) {
        return "$cmd does not accept any arguments" if ( ( defined( $args[0] ) ) );
        LoeweTV_WakeUp_Udp($hash,$hash->{TVMAC},'255.255.255.255') if( defined($hash->{TVMAC}) );
        InternalTimer( gettimeofday()+5, "LoeweTV_Activate", $hash, 1 );
...


Bei mir klappt damit das Einschalten der Glotze.
PS: Es wäre wohl noch ganz gut, in LoeweTV_Activate einen Zähler einzubauen und bei einem gesetzten Maximalwert mit Fehler abzubrechen. Falls der WakeUp aus irgendeinem Grunde nicht klappt, gibt's ansonsten eine Endlosreferenzierung.

Ich würde den activate call nicht so einbauen:
- Hier kommen sich unter Umständen mehrere sendRequest ins Gehege und auch mehrere Datenabfragen, es wäre besser das im aktuellen Timer abzubilden und damit das Polling des Status nicht durchzuführen, wenn gerade ein activate-wakeupEinschalten läuft
- Der RequestAccess sollte besser automatisch eingestreut werden, wenn das aktuelle Token nicht valide ist oder keines vorliegt
- Selbst wenn es keine Grenze gibt, aber ich würde lieber vermeiden viele Timer in einem Modul zu haben, da sich dadurch zusätzliche Fehlerquellen ergeben

[viegener]

Habe jetzt mal versucht das Attribut interval in fhem.cfg zu setzen (Versuche mit den Werten 30 und 300) -> FHEM hängt sich komplett auf!

Kannst Du das genauer beschreiben, was heisst aufhängen? --> Was steht im Log ? Ist es blockiert? Für wielange? stürzt FHEM ab?

Es würde helfen, wenn DU das verbose level mal auf 4 oder sogar 5 für den Loewe Device setzt und dann den Log-Teil nach aktivieren von interval hier bereitstellst.

Die Loewe Chassis verhalten sind offensichtlich in vielerlei Hinsicht unterschiedlich und fürs debuggen kann ich nur mein Chassis verwenden, cooltux hat sogar gar keine Möglichkeit real zu debuggen (oder hast DU Dir inzwischen einen loewe zugelegt  )

[cartzilla]

FHEM ist inhärent single threaded, damit sind alle blockierenden Operationen asynchron auszuführen (das gilt übrigens auch für die http-Abfragen)

Das habe ich auch schon aus den Developertexten mitbekommen. Ich verstehe jetzt bloss nicht warum der Aufruf von LoeweTV_Presence am Ende der Funktion statt am Anfang einen Unterschied in der "Asynchronität" macht ? Ok, die Zeit zwischen zwei Aufrufen der Funktion soll also genutzt werden für die eigentliche Presence-Abfrage.
Naja, richtig optimal ist das aber auch nicht. Wäre es dann nicht besser in der Funktion LoeweTV_PresenceDone die anstehenden Jobs zu erledigen?