Hallo, kann man einer Gruppe die aus Hue per autocreate erzeugt wurde auch einen State zuweisen?
Bei mir steh da immer nur unknown, egal ob die Gruppe on oder off ist.
Ich würde der Gruppe gerne mit devstateicon ein Icon zuweisen, doch das geht natürlich nur wenn die Gruppe einen defnirten Zustand hat.
"State" kann man sicher auch zuweisen, aber den Sinn dahinter müßtest du mir erklären, für mich machen nur "state" oder "STATE" Sinn ::) .
Ansonsten solltest du mal einen kritischen Blick auf ein "list" von so einem Device werfen bzw. darauf, welche Readings sich ändern, wenn alle/keines/ein Teil der Geräte an sind und dich danach mit stateFormat beschäftigen ;) .
Sorry, ich meinte STATE. Ich vergesse immer dass es das state in Kleinbuchstaben auch noch gibt.
Der Sinn ist ganz einfach, dass ich gerne erkennen würde ob eine Lichtgruppe (also alle zugewiesenen Lampen einer Gruppe) eingeschaltet sind oder nicht.
In den meisten Fällen schalte ich wahrscheinlich die Gruppe und nicht die einzelnen Gruppenmitglieder.
Im Moment wird der STATE kontinuierlich mit "Unknown" angegeben, weshalb keine Zuweisung mit devstateicon möglich ist. Es wird konstant ein nichts sagendes Icon mit einem Fragezeichen drin angezeigt.
stateformat dient doch der Formatierung, oder? Was soll ich damit bewirken können?
Die Readings der "Gruppenmitglieder" sind eigentlich egal, da sie sich ja ändern und der STATE der Gruppe trotzdem "Unknown" bleibt.
Das einzige was mir einfällt wäre mit Hilfe eines structure die STATE der Gruppenmitglieder "auszulesen" und das dann dem Gruppendevice zuzuordnen, aber dann kommt wieder ein überflüssiger Dummy (structure) ins Spiel. Außerdem wüsste ich nicht wie ich den Wert aus dem structure an den STATE der Gruppe übergeben kann, das ginge doch nur mit userreadings.
P.S.:
Nur zur Klarstellung, ich rede von automatisch erzeugten Gruppen, die in der Hue-App angelegt wurden, nicht von Devices die in Fhem als Gruppe angelegt worden sind.
Welcher Art entsprechen die über autocreate angelegten HUE-Gruppen-Device eigentlich? Ist das ein extra Device-Typ? Offensichtlich ja kein structure-device, oder?
P.P.S.:
Worin besteht eigentlich der genaue Unterschied zwischen STATE und state, das habe ich noch nicht kapiert? In der Regel sind die beinhalteten Werte identisch.
1. Liefere bitte ein list (https://forum.fhem.de/index.php/topic,71806.0.html) (von dem HUEDevice der fraglichen Gruppe).
2. Bitte verlinke die Doku zu stateFormat, die du zu Rate gezogen hast.
Hier das List:
Internals:
CFGFN
DEF group 12 IODev=Hue_Bridge
FUUID 5f51483c-f33f-b8b5-6246-f595145d182b9ae4
FVERSION 31_HUEDevice.pm:0.218370/2020-05-02
ID G12
INTERVAL
IODev Hue_Bridge
NAME HUEGroup12
NR 70865
STATE unknown
TYPE HUEDevice
class Bedroom
desired 0
lights 3,4
name Nachtische
type Zone
READINGS:
2020-09-03 21:56:50 all_on 0
2020-09-04 05:55:49 any_on 0
helper:
devtype G
fromAutocreate 1
update_timeout 1
json:
class Bedroom
name Nachtische
type Zone
action:
alert select
bri 254
colormode xy
ct 153
effect none
hue 0
sat 254
xy:
0.2142
0.0813
lights:
3
4
sensors:
state:
lights:
3 1
4 1
Attributes:
IODev Hue_Bridge
alias Nachtische
color-icons 2
delayedUpdate 1
devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
group Licht
room 20_Schlafzimmer
userattr createActionReadings:1,0 createGroupReadings:1,0
Doku kann ich keine Verlinken, der Satz bezog sich auf verschiedene gelesene Information bei Rechergen zu anderen Befehlen und die daraus abgeleiteten Schlüsse.
OK, dann melde dich wieder, wenn du den Abschnitt readingFnAttributes in https://fhem.de/commandref_modular.html gelesen hast (oder die DE-Version) und die Doku zu HUEDevice (https://fhem.de/commandref_modular.html#HUEDevice). Ich werde dann entscheiden, ob ich dir eine funktionierende RAW-Definition von so einem Device zeige. Meine Erwartung ist, Bemühungen erkennen zu können, das zu verstehen.
Ansonsten bin ich hier raus.
Also soweit ich das verstehe - und ich bin mir bei vielem nicht sicher - soll ich per stateformat den Inhalt aus state an STATE übergeben. Dabei kann der übergebene Inhalt formatiert werden oder auch nicht. Ist das so richtig? Habe mir auf die schnelle die google-Übersetzung der englischen Seiten durchgelesen, aber die ist natürlich nicht wirklich gut.
Falls ja bestehen zwei Probleme:
1. ich habe in der Gruppe kein reading state, einzig all_on und any_on, keins der angegebenen readings in der Devicebeschreibung ist vorhanden.
2. die readings all_on und any_on reagieren nr wenn man die Gruppe ein-/ausschaltet und wechseln zwischen 0 und 1, was man ja noch mit an und aus oder on und off umformatieren könnte. Aber es bringt ja nichts wenn die readings beim direkten Schalten der Lampe auf 0 stehen bleiben.
P.S.:
List liefere ich später nach, kriege ich vom Handy aktuell mal wieder nicht hin.
Wow, translator statt https://fhem.de/commandref_modular_DE.htm...
Nein, wie du schon richtig beobachtet hast, entspricht STATE state, wenn man _nichts_ macht. Dieses dafault-Verhalten kann durch (mind) zwei Stellschrauben GEÄNDERT werden: eventMap und stateFormat. Damit bekommt man also _etwas anderes_ nach STATE. Lesetipp: https://wiki.fhem.de/wiki/DeviceOverview_anpassen
Ich muß zugeben, dass mich das Verhalten der Gruppe beim Schalten einzelner Devices daraus bisher nicht sonderlich interessiert hat, weil ich die wenn, dann nur in der Gruppe schalte bzw. dimme. Ich gehe aber davon aus, dass justme68 auch da einen guten Job gemacht hat und man sinnvolle Ergebnisse erhalten kann, wenn man die gruppenbezogenen Spezialattribute an HUEDevice nutzt. (da gibt's die cref allerdings nur in englisch, aber evtl. kannst du die Attributnamen ja als Schlagworte für die Suche im Wiki bzw. Forum nutzen, falls der englische Text mit etwas Ausprobieren nicht weiterhilft (Trockenübungen sind Sch..., aber das hatten wir auch schon, oder?)).
Sorry, aber woher soll ich wissen dass es die URL https://fhem.de/commandref_modular_DE.htm... gibt. auf der von dir verlinken Seite wurde nirgendwo ein Link zu einer deutschen Version angezeigt (so wie in der CommandRef).
Allgemein habe ich nicht das Problem mit Englisch, doch leider sind in den Artikeln zu viele Abkürzungen und Fachbegriffe enthalten für die man die Übersetzung erst recherchieren muss. Dafür fehlt mir während der Arbeit aber leider die Zeit. Darum hatte ich auf den Translator zurückgegriffen., der war/ist der schnellste Weg. Sicher nicht die beste Möglichkeit aber das beste was ohne das Wissen und ohne Zeit geht.
Aber egal, zum Thema:
Mein Problem ist ja eben, dass ich das reading state in der HueGruppe nicht bekomme. Wie geschrieben sind die einzigen beiden readings "all_on" und " any_on". Wobei der Sinn der beiden readings nicht wirklich schlüssig ist, da sie immer beide entweder 1 oder 0 sind. Und eben auch nur schalten, wenn die Gruppe direkt geschaltet wird. Schaltet man die einzelnen Lampen die in der Gruppe enthalten sind einzeln, bleiben beide readings auf 0, selbst wenn alle Lampen eingeschaltet sind.
Was verstehst du unter gruppenbezogene Spezialattribute? Kann man die wieder über den Butten unter dem Device finden? Welche cref meinst du? die normale CommandRef?
Gibt es das reading state auch wenn es nicht angezeigt wird?
Na ja, die CommandRef gibt es eben in englisch und machmal in deutsch (https://wiki.fhem.de/wiki/Dokumentationsstruktur), aber im Prinzip ist unter allen Links immer das zu finden, was du auch mit dem entsprechenden help-Befehl in FHEM sehen würdest bzw. den Button "device specific help" unten in der Detailansicht eines Geräts, auf die du dich vermutlich beziehst. Es ist daher (fast) völlig gleichgültig, ob du über modular, commandref_join (das, was hier im Forum verlinkt ist: https://commandref.fhem.de/) oder die https://fhem.de/commandref_DE.html auf die entsprechenden Seiten kommst.
Da man in der commandref_modular nur die jeweils relevanten Teile sieht, verlinke ich eben gerne auf die, die ist besser zu durchsuchen und da nur die englische verpflichtend ist, ist die auch immer vorhanden. Bis auf wenige Ausnahmen ist die auch in der Regel technisch besser als die DE-Variante.
Den betreffenden commandref-Abschnitt hatte ich bereits genannt, ebenso Stellen, wo Antworten auf die diversen noch offenen Fragen zu finden sind. Bitte lies ggf. einfach nochmal den gesamten Thread hier durch, vielleicht wird dann mein Geschreibsel auch nochmal etwas verständlicher, ist mir auch mal so gegangen, dass ich nicht alles beim ersten Mal verstanden hatte (bzw. das geht mir heute nicht ganz selten immer noch so).
Ansonsten schaust du dir das bitte an deinem FHEM heute abend in Ruhe an und experimentierst mit den Attributen von HUEDevice ein bißchen rum.
Wie bereits mehrfach betont, geht es nicht darum, dass du schnell antwortest, sondern dass du möglichst schnell Antworten findest. Meine Überzeugung ist die: Du wirst schneller Antworten finden, wenn du langsamer, aber gründlich vorgehst und wohl oder übel die grundlegenden Dinge lernst. Dazu gehört vor allem auch das Verständnis, wie die Doku zu lesen ist.
Dann warte ich jetzt mal ab, was deine abendlichen Versuche so an Erkenntnissen ergeben ;) .
Vielleicht machst du dir auch die Mühe, mal meine ersten Fragmente eines aktuellen Einsteiger-pdf's zu lesen, das ermöglicht ggf. auch nochmal einen anderen Blick auf manches: https://svn.fhem.de/fhem/branches/epdf2020/frame.adoc. Leider funktionieren die darin enthaltenen links zu Bildern usw. noch nicht so richtig usw., aber vielleicht wird das auch irgendwann nochmal was...
Danke für die Hinweise zur Commandref, da wird einiiges klarer. Hatte immer gedacht, dass es verschiedene Quellen sind.
Wie gesagt mit dem englischen ist das so die Sache, dass man die Abkürzungen und Fachbegriffe recherchieren muss, die kenne ich halt nicht. Das dauert immer etwas, darum kürzt man gerne mal ab.
Werde mich mal durcharbeiten und schauen was ich machen kann.
Bin leider mit dem Versuchen sehr vorsichtig geworden, da ich mir das laufende System zu oft durch sowas zerschossen habe.
Ich hatte für fleißiges Lesen ein list ausgelobt...
Da du das in dem anderen Thread ausgiebig unter Beweis gestellt hast hier mal eine RAW-Definition (in der Hoffnung, dass dir klar ist, was der Unterschied zu einem "normalen" list ist):
defmod Licht_Essen HUEDevice group 240 IODev=phoscon
attr Licht_Essen userattr createActionReadings:1,0 createGroupReadings:1,0
attr Licht_Essen IODev phoscon
attr Licht_Essen alias Licht Essen
attr Licht_Essen color-icons 2
attr Licht_Essen delayedUpdate 1
attr Licht_Essen devStateIcon gr.1:on:off gr.0:off:on
attr Licht_Essen group Licht
attr Licht_Essen icon light_control
attr Licht_Essen room Esszimmer
attr Licht_Essen stateFormat gr:any_on
attr Licht_Essen webCmd pct:ct
(Bitte vor eventuellen Fragen Device-Overview anpassen im Wiki nachlesen...)
Zitat von: MarkoP am 04 September 2020, 20:08:11
Bin leider mit dem Versuchen sehr vorsichtig geworden, da ich mir das laufende System zu oft durch sowas zerschossen habe.
Drum hab ich mindestens 1 Testsystem (aktuell sogar 2 ;) )...
Da probiere ich rum und auch "neue" ("unbekannte") Module etc. aus...
Wenn ich dann die Funktionalität "brauche"/will und mir das Modul zusagt -> Hauptsystem
Ebenso andere "Spielereien" inkl. OS-Pakete (nach)installieren: erst mal auf dem Testsystem(en) und da auch mitnotieren, was ich tun musste um es zum Laufen zu kriegen (inkl. "Verifikation" eines "geradlinigen" Wegs [weil oft geht's mal "hin-und-her" ;) ])...
Und gleiches: wenn ich' dann "haben will", dann kommt es auf's Hauptsystem...
WEIL: mein Hauptsystem ist WICHTIG und soll (ohne Probleme) 24/7 laufen! Da kann ich keine "Spielereien" brauchen...
Gruß, Joachim
Zitat von: MadMax-FHEM am 10 September 2020, 17:44:01
Drum hab ich mindestens 1 Testsystem (aktuell sogar 2 ;) )...
...ja, auch ein interessantes Thema...
Ich habe auch mehrere (kleine) Testumgebungen, aber wenn es darum geht, irgendwie in Interaktion mit Hardware zu treten oder Wechselwirkungen zwischen verschiedenen Teilen zu testen, kommt man - je nachdem - kaum drumrum, manches im Hauptsystem "reifen" zu lassen (Bananenprinzip läßt grüßen, ich wünsche dir (MarkoP) eine geduldige Partnerin ;D ).
Es ist nicht ganz so einfach, da eine Empfehlung für den Anfang zu geben, ich würde dazu tendieren, (funktionierende) Zwischenstände wegzuspeichern (also die cfg. unter passendem Namen zu kopieren) und dann ggf. tatsächlich (mit Bedacht) am Hauptsystem weiterzumachen.
Was auch helfen kann: configDB (@sqlite)! Da kannst du auch mehrere Versionen von einem Device "behalten", diffs ausgeben und ggf. dann auch mal einen alten Stand einzelner Devices rekonstruieren. (Ich nutze am Hauptsystem configDB und speichere daraus dann aber schon bei Gelegenheit/nach größeren Umbauten auch schon mal einfach nur die cfg unter dem aktuellen Datum raus. Im Übrigen wäre dann irgendwann auch das Thema Backup-Strategie (und Restore-Testen) ein wichtiger Themenkreis.)
Grundsätzlich würde ich aber dazu raten, immer nur eine Baustelle zu bearbeiten und dann die jeweils wieder auf einen Stand zu bringen, den man erst mal wieder so stehen lassen kann - daher habe ich mit dem RAW auch gewartet, bis das Thema "Schlaferkennung durch Qi-Schale?" (nicht) erledigt (aber erst mal abgehakt) ist ;) .
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.
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.
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.
ZitatGrundsätzlich würde ich aber dazu raten, immer nur eine Baustelle zu bearbeiten und dann die jeweils wieder auf einen Stand zu bringen, den man erst mal wieder so stehen lassen kann - daher habe ich mit dem RAW auch gewartet, bis das Thema "Schlaferkennung durch Qi-Schale?" (nicht) erledigt (aber erst mal abgehakt) ist
Stimme ich voll und Ganz zu und versuche das auch nach Möglichkeit einzuhalten, leider bauen zu oft Sachen auf einander auf oder greifen derart ineinander, dass dies nur bedingt möglich ist. Ich komme im Moment ja nicht mal bei diesen zwei Baustellen weiter. Neue werde ich definitiv erst nach einer Klärung beginnen. Habe mir seit Freitag mindestens ein halbes Dutzend Mal vorgenommen das Intervall bei der QI-Sache festzustellen und dann die Sache mit einem Watchdog erst mal abzuschließen, doch jedes mal wenn ich denke ich habe mal eine halbe Stunde Zeit, kommt wieder etwas anderes dazwischen
Zitat von: MarkoP am 14 September 2020, 11:00:34
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... ;)
Zitat von: MarkoP am 14 September 2020, 11:00:34
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...
ZitatBackups 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...
ZitatDas 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...
Zitat
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 ;) .)
@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.
Zitat von: MarkoP am 14 September 2020, 12:26:56
@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
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).
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.
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.
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.
Zitat von: MarkoP am 14 September 2020, 14:16:50
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
Ok, so habe ich es auch verstanden. Habe nur nachgefragt weil ich es nicht glauben konnte.
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 ;) .
Zitat von: Beta-User am 14 September 2020, 14:34:54
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
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.