Namenskonvention für icons

Begonnen von UliM, 11 Juni 2013, 12:45:44

Vorheriges Thema - Nächstes Thema

UliM


Hallo allerseits,
Im Forum werden gerade viele schöne icons beigesteuert.
Bisher gibt es nicht wirklich eine Namenskonvention.

Es gibt fhem-Standardicons zu TYPE, STATE usw. Diese sollten m.E. -wie auch alle anderen bereita eingecheckten icons- unverändert bleiben.

Bei einigen icons habe ih mal das Farbschema vorangestellt, also predig blk_ oder blu_
Bei steigender Anzahl Dateien fände ich die Nutzung einer Namenskonvention gut.

Vorschlag für alle zukünftig eingecheckten icons:
<Themengebiet>_<Farbschema>_<Beschreibung>

Themengebiete: hc=HeatingControl, rc=RemoteControl, li=Lighting, au=Audio, wd=Windows&Doors, ..., ge=General
Farbschemata: blk, blu, wht, trp (transparent), usw Isocodes
Also zB
hc_blk_Radiator-cold.png

Ggf müsste zumindest teilweise auch die Quelle mit eingebaut werden, teilweise auch die Nutzung von Unterordnern für spezielle Zwecke.

Was meint ihr?

Gruß, Uli
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

justme1968

eine namenskonvention finde ich sehr gut.

das farbschema würde ich aber versuchen über einen unterordner lösen. das macht zum einen das icon verzeichniss ein wenig übersichtlicher und würde erlauben das farbschema auf einen schlag umzustellen oder z.b. für zwei web definitionen unterschiedliche schemata zu verwenden ohne jede einzelne definition in fhem anzupassen.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Ich finde es gut, dass diese Diskussion nicht mehr im alten Thread stattfindet, danke Uli.

Ich habe z.Zt. etwas andere Plaene mit diesen Icons: ich habe sie mit potrace (geniales Programm, wird auch von inkscape verwendet) nach SVG konvertiert, und ich versuche diese in FHEMWEB verwendbar zu machen.

Vorteile von SVG:
Groesse/default-Farbe kann man per stylesheet steuern, sogar eine individualFarbe ist moeglich durch zusaetzliches Attribut. Den Syntax fuer Individualfarbe weiss ich noch nicht genau, aber FHEM muss dazu in der .svg nur ein bestimmtes Wort austauschen, und sowas geht in Perl einfach :) Skalieren funktioniert problemlos, haengt natuerlich vom Browser ab, ob es gut ist.
Nachteil: nicht alle Browser koennen SVG, z.Bsp. der default unter Android < 3.0.

Ich wuerde die Dateinamen der openautomation icons im Ehren der Erschaffer (bzw. in der Hoffnung, dass wir mal update machen koennen :) belassen, eine Aufteilung nach Themengebiete gibts da schon. Fuer andere Icons habe ich nichts gegen Ulis Vorschlag einzuwenden, fuer SVG wuerde ich aber Farbschema ins stylesheet auslagern.

Ich moechte eine weitere Datei (iconalias.txt) erstellen, wo drin steht, dass light_light_dim_00.svg fuer off und Aus steht. Damit koennte man auch das FS20 vs HomeMatic dim% Problematik elegant loesen. Welche Verzeichnisse fuer default genommen werden (off aus Alt-Png oder Neu-SVG), muessen wir irgendwie per Attribut steuern.

Fragen/Kommentare?

justme1968

das ist noch viel besser...

mit einem ganz kleinen aber. hast du schon geschaut ob die icons (besonders automatisch konvertiert) als svg wirklich so klein funktionieren? wir haben in diversen projekten auch in zusammenarbeit mit designer leider immer die erfahrung machen müssen das es unterhalb von etwa 48x48 nicht mehr automatisch geht und das sogar die von hand entworfenen icons oft in extra versionen erstellt werden müssen. ich fürchte das wird hier für die grössen 32 und 24 auch so sein.

wir machen es jetzt bei uns so das wir icons zumindest in klein und gross vorhalten und nur dann automatisch skaliert wird wenn es ein icon nicht in der angeforderten größe gibt. so kann man für die kleinen grössen auch von hand bearbeitete png verwenden und svg nur für alles größere. das kann man auch für den client transparent machen und im server kapseln.

lange rede kurzer sinn: ich würde vorschlagen das man auf server seite zumindest nachschaut ob unterhalb einer bestimmten grösse zum svg ein png vorhanden ist und dieses als default ausliefert.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dirk

SVG ist zwar toll, aber gibt es möglicherweise noch Icons die nur als png, gif, usw. vorliegen. Vor allem wenn der User die selber vergeben möchte. Daher sollte das Ganze nicht nur aucf SVG beschränkt sein.

Auch ein Ordner für Farbschemen macht sinn. Oder alternativer Name "Stylesets" oder ähnlich. In dem könnten auch die passende(n) CSS-Datei(en) Platz finden. Die dann beim Laden eines "Stylesets" benutzt wird.
Quasi als Weiterentwicklung zu den bisherigen darksvg_style.css usw.

UliM

Hi,
Unterordner für fhem-styles gibt's ja schon, zB dark .

M.E. hat das aber nur selten was mit dem icon zu tun. Ob ich ein icon mit schwarzem icon-Hintergrund in einen screen packe, der seinerseits als Hintergrundfarbe schwarz oder gelb oder sonstwas hat, hat ja nur selten was mit ebendieser Hintergrundfarbe zu tun - ist Geschmacksache.

Wenn ich Dich richtig verstehe, möchtest Du zB ein weiteres gesamtes Farbschema zB 'blue' erstellen. Geht, dann gehören alle icons, die sinnvollerweise ausschließlich in diesem Farbschema verwendet werden, in den Ordner blue. Die css liegt in pgm2 und heisst bluestyle.css .

Das ist aber was anderes als ich mit Unterordnern meinte. Ich stelle mir die eher themenbezogen vor (so wie es schon default/weather gibt, gedenke ich alsbald default/remotecontrol einzucheken).
Oder eben nach Hintergrundfarbe des icons - nur kann man die dann nicht mehr via FHEMWEB zuordnen, sobald sie in nem Unterordner liegen. Das ist doof. Daher mein Vorschlag mit der Dateinamenskonvention.

=8-)
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

justme1968

warum hintergrund farbe? die icons sollten doch transparent sein. oder meinst du die vordergrund farbe? wenn es ein icon jeweils in z.b. rot und grün gibt um zwei zustände anzuzeigen dann gehört es in den namen, wenn es die allgemeine farbe eines iconsets ist sollte die auf keinen fall im namen codiert weil es sonst z.b. nicht wirklich möglich ist für den darkstyle eine andere farbe zu verwenden wie für das web auf dem mobile port.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

UliM

Zitat von: justme1968 schrieb am Di, 11 Juni 2013 21:56warum hintergrund farbe? die icons sollten doch transparent sein.
Ebenfalls Geschmacksache. Ich meinte durchaus die Hintergrundfarbe des icons selbst.
Schau mal auf Deinem Rechner in www/images/default, da gibt's zB black_Steckdose.off.png, black_Steckdose.on.png
Sowas meinte ich.
Für transparente icons könnte man ja wie o.g. statt black_ dann transp_ oder so nehmen.

=8-)
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

justme1968

für mich ist das die vordergrundfarbe. und genau das was nicht in den namen sollte. der farbige ring bei der steckdose grün würde aber meiner meinung nach in den namen gehören weil ich mit gut auch eine mit rotem oder gelben kreis vorstellen kann

der hintergrund bei deinem bild ist sehr klein. nur die runden ecken. aber der ist transparent. das gehört nicht in den namen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dirk

Zitat von: UliM schrieb am Di, 11 Juni 2013 21:19Hi,
Unterordner für fhem-styles gibt's ja schon, zB dark .
Ja stimmt. Ich hatte eher das Zusammenfassen aller Layout Ressourcen im Sinn. Also Images, Icons, Css. ggf. zusätzlich optionales Javascript. Ggf. sogar mal an Templates für das HTML denken. Ich weiß, das ist jetzt sicher zuviel des Guten, aber vielleicht kann man das als Idee mal mitnehmen. Da müsste dann vor allem auch das Rendering der einzelnen Geräte angepasst werden.

ZitatWenn ich Dich richtig verstehe, möchtest Du zB ein weiteres gesamtes Farbschema zB 'blue' erstellen.
Eher eine zentrale Sammlung des Designs. Ein neues Desgin bedarf derzeit zusätzlich zum Images-Ordner noch eine seperat abgelegte CSS-Datei. Zusammengelegt könnte man das einfacher austauschen.

ZitatDas ist aber was anderes als ich mit Unterordnern meinte.
Ja, das geht etwas weiter.
Zitatnur kann man die dann nicht mehr via FHEMWEB zuordnen
Das müsste man dann entsprechend programmtechnisch umsetzen.

Wie gesagt, das geht über das hinaus was du mit Unterordnern meinst. Ist auch nur als Anregung.

Gruß
Dirk

rudolfkoenig

Ich habe die openautomation Icons samt zugehoerigen FHEMWEB Aenderungen eingecheckt. Da sourceforge gerade jetzt die fhem-Umstellung geschafft hat (grrr) und ziemlich spaet ist, ist evtl. was schiefgegangen, bitte melden.

Aenderungen:
- www/images/openautomation/*.svg hinzugefuegt. Dazu habe ich erst den 480x480-er .pngs die Raender abgeschnitten und nach .png konvertiert.
- iconPath FHEMWEB Attribut hinzugefuegt. Bestimmt die Reihenfolge der Bildsuche. Default ist $stylesheetPrefix:default, ich empfehle es auf openautomation zu setzen, um diese SVG's zu testen. Oder auf
openautomation:default.
- FHEMWEB kann jetzt .svg Dateien anzeigen. Achtung: das Format ist leicht eingeschraenkt: die ersten 3 Zeilen werden immer abgeschnitten (wg. DOCTYPE &co), und ein fill="#000000" wird auch erwartet bzw. ersetzt.
- falls im devStateIcon eine SVG Datei spezifiziert wird, dann kann man mit dem Suffix @red oder @FFF die Farbe fuer diesen Fall bestimmen. Sonst wird das default in dem Stylesheet bestimmt, hier kann man fuer einzelne Bilder es aber ueberschreiben (mit Hilfe der HTML class, siehe letzte Zeile im style.css)
- Falls im images/xxx Ordner sich eine iconalias.txt Datei befindet, dann kann man hier Uebersetzungen fuer die Bilder definieren, z.Bsp. "Aus light_light_dim_00.svg", usw.
Ich meine diese Datei sollte noch ergaenzt werden.

Funktioniert mit Firefox, Chrome und Android 4.1.

Safari ignoriert die Groessenangaben fuer die SVG. Wenn jemand weiss wieso, bitte melden.

rudolfkoenig

Hab noch Antowrt vom Autor bekommen:

==================
Hallo,
selbstverständlich geht das in Ordnung, die Icons sind ja dazu da
verwendet zu werden.
Für die SVG-Renderings kann ich allerdings nicht garantieren, dass
alles einwandfrei aussieht.

Als Hinweis: das Icon-Set ist in der nächsten Ausbaustufe auch als
SVG-Version geplant, damit sollen dann  auch detailierte Anpassungen
der einzelnen Icons möglich sein die im Moment nur über verschiedene
Einzel-Icons realisierbar sind.
Das wird aber noch eine (unbestimmte) Zeit dauern.

Gruß
mfd
M. Fuchs

rudolfkoenig

Safari habe ich jetzt gefixed (der hat sich an dem max-width gestoert, width scheint aber zu klappen).

Die Bilder habe ich jetzt auch als icons zugelassen, im Stylesheet koennte man die SVG-Dateien, wenn sie als icon angezeigt werden, auch anders einfaerben/vergroessern.

Im www/imgaes/default Verzeichnis wuerde ich noch Duplikate (on.png vs. FS20.on.png usw.) entfernen, und einen passenden Eintrag in iconalias.txt erstellen.
@Uli, wenn Du das uebernehmen willst, melde Dich.

justme1968

ich habe noch ein kleines problem die neuen svg icons (die sind übrigens auch so klein wirklich klasse sind) mit devStateIcon und {} zu verwenden:

  • ich würde gerne in bestimmten fällen das default icon für einen zustand verwenden z.b wenn die lampe aus ist und sonst etwas komplett anderes um z.b. die farbe anzuzeigen. bisher gebe ich dann z.b.
<img src="/fhem/icons/off" alt="off" title="off"> zurück. das ist das was fhem im nicht svg fall auch verwendet. wenn ich das aber bei aktivierten svg icons mache sind die icons nicht skaliert sondern bildschirm füllend.

-> es wäre schön in der rückgabe sagen zu können: verwende das default icon für den zustand xy. am besten noch mit der option die ersetzungsfarbe anzugeben.

-> ist es realstisch zu versuchen dich zu einer zweiten farbe pro icon die ersetzt wird zu überreden ?
  • wenn ich "" oder undef zurück gebe wird der state als text angezeigt.

    -> wie wäre es nur bei rückgabe von "" den text anzuzeigen und bei rückgabe von undef das default icon für den aktuellen state zu verwenden.[/list]
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

    https://github.com/sponsors/justme-1968

    rudolfkoenig

    Fuer alle die nicht ganz aufmerksam gelesen haben, es geht um den Sonderfall devStateIcon mit ausfuehrbaren Code in {}, was vmtl. bisher nur vom colorpicker bzw. justme1868 verwendet wird.


    > es wäre schön in der rückgabe sagen zu können: verwende das default icon für den zustand xy. am besten noch mit der option die ersetzungsfarbe anzugeben.

    Geht mir zuweit. Aber s.u.


    > ist es realstisch zu versuchen dich zu einer zweiten farbe pro icon die ersetzt wird zu überreden ?

    Nein, sonst kommt jemand mit Wunsch nach 3.Farbe/Linienfarbe/Dicke/etc. Ich habe aber fhemweb modifiziert, und das nach @ wird auch als Klasse in <SVG> eingetragen, damit kannst du dich in CSS beliebig austoben. Und falls kein fill="#000000" im SVG gefunden wurde, dann wird das @ auch nicht ersetzt.


    >  wie wäre es nur bei rückgabe von "" den text anzuzeigen und bei rückgabe von undef das default icon für den aktuellen state zu verwenden.

    Habs gemacht und eingecheckt aber nicht getestet.
    Falls es nicht funktioniert, bitte gleich einen Patch liefern.

    Gruss,
      Rudi

    justme1968

    danke. das hilft schon mal weiter. damit kann ich off, die dimbaren (nicht farbigen) lampen und die farbigen lampen im weiss modus abdecken. probiere ich heute abend gleich aus.

    die idee mit dem css ist auch besser als die farbe direkt anzugeben. zur zeit aber noch nicht vom {} code aus nutzbar. wenn wir noch eine möglichkeit finden vom {} aus das css für ein bestimmtes icon zu beeinflussen kann ich auch die farben mit den svg icons abbilden. die neuen icons sind so gut, es wäre dumm sie nicht zu nutzen.

    gruss
      andre
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

    https://github.com/sponsors/justme-1968

    justme1968

    so... kurzer zwischenstand: im prinzip geht es fast. aber es hakt noch an diversen stellen.

    - in zeile 2254 muss der operator 'eq' sein und nicht '=='. es ist ja ein string.
    - so wie ich es bisher mache devStateIcon aus dem code heraus auf '{CommandGet("","'.$name.' devStateIcon")}' zu setzen geht nicht. weil beim CommandGet das undef das ich zurückgebe in ein '' verwandelt wird. (ich weiss du magst nicht das ich es so verwende aber es war so implementiert bevor FW_summaryFn gab und FW_summaryFn funktioniert noch nicht richtig)
    - wenn ich es mit FW_summaryFn versuche klappt dann zwar die rückgabe, ich habe aber das problem das FW_summaryFn zu spät/gar nicht aufgerufen wird: beispiel: meine lampe ist aus und es wird das normale off icon angezeigt -> ich klicke auf die lampe, sie geht an und es wird das default on icon angezeigt ohne das FW_summaryFn aufgerufen wurde. erst wenn ich im browser ein refresh mache wird das icon angezeigt das FW_summaryFn zurück liefert.
    - FW_summaryFn hat nicht die möglichkeit das beim klick auszuführende kommando mit zurückzugeben

    gruss
      andre

    edit: ich habe mir jetzt einen wrapper HUEDevice_devStateIcon() geschrieben der als default für das devStateIcon gesetz wird devStateIcon {(HUEDevice_devStateIcon($name),"toggle")} und der selber wiederum meine FW_summaryFn aufruft die ich aber fhem nicht bekannt gemacht habe. damit kann ich undef zurückgeben und das kommando und es wird zum richtigen zeitpunkt aufgerufen. das ist zwar sicher nicht im sinne des erfinders von FW_summaryFn aber es funktioniert. d.h. ich kann erst mal damit leben.

    ich hab es gleich so gebaut das ich entweder den namen oder den hash übergeben kann. so kann ich es intern und für die user aufrufbar machen. gar nicht unpraktisch.

    jetzt fehlt nur noch das ich irgendwie aus dem code das css für das icon setzen kann.

    edit2: beim testen eben bemerkt: die webCmdFn wird auch zu spät bzw erst nach einem refresh der seite aufgerufen. nicht wenn ich auf der seite auf ein icon oder ein webCmd clicke.

    edit3: ich hatte vorhin meine änderungen am hue modul schon eingecheckt ohne daran zu denken das der string vergleich noch falsch war. ich habe mir  deshalb eben ausnahmsweise erlaubt das in 01_FHEMWEB direkt zu fixen und einzuchecken damit morgen/nachher nach dem update die icons im hue modul bei den anwendern noch gehen.
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

    https://github.com/sponsors/justme-1968

    justme1968

    wäre es für dich eine option das @... als rückgabe alternativ zum html zuzulassen? dann könnte ich genau das 'css austoben' das du vorgeschlagen hast vom modul code aus machen. sonst habe ich ja keine möglichkeit das icon spezifisch zu machen.
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

    https://github.com/sponsors/justme-1968

    rudolfkoenig

    > eine option das @... als rückgabe ...

    Du kannst ja auch FW_makeImage direkt aufrufen. Ich kann Dein Vorschlag mit @ einbauen, aber langsam wird es mir zu bunt mit den verschiedenen Rueckgabemoeglichkeiten: normal, undef, "" und @... Wer soll den Sinn ausser Dir noch verstehen...

    > FW_summaryFn zu spät/gar nicht aufgerufen wird:

    Das ist in der Tat ein Bug, ich hoffe ich habe es jetzt gefixed: es wurde bisher nur beim Seitenaufbau aufgerufen, aber nicht wenn longpoll nach dem Status gefragt hat. Kannst Du es bitte testen?
    Die anderen Beispiele mit summaryFn (weblink/FileLog) generieren keine Events, deswegen kann ich es nicht so gut testen.


    > webCmdFn wird auch zu spät bzw erst nach einem refresh der seite aufgerufen.

    Stimmt, aber das bleibt erstmal auch so.



    justme1968

    Zitataber langsam wird es mir zu bunt
    ... genau darum geht es bei den ganzen bunten lampen :)

    aber im ernst: ich probiere es mit FW_makeImage aus. wenn das geht brauche ich die @ erweiterung nicht unbedingt. der sinn ist die icons vom modul code zu steuern. ich weiss ich bin noch der einzige der es nutzt. und auch die nur fast 30 anwender sind im vergleich zur gesamten anwenderzahl nicht viel. aber beides kann sich ja ändern.

    den FW_summaryFn fix probiere ich auch.

    das mit webCmdFn ist schade... der colorpicker hat dann immer die farbe des letzten events und nicht des aktuellen.
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

    https://github.com/sponsors/justme-1968

    justme1968

    ich hab es gerade mit der neuen version probiert aber es funktioniert noch nicht ganz.

    sollte der FW_summaryFn aufruf in FW_devState nicht vor die stelle an der die default icons erzeugt werden? was angezeigt wird (nichts, default oder modul code) ist ja  genau abhängig vom der rückgabe. sonst geht ja der undef und "" fall nicht mehr.

    das hatten wir bisher definiert:
    undef -> das default icon das fhem normalerweise verwenden würde
    "" -> kein icon sondern state (oder STATE?) als text
    <html...> -> der html code als icon
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

    https://github.com/sponsors/justme-1968

    justme1968

    wenn man neben dem html code als zweite version state@color/css erlaubt könnte man die rückgabe aus dem {} auf zwei möglichkeiten beschränken von denen eine identisch zu dem ist was ein anwender im devStateIcon setzen kann. das wäre einfach und übersichtlich und deckt alles ab: einmal einfach wenn es nur im das icon für einen bestimmten state oder in einer bestimmten farbe geht mit allen defaults und konfigurationen die fhem bietet und einmal als html mit allen freiheiten.
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

    https://github.com/sponsors/justme-1968

    rudolfkoenig

    > sonst geht ja der undef und "" fall nicht mehr.

    Sorry, das habe ich verdraengt :), aber jetzt wieder eingebaut.


    > wenn man neben dem html code als zweite version state@color/css

    Habe nichts dagegen, solange Du mir sagst, wie ich die beiden ausseinanderhalten soll.

    justme1968

    ZitatHabe nichts dagegen, solange Du mir sagst, wie ich die beiden ausseinanderhalten soll.

    aus dem stehgreif würde ich sagen html fängt immer mit einem tag, d.h. mit '<' an. alles andere wäre dann der name des state mit optional angeängtem @...
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

    https://github.com/sponsors/justme-1968

    rudolfkoenig

    Hab schon gedacht, wollte aber von Dir hoeren :) Ist jetzt eingecheckt mit:
    - <.*> -> Html
    - sonst wird devStateIcon auf das erste Rueckgabewert gesetzt und ausgewertet.

    justme1968

    das klingt gut. schau ich mir so bald wie möglich an.

    danke.
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

    https://github.com/sponsors/justme-1968

    justme1968

    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

    https://github.com/sponsors/justme-1968

    justme1968

    kannst du bitte das matchen auf html code noch etwas erweitern das auch code mit newline erkannt wird?m/^<.*>$/ms

    wenn ich die neue remote (mit obiger web erweiterung) als devstateIcon oder FW_summaryFn einbinde ist sie beim seiten aufbau kurz zu sehen und verschwindet dann. hast du eine idee woran das liegt ?
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

    https://github.com/sponsors/justme-1968

    rudolfkoenig

    Bist Du sicher dass wir den ms Modifier brauchen? s verstehe ich noch, aber ms?
    Wenn es ms sein soll, dann will ich ein Beispiel, damit ich es verstehe.

    justme1968

    ich hatte es mit dem html code probiert den das neue remotecontroll modul liefert. da geht es ohne m nicht. der code wird nicht als html erkannt und fhem schmiert komplett ab. ich dachte es liegt an zu vielen \n am ende. jetzt hab ich noch mal genau nachgeschaut und es liegt an einem \n am anfang.

    wenn man das in 95_remotecontrol ändert dann geht aus mit nur s.

    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

    https://github.com/sponsors/justme-1968

    rudolfkoenig

    Hab ein s modifier hinzugefuegt.

    justme1968

    es gibt noch irgendein problem mit devStateIcon (und mehrzeiligem html) und longpoll. ich hab hier ein beispiel zum reproduzieren gepostet.

    gruss
      andre
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

    https://github.com/sponsors/justme-1968