Suche (Alpha-)Tester für meinen FHEManager

[koldomon]

Hallo zusammen,

ich hab mir in VB.NET ein kleines Windows-Tool geschrieben das mir verschiedene Aufgaben in FHEM erleichter. Ich würde das gerne als Open-Source veröffentlichen, möchte aber nicht mit einer ungetesteten Version rausgehen. Daher würde ich ein paar Freiwillige suchen, die das Tool auf Herz und Nieren Testen, Verbesserungsvorschläge einbringen und mir Feedback geben 

Voraussetzung für die Tester: Windows-PC (7,8,10), MSExcel (ab2012), 7Zip, VB.NET lesen können, Excel-VBA lesen und schreiben)

Kurz, was das Tools ist und was es kann

3 Module

1. Modul: Cmd-line Interface
laden der fhem.cfg, sortieren, aufräumen und wieder speichern
backup/archivieren der *.log dateien (es wird der letzte monat im Log belassen, die alten einträge additiv in ein Backupfile geschrieben)
....tbd 
2. Modul: COM-Interface
Ich hab ne Exceltabelle, in die ich meine Devices eintragen lasse. Benutze ich hauptsächlich, damit die Attribute einheitlich werden usw. Excel-Tabelle gibt's zum testen dazu.
3. Modul: FHEMTemplates
Extrahieren eines Templates aus einem vorhandenen Device,
Anwenden von Templates auf eine Gruppe von Devices.

erklärung zu den Templates: ich persönlich schaffe es nicht, 3 Devices mit allen anhängigen "funktionen" (sprich DOIF, notify....) gleich anzulegen. entweder vergesse ich Attribute, oder beim Copy&Paste aus dem Text-Editor passieren fehler, ich ordne die falschen Devices zu......also Human-Error-At-A-Glance. Deshalb (m)ein Template-System. Das Template ist eine XML-Datei (ja, Schema gibt's dazu) wo ich mit Textersetzungen arbeiten kann. Ich tue mir grad schwer das mit Worten zu verdeutlichen - daher ein Beispiel:
<ObjectTemplate FHEMType="DOIF">
          <Name>
            <FormatString>{0}_Timer</FormatString>
            <Values>
              <KeyValueObject Key="{0}">
                <ReferenceObject>
                  <ObjectSpecifier>TemplateFHEMObj</ObjectSpecifier>
                  <KeyValueObject Key="Attributes">
                    <KeyValueObject Key="room">
                      <StringObject>
                        <Value>1</Value>
                      </StringObject>
                    </KeyValueObject>
                  </KeyValueObject>
                </ReferenceObject>
              </KeyValueObject>
          </Name>
</ObjectTemplate>
was hier exemplarisch für den Namen des neuen FHEM "DOIF" passiert: es wird ein "FormatString" (String.Format - für die Kenner) (<FormatString>) erzeugt, das die Ersetzungen (<Values><KeyValueObject Key="{0}">) aus dem Objekt (<ReferenceObject>) holt, auf das es angewendet wird (<ObjectSpecifier>TemplateFHEMObj</ObjectSpecifier>). Beim füllen der Text wird aus dem ReferenceObject die Property "Attributes" (FHEMObj-Eigenschaft: intern eine Hashtabel) nach dem Schlüssel "room" durchsucht (was eine List(Of String) liefert) und daraus den 2ten Eintrag (Index 1) zurückliefert. Bei mir wäre das Attribut "room" z.B. "02_OG,02_OG_Wohn". Das Ergebniss des Namens aus dem ObjectTempalte wäre demnach "02_OG_Wohn_Timer".

Ich hoffe hier 3-4 Leute zu finden (wenn möglich mit einer umfangreichen FHEM-Installation) die mir vor allem beim Testen helfen, da ich natürlich nicht alle möglichen Devices hier bei mir habe und ich das Tool natürlich in meiner "Betriebsblindheit" entwickelt habe. Ziel soll "Open-Source" werden, da ich denke, das Tool kann uns allen nützlich sein. Daher sollte es auch in der breiten Masse funktionieren - und da kommt Ihr in's Spiel.

Bei interesse bitte eine Nachricht hinterlassen.....ich schreib solange an der Doku weiter 

cu markus

[koldomon]

Hier mal 2 Dateien, die das Ausmaß der Templates verdeutlichen soll:

FHEMGenerateObjectTemplateCreateCommand.xml - automatisch generiert von einem meiner Geräte. Der Aufruf im Code sieht ca so aus: CreateTemplate(%TemlateName%, %VORHANDENER_DOIF%, %HEIZKOERPERVENTIL_1%)

An dem DOIF hängen bei mir noch ein FileLog, ein Notify (mit FileLog) und in der Definition des DOIF verweise ich auf verschieden dummy Devices. Das wird automatisch erkannt und in das Template mit eingebunden.

FHEMGenerateObjectTemplateCreateCommand.cfg - das ist die Ausgabe, wenn das Template auf %HEIZKOERPERVENTIL_2% angewendet wird. Die hübsche Ausgabe ist übrigens "Feature" von meinem Tool 

P.S. Die Dateien stammen aus dem UnitTest. Das Template wurde automatisch generiert und sofort auf ein neues Objekt angewendet. Daher sieht "room" so "unrealistisch" aus. Es ist aber einfacher das Template auszumisten, als von vorne selbst zu schreiben 

[KernSani]

Hi Markus,

Ich will dir deine Begeisterung nicht nehmen, aber vieles was ich hier lese, halte ich für unnötig (weil FHEM das von sich aus schon kann), oder sogar gefährlich (fhem.cfg sortieren und aufräumen-der Sinn ist mir unklar, klingt aber böse). Logfiles archivieren, es gibt doch Monatslogs, template-System - es gibt z.B. Den template-Befehl, raw Definition usw... Ich kann das gerne später am Rechner nochmal ausführlich darlegen...
Grüße
Oli


Kurz, weil mobil...

[koldomon]

Hallo Oli,
keine Angst, Begeisterung nimmst du mir nicht. Das Tool ist ja entstanden, weil ich das in FHEM eben nicht so gefunden habe. Gerne erkläre ich das auch Detailiert.

MonatsLogs: ok, hast am 2. 2. mal deine SVG-Plots der letzen 7 Tage angesehen....vielleicht ist das ja mittlerweile anders, damals hab ich eben nur noch 2 Tage gesehen, der Rest war im vorherigen Log, was der SVG nicht angezeigt hat

Generell. Das Tool hab ich angefangen zu schreiben, ca 2014 

fhem.cfg aufräumen...gefährlich - ja, sogar sehr gefährlich. Deshalb mach das Tool ein Backup vorher. Mein Anwendungsfall war folgender: nach 2 Jahren FHEM, ausbau der Heimautomatisierung hab ich in der cfg nix mehr gefunden, alles war wild sortiert. Was mein Tool macht, wenn ein Device ein Logfile hat, dann schreib das direkt unter das Device, dito mit dem SVG. Dann werden die Devices nach Typ zusammengefasst. Alle notify als Block usw. Bei mir macht das keine Probleme und ich kann auch Kommentare hinterlegen. siehe das Beispielfile. Die Regeln zum aufbau der fhem.cfg werden beachtet.

Template-System. Es geht mir um folgenden Anwendungsfall, den ich tatsächlich vor 4 Wochen hatte. Den ersten Rolladenantrieb verbaut. Also ein "DUOFERN"-Device, LogFile dazu (1. Block). Dann ein "DOIF" (+LogFile) zur Steuerung und ein "notify"(+LogFile) für das Ansprechen des Devices (2.Block). Das DOIF ist abhängig von ein paar Dummies, die Teilweise "Haus"-Scope haben und teilweise nur "Stockwerk"-Scope. Soviel zum ersten Rolladenantrieb, den ich mir Testweise besorgt hab.
Als ich dann angefangen habe das ganze Haus damit auszurüsten hatte ich plötzlich 12 neue Devices und musst für jedes den 2ten Block individuell bauen. Und genau da setzt mein Template an. In meinem Template kann ich die Variablen Teile im Notify oder DOIF beim generieren durch die Daten (Name, Definition, Attribute) des (z.B.) neuen Devices ersetzen lassen. Dadurch sehen die "gleichen" Devices tatsächlich gleich aus (wie oft vergess ich ein ; in einem Notify) und es wird alles auf einmal generiert. Das generieren der Devices über ein Template ist nicht life. Es kann die "Live-Cfg" verwendet werden (da passiert ja das autocreate), die Texte, die unten aus dem Template rausfallen, landen aber nicht auf dem FHEM. Die sind zur Nachkontrolle und manuellen Übernahme nach FHEM gedacht. Ich nehme den generierten Text und füge den per C&P in telnet ein - da bin ich gerne vorsichtig.

Hab mir grad nochmal das "template" von FHEM angesehen. Ja das ist gut, mein Lösung geht aber noch ne Ecke weiter, da ich nur noch ein neues Device angeben muss und nicht alle Parameter übergeben muss. Das was das "template" macht, hab ich vorher in Excel gemacht, daher auch das COM-Interface, hab ich immer noch zu viele manuelle Fehler reingeschrieben. 

weitere Fragen bitte.....

[KernSani]

MonatsLogs: ok, hast am 2. 2. mal deine SVG-Plots der letzen 7 Tage angesehen....vielleicht ist das ja mittlerweile anders, damals hab ich eben nur noch 2 Tage gesehen, der Rest war im vorherigen Log, was der SVG nicht angezeigt hat

Ich verwende schon sehr lange DBLog, da stellt sich dieses Problem nicht, aber ich bin mir ziemlich sicher, dass ich dieses Problem auch vor DBLog nicht hatte...

Generell. Das Tool hab ich angefangen zu schreiben, ca 2014 

Das erklärt einiges. FHEM hat sich seitdem ja auch ein bisschen weiter entwickelt.

fhem.cfg aufräumen...gefährlich - ja, sogar sehr gefährlich. Deshalb mach das Tool ein Backup vorher. Mein Anwendungsfall war folgender: nach 2 Jahren FHEM, ausbau der Heimautomatisierung hab ich in der cfg nix mehr gefunden, alles war wild sortiert. Was mein Tool macht, wenn ein Device ein Logfile hat, dann schreib das direkt unter das Device, dito mit dem SVG. Dann werden die Devices nach Typ zusammengefasst. Alle notify als Block usw. Bei mir macht das keine Probleme und ich kann auch Kommentare hinterlegen. siehe das Beispielfile. Die Regeln zum aufbau der fhem.cfg werden beachtet.

Dass das editieren (oder auch nur das Ansehen) der fhem.cfg bis auf ganz wenige Ausnahmefälle (und auch über die kann man debattieren) weder sinnvoll noch notwendig ist, wurde hier schon 100mal diskutiert.

Hab mir grad nochmal das "template" von FHEM angesehen. Ja das ist gut, mein Lösung geht aber noch ne Ecke weiter, da ich nur noch ein neues Device angeben muss und nicht alle Parameter übergeben muss. Das was das "template" macht, hab ich vorher in Excel gemacht, daher auch das COM-Interface, hab ich immer noch zu viele manuelle Fehler reingeschrieben. 

Dem widerspreche ich jetzt mal nicht, dein Template-System mag mächtiger sein, als der template-Befehl. Ich persönlich habe mich auch wegen meiner Rollläden mit dem template Befehl beschäftigt, das war aber auch das einzige Mal, wo ich das ansatzweise gebrauchen konnte. Grundsätzlich würde ich aber davon ausgehen, dass man etwas falsch macht, wenn man für 12 Devices 12 gleichartige Notifies anlegt (geht das nicht auch mit einem notify?) Aber für ein ausgereiftes Templatesystem gibt es bestimmt an der ein oder anderen Stelle Anwendungsfälle. Die meisten "Massenoperation" lassen sich meiner Erfahrung nach auch über FHEM Bordmittel (copy, raw-definition etc...) und natürlich die korrekte Nutzung von Namenskoventionen und Devspec effizient lösen.

Das hier:

2. Modul: COM-Interface
Ich hab ne Exceltabelle, in die ich meine Devices eintragen lasse. Benutze ich hauptsächlich, damit die Attribute einheitlich werden usw. Excel-Tabelle gibt's zum testen dazu. 

verstehe ich noch nicht... Um Attribute einheitlich zu machen verwende ich i.d.R. attr <devspec> <Attributname> <Attributwert>

habe ich übrigens noch nicht verstanden...

[koldomon]

Hallo Oli

Ich verwende schon sehr lange DBLog, da stellt sich dieses Problem nicht

Richtig. Ich mag Textdateien und hab deshalb nicht auf DBLog umgestellt. Damit bist du leider nicht mehr als Tester für die Backup-Funktion der Log-Dateien brauchbar 

...weder sinnvoll noch notwendig ist...

Dem widerspreche ich nicht. Tue es aber trotzdem. Diese Freiheit nehm ich mir bei Freier Software raus.
Ich empfehle auch niemandem seine fhem.cfg manuell zu editieren oder verpflichte jemanden die Datei aufzuräumen. An alle anderen, "FINGER WEG VON DER FHEM.CFG"!!!.

geht das nicht auch mit einem notify

leider nein, denn mein notify ist für die "Funktionsgruppe" spezifisch. Tür-Fenster-Kontakt, Heizungsventil und Rolladen hängen da zusammen und werden individuell angesprochen. die TF-Kontakte arbeiten bei mir dann raumübergreifend....to much detail.

lassen sich meiner Erfahrung nach auch über FHEM Bordmittel

ja, natürlich geht das. hab es ja selbst jahrelang so gemacht. mit all den Fehlern die das manuelle so mit sich bringen. 

Das COM-Interface ist noch ein "Relikt" aus der "Prä-Template" Zeit. Ich hab mir die komplette cfg eingelesen und mir die Tabellen nach Typ sortiert füllen lassen. also alle DoIF, Notify usw. Damit hab ich lange meine Devices "einheitlich" gemacht und bei neuen Geräten die funktionen der anderen per C&P, Search&Replace, bla, bla, bla.

Da du dich so dafür interessierst, magst du Tester werden? 

[koldomon]

Nachtrag zum Archivieren (backuplogs)

Da ich das als normale .exe implementiert habe, kann ich das Tool auch mit "backuplogs" als Parameter aufrufen und er macht mir meine Backups automatisch. Hab ich als Scheduled-Task auf meinem Backup-Server laufen - da wandern bei mir auch die alten Logs hin.

Es passiert beim Archivieren noch ein wenig mehr. ich werfe z.b. alle Fehlermeldungen raus, die Archiviere ich nicht. Weiterhin hatte ich lange Zeit so ein "Device-Da, device-Weg" spielchen mit meinem CUNO was mir das fhem.log vollgemüllt hat. Das werf ich auch raus. Oder alles über Debug-Level 3. Brauch ich, wenn ich einen Fehler finden will, aber im Archiv interessiert mich das nicht, wann ich mal wieder "to-stupid-for-perl" war.....und das soll auch nicht nachvollziehbar sein 

wie schon erwähnt. Das Tool ist mit meiner Betriebsbrille entstanden. Mir ist vollkommen klar, dass jeder seine eigenen "Best-Practices" mit FHEM hat. Deshalt ja auch die Tester, damit ich die andere Brille bekomme

[koldomon]

Nachtrag zum Template

Ein von mir gedachter Einsatzzweck ist auch die Validierung der vorhandenen Devices. Ich kann mit dem Tool hergehen, mir ein Template z.B. vom Heizkörper im Bad erstellen lassen (was eine eingestelle Vorheizzeit hat) und es auf das Ventil in der Toilette übertragen. Was mir mein Tool dann ermittelt ist die Differenz der vorhandenen Konfiguration zu der Konfiguration des Template und mir diese Differenz als FHEM-Befehle generieren lassen (modify statt define, nur unterschiedliche Attribute). Auf diese Art und Weise hab ich mal schnell 10 vergessene ";" gefunden. 

Mein persönliches Ziel ist es, ein Template zu haben, mit dem ich notfalls meine komplette Installation auf Knopfdruck generieren lassen kann.

Ein weiterer Einsatzzweck wäre der Ausfall eines vorhanden Gerätes. Ich behalte mir in den Namen meiner Geräte die ID mit drin, was den Nachteil hat, das diese ID auch überall verwendet wird. Umbenennen geht, klar, aber ich kann jetzt halt auch einfach neu anlegen lassen, bzw. kann mir alles was am alten Device drangehängt ist auf's neue ändern lassen, ohne dass ich was vergessen kann.

[KernSani]

Ok, ich sehe schon, da steckt viel Arbeit und Überlegung drin (mehr als vielleicht aus den ersten Zeilen zu erkennen ist) und ich bestreite nicht, dass das deiner Arbeitsweise (und möglicherweise auch Anderen) entgegenkommt. Ich halte mich jetzt aber vornehm zurück (und nein, ich möchte nicht testen ) und wünsche viel Erfolg! Weitere Leser sollten sich von meinen Worten nicht abschrecken lassen, sondern sich ihre eigene Meinung bilden (ggf. indem sie testen).

[koldomon]

Danke Oli,

also, wer hat Bock zum Testen.

Code liegt bei GitHub https://github.com/koldomon/FHEManager