Better message handling, when performing get actions and better ping handling about rffhem HOT 12 CLOSED

Nachtrag:
durch die KeepAlive Routinen müsste es auch funktionieren ohne das der Arduino ein "alive" sendet.

from rffhem.

Ja, müsste man mal grob überlegen.
Aus meiner Sicht aber besser, man fragt den arduino ab und lässt ihn nicht automatisch was senden.
So ist man flexibel mit dem Intervall etc.

Dass wir nur etwas abfragen, wenn nichts empfangen wurde klingt plausibel.

In SIGNALduino_ReadAnswer sollte man auf einen Zeilenumbruch reagieren, das könnte ausreichend sein.

from rffhem.

Ich habe die notwendigen Änderungen in der SIGNALduino_ReadAnswer jetzt commited.
Damit funktioniert es bei mir seit 2 Tagen ohne Probleme. Es werden jetzt aus der Antwort vom get-Befehl alle Signal-Nachrichten rausgefiltert.

Es können vor der Antwort vollständige oder eine Signal-Nachricht ohne Anfang empfangen werden:

2016.01.22 03:56:23 3: sduino/RAW (ReadAnswerCut003 74): 5353534353535353535353434353434353435343434343535343535343534;CP=3;SP=0;O;�
O

Es können auch nach der Antwort Signal-Nachrichten empfangen werden:

2016.01.22 05:31:24 3: sduino/RAW (ReadAnswerCut002003): OK
�MS;P0=-1948;P1=495;P2=-972;P3=-3900;D=13101210121012121210121212121212121010121212121010101010101212101212101010;CP=1;SP=3;O;�

from rffhem.

OK, ich schau mir das noch mal genauer an.

Ich habe aber womöglich eine Ursache für zusammenhängende Übertragungen gefunden.

Wenn wir mit einem SET Befehl ein Kommando an den Arduino sendet, wird das Kommando quasi als Bestätigung zurück übermittelt.

Es fehlt aber meist ein readanswert, was dazu führt, dass der Befehl in der read routine verarbeitet wird.
Ich bin schon dabei, das an zu passen.

from rffhem.

Das ist mir nicht klar, vermutest Du den Fehler in der 00_SIGNALduino.pm oder in der Firmware im Arduino.
Ich würde in der dev32 Firmware keine große Änderungen mehr vornehmen, sie läuft mittlerweile sehr stabil.

from rffhem.

Es ist ein Fehler im Modul.
Die Firmware ist so ganz okay und stabil.

Vielleicht baue ich noch eine config Option ein, aber große Änderungen sind keine geplant

from rffhem.

Die Sache mit der ReadAnswer Routine gefällt mir nicht so richtig.
Eine Möglichkeit wäre, die Antworten in der read Routine rauszufiltern und im hash zu speichern.
In der get Routine müsste dann nach dem senden des Befehls per InternalTimer nach ca 1-3 Sekunden eine Routine aufgerufen werden in der geprüft wird ob die Antwort im hash ist.
Das Problem dabei ist, daß ich keine Möglichkeit gefunden habe, wie man die Antwort in einer Message Box ausgeben kann

from rffhem.

ReadAnswer ist die übliche Vorgehensweise. Es ist ja so. Es wird etwas gesendet, darauf kommt auch eine Antwort, aber die Antwort fangen wir nicht ab.

Die Antwort wird ja quasi als Bestätigung gesendet. Darauf kann man mit Readanswer gut prüfen. Ich hab mir deinen Commit angesehen. Ich kommentiere da gleich noch, ich verstehe den Ansatz nicht so ganz.

from rffhem.

da readAnswer nicht mehr verwendet wird und die ganze Kommunikation FHEM nicht mehr blockiert, können wir das Thema ja eigentlich schließen oder?

from rffhem.

für das dev-32 dürfte es soweit passen.

Für das dev-33 sehe ich noch optimierungs Potential.
Man könnte z.B. für Antworten einen neuen Nachrichtentyp z.B. "MA" einführen.
Damit müsste sich das parsen der Antworten vereinfachen.
Beim Getupdate sehe ich auch noch Optimierungspotential.

from rffhem.

Mittlerweile hast Du ja einiges optimiert. Fehlt noch was für 3.3.0 oder können wir das Thema erst mal als erledigt ansehen?

from rffhem.

es ist mittlerweile alles drin. Für mich ist das Thema erledigt.

from rffhem.