Misterhouse: Überarbeitung der eibd-Kommunikation

[Pauker]

Hallo Jockel

welche Version des EIB_Device.pm verwendest Du?

[Pauker]

Eine etwas andere Merkwürdigkeit in der EIB Kommunikation

MH ließt ein Paket was MH selbst auf den Bus geschrieben hat. Im Gruppenmonitor gibt es aber nur einen Eintrag. Zeitgleich wurden noch drei weitere AnAusmeldungen geschrieben, die nicht wieder gelesen wurden.

15/04/10 10:00:00 EIB_Item.pm::set: state 'off' for '$ER_AnAus_E2_RB_Rotes_Bad'
15/04/10 10:00:00 EIB_Item.pm::set:self: EIB1_Item=HASH(0x9d78be0) state 'off' for setby:'' self:$ER_AnAus_E2_RB_Rotes_Bad'Target: $ER_AnAus_E2_RB_Rotes_Bad
15/04/10 10:00:00 EIB_Item.pm::set_receive: state 'off' for '$ER_AnAus_E2_RB_Rotes_Bad' item:EIB1_Item=HASH(0x9d78be0)

15/04/10 10:00:02 EIB_Device_Received packet:
15/04/10 10:00:02 EIB write from 0.0.0 to 3/3/225 : "off"
15/04/10 10:00:02 EIB_Item::receive_write_msg: new state off set on '$ER_AnAus_E2_RB_Rotes_Bad'
15/04/10 10:00:02 EIB_Item.pm::set_receive: state 'off' for '$ER_AnAus_E2_RB_Rotes_Bad' item:EIB1_Item=HASH(0x9d78be0)
15/04/10 10:00:02 EIB_Device_verarbeitet packet:

[mike]

Zur Ursache des Problems habe ich eine Idee. Ich habe letztens eine eibd-Kommunikation für einen Mikrokontroller geschrieben (ethersex). Da ist mir aufgefallen, dass ich das Protokoll evtl. nicht ganz verstehe oder das es da eine Lücke gibt.

Konkret geht es darum, das auf einer Netz-Verbindung sowohl gesendet als auch empfangen wird. Beim Senden eines Telegramms wird immer eine Quittung erwartet. Das müsste ich damals in den C-Sourcen so gesehen haben. Von alleine käme ich sicher nicht auf die Idee ...
In den aktuellen Sourcen von eibd kann ich im Client diese Quittung nicht mehr nachvollziehen. Der Empfang dieser Quittung könnte nun das Problem sein, da beim Empfang sowohl die Quittung kommen könnte als auch schon ein neues Telegramm. So zumindest meine Idee.

Um das auszuprobieren ändere bitte in EIB_Device.pm folgendes ab:

# Send group data
# sendGroup SOCK DEST DATA
sub sendGroup {
    my $Sock = shift;
    my $Dest = shift;
    my ($str) = @_;

    #print "SendGroupPacket: ", unpack("H*",$str), "\n";

    my @msg = (0x0027,$Dest);                   # EIB_GROUP_PACKET
    push @msg, $str;
    sendRequest ($Sock, pack "nna*", @msg);
!    #goto error unless my $answer = getRequest ($Sock);
!    #my $head = unpack ("n", $answer);
!    #goto error unless $head == 0x0027;
    return 1;

  error:
    print "sendGroup failed\n";
    return undef;
}

Wie du siehst wird einfach der Empfang der "Quittung" abgeschalten. Die "Quittung" wird dann ganz normal wie ein Telegramm empfangen und führt zu doppelten Ereignissen wenn mh die Ereignisquelle ist, was wir aber erst einmal ignorieren sollten.

Ich habe das bei mir ausprobiert und es funktioniert genauso wie vorher.
Bringt das bei dir eine Besserung?
Die erste Änderung (empfang vieler Telegramme auf einmal) bitte wieder rückgängig machen.

Mike

[mike]

MH ließt ein Paket was MH selbst auf den Bus geschrieben hat. Im Gruppenmonitor gibt es aber nur einen Eintrag. Zeitgleich wurden noch drei weitere AnAusmeldungen geschrieben, die nicht wieder gelesen wurden.

Das würde ja genau auf meine Vermutung passen. Ein Telegramm wird als "Quittung" misverstanden und die "Quittung" wird dann als Telegramm interpretiert.

Mehr möchte ich jetzt hier nicht spekulieren. Ich warte mal ab, ob die aktuelle Änderung was verbessert.

Mike

[Pauker]

Habe die Änderungen eingebaut.

[mike]

Ich weiß nicht wie stark dich die Echos stören werden. Vielleicht kannst du noch folgendes einbauen:

sub check_for_eibddata {
.
.
.
               my $msg = decode($data);
!                EIB_Item::receive_msg($msg) unless $msg->{'src'} eq "0.0.0";
.
.
}

d.h. es sollen nur die Telegramme verarbeitet werden, die nicht von 0.0.0 kommen ...

Nachteil: Das unterdrückt den Empfang aller Pakete die über eibd auf den Bus geschickt werden (also nicht nur mh-Telegramme).

Mike

[Pauker]

Ich weiß nicht wie stark dich die Echos stören werden. Vielleicht kannst du noch folgendes einbauen:

sub check_for_eibddata {
.
.
.
               my $msg = decode($data);
!                EIB_Item::receive_msg($msg) unless $msg->{'src'} eq "0.0.0";
.
.
}

d.h. es sollen nur die Telegramme verarbeitet werden, die nicht von 0.0.0 kommen ...

Nachteil: Das unterdrückt den Empfang aller Pakete die über eibd auf den Bus geschickt werden (also nicht nur mh-Telegramme).

Mike

Die Echos stehen nur im Log und Platz habe ich genug. Alte Testregel erst was ausschalten wenn es Funktioniert um den Fehler besser einzugrenzen. Ich bastele gerade eine Zentralfunktion zusammen die alle Rollläden zeitgleich durch mh schließt bzw öffnet um die Testinterwalle zu kürzen. Denn über die Rolläden lassen sich Fehler am besten lokalisieren. OE und UE können nicht gleichzeitig vorkommen.

[Pauker]

Die ersten Tests sehen sehr gut aus bislang keine Fehler.

[Pauker]

Gut der Fehler ist weg. 6 Fahrten aller Rollläden und der lauf heute Abend waren ohne Fehler.

[mike]

Na das ist doch toll!

Bleibt nur das Problem der Echos ... Das sollte man nicht unterschätzen. Wenn mit bestimmten Ereignissen etwas getriggert wird, dann ist das sehr schlecht, wenn Ereignisse doppelt kommen.

Ich werde die Version mit der Unterdrückung der 0.0.0-Ereignisse in Richtung Misterhouse-Repository auf den Weg schicken ...

Mike

[Jockel]

welche Version des EIB_Device.pm verwendest Du?

Das ist eine gute Frage Hier im Forum gibt es ja zu einigen MH Dateien neuere Varianten, die nicht im SVN zu finden sind. Ich weiß aber nicht mehr, ob die EIB_Device.pm auch dazu gehört.

Um sicher zu gehen hab ich die aktuelle Variante mal angehängt.

Ich werde die Änderungen bei mir auch einbauen und dann testen, weiß aber noch nicht ob ich heute oder norgen dazu kommen werde.

[Pauker]

Das ist eine gute Frage Hier im Forum gibt es ja zu einigen MH Dateien neuere Varianten, die nicht im SVN zu finden sind. Ich weiß aber nicht mehr, ob die EIB_Device.pm auch dazu gehört.

Ja, leider. Und bei der EIB_Items.pm gibt es noch mehr.

Um sicher zu gehen hab ich die aktuelle Variante mal angehängt.

Ich werde die Änderungen bei mir auch einbauen und dann testen, weiß aber noch nicht ob ich heute oder norgen dazu kommen werde.

Du hast die Version vom 24.08.2009 aus dem SVN Revision 1665
Wir arbeiten also an der selben Version. Damit wird das vergleichen der Ergebnisse erst möglich.

[Jockel]

Du hast die Version vom 24.08.2009 aus dem SVN Revision 1665
Wir arbeiten also an der selben Version. Damit wird das vergleichen der Ergebnisse erst möglich.

Danke, hab im Moment leider keinen Zugriff auf den Rechner um einen diff gehen das Repository machen zu können und hab die Datei aus dem gestrigen Backup genommen!

Vielleicht sollten wir mal einen anderen Thread aufmachen um die aktuellen Versionen der Dateien zu sammeln. Es gab ja auch mal den Ansatz die Änderungen ins Repository einzupflegen, da scheint es aber Lücken gegeben zu haben.

[mike]

Es gab ja auch mal den Ansatz die Änderungen ins Repository einzupflegen, da scheint es aber Lücken gegeben zu haben.

Das liegt daran, dass keiner von denen die hier was für MH entwickeln einen Zugang zum Repository haben. Man muss immer andere Leute anbetteln etwas ins Repository einzuchecken oder es wird mal was "aus versehen" ins Repository eingecheckt (wie beim Ajax-Kram passiert).

Du kannst auch bei einem alten Misterhouse die aktuellste EIB_Device.pm nehmen. Die passen zusammen. Du kriegst höchstens beim Start eine Meldung wegen eines geänderten Parameters ...

Mike

[Pauker]

@Mike

Ich finde man sollten MH dahin gehend verändern, dass man den Status der kommenden Pakete mit dem aktuellen Status vergleicht und sie verwirft, wenn es keine Änderung gegeben hat. Besser noch die Pakete werden nur verworfen, wenn sie gleich sind und vom eibd (0.0.0) kommen. Somit werden alle Änderungen erfasst.

Alternativ könnten nur die gelesenden Werte Statusmeldungen erzeugen. So erreicht man eine Kontrolle ob die Werte den Bus erreicht haben. Allerdings verliert man daduch die Information wer die Statusänderung ausgelöst hat.

Ich hoffe keinen Denkfehler gemacht zu haben.