[HMdeviceTools.js (hm.js)] WebUI zur Register-Konfiguration/Templatehandling

[frank]

Um das Namensproblem zu lösen, könnte man doch noch einen "Alias"-Namen einführen. Dann kann der echte Name ruhig kryptisch sein. Im UI wird aber der "Alias" angezeigt. Dann kann es auch den gleichen Alias für die gleiche Funktion bei Schaltern/Dimmern/... geben.

Beim Setzen eines Templates würde ich mir wünschen, die Register und die Werte optional einzublenden. Ich weiss gerne, was passiert Ich hab mal einen Screenshort von meiner, alten Version angehängt.

hallo papa,

ein alias löst leider nicht das problem des "erstkontaktes" der user mit den templates.

die user, die das interface nutzen (zur zeit 12 nerds?), sind dann ja schon viele schritte weiter. müssten dann aber auch erst das template analysieren (infotext, parameter, register), um einen eigenen alias kreieren zu können.
um einen alias zu schaffen, müsste dieser in den infotext eingearbeitet werden. dazu müssten die default-templates grundsätzlich editierbar sein. da müsste martin wahrscheinlich noch nacharbeiten, denn löschen der default-templates funktioniert noch nicht.

ich behalte den alias aber mal im "auge".
details zu den templates wirst du ganz sicher bekommen, keine sorge. 

hast du eventuell eine idee zu diesem problem? https://forum.fhem.de/index.php/topic,107125.0.html

[papa]

ein alias löst leider nicht das problem des "erstkontaktes" der user mit den templates.

Ich glaube jetzt verwechselst Du das "alias" Commando mit einem weiteren Feld in der Templatedefinition, den ich "Alias" genannt habe. Das ist genau so ein Feld wie z.B. der Kommentar. Der Alias würde also beim Anlegen des Templates definiert. Man könnte das auch "User visible Name" nennen. Oder vielleicht noch besser "Label".

hast du eventuell eine idee zu diesem problem? https://forum.fhem.de/index.php/topic,107125.0.html

Da kann ich leider auch nicht helfen. Wahrscheinlich müsste der BlockingCall raus.

[frank]

Ich glaube jetzt verwechselst Du das "alias" Commando mit einem weiteren Feld in der Templatedefinition, den ich "Alias" genannt habe. Das ist genau so ein Feld wie z.B. der Kommentar. Der Alias würde also beim Anlegen des Templates definiert. Man könnte das auch "User visible Name" nennen. Oder vielleicht noch besser "Label".

ich hatte es schon verstanden, aber bereits intuitiv ausgeschlossen, dass martin so einen umbau betreiben würde.

ein "label" in der def wäre natürlich optimal. (abhängig vom inhalt natürlich mehr oder weniger optimal  )

vielleicht sogar mehrsprachig, je nach "attr global language", was ich aber gar nicht gefunden habe. ich dachte eigentlich, irgendwo hätte ich mal was zu language gelesen.

[frank]

moin,

anbei ein update mit generischer template erstellung für "short OR long" und automatischer erkennung, ob der aktuelle registersatz das feature unterstützt. das feature ist nur zugänglich bei entsprechender erkennung.

wie ich feststellen musste gibt es neben switch, dimmer und blind auch keymatic, outputunit, ..... und die virtuellen dimmer channel.
da ich nur switche und "normale" dimmer habe, würden mich tests mit anderen aktoren interessieren.
nach positiven rückmeldungen, kommt dieses update in den ersten beitrag.


über den fhem befehl "version" kann man übrigens die revision erkennen.
die erste hat rev 2000, dieses update ist rev 2001. wenn ich es nicht vergesse, erhöhe ich jede neue version.


@martin
reicht folgender algorithmus zur eindeutigen erkennung passender registersätze, oder muss ich noch prüfen, ob wirklich alle register-kern-namen symetrisch in beiden gruppen sh/lg vorhanden sind?

1. alle register zählen (regCtr)
2. sh-register zählen (shCtr)
3. lg-register zählen (lgCtr)
4. (shCtr + lgCtr) == regCtr && shCtr == lgCtr


gruss frank


edit:
hm.js rev 2001 aus diesem beitrag entfernt.
updates jetzt immer im ersten post.

[martinp876]

Virtuelle dimkanäle sind identisch dem normales. Es ist ein eigener kanal, für dich also transparent.

Was du mit den register hashes willst ist mir nicht klar.
Ich habe Methoden die eine Prüfung vornehmen.  Was und warum prüfst du separat?
Long und short sind identisch. Die definition ist eine kopie. Somit reicht es, einen zu prüfen.

Festgelegt werden muss, ob du gegen definierte oder vorhandene register prüfst. Da ich keine fw Versionen in den devices unterschiede kann es zu abweichungen kommen.
Ein vollstàndiges lesen der register ist vor der nutzung der templates sinvoll, da das schreiben der register  häufig bit manipulationen verlangt und somit nur möglich ist, wenn die ist-Werte vorhanden sind.

Gegen definitionen zu prüfen hat auch etwas. Macht die zuweisung unabhängig vom stand des gelesenen.

In jedem fall rate ich, die reg hashes nicht selbst zu interpretieren. Sollte ich intern etwas ändern sieht es schlecht aus. Gilt insbesondere für die nutzung mit hmccu

[frank]

moin,

im ersten post gibt es ein neues update.

Code Auswählen Erweitern

- rev 2002 31.01.2020
     new: - "globale" template zuweisung mit den neuen funktionen "Use, Use All, Use None"
             - auswahlliste diverser template details in der template ansicht.


[papa]

Sehr cool - sieht super aus. Auch wenn ich noch nicht viel Zeit zum Probieren hatte.
Allerdings gibt es mit dem f18 Style ein paar ANzeigeprobleme. Siehe Screenshot

[frank]

den sinn erkennt man wohl nur im darkstyle fhemweb. 
entferne ich wieder.

in fhemweb wechselt ja die backgroundcolor der tabellenzeilen, vermutlich durch class=odd.
im popup hatte es bei mir jedoch keinen effekt, weswegen ich die farbe zum testen zunächst hart codiert hatte.

hast du eine idee, wie ich den style ins popup bekomme, um tabellenzeilen zu "markieren"?

ebenfalls wäre eine popup titelzeile interessant, um die überschrift style-unabhängig hervorheben zu können.

gibt es eventuell ein style-guide für fhem?

[frank]

neues update im 1. beitrag.

• rev 2003 04.02.2020


• fix: style problem mit f18
• fix: manchmal doppelte einträge in tabelle used devices (laufzeitproblem)

[DC]

hallo papa,

ein alias löst leider nicht das problem des "erstkontaktes" der user mit den templates.

die user, die das interface nutzen (zur zeit 12 nerds?), sind dann ja schon viele schritte weiter. müssten dann aber auch erst das template analysieren (infotext, parameter, register), um einen eigenen alias kreieren zu können.
um einen alias zu schaffen, müsste dieser in den infotext eingearbeitet werden. dazu müssten die default-templates grundsätzlich editierbar sein. da müsste martin wahrscheinlich noch nacharbeiten, denn löschen der default-templates funktioniert noch nicht.

ich behalte den alias aber mal im "auge".
details zu den templates wirst du ganz sicher bekommen, keine sorge. 

hast du eventuell eine idee zu diesem problem? https://forum.fhem.de/index.php/topic,107125.0.html

Mal ein kleines Danke für Eure Arbeit 

Zum Erstkontakt:
Das UI ist eigentlich so OK. Man braucht erst mal ein Verständnis für die Register (gibt es da eine gute Einführung/Übersicht ?? Das ist zumindest aktuell mein Problem)...
Noch als Anregung: wenn man Register sinnvoll gruppieren könnte im UI (short, long, condition tables etc) macht es das Ganze etwas übersichtlicher.

[Pfriemler]

Hilfe zur Registern, ihrer prinzipiellen Funktion, Arten, Funktionen findet man im im berühmten Homematic-Anhang des fhem-Einsteiger-Docs. Besonders was die state machine ist, sollte man wenigstens grob erfasst haben, damit man versteht, wo welche Stellschräubchen ansetzen.
Im Wiki gibt es einen Artikel, der darauf aufbauend das Thema Registerprogrammierung  kurz anreißt und mit Beispielen unterlegt.
Wenn man das einmal prinzipiell verstanden hat, sind die Registernamen und ihre Funktion eigentlich selbsterklärend - wirst Du sehen ... Der erste Anfang ist etwas schwer.
Gruppiert sind die Register schon des Namens wegen eigentlich von selbst (short, long, triggerunabhängig). Man könnte in Zeiten, Werten, Bedingungen trennen. Ich fürchte aber, das wird nicht übersichtlicher.
Und ist sehr zusätzliche Arbeit, weil man die Register schon vorinterpretieren muss. Bei hunderten von möglichen Registern wirklich kein leichtes Unterfangen.

[DC]

Danke für den Hinweis

Nach 6 Jahren FHEM - ohne dass die Notwendigkeit bestand, dort etwas nachzuschauen - wieder etwas gelernt...
Passt

[Otto123]

Danke für die Vorarbeit. Hab's installiert und es läuft.
Mal sehen was die Praxis bringt.

[Otto123]

Nach den ersten Versuchen, mein wohlgemeintes Feedback:
Ich will einfach ein neues Template machen, anhand eines Dimmers der schon konfiguriert ist.
Also ...
new template -> new_template_name/eintragen
darunter Info eintragen
unten drei Register von off nach on
show drücken, anschauen

Code Auswählen Erweitern

set hm templateDef DimTest 0 "DimTest Info" lgDimMaxLvl:60 lgDimMinLvl:6 lgDimStep:3
Define
Dann oben in der Ecke global Usage auswählen,
zwei Dimmer werden gezeigt, bei
LichtWzR_Dim:self01
LichtWzR_Dim:self02

jeweils Haken setzen. Und Use drücken - Fehlermeldung

give :[short|long|both] with peer, not self01 self01,

Und nun was habe ich falsch gemacht?

Ja da war noch was, ganz oben, gaaanz weit weg, in der rechten Ecke (siehe Bild im Anhang).
Also neuer Versuch, ich wollte ja nur long (aber ich hatte doch long Register gewählt?) also long auswählen
Sieht dann so aus:

Code Auswählen Erweitern

set hm templateDef DimLED 0 "set new fixed dimLevel to 60" DimMaxLvl:60 DimMinLvl:6 DimStep:3
Jetzt fehlen die lg und es gibt ratzfatz zwei Templates DimLED_long und DimLED_short (ich wollte doch nur long?)
Das long Template funktioniert jetzt wie gewünscht, alle Dimmer auswählen, Use und fertig

1. Kann man, da es ja extrem relevant für den Erfolg ist, die Auswahlbox long and short/long/short nicht anschließend an die beiden anderen Boxen mit nach links machen, damit man sie nicht übersieht?
2. Warum geht mein template mit lg Registern für short und long nicht? Also kann ich gar keine gemischten Templates machen? Was hab ich da übersehen?
3. Warum erzeugt das Anlegen eines long Templates auch eines für short?

LG Otto

[frank]

hallo otto,

schön, dass du das ui ausprobiert hast.
nummer 5 lebt! 

die theorie zum template-type (dropdown ganz rechts) sieht folgendermassen aus:

für registersätze, die das short/long verhalten eines devices beeinflussen, hat martin die möglichkeit geschaffen, "generische" templates zu erstellen.
solche registersätze besitzen je einen block short-register und long-register mit jeweils "gleichen" registern, also symetrische registerblöcke. registernamen für short beginnen mit "sh" und long-register beginnen mit "lg". soweit sicher nichts neues.

wenn man nun ein "generisches" template mit "neutralen" registernamen (ohne präfix sh/lg) aus nur einem "neutralen" registerblock definiert, erstellt hminfo daraus automatisch 2 templates mit dem selbst vergebenen templatenamen plus den namensendungen "_short" und "_long". somit sind auch eigene templatenamen mit diesen endungen verboten (sollte ich abgefangen haben).
generische templates sind also lediglich eine arbeitserleichterung, da man nur ein template erstellt und automatisch 2 bekommt.

das "type"-dropdown existiert nur, wenn ein passender registersatz vorliegt.

1. short AND long
zum erstellen eines "normalen" templates (bezeichnet martin teilweise auch mit "both").
der gesamte registersatz mit sh- und lg-registernamen steht zur verfügung.

2. generic from short
es steht nur ein "neutraler" registerblock für ein generisches template (neueste bezeichnung von martin "short OR long") zur verfügung.
es ist der aktuelle short-registerblock, aber die registernamen haben kein präfix.

3. generic from long
es steht nur ein "neutraler" registerblock für ein generisches template (neueste bezeichnung von martin "short OR long") zur verfügung.
es ist der aktuelle long-registerblock, aber die registernamen haben kein präfix.


wenn du nun "nur" ein template für long erstellen möchtest, hast du im prinzip 2 möglichkeiten. entweder ein "normales" template, das nur aus lg-registern besteht, oder eben ein "generisches", wobei du aber zusätzlich auch eines für short erhälst.

mal angenommen, du hast bereits einen gepeerten aktor mit unterschiedlichen funktionen für short (toggle) und long (on-for-timer). nun möchtest du für beide bereits schon konfigurierten funktionen je ein generisches template erstellen, um hinterher 4 templates zu haben. toggle_short, toggle_long, on-for-timer_short und on-for-timer_long. dann solltest du für das generische toggle template "type=generic from short" wählen, da somit der vorhandene registersatz deiner short register zur verfügung steht. anschliessend einmal auf "Add All" klicken, namen und info text eingeben und schon kannst du mit define die ersten beiden templates erstellen.
danach für das generische template on-for-timer entsprechend mit der auswahl "type=generic from long" verfahren.
und schon hast du 4 templates für alle gepeerten devices, die diese register nutzen.

da es zb auch lg-konfigurationen gibt (register MultiExec), die bei short keinen sinn ergeben, sollte man vorher etwas nachdenken bei der wahl eines generischen templates. denn generische templates gibt es immer nur im doppelpack. hminfo lässt leider kein löschen (delete) eines "halben" generischen templates zu. man kann immer nur beide templates löschen, und das auch nur, wenn beide templates bei keinem device genutzt werden.


dein gefundener fehler bei use, sollte "nur" bei normalen templates für sh/lg-verhalten auftreten. der befehl "set hminfo templateSet" funktioniert leider nicht so, wie in der cmdref beschrieben (siehe nächsten post von mir).
als workaround bis zum fix empfehle ich generische templates. der fix wird wohl etwas aufwendiger und da ich gerade an der "edit" implementation arbeite, könnte es noch etwas dauern.


die position (ganz, ganz weit rechts  habe ich absichtlich so gewählt, da sie wahrscheinlich eher für "poweruser" wichtig ist und mit dem "eigentlichen" inhalt des templates doch nur indirekt zu tun hat.
die befehle sind ja ausserdem genau so weit rechts.
unglücklich ist eher, dass die description vom register ActionType beim dimmer elendig lang ist und wegen fehlendem leerzeichen kein automatischer zeilenumbruch erfolgen kann. das stört mich schon länger.


gruss frank