Symbol für Gruppen

[MadMax-FHEM]

Das mit dem Testsystem ist sicher eine gute Idee, wobei ich mir die Frage stelle wie ihr dabei verhindert, dass beide Systeme parallel reagieren bzw. Prozesse auslösen und es so zu ungewollten Aktionen kommt.

Weil die Systeme UNABHÄNGIG voneinander sind (bei mir zumindest)...

Zwar durchaus gleiche Systeme, also Homematic, ZWave, EnOcean, HUE, ...

Aber halt in ihrer "eigenen Welt"...
...sonst würde es ja schon schief laufen, wenn der Nachbar plötzlich mit Homeautomation "um die Ecke käme"

Und: manchmal hängen gewisse Dinge ja nur kurz am Testsystem und wandern dann auf's Hauptsystem...

Also: ich will mir evtl. ein neues System zulegen. Dann geht das erst mal "auf" eines der Testsysteme. Bin ich zufrieden -> Hauptsystem. Wenn nicht: "Müll" (nein: es bleibt halt am "Spielsystem", wer weiß   weil vielleicht "entwickelt" sich das System oder das zugehörige fhem Modul oder oder oder)

Gruß, Joachim


P.S.: ja manche HW ist doppelt... Ja: kostet zusätzlich Geld... ABER: wegen Geld(ersparnis) darf man "hier" wohl nicht "mitmachen"... Es ist (für mich) erst mal ein Hobby mit Kosten. Dafür aber (meist) Spaß und einigen schönen "Nebeneffekten" wozu auch etwas "sparen" gehört. Aber sicher (bei weitem) nicht in dem Umfang der Kosten... Wer das genau wegen Geld sparen macht: eieiei...

[Beta-User]

Das mit dem Testsystem ist sicher eine gute Idee, wobei ich mir die Frage stelle wie ihr dabei verhindert, dass beide Systeme parallel reagieren bzw. Prozesse auslösen und es so zu ungewollten Aktionen kommt.

Tendenziell ist bei mir v.a. Hardware nur "entweder oder" eingebunden, was funktioniert, kommt in der Regel recht schnell ins Hauptsystem (es gibt auch Leute, die mit verteilten Systemen arbeiten, (Stichwort RFHEM/FHEM2FHEM oder auch via MQTT), aber mir ist das zu kompliziert.)

Ein Testsystem ist v.a. dazu gut, um z.B. mal einzelne Logikbausteinchen auszutesten (oder überarbeiteten Modulcode) oder neue Hardwaresysteme an sich kennenzulernen. Ich versuche allerdings z.B. auch, die Zahl der eingesetzten Module eher zu begrenzen...

Backups werden bei mir jede Nacht um Mitternacht gemacht, das habe ich erst vor kurzem so eingerichtet. Außerdem müsste jedes mal eins gemacht werden wenn die Config gespeichert wird. Ich hoffe mal das sollte ausreichend sein.

Backup jede Nacht klingt gut, du solltest dann aber auch testen, ob das mit dem Wiederherstellen klappt.

Änderungen der config gehen bei mir über configDB, aber prinzipiell würde ich nicht jedes Detail nachverfolgen (wer blickt da irgendwann noch durch?), sondern mache z.B. entsprechende (Vorher/nachher-) Auszüge nur dann, wenn ich mal wieder was ausgiebiger umgebaut habe; der Rest funktioniert ja...

Das mit dem ConfigDB ist mir ein Begriff, habe ich aber bisher komplett ignoriert. Genau um da nicht eine weitere Baustelle aufzumachen und auch weil es so wie ich es verstehe wohl eine Grundsatzentscheidung ist welches System man nutzt, eine DB oder die CFG.

Na ja, ich würde das etwas weniger dogmatisch sehen, jedenfalls was die Frage der Konfiguration angeht (nicht das Logging, das ist eine ganz andere und sehr grundsätzliche Baustelle!). Meine Einschätzung für dich wäre, dass dir die Umstellung auf configDB helfen würde, weil es dich vom administrativen Nachverfolgen jeder Kleinigkeit entlasten würde. Falls du umstellen wolltest: Die Anleitung in der commandref ist aktuell, und ich meine, es gibt auch einen "Workshop" zur Umstellung von betateilchen hier im Forum. Allerdings kann ich dir nicht sagen, wie das mit der Anpassung des Startscripts bei Docker funktioniert...

leider bauen zu oft Sachen auf einander auf oder greifen derart ineinander, dass dies nur bedingt möglich ist.

Mein Eindruck: Das mag in Teilen stimmen, aber es liegt vermutlich auch daran, dass du gleich die "Vollversion" haben willst.
Tatsächlich ist es schon nicht einfach zu verstehen, was für eine Logik hinter dem RAW-Code liegt, den ich gepostet hatte. Sei doch einfach schon mal etwas weniger ungeduldig mit dir selbst, wenn sowas schon mal funktioniert und erwarte nicht zu viel auf einmal... (Ich hatte früher auch nie verstanden, warum man seine Müll-Termine in FHEM braucht, aber "blink" bzw. "hello world" haben schon eine wichtige Funktion, und für sowas tun es ggf. auch Mülleimer in einem Testsystem .)

[MarkoP]

@MadMax-FHEM
Ich glaube da sind wir gerade aneinander vorbei geschossen.
Korrigier mich aber ich gehe davon aus, dass mit dem Hauptsystem und dem Testsystem die gleichen Komponenten angesprochen werden, da alle im Hauptsystem befindlichen Abläufe vorher im Testsystem getestet wurden. Wie also verhinderst du , das ein bestimmter Trigger ein Notify nicht zeitgleich auf dem Haupt- und auf dem Testsystem auslöst? Auf beiden Systemen ist ja das Notify vorhanden, oder nicht?

@Beta-User
Im Prinzip gilt auch hier die gleiche Frage wie oben. Wenn du nur Teile im Testsystem hast wie stellst du dann die Funktionalität bei Abhängigkeiten dar?

Du meinst das ich die "Vollversion" möchte.
Das verstehe ich nicht, auf der einen Seite hast du geraten alles so universal und generisch (setzt voraus, dass man sich vorab Gedanken um Struktur und Benennung macht) zu halten wie möglich und auf der anderen Seite sagst du jetzt alles in Einzelschritten und so wenig Abhängigkeiten wie möglich. Das ist für mich ein Wiederspruch in sich selbst. Ich kenne zwei Systeme, entweder ich mache alles in Einzelschritten und muss mir keine Gedanken um Abhängigkeiten machen oder ich plane vor Beginn und überlege welche Abhängigkeiten existieren und was neben dem gewollten noch passieren kann wenn etwas ausgelöst wird. Wobei ersteres oftmals gar nicht geht, zumindest meiner Erfahrung nach.

Backup habe ich noch keins wiederhergestellt, macht man eben gerne erst wenn es wirklich sein muss. Guter Tipp, muss ich mich mal drum kümmern.

[MadMax-FHEM]

@MadMax-FHEM
Ich glaube da sind wir gerade aneinander vorbei geschossen.
Korrigier mich aber ich gehe davon aus, dass mit dem Hauptsystem und dem Testsystem die gleichen Komponenten angesprochen werden, da alle im Hauptsystem befindlichen Abläufe vorher im Testsystem getestet wurden. Wie also verhinderst du , das ein bestimmter Trigger ein Notify nicht zeitgleich auf dem Haupt- und auf dem Testsystem auslöst? Auf beiden Systemen ist ja das Notify vorhanden, oder nicht?

FALSCH: so wie auch Beta-User geschrieben hat. Es sind (bei mir) komplett GETRENNTE Systeme (habe ich doch geschrieben)! Wenn ich etwas ausprobiere, dann habe ich dafür (ja auch in HW) Komponenten am Testsystem. Logiken kann man ja (zur Not) mit dummy testen... Und neue Module (bei denen ich erst mal schaue: taugt das und v.a. taugt das MIR) sind ja eh erst mal nur auf dem Testsystem...

EDIT: und "Verfeinerungen" von Dingen die laufen passieren nat. schon (meist) direkt am Hauptsystem. ABER: nur "Verbesserungen"... Wenn ich grundsätzliche Dinge (neu oder auch um) "Baue", dann erst mal auf einem Testsystem. V.a. wenn es sich um Module handelt, die irgendwelche "Spezial-Installationen" brauchen. Ich will ja nicht mein Hauptsystem mit "Hin-und-her-Installationsversuchen" komplett "zerstören"... Erst wenn ich glaube einen "sauberen Weg" gefunden zu haben (und ja da kann es schon sein, dass ich das Testsystem mal "platt mache" und neu aufsetze um das zu überprüfen) UND das Modul etc. als "gut" empfinde kommt es auf's Hauptsystem. U.a. "teste" ich auch Speicheranstieg und Blockieren. Module die blockieren (oder wo der Speicher plötzlich anfängt zu wachsen) können kommen (erst mal) nicht aufs Hauptsystem...

EDIT: sollte ich jemals auf configDB oder DBLog umsteigen dann auch erst mal auf einem Testsystem

EDIT: ein Testsystem "platt machen" und neu aufsetzen hilft auch sein Backup/Restore-Konzept zu testen und zwar ohne dass "schlimme Dinge" passieren können (selbst wenn ich ein Testsystem nicht mehr wieder hin kriege wie vorher: who cares, es ist eine Testplattform)  Und wenn es dann für das Testsystem taugt (und schnell geht, weil das soll/muss es ja   ), dann sollte es für das Hauptsystem (mit deutlich mehr "Sauberkeit" und deutlich besserer "Dokumentation") ja auch passen

Gruß, Joachim

[Beta-User]

Ein Testsystem muß nicht zwingend dieselben Komponenten beinhalten wie das Hauptsystem.

Wenn du wissen willst, wie man in FHEM mit einer Gruppe von HUEDevice-Leuchten umgehen kann, geht das ohne weiteres auf einem Testsystem, das muß nur auf die HUEBridge draufkönnen (dann hast du ggf. in FHEM nur das gleiche Problem, wie wenn du was mit der Handy-App schaltest: soll darauf in FHEM irdendwie reagiert werden...? Was aber kein Problem ist, solange das Teil dort nicht wirklich eingebunden ist.)

Wenn du wissen willst, wie ein watchdog funktioniert, genügen dafür 2-3 dummy-Geräte (meine sind meistens MQTT2_DEVICEs, die fliegen da eh's schon in unnötig großer Zahl rum) und eben der watchdog (oder man nimmt nur den watchdog und macht den Rest mit trigger). Wenn das dann klar ist, kann man das Device dann einfach mit RAW-Import in das Haupt-FHEM übertragen; der Rest ist dann ggf. eine Frage der Skalierung bzw. der Einbindung in das Gesamtsystem.

Und klar, ob etwas ggf. am Ende (noch) funktioniert, sehe ich manchmal auch erst, wenn es "an Ort und Stelle" ist...

Ansonsten sehe ich den behaupteten Widerspruch nicht: bei bestimmten Bausteinchen (Hard- und Software) muß man erst die Details kennen (wie funktioniert das, wann kommen welche Events, wovon hängen die ab und wie kann ich das ggf. beeinflussen...), dann kann man sich die Frage stellen, wie das ins Gesamtsystem passen soll, und dann geht es (wo möglich: generisch strukturiert) los. Und bei Logik-Elementen kann man die auch nachträglich in der Regel ohne weiteres erweitern, wenn man feststellt, das z.B. bestimmte weitere Rahmenbedingungen eine Rolle spielen, die man vorher nicht erkannt hatte.

Mit "wo möglich: generisch strukturiert" ist sowas gemeint wie: ich habe für die Aufgabe der Breitstellung virtueller Raumthermostate neben der eigentlichen "Hardware" (je ein Temp/Hum-Sensor je Raum, dazu je ein virtueller Homematic-Temperaturkanal (auf je einem anderen HM-Haupt-Device)) genau ein notify, um auf alle Temperatur-Events dieser Raum-Sensoren zu reagieren (das schreibt die Temperatur in den zugehörigen HM-Kanal) und genau ein at, um alle veralteten Werte zu löschen (damit das insgesamt ausfallsicher ist). Also z.B. nicht je ein notify für jede Sonsor-Kanal-Kombination; (den zum jeweiligen Temperatursensor gehörenden HM-Kanal ermittelt die set-Anweisung über ein userattr, so ist auch direkt am HM-Kanaldevice zu erkennen, zu "wem" es "eigentlich" gehört, wer also die Daten liefert).

[MarkoP]

Ok, mein Fehler. Ich verstehe unter dem Begriff Testsystem ein Duplikat mit den gleichen Zugriffen auf Soft- und Hardware wie das Hauptsystem. Ihr meint damit eher die Fhem-Basic-Installation wo ggf. Hardwareelemente mit Dummys gespiegelt werden.

Nein, mit generisch meine ich zb. alle Lichter auf einmal auszuschalten, zb durch "set .*licht off" oder ähnliches. Dabei muss ich mir doch vorher Gedanken machen was alles von dem Regex ".*licht2" erfasst wird.
Um das zu organisieren muss ich vorher überlegen welche Benennung Sinn macht.

[Beta-User]

Zwei Steuerungen, die auf dieselbe Hardware gehen sind immer schwierig, weil mn dann nie sicher weiß, aus welcher Sphäre denn jetzt z.B. ausgeschaltet wurde. Daher kann man entweder ein Testsystem haben, in dem man mehr oder weniger ausschließlich Logiken hat (und die Hardware eventuell mit FHEM2FHEM+dummy durchreicht, oder eben Testsystem eher als eine Art Spielwiese verstehen... Ersteres ist eher was für Power-User (mind. Fortgeschrittene), Letztere ist m.E. fast auch für Anfänger ein Muss, sobald das Haupt-FHEM in irgendeiner Art und Weise "produktiv" ist...

Über den Nutzen eines sinnvollen Namensschemas brauchen wir nicht zu streiten. Nach meinem Verständnis ist ein Befehl wie "set .*licht off" nichts generisches (=für eine Vielzahl von gleichartigen oder ähnlichen Anwendungsfällen passend), sondern ein einzelner Befehl mit relativ klar umrissenen Ergebnissen, die auch nicht variieren (nicht mal, wenn man z.B. eine FILTER-Anweisung dahinterschreibt, die auf den aktuellen "state" ginge; das wäre erst anders, wenn man z.B. den Raum dynamisch aus dem triggernden Event ableiten würde und dann z.B. ein 'fhem("set .*licht:FILTER=room=$room off")' absetzt.

PS: Auf welche Geräte ein Befehl Auswirkungen hat, kann man sich leicht mit "list <devspec>" anzeigen lassen.

[MarkoP]

Das ist doch genau meine Rede, darum habe ich ja gefragt wie ihr ein Testsystem vom Hauptsystem trennt. Für mich ist ein Testsystem eben ein System mit dem ich gleiche Verhältnisse habe um auch gleiche Ergebnisse reproduzieren zu können, also hatte ich vorausgesetzt, dass ein Testsystem auch die gleichen Hardwarekomponenten anspricht. Es ist halt wie mit allem, ein Begriff kann von jedem anders interpretiert werden.

Das gilt genauso für das generisch. Für mich bedeutet generisch, dass mit einem Befehl mehrere Elemente bedient werden, in dem Beispiel eben mit einem Trigger alle Elemente die ein "Licht" im Namen haben ohne zu wissen welche das wirklich sind. Aber egal, lieber eine andere Frage die mich quält. Vielleicht kannst du mich aufklären welche Bedeutung der Alias bei den Devices hat. Ich kann jedenfalls mit dem Alias kein Device in einem Set-Befehl ansprechen.

[MadMax-FHEM]

Vielleicht kannst du mich aufklären welche Bedeutung der Alias bei den Devices hat. Ich kann jedenfalls mit dem Alias kein Device in einem Set-Befehl ansprechen.

Menschen lesbarer ("schöner") Name von Devices, damit man eben für "generische" (Programmierung) Dinge einen "maschinenverarbeitbaren" Namen hat über den eben "maschinengesteuert" geschaltet/bedient/... wird...
...und für zum "Anschauen" (auf z.B. fhemWEB) was hat, womit sich ein Mensch "angenehmer" tut...

Das gehört zu: fhem Basics

Und ja: genau das ist der Grund (schätze ich) warum eben ein "programmatisches" Schalten damit nicht geht, weil nicht dafür gedacht

EDIT: außerdem muss ein alias nicht eindeutig sein! Ein NAME schon!

EDIT: z.B. heißen meine Wandthermostate alle Wandthermostat Sie sind ja in verschiedenen Räumen und für mich (Mensch) dadurch unterscheidbar...

Außer als Filter etc.

Gruß, Joachim

[MarkoP]

Ok, so habe ich es auch verstanden. Habe nur nachgefragt weil ich es nicht glauben konnte.

[Beta-User]

Na ja, ich nutze das nicht, aber soweit ich verstanden habe, wird teils für die Sprachssteuerungslösungen der alias ausgewertet, der Rest wird aus den Umgebungsbedingungen abgeleitet, so dass "Mach das Deckenlicht" an sowohl im Wohnzimmer wie im Esszimmer funktionieren können...

Und man kann es als FILTER für devspec verwenden .

[MadMax-FHEM]

Na ja, ich nutze das nicht, aber soweit ich verstanden habe, wird teils für die Sprachssteuerungslösungen der alias ausgewertet, der Rest wird aus den Umgebungsbedingungen abgeleitet, so dass "Mach das Deckenlicht" an sowohl im Wohnzimmer wie im Esszimmer funktionieren können...

Jep. Ist aber "speziell Sprachsteuerung" wobei da auch "jede" anders verfahren kann...

Für alexa-fhem gilt:

alexaName (andere haben andere "Eigennamen" für das Attribut )
wenn nicht vorhanden, dann: alias
wenn auch das nicht: NAME (weil der muss ja   )

Gruß, Joachim

[MarkoP]

Ok, dann kann ich das erstmal ignorieren. Auch wenn es natürlich ziehl ist meine beiden Nest Mini in Fhem einzubinden, also sowohl Anfragen weiterzuleiten wie auch Ansagen aus Fhem heraus zu generieren. Aber das ist nichts Aktuelles.