Misterhouse: Überarbeitung der eibd-Kommunikation

[mike]

Als ich die erste Variante der eibd-Anbindung implementiert habe, wusste ich noch nicht so genau, was eigentlich alles gebraucht wird.

Da Misterhouse nur die Gruppenkommunikation verwendet, kann die Anbindung einfacher über einen Group-Socket erfolgen. Das habe ich nun implementiert.

Seiteneffekte:
- mh.ini eib_device in eib_connection umbenannt - der Parameter eib_device beißt sich mit den Generic_device und gibt eine unverständliche Fehlermeldung
- Pakete die auf den Bus gesendet werden, kommen nicht mehr als Echo zu Misterhouse zurück. Da bisher für den Telegrammempfang ein Busmonitor verwendet wurde, sah man immer die eigenen gesendeten Telegramme. Das man das jetzt nicht mehr sieht ist ein Vorteil, da es die Zahl der Events im MH verringert.

Bitte (mutige) Tester mal den Patch einspielen und Probleme melden. Bei mir läuft das seit einem halben Jahr ohne Probleme. Ansonsten schiebe ich das in rund einer Woche "upstream" (wie man so schön sagt).

[chrismave]

Als ich die erste Variante der eibd-Anbindung implementiert habe, wusste ich noch nicht so genau, was eigentlich alles gebraucht wird.

Da Misterhouse nur die Gruppenkommunikation verwendet, kann die Anbindung einfacher über einen Group-Socket erfolgen. Das habe ich nun implementiert.

Seiteneffekte:
- mh.ini eib_device in eib_connection umbenannt - der Parameter eib_device beißt sich mit den Generic_device und gibt eine unverständliche Fehlermeldung
- Pakete die auf den Bus gesendet werden, kommen nicht mehr als Echo zu Misterhouse zurück. Da bisher für den Telegrammempfang ein Busmonitor verwendet wurde, sah man immer die eigenen gesendeten Telegramme. Das man das jetzt nicht mehr sieht ist ein Vorteil, da es die Zahl der Events im MH verringert.

Bitte (mutige) Tester mal den Patch einspielen und Probleme melden. Bei mir läuft das seit einem halben Jahr ohne Probleme. Ansonsten schiebe ich das in rund einer Woche "upstream" (wie man so schön sagt).

Hallo Mike,
hört sich gut an würde ich auch testen aber kannst du bitte mal erklären was ich Dummy genau machen muss, ich verstehe nur Bahnhof. Was muss ich wo umbennen und mit deinem ersetzen?!


Ergänzung:

Ich tausche in meiner mh.ini unter "Catergory = EIB" eib_device in eib_connection, richtig?

Dann schreibe ich deine EIB_Device.txt als eib_device.pm in mein mh/bin verzeichniss wo auch die mh.ini liegt,oder?


Danke Christoph

[mike]

Die Datei EIB_Device.txt enthält einen Patch auf die lib/EIB_Device.pm vom misterhouse Hauptzweig. Da sich EIB_Device.pm aber seit ewigkeiten nicht geändert hat, sollte der Patch auf alle Versionen von Misterhouse anwendbar sein.

Zum Einspielen:
cd MISTERHOUSEHOME # wo immer das ist
cd lib
cp EIB_Device.pm EIB_Device.pm_safe # Sichern der originalen Datei
patch -p2 < EIB_Device.txt

Das wars.

Wenn "patch" nicht auf dem Rechner installiert ist, kann man auch die komplette Version von EIB_Device.pm direkt ins lib-Verzeichnis einspielen. Ich habe diese hier angehangen.

[chrismave]

O.K. habe die entsprechenden Dateien in meiner VirtualBox Installation gefunden, setze das heute Abend mal bei mir zu Hause zum testen um.

Vielen Dank.

Christoph

[chrismave]

So, ich habe das mal gemacht,
Mh läuft wieder und das was schon mal gut funktioniert ist die Tatsache das ich Telegramme aus der ETS nicht zweimal über den Bus gehen sprich als "send" und "read"!

Schauen wir mal weiter!

Gruß
Christoph

[aggie89go]

Bei mir läuft's auch seit 24h ohne Probleme.

[mike]

Ich schicke das jetzt Upstream ...

[Pauker]

Hallo, ich habe einige Probleme mit der Kommunikation zwischen MH und dem EIB Bus.

Ich verwende deine EIB_Device.pm und habe leider folgendes festgestellt:

MH unterschlägt Telegramme.

Den eibd und die Schnittstelle habe ich über den Gruppenmonitor der ETS ausschließen können:
Gruppenmonitor parallel zu Misterhouse an den eibd und in der ETS sind die Telegramme da und in Misterhouse nicht.

Mh hat wohl ein Timingproblem, denn bei mir liegt es vermutlich an der Menge von Telegrammen. Zumindest lässt sich der Fehler hier an besten beobachten. Wenn ich meine 17 Rollläden zeitgleichen öffne kommen die Statusmeldungen der Aktoren oder andere Telegramme nicht vollständig in MH an. Im Gruppenmonitor der ETS sind die Statusmeldungen vorhanden.

Meine eibd starte ich über:
eibd -D -T -S -d -i --pid-file=/var/run/eibd.pid usb:1:3:1:0

[mike]

Gruppenmonitor parallel zu Misterhouse an den eibd und in der ETS sind die Telegramme da und in Misterhouse nicht.

Woher weißt du das die Telegramme in Misterhouse nicht ankommen?

Hast du eib_errata auf 3 gesetzt?
Kannst du mal die Ausgaben des Gruppenmonitors und die log-Ausgaben von Misterhouse hier einstellen?

Mike

[chrismave]

H
MH unterschlägt Telegramme.

Soweit ich dich verstehe siehst du die Telegramme nicht im Terminalfenster, das ist bei mir auch so, sondern du siehst soweit ich das weis nur welche die mh selbst generiert und welche die nicht in deiner eib_items hinterlegt sind.

Sprich wenn ich ein telegramm über eibd von der ETS aus sende dann geht das z.B. Licht an der Status in der Visu ändert sich nach dem neu laden aber im terminal Fenster siehst du das telegramm nicht!

Ich hoffe das hilft ein wenig!

Gruß
Christoph

[Pauker]

Danke fürs antworten.

In der zip Datei sind Ausschnitte aus dem Gruppenmonitor und aus dem Printlog. Die entscheidene Zeile habe ich in beiden Dateien kenntlich gemacht. Es gehen definitiv Telegramme in MH verlohren. Der Fehler tritt besonders bei viel Buslast auf. Aber auch bei weniger Last ist der Fehler schon aufgetreten (Effekt war eine kalte Dusche) die Heizungsregelung hat die Umschaltung der Warmwasseranforderung nicht mitbekommen. Seit dem versuche ich das Problem zu lösen.


Zum besseren Verstendnis der MH Printlogeinträge:

Der Sub der die Logeinträge erzeugt:
sub check_for_eibddata {
my ($rin, $rout, $ein, $eout, $win, $wout);
my ($nfound, $nread);
my ($buf);

openEIBSocket () unless $EIBSock;
if ($EIBSock) {
# Check for input
$rin = $win = $ein = '';
vec($rin, fileno($EIBSock), 1) = 1;
$ein = $rin;
($nfound) = select($rout=$rin, undef, undef, 0);
if ($nfound > 0) {
&main:rint_log("EIB Device__Daten vom Bus.. ") if $main::config_parms{eib_errata} >= 5;
if (my $buf = getGroup_Src ($EIBSock)) {
# Modify data to make it compatible to data from BCU1
my @tmpdat = unpack ("nna*", $buf);
my $data = pack "CCnnCa*", 0xbc, 0x00, $tmpdat[0], $tmpdat[1], 0xe1, $tmpdat[2];
#print "Modified packet: ", unpack("H*",$data), "\n";
my $msg = decode($data);
EIB_Item::receive_msg($msg);
&main:rint_log("EIB_Device_verarbeitet packet: $data") if $main::config_parms{eib_errata} >= 5;

} else {
# Close socket in case of errors
close $EIBSock;
$EIBSock = undef;
}
}
}

openEIBSocket () unless $EIBSock;

if ($EIBSock) {
# Check for output
$count++ unless $count > $::config_parms{eib_send_interval};
if (($#outqueue >= 0) && $count >= $::config_parms{eib_send_interval}) {
$count = 0;
my $mref = shift @outqueue;
&main:rint_log("EIB_Device_schreiben: $mref ") if $main::config_parms{eib_errata} >= 5;
if (!writeeibd(encode ($mref))) {
# Close socket in case of errors
close $EIBSock;
$EIBSock = undef;
}
}
}

}

@chrismave: Leider nicht Aber Danke darüber bin ich auch am Anfang gestolpert.

[mike]

Das Problem ist mir noch nie aufgefallen ...

In EIB_Device.pm ist der Telegrammempfang so programmiert, das je Hauptschleife ein Telegramm abgeholt wird. Wenn die Telegramme nun viel schneller kommen als die Hauptschleife läuft, dann werden wohl Telegramme verworfen.

Interessant wären nun 2 Sachen:
1.) Ist deine Hauptschleife so aufgebläht (mit irgendwelchen Logiken) dass sie so langsam ist? Auf was für einer Hardware läuft Misterhouse?
2.) Was passiert, wenn bei jeder Hauptschleife einfach mal alle Telegramme geholt werden. Da kann es natürlich passieren, dass die Hauptschleife ins stocken gerät. Man könnte dann wieder die Zahl der Telegramme je Hauptschleife begrenzen ...

Ändere doch mal check_for_eibddata folgendermassen ab:

sub check_for_eibddata {
    my ($rin, $rout, $ein, $eout, $win, $wout);
!   my ($nfound, $nread,$nmaxtele);
    my ($buf);


    openEIBSocket () unless $EIBSock;
    if ($EIBSock) {
        # Check for input
        $rin = $win = $ein = '';
        vec($rin, fileno($EIBSock), 1) = 1;
        $ein = $rin;
!       $nmaxtele=10;
!       do {
          ($nfound) = select($rout=$rin, undef,  undef, 0);
          if ($nfound > 0) {
!             $nmaxtele--;
              if (my $buf = getGroup_Src ($EIBSock)) {
                  # Modify data to make it compatible to data from BCU1
                  my @tmpdat = unpack ("nna*", $buf);
                  my $data = pack "CCnnCa*", 0xbc, 0x00, $tmpdat[0], $tmpdat[1], 0xe1, $tmpdat[2];
                  #print "Modified packet: ", unpack("H*",$data), "\n";
                  my $msg = decode($data);
                  EIB_Item::receive_msg($msg);
              } else {
                  # Close socket in case of errors
                  close $EIBSock;
                  $EIBSock = undef;
              }
          }
!       } while ($nfound > 0 && $nmaxtele > 0);
    }
 ....

Mit dem ! habe ich markiert, wo was geändert wurde.
Kann sein das da noch Syntaxfehler drin sind, aber die Idee besteht darin das Abholen in einer Schleife laufen zu lassen, solang noch Daten vom EIB (also eibd) anstehen. Maximal aber n-Telegramme.

Verbessert das irgendwas?

Mike

[Pauker]

zu1. Ja meine Hauptschleife ist groß und enthält viele Logiken. Von denen sind auch einige etwas aufwendig. Abdunkeln nach Sonenstand, Fensteröffnung und nur wenn die Rauminnentemparatur größer der RaumSolltemteratur ist und die Außentemeratur über 20°C ist.

Und die Heizung wird auch beeinflusst um die Brennerstarts zu minimieren.

Und ich habe 1075 Gruppenadressen in MH eingepflegt. Ich nutze davon aber "noch" nicht alle. Die Zahl ist so hoch, weil ich in MS Access die Adressen für die Räume nach deren späteren Möglichkeiten generieren lasse und dann in die ETS und MH importiere. So erhalte ich eine einheitliche Bezeichnung.

zu2 mh läuft auf einem:
AMD Athlon(tm) 64 Processor 3200+
top - 18:03:01 up 14 days, 21:22, 1 user, load average: 0.58, 0.56, 0.58
Tasks: 151 total, 2 running, 149 sleeping, 0 stopped, 0 zombie
Cpu(s): 26.9%us, 10.3%sy, 0.3%ni, 54.8%id, 6.6%wa, 0.0%hi, 1.0%si, 0.0%st
Mem: 2075024k total, 2020708k used, 54316k free, 704k buffers
Swap: 10241240k total, 2359464k used, 7881776k free, 1371240k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23502 root 20 0 141m 127m 1668 S 23.2 6.3 57:13.59 mh
12119 root 10 -10 647m 64m 51m S 4.6 3.2 458:17.14 vmware-vmx
13424 root 10 -10 386m 259m 247m S 3.0 12.8 354:00.05 vmware-vmx
23319 root 20 0 16868 5352 3916 S 3.0 0.3 2:05.86 smbd
2804 vdr 20 0 117m 39m 872 S 2.3 1.9 294:04.07 vdr

neben einem vdr und 3vm
alles unter (Debian 4.3.2-1.1)


Wenn die Infos nicht reichen einfach nachfragen.

Werde die Änderungen jetzt einbinden und die Fahrten der Rollladen abwarten.


mfg

[Jockel]

Das Problem kann ich auch bestätigen, hier gibt es ja auch noch einen zweiten Thread dazu.

Bei mir liegt es definitiv nicht an der Buslast, bei meinen Tests gab es nur die Telegramme des einen Tasters!

[Pauker]

Rollladen sind alle wieder auf.

Hat leider keine Besserung gebracht.
Passenderweise ist es heute ein anderer Rollladen.

Logs wieder beigelegt.

Gibt es bei MH eigentlich die Möglichkeit außer beim Start einen readrequest durchzuführen?