Misterhouse: Erweiterung für hörende Gruppenadressen (Tester gesucht)

[mike]

Problem: In Misterhouse kann man hörende Gruppenadressen nur über die EIB1G_Items simulieren. Dabei muss aber andersherum gedacht werden als es in EIB üblich ist.
Dadurch dass es keine anderen EIBXG_Items gibt ist die Anwendung nur auf EIS1 (oder neuer DPT1) Objekte beschränkt.

Gerade moderne Aktoren besitzen aber alle möglichen Statusobjekte mit denen wichtige Rückmeldungen gegeben werden (Beispiel Treppenhausfunktion, Dimmwert). Dafür extra ein Item anzulegen ist nicht schön.

Lösung: EIB_Items wurde dahingehend modifiziert, dass überall wo eine Gruppenadresse angegeben werden muss, eine beliebige Anzahl Gruppenadressen durch + getrennt angegeben werden kann. Die erste Adresse ist die sendende Adresse. Alle weiteren sind hörende Adressen.

Beispiel:

EIB2,  1/3/23+1/0/0|1/3/32|1/3/33, Essbereich,                     Wohnzimmer|All_Lights,

Die Adresse 1/0/0 ist eine Zentralfunktion.

Weitere Änderungen: Die states-Variable der EIBX_Items wird jetzt mit sinnvollen Werten gefüllt. Daher entfällt das Ändern der Liste mit Stati in der Web-Anzeige (lib/http_server.pl).

Beim EIB2_Item muss jetzt die R-Option explizit angegeben werden, damit der Dimmwert aktiv über den Bus zurückgelesen wird. Hat man ein Dimmwertstatusobjekt im Aktor, so ist es natürlich praktischer dieses als hörende Adresse anzugeben und R nicht zu setzen.

Im Anhang befindet sich der Patch und (für die Leute die mit Patches auf Kriegsfuss stehen) ein Zip mit bereits gepatchten Files. Beides setzt auf Misterhouse 2.105 auf.

Ausserdem findet Ihr das Perl-Script mhtconvert.pl. Dieses Script schiebt die Adressen die in EIB1G und EIB7G Items definiert sind als hörende Adressen um. Aufruf geschieht mit

mhtconvert.pl MyItems.mht

Es wird eine Datei MyItems.mht_new erstellt in der es dann keine G-Objekte mehr gibt.
Diese müsst ihr dann kontrollieren und umbenennen.

Bitte probiert das mal aus.
Ich wollte das demnächst dann Upstream schieben.

Gibt es jemanden, der EIB1G vermisst? Wenn ja warum?

[pheno]

Hallo Mike,


also ich habe jetzt die beiden Perl Dateien (EIB_Items.pm & http_server.pl) ausgetauscht, aber wie geht es jetzt weiter?

Dein Beispiel habe ich nicht so ganz verstanden.
Wie kann ich jetzt den Status der einzelnen Raffstores abfragen?
pheno

[mike]

Mit dem Patch ist es einfach so, dass du überall wo man bisher eine Gruppenadressen angeben konnte, jetzt beliebig viele Gruppenadressen angeben kannst.

Hast du z.B. für die Flurbeleuchtung einen Aktor, der auf Adresse 1/1/1 die Lampe anschaltet und nach 5 Minuten wieder ausschaltet und das per Status-Objekt auf Adresse 4/1/1 meldet, dann kannst du schreiben:

EIB1,  1/1/1+4/1/1, Flurlicht,

Das Event auf dem Status-Objekt schaltet dir dann in der Visu den Zustand um.

Bisher hättest du schreiben müssen:

EIB1,  1/1/1+4/1/1, Flurlicht,
EIB1G, 4/1/1, Flurlicht_Status, 1/1/1

Bei Jalousien ist es so, dass das EIB7_Objekt keine Angaben zu Position der Rolläden oder Jalousien liefert. Wenn du das jetzt erweitern wolltest, dann wird das durch diesen Patch einfacher, da du keine EIB7G-Items basteln musst.

Wenn du einen Aktor hast der per 1Byte-Objekt die Jalousien auf eine bestimmte Position fahren kann und über ein anderes 1Byte-Objekt die Position nach dem fahren meldet, dann kannst du folgendes Definieren:

EIB6, 2/1/1+4/1/2, Raffstore_Bad_Position,

(unter der Annahme das 2/1/1 die GA für das 1Byte-Objekt ist und 4/1/2 für das Status-Objekt).
Ohne den Patch ist das nicht möglich. Es gab auch nie ein EIB6G_Item.

[McTao]

Mit dem Patch ist es einfach so, dass du überall wo man bisher eine Gruppenadressen angeben konnte, jetzt beliebig viele Gruppenadressen angeben kannst.

Ohne den Patch ist das nicht möglich. Es gab auch nie ein EIB6G_Item.

Müsste das auch mit den EIBRB Items von RaK gehen. Genau diese setzte ich nämlich für die Rollladen ein.

Dann würde ich nämlich sofort mit dem Testen anfangen, sonst erst am Wochenende, da ich erst für Rollladen eine Lösung brauche.

Gruss McTao

[mike]

Eigentlich sollte es funktionieren, da für die hörenden GA das EIB_Item, also die Mutter aller EIBX_Items angepasst wurde.

Mit den Stati könnte es Probleme geben. Wenn du nicht experimentieren willst, dann sehe ich mir das heute Abend mal an (wenn ich es schaffe ...).

Grüße
Mike

[McTao]

Eigentlich sollte es funktionieren, da für die hörenden GA das EIB_Item, also die Mutter aller EIBX_Items angepasst wurde.

Hi, habs ausprobiert, bekomme:
Can't locate object method "add" via package "EIBRB1_Item" at ../lib/Rollerblinds.pm line 27

Gruss McTao

[pheno]

wo bekomme ich denn dieses EIBRB_Item her?
Ich hab' das schon wie bekloppt gesucht, aber nicht gefunden.

Eigentlich möchte ich meine Raffstores so steuern, dass ich Sie auf eine bestimmte Höhe fahren kann, z.B. 50% oder 70%.

Danach den Status abzufragen ist dann ein nice-to-have.
pheno

[mike]

Hi, habs ausprobiert, bekomme:
Can't locate object method "add" via package "EIBRB1_Item" at ../lib/Rollerblinds.pm line 27

Schmeiss einfach alle add-Calls raus und füge diese Zeile (auf Zeile 41 vor add rausschmiss) hinzu:

push(@{$$self{states}}, 'up', 'down','stop');

wo bekomme ich denn dieses EIBRB_Item her?

Von hier

[McTao]

Schmeiss einfach alle add-Calls raus und füge diese Zeile (auf Zeile 41 vor add rausschmiss) hinzu:

Du meinst in der Rollerblinds.pm darf kein add-Call mehr auftauchen?

ICh habe gerade mal grep add im libVerzeichnis gemacht, da sind etliche.
Was ist der Hintergrund vom umschreiben des add-Calls?

Gruss McTao

[mike]

Du meinst in der Rollerblinds.pm darf kein add-Call mehr auftauchen?

Genau!

ICh habe gerade mal grep add im libVerzeichnis gemacht, da sind etliche.
Was ist der Hintergrund vom umschreiben des add-Calls?

Das X10-Item wurde wohl als Muster für das EIB_Item benutzt. Dort gab es den add-Call um die X10-Adressen in einem Array zu registrieren.
In der Add-Routine wurde auch die Liste der Stati mit aufgebaut. Bei X10 mag das vielleicht etwas miteinander zu tun haben. So genau steige ich durch die Sourcen auch nicht durch. Beim EIB_Item hatte ich mich immer gewundert wozu das gut sein soll und warum die Gruppenadresse als Status erscheint. Daher habe ich dann die Registrierung der Gruppenadressen um das EIB_Item zu finden, wenn am Bus was empfangen wird und die Stati, die in der Http-Ansicht angeben, was ein Item alles kann, voneinander getrennt.

Der Member states gibt einfach nur an, was im Http angeboten wird. Schau dir das EIB2_Item an. Da kann man per Konfiguration angeben, was in die Liste hinein soll. Ansonsten wird "states" nirgends verwendet.
Ein Item weiß immer selbst welche Stati es unterstützt. Wenn du also in die Liste was falsches reinschreibst, dann meckert das Item schon.

[McTao]

Schmeiss einfach alle add-Calls raus

Danke, habe ich gemacht und jetzt läuft MH wieder mit den von Dir geänderten Sachen und auch die Rollerblinds.pm geht wieder.

Die Webansicht sieht erst mal so aus wie immer. Die Steuerung kann ich erst heute Abend testen.

Jetzt fange ich dann heute Abend an die Stati (auch in Bezug der Rollladen= zu testen.

Gruss McTao

[McTao]

@RaK

Wenn ich nun Schaltobjekte für die Rollerblinds habe, wo trage ich diese ein?

Schlatend 0/1 würde an die erste Gruppenadresse kommen (Zentralaufgaben).

Positionsangaben (zB für Sonnenschutz über Aktor) an die 3. Adresse?

Hat jemand eine Idee oder muss das durch probieren festgestellt werden?

Gruss McTao

[mike]

Im Prinzip machst du das genauso wie in der ETS. Alle Adressen auf die der Aktor reagiert gehören hier eingetragen. Wichtig ist nur das die jeweils erste Adresse der sendenden Adresse entspricht.

[McTao]

Bin jetzt aktiv am testen:

Schaltende Adressen (defineirt mit EIB_ITems.pm) gehen.

EIBRB_Item definiert in Rollserblinds.pm geht nicht.
Bisher geändert:
1.) alle $item ->add in push umgesetzt
2.) Auruf eib_item_by_id($subitem) in eib_items_by_id($subitem)

nun habe ich noch folgenden Fehler:
($EsszimmerTerasse_Rollladen->set("down", "web : ($EsszimmerTerasse_Rollladen = "down") error=Can't call method "set" without a package or object reference at ../lib/Rollerblinds.pm line 177, <GEN149> line 12.

Damit komme ich noch nicht weiter.

Gruss McTao

[mike]

Normalerweise werden die verschiedenen Items immer per Id gespeichert und müssen dann vor jeder Benutzung erst per eib_item_per_id geholt werden. Nun kann es aber pro Id (welches die Gruppenadresse ist) mehrere Items geben. Daher speicher ich jetzt immer die Objectreferenzen selbst.

Wenn das Nachteilig ist, dann bitte erklären warum!

Ich habe die Rollerblinds.pm entsprechend angepasst.

Mike