Misterhouse - Eigene Weboberfläche

Hi DK,

liegt das mh_client Verzeichnis unter "web"?

Arno

[DK178]

Hallo Mike,

eine Frage. Habe versucht deine Beispiele aufzusetzen. Leider kommt beim Aufruf http://[mh adresse und port]/mh_client/rooms?room=livingroom folgendes im Browser:



Was mach ich falsch?

Hi,

...ohh... habe wohl den ersten "merge" geerbt. Ich habe noch parallel an der Navigationslogik für verschiedene Räume gearbeitet, bin aber noch nicht ganz zufrieden damit.

Layout ist momentan ausgelegt auf ca. 1300 Pixel horizontal (ungefähre Auflösung vom ASUS eee Touch 1602), daher bis max. 4 Blöcke pro Zeile, 3 Blöcke sind also kein Problem. Andererseits könnte man auch versuchen, die Tasterlogik nachzubilden (kurz drücken: Schritt, lang drücken: Fahren).

Arno

[mike]

Ich habe noch ein ValueDisplay-Objekt zur Anzeige von Werten (Temperatur, Helligkeit, etc. hinzugefügt). Ausserdem erfolgt das Starten des Refreshers jetzt nach dem Laden des Raumes. Lädt man einen anderen Raum, wird der Refresher für diesen neu gestartet.

Hast du eine Idee wie das Objekt für eine Jalousie aussehen soll? Im Prinzip bräuchte man 4 Buttons für Hoch/Runter und Schritt Hoch/Schritt Runter. Das wird dann aber 3 Spalten breit. Ist das zu breit?

Mike

Hallo,

nach kleiner Pause melde ich mich mal wieder...
Zum Thema Einzel / Kombiobjekte...
Mit Einzelobjekten hat man mehr Kontrolle über die Gestaltung im UI, damit kann sich diese eher an die tatsächlichen Use Cases orientieren und weniger auf technische Gegebenheiten von MH.

Zum Thema Layout/CSS: Habe es mit absoluter Positionierung in den Griff bekommen.

Derweil bin ich ein weiteres Stückchen weitergekommen...

• Rolladenobjekte (Auto / Hold - Shutter)
• Spacer um das Layout zu ordnen
• Wetter-Widget (bezieht Daten aus dem Google API)

Doku kommt dann irgendwann nach...
Gruss
Arno

[mike]

... zahne ich noch...
Ebenso am CSS (bei mehrzeiligen Texten im Button stimmt die Positionierung der darauf folgenden Buttons im Control nicht mehr)

Ich habe das nur durch absolute Positionierung zum umgebenden Controlcontainer beheben können ...

Mike

[aggie89go]

Ich bin auch ein Freund von Einzelobjekten, der Mehraufwand beim Erstellen der eib_items.mht hält sich in Grenzen und die Flexibilität steigt.

[mike]

Einzel- oder Kombiojekte

Ich habe mal noch eine grundsätzliche Überlegung:
In Misterhouse sind EIB2_Item und EIB7_Item Kombiobjekte, d.h. sie stellen keine Datenpunkte dar, sondern sind eine Ansammlung von Datenpunkten.

Für die Visualisierung ist es aber besser die einzelnen Datenpunkte ansteuern zu können. Gerade bei Jalousien, wo es Behanghöhe und Lamellenstellung gibt, wird eine Statusanzeige sonst kompliziert.

Ich habe mir mal die Vor- und Nachteile überlegt:
Kombiobjekte
Vorteile

• weniger Items nötig
• bessere Anzeige im aktuellen Misterhouse
• bessere Integration in Misterhouse, da X10 kompatibler *1
• einfacher beim Scripting, da man nur mit einem Item arbeiten muss
• manche Funktionen sind nur mit einem Kombiobjekt möglich *2

Nachteile

• spezielle Eigenschaften von Aktoren werden nicht unterstützt (z.B. EIB7_Item und Positionierung)
• Import aus ETS unmöglich, da beim Import zusammenhänge erkannt werden müssten

Einzelobjekte
Vorteile

• Status jedes einzelnen Datenpunkts abrufbar
• evtl. Import aus ETS möglich
• flexiblere Verwendung möglich

Nachteile

• mehr Items im Misterhouse; es muss mehr definiert werden
• Gruppieren von Datenpunkten muss im Browser erfolgen

Was meint Ihr? Welcher Weg ist der bessere?
Kennt Ihr irgendwelche KO-Kriterien?

Ich bin übrigens für Einzelobjekte.

Braucht Ihr ein Beispiel?
Dimmer (EIB2_Item): Besteht aus 3 Datenpunkten. Einer zum Ein-/Ausschalten, einer zum Dimmen (Heller/Dunkler) und einer zum direkten Anspringen eines Dimmwertes und zur Abfrage des aktuellen Dimmwertes. Moderne Aktoren bieten noch weitere Datenpunkte. Vor allem geht es hier um den Status des Aktors (An-/Aus; aktueller Dimmwert). In der Visualisierung könnte man nun alle 3 Datenpunkte einzeln, aber optisch zusammengefasst darstellen. Dimmt man eine Lampe an, so springt während des Dimmens die An-/Aus-Anzeige auf AN. Beim Kombiobjekt ist der Status: "brighten" und evtl. zwischendurch kurz "on" (wenn der Aktor den Status des Schaltobjektes sendet) was aber eigentlich 100% Dimmwert entspricht . Da kann man sich vorstellen wie eine Balkenanzeige hin- und herzappelt, bzw. was man für Klimmzüge machen muss um das zu beruhigen.


*1 Bei X10 gibt es z.B. nur eine Adresse für eine Lampe. Ob diese geschalten oder gedimmt wird ergibt sich aus dem Befehl, der an diese Adresse geschickt wird.

*2 Beim EIB2_Item wird standardmäßig nach einem Dimmvorgang mit einer Zeitverzögerung der aktuelle Dimmwert vom Aktor geholt, da der "Referenzaktor" (nach dem EIB2_Item implementiert wurde) direkt nach dem Dimmen falsche Werte geliefert hat. Überhaupt ist der Trigger: "Es wurde gerade der Dimmwert verstellt" nur im Kombiobjekt verfügbar. Der einzelne Datenpunkt weiß nicht das er aktiv aktualisiert werden müsste wenn ein anderer Datenpunkt seinen Status ändert. Andererseits kann man das natürlich nachprogrammieren.

[mike]

im Moment habe ich noch keine Automatisierung... Haus wird ja erst gebaut.

Hast du wenigstens einen Minimalaufbau? Also so dass eibd an einen echten Bus geht?
Da kannst du das evtl simulieren in dem du das Kommando:

groupwrite ip:localhost 1/0/3 35

ausführst. Dass sendet dann den aktuellen Dimm-Wert auf den Bus und sollte somit auch in MH gesehen werden (Gruppenadresse musst du natürlich anpassen; Wert (im Beispiel 35) kann zwischen 0 und 255 sein (Grenzen eingeschlossen)).

Mike

Hallo,

im Moment habe ich noch keine Automatisierung... Haus wird ja erst gebaut.
Ich sehe aber ein, dass gewisse Funktionen nur mit entsprechender Hardware getestet werden können.

Benutzen werde ich künftig entweder den Universal Dimmaktor von Siemens (4fach) oder einen 1-10V Schalt-Dimmaktor, ebenfalls Siemens.

Gruss
Arno

[mike]

...der Dimmwert kommt bei mir aber nicht an, die letzte Meldung in "this.updateState" ist "stop".

Setz doch mal bei den Optionen des EIB2_Items ein R, also:

EIB2, 1/0/1|1/0/2|1/0/3, Licht, LichtGruppe, R

Falls du den original Misterhouse-2.105-Stand verwendest macht das allerdings keinen Unterschied. Das EIB2_Item versucht nach einem Dimmvorgang nach einer kleinen Pause, den Dimmwert vom Aktor auszulesen (von der 3. Adresse). Die Frage ist, ob dein Aktor das Unterstützt. Eventuell musst du auch nur das Leseflag beim Aktor setzen.

Manche Aktoren (z.B. Siemens EIB-Dali-gateway) sind so nett und schicken von sich aus nach dem sie "stop" empfangen haben den aktuellen Wert auf den Bus (auf eine separate Statusadresse). Da empfiehlt sich dann die Verwendung meines Patches für hörende Gruppenadressen. Den Patch findest du auch hier im Forum. (Ein SVN wäre ja nicht schlecht ).

Was für einen Aktor hast du? Da kann ich dann vielleicht mal nachsehen ...

Mike

Die Statusfolge ist so "off" -> "brighten" -> "stop" -> "34%", d.h. am Ende wird der aktuelle Dimmwert in % als Status gesendet.

...der Dimmwert kommt bei mir aber nicht an, die letzte Meldung in "this.updateState" ist "stop". Mit einem %-Wert könnte ich ja schon etwas anfangen. An den Anzeigebalken setze ich mich noch... sollte kein großes Ding sein.

Arno

[mike]

ja, müsste gehen... so a la Enterprise mit dem Finger schieben (ENERGIE!!) (wo gibt es eigentlich eine Liste mit den Smilies, ich brauche unbedingt einen Vulkanier)
Ich müsste dann direkt den Dimmwert in % setzen, heisst dann kontinuierlich die entsprechende Funktion aufrufen. Ob das dann so smooth läuft, müsste man in der Praxis ausprobieren.

Ich meinte zwar eigentlich einen Balken für die Anzeige. So ein "Schieberegler" wär natürlich auch eine tolle Sache. Schieben muss ja nicht unbedingt sein, aber das direkte Anspringen eines Prozentwertes ist auch toll.

Da nun über den Status die jeweilige Dimmfunktion zurückkommt (dim, brighten, stop), ist eine Zuordnung, ob das Licht an oder aus ist nicht mehr möglich. Kann man das anderweitig abfragen?

Leider nein. Im MH wird es so gehandhabt, dass "0%" in "off" gewandelt wird und dann alles was nicht "off" ist "on" sein muss. Ach ja und "100%" wird natürlich zu "on".

Ich habe die Dimmfunktion mal eingebaut. Allerdings habe ich von CSS keine Ahnung. Daher ist es z.Z. so, dass wenn man auf "+" drückt, die Grafik vom Button kleiner wird und daher das MouseUp-Event nicht mehr kommt.

nach dem ich ausprobiert habe, verstehe ich...
ich verwende den Status, um das entsprechende Style für das Button auszuwählen. Bisher behandle ich nur on/off um entsprechend zu signalisieren, ob das Licht eingeschaltet ist oder nicht. Da nun über den Status die jeweilige Dimmfunktion zurückkommt (dim, brighten, stop), ist eine Zuordnung, ob das Licht an oder aus ist nicht mehr möglich. Kann man das anderweitig abfragen?

Arno

Hallo,

Code schon mal "optimiert" (Funktion wird direkt mit "brighten" / "dim" aufgerufen, kommt mit der nächsten Version mit).

Für eine gedimmte Lampe benötigt man nur ein EIB2_Item. Wozu ist das 2. Item bei dir gedacht?

Ich dachte, man bräuchte dann etwas zum ein/ausschalten (wie beim echten Dimmer eben). Lesen bildet... jetzt weiss ich, wie der Dimmer in MH adressiert wird. Werde wohl die nächsten paar Stunden wieder aus der Programmierung aussteigen und die MH docs durchwälzen.

Die Statusfolge ist so "off" -> "brighten" -> "stop" -> "34%", d.h. am Ende wird der aktuelle Dimmwert in % als Status gesendet.

Kann man daraus einen Balken bauen?

ja, müsste gehen... so a la Enterprise mit dem Finger schieben (ENERGIE!!) (wo gibt es eigentlich eine Liste mit den Smilies, ich brauche unbedingt einen Vulkanier)
Ich müsste dann direkt den Dimmwert in % setzen, heisst dann kontinuierlich die entsprechende Funktion aufrufen. Ob das dann so smooth läuft, müsste man in der Praxis ausprobieren.

Arno