HM-MOD-Re-8 in fhem integrieren und Relais schalten

[betateilchen]

martin, wenn Du Dir meinen letzten Beitrag anschaust, wirst Du feststellen, dass ich die intKey bereits auf visib gestellt habe. Ein anschließendes getConfig bringt keine Änderung.

[betateilchen]

ha... jetzt hab ich eine Fernbedienung mit einem der Channels gepeert, siehe da...

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        2C072501
   NAME       CUL_HM_HM_MOD_Re_8_2C0725_Sw_01
   NR         305
   STATE      on
   TYPE       CUL_HM
   chanNo     01
   device     CUL_HM_HM_MOD_Re_8_2C0725
   peerList   HMFB03_Btn_04,self01,
   Readings:
     2014-07-29 19:55:29   CommandAccepted yes
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgActionType jmpToTarget
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgCtDlyOff geLo
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgCtDlyOn geLo
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgCtOff geLo
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgCtOn geLo
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgCtValHi 100
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgCtValLo 50
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgMultiExec on
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgOffDly 0 s
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgOffTime 111600 s
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgOffTimeMode absolut
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgOnDly 0 s
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgOnTime 111600 s
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgOnTimeMode absolut
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgSwJtDlyOff off
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgSwJtDlyOn on
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgSwJtOff dlyOn
     2014-07-29 21:04:00   R-HMFB03_Btn_04-lgSwJtOn dlyOff
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shActionType jmpToTarget
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shCtDlyOff geLo
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shCtDlyOn geLo
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shCtOff geLo
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shCtOn geLo
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shCtValHi 100
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shCtValLo 50
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shOffDly 0 s
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shOffTime 111600 s
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shOffTimeMode absolut
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shOnDly 0 s
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shOnTime 111600 s
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shOnTimeMode absolut
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shSwJtDlyOff off
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shSwJtDlyOn on
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shSwJtOff dlyOn
     2014-07-29 21:04:00   R-HMFB03_Btn_04-shSwJtOn dlyOff
     2014-07-29 20:29:19   R-self01-lgActionType jmpToTarget
     2014-07-29 20:29:19   R-self01-lgCtDlyOff geLo
     2014-07-29 20:29:19   R-self01-lgCtDlyOn geLo
     2014-07-29 20:29:19   R-self01-lgCtOff geLo
     2014-07-29 20:29:19   R-self01-lgCtOn geLo
     2014-07-29 20:29:19   R-self01-lgCtValHi 100
     2014-07-29 20:29:19   R-self01-lgCtValLo 50
     2014-07-29 20:29:19   R-self01-lgMultiExec on
     2014-07-29 20:29:19   R-self01-lgOffDly 0 s
     2014-07-29 20:29:19   R-self01-lgOffTime 111600 s
     2014-07-29 20:29:19   R-self01-lgOffTimeMode absolut
     2014-07-29 20:29:19   R-self01-lgOnDly 0 s
     2014-07-29 20:29:19   R-self01-lgOnTime 111600 s
     2014-07-29 20:29:19   R-self01-lgOnTimeMode absolut
     2014-07-29 20:29:19   R-self01-lgSwJtDlyOff off
     2014-07-29 20:29:19   R-self01-lgSwJtDlyOn on
     2014-07-29 20:29:19   R-self01-lgSwJtOff dlyOn
     2014-07-29 20:29:19   R-self01-lgSwJtOn dlyOff
     2014-07-29 20:29:19   R-self01-shActionType jmpToTarget
     2014-07-29 20:29:19   R-self01-shCtDlyOff geLo
     2014-07-29 20:29:19   R-self01-shCtDlyOn geLo
     2014-07-29 20:29:19   R-self01-shCtOff geLo
     2014-07-29 20:29:19   R-self01-shCtOn geLo
     2014-07-29 20:29:19   R-self01-shCtValHi 100
     2014-07-29 20:29:19   R-self01-shCtValLo 50
     2014-07-29 20:29:19   R-self01-shOffDly 0 s
     2014-07-29 20:29:19   R-self01-shOffTime 111600 s
     2014-07-29 20:29:19   R-self01-shOffTimeMode absolut
     2014-07-29 20:29:19   R-self01-shOnDly 0 s
     2014-07-29 20:29:19   R-self01-shOnTime 111600 s
     2014-07-29 20:29:19   R-self01-shOnTimeMode absolut
     2014-07-29 20:29:19   R-self01-shSwJtDlyOff off
     2014-07-29 20:29:19   R-self01-shSwJtDlyOn on
     2014-07-29 20:29:19   R-self01-shSwJtOff dlyOn
     2014-07-29 20:29:19   R-self01-shSwJtOn dlyOff
     2014-07-29 20:28:05   R-sign          off
     2014-07-29 21:04:50   RegL_03:HMFB03_Btn_04  02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00
     2014-07-29 21:04:52   RegL_03:self01   02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00
     2014-07-29 21:03:55   deviceMsg       on (to vccu)
     2014-07-29 21:03:55   level           100
     2014-07-29 21:03:55   pct             100
     2014-07-29 21:04:17   peerList        HMFB03_Btn_04,self01,
     2014-07-29 21:03:55   recentStateType info
     2014-07-29 21:03:55   state           on
     2014-07-29 21:03:55   timedOn         off
   Helper:
     dlvlCmd    ++A0111270002C07250201000000
     peerIDsRaw ,2C072501,252E3404,00000000
     Role:
       chn        1
       prs        1
     Shadowreg:
Attributes:
   group      MOD8
   model      HM-MOD-Re-8
   peerIDs    00000000,252E3404,2C072501,
   room       MOD8
   webCmd     statusRequest:toggle:on:off


[betateilchen]

Das Schalten hat genau einmal funktioniert. In der Fernbedienung ist vom gepeerten Channel nichts mehr zu sehen. Komisch.

Edit: Peering nochmal eingerichtet, jetzt scheint es stabil zu sein.

[betateilchen]

Ich frage mich grade, was sich hinter dem derzeit angezeigten Register confBtnTime verbirgt. Ausserdem vermisse ich ein Register zum Einstellen der lowBat Schwelle - ein solches Register muss es geben, da ich über die CCU2 diesen Wert einstellen kann.

(http://up.picr.de/19060359ea.jpg)

Achja - die CCU2 zeigt auch automatisch den "richtigen" Modellnamen an.

[frank]

Ich frage mich grade, was sich hinter dem derzeit angezeigten Register confBtnTime verbirgt. Ausserdem vermisse ich ein Register zum Einstellen der lowBat Schwelle - ein solches Register muss es geben, da ich über die CCU2 diesen Wert einstellen kann.

stell doch mal was ein für lowBat mit ccu, und mache anschliessend über fhem getconfig. da müsste sich ja dann was ändern. vielleicht confBtnTime.


ich versuche die ganze zeit mit meiner cul das device zu simulieren, indem ich deine anlernmessage über die cul versende. dazu mache ich

Code Auswählen Erweitern

2014.07.29 23:11:56.873 3: set cul868 raw As190384002C07250000001000BE4C45513035373439383110480100
2014.07.29 23:11:56.874 4: CUL_send:  cul868As 19 03 8400 2C0725 000000 1000BE4C45513035373439383110480100

aber weder hmlan noch hmusb empfangen diese nachricht. was mache ich falsch?
mein plan war eigentlich, das simulierte device dadurch an die winsoftware anzulernen, um ebenfalls deine screenshots zu bekommen.

[Bennemannc]

Hallo,

@betateilchen

Code Auswählen Erweitern

Ausserdem vermisse ich ein Register zum Einstellen der lowBat Schwelle - ein solches Register muss es geben, da ich über die CCU2 diesen Wert einstellen kann.

- muss es nicht. Ich habe einen 4 Kanal Actor (die Platine). Da habe ich mit Martin auch schon versucht herauszufinden was die da treiben. Definitv "merkt" sich die CCU bei diesem Actor den Wert für BatLow. Nach einem Reset des Actors müsste dieser ja 0 sein - die CCU zeigt aber den voher eingestellten Wert. Wenn man den Wert mit der CCU setzt, wird dieser auch an das Device übertragen - zumindest kommen die BatLow Meldungen entsprechend.

Gruß Christoph

PS: Ich habe jetzt auch ein zweites IODev, und könnte das setzen jetzt mitloggen.

[martinp876]

das mit intKeyVisib ist seltsam, auch dass das peering nicht stabil ist. Ist das nicht die eQ3 Qualitaet?

- Register confBtnTime
kann ich nicht sagen, gibt es aber bei einigen Devices (Blinds, switches...).
Neu ist es nicht.

- Register zum Einstellen der lowBat Schwelle
das Register sollte lowBatLimitBA2 sein. Nach Anleitung ist es auf Adresse 18 zu finden sein. Das ist aber nicht in der Liste - stattdessen ein unbekanntes Register 50 - steht gerade auf 7,3V. So etwas hatten wir schon einmal - und haben versucht, das einzugrenzen. Erfolglos, es scheint zu wandern. Ist sicher ein FW-bug. Zum setzen sollte es allerdings reichen. get <entity> regList hast du sicher probiert.
Übrigens hat auch die CCU2 den Wert nicht gefunden und zeigt verlegen "0.0" an, was schlicht falsch ist.


Für Bastler:
"Simulieren " kann man ein device mit (hier die mId des Mod8)

Code Auswählen Erweitern

delete y
{my ($mid,$name,$hId) = ("00BE","y","555555");;\
CommandDefine(undef,"$name CUL_HM $hId");;\
CUL_HM_infoUpdtDevData($name,$defs{$name},"11".$mid."4C45513030373331313612060100");;\
CUL_HM_queueUpdtCfg($name);;\
CUL_HM_queueUpdtCfg($_) foreach(grep(/^channel_/,keys %{$defs{$name}}));;\
$attr{$name}{expert}="2";;\
}

ps: Interessant ist, dass das Device in Version 1.2 der HM SW eingebaut war, aber seit Version 13 wieder entfernt wurde und seither fehlt.

[betateilchen]

Hallo Martin, die Sache mit dem intKeyVisib ist doch inzwischen genauso geklärt wie das Problem mit dem instabilen Peering - siehe meine letzten Beiträge, in denen Du auch die kompletten Ausgaben inklusive List3 findest.

Gestern abend nach den ganzen Experimenten mit dem Modul hatte ich noch ein fhem Update gemacht, bei dem auch ein paar Homematic-Komponenten aktualisiert wurden. Seitdem scheitert die Nutzung des Moduls entweder mit "MISSING ACK" oder "Timeout:RegisterRead". Allerdings hatte ich gestern abend dann keine Lust mehr, dieser Sache weiter nachzugehen und zu prüfen, ob das wirklich mit den Updates zusammenhängt.

[martinp876]

die Sache mit dem intKeyVisib ist doch inzwischen genauso geklärt wie das Problem mit dem instabilen Peering - siehe meine letzten Beiträge, in denen Du auch die kompletten Ausgaben inklusive List3 findest.

Peering nochmal eingerichtet, jetzt scheint es stabil zu sein.

scheint zu klappen, habe aber keine klare Einsicht, warum das so ist, was falsch war,...  geht plötzlich ist schön, aber nicht befriedigend. Aber gut

Seitdem scheitert die Nutzung des Moduls entweder mit "MISSING ACK" oder "Timeout:RegisterRead".

hierzu hätte ich gerne die rohmesssages - um sicherzustellen, dass FHEM /CUL_HM noch stabil ist. Wie immer eben
Egal ob es vom update kommt oder nicht.

Ansonsten ist das Device entsprechend Spec eingebaut und sieht komplett aus. Änderungen waren keine notwendig.
Wenn dir also noch etwas auffällt oder fehlt.....

[betateilchen]

geht plötzlich ist schön, aber nicht befriedigend. Aber gut

Kann ja auch ein Einrichtungsfehler von meiner Seite beim ersten Versuch gewesen sein, ich würde das jetzt nicht überbewerten.

hierzu hätte ich gerne die rohmesssages - um sicherzustellen, dass FHEM /CUL_HM noch stabil ist. Wie immer eben

Schau ich mir heute abend noch mal alles in Ruhe an.

Ansonsten ist das Device entsprechend Spec eingebaut und sieht komplett aus. Änderungen waren keine notwendig.
Wenn dir also noch etwas auffällt oder fehlt.....

Mir fehlt in der HMConfig die korrekte Bezeichnung Re8 anstatt RC8

[martinp876]

Mir fehlt in der HMConfig die korrekte Bezeichnung Re8 anstatt RC8

in Version 1.2 wird das Device mit mId "00BE" id="HM-MOD-RC-8" bezeichnet.
Re scheint sich aber durchzuetzen, vielleicht ist RC ein tippfehler von eQ3.  Werde es demnach Ändern.
bei eHome ist auch ein HM-MOD-EM-8 abgbildet, das hierzu passen soll Da habe ich keinen Infos

ps: wenn sich "model" im HMConfig ändert solltest du noch einmal anlernen drücken. FHEM nutzt model also "key", der Name darf sich demnach nicht wirklich ändern. Für dich sicher kein Problem

[betateilchen]

ps: wenn sich "model" im HMConfig ändert solltest du noch einmal anlernen drücken. FHEM nutzt model also "key",

Kein Problem.

Das EM-8 ist übrigens auch bei ELV schon abgebildet:

(http://www.elv-downloads.de/bilder/artikel/Produkte/13/1321/132143/Internet//gross/132143_w01_Modul.jpg)

Zu diesem Empfänger in Modulbauweise wird es
auch ein entsprechendes Pendant geben, und zwar
einen 8-Kanal-Senderbaustein, der in einer der
nächs ten Ausgaben des ELVjournal erscheinen wird.

[martinp876]

das meinte ich

[betateilchen]

Hallo Martin,

muss es in der HMConfig in %culHmRegModel nicht auch HM-MOD-Re-8 heißen?

[betateilchen]

Gestern abend nach den ganzen Experimenten mit dem Modul hatte ich noch ein fhem Update gemacht, bei dem auch ein paar Homematic-Komponenten aktualisiert wurden. Seitdem scheitert die Nutzung des Moduls entweder mit "MISSING ACK" oder "Timeout:RegisterRead".

Entwarnung. Funktioniert aktuell alles wieder wie vorgesehen.

- Register zum Einstellen der lowBat Schwelle
das Register sollte lowBatLimitBA2 sein. Nach Anleitung ist es auf Adresse 18 zu finden sein. Das ist aber nicht in der Liste - stattdessen ein unbekanntes Register 50 - steht gerade auf 7,3V. So etwas hatten wir schon einmal - und haben versucht, das einzugrenzen. Erfolglos, es scheint zu wandern. Ist sicher ein FW-bug. Zum setzen sollte es allerdings reichen. get <entity> regList hast du sicher probiert.
Übrigens hat auch die CCU2 den Wert nicht gefunden und zeigt verlegen "0.0" an, was schlicht falsch ist.

Ich kann zumindest über die CCU2 einen Wert für die Spannungsschwelle einstellen. Ob der tatsächlich an das Modul übertragen wird, muss ich noch prüfen.

Grade gesehen, dass es heute schon wieder eine neue Firmware für die CCU2 gibt.