ebusd.mqtt2.template: Fragen, Anregungen

[TomLee]

Hallo,

spricht was dagegen jsonMAP dann halt nur für das ausblenden der "unnötigen" Status01_0_name zu sehen und den Status01_0_value Readings "einheitliche" Namen zu verpassen meinetwegen weiterhin mit einem Status0x_ davor, Bsp:

Status01_FlowTemp

[Beta-User]

Mit readingsGroup geht das relativ einfach, mich würde jetzt interessieren wie man sowas mit dem devStatIcon hinbekommt. Braucht man mehr Code oder weniger? Ziel ist es, je nach Leistung oder Drehzahl das Icon und die Farbe zu ändern (auch unbekannte Zwischenstufen), den Wert in Klammer dazuschreiben und die Texte mit Überschrift zu formatieren. Und das Ganze sollte per Template verteilt werden können.

Das ist noch ungetestet, könnte aber funktionieren, was die Icons, die Zusammensetzung des Textes und die farbigen Icons angeht:

Code Auswählen Erweitern

{ my $vP = ReadingsVal($name, "WPPWMPower_percent0_value", "4448"); my $iconPower = $vP < 61 ? 'sani_pump@lightgreen' : $vP <448 ? 'sani_pump@green' : $vP <4448 ?   'sani_pump@orange' : 'file_unknown@grey'; my $vFS = ReadingsVal($name, "FanSpeed_0_value", "3001"); my $iconFSpeed =  $vFS < 11 ? ''vent_ventilation_level_0@grey'' : $vFS < 499 ? ''vent_ventilation_level_0@lightgreen'' : $vFS <1699 ? ''vent_ventilation_level_1@green'' : $vFS <3001 ? ''vent_ventilation_level_2@orange'' : 'vent_ventilation_level_3@red'; "<div style=\"text-align:right\" > Heizungspumpe: " . FW_makeImage("$vP",'file_unknown@grey') . " (. $vP Watt)<br>Ventilatordrehzahl: " . FW_makeImage("$vFS",'vent_ventilation_level_3@red') . " ( $vFS Upm)</div>"}

(Alles in eine Zeile und als devStateIcon).
Um die Textfarbe usw. hinzubekommen, das entweder bei dem ersten div mit dazuschreiben und ggf. Anführungszeichen escapen, oder evtl. gibt es auch eine Formatierungsoption bei den Device-Attributen. Geht jedenfalls ziemlich sicher auch.

Die Code-Länge mag ich nicht beurteilen, da kann man etwas tricksen, wie ihr seht... Aber so steht es halt direkt im Gerät bei Anwendung eines templates für dieses Gerät. Und man _muß_ den code auch nicht in eine myUtils auslagern. Aber es wäre recht einfach, das umzusetzen.

(Grundsätzliche Anmerkung: eigentlich finde ich es nicht optimal, durch ein template weitere/andere Geräte zu definieren, die ggf. schon vorhanden sind, deswegen mag ich das mit den devStateIcons mehr wie die RG-Lösung).

(edit, hatte den Zwischenpost nicht gesehen, war aber schon soweit):
Was die Unterscheidung zwischen Broadcast und dem "eigentlichen" Status angeht: hier wäre vielleicht eine JSONMAP hilfreich, die das zwar auseinanderhält, aber den Readingnamen aus dem Status_x verkürzt, z.B. zu "S1_Flowtemp" für das Flowtemp-Reading aus Status 1.

Bei dieser Art des erweiterten Auspackens stört mich halt schon immer, dass die Readingnamen so (meist unnötig) lang werden, das ist aber eigentlich nur was optisches... Das war aber mit der Grund, warum ich gegen "complex" als default war.

[Reinhart]

Danke für dein Beispiel, ich habe mich jetzt etwas damit beschäftigt aber ganz bekomme ich das nicht zu laufen, es werden keine Icons angezeigt. Habe aber die Syntax etwas abgeändert weils sonst nicht läuft.

Ich habe den $name durch den Devicenamen ersetzt und bei den Icons die Doppelquotas entfernt, sonst meckert der Syntaxcheck von Fhem. Was mir generell auffällt, das devStateIcon öffnet in Fhem kein Editorfenster, man muss alles in der  kleinen schmalen Zeile editieren und wird bei einer so langen Zeile schnell unübersichtlich. Auch habe ich versucht die Zeile zu verstehen, aber da muss man schon tief in der Materie sein.

Code Auswählen Erweitern

{ my $vP = ReadingsVal("MQTT2_ebusd_bai", "WPPWMPower_percent0_value", "4448"); my $iconPower = $vP < 61 ? 'sani_pump@lightgreen' : $vP <448 ? 'sani_pump@green' : $vP <4448 ?   'sani_pump@orange' : 'file_unknown@grey'; my $vFS = ReadingsVal("MQTT2_ebusd_bai", "FanSpeed_0_value", "3001"); my $iconFSpeed =  $vFS < 11 ? 'vent_ventilation_level_0@grey' : $vFS < 499 ? 'vent_ventilation_level_0@lightgreen' : $vFS <1699 ? 'vent_ventilation_level_1@green' : $vFS <3001 ? 'vent_ventilation_level_2@orange' : 'vent_ventilation_level_3@red'; "<div style=\"text-align:right\" > Heizungspumpe: " . FW_makeImage("$vP",'file_unknown@grey') . " (. $vP Watt)<br>Ventilatordrehzahl: " . FW_makeImage("$vFS",'vent_ventilation_level_3@red') . " ( $vFS Upm)</div>"}

Man muss aber eins bedenken, mit devStateIcon kann man nur in einen Device bearbeiten, will man aus "MQTT2_ebusd_bai" aber weitere Readings zur Anzeige bringen ist das so nicht komfortabel möglich, bzw. erscheinen dann halt alle untereinander. Bei einer readingsGroup wird einfach ein neuer Name vergeben und man kann beliebig viele unterschiedlich formatierte Readings mit Balken, Icons oder Text anzeigen. Aber Optik ist immer Geschmacksache und liegt im Auge des Betrachters, der eine mag's so, der andere wieder ganz anders, sonst würden wir ja alle dieselbe Frau haben wollen.

Aber interessant ist diese Methode auf jeden Fall, nur zweifle ich daran das hier ein Neueinsteiger was ändern oder dazu bauen kann. Solange das alles aus dem Template kommt ist es ok, dass muss ja auch keiner zwingend verstehen.

Zum Thema Template und "complex", ich finde das sehr gut, weil wirklich schön differenziert wird auch wenn die Namen jetzt länger werden ist das kein wirkliches Malheur. Ja, mit dem Vorschlag von TomLee "Status01_FlowTemp" kann man auch gut leben weil man aus dem Namen weiß wo das Reading herkommt. Dann müsste man allerdings auch diesen Translate im Template berücksichtigen und den Rest unangetastet lassen, denn so gut wie es jetzt funktioniert geht es kaum besser.

Ich habe jetzt im Testbetrieb am Hauptsystem Mosquitto und MQTT2_Client und am Testsystem MQTT2_Server laufen beide auf einem separaten eBusadapter.

LG

[Beta-User]

Danke für's testen!

$name funktioniert, das nutze ich selbst auch an einigen Stellen und in den mqtt2.templates ist es auch häufiger drin; das mit den Doppelquotas ist seltsam, da hatte ich irgendeinen Bock geschossen, sorry. (Der code war ausdrücklich untested, vermutlich hätte es gereicht, die dusseligen Doppelquotas zu entfernen...).

Dann müsste man allerdings auch diesen Translate im Template berücksichtigen und den Rest unangetastet lassen, denn so gut wie es jetzt funktioniert geht es kaum besser.

Wie bereits geschrieben, wäre ich sehr froh, ein oder zwei Beispiele für die JSONMAP-Funktionalität in den templates zu haben .

Dass man dann sinnvollerweise einen Standard incl. JSONMAP ausliefert, der dann "nur" erst mal das "Standarddevice" mit einer "Status01_FlowTemp"-Benennung (o.ä.) berücksichtigt, ist soweit klar. Ziel dieser Übung wäre "nur", bestimmte Geräte, die immer/häufig anzutreffen sind, direkt funktional anzuzeigen und ggf. grundlegend bedienbar zu haben (wie das 430-er mit der Vorlauftemperatur/Heizkurve).
Dazu sollte dann aber nur der Standard abgedeckt werden (ich würde sogar Farbe vermeiden), und der user muß dann auch nicht mit dem Code an sich beschäftigen oder in dem kleinen Fensterlein rumwerkeln (das kann man auch irgendwo auf textFieldLong umstellen; ich kopiere das im Moment immer in einen Editor und dann wieder zurück, sobald das steht, muss man da ja auch nicht mehr ran...) Das sollten die "Experten" vorher soweit "ausgekocht" haben, dass der Normaluser eine vernünftige Basis hat (daher legen wir uns ja grade unter Autos, die wir erst kennenlernen müssen).

Wer dann mehr will, kann (und soll!) dann weitere Dinge tun können (gerne mit ReadingsGroup!) oder das eigentliche Device irgendwo verstecken, devStateIcon löschen und stateFormat verwenden...

Wegen dieser "unkomfortablen" Zugriffsmöglichkeiten auf devStateIcon auch nochmal der Hinweis, dass man den eigentlichen Code auch auslagern kann (was sinnvoll wäre, wenn man eh' eine myUtils mit ausliefern sollte). Wer sich dann intensiver damit beschäftigen will, kann den Code dann in myUtils anpassen.

Zusammengefaßt nochmal:
Es ist keine "alles-oder-nichts"-Diskussion, die wir hier haben sollten, m.E. wäre eine Mischform sogar wünschenswert; also der Spur nach so:
- Basisfunktionalität einschl. des Setzens von Zielwerten wie Heizkurve usw, das ganze hübsch verpackt: aus dem jeweiligen template direkt am Gerät, ohne viel Farbe, Dynamik ggf. nur aus dem Icon selbst (Bsp: 3-er Lüfter)
- alles andere: ReadingsGroup, myUtils-Code, Farbverläufe mit pah-Color... (FHEM eben!) ganz nach Belieben, gerne auch mit weiteren Templates zum Ausprobieren

Zum Thema Template und "complex", ich finde das sehr gut, [...]

Auch hier: Alles-oder-nichts liegt mir fern; das hat seine volle Berechtigung, wenn man auf komplexe Geräte schaut (deswegen bettle ich ja wegen der JSONMAP ...).
Es ist nur in dem Moment "von hinten durch die Brust ins Auge", wenn man JSONMAP braucht, um wieder Reading-Namen zu haben, die z.B. sprachsteuerungstauglich sind, "nur", weil man den JSON vorher "complex" ausgepackt hat . Ich persönlich finde es jetzt super, dass wir beide Welten zufrieden stellen können, auch wenn  es evtl. (noch) Nebenwirkungen geben könnte, die mir bislang entgangen sind, aber bis daher ging das Baugefühl dazu soweit auf.

[TomLee]

[OT]

Die Zuordnung der einzelnen Werte im Status steht im hcmode.inc File.

Code Auswählen Erweitern

r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,


Der Originaltext aus der Datenbank heißt beim Vorlauf "FlowTemp" und befindet sich im Register d.40 und findet man im entsprechenden CSV File.

Das hcmode.inc File hab ich mir jetzt mal angeschaut, dachte wenn du FlowTemp und d.40 erwähnst kann man hier auch Rückschlüsse ziehen woher die anderen Werte kommen. Ist aber nicht so. Bei mir kommt unter Status01_3_value mein 1_Fragez  immer 0.0 rein.
Welcher Wert im CSV File ist denn WW Temperatur, Speichertemperatur ist bei mir die Warmwasserspeichertemperatur wo wird den noch eine Temperatur bezüglich WW gemessen ?
[/OT]

[Reinhart]

@Beta-User

Ja, machen wir so wie du in deiner Zusammenfassung schreibst.

Übrigens mit dem $name hast du recht, es waren nur die Doppelquotas, gerade nochmals getestet. Aber das wesentliche sind noch die fehlenden Icons, die sollten wir noch hinbekommen. Du kannst auch noch auf den Testraspi drauf wenn du da was testen willst.

Das mit der Auslagerung in die myUtils sollten wir wirklich in Betracht ziehen, denn dann bleibt alles übersichtlicher.
Weil du die Sprachausgabe erwähnt hast, ich habe myTTS laufen und Alexa. Bei Alexa ist es eh egal, den da hat man eh den "alexaname" und bei myTTS benutze ich ebenfalls die myUtils weil ich da noch die Lautstärke je nach Tageszeit einstelle. Aber du hast schon recht, es ist mit so "wilden" Namen schon etwas komplizierter.
Ich steuere sonst die ganze Heizung auch via Alexa und eBus und bekomme auch via Fhem Echomodul alle wichtigen Messwerte direkt vom eBus (aufbereitet) vorgelesen. Das meiste läuft aber hier über einfache Dummies die über notify dann Code in der myUtils ausführen oder dann in der Alexa-App als Routine weiter verarbeitet werden.

Was ich dich noch fragen wollte, kann man eigentlich aus dem Template die Bash aufrufen (kopieren oder mit wget Code aus dem Github holen)?

@TomLee
klären wir das bitte in einem Inbetriebnahmethread, wird sonst zuviel OT hier und ich weiß nicht ob John hier mitliest, der weiß das alles aus dem FF.

[Beta-User]

Moin zusammen .

Sorry für den doppelt fehlerhaften Code gestern, da war außer den doppel-Anführungszeichen auch noch der Fehler drin, dass bei der eigentlichen Icon-Generierung dann statt der Variable für das Icon die für den Wert herangezogen war - konnte so nicht gehen ...

Jetzt also:
1. "Einfaches" nichtfarbiges devStateIcon

Code Auswählen Erweitern

{ my $vP = ReadingsVal($name, "WPPWMPower_percent0_value", "4448"); my $vFS = ReadingsVal($name, "FanSpeed_0_value", "3001"); my $iconFSpeed =  $vFS < 11 ? 'vent_ventilation_level_0' : $vFS < 499 ? 'vent_ventilation_level_0' : $vFS <1699 ? 'vent_ventilation_level_1' : $vFS <3001 ? 'vent_ventilation_level_2' : 'vent_ventilation_level_3'; "<div style=\"text-align:right\" > Heizungspumpe: " . FW_makeImage("sani_pump",'file_unknown') . " ($vP Watt)<br>Ventilatordrehzahl: " . FW_makeImage("$iconFSpeed",'vent_ventilation_level_3') . " ($vFS Upm)</div>"}
Zur Erläuterung: Der eigentliche Rückgabewert des Perl-Codes ist html-Code. Dieser wird in der letzten "Zeile" gebildet, also beginnend mit "<div style. Dabei werden verschiedene "Text"-Elemente miteinander verbunden (concatenation). Zunächst etwas Formatierung (dafür erforderliche Anführungszeichen sind escaped), dann etwas echter Text, dann Perl-Code, der ein Icon zurückgibt (hier im ersten für die Pumpe fest angegeben), dann wieder Text, wobei die Werte-Variable mit drin ist. Dann wieder ein Icon, dieses Mal aus der vorher gefundenen Variable, Rest wie vor, mit dabei dann das Ende der html-Formatierung...
Was das "Finden" der Variable angeht, ist das eine sehr kurz geschriebene if ... else mit weiteren nachfolgenden if ... else- Abfragen. Sobald der erste "Hit" da ist, gibt es einen Rückgabewert. Da aufsteigend sortiert, kann man einfach mit dem kleinsten Wert beginnen und dann immer größer werden .

2. "Einfaches" dynamisch-farbiges devStateIcon

Code Auswählen Erweitern

{ my $vP = ReadingsVal($name, "WPPWMPower_percent0_value", "4448"); my $iconPower = $vP < 61 ? 'sani_pump@lightgreen' : $vP <448 ? 'sani_pump@green' : $vP <4448 ?   'sani_pump@orange' : 'file_unknown@grey'; my $vFS = ReadingsVal($name, "FanSpeed_0_value", "3001"); my $iconFSpeed =  $vFS < 11 ? 'vent_ventilation_level_0@grey' : $vFS < 499 ? 'vent_ventilation_level_0@lightgreen' : $vFS <1699 ? 'vent_ventilation_level_1@green' : $vFS <3001 ? 'vent_ventilation_level_2@orange' : 'vent_ventilation_level_3@red'; "<div style=\"text-align:right\" > Heizungspumpe: " . FW_makeImage("$iconPower",'file_unknown@grey') . " ($vP Watt)<br>Ventilatordrehzahl: " . FW_makeImage("$iconFSpeed",'vent_ventilation_level_3@red') . " ($vFS Upm)</div>"}
Funktioniert im Prinzip wie das andere, nur dass hier auch das Icon für die Pumpe farbig gemacht wird und der Ventilator nicht nur gestuft ist, sondern auch gefärbt.

3. voll-dynamisch-farbiges devStateIcon
Dann wollte ich das Color-Dingens mal antesten, klappt soweit auch. Aber es ist jetzt trotzdem nur erst mal nur ein ziemlich willkürlicher Versuch, weil mir zum einen nicht klar ist, welche Farbausgaben denn eigentlich für die Hardware sinnvoll ist und zum anderen, wie die genaue Parametrierung der pahColor-Funktion funktioniert. Da könnt ihr ja noch dran drehen, Details finden sich u.a. hier: https://wiki.fhem.de/wiki/Color#Farbskala_mit_Color::pahColor.

Code Auswählen Erweitern

{ my $vP = ReadingsVal($name, "WPPWMPower_percent0_value", "4448"); my $colPower = substr(Color::pahColor(0,50,4449,$vP,0),0,6); my $iconPower = 'sani_pump@'.$colPower; my $vFS = ReadingsVal($name, "FanSpeed_0_value", "3001"); my $colFSpeed = substr(Color::pahColor(0,50,4000,$vFS,0),0,6); my $iconFSpeed =  'vent_ventilation_level_'; $iconFSpeed .=  $vFS < 499 ? '0@' : $vFS <1699 ? '1@' : $vFS <3001 ? '2@' : '3@'; $iconFSpeed .= $colFSpeed; "<div style=\"text-align:right\" > Heizungspumpe: " . FW_makeImage("$iconPower",'file_unknown@grey') . " ($vP Watt)<br>Ventilatordrehzahl: " . FW_makeImage("$iconFSpeed",'vent_ventilation_level_3@red') . " ($vFS Upm)</div>"}

4. myUtils
Bei Bedarf kann ich auch die myUtils-Geschichte noch angehen, aber da habt ihr eigentlich auch genug eigene Erfahrung, oder? (Meine eigene Installation ist übrigens bei weitem nicht so ausgereift wie deine, @Reinhart ). Dazu vielleicht noch eine Anregung: Auf dem Test-Pi gibt es _eine_ 99_myUtils.pm. Da scheint im Moment alles mögliche drin zu sein, ich habe nicht im Detail nachgesehen, ob das nur ebus-spezifische Dinge waren. Es wird m.E. übersichtlicher, wenn man für ebus-Zwecke eine weitere pm erstellt, also z.B. 99_myUtils_ebus.pm (bitte den initialize-Namen auch entsprechend anpassen); das macht es auch einfacher, das später zentral bereitzustellen.

5. Funktionsaufruf von myUtils via devStateIcon
Ist in der Regel einfach, gebraucht wird halt der Name, also mind. den übergeben (mit $name, das kann dann auch in den myUtils wieder von @ nach $name übergeben werden).
Wenn es für den user sehr einfach sein soll, würde ich an eine Funktion devStateIcon_ebus() denken, und dann ($name, $type [,color, ?...]) als Parameter übergeben. $type könnte dann "bai", "bai_n" (für weitere Status_n-Geräte), "remote" (ggf. mit unterschiedlichen Varianten) sein, "color" gibt an, ob farbig...

(A propos Farbe: das Grund-Icon finde ich mit der farbigen Flamme überdenkenswert, ich versuche in meiner Installation nur noch Icons zu verwenden, die die Hintergrundfarbe annehmen, wenn ich sie nicht absichtlich anders einfärbe; denke, das ist "ruhiger" - aber Geschmackssache, klar...)

6. Zur Darstellung des ebus-Splitters noch ein Vorschlag (RAW-Darstellung):

Code Auswählen Erweitern

attr MQTT2_ebusd devStateIcon 2.true:lan_rs485 2.false:lan_rs485@red 1.true:it_net 1.false:it_net@red
attr MQTT2_ebusd stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr MQTT2_ebusd userReadings formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;; return sprintf "0 000 00:%02d", $m if $m < 60;; my $h = $m / 60;; $m %= 60;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;; my $d = $h / 24;; $h %= 24;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;; my $y = $d / 365;; $d %= 365;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}
Die Symbole sind etwas willkürlich gewählt, geht vorrangig um die Darstellung dieser Variante...




Kurz zu der Frage nach Code-Aufrufen aus den templates:
Vor der technischen Seite her würde ich annehmen, dass das ginge.
ABER:
Ich halte das nicht für wünschenswert!
Es ist nicht ausgeschlossen, dass ich da meine Meinung ändere, aber ich will kurz erläutern, warum; ihr könnt mir gerne Gegenargumente nennen (und bitte: es ist eine Meinungsäußerung )...
M.E. sollten templates im Kern _das Gerät konfigurieren, auf das sie angewendet werden_. Das ist das, was der Nutzer erwarten kann und darf. Sie sind aber _kein Installer oder so was ähnliches, ihre Wirkung sollte jeweils auf das Gerät beschränkt bleiben.
Das war der Hintergrund, warum ich schon die Erstellung von ReadingsGroups mit auf MQTT2_DEVICE-Geräten angewendeten templates nicht so toll finde, aber ok, das ist nur eine Darstellungssache, damit kann ich mich gerade so noch abfinden.
Eigentlich hatte ich z.B. aber schon Skrupel, die Hardware, die repräsentiert wird, durch Konfigurationsbefehle zu "ändern" (tasmota-Kleinschreibung), weil das auch unangenehme Nebenwirkungen haben kann, wenn jemand noch "was anderes" nutzt (openHAB etc.). Aber ok: Da ist vorneweg ein Hinweis drin, wer den nicht liest, muß halt reparieren...

Für das General-bridgeRegexp-MQTT2_DEVICE für den CLIENT als IO hatte ich den template-Code im Prinzip schon fertig, um aus dem aktuellen Device eine Kopie zu ziehen, die CID zu ändern und das dann mit der passenden BridgeRegexp zu versehen. Ich hab's gelassen, u.A. weil ich dann ein evtl. vorhandenes Gerät mit demselben Namen hätte löschen müssen. Echtes Risiko: gering, aber das Prinzip ist einfach nicht gut, der user weiß hinterher nicht richtig, was passiert ist (er kommt auf die Seite mit dem Ausgangsgerät zurück...)

Jetzt aber Daten von "irgendwoher" zu holen (das ist nichts persönliches, es geht um's Prinzip, s.o.), finde ich noch wesentlich weitgehender, v.a., wenn sie ausführbaren Code enthalten.

Lösungsvorschlag dazu:
Wenn ihr sowieso den Code in github pflegt, könnte man eine controls.ebusd.txt-Datei erstellen (siehe z.B. für Signalduino) und dem User z.B. auf der Infoseite zum ebusd-Basistemplate (splitter) mitteilen, dass er diese Datei in seinen update-Pfad einfügt. Dann kann der user das tun oder sich eben darum kümmern, dass er die notwendigen Dinge selbst einpflegt.
Wäre m.E. sauberer.

Hoffe, das hilft euch weiter?

Edit: Bilder...

[Reinhart]

@Beta-User

ich habe gesehen du hast einiges getestet und es funktioniert auch alles soweit. Die jsonMaps wie TomLee sie haben möchte habe ich mir auch angeschaut und funktioniert ebenfalls. Complex und auch den Eintrag in der readingList habe ich gelassen, aber ein zusätzliches "attr jsonMap" bennent dann um.

Code Auswählen Erweitern


Status01_0_value:_Vorlauf
Status01_1_value:_Ruecklauf
Status01_2_value:_Aussentemp
Status01_3_value:_Warmwasser
Status01_4_value:_WWSpeicher
zusätzliches jsonMap

Ich baue die nächsten Tage die Templates alle um, bzw. füge die Beispiele der devStateIcons dazu. Muss aber alles testen und das dauert eine Weile.
Ach ja, der neue Style f18 am Testssystem ist interessant, aber an die orange Schrift muss man sich gewöhnen.

LG

[Beta-User]

Ach ja, der neue Style f18 am Testssystem ist interessant, aber an die orange Schrift muss man sich gewöhnen.

Sorry wg. der Farbe... Das sind nur 3-4 Klicks, dann ist das auch wieder geändert . Das ist einfach f18 mit dem "Preset colors: -> dark" (der defailt gefällt mir nicht so).

Für die template-Geschichte ist es vielleicht ganz gut, hin und wieder zwischen den verschiedenen f18-color-Presets zu wechseln, dann entspricht es am ehesten dem, was ein "Neueinsteiger" dann von FHEM sieht.

Was diese vielen Aspekte aus meinem letzten Post hier angeht:
Sorry, dass das so ein Wust an Teilaspekten ist, ich hoffe, dass es ok ist, wenn ich da alles erst mal nur in der Kürze angerissen habe und keine fertigen Lösungen?
Laß dir Zeit bzw. hol dir vielleicht jetzt auch weitere ebus-Nutzer dazu, m.E. sind wir jetzt so weit, dass der "Werkzeugkasten" einigermaßen steht. Ein paar Bilder im Hauptthread wirken da vielleicht Wunder...

Ein paar Dinge noch, die mir grade noch durch den Kopf gehen:
- Für das Einrichten wäre es evtl. ganz gut, wir könnten noch einen ebus-Befehl (für die Konsole) einfügen, der dann erst mal dazu führt, dass sämtliche vorhandenen Gerätschaften via MQTT präsentiert werden, nachdem der Splitter konfiguriert wurde.
- Dann sollten  wir ein template haben für die "430"-er, das dann eine möglichst optimierte setList enthält (ist mind. in Teilen vorhanden)
- dto. für den "bai"
- dann kann man das at entsprechend auf die "get"-Befehle umbauen.


Womit ich nicht zufrieden war, waren die verfügbaren Icons; vielleicht wäre es clever, da mal im Icon-thread nachzufragen, dass jemand noch ein paar Icons bauen mag (die "durchsichtigen", damit es zu f18 paßt). Toll wären neben diversen Pumpenzuständen (off, mehr Level) noch die Signalzustände und ein generelles "ebus"-Symbol (vielleicht ähnlich zu rs485-lan)?


Was die templates angeht, wäre es gut, wir könnten erst das splitter-template komplettieren (ggf. die Symbole später tauschen), dabei erst mal alles "farblos"; das müßte eigentlich sogar ohne Perl-Code gehen.
Dann das bai (mit JSONMAP, aber immer noch farblos); braucht vermutlich Perl wg. der Level->Symbol-Umrechnung.

Dann ein "430"-er mit Steuerungsmöglichkeit; wäre vermutlich eine gute Idee, da statt  Text Symbole für die Temperatur- und Kennlinien-Benennung zu verwenden (müßte auch mit der newline in stateFormat gehen; hier wäre noch interessant, ob man die set-Einträge in die stateFormat-Angabe integrieren kann).

Soviel erst mal wieder, schönen Sonntag noch.

[Reinhart]

im Augenblick habe ich bei den Tests massive Probleme mit Fhem. Seit etwa 3 Tagen wird es immer langsamer und das Öffnen eines Readings oder Menüpunkt dauert bis zu 2 Minuten. Ich hatte zuerst die Sqlite3 Datenbank im Verdacht und habe sie gelöscht, dann geht es wieder bis zu dem Augenblick wo ich beginne den MQTT2_Client zu definieren und Daten zu sammeln. Innerhalb 30 Minuten werden durch autocreate etwa 500 Readings angelegt. Am schlimmsten ist der Rasenmäher der gleich über 200 anlegt, schon alleine die vielen Zeitprogramme.

Das Testsystem funktioniert, aber wenn ich meine produktive fhem.cfg einspiele ist auch dort sofort der Fehler da. Meine fhem.cfg hat an die 6400 Zeilen, das war aber auch vorher so und war sehr schnell. Ich werde daher erst wieder richtig testen können, wenn ich den Fehler im Griff habe. ich beginne jetzt auf einem anderen System mit älteren Sicherungen zu testen.

Was ich bis jetzt mit den Mappings testen konnte funktioniert das bei mir nur zufällig, siehe Bild, da wird nur jeder 2. mit jsonMap angelegt (die roten kommen trotz jsonMap noch durch). Das ist mir aber nicht sonderlich wichtig, weil es eigentlich von hinten durchs Knie geschossen ist, zuerst mit Complex schön brav erfassen und dann mit jsonMap auf ein neues Reading umleiten ist nicht gerade sauber gelöst.

LG

[Reinhart]

so, ich habe den Fehler jetzt gefunden, eine Fhem2Fhem Verbindung hat plötzlich durchgedreht und etwa 15-20 x pro Sekunde gesendet. Habe es mit der Netzwerküberwachung gesehen das hier am Raspi was nicht stimmt. Komische Sachen, die Verbindung ist seit Jahren stabil gelaufen.
Ich mach nun mit den Templates weiter, das geht nun trotz der Datenmassen wieder sehr schnell.

LG

[Beta-User]

Klingt schräg, das mit dem FHEM2FHEM, schön, dass du den Fehler gefunden hast.

Was das JSON-Mapping angeht, sollte es schon eindeutige Namen ergeben, nur eben kürzer. Da sah' der Screenshot seltsam aus, weil einiges in dasselbe Reading gemappt war. Da du das selbst nicht für so wichtig ansiehst: Es wäre für mich auch völlig ok, wenn diesen Teil TomLee beisteuern würde; es sollte halt sowas wie ein konsolidiertes Ergebnis geben. (Das ist nicht als Kritik gemeint, es ist ok, wenn du lieber mit den "vollen" Readingnamen umgehen willst, wie gesagt: mir geht es um die Darstellung eines Beispiels für das Funktionsprinzip.)

Ansonsten: Keine Eile!

[Reinhart]

ich habe nun einiges getestet und auch einige devStateIcons gebaut. Das einzige Problem das ich noch nicht lösen konnte, ist das Anlegen neuer Devices (Dummys nur wegen Gruppierung in eigenem Device) im Room "MQTT2_DEVICE", also im eigenen Room wo alle Devices mit den Readings liegen. Das hat den Sinn, dem Anwender es zu erlauben hier mehrere Templates auszuwählen, sodaß es noch eine schöne Übersicht ergibt. Das Problem ist der Name selbst, der ja innerhalb vom Template eine Variable ist. Momentan lege ich das Template "E_06" in einem anderen Room an und muss es dann händisch umlegen. Eventuell hat da Beta-User noch eine Idee wie man das lösen kann. Meine Versuche mit Quotas und Klammern sind fehlgeschlagen, die werden einfach so angelegt und dargestellt. Selbst String Additionen gehen in die Hose.

Das angehängte Bild ist ein Beispiel der unterschiedlichen Möglichkeiten. Auch die readingsGroups habe ich noch um ein paar erweitert. Bei den test habe ich nun keine Fehler mehr gefunden, löschen von vorhandenen Readings habe ich absichtlich nicht eingebaut und es kommt eine Fehlermeldung das es schon vorhanden ist. Dann schaut jeder vorher nach, nicht das wertvolle Arbeit einfach überschrieben wird.

Ja, mit den Icons wäre es schön wenn wir mehr hätten, aber man kommt auch so durch. Ich persönlich finde aber ein schönes buntes und dynamisches Icon (evtl. mit farbiger Schrift) gibt dem Aussehen ein rundes Gesicht und peppt das schön auf. Daher macht auch die Aufteilung in mehrere Dummy Devices eine bessere Übersicht, aber Design ist immer Ansichtssache.

LG

[rudolfkoenig]

Das Problem ist der Name selbst, der ja innerhalb vom Template eine Variable ist.

Kannst du das bitte so erklaeren, dass ich das nachstellen kann?

Ja, mit den Icons wäre es schön wenn wir mehr hätten, aber man kommt auch so durch.

*staun*:

Code Auswählen Erweitern

% find www/images -type f | wc -l
    1297


[Beta-User]

Moin zusammen,

das mit dem Namen deute ich so: Du willst ein define im template ausführen, und zwar mit dem TPY MQTT2_DEVICE. Das klappt aber nicht, weil der hintere Teil "DEVICE" ersetzt wird durch den Namen, aber ein solches Modul gibt es natürlich nicht...

Ausweg: copy verwenden? (Ich mag das aber aus prizipiellen Erwägungen nicht so, lieber ist mir, der Anwender erstellt die copy und wendet dann darauf ein template an; die prinzipiellen Einwände, die ich gegen das Erstellen von "ganz anderen" Devices habe, hatte ich ja schon erläutert)

Das mit den images: Es geht um spezielle Dinge, wie z.B. die Pumpendrehzahl durch "mehr Pfeile" anzuzeigen, oder ein spezielles "ebus"-Symbol.

Ich schau mir das am WE voraussichtlich noch intensiver an.

Ansonsten habe ich im Wiki in den Praxisbeispielen jetzt nochmal deutlich was hin- und hergeschoben und das im wesenlichen auf MQTT2_SERVER zugeschnitten.
Wäre nett, wenn ihr einen kurzen Blick drauf werfen könntet und ggf. noch das "Ende" dahingehend ergänzen, dass man z.B. einen Konsolenbefehl hätte, mit dem man auch den "430"-er sichtbar machen könnte - irgendwoher muß der geneigte Anwender ja wissen, was da ist... (Oder weiß er das nach der Einrichtung des Dämons sowieso? Dann wäre _kurz_ der Transfer vom Dämon zu MQTT2_DEVICE darzustellen.