Homematic wired Direktverknüpfungen (peering)

[Ralf9]

Hallo,

hat schon mal jemand bei dem HMW-IO-12-FM oder einem anderem Modul Direktverknüpfungen angelegt?
Ich möchte beim HMW-IO-12-FM interne Direktverknüpfungen anlegen.

Ich habe mir dazu in der "hmw_io_12_fm.xml" die Inhaltsbeschreibung des EEPROM angeschaut. Im Bild in der Anlage müsste der dazu relevate Teil sein.

Ich habe aus der xml-Datei folgendes rausgelesen:

Code Auswählen Erweitern


address_start="0x39"

+0  Adresse des Sensors
+4  Kanal des Sensors
+5  Kanal des Ausgangs

+6.7 SHORT_ON_TIME_MODE
+6.6 SHORT_OFF_TIME_MODE
+6.4 SHORT_TOGGLE_USE
+6.0 SHORT_ACTION_TYPE

+7  SHORT_ONDELAY_TIME    size="2.0   default="0.0"
+9  SHORT_ON_TIME         size="2.0
+11 SHORT_OFFDELAY_TIME   size="2.0   default="0.0"
+13 SHORT_OFF_TIME        size="2.0
..


Ich habe das EEPROM ab 0x39 ausgelesen:

Code Auswählen Erweitern


set HM485_LAN RAW 00008C69 98 00000001 52003910

2014.12.21 18:45:14.534 3: HM485d: Tx: (167:1) I[0](0,Y,F,B)(98) 00000001 -> 00008C69 [6] 52(R) 003910 {AA88}
2014.12.21 18:45:14.539 3: HM485d: Rx:  I[0](0,Y,F,B)(98) 00000001 -> 00008C69 [6] 52(R) 003910 {AA88}
2014.12.21 18:45:14.552 3: HM485d: Rx: Response: (167) I[1](0,F,B)(1A) 00008C69 -> 00000001 [18] FF(�) FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF {7316}

Ich hätte anstatt den vielen "FF" zumindest bei SHORT_ONDELAY und SHORT_OFFDELAY auch "00" erwartet.

Wenn ich Kanal 7 (Eingang) mit Kanal 1 (Ausgang) verknüpfen möchte, kann ich dies mit folgendem set Befehl tun?

ab Adr 0039:  00008C69 06 00 schreiben

set HM485_LAN RAW 00008C69 98 00000001 5700390600008C690600

Gruß Ralf

[Ralf9]

Hallo,

hat schon mal jemand mit der CCU eine Direktverknüpfung eingerichtet und dabei mit fhem die set Befehle mitgeloggt oder das EEPROM ausgelesen?

Mein HMW_IO_12_FM  hat die Adresse  00008C69. Wie muß ich die Adresse ins EEPROM ab 0x39 schreiben, normal (00008C69) oder umgekehrt (698C0000)?

Gruß Ralf

[Ralf9]

Mittlerweile ist es mir gelungen eine interne Direktverknüpfung einzurichten.
Wenn ich die zugeordnete Taste drücke, toggelt der Ausgang.
Da ich aber nicht weiß welchen Wert ich bei "SHORT_OFF_TIME" für "not_used" eintragen muß, toggelt der Ausgang von selber.

In der  hmw_io_12_fm.xml steht dazu:
<logical default="16383000" max="982980.0" min="0.0" type="float" unit="s">
<special_value id="NOT_USED" value="16383000"/>
<physical endian="little" interface="eeprom" size="2.0" type="integer"
<conversion factors="0.1,1,60,1000" type="float_configtime" value_size="1.6"/>
<conversion type="integer_integer_map">
<value_map device_value="0xc000" mask="0xc000" parameter_value="0xffff"/>

Ich weiß nicht wie "conversion factors="0.1,1,60,1000" zu interpretieren ist.

Da der Ausgang nach einiger Zeit wieder von selber nach aus gehen soll, muß ich die ensprechende Zeit in "SHORT_ON_TIME" eintragen.
Da ich nicht weiß wie man die Sekunden in den 14 Bit Wert umrechnet, ist es für mich ein reines probieren.

Ich habe einige Hex-Werte getestet und die folgenden Zeiten erhalten. Wenn ich den Hex-Wert ins EEPROM schreibe muß ich Hi und Lo vertauschen.

0080 ca  13 sec
0100 ca  26 sec
0600 ca 154 sec
1000 ca 410 sec
2000 ca 819 sec
3F00 ca 1615 sec

Kann mir da jemand weiterhelfen?

Edit:
Ich habe es durch probieren selber herausgefunden. Den Hex-Wert nach dezimal wandeln und dann durch 10 ergeben die Sekunden.
Der maximale Hex-Wert 3FFF ergibt dann 1638 Sekunden, dies ist von dem angegebenen max="982980.0" noch weit entfernt.

Gruß Ralf

[hglaser]

Hallo Ralf

Bist du diesbezüglich schon etwas weiter gekommen ?
Ich hab es auch probiert und scheitere ebenfalls bei ca. 1600 sek.
Ich habs mal in eiener anderen Form probiert:
Den ersten und zweiten HEX wert in DEC konvertiert, danach den 2. mit 255 multipliziert und beide werte addiert Das ganze stimmt bis ca. 1600 Sekunden.
Danach kommt wohl noch ein multiplikator. EinBeispiel:

Eine SHORT_ON_TIME von 1551,6 Sekunden, erzeugt wenn ich es über die CCU mache ein

Code Auswählen Erweitern


00301024000EFF00009C3C000000C0D1F0FF00

Also 0x9C ist 156 und 0x3C ist 60.
also 255 * 60 + 156 + 60 = 15516 so weit so gut.

bei einer Eingabe 2460,0 Sekunden bin ich jedoch gescheitert

Code Auswählen Erweitern

00301024000EFF00009C49000000C0D1F0FF00
9C = 156 ,49 = 73, also
255 * 73 + 73 + 49 = 18844, sollte aber eigentlich 24600 sein.

Ich habe einen HMW-IO-12-SW7-DR. Dieser ist intern einige Male gepeert und auch 2 Taster-Kanäle mit einem HMW_LC_Dim1-DR. würde es Dir helfen wenn ich Ihn Zurücksetze und eine Direktverknüpfung mitlogge. Einen HMW_IO_12_FM hab ich leider nicht.

lg Harald

[Ralf9]

Hallo Harald,

nein, ich bin bei den Zeiten auch nicht so richtig weitergekommen. Bis ca 27 Min oder Hex 3FFF paßt es.  Den Hex-Wert nach dezimal wandeln und dann durch 10 ergeben die Sekunden.
Bei ca Hex 3FFF scheint sich der Umrechnungsfaktor zu ändern. Interessant wäre welche Hex-Werte 30 Min, 1 Std, 2 Std, 10 Std von der CCU eingegeben, ergeben.

Gruß Ralf

[hglaser]

Hallo Ralf

1800 sek

Code Auswählen Erweitern

2015.01.27 17:00:03.010 3: HM485d: Rx:  I[3](3,F,B)(7E) 00000001 -> 00009624 [22] 57(W) 00301024000EFF00000847000000C0D1F0FF00 {B702}
3600

Code Auswählen Erweitern

2015.01.27 17:01:20.108 3: HM485d: Rx:  I[2](3,F,B)(7C) 00000001 -> 00009624 [22] 57(W) 00301024000EFF0000104E000000C0D1F0FF00 {F458}
7200

Code Auswählen Erweitern

2015.01.27 17:02:44.237 3: HM485d: Rx:  I[1](3,F,B)(7A) 00000001 -> 00009624 [22] 57(W) 00301024000EFF0000205C000000C0D1F0FF00 {6B2A}
36000 sek

Code Auswählen Erweitern

2015.01.27 17:04:07.588 3: HM485d: Rx:  I[0](3,F,B)(78) 00000001 -> 00009624 [22] 57(W) 00301024000EFF00005882000000C0D1F0FF00 {631C}
alles SHORT_ON_TIME

lg Harald

[Ralf9]

Hallo,

bei Zeiten größer ca 1630 sek komme ich auch nicht weiter. Die Daten in der xml-Datei helfen mir auch nicht weiter.
Ich habe auch einige Werte ins EEPROM geschrieben und gemessen.
Nicht alle Werte funktionieren.  3F80 hat noch funktioniert, aber bei den Hex-Werten 3FFF und 4000 konnte ich mit einem Tastendruck nicht mehr schalten.
Bei Hex 4500 kam mit 1281 sek eine kleinere Zeit als erwartet heraus.

Hier ist nochmals eine Zusammenfassung der bis jetzt ermittelten Zuordnungen:

Code Auswählen Erweitern


Hex   Sek
3F00 1615
3F80 1625       
4500 1281       
4708 1800    30 Min
499C 2460 
4E10 3600    1 Std
5C20 7200    2 Std
8258 36000   10 Std
85A0 86400   24 Std


Hat jemand eine Idee wie man ab ca 1630 Sekunden, rechnerisch aus den Hex-Werten die Zeit ermitteln kann?

Gruß Ralf

[hglaser]

Hallo Ralf

Ich bin wieder ein bisschen weiter gekommen

Man nimmt die beiden Hex Werte, und vertauscht sie. soweit sind wir schon gewesen.
wenn man nun mit dem Wert und der Maske 0xC000 aus dem xml ein bitweisesUND macht kommt bei den kleinen Zahlen die wir schon hatten ein 0x0000 heraus. wie nennt man das? broadcast ? Bei ungefähr 1600 sekunden springt die zahl auf 0x4000, was wohl dann der multiplikator 1 bedeutet . Hier stimmen dann die Sekunden wenn man 0x4000 abzieht. Bei 0x8000 daselbe und mit 60 multiplizieren. Weiter bin ich noch nicht. Bsp:

Code Auswählen Erweitern


50 sek sind im EEprom  F4 01
01F4 = 500
C000 bit&
0000 = multiplicator 0,1

somit 500 * 0,1 = 50 Sek
-----
2460 sek im EEProm 9C 49
499C
C000 bit&
4000 = multiplikator 1
somit 499C - 4000 = 99C = dec 2460 sek
------
6550 Sek im EEProm 96 59
5996
C000 bit&
4000 dh. multiplikator 1
somit 5996 - 4000 = 1996 = dec 6550 sek
------
65340 Sek im EEProm 41 84
8441
C000 bit&
8000 dh multiplikator 60
somit 8441 - 8000 = 441
441 = dec 1089 * 60 = 65340 sek
-------
888900 Sek im EEProm DFB9
B9DF
C000 bit &
8000 multiplikator 60
somit B9DF - 8000 = 39DF
39DF = dec 14815 * 60 = 888900

mit dem nächsten Faktor der dann 1000 sein müsste hab ichs nicht probiert. es stimmt bis dahin mit den Daten die ich von der CCU geammelt habe zusammen.

Das ganze geht bestimmt irgendwie einfacher und auch umgekehrt. Hier wäre so ein kleines perl scriptlein schön . Auch Dirk oder Gevoo hat da noch ein TODO im Device.pm. Da hab ich nämlich auch nach eine Lösung gesucht. Vielleicht hilfts ja was.

Grüße Harald

[hglaser]

Hallo Ralf

Ist zwar kein Einzeiler, aber besser als nichts . Leider kenn ich mich in perl noch nicht recht aus.

Code Auswählen Erweitern

#!/usr/bin/perl
# Program um hexwerte in Sekunden umzurechnen.

print "Input a hexdecimal number lesser than BFFF: ", "\n";
my $hex;

$input = <STDIN>;
$hex = hex $input;
$decimal = unpack('s',pack 's', hex($input));

#TODO die zwei HEX paare vertauschen

printf "Hex = %04X\n", $hex;
printf "mask: %04X\n", $hex & hex C000;

my $test1 = $hex & hex C000;

#keine Ahnung wie case in perl geht also halt if
if ($test1 == hex '0000') {
print "mal 0.1\n";
printf "0x%x sind %s Sekunden\n", $hex, $hex * 0.1;
}

if ($test1 == hex '4000') {
print "1 zu 1\n";
printf "0x%x sind %s Sekunden\n", $hex, $hex - hex 4000;
}

if ($test1 == hex '8000') {
print "mal 60\n";
printf "0x%x sind %s Sekunden\n", $hex, ($hex - hex 8000) * 60;
}

if ($test1 == hex 'C000') {
print "mal 1000\n";
printf "0x%x sind %s Sekunden\n", $hex, ($hex - hex C000) * 1000;
}

Gruß Harald

edit: 1000er multiplikator ergänzt. wird aber wohl nicht verwendet

Da ich aber nicht weiß welchen Wert ich bei "SHORT_OFF_TIME" für "not_used" eintragen muß, toggelt der Ausgang von selber.

das ist dann wohl "C000" oder im eeprom "00C0"

[Ralf9]

Hallo Harald,

Danke, mit Deinen Erkenntnissen passt es nun mit der Umrechnung.
Der 1000er Multiplikator wird gar nicht benötigt, da der Wertebereich nur bis Hex BFFF geht.
Ich habe mal ein kleines Perl Script geschrieben.  Es gibt eine Liste aus.
Damit wird mir einiges klar. Nun ist mir auch klar, warum ich beim Testen von größeren Werten keinen Erfolg hatte, ich hatte es mit Hex 4000 und 8000 versucht..

Code Auswählen Erweitern


my $von = hex('3F00');
my $bis = hex('8600');
my $step = 128;

my $a = 0;
for (my $i = $von; $i <= $bis; $i+=$step ) {
    if ( $i < 0x4000) {
$a = $i / 10;
    } elsif ( $i < 0x8000) {
$a = $i - 0x4000
    } else {
$a = ($i - 0x8000) * 60;
    }
    printf(" %04X  % 5u Sek % 4u Min % 3u Std\n",$i,$a,$a/60,$a/3600);
}


Bei mir funktionieren die Direktverknüpfungen inzwischen wie gewünscht. Ich habe mir die Dateien so angepasst, daß es für mich passt.

Gruß Ralf

[hglaser]

Hallo Ralf

Ich schreib jetzt hier mal weiter. Du wolltest Bilder haben, wie es bis jetzt aussieht. Nun es ist noch fernab von einer funktionierenden Version. Die ganzen channels müssen erst ausgelesen und den zugehörigen Devices zugeordenet werden, wobei auch mehrere peerings mit mehreren aktoren berücksichtigt werden müssen. Ich denke da an ein Dropdownmenü für die einzelnen zugeordenten Device_channels im "Configuration" Feld. Und danach sollte dann dieses "Settings" Feld darunter erscheinen. Das ganze nicht wie jetzt bei den Sensoren, sondern bei den Aktoren. Auch das xmlHelper script muß noch angepasst werden, da die ganzen Dropdown Menüs, die mehr als 2 Auswahlmöglichkeiten haben, sonst nicht richtig zugeordnet werden können.
Du sieht also, es ist noch eine große Baustelle. Wenn das alles erledigt ist. möchte ich dann kleine Dateien erstellen in denen dann vordefinierte Werte für z.B ein Treppenhauslicht oder Blinklicht sind und diese dann auch ausgewält werden können. Wie in der CCU halt auch. Das ganze entwickle ich zur Zeit unter dem peering branch https://github.com/hresalg/FHEM-HM485/tree/peering

lg Harald.

[hglaser]

Hallo Ralf

Ich habe jetzt einmal versucht ein "get peersettings <DEFNUMMER>" einzubauen. Nach ausführen erscheint dann dieses laaange Settings Fenster. Mit dieser Lösung bin ich eigentlich ganz zufrieden.

Die Werte kann man noch nicht ändern und ob sie überhaupt stimmen hab ich noch nicht überprüft. beim HMW_IO_12_FM funktioniert zumindest das interne peering auch noch nicht. Hier muss ich erst einmal das xml studieren, wo und wie das Gerät die Peerings speichert. Die Anzeige funktioniert bisher beim HMW_IO_12_Sw7_DR und ich denke auch beim HMW_LC_Dim1L_DR. Einen Blind hab ich leider nicht. Hat jemand einen und Lust esauszuprobieren? Bilder eines IO_12_Sw7 Tasters der mit einem Dimmer gepeert ist, hab ich mal angefügt.

lg Harald

[Ralf9]

Ich habe jetzt einmal versucht ein "get peersettings <DEFNUMMER>" einzubauen. Nach ausführen erscheint dann dieses laaange Settings Fenster. Mit dieser Lösung bin ich eigentlich ganz zufrieden.

Hallo Harald,

ist schon mal ein guter Anfang. Ob die Werte stimmen müsstest Du durch Vergleich mit der CCU z.T. überprüfen können.
Zum Rest schreibe ich heute Abend noch was.

Gruß Ralf

[Ralf9]

Die Werte kann man noch nicht ändern und ob sie überhaupt stimmen hab ich noch nicht überprüft. beim HMW_IO_12_FM funktioniert zumindest das interne peering auch noch nicht. Hier muss ich erst einmal das xml studieren, wo und wie das Gerät die Peerings speichert.

Hallo Harald,

Ich hab mal die xml vom "HMW_IO_12_FM" und "HMW_IO_12_Sw7_DR" verglichen. Mir ist folgender Unterschied aufgefallen.
"HMW_IO_12_FM":
<channel count="12" index="1" physical_index_offset="-1" type="INPUT_OUTPUT">

"HMW_IO_12_Sw7_DR"
<channel index="13" physical_index_offset="-1" count="7" type="SWITCH">


Hier ist mal eine Übersicht der wired Module die Peering können:

Code Auswählen Erweitern


HMW-IO-12-FM     start 0x39  step 28  count 28   RS485 I/O module 12-channel
HMW-IO-4-FM      start 0x18  step 28  count 30   RS485 I/O module 4-channel
HMW-IO-SR-FM     start 0x1F  step 28  count 29   RS485 I/O SR
HMW-IO-12-Sw7-DR start 0x2D  step 28  count 29   RS485 I/O module 12-channel in and switch actuator 7-channel
HMW-LC-Sw2-DR    start 0x0F  step 28  count 30   RS485 switch actuator 2-channel

HMW-LC-Bl1-DR    start 0x12  step 38  count 22   RS485 blind actuator 1-channel (Rollladenaktor)
HMW-LC-Dim1L-DR  start 0x0C  step 54  count 16   RS485 dimming actuator 1-channel leading edge




Wenn ich beim  "HMW_IO_12_FM" bei einem internen Peering eine Taste drücke bekomme ich nur "4B(K)" (press key) gemeldet, aber nicht den aktuellen State des Ausgangs "69(i)"
Ich habe es mit einem notify gelöst:

Code Auswählen Erweitern


define Kan7pnot1 notify HMW_IO_12_GEQ_01_Licht_Waschk.* get HMW_IO_12_GEQ_07_Licht_Waschk state

Ist dies beim HMW_IO_12_Sw7_DR genauso?


Hier ist meine korrigierte Version der "setRawEEpromData":

Code Auswählen Erweitern


sub setRawEEpromData($$$$) {
my ($hash, $start, $len, $data) = @_;
$len = $len * 2;
$data = substr($data, 0, $len);

my $blockLen = 16;
my $addrMax = 1024;
my $blockStart = 0;
my $blockCount = 0;

if ($start > 0) {
$blockStart = int(($start * 2) / ($blockLen*2));
}

for ($blockCount = $blockStart; $blockCount < (ceil($addrMax / $blockLen)); $blockCount++) {

my $blockId = sprintf ('.eeprom_%04X' , ($blockCount * $blockLen));
my $blockData = $hash->{READINGS}{$blockId}{VAL};
if (!$blockData) {
# no blockdata defined yet
$blockData = 'FF' x $blockLen;
}

my $dataStart = ($start * 2) - ($blockCount * ($blockLen * 2));
my $dataLen = $len;

HM485::Util::HM485_Log('Device:setRawEEprom start = ' . $start . ' blId = ' . $blockId . ' blCount = ' . $blockCount . ' datStart = ' . $dataStart, 4);
HM485::Util::HM485_Log('Device:setRawEEprom blData   = ' . $blockData . ' dat = ' . $data, 4);

if ($dataLen > (($blockLen * 2) - $dataStart)) {
$dataLen = ($blockLen * 2) - $dataStart;
}

my $newBlockData = $blockData;

if ($dataStart > 0) {
$newBlockData = substr($newBlockData, 0, $dataStart);
} else {
$newBlockData = '';
}

$dataLen = ($len <= $dataLen) ? $len : $dataLen;
$newBlockData.= substr($data, 0, $dataLen);

if ($dataStart + $dataLen < ($blockLen * 2)) {
$newBlockData.= substr(
$blockData, ($dataStart + $dataLen), ($blockLen * 2) - $dataStart + $dataLen
);
$data = '';
} else {
$data = substr($data, $dataLen);
$start = ($blockCount * $blockLen) + $blockLen;
}

HM485::Util::HM485_Log('Device:setRawEEprom newBlDat = ' . $newBlockData . ' len = ' . $dataLen . ' data = ' . $data, 4);

$hash->{READINGS}{$blockId}{VAL} = $newBlockData;

$len = length($data);
if ($len == 0) {
last;
}
}
}


sub internalUpdateEEpromData($$) {
my ($devHash, $requestData) = @_;

my $start = hex(substr($requestData, 0, 4));
my $len   = hex(substr($requestData, 4, 2));
my $data  = substr($requestData, 6);

setRawEEpromData($devHash, $start, $len, $data);
}



Gruß Ralf

[Ralf9]

Hallo Harald,

ich finde bei den IO- und Switch-Modulen ein Übersicht über alle Peerings sehr praktisch und hilfreich.
Spricht  etwas dagegen diese Übersicht in das Reading des Muduls zu schreiben?
In der Anlage ist zu sehen, wie ich es gelöst habe.

Gruß Ralf

[hglaser]

Wenn ich beim  "HMW_IO_12_FM" bei einem internen Peering eine Taste drücke bekomme ich nur "4B(K)" (press key) gemeldet, aber nicht den aktuellen State des Ausgangs "69(i)"

Hallo Ralf

Ja das ist beim HMW_IO_12_FM scheinbar wirklich so. Ich habe es gerade auch probiert. Du kannst Dir aber damit behelfen, in dem Du das Logging einschaltest, dann kommt nach der loggingtime ein "i" befehl. Nicht gerade Echtzeit. aber dafür eine Rückmeldung, daß wirklich eingeschaltet ist.

Code Auswählen Erweitern


2015.05.20 19:25:50.024 3: HM485d: Rx:  I[3](3,Y,F,B)(FE) 0000E1DD -> FFFFFFFF [6] 4B(K) 0B008E {40E8}
2015.05.20 19:25:50.050 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 0000E1DD -> FFFFFFFF [18] 41(A) 0B1B0003004C455130323338323137 {16F8}
2015.05.20 19:25:51.956 3: HM485d: Rx:  I[1](3,F,B)(7A) 0000E1DD -> 00000001 [6] 69(i) 080000 {1BA8}
2015.05.20 19:25:51.964 3: HM485d: Tx: ACK(1,B)(39) 00000001 -> 0000E1DD [2] {E372}

beim io12sw7 kommt von Haus aus ein 0x69

HMW-IO-12-FM     start 0x39  step 28  count 28

Ja danke, dort steht was. Ich werde das behaviour wohl auch noch integrieren müssen.

Danke für deine sub setRawEEpromData($$$$). Immer gut wenn ich nicht selber suchen muß

[hglaser]

ich finde bei den IO- und Switch-Modulen ein Übersicht über alle Peerings sehr praktisch und hilfreich.
Spricht  etwas dagegen diese Übersicht in das Reading des Muduls zu schreiben?
In der Anlage ist zu sehen, wie ich es gelöst habe.

Du möchtest es ins Reading des Modules verstehe ich das richtig? das sind die einzelnen channels und Long- und Short- Werte ? und Du möchtest die HEX Daten und nicht die berechneten Werte?

lg Harald

[Ralf9]

Du möchtest es ins Reading des Modules verstehe ich das richtig? das sind die einzelnen channels und Long- und Short- Werte ? und Du möchtest die HEX Daten und nicht die berechneten Werte?

Ja, ich möchte es sichtbar ins reading des Moduls. Bei den Funkmodulen sind die Hexwerte auch sichtbar in den readings.
Mit den Hex-Daten ist es übersichtlicher. Wenn ich es ausführlich mit den berechneten Werten benötige kann ich ja in den entspechenden Kanal reingehen und es mir anzeigen lassen.

Code Auswählen Erweitern


0039_01  00003E950006 E1 A7

_01 = laufende Nr der Peeringeinträge
E1 = Eingang 1
A7 = Ausgang 7

Code Auswählen Erweitern


003F_S  FF00007017000000C0D1F0  - 10.0 Min

_S = Short
10.0 Min = short_on_time in Minuten

Code Auswählen Erweitern


004A_L  FF0000B84B000000C0C9F0 - 50.0 Min

_L = Long
50.0 Min = long_on_time in Minuten

Nachtrag:
Hier ist eine weitere Darstellungsvariante

Code Auswählen Erweitern


0039_01 00003E950006 E1 A7
003F FF00007017000000C0D1F0 - 10.0 Min short_on_time
004A FF0000B84B000000C0C9F0 - 50.0 Min long_on_time



Gruß Ralf

[hglaser]

Danke Ralf
Ich weiß nun was Du willst. Bitte um Bedenkzeit.

lg Harald

[Ralf9]

Hallo Harald,

ich habe meinen Vorschlag mal bei mir eingebaut, siehe Anlage.
Durch den Aufruf von get_peering() in der  "sub internalUpdateEEpromData($$)" wird nach dem Schreiben ins EEPROM die Peeringsübersicht  in dem Reading automatisch aktualisiert.

Gruß Ralf

[Ralf9]

Hallo Harald,

funktioniert bei Dir der  (0xCB) - Key-Sim - Befehl?
Gibt es dabei einen Trick? Funktioniert er sowohl bei ungepeerten als auch bei gepeerten Ausgängen.
Was verwendest du als Nummer des Eingangs?

Da es mir nicht gelungen ist mit dem Key-Sim - Befehl einen Ausgang zu schalten, habe ich die Ausgänge zusätzlich mit der Zentrale (00000001) gepeert.
Damit kann ich dann per webcmd mit dem (0x4B) - Key-Event die Ausgänge schalten.

Gruß Ralf

[hglaser]

Hallo Harald,

funktioniert bei Dir der  (0xCB) - Key-Sim - Befehl?
Gibt es dabei einen Trick? Funktioniert er sowohl bei ungepeerten als auch bei gepeerten Ausgängen.
Was verwendest du als Nummer des Eingangs?

Hallo Ralf

Ja key syms funktionieren bei mir, jedoch nur mit gepeerten Ausgängen. Auch mit der CCU funktioniert es nur mit gepeerten Ausgängen. Ich habe jedoch noch nicht versucht mit der Zentrale zu peeren. Trick gibts da eigentlich keinen, Du brauchst nur einen Counter. Den speichere ich in den Readings. genauere Beschreibung findest Du hier: http://forum.fhem.de/index.php/topic,10607.msg100358.html#msg100358

anbei die subs (optimierungsbedürftig ein paar if's zuviel)

Code Auswählen Erweitern


sub HM485_SetKeyEvent($$) {
my ($hash, $cmd) = @_;

my $retVal            = '';
my $frameData;
my ($hmwId, $chNr)    = HM485::Util::getHmwIdAndChNrFromHash($hash);
my $devHash            = $main::modules{'HM485'}{'defptr'}{substr($hmwId,0,8)};
my $deviceKey          = HM485::Device::getDeviceKeyFromHash($devHash);
my $chType            = HM485::Device::getChannelType($deviceKey, $chNr);
my ($behaviour,$bool,$role) = HM485::Device::getChannelBehaviour($hash);

if ($role && $role eq 'switch') {
$behaviour = $role .'_ch';
}

my $valuePrafix        = $bool ? '/subconfig/paramset/hmw_'. $behaviour.
'_values/parameter' : '/paramset/values/parameter/';
my $values            = HM485::Device::getValueFromDefinitions(
$deviceKey . '/channels/' . $chType . $valuePrafix
);

foreach my $valueKey (keys %{$values}) {
if ($valueKey eq 'press_short'  || $valueKey eq 'press_long') {

my $valueHash  = $values->{$valueKey} ? $values->{$valueKey} : '';
my $control    = $valueHash->{'control'} ? $valueHash->{'control'} : '';
my $frameValue = undef;
my $peerHash;

if (($cmd eq 'press_short' && $control eq 'button.short') || ($cmd eq 'press_long' && $control eq 'button.long')) {
if ($control eq 'button.short' || $control eq 'button.long') {
#we need the last counter from the readings
my $lastCounter = $hash->{'READINGS'}{'sim_counter'}{'VAL'};
$frameValue = HM485::Device::simCounter($valueHash, $cmd, $lastCounter);
} else {
$retVal = 'no press_short / press_long for this channel';
}
$frameData->{$valueKey} = {
value    => $frameValue,
physical => $valueHash->{'physical'}
};

if ($frameData) {
my $frameType  = $valueHash->{'physical'}{'set'}{'request'};
if (($frameType eq 'key_sim_short' && $cmd eq 'press_short') ||
($frameType eq 'key_sim_long'  && $cmd eq 'press_long')) {
$peerHash = HM485::PeeringManager::getPeeringFromDevice($hash,$chNr);
if ($peerHash) {
my $data = HM485::Device::buildFrame($hash, $frameType, $frameData, $peerHash);

readingsSingleUpdate($hash, 'sim_counter', $frameValue, 1);
HM485_SendCommand($hash, $peerHash->{'actuator'}{'address'}, $data) if length $data;

} else {
$retVal = 'no peering for this channel';
}
}
}
}
}
}
#print Dumper ("HM485_SetKeyEvent devkey:$deviceKey type:$chType cmd:$cmd",$values);
return $retVal;
}


Code Auswählen Erweitern

sub simCounter($$$) {
my ($stateHash, $cmd, $lastCounter) = @_;

my $ret;
my $countersize = $stateHash->{'conversion'}{'counter_size'} ? int($stateHash->{'conversion'}{'counter_size'}) : 1;
my $oldcounter = $lastCounter ? $lastCounter : 1;

if ($oldcounter >= 2 ** $countersize -1) {
$ret = '0';
} else {
$ret = $oldcounter + 1 ;
}

return $ret;
}

lg Harald

[Ralf9]

Ich scheitere gerade daran die richtigen Werte fürs peering ins EEprom zu schreiben.

Hallo Harald,

Ich habe bei mir die Werte fürs EEPROM händisch aus den Daten von der xml-Datei berechnet.
Die nicht verwendeten Bitpositionen habe ich mit Einsen aufgefüllt

Was schreibt die CCU als Default ins EEPROM?

Das hier ergibt FF

Code Auswählen Erweitern


+6.7 SHORT_ON_TIME_MODE
0 id="MINIMAL
1 id="ABSOLUTE"  default="true"

+6.6 SHORT_OFF_TIME_MODE
0 id="MINIMAL
1 id="ABSOLUTE"  default="true"

+6.4 SHORT_TOGGLE_USE     size="0.2"
11  "DONT_USE"  default="true"
10  "DIRECT" 
00  "INVERTED"
     <value_map device_value="0x03" from_device="true" parameter_value="0" to_device="true"/>
     <value_map device_value="0x02" from_device="true" parameter_value="1" to_device="true"/>
     <value_map device_value="0x00" from_device="true" parameter_value="2" to_device="true"/>
     
+6.0 SHORT_ACTION_TYPE    size="0.1"
0  id="INACTIVE"
1  id="ACTIVE"  default="true"



und das hier ergibt 1111 000 011 010 001 = D1 F0

Code Auswählen Erweitern


+15.0 SHORT_JT_ONDELAY      read_size="2" size="0.3"
000 "ONDELAY"
001 "ON"       default="true"
010 "OFFDELAY"
011 "OFF"
100 "NO_JUMP_IGNORE_COMMAND"

+15.3 SHORT_JT_ON          read_size="2" size="0.3"
000 "ONDELAY"
001 "ON"
010 "OFFDELAY"  default="true"
011 "OFF"
100 "NO_JUMP_IGNORE_COMMAND"

+15.6 SHORT_JT_OFFDELAY   read_size="2" size="0.3"
000 "ONDELAY"
001 "ON"
010 "OFFDELAY"
011 "OFF"      default="true"
100 "NO_JUMP_IGNORE_COMMAND"
   
+15.9 SHORT_JT_OFF         read_size="2" size="0.3"
000 "ONDELAY"  default="true"
001 "ON"
010 "OFFDELAY"
011 "OFF"
100 "NO_JUMP_IGNORE_COMMAND"


Bei long ist es genauso FF und D1 F0

Weißt Du zufällig was bei TIME_MODE der Unterschied zwischen MINIMAL und ABSOLUTE ist?

Gruß Ralf

[hglaser]

Hallo Ralf

Ich habe bei mir die Werte fürs EEPROM händisch aus den Daten von der xml-Datei berechnet.
Die nicht verwendeten Bitpositionen habe ich mit Einsen aufgefüllt

Danke Ralf, ich habs nicht mit "1en" aufgefüllt. Das wird die Lösung sein. Manchmal sieht man den Wald vor lauter Bäumen nicht. Malsehen ob ich das jetzt hinbringe. Zumindest weiss ich jetzt wo ich suchen muß.  Die CCU schreibt als Default genau dasselbe also:

Code Auswählen Erweitern

     0 1 2 3 4 5 6 7 8 9 A B C D E F
0020 FFFFFFFFFFFFFFFFFFFFFFFFFF000096
0030 24000CFF000000C0000000C0D1F0FF00
0040 0000C0000000C0D1F0FFFFFFFFFFFFFF
0050 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Weißt Du zufällig was bei TIME_MODE der Unterschied zwischen MINIMAL und ABSOLUTE ist?

Nein weiss ich leider auch nicht. Aber diese Register gibts ja auch bei den Funk Devices. Eventuell kann da Martin oder einer der sich mit den Registern in den Funk Devices auskennt, etwas Licht ins Dunkel bringen. 

lg Harald

[hglaser]

Hallo

OK peeren geht schon mal. Auffüllen mit 1en war die Lösung. Zwar nur mit den Defaultwerten von einem Switch, aber es ist schon mal ein Anfang. Peeren mit einem Dimmer geht noch nicht recht, der schaltet nur aus. Hier muss ich noch nach den Defaultwerten im xml suchen.
Du hast ja glaube ich auch einen IO12FM. Hier habe ich einmal einen Eingang als Ausgang umgestellt und mit einem Eingang gepeert. Ein press_short über keysym funktioniert, wenn ich aber den Taster betätige gehts nicht. Habe dann das ganze wieder nocheinmal komplett gelöscht und über die CCU versucht. Und da gehts auch nicht.
Kannst Du das einmal probieren, ob das interne peeren mit einem IO12FM überhaupt geht und der Ausgang auf Tastendruck reagiert.

lg Harald

[Ralf9]

Hallo Harald,

was funktioniert bei Dir nicht beim internen peering beim IO12FM.
Wechselt in fhem der state des Ausgangs nicht?
Oder hast Du keinen wechsel am  physikalischen Ausgang z.B. an einer LED?

Ich habe zwei IO12FM mit denen ich u.a. das Treppenhaus- und Außenlicht schalte. Ich mache alles über internes peering.
Da bei mir bei einem Tastendruck nicht der state des Ausgangs an fhem gemeldet wird, habe ich für jeden verwendeten Eingang ein notify erstellt:

Code Auswählen Erweitern

HMW_IO_12_GEQ_06.* get HMW_IO_12_GEQ_08_Licht_AussenWK state


Beim "HMW-LC-Sw2-DR", "HMW-LC-Bl1-DR" und "HMW-LC-Dim1L-DR" dürfte ein peering über fhem nicht unbedingt notwendig sein.
Diese haben eine Programmiertaste mit der man recht einfach einen Ausgang mit einem Eingang peeren kann.

Gruß Ralf

[hglaser]

Oder hast Du keinen wechsel am physikalischen Ausgang z.B. an einer LED?

ja genau so ist es. Allerdings habe ich gar keine LED angeschlossen. War nur zu Testzwecken und hab mich gewundert, daß sich nichts rührt. Ich dachte schon, meine EEprom-schreiberei wäre daran schuld. Es ist schade, daß das Ding keine Rückmeldung liefert. Das logging kann man zwar aktivieren, ist allerdings ebenfalls nutzlos. Ich werde einmal nur so interessehalber einen Eingang eines IO12SW7 mit einem Ausgang des IO12FM peeren. mal sehen, ob man da eine Rückmeldung bekommt.

lg harald

[Ralf9]

Ja key syms funktionieren bei mir, jedoch nur mit gepeerten Ausgängen. Auch mit der CCU funktioniert es nur mit gepeerten Ausgängen. Ich habe jedoch noch nicht versucht mit der Zentrale zu peeren. Trick gibts da eigentlich keinen, Du brauchst nur einen Counter. Den speichere ich in den Readings. genauere Beschreibung findest Du hier: http://forum.fhem.de/index.php/topic,10607.msg100358.html#msg100358

Danke, damit funktioniert der Key-Sim wie gewünscht. Damit ist nun auch kein peering zur Zentrale mehr notwendig.
Ich habe es wie folgt gelöst:

Code Auswählen Erweitern


} elsif ( $cmd eq 'press_long' || $cmd eq 'press_short') {
my $count = 0;
my $k = 1;
my $sen = 0;
my $senadr = '';
if ( $cmd eq 'press_short') {
$k = 0;
}
if (index($value, '_') != -1) {
my @param = split('_', $value);
$senadr = $param[0];
$sen = $param[1];
} else {
$sen = $value;
$senadr = substr($hmwId, 0, 8);
}
my $webkey = ReadingsVal($name,'webKey_' . $value , '');
if ($webkey eq '') {
$count = 1;   # Counter zurücksetzen
} else {
my @param = split(' ', $webkey);
$count = $param[1];
$count = $count + 1;
$count = $count & 63
}
readingsSingleUpdate($hash, 'webKey_' . $value, $cmd . ' ' . $count, 1);
$count = ($count * 4) + $k;
my $evk = sprintf("%02X",$count);
$data  = sprintf('CB%02X%02X', $sen-1, $chNr-1);
HM485_SendCommand( $hash, $hmwId, $data . $evk . $senadr);


Ich übergebe mit dem press_short/long den Sensorkanal. Durch die optionale übergabe der Sensoradresse wird es sehr flexibel.
Bei meinem Beispiel in der Anlage wird mit dem webCmd "delShort" der Peeringeintrag 04 verwendet. Durch die  SHORT_ONDELAY_TIME wird der Ausgang 3 verzögert eingeschaltet.
Ohne die übergabe der Sensoradresse wird das interne peering mit der Nr 03 verwendet.

Gruß Ralf

[hglaser]

Hallo

könnte bitte jemand, der einen HMW_LC_Bl1_DR hat, diesen peeren und einmal die eeprom Daten schicken? Oder noch besser anbei die Daten die von mir als Default gechickt werden einmal vergleichen.

Code Auswählen Erweitern

$VAR1 = 'SetPeer 42FFFFFE_01 act > 57 0356 01 00';
$VAR1 = 'SetPeer 42FFFFFE_01 act > 57 0357 05 42FFFFFE02';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0012 05 42FFFFFE00';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0017 01 02';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0018 01 FF';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0019 01 00';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 001A 01 C8';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 001B 02 0000';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 001D 02 0000';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 001F 02 00C0';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0021 02 00C0';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0023 01 FF';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0024 01 31';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0025 01 43';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0026 01 75';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0027 01 07';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0028 01 FF';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0029 01 00';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 002A 01 C8';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 002B 02 0000';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 002D 02 0000';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 002F 02 00C0';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0031 02 00C0';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0033 01 05';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0034 01 31';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0035 01 43';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0036 01 75';
$VAR1 = 'SetPeer 42FFFFFE_03 sen > 57 0037 01 07';

vielen Dank

Wer es selbst einmal ausprobieren will, der kann sich natürlich auch den "peering" branch runterladen. peeren sollte nun funktionieren. Allerdings nur mit den Default Werten. Ein Verändern von z.B short_on_level ist noch nicht möglich. Anzeigen lassen kann man es sich, falls man es überprüfen möchte.

lg Harald

[hglaser]

Hallo Ralf

Hier einmal eine Testversion mit der "peeren" und "unpeeren" zu probieren wären. Auch die expert-Settings sollten funktionieren. Leider habe ich ich keinen Jalousie Aktor, kann also nicht selber testen.
ein

Code Auswählen Erweitern

set settings [Aktor] [Sensor] short_on_time=100 und mehrere peers für einen Sensor wäre dann der nächste Schritt, wenn peering und die Settings funktionieren.

lg Harald.

[hglaser]

Weißt Du zufällig was bei TIME_MODE der Unterschied zwischen MINIMAL und ABSOLUTE ist?

minimal bedeutet eigentlich "mindestens" und bei Absolute wird eine eventuell vorher schon definierte Zeit überschrieben.

lg Harald
ps: hier wirds erkärt: (Teil 2) http://www.homematic-inside.de/software/download/item/expertenparameter

[Ralf9]

Hier einmal eine Testversion mit der "peeren" und "unpeeren" zu probieren wären. Auch die expert-Settings sollten funktionieren. Leider habe ich ich keinen Jalousie Aktor, kann also nicht selber testen.

Hallo Harald,

ich habe bei mir noch eine ältere Version von Ende Februar/ Anfang März am laufen. Ich habe sie mir so angepasst, das es für mich passt. Die aktuelle Version, hat für mich momentan noch keine Vorteile. Ich müsste noch einiges ändern und ergänzen damit es für mich passt.
Ich denke spätestens im Herbst, wo ich vorhabe ein Fenster auf Rolladenmotor umzurüsten, werde ich auf die aktuelle Version wechseln.

Wie hast Du das unpeeren gelöst? Was machst Du im EEPROM mit der Lücke in der Liste der Peeringeinträge die entsteht, wenn nicht gerade der letzte Eintrag gelöscht wird. Eine Möglichkeit wäre den letzten Eintrag in die Lücke rein zu kopieren und dann den letzten Eintrag mit FF überschreiben.
Wie macht die CCU das unpeering?

Du hast in den settings auch ein Modul-Reset eingefügt. In welchen Fällen ist ein zurücksetzen eines Modul notwendig?
Hattest Du schon Probleme oder Fehler die Du nur mit einem  zurücksetzen des Moduls wegbekommen hast?

minimal bedeutet eigentlich "mindestens" und bei Absolute wird eine eventuell vorher schon definierte Zeit überschrieben.

ps: hier wirds erkärt: (Teil 2) http://www.homematic-inside.de/software/download/item/expertenparameter

Danke, damit ist dieser und einige andere Parameter klar geworden.

@alle
Ich habe das Gefühl, das nur bei wenigen ein Interesse an peering besteht oder täuscht dies.
Evtl ist noch nicht bei allen bekannt was damit alles machbar ist und welche Vorteile es hat. Wenn z.B. fhem morgens wegen eines Gewitters in der Nacht nicht mehr läuft, kann ohne peering das Licht nicht mehr eingeschaltet werden. Mit peering lässt es sich so konfigurieren, das die Grundfunktionen auch ohne fhem funktionieren.

Wer möchte kann mit dieser Version gerne das peering testen.

Wenn "attr global showInternalValues 1" gesetzt ist, wird der EEPROM Inhalt in den readings angezeigt und kann mit "List <Modulname>" recht einfach kopiert werden.

Gruß Ralf

[hglaser]

Hallo Ralf

Wie hast Du das unpeeren gelöst?

Ich schreibe einfach 0xFFs in die "address-" und "channel-" Parameter. die restlichen Parameter bleiben unverändert. Es entsteht also eine Lücke. Beim nächsten peeren wird die Lücke einfach wieder gefüllt, weil ich nach 0xFF im channel suche. Die CCU machts genauso.

Du hast in den settings auch ein Modul-Reset eingefügt.

Ja habe ich. Es ist für mich praktisch zum Testen gewesen, da ich zuerst das peeren entwickelt hatte und danach erst das unpeeren. Manchmal ist es ganz praktisch, aber wirklich brauchen tut mans glaub ich nicht. Wenn alles funktioniert, schmeiss ich es vielleicht wieder raus oder optimiere es ein wenig.

Du hast mal mit der Zentrale gepeert, funktioniert das? ich möchte mal das toggeln und dimmup, dimmdown, evtl. on-for-timer für den Dimmer so programmieren, indem ich einen peer mit den entsprechenden action_type parametern ins eeprom schreibe und dann einen key-sim-event auslöse. Hast Du so etwas schon einmal probiert? Ein on-for-timer auf der FHEM-seite will ich eigentlich nicht, wenns das Device schon intern kann.

lg Harald

[Ralf9]

Du hast mal mit der Zentrale gepeert, funktioniert das? ich möchte mal das toggeln und dimmup, dimmdown, evtl. on-for-timer für den Dimmer so programmieren, indem ich einen peer mit den entsprechenden action_type parametern ins eeprom schreibe und dann einen key-sim-event auslöse. Hast Du so etwas schon einmal probiert? Ein on-for-timer auf der FHEM-seite will ich eigentlich nicht, wenns das Device schon intern kann.

Hallo Harald,

durch den key-sim Befehl ist das peeren mit der Zentrale nicht mehr notwendig. Es muß nur ein weiterer peering Eintrag mit einer beliebigen Sensoradresse (z.B. CAFEBABE) und Kanal ins EEPROM geschrieben werden.
Diese beliebige Sensoradresse (z.B. CAFEBABE) wird dann beim key-sim Befehl als 5-8 Byte direkt hinter dem Event gesendet.

Siehe auch
http://forum.fhem.de/index.php/topic,30804.msg301342.html#msg301342

Gruß Ralf

[Ralf9]

Hier ist meine korrigierte Version der "setRawEEpromData":

Dazu noch ein Hinweis. Dies funktioniert nur, wenn die "hex()", die  bei der "sub setRawEEpromData" entfernt wurden,
hier wieder zugefügt werden:

Code Auswählen Erweitern


sub internalUpdateEEpromData($$) {
my ($devHash, $requestData) = @_;

my $start = hex(substr($requestData, 0, 4));
my $len   = hex(substr($requestData, 4, 2));
my $data  = substr($requestData, 6);

setRawEEpromData($devHash, $start, $len, $data);
}


Gruß Ralf

[hglaser]

Dazu noch ein Hinweis. Dies funktioniert nur, wenn die "hex()", die  bei der "sub setRawEEpromData" entfernt wurden,
hier wieder zugefügt werden:

aha, habs gestern mal probiert und wieder rausgeschmissen, weil ich das nicht bemerkt habe.
lg Harald.

[hglaser]

Hallo

Anbei einmal eine erste "VorabVersion", bei der das peeren, unpeeren, und setzen der Parameter funktionieren sollten. Ich hoffe ich habe alle Parameter berücksichtigt. die Anzeige für "short_on_time" und "long_on_time" ist noch nicht fertig. Hier steht nur die Default Zahl von "49152" sek, welche man sich als "nicht benutzt" vorstellen muss

lg Harald

[hglaser]

Hallo

kleines Update.

Irgendwie freut es mich ja, daß das Peering nicht so recht Anklang bei den Wired Devices findet, wohl weil die meisten Module auch einen Config-Button haben und die Expert-Settings wohl wenige brauchen. Dadurch hat man schön Zeit zum Herumspielen. Ich habe nun einmal das ganze auf Device-Ebene umgeschrieben und cache nun die Parameter im Device-Hash, da es gar arg langsam wurde auf dem Rasperry. Sämtliche Devices nach peerdaten zu durchsuchen dauert halt. Nun dauert es nur mehr beim ersten Mal bei vielen Modulen etwas länger.

Auch den Vorschlag von Ralf, eine Übersicht über alle Peerings in die Readings zu schreiben habe ich mir überlegt. Nun habe ich es etwas anders gelöst und nicht in die Readings sondern in die Internals geschrieben. Ich konnte mich jedoch nicht dazu durchringen auch die Hexdaten der einzelnen peerings hineinzuschreiben. Ich hoffe Ralf verzeiht mir Siehe Screenshot.

Leider muß man bei der neuesten Version von FHEM nun auch bei einem "get peersettings" den Browser refreshen, damit die Settings angezeigt werden. Hier habe ich noch keine Lösung gefunden. Man muss hier wohl mit Notify_FN und InformId arbeiten, habe aber noch keine Ahnung, wie das geht. Ich warte mal ab, vielleicht stört sich ja jemand an dem "Configuration" Fenster. Dieses aktualisiert sich ja auch nicht, und fixt es. Dann häng ich mich da dran

Falls sich jemand anderes doch noch fürs peering per FHEM interessieren sollte habe ich einmal eine aktuelle Version angehangen.

lg Harald

[holzwurm83]

Hallo zusammen,

gibt es zu den peersettings irgendwo eine Beschreibung, welches Setting was bedeutet und welche Funktion es hat?

Ich habe mal mit einer CCU (vor 2 Jahren) ein Schalter mit einem Aktor gepeert und und habe nun einen zweiten Schalter mit dem gleichen Aktor gepeert. Die Settings sind auf beiden Seiten identisch, aber die Funktion ist nicht die gleiche. Der Zweite Schalter schaltet die Lampe nur ein aber nicht aus.

Ich habe die aktuelle Wired-Version von Torsten drauf.

[mago0211]

Ist ja lustig hab genau das gleiche Problem grad und wollte im Forum nachfragen....

wenn ich short_toggle_use auf direct stelle habe ich eine Toggle Funktion (funktioniert auch bei mir).

Ich will aber kein Toggle sondern einfach nur das Licht einschalten. Bei mir geht es aber immer aus.

(Identische Einstellungen wie holzwurm  )

Gruß
Markus

[Ralf9]

gibt es zu den peersettings irgendwo eine Beschreibung, welches Setting was bedeutet und welche Funktion es hat?

In der Einsteigerdoku ist unter Statemachine was beschrieben (ab Seite 80)
http://fhem.de/Heimautomatisierung-mit-fhem.pdf

Hier wird auch einiges erklärt (Vorsicht sehr lang)
http://www.homematic-inside.de/software/download/item/expertenparameter

Der Zweite Schalter schaltet die Lampe nur ein aber nicht aus.

Ändere mal short_jt_on von ondelay auf offdelay

Gruß Ralf

[Ralf9]

Ich will aber kein Toggle sondern einfach nur das Licht einschalten. Bei mir geht es aber immer aus.

Wie sind Deine Peersettings?

Gruß Ralf

[holzwurm83]

Ändere mal short_jt_on von ondelay auf offdelay

Danke Ralf, dass war die Lösung!

[mago0211]

Hallo Ralf,

habe schon jede menge Einstellungen durchprobiert und versucht mit trial and error was rauszufinden leider ohne Erfolg bisher.

Meine letzten Einstellungen siehst du im Anhang unten.
Mit der Einstellung geht das Licht immer aus wenn ich den Taster drücke.

Gruß
Markus

[Ralf9]

Meine letzten Einstellungen siehst du im Anhang unten.
Mit der Einstellung geht das Licht immer aus wenn ich den Taster drücke.

Mit diesen Einstellungen dürftest Du bei short und bei long eine Togglefunktion haben.
Wie soll es sich verhalten? Wie soll das Licht wieder ausgeschaltet werden?

Solange Du die Funktion der Statemaschine nicht kapiert hast, wirst Du dich mit der peering konfiguration sehr schwer tun.
Hier wird im Teil 1 ab der Minute 23 was über die  Statemaschine erklärt:
http://www.homematic-inside.de/software/download/item/expertenparameter

Gruß Ralf

[mago0211]

Mit diesen Einstellungen habe ich nur eine off Funktion.
Eine Toggle Funktion habe ich wenn ich short_toggle_use auf direct stelle

Eigentlich ist die Funktion ganz einfach.

Taster wird gedrückt -> Aktor soll auf ON gehen (egal welcher zustand vorher war)

Ausgeschaltet wird entweder über einen anderen Taster oder direkt über Fhem.

Soweit ich es jetzt verstanden habe nach der Doku und der Präsentation habe ich jetzt mal folgende Einstellungen vorgenommen.

short_ondelay_time = 0 (keine Wartezeit bis der ON ausgeführt wird)
short_on_time = 1 (nach 1 sec geht er nach dlyOff also wartet auf den Off)
short_jt_ondelay = on (ondelay_time gibt es bei mir nicht also sollte das keine wirkung haben)
short_jt_on = on (ist das Licht schon an wird noch einmal ein on gesendet)
short_jt_offdelay = on (offdelay_time gibt es bei mir nicht also sollte das keine wirkung haben)
short_jt_off = on (ist das Licht aus wird es eingeschaltet)

Leider gleicher Effekt wie vorher ich kann das Licht nur ausschalten nicht einschalten.

Eigentlich sollte doch so wie ich es eingestellt habe egal in welchem Zustand er sich befindet ein ON an den Aktor gesendet werden. Oder ist das Falsch?

(Ich verwende im Moment die dev Version von Thorsten und das HMW-Lan-Gateway)

Danke und Gruß
Markus

[Ralf9]

Mit diesen Einstellungen habe ich nur eine off Funktion.

short_on_time = 1 (nach 1 sec geht er nach dlyOff also wartet auf den Off)

Damit ist die Lampe für eine Sekunde ein und geht dann über dlyOff nach Off.
Setze mal die short_on_time auf unendlich.

Gruß Ralf

[mago0211]

Ahhh jetzt ist der Groschen gefallen 

Funktioniert!

Darauf kann ich aufbauen jetzt wo ich einigermaßen kapiert was die Einstellungen bedeuten. Das PDF Dokument mit der Statemachine Beschreibung hat mir am meisten geholfen. Der Vortrag ist aber auch super.

Danke für deine Hilfe 

Gruß
Markus

[mago0211]

Ich hab gleich noch eine Anschlussfrage 

Wenn ein Aktor durch eine Peering geschalten wurden z.b. von off auf on. Wird der neue Zustand in Fhem beim Aktor nicht angezeigt. Damit ich den aktuellen Zustand bekomme muss ich erst get [AKTORNAME] state machen.

Ist das so gewollt?

Gruß
Markus

[Ralf9]

Wenn ein Aktor durch eine Peering geschalten wurden z.b. von off auf on. Wird der neue Zustand in Fhem beim Aktor nicht angezeigt. Damit ich den aktuellen Zustand bekomme muss ich erst get [AKTORNAME] state machen.
Ist das so gewollt?

Nein, das sollte eigentlich funktionieren. Hast Du im Modul das logging eingeschaltet?

Welches Modul hast Du?

Gruß Ralf

[mago0211]

Das HMW_IO_12_Sw7.

Logging ist ausgeschaltet. Du meinst das Logging welches man direkt beim Aktor einschalten kann?

Gruß
Markus

[Ralf9]

Ja, dieses logging mal einschalten.

Gruß Ralf

[mago0211]

Wenn ich es einschalte funktioniert es. Beim off dauert es aber ca. 3 sec. bis der Befehl in Fhem ankommt. Bei On geht es sofort.


Gruß
Markus

[Ralf9]

Wenn ich es einschalte funktioniert es. Beim off dauert es aber ca. 3 sec. bis der Befehl in Fhem ankommt. Bei On geht es sofort.

Wenn in Modul die logging time auf 2 sek steht, dürfte dies normal sein. Du kannst mal versuchen die logging time auf 1 sek zu stellen

Gruss Ralf

[mago0211]

Ja das Funktioniert. Danke nochmal 

Gruß
Markus

[Hoschiq]

Hallo,

ich habe eine Frage zum logging der einzelnen channels.

Wie wird der aktuelle Zustand vom Aktor gemeldet? Ist das ein Broadcast oder eine direkte Info an die Zentrale, falls der Aktor gepairt ist.
Werden auch die Zustandsübergänge in Ondelay und Offdelay gemeldet, falls der Zustandsautomat ohne externen Trigger einen Zustandswechsel vornimmt?
Ich implementiere das gerade für homebrew wired daher die Frage was darüber bekannt ist.

Aktuell habe ich es so vorgesehen:

Code Auswählen Erweitern

void HMWDevice::sendActualState(uint8_t channel){

  if(config.central_address != 0xFFFFFFFF)
hmwmodule->sendInfoMessage(channel, getLevel(channel,255), config.central_address); // inform central
  else
hmwmodule->broadcastInfoMessage(channel,  getLevel(channel,255)); // inform broadcast
}

Also Info nur an Zentrale falls gepairt sonst broadcast.
Hat jemand eine Idee warum die Info verzögert (logging_time) gesendet wird? Der Bus wird dadurch ja nicht lange belegt und auch sonst sehe ich da nicht so recht den Sinn dahinter...

Danke

[Ralf9]

Wie wird der aktuelle Zustand vom Aktor gemeldet? Ist das ein Broadcast oder eine direkte Info an die Zentrale, falls der Aktor gepairt ist.
Werden auch die Zustandsübergänge in Ondelay und Offdelay gemeldet, falls der Zustandsautomat ohne externen Trigger einen Zustandswechsel vornimmt?

Bei dem hmw-io-12-fm wird per Broadcast gemeldet auch wenn die Adresse der Zentrale im Modul eingetragen ist.
Wie es bei den anderen Modulen ist, weiß ich nicht.
Wenn das Modul nicht auch bei der CCU funktioniern muß, dürfte es egal sein wie Du es machst.
Eine direkte Info an die Zentrale hat den Vorteil, daß die Meldung bis zu 2 mal wiederholt wird, falls kein Ack zurückkommt.

Ja, die Zustandsübergänge in Ondelay und Offdelay werden auch gemeldet. Das Working Flag wird auch mit übertragen.

Gruß Ralf

[Ma_Bo]

Sorry, wenn ich das Thema hier wieder hochhole, aber ich verstehe die Einstellungen auch nach dem lesen des Einsteiger PDF für Statemachine, immer noch nicht.

Ich möchte an einem HMW-IO-12-Sw7-DR Wired RS485 I/O-Modul 12 Eingänge 7 Ausgänge folgendes machen. (Eingang und Ausgang gepeert)

Eingang 1 wird "Short" getastet und es soll sofort Ausgang 1 eingeschaltet werden.
Eingang 1 wird "Short" erneut getastet und es soll sofort der Ausgang 1 ausgeschaltet werden.

Das war es schon, keine Zeiten, nix weiteres.

Kann mir jemand ein Beispielbild für diese Konfiguration schicken?

Grüße Marcel

[Ralf9]

Eingang 1 wird "Short" getastet und es soll sofort Ausgang 1 eingeschaltet werden.
Eingang 1 wird "Short" erneut getastet und es soll sofort der Ausgang 1 ausgeschaltet werden.

Das sollte doch eigentlich die Defaulteinstellung sein . Falls es nach dem neueinrichten eines Peerings so nicht funktioniert, einfach mal das settings des Peerings hier posten.

Gruß Ralf

[Ma_Bo]

Das sollte doch eigentlich die Defaulteinstellung sein . Falls es nach dem neueinrichten eines Peerings so nicht funktioniert, einfach mal das settings des Peerings hier posten.

Gruß Ralf

Danke Ralf, da ich momentan gesundheitlich nicht dazu komme, melde ich mich, sobald ich wieder an die Steuerung ran gehe...