HMINfo, intention, sinn und Zweck

[martinp876]

Hi,

Zum einen hat CUL_HM selbst keine Representation im Web-interface. Dennoch werden hier (wo sonst) warte-queues verwaltet. Also brauche ich eine Darstellungsebene, die nicht in CUL_HM liegen kann sondern darueber.
Ein weiterer Punkt war, dass man um HM ueberblicken zu koennen Tabellen und Datensammlungen braucht. Fuer ein halbwegs userfreundliches System sollte(muss) man zusammenfassungen anbiegen. Einige Teile von HM sind spezifisch - ergo muessen sie in einem HM-layer abgehandelt werden (CUL_HM ist ein HM-entity layer mit channels und devices). Dazu gehoeren Uebersichten wie protokoll-tabelle, RSSI, message-statistik,...
Ein weiterer wichtiger Punkt ist das Sammeln von Alarmen, das viele User von hand machen. Da es (fast) jeder braucht sollte es das System bereitstellen. Das Entwicklerforum hatte meinen Vorstoss, hier ein Handling einzufuehren verworfen, also gibt es dies jetzt HM spezifisch - mit User editierbaren defaults.
Das ist die Gruppe "info" mit der ich begonnen habe - und daher kommt der Name. "Alarming" ist der 2. Baustein.
ActionDetector waere auch hier gelandet, den hatte ich aber schon vorher gebaut. Eigentlich gehoert er in diesen Layer.

Im Laufe der Zeit habe ich dann angefangen HM-weite Kommandos zu addieren. Sichern von Register-readings, anstossen eine AutoreadReg, Loeschen von Statistiken,... alles fuer alle HM entities (oder man filter, das geht fast immer)

Eine weitere Gruppe Kommandos habe ich begonnen, die das Programmieren der Aktoren unterstuetzen soll. Nicht jeder User will alle Register verstehen muessen. Somit gibt es parametriesierbare Templates z.B. zum Einrichten eines "treppenhausschalters". Der/die user koenn(t)en templates addieren fuer haeufig genutzte Anwendungen und diese in einer Library zu Verfuegung stellen - will bisher keiner, ist nicht verstanden oder nicht gefunden... aber existiert.

Alle Kommandos sind als 1Zeiler mit
set hm help
sichtbar. Die Info ist kompakt und sollte hoffentlich reichen, um das Interesse zu wecken "koennte ich brauche"

Aktuell habe ich archConfig addiert, welches komplette Registersaetze nach dem Lesen/update archiviert (zeitverzoegert). Man kann diese Werte dann in die Readings zuruecklesen - vorteilhaft fuer config-only devices. Kann man zyglisch laufen lassen.

templisten verwaltung wie es die meisten (wohl nach einem Wiki eintrag?) per "programm" machen ist in meinen Augen ein notbehelf. Programm und Daten muessen getrennt sein. Eine Konfig-aenderung lade ich nicht per reload eines Programms nach... ok, man kann. Die Idee, auch hier templates zu machen ist nicht schlecht... und evtl garnicht schwierig.
Der TC-IT ist hier noch nicht eingebaut.

Die Liste der Detail ist laenger, so versuche ich alle config file in einen unterordner plazieren zu koennen - kann man (fuer HM) in HMInfo festlegen (attribut). Da gehen dann alle templisten, registerlisten,... hin

commandref sollte vollstaendig sein, help probieren.

HMInfo ist sicher nicht vollstaendig - ich hoffe hier klar gemacht zu haben, was es abdecken soll, einen Sammel,Kontroll,Info und Abstaraktionslayer fuer HM in FHEM

Anregungen gerne.
Wiki schreibe ich auch hier nicht... sorry
Gruss Martin

[jab]

Moin Martin,

klingt sehr sinnvoll! Ich nutze das mittlerweile auch öfters. Ich habe einen rudimentären Wiki Artikel geschrieben da ich jedes mal wieder Suche wie einzelne Dinge funktionieren: http://www.fhemwiki.de/wiki/Homematic_HMInfo

Außerdem habe ich noch einen kleinen Artikel zum HM Sniffen geschrieben da die Frage hier immer wieder aufkommt: http://www.fhemwiki.de/wiki/Homematic_Nachrichten_sniffen

Hoffe das stört dich nicht.


Gruß,
Jan

[martinp876]

Hoffe das stört dich nicht.

auf keinen Fall! Die wichtigsten Kommandos sind m.E.
       ."\n ---checks---"
           ."\n configCheck [<typeFilter>]                     # perform regCheck and regCheck"
       ."\n ---actions---"
           ."\n saveConfig [<typeFilter>] [<file>]             # stores peers and register with saveConfig"
           ."\n archConfig [-a] [<file>]                       # as saveConfig but only if data of entity is complete"

       ."\n ---infos---"
           ."\n update                                         # update HMindfo counts"
           ."\n register [<typeFilter>]                        # devicefilter parse devicename. Partial strings supported"
           ."\n peerXref [<typeFilter>]                        # peer cross-reference"
           ."\n models [<typeFilter>]                          # list of models incl native parameter"
           ."\n protoEvents [<typeFilter>] [short|long]        # protocol status - names can be filtered"
           ."\n rssi [<typeFilter>]                            # displays receive level of the HM devices"

       ."\n ---clear status---"
           ."\n clear [<typeFilter>] [Protocol|readings|msgStat|register|rssi]"

       ."\n ***footnote***"
           ."\n [<nameFilter>]   : only matiching names are processed - partial names are possible"
           ."\n [<modelsFilter>] : any match in the output are searched. "

       ."\n ======= typeFilter options: supress class of devices  ===="
           ."\n set <name> <cmd> [-dcasev] [-f <filter>] [params]"
           ."\n      entities according to list will be processed"
           ."\n      d - device   :include devices"
           ."\n      c - channels :include channels"
           ."\n      i - ignore   :include devices marked as ignore"
           ."\n      v - virtual  :supress fhem virtual"
           ."\n      p - physical :supress physical"
           ."\n      a - aktor    :supress actor"
           ."\n      s - sensor   :supress sensor"
           ."\n      e - empty    :include results even if requested fields are empty"
           ."\n "
           ."\n     -f - filter   :regexp to filter entity names "
           ."\n "


Gruss Martin

[betateilchen]

Hallo Martin,

soll ich Dir sagen, was mich bei HMinfo bisher immer völlig verwirrt hat und für mich deshalb immer absolut unlogisch war? Dass man im HMinfo immer mit SET arbeitet anstatt mit GET. Eigentlich werden ja Daten GELESEN und nicht geschrieben...

Die in der Commandref dazu angeführte Begründung, mit SET könne man leichter im Webfrontend arbeiten, ist ja nun schon lange nicht mehr gültig, das kann man nämlich mit GET genauso einfach. Vielleicht würde eine diesbezügliche Änderung bzw. Aufteilung der Kommandos das logische Verständnis auch bei anderen Nutzern vereinfachen.

Viele Grüße
Udo

[martinp876]

Hi Udo,

gerne - habe ich bisher nicht gemacht, da Kommandos verschieben die User immer vor Raetsel stellt, wo es nun hin ist. Aber ich geben dir recht - und bei HMInfo kann an es wohl verschmerzen...
Also Obacht in der naechsten Zeit an dieser Stelle

Gruss Martin

[Samsi]

Hallo martin,

ist nicht verstanden oder nicht gefunden..

Trifft beides zu. Vieles findet man nicht so einfach, das mit den Templates z.B. finde ich eine sehr gute Idee. Hatte ich bisher nicht gefunden. Die sind meiner Meinung nach auch an der falschen stelle. Ich glaube auch nicht, das ich sie so verwenden werde, weil ich einfach nicht genau weiss wofür die sind und ich Sorge hätte mir meine Register so sehr zu verstellen, das ich am ende nicht mehr weis was ich gemacht habe.

Warum an der falschen Stelle:

Ich bekomme eine Liste aller Templates:
BlStopDnLg       params:                         Info:Blind: stop drive on any key - for long drive down
BlStopDnSh       params:                         Info:Blind: stop drive on any key - for short drive down
BlStopUpLg       params:                         Info:Blind: stop drive on any key - for long drive up
BlStopUpSh       params:                         Info:Blind: stop drive on
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
SwOnCond         params:level cond               Info:switch:execute only if condition [geLo|ltLo] level is below limit
autoOff          params:time                     Info:staircase - auto off after <time>, extend time with each trigger
motionOnDim      params:ontime brightness        Info:Dimmer:on for time if MDIR-brightness below level
motionOnSw       params:ontime brightness        Info:Switch:on for time if MDIR-brightness below level

Ich wäre ich mir nicht sicher auf Welches Devices ich das Template anwenden müsste, z.B. bei motionOnSw  auf den MDIR oder den dazu gehörigen Aktor (ok im grunde immer auf den peer im Aktor, aber das MDIR verwirrt mich jetzt hier in der Beschreibung). Oder teilweise verstehe ich das template gar nicht: " Info:Blind: stop drive on any key - for long drive down"  das sagt mir leider überhaupt nichts. Vermutlich für irgend ein Device das ich nicht kenne und auch nicht besitze.

Deshalb denke ich, die templates müssten beim Peer selbst stehen. Bei der HM Software ist das auch so gelöst. Man sucht ein Template für den Peer (oder internen Peer) aus. Z.B. Treppenhauslicht, Blinklicht, Einschaltverzögerung, Ein, Ein-Aus etc.
Man sieht also nur die Templates die für das Peer sinnvoll sind. Wem das nicht reicht stellt auf Experte um und ändert die Register manuell.

Gleichzeitig würde es auch das eigene Entwickeln von Templates einfacher machen, wenn man einfach seine Register einstellt, bis es einem gefällt und es dann eine art "save register as template" gäbe. Das wäre auch intuitiver und Anfänger würden es schneller finden. Templates erscheinen dann nur dort wo sie sinnvoll sind (also Tür Öffnen nur bei der Keymatic und Treppenhauslicht bei einem Lichtschalter).

Was die ganze Sache auch sehr unübersichtlich macht, ist die Anzeige, wie Register angezeigt werden. Momentan eine ellenlange Liste:

R-keySchlafzimmer_Btn_03-shCtOff
....
Übersichtlicher wäre, wenn man nur sehen würde:

+keySchlafzimmer
+keyWohnzimmer
Und dann auf ein Klick auf das Plus und die Register werden ausgeklappt (ohne das da jedess mal R-keySchlafzimmer davor steht) und dann wird die nächste Ebene angezeigt:

- keySchlafzimmer
   + Btn_03
   + Btn_02
...



Und hier  verstehe ich teilweise wirklich nicht was es ist oder wie es mir hilft:

configCheck [<typeFilter>]                     # perform regCheck and regCheck
Sagt mir überhaupt nichts

regCheck [<typeFilter>]                        # find incomplete or inconsistant register readings
Verstehe ich nicht, weil ich nicht weiss was 'nicht komplette' register readings sein sollen? Was kann an einem Register nicht komplett sein?

peerCheck [<typeFilter>]                       # find incomplete or inconsistant peer lists
DITO

saveConfig [<typeFilter>] [<file>]             # stores peers and register with saveConfig
Hängt das mit dem saveConfig im WebFrontend zusammen? Wo werden die hin gespeichert wenn ich <File> nicht angebe? Zerschieße ich mir dann ein bestehendes File? Und kann ich damit etwas anfangen, wenn ich die peers in eine Datei schreibe? Ich seh da nicht den nutzen (vielleicht weil ich es nicht verstehe, vielleicht aber weil es noch nie vermisst habe?)

archConfig [-a] [<file>]                       # as saveConfig but only if data of entity is complete
purgeConfig [<file>]                           # purge content of saved configfile
Lösche ich damit den Inhalt und habe dann ein leeres configFile?

loadConfig [<typeFilter>] <file>               # restores register and peer readings if missing
Ok, hier kann ich das wieder laden. Aber macht es nicht mehr sinn, fehlende Register von einzelnen devices mit getConfig neu zu laden?

autoReadReg [<typeFilter>]                     # trigger update readings if attr autoReadReg is set
Das hab ich auf anhieb verstanden

tempList [<typeFilter>][save|restore|verify][<filename>]# handle tempList of thermostat devices
Das ist auch einfach

---infos---
update                                         # update HMindfo counts
Sagte mir nichts, hab ich mal ausprobiert, ergebnis:
ERR__protoNames  Steckdose1,licht_KellerFlur
ERR_names PIR_1OG,sTuer
CRIT__protocol ErrIoAttack:1
Leider sagt mir das Ergebnis nichts. ERR deutet auf einen Fehler hin, aber die Geräte arbeiten einwandfrei.


Aber: Das alles soll kein 'gemecker' sein, sondern nur aufzeigen womit ich hier und da Schwierigkeiten habe (und vielleicht auch andere) und ich hoffe Dir damit zu helfen das Du weniger von Anfängerfragen aufgehalten wirst.
Die HM Software ist was die Register-Configuration angeht für mich übersichtlicher und deshalb intuitiver zu bedienen (so das sich sie zum peeren und Register einstellen gerne noch verwende, gerade bei neuen Geräten die man noch nicht so gut kennt). Auch weil vieles (außer die Experten Register) deutlicher beschrieben (also entweder eine Erklärung dabei oder nicht ganz so abgekürzt) ist.
Ich komme mit FHEM an sich gut zurecht  (deshalb danke an dieser Stelle an Dch und alle die daran so viel Zeit aufwenden) , aber man muss halt leider viel mehr 'suchen' (und fragen) bis man etwas versteht oder findet. Und Funktionen die in dem Dropdown beim beim Device sind mit dem man etwas machen möchte, findet man halt leichter. So etwas wie templates hätte ich jetzt auch nicht woanders vermutet.


Grüße

[martinp876]

Hallo samsi,

Die sind meiner Meinung nach auch an der falschen stelle.

verstehe ich nicht

...und ich Sorge hätte mir meine Register so sehr zu verstellen, ....

ok - aber das wissen viele auch so nicht. Mein Rat (nicht nur hier) zu diesem Thema: Vorher sauber register lesen, ein saveConfig machen. Danach kannst du immer wieder auf den gesicherten Stand zurueck. Reset ist auch eine Option.
uebrigens sagt dir

set hm templateList BlStopDnLg       

was geaendert werden soll. Analog dem list.


Warum an der falschen Stelle:

Ich bekomme eine Liste aller Templates:
BlStopDnLg       params:                         Info:Blind: stop drive on any key - for long drive down
BlStopDnSh       params:                         Info:Blind: stop drive on any key - for short drive down
BlStopUpLg       params:                         Info:Blind: stop drive on any key - for long drive up
BlStopUpSh       params:                         Info:Blind: stop drive on
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
SwOnCond         params:level cond               Info:switch:execute only if condition [geLo|ltLo] level is below limit
autoOff          params:time                     Info:staircase - auto off after <time>, extend time with each trigger
motionOnDim      params:ontime brightness        Info:Dimmer:on for time if MDIR-brightness below level
motionOnSw       params:ontime brightness        Info:Switch:on for time if MDIR-brightness below level

Ich wäre ich mir nicht sicher auf Welches Devices ich das Template anwenden müsste

klar, die Beschreibung ist kurz (einzeiler) und somit begrenzt. Gedacht waren die vorgebauten Templates als erste Ideen.
Eine laengere Beschreibung wuerde in ein tutorial und in eine Katalog gehoeren.

ok im grunde immer auf den peer im Aktor, aber das MDIR verwirrt mich jetzt hier in der Beschreibung).

hm - schlechte Beschreibung. Der Unterschied ist eben der mitgelieferte Level.
=> hier ein Aufruf: Sollte einer bessere, eingaenglichere, genauere Beschreidungen haben ersetze ich gerne den Text. Gilt auch fuer Register und sonstigen...  . Vorgabe: einzeiler.

Info:Blind: stop drive on any key - for long drive down

hm - alles kann ich nicht hier erklaeren. Die Beschreibung ist englisch - blind ist das Rollo (ggf woerterbuch). Viel genauer kann ich blind nicht beschreiben. es geht um das Stoppen bei naechsten Tastendruck

Deshalb denke ich, die templates müssten beim Peer selbst stehen.

ich sehe deinen Gedanke - verstehe ihm auch. Dennoch wollte ich CUL_HM nicht ueberfrachten - sehe ich immer noch als den roh-level. Daher plane ich dies bis auf weiteres nicht. HMInfo ist der naechste Abstraktionslevel. Bisher habe ich den Aufwand vermieden, templates exact fuer devices freizuschalten. Das macht das erstellen fuer User m.e. noch deutlich komplexer...
Vielleicht muss ich es noch einmal ueberdenken.

Man sieht also nur die Templates die für das Peer sinnvoll sind. Wem das nicht reicht stellt auf Experte um und ändert die Register manuell.

Dieser Level waere eine Umkehr der aktuellen zustaende - wuerde jede Menge aenderungen nach sich ziehen. Die HM-SW setzt nicht nur das template sondern stellt es auch dar (rueckewaertsrichtung). Ein Umschalten dieser Qualitaet ist sicher schoen aber sehr umfangreich. Wenn dann muss es auf den HMInfo level, CUL_HM ist der programming expert level. Und in HMInfo ist eine Entity Darstellung nicht vorhanden. Des weiteren habe ich schon jetzt Bedenken wegen der Performance - perl ist eben doch langsam...

Gleichzeitig würde es auch das eigene Entwickeln von Templates einfacher machen, wenn man einfach seine Register einstellt, bis es einem gefällt und es dann eine art "save register as template" gäbe.

gibt es doch. Wenn du eine wunscheinstellung hast, speichere sie

Code Auswählen Erweitern

set hm saveConfig <myTempalteFile>
set hm saveConfig -f ^meinDevice$ <myTempalteFile>
im file steht dann ein code um es wieder einzulesen - kann man direkt ausfuehren

oder direkt kopieren

Code Auswählen Erweitern

set hm cpRegs Licht1:peer7 Licht3:peer2

Das wäre auch intuitiver und Anfänger würden es schneller finden.

ich denke da fehlt einfach eine wiki-anleitung

Was die ganze Sache auch sehr unübersichtlich macht, ist die Anzeige, wie Register angezeigt werden. Momentan eine ellenlange Liste:

ja

Übersichtlicher wäre, wenn man nur sehen würde:

+keySchlafzimmer
+keyWohnzimmer

da sehe ich nicht, dass das web-frontend dies zulaesst. da kann ich nicht machen.

Und dann auf ein Klick auf das Plus und die Register werden ausgeklappt

cool - siehe oben

Und hier  verstehe ich teilweise wirklich nicht was es ist oder wie es mir hilft:
configCheck [<typeFilter>]                     # perform regCheck and regCheck
Sagt mir überhaupt nichts

der kurztext ist der kurztext. ersetzt nicht das kommadnref - und schon garnicht ein tutorial,wiki oder best-current-practice(von denen habe ich bisher nur seeehr wenig gesehen!) Die Schreiben ich auch nicht alle

regCheck [<typeFilter>]                        # find incomplete or inconsistant register readings
Verstehe ich nicht, weil ich nicht weiss was 'nicht komplette' register readings sein sollen? Was kann an einem Register nicht komplett sein?

ist in configCheck enthalten. Die Uebertragung von Device koennte unterbrochen worden sein, liste nicht komplett vorhanden. Schon einmal das Einsteigerdoc gelesen?

saveConfig [<typeFilter>] [<file>]             # stores peers and register with saveConfig
Hängt das mit dem saveConfig im WebFrontend zusammen?

klar - commandref lesen ist Pflicht vor dem Fragen.

Wo werden die hin gespeichert wenn ich <File> nicht angebe?

defaultfile

Zerschieße ich mir dann ein bestehendes File?

kumulative speicherung

Und kann ich damit etwas anfangen, wenn ich die peers in eine Datei schreibe?

kann man ausfuehren

Ich seh da nicht den nutzen (vielleicht weil ich es nicht verstehe, vielleicht aber weil es noch nie vermisst habe?)

ich denke ersteres. Immerhin hattest du oben Angst, deine Config zu zerscheissen. Das ist die Loesung dazu. Wenn du ein device austauschst (HW-defekt) musst du alles neu programmieren - oder aber die alte Konfig einspielen. Machst du am PC sicherheitskopien? Wozu?

archConfig [-a] [<file>]                       # as saveConfig but only if data of entity is complete
purgeConfig [<file>]                           # purge content of saved configfile
Lösche ich damit den Inhalt und habe dann ein leeres configFile?

verstehe ich nicht - ist die Beschreinung sooo schlecht?

loadConfig [<typeFilter>] <file>               # restores register and peer readings if missing
Ok, hier kann ich das wieder laden. Aber macht es nicht mehr sinn, fehlende Register von einzelnen devices mit getConfig neu zu laden?

Begrenzt.
Fall 1: Config devices (meine RC12 ist geradezu einfach, der eingebaute Wandschalter schon schlechter). Ich habe diese Programmiert und die Register gelesen. Nach einigen restarts werden die Register nicht mehr in FHEM sichtbar sein, da Readings nicht stabil gespeichert werden. Um an das Config zu kommen muss ich anlernen druecken - den Wand-taster sogar ausbauen. Oder ich lade mit eine known-good-config aus dem File bei jeden neustart. Again: Siehe hinweis im Comandref - der ist ernst zu nehmen.
Fall 2: User, die kein automatisches Lesen habe wollen koennen dies ebenfalls nutzen - reduziert die messagelast  . Geschmackssache, nicht mein Fall, aber moeglich.

tempList [<typeFilter>][save|restore|verify][<filename>]# handle tempList of thermostat devices
Das ist auch einfach

nun, deshalb erweitere ich es . siehe tempListTmpl zum verwalten verschiedener Wochenprogramme

update                                         # update HMindfo counts
Sagte mir nichts, hab ich mal ausprobiert, ergebnis:
ERR__protoNames  Steckdose1,licht_KellerFlur
ERR_names PIR_1OG,sTuer
CRIT__protocol ErrIoAttack:1
Leider sagt mir das Ergebnis nichts. ERR deutet auf einen Fehler hin, aber die Geräte arbeiten einwandfrei.

das war eigentlich das Herzsteuck von HMInfo. Es liefert (oder soll zumindest) ein alarm-interface. In deinen Fall sind
protokoll fehler fuer Steckdose1,licht_KellerFlur aufgetreten. Koennte sein, dass etwas nicht uebertragen wurde. Solltest du nachsehen
Fehler gemaess dem Filter sind fuer PIR_1OG,sTuer. Dass heisst Readings, die gemaess dem HMInfo attribut sumERROR gefiltere werden sind eingetreten. Koennte die Batterie sein. Das Attribut hat defaults, kannst du aber anpassen.
CRIT__protocol ErrIoAttack: nun, es hat ein Zugriffsversuch auf dein Device von einer unzulaessigen?unbekannten Zentrale stattgefunden.

Die Readings sind so ausgelegt, dass du zum fraglichen entity hin'clicken' kannst

Aber: Das alles soll kein 'gemecker' sein,

habe ich schon verstanden.

Die HM Software ist was die Register-Configuration angeht für mich übersichtlicher

ich denke auch nicht, das HM frontend-leven zu toppen - wenn das dein Weg ist, wird es dein Weg bleiben. In FHEM ist HM nur ein kleiner Teil.
Gruss Martin

[jab]

Moin,

ich habe das Wiki mal etwas weiter gepflegt: http://www.fhemwiki.de/wiki/Homematic_HMInfo. Heute ist es schön sonnig also gebt euch alle einen Ruck und fügt ein paar weitere Details eures Wissens ein. Dann haben wir ganz schnell eine tolle Dokumentation .


Gruß,
Jan

[ph1959de]

Ich habe mal ein paar Strukturierungsvorschläge in den Wiki-Artikel eingefügt. Ich hoffe, es wird so etwas übersichtlicher (und ich mag sowas immer gern zu Beginn machen, damit der Überarbeitungsaufwand nachher nicht zu groß wird).

Gruß, Peter

[Samsi]

Hallo Martin,

ich habe mal cpRegs ausprobiert aber ich bekomme  "sourcepeer not in peerlist"

set hm cpRegs  licht_kellerFlur_Sw_02:self02 licht_kellerFlur_Sw_02:self01

aber die peers existieren:

NAME licht_kellerFlur_Sw_02
device licht_KellerFlur
peerList self01,self02

Wenn ich einen meiner älteren LC-Sw1PBU-FM als SOURCE nehme, das noch als Device ohne Channels in FHEM definiert ist, kommt die Fehlermeldung nicht (dafür aber dann destpeer not in peerlist).

Grüße

[martinp876]

Hi Samsi

probier V4932
Gruss Martin

[JoeALLb]

Hallo Martin,
Frage: Wie kann ich die Templatenamen der Heizungs-Templates neu einlesen?
Ich erweitere diese Datei direkt auf Systemebene, in und setze in fhem beim Thermostat dann den Eintrag, welcher gilt.
Leider aktualisieren sich die Einträge der Combobox, die mir die vorhandenen Templates anzeigt, nicht.
Gibt es dafür eine Lösung, die ich gerade übersehe?

[martinp876]

Muss i h mal prüfen.
Du kannst in jedem Fall in hminfo temptempl einen Status anfordern. Hier wird neu gelesen.

Dann ein Update auf der webpage des RT.
Das filewrite bekomme ich nicht mit - mal sehen, vielleicht gibt es einen trigger den ich nutzen kann.

[JoeALLb]

Danke!
ein

Code Auswählen Erweitern

hminfo temptempl reread
könnte ich absetzen.

Aktuell befehle ich mir mit

Code Auswählen Erweitern

attr hm configTempFile FHEM/XXX.cfg
schade ist halt, dass die Anwender wissen müssen, dass sich der Inhalt geändert hat und die Seite neu laden müssen.
Am Handy mit Cache funktioniert das nicht immer.

Nicht dringend, aber eine Info über Longpoll wäre wünschenswert, ode rhabe ich da einen Denkfehler??!?