Habe heute versucht den Homematic wired Dimmer HMW-LC-Dim1L-DR in eine bestehende und funktionierende HM485 Installation einzubinden (die HM485 Dateien sind aktuell).
Das Anlernen habe ich zunächst mit discovery versucht, dann durch Betätigen eines Tastereingangs, dann durch Drücken des Anlernknopfes am Gerät.
Alles erfolglos, der Dimmer wird nicht durch autocreate angelegt.
Testweise habe ich dann den gesamten RS485 Strang an eine CCU1 drangehängt, alle Geräte, auch der Dimmer erscheinen.
An der Busverkabelung kanns also nicht liegen.
Weiss jemand Rat?
Danke und Gruss,
Herbert
Hi,
das ist seltsam. Erscheint denn gar nichts zu dem Teil?
Discovery funktioniert gar nicht, aber das ist halt noch nicht so ganz implementiert. Der Knopf auf dem Teil ist glaube ich kein Anlernknopf. D.h. das einzige, was funktionieren dürfte ist die Sache mit dem Tastereingang.
Könntest Du mal ein Level-5 Log machen wenn der Tastereingang betätigt wird?
Gruß,
Thorsten
habe nun mit verbose 5 beim tastendrücken geloggt.
in dem Wust an Meldungen konnte ich in einem HM485-Tx erkennen:
00000001 -> 0000BBF8
Habe letztere Adresse und die Serien-Nr. des Dimmers genommen und folgendes auf gut Glück in die fhem.cfg gesetzt:
define HMdim HM485 0000BBF8
attr HMdim model HMW_LC_Dim1L_DR
attr HMdim room HM485
attr HMdim serialNr KEQ0016253
nach einem restart hat sich das Device dann vollends selbst fertgkonfiguriert.
und nun läuft alles bestens.
Zitat von: HRueck am 01 Oktober 2015, 17:33:50
habe nun mit verbose 5 beim tastendrücken geloggt.
in dem Wust an Meldungen konnte ich in einem HM485-Tx erkennen:
00000001 -> 0000BBF8
Das ist etwas seltsam. Das ist eine Meldung von der Zentrale ans Device. Da müsste das Device vorher was gesendet haben, sonst wüsste die Zentrale ja nichts davon. Außerdem müsste man im Log noch viel mehr sehen.
Zitat
Habe letztere Adresse und die Serien-Nr. des Dimmers genommen und folgendes auf gut Glück in die fhem.cfg gesetzt:
define HMdim HM485 0000BBF8
attr HMdim model HMW_LC_Dim1L_DR
attr HMdim room HM485
attr HMdim serialNr KEQ0016253
nach einem restart hat sich das Device dann vollends selbst fertgkonfiguriert.
und nun läuft alles bestens.
Das ist ja schön für Dich, aber das deutet ja schon darauf hin, dass da was noch nicht ganz rund läuft.
Könntest Du doch mal den entsprechenden Ausschnitt aus dem Logfile hier reinhängen?
Ich würde mir das gerne mal selbst ansehen.
Außerdem: Könntest Du mal die Versionsnummer aus dem Header der datei 10_HM485.pm hier posten?
Gruß,
Thorsten
Datei ist 10_HM485.pm Version 0.7.24
Da in verbose 5 alles vom System geloggt wird, weiss ich nicht, was dich genau interessiert.
Hier aber mal ein Auszug:
.......
2015.10.01 17:17:18 5: HM485_LAN_parseIncommingCommand: Removing Queue 0000003D
2015.10.01 17:17:18 5: HM485_LAN_CheckResendQueueItems: QID: 0000003D
2015.10.01 17:17:18 5: HM485_LAN_SendQueueNextItem: QID: 0000003E
2015.10.01 17:17:18 5: SW: fd204753c80000bbf81a0000000157030010ffffffffffffffffffffffffffffffff
2015.10.01 17:17:18 4: HM485: TX: (71) I[1](0,F,B)(1A) 00000001 -> 0000BBF8 [22] 57(W) 030010FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2015.10.01 17:17:18 5: HM485_LAN_parseIncommingCommand: MsgId: 71 Cmd: 114
2015.10.01 17:17:18 5: HM485_LAN_parseIncommingCommand: Response: (71)
2015.10.01 17:17:18 5: HM485 dispatch �Gr9
2015.10.01 17:17:18 5: HM485_Parse: MsgId: 71
2015.10.01 17:17:18 5: HM485_Parse: ProcessResponse
2015.10.01 17:17:18 5: HM485_ProcessResponse: msgData =
2015.10.01 17:17:18 5: HM485_LAN_parseIncommingCommand: Removing Queue 0000003E
2015.10.01 17:17:18 5: HM485_LAN_CheckResendQueueItems: QID: 0000003E
2015.10.01 17:17:18 5: HM485_LAN_SendQueueNextItem: QID: 0000003F
2015.10.01 17:17:18 5: SW: fd204853c80000bbf81c0000000157003010ffffffffffffffffffffffffffffffff
2015.10.01 17:17:18 4: HM485: TX: (72) I[2](0,F,B)(1C) 00000001 -> 0000BBF8 [22] 57(W) 003010FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2015.10.01 17:17:18 5: HM485_LAN_parseIncommingCommand: MsgId: 72 Cmd: 114
2015.10.01 17:17:18 5: HM485_LAN_parseIncommingCommand: Response: (72)
2015.10.01 17:17:18 5: HM485 dispatch �HrY
2015.10.01 17:17:18 5: HM485_Parse: MsgId: 72
2015.10.01 17:17:18 5: HM485_Parse: ProcessResponse
2015.10.01 17:17:18 5: HM485_ProcessResponse: msgData =
2015.10.01 17:17:18 5: HM485_LAN_parseIncommingCommand: Removing Queue 0000003F
2015.10.01 17:17:18 5: HM485_LAN_CheckResendQueueItems: QID: 0000003F
2015.10.01 17:17:18 5: HM485_LAN_SendQueueNextItem: QID: 00000040
2015.10.01 17:17:18 5: SW: fd204953c80000bbf81e000000015700b010ffffffffffffffffffffffffffffffff
2015.10.01 17:17:18 4: HM485: TX: (73) I[3](0,F,B)(1E) 00000001 -> 0000BBF8 [22] 57(W) 00B010FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2015.10.01 17:17:18 5: HM485_LAN_parseIncommingCommand: MsgId: 73 Cmd: 114
........
so ähnlich wiederholt sich das Ganze sehr oft!
Hi,
der Auszug sieht so aus, als ob FHEM ins EEPROM des Geräts schreibt. Das passiert eigentlich nur dann, wenn Du irgendwelche Einstellungen gemacht hast bzw. diese sicherst.
Ich meinte eigentlich einen kompletten Auszug aus dem Log ab dem Zeitpunkt, an dem Du die Taste gedrückt hast (also den Eingang am Dimmer aktiviert hast) bis ungefähr 3 Minuten danach.
...und da einfach alles, ich such mir dann schon das richtige raus. Am besten, Du hängst das zwischen code-tags (die Taste mit dem # drücken), dann wird der Beitrag nicht so unübersichtlich.
Gruß,
Thorsten
hier der log als Anhang
Hi,
also ich habe mal angefangen, das ganze zu analysieren:
2015.10.01 10:55:13 3: HM485: Interface-Type: eQ3-HMW-LGW
Du hast also das Gateway von eQ3, d.h. da läuft kein hm485d. Korrekt?
2015.10.01 11:14:55 3: HM485: NACK: (30) 0000BBF8
2015.10.01 11:16:29 2: HM485: Discovery - canceled. No results found within 10 seconds!
2015.10.01 11:21:30 2: HM485: Discovery - canceled. No results found within 10 seconds!
Die erste Zeile ist das erste im Log, was ich zum Device 0000BBF8 finde. Ein NACK kann eigentlich nur dadurch kommen, dass etwas an das Device geschickt wurde, aber das Device keine Antwort gegeben hat. D.h. entweder, Du hast da was mit RAW-Messages probiert oder FHEM hat das Device davor schon gekannt. Kann das sein?
Die anderen beiden Zeilen zeigen die misslungenen Discovery-Versuche.
Ähnliches kommt später auch noch mal vor.
[code]
2015.10.01 17:06:26 5: HM485_LAN_parseIncommingCommand: MsgId: 66 Cmd: 101
2015.10.01 17:06:26 4: HM485: Event: I[0](3,Y,F,B)(F8) 0000BBF8 -> FFFFFFFF [4] 4B(K) 01
2015.10.01 17:06:26 5: HM485 dispatch ����
ich habe keine raw-Befehle geschickt und das Gerät konnte definitiv nicht bekannt gewesen sein!
werde demnächst noch weitere gleiche Geräte installieren, mal sehen wie die sich verhalten.
btw: sowas wie einen dim-up/down-Befehl scheint es nicht zu geben, oder?
Zitat von: HRueck am 02 Oktober 2015, 16:13:54
btw: sowas wie einen dim-up/down-Befehl scheint es nicht zu geben, oder?
Hi,
Ich habe gerade nochmal im Device-XML nachgeschaut. Der einzige Befehl, den das Ding akzeptiert ist "set level" (in FHEM-Sprache). Es gibt wohl die Möglichkeit, durch direktes Peering mit Tasten ein "Dim Step" zu machen, aber nicht als direkter Befehl.
Was genau wolltest Du denn damit machen?
Gruß,
Thorsten
ich möchte gerne mit Tastendruck (sowohl vom web aus als auch per Hardware-Taster) rauf bzw. runterdimmen.
am schönsten wäre natürlich folgende Lösung:
Taster kurz drücken -> dimmt hoch
gleichen Taster wieder kurz drücken -> stop
gleichen Taster wieder kurz drücken -> dimmt runter
gleichen Taster wieder kurz drücken -> stop
Taster lang drücken -> toggle an/aus
aber reines rauf/runter wäre schon mal ein netter Anfang.
Gruss Herbert
Hi,
das könnte per direktem Peering mit einem Taster funktionieren. Du musst halt mal mit der Konfiguration des Peering (des Links) rumspielen. Wahrscheinlich muss SHORT_ACTION_TYPE auf TOGGLEDIM gesetzt werden.
(Ich habe das alles nur aus dem Device-XML. Ausprobiert habe ich das nicht.)
Von FHEMWEB aus geht das wahrscheinlich nicht ganz so einfach. Ein virtuelles HMW-Device haben wir (noch) nicht. (...denn dann könnte man dessen "Tasten" peeren.)
Ich kann mir aber vorstellen, dass man das mit einem Dummy und dem Anlegen und Löschen eines geschickten "at" hinbekommen kann. Allerdings weiß ich nicht, wie man einen langen Tastendruck auf dem Web-Frontend macht.
Gruß,
Thorsten
habe nun ein weiteres (Fabrik-neues) Modul eingebunden.
genau dasselbe Verhalten!
log nach dem Betätigen eines Tasters:
2015.10.06 15:52:53 5: HM485 dispatch �+e�����/�K�
2015.10.06 15:52:53 5: HM485_Parse: MsgId: 43
2015.10.06 15:52:53 5: HM485_Parse: ProcessEvent
2015.10.06 15:52:53 4: HM485: Device 00012FBF not defined yet. We need the type for autocreate
2015.10.06 15:52:53 5: HM485_GetNewMsgQueue: bla
2015.10.06 15:52:53 5: HM485_QueueCommand: 68
2015.10.06 15:52:53 5: HM485_QueueStart: Num: 0
2015.10.06 15:52:53 5: HM485_QueueProcessStep: HASH(0x2c1ec70)
2015.10.06 15:52:53 5: HM485_SendCommand: 68
2015.10.06 15:52:53 5: HM485_LAN_Write: TX: 50
2015.10.06 15:52:53 5: HM485_LAN_SendQueueNextItem: QID: 000000F1
2015.10.06 15:52:53 5: SW: fd0d3253c800012fbf980000000168
2015.10.06 15:52:53 4: HM485: TX: (50) I[0](0,Y,F,B)(98) 00000001 -> 00012FBF [3] 68(h)
2015.10.06 15:52:53 5: HM485_DoSendCommand: hmwId = 00012FBF data = 68 requestId = 50
2015.10.06 15:52:53 5: HM485_QueueSetRequestId: start
2015.10.06 15:52:53 5: HM485_QueueSetRequestId: Id: 50
2015.10.06 15:52:53 5: HM485_LAN_parseIncommingCommand: MsgId: 50 Cmd: 97
2015.10.06 15:52:53 5: HM485_LAN_parseIncommingCommand: Alive: (50) 02 AliveStatus: 02
2015.10.06 15:52:53 5: HM485_LAN_DispatchNack: Start
2015.10.06 15:52:53 3: HM485: NACK: (50) 00012FBF
2015.10.06 15:52:53 5: HM485_LAN_parseIncommingCommand: MsgId: 44 Cmd: 101
2015.10.06 15:52:53 4: HM485: Event: I[0](1,Y,F,B)(B8) 00012FBF -> FFFFFFFF [16] 41(A) 00140003034D45513033313231
2015.10.06 15:52:53 5: HM485 dispatch �,e�����/�AMEQ0312121
2015.10.06 15:52:53 5: HM485_Parse: MsgId: 44
2015.10.06 15:52:53 5: HM485_Parse: ProcessEvent
2015.10.06 15:52:53 4: HM485: Device 00012FBF not defined yet. We need the type for autocreate
2015.10.06 15:52:53 5: HM485_GetNewMsgQueue: bla
2015.10.06 15:52:53 5: HM485_QueueCommand: 68
2015.10.06 15:52:53 5: HM485_QueueStart: Num: 1
nach manuellem Eintrag in die fhem.cfg mit 00012FBF und MEQ0312121 läuft das Modul.
Gruss Herbert
Hi,
der interessante Part ist das hier:
2015.10.06 15:52:53 4: HM485: TX: (50) I[0](0,Y,F,B)(98) 00000001 -> 00012FBF [3] 68(h)
2015.10.06 15:52:53 5: HM485_DoSendCommand: hmwId = 00012FBF data = 68 requestId = 50
2015.10.06 15:52:53 5: HM485_QueueSetRequestId: start
2015.10.06 15:52:53 5: HM485_QueueSetRequestId: Id: 50
2015.10.06 15:52:53 5: HM485_LAN_parseIncommingCommand: MsgId: 50 Cmd: 97
2015.10.06 15:52:53 5: HM485_LAN_parseIncommingCommand: Alive: (50) 02 AliveStatus: 02
2015.10.06 15:52:53 5: HM485_LAN_DispatchNack: Start
2015.10.06 15:52:53 3: HM485: NACK: (50) 00012FBF
FHEM schickt ein 0x68 ans Device, aber das scheint darauf nicht antworten zu wollen. Komischerweise scheint aber die restliche Kommunikation mit den Teilen zu funktionieren. Moeglicherweise hat eq3 da was geaendert. Sind die Teile ganz neu oder schon aelter?
Koenntest Du mal folgendes probieren:
1. Log level auf 5 setzen
2. In der Anzeige des Device in FHEM ein "set <device> raw 68" absetzen.
3. Ungefaehr 10 Sekunden warten
4. Log level wieder auf "normal" schalten
5. Den entsprechenden Log-Ausschnitt hier posten.
Ich kann das selbst momentan nicht ausprobieren, da ich erstens kein solches Device habe und zweitens weit weg von daheim bin. Aber vielleicht finden wir ja was ueber die logs raus.
Gruss,
Thorsten
Das Modul war neu.
Hier der log-Auszug nach set raw 68:
2015.10.09 09:28:02 5: Cmd: >set HMDim_2 raw 68<
2015.10.09 09:28:02 5: HM485_SendCommand: 68
2015.10.09 09:28:02 5: HM485_LAN_Write: TX: 67
2015.10.09 09:28:02 5: HM485_LAN_SendQueueNextItem: QID: 0000011A
2015.10.09 09:28:02 5: SW: fd0d4353c800012fbf180000000168
2015.10.09 09:28:02 4: HM485: TX: (67) I[0](0,F,B)(18) 00000001 -> 00012FBF [3] 68(h)
2015.10.09 09:28:02 5: HM485_DoSendCommand: hmwId = 00012FBF data = 68 requestId = 67
2015.10.09 09:28:02 5: HM485_QueueSetRequestId: start
2015.10.09 09:28:02 4: FHEMWEB:192.168.1.10:64606 GET /fhem?detail=HMDim_2; BUFLEN:0
2015.10.09 09:28:02 5: HM485:Device:dataConversion: retVal = 2.00
2015.10.09 09:28:03 4: name: /fhem?detail=HMDim_2 / RL:3065 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.10.09 09:28:03 5: HM485_LAN_parseIncommingCommand: MsgId: 67 Cmd: 114
2015.10.09 09:28:03 5: HM485_LAN_parseIncommingCommand: Response: (67) 1400
2015.10.09 09:28:03 5: HM485 dispatch �Cr
2015.10.09 09:28:03 5: HM485_Parse: MsgId: 67
2015.10.09 09:28:03 5: HM485_Parse: ProcessResponse
2015.10.09 09:28:03 5: HM485_ProcessResponse: msgData = 1400
2015.10.09 09:28:03 5: HM485_ProcessResponse: deviceKey = requestType = 68 requestData = msgData = 1400
2015.10.09 09:28:03 5: HM485:Device:dataConversion: retVal = 2.00
2015.10.09 09:28:03 5: Triggering global (1 changes)
2015.10.09 09:28:03 5: Notify loop for global ATTR HMDim_2 model HMW_LC_Dim1L_DR
2015.10.09 09:28:03 5: HM485_LAN_parseIncommingCommand: Removing Queue 0000011A
2015.10.09 09:28:03 5: HM485_LAN_CheckResendQueueItems: QID: 0000011A
2015.10.09 09:28:03 4: FHEMWEB:192.168.1.10:64606 GET /fhem?cmd={ReadingsVal(%22HMDim_2%22,%22config%22,%22%22)}&XHR=1; BUFLEN:0
2015.10.09 09:28:03 5: Cmd: >{ReadingsVal("HMDim_2","config","")}<
2015.10.09 09:28:03 4: name: /fhem?cmd={ReadingsVal(%22HMDim_2%22,%22config%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.10.09 09:28:03 4: Connection accepted from FHEMWEB:192.168.1.10:64607
2015.10.09 09:28:03 4: FHEMWEB:192.168.1.10:64607 GET /fhem?cmd={AttrVal(%22HMDim_2%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2015.10.09 09:28:03 5: Cmd: >{AttrVal("HMDim_2","room","")}<
2015.10.09 09:28:03 4: name: /fhem?cmd={AttrVal(%22HMDim_2%22,%22room%22,%22%22)}&XHR=1 / RL:26 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
Hi,
da scheint auf das 0x68 eine korrekte Antwort zurueck zu kommen.
Tja, so recht weiss ich da auf die Entfernung auch nicht weiter. Vielleicht ist das Problem tatsaechlich, dass beim Tastendruck auf das 0x4B gleich ein 0x41 nachkommt und sich der autocreate-Prozess daran irgendwie verschluckt.
Ich kann versuchen, das zuhause nachzustellen, aber das wird fruehestens naechste Woche sein. Fuer Dich ist das ja nicht so schlimm.
Vielleicht ist das Problem auch spezifisch fuer den eQ3-HMW-LGW, und so einen habe ich nicht...
Ich lasse da mal mein Unterbewusstsein dran arbeiten und melde mich wieder.
Falls sonst noch jemand Vermutungen oder Erkenntnisse hat, dann her damit.
Gruss,
Thorsten
Hallo zusammen,
ich möchte hier nochmal mein Glück probieren.
Ich habe ebenfalls den HMW_LC_Dim1L_DR in Kombination mit dem LAN-Gateway von Homematic.
Die Installation lief problemlos. FHEM hat die Geräte sofort erkannt und korrekt erstellt.
Hat es mittlerweile jemand geschafft mit dem Dimmaktor eine Rampe über das Web-Frontend hinzubekommen?
Ich habe aktuell noch den HM-LC-DIM1T-FM eingesetzt mit dem das ganze ja problemlos geht.
set Licht1 pct 50 0 5
Mit dem Wired Modul kann ich aber nur Prozentwerte "hart" anfahren.
Freundliche Grüße
Zitat von: Take-Off am 09 Januar 2016, 11:37:50
Hat es mittlerweile jemand geschafft mit dem Dimmaktor eine Rampe über das Web-Frontend hinzubekommen?
Ich habe aktuell noch den HM-LC-DIM1T-FM eingesetzt mit dem das ganze ja problemlos geht.
set Licht1 pct 50 0 5
Mit dem Wired Modul kann ich aber nur Prozentwerte "hart" anfahren.
Hi,
laut Device-XML haben die Peerings irgendwas mit Rampen drin. Du kannst ja mal versuchen, irgendeine Taste mit dem Aktorkanal zu peeren und dann mit den peersettings zu spielen. Vom FHEM aus koenntest Du dann den Tastendruck mit "set ... short_press" vom Sensorkanal aus simulieren.
Das ist nur so eine Idee.
Ansonsten waere es interessant, wie das genau intern bei HM-Funk laeuft. Wenn das FHEM irgendwie emuliert, dann wuerde ich es nur sehr, sehr ungern ins Modul einbauen. Meiner Meinung nach soll das Modul nur das widerspiegeln, was die Geraete wirklich koennen. Alles Weitere sollte man mit darauf aufsetzenden Modulen oder Funktionen machen. (Z.B. ein at, das einmal pro Sekunde um 2 Prozent in die Soll-Richtung faehrt, bis der Sollwert erreicht ist.)
Gruss,
Thorsten
Vielen Dank für deine Antwort.
Was genau meinst du mit den "peersettings spielen"?
Mir fehlt zu diesen Devices leider auch jegliche Info um durch "rumprobieren" weiter zu kommen.
Für die Funk-Geräte gibt es wesentlich mehr Info auch hier im Forum. :-\
Gepeert hab ich bereits, Short und Long Press kann ich problemlos über das Web-Frontend abschicken.
Ich hab das Gerät auch leider nur noch heute hier, da die Rückgabefrist abläuft.
Momentan ist es für mich ja leider nicht sinnvoll einsetzbar. :(
EDIT: Jetzt hab ich verstanden was du mit Peersettings meinst.
Ich habe auch meine bestehende Schaltung einigermaßen ersetzt bekommen. Dafür hinterlege ich meine verschiedenen "Szenarien" in den Short und Long Peers der beiden Channel. Allerdings ist diese Lösung nicht sehr elegant meiner Meinung nach.
Bewegungsmelder (Auslösen im dunkeln) --> set Ch01 press_short
Bewegungsmelder (Auslösen im hellen) --> set Ch01 press_long (Halbe Helligkeit)
Licht aus --> set Ch02 press_short (Umgekehrte Logik: 0.1s an)
Eine Lösung wie sie bei den Funkmodulen genutzt wird erscheint mir bedeutend sinnvoller. :)
Grüße :)
Zitat von: Take-Off am 11 Januar 2016, 18:17:33
Mir fehlt zu diesen Devices leider auch jegliche Info um durch "rumprobieren" weiter zu kommen.
Für die Funk-Geräte gibt es wesentlich mehr Info auch hier im Forum. :-\
Das liegt hauptsaechlich daran, dass die Funk-Teile mehr genutzt werden.
...aber vielleicht klicke mal auf den Link "Device specific help" rechts unterhalb der Device-Details in FHEM. Ausserdem zeigt die Oberflaeche in FHEM inzwischen so ziemlich alles an, was das Device kann, zumindest wenn man auch mal die peersettings betrachtet.
Ich selbst habe auch keine gute Doku zu allen Devices. Ich schaue mir normalerweise das Device-XML an. In FHEM muesstest Du diese unter /opt/fhem/FHEM/lib/HM485/Devices/xml finden (zumindest bei einer Standard-Installation).
Zitat
Ich habe auch meine bestehende Schaltung einigermaßen ersetzt bekommen. Dafür hinterlege ich meine verschiedenen "Szenarien" in den Short und Long Peers der beiden Channel.
Es waere nett, wenn Du mal die komplette Loesung hier beschreiben koenntest.
Zitat
Eine Lösung wie sie bei den Funkmodulen genutzt wird erscheint mir bedeutend sinnvoller. :)
Soweit ich das verstehe koennen die HMW-Dimmer so etwas nicht direkt. Ich habe nicht analysiert, wie das bei den Funk-Teilen aussieht. Ich kann mir vorstellen, dass Martin das im FHEM-Modul irgendwie programmiert hat. So etwas wuerde ich (wie schon gesagt) allerdings nur sehr ungern tun. Meiner Meinung nach sollte das FHEM-Modul das abdecken, was die Devices selbst koennen. Den Rest kann man dann per weiterem Modul oder weiterer Funktion draufsetzen. Ansonsten wuerde es so aussehen, als ob das Device es koennte und man wundert sich nachher, warum das den Bus vollmuellt.
Gruss,
Thorsten
ZitatEs waere nett, wenn Du mal die komplette Loesung hier beschreiben koenntest.
Ich habe beide Channels des HMW-LC-Dim1L-DR mit dem Aktorpart gepeert und mir dabei in die Peersettings meine benötigten Werte eingetragen.
CH01 --> Rampe auf 100% ; hier sind auch die bestehenden Taster über ein Relais angebunden.
Ch01 (long) --> Rampe auf 50%
Ch02 (short) --> Rampe auf 99% (Hängt mit dem Code für den BWM zusammen)
Ch02 (long) --> Rampe für aus. Dafür muss in den PeerSettings die On_Time auf 0.1s gesetzt werden. (Umgedrehte Logik) Zur Sicherheit kommt dann nach 5 Sekunden noch ein "set Aktor level_0" Anstatt in meinem BWM Notify nun direkt den Aktor mit "set Aktor level_100" anzusteuern (hier ist ja keine Rampe möglich) habe ich "set Ch01 press_short" als Befehl hinterlegt. Die Rampe wird nun also über den Umweg des Channels gefahren.
Das ganze kostet mich natürlich unnötig Hardware Ressourcen, da ich den eig. unbenötigten CH02 jetzt nicht für andere Spielereien nutzen kann.
Ich hoffe ich konnte es einigermaßen rüberbringen. :) Bei Bedarf kann ich auch noch meinen Code für den BWM posten.
Wie das Funkmodul die Rampe löst kann ich dir leider nicht sagen, dafür habe ich zu wenig Hintergrundwissen.
Ich kann dir aber sagen dass es FHEM nicht unnötig (zumindest nicht spürbar) belastet. Auch nicht bei langen Rampenzeiten.
Zitat von: Take-Off am 12 Januar 2016, 18:14:58
Ich habe beide Channels des HMW-LC-Dim1L-DR mit dem Aktorpart gepeert und mir dabei in die Peersettings meine benötigten Werte eingetragen.
Genau daran waere ich interessiert. Wie sieht das in den Peersettings genau aus und was tut es dann genau?
ZitatAnstatt in meinem BWM Notify nun direkt den Aktor mit "set Aktor level_100" anzusteuern (hier ist ja keine Rampe möglich) habe ich "set Ch01 press_short" als Befehl hinterlegt. Die Rampe wird nun also über den Umweg des Channels gefahren.
Das war klar, nur was ist ein "BWM"?
ZitatDas ganze kostet mich natürlich unnötig Hardware Ressourcen, da ich den eig. unbenötigten CH02 jetzt nicht für andere Spielereien nutzen kann.
Im Prinzip musst Du ja nicht einen Tastereingang des Dimmers selbst nutzen. Ich ueberlege mir auch schon seit einiger Zeit, ob ich nicht so etwas wie ein virtuelles HMW-Device in FHEM hinbekommen koennte. Das waere fuer Dich wahrscheinlich ziemlich nuetzlich: Du koenntest dann den Aktor mit einem Sensor peeren, den es eigentlich gar nicht gibt.
ZitatBei Bedarf kann ich auch noch meinen Code für den BWM posten.
Das waere schon nuetzlich, denke ich.
Zitat
Wie das Funkmodul die Rampe löst kann ich dir leider nicht sagen, dafür habe ich zu wenig Hintergrundwissen.
Ich kann dir aber sagen dass es FHEM nicht unnötig (zumindest nicht spürbar) belastet. Auch nicht bei langen Rampenzeiten.
In FHEM wuerde man das auch nicht merken, ich haette da nur Sorge mit dem Funk-Kontingent.
Mal sehen, wenn ich wieder mal zuhause bin, dann kann ich mir's vielleicht anschauen.
Gruss,
Thorsten
Ich hab dir von den Einstellmöglichkeiten mal einen Screenshot gemacht.
Was jeder Kanal genau macht kann ich dir noch nicht sagen. Mir reichen momentan die Rampenzeiten und die Leveleinstellungen.
Sorry, BWM heißt Bewegungsmelder. :)
ZitatIm Prinzip musst Du ja nicht einen Tastereingang des Dimmers selbst nutzen. Ich ueberlege mir auch schon seit einiger Zeit, ob ich nicht so etwas wie ein virtuelles HMW-Device in FHEM hinbekommen koennte. Das waere fuer Dich wahrscheinlich ziemlich nuetzlich: Du koenntest dann den Aktor mit einem Sensor peeren, den es eigentlich gar nicht gibt.
Das wäre evtl. eine gute Lösung. Allerdings auch wie meine jetzige Lösung um 3 Ecken gebastelt :-\
ZitatIn FHEM wuerde man das auch nicht merken, ich haette da nur Sorge mit dem Funk-Kontingent.
Damit hatte ich gar keine Probleme obwohl ich beim Programmieren damals Unmengen an Tests gemacht habe.
Hier mal noch mein Code für die Ansteuerung des Kellerlichts. Das mag unnötig kompliziert aussehen und ist auch als Einzeiler getippt, erfüllt aber meinen Zweck und ich hatte keine bessere Idee ;D
BewegungsmelderKeller:motion { if (Value("Kellerlicht_03") eq "level_0") { if ( ReadingsVal( "BewegungsmelderKeller", "brightness", "") <= 38 ) {fhem("set Kellerlicht_02 press_short ; defmod KellerlichtAusBWM at +00:01:05 Kellerlicht_02 press_long ;; sleep 5 ;; set Kellerlicht_03 off")} else {fhem("set Kellerlicht_01 press_long ; defmod KellerlichtAusBWM at +00:01:05 set Kellerlicht_02 press_long ;; sleep 5 ;; set Kellerlicht_03 off")} } else { if (Value("Kellerlicht_03") eq "level_95") {fhem ("defmod KellerlichtAusBWM at +00:01:05 set Kellerlicht_02 press_long ;; sleep 5 ;; set Kellerlicht_03 off")} } }Was die einzelnen Kanäle machen hatte ich ja oben schon geschrieben, das spar ich mir jetzt. :)
Gruß