Misterhouse: Überarbeitung der eibd-Kommunikation

[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.

Das könnte in der Praxis größtenteils funktionieren. Allerdings ist das aufwändig in der Auswertung.
Nachteil: Ein Ereignis mit einem Wert identisch zum aktuellen ist auch ein Ereignis. Wenn man das wegfiltert, dann funktionieren manche Logiken nicht.

Es müssen also genau die Ereignisse unterdrückt werden, die gerade geschickt worden sind. Ich denke das beste ist jedes gesendete Ereignis in einen Puffer zu schreiben und Ereignisse beim Empfang zu unterdrücken, wenn sie von 0.0.0 kommen und sich mit dem gleichen Wert im Puffer befinden. Dann natürlich aus dem Puffer entfernen. Steht kein Telegram bereit, dann den Puffer leeren (fallback bei ausbleibendem Echo).

Mal sehen ob ich irgendwann Zeit finde das einzubauen ...

Solange man mit MH exklusiv auf einen eibd geht, ist die aktuelle Version vollkommen ausreichend.

[Pauker]

Das könnte in der Praxis größtenteils funktionieren. Allerdings ist das aufwändig in der Auswertung.
Nachteil: Ein Ereignis mit einem Wert identisch zum aktuellen ist auch ein Ereignis. Wenn man das wegfiltert, dann funktionieren manche Logiken nicht.

Stimmt, alle Logiken mit state_now werden so ausgebremst.

Es müssen also genau die Ereignisse unterdrückt werden, die gerade geschickt worden sind. Ich denke das beste ist jedes gesendete Ereignis in einen Puffer zu schreiben und Ereignisse beim Empfang zu unterdrücken, wenn sie von 0.0.0 kommen und sich mit dem gleichen Wert im Puffer befinden. Dann natürlich aus dem Puffer entfernen. Steht kein Telegram bereit, dann den Puffer leeren (fallback bei ausbleibendem Echo).

Mal sehen ob ich irgendwann Zeit finde das einzubauen ...

Wenn das Echo ausbleibt sollte man dann aber eine Fehlermeldung im Log erzeugen.

Solange man mit MH exklusiv auf einen eibd geht, ist die aktuelle Version vollkommen ausreichend.

Richtig.

Unsere Ansätze unterscheiden sich nur in dem separaten Puffer und dem Zeitfaktor oder?

Daher wollte die EIB_Items.pm in diesem sub ändern:
sub set_receive {
my ($self, $state, $set_by, $target) = @_;

&main:rint_log ("EIB_Item.pm::set_receive: state '$state' for '$self->{object_name}' item:$self") if $main::config_parms{eib_errata} >= 3;
return if &main::check_for_tied_filters($self, $state, $set_by);
# Set target to symbolic item name, if possible
$target = $self->{groupaddr} unless (defined $target);
$target = &printname($target);

#
# An dieser Stelle müssten alle Werte für den Vergleich vorliegen.
#

&Generic_Item::set_states_for_next_pass($self, $state, $set_by, $target);


}
Bleibt das Zeitproblem...

[mike]

In der EIB_Items.pm würde ich nichts ändern wollen, da das Problem der Echos ein reines Kommunikatonsproblem ist, was daher in der EIB_Device.pm abgehandelt werden sollte. Dort auch nur innerhalb der eibd Kommunikation und nicht im BCU1-Zweig.

Ich habe das mal implementiert. Bitte testen! (Bei mir läuft das ok).

Die Änderung von gestern habe ich schon in Richtung Repository geschickt. Mit dieser Änderung warte ich mal noch ein paar Tage ob alles stabil ist, dann schicke ich die auch weiter ...

Mike

Der Patch ist auf EIB_Device.pm Revision 1665 anzuwenden.

[Pauker]

@ Mike

habe den diff eingespiel sieht auf den ersten Blick gut aus.

Ich finde das zurückschreiben der Werte aber eher gut. Es ist eine qualifizierte Sendebestätgung. Beim set werden in MH immer ein set_receive aufgerufen um die Werte zu aktualisieren. Allerdings ohne Kontrolle ob es tatsächlich gesendet wurde.

Jetzt könnte man einen Schritt weitergehen und in der EIB_Items.pm den set_recive im sub set entfernen. In der EIB_Device.pm über den Vergleich von gesendet zu empfangen den "ürsprünglichen" Sender setzen.
Denn dann heißt der LOGeintrag nicht nur ich habe versuch den Taster zu drücken, sondern ich habe gedrückt.

Besser noch wenn es Fehlschlägt: Drücken hat nicht funktioniert.

[mike]

Jetzt könnte man einen Schritt weitergehen und in der EIB_Items.pm den set_recive im sub set entfernen. In der EIB_Device.pm über den Vergleich von gesendet zu empfangen den "ürsprünglichen" Sender setzen.
Denn dann heißt der LOGeintrag nicht nur ich habe versuch den Taster zu drücken, sondern ich habe gedrückt.

Das hat aber ein paar "Unschönheiten" zur Folge:
- Der Offline-Modus funktioniert nicht mehr
(Suche mal in EIB_Items.pm nach 'offline')
- Im Browser siehst du die Änderungen nicht mehr. Das liegt daran, dass die neue Seite in der Regel nach dem Ausführen des Kommandos aufgebaut wird. In dem Augenblick kam aber noch nicht die Rückmeldung vom eibd, so das der neue Status noch nicht verfügbar ist. Du musst also auf "Lampe An" drücken und danach die Seite aktualisieren um zu sehen ob die Lampe wirklich an ist.

Daher ist eine solche Änderung meiner Meinung nach nicht zu vertreten.
Aber es ist ja Open Source, probier es doch einfach mal aus.

Vorher kannst du ja mal testen wieviele Telegramme nicht rückgemeldet werden. Wenn die suppressqueue geleert wird, da keine Telegramme mehr kommen aber immer noch zu unterdrückende Telegramme vorliegen, dann kommt eine Meldung:

Suppress queue cleared

Interessant wäre es wie häufig am Tag diese Meldung kommt.

Mike

[Pauker]

Das hat aber ein paar "Unschönheiten" zur Folge:
- Der Offline-Modus funktioniert nicht mehr
(Suche mal in EIB_Items.pm nach 'offline')
- Im Browser siehst du die Änderungen nicht mehr. Das liegt daran, dass die neue Seite in der Regel nach dem Ausführen des Kommandos aufgebaut wird. In dem Augenblick kam aber noch nicht die Rückmeldung vom eibd, so das der neue Status noch nicht verfügbar ist. Du musst also auf "Lampe An" drücken und danach die Seite aktualisieren um zu sehen ob die Lampe wirklich an ist.

Diesen Modus kenne ich nicht. Deaktiviert man damit die Kommunikation zum Testen? Das ist aber kein Problem, wenn der 'offline' Modus gesetzt wird aktiviert man das set_recive wieder.
Das sehe ich etwas anders, denn ich sehe nur das ich die Taste gedrückt habe, mit der ich die Lampe schalten will. Ich habe keinerlei Auskunft darüber ob MH die Meldung auch an den Bus gesendet hat. Das ist ein Unterschied. Kann man keine zeitliche Verzögerung (1 sec) in die Aktualisierung setzen. Eine echte Meldung ob der Aktor geschaltet hat bekommt bekommt man sowieso nur über ein Statusobjekt. Das wird in der Weboberfläche leider auch erst nach einer Aktualisierung sichtbar.

Vorher kannst du ja mal testen wieviele Telegramme nicht rückgemeldet werden. Wenn die suppressqueue geleert wird, da keine Telegramme mehr kommen aber immer noch zu unterdrückende Telegramme vorliegen, dann kommt eine Meldung:

Suppress queue cleared

Interessant wäre es wie häufig am Tag diese Meldung kommt.

Das werde ich tun.

[aggie89go]

Sobald ich wieder zu Hause bin muß ich wohl unbedingt mal schauen, wie meine EIB_Devices aussieht und ggf. aktualisieren ...
Haltet uns auf dem Laufenden!

[Pauker]

Die ersten Daten mit dem EIB_Device.pm:
16/04/10 19:15 Beginn der Auswertung
16/04/10 21:30:02 Suppress queue cleared (EIB5 nach Senden bei 01sec Paket danach wars bei 03 sec)
16/04/10 23:42:02 Suppress queue cleared (EIB5 nach Senden bei 01sec Paket danach wars bei 05 sec)
16/04/10 23:45:02 Suppress queue cleared (EIB5 nach Senden bei 01sec Paket danach wars bei 05 sec)
17/04/10 02:06:02 Suppress queue cleared (EIB5 nach Senden bei 01sec Paket danach wars bei 04 sec)
17/04/10 02:12:02 Suppress queue cleared (EIB5 nach Senden bei 00sec Paket danach wars bei 06 sec MH hat hier 5sec Pause gemacht)
17/04/10 03:24:02 Suppress queue cleared (EIB5 nach Senden bei 00sec Paket danach wars bei 06 sec MH hat hier 5sec Pause gemacht)
17/04/10 03:36:02 Suppress queue cleared (EIB5 nach Senden bei 01sec Paket danach wars bei 05 sec)

17/04/10 04:24:02 Suppress queue cleared (EIB5 nach Senden bei 01sec Paket danach wars bei 04 sec)
17/04/10 04:24:06 Suppress queue cleared (EIB5 nach Senden bei 06sec Paket danach wars bei 06 sec)
Besonderheit es standen drei Werte zum schreiben der dritte wurde nach dem Emfang eines anderen Paketes gesendet und "Richtig" verworfen.


Zwei Werte zum Schreiben 04:30:00 erstellt
7/04/10 04:30:00 weather_rrd: updating weather graphs
17/04/10 04:30:00 Paused for 5 seconds
17/04/10 04:30:01 EIB_Device_schreiben: HASH(0x9962678)
17/04/10 04:30:01 EIB_Device_Sending packet:
17/04/10 04:30:02 Suppress queue cleared
17/04/10 04:30:04 EIB Device__Daten vom Bus..
17/04/10 04:30:04 EIB_Device_Received packet:
1.Wert
17/04/10 04:30:04 EIB_Device_verarbeitet packet: ¼
17/04/10 04:30:06 EIB_Device_schreiben: HASH(0xa13ab78)
17/04/10 04:30:06 EIB_Device_Sending packet:
17/04/10 04:30:06 Suppress queue cleared
17/04/10 04:30:06 EIB Device__Daten vom Bus..
17/04/10 04:30:06 EIB_Device_Received packet:
2.Wert
17/04/10 04:30:06 EIB_Device_verarbeitet packet:


17/04/10 06:12:02 Suppress queue cleared
17/04/10 06:12:06 Suppress queue cleared
Wie oben Das Muster setzt sich fort

17/04/10 06:36:02 Suppress queue cleared
17/04/10 06:36:06 Suppress queue cleared
Muster oben
17/04/10 07:12:02 Suppress queue cleared
17/04/10 07:12:06 Suppress queue cleared
Muster oben
17/04/10 08:27:02 Suppress queue cleared (EIB5 nach Senden bei 01sec Paket danach wars bei 05 sec)
Besonderheit hier: Vier EIB5 Werte zum Schreiben. Eintrag ist zwischen dem ersten Wert. Die weiteren vier Werte wurden geschrieben und "Richtg" verworfen.
17/04/10 09:36 Ende der Auswertung

Fazit: Alle Werte waren EIB5

[Jockel]

Die Änderungen hab ich jetzt auch mal eingebaut. Ein kurzer Test hat aber schon gezeigt, daß MH weiterhin Telegramme unterschlägt.

[Pauker]

Sicher, dass MH die Telegramme unterschlägt?

Ich kann keine Unterschlagungen mehr ermitteln.

Wenn in der EIB_Item der Code wie folgt abgeändert wird:

sub sendRequest {
    my $Sock = shift;
    my ($str) = @_;
 !   &main::print_log("EIB_Device_Sending packet:....") if $main::config_parms{eib_errata} >= 5;
    my $size = bytes::length($str);
    my @head = (($size >> 8) & 0xff, $size & 0xff);
    return undef unless syswrite $Sock, (pack "CC", @head);
    return undef unless syswrite $Sock, $str;
}

# Gets a request from eibd
# DATA = getRequest SOCK
sub getRequest {
    my $Sock = shift;
    my ($data);
    goto error unless sysread $Sock, $data, 2;
    my $size = unpack ("n", $data);
    goto error unless sysread $Sock, $data, $size;
!    &main::print_log("EIB_Device_Received packet:.....") if $main::config_parms{eib_errata} >= 5;
    return $data;

  error:
    printf "eibd communication failed\n";
    return undef;
}

(Änderungen mit ! markiert) Sieht man wenn etwas von MH gelesen oder geschrieben wird.
Paralell dazu legt man die Kommunikation der ETS für den Gruppenmonitor auf den eibd. Jetzt das Testsignal senden und den Gruppenmonitor/Log beobachten.

Wenn dann Einträge im Gruppenmonitor ohne passenden Logeintrag bei MH "EIB_Device_Received packet:...." auftauchen liegt es an MH.

Wenn nicht an der Kommunikationsschnittstelle.