Device-Reading floorplanHTML

[UliM]

Hallo,
von Topos und Oskar kam der Vorschlag, bei Geräten ein device-Reading floorplanHTML einzuführen, das durch den user statt des state in einem floorplan eingebunden/angezeigt werden kann. Damit liegt die Definition der Darstellungsweise beim Autor des Moduls.

Bspw für S300TH hab ich einen separaten "Style" zur gefälligen Darstellung von sowohl Temperatur als auch Humidity eingebaut, allerdings wäre das Einbauen unterschiedlicher gerätespezifischer 'styles' für weitere device-types wohl schnell unübersichtlich.

Um diesen Lösungsweg zu demonstrieren, hab ich einen Beipiel-screenshot des neuen Luxtronik2-Moduls kopiert und hier angehängt. Es ist eben nicht nur die Temperatur zu sehen, sondern ein vom Modulautor zusammengestellter Anzeigeüberblick mit passenden Zeilenumbrüchen etc (stammt aus diesem Fred: https://groups.google.com/d/msg/fhem-users/tSd5hdJOIJk/5vQd_zY1XlkJ , dort auch die Info wie's für den user aktivierbar und nutzbar ist)

Ein wenig Hintergrundinfo und einen Implementierungsvorschlag gibt's hier:
https://groups.google.com/d/msg/fhem-users/4jgKdk6_Z7A/f7BdtPWdq5EJ
(auch die 5 nächsten posts dort weiter unten)

Es würde mich freuen, wenn sich ein paar weitere Modulautoren diesem Lösungsweg anschließen würden und ihre Module in dieser Art "nachrüsten".

Konstruktive Grüße,
Uli

PS: Besonders begrüßen würde ich das für CUL_WS, dann könnte ich die floorplan-Sonderlocke für S300TH (style4) wieder rausschmeißen

[Willi]

Hallo Uli,

die Idee finde ich generell gut. Ich werde es auch gerne nutzen, wenn wir uns auf keine andere Lösung einigen. Ich werde daher noch etwas die Diskussion abwarten.

Als Modulautor habe ich es einfach meine eigenen Wünsche umzusetzen, damit Floorplan dann so aussieht wie ich es möchte.

Allerdings werden dann die Wünsche aller Benutzer nicht berücksichtigt. Die Ausgabe ist für den Benutzer nicht konfigurierbar. 

Oder habe ich das falsch verstanden?

Besser fände ich es, wenn wir einen Weg finden würden, dass man HTML in einem Attribut angeben könnte, in dem auch beliebige Variablen, insbesondere Readings enthalten sein können. Also im Prinzip die gleiche Idee wie bei den HTML-Readings, aber als Attribute, die von jedem per fhem.cfg zu setzen sind und die dann von Floorplan verwendet werden.

Zur Diskussion.

MfG Willi

[Olaf Droegehorn]

Hi all,

die Idee, dass der User eingreifen kann, finde ich gut. Dem User
allerdings HTML abzufordern ist nicht praktikabel, zumindest nicht, wenn
FHEM f锟絩 Endkunden sein soll. Da w锟絩e ein Editor, mind. eine
Dropdown-List wichtig. Alles andere ist f锟絩 Nerds wie uns.

just my 2 cents.

Gr锟斤拷e,
Olaf

Am 02.05.2012 23:30, schrieb Willi:
> Hallo Uli,
>
> die Idee finde ich generell gut. Ich werde es auch gerne nutzen, wenn

> wir uns auf keine andere L锟絪ung einigen. Ich werde daher noch etwas die
> Diskussion abwarten.
>
> Als Modulautor habe ich es einfach meine eigenen W锟絥sche umzusetzen,
> damit Floorplan dann so aussieht wie ich es m锟絚hte.
> Allerdings werden dann die W锟絥sche aller Benutzer nicht ber锟絚ksichtigt.
> Die Ausgabe ist f锟絩 den Benutzer nicht konfigurierbar.

> Oder habe ich das falsch verstanden?
>

> Besser f锟絥de ich es, wenn wir einen Weg finden w锟絩den, dass man HTML in
> einem Attribut angeben k锟絥nte, in dem auch beliebige Variablen,
> insbesondere Readings enthalten sein k锟絥nen. Also im Prinzip die gleiche

> Idee wie bei den HTML-Readings, aber als Attribute, die von jedem per
> fhem.cfg zu setzen sind und die dann von Floorplan verwendet werden.
>
> Zur Diskussion.
>
> MfG Willi
>

> --
> Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe
> FHEM developers beigetreten sind.
> Besuchen Sie
> https://groups.google.com/d/msg/fhem-developers/-/oTfSpOQx5F8J, um diese
> Diskussion im Web anzuzeigen.
> Wenn Sie Nachrichten in dieser Gruppe posten m锟絚hten, senden Sie eine
> E-Mail an fhem-de...@googlegroups.com.
> Wenn Sie aus dieser Gruppe austreten m锟絚hten, senden Sie eine E-Mail an
> fhem-develope...@googlegroups.com.
> Besuchen Sie die Gruppe unter
> http://groups.google.com/group/fhem-developers?hl=de, um weitere
> Optionen zu erhalten.

--
------------------------------------------------------------------------
Prof. Dr. Olaf Droegehorn
General Manager Tel. : +49-2244-918-4080
DHS - Computertechnik GmbH Fax. : +49-2244-918-4082
Wilhelm-Liebertz-Str. 2c E-Mail: O.Droegehorn@dhs-
computertechnik.de
D-53639 Koenigswinter WEB: www.dhs-computertechnik.de
------------------------------------------------------------------------

[UliM]

Am Mittwoch, 2. Mai 2012 23:30:14 UTC+2 schrieb Willi:

Die Ausgabe ist für den Benutzer nicht konfigurierbar. 

Oder habe ich das falsch verstanden?

 
Moin,
jain :)

Derzeit hat der user ja auch nur eingeschränkte Möglichkeiten, die Darstellung zu beeinflussen (style und css). Diese Möglichkeiten bleiben. Derzeit wird immer STATE dargestellt. Wenn ein Modul ein reading floorplanHTML bereitstellt, kann der user schon wählen zwischen Anzeige des STATE und Anzeige des readings htmlFloorplan.

Wenn ein Modulautor mehrere Darstellungsvarianten bereitstellen möchte (es kam zB gerade die Anfrage, ob man mit gemessenen Temperaturen nicht auch den Zeitstempel der letzten Messung anzeigen könnte), kann man diese Darstellungsvarianten ja über das im Luxtronik2-Beispiel genannte Device-Attribut statusHTML anbieten. Als Gedankenspiel zu S300TH: 
statusHTML 1 -> floorplanHTML zeigt Nur Temperatur,
statusHTML 2 -> floorplanHTML zeigt nur Humidity,
statusHTML 3 -> floorplanHTML zeigt Temperatur & Humidity & Zeitstempel,
statusHTML 4 -> floorplanHTML zeigt Temp & Hum (incl divs, so wie jetzt mit floorplan-style 4).
Das reading floorplanHTML würde also abhängig vom Attributwert statusHTML unterschiedlich befüllt.
Muss man ja nicht machen. Analog zu Luxtronik2 würde aber das reading floorplanHTML erst bereitgestellt, wenn statusHTML auf dem device gesetzt ist.

@Olaf: Sieht nach Missverständnis aus.  Klar soll der user nix mit html zu tun haben. floorplanHTML wäre als Reading eines device bereitgestellt und steht damit zur Auswahl der Darstellungsweise im floorplan zur Verfügung. Der user muss nur den geeigneten style (ggf mit Angabe des readings) im floorplan auswählen.

Hoffe das ist einigermassen verständlich ;-)
Falls unklar - bitte mal den Links im originären post folgen, da steht der Vorschlag etwas ausführlicher.

Grüßle,
Uli

[Rudolf Koenig]

> Ein wenig Hintergrundinfo und einen Implementierungsvorschlag gibt's hier:
> https://groups.google.com/d/msg/fhem-users/4jgKdk6_Z7A/f7BdtPWdq5EJ

> (auch die 5 n�chsten posts dort weiter unten)

Jetzt verstehe ich den Vorschlag, mein Antwort auf Deine Frage war nicht
sinnvoll, da ich den Kommentar von Topos nicht mehr im Sinn hatte.


> Besser f�nde ich es, wenn wir einen Weg finden w�rden, dass man HTML in einem
> Attribut angeben k�nnte, in dem auch beliebige Variablen, insbesondere
> Readings enthalten sein k�nnen.

Das finde ich auch. Bei den weblink Attributen label und title wird es so
gehandhabt: das spezifizierte String wird als perl Ausdruck ausgefuehrt, und
dessen Ergebnis wird verwendet, damit man im Title min/max/etc Werte reinbauen
kann.


> Da waere ein Editor, mind. eine Dropdown-List wichtig.

Sicher, aber:
- dropdown reicht nicht, man will ja was gestalten, z.Bsp einen Umbruch
einbauen, weil es zu breit ist. Oder andersherum.
- Alle webfrontends muessten diesen "Editor" nachbauen.

Mein Vorschlag:
- es gibt ein Attribut HTMLstate, falls gesetzt wird es ausgefuehrt und statt
STATE angezeigt.
- der Modul-Author kann es beim define setzen, der Benutzer kann es
ueberschreiben.
- Die Anzeige kann je nach frontend passen oder auch nicht. Eigentlich
braucht man was je nach frontend, oder genauer, je nach Instanz des
frontends. Das koennte man aber mit einem zusaetzlichen HTMLstate.<WEBNAME>
Attribut loesen: dieser wird erst geprueft, und dann HTMLstate.

Haken:
- Attribut Loeschen reicht nicht, da beim naechsten fhem-Start wieder da ist.
Attribut auf 0 oder none zu setzen ist nicht intuitiv.

Andere Ideen?

[Topos]

Die Idee ist, die Ausgabe konfigurierbar zu machen. Das heißt man kann über ein Attribut (z.B. statushtml) die auszugebenden Readings (attr <device> statushtml <reading1>,<reading2>,<reading3>) konfigurieren und das Modul schreibt sie dann einfach mit Zeilenumbruch untereinander. Wenn statushtml nicht vorhanden ist, wird eine Standardausgabe erzeugt. (Oder gar nix.)

 

Hmm. Wenn man das weiterspinnt, könnte man das Ganze so bauen, das Floorplan standardmäßig den "state" anzeigt. Sobald ein floorplanHTML existiert, wird aber dieses angezeigt. Die Modulautoren könnten dann als Standardausgabe (kein Attribut statushtml vorhanden.) einfach den "state" unter floorplanHTML speichern.

 

Eine Formatierung ist prinzipiel über die floorplan.css Datei möglich (wie für den S300TH bereits vorhanden). Die Frage ist dann, ob der Style den Gerätenamen (#id) oder den Devicetyp (.class) erhalten soll. Das ganze wird im Geräte-Modul implementiert, die Richtlinie sollte aber in diesem Forum definiert werden.

 

Gruß

Topos

[Topos]

'tschuldigung für Überschneidungen. Habe Rudis Posting nicht richtig gelesen.

[UliM]

Am Donnerstag, 3. Mai 2012 08:32:50 UTC+2 schrieb Rudolf Koenig:

Mein Vorschlag:
- es gibt ein Attribut HTMLstate, falls gesetzt wird es ausgefuehrt und statt
  STATE angezeigt.
- der Modul-Author kann es beim define setzen, der Benutzer kann es
  ueberschreiben.
- Die Anzeige kann je nach frontend passen oder auch nicht. Eigentlich
  braucht man was je nach frontend, oder genauer, je nach Instanz des
  frontends. Das koennte man aber mit einem zusaetzlichen HTMLstate.<WEBNAME>
  Attribut loesen: dieser wird erst geprueft, und dann HTMLstate.

Haken:
- Attribut Loeschen reicht nicht, da beim naechsten fhem-Start wieder da ist.
  Attribut auf 0 oder none zu setzen ist nicht intuitiv.

Andere Ideen?

Der Haken hakt nur, wenn HTMLstate gleich beim define gesetzt wird. Ich find das muss gar nicht sein.  Ist das Attribut nicht gesetzt, gibt's wie bisher nur Ausgabe in STATE.
Wenn HTMLstate gesetzt ist, wird STATE stattdessen damit gefüllt.

Ich fänd's trotzdem gut, wenn es eine separate Darstellungsmöglichkeit in floorplans gäbe. Grund: in pgm2 will ich vsl immer eine einzeilige Darstellung haben - ein device mit 4zeiligem STATE würde da doch ziemlich aus dem Rahmen fallen.  Im floorplan hingegen ist genug Platz, da sind 4 Zeile sicher häufig gewünscht.
Vorschlag: Es soll auch die Variante HTMLstate.<FLOORPLANNAME>  geben.
Ausgabe dann je nachdem, von wo der Aufruf erfolgt... aber es gibt doch STATE nur einmal?? Ich steh grad auf der Leitung wie das gehen soll...

=8-)

[Rudolf Koenig]

> Der Haken hakt nur, wenn HTMLstate gleich beim define gesetzt wird. Ich
> find das muss gar nicht sein.

Sicher, aber dann hat der Modul-Author nichts zu sagen, und der Benutzer muss
sich auf die (Web-) Suche begehen. Dagegen wehrt sich verstaendlicherweise
Olaf.

> Vorschlag: Es soll auch die Variante HTMLstate.<FLOORPLANNAME> geben.

Floorplan koennte einen globalen FW_wname modifizieren. Alternativ benoetigt
man fuer die abweichende Floorplan-Darstellung einen separaten FHEMWEB Instanz.

[Olaf Droegehorn]

Hi all,

evtl. nur um deutlich zu sein:
Ich wehre mich nicht, ich gebe zu bedenken. Ich find es schon toll, dass
sich viele Leute Arbeit machen, und so gute Module entwickeln.

Am Ende liegt es in der Hand des jeweiligen Modul-Autors, was er
einbaut, und was nicht.

Alles andere sind nur Vorschl�ge.

Gru�,
Olaf

[UliM]

Hi,
um den Faden noch mal aufzunehmen...

Anforderungen:
1. Es soll Darstellungsalternativen geben
2. Diese sollen für non-nerds ohne html-Kenntnisse auswählbar sein
3. Für nerds mit html-Kenntnissen soll es erweiterte Möglichkeiten geben
Hoffe ich hab das jetzt richtig zusammengefasst.

Lösungsvorschlag:
- Ein Modul schreibt wie bisher den STATE
- Dieser ist für nerds durch ein Attribut HTMLstate beeinflussbar
- Ein Modul bietet ggf ein Attribut floorplanHTML , mit dem eine Ausgabe in ein zusätzliches reading floorplanHTML aktiviert wird. Dieses reading kann auch von non-nerds in floorplan angezeigt werden (style3). Es steht dem Modulautor frei, als Wert für floorplanHTML mehrere Werte (0,1,2,3...) zuzulassen, die dann unterschiedliche vorgefertigte Formate in das reading floorplanHTML ausgeben (siehe oben).
- Ein Modul kann ausserdem ein Attribut HTMLfloorplan anbieten, das für nerds die Ausgabe in das reading floorplanHTML beeinflusst.

Vll kann man an den Namen der Attribute noch etwas feilen - ist dieser Vorschlag grundsätzlich konsensfähig?  :-)

Gruß, Uli

[Topos]

Hallo,

 

wo genau liegt der Vorteil von HTML in STATE?

 

Hier noch ein paar Verfeinerungen Deines Vorschlags:

 

Bzgl. floorplan.pm:

 

Ich würde empfehlen, (1) ein Reading "floorplanHTML" einzuführen, dass Du dann immer mit style3 ausliest.

 

(2) Wenn es nicht vorhanden ist, nimmst Du bei style3 einfach STATE.

 

Bzgl. Geräte-Module

 

(3) Es gibt ein "floorplanHTML"-Konfigurationsattribut, z.B. "fp_content" (oder HTMLstate?)

 

(4) Das "floorplanHTML"-Konfigurationsattribut sollte HTML-Nerds und Non-Nerds dienen.

 

(5) Wenn kein "floorplanHTML"-Konfigurationsattribut angegeben ist, legt der Modul-Author selbst fest, was er in "floorplanHTML" reinschreibt (z.B. STATE).

 

(6) Es können vorbestimmte Modi gewählt werden (1,2,3,4), z.B. "attr <name> fp_content 2".

 

(7) Es könnte einen Modus "Reading:" geben der Readings einliest, z.B."attr <name> fp_content Reading:{reading1}{reading2},{reading3}. Komma heißt hier Zeilenumbruch. Reading-Namen in geschweiften Klammern werden bei der Ausgabe durch den tatsächlichen Wert ersetzt.

 

(8) Für HTML-Nerds gibt den Modus "HTML:", z.B."attr <name> fp_content HTML:{reading1}&nbsp;{reading2}<br>{reading3}

 

(9) Die Formatierung erfolgt über floorplan.css (Richtlinie?). Die Styles müssen von den Modul-Authoren in "floorplanHTML" eingefügt werden.

(10) Man könnte auch noch einen Modus "CSS:" einführen.

 

Gruß

 

Topos

[UliM]

Hi,

auch ne Variante...

Mir scheint wir kommen mit Mailverkehr hier nicht zum Ziel.

Werde für kommende Woche Di Abend ein Teamviewer-Meeting einstellen und würde mich freuen, wenn Interessierte und Lösungsträger teilnehmen :)  Ziel des Meetings ist es, um der Einheitlichkeit und usability Willen eine Empfehlung zu formulieren, wie der Darstellungsaspekt von den Modulautoren einheitlich behandelt werden kann.

 

Detail-Infos folgen.

 

Carpe diem,

Uli

[UliM]

Am Donnerstag, 10. Mai 2012 10:46:49 UTC+2 schrieb UliM:

Detail-Infos folgen.

 

Hi,
bitte tragt euch Dienstag, 15.05.12 19:30 in den Kalender ein.
Teamviewer-Koordinaten schicke ich dann in diesem fred ca 1h vor Beginn.

Teilnehmer müssen keinen fat-client installieren. VoIP sollte gehen, mW ist auch Einwahl per Tel möglich - dann meist bessere Audio-Qualität.
(http://www.teamviewer.com/de/products/meeting.aspx)

Ich hoffe, dass Minimum Rudi, Topos und Willi teilnehmen. Jeder andere Teilnehmer ist herzlich willkommen.
@Rudi, Topos, Willi: Bitte schickt mir ne PM falls ihr zu dem Termin nicht könnt, dann suchen wir nen anderen Termin.
Grüßle, Uli

[UliM]

Hallo,
hier die Einwahldaten zum Meeting:
http://go.teamviewer.com/v7/m80133523
Meeting-ID: m80-133-523

Wenn man auf den o.g. link klickt, kommt ein popup zur Installation eines frontends.  Ihr könnt dann
- das frontend installieren
- oder auf Abbrechen klicken und den Link 'Teilnahme über Browser' klicken
- oder von der Teamviewer-Seite zB eine Portable-Version des frontends runterladen, dann muss nix installiert werden. Frintends gibt's zum download auch für Linux, OS X etc

Ihr benötigt ein Headset bzw Kopfhörer+Mic. Telefoneinwahl kostet 14ct/min.

Gruß+bis 19:30,
Uli