FHEM Forum

Hallo liebe Leute,

heute habe ich meine HM- Komponenten bekommen (als Bausatz), u.a. den o.g. 6fach Taster und einen 4CH Aktor für Hutschine.
Das läuft auch alles so weit und ich habe es sogar hinbekommen, die Beiden über FHEM zu pairen. So weit, so gut. Allerdings fehlt mir eine wirkliche Rückmeldung vom Aktor an den Taster...

Ich hatte mal die Nummer mit dem virtuellen Aktor versucht (http://www.fhemwiki.de/wiki/HM-PB-6-WM55_6fach-Funk-Wandtaster), aber das funktioniert irgendwie so gar nicht resp. bekomme ich das nicht hin. Macht aber auch nichts, da das ja letztlich nur eine Rückmeldung ist, das FHEM den Befehl verstanden hat. Ob der Befehl tatsächlich am Aktor ausgeführt wurde, ist so ja nicht feststellbar. Aber genau das würde ich gerne erreichen, was mir mangels Wissen einfach nicht gelingen will; ich finde dazu auch nichts, was ich als Beispiel verwenden könnte...

Ich möchte also diesen Weg gerne realisieren:

Taste >> FHEM >> Aktor (klick) >> FHEM >> Taste LED=grün (und auch gerne rot, wenn nach einer gewissen Zeit keine Rückmeldung vom Aktor bei FHEM aufgeschlagen ist).


Was mir noch aufgefallen ist:
Ich habe die Beiden in FHEM via set EG_FL_T6_Btn_01 peerChan 0 KG_ZS_04CH_Sw_01 zusammen gebracht; hat ja auch funktioniert. Nur bedarf es jetzt eines langen Tastendruck, damit der Aktor auch reagiert.

Frage ist also, wie ich dafür sorgen kann, das auch ein kurzer Druck ausreicht?

Denn die langen Tastendrücke möchte ich in Zukunft (wenn ich irgendwann die Kenntnisse beisammen habe...) für Sonderfunktionen nutzen (kurz=Licht dauern/sofort aus, lang=Timer +/- x Sekunden für Leuchtdauer / Abschalten nach).

wenn der taster mit dem aktor gepeert ist, bekommt der taster die rückmeldung direkt vom aktor.
das verhalten des aktors wird mit den registern im aktor für diesen peer konfiguriert.
wenn der funk ausreichend ist, bekommt fhem den zustand vom aktor auch mit. lauschen kann man nicht verbieten.

Zitatwenn der taster mit dem aktor gepeert ist, bekommt der taster die rückmeldung direkt vom aktor.

Ist es nicht, wie gesagt. Läuft über FHEM. Daher muss auch die Quittung über FHEM weitergereicht werden. Das ist die Aufgabe ;)

ZitatIch habe die Beiden in FHEM via set EG_FL_T6_Btn_01 peerChan 0 KG_ZS_04CH_Sw_01 zusammen gebracht;

mir scheint, du weisst nicht, was du tust, denn das nennt man peeren.  :)

... also noch mal ...

Möglichkeit 1:
Ich peere den Sensor (Taster) direkt mit dem Aktor und lasse FHEM nur lauschen

Möglichkeit 2:
Ich peere den Sensor mit FHEM, ich peere den Aktor mit FHEM und FHEM vermittelt zwischen beiden.

Wenn ich Möglichkeit 1 benutzt hätte, würde auch die Quittung kommen; tut sie nicht. Vorher war nur der Aktor in FHEM angelegt und von dort aus steuerbar. Der 6fach-Taster ist erst danach ebenfalls in FHEM angelegt worden. Zu der Zeit "wussten" die Beiden noch nichts voneinander. Also muss doch FHEM der Vermittler zwischen den beiden werden, was ich entweder via "... peerChan ..." oder aber etwas aufwändiger über z.B. "define TA_EG_FL_01 notify EG_FL_T6_Btn_01:trigger:.* set KG_ZS_04CH_Sw_01 off" machen kann.

Der Test, weil Du mich doch gerade ziemlich verunsichert hast: FHEM runterfahren und schauen, ob sich noch schalten lässt... Schidde  :-\ Funktioniert ja immer noch...

Ok, dann habe ich gerade was dazu gelernt  ::)

Aber dann stimmt was anderes nicht. Wenn ich das richtig verstanden habe, sollte nun doch die LED von orange auf grün wechseln, wenn der AKtor den Befehl ausgeführt hat; zumindest habe ich das so rausgelesen... Tut aber nicht...

Und da ich das eigentlich so nicht haben wollte, kommen wir mal zurück auf die gewollte Version 2.
define TA_EG_FL_01 notify EG_FL_T6_Btn_01:trigger:.* set KG_ZS_04CH_Sw_01 off
define TA_EG_FL_01 notify EG_FL_T6_Btn_02:trigger:.* set KG_ZS_04CH_Sw_01 on
Das geht doch sicherlich eleganter, evtl sogar mit Unterscheidung auf short/long/toggle ? Irgendwo hatte ich mal was gelesen, das es eine interne Variable gibt, die man "von vorne nach hinten" weitergeben kann...

Zitat von: frank am 22 November 2015, 00:21:45
mir scheint, du weisst nicht, was du tust, denn das nennt man peeren.  :)

Ich befürchte Frank hat Recht. Es fehlt ein wenig an Hintergrundwissen.
Homematicgeräte mit einer Base verbinden nennt man pairen, das Verbinden untereinander ( immer Sensor mit Aktor ) nennt man peeren. Du kannst ohne weiteres beides machen.
Paire beide Geräte mit FHEM, danach peerst Du den Tasterchannel mit dem Aktor welcher ihn auslösen soll. Wenn Du das gemacht hast löst sowohl ein langer als auch ein kurzer Druck auf den Taster den Aktor aus. Willst Du das nicht mußt Du das gewünschte Verhalten im Register des Aktors unter ActionType einstellen.


Grüße

ZitatIch befürchte Frank hat Recht. Es fehlt ein wenig an Hintergrundwissen.

Ja nun, was erwartet Ihr nach ein paar Tagen meinerseits, in denen ich mich wirklich mit FHEM beschäftige? Ich bin auch keine 30 mehr, habe Familie, Haus, Hof Hund und Katz, die auch Zeit erfordern (und nicht zu knapp). Ok, mit 20 hätte ich den Stoff sicherlich schneller aufgesogen, aber mit über 50 wird das schon merklich langsamer^^

BTW: Wann schläfst Du denn? Oder musstest Du früh raus?

Also... Ich möchte grundsätzlich ein peeren verhindern und nur mit ge-pairten Geräten arbeiten, um die Sache homogen zu halten, zumindest in der ersten Zeit. Daher habe ich gestern alle pairings aufgehoben. Dachte ich zumindest; hat nicht geklappt, auch nicht bei mehrfachem Absenden. Ich habe dann aus Frust die Geräte in den Factoy gesetzt und neu angelegt ...

Noch mal die Frage zu:
define TA_EG_FL_01 notify EG_FL_T6_Btn_01:trigger:.* set KG_ZS_04CH_Sw_01 off
define TA_EG_FL_01 notify EG_FL_T6_Btn_02:trigger:.* set KG_ZS_04CH_Sw_01 on
Das geht doch eleganter irgendwie? Und wie kann ich gleichzeitig die Länge der Tastenbetätigung auswerten? Und wie bekomme ich die LED am Sensor grün auf Grund der Aktor-Quittung (nicht via virtuellem Aktor)?

Wenn ich das alles mit Eurer Hilfe rausgefunden und umgesetzt habe, dann kann ich auch weitermachen, den Kram vom Schreibtisch in den Zählerschrank resp. Hausflur verfrachten und mit weiteren Komponenten auf neue Probleme... ähh Aufgaben stoßen ;)

Zitat von: M_I_B am 22 November 2015, 09:37:03
Ich möchte grundsätzlich ein peeren verhindern und nur mit ge-pairten Geräten arbeiten

Keine gute Idee für eine produktive Umgebung.

Zitat von: M_I_B am 22 November 2015, 09:37:03
Das geht doch eleganter irgendwie?

Nö

Zitat von: M_I_B am 22 November 2015, 09:37:03
Und wie kann ich gleichzeitig die Länge der Tastenbetätigung auswerten?

Schau in den Eventmonitor was an Events ausgelöst wird. Du kannst bei HM Geräten z.B. Long_\d+ auswerten.

Zitat von: M_I_B am 22 November 2015, 09:37:03
Und wie bekomme ich die LED am Sensor grün auf Grund der Aktor-Quittung (nicht via virtuellem Aktor)?

Durch ein Peering - virtuell oder physikalisch.

Zitat von: M_I_B am 22 November 2015, 09:37:03
Ja nun, was erwartet Ihr nach ein paar Tagen meinerseits
...
Wenn ich das alles mit Eurer Hilfe rausgefunden und umgesetzt habe

Das wird nicht gut gehen, glaub es mir. Nimm Ratschläge an (peering), lies die Einsteiger Dokus, Wikis und quer durchs Forum. Wenn Du wenig Zeit hast, dann dauert es halt länger. Aber mit diesem Halbwissen wirst Du mit FHEM nicht glücklich.

Zitat

ZitatIch möchte grundsätzlich ein peeren verhindern und nur mit ge-pairten Geräten arbeiten

Keine gute Idee für eine produktive Umgebung.

Lässt sich in der Masse nicht anders machen. Für eine direkte Verbindung sind die HF- Bedingungen und Entfernungen zu groß. Es gibt schon Probleme vom Hausflur zum im Keller darunter liegenden Zählerschrank; no way...
Da aber überall großzügig CAT7 verlegt ist/wird, ist FHEM der Dreh- und Angelpunkt. Und, falls das eines Deiner Argumente dagegen sein sollte, gegen Stromausfall u.ä. Ungemach sind wir über Tage gesichert (Serverschrank mit 3KW UPS an 480AH Akkus, 4,5KW selbststartender Notstromgenerator, 7000er PV mit Notstromfunktion). Auch der RPi ist mehrfach vorhanden und haben immer den identischen Zustand. Und wenn ich ggf. FHEM auf dem NAS (FreeBSD) zum Laufen bekomme, was ebenfalls zweifach vorhanden ist, kann eigentlich nichts mehr schief gehen.

ZitatSchau in den Eventmonitor was an Events ausgelöst wird. Du kannst bei HM Geräten z.B. Long_\d+ auswerten.

Jau, stimmt auffallen ;) Zu viel Bäume im Wald ^^

Zitat

ZitatUnd wie bekomme ich die LED am Sensor grün auf Grund der Aktor-Quittung (nicht via virtuellem Aktor)?

Durch ein Peering - virtuell oder physikalisch.

Kann ich nicht nachvollziehen. Nach meinem Verständnis muss das auch anders gehen. Immerhin sendet der gepairte Aktor ein ACK an FHEM zurück, was ja von FHEM ausgewertet wird. Dieses ACK kann ich doch hernehmen und als ACK an den Sensor weitergeben?! Die Frage ist halt nur (für mich im Moment), wie das auf Softwareseite gemacht wird.

ZitatDas wird nicht gut gehen, glaub es mir. Nimm Ratschläge an (peering), lies die Einsteiger Dokus, Wikis und quer durchs Forum. Wenn Du wenig Zeit hast, dann dauert es halt länger. Aber mit diesem Halbwissen wirst Du mit FHEM nicht glücklich.

Ich nehme Ratschläge gerne entgegen und setze die auch oft um, aber dennoch will und muss ich verstehen, was da im Hintergrund abläuft und wie was zusammen hängt. Nur dann kann ich irgendwann vollkommen selbstständig arbeiten und ggf. neue Wege kreieren, auf die noch keiner gekommen ist. Copy&Past mag ja am Anfang gut helfen, nutzt aber nichts, wenn man den Kern nicht erfassen kann. Und genau das mündet dann in dem von Dir genannten Halbwissen.
Ich will mal einen Vergleich benennen:
Jeder, der einen Lötkolben an der richtigen Seite anfassen kann, ist in der Lage, den Bausatz eines z.B. Röhrenverstärkers zusammen zu bauen und erfolgreich in Betrieb zu nehmen. Dennoch hat derjenige oft keinen Plan, wie genau eine Röhre funktioniert und wie was miteinander zusammen hängt. Damit ist er auch nicht in der Lage, eigene Änderungen einzubringen. Lediglich wenn ihm wer sagt, "tausche R17 und R18 gegen 230kR und überbrücke R18 mit einem 10nF/400V MKT", kann er Erfahrungen anderer einbringen, was umgesetzt auf FHEM dem Copy&Past entspricht.

vielleicht ist dein denkfehler das mit dem ack das erfolgreiche ausführen eines kommandos bestätigt wird.

es wird aber nur der erfolgreiche empfang bestätigt und nicht irgendetwas das nach dem empfang ausgelöst wird. das ack wird auch sofort nach dem empfang und je nach io sogar schon in der firmware und ohne beteiligung von FHEM zurück gesendet.

das was du dir vorstellst geht mit homematic nicht. und wenn du noch FHEM zwischen die geräte setzt erst recht nicht.

gruss
  andre

Jup wollte ich auch gerade schreiben.

Kurz zu meinem Frühstart. Ich habe Hof, Haus, drei Kinder und Frau die Sonntag Morgen um 4 raus muß zur Arbeit  :)

Meine Aussage das Frank Recht hat sollte kein Angriff sein sondern Dich nur darin bestärken zu erkennen das DeinWeg nicht falsch, aber eben auch nicht Vorteilhaft ist. Es gibt hier Leute die sind 20 haben aber nunmal mehr Erfahrung mit Homematic. Vertrau deren Aussagen, wir machen es eventuell mit einer Deiner Lebensaussagen auch mal.
So und weiter. André hat es Dir schon gesagt was das Quittieren an geht.
Bei Deiner Ausstattung sollte es kein Problem sein mehrere HMLan Adapter ans laufen zu bekommen, so kannst Du die Distanzen Überbrücken. Mach alles was geht mittels pairing und peering. Denn nur so kannst Du auch Licht an machen wenn FHEM mal stockt. Glaub mir, Abends im dunkeln in den Keller gehen weil mal kurz FHEM hustet ist kacke und macht Aua.

Meine Empfehlung wenn schon so viel Cat liegt. 2-3 HMLan Adapter ran an FHEM und gut ist. Wie man das am besten mit mehreren macht liest Du und kannst dann noch mal fragen.


Grüße

Zitatvielleicht ist dein denkfehler das mit dem ack das erfolgreiche ausführen eines kommandos bestätigt wird.

Ne ja doch, schon klar. Kann ja auch nicht so ohne weiteres, ohne deutlich mehr Hardwareaufwand zu generieren. Aber das ACK als Quittung, das der Befehl am Ziel angekommen ist, reicht ja meist schon.

Zitatdas was du dir vorstellst geht mit homematic nicht.

Das ist natürlich ein Argument; schade eigentlich, denn damit könnte man noch ein paar weitere sinnvolle Aktionen generieren.

Heißt also im Klartext, das ich im Moment die LED des 6fach- Tasters nicht grün bekomme; virtueller Aktor hat ja nicht funktioniert und auch während des (versehentlich) erzeugten peering hatte ich keine "grüne" Rückmeldung

Zitat2-3 HMLan Adapter ran an FHEM und gut ist.

Ja, so dachte ich mir das in Zukunft, auch wenn es wohl eher 5 werden ^^. Mit den SCC's bin ich bekanntermassen eh unzufrieden. Arbeiten die HMLan dann beim peering als transparente Repeater? Und kommt ggf. in naher Zukunft ein HMLan mit PoE? Das würde echt Sinn machen...

Und da wir gerade dabei sind, obwohl an anderer Stelle schon mal gefragt: Gibt es für 433MHz (SlowRF/IT) ein vergleichbares "UFO" wie den HMLan, also Anbindung über LAN und ggf. PoE?

Hallo,

also mehrere HMLAN -> VCCU. Die Virtuelle CCU hat dann viele IO Devices (eben die HMLAN) und kümmert sich selber darum, über welchen HMLAN gesendet werden soll. Das kann man zwar noch am Gerät zusätzlich einstellen - würde ich aber am Anfang nicht machen. Es ist schon richtig, das peers über große Distanzen nicht funktionieren. Hier hat HM einen Repeater auf 230V herausgebracht. An den müssen die Geräte, die sich sonst nicht verstehen angemeldet werden. Er gibt die Befehle dann einfach weiter.
Für den "normalen" Aufbau sollte das meiste aber mittels peering gehen - es sei denn Du möchtest vom Dachboden das Licht im Keller einschalten  ;).

Gruß Christoph

ZitatHeißt also im Klartext, das ich im Moment die LED des 6fach- Tasters nicht grün bekomme; virtueller Aktor hat ja nicht funktioniert

wenn das nicht funktioniert, stimmt etwas nicht.

fang am besten bei einem io auch gleich mit einer vccu an und nimm diese auch zum peeren des tasters. dann wird die led auch grün.

es gibt glaube ich einen rfxtrx mit 433mhz und netzwerk. die dinger sind aber ziemlich teuer. ich mach das per raspberry pi und mincul und ser2net. funktioniert wunderbar und zuverlässig auch mit mehreren ios. an die raspberry pi pro stockwerk bzw zimmer sollen noch bluetoth module für presence erkennung und kleine bluethoth taster um die sonos lautstärke zu regeln und etwas zur sound ausgabe in den räumen in denen kein sonos player steht. für die lautstärke regelung ist hm zu träge. den mehrfach nutzen hast du mit einem rfxtrx nicht.

statt dem hmlan kannst du auch einen hm config usb am raspberry verwenden falls vorhanden. manche bevorzugen den und günstiger ist er auch.

@Christoph:

ZitatFür den "normalen" Aufbau sollte das meiste aber mittels peering gehen - es sei denn Du möchtest vom Dachboden das Licht im Keller einschalten

... so ähnlich ;) In diesem Haus ist mit HF über 100MHz kaum was zu machen. Sobald da eine Wand zwischen ist, ist schon fast essig. Daher wird auch komplett und großzügig mit CAT7 verkabelt, das diese Einschränkungen natürlich auch WLAN & Co. betreffen. Ausserdem gibt es noch einige Nebengebäude am anderen Ende des nicht gerade klein zu nennenden Grundstückes. Hinzu kommen, natürlich hauptsächlich am Tage, massive Störungen durch die Wechselrichter und Speicher unserer eigenen PV und jene der Nachbarn... Summa summarum "anstrengend" ;)

@Frank

Zitatwenn das nicht funktioniert, stimmt etwas nicht.

Tja, wem sagst Du das^^ Ich habe ungezählte Versuche gestartet mit dem VirtAktor. Aber auch bei der direkten Version hat das nicht hingehauen; vielleicht hat ja der Taster einen Schuß weg?

@justme1968
... ich werde mal schauen, ob ich ggf. mehrere PI's einsetze. Aber Anwesenheit per BT kannst Du hier vergessen; siehe oben...
(... vielleicht könnte man den RXTX aus dem HMlan ausbauen und gegen ein 433er Modul tauschen resp ein 433er RXTX zusätzlich einbauen; wird wohl nicht so ohne weiteres funktionieren ohne patchen der FW, aber die Idee finde ich gut *fg*)

ein pi pro raum und du hast presence gleich auf zimmer ebene.

Zitat von: justme1968 am 22 November 2015, 13:16:27
ein pi pro raum und du hast presence gleich auf zimmer ebene.

LOL ok, aber das wird teuer ;) Ausserdem haben wir es nicht so wirklich mit SmartPhones. Unsere MiniZicke schon, aber meine Frau hat ihr SP fast nie im Haus dabei und meines liegt i.d.R. auch nur im Büro. Das muss ich anders lösen (Raumvolumenmessung, Infraschall, Induktionsschleifen in den Türrahmen, was auch immer)

rfid chip einpflanzen. das ist das einzige was wirklich zuverlässig wäre :)

... jau, aber das muss ich dann machen, wenn meine Zicken im Koma liegen, sonst gibbes Megger ;)
Vielleicht eine Halskette oder (Uhren-) Armband mit RFID... Aber die Dinger haben auch das Problem, das Reichweite nicht wirkich vorhanden ist. Man könnte zwar mit Spulen im Türrahmen erkennen, wer gerade den Raum betritt oder verlässt, aber mir würde es reichen, wenn man feststellen kann, das ein Raum belegt ist oder nicht. Und dafür reichen die Spulen im Türrahmen vollkommen aus, einen Durchgang mit Richtungserkennung zu generieren; geht auch mit je zwei kleinen Lichtschranken / Tür, welche aber bei Vorhandensein von Haustieren hoch genug montiert werden sollten. Da ist die durch Körpermasse erzeugte Verstimmung von Schwingkreisen aussagekräftiger (sowas hab ich auf'm Schirm..)

ich glaube das keine lichtschlanken lösung zuverlässig genug ist um damit irgendetwas zu automatisieren. ausser du baust dir auch gleiche eine schleuse die immer nur eine person durchlässt.

eine wirklich zuverlässige automatische raum belegungs erkennung ist eine der eine wirkliche herausforderung.

eine kamera oben in jedem türrahmen  die auch noch den bereich davor und dahinter überwacht bekommt das reine zählen vermutlich am zuverlässigsten hin. bei dem blickwinkel ist dann aber die identifizierung schwierig.

... sooo schlimm wie Du meinst ist das nicht. Das mit der Lichtschranke hatte ich in unserem alten Haus schon gemacht und war sehr zuverlässig. Es kommt in einem Privathaus eher selten vor, das zumindest Erwachsene sich gemeinsam durch die Tür quetschen (ab einer gewissen Leibesfülle eh ausgeschlossen). Ich kann mich nur an einen "Verzähl- Tag" erinnern; Kindergeburtstag ^^ Wenn man das ggf. noch mit Daten von Bewegungsmeldern verknüpft, sollte das ziemlich zuverlässig sein.
Die Nummer mit den zwei Spulen in jedem Türrahmen ist da deutlich präziser, da die "Verstimmung" im direkten Zusammenhang mit der Masse steht, die sich durch das Feld bewegt; zumindest meine Versuche dazu vor ein paar Jahren waren recht vielversprechend. Natürlich hat das auch einen Haken: Es wird ständig ein magnetisches HF-Feld generiert, bei mehreren Türen ohne synchronisierte Oszillatoren bilden die Felder dann auch noch Interferenzen und Harmonische aus... Das will nicht jeder haben...

du sprichst genau das problem  der lichtschranken an. kinder :)
ich kann dir garnicht sagen wie oft meine kleine sich noch mit durch die türen geht.

wenn du eine zuverlässige und nachrüstbare erkennund schaffst bin ich sehr interessiert.

Zitatwenn du eine zuverlässige und nachrüstbare erkennund schaffst bin ich sehr interessiert.

Selbstverfreilich... So bald ich meine Elektronik-Werkstatt in diesem neuen Haus am Start habe (so lange Wetter war, war "Haus- und Hof" angesagt), werden auch alte und liegengelassene Projekte wieder aktiviert, so bald ich den Reparatur- und Restaurations- Stau abgearbeitet habe.

... ok, ich bekomme die grüne LED mit dem virtuellen AKtor nicht ans Laufen >:(

Habe so getan:
define Virt_Actor CUL_HM 000001
attr Virt_Actor IODev SCC2
attr Virt_Actor expert 2_full
attr Virt_Actor model virtual_1
attr Virt_Actor subType virtual
attr Virt_Actor webCmd virtual
define Virt_Taster CUL_HM 00000101
attr Virt_Taster model virtual_1
attr Virt_Taster peerIDs 3AF9D601,3AF9D602,3AF9D603,3AF9D604,3AF9D605,3AF9D606,
attr Virt_Taster webCmd press short:press long

Die peerIDs entsprechen den IDs der einzelnen Tasten; mehrfach überprüft.

Hier der Kopfteil mit der ersten Taste:
define EG_FL_6CH CUL_HM 3AF9D6
attr EG_FL_6CH .devInfo 060000
attr EG_FL_6CH .stc 40
attr EG_FL_6CH IODev SCC2
attr EG_FL_6CH alias 6fach Taster, Hausflur, Aussenlicht
attr EG_FL_6CH autoReadReg 4_reqStatus
attr EG_FL_6CH expert 2_full
attr EG_FL_6CH firmware 1.2
attr EG_FL_6CH model HM-PB-6-WM55
attr EG_FL_6CH peerIDs 000001
attr EG_FL_6CH room EG Hausflur
attr EG_FL_6CH serialNr MEQ0443617
attr EG_FL_6CH subType remote
attr EG_FL_6CH webCmd getConfig:clear msgEvents

# Taste 1
define EG_FL_6CH_CH1 CUL_HM 3AF9D601
attr EG_FL_6CH_CH1 model HM-PB-6-WM55
attr EG_FL_6CH_CH1 peerIDs 00000101
attr EG_FL_6CH_CH1 room EG Hausflur

... und warum zur Hölle geht das nicht? WO mache ich da meinen Denkfehler?

Zitat... und warum zur Hölle geht das nicht? WO mache ich da meinen Denkfehler?

kann es sein das du die attr peerIDs selber gesetzt hast? peeren musst du immer mit peerchan, das erzeugt auch die attr.

Schreibe mal genau wie Du peerst. Also den genauen Befehl!

... ne, die peerIDs sind nicht von mir gesetzt worden. Ich habe die nur kontrolliert, ob die passen; tun sie ja.

Peering: set EG_FL_6CH_CH1 peerChan 0 Virt_Taster dual set

EDIT sagt:
Ich habe die ganzen peerings mal mit unset gelöscht, Taste kurz angetippt (blinkblink orange), dann fhem neu gestartet, die peerings neu gesetzt (drei mal für 1, 3 und 5), config gespeichert, nachgeschaut ob die peerID's wiede da sind (ja, sind sie) und dann nochmal klick auf die Taste (blinkblink orange), GetConfig, ...

Nun habe ich immerhin bei Taste 1 und 2 eine rote LED, also kurz orange und dann länger rot. Die anderen Tasten wie gehabt orange ?!?

Hast Du die Seite gelesen?

http://www.fhemwiki.de/wiki/HM-PB-2-WM55_2fach-Funk-Wandtaster (http://www.fhemwiki.de/wiki/HM-PB-2-WM55_2fach-Funk-Wandtaster)

ZitatIch habe die nur kontrolliert, ob die passen; tun sie ja.

nicht so ganz.

1. bei mir gibt es in keinem device (parentchannel) ein attr peerids. bei dir im schalter-device.
2. in allen gepeerten realen channels gibt es bei mir zusätzlich den peer 00000000.

was ergibt denn ein get hminfo configCheck?
ansonsten sniffe mal die rawmessages nach wiki homematc sniffen.

@CoolTux
Ja, genau das war meine Vorlage. Zum hier verwendeten 6er gibt es auch eine Seite, die ich mitverwendet habe

@Frank
zu 1. Jo, habe ich aber nicht angelegt ?!?
zu 2. ... nach dem erneuten peeren bei mir auch

Zitatget hminfo configCheck

? Wo gehört denn das hin?

hminfo ist ein extra modul. erst definieren. zb:

define hminfo HMinfo

edit: zu 1. das attr im device würde ich mal löschen.

Zitat
Peering: set EG_FL_6CH_CH1 peerChan 0 Virt_Taster dual set

Hast Du mal single statt dual probiert? Und dann am Taster noch mal den korrekten Button drücken

... ok, habe ich gemacht. Dann hat mir FHEM in die fhem.conf diverse Zeilen geschrieben:
define hminfo HMinfo
attr hminfo sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed
attr hminfo sumStatus battery,sabotageError,powerError,motor
attr hminfo webCmd update:protoEvents short:rssi:peerXref:configCheck:models
Ich hoffe, das muss so?!? Nach Neustart aber kennt der das Kommando immer noch nicht:
Unknown command hminfo, try help.

Ansonsten habe ich jetzt das peering komplett gelöscht (mehrfach zur Sicherheit), den virtuellen Aktor komplett aus der CFG gelöscht, ebenso wie die Zeilen mit den IDs aus der 6fach-Taster-Definition. Nach Neustart und Tastendruck am Sensor (das Ganze mehrfach wiederholt) schreibt mit fhem immer wieder zumindest in einen Teil der Tasten die IDs, die LED kommt immer wieder mit rot bei Taste 1-3 (eine dazu gekommen).

Irgendwie ist nun alles verquer und ich komme nicht mehr zum Ausgangszustand zurück, um von vorne zu beginnen... Ausser vielleicht den Sensor komplett löschen und auf Factory resetten...

ZitatIch hoffe, das muss so?!? Nach Neustart aber kennt der das Kommando immer noch nicht:

das passt so. vielleicht kein save gemacht und die definition ist wieder weg.

... ich gebe auch  >:( >:( >:(
Habe jetzt den HM-PB-6 auf Factory gesetzt und in der CFG gelöscht. rereadcfg und neu eingepflegt.
Anschließend über die GUI einen virtuellen Aktor erstell mit 3 Kanälen (je einen für 1/2, 3/4, 5/6) erstellt und die Tasten jeweils einzeln (auch dual probiert) gepeert wie folgt:
define VirtualDevice CUL_HM FFFFFF
set VirtualDevice virtual 3
rename VirtualDevice_Btn1 VirtualTaster1
rename VirtualDevice_Btn2 VirtualTaster2
rename VirtualDevice_Btn3 VirtualTaster3

set EG_FL_6CH_CH1 peerChan 0 VirtualTaster1 single set
set EG_FL_6CH_CH2 peerChan 0 VirtualTaster1 single set
set EG_FL_6CH_CH3 peerChan 0 VirtualTaster2 single set
set EG_FL_6CH_CH4 peerChan 0 VirtualTaster2 single set
set EG_FL_6CH_CH5 peerChan 0 VirtualTaster3 single set
set EG_FL_6CH_CH6 peerChan 0 VirtualTaster3 single set
set EG_FL_6CH getConfig
Anschließend einen Klick auf die Anlerntaste > blinkblinkblink...orange... grün. Anschliessend noch mal ein getConfig... geht nicht  :(

Taste 1,2 und 5 werden grün quittiert, die anderen Tasten nicht.

Wenn ich nach kurzer Zeit wieder über die GUI die einzelnen Tasten betrachte, stehen die peerIDs bei einigen Tasten wieder auf "00000000" und nicht auf "000000,FFFFFF02" z.b. Dann lösche ich das attr über die GUI speichere die config, lege eine neue peerID korrekt an, aber wenn ich dann wieder reinschaue, ist sie wieder falsch...

Es juckt FHEM auch nicht, wenn ich die CFG manuell per Notepad++ ändere und die Config neu einlese resp reboote.

Fragen:

1.
Gibt es eine Möglichkeit, alle je gesetzten peerings global zu löschen, notfalls durch löschen einer Datei? Denn irgendwo muss FHEM ja den quatsch herholen...

2.
Kann ich in der GUI im Eingabefeld auch eine Datei angeben, in der die Befehle stehen, so nach dem Schema "execute /opt/fhem/macro1.txt" ? Denn so wie es ausschaut, werden direkt eingegebene Befehle anders behandelt als jene aus der fhem.cfg

irgendwie hast du das homematic system noch nicht wirklich verstanden.

also, alle configdaten (register, pairing und peering) werden im eeprom der devices gespeichert. in fhem existiert dann das abbild des realen gerätes, das device (eventull mit channels). die daten vom gerät und abbild müssen/sollten immer synchron sein. mit getconfig werden sämtliche daten ausgelesen und in fhem dargestellt. nur nach einem erfolgreichen getconfig kannst du sicher sein, dass die device daten den gerätedaten entsprechen. und nie vergessen save config klicken, damit die fhemdaten auch überleben.

beim peeren (peerchan) werden also befehle an 2 reale geräte gesendet. in deinem aktuellen fall ist ein gerät komplett virtuell. diese daten sind natürlich nur in fhem. alle relevanten daten sind im normalfall also im eeprom. deswegen kannst du nur mit reset alles löschen. werkseinstellungen. über hminfo gibt es auch möglichkeiten, komplette konfigurationen zu speichern/laden/restaurieren etc.

... das habe ich schon verstanden, aber genau da scheint das Problem her zu kommen.
Ich ändere die Daten für das peering und versuche über getConfig die Sache wieder syncron zu bekommen (save config versteht sich von selber). Aber irgendwann ändern sich aus mir unerfindlichen Gründen die Daten in FHEM und stimmen dann nicht mehr mit den Daten im EEPROM überein.
Wenn ich also ein peering herstelle zwischen einem Sensor und einem Virtuellen, dann aber dieses peering mit unset lösche, so sollte das doch ebenso im EEPROM gelöscht sein mit allen Daten, die zu diesem peering gehören. Und genau das scheint nicht zu funktionieren... Ich weiß nicht, wie ich es anders erklären soll, was hier vorgeht...

Zitatüber hminfo gibt es auch möglichkeiten, komplette konfigurationen zu speichern/laden/restaurieren etc.

Nett, wenn denn hminfo bei mir mal laufen würde (siehe ein paar Beiträge zuvor). Aber wenn, kann man dann diese runtergeladenen Konfigurationen editieren und zurückschreiben?

Morgen mache ich noch mal ein Factory bei dem Sensor und dann noch mal alles von vorne über vorbereitetes Macro

Ich geh jetzt schlafen; Faxen dicke für heute >:(

Hallo,

ZitatWenn ich also ein peering herstelle zwischen einem Sensor und einem Virtuellen, dann aber dieses peering mit unset lösche, so sollte das doch ebenso im EEPROM gelöscht sein mit allen Daten, die zu diesem peering gehören.

Wenn Du danach am Gerät den Configknopf drückst - ja. Sonst bekommt das Gerät die Änderungen bzw den unset nicht mit. Der ist zunächst nur in fhem - liegt im Stapel der zu sendenden Informationen zum Gerät. Manche Geräte arbeiten so etwas automatisch ab (230V Geräte) manche Batteriegeräte fragen nach einem Senden von Informationen ob es etwas neues gibt und bei manchen (z.B. Fernbedienungen) muss die Configtaste am Gerät gedrückt werden.

Gruß Christoph

ZitatWenn Du danach am Gerät den Configknopf drückst - ja.

Ja, ist klar. Ich habe es nur nicht jedesmal explizit erwähnt. Ich gehe davon aus (steht nämlich nirgendwo), das nach Tippen der P-Taste die vielen kurzen orangen Blinks gefolgt von einem langen grünen Blink die erfolgreiche Übertragung signalisieren. Tippe ich danach nochmal auf die P-Taste, blinkt es nur noch grün. Und da die Farbe Grün für mich das SIgnal für "alles schön" ist (ausser bei entsprechender Gesichtsfarbe), sollte das passen.

BTW: HMinfo läuft jetzt bei mir!

define hminfo HMinfo funktioniert (bei mir) nicht,
define hm HMinfo
define hmi HMinfo
define hmin HMinfo
define hminf HMinfo funktioniert.
Offensichtlich darf der Name der Definition nicht mit dem des Moduls überein stimmen. Ich habe es mehrfach ausprobiert; ist bei mir reproduzierbar.

Nun kann ich "Fehler" liefern:
configCheck done:

missing register list
    BU_TT_8CH: RegL_00:
    BU_TT_8CH_CH1: RegL_01:
    BU_TT_8CH_CH2: RegL_01:
    BU_TT_8CH_CH3: RegL_01:
    BU_TT_8CH_CH4: RegL_01:
    BU_TT_8CH_CH5: RegL_01:
    BU_TT_8CH_CH6: RegL_01:
    BU_TT_8CH_CH7: RegL_01:
    BU_TT_8CH_CH8: RegL_01:

peer list incomplete. Use getConfig to read it.
    incomplete: BU_TT_8CH_CH1:
    incomplete: BU_TT_8CH_CH2:
    incomplete: BU_TT_8CH_CH3:
    incomplete: BU_TT_8CH_CH4:
    incomplete: BU_TT_8CH_CH5:
    incomplete: BU_TT_8CH_CH6:
    incomplete: BU_TT_8CH_CH7:
    incomplete: BU_TT_8CH_CH8:
    incomplete: EG_FL_6CH_CH1:
    incomplete: EG_FL_6CH_CH2:
    incomplete: EG_FL_6CH_CH3:
    incomplete: EG_FL_6CH_CH4:
    incomplete: EG_FL_6CH_CH5:
    incomplete: EG_FL_6CH_CH6:
    incomplete: KG_ZS_4CH_CH1:
    incomplete: KG_ZS_4CH_CH2:
    incomplete: KG_ZS_4CH_CH3:
    incomplete: KG_ZS_4CH_CH4:

PairedTo missing/unknown
    BU_TT_8CH

PairedTo mismatch to IODev
    EG_FL_6CH paired:0x000000 IO attr: -.
    KG_ZS_4CH paired:0xF10000 IO attr: -.

templateCheck:

Warum die 8CH-Aktor-Platine nun auch stresst, weiß ich nicht. Ein getConfig ändert daran nix. Ich bekomme die Tage aber noch eine zweite 8CH-Aktor so wie das dazu passende Sensor-Pendant. Aber das hat ja nix mit den aktuellen Ärgernissen zu tun, im Gegensatz zu ...
PairedTo mismatch to IODev
    EG_FL_6CH paired:0x000000 IO attr: -.
    KG_ZS_4CH paired:0xF10000 IO attr: -.
EG_FL... ist der 6fach Taster HM-PB-6-WM55, KG_SZ... der 4fach Aktor für Hutschine HM-LC-Sw4-DR. Letzterer hat noch nie Probleme gemacht und funktioniert immer noch schmerzfrei.
Wie bekomme ich die Fehler weg?

... so, habe noch mal alles von NULL aus neu gemacht:

Alle Aktoren und Sensoren auf Faktory, Einträge dazu in der CFG gelöscht (weggesichert), 4fach Aktor gepeert, 8fach Aktor gepeert, 6fach Taster gepeert.

Dann der Reihe nach folgendes in die GUI eingegeben, wobei ich nach JEDEM Schritt "SAVE CONFIG" (SC) geklickt habe so wie nach jedem peerChan "SAVE CONFIG" (PT) und P-Taste am Sensor, was im Folgenden in eckigen Klammern dargestellt ist:

define VirtualDevice CUL_HM FFFFFF [SC]
set VirtualDevice virtual 3 [SC]
rename VirtualDevice_Btn1 VirtualTaster1 [SC]
rename VirtualDevice_Btn2 VirtualTaster2 [SC]
rename VirtualDevice_Btn3 VirtualTaster3 [SC]

set EG_FL_6CH_CH1 peerChan 0 VirtualTaster1 single set [SC] [PT]
set EG_FL_6CH_CH2 peerChan 0 VirtualTaster1 single set [SC] [PT]
set EG_FL_6CH_CH3 peerChan 0 VirtualTaster2 single set [SC] [PT]
set EG_FL_6CH_CH4 peerChan 0 VirtualTaster2 single set [SC] [PT]
set EG_FL_6CH_CH5 peerChan 0 VirtualTaster3 single set [SC] [PT]
set EG_FL_6CH_CH6 peerChan 0 VirtualTaster3 single set [SC] [PT]
set EG_FL_6CH getConfig [SC] [PT]
set EG_FL_6CH getConfig

Die ganze Nummer hat folgendes inder CFG angelegt:
define VirtualDevice CUL_HM FFFFFF
attr VirtualDevice IODev SCC2
attr VirtualDevice model virtual_3
attr VirtualDevice subType virtual
attr VirtualDevice webCmd virtual
define VirtualTaster1 CUL_HM FFFFFF01
attr VirtualTaster1 model virtual_3
attr VirtualTaster1 peerIDs 3AF9D601,3AF9D602,
attr VirtualTaster1 webCmd press short:press long
define VirtualTaster2 CUL_HM FFFFFF02
attr VirtualTaster2 model virtual_3
attr VirtualTaster2 peerIDs 3AF9D603,3AF9D604,
attr VirtualTaster2 webCmd press short:press long
define VirtualTaster3 CUL_HM FFFFFF03
attr VirtualTaster3 model virtual_3
attr VirtualTaster3 peerIDs 3AF9D605,3AF9D606,
attr VirtualTaster3 webCmd press short:press long

define ActionDetector CUL_HM 000000
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

Taste 1 und 2 werden grün, alle anderen nicht (schalten aber den Aktor)
Ein Blick unter "Everything" zeigt, das lediglich die Tasten 1 und 2 an das VD melden:
ActionDetector  alive:0 dead:0 unkn:0 off:0
EG_FL_6CH_CH1  Short (to VirtualDevice)
EG_FL_6CH_CH2  Short (to VirtualDevice)
EG_FL_6CH_CH3  Short (to SCC2)
EG_FL_6CH_CH4  Short (to SCC2)
EG_FL_6CH_CH5  Short (to SCC2)
EG_FL_6CH_CH6  Short (to SCC2)
VirtualTaster1     OFF  press short  press long
VirtualTaster2     ???   press short  press long
VirtualTaster3     ???   press short  press long

Gehe ich jetzt auf eine der Tasten 3-6, lösche das attr fpr peerIDs [SC] und lege es neu an [SET][SC] und übernehme die Daten in den Taster [PT], wird das zwar korrekt in der fhem.cfg gelöscht und neu angelegt, aber ansonsten ändert sich nichts.

 8) 8) 8) 8) 8) 8)

Taste 3-6 peerChan unset [PT]
Taste 3-6 peerChan set [PT]

Und nun geht's auf einmal. Offensichtlich braucht das Teil massive Überredungskunst, um die config zu verdauen...

**frech** Oder etas Zeit und Geduld. Ist halt nicht das jüngste. Aber das kennst ja bestimmt     ;D **/frech**

Aber schön das es nun geht. Vorallem macht das ja auch einem selber wieder Mut.



Grüße

... keine Bange ... Ich habe ein seeeeehhhr dickes Fell ;)

ZitatVorallem macht das ja auch einem selber wieder Mut.

Hmmm... Ich weiss nicht so recht, ob mir das Mut machen soll oder Angst. Denn wenn sich jedes HM-Teil so heftig rumzickt, dann bin ich in Jahren noch nicht durch mit der Sache. Ich kann im Moment auch ums Verrecken nicht nachvollziehen, warum z.B. die ersten beiden Tasten auf Anhieb das gemacht haben, was gefordert war, die anderen vier aber erst nach intensiver Bearbeitung mit der großen Hammer...

Kommen wir zur nächsten Aufgabe (DuckUndWech)?!
Anfänglich hatte ich das schon mal angesprochen, aber das ist ob des ganzen Ärgers erstmal in den Hintergrund gegangen und kommt nun wieder heraus gekrochen...
Wie muss ich es anstellen, wenn ich die Länge der Tastendrücke unterscheiden möchte? Damit möchte ich folgendes machen:

Wenn ich die jeweiligen Tasten nur kurz antippe, soll der Aktor stumpf EIN resp. AUS schalten.
Wenn ich die EIN Taste lang betätige, soll der Kanal für xy Sekunden eingeschaltet werden und dann ausgehen. Das soll auch gelten, wenn der Kanal schon per kurz eingeschaltet ist. Betätige ich wärend der Ablaufzeit die Taste ein zweites mal lang, sollen zur vorhandenen Zeit xy Sekunden addiert werden, betätige ich noch mal lang, ....
Beispiel:
kurz = an / 1te lang = an für 3 Minuten / 2te lang 15 Minuten / 3te lang 60 Minuten

Die AUS- Tasten sollten ähnlich funktionieren, allerdings rückwärts, um (versehentlich) zu hoch gesetzte Zeiten zu verringern

Also Aufgabe wäre demnach, erst einmal die Unterscheidung der Tastendrucklängen zu gestalten und davon abhängig dann die Zeiten zu generieren.

BTW: Ich hatte sowas mal in ähnlicher Art vor Jahren mit Bascom auf einem AVRtiny realisiert für ein Treppenhaus (Ein Taster, erster Druck 3min., wobei die Druckzeit keine Rolle spielt, 2ter Druck für mehr als 5sec = Basiszeit * 2, kurzer Druck wenn in Betrieb AUS nach 10sek. Warnung bei 9 und 3 sek durch kurzes Lichtflackern)

Also genau so wie Du es haben möchtest geht es meines Wissens in der Tat nur mittels FHEM und Perlcode. Das wirst Du über die angesprochenden Register nicht realisieren können. Da kannst Du nur sagen welcher Aktor auf welchen Kanal und welchem Druck reagieren soll. Also lang oder kurz halt.

ZitatDa kannst Du nur sagen welcher Aktor auf welchen Kanal und welchem Druck reagieren soll. Also lang oder kurz halt.

Naja, das wäre ja der erste Schritt zum Üben; gibt es dazu was zu lesen, wie man die Tastlängen auseinander fusselt? Deshalb hatte ich mir ja explizit den kleinen 8fach Aktor gekauft, sozusagen als weiteres Ziel zum Experimentieren und üben.

BTW: Wenn ich FHEM neu starte, zeigen die Aktoren auf allen Kanälen "???". In der GUI kann ich ja für jeden Kanal auf "statusRequest" klicken. Geht das irgendwie automatisch innerhalb der CFG? Der Versuch mit Eingabe in die GUI-Kommandozeile like "set [Gerät oder Kanal] statusRequest" funktioniert ja nicht.

http://www.fhemwiki.de/wiki/Homematic_Peering_Beispiele (http://www.fhemwiki.de/wiki/Homematic_Peering_Beispiele)

Schlagwort "ActionType"

ahhh ... Eine Insel mit zwei Bergen ;)
Da werde ich mich mal dran machen; vielen Dank!

Also würde ich aus meinem jetzigen Verständnis den Aktor anweisen, nur auf SHORT zu reagieren. Dann lege ich einen virtuellen Aktor an, der pro Kanal auf LONG reagiert, generiere damit einen Timer und schalte damit den echten Aktor... Also SHORT direkt, LONG über VA. So in etwas?

Das sollte gehen.
Ich hatte es auch eine Zeit lang so das der Actor auf Short und Long reagiert hat und habe ein notify gemacht das auf short er einen on-for-timer machen soll. Das hat auch geklappt. Licht ging an und nach 15 Minuten wieder aus. Wenn FHEM mal weg ist bleibt das Licht halt immer an    ;D

ZitatIch kann im Moment auch ums Verrecken nicht nachvollziehen, warum z.B. die ersten beiden Tasten auf Anhieb das gemacht haben, was gefordert war, die anderen vier aber erst nach intensiver Bearbeitung mit der großen Hammer...

um zu erkennen, ob ein befehl verarbeitet wurde, gibt es immer im parent device, die internals des com-protokolls. da sollte mindestens cmds_done erscheinen. ausserdem keine pending cmds, sonst nochmal am configtaster drücken.

ein taster hat keinen status. der erzeugt nur beim drücken events. schau auf den eventmonitor. entsprechende readings lassen sich dann auswerten.
es gibt auch ein modul sequence, vielleicht hilft das für komplexere aufgaben.

die virtuellen aktoren können nur toggeln. die haben keine statemachine.

Zitatda sollte mindestens cmds_done erscheinen.

jo, war auch immer, zumindest wenn ich keinen übersehen habe ...
Den Rest schaue ich mir mal an; ich muss aufpassen, das ich nicht an zu vielen Baustellen gleichzeitig lerne; Männer können bekanntlich nicht multitasken (behauptet meine MamaZicke zumindest) ;)

Zitatdie virtuellen aktoren können nur toggeln. die haben keine statemachine.

... das is ja doof :-[ Dann klappt das ja auf diesem Weg schon mal nicht... schidde...

ZitatWenn FHEM mal weg ist bleibt das Licht halt immer an

... soll vorkommen ;) Aber kann man nicht einen Timer direkt im Aktor starten? ich meine, hier mal irgend was darüber gelesen zu haben. Dann kann FHEM auch auf die Nase fallen.

Also... Meine Idee klappt also nicht, zumindest nicht über einen VA.

ZitatIch hatte es auch eine Zeit lang so das der Actor auf Short und Long reagiert hat und habe ein notify gemacht das auf short er einen on-for-timer machen soll.

Hast Du den Codeschnippsel noch, damit ich damit üben kann?

Zitat von: M_I_B am 23 November 2015, 11:19:00
jo, war auch immer, zumindest wenn ich keinen übersehen habe ...
Den Rest schaue ich mir mal an; ich muss aufpassen, das ich nicht an zu vielen Baustellen gleichzeitig lerne; Männer können bekanntlich nicht multitasken (behauptet meine MamaZicke zumindest) ;)... das is ja doof :-[ Dann klappt das ja auf diesem Weg schon mal nicht... schidde...
... soll vorkommen ;) Aber kann man nicht einen Timer direkt im Aktor starten? ich meine, hier mal irgend was darüber gelesen zu haben. Dann kann FHEM auch auf die Nase fallen.

Also... Meine Idee klappt also nicht, zumindest nicht über einen VA. Hast Du den Codeschnippsel noch, damit ich damit üben kann?


LichtSchalterAnnaBett_Btn1:Long.* set LichtSchalterBadDeckenLampe_Sw on-for-timer 900


mehr ist da nicht nötig gewesen

... dass'ja einfach ;) Retzt müsste ich theoretisch nur den Timer vom Aktor an Stelle des FHEM nutzen und alles ist schön...

... ich habe die Register jetzt auf sichtbar gestellt (glaube ich zumindest) mit "set KG_ZS_4CH regSet intKeyVisib visib"

Nach Eingabe von "set KG_ZS_4CH getRegRaw List1 all" erhalte ich dann allerdings nach etwa 10 Sekunden ein "RESPONSE TIMEOUT:RegisterRead" ?!?

Zitat von: M_I_B am 23 November 2015, 11:46:31
... dass'ja einfach ;) Retzt müsste ich theoretisch nur den Timer vom Aktor an Stelle des FHEM nutzen und alles ist schön...

... ich habe die Register jetzt auf sichtbar gestellt (glaube ich zumindest) mit "set KG_ZS_4CH regSet intKeyVisib visib"

Nach Eingabe von "set KG_ZS_4CH getRegRaw List1 all" erhalte ich dann allerdings nach etwa 10 Sekunden ein "RESPONSE TIMEOUT:RegisterRead" ?!?

Ich kann Dir nicht mal sagen ob der Aktor einen Timer hat. Das on-for-timer was in fhem beim aktor steht kommt wohl eher von fhem. denke ich. stecke da nicht so doll drin.

Zitat
... ich habe die Register jetzt auf sichtbar gestellt (glaube ich zumindest) mit "set KG_ZS_4CH regSet intKeyVisib visib"

Wo haste denn das gelesen? Commandref?

HM-Aktoren haben einen eigenen Timer. on-for-timer wird im Aktor ausgeführt.

Ich würde, anstelle dieses Ratespiels, ja das Lesen der Literatur (Einsteiger-PDF etc.) bevorzugen.

Marvin hat da mal echt Recht.

Zitat
Eine Zustandsänderung von ,,on" nach ,,on" startet den timer neu! Wenn man also einen
Treppenausschalter hat mit 20se
c on und nach
10
sec noch einmal drückt kommt es darauf an:

Zitat aus dem Einsteiger PDF - Anhang Homematic
also eigentlich genau das was Du ja machen wolltest wo ich dachte das geht so einfach nicht direkt.

Habe eben mal geschaut. Du kannst in der Tat für jeden Tastendruck ein onTime einstellen. Also set regSet Taster-shActionType onTime 300 oder so. Cool
Das muß ich mir mal genauer anschauen. Dann kann ich mir nämlich mein notify kneifen.

... der Laie staunt und de Fachmann wunder sich ;)

ZitatWo haste denn das gelesen? Commandref?

Jupp, genau, unter dem Unterpunkt "getRegRaw"

Also ok. Das sowas in dem Einsteiger-PDF steht, hätte ich nicht erwartet^^ Man(n) lernt nie aus...

Daraus geht ja hervor, das der Timer retriggerbar ist. Also sobald ein zweites ON kommt startet der Timer neu. Für einen einfachen Treppenlicht- Automaten ziemlich gut und einfach umzusetzen. Jetzt müsste man das nur noch erweitern und nebst Zwischenspeicherung feststellen, wie oft LONG ON oder LONG OFF gedrück wurde, um damit den Timer entsprechend zu setzen.

Zitat von: M_I_B am 23 November 2015, 13:20:28


Also ok. Das sowas in dem Einsteiger-PDF steht, hätte ich nicht erwartet^^ Man(n) lernt nie aus...

Ich glaube, dir wurde in diesem Thread gesagt, dass das Lesen dieses Dokuments eine gute Idee ist. Vieles von dem, was du dir hier im Thread mühsam zusammen gefragt hast, steht dort, im Wiki oder in der Commandref. Eine gute Idee ist immer, erst die Doku zu lesen und dann bei Unklarheiten zu fragen.

... das hast Du gut gesagt und auch vollkommen Recht ... Nur ist das mit der Realität nicht immer vereinbar.
Ich verbringe z.Z. fast den ganzen Tag mit Lesen und ausprobieren, wovon ca. 90% auf's Lesen verwendet wird und der Rest aufs Probieren. Dabei geht im Moment so viel Zeit drauf, das meine Frau mich schon mit den Worten "... ich lasse keine Fremden ins Bett ..." in der Nacht empfängt ^^ Da kann man einfach nicht alles sehen und wissen, wo was steht oder zu finden ist.
Im Übrigen muss ich Dir widersprechen bezgl. "mühsam zusammengefragt": Das ursprüngliche Problem bestand ja hauptsächlich im "grün machen" der LED. Die Lösung, auch wenn offensichtlich niemand genau weiss, warum das jetzt klappt, hat sich nur durch einen Zufall ergeben, welcher sich aus der Kommunikation mit allen hier involvierten Usern ergeben hat. Mit dem Hinweis darauf wo was steht, wäre ich damit noch keinen noch so kleinen Schritt weiter. Und genau dafür, so ist meine Auffassung zumindest, ist ein Forum da; Kommunikation mit anderen Menschen und erarbeiten einer Lösung oder anderer Wege zum Ziel... Denn alles ist schon mal irgendwo geschrieben worden; wenn man sich darauf stützt und alles so super erklärt und an Beispielen funktionierend vertieft wird, bräuchte es kein Forum...

... aber das ist nur meine unmassgebliche Meinung ...

... so, nächste Aufgabe bezgl. Long/Short ...

define TA_EG_FL_01 notify EG_FL_6CH_CH1 set KG_ZS_4CH_CH1 toggle
define TA_EG_FL_11 notify EG_FL_6CH_CH1:Long.* set KG_ZS_4CH_CH1 on-for-timer 10
Das funktioniert erstaunlicher Weise schmerzfrei wie gewollt. Aber das möchte ich natürlich eleganter lösen. Also habe ich ...
define TA_EG_FL DOIF ([EG_FL_6CH_CH1:?Short.*]) (set KG_ZS_4CH_CH1 toggle) DOELSEIF ([EG_FL_6CH_CH1:?Long.*]) (set KG_ZS_4CH_CH1 on-for-timer 10)
... und ...
define TA_EG_FL DOIF ([EG_FL_6CH_CH1] =~ "Short") (set KG_ZS_4CH_CH1 toggle) DOELSEIF ([EG_FL_6CH_CH1]  =~ "Long") (set KG_ZS_4CH_CH1 on-for-timer 10)
Versucht. Funktioniert leider nur zum Teil...

Mit kurzem Druck geht der Kanal an, aber nicht wieder aus. Sehr wohl kann ich aber mit einem langen Druck den Timer Setzen und retriggern. Also wird offensichtlich der ELSE- Teil abgearbeitet bei langem Tastendruck, aber beim zweiten kurzen Tastendruck der IF-Teil nicht mehr.

Ist vermutlich ein ganz simpler (Denk-) Fehler, aber ich komme einfach nicht drauf.

Das ganze Konstrukt sieht im Übrigen jetzt so aus:
## 6fach Taster Haustür <-> 4fach AKtor Zählerschrank Aussenlicht ##

#define TA_EG_FL_01 notify EG_FL_6CH_CH1 set KG_ZS_4CH_CH1 toggle
#define TA_EG_FL_11 notify EG_FL_6CH_CH1:Long.* set KG_ZS_4CH_CH1 on-for-timer 10

define TA_EG_FL DOIF ([EG_FL_6CH_CH1:?Short.*]) (set KG_ZS_4CH_CH1 toggle) DOELSEIF ([EG_FL_6CH_CH1:?Long.*]) (set KG_ZS_4CH_CH1 on-for-timer 10)

define TA_EG_FL_02 notify EG_FL_6CH_CH2 set KG_ZS_4CH_CH2 toggle
define TA_EG_FL_03 notify EG_FL_6CH_CH3 set KG_ZS_4CH_CH3 toggle
define TA_EG_FL_04 notify EG_FL_6CH_CH4 set KG_ZS_4CH_CH4 toggle
define TA_EG_FL_05 notify EG_FL_6CH_CH5 set KG_ZS_4CH_(CH1|CH2|CH3|CH4) on;
define TA_EG_FL_06 notify EG_FL_6CH_CH6 set KG_ZS_4CH_(CH1|CH2|CH3|CH4) off;

... bin selber drauf gekommen; das ist, zumindest für mich, in der CommandRef etwas missverständlich ausgedrückt... Da fehlt ein "do always" ^^

define TA_EG_FL DOIF ([EG_FL_6CH_CH1:?Short.*]) (set KG_ZS_4CH_CH1 toggle) DOELSEIF ([EG_FL_6CH_CH1:?Long.*]) (set KG_ZS_4CH_CH1 on-for-timer 10)
attr TA_EG_FL do always

Und man kann es weiter vereinfachen, da nur Short und Long ausgewertet werden müssen:
define TA_EG_FL DOIF ([EG_FL_6CH_CH1:?Short.*]) (set KG_ZS_4CH_CH1 toggle) DOELSE (set KG_ZS_4CH_CH1 on-for-timer 10)
attr TA_EG_FL do always

Jetzt fehlt mir nur noch das Hinzuzählen von Zeitblöcken, wenn der Timer noch nicht abgelaufen ist nach dem Basic-like Schema:

SET $t0 = 0, $t1 = 30
IF
  TimerRun AND Long AND $t0 = 0 OR TimerOff AND Long
    SET on-for-timer $t1
    SET $t0 = 1
ELSEIF
  TimerRun AND Long AND $t0 > 0
    SET on-for-timer ($t1 * $t0)
    SET $t0 = $t0 + 1
ENDIF
   
... ich Hoffe, mann kann meinen wirren Gedanken folgen?!

Zitatwenn der Timer noch nicht abgelaufen

das actor reading timedOn=running/off.

... suppi; Dank für den Hinweis!
Gibt's da vielleicht was zu lesen zu, ausser ComRef/Einsteiger.pdf?

... jetzt hänge ich bei einem RegEx  >:(

Ich möchte "Long 13_324" auswerten. Allerdings nicht das ganze Ding, sondern lediglich den Null- Durchgang des Zählers vor dem Unterstrich.
Meine ersten Versuche mit der Reaktion auf lange Drücke sahen so aus:
blablub ... EG_FL_6CH_CH1:?Long 10.* ... blubbla
Da habe ich stumpf abgefragt, ob eine 10 oder eine 20 oder was auch immer da auftaucht. Das funktioniert super und erfüllt seine Zweck. Nun möchte ich aber einen kleinen Schritt weiter. Das Problem was ich nun mit RegEx habe ist, das die Länge sich ja bei jedem Potenzsprung ändert, also bis 9 einstellig, bis 99 zweistellig u.s.w.. Ich müsste also zum einen wissen, das "Long" auftaucht und zum anderen vom Unterstrich eine Stelle nach links auf "0" abfragen.
Da bin ich einfach mangels Erfahrung mit RegEx zu doof zu... Wie geht man an so eine Aufgabe in Verbindung mit RegEx ran?

Mir hilft diese Seite eigentlich immer weiter: https://wiki.selfhtml.org/wiki/Perl/Reguläre_Ausdrücke

... auch nicht schlecht und besser erklärt als das was ich kenne; gespeichert. Bringt mich aber zum gleichen Ergebnis...
Long.*0_.*
... funktioniert nicht wie gedacht.
Aber erst recht laufe ich gegen die Wand bei:
... set KG_ZS_4CH_CH1 on-for-timer 180 * EG_FL_6CH_CH1:?.*(Zehnerstelle).*) ...
Da weiß ich zum einen nicht, ob das überhaupt geht, das ich stumpf eine Wert (hinter on-for-timer) mit einem anderen Wert (Zehnerstelle) multiplizieren kann und weiß ebenfalls nicht, wie ich dann die Zehnerstelle da mit RegEx heraus bekomme als Operand...

Ich denke, was ich erreichen möchte ist klar, aber ich hänge da geistig vollkommen fest...

du kannst nicht auf fhem ebene multiplizieren das geht 'nur' auf perl ebene.

in einem notify würde das etwa so aussehen: define myNotify notify EG_FL_6CH_CH1:Long.* { if( $EVTPART1 =~ m/(\d+)0_/ ) {fhem("set KG_ZS_4CH_CH1 on-for-timer ". 180 * $1)} }

gruss
  andre

ps: das ? zwischen : und Long das du verwendest ist überflüssig.

... auha ... Auf die perl- Ebene wollte ich mich eigentlich noch nicht ranwagen; mir qualmt ja so schon die Omme ^^

Aber so wie's ausschaut, komme ich da wohl nicht umhin... ich trau mich mal... Morgen, wenn ich halbwegs ausgeschlafen bin ;)

Erstmal vielen Dank; ich werde berichten, was bei meinem Murks rausgekommen ist...

Zitatps: das ? zwischen : und Long das du verwendest ist überflüssig.

Nich? Stand so in der Doku und habe es somit als gegeben hingenommen, quasi als Äquivalent zu =~

nicht nur überflüssig sondern sogar falsch...

der : an dieser stelle trennt den device namen vom reading namen. d.h. nach dem doppelpunkt fängt die regex an die auf das reading matched. ein quantifier wie ? ist aber direkt am anfang einer regex sinnlos weil es kein zeichen davor gibt das mit einer bestimmten anzahl vorkommen könnte.

schau mal ins log. eigentlich müsstest du da auch einen entsprechenden fehler sehen der dann der grund ist warum deine regex nicht funktioniert.

das gilt zumindest für notify und regex im allgemeinen. ob es bei DOIF eine andere sinnvolle bedeutung hat weiss ich nicht. das verwende ich nicht.

gruss
  andre

... da hast Du recht. Ich hatte das aus dem HowTo bezgl DOIF her und angenommen, das es bei notify ebenso ist ...

Bevor ich ins Bettchen schleiche, konnte ich es nicht lassen und habe das mal eben noch schnell alleine eingebaut (alles andere auskommentiert).
Ich habe Deine Zeile natürlich noch nicht verstanden, aber so funktioniert sie nicht. Als Test habe ich mal den Multiplikator $1 am Ende weggenommen; dann geht's. Es scheint mir, das in $1 immer NULL oder 0 steht oder was anderes in dem Zusammenhang nicht klappt.

define di_1 notify EG_FL_6CH_CH1:Long.* { if( $EVTPART1 =~ m/\d+0_/ ) {fhem("set KG_ZS_4CH_CH1 on-for-timer ". 3 * $1)} }
Da passiert nüscht

define di_1 notify EG_FL_6CH_CH1:Long.* { if( $EVTPART1 =~ m/\d+0_/ ) {fhem("set KG_ZS_4CH_CH1 on-for-timer ". 3 )} }
Da wird der Timer auf 3 Sekunden gesetzt, natürlich ohne hochzuzählen

BTW: Vorhin stand da doch $EVTPART1 und nicht wie jetzt $EVENT ?!?

Ich hab's jetzt noch mal schnell mit $EVENT probiert. Dann geht nix mehr ...

sorry. aus irgend einem grund haben in meinem post zwei klammern gefehlt die in die regex gehören. ohne die klammern wird nichts gecaptured.

gruss
  andre

... ja super; funktioniert perfekt! Vielen Dank!
Jetzt werde ich die Tage mal versuchen, Deinen RegEx zu analysieren und zu verstehen. Immerhin hatte ich den richtigen Riecher mit der leeren Variable; wenn ich das richtig verstanden habe, "merkt" sich RegEx das, was innerhalb von Klammern auf das Muster passt und legt es in $1, $2, ...$+n ab?!

Mag sein, das ich heute wegen Fieber & Co. nicht so ganz klarf im Kopf bin... Also bitte ggf. meinen Dummfug vergessen^^
So wie ich das sehe, funktioniert DOIF nicht mehr wirklich, sobald man auf die perl- Ebene springt; zumindest wird es dann ziemlich verwirrend mit der ganzen Klammerung... Also wäre es wohl schlauer, die von mir gewünschten Funktionen komplett auf perl-Ebene (Basic oder Pascal wäre mir lieber *DuckUndWeg*) zu verwirklichen, oder?

Letztlich will ich da hin kommen:

Bei einem kurzen Druck soll der Aktor toggeln.
Bei einem langen Druck soll der Aktor erstmal einschalten.
  Dann Rausfusseln des Zählers auf Nulldurchgang als Multiplikator für on-for-timer (tut ja schon)
  Parallel bei jedem Nulldurchgang kurz Aktor OFF/ON als optische Rückmeldung (nur Leuchtmittel!)
  Bei "LongRelease.*" on-for-timer mit dem errechneten Wert setzen

Anm.: Das mit der optischen Rückmeldung funktioniert nicht oder nur eingeschränkt mit Leuchtstofflampen, wozu auch die s.g. Energiesparlampen gehören. Klassische Leuchtmittel und LED haben damit kein Problem.

Vielleicht könnte man das komplett als perl- Funktion bosseln, die man unabhängig vom Sensor- und Aktor aus FHEM aufrufen kann? Damit habe ich mich noch gar nicht beschäftigt, aber ich meine irgendwo gelesen zu haben, das sowas geht und bei Euch Profis gängige Praxis ist? Also in etwa so:


define di_1 DOIF ([EG_FL_6CH_CH1:?Short.*]) (set KG_ZS_4CH_CH1 toggle) \
          DOELSE (set KG_ZS_4CH_CH1 {call perl-funktion})
attr di_1 do always

... ist vermutlich Blödsinn und/oder nicht so realisierbar?

ja. genau. mit den klammern kannst du einzelne teile extrahieren und zwischenspeichern.

wie gesagt: ich verwende DOIF nicht und sehe gerade wegen der klammern und mancher syntax besonderheiten die sich dann mit fhem oder perl beissen keinen vorteil darin noch mal eine zwischenstufe zu lernen. es gibt aber viele die sehen das anders.

unabhängig davon ist es immer sinnvoll so etwas in eine 99_myUtils routine auszulagern und diese nur aufzurufen wenn es mehr als ein paar ganz wenige zeilen sind. wenn die ereignisse unabhängig voneinander sind muss es auch nicht das gleiche notify oder die gleiche routine sein.

... ich habe den Quatsch mal gelöscht, den ich vorhin verzapft habe ^^

Ich versuche das jetzt "zeilenweise":

define di_1 notify EG_FL_6CH_CH1 {\
{ fhem ( "set KG_ZS_4CH_CH1 on" ) }\
}
Das funktioniert schon mal...

define di_1 notify EG_FL_6CH_CH1 {\
{ fhem ( "set KG_ZS_4CH_CH1 on" ) };; \
if ( $EVTPART1 =~ m/(\d+)0_/ ) { fhem ( "set KG_ZS_4CH_CH1 off" );; fhem ( "set KG_ZS_4CH_CH1 on" ) }
}
Das im Prinzip auch. Allerdings ist die Auswertung soooo langsam, das FHEM/RPi nicht hinterher kommt. Da kann ich nach einem langen DRuck mit Zähler über 50 schon lange losgelassen haben, und der Aktor macht immer noch ne ganze Weise klickklack, wenn die AUswerung über 0 gekommen ist. Das geht so also nicht ohne weitere Optimierung bezgl. Aufführungszeit. Damit bin ich aber derzeit vollkommen überfordert, weil ich nicht den leisesten Schimmer habe, was in welcher Kombination wie viel Rechenzeit beansprucht.

Auch fehlt mir noch das Verständnis, was z.B. $EVTPARTx macht und für was das m im RegEx gut ist; ich habe es mal stumpf übernommen...

Nachtrag:

define blablub notify EG_FL_6CH_CH1 set KG_ZS_4CH_CH1 off;; set KG_ZS_4CH_CH1 on

... ist so schnell, das man zwangsweise zwischen die OFF/ON Sequenzen ein Sleep setzen muss. SOmald man aber gleiche Sequenz im perl nutzt ala ...

... { fhem ( "set KG_ZS_4CH_CH1 off;; set KG_ZS_4CH_CH1 on" ) }\

ist es viel zu langsam... Kann mich mal wer schlau machen?

commandref/notify => $EVTPART

2 klammern weniger
define di_1 notify EG_FL_6CH_CH1 {\
fhem ( "set KG_ZS_4CH_CH1 on" );; \
if ( $EVTPART1 =~ m/(\d+)0_/ ) { fhem ( "set KG_ZS_4CH_CH1 off" );; fhem ( "set KG_ZS_4CH_CH1 on" ) }
}

... huppsi ... Jetzt wo Du's erwähnst ::) Bei so viel Klammerei kann man schon mal den Überblick verlieren und sieht's dann auch beim 100ten mal drüberlesen nicht...

aBär.. an der Ablaufgeschwindigkeit hat sich nichts getan. Wenn ich mir den Counter anschaue, reagiert der Aktor im besten Fall das erste mal auf den Null- Durchlauf, wenn der Counter schon bei 17 steht, oft aber erst, wenn der Counter 30 deutlich überschritten hat.
Wenn man sich so den Counter auf der GUI anschaut fällt auf, das er recht langsam läuft bis zu dem Zeitpunkt, wo man die Taste wieder löst. Dann hat er es für ein paar weitere Zählschritte sehr eilig. Das verleitet mich zu der Vermutung, das der RPi/FHEM so sehr damit beschäftigt ist, die Datenpakete entgegen zu nehmen, das er zu nix anderem mehr kommt. Also habe ich mal X gestartet und mir die Prozessorlast angesehen... Fehlanzeige. In Ruhe liegt die Last so bei 0-1%, Bei Festhalten der Taste maximal 7%. Finde ich zwar schon viel, aber ist weit entfernt von kritischen Lastwerten. Vermutung also selbst wiederlegt.
Die Frage ist nur, woran es denn sonst liegen könnte?!?

... ich habe es jetzt mal anders versucht. Zumindest stottert der Counter jetzt nicht mehr, aber funktionieren tut's leider auch nicht.. Ich arbeite noch dran:

altlast entsorgt

... an dieser Stelle gebe ich erstmal (für heute) auf >:(
Kurzer Tastendruck wird korrekt als toggle umgesetzt, aber so bald ich einen langen Tastendruck erzeuge, läuft FHEM in eine Endlosschleife, die sich auch nicht durch stoppen und starten des FHEM- Dienstes stoppen lässt. Nur der Neustart des RPi hilft.
Ich komme einfach nicht dahinter, wo mein Denkfehler ist...

define di_1 notify EG_FL_6CH_CH1 { \
if ( $EVENT =~ /\Short/m ) { \
fhem ( "set KG_ZS_4CH_CH1 toggle" );; \
} elsif ( $EVENT =~ /\Long./m ) { \
fhem ( "set KG_ZS_4CH_CH1 on" );; \
my $timer = 3;; \
while ( $EVENT =~ /\Long./m ) { \
if ( $EVTPART1 =~ /(\d+)0_/m ) { \
$timer = $timer ** $1;; \
fhem ( "set KG_ZS_4CH_CH1 off;; set KG_ZS_4CH_CH1 on" );; \
} \
} \
fhem ( "set KG_ZS_4CH_CH1 on-for-timer ". $timer );; \
} \
}


das while würde ich mal dringend entsorgen.
$EVENT ändert sich nicht, daher gibt es keinen ausgang.

... Echt? Wieso ändert sich $EVENT nicht? Nach allem was ich gelesen und verstanden habe, steht doch in $EVENT genau das drin, was die Taste gerade sendet, also entweder "Short", "Long x1_x2", oder "LongRelease x1_x2"?!?
Aber auch mal angenommen, es ändert sich nicht, dann kann WHILE nur mit Long aufgerufen werden. Bei Short wird das While übersprungen, und nur Long wird in der ELSIF akzeptiert. Also müsste zumindest der Befehl ON nach ELSIF noch ausgeführt werden. Aber bis dahin komme ich gar nicht, also nach meinem Verständnis auch nicht zum WHILE. Aber auch wenn, dann müsste das WHILE zumindest dauerhaft laufen. Aber das FHEM schmiert wie gesagt irgendwo komplett ab und ist nur durch einen kompletten ReBoot zu reaktivieren...

Du verwirrst mich ;)

fhem ist nicht multithreaded und arbeitet event basiert. so lange du in dein er while schleife bist macht fhem nichts anderes als deine while schleife abzuarbeiten. jede art von schleife um auf änderungen zu warten ist konzeptionell falsch und funktioniert nicht.

wenn du je nach zustand unterschiedlich auf events regieren willst ist es am besten alles in 99_myUtils auszulagern und eine state machine zu verwenden.

gruss
  andre

Zitatsteht doch in $EVENT genau das drin, was die Taste gerade sendet,

fhem grundkurs: 0. vorwort

in fhem gibt es im prinzip keine parallelverarbeitung.
events werden nacheinander erzeugt (siehe eventmonitor) und nacheinander abgearbeitet und dienen der kommunikation zwischen verschiedenen modulen. ein notify zb lauscht permanent auf passende events.
wenn nun das aktuell zu verarbeitende event auf die regex deines notifys passt, werden die daten des events an dein notify übergeben und es wird abgearbeitet. während der laufzeit deines notifys ändern sich die eventdaten nicht.

andre war schneller.

... ok, jetzt leuchtet mir das auch ein und erklärt das von mir unerwartete Verhalten.. Schidde... Holzweg  :-[

Zitatalles in 99_myUtils auszulagern und eine state machine zu verwenden.

Noch nie von gehört/gelesen (von der state machine meine ich). Gibt es da irghendwo was schlaues drüber zu lesen, wie man so was anstellt?

hm ... wie wärs mit wiki?
http://www.fhemwiki.de/wiki/HM-Dis-WM55_Funk_Statusanzeige

... nett, auch wenn ich ...

... kein Wort von dem dort gesagten verstehe ...
... ich kein HM-Dis-WM55 habe ...
... ich dort an keiner Stelle die Bezeichnung "event machine" finden konnte ...
... und somit auch die Suche danach nicht auf dieses Dokument verwiesen hat.

Daher im Moment: Nicht hilfreich.

eine finite state machine bzw. endlicher automat ist ein konstrukt mit dem das verhalten eines systems durch eine menge von zuständen und die übergänge zwischen diesen beschrieben wird.

bei wikipedia gibt es mehr oder weniger theoretische beschreibungen, der von martin verlinkte artikel beruht auch auf einer state machine.

das schaut im ersten augenblick zwar kompliziert aus ist aber wenn das prinzip klar ist sehr viel einfacher zu warten und zu erweitern.

der knackpunkt ist das nicht mehr ein unüberschaubarer wust von verschachtelten if/else konstrukten verwendet werden sondern die zustände durch datenstrukturen beschrieben werden und es im prinzip nur noch eine einzige routine gibt die gesteuert durch den aktuellen zustand und den aktuellen input in den neuen zustand wechselt und dabei als 'seiteneffekt' die gewünschten aktionen auslöst.

diese routine kann sehr generisch implementiert und so für alle möglichen aufgaben wiederverwendet werden. nur die beschreibung der zustände und aktionen wäre jeweils individuell.

ein solches modell passt sehr gut zum event gesteuerten modell das fhem vorgibt.

such ein bisschen bei google. lese dich langsam ein. nicht durch die seiten mit theoretischen anstrich abschrecken lassen. es ist wirklich eine praktische sache. ein schöner aspekt ist das man gezwungen wird sich über die zustände und übergänge gedanken zu machen und diese auch gut aufmalen kann.

gruss
  andre

ps: wenn ich so drüber nachdenke wäre das eigentlich fast ein fhem modul wert. zustände und aktionen definieren und die events die dann die übergänge herbeiführen...

... damit kann ich was anfangen! Vielen Dank für die ausführliche Erklärung. Das bringt mich deutlich weiter, als ein Link ohne weitere Erklärungen

Zitatps: wenn ich so drüber nachdenke wäre das eigentlich fast ein fhem modul wert. zustände und aktionen definieren und die events die dann die übergänge herbeiführen...

... ich bin dafür!  ;D

hm - dieser Teil ist frei programmierbar. das wird etwas schwer, ohne Flexibilitaet einzubüsen. Möglich ist alles, ob es einfacher wird - hängt vom Standpunkt ab.
Das Beispiel in Wiki ist voll funktionsfähig - ist doch eigentlich ein Modul.

... ok ... Da mir die Nummer mit der "event machine" im Moment noch eine Nummer zu fett ist, habe ich nach einer anderen Lösung gesucht und wohl auch theoretisch gefunden; wenn sie denn funktionieren würde:

define di_1 notify EG_FL_6CH_CH1 { \
if ( $EVENT =~ /\Long.*/m && $multi == 0 ) { \
my $timer = 3;; \
my $multi = 1;; \
fhem ( "set KG_ZS_4CH_CH1 on" );; \
} elsif ( $EVENT =~ /\Long.*/m && $multi != 0 ) { \
$timer = 0;; \
$multi = 0;; \
fhem ( "set KG_ZS_4CH_CH1 off" );; \
} elsif ( $EVENT =~ /\Short.*/m && $multi != 0) { \
fhem ( "set KG_ZS_4CH_CH1 on-for-timer ". $timer ** $multi );; \
} \
}

Das ist eine der versuchten Varianten, die nicht funktioniert, weder auf Short noch auf Long. Ich vermute, das ich mangels Erfahrung mit perl da irgend etwas übersehe. Was ich auch nicht rausbekommen konnte ist, ob hier perl im strict- Modus arbeitet und ich zwingend die Variablen vorher deklarieren muss? Wenn ja, sollte das nach meinem Verständnis an einer Stelle geschehen, die beim Starten von FHEM einmal durchlaufen wird, da ja ansonsten die Variablen immer neu deklariert werden; nur wo? Oder macht das nix?

ich bastle gerade an einem state machine modul, mal sehen ob das was wird...

zu deinem problem: du musst variablen deklarieren und wenn du sie über einen scope (notify aufruf) hinüber retten willst gibt es zwei möglichkeiten: in ein reading stecken und wieder auslesen, den ganzen code in 99_myUtil stecken und die variablen dort ausserhalb der sub deklarieren.

eventuell hilft dir auch OldValue um auf den vorherigen STATE wert zuzugreifen.

gruss
  andre

Andre war schneller, egal...

Variablen müssen deklariert werden. Speichern und lesen kannst Du sie in readings mit setreading/ReadingsVal.
z.B.

define foo notify ... {
  my $bla = ReadingsVal('device','reading','default');
  if ($bla eq 'blabla') {
    fhem('setreading device reading foobar')
  }
}


... vielen Dank, das Ihr so schnell reagiert habt!

das mit dem "setreading/ReadingsVal" habe ich noch nicht verstanden. Da versuche ich mich mal heute Abend einzulesen.

Ganz unabhängig davon wäre aber wohl eine "Funktion" (?) in der myUtil sinnvoller, da man die dann für jedes TimerDingsBumsKonstrukt verwenden kann, welche das Gleiche machen sollen, oder? Da könnte ich dann ja auch Zeitwerte in einem Array hinterlegen und bei Bedarf immer einen Wert weter springen, so das ich die nicht ggf. praxisfremd berechnen müsste (Zeit * Zähler dauert zu lange, Zeit ** Zähler schießt schnell übers Ziel).
Wenn ich das so annährend richtig sehe, scheint mir die Unterbringung in der myUtil allgemein nur Vorteile zu haben. Hat (für mich) lediglich den Nachteil, das ich erneut keinen Plan habe, wie so eine Funktion zu bauen ist und ich schon wieder noch tiefer in das System tauchen und was ganz neues lernen muss^^ (... oder, was natürlich auch eine Sichtweise ist ... Ich habe einfach zu hohe Ansprüche an den gewünschten Funktionsumfang  ::) )

Zitat... Ich habe einfach zu hohe Ansprüche an den gewünschten Funktionsumfang

oder du willst keine erfolgerlebnisse.  ;)

wenn es im notify schon nicht geht, wird es auch nicht besser beim auslagern.

wenn es im notify schon nicht geht, wird es auch nicht besser beim auslagern.

das kommt drauf an... wenn man mit variablen arbeiten möchte um sich den zustand zu merken geht es nur ausgelagert gut.

Zitatwenn man mit variablen arbeiten möchte um sich den zustand zu merken geht es nur ausgelagert gut.

zustände in readings speichern funktioniert auch im notify.

ja. natürlich.

aber unabhängig vom speichern ist es ab einer gewissen code länge übersichtlicher das nicht mehr direkt ins notify zu packen. und wiederverwendbar ist es da auch nicht.

... na Leute, Ihr seid ja witzig  ::)
Natürlich finde ich Erfolgserlebnisse nett. Aber im Moment verzichte ich bewusst darauf. Denn mit den Dingen die ich wirklich drauf habe, könnte ich mir täglich massenhaft Erfolgserlebnisse verschaffen, so das meine Frau mir das Grinsen am Abend aus dem Gesicht schlagen müsste ;D

Aber im Ernst: Es ist doch verständlich, das ich erst einmal versuche, selber einen einfachen Weg zu finden, der funktioniert; ob nun schön oder nicht ist erst einmal Nebensache. Mit Fortschreiten des Lernens wird i.d.R. auch der Code besser, die Rückfragen zu (aus EUrer Sicht) simplen Fehlern/Tatsachen und das allgemeine Verständnis. Letztlich ist mein Wunsch ja auch keine schwere Aufgabe (aus Eurer Sicht natürlich). der Haken daran ist nur, das ich derzeit zu vermeiden suche, zu tief und zu gefächert ins System einzusteigen. Ich habe einfach Angst, den Überblick und in der Folge die Motivation zu verlieren. Es ist schon deprimierend genug, wenn ein an sich gut ausschauender Code auf Grund der Besonderheiten in FHEM / perl einfach nicht funktioniert und wen man ab- und an auf Nachfragen einfach nur einen Link vor die Nase bekommt, der einem nicht weiter hilft.


Aber das nur am Rande ...

nicht entmutigen lassen :)

der code würde auch ausserhalb von fhem nicht laufen. du kannst nicht im scope des if eine variable deklarieren und dann im else scope drauf zugreifen. das hat nichts mit fhem zu tun.

gruss
  andre

Zitatnicht entmutigen lassen :)

... ich bemühe mich ...
Das mit den Variablen habe ich nun verstanden; Basic- Nachwirkungen. Da geit dat nämlich ...

Aber mal eine vielleicht blöde Frage:
Kann ich die beiden Variablen nicht stumpf in der myUtil als global (how?) definieren, so das ich sie in meinem ELSIF- Kontrukt verwenden kann?

Ich denke, ich mache heute mal was ganz anderes, um den Kopf frei zu bekommen: Bakterien aus den Motorrädern müssen noch in'n Keller, dem V8 sollte ich mal die Winterschluffen aufstecken, die letzten 15 von 107 Fichtenwurzeln müssen noch aus'm Boden, Wohzimmer Fußleisten und CAT7, ... Arbeit ist genug und die Ecken, in denen ich mich bei einem Arbeitsanfall verstecken könnte, sind schon alle besetzt  8)

Zitat von: M_I_B am 27 November 2015, 13:14:02
Kann ich die beiden Variablen nicht stumpf in der myUtil als global (how?) definieren

Du wolltest Dich doch nicht verzetteln ;) Benutze die Variante von oben, wie alle anderen auch.
Und obendrauf kriegste noch einen Link, diesmal zur: 99_myUtils.pm (http://www.fhemwiki.de/wiki/99_myUtils_anlegen)

ZitatDu wolltest Dich doch nicht verzetteln ;)

Ja menno, hassa recht ;)

Also... Um überhaupt erst mal rein zu kommen habe ich das Beispiel in der genannten Doku entsprechend umgebaut, wobei folgendes heraus gekommen ist:

# define di_1 notify EG_FL_6CH_CH1 { SetTimerOnTip("$EVENT","$NAME") } #
my $timer = 3;
my $multi = 0;

sub SetTimerOnTip($$) {
my ($EVENT, $NAME) = @_;
if ($EVENT =~ /\Long.*/m && $multi == 0 ) {
$multi = 1;
fhem ( "set $NAME on" );
} elsif ( $EVENT =~ /\Long.*/m && $multi != 0 ) {
$multi = 0;
fhem ( "set $NAME off" );
} elsif ( $EVENT =~ /\Short.*/m && $multi != 0) {
$multi ++;
fhem ( "set $NAME on" ); #retrigger timer
fhem ( "set $NAME on-for-timer". $timer ** $multi );
}
}

Wie es aus FHEM aufgerufen wird, steht als Kommentar drüber. Nixxe passieren :-\

Um überhaupt mal festzustellen, ob da überhaupt was geht, habe ich den Code auf folgendes reduziert:

sub SetTimerOnTip($$) {
my ($EVENT, $NAME) = @_;
fhem ( "set $NAME on" );
}

Och nix... Natürlich ist die Datei wie beschrieben als 99_myUtils.pm abgespeichert und physikalisch da (ich arbeite lieber mit np++ und reloade lieber).
Ich habe die Doku nun schon ungezählte male durchgelesen, aber einen Fehler konnte ich nicht finden. In $NAME sollte "EG_FL_6CH_CH1" stehen und in $EVENT halt entsprechend "Short", "Long.*" oder "LongRelease.*"... ist doch so, wa?

(is zwar noch früh, aber ich genemige meinem Frust jetzt mal'n Irischen Single Malt; noch wer?!)

Zuviel reduziert, deine Parameter werden nicht übernommen.

Du kannst doch Log Meldungen einbauen um zu sehen was passiert.

ZitatZuviel reduziert, deine Parameter werden nicht übernommen.

... verstehe ich leider nicht ... Was meinst Du damit? Das ist doch fast identisch mit dem HowTo und zumindest, der "Einzeiler" sollte funktionieren... Ach ne... Übergabe vergessen... Schön das wir drüber gesprochen haben ;)

Ok, noch mal... (time goes by ...)

Nene, alles korrekt. Hatte ich nur vergessen beim Copy&Past hierher; ich hab's oben korrigiert, so wie's wirklich ist.

Ach, vergesst es; ich bin so blöd, das mich die Schweine beissen  >:( >:( >:( Das kann gar nicht funktionieren, da in $NAME ja das auslösende Gerät steht und nicht das Ziel...

... ok, ich gebe erst mal auf; kostet zu viel Zeit und ab 50 läuft die rückwärts  :'(

Erstes Problem:
In perl (myUtils) kann ich problemlos "Short" und "Long.*" erfassen, nicht aber "LongRelease.*". Warum nicht ist mir ein Rätsel. Und weil ich das nicht hingekommen habe, habe ich nach einem anderen Weg gesucht und stoße dann auf das ...

Zweite Problem:
ReadingsVal/setreading ist wohl das was ich benötige, um den aktuellen Zustand des Aktors zu erfragen, oder täusche ich mich da? Wenn ich damit richtig liege, benötige ich genau das, um ein halbwegs funktionelles Script zu bosseln. Nur leider verstehe ich diese Nummer irgendwie überhaupt nicht, weder wie es auf FHEM und/oder perl- Ebene eingesetzt wird, noch wie ich aus perl heraus (in myUtils) an den aktuellen Aktorzustand heran komme...; ich mag jetzt nicht mehr so wirklich...

Ich mache jetzt ein paar große Schritte zurück und nutze wieder das ursprüngliche Konstrukt mit Vorgabe einer festen Zeit... Dann ist das halt so...

Dann zeige doch wo es klemmt.

... schrieb ich doch:

1.:
LongRelease lässt sich ins perl nicht via $EVENT übergeben.

2.:
ReadingsVal/setreading verstehe ich nicht, da ich trotz stundenlanger Suche kein HowTo oder Beispiele habe finden können, die mich die Zusammenhänge hätten erkennen lassen.

Eines von beiden benötige ich, um weiter zu kommen. Da 1. wohl nicht möglich ist und ich 2. nicht verstehe, schmeiße ich erst mal das Handtuch, damit ich hier überhaupt mal weiter komme, den Kram einbauen kann und meine Zicken mich auch noch mal zu Gesicht bekommen.

Zitat von: M_I_B am 27 November 2015, 21:31:04
... schrieb ich doch:

1.:
LongRelease lässt sich ins perl nicht via $EVENT übergeben.

Glaub ich nicht.

Lasse dir in deiner Routine doch die Werte ins Log schreiben mit

Log <verbose-level>, <Text>;
zB:
Log 3, "mySub: Name=".$NAME." EVENT=".$EVENT;

Zitat
2.:
ReadingsVal/setreading verstehe ich nicht, da ich trotz stundenlanger Suche kein HowTo oder Beispiele habe finden können, die mich die Zusammenhänge hätten erkennen lassen.

my $var = ReadingsVal(<Device>,<Reading>,<Default>);
Der Variablen $var wird das <Reading> vom <Device> zugewiesen wenn <Reading> vorhanden, wenn nicht wird der Wert <Default> zugewiesen.
fhem("setreading <Device> <Reading> <Value>");

... ja, LOG habe ich inzwischen, aber über Data::Dumper ...

Glaube mir: LongRelease wird nicht erkannt; probier's mal aus ala:
# Aufruf:
define frosch notify Sensor { SetTimerOnTip("Aktor","$EVENT") }

# Sub:
sub SetTimerOnTip($$) {
my ($TARGET,$EVENT) = @_;
if ($EVENT =~ /\LongRelease.*/m ) {
fhem ( "set $TARGET toggle" );
}
}

... wird nicht klappen. Vielleicht gibt es einen anderen Weg, auf das "Release" zu reagieren, aber ich habe keinen gefunden. Auch wenn ich jedesmal mit "print Dumper ("ReVal  = : ".ReadingsVal($TARGET,"state","err"));" nachschaue, was übermittelt wird, taucht das LongRelease nie auf (ja, inzwischen habe ich durch viel Probieren  rausgefunden, wie das ReVal funktioniert). Da kommen lediglich "set_off", "set_on", "off", "on", "set_on-for-timer xxx"... das war's.
Wenn ich daher nur auf das "Long" reagiere, habe ich das Problem, das der Counter so lange hochläuft, wie die Taste gehalten wird. Damit wird das Endergebnis unkalkulierbar.

Deine Bedingung greift nicht.

if ($EVENT =~ m/LongRelease/ ) {

beachte: das "Release" kommt nur, wenn der Button gepeert ist.

@stromer-12:
Warum sollte sie nicht? Die Ausdrücke für Short und Long sind identisch aufgebaut und greifen ja auch.
https://wiki.selfhtml.org/wiki/Perl/Regul%C3%A4re_Ausdr%C3%BCcke#Modifiers
Wäre nett, wenn Du mir bei Irrtum meinerseits erklären möchtest, warum "\/Short/m" und "\/Long/m" greift, hingegen "\/LongRelease/m" nicht. Ich mache ja immerhin erst seit zwei Tagen mit RegEx rum und kann noch nicht alle Feinheiten kennen, welche bezogen auf das Problem da den Unterschied machen.

@martinp876:
... nicht das ich wieder falsch liege: peer = Device <-> FHEM /// pair = Device <-> Device ... Habe ich mir doch richtig gemerkt? Wenn ja...
Beide Geräte sind mit/über FHEM verbunden und nicht direkt, sonst würde ja der Rest auch nicht funktionieren. FHEM selbst erkennt auch die drei verschiedenen Zustände, nur zur Auswertung kann ich im Gegensatz zu den anderen beiden Zuständen den LongRelease nicht greifen, warum auch immer.

Zitatpeer = Device <-> FHEM /// pair = Device <-> Device ... Habe ich mir doch richtig gemerkt?

nein. Sind doch alle Kommandos so beschrieben:

hmPairForSev: Device <->FHEM
hmPairserial: Device <->FHEM
PairedTo: Device <->FHEM

peerIDs: Channel<->Channel
peerList: Channel<->Channel
peerChan: Channel<->Channel

ZitatBeide Geräte sind mit/über FHEM verbunden und nicht direkt, sonst würde ja der Rest auch nicht funktionieren

ohne peering kein "Release" für diesen Kanal- period!

ZitatFHEM selbst erkennt auch die drei verschiedenen Zustände,

welche 3?

Zitatnur zur Auswertung kann ich im Gegensatz zu den anderen beiden Zuständen den LongRelease nicht greifen, warum auch immer.

weil es überall so beschrieben ist.
schaue einfach die Events an - wenn beim Press kein Release kommt, kommt kein Release das du auswerten kannst. Du musst also nicht bei der Auswertung suchen sondern der Generierung.

Ich würde immer einen genutzten Button peeren. Wegen Release, wegen der LED, wegen den Wiederholungen, weil es einem System entspricht.
Wenn du nicht Aktor mit Aktor peeren willst baue einen virtuellen Kanal. Der kann ein Kanal der vccu sein oder ein virtuelles Device.

Device<->Device => gibt es nicht

Hallo Martin,

Was mir heute morgen bei den Test aufgefallen ist:

LongRelease wird bei mehrfach gepeerten Devices weiter hochgezählt.
Sollte es beim letzten nicht auch 9_37 sein?

2015.11.28 01:19:34.679 2: xxxx Long 1_37 (to CUL_HM_SW4_01)
2015.11.28 01:19:34.682 2: xxxx trigger: Long_37
2015.11.28 01:19:34.685 2: xxxx trigger_cnt: 37
2015.11.28 01:19:35.031 2: xxxx Long 2_37 (to CUL_HM_SW4_01)
2015.11.28 01:19:35.178 2: xxxx Long 3_37 (to CUL_HM_SW4_01)
2015.11.28 01:19:35.434 2: xxxx Long 4_37 (to CUL_HM_SW4_01)
2015.11.28 01:19:35.686 2: xxxx Long 5_37 (to CUL_HM_SW4_01)
2015.11.28 01:19:35.941 2: xxxx Long 6_37 (to CUL_HM_SW4_01)
2015.11.28 01:19:36.197 2: xxxx Long 7_37 (to CUL_HM_SW4_01)
2015.11.28 01:19:36.451 2: xxxx Long 8_37 (to CUL_HM_SW4_01)
2015.11.28 01:19:36.738 2: xxxx LongRelease 9_37 (to CUL_HM_SW4_01)
2015.11.28 01:19:36.982 2: xxxx LongRelease 10_37 (to vccu)

Ja, ein Bug

@martinp876:
... ok, habe mir jetzt eine Notiz an die Wand gepappt, damit ich nicht immer die Ausdrücke peer und pair verwechsle; scheiß Alzheimer  ::)
Mit den drei Stati meinte ich "Short", "Long", "LongRelease".

@all
Aber ist auch überholt; habe fertig  ;D
Was jetzt noch stört und was ich per Klimmzug eliminieren musste ist, das die SUB bei jedem Tastendruck genau 3 mal durchlaufen wird. Kann man das irgendwie verhindern oder ist das Systembedingt?

1. wie immer erst auf den eventmonitor schauen, um alle events zu sehen.
2. je nach eventmonitor eventuell die regex vom notify spezieller gestalten.
3. und/oder mit event-on-change die eventgenerierung beeinflussen.

Schau Dir die Events an, die Deine Sub triggern (ggf. in der Sub mitloggen) und dann die Events weiter einschränken auf die das notify reagieren soll.
In dem folgenden Beispiel würde die Sub nur aufgerufen, wenn das Device "Sensor" einen Event auslöst, in dem "Long 1_.*" oder "Short" vorkommt.
define frosch notify Sensor:(Long.1_.*|Short) { SetTimerOnTip("Aktor","$EVENT") }


... ich hatte und rufe die SUB ja auf mit
define di_1 notify EG_FL_6CH_CH1 { SetTimerOnTip("$NAME","KG_ZS_4CH_CH1","$EVENT") }
Damit wird die SUB angesprungen, egal ob da Short, Long oder LongEvent auftaucht. Aber ich werde es auch mal auf Deinem Weg probieren beim nächsten Sensor/Aktor. Denn dieser hier wird heute in den Zählerschrank gestopft und der Taster an der Haustür angepappt, damit meine MamaZicke wieder etwas geschmeidiger wird wenn sie sieht, für was sie die letzen Tage auf meine Präsenz verzichten musste ;)

Wie gesagt habe ich nun eine funktionierende Lösung. Sicherlich nicht besonders elegant, aber sie funktioniert genau so, wie ich mir das vorgestellt habe (mit Ausnahme des jeweils dreifachen Durchlaufens der SUB).

Weg ist:

HM-PB-6-WM55 --> FHEM --> HM-LC-Sw4-DR
ITS-150 (A-III)  --> FHEM --> HM-LC-Sw4-DR
HM-PB-6-WM55 <-- FHEM-Dummy (LED)

Nachträglich lasse ich den Handsender noch auf ein Dummydevice in FHEM laufen, um darüber kurze und lange Tastendrücke auszuwerten, um so auch damit den Teimer aktivieren zu können.
Und wenn das fertig ist, kümmere ich mich um die entsprechende Darstellung in FEHM, damit man nicht nur ON/OFF sehen kann, sondern auch den Timerbetrieb erkennt und setzen kann... Aber das hat Zeit.

... darf ich eben noch mal eine DummFrage loswerden?!

Warum taucht im Folgenden beim Klick auf einen der beiden Timereinträge an Stelle des Icons (message_socket) kurz "set_05 MIN" auf, anschliessend aber wieder das Icon "message_socket" und nicht wie gewünscht "general_an_fuer_zeit"???

attr KG_ZS_4CH_CH1 eventMap /on:AN/on-for-timer 300:05 MIN/on-for-timer 1800:30 MIN/off:AUS
attr KG_ZS_4CH_CH1 devStateIcon AN:message_socket@green \d+.*/MIN:general_an_fuer_zeit@orange AUS:message_socket@gray
... blablub ...
attr KG_ZS_4CH_CH1 webCmd AN:05 MIN:30 MIN:AUS

Bei Befehlsübermittlung wird ein set_ vorangestellt, bis der Befehl bestätigt wurde.

Steht in deinem STATE 5 MIN drin?

... ne, natürlich nicht :P
Zitat aus http://www.fhemwiki.de/wiki/EventMap :

ZitatWerden mit eventMap Werte umdefiniert, müssen zumindest in manchen Situationen (z.B. devStateIcon) die "neuen" Werte verwendet werden.

So sind ja auch die Icons für "on" und "off" gesetzt, die jetzt "AN" und "AUS" heißen. Ebenso heißt "on-for-timer 300" nun "05 MIN". Daher bin ich in Anlehnung an das Zitat nebst Wiki davon ausgegangen, das die Notation so korrekt ist.
Der Aktor generiert m.W. nur on:off. Allerdings sehe ich gerade erst, das es da noch was anderes gibt, nämlich "timedOn - running:AUS"... Da komme ich so ohne weiteres aber nicht dran?!? Also wohl wieder Klimmzüge machen?

devStateIcon bezieht sich immer auf das internal STATE. du kannst mir stateFormat bestimmen was in STATE steht.

das set_ taucht bei hm (und manchen anderen devices) so lange auf bis vom device das ack gekommen ist. mit passendem devStateIvon und/oder stateFormat kannst du für die set_ zustände ein eigenes icon anzeigen oder das set_ ignorieren.

im gegensatz zu FS20 ist bei homematic am state und STATE nicht zu erkennen ob (und wie lange) ein device eingeschaltet bleiben soll. unter anderem weil das unter umständen vom device selber abhängt. du kannst es intern so programmieren das es auch bei einem on (z.b. durch einen gepeerten taster) nur für eine gewisse zeit lang an bleibt.

es gibt 'nur' das reading timedOn an dem zu sehen ist das es kein permanentes on ist.

wie man das timedOn mit bei devStateIcon berücksichtig findest du z.b. hier: http://forum.fhem.de/index.php/topic,39969.msg322107.html#msg322107 (http://forum.fhem.de/index.php/topic,39969.msg322107.html#msg322107).

das sind keine 'klimmzüge' sondern liegt an dein eigenheiten und möglichkeiten von homematic. du musst fhem halt recht genau sagen wie es mit den vielen unterschiedlichen kombinationsmöglichkeiten die homematic bietet umgehen soll.

gruss
  andre

... was für die einen eine "nebenbei"- Geschichte, ist für die andere ein Klimmzug  ;D

Aber super! Genau das habe ich gesucht. Vermutlich hätte ich jetzt wieder probiert, da mit wilden SUB's o.ä. rumzudoktorn ^^ Ne, hätte ich doch nicht; ich hät's erstmal so gelassen ;)

EDIT:
Läuft so wie erwartet und sollte mir erstmal reichen; feine Sache das ;) Vielen Dank noch mal!

Irgendwann werde ich mir dann mal anschauen, ...
... ob es eine Möglichkeit gibt, dem Aktorkanal den aktuellen Zählerstand zu entlocken und via GD resp. ImageMagick als aktives Icon zu übergeben; das wäre mal knorke ;)
... wie man in der GUI an Stelle der vielen "Timertasten" ein Eingabefeld zur freien Eingabe schaffen kann

... mal 'ne bescheidene Frage:
Kann es sein, das ein Aktor von jetzt auf gleich nicht mehr auf seine Sensoren reagiert, wohl aber auf Befehle aus FHEM?!? Ich habe hier gerade ein ganz merkwürdiges Problem...
Mein Bruder war vorhin da, ebenfalls interessiert an dem Thema. Da der Hutschienenaktor und der 6fach- Taster immer noch nicht eingebaut ist (was dazwischen gekommen), wollte er das mal antesten... Dabei war festzustellen, das diese Timernummer auf einmal nicht mehr funktionierte. Also dachte ich mir, das ggf. irgend etwas hängt und habe den RPi kurzerhand neu gestartet. Nun aber reagiert der Aktor aber weder auf die 6fach-Taste, noch auf den ebenfalls zugewiesenen ITS-500. Lediglich aus FHEM raus lässt er sich noch steuern...
Auch ein Blick ins EventLOG und die CFG's hat mich nicht weiter gebracht; alles so wie gewohnt... Kapier ich nicht  >:(

Irgend wer eine glorreiche Idee?

was sagt fhem.log?

... nüscht relevantes ... konnte es auch nicht ... Irgendwie hat meine "chains.cfg" einen Knacks weg gehabt. FHEM hat beim Einlesen zwar keinen Fehler generiert, dennoch alle Inhalte ignoriert. Ich habe die Datei jetzt mal gelöscht und neu rein kopiert und nun geht das wieder (in der Datei stehen alle manuellen Zuweisungen "Sender/Sensoren" <-> "Empfänger/Aktoren"). Grund? Keine Ahnung :o

Aber jetzt stelle ich gerade eine andere Macke fest:
Kann es sein, das der "Trick"/Link von justme1968 ein paar Beiträge weiter oben bzgl. devStateIcon sich mit meiner SUB bezgl. TimerSET beißt? Ich werde das versuchsweise gleich mal rausnehmen, aber vorher hat es ja funktioniert... Mir dünkt, das nun der LongRelease nicht mehr erfasst werden kann?!?

Hier noch mal die relevanten Teile:

Ein Aktorkanal mit dem veränderten stateFormat:
define KG_ZS_4CH.1 CUL_HM 3A5CE401
attr KG_ZS_4CH.1 alias Licht Dachstuhl
attr KG_ZS_4CH.1 devStateIcon on:message_socket@green:off off:message_socket@gray:on timedOn:general_on_fuer_zeit@oronge:off
attr KG_ZS_4CH.1 eventMap /on-for-timer 300:[05m]/on-for-timer 900:[15m]/on-for-timer 1800:[30m]/on-for-timer 3600:[01h]/on-for-timer 7400:[02h]/on-for-timer 14800:[04h]
attr KG_ZS_4CH.1 group HM.Aktoren
attr KG_ZS_4CH.1 model HM-LC-SW4-DR
attr KG_ZS_4CH.1 peerIDs 00000000,FFFFFF01,
attr KG_ZS_4CH.1 room KG.Zählerschronk
attr KG_ZS_4CH.1 sortby 02
attr KG_ZS_4CH.1 stateFormat {if(ReadingsVal($name,"timedOn","off")eq"running"){return "timedOn";;}else{return ReadingsVal($name,"state","off");;}}
attr KG_ZS_4CH.1 webCmd on:[05m]:[15m]:[30m]:[01h]:[02h]:[04h]:off

Die SUB zum Timer-Erweitern:
### Timer setzen für Lichtautomaten ###

my $timer = 300;
my $multi = 0;
my $count = $timer;

sub SetTimerOnTip($$$) {
my ($SOURCE,$TARGET,$EVENT) = @_;

if ($EVENT =~ /\Short/m && ReadingsVal($TARGET,"state","err") eq "off" ) {
fhem ( "set $TARGET on" );
$count = $timer;
}
elsif ($EVENT =~ /\Short/m && ReadingsVal($TARGET,"state","err") eq "on" ) {
fhem ( "set $TARGET off" );
$multi = 1; $count = $timer;
}
elsif ( substr(ReadingsVal($SOURCE,"state","err"),0,11) eq "LongRelease" ) {
if (ReadingsVal($TARGET,"state","err") eq "on") {
$multi++;
}
$count = $timer * $multi;
if (int($count) == $count) {
fhem ( "set $TARGET on-for-timer $count"  );
}
}
}

... jetzt wird es ganz schräg  :o :o :o

Im letzten Teil der SUB (letzte Befehlszeile) wird zwar ...
fhem ( "set $TARGET on" );
...ausgeführt, aber ...
fhem ( "set $TARGET on-for-timer $count" );
... an gleicher Stelle wird ignoriert. $count hat im Übrigen immer einen Wert von 300 oder einem vielfachen davon.

Ein ...
print Dumper ("set $TARGET on-for-timer $count");
... also Kontrolle ergibt die korrekte Befehlszeile set KG_ZS_4CH_1 on-for-timer 600


Das ist reproduzierbar und mir vollkommen unerklärlich, vor allen Dingen deshalb, weil es ja mal genau so funktioniert hat  ??? :o >:(

wenn du HM Kommandos testen willst mache es erst einmal ohne Variablen - zumindest wenn du postest- Ich rate nicht gerne.
Und ich rate auch nicht gerne, was dein Problem ist.
Also wenn du
set KG_ZS_4CH_1 on-for-timer 600
passiert was? ich haben ein on-for-timer 600 probiert - klappt problemlos.
was sagen die messages? Bitte aufzeichnen. Kommt ein Fehler oder kommen einfach keine messages? Sind kommandos pending? Steht ein Overload am IO an? macht es doch nicht immer so kompliziert.

Zitatmacht es doch nicht immer so kompliziert.

Ich für meinen Teil finde es viel komplizierter, all das aufzuführen, was nicht ist, wie in diesem Fall auch ...

Es passiert schlicht und ergreifend ........... nichts!

# fhem ( "set $TARGET off" );
print Dumper ("set $TARGET on-for-timer $count");
# fhem ( "set $TARGET on-for-timer $count" );
fhem ( "set KG_ZS_4CH_1 on-for-timer 300" );
}
... habe ich selbstverständlich auch getestet. Das "on-for-timer" wird schlichtweg ignoriert, ohne Fehler, ohne Logeintrag, ohne Messages... nix "pending", nix "overload", nix nix ...
Und auch das Neuschreiben der Datei in Anlehnung an das chains.cfg-Problem hat nichts geändert, auch kein Neustart, auch kein Update, kein garnix...

... jetzt habe ich eine Fehlermeldung provozieren können direkt aus FHEM heraus ...

Gebe ich direkt in die FHEM Kommandozeile "set KG_ZS_4CH_1 on-for-timer 300" ein, erhalte ich eine Fehlermeldung wie folgt:
Unknown argument on-for-tion-for-timer, choose one of clear getConfig getRegRaw inhibit off on on-for-timer on-till peerBulk peerIODev press regBulk regSet sign statusRequest toggle
Wie man sieht, wird aus on-for-timer mal eben on-for-tion-for-timer, was er selbstverständlich nicht kennen kann. Die FRage ist jetzt halt nur, warum acht er das?!?

du sendest immer zusammengebaute kommandos und willst wissen, ob FHEM ein on-for-timer kann.

In deinem Programflow bekommst du eben KEINE Rückmeldung. Also noch einmal: nicht so kompliziert, immer einmal kleine Schritte. Untersuche die Kommandos einzeln, dann baue sie zusammen. So kannst du erkennen, wo das Problem ist. Ich kann das an deinem System eben nicht.

Wenn ich in die Kommandozeile ein
set laBusch on-for-timer 10
einbaue klappt das prima.

hast du irgendwelche alias gesetzt?  Das ist definitiv kein Systemverhalten. Schalte einmal deine replacements ab.

Zitatdu sendest immer zusammengebaute kommandos und willst wissen, ob FHEM ein on-for-timer kann.

... Du sprichst in Rätseln ...

ZitatGebe ich direkt in die FHEM Kommandozeile "set KG_ZS_4CH_1 on-for-timer 300" ein, erhalte ich eine Fehlermeldung wie folgt:

... wie bitte geht es noch direkter und an welcher Stelle übersehe ich den Zusammenhang zwischen "ProgramFlow" und Direkteingabe?

das kommando hat kein Problem.
dein system hat ein Problem.
nutzt du alias? Irgendwelche replacements? Sind updates offen? Jetzt musst du einmal selbst nachsehen.

die proceduren hattest du am Anfang - dann hast du hier gefragt, warum es nicht geht. Kann kein Mensch finden. Jetzt nutzt du das Kommando direkt, schon hast du eine Fehlermeldung. Jetzt probiere, warum das Kommando verhunzt wird. Es muss an deinen Einstellungen liegen.

... Thema hat sich durch Neuinstallation Debian & Co. und Zurückspielen der CFG's erledigt ... Weiß der Draht, was das war ^^