FHEM Forum

die aktuelle version von HMdeviceTools.js ist nun bei github zu finden.
durch einbundung des thirdparty-repository kann ein update nun über das "normale" fhem update bezogen werden.
siehe hinweise unter "Vorbereitungen" punkt 0.1.


das alt bekannte, aber leider wenig beachtete interface von @papa, zum einfachen konfigurieren der homematic-geräte-register, hat nun eine erweiterung bekommen. mit ein paar clicks kann man sich jetzt ein template erstellen und dieses den devices zuweisen. vielleicht schaffen es die ebenfalls zu unrecht unbeachteten templates von @martinp876 hiermit mal den durchbruch.

ich mach mal extra keine lange anleitung, um zu sehen, ob das handling des dynamischen interfaces intuitiv genug ist.


kurzanleitung:

Vorbereitungen:

0.1. automatischen download über den fhem update mechanismus einrichten. ein paar beispiele für den fhem update cmd sind in diesem post zu finden: https://forum.fhem.de/index.php/topic,112825.msg1197938.html#msg1197938 (https://forum.fhem.de/index.php/topic,112825.msg1197938.html#msg1197938)
update add https://raw.githubusercontent.com/frank962/fhem/main/autoupdate/controls_HMtools.txt
- die installierte version von HMdeviceTools.js kann über den fhem cmd "version" angezeigt werden

0.2. beim FHEMWEB device das neue file HMdeviceTools.js zusätzlich eintragen (leerzeichen getrennte liste):
attr <myFHEMWEB> JavaScripts pgm2/HMdeviceTools.js
HMdeviceTools sollte nun nach dem aufrufen einer detailseite eines homematic devices über den internals sichtbar sein.

0.3. hminfo definieren sollte pflicht sein. ohne hminfo funktioniert nur der bisherige register editor (expert mode).
define hminfo HMinfo
mit der zusätzlichen installation von HMinfoTools.js werden auch diverse status icons angezeigt.
https://forum.fhem.de/index.php/topic,112825.0.html (https://forum.fhem.de/index.php/topic,112825.0.html)

0.4 wichtig: damit keine neuen templates nach fhem restart verloren gehen, unbedingt die hinweise zur vorbereitung im wiki beachten (link beim fragezeichen). es muss natürlich auch eine config datei vorhanden sein, damit es nicht ständige meldungen in fhem.log gibt, da keine datei gefunden wird.
attr hminfo autoLoadArchive 1_load
attr hminfo autoArchive 1


Anleitung:

1. wenn bereits ein zugewiesenes ("Set") template existiert, wird dieses beim start des interface automatisch selektiert. ansonsten wird mit dem expertmode eröffnet. über das obere "menü"-dropdown kann man zu jeder zeit die bearbeitungsebene wechseln. in der dropdown-liste sind alle augenblicklich verfügbaren templates zu sehen (grün:assigned, gelb:extern assigned, weiss: ungenutzt)

2.1. template erstellen (new template...) und definieren mit dem befehl "Define".
mit "Show" kann man eine "trockenübung" ausführen; der erzeugte define-befehl erscheint ganz unten im weissen define-output. auch zum tauschen mit anderen usern gedacht. farbcode beim auswählen der register => grün:register mit festem, entsprechend eingestelltem wert. gelb: register mit exklusivem parameter (single par). orange: mehrere register teilen sich ein parameter (multi par). weiss: register bleibt unbenutzt (off).

martin hat bereits einige templates erstellt, die automatisch zur verfügung stehen.

2.2. template zuweisen und ggf neue registerwerte setzen mit "Set"
nach erfolgreichem define wird das neue template automatisch selektiert (farbcode weiss). nun muss es nur noch zugewiesen werden. wenn durch das template keine registerwerte zu verändern sind, verändert sich nur der farbcode (grün) im dropdown. müssen durch die zuweisung registerwerte im device neu gesetzt werden, wird das popup geschlossen, da man nun erst einmal das setzen der neuen werte verifizieren sollte.

2.3 template zuweisung aufheben mit "Unassign".
farbe wechselt von grün auf weiss (ungenutzt) oder gelb (von anderem device/peer extern genutzt)

2.4 kombinierter befehl "Use" ("Set"/"Unassign") und hilfsbefehle "Use All" und "Use None"
wenn in der templateansicht die templatedetails "global usage" oder "all details" ausgewählt sind, erfolgt das zuweisen und abwählen des templates über den befehl "Use". in diesen detailansichten erscheint jeweils eine tabelle (link-tabelle) mit allen möglichen device/peer kombinationen, die das aktuell selektierte template nutzen können. bei der tabellenerstellung werden auch die aktuell genutzen "links" mit den aktuell verwendeten parameterwerten gesetzt, so dass man eine aktuelle übersicht über die "globale" nutzung dieses templates hat.
über die checkbox kann man das template entweder zuweisen oder eine zuweisung aufheben. ebenso lassen sich eventuelle parameter für jeden link setzen. sobald eine veränderung an der tabelle vorgenommen wird, die eine änderung der nutzung des templates zur folge hätte, erscheint der "Use" befehl und der name des jeweiligen links ändert die farbe. man "klickt" sich also zunächst die gewünschte nutzung des templates für alle links zusammen und muss am ende nur einmal "Use" benutzen, um sämtliche template zuweisungen und parameter änderungen in einem "rutsch" zu erledigen.
wird das template für einen link aktuell noch nicht genutzt, zeigen parameter inputs zu diesem link zunächst noch keine werte an. wird nun dieser link über die checkbox erstmalig ausgewählt, erfolgt ein request an das device, um die aktuellen registerwerte, die mit den parameterwerten korrespondieren, zu ermitteln. bei erfolg werden diese werte dann entsprechend eingestellt.
mit den hilfsfunktionen "Use All" und "Use None" kann man alle links auswählen oder abwählen.

2.5 template endgültig löschen mit "Delete".
ein template kann nur gelöscht werden, wenn es in keinem device genutzt wird (weiss).
generische templates, an der endung "_short" oder "_long" erkennbar, können nur gelöscht werden, wenn beide templates ungenutzt sind.


im günstigsten fall ein default template selektieren, eventuelle parameter ggf noch anpassen und mit einem click zuweisen (set).
und schon fertig.  ;)

hallo martin,

falls du neben hmccu noch lust auf coding hast, hätte ich noch ein paar wünsche. am besten natürlich über hminfo.
sollte hmccu die selbe schnittstelle (daten/befehle) zur verfügung stellen, wäre eine gemeinsame nutzung des interface besonders einfach.  ;)



1. eine liste der fest eingebauten default templates.

die fest eingebauten templates kann man ja weder löschen noch editieren.
um das im interface zu unterbinden, könnte ich eine entsprechende liste gebrauchen.
am perfektesten für mich wäre eine kombination aus folgenden listen erweitert mit der angabe, ob es sich um ein default template handelt.

a. available templates für eine device:peer kombination, die im befehl "set <device> tplSet_<peer> <template>" zu finden ist.
b. zu jedem dieser templates die infos, die über "set hminfo templateUsgG sortTemplate" zu bekommen sind. wenn ein available template zusätzlich in anderen device:peer kombinationen assigned/benutzt wird, für jede weitere nutzung dieses templates eine zusätzliche zeile. so wie bei templateUsgG, wenn mehrfachnutzungen existieren.
c. in der 1.spalte mit dem templatenamen eine zusätzliche kennzeichnung für ein default template.


2. ein defmod befehl zum editieren existierender templates.

als workaround habe ich zur zeit nur einen komplexen ablauf im kopf.
a. alle template zuweisungen ermitteln, merken und lösen,
b. altes template löschen,
c. editiertes template definieren,
d. neues template wieder allen devices wie unter a. zuweisen.

eventuell hast du eine einfachere möglichkeit auf lager.


3. ein befehl zum übermitteln der "echten" definition eines templates

zum parsen/einlesen eines existierenden templates nutze ich "set hminfo templateList <template>".
auf diese weise wird der vorgang allerdings unnötig "sensibel/fragile", da die eigentliche definition des templates auf dem weg von hminfo zum interface mindestens über eine zusätzliche transformation (templateList) erfolgt.

Hallo Frank,

Die Erweiterung von papa habe ich noch nicht gesehen - muss ich gleich einmal probieren. Wo finde ich die aktuelle Version von hm.js?

Zu den default templates: Diese sollte man schon editieren und löschen können (muss ich noch einmal prüfen...
Diese haben ich vor langer zeit gemacht. Ich nutze eine Reiha anderer Templates. Ich würde gerne eine Reihe von templates zu Verfügung stellen. Vor ab wäre ein Austausch sinnvoll, wie der "Mainstream" es haben will.
Mittlerweile ist das "Anwenden" von Templates ohne Zusätze (hm.js) möglich. Es muss nur definiert sein.
Zum Hintergrund: Template-definitionen und template-assignments werden im File "regConfig.cfg" gespeichert (hmInfo ist der "Verwalter") Beim normalen Save wird dies auch gespeichet. Man sollte es dann auch wieder laden. Hierzu
attr hm autoLoadArchive 1
attr hm autoArchive 1

setzen.
In jeden Device, welches das Template nutzen "könnte" (da die Register vorhanden sind) erscheinen die Komamndos
tplSet_<peer> [liste der möglichen templates]
also ein "click-only" kommando, nix tippen.
Ebenso ein Kommando die Templates zu löschen
Und weiter ein Kommando, die Parameter des Templates zu setzen (m.E. ein muss!)

Einzig das Erstellen ist gewöhnungsbedürftig. Aber mit dem Template-editor (in Wiki beschrieben) kann man dies auch "zusammenclicken". Hier habe ich auf eine js unterstützung gehofft, dann habe ich es eben ohne gemacht.

Zu deinen Ideen:
Die Templates würde ich in der Tat gerne übernehmen - von der Semantik und Syntax zu mindest. Aber noch fehlen mit bei HMCCU die Grundlagen. Einiges ist schon gut, anderes verstehe ich nicht und einigen werde ich nicht (zumindest für mich) modifizieren. Noch weiss ich nicht so recht, welche Richtung Dirk gehen will.

zu 1.
Löschen und editieren geht schon. Allerdings muss man das File regConfig.cfg über hmInfo nutzen und einlesen (loadConfig oder autoLoadArchive).
Die aktuelle Liste war eine Idee vor jahren. Ich würde sehr! gerne eine Liste von Templates bereitstellen, welche die Notwendigkeiten der Anwender  abblildet.
Eine (Um-)Frageliste am Ende.

zu 1 a) Im Kommando tplSet_<peer> gibt es schon eine drop-down list von templates. Diese reicht nicht? tplSet kommt im getcmdList nicht vor. also ein neues get kommando?
zu 1 b) Ein Template kann bei einem Kanal immer für alle seiner Peers genutzt werden. Es gibt auch templates ohne peers. De-facto ist es also ein Liste der nutzbaren Templates dieses kanal, also ein Subset aus  templateUsgG
zu 1 c)  nicht notwendig, siehe oben. Evtl wären unveränderliche default-templates sinnvol... ich hatte mich damals dagegen entschieden.

zu 2)
Schon einmal
define ht HMtemplate
probiert? in "Internals" habe ich versucht eine anleitung einzupassen.. Editieren der Register geht über die Attribute.
https://wiki.fhem.de/wiki/HomeMatic_Templates
HMtemplate ist ein editor. Es könnte nach den editieren gelöscht werden - frisst aber kein Brot.

zu 3)
nun, du hast schon merkwürdige Vorstellungen, was ich mir antun will. Massochist bin ich nicht. ;)
a) default templates werden aud HMConfig erst einmal eingelesen, wenn man noch nichts hat
b) HMInfo verwaltet template-definitionen (wer sonst) und auch das File regConfig.cfg. Der Name kann über attr hm configFilename festgelegt werden. Probiere einmal

attr hm configFilename regConfig.cfg # default - kann man weglassen
get hm templateUsgG sortTemplate # liste der genutzten (icht nutzbaren)Templates  sortiert nach template
set hm saveConfig # das regConfig.cfg wird geschrieben. Hier enthalten sind alle Register-settings aber auch die template definitions und assignments
set hm loadConfig # regConfig wird gelesen (und alle fehlenden Register-settings/readings). Default templates sind dann Geschichte.
attr hm autoLoadArchive 1_load #regConfig.cfg wird nach FHEM start eingelesen, templates assigned und definitionen wieder hergestellt
get hm peerUsg # relativ neu. eine nach trigger sortierte listeder template nutzung. Ich habe für mich beschlossen, dass die Funktion jedes Peering über templates beschrieben wird

Das sollte für den Anfang reichen

So, nun die Fragen zu den default templates.
a) short/long
Am häufigsten hat man wohl einen Schalter (RTs später). Dieser ist gepeert mit einem Button oder BM. Zu definieren für dieses Peering ist nun die Reaktion auf short und auf long.
Option aa) man hat eine liste von Templates [on|off|toggle|ignore] (sicher noch mehr). Nun weist man dem peering 2 Templates zu, bswp short=on, long= ignore.
Option bb) man weist einem peering typisch ein template zu. Da man immernoch beide funktionsteile beschreiben muss quartiert sich die anzahl der templates. Also template für short_long = [on_on|on_off|on_ignore|on_toggle|off_on|off_off|...]
Ich bin zu option bb übergegangen da es einfacher in Device zu sehen ist. Da ich buttons bspw einer FB im Wohnbereich mehrfach nutze brauche ich sehr viele Konbinationen. Gerade ist eine neue notwendig geworden.
So nutze ich folgende Nomenklatur der Templates
<modelTyp><shortBehavior><longBehavior>
Beispiel
SwOnOff # für Switches: short= on, long = off
DimOffDown # für Dimmer: short= off, long = dimDown

b) template parameter
für einen Switch on will ich bswp die Ontime definieren. alle (ALLE) meine buttons schalten das List nur für eine Zeit ein. Das sind im Wohnzimmer einige Stunden. Aber irgendwann geht das Licht aus. Der Parameter ist einstellbar - das sind die template-paramenter. Die Frage ist, welche notwendig sind. Beispiel ist eben ein Schaltaktor. Möglich sind
- einschalt-dauer
- einschaltverzögerung
- ausschaltverzögerung
- Helligkeitslevel beim peering mit Bewegungsmeldern.
Der Template parameter kann dann in jeder Entity setz einfach geändert werden.
Übrigens haben meine RTs auch alle ein template. Hier stelle ich valvemax und boosttime individuell ein.

Ich warte auf das feedback

nur kurz:
hm.js habe ich hier im ersten post angehängt.

danke.
das Modul sollte hm.js sollte irgendwo anbgelegt werden. Zumindest in contribute. Der Name ist leider recht nichtssagend.

Meine Bewertung:
- Einsatz zur Definition eines Templates: Sehr gut.
     + man kann ein registerset  also template nutzen
      -  template parameter kann ich noch nicht hinzufügen - oder?
      - die Option "both" ist für peerings unterstützt. Short/long kann man nicht definieren. Kein Bedarf?
  - templates editieren: nicht unterstützt. Müsste man in hmInfo machen.
       - HMInfo hat (wie immer) für übergreifende Aktionen seine Berechigung. Somit sollte das editieren auch hier angelegt werden . HMTemplate könnte dann obsolet werden.
  - templates zuweisen: Ist gut.  Vorteil ist, dass man die Beschreibung sieht und die Parameter des Templates
    beides kann man auch direkt setzen  - allerdings mit weniger Beschreibung. Perfekt, dass die Werte aus dem Commandset umgesetzt werden!

Wie immer: Das Modul erlaubt User-freundliche Kommados mit a) Beschreibung b) Auswahllisten mehrer Parameter, Beschreibung der Parameter.
Das vermisste ich schon vor Jahren. Sollte generell zu verfügung gestellt werden. Das kann ich häufiger brauchen.

Ein "get" zu templates baue ich noch :)

done.
get <entity> cmdList updated
get <entity> tplInfo implemented
Achtung: Auch HMConfig muss geladen werden.

Die Infos zu den Templates müsste ich sicher noch allgemeinverständlich gestalten. Wegen der geringen Nachfrage habe ich  mir keine Mühe mehr gegeben.
Hier ein paar Beispiele:
Bei RTs habe ich a) an den Regelparametern gespielt und b) die stelle ich Boost-Time und maxValve individuell ein. Alles andere ist identisch. Dafür mein Template als Kommando:
set hm templateDef HeatDefault boost:valveMax "myDefault RT settings, enter boostTime and valveMax" showWeekday:off boostPeriod:p0 modePrioParty:all tempMax:30.5 valveMaxPos:p1 daylightSaveTime:off btnNoBckLight:off regAdaptive:on showInfo:time decalcTime:11:00 noMinMax4Manu:off tempOffset:0.0K decalcWeekday:Sat dayTemp:21 tempMin:4.5 nightTemp:17 boostPos:30 valveOffsetRt:0 valveErrPos:15 modePrioManu:all

Mein Standard template für ein-taster bedienung eines Schalters: Kurz ist ein, lang ist aus. Ich präferieren dedizierte Kommandos. Toggel nur mit Widerwillen.
natürlich wird das Licht nur für eine einstellbare Zeit eingeschaltet
set hm templateDef SwOnOff timeOn "sh:on lg:off" shSwJtOn:no shActionType:jmpToTarget shSwJtOff:dlyOn lgActionType:off shOnDly:0 shSwJtDlyOn:on shSwJtDlyOff:dlyOn shOnTimeMode:absolut shOnTime:p0 shMultiExec:off


Hier ein Template für Blind - herunterfahren.
set hm templateDef BlSmartStopDn 0 "from Master BlSmartStopDn > FB_09:both" shOnTime:unused lgCtRefOn:geLo shBlJtRefOn:on shBlJtDlyOn:dlyOff lgOffTime:unused lgOnLevel:100 shMaxTimeF:unused shBlJtOn:dlyOff lgOffDly:0 shBlJtOff:dlyOff lgCtOff:geLo lgOnTimeMode:absolut shBlJtRampOff:off lgCtRefOff:geLo shActionType:jmpToTarget lgCtValLo:50 shCtRampOff:geLo shBlJtDlyOff:refOff shCtRefOff:geLo shCtValLo:50 lgMaxTimeF:0.5 lgCtValHi:100 shBlJtRefOff:rampOff lgBlJtOn:dlyOff shCtOff:geLo lgBlJtDlyOff:refOff lgOnDly:0 lgOnTime:unused shBlJtRampOn:on shMultiExec:off shOnTimeMode:absolut lgMultiExec:on lgBlJtOff:dlyOff lgOffTimeMode:absolut shOffTime:unused lgBlJtRampOn:on lgDriveMode:direct lgBlJtRampOff:rampOff lgCtDlyOff:geLo shCtOn:geLo shCtRampOn:geLo lgCtRampOff:geLo lgActionType:jmpToTarget shCtDlyOff:geLo lgBlJtRefOff:rampOff shCtDlyOn:geLo lgBlJtRefOn:on shOffDly:0 shOffTimeMode:absolut lgBlJtDlyOn:dlyOff lgCtOn:geLo shCtRefOn:geLo shOnDly:0 lgCtDlyOn:geLo shCtValHi:100 shOffLevel:0 lgOffLevel:0 shOnLevel:100 lgCtRampOn:geLo shDriveMode:direct


Möglchkeiten aus HMtemplate:
ein
get ht defineCmd <template>
gibt dir das Kommado zurück welches du zur Definition eines Tempaltes in die Kommandozeile pasten kannst. Voraussetzung: die  HMInfo-entity heist "hm". Die Idee ist, dass  jeder der meint ein cooles tempate zu haben er hier herausziehen und weitergeben kann.
Viel einfacher konnte ich es mir nicht mehr vorstellen.

freut mich, dass es dir gefällt. dann sind wir augenblicklich schon 3.  :)

ZitatMeine Bewertung:
- Einsatz zur Definition eines Templates: Sehr gut.
     + man kann ein registerset  also template nutzen
      -  template parameter kann ich noch nicht hinzufügen - oder?
      - die Option "both" ist für peerings unterstützt. Short/long kann man nicht definieren. Kein Bedarf?

parameter definieren sollte funktionieren, siehe kurzanleitung punkt 2.1.
es könnte sein, dass dich die vielen, "gesperrten" einträge für die parameter irritiert haben. es ist immer nur der erste mögliche parameter aktiv. zuerst also nur p0.

hintergrund: da es "nur" 9 parameter geben darf, wollte ich von anfang an alle in der selekt liste sichtbar haben, damit man sie sparsam nutzt.
weil die parameter aber mit p0 beginnen und am ende eine kontinuierliche reihe ergeben müssen, deaktiviere ich die noch nicht benötigten einträge. aus vielen beiträgen hier im forum, habe ich ja gelernt, dass viele user auf "alles" klicken, was nicht rechtzeitig auf die bäume huscht.  ;)

für short/long ist natürlich "bedarf". daher steht es bereits auf der todo liste im 1. post.
die reihenfolge in der todo liste zeigt meine aktuelle priorität.

Zitat- templates editieren: nicht unterstützt. Müsste man in hmInfo machen.
       - HMInfo hat (wie immer) für übergreifende Aktionen seine Berechigung. Somit sollte das editieren auch hier angelegt werden . HMTemplate könnte dann obsolet werden.

"templates editieren" baue ich hier ein und hat für mich oberste prio.

das betrifft ja meinen wunsch 2. von oben.
seit gestern abend habe ich aber ganz neue ideen zum editieren im kopf, so dass sich wunsch 2. etwas geändert hat.
bisher hatte ich zu kurz gedacht, da ich immer nur den infotext im auge hatte. wenn man aber parameter und register hinzufügen oder ändern will, muss man ja sowieso zuerst alle assignments entfernen und anschliessend neu setzen. somit funktioniert dann ja sowieso nur mein beschriebener workaround.
und wenn ich dann schon alle assignment daten einsammeln muss, kann ich auch gleich eine tabelle aller device:peer kombis erstellen, die das template aktuell nutzen. über checkboxen wird man die assignments dann auswählen können.

mein plan ist quasi ein 2-stufen-editieren des templates.
stufe 1 (basic): alle daten editieren, die die definition des eigentlichen templates betreffen (info, register, parameter).
stufe 2 (global): alle "link"- daten des templates editieren (assignments, parameter values).

das bringt mich dann zu meinem neuen wunsch 2. zum editieren:
eine liste aller möglichen (possible) device:peer kombinationen, die dieses template nutzen könnten. also zb:
"get hminfo templatePossibleDevices <template>"
idealerweise enthält die liste eine spalte mit den aktuellen parameter values bei device:peer kombis, die aktuell mit diesem template assigned sind. bei allen noch nicht genutzten kombis enthält die spalte, die aktuell gesetzten register values. zum initialen assignen (set) nehme ich immer die aktuellen register einstellungen, um die parameter zu füttern. so habe ich deine entity befehle tplSet_<peer> zumindestens verstanden. wenn du den values bei assigned device:peer kombis die jeweilige parameter id voranstellt ("p0:", "p1:", ...) kann ich dadurch ein assignment erkennen.

damit könnte ich dann ein "globales" assign/unassign/set realisieren.
allerdings sind meine ideen bisher immer ein stück weit von meinen fähigkeiten entfernt.

Zitat- templates zuweisen: Ist gut.  Vorteil ist, dass man die Beschreibung sieht und die Parameter des Templates
    beides kann man auch direkt setzen  - allerdings mit weniger Beschreibung. Perfekt, dass die Werte aus dem Commandset umgesetzt werden!

was meinst du mit weniger beschreibung? bei inputs, die keine auswahlliste haben, wird der value range am mauszeiger sichtbar, wenn der mauszeiger über dem element ist. die descriptions und inputs sollten identisch zu den register zeilen im expert mode sein. papa hatte diese sinnvolle "zerlegung" eigeführt. vermisst du etwas? könnte beim parsen verloren gegangen sein.

zu den descriptions bei den parametern habe ich noch folgende idee:
wenn im infotext zum template am ende eine irgenwie gekennzeichnete liste mit parameter beschreibungen existiert, werden diese texte bei den parametern entsprechend angezeigt.
wahrscheinlich besonders interessant bei nutzung von mult-parametern, die gleichzeitig mehrere register bedienen. zur zeit wird immer die description des registers benutzt, das in der definition des templates als erstes mit der entsprechenden parameter id auftaucht. 

gibt es eigentlich eine maximale länge für den infotext?

ZitatMöglchkeiten aus HMtemplate:
ein

Code Auswählen Erweitern

get ht defineCmd <template>
gibt dir das Kommado zurück welches du zur Definition eines Tempaltes in die Kommandozeile pasten kannst. Voraussetzung: die  HMInfo-entity heist "hm". Die Idee ist, dass  jeder der meint ein cooles tempate zu haben er hier herausziehen und weitergeben kann.
Viel einfacher konnte ich es mir nicht mehr vorstellen.

genau diesen cmd meinte ich mit meinem wunsch 3.
ich hätte es allerdings gerne über hminfo, um damit existierende templates zu parsen.
ich verfolge nämlich meinen vagen traum, das interface irgend wann in ferner zukunft quasi 1zu1 auf hmccu adaptieren zu können. je weniger beteiligte module für die requests, desto grösser die wahrscheinlichkeit.

aus hminfo wird dann hmccuinfo, und fertig.  ;)

click dir mal ein template zusammen und benutze nicht den define button, sondern den show button.


gefundene fehler:

1. HM-LC-SW1PBU-FM.
wenn ich diesen mit einem fensterkontakt peere, gibts hierfür kein cmd "set <entity> tplSet_<peer>" im aktor. dadurch natürlich auch keine available templates. bei den fest gepeerten buttons self01/2 tauchen jeweils ca 1 dutzend default templates auf. nach meiner logik müssten beim fensterkontakt die selben templates auftauchen.

2. HM-LC-DIM1T-FM
bei diesem device fehlen mir leider diverse register. ich hatte es vor einiger zeit mal gepostet: https://forum.fhem.de/index.php/topic,105531.msg994652/topicseen.html#msg994652 (https://forum.fhem.de/index.php/topic,105531.msg994652/topicseen.html#msg994652)

3. HM-CC-TC
auch hier fehlen mir register, zb day-temp, night-temp, party-temp.

4. HM-ES-PMSW1-PL
hier kann ich im channel 02 beim register txThrPwr kein special unused mehr setzen. https://forum.fhem.de/index.php/topic,96646.0.html (https://forum.fhem.de/index.php/topic,96646.0.html)

könntest du nicht mal deine neuen hmccu device daten irgendwie mit den registerdaten aus HMConfig.pm vergleichen?
ich habe auch schon mal vergeblich danach geschaut, denn das gemisch aus subtype/clones/direkten -daten habe ich immer noch nicht durchschaut.



die neuen befehle schau ich mir morgen an, danke schon mal.

So, mal sehen, das sich alles korrekt kommentiere :)

* Parameter sollten funktioniere => ok
* 9 Parameter sind m.E. reichlich. Ansonsten ist ein neues Template fällig.

Zitatwenn man aber parameter und register hinzufügen oder ändern will, muss man ja sowieso zuerst alle assignments entfernen und anschliessend neu setzen.

Das sehe ich definitiv nicht so. Unassign kommt nicht in Frage - widerspricht den Komzept.
Das (von mir vorgesehene) Vorgehen ist - und so nutze iches auch:
- will ich ein template ändern ändere ich das Template
   > die assigned entites divergieren - klar
   > ich starte ein "set hm templateExe"  => alle definitionen werden geschrieben
   > ich mache ein get hm templateChk => ich sehe den Zustand und kann aggieren
   > ich mache ein get hm configCheck => beinhaltet (natürlich) templateChk

Zitatkann ich auch gleich eine tabelle aller device:peer kombis erstellen

Die hast du schon in HMInfo

Zitatüber checkboxen wird man die assignments dann auswählen können

cool. Hier reden wir aber definitiv über HMInfo. "In" einem Entity-context manipuliert man "die Entities". Will man übergreifend aggieren macht man das in HMinfo.
Bitte nicht die Systematik zerstören

Zitat"get hminfo templatePossibleDevices <template>"

mal sehen. Würde ich aber eigentlich in HMtemplate sehen. Mal schauen. Problem ist die Berechnung. Das könnte Rechenzeit kosten.... Da muss jedes Register des Templates mit den Registern aller Devices verglichen werden . Statisch möchte ich es nicht machen....

Zitatidealerweise enthält die liste eine spalte mit den aktuellen parameter values bei device:peer kombis, die aktuell mit diesem template assigned sind

nun steige ich langsam aus. Die Liste wird sehr lang. Und auch breit. Wofür brauchst du sie? Kann ein User damit umgehen und was ist das Ziel? Ist das für Nerds?

Zitatnehme ich immer die aktuellen register einstellungen,

So macht es das Assign kommando, korrekt.

Zitatwenn du den values bei assigned device:peer kombis die jeweilige parameter id voranstellt ("p0:", "p1:", ...) kann ich dadurch ein assignment erkennen.

dann wird das Kommando noch lääänger.

Zitatdamit könnte ich dann ein "globales" assign/unassign/set realisieren.

nicht schlecht. Allerdings denke ich, muss ich hier an einem Konzept arbeiten, die Performance gering zu halten. Ich denke wir haben aber schon einige gute Funktionen. Wenn Anwender interessiert sind wenden sie es an, wenn nicht, nicht.
=> wir brauchen standard-templates. Ohne diese werden wir keinen Durchbruch erreichen.
=> welche templates brauchen wir? Welches Konzept (nicht des Codes, sondern der Templates) würdest du sehen?

Zitatwas meinst du mit weniger beschreibung?

Um Templates zu assignen brauche ich das neue Frontend nicht, geht auch so - per drop-down. Der Simple-user will/soll die Register nicht sehen. Der Nerd schon.
Im Frontend ist "mehr als genug" info.

Zitatdes registers benutzt, das in der definition des templates als erstes mit der entsprechenden parameter id auftaucht.

passt. Es wird nur selten ausnahmen mit multi.reg geben.

Zitatgibt es eigentlich eine maximale länge für den infotext?

nein

Zitatich hätte es allerdings gerne über hminfo, um damit existierende templates zu parsen.

Verstanden. Aber HMtemplate parsed existierende templates.

Zitatgefundene fehler:
1. HM-LC-SW1PBU-FM.

sollte nicht sein. Allerdings: hast du schon ein getConfig gemacht? Ihc prüfe die vorhandenen Register, nicht die möglichen. Ohne getConfig sind die Register nicht vorhanden.
Könnte ich umstellen - aber das zuweisen wird scheitern, da ich die hex-werte beim Assign nicht rechnen kann. => nein, nicht umstellen.

ZitatHM-CC-TC auch hier fehlen mir register, zb day-temp, night-temp, party-temp.

werde ich prüfen... das Device habe ich nicht(mehr)

Zitatkönntest du nicht mal deine neuen hmccu device daten irgendwie mit den registerdaten aus HMConfig.pm vergleichen?

die neuen nicht - da habe ich andere Wege. Aber da es handarbeit ist können fehler drin sein. Bei HMCCU geht es dann automatisch.

Die Bugs sollten erledigt sein. Der Erste war heftiger, als erwartet. Allerdings ist die Registerliste schon komplett, nur die Anwendung hatte ein Problem. Systematisch also.

So nun erst einmal wieder eine meiner generellen Betrachtungen: Was/wie/wo templates
Use cases / user:
Ich gruppiere die User einmal digital in 2 Gruppen
A) Nerds: wollen alles steuern, freuen sich über komplexe kommandos bei welche sie viel einstellen können - wenn sie das Thema interessiert. FHEM developer sind erst einmal nerds. FHEM Nutzer zu 80%
B) User: wollen nichts einstellen. Plug&Play muss es gehen. Don't rtfm - das Kommando muss intuitiv sein, selbsterklärend. Alles über auswahllisten (maxilal) - Am Besten alles stellt sich selbst ein.

Ich beispielsweise bin... beides. wenn ich codiere bin ich Nerd. Nutze ich fremde Module bin ich User. Nutze ich mein Modul einige Zeit werde ich immer mehr user

=> m.E. werden templates nicht angewendet weil eine a) das Interface bei Einführung zu nerdig war b)  User sich vom "define"  haben abschrecken lassen anstatt sich auf "assign" zu konzentrieren c) die nach gereichten vereinfachungen nicht mehr beachtet wurden d) Nerd Anwender in panik gerieten, dass man ihnen Kontrolle nimmt und e) die User von den Nerds nicht in Richtung tempaltes geführt wurden.

Um templates zu "vermarkten" braucht es zu allererst
1) eine gute Abdeckung an funktionen durch "default templates". User wollen erst einmal nicht über Details nachdenken sondern fertige Lösungen einsetzen. Anpassen kommt "viel" später
2) Fokus auf "assign". Der User sollte wenig mit "define" in Konkakt kommen. Das schreckt ab

Natürlich gibt es die Nerd-anwendungen dann auch noch!

Bisher habe ich m.E. die User mit den vielen Optionen überfordert. Templates lassen "unendlich viel" Konzepte zu. Ich hätte nur eines bewerben sollen. Kannst du mir helfen, die Entscheidung zu treffen? Bei den wohl am meisten genutzten Templates (wenn es einmal so weit kommt) sind sicher die Schalter oder Dimmer zu nennen. Hier kann man
I) templates "both" definieren. Es wird also das Verhalten bei long und short press auf einmal definiert
II) templates "short" oder "long" separat definieren. Es werden deutlich weniger Templates definiert, aber es müssen immer 2 assigned werden
III) interne Funktion separiert. Ich habe bspw die Jumptable in einem und die CT in einem andere Template definiert. Das sind noch weniger Templates aber noch mehr assignments

Ich nutze aktuell die Version I).
Des weiteren brauchen wir die template parameter welche beinhaltet sein sollten.
Somit sehe ich für einen Schalter die einschaltzeit und ausschaltverzögerung.
Für Motion detector braucht man m.E. ein anderes Template. Dies soll erreichen, dass ein "on" den MD ausser Kraft setzt.
Switch template beginnen mit "SW"

Damit komme ich für I) auf
SwOnOn OnTime, OffDelay
SwOnOff OnTime, OffDelay
SwToggleOff OnTime, OffDelay
SwOffToggle OnTime, OffDelay
SwIgnoreToggle OnTime, OffDelay
SwOffOff
...
Ich habe als Funktion On/Off/Toggle/Ignore welche in jeder Kombination genutzt werden können.
Weiter habe ich Toggle2Cnt. Macht sinn, wenn man eine Button zum Schalten mehrer Aktoren nutzen will

Deine Meinung?


Noch ein Thema: Context.
Aktuell konzentrierst du dich voll auch CUL_HM. Bitte unbedingt beachten, dass CUL_HM Kanäle bearbeitet. Befinde ich mich in diesem Kontext sind kommandos welche entity-übergreifend sind (exterm) unpassend.
HMInfo ist die Übergreifende Entity. Alles was übergreifend ist (und bei Templates ist man schnell an dieser Stelle!) muss (MUSS) hier bearbeitet werden.
Daher meine Bitte, dass template-editieren auf der Ebene HMInfo bearbeitet wird. Es hat schon seinen Grund, warum ich HMTemplate gebaut habe. Schlussendlich halte ich das für den richtigen Weg, auch für deine übergreifenden Ideen.
HMTemplate wird, wenn du fertig bist, nicht mehr benötigt. Aber mir würde es gefallen wenn du deine Platfrom in HMTemplate integrierst, oder es ersetzt. De-facto stellst du einen Template-editor zu Verfügung.
Also das Assign und die Implementierung in CUL_HM ist fast komplett. Hier sollte nicht mehr passieren (ausser fixes).
HMInfo verwaltet die Templates, ist aber im Hintergrund.
Dein Frontend bietet nun eine Möglichkeit die templates übergreifend zu "bedienen". Ob du das nun an HMInfo oder in ein (neues) HMTemplate integrierst wäre mir egal. Zuerst sehe ich eine bessere visualisierung der Funktionen aus HMTemplate.

Deine Meinung?

Bin auch schon Fan, auch wen ich noch keine Zeit hatte, es mir mal anzusehen. Schön, dass meine einfachen Anfänge weiter geführt werden.

hm.js einkopiert: diverse fehlende Register. Klar, also:
FHEM-Update, 10_CUL_HM und HMConfig aus dem SVN dazu + reload = läuft! Sauber!

Vielleicht finde ich jetzt auch endlich mal mehr Zugang zu den Templates.

Einen Wunsch hätte ich noch: Templates kann ich anwenden ("set") und die Verknüpfung aufheben "unassign" (beides testweise mit autoOff_short auf self01 eines Steckdosenaktors probiert). Danach bleiben aber alle durch das Template gemachten Änderungen weiterhin aktiv. Ein Reset aller betreffenden Register wäre hilfreich.

Derzeit sehe ich keine andere Möglichkeit, als bei list3 das Peering aufzuheben und erneut zu setzen und für list0 und list1 das Gerät zurückzusetzen, wobei man es dann wieder neu pairen muss...
Selbst wenn es eine Defaults-Datenbank gäbe, müsste sie mit jeder Geräte-FW aktualisiert werden. Und list3-Defaults richten sich unter anderem danach ob single oder dual gepeert ist.

Eventuell könnte man auf Backups in regSave.cfg zurückgreifen. Die laufen aber m.W. auch nicht automatisiert ab, meine letzte ist vom August 2019.

Hat jemand von Euch dazu irgendeine Idee?

moin martin,

du bist ja wie im rausch, ich komme kaum hinterher.  :)


der neue befehl "get tplInfo":

templates for peerings serving short AND long press:
   SwToggleIgnore   params:timeOn                   Info:sh:toggle lg:ignore
device templates:
   hallo            params:                         Info:hallo@dies ist test 1.
   hallo1           params:                         Info:hallo@das ist test 2, @mit 3 zeilen.
   hallo2           params:                         Info:hallo@test 3 macht autowrap mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb, @ende zeile 5.
templates for peerings serving short OR long press:
   SwCondAbove      params:condition                Info:Switch: execute only if condition level is above limit
   SwCondAbove      params:condition                Info:Switch: execute only if condition level is above limit
   SwCondBelow      params:condition                Info:Switch: execute only if condition level is below limit
   SwCondBelow      params:condition                Info:Switch: execute only if condition level is below limit
   SwOff            params:                         Info:Switch: off if trigger
   SwOff            params:                         Info:Switch: off if trigger
   SwOnCond         params:level cond               Info:switch: execute only if condition [geLo|ltLo] level is below limit
   SwOnCond         params:level cond               Info:switch: execute only if condition [geLo|ltLo] level is below limit
   SwOn             params:                         Info:Switch: on if trigger
   SwOn             params:                         Info:Switch: on if trigger
   SwToggle         params:                         Info:Switch: toggle on trigger
   SwToggle         params:                         Info:Switch: toggle on trigger
   autoOff          params:time                     Info:staircase - auto off after -time-, extend time with each trigger
   autoOff          params:time                     Info:staircase - auto off after -time-, extend time with each trigger
   motionOnSw       params:ontime brightness        Info:Switch: on for time if MDIR-brightness below level
   motionOnSw       params:ontime brightness        Info:Switch: on for time if MDIR-brightness below level

• in spalte 1 für den bereich "short OR long" fehlt noch "_short, _long" am ende der template namen.
• die gruppe device templates würde ich immer ganz oben ausgeben.
• wenn keine templates vorhanden sind, gibt es keine ausgabe/reaktion beim klicken auf den get befehl. eine mitteilung über diese tatsache, wie "no templates available", gäbe weniger irritationen.
• bei meinen "hallo"-templates siehst du im info text "klammeraffen" (@).
  im nächsten update werden sie für manuelle zeilenumbrüche zur formatierung verwendet. nur als hinweis, falls du deine default templates entsprechend "formatieren" möchtest.
  beim definieren über das interface werden die @ dann automatisch aus den newline-zeichen generiert, die durch die benutzung der return taste im info-inputelement entstehen.
  
  ohne substitution der \n hat hminfo templateDef leider einen leeren infotext erzeugt.

 

fehlende cmds "set tplSet_<peer>" für einen gepeerten fensterkontakt:

hierzu habe ich mal einen eigenen thread erstellt.
https://forum.fhem.de/index.php/topic,107137.0.html (https://forum.fhem.de/index.php/topic,107137.0.html)


template vermarktung:

ZitatBisher habe ich m.E. die User mit den vielen Optionen überfordert. Templates lassen "unendlich viel" Konzepte zu. Ich hätte nur eines bewerben sollen. Kannst du mir helfen, die Entscheidung zu treffen? Bei den wohl am meisten genutzten Templates (wenn es einmal so weit kommt) sind sicher die Schalter oder Dimmer zu nennen. Hier kann man
I) templates "both" definieren. Es wird also das Verhalten bei long und short press auf einmal definiert
II) templates "short" oder "long" separat definieren. Es werden deutlich weniger Templates definiert, aber es müssen immer 2 assigned werden
III) interne Funktion separiert. Ich habe bspw die Jumptable in einem und die CT in einem andere Template definiert. Das sind noch weniger Templates aber noch mehr assignments

1. das wichtigste für mich ist ein eindeutiger und lesbarer template name.
dieser darf absolut keinen zweifel darüber aufkommen lassen, was das template macht. je weniger das template macht, desto einfacher, eindeutiger und kürzer kann der name sein.
jeder der die templateliste einmal genutzt hat (zb durch forenuser gelenkt), muss auch nach 6 monaten zweifelsfrei das selbe template sofort wiederfinden.

2. auch die subtype beschreibung zur unterscheidung schalter/dimmer finde ich im namen störend und verwirrend, da sie nichts zur funktionsbeschreibung des templates beiträgt. zur unterscheidung der templates leider nötig, sollte dieser zusatz aber nicht als präfix an der besten position des namens stehen. ich würde ihn für schalter gänzlich weglassen und bei dimmern im namen "verstecken" (vorletzte stelle vor short/long).
ebenso abkürzungen möglichst vermeiden und namensteile explizit durch tiefstriche von einander abgrenzen.
am anfang des namens muss die funktion stehen, und diese muss mit den funktionsnamen bei den set befehlen übereinstimmen. also bitte kein "autoOff", auch wenn der name wirklich schön ist, aber in fhem weiss irgendwann jeder, was on-for-timer ist. und danach wird auch gesucht.

3. weniger ist mehr.
eine zu lange templateliste ist auch erschreckend. besser im "einführungsangebot" (default templates) nur die wichtigsten. wir müssen die user erst "anfixen". weniger gebräuchliche "standard" templates würde ich aus diesem grund ins wiki auslagern. es ist ja total einfach uber set templateDef (copy&paste) zu erweitern. ausserdem kann man dadurch interessierte user langsam an weitere template funktionalitäten heranführen.


daher halte ich eine mischung aus II) und III) am optimalsten. modulares system, getrennt für short und long. die grundfunktionen sind quasi "basic"-templates, die jeweils mit "addon"-templates ausgebaut werden können. dabei sollten die basic templates das komplette parameterset beschreiben, um auf jedenfall eine definierte grundlage zu schaffen. addons ändern dann nur noch wenig.
im info text sollten dann bei basic templates hinweise zu sinnvollen addons stehen. und umgekehrt im addon hinweise zu sinvollen basic templates.


für schalter würde ich zur zeit folgendes vorschlagen. wobei mir noch eine sinnvolle/prägnante benamung (conditionText) der addons für die conditiontable fehlt auch müssen die conditition addons einfach sein. feste vorgaben für die bedingung scheint mir besser zu sein, als ein parameter. vielleicht anwendungsspezifische beschreibungen. jedenfalls sollten bm und fk gezieltes schalten ermöglichen können. insgesammt aber vielleicht eine obergrenze von 15-20 default templates, alles weitere ins wiki:

default (basic):
on_short
on_long
off_short
off_long
on-for-timer_short (mit parameter:onTime)
on-for-timer_long (mit parameter:onTime)
toggle_short
toggle_long
ignore_short
ignore_long

default (addons):
add_delayOn_short (mit parameter:onDelay)
add_delayOn_long (mit parameter:onDelay)
add_delayOff_short (mit parameter:offDelay)
add_delayOff_long (mit parameter:offDelay)
add_conditionText_short (mit parameter:???)
add_conditionText_long (mit parameter:???)

wiki (basic):
off-for-timer_short
off-for-timer_long
toggleToCnt_short
toggleToCnt_short


den zusätzlichen namenszusatz (_dim_) für dimmer templates würde ich an die vorletzte stelle verschieben.

on_dim_short
off_dim_long
pct_dim_short (mit parameter:level)


gruss frank

Zitat von: Pfriemler am 05 Januar 2020, 19:25:05
Einen Wunsch hätte ich noch: Templates kann ich anwenden ("set") und die Verknüpfung aufheben "unassign" (beides testweise mit autoOff_short auf self01 eines Steckdosenaktors probiert). Danach bleiben aber alle durch das Template gemachten Änderungen weiterhin aktiv. Ein Reset aller betreffenden Register wäre hilfreich.

am besten vor dem spielen config sichern.  ;)

aber mal ernsthaft:

wozu reset?
wenn es wirklich so viele unterschiedliche reset datensätze gibt, ist es doch einfacher das gewünschte verhalten neu zu setzen.
wenn man mal spielen will, könnte man auch vorher vom datensatz ein template aller register erstellen und nach dem spielen wieder drüberbügeln. dafür könnte ein button selectAll ganz nützlich sein.

ein manager interface zum handling von configs würde mir auch gefallen. sehe ich hier allerdings nicht.

gruss 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.

Zitat von: frank am 07 Januar 2020, 19:00:58
am besten vor dem spielen config sichern.  ;)
aber mal ernsthaft:
wozu reset?

Ja, das mit dem Sichern vor der Änderung ist wohl doch der einfachste Weg. Vielleicht wäre genau das direkt vor "Apply" ein gangbarer Weg.
Im Dialog ein "alte Registerkonfiguration sichern"-Häkchen (kann ja default off sein)? Wäre sowohl für templates als auch für Expertenmodus gleichermaßen nützlich.
Global ist vielleicht keine so gute Idee. saveConfig an sich ist ja schon unterstützt, muss man nur aufrufen, ggf. als Einzeldatei - kann man ja jetzt schon bei jedem Gerät in einen individuellen Dateinamen exportieren. Nur ... statt der dezeit verwendeten "entity" (Device-Namen) würde ich würde eine Datei mit der (unveränderlichen) HmID vorschlagen, da diese auch etwaige spätere Namensänderungen des Device überlebt - saveConfig und Co verwenden ja derzeit den entity-Namen, und serialNr ist zumindest bei Kanälen nicht mehr unique.
Wobei: Vielleicht sogar noch ein kleines Textfeld als comment dazu? Dann wird es aber schon gänzlich inkompatibel zum bisherigen Mechanismus.
Daraus könnte man eventuell auch einfach Backups zum Restore ziehen, Zeitpunkt des Backups ist ja schon hinterlegt.
Nun noch ein Vergleich von backup und Istzustand mit markierten Änderungen ... (ach, man wird ja wohl mal träumen dürfen...)

Wozu Reset? Um wieder ein definiertes Verhalten herzustellen, besonders nach der dritten oder vierten Änderung, bei der man sich vertan hat. Ich persönlich bin ja mehr der Freund detaillierter Einzeländerungen, die so wenig wie nötig "verstellen". Der Aufwand eines Geräteresets oder einer Erneuerung der Verknüpfung ist zumindest in der Experimentierphase ja überschaubar, zumal man ja auch da seine Änderungen gewöhnlich protokolliert. Aber weiß man das nach einem halben Jahr noch?
Hin und wieder werden Geräte bei mir auch anderen Verwendungen zugeführt (besonders Zwischenstecker). Die hätte ich dann gern "rückstandsfrei".
Ist alles sehr speziell, ich weiß. Es geht auch ohne. Oder aber, wenn ich vor der ersten Verpfriemlung ein Backup mit entsprechendem Kommentar anlege.

Zitat von: papa am 07 Januar 2020, 21:16:57
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.

Das würde ich ja vollstens unterschreiben. Schon die gemischte Groß-Klein-Schreibweise der Abkürzungen ist für einen Nicht-Register-Kenner überraschend (wennauch nach dem Kennenlernen reproduzierbar logisch).

Derzeit frage ich mich noch, ob die Unterscheidung in Long/Short bei den Templatenamen nicht auch noch zu umgehen wäre. Beim HMTemplate von Martin wird das ja auch erst beim Konfigurieren der Parameter festgelegt. Schwierig wird das allerdings, wenn man z.B. ein autoOff sowohl für short als auch für long anwendet. Die zugrundelegenden Manipulationen beschränken sich ja hier bspw. nicht nur auf die Laufzeit, sondern auch auf das Tastenverhalten (Nachtriggern, keine Ausschaltmöglichkeit). Im Grunde müsste man die Parameter doppelt listen und einen getrennten Haken für beide Varianten setzen. Das alles umgeht die derzeitige Trennung in der Liste ganz elegant ...

Zitat von: papa am 07 Januar 2020, 21:16:57
Beim Setzen eines Templates würde ich mir wünschen, die Register und die Werte optional einzublenden. Ich weiss gerne, was passiert :-)

auch das stünde auf meiner Wunschliste ...

Zitat von: papa am 07 Januar 2020, 21:16:57
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 (https://forum.fhem.de/index.php/topic,107125.0.html)

Zitat von: frank am 08 Januar 2020, 13:16:24
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".

Zitat von: frank am 08 Januar 2020, 13:16:24
hast du eventuell eine idee zu diesem problem? https://forum.fhem.de/index.php/topic,107125.0.html (https://forum.fhem.de/index.php/topic,107125.0.html)

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

Zitat von: papa am 08 Januar 2020, 13:54:34
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.

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.

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

moin,

im ersten post gibt es ein neues update.

- 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.


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

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?

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)

Zitat von: frank am 08 Januar 2020, 13:16:24
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 (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.

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.

Danke für den Hinweis :)

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

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

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 :)
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 :(

Zitatgive :[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:
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 :) ;D

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

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

Hallo Frank,

danke für die umfangreiche Erklärung :) und die Bestätigung: Ich habe eigentlich nichts verkehrt gemacht ;)
Ich habe es quasi sogar verstanden 😂

Zitatdie position (ganz, ganz weit rechts  :)) habe ich absichtlich so gewählt, da sie wahrscheinlich eher für "poweruser"

Wobei der normale User da derzeit fast verloren hat (auf Grund des Fehlers) Temporär Hinweis einblenden? Geht so was einfach im js ?

Aber: Ja! Die Position ist an sich schon logisch, ist mir auch gestern schon klar geworden. ;)

Na ich bin gespannt wie es weitergeht.

Gruß Otto

hallo martin.

1. ich habe gerade entdeckt, dass der befehl "set hminfo templateSet"  nicht wirklich nach der beschreibung in der commandRef funktioniert.

ZitattemplateSet <entity> <template> <peer:[long|short]> [<param1> ...]
sets a bunch of register accroding to a given template. Parameter may be added depending on the template setup.
templateSet will collect and accumulate all changes. Finally the results are written streamlined.
entity: peer is the source entity. Peer needs to be given if a peer behabior beeds to be copied
template: one of the programmed template
peer: [long|short]:if necessary a peer needs to be given. If no peer is used enter '0'. with a peer it should be given whether it is for long or short keypress
param: number and meaning of parameter depends on the given template
Example could be (templates not provided, just theoretical)

    set hm templateSet Licht1 staircase FB1:short 20
    set hm templateSet Licht1 staircase FB1:long 100

Restrictions:

    User must ensure to read configuration prior to execution.
    templateSet may not setup a complete register block but only a part if it. This is up to template design.

der befehlsabschnitt "<peer:[long|short]>" erwartet scheinbar "peer:both", wenn es sich um ein "normales" template für "short AND long" handelt, denn mit:

set hminfo templateSet SwitchUP01 genUP2 self01

erhalte ich den fehler: "give :[short|long|both] with peer, not self01 self01,". mit folgendem befehl scheint es zu funktioniere:

set hminfo templateSet SwitchUP01 genUP2 self01:both

wahrscheinlich ist nur die commandref falsch. allerdings könnte es auch ein fehler in hminfo sein, da der type=both für das template eigentlich überflüssig ist, weil es ja in hminfo bekannt sein sollte.

der befehlsteil "<peer:[long|short]>" existiert ebenfalls noch bei "set templateDel", "set templateDef fromMaster" und "get templateChk". das beispiel bei templateChk:

set hm templateChk -f RolloNord BlStopUpLg peerName # RolloNord peerName, long and short

lässt mich aber vermuten, das es eventuell doch ein fehler in hminfo ist.
für "basic"-templates mit peer=0 wird ja zb auch nur der peer angegeben.

vielleicht könntest du dich dazu mal äussern.


2. immer noch fehlende set tplSet_ befehle
ich habe hier https://forum.fhem.de/index.php/topic,107137.0.html (https://forum.fhem.de/index.php/topic,107137.0.html) neulich eine vermutung kund getan.
könntest du dir das mal anschauen?


gruss frank

moin otto.

im ersten post gibt es ein update.

rev 2004 25.02.2020
    fix: probleme mit templates vom typ "both"

moin,
neues update im 1. post.

    rev 2005 04.04.2020
        fix: probleme bei der erkennung von genutzten templates mit langen namen

moin,
für die vielen ungeduldigen user endlich wieder ein update im 1. post.  :)

rev 2006 29.05.2020
    new: template nutzung für single-channel-peers
    fix: some bugs

neues update im ersten post.

neu:
hm.js heisst nun HMdeviceTools.js.
wenn HMinfoTools.js HMdeviceTools.js entdeckt, integriert es dort die entsprechenden icons.
dadurch ist der code deutlich reduziert und die icons inklusive deren verhalten sind immer identisch mit HMinfoTools.

nicht vergessen:
im webif das "attr JavaScripts" anpassen, also hm.js ändern zu HMdeviceTools.js.
hm.js kann dann auch gelöscht werden.

update im ersten post.
fix für templatecheck.

Guten Morgen.

Ich habe hm.js durch HMdeviceTools.js ersetzt. Allerdings bleibt bei mir die Zeile "HMdeviceTools" überall leer.

Die Dateien sind in www so abgelegt:

-rwxrwxrwx  1 fhem dialout  85650 Nov 23 10:21 HMdeviceTools.js
-rwxrwxrwx  1 fhem dialout  62739 Nov 23 10:31 HMinfoTools.js


In WEB habe ich:

   JavaScripts codemirror/fhem_codemirror.js pgm2/HMdeviceTools.js

Und hmInfo sieht so aus:

Internals:
   CFGFN     
   FUUID      619cb92c-f33f-b425-1f09-916ade6ec86fcbec
   NAME       HMinfo
   NOTIFYDEV  global
   NR         1090
   NTFY_ORDER 49-HMinfo
   STATE      updated:2021-11-23 10:35:17
   TYPE       HMinfo
   Version    01
   READINGS:
     2018-01-07 13:32:01   CRIT__protocol  -
     2021-11-23 10:35:17   CRI__protocol   0
     2021-04-30 19:05:11   C_sumDefined    entities:75,device:25,channel:65,virtual:16
     2021-11-23 10:35:17   ERR_IODev       HMLAN1:19,myHmUART:5,
     2021-11-23 10:35:17   ERR__protocol   0
     2020-06-25 09:02:33   ERR__unreachable 0
     2021-11-23 10:35:17   ERR_battery     0
     2021-11-23 10:35:17   ERR_cfgState    PeerVerf:2,TempChk:2,
     2021-11-14 12:26:14   ERR_sabotageError on:1,
     2021-11-23 10:35:17   I_actTotal      alive:18,dead:0,unkn:2,off:0
     2017-02-20 20:41:21   I_autoReadPend  0
     2021-11-23 10:35:17   I_rssiMinLevel  59<:3 60>:3 80>:3 99>:0
     2021-11-13 17:41:14   I_sum_battery   ok:10,
     2021-11-23 10:35:17   I_sum_motor     stop:on:7,
     2021-11-14 12:26:14   I_sum_sabotageError off:3,on:1,
     2021-11-23 10:35:17   W__protocol     0
     2021-11-23 10:35:17   lastErrChange   updated:2021-11-23 10:35:17
   helper:
     autoUpdate 13500
     cfgChkResult configCheck done:-ret--ret- peer not verified. Check that peer is set on both sides-ret-    WZ_Hk0_WindowRec: p:virSEC-ret-    WZ_Hk1_WindowRec: p:virSEC-ret--ret- templist mismatch-ret-    WZ_Hk0_Clima: failed Entries:-ret-     WZ_Hk0_Clima: R_0_tempListSat mismatch 07:30 17.0 09:00 21.0 16:00 17.0 20:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-     WZ_Hk0_Clima: R_1_tempListSun mismatch 07:30 17.0 09:00 21.0 16:00 17.0 20:00 17.0 22:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-     WZ_Hk0_Clima: R_2_tempListMon mismatch 07:00 17.0 09:00 21.0 16:00 17.0 20:00 21.0 22:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-     WZ_Hk0_Clima: R_3_tempListTue mismatch 07:00 17.0 09:00 17.0 16:00 17.0 20:00 21.0 22:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-     WZ_Hk0_Clima: R_4_tempListWed mismatch 07:00 17.0 09:00 21.0 20:00 17.0 22:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-     WZ_Hk0_Clima: R_5_tempListThu mismatch 07:00 17.0 09:00 21.0 20:00 17.0 22:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-     WZ_Hk0_Clima: R_6_tempListFri mismatch 06:00 17.0 09:00 17.0 17:00 17.0 20:00 17.0 22:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-    WZ_Hk1_Clima: failed Entries:-ret-     WZ_Hk1_Clima: R_0_tempListSat mismatch 07:30 17.0 09:00 21.0 16:00 17.0 20:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-     WZ_Hk1_Clima: R_1_tempListSun mismatch 07:30 17.0 09:00 21.0 16:00 17.0 20:00 17.0 22:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-     WZ_Hk1_Clima: R_2_tempListMon mismatch 07:00 17.0 09:00 21.0 16:00 17.0 20:00 21.0 22:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-     WZ_Hk1_Clima: R_3_tempListTue mismatch 07:00 17.0 09:00 17.0 16:00 17.0 20:00 21.0 22:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-     WZ_Hk1_Clima: R_4_tempListWed mismatch 07:00 17.0 09:00 21.0 20:00 17.0 22:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-     WZ_Hk1_Clima: R_5_tempListThu mismatch 07:00 17.0 09:00 21.0 20:00 17.0 22:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-     WZ_Hk1_Clima: R_6_tempListFri mismatch 06:00 17.0 09:00 17.0 17:00 17.0 20:00 17.0 22:00 21.0 24:00 17.0 ne 14:00 17.0 16:00 17.0 19:00 21.0 21:30 21.0 24:00 17.0 ##-ret-
     weekplanListDef ./FHEM/tempList.cfg
     weekplanListDir ./FHEM/
     weekplanList:
       BD_Hk4_Clima
       BD_Regler_Climate
       WZ_Hk0_Clima
       WZ_Hk1_Clima
       Früh
       Tag
       Spät
       Nacht
       UrlaubUnterwegs
       UrlaubZuhause
   nb:
     cnt        2
Attributes:
   alias      HM Geräteinfos
   autoArchive 1
   autoLoadArchive 1_load
   autoUpdate 03:45
   configDir  ./FHEM
   group      Tools
   icon       icoTool
   room       085System
   sumERROR   battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed,IODev:ok,cfgState:ok
   sumStatus  battery,sabotageError,powerError,motor
   webCmd     protoEvents:rssi:peerXref:configCheck:models

Fhem habe ich neu gestartet...

Wo "steckt" der Fehler...?

ZitatWo "steckt" der Fehler...?

im attr JavaScripts fehlt HMinfoTools.js.
vermutlich so:
   JavaScripts codemirror/fhem_codemirror.js pgm2/HMdeviceTools.js pgm2/HMinfoTools.js

edit:

ZitatFhem habe ich neu gestartet...

das ist nicht nötig.
ein reload der webseite sollte reichen. im handy eventuell die app beenden und neu starten.

Dankeschön, manchmal sieht man den Wald vor lauter Bäumen nicht...

Jetzt versucht fhem immer einen Reconnect, wenn ich Hminfo aufrufe und der Status ist:"waiting for problems..."

Beim Aufruf eines HM-Gerätes kommt diese Meldung:
"HMinfoTools.js line 1116:
TypeError: vcculist is undefined"

HMinfo listet jetzt alles auf - das dauert wohl ein wenig... die Reconnects sind auch weg.

Das besteht leider immer noch:

ZitatBeim Aufruf eines HM-Gerätes kommt diese Meldung:
"HMinfoTools.js line 1116:
TypeError: vcculist is undefined"

ok, 3 probleme.

1. connection lost
welchen browser nutzt du?
hast du im webdevice attr longpoll=websocket gesetzt?
werden die reconnects beendet, wenn du die seite neu lädst?

2. "waiting for problems..."
ohne erkannte probleme ist der zustand normal.
probleme ermittelt hminfo immer über "set hminfo update". das kann man entweder immer mal wieder manuell auslösen, oder automatisch durchführen lassen => siehe HMinfoTools beschreibung => attr hminfo autoUpdate

3. probiere die neue HMinfoTools.js v2002

zu 1.: Problem hat sich erledigt (s.o.), websocket war gesetzt, Browser FF 94.0.2

zu 2.: zeigt jetzt alle Geräte an, autoUpdate auf 10 Minuten gesetzt

zu 3.: mache ich gleich...

Mit der 2002 funzt es...

Dankeschön für die schnelle Unterstützung.

prima, dass es nun tut.
dann warst du bisher der erste, der eine detailseite von einem device aufgerufen hat, das kein prefered io nutzt.
ein oder mehrere prefered io bei "stationären" devices zu setzen, ist übrigens sehr sinnvoll. zb wegen load verteilung.

Ok.
Dann werde ich das mal noch nachholen...

update im ersten post:
fix zur vermeidung von problemen mit unterschiedlichen fhem-styles.

Hallo Frank,

HMDevice-Tools spuckt meinem Layout etwas in die Suppe.

Bei der Injektion in die Device-Übersicht erhält das Header denselben data-name, wie der Internals (detail_Internals) und lässt sich somit nicht so ohne weiteres im css selektieren:


<div class="col_header pinHeader detail_Internals" data-name="detail_Internals">HMdeviceTools</div>


Weiterhin bringt die zugehörige Tabelle wohl eigene styles direkt an der table mit und wird so leider auch nicht meinem css entsprechend formatiert (durch die background-color passt der Rahmen nicht):


<table class="block wide internals" style="background-color: rgb(51, 51, 51);color: rgba(204, 204, 204, 0.8);">

s.a. Screenshot im Anhang!

Vielleicht kannst du das bei Gelegenheit ja anpassen?

gb#

ZitatHMDevice-Tools spuckt meinem Layout etwas in die Suppe.

teilweise auch beabsichtigt.  :)
background-color und schriftfarbe habe ich gesetzt.

du willst also den reiter (violett) und den rahmen (blau) der HMdeviceTools table gleich färben können. und zwar unabhängig von der internals table.
das blau vom rahmen hast du bereits gesetzt und ist richtig, oder?

schaue ich mir demnächst mal an benni.

Zitat von: frank am 04 Januar 2022, 22:19:44
du willst also den reiter (violett) und den rahmen (blau) der HMdeviceTools table gleich färben können. und zwar unabhängig von der internals table.

Das war der Plan, bzw. ist für die anderen Bereiche in der DeviceOverview bereits so umgesetzt
(s. https://forum.fhem.de/index.php/topic,125119.msg1197622.html#msg1197622)

Zitat von: frank am 04 Januar 2022, 22:19:44
schaue ich mir demnächst mal an benni.

Danke! Eilt nicht! :)

gb#

Zitat von: frank am 04 Januar 2022, 20:28:27
moin.

ab sofort können die neuesten updates von HMinfoTools.js und HMdeviceTools.js über fhem update bezogen werden.

updates direkt checken:

Code Auswählen Erweitern

update check https://raw.githubusercontent.com/frank962/fhem/main/autoupdate/controls_HMtools.txt
updates direkt downloaden:

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/frank962/fhem/main/autoupdate/controls_HMtools.txt


falls die updates automatisch mit dem normalen fhem update kommen sollen, muss das controls-file in fhem integriert werden:

Code Auswählen Erweitern

update add https://raw.githubusercontent.com/frank962/fhem/main/autoupdate/controls_HMtools.txt
zum checken, ob das controls-file integriert ist:

Code Auswählen Erweitern

update list
controls-file wieder auschecken, um automatische updates zu beenden:

Code Auswählen Erweitern

update delete https://raw.githubusercontent.com/frank962/fhem/main/autoupdate/controls_HMtools.txt


die ausgabe des fhem cmd "version" sollte nach heutigem update folgendes anzeigen:

Code Auswählen Erweitern

HMdeviceTools.js           1003 2022-01-04 16:24:18Z frank
HMinfoTools.js             2006 2022-01-04 17:29:19Z frank

hallo benni,

wenn ich ein "normales" dark f18 style nehme und unter additional css folgendes eingebe:
div#HMdeviceTools_toolsTable .col_header {
background-color: #652b65;
color: white;
}
.col_header[data-name="detail_Internals"] {
background-color: #3373a6;;
color: white;
}


erhalte ich 2 unterschiedliche farben

Hallo Frank,

vielen Dank fürs Nachschauen. Der Identifier der HMdeviceTools-Table ist mir doch glatt entgangen.

so ist dann bei mir auch der Rahmen sauber ohne Hintergrundfarbe:


div#HMdeviceTools_toolsTable .col_header {
background-color: #2b3867;
}

div#HMdeviceTools_toolsTable table.block.wide {
    border: solid 2px #2b3867;
    background-color:unset !important;
}


gb#

schön, das es doch noch funktioniert.

background-color:unset !important;
interesanter ansatz.

Zitat von: frank am 03 Januar 2020, 01:49:01
...
0.1. automatischen download über den fhem update mechanismus einrichten. ein paar beispiele für den fhem update cmd sind in diesem post zu finden: https://forum.fhem.de/index.phptopic,112825.msg1197938.html#msg1197938 (https://forum.fhem.de/index.phptopic,112825.msg1197938.html#msg1197938)
...

Hallo Frank
Hier fehlt ein /
//forum.fhem.de/index.php/topic,112825.msg1197938.html#msg1197938

Bei den HMinfoTools im ersten Post auch.

danke, repariert.

neues grosses update v1006 auf github.

nun gibt es endlich eine edit-funktion zum editieren von templates.
alles lässt sich ändern sogar der name.

einfach template aus der liste selektieren und edit button drücken.
nach den änderungen den save button drücken, um die änderungen zu übernehmen, logisch.
oder über cancel button das editieren verwerfen und beenden.

im prinzip wird das vorhandene template gelöscht und ein neues definiert.
zusätzlich werden vor dem löschen des alten templates automatisch alle assignments entfernt und nach dem erstellen des neuen templates alle assignments wieder automatisch gesetzt.

dann mal viel spass beim editieren.  :)

update v1008 auf github.

HMdeviceTools findet nun zu jedem selektierten template alle entities mit passendem registersatz.

entsprechend ist die edit funktion nun so angepasst, dass die assignments, die ein template vor dem editieren hatte, nun gecheckt werden, ob sie für das "neue" template noch passen.