ḱleine Frage in die Runde, ist jetzt auch nicht ganz so wichtig da ja nur optisch ::)
kann man den devStateIcon auch einem bestimmten Reading zuweisen? oder greift der immer auf "state"?
Nach meinen Erfahrungen greift es auf STAE, also mittels stateFormat, dass andere Reading in den STATE setzen.
devStateIcon bezieht sich auf internal STATE. du kannst per stateFormat bei den meisten devices jedes reading verwenden um STATE zu füllen.
gruß
andre
Hallo,
würde das Problem mal aufgreifen.
Kann man das das devstateIcon von eimen anderem state abhängigmachen.
Ich arbeite mit Siemens Logo und da ist der Taste und Lampe getrennt. Würde das gerne zusammen fassen so dass ich den Status der Lampe am Taster sehen kann.
Dachte das geht über den devstateIcon.
Danke
Hi,
wie es oben im Post von André steht: Die Wirkungskette die Du brauchst ist:
readings -> stateformat (https://fhem.de/commandref_DE.html#stateFormat)-> STATE -> devStateIcon (https://fhem.de/commandref_DE.html#devStateIcon)
Ob und wie das bei Siemens Logo geht weiß ich leider nicht.
Gruß Otto
Hallo zusammen,
könnte hier jemand ein beispiel posten wie das umzusetzen wäre?
Ich möchte auch ein Dummyicon mit einem reading von einem Fensterkontakt abbilden.
Gruß
Matthias
warum ein dummy und nicht den fenster kontakt direkt?
Hallo sehr gerne auch direkt mit dem Festerkontakt icon.
Ich dachte nur, dass der Fensterkontakt immer ein eingang ist und ich damit nichts schalten kann.
Ich möchte mir ein Offenes und geschlossenes Garagentor von dem Fensterkontakt anzeigen lassen,
soweit klappt das. Aber ich möchte auch mit der Maus das Icon zum öffnen der Garage benutzen.
Ist das umsetzbar?
Ok - ich habe es auch mit einem extra Dummy gemacht:
define GaragenTor dummy
attr GaragenTor devStateIcon zu:control_arrow_down auf:control_arrow_up open:fts_garage_door_10:zu closed:fts_garage_door_100:auf
attr GaragenTor room Garage
attr GaragenTor webCmd zu:auf
define di_garagentor DOIF ([RC81_1_TorOben:"closed"])(set GaragenTor open) DOELSEIF ([RC81_2_TorUnten:"closed"])(set GaragenTor closed)
attr di_garagentor room Garage
defmod nty_TorAuf notify GaragenTor:auf|VCCU_Btn4:trig_RC41_4:.*|VCCU_Btn4:trig_RC42_4:.* set SW81_1_TorAuf on-for-timer 1
defmod nty_TorZu notify GaragenTor:zu|VCCU_Btn3:trig_RC41_3:.*|VCCU_Btn3:trig_RC42_3:.* set SW81_3_TorZu on-for-timer 1
Quelle (https://heinz-otto.blogspot.de/2016/07/garagentor-mit-fhem-bedienen.html)
Gruß Otto
Danke für deine Hilfe.
Ich werde es morgen testen.
Gruß Matthias
Hallo Otto,
ich habe versucht das so zu integrieren, komme aber nicht weiter:
define GaragenTor1 dummy
attr GaragenTor1 devStateIcon open:fts_garage_door_10 close:fts_garage_door_100
attr GaragenTor1 room Garage
attr GaragenTor1 webCmd toggle
define di_garagentor1 DOIF ([Garage1switch:"open"])(set GaragenTor1 open) DOELSEIF ([Garage1switch:"close"])(set GaragenTor1 close)
attr di_garagentor1 room Garage
defmod nty_TorAuf notify GaragenTor1:toggle set GarageL on-for-timer 25
Das Dummy icon lässt sich nicht bedienen (kein Mouse over) wenn ich auf das Toggle daneben drücke geht das Tor auf.
Das open vom Garage1switch wird auch nicht immer an den Dummy weitergegeben.
Hast du einen Tip für mich?
Gruß Matthias
Hallo Matthias,
das Icon ist nur bedienbar wenn Du auch ein Kommando hinterlegst. Mein Beispiel:
closed:fts_garage_door_100:auf
Bedeutet Wenn Status Closed zeige Icon fts_garage_door_100 und bei Klick für Kommando auf aus.
Das Kommando fehlt bei Dir.
Was ist Garage1switch für ein Gerät?
Gruß Otto
Hallo Otto,
aaach jetzt habe ich das verstanden. OK jetzt ist das Icon bedienbar.
Jetzt funktioniert es:
define GaragenTor1 dummy
attr GaragenTor1 devStateIcon zu:control_arrow_down auf:control_arrow_up open:fts_garage_door_10:zu close:fts_garage_door_100:auf
attr GaragenTor1 room Garage
attr GaragenTor1 webCmd zu:auf
define di_garagentor1 DOIF ([Garage1switch:"open"])(set GaragenTor1 open) DOELSEIF ([Garage1switch:"close"])(set GaragenTor1 close)
attr di_garagentor1 room Garage
defmod nty_Torzu notify GaragenTor1:zu set GarageL on-for-timer 25
defmod nty_TorAuf notify GaragenTor1:auf set GarageL on-for-timer 25
Garage1switch ist ein xiaomi Fensterkontakt
jetzt werde ich es in meinen Floorplan einbauen und testen.
DANKE für deine Hilfe
Gruß
Matthias
Freut mich, dass es funktioniert:-) Dann musst du jetzt nur noch verstehen, wie man Code-Tags verwendet (das # oben im Editor) und das Thema auf gelöst setzen ( Subject des ersten Posts ändern und [Gelöst] davor schreiben)
Danke,
Oli
Hallo zusammen,
ich hatte immernoch Probleme mit dem Status übertragen von dem Fensterkontakt und dem DOIF ich habe es jetzt mit 2 einfachen notify gelöst, jetzt funktioniert es bei mir besser:
define GaragenTor1 dummy
attr GaragenTor1 devStateIcon zu:control_arrow_down:zu auf:control_arrow_up:auf open:fts_garage_door_10:zu close:fts_garage_door_100:auf
attr GaragenTor1 room Garage
attr GaragenTor1 webCmd zu:auf
define Garage1sensoro notify Garage1switch:open set GaragenTor1 open
define Garage1sensorc notify Garage1switch:close set GaragenTor1 close
defmod nty_Torzu notify GaragenTor1:zu set Garage1 on-for-timer 25
defmod nty_TorAuf notify GaragenTor1:auf set Garage1 on-for-timer 25
Ich werde noch testen ob es jetzt keine Probleme mehr macht.
Danke für den Tip mit dem Code einfügen.
Hallo,
ich wollte das Thema nochmal aufgreifen.
In meiner Wohnung befinden sich mehrere Temp Sensoren die über Lacrosse eingebunden sind. Ich würde gerne in der Web Oberfläche hinter jedem Sensor auch den Batteriestatus mit einem Icon sehen.
Momentan habe ich nur den Status in Textform hinbekommen. Meine config sieht wie folgt aus:
define Aussentemperatur_1 LaCrosse 0D
setuuid Aussentemperatur_1 5c52094a-f33f-78d7-9383-c4c5daaf49630ede
attr Aussentemperatur_1 IODev myJeeLink
attr Aussentemperatur_1 devStateIcon ok:measure_battery_100
attr Aussentemperatur_1 icon temp_outside
attr Aussentemperatur_1 room Balkon,LaCrosse,Wohnung
attr Aussentemperatur_1 stateFormat Temperatur: temperature°C - Feuchtigkkeit:humidity% - Batterie:battery
devstateicon scheint den Status ok nicht zu finden. Kann ich das irgendwie bewerkstelligen?
Danke
Moin,
naja: dein STATE ist nicht ok, der ist: irgendwas - ok.
Damit Dein Icon dafür gefunden wird kannst Du ein entsprechendes regExp nehmen:
.*ok:measure_battery_100
findet: "irgendwas was auf ok endet - ok"
Alllerdings hast Du dann nur ein Icon, der Text vorn ist weg. Das was Du sicher willst ist komplizierter. Da habe ich kein Beispiel parat.
Gruß Otto
@kinghill, versuch mal die relativ neue Variante mit dem mehrzeiligen stateFormat
attr Aussentemperatur_1 devStateIcon ok:measure_battery_100@green low:measure_battery_0@red
attr Aussentemperatur_1 stateFormat battery
Temperatur: temperature°C - Feuchtigkkeit:humidity%
direkt im Attribut oder als raw
attr Aussentemperatur_1 devStateIcon ok:measure_battery_100@green low:measure_battery_0@red
attr Aussentemperatur_1 stateFormat battery\
Temperatur: temperature°C - Feuchtigkkeit:humidity%
Wichtig ist der Zeilenumbruch im stateFormat !
Edit : wenn das Icon hinter den Text soll dann einfach die beiden Zeilen tauschen
Noch ein alternativer Ansatz?
attr <device> devStateIcon {Hole_State_und_ZusatzIcon(<devicename>,"","alt","")}
mit
####
# Hole_State_und_ZusatzIcon
####
# Parameter: <Devicename>,<Farbe für State-Icon>,<2.Reading>,<Farbe für 2.Icon>
####
# Rückgabe: String mit Inhalt für devStateIcon
####
sub Hole_State_und_ZusatzIcon($$$$)
{
my ($dev,$stateColor,$altReading,$altColor) = @_;
my $icon = "";
my %stateList = (
);
my $state = ReadingsVal($dev,"state","");
if ($state ne ".")
{
$icon = $stateList{$state}."\@".$stateColor;
my $mainImg = FW_makeImage( $icon, $stateList{$state} );
my $state = ReadingsVal($dev,$altReading,"");
$icon = $stateList{$state}."\@".$altColor;
my $secImg = FW_makeImage( $icon, $stateList{$state});
return '<div>'.$secImg." > ".$mainImg.'</div>';
}
else
{
return '<div></div>';
}
}
Dabei muss der Hash "statelist" natürlich sinnvoll gefüllt sein. Das habe ich hier mal weggelassen.
Aber dieser Ansatz bietet noch viel mehr Möglichkeiten und Freiheiten.
Zitat von: Wzut am 09 August 2019, 10:15:41
@kinghill, versuch mal die relativ neue Variante mit dem mehrzeiligen stateFormat
attr Aussentemperatur_1 devStateIcon ok:measure_battery_100@green low:measure_battery_0@red
attr Aussentemperatur_1 stateFormat battery
Temperatur: temperature°C - Feuchtigkkeit:humidity%
direkt im Attribut oder als raw
attr Aussentemperatur_1 devStateIcon ok:measure_battery_100@green low:measure_battery_0@red
attr Aussentemperatur_1 stateFormat battery\
Temperatur: temperature°C - Feuchtigkkeit:humidity%
Wichtig ist der Zeilenumbruch im stateFormat !
Edit : wenn das Icon hinter den Text soll dann einfach die beiden Zeilen tauschen
Hi.
Das hat perfekt funktioniert.
Habe das Batterie Icon noch nach hinten verschoben. Das ganze sieht jetzt so aus:
define Aussentemperatur_1 LaCrosse 0D
attr Aussentemperatur_1 IODev myJeeLink
attr Aussentemperatur_1 icon temp_outside
attr Aussentemperatur_1 room Balkon,LaCrosse,Wohnung
attr Aussentemperatur_1 devStateIcon ok:measure_battery_100@green low:measure_battery_0@red
attr Aussentemperatur_1 stateFormat Temperatur: temperature°C - Feuchtigkkeit: humidity%\
battery Vielen Dank für die Antworten!
wenn du am rechner ein foto vom desktop (bildschirm) machen willst, macht man das in windows mit dem "snippingtool" oder dem nachfolger "Ausschneiden und Skizzieren".
das ganze nennt sich dann "screenshot"
vorteile:
-keine externe hardware
-bessere qualität
-kleinere dateigrösse
-schneller
-sichnichtdieblösegebenseinmonitormitdemhandyabzufotografieren ;)
nachteil:
keiner
Zitat von: DasQ am 10 August 2019, 14:57:37
wenn du am rechner ein foto vom desktop (bildschirm) machen willst, macht man das in windows mit dem "snippingtool" oder dem nachfolger "Ausschneiden und Skizzieren".
das ganze nennt sich dann "screenshot"
vorteile:
-keine externe hardware
-bessere qualität
-kleinere dateigrösse
-schneller
-sichnichtdieblösegebenseinmonitormitdemhandyabzufotografieren ;)
nachteil:
keiner
HAHA. :P
Danke für die Info. Diese Funktionen sind mir bekannt.
Ich sass an einem Hackintosh an dem die Tastatur nicht sauber Konfiguriert ist, Sprich die Tastenkombi zum Screenshot machen wollte nicht funktionieren.
Danke nochmals allen :-)
Hallo
Ich würde das Thema gerne noch einmal aufrollen.
Ich hätte gerne zusätzlich noch je ein Icon
anstatt des Textes vor den Temperatur und Feuchtigkeitswerten.
Wie kann ich das verwirklichen?
define Aussentemperatur_1 LaCrosse 06
setuuid Aussentemperatur_1 5c52094a-f33f-78d7-9383-c4c5daaf49630ede
attr Aussentemperatur_1 IODev myJeeLink
attr Aussentemperatur_1 devStateIcon ok:measure_battery_100@green low:measure_battery_0@red
attr Aussentemperatur_1 icon temp_outside@white
attr Aussentemperatur_1 room Balkon,LaCrosse,Wohnung
attr Aussentemperatur_1 stateFormat Temperatur: temperature°C\
Feuchtigkkeit: humidity%\
battery
Hallo,
hier (https://wiki.fhem.de/wiki/DeviceOverview_anpassen#Perl-Variante) findest ein Beispiel.
Gruß
Thomas
Das sollte sogar ohne Perl kein Problem sein. Wichtig ist, dass der gewünschte Icon-Name bzw. der zu ersetzende Text (da identisch mit dem Readingnamen via devStateIcon zu machen) jeweils in einer Zeile steht. Ungetestet:
attr Aussentemperatur_1 devStateIcon ok:measure_battery_100@green low:measure_battery_0@red Feuchtigkeit:humidity
attr Aussentemperatur_1 stateFormat temp_temperature\
temperature°C\
Feuchtigkeit\
humidity%\
battery
EDIT: kann sein, dass das mit tem_temperature auch so zu machen ist wie bei Feuchtigkeit...
Hi
Danke für die Infos!
Genau so hatte ich es schon probiert. Allerdings habe ich jetzt festgestellt, dass ein Leerzeichen nach dem Icon Name fehlte.
Jetzt läuft es:
define Aussentemperatur_1 LaCrosse 06
attr Aussentemperatur_1 IODev myJeeLink
attr Aussentemperatur_1 devStateIcon ok:measure_battery_100@green low:measure_battery_0@red
attr Aussentemperatur_1 icon temp_outside@white
attr Aussentemperatur_1 room Balkon,LaCrosse,Wohnung
attr Aussentemperatur_1 stateFormat temp_temperature \
temperature °C\
temperature_humidity \
humidity %\
battery
Gibt es eine Möglichkeit DevStateIcon so einzustellen, dass es ein anders Symbol anzeigt, nur wenn das Gerät offline ist?
Hintergrund: Ich habe einige WLAN-Steckdosen. Wenn diese jedoch nicht in Verwendung sind hätte ich gern, dass das DevStateIcon die Steckdosen als Offline anzeigt.
Wenn ich nun aber StateFormat verwende und dort die Readings POWER und LWT eintrage, haben DOIFs die auf eq "on" oder eq "off" reagieren ein Problem, da der State der Steckdose dann nicht mehr nur "on" oder "off" enthält sondern "on Online" oder "off Online" usw.
Gibt es da eine einfachere Variante, ohne DOIFs entsprechend auf den neuen State anzupassen? Es wäre also gut, wenn der Internal State weiterhin nur on oder off kennt. Sollte aber das Reading LWT auf Offline stehen, dann ein anderes Symbol anzeigen.
Ja, Perl-Variante von devStateIcon nutzen. Das verändert STATE nicht.
Hallo zusammen,
also wenn ich mir das hier so durchlese, stelle ich fest, dass es außer mir
noch eine Menge anderer Nutzer gibt, die mit den internen Abläufen/Strukturen
von Fhem bezüglich der Darstellung von Bedienelementen und Icons so Ihre Probleme haben.
Ich als Einsteiger habe, obwohl ich alle Doku/Unterlagen teilweise auch mehrfach gelesen habe,
so meine Probleme mit den internen Abläufen. Man kann ja alles ausprobieren.
Dies macht aber nur Sinn, wenn man verstanden hat, was FHEM verlangt, um eine bestimmte Funktionalität zu implementieren.
Ist denn mein Eindruck falsch, dass man hier erstmal x-Tausend Posts gelesen/geschrieben haben muss
um hinter die Abläufe/Feinheiten zu blicken?
Wie habt Ihr denn den Zugang/Wissen zu Fhem erlangt?
Geht das nur über Learning by doing und stellen von Fragen?
Fhem ist natürlich kein System ,,Out oft the Box".
Als Beispiel möchte ich hier nur mal die interne Variable STATE anführen
die hier ja mehrfach diskutiert wurde.
Sie wird von diversen Kommandos beeinflusst und beeinflusst selber das Verhalten
der Benutzeroberfläche und Darstellung von Icons.
Natürlich, um Fhem wirklich zu verstehen muss man die Quellen studieren...
Ein anderes Beispiel sind die List-Boxen (setList, webCmd, eventMap).
Sie sind zwar in der Doku genau beschrieben, ihr verhalten ist aber für Einsteiger sehr undurchsichtig.
Oder liege ich mit meiner Einschätzung der Dinge völlig daneben...
Gruß Crania
Das ist m.E. tatsächlich aus Usersicht nicht so einfach zu verstehen. Meinen Versuch, das in einen verständlichen Zusammenhang zu bringen, ist hier nachzulesen: https://wiki.fhem.de/wiki/DeviceOverview_anpassen.
Der andere sind die attrTemplate's (v.a. für MQTT2_DEVICE). Das kann man (fast) 1:1 auf dummy übertragen (v.a. auch, was setList und readingList angeht).
das problem ist aber doch eher das es falsch ist auf STATE zu reagieren. zumal es als internal überhaupt keine events erzeugt.
richtig wäre es auf readings zu reagieren. nicht umsonst erzeugen diese auch events.
STATE ist eigentlich nur für die darstellung in fhemweb. nicht um es in einer automatisierung weiter zu verarbeiten. nicht umsonst ist fhem event basiert.
unabhängig davon: nein, man muss nicht die quelltexte lesen um fhem zu verstehen. ein paar konzepte, wie z.b. die events, reichen. das manche erweiterungen wie z.b. leider auch das DOIF versuchen den anwender von den grundlegenden konzepten abzuschirmen bzw. noch etwas drauf setzen das zwar ähnlich ist aber dann doch nicht genau so ist leider nicht hilfreich. einfach ist nicht immer besser.
Zitat von: Beta-User am 28 November 2019, 07:23:36
Ja, Perl-Variante von devStateIcon nutzen. Das verändert STATE nicht.
Danke, dieser kleine Anstoß hat mir gereicht um genauer nach weiteren Infos zu suchen und ich habe es nun so gelöst bekommen, wie ich es für mich brauchte.
Zur Allgemeinen Diskussion: Für Einsteigern ist FHEM sicherlich sehr sehr kompliziert. Man muss eben klein Anfangen, sehr viel nachlesen und so dann verstehen.
Einen Überblick über sämtliche Funktionen, Module usw. kann man fast gar nicht mehr haben. Oft genug ist es mir schon passiert, dass ich Lösungen gesucht habe, es auch geschafft habe, dass alles so funktioniert wie es soll - und paar Wochen später stoß ich zufällig auf ein ähnliches Problem, dass z.b. durch ein Modul viel einfacher zu lösen gewesen wäre.
Aber genau das finde ich, ist das tolle an FHEM und der Community. Das System ist so offen für alles mögliche und die Community ist einfach nur Spitze, sei es bei sich immer wiederholenden Fragen, bei echten Schwierigkeiten, Feature-Wünschen in Modulen oder generell die Weiterentwicklung.
Ich bin froh, dass ich auf FHEM gesetzt habe und nicht auf eine fertige, einfache Lösung, die vielleicht sogar noch Geld kostet, aber bei weiten nicht so viel könnte.
Gerade in meiner Anfangszeit hatte ich viele viele Fragen, aber mit Hilfe von Google, CommandRef, Forum und auch YouTube-Videos lernt man FHEM schnell kennen finde ich. Auch wenn ich kein Perl programmieren kann (allerhöchstens Codeschnippsel zusammenkopieren und für mich anpassen ;D)
Btw: Ich nutze überwiegend DOIF, weil es das "komplizierte" FHEM für mich einfacher macht als Notifys zu nutzen.
Zitat von: swsmily am 28 November 2019, 16:12:34
Danke, dieser kleine Anstoß hat mir gereicht um genauer nach weiteren Infos zu suchen und ich habe es nun so gelöst bekommen, wie ich es für mich brauchte.
Danke für die Rückmeldung.
Ansonsten klingt das für mich so, als würdest du genau immer wieder in das von justme1968 genannte Problem reinlaufen, dass DOIF (scheinbar) alles einfach möglich macht, du dir den Wolf konfigurierst, bis es (halbwegs) so funktioniert, wie du das vorstellst und dabei übersiehst, dass es für viele "Standardfälle" kleine "Spezialisten" gibt, die bestimmte typische Anwendungsfälle (meistens viel einfacher) abdecken.
Man mag darüber denken, was man will, aber ich für meinen Teil bin froh, dass ich kein DOIF mehr im Einsatz habe; ich bin einfach zu doof für die Syntax, die dieses Modul haben will, und bin früher gefühlt immer wieder in irgendeine Falle gelaufen, nicht selten, ohne das gleich zu merken. (Apropos Syntax: Vermutlich reagiert das fragliche DOIF nicht wegen STATE, sondern auf ein Event von state..., aber das ist pure Spekulation.)
Zwischenzeitlich nutze ich eben für alles mögliche event-basierte in der Regel eine notify+Perl-Variante. Finde ich deutlich übersichtlicher, und meistens macht das dann tatsächlich irgendwann das, was ich will (und in der Regel versuche ich, generalisierte Varianten zu nutzen, also z.B. nur noch ein (kurzes) notify für alle Fenster-open/tilt/closed-Events).
(Und nein, ich konnte früher weder programmieren, noch hatte ich einen Schimmer von Perl (ob das jetzt in den Augen wirklicher Experten wesentlich besser ist, sei mal dahingestellt). FHEM kann man m.E. jedenfalls ohne DOIF aber auch dann nutzen, wenn man bei beidem nur rudimentäre Kenntnisse hat; es reicht, wenn man Kausalitäten zwischen Ursache und Wirkung nachverfolgen kann).
Ich kann mich daher nur der Empfehlung von justme1968 anschließen, sich als FHEM-Nutzer auch und vor allem erst mal mit den grundlegenden Mechanismen zu beschäftigen. Persönlich finde ich auch den Rahmen der commandref immer wieder aufschlußreich: https://fhem.de/commandref_modular_DE.html. Überfliegt man das jeden Monat ein Mal, macht man vermutlich nichts falsch und findet immer wieder was, was man brauchen kann...
Zitat von: Beta-User am 28 November 2019, 16:58:57
ich bin einfach zu doof für die Syntax, die dieses Modul haben will
da bin ich aber froh das ich genau mit diesem Problem doch nicht sooo alleine bin :)
Zitat von: Wzut am 28 November 2019, 17:16:21
da bin ich aber froh das ich genau mit diesem Problem doch nicht sooo alleine bin :)
Da gibt's noch einige mehr ;D ...
Aber wenn man die Syntax drauf hat, scheint es das zu machen, was es soll. An sich also eine echt gewaltige Leistung des Entwicklers, das sei mal an der Stelle ausdrücklich betont!
Ich bin da irgendwann mal vor ein paar Jahren gedanklich ausgestiegen, hatte dann noch ein paar halbherzige Versuche unternommen, und es dann irgendwann aufgegeben. Das waren mir zu viele via Attribut einstellbaren Verhaltensweisen, deren Wechselwirkungen scheinbar nicht mal Experten völlig klar zu sein schienen...
Dann war es einige Zeit still, bis ich mir dann den Ruck gegeben habe, alle DOIF wieder auszubauen. In 3/4 der gut 20 Fälle war das jeweils in wenigen Minuten erledigt, (WeekdayTimer, THRESHOLD, ein paar notify), bei ein paar hat es länger gedauert, aber das auch nur, weil ich zwischenzeitlich ein paar Ideen hatte, wie man das effizienter und generalisierter lösen könnte (auch mittels DOIF kann man generalisieren, ist schon klar).
Wie dem auch sei, der Rest war auch kein Hexenwerk und jetzt weiß ich jedenfalls (halbwegs), wie FHEM tickt und kann in der Regel auch ohne dieses Modul so eingreifen, wie ich das will, ohne groß rumzuraten ;D .
Aber lassen wir das, führt ja nicht weiter.
Mir hat ja des doiftools (https://wiki.fhem.de/wiki/DOIFtools) auf die Sprünge geholfen. Teilweise hab ich aber auch nach längerer Pause auch einfach Knoten im Kopf und kapier erst aufn zweiten Anlauf, was ich schon zusammen gebastelt hab.
Und des ist auch mein tip, nehmt vorhandenes als Template