FHEMWEB und Leerstellen (und ggf. andere Zeichen)

[Martin Fischer]

hiya boris,

heute ist mit aufgefallen, das du (oder davor schon jemand anderes) in FHEMWEB
scheinbar leerstellen in ein geschütztes leerzeichen (NBSP) umwandelst. ggf.
sind auch andere zeichen davon betroffen. dadurch wird ein anderes verhalten
gegenüber der konsole erzielt, was nicht sein sollte.

ergo:
ein "attr foobar room EG Wohnzimmer" in FHEMWEB erzeugt einen raum
"EG(NBSP)Wohnzimmer" mit geschütztem leerzeichen was natürlich in der GUI
nicht sichtbar ist. da du evtl. einen mailclient mit HTML nutzt, habe ich den
platzhalter (NBSP) anstelle des html-codes verwendet.

ausserdem funktioniert das "rename" nicht mehr:
ein per autocreate erzeugtes wandthermostat CUL_HM_HM_CC_TC_19DF7B zum
nachstellen:

über FHEMWEB:
- raum CUL_HM auswählen
- device CUL_HM_HM_CC_TC_19DF7B auswählen
- attr room "EG Wohnzimmer" in der GUI setzen
- "rename CUL_HM_HM_CC_TC_19DF7B EG.wz.CC.TC.01" in der GUI setzen

ergebnis:
- device _nicht_ umbenannt
- zwei räume "EG Wohnzimmer" in der GUI zu sehen
- "EG Wohnzimmer" (aus .cfg _ohne_ geschütztem leerzeichen)
- "EG(NBSP)Wohnzimmer" (aus FHEMWEB _mit_ geschütztem leerzeichen)

der raum "EG(NBSP)Wohnzimmer" ist leer, das device CUL_HM_HM_CC_TC_19DF7B
heisst immer noch so wie vorher.

in der fhem konsole nach dem rename über FHEMWEB:
fhem> rename CUL_HM_HM_CC_TC_19DF7B EG.wz.CC.TC.01
fhem> list EG.wz.CC.TC.01
Internals:
[...]
Attributes:
devInfo 00FFFF
firmware 2.1
hmClass unknown
model HM-CC-TC
room EG&nbsp;Wohnzimmer <--- hier _mit_ NBSP
serialNr JEQ0021872
subType unknown

fhem> attr EG.wz.CC.TC.01 room EG Wohnzimmer
fhem> list EG.wz.CC.TC.01
Attributes:
devInfo 00FFFF
firmware 2.1
hmClass unknown
model HM-CC-TC
room EG Wohnzimmer <--- hier _ohne_ NBSP
serialNr JEQ0021872
subType unknown

html-code gehört meiner meinung nach _nicht_ in dieses oder ähnliche felder,
weil es dann auf der fhem konsole zur unleserlichkeit führt.

gruss martin

[Dr. Boris Neubert]

Hallo,

die nbsp stammen nicht (bewußt) von mir - müssen wir reinschauen.

Viele Grüße
Boris

Martin Fischer <m_fi...@gmx.de> schrieb:

-- 
Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe FHEM developers beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-de...@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, 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.
 

[Rudolf Koenig]

> - attr room "EG Wohnzimmer" in der GUI setzen

Das ist ein Konsequenz meiner Loesung des Problems:
"Leerzeichen im Raumnamen gehen in FHEMWEB nicht"
War aktuell vor ca vor einem halben Jahr, siehe "svn blame 01_FHEMWEB.pm":
1458 rudolfkoenig $roomList=~s/ /\&nbsp;/g;
es gibt auch eine Diskussion dazu.

Neu ist, dass solche Raeume nicht mehr funktionieren (sind leer), und dass im
Dropdown das nbsp auftaucht. Ich vermute letzteres als die eigentliche Ursache.
Btw. rename funktioniert bei mir ohne Probleme.

[Rudolf Koenig]

Das Problem mit dem nbsp; stammt wahrscheinlich nicht von den aktuellen
Aenderungen von Boris.

Nach einem diff sind mir noch folgene Punkte aufgefallen:

- meine bekanntgegebene Modifikation von der Wochenende (fhemweb schaut auch
nach dem Uebersetzten Status als Bild) ist rausgeflogen.

- wenn ich es richtig sehe, funktionieren .jpg/.gif nicht mehr, nur noch .png

- das Einlesen der Icons ist deutlich langsamer jetzt, da alle Dateien mit
stat() geprueft werden, damit das rekursive Lesen klappt. Das ist ein netter
Feature, bin aber der Ansicht, dass es nicht Wert ist.

- Es existiern noch Refenzen auf $FW_ME/docs/commandref.html

- Wie auch in der Gruppe erwaehnt: fhem.cfg in Edit Files wird falsch
abgespeichert.

- ich finde die Ergebnisse von FW_SetDirs sollten gecached werden, damit
FHEMWEB nicht bei jedem Zugriff unnoetige Filesystemoperationen
durchfuehrt.

Ich faende es gut, wenn ein Modul nur von einem Entwickler bearbeitet wird, und
nur unwesentliche Aenderungen (tippfehler/etc) von jemanden anderen gemacht
werden. Sonst stellt sich schnell der Zustand ein, dass keiner sich zustaendig
fuehlt, und das will ich vermeiden.

Damit liegt das Beheben des nbsp Problems samt o.g. Punkte z.Zt. bei Boris, er
hat ja FHEMWEB de facto von mir entwendet. Und damit auch die Probleme :)

[Dr. Boris Neubert]

Hallo,

Am 18.07.2012 11:27, schrieb Rudolf Koenig:
> - meine bekanntgegebene Modifikation von der Wochenende (fhemweb schaut auch
> nach dem Uebersetzten Status als Bild) ist rausgeflogen.

tut mir leid, beim svn merge mit anschließender Konfliktlösung habe ich
die Zeile übersehen. Kannst Du sie bitte wieder einbauen?

> - wenn ich es richtig sehe, funktionieren .jpg/.gif nicht mehr, nur noch .png

Das Thema bereitet mir Kopfzerbrechen. Die Icons sind derzeit im
%FW_icons wie folgt abgelegt:

logischer Pfad zum Icon mit .png => voller physischer Dateiname lokal zu
$FW_icondir

Der logische Pfad ist der Teil hinter dem
http://meinserver:8083/fhem/images/

Beispiele:

icoTempHausRegEG.png => /dark/icoTempHausRegEG.png
sunny.png => /default/weather/sunny.png

An manchen Stellen mußte ich beim Umbau ein .png als Suffix an den
logischen Pfad hängen (bei allen Übersetzungen von Gerätenamen nach Icon
usw.).

Es wäre besser, wenn der logische Pfad ohne Suffix auskommt und die
Vorfahrtslogik für Suffixe zum Einsatz kommt (präferiere .png vor .gif
vor .jpg).

Beispiele:

icoTempHausRegEG => /dark/icoTempHausRegEG.gif
sunny => /default/weather/sunny.png

http://meinserver:8083/fhem/images/icoTempHausRegEG würde dann
$FW_icondir/dark/icoTempHausRegEG.gif liefern.

Allerdings hätte das an anderen Stellen Rattenschwänze an Änderungen
nach sich gezogen, die ich zum Zeitpunkt der ganzen Änderungen vor ein
paar Wochen noch nicht überblickt habe.

Ich schlage vor, das wie beschrieben zu ändern.

> - das Einlesen der Icons ist deutlich langsamer jetzt, da alle Dateien mit
> stat() geprueft werden, damit das rekursive Lesen klappt. Das ist ein netter
> Feature, bin aber der Ansicht, dass es nicht Wert ist.

Ich liebe Ordnung im Dateisystem. Ich habe das deswegen umgebaut, damit
ich die Weather-Icons von Michael Preidel zusammen mit einer
COPYRIGHT-Notiz in einem Unterordner halten kann. Es sollte kein Problem
sein, wenn wir den übernächsten Punkt umsetzen.

> - Es existiern noch Refenzen auf $FW_ME/docs/commandref.html

Das ist so richtig. $FW_ME/docs/commandref.html sorgt dafür, daß die
commandref via http://meinserver:8083/fhem/docs/commandref.html
serviert wird. Die einzige Stelle, wo $FW_docdir/commandref.html steht
ist jene, wo nach Klick auf den Menüpunkt "Definition..." die Definition
aus der commandref herausgeschnitten und angezeigt wird.

>
> - Wie auch in der Gruppe erwaehnt: fhem.cfg in Edit Files wird falsch
> abgespeichert.

Autsch, das habe ich vermasselt. Ich habe das jetzt repariert und ins
SVN eingecheckt. Die elementaren Schutzmechanismen habe ich dabei
entfernen müssen. Mit "Save as" kann der Benutzer jetzt überall ins
Dateisystem speichern, wo fhem Schreibrechte hat. Ein Argument dafür,
fhem nach dem Start die Rechte bis aufs Minimum wegzuschneiden.

> - ich finde die Ergebnisse von FW_SetDirs sollten gecached werden, damit
> FHEMWEB nicht bei jedem Zugriff unnoetige Filesystemoperationen
> durchfuehrt.

Ich hatte den bisherigen Mechanismus dringelassen, daß die Icons
frühestens nach 5 Sekunden erneut gesucht werden. Ich fände es auch
besser, wenn die Icons einmal beim define des FHEMWEB-Geräts eingelesen
werden und danach mit set ... rereadimages explizit vom Anwender
aktualisiert werden.

Grüße
Boris

[Dr. Boris Neubert]

Hallo,

Am 18.07.2012 11:27, schrieb Rudolf Koenig:

> Ich faende es gut, wenn ein Modul nur von einem Entwickler bearbeitet wird, und
> nur unwesentliche Aenderungen (tippfehler/etc) von jemanden anderen gemacht
> werden. Sonst stellt sich schnell der Zustand ein, dass keiner sich zustaendig
> fuehlt, und das will ich vermeiden.

ich hoffe, daß Du das WIR in meiner Aussage "Das müssen WIR uns
ansehen." nicht als RUDI interpretiert hast. Ich hatte schon vor, mir
das anzusehen

Es gibt sicher zahlreiche Argumente für und gegen die Regel, daß nur der
Owner eines Moduls dieses auch substantiell ändern sollte. Eines dafür
lautet: Es gibt eine Person, die sich bestens auskennt. Und eines
dagegen lautet: Es gibt eine Person, die sich bestens auskennt. :-)

Grüße
Boris

[Dr. Boris Neubert]

Hallo,

Am 18.07.2012 00:16, schrieb Martin Fischer:
> ergo:
> ein "attr foobar room EG Wohnzimmer" in FHEMWEB erzeugt einen raum
> "EG(NBSP)Wohnzimmer" mit geschütztem leerzeichen was natürlich in der GUI

das kann ich nicht nachvollziehen.

Ich habe

attr Calendar room bla bla

im Webfront eingegeben. Im HTML-Kode sieht der Raum dann im Menü so aus:

<a href="/fhem?room=bla%20bla"><div>bla bla</div></a>

Also mit einem normalen Space %20 und keiner &nbsp;-Entity.

Der Raum enthält den Calendar.

> ausserdem funktioniert das "rename" nicht mehr:
> ein per autocreate erzeugtes wandthermostat CUL_HM_HM_CC_TC_19DF7B zum
> nachstellen:

Kann ich auch nicht nachstellen.

rename Calendar Paulchen

funktioniert bei mir (Eingabe über das Webfrontend).

Wie kreisen wir das Problem ein?

Viele Grüße
Boris

[Rudolf Koenig]

> Also mit einem normalen Space %20 und keiner &nbsp;-Entity.

Stimmt. Jetzt geh mal ins Detail-Ansicht eines anderes Geraetes, und weise
diesem das vorherige Raum (mit Leerzeichen) zu, mit dem dropdown neben "attr
room".
-> Hier steht EG(NBSP)Wohnzimmer.

(bin selber genauso reingefallen, und war schon fast mit dem "kann nicht
nachvollziehen" mail fertig :)

[Rudolf Koenig]

> Es gibt sicher zahlreiche Argumente f�r und gegen die Regel, da� nur der
> Owner eines Moduls dieses auch substantiell �ndern sollte. Eines daf�r

> lautet: Es gibt eine Person, die sich bestens auskennt. Und eines
> dagegen lautet: Es gibt eine Person, die sich bestens auskennt. :-)

Stimmt. Ich warte aber jetzt solange, bis Du mit den aktuellen Aenderungen grob
durch bist. Dann klaue ich mir FHEMWEB zurueck. :)

[Rudolf Koenig]

> Es w�re besser, wenn der logische Pfad ohne Suffix auskommt und die
> Vorfahrtslogik f�r Suffixe zum Einsatz kommt (pr�feriere .png vor .gif
> vor .jpg).

Das war bisher so, $FW_icons{logischer_name} = vollstaendiger_name (bzw. das,
was FHEMWEB zum ausliefern braucht).


> Ich f�nde es auch besser, wenn die Icons einmal beim define des
> FHEMWEB-Ger�ts eingelesen werden und danach mit set ... rereadimages explizit
> vom Anwender aktualisiert werden.

Einverstanden.

[Martin Fischer]

Am Mittwoch, 18. Juli 2012, 20:52:55 schrieb Dr. Boris Neubert:
> [...]

> Ich habe
>
> attr Calendar room bla bla
>
> im Webfront eingegeben. Im HTML-Kode sieht der Raum dann im Menü so aus:

ich hatte vergessen zu erwähnen, dass du das über den "drop-down attr" setzen
musst. dann sollte es auch bei dir nachzustellen sein.

[Martin Fischer]

hallo boris,

desweiteren habe ich heute festgestellt, dass du scheinbar unter windows
entwickelst, denn anders kann ich mir die neuerdings autretenden ^M (cr,lf) am
zeilenende in den logfiles (und wo du das auch sonst noch hast) nicht
erklären:

2012.07.20 00:13:37 4: HTTP FHEMWEB:127.0.0.1:56902 GET
/fhem/icons/icoEverything.png
2012.07.20 00:13:37 4: /fhem/icons/icoEverything.png / RL: 344 / image/png /
/ Expires: Fri Jul 20 00:28:37 2012 GMT^M

2012.07.20 00:13:37 4: HTTP FHEMWEB:127.0.0.1:56903 GET /fhem/icons/off.png
2012.07.20 00:13:37 4: /fhem/icons/off.png / RL: 2282 / image/png / /
Expires: Fri Jul 20 00:28:37 2012 GMT^M

2012.07.20 00:13:37 4: HTTP FHEMWEB:127.0.0.1:56902 GET /fhem/fhem.png
2012.07.20 00:13:37 4: /fhem/fhem.png / RL: 7911 / image/png / / Expires: Fri
Jul 20 00:28:37 2012 GMT^M

2012.07.20 00:13:38 4: HTTP FHEMWEB:127.0.0.1:56902 GET /fhem?room=CUL_HM
2012.07.20 00:13:38 4: /fhem?room=CUL_HM / RL: 912 / text/html; charset=UTF-8
/ Content-Encoding: gzip^M
/
2012.07.20 00:13:40 4: HTTP FHEMWEB:127.0.0.1:56902 GET /fhem?room=all
2012.07.20 00:13:40 4: /fhem?room=all / RL: 1340 / text/html; charset=UTF-8 /
Content-Encoding: gzip^M

[Martin Fischer]

hallo boris,

Am Mittwoch, 18. Juli 2012, 20:52:55 schrieb Dr. Boris Neubert:
> [...]

> Am 18.07.2012 00:16, schrieb Martin Fischer:
> > ergo:
> > ein "attr foobar room EG Wohnzimmer" in FHEMWEB erzeugt einen raum
> > "EG(NBSP)Wohnzimmer" mit geschütztem leerzeichen was natürlich in der GUI
>
> das kann ich nicht nachvollziehen.

konntest du das inzwischen nachstellen?

siehe anhang...

[Dr. Boris Neubert]

Hallo Martin,

Am 20.07.2012 08:43, schrieb Martin Fischer:
> desweiteren habe ich heute festgestellt, dass du scheinbar unter windows

nö, Linux, seit eh und je.

> entwickelst, denn anders kann ich mir die neuerdings autretenden ^M (cr,lf) am
> zeilenende in den logfiles (und wo du das auch sonst noch hast) nicht
> erklären:

Habe mir 01_FHEMWEB.pm mit einem Hexeditor angesehen und da ist keine
einzige 13 (0x0d) drin.

Es ist einfach so, daß der Carriage Return explizit geschrieben wird:

grep Expires *
01_FHEMWEB.pm: ("Expires:
".localtime(time()+900)." GMT\r\n") : "");

Grüße
Boris

[Dr. Boris Neubert]

ich habe mich jetzt eine Stunde in diese Sache vertieft.

Ich habe bei mir Revision 1458 installiert und damit funktioniert(e) es.

Mit HEAD (1739) funktioniert es nicht. Das &nbsp; erscheint im
Dropdown-Menü.

Ursache sind die Änderungen von Revision 1465 auf 1472 in FW_makeSelect.

Diese Änderungen überblicke ich nicht.

Rudi, die Änderungen sind von Dir. Kannst Du Dir bitte ansehen, was das
passiert ist?

Danke
Boris

[Rudolf Koenig]

> Rudi, die �nderungen sind von Dir. Kannst Du Dir bitte ansehen, was das
> passiert ist?

Ich habe jetzt Raeume mit Leerzeichen aus dem dropdown entfernt. Solche
Raumnamen kann man weiterhin im Freitext zuweisen, angezeigt wird es (soweit
ich es sehe) auch richtig.

Hab auch aus den FW_dev2image entfernten eventmap Aenderungen wieder
zurueckgepackt, und undefined Meldungen im Fall von fehlenden icons entfernt.
Dass in FW_icons{<name>} das .png mitgegeben werden muss, verwirrt mich immer
noch. Ich meine das muss da raus.

Hab fhemupdate gestartet.

[Dr. Boris Neubert]

Am 21.07.2012 13:48, schrieb Rudolf Koenig:
> Dass in FW_icons{<name>} das .png mitgegeben werden muss, verwirrt mich immer
> noch. Ich meine das muss da raus.

Ich stelle mir die Anpassungen wie folgt vor:

1. Im Code wird nur noch mit logischen Pfaden zu Icons gearbeitet.
Beispiele:
FS20.on
weather/sunny


2. Im Code kann man sich den physikalischen Pfad relativ zu $FW_icondir
für den logischen Pfad zu einem Icon mit

FW_getIcon(LogischerIconName)

beschaffen (Routine von Rudi). Beispiele:
FS20.on -> default/FS20.on.png
weather/sunny -> default/weather/sunny.gif
fhem -> dark/fhem.png

Die Ermittlung des Mappings vom logischen zum physikalischen Pfad findet
einmalig bei der Definition des FHEMWEB-Device statt und später auf
Anforderung mit set myFHEMWEB rereadicons.


3. Die Weboberfläche zieht sich ein Icon von

$FW_ME/icons/LogischerIconName


4. Im Code wird diese URL gekapselt durch

FW_IconURL(LogischerIconName)

Diese Routine ist schon eingebaut. Im Moment verarbeitet sie sowohl

FW_IconURL("FS20.on")

als auch

FW_IconURL("FS20.on.png")

Das letztere wird dann später wieder verboten, wenn alles funktioniert.
Ich habe das deswegen schon jetzt eingebaut, damit Uli den FLOORPLAN
reparieren kann, und sich damit hoffentlich von den noch kommenden
Änderungen abkapselt. Ich weiß nämlich noch nicht, wann ich die
Änderungen vollständig durchgeführt und getestet haben werde.

Findet das Zustimmung?

Viele Grüße
Boris

[Dr. Boris Neubert]

Am 21.07.2012 17:59, schrieb Dr. Boris Neubert:

> Ich stelle mir die Anpassungen wie folgt vor:
>
> 1. Im Code wird nur noch mit logischen Pfaden zu Icons gearbeitet.
> Beispiele:
> FS20.on
> weather/sunny
>
>
> 2. Im Code kann man sich den physikalischen Pfad relativ zu $FW_icondir
> für den logischen Pfad zu einem Icon mit
>
> FW_getIcon(LogischerIconName)
>
> beschaffen (Routine von Rudi). Beispiele:
> FS20.on -> default/FS20.on.png
> weather/sunny -> default/weather/sunny.gif
> fhem -> dark/fhem.png
>
> Die Ermittlung des Mappings vom logischen zum physikalischen Pfad findet
> einmalig bei der Definition des FHEMWEB-Device statt und später auf
> Anforderung mit set myFHEMWEB rereadicons.

und wenn ein neuer Style mit attr gesetzt wird.

[Martin Fischer]

Am Samstag, 21. Juli 2012, 13:48:45 schrieb Rudolf Koenig:
> [...]

> Ich habe jetzt Raeume mit Leerzeichen aus dem dropdown entfernt. Solche
> Raumnamen kann man weiterhin im Freitext zuweisen, angezeigt wird es (soweit
> ich es sehe) auch richtig.

hm... das verwirrt aber auch wieder... ich habe zum beispiel in _allen_ räumen
eine leerstelle, damit ich zwischen den etagen unterscheiden kann:
EG Wohnzimmer
OG Wohnzimmer
KG ...
DG ...
...

das heisst, das ich dann ausser "Haus", "Garten", "Server", "Unsorted" und
"hidden" keine weitere räume mehr im dropdown habe. :-(

irgendwie widerstrebt es mir nun auch noch in raumnamen trennzeichen einbauen
zu müssen. darunter leidet die anwenderfreundlichkeit aus meiner sicht.

ich finde schon die darstellung im raum "Everything" sowie andFHEM nicht so
sinnvoll, wo anstelle dem devicenamen _nur_ der alias angezeigt wird. alias
ist aber gerade für den "endanwender" wichtig (kam übrigens mal auf meinen
wunsch hinzu, da es damals nur "comment" gab).

beispiel aus raum "Everything":
CUL_FHTTK
Fenster (links) Closed
Fenster (mitte) Closed
Fenster (rechts) Closed
Fenster Closed
Fenster Closed
Fenster Closed
Fenster Closed
Fenster Closed
Fenster Closed
Fenster Closed
Balkontuer Closed
Fenster Closed

welches fenster ist nun in welchem raum? erst wenn ich mit der maus drüber
gehe, kann ich es anhand der logischen devicesnamen erkennen:
z.b. bei "Fenster (rechts)" = EG.bz.TK.03 und ich weiss, das es ein
tür-/fensterkontakt im badezimmer, erdgeschoss ist.

schöner wäre in "Everything" sowas wie:
CUL_FHTTK
Raum: EG Badezimer
Fenster (links) Closed
Fenster (mitte) Closed
Fenster (rechts) Closed
Raum: EG Esszimmer
Fenster Closed
Raum: EG Kinderzimmer
Fenster Closed
...
Raum: Unsorted
Fenster Closed
Fenster Closed
Raum: hidden
Fenster Closed

CUL_HM
Raum: ...
...

man hätte alle notwendigen informationen. und wenn jemand keine räume
definiert hat, dann stehen sie halt alle unter CUL_FHTTK -> Raum: Unsorted

schlimmer wird es in "Everything" mit der anzeige der aliases, wenn viele
devices aus einem "technik-typ" kommen. ich stelle z.b. gerade vieles auf
homematic um. hier ein beispiel aus meinem "CUL_HM" (status mal weggelassen):
CUL_HM
Deckenlampe Gang
Beleuchtung Spiegel
Deckenlampe
Deckenlampe
Fenster
Deckenlampe
Wandthermostat
Heizung (Fenster Garten)
Heizung (Fenster Strasse)
Deckenstrahler (Fenster Garten)
Deckenstrahler (Fenster Strasse)
Deckentrahler (Mitte)
Fernseher (alle Komponenten)
Stehlampe Fernseher
Terrassentuer
Fenster (Garten)

auch hier kann ich schon nicht mehr unterscheiden wo welches device verbaut
ist. hier hilft wie oben auch nur das "überfahren" mit der maus und ein blick
in die statusleiste des browsers. wenn ich bedenke, das ich demnächst, nur in
meinem erdgeschoss zusätzlich noch ca. 5x wandthermostate mit 5x stellantrieb,
7x "threeStateSensor" und noch weitere "zwischenstecker" nachziehe, dann wird
CUL_HM im raum "Everything" unbrauchbar. nun könnte mir ja jemand den "tip"
geben, den raum im alias anzugeben. naja... dann befände ich mich im raum "EG
Wohnzimmer" und sehe den thermostat "Wandthermostat EG Wohnzimmer". das wäre
in etwa wie emailadressen im format <vorname>@<vorname>.<nachname>.tld.
unschön..

und wenn ich schon bei den "räumen" bin:
auch hier sollte in der anzeige nicht mehr zwischen "device-typ" unterschieden
werden. was interessiert es den "rest der familie" ob ein "Wandthermostat" nun
vom typ CUL_HM oder FHT oder die "Stehlampe Fenster" über FS20 und die
"Stehlampe Fernseher" über CUL_HM geschaltet wird?

vielleicht könnte man da ein "mapping" integrieren. ich glaube boris hatte da
mal was in richtung "deviceklassen" angeregt?!?

es wird nicht langweilig ;-)

gruss martin

[Martin Fischer]

Am Samstag, 21. Juli 2012, 17:59:32 schrieb Dr. Boris Neubert:
> Am 21.07.2012 13:48, schrieb Rudolf Koenig:
> > Dass in FW_icons{<name>} das .png mitgegeben werden muss, verwirrt mich
> > immer noch. Ich meine das muss da raus.
>
> Ich stelle mir die Anpassungen wie folgt vor:

> [...]
> Findet das Zustimmung?

ich bin da leidenschaftslos :-)

wichtig ist mir an dieser stelle nur der hinweis von uli: wenn ich mir html-
quelltext ansehe, dann muss mir klar sein aus welchem verzeichnis die datei
kommt.

[Rudolf Koenig]

> irgendwie widerstrebt es mir nun auch noch in raumnamen trennzeichen einbauen

> zu m�ssen. darunter leidet die anwenderfreundlichkeit aus meiner sicht.

Musst Du ja nicht, diese sind halt dann bis auf Weiteres nur im Dropdown nicht
verfuegbar.


> welches fenster ist nun in welchem raum? erst wenn ich mit der maus dr�ber

> gehe, kann ich es anhand der logischen devicesnamen erkennen:
> z.b. bei "Fenster (rechts)" = EG.bz.TK.03 und ich weiss, das es ein

> t�r-/fensterkontakt im badezimmer, erdgeschoss ist.

Wenn jemanden Everything wichtig ist, der sollte keine gleichlautenden aliase
vergeben. Oder andersherum.


> sch�ner w�re in "Everything" sowas wie:

Evtl. hift Dir das group Attribut. Ja, mir ist das "aber" bekannt.

> auch hier sollte in der anzeige nicht mehr zwischen "device-typ" unterschieden
> werden.

Das hatten wir schon mal (ich bin damit als Erstes auf die Nase gefallen),
daraufhin hat Boris das group Attribut eingebaut.

> es wird nicht langweilig ;-)

Bis 5.3 doch :)