Plugin TEAC AG980

[henfri]

Hallo,

dass das Plugin nichts mehr machte lag am _lock.
So funktioniert der Code prinzipiell:

                        else:
                            self.log_debug('No response from ag980. Disconnecting')
                            self.disconnect()
                            self._lock.release()
                            self.log_debug('No response from ag980. Connect.ing')                            
                            self.connect()
                            self._lock.acquire()
                            self.send_bytes(packet_send)
                            counter=0

D.h. es wird ein Disconnect und ein connect gemacht, sowie das letzte Paket erneut gesendet.

Aber es scheint einfach nix vom TEAC zu kommen.

Das ist komisch. Auf dem Stammtisch hat es mit meinem Kabel und Lapheus RasPi und TEAC ja geklappt. Es kann also nur an meinem TEAC oder meinem Rechner liegen, oder?

Gruß,
Hendrik

[henfri]

Hallo,

es scheint jetzt erstmal wieder zu funktionieren, nachdem ich es von Windows aus probiert habe.
Vielleicht ein Wackelkontakt im Kabel, oder ein Schluckauf...

Werde berichten.

Gruß,
Hendrik

[henfri]

Und jetzt funktionierts nimmer.

Frustrierend. So kriegt man auch nen Tag rum. :-(

Vielleicht hat ja noch jemand eine Idee.

[callidomus]

Hallo Hendrik,

der Code in Post 15 enthält einige Stellen, die zu einem Deadlock führen können.
Das Lock wird ja per default gar nicht mehr freigegeben.
Ich denke man muss den Code noch einmal systematisch überarbeiten um das Locking in den Griff zu bekommen.

Am besten eignet sich normalerweise der Author dazu, ich könnte es theoretisch auch machen, habe aber leider keine Zeit.

Bis bald

Marcus

[henfri]

Hallo,

@Marcus: Danke für deinen Hinweis. Der Lock wird wieder freigegeben:
Direkt unter dem von mir geposteten code gibt es noch ein:

        finally:            
            # At the end, release the lock
            self._lock.release()

Aber ich gucke mir das noch mal mit frischem Gemüt an.
@Lapheus: zumindest das

self._statuslock = false

sollte nicht in die Funktion parse_response() sondern lieber so:

                # Parse response
                self.parse_response(packet)
                self._statuslock = false

Davon abgesehen habe ich aber den Fehler etwas eingrenzen können:
Du fragst so den Status ab:

                packet = bytearray()
                firstpartlen = 3
                while self.alive and len(packet) < firstpartlen:
                    try:
                        bytestoreceive = firstpartlen - len(packet)

(BTW: was soll die letzte Zeile? len(packet) ist doch immer 0).
und danach:

                #packet length fix at 20 bytes
                packetlen = 20

                # Try to receive the second part of the packet
                while self.alive and len(packet) < packetlen:
                    try:
                        #Receive next chunk
                        bytestoreceive = packetlen - len(packet)
                        self.log_debug('Trying to receive {} bytes for the second part of the response.'.format(bytestoreceive))
                        chunk = self.read_bytes(bytestoreceive)

also kurz: erst rufst du die ersten 3 byte ab und dann die nächsten 20.

Warum? Das funktioniert bei mir mit der seriellen Verbindung nicht. Wenn ich das ohne Plugin ausprobiere, meldet der TEAC nix mehr zurück statt den Statusstring.

Wenn ich nur die 20byte abrufe, dann klappt es zumindest in meinem test-skript schonmal.

Gruß,
Hendrik

[henfri]

@Lapheus:
Ich würde meine Erfahrungen gerne in deinen Code einpflegen. Kannst du obige Fragen beantworten, dann kann ich loslegen.

Gruß,
Hendrik

[Lapheus]

Hallo Henfri,

ich komm aktuell nicht dazu das nachzusehen.

Habe mir jetzt nur Deine Fragen dazu durchgesehen.

Erstens:
Die Abfrage der Daten erfolgt immer in zwei Schritten. In irgendeinem Tutoriell habe ich das so gelesen und mich dran gehalten. Hatte in meiner ersten Version das nicht so gemacht weil ich das nicht verstanden habe, ich hatte da auch Probleme das nichts mehr empfangen wird. Es muss bei Python wohl in zwei Schritten empfangen werden, da es sonst zu Problemen kommt, das Daten fehlen oder nicht alles empfangen wird. (Wie bei Dir?)

Zweitens:
Hast Du den Code aus dem Zip File aus Post 7 komplett eingefügt?
Wenn Du nur Teile kopiert hast, kann das Problem genau wie Du beschrieben hast vorkommen. Ich habe den Code sehr viel angepasst, einmal das Empfangen in zwei Schritten, einmal den Deadlock zu vermeiden.

Drittens:
Warum setze ich die Sperren so wie Sie sind?
Damit Sie genau das sperren was nicht sein soll. Während einer Status Abfrage darf nicht wieder in die send_command Funktion reingegangen werden. Dann erfolgt der Deadlock!
Wenn aber innerhalb der parse_response Funktion ein Wert geändert wird, geht es an der Stelle wieder in eine send_command Funktion (somit ein Deadlock), dann passiert genau das was Du beschreibst!

Nimm bitte die Dateien aus dem Zip File. Nutze keine KNX Anbindung, das funktionierte noch nicht zuverlässig, da ich durch die Items eine Sendeschleife über KNX erzeugt habe, das hatte ich auf dem Stammtisch beschrieben.
Wenn Du das über die CLI testest, sollte es keine Probleme geben. Ich habe das bei mir nicht mehr in einen Deadlock bekommen, wie auf dem Stammtisch zu sehen war.

Um über KNX zu testen, könntest Du die Items so anpassen das Du Sende- und Empfangs-Gruppenadressen unterschiedlich machst. Die Sende-Gruppenadresse ist die Status Adresse, die Empfangs-Gruppenadresse ist die "normale" Adresse.

Hoffe das ich am Sonntag dazu komme, danach zu schauen.

[henfri]

Hallo Frank,

Erstens:
Die Abfrage der Daten erfolgt immer in zwei Schritten. In irgendeinem Tutoriell habe ich das so gelesen und mich dran gehalten. Hatte in meiner ersten Version das nicht so gemacht weil ich das nicht verstanden habe, ich hatte da auch Probleme das nichts mehr empfangen wird. Es muss bei Python wohl in zwei Schritten empfangen werden, da es sonst zu Problemen kommt, das Daten fehlen oder nicht alles empfangen wird. (Wie bei Dir?)

Nein, bei mir ist es genau umgekehrt. Vielleicht ist es eine Eigenart der TCP-> Serial Verbindung?

Ich habe den Code jetzt so angepasst, dass es seriell zuverlässig funktioniert. Da ich davon ausgehe, dass es bei dir dann nicht mehr funktioniert habe ich eine Fallunterscheidung eingebaut.

Zweitens:
Hast Du den Code aus dem Zip File aus Post 7 komplett eingefügt?
Wenn Du nur Teile kopiert hast, kann das Problem genau wie Du beschrieben hast vorkommen. Ich habe den Code sehr viel angepasst, einmal das Empfangen in zwei Schritten, einmal den Deadlock zu vermeiden.

Ja, ich habe den Code aus Post 7 komplett verwendet/modifiziert

Drittens:
Warum setze ich die Sperren so wie Sie sind?
Damit Sie genau das sperren was nicht sein soll. Während einer Status Abfrage darf nicht wieder in die send_command Funktion reingegangen werden. Dann erfolgt der Deadlock!
Wenn aber innerhalb der parse_response Funktion ein Wert geändert wird, geht es an der Stelle wieder in eine send_command Funktion (somit ein Deadlock), dann passiert genau das was Du beschreibst!

Das ist soweit verstanden.

Ich halte es aber besser, dies so zu machen:

self._statuslock = False
#senden, empfangen
self.parse_response(packet, value)
self._statuslock = False

def parse_response(packet, value):
    bla
    blub

als so:

self._statuslock = False
#senden, empfangen
self.parse_response(packet, value)

def parse_response(packet, value):
    bla
    blub
    self._statuslock = False

Momentan wird parse_response ausschließlich in send_command aufgerufen. Somit sind beide Varianten identisch.

Wenn aber irgendwann parse_response auch in einer anderen Funktion aufgerufen wird, wird statuslock in parse_response auf False gesetzt, auch wenn die aufrufende Funktion das eigentlich noch gar nicht möchte.

Nimm bitte die Dateien aus dem Zip File. Nutze keine KNX Anbindung, das funktionierte noch nicht zuverlässig, da ich durch die Items eine Sendeschleife über KNX erzeugt habe, das hatte ich auf dem Stammtisch beschrieben.
Wenn Du das über die CLI testest, sollte es keine Probleme geben. Ich habe das bei mir nicht mehr in einen Deadlock bekommen, wie auf dem Stammtisch zu sehen war.

Bisher habe ich nur via CLI getestet. Und mit meiner Modifikation funktioniert das auch zuverlässig

Noch eine Frage:

                        while curentvol < value:
                            self.log_debug('Volume ist: "{}" und soll rauf auf "{}"'.format(curentvol, value))
                            self.send_command('mainvolumeup', value)
                            curentvol += 1

Theoretisch könnte hier ja mal etwas verschluckt werden. So ist das bei mir wenn ich die Kommandos einfach ohne Delay rausschicke.
Wäre es nicht besser, ein status-request abzusetzen und Volume zu aktualisieren?

Gruß,
Hendrik