Hallo zusammen,
ich habe bei dem Wired-Modul HMW_LC-Sw2_DR ein Problem mit dem Reading State.
Der 2. Ausgang (Channel 4) wird nicht immer richtig angezeigt.
Wenn über das Web-Interface von FHEM der Aktor geschaltet wird, dann ist der State immer in Ordnung.
Wird der Aktor über den gepeerten Eingang geschaltet, dann bleibt der State meistens auf off.
Evt. könnt ihr mir helfen das Problem zu lokalisieren ??
Torsten schrieb dazu mal:
Kannst Du mal versuchen, die Buskommunikation zu tracen? Ich mache das normalerweise, indem ich den HM485d stoppe und manuell wieder starte. Blöderweise kann ich momentan dazu keine genauere Anleitung geben.
Ich habe jedoch keine Ahnung was ich machen soll - über Hilfe wäre ich dankbar.
Lieben Gruß
Sprudelverduenner
Hi,
hast Du logging eingeschaltet und was ist die logging time fuer diesen Kanal?
Gruss,
Thorsten
Logging ist bei beiden Ausgangs-Kanälen an.
Die Logging Time ist 1 Sekunde.
Gruß
Sprudelverduenner
Zitat von: sprudelverduenner am 06 Oktober 2015, 15:25:28
ich habe bei dem Wired-Modul HMW_LC-Sw2_DR ein Problem mit dem Reading State.
Hast Du außer dem HMW_LC-Sw2_DR noch andere Wired-Module die peering können?
Gruß Ralf
Leider nein, ich habe nur ein 2. HMW_LC-Sw2_DR ...
hast Du bei beiden HMW_LC-Sw2_DR beide Eingänge auf beide Ausgänge intern gepeert? also insgesamt 4 interne peerings?
Gruß Ralf
es ist etwas komplizierter .... ich versuche es zu beschreiben:
Die beiden Module heißen flur.eltako.1 und flur.eltako.2.
Die Kanäle des 1. Moduls
channel_01 flur.eltako.1_01
channel_02 flur.eltako.1_02
channel_03 flur.eltako.1_03
channel_04 flur.eltako.1_04
Die Kanäle des 2. Moduls
channel_01 flur.eltako.2_01
channel_02 flur.eltako.2_02
channel_03 flur.eltako.2_03
channel_04 flur.eltako.2_04
Peers Modul 1
channel_01 → flur.eltako.1_03
channel_01 → flur.eltako.1_04
channel_01 → flur.eltako.2_03
channel_02 → flur.eltako.1_03
channel_02 → flur.eltako.1_04
channel_02 → flur.eltako.2_03
Peers Modul 2
channel_01 → flur.eltako.1_03
channel_01 → flur.eltako.1_04
channel_01 → flur.eltako.2_03
channel_02 → flur.eltako.2_04
channel_02 → flur.eltako.2_03
Hi,
und von welchem der beiden wird Kanal 4 nicht richtig angezeigt?
Ausserdem: Kannst Du einen Zusammenhang feststellen zwischen internem und externem Peering und einer richtigen oder falsche Anzeige?
Ich wuerde das vielleicht mal versuchen nachzustellen, aber ich bin leider gerade ein paar tausend km weit weg...
Gruss,
Thorsten
komischerweise betrifft das nur den 4. Kanal von 1. Modul [channel_04 flur.eltako.1_04 ].
Zitat von: sprudelverduenner am 06 Oktober 2015, 21:05:03
es ist etwas komplizierter .... ich versuche es zu beschreiben:
Ja, das ist recht kompliziert.
Nach meiner Erfahrung dürften die Probleme bei der aktualisierung des readingstate nur bei internen peers vorkommen.
Wenn sich bei Dir die probleme auf interene peers beschränken, wäre ein weiteres Modul eine Lösungsmöglichkeit.
Evtl gibt es eine Möglichkeit die peers zu vereinfachen, z.B. durch zusätzliche Taster
Gruß Ralf
Halt .... Kommando zurück!
Der Kanal 04 von BEIDEN Modulen gibt einen fehlerhaften State zurück.
Und es ist egal welcher der Eingänge benutzt wird - der Fehler bleibt ...
Zitat von: sprudelverduenner am 06 Oktober 2015, 22:18:22
Der Kanal 04 von BEIDEN Modulen gibt einen fehlerhaften State zurück.
Und es ist egal welcher der Eingänge benutzt wird - der Fehler bleibt ...
Ist der Fehler auch bei:
Peers Modul 2
channel_01 → flur.eltako.1_04
Ja
Zitat von: sprudelverduenner am 06 Oktober 2015, 22:18:22
Der Kanal 04 von BEIDEN Modulen gibt einen fehlerhaften State zurück.
Und es ist egal welcher der Eingänge benutzt wird - der Fehler bleibt ...
Hast Du den fehlerhaften state, wenn Du das Licht mit dem Taster ein- oder ausschaltet?
Oder, wenn sich das Licht nach ablauf der ontime ausschaltet?
Hast Du von den Tastern zum Verteilerschrank eine zu 230V getrennte Verkabelung?
Dann gäbe es evtl die Möglichkeit in eine Verteilerdose das "076804 Wired RS485 4fach-I/O-Modul" und auch einen zusätzlichen Taster einzubauen.
Das würde dann die Sache mit den peerings vereinfachen.
Gruß Ralf
Das State ist sowohl nach dem Einschalten durch den Taster fehlerhaft (geht nicht an) als auch nach dem Ausschalten durch einen Taster (wenn es mal an ist, dann geht es nicht aus).
Was im Fehlerfall nach der OnTime passiert müsste ich mal versuchen herauszufinden - kann ich bisher nicht sagen.
Was den zusätzlichen Aktor angeht bin ich eigentlich nicht gewillt in zusätzliche Hardware zu investieren, wenn das Problem evt. durch Software hervorgerufen wird und sich dadurch auch lösen lassen könnte.
Meine Hardware Konstellation läuft ja generell so wie sie sollte - ausser das durch den falschen State das Abschalten einer Leuchte mit einem DOIF nicht zuverlässig geht...
UPDATE: Nach OnTime sind beide Ausgänge des 1. Moduls auf State on geblieben, der 1. Ausgang des 2. Moduls ist richtig auf off gegangen!
Zitat von: sprudelverduenner am 07 Oktober 2015, 16:57:50
Das State ist sowohl nach dem Einschalten durch den Taster fehlerhaft (geht nicht an) als auch nach dem Ausschalten durch einen Taster (wenn es mal an ist, dann geht es nicht aus).
Versuch mal ob der fehlerhafte state weg ist, wenn Du mit notifys bei einem Tastendruck ein "get state" des betroffenen Ausgangs ausführst.
In etwa so:
wenn Taster "flur.eltako.1_01" oder "flur.eltako.1_02" gedrückt, dann "get flur.eltako.1_04 state"
wenn Taster "flur.eltako.2_01" gedrückt, dann "get flur.eltako.1_04 state"
wenn Taster "flur.eltako.2_02" gedrückt, dann "get flur.eltako.2_04 state"
Gruß Ralf
Hi,
koenntest Du mal den Log Level auf 5 setzen, dann eine der Aktionen ausfuehren, die nicht richtig klappt, ein paar Sekunden warten und dann den Log Level wieder zurueck setzen. Ich wuerde dann gerne mal das entstandene Log sehen.
Gruss,
Thorsten
Moin Thorsten,
ich hoffe, dass ich alles richtig gemacht habe. Ich habe aus dem LOG alles unnötige rausgeholt.
Sollte etwas nicht passen bitte eine Rückinfo.
In diesem Fehlerfall ist der State von Kanal 4 von Modul (Eltako 1) ausgeblieben.
Lieben Gruß
Sprudelverduenner
Hi,
was ist denn das fuer ein Log? Irgendwie kommt mir das sehr unvertraut vor.
Kannst Du mal das komplette level-5 FHEM log von der ganzen Aktion hier reinstellen? D.h. loesche bitte nichts raus.
Bitte in code-Tags, dass man das nicht runterladen muss.
Gruss,
Thorsten
Da habe ich wohl gründlich Mist gebaut ?? :-[
Ich habe unter GLOBAL den VERBOSE von 3 auf 5 gesetzt.
Und dann habe ich das im log-Verzeichnis erzeugte fhem.save genommen.
Gelöscht habe ich dort nur Sachen von anderen Aktoren.
Sei so nett und sage mir doch, was ich machen soll....
Danke schön.
Zitat von: sprudelverduenner am 09 Oktober 2015, 17:45:27
Da habe ich wohl gründlich Mist gebaut ?? :-[
Soo schlimm ist das nicht.
Zitat
Ich habe unter GLOBAL den VERBOSE von 3 auf 5 gesetzt.
Ja, das war gemeint.
Zitat
Und dann habe ich das im log-Verzeichnis erzeugte fhem.save genommen.
Das ist nicht das logfile.
Am besten, Du klickst in der FHEM-UI links im Menue auf "Logfile". Daraus haette ich dann gerne alles von etwa eine Sekunde vor dem Tastendruck bis etwa 10 Sekunden danach.
...das ganze am besten nicht als Attachment, sondern in code-Tags.
Gruss,
Thorsten
sooooo .... ich hoffe, dass es das Richtige ist .....
In meiner fhem.cfg hatte ich die Zeile mit der Erstellung des logfile mit # auskommentiert ;D .
Kurz vor der Aktion siehst Du im LOG den Wechsel auf VERBOSE 5 und nach der Aktion am Ende den VERBOSE 3.
Da zwischen im Prinzip nur das Drücken von Taster zum Einschalten. Der Kanal 4 des elkato 1 macht hier den falschen State (er bleibt aus).
Kurz danach das 2. Drücken des Tasters zum Ausschalten des Lichts.
EDIT: ich muss das LOG-File dranhängen - es ist trotz der paar Sekunden zu lang für einen CODE-TAG.
* push *
Hi,
ich sehe das ganze schon, nur ist es fuer mich ziemlich schwierig, das von hier (bin gerade nicht daheim) auszuwerten.
Das kann naechste Woche werden.
Gruss,
Thorsten
Hi,
ich habe das ganze jetzt mal analysiert. ...oder zumindest damit angefangen.
Ich kann mir vorstellen, dass das System insgesamt etwas überlastet ist, bin mir aber nicht sicher. Deine HMW-Devices (oder zumindest zwei davon) scheinen in einer "get config" Schleife zu hängen. Dadurch bleibt das System relativ hoch belastet und es kann auch sein, dass andere Nachrichten nicht so richtig durchdringen. Das soll natürlich nicht so sein...
Kannst Du mal für alle Deine HMW-Devices nachsehen, was im Internal CONFIG_STATUS steht? Schau am Besten mehrmals nach und vor Allem dann, wenn die Probleme auftreten.
Gruß,
Thorsten
Guten Morgen,
Danke für Deine Rückmeldung.
Wo genau finde ich diesen CONFIG_STATUS ?
Info: ich habe nur diese beiden HMW Devices - keine weiteren...
Gruß
Sprudelverduenner
Zitat von: sprudelverduenner am 13 Oktober 2015, 07:38:04Wo genau finde ich diesen CONFIG_STATUS ?
Auf dem Detailbild zu Deinen Devices, relativ weit oben.
Häng am besten mal einen Screenshot Deiner Devices hier rein.
Moin Torsten,
ich hoffe dass diese Info die ist, die Du sehen wolltest.
Screenshot habe ich gemacht während der Kanal 4 von Eltako 1 anzeigte dass er angeblich aus sei.
Wenn Du hier einen Fehler vermutest, dann gehe ich die Tage hin und lösche die gesamte Config noch einmal und richte sie Step-by-Step neu ein um darauf achten zu können, nach welchem Schritt sich das Problem einstellt...
Gruß
Sprudelverduenner
Hi,
nur eine kurze Rückmeldung von mir: Ich hab das schon noch auf dem Radar, aber momentan wenig Zeit.
Ich glaube, dass es etwas damit zu tun hat, dass es von Zeit zu Zeit irgendwelche Probleme auf dem Bus gibt, die durch die normale Wiederholung der Nachrichten nicht zu beheben sind. (Da solltest Du vielleicht nochmal die Verkabelung und ggf. "Abschluss"widerstände prüfen.) Dadurch kommt es vor, dass das System die Konfiguration der Geräte neu einliest. Dabei kommt es zu etwas mehr Last auf dem Bus, was dann andere Nachrichten stören kann. Normalerweise ist das kein Problem, außer bei Broadcast-Messages. Letztere haben die Besonderheit, dass keine Antwort (kein ACK) erwartet wird, da sie keinen eindeutigen Empfänger haben. D.h. diese Messages funktionieren entweder beim ersten Versuch oder sie gehen eben verloren.
An der Sache mit den Broadcasts an sich kann man nichts machen. Ich habe aber ein paar Ideen, wie man das Problem zumindest kleiner machen kann. Bis dahin kannst Du Dir vielleicht ein "at" einrichten, das alle 10 Sekunden oder so den aktuellen Status der Kanäle abfragt. Ist nicht schön, aber damit hast Du es wenigstens einigermaßen aktuell.
Gruß,
Thorsten
Hi,
ich habe mich jetzt mal mit einer möglichen Lösung befasst. Mit Version 0.7.26 (siehe hier: http://forum.fhem.de/index.php/topic,10607.msg351017.html#msg351017 (http://forum.fhem.de/index.php/topic,10607.msg351017.html#msg351017)) wird den Geräten die Zentralenadresse beigebracht. Ein Effekt ist, dass die Übertragung der Gerätezustände ("Logging") zuverlässiger wird.
Könntest Du Dir mal die neuste Version (also mindestens 0.7.26) aus dem dev-Branch (https://github.com/kc-GitHub/FHEM-HM485/tree/dev (https://github.com/kc-GitHub/FHEM-HM485/tree/dev)) holen und installieren?
Danach für Deine HM-Wired Geräte ein "get ... config all" machen. Du müsstest dann (nach einem Browser-Refresh) ein neues Reading "R-central_address" sehen mit dem Wert "FFFFFFFF". Danach dann nochmal "get...config all", was den Wert von R-central_address auf "00000001" ändern sollte. (Der Wert ist im Gerät vorher schon so, nur die Anzeige in FHEM wird noch nicht automatisch richtig gebogen.)
Dadurch sollte die Anzeige des Zustands Deiner Kanäle zuverlässiger sein.
Gruß,
Thorsten
Moin Thorsten,
ich habe heute morgen Deine neue Version aus dem Github drauf geschmissen.
Das Reading ist bei beiden Modulen jetzt da. Es hat einige GET.... CONFIG ALL gebraucht - gepaart mit mehrmaligem Betätigen der Taster an den Eingängen. Auch die LOGGING TIME wurde nicht sofort übernommen.
Ich kann aber leider beim STATE keine Verbesserung erkennen.
Die nächsten Tage schaue ich mit noch einmal die Verkabelung an:
Es sind nur diese 2 Module und ein selbst konstruierter Abschlusswiderstand.
Danke und schönen Tag.
Lieben Gruß
Sprudelverduenner
Hi,
das, was Du schreibst, klingt etwas seltsam. Aber erstmal Stück für Stück.
Zitat von: sprudelverduenner am 28 Oktober 2015, 09:35:58
Das Reading ist bei beiden Modulen jetzt da. Es hat einige GET.... CONFIG ALL gebraucht - gepaart mit mehrmaligem Betätigen der Taster an den Eingängen.
Das Betätigen irgendwelcher Tasten während dem get config dürfte in Deiner wackeligen Umgebung sehr kontraproduktiv sein. Wenn man mal ein "get config" für ein Device gestartet hat, dann sollte man das Internal "CONFIG_STATUS" beobachten (mal zwischendurch ein Browser-Refresh machen). Normalerweise sollte das System so lange versuchen, die Daten vom Gerät zu bekommen, bis es erfolgreich ist. Dann steht "CONFIG_STATUS" auf "OK". Das kann bei Problemen auf dem Bus auch mal eine Weile dauern.
Irgendwelche Tasten muss man nur drücken, wenn FHEM das Gerät noch nicht kennt.
Zitat
Auch die LOGGING TIME wurde nicht sofort übernommen.
Was meinst Du denn damit? Das war doch vorher schon da. Ist es zwischendurch verschwunden?
ZitatIch kann aber leider beim STATE keine Verbesserung erkennen.
Tja, dann hat die Änderung wohl erstmal nichts gebracht...
Zitat
Es sind nur diese 2 Module und ein selbst konstruierter Abschlusswiderstand.
Könntest Du davon mal einen Schaltplan liefern? Es ist nämlich gar nicht so klar was "Abschlusswiderstand" eigentlich bedeutet. Bei Homematic sind das eher Pullup- und Pulldown-Widerstände. Echte Abschlusswiderstände sind meiner Meinung nach nur bei höheren Frequenzen sinnvoll.
Gruß,
Thorsten
Hi Thorsten,
also die logging Time stand mit der Firmware aus dem Github nicht mehr auf 1.00 Sek sondern auf 5.1 Sek.
Ich musste mehrmals die 1.00 Sek eingeben und auf speichern drücken bis nach einem Browser Refresh diese auch tatsächlich angezeigt wurde...
Der "Abschlusswiderstand" ist bei mir eine Widerstandsbrücke aus (ich glaube) 3 Widerständen. Den Schaltplan dazu habe ich mal im iNet gefunden. Der Plan habe ich jetzt zu Hause. Aus der Erinnerung: Es wird A mit einem Widerstand auf + verbunden, B mit - und A und B...
Grüße
Sprudelverduenner
Zitat von: sprudelverduenner am 28 Oktober 2015, 11:05:33
also die logging Time stand mit der Firmware aus dem Github nicht mehr auf 1.00 Sek sondern auf 5.1 Sek.
Ich musste mehrmals die 1.00 Sek eingeben und auf speichern drücken bis nach einem Browser Refresh diese auch tatsächlich angezeigt wurde...
Da vermute ich mal, dass der Initialisierungsprozess (get config am Anfang) noch nicht ganz durch war. Dann werden u.U. erst einmal blödsinnige Werte angezeigt. Hast Du das versucht, bevor oder nachdem CONFIG_STATUS auf OK war?
Ich glaube, ich muss da mal was einbauen, dass man mit den Geräten erst was machen kann nachdem die Konfiguration eingelesen ist.
ZitatDer "Abschlusswiderstand" ist bei mir eine Widerstandsbrücke aus (ich glaube) 3 Widerständen. Den Schaltplan dazu habe ich mal im iNet gefunden. Der Plan habe ich jetzt zu Hause. Aus der Erinnerung: Es wird A mit einem Widerstand auf + verbunden, B mit - und A und B...
Hier kommt's stark auf die Werte der Widerstände an. Es kursieren dazu im Wesentlichen zwei verschiedene Versionen: Eine mit relativ niedrigen Widerstandswerten (< 1kOhm) und eine mit hohen (> 10kOhm). Für HM-Wired braucht's das mit den hohen.
Gruß,
Thorsten
Auf den CONFIG_STATUS habe ich (ehrlich gesagt) nicht geachtet.
Vielleicht war es auch das, dass ich meinte mit mehreren Tastendrücken wäre es behoben und in Wirklichkeit war es noch nicht fertig mit einlesen ....
Bzgl. Widerstände muss ich heute Abend in den Unterlagen nachschauen - ich weiss, dass ich auch 2 Varianten im Netz gefunden hatte. Welche ich nun final verbaut habe weiss ich aus dem Kopf nicht mehr - ich habe aber den Schaltplan aufbewahrt und werde berichten...
Gruß
Sprudelverduenner
Hi,
ich habe jetzt eine neue Version 0.7.27 gemacht, die die Buslast stark vermindert, wenn es Probleme auf dem Bus gibt. Details gibt's hier: http://forum.fhem.de/index.php/topic,10607.msg351548.html#msg351548 (http://forum.fhem.de/index.php/topic,10607.msg351548.html#msg351548).
Es kann sein, dass dadurch Deine Probleme kleiner werden. Wenn nicht, dann haben wir wenigstens bessere Chancen, sie zu analysieren.
Installieren und shutdown restart sollten ausreichen.
Gruß,
Thorsten
Mahlzeit Thorsten,
aktuelle Version aus dem Github ist installiert.
Problem ist geblieben. Was kann ich Dir jetzt an Daten geben, um das Problem einzugrenzen?
Gruß
Sprudelverduenner
Nachtrag:
Den Abschlusswiderstand habe ich nach dieser Anleitung nachgebaut ....
http://homematic-forum.de/forum/viewtopic.php?f=31&t=15128&p=119896 (http://homematic-forum.de/forum/viewtopic.php?f=31&t=15128&p=119896)
Zitat von: sprudelverduenner am 01 November 2015, 13:15:48aktuelle Version aus dem Github ist installiert.
Problem ist geblieben. Was kann ich Dir jetzt an Daten geben, um das Problem einzugrenzen?
Sehr seltsam...
Setze mal im HM485_LAN-Device das Attribute verbose auf 5 und versuche dann, das Problem zu provozieren. Das Log hätte ich dann gerne.
Das Attribute verbose kannst Du danach einfach löschen.
Zitat von: sprudelverduenner am 01 November 2015, 13:31:52
Den Abschlusswiderstand habe ich nach dieser Anleitung nachgebaut ....
http://homematic-forum.de/forum/viewtopic.php?f=31&t=15128&p=119896 (http://homematic-forum.de/forum/viewtopic.php?f=31&t=15128&p=119896)
Das sieht eigentlich richtig aus.
Gruß,
Thorsten
Here we go......
Direkt im 1. Versuch blieb der STATE von Flur.eltako.1_04 aus.
LOG im Anhang.
Was mir heute Nachmittag aufgefallen war: Wenn der STATE falsch ist und ich einen GET CONFIG ALL mache, dann liest das Modul den richtigen STATE ein.
Hi,
ich verstehe nicht so ganz, warum da immer etwas wie das hier dazwischen ist:
flur.eltako.2: Device:getRawEEpromData hmwId = 0000AE44
Das dürfte mit der neuen Version eigentlich nur beim Neustart passieren oder wenn Du manuell get config machst. Könntest Du mal shutdown restart machen und ein list der beteiligten Devices schicken?
(Ich bin zurzeit im Urlaub, es kann sein, dass meine Antworten etwas auf sich warten lassen.)
Gruß,
Thorsten
Moin,
erst einmal Danke, dass Du Dich da so bemühst und Urlaub geht vor....
Hier der LIST Flur.eltako.1
Internals:
CFGFN /opt/fhem/FHEM/sub_schalter.cfg
DEF 0000AE4F
FW_VERSION 3.06
IODev HMRS485
MODEL HMW_LC_Sw2_DR
NAME flur.eltako.1
NR 268
STATE ACK
TYPE HM485
channel_01 flur.eltako.1_01
channel_02 flur.eltako.1_02
channel_03 flur.eltako.1_03
channel_04 flur.eltako.1_04
peer_act_0 channel_01 ? flur.eltako.1_03
peer_act_1 channel_02 ? flur.eltako.1_03
peer_act_2 channel_02 ? flur.eltako.1_04
peer_act_3 channel_01 ? flur.eltako.1_04
peer_act_4 channel_02 ? flur.eltako.2_03
peer_act_5 channel_01 ? flur.eltako.2_03
peer_act_6 channel_01 ? flur.eltako.2_04
peer_act_7 channel_02 ? flur.eltako.2_04
peer_sen_0 channel_03 ? flur.eltako.1_01
peer_sen_1 channel_03 ? flur.eltako.1_02
peer_sen_2 channel_04 ? flur.eltako.2_01
peer_sen_3 channel_04 ? flur.eltako.1_02
peer_sen_4 channel_04 ? flur.eltako.1_01
peer_sen_5 channel_03 ? flur.eltako.2_01
Readings:
2015-11-03 07:50:36 R-central_address 00000001
2015-11-03 07:50:37 configStatus OK
2015-11-03 07:50:37 state ACK
Cache:
Linkparams:
Actuator:
address_start 855
address_step 6
channel_param channel
channels 01 02
count 28
peer_param actuator
type link
Parameter:
Actuator:
hidden 1
operations none
Logical:
type address
physical:
HASH(0x1039818)
HASH(0x1050ec0)
Channel:
hidden 1
operations none
Logical:
default 255
max 255
min 0
type integer
Physical:
interface eeprom
size 1
type integer
Address:
index 0
Sensor:
address_start 15
address_step 28
channel_param channel
channels 03 04
count 30
peer_param sensor
type link
Parameter:
Channel:
hidden 1
operations none
Logical:
default 255
max 255
min 0
type integer
Physical:
interface eeprom
size 1
type integer
Address:
index 5
Long_action_type:
Logical:
type option
option:
HASH(0xeb42f0)
HASH(0xeb3fa8)
Physical:
interface eeprom
size 0.1
type integer
Address:
index 17
Long_jt_off:
Logical:
type option
option:
HASH(0xeb36b8)
HASH(0xeb3768)
HASH(0xeb3628)
HASH(0xeb3610)
HASH(0xeb35b0)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 26.9
Long_jt_offdelay:
Logical:
type option
option:
HASH(0xeb3340)
HASH(0xeb32f8)
HASH(0xeb3310)
HASH(0xeb3298)
HASH(0xeb3328)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 26.6
Long_jt_on:
Logical:
type option
option:
HASH(0xeb30d0)
HASH(0xeb2ed8)
HASH(0xeb2fe0)
HASH(0xeb2ea8)
HASH(0xeb2e78)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 26.3
Long_jt_ondelay:
Logical:
type option
option:
HASH(0xeb2bf0)
HASH(0xeb2c80)
HASH(0xeb2c20)
HASH(0xeb2b60)
HASH(0xeb2bd8)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 26
Long_multiexecute:
Logical:
default 1
type boolean
Physical:
interface eeprom
size 0.1
type integer
Address:
index 17.2
Long_off_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 16383000
max 982980
min 0
type float
unit s
Special_value:
id not_used
value 16383000
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 24
Long_off_time_mode:
Logical:
type option
option:
HASH(0x1111658)
HASH(0x1111610)
Physical:
interface eeprom
size 0.1
type integer
Address:
index 17.6
Long_offdelay_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 0
max 982980
min 0
type float
unit s
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 22
Long_on_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 16383000
max 982980
min 0
type float
unit s
Special_value:
id not_used
value 16383000
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 20
Long_on_time_mode:
Logical:
type option
option:
HASH(0x110ac28)
HASH(0x110ad48)
Physical:
interface eeprom
size 0.1
type integer
Address:
index 17.7
Long_ondelay_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 0
max 982980
min 0
type float
unit s
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 18
Long_toggle_use:
Conversion:
type option_integer
Value_map:
1:
device_value 3
from_device 1
parameter_value 0
to_device 1
2:
device_value 2
from_device 1
parameter_value 1
to_device 1
3:
device_value 0
from_device 1
parameter_value 2
to_device 1
Logical:
type option
option:
HASH(0x11081f8)
HASH(0x11078d8)
HASH(0x1107800)
Physical:
interface eeprom
size 0.2
type integer
Address:
index 17.4
Sensor:
hidden 1
operations none
Logical:
type address
physical:
HASH(0x1106c48)
HASH(0x1106170)
Short_action_type:
Logical:
type option
option:
HASH(0x1105b70)
HASH(0x1105a98)
Physical:
interface eeprom
size 0.1
type integer
Address:
index 6
Short_jt_off:
Logical:
type option
option:
HASH(0x11050d0)
HASH(0x1104f38)
HASH(0x1104e30)
HASH(0x1104cf8)
HASH(0x1104bf0)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 15.9
Short_jt_offdelay:
Logical:
type option
option:
HASH(0x10c1010)
HASH(0x10c0d28)
HASH(0x10c0c50)
HASH(0x10c0bd8)
HASH(0x10c09e0)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 15.6
Short_jt_on:
Logical:
type option
option:
HASH(0x10fb7b8)
HASH(0x10fb6c8)
HASH(0x10fb620)
HASH(0x10fb3b0)
HASH(0x10fb2c0)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 15.3
Short_jt_ondelay:
Logical:
type option
option:
HASH(0x1098050)
HASH(0x1098458)
HASH(0x10aeac8)
HASH(0x10aef30)
HASH(0x10af5d8)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 15
Short_off_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 16383000
max 982980
min 0
type float
unit s
Special_value:
id not_used
value 16383000
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 13
Short_off_time_mode:
Logical:
type option
option:
HASH(0x1139810)
HASH(0x1139858)
Physical:
interface eeprom
size 0.1
type integer
Address:
index 6.6
Short_offdelay_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 0
max 982980
min 0
type float
unit s
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 11
Short_on_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 16383000
max 982980
min 0
type float
unit s
Special_value:
id not_used
value 16383000
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 9
Short_on_time_mode:
Logical:
type option
option:
HASH(0x113c890)
HASH(0x113c8d8)
Physical:
interface eeprom
size 0.1
type integer
Address:
index 6.7
Short_ondelay_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 0
max 982980
min 0
type float
unit s
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 7
Short_toggle_use:
Conversion:
type option_integer
Value_map:
1:
device_value 3
from_device 1
parameter_value 0
to_device 1
2:
device_value 2
from_device 1
parameter_value 1
to_device 1
3:
device_value 0
from_device 1
parameter_value 2
to_device 1
Logical:
type option
option:
HASH(0x113cdb8)
HASH(0x113ce18)
HASH(0x113ce60)
Physical:
interface eeprom
size 0.2
type integer
Address:
index 6.4
Ui_hint:
Logical:
default
type string
use_default_on_failure 1
Physical:
id ui_hint
interface store
save_on_change 1
type string
Peered_act:
0:
channel 01
name 0000AE4F_03
1:
channel 02
name 0000AE4F_03
2:
channel 02
name 0000AE4F_04
3:
channel 01
name 0000AE4F_04
4:
channel 02
name 0000AE44_03
5:
channel 01
name 0000AE44_03
6:
channel 01
name 0000AE44_04
7:
channel 02
name 0000AE44_04
Peers:
Actuators:
0:
actuator 0000AE4F_03
channel 01
1:
actuator 0000AE4F_03
channel 02
2:
actuator 0000AE4F_04
channel 02
3:
actuator 0000AE4F_04
channel 01
4:
actuator 0000AE44_03
channel 02
5:
actuator 0000AE44_03
channel 01
6:
actuator 0000AE44_04
channel 01
7:
actuator 0000AE44_04
channel 02
Sensors:
0:
channel 03
sensor 0000AE4F_01
1:
channel 03
sensor 0000AE4F_02
2:
channel 04
sensor 0000AE44_01
3:
channel 04
sensor 0000AE4F_02
4:
channel 04
sensor 0000AE4F_01
5:
channel 03
sensor 0000AE44_01
Attributes:
firmwareVersion 3.06
model HMW_LC_Sw2_DR
room 0.1_Flur
serialNr KEQ1056348
Und der LIST flur.eltako.2
Internals:
CFGFN /opt/fhem/FHEM/sub_schalter.cfg
DEF 0000AE44
FW_VERSION 3.06
IODev HMRS485
MODEL HMW_LC_Sw2_DR
NAME flur.eltako.2
NR 269
STATE ACK
TYPE HM485
channel_01 flur.eltako.2_01
channel_02 flur.eltako.2_02
channel_03 flur.eltako.2_03
channel_04 flur.eltako.2_04
peer_act_0 channel_02 ? flur.eltako.2_04
peer_act_1 channel_01 ? flur.eltako.2_03
peer_act_2 channel_02 ? flur.eltako.2_03
peer_sen_0 channel_04 ? flur.eltako.2_02
peer_sen_1 channel_03 ? flur.eltako.1_01
peer_sen_2 channel_03 ? flur.eltako.1_02
peer_sen_3 channel_03 ? flur.eltako.2_01
peer_sen_4 channel_03 ? flur.eltako.2_02
peer_sen_5 channel_04 ? flur.eltako.1_01
peer_sen_6 channel_04 ? flur.eltako.1_02
Readings:
2015-11-03 07:50:29 R-central_address 00000001
2015-11-03 07:50:29 configStatus OK
2015-11-03 07:50:29 state ACK
Cache:
Linkparams:
Actuator:
address_start 855
address_step 6
channel_param channel
channels 01 02
count 28
peer_param actuator
type link
Parameter:
Actuator:
hidden 1
operations none
Logical:
type address
physical:
HASH(0x1039818)
HASH(0x1050ec0)
Channel:
hidden 1
operations none
Logical:
default 255
max 255
min 0
type integer
Physical:
interface eeprom
size 1
type integer
Address:
index 0
Sensor:
address_start 15
address_step 28
channel_param channel
channels 03 04
count 30
peer_param sensor
type link
Parameter:
Channel:
hidden 1
operations none
Logical:
default 255
max 255
min 0
type integer
Physical:
interface eeprom
size 1
type integer
Address:
index 5
Long_action_type:
Logical:
type option
option:
HASH(0xeb42f0)
HASH(0xeb3fa8)
Physical:
interface eeprom
size 0.1
type integer
Address:
index 17
Long_jt_off:
Logical:
type option
option:
HASH(0xeb36b8)
HASH(0xeb3768)
HASH(0xeb3628)
HASH(0xeb3610)
HASH(0xeb35b0)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 26.9
Long_jt_offdelay:
Logical:
type option
option:
HASH(0xeb3340)
HASH(0xeb32f8)
HASH(0xeb3310)
HASH(0xeb3298)
HASH(0xeb3328)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 26.6
Long_jt_on:
Logical:
type option
option:
HASH(0xeb30d0)
HASH(0xeb2ed8)
HASH(0xeb2fe0)
HASH(0xeb2ea8)
HASH(0xeb2e78)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 26.3
Long_jt_ondelay:
Logical:
type option
option:
HASH(0xeb2bf0)
HASH(0xeb2c80)
HASH(0xeb2c20)
HASH(0xeb2b60)
HASH(0xeb2bd8)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 26
Long_multiexecute:
Logical:
default 1
type boolean
Physical:
interface eeprom
size 0.1
type integer
Address:
index 17.2
Long_off_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 16383000
max 982980
min 0
type float
unit s
Special_value:
id not_used
value 16383000
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 24
Long_off_time_mode:
Logical:
type option
option:
HASH(0x1111658)
HASH(0x1111610)
Physical:
interface eeprom
size 0.1
type integer
Address:
index 17.6
Long_offdelay_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 0
max 982980
min 0
type float
unit s
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 22
Long_on_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 16383000
max 982980
min 0
type float
unit s
Special_value:
id not_used
value 16383000
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 20
Long_on_time_mode:
Logical:
type option
option:
HASH(0x110ac28)
HASH(0x110ad48)
Physical:
interface eeprom
size 0.1
type integer
Address:
index 17.7
Long_ondelay_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 0
max 982980
min 0
type float
unit s
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 18
Long_toggle_use:
Conversion:
type option_integer
Value_map:
1:
device_value 3
from_device 1
parameter_value 0
to_device 1
2:
device_value 2
from_device 1
parameter_value 1
to_device 1
3:
device_value 0
from_device 1
parameter_value 2
to_device 1
Logical:
type option
option:
HASH(0x11081f8)
HASH(0x11078d8)
HASH(0x1107800)
Physical:
interface eeprom
size 0.2
type integer
Address:
index 17.4
Sensor:
hidden 1
operations none
Logical:
type address
physical:
HASH(0x1106c48)
HASH(0x1106170)
Short_action_type:
Logical:
type option
option:
HASH(0x1105b70)
HASH(0x1105a98)
Physical:
interface eeprom
size 0.1
type integer
Address:
index 6
Short_jt_off:
Logical:
type option
option:
HASH(0x11050d0)
HASH(0x1104f38)
HASH(0x1104e30)
HASH(0x1104cf8)
HASH(0x1104bf0)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 15.9
Short_jt_offdelay:
Logical:
type option
option:
HASH(0x10c1010)
HASH(0x10c0d28)
HASH(0x10c0c50)
HASH(0x10c0bd8)
HASH(0x10c09e0)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 15.6
Short_jt_on:
Logical:
type option
option:
HASH(0x10fb7b8)
HASH(0x10fb6c8)
HASH(0x10fb620)
HASH(0x10fb3b0)
HASH(0x10fb2c0)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 15.3
Short_jt_ondelay:
Logical:
type option
option:
HASH(0x1098050)
HASH(0x1098458)
HASH(0x10aeac8)
HASH(0x10aef30)
HASH(0x10af5d8)
Physical:
endian little
interface eeprom
read_size 2
size 0.3
type integer
Address:
index 15
Short_off_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 16383000
max 982980
min 0
type float
unit s
Special_value:
id not_used
value 16383000
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 13
Short_off_time_mode:
Logical:
type option
option:
HASH(0x1139810)
HASH(0x1139858)
Physical:
interface eeprom
size 0.1
type integer
Address:
index 6.6
Short_offdelay_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 0
max 982980
min 0
type float
unit s
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 11
Short_on_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 16383000
max 982980
min 0
type float
unit s
Special_value:
id not_used
value 16383000
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 9
Short_on_time_mode:
Logical:
type option
option:
HASH(0x113c890)
HASH(0x113c8d8)
Physical:
interface eeprom
size 0.1
type integer
Address:
index 6.7
Short_ondelay_time:
Conversion:
1:
factors 0.1,1,60,1000
type float_configtime
value_size 1.6
2:
type integer_integer_map
Value_map:
device_value 49152
mask 49152
parameter_value 65535
Logical:
default 0
max 982980
min 0
type float
unit s
Physical:
endian little
interface eeprom
size 2
type integer
Address:
index 7
Short_toggle_use:
Conversion:
type option_integer
Value_map:
1:
device_value 3
from_device 1
parameter_value 0
to_device 1
2:
device_value 2
from_device 1
parameter_value 1
to_device 1
3:
device_value 0
from_device 1
parameter_value 2
to_device 1
Logical:
type option
option:
HASH(0x113cdb8)
HASH(0x113ce18)
HASH(0x113ce60)
Physical:
interface eeprom
size 0.2
type integer
Address:
index 6.4
Ui_hint:
Logical:
default
type string
use_default_on_failure 1
Physical:
id ui_hint
interface store
save_on_change 1
type string
Peered_act:
0:
channel 02
name 0000AE44_04
1:
channel 01
name 0000AE44_03
2:
channel 02
name 0000AE44_03
Peers:
Actuators:
0:
actuator 0000AE44_04
channel 02
1:
actuator 0000AE44_03
channel 01
2:
actuator 0000AE44_03
channel 02
Sensors:
0:
channel 04
sensor 0000AE44_02
1:
channel 03
sensor 0000AE4F_01
2:
channel 03
sensor 0000AE4F_02
3:
channel 03
sensor 0000AE44_01
4:
channel 03
sensor 0000AE44_02
5:
channel 04
sensor 0000AE4F_01
6:
channel 04
sensor 0000AE4F_02
Attributes:
firmwareVersion 3.06
model HMW_LC_Sw2_DR
room 0.1_Flur
serialNr KEQ1056355
Hi,
das sieht eigentlich alles gut aus. Ich kann mir momentan nicht so ganz erklären, warum das nicht funktioniert.
Kannst Du mir mal ein Level-5-Log liefern für einen Fall wo es funktioniert? Bitte ohne get config oder ähnliches.
Gruß,
Thorsten
Moin,
hier ein LOG vom umgekehrten Fall.
Bei der 1. Tasteraktion:
flur.eltako.1_03 STATE bleibt aus
und
flur.eltako.1_04 STATE ging ausnahmsweise mal an
Bei der 2. Tasteraktion:
flur.eltako.1_03 + flur.eltako.1_04 STATE bleiben wie vorher - also flur.eltako.1_04 STATE fälschlicherweise an
Bin ja mal gespannt, ob Du einen Unterschied im LOG findest.
Hi,
sorry für die späte Antwort. Ich war im Urlaub und habe jetzt wenig Zeit. Das Log durchzugehen braucht ja schon etwas Muße. Es wäre auch nicht schlecht gewesen, wenn Du mir die Zeit (Uhrzeit) der Aktionen genannt hättest. Kannst Du das noch?
Gruß,
Thorsten
Moin moin,
also insgesamt sind in dem LOG nur dIe 2 angesprochenen Aktionen drinne.
Ich kann mir natürlich gerne den LOG noch einmal vornehmen und alle anderen Sachen, die nichts damit zu tun haben, löschen, so dass der LOG kompakter wird ...
LG Sprudelverduenner
Hi,
das ganze sieht so aus, als ob Du FHEM gerade gestartet hast und erst einmal die ganze Konfiguration von den Devices gelesen wird. Dadurch steht erst einmal ziemlich viel Kram im Log und außerdem kann es durchaus sein, dass die Kommunikation zwischen FHEM und den Devices noch nicht so richtig klappt. Eigentlich sollte das nicht so sein, aber es ist ziemlich schwierig nachzuvollziehen.
Könntest Du mal folgendes machen:
1. Sicherstellen, dass FHEM schon ein paar Minuten läuft und in allen HMW-Devices das Reading (nicht das Internal!) configStatus auf OK steht.
2. Dann das Attribut verbose im Device HMRS485 auf 5 setzen. (Nicht verbose in global.)
3. Dann versuchen, die entsprechenden Logs zu erzeugen, d.h. einmal mit der richtigen Funktion und einmal wo es nicht klappt.
Gruß,
Thorsten
Ich hoffe hier ist jetzt etwas verwertbares für Dich dabei....
1. Fall: flur.eltako.1_03 geht an / flur.eltako.1_04 bleibt aus [beides sollte an gehen]
2015.11.15 15:09:38 1: Including fhem.cfg
2015.11.15 15:09:38 3: telnetPort: port 7072 opened
2015.11.15 15:09:38 3: WEB: port 8083 opened
2015.11.15 15:09:38 3: WEBphone: port 8084 opened
2015.11.15 15:09:38 3: WEBtablet: port 8085 opened
2015.11.15 15:09:40 2: eventTypes: loaded 3770 events from ./log/eventTypes.log
2015.11.15 15:09:40 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.11.15 15:09:40 3: Opening HMLAN1 device 192.168.1.51:1000
2015.11.15 15:09:40 3: HMLAN1 device opened
2015.11.15 15:09:40 1: HMLAN_Parse: HMLAN1 new condition init
2015.11.15 15:09:41 1: Including /opt/fhem/FHEM/sub_externe-geraete.cfg
2015.11.15 15:09:41 2: FRITZBOX fritz.box: TR064_Init.4099 The device 'undefined' doesn't have a TR-064 API or TR-064 is switched off.
2015.11.15 15:09:41 3: Opening fritz.box.callmonitor device 192.168.1.10:1012
2015.11.15 15:09:41 3: fritz.box.callmonitor device opened
2015.11.15 15:09:44 1: Including /opt/fhem/FHEM/sub_fenster.cfg
2015.11.15 15:09:44 1: Including /opt/fhem/FHEM/sub_heizung.cfg
2015.11.15 15:09:45 1: Including /opt/fhem/FHEM/sub_licht.cfg
2015.11.15 15:09:47 1: Including /opt/fhem/FHEM/sub_rollade.cfg
2015.11.15 15:09:48 1: Including /opt/fhem/FHEM/sub_schalter.cfg
2015.11.15 15:09:49 2: HMRS485: Assigned 0000AE4F as flur.eltako.1
2015.11.15 15:09:49 3: HMRS485: Warte auf Initialisierung Gateway
2015.11.15 15:09:49 2: HMRS485: Assigned 0000AE44 as flur.eltako.2
2015.11.15 15:09:49 3: HMRS485: Warte auf Initialisierung Gateway
2015.11.15 15:09:49 1: Including ./log/fhem.save
2015.11.15 15:09:54 3: Opening HMRS485 device 192.168.1.52:1000
2015.11.15 15:09:54 3: HMRS485 device opened
2015.11.15 15:09:54 3: HMRS485: connected to device 192.168.1.52:1000
2015.11.15 15:09:55 3: HMRS485: Initialisierung von Modul 0000AE4F
2015.11.15 15:09:55 3: HMRS485: Initialisierung von Modul 0000AE44
2015.11.15 15:09:55 1: HMLAN_Parse: HMLAN1 new condition ok
2015.11.15 15:09:55 3: HMRS485: Lan Device Information
2015.11.15 15:09:55 3: HMRS485: Protocol-Version: 01
2015.11.15 15:09:55 3: HMRS485: Interface-Type: eQ3-HMW-LGW
2015.11.15 15:09:55 3: HMRS485: Firmware-Version: 1.0.4
2015.11.15 15:09:55 3: HMRS485: Serial-Number: LEQ0636924
2015.11.15 15:09:55 3: HMRS485: Initialize the interface
2015.11.15 15:09:56 3: Device aussen.tuer.motion added to ActionDetector with 000:10 time
2015.11.15 15:09:56 3: Device bad.fenster added to ActionDetector with 028:00 time
2015.11.15 15:09:56 3: Device bad.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:56 3: Device buegelz.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:56 3: Device buero.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:57 3: Device buero.tuer added to ActionDetector with 028:00 time
2015.11.15 15:09:57 3: Device flur.fenster.rechts added to ActionDetector with 028:00 time
2015.11.15 15:09:57 3: Device flur.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:57 3: Device gaestez.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:58 3: Device kueche.fenster added to ActionDetector with 028:00 time
2015.11.15 15:09:58 3: Device kueche.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:58 3: Device schlafz.fenster added to ActionDetector with 028:00 time
2015.11.15 15:09:58 3: Device schlafz.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:59 3: Device wohnz.fenster.links added to ActionDetector with 028:00 time
2015.11.15 15:09:59 3: Device wohnz.heizung.links added to ActionDetector with 000:10 time
2015.11.15 15:09:59 3: Device wohnz.heizung.rechts added to ActionDetector with 000:10 time
2015.11.15 15:09:59 3: Opening Sonos device localhost:4711
2015.11.15 15:09:59 3: Sonos device opened
2015.11.15 15:10:00 3: flur.eltako.1: Request config for device 0000AE4F
2015.11.15 15:10:00 3: flur.eltako.1: Lese Eeprom 0000AE4F
2015.11.15 15:10:00 3: flur.eltako.2: Request config for device 0000AE44
2015.11.15 15:10:00 3: flur.eltako.2: Lese Eeprom 0000AE44
2015.11.15 15:10:00 3: CUL_HM set aussen.tuer.lampe statusRequest
2015.11.15 15:10:01 3: CUL_HM set bad.rollade.fenster statusRequest
2015.11.15 15:10:03 3: CUL_HM set buero.rollade.fenster statusRequest
2015.11.15 15:10:04 3: CUL_HM set buero.rollade.tuer statusRequest
2015.11.15 15:10:05 3: CUL_HM set flur.eingang.licht statusRequest
2015.11.15 15:10:06 3: CUL_HM set flur.rollade.links statusRequest
2015.11.15 15:10:07 3: CUL_HM set flur.rollade.rechts statusRequest
2015.11.15 15:10:08 3: CUL_HM set gaestez.rollade.fenster statusRequest
2015.11.15 15:10:10 3: CUL_HM set kueche.licht statusRequest
2015.11.15 15:10:10 3: HMRS485: HM485_QueueStepFailed Call step
2015.11.15 15:10:10 3: flur.eltako.2: RESPONSE TIMEOUT for 0000AE44
2015.11.15 15:10:12 3: CUL_HM set kueche.rollade.fenster statusRequest
2015.11.15 15:10:12 3: FRITZBOX fritz.box: Readout_Process.1556 TR-064 is switched on
2015.11.15 15:10:13 3: CUL_HM set schlafz.licht statusRequest
2015.11.15 15:10:14 3: CUL_HM set schlafz.rollade.fenster statusRequest
2015.11.15 15:10:15 3: CUL_HM set vorrat.rollade.fenster statusRequest
2015.11.15 15:10:15 3: HMRS485: Initialisierung von Modul 0000AE44
2015.11.15 15:10:16 3: flur.eltako.2: Request config for device 0000AE44
2015.11.15 15:10:16 3: flur.eltako.2: Lese Eeprom 0000AE44
2015.11.15 15:10:17 3: CUL_HM set wohnz.dimmer.led12 statusRequest
2015.11.15 15:10:18 3: CUL_HM set wohnz.dimmer.led34 statusRequest
2015.11.15 15:10:19 3: CUL_HM set wohnz.rollade.links statusRequest
2015.11.15 15:10:20 3: CUL_HM set wohnz.rollade.rechts statusRequest
2015.11.15 15:10:24 3: CUL_HM set hm_fernbedienung getConfig
2015.11.15 15:11:10 5: flur.eltako.1: Device:getRawEEpromData hmwId = 0000AE4F
2015.11.15 15:11:10 5: flur.eltako.1: Device:getRawEEpromData hmwId = 0000AE4F
2015.11.15 15:11:10 5: flur.eltako.1: Device:getRawEEpromData hmwId = 0000AE4F
2015.11.15 15:11:40 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state_flags value1 = 4
2015.11.15 15:11:40 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 1
2015.11.15 15:11:40 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state value1 = 200
2015.11.15 15:11:40 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 1
2015.11.15 15:11:40 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 03 msgData = 6902C840 actionType = frame
2. Fall: flur.eltako.1_03 bleibt aus / flur.eltako.1_04 geht an [beides sollte an gehen]
2015.11.15 15:13:01 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state_flags value1 = 0
2015.11.15 15:13:01 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 0
2015.11.15 15:13:01 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state value1 = 0
2015.11.15 15:13:01 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 0
2015.11.15 15:13:01 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 03 msgData = 69020000 actionType = frame
2015.11.15 15:13:06 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 55
2015.11.15 15:13:06 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 55
2015.11.15 15:13:06 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 01 msgData = 4B0000DF actionType = frame
2015.11.15 15:13:06 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 55
2015.11.15 15:13:06 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 55
2015.11.15 15:13:06 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 01 msgData = 4B0000DF actionType = frame
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 55
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 55
2015.11.15 15:13:07 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 01 msgData = 4B0000DF actionType = frame
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 55
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 55
2015.11.15 15:13:07 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 01 msgData = 4B0000DF actionType = frame
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 55
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 55
2015.11.15 15:13:07 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 01 msgData = 4B0002DF actionType = frame
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 55
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 55
2015.11.15 15:13:07 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 01 msgData = 4B0003DF actionType = frame
2015.11.15 15:13:07 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F No channel
2015.11.15 15:13:08 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state_flags value1 = 0
2015.11.15 15:13:08 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 0
2015.11.15 15:13:08 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state value1 = 200
2015.11.15 15:13:08 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 1
2015.11.15 15:13:08 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 04 msgData = 6903C800 actionType = frame
2015.11.15 15:13:19 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 52
2015.11.15 15:13:19 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 52
2015.11.15 15:13:19 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 02 msgData = 4B0100D3 actionType = frame
2015.11.15 15:13:19 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 52
2015.11.15 15:13:19 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 52
2015.11.15 15:13:19 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 02 msgData = 4B0100D3 actionType = frame
2015.11.15 15:13:20 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 52
2015.11.15 15:13:20 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 52
2015.11.15 15:13:20 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 02 msgData = 4B0100D3 actionType = frame
2015.11.15 15:13:20 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 52
2015.11.15 15:13:20 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 52
2015.11.15 15:13:20 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 02 msgData = 4B0102D3 actionType = frame
2015.11.15 15:13:20 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 52
2015.11.15 15:13:20 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 52
2015.11.15 15:13:20 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 02 msgData = 4B0103D3 actionType = frame
2015.11.15 15:13:20 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F No channel
2015.11.15 15:13:21 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state_flags value1 = 0
2015.11.15 15:13:21 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 0
2015.11.15 15:13:21 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state value1 = 0
2015.11.15 15:13:21 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 0
2015.11.15 15:13:21 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 04 msgData = 69030000 actionType = frame
Lieben Gruß
Sprudelverduenner
Zitat von: sprudelverduenner am 15 November 2015, 15:20:38
Ich hoffe hier ist jetzt etwas verwertbares für Dich dabei....
Der erste Ausschnitt sieht zwar immer noch so aus als ob FHEM gerade hochfaehrt, aber jetzt kann man tatsaechlich ein bisschen was sehen. Allerdings habe ich gerade keinen Zugriff auf meinen ganzen FHEM-Kram und muss das alles aus dem Kopf machen.
Zitat
1. Fall: flur.eltako.1_03 geht an / flur.eltako.1_04 bleibt aus [beides sollte an gehen]
2015.11.15 15:09:49 2: HMRS485: Assigned 0000AE4F as flur.eltako.1
2015.11.15 15:09:49 2: HMRS485: Assigned 0000AE44 as flur.eltako.2
2015.11.15 15:09:54 3: HMRS485: connected to device 192.168.1.52:1000
2015.11.15 15:09:55 3: HMRS485: Initialisierung von Modul 0000AE4F
2015.11.15 15:09:55 3: HMRS485: Initialisierung von Modul 0000AE44
2015.11.15 15:10:00 3: flur.eltako.1: Request config for device 0000AE4F
2015.11.15 15:10:00 3: flur.eltako.1: Lese Eeprom 0000AE4F
2015.11.15 15:10:00 3: flur.eltako.2: Request config for device 0000AE44
2015.11.15 15:10:00 3: flur.eltako.2: Lese Eeprom 0000AE44
2015.11.15 15:10:10 3: HMRS485: HM485_QueueStepFailed Call step
2015.11.15 15:10:10 3: flur.eltako.2: RESPONSE TIMEOUT for 0000AE44
Da scheint es irgend ein Problem auf Deinem Bus zu geben. Vielleicht reagiert Dein eQ3-HMW-LGW aber auch nicht so, wie ich das vermute. Das waere aber etwas schade, weil dann waere der FHEM-Daemon sogar besser als der HM-Original-Kram.
Zitat
2015.11.15 15:10:16 3: flur.eltako.2: Request config for device 0000AE44
2015.11.15 15:10:16 3: flur.eltako.2: Lese Eeprom 0000AE44
2015.11.15 15:11:10 5: flur.eltako.1: Device:getRawEEpromData hmwId = 0000AE4F
2015.11.15 15:11:10 5: flur.eltako.1: Device:getRawEEpromData hmwId = 0000AE4F
Kann es sein, dass Du verbose fuer flur.eltako.2 explizit auf 3 sitzen hast? Ich sehe naemlich keine einzige Level-5 Message fuer flur.eltako.2. Koenntest Du das mal pruefen und das ganze ggf. nochmal machen?
Zitat
2015.11.15 15:11:40 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 03 msgData = 6902C840 actionType = frame
Das ist die einzige Message, die darauf hindeutet, dass der flur.eltako.1 seinen Zustand sendet. Er teilt da gerade mit, dass Kanal 02 (also nach aussen Kanal 3) auf "on" gesetzt wurde. Zum Kanal 4 steht hier tatsaechlich nichts.
Ist das wirklich alles, oder kommt danach noch was im Log?
Zitat
2. Fall: flur.eltako.1_03 bleibt aus / flur.eltako.1_04 geht an [beides sollte an gehen]
2015.11.15 15:13:01 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 03 msgData = 69020000 actionType = frame
2015.11.15 15:13:07 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F No channel
2015.11.15 15:13:08 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 04 msgData = 6903C800 actionType = frame
2015.11.15 15:13:21 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 04 msgData = 69030000 actionType = frame
Das heisst uebersetzt: Kanal 3 wird auf "off" gesetzt, dann Kanal 4 auf "on", dann Kanal 4 wieder auf "off". Das ist aber nicht ganz das, was Du gesagt hast. Ausserdem wundert mich das mit dem "No channel" zwischendurch.
Tja, was sollen wir jetzt damit machen?
Also erst einmal erinnere ich mich daran, dass wenn ich bei einem meiner HMW-Devices zwei Ausgaenge schnell hintereinander schalte, dass dann die "logging"-Message nicht fuer beide kam. Das ist dann ein Problem der HMW-Devices und FHEM koennte da auch nichts machen. Das muesste ich mir mal daheim anschauen, was aber fruehestens naechste Woche geht. Wenn das wirklich der Fall ist, dann koennte man noch etwas mit notify und get machen.
Ansonsten koennte ich Dir anbieten, dass wir mal eine Session ueber Skype machen. (Ich nehme nicht an, dass Du in meiner Nachbarschaft wohnst.) Dann koennten wir etwas direkter kommunizieren und ich wuerde auch direkt sehen, welche Aktion genau was ausloest. Wenn Du das willst, dann schreib' mir mal eine PM mit Deiner e-mail, Deinem Skype-Namen und einem Terminvorschlag fuer naechste Woche.
Gruss,
Thorsten
Moin Thorsten,
das ist in der Tat der komplette LOG, den ich nur in die 2 unterschiedlichen Fehlerbilder getrennt habe.
Aber Du hast recht, ich Dussel habe nur vom 1. Aktor den Verbose geändert.
Da ich das LOG-File generell auskommentiert habe ist am Anfang - nach der Aktivierung des LOGs - dann noch etwas mehr zu lesen.
Sehr gerne würde ich auf Dein Angebot einer Skype Session zurück kommen. Teamviewer wäre bei mir auch am Start. Alles Weitere kommt dann per PM.
Vielen Dank vorab.
LG Sprudelverduenner
Hi,
ich habe jetzt auch mal ein bisschen damit herumgespielt. Tatsächlich kommt auch nur ein Kanal an, wenn man die zwei Knöpfe oben auf dem Teil gleichzeitig drückt. Dagegen kommen beide an, wenn man die Knöpfe schnell hintereinander drückt. Das finde ich zwar etwas seltsam, aber ich hab's bestimmt 100 mal ausprobiert.
Mit dieser Erkenntnis habe ich dann auch herausgefunden, dass folgender eigentlich ganz einfacher Workaround funktioniert.
Mach mal im Kanal "get ... peersettings <peer>". Als <peer> wählst Du den zweiten Aktor am problematischen Device aus.
Dort setzt Du dann "short_ondelay_time" und "short_offdelay_time" jeweils auf 0.20 s. (0.10 reicht nicht, das habe ich ausprobiert.)
Dann unten "Save Settings" drücken oder einfach <return>.
Jetzt geht die zweite Lampe 0.2s nach der ersten an und die Rückmeldungen kommen beide.
So, das zur Theorie. Blöderweise habe ich in einer der letzten Änderungen einen Fehler gemacht, so dass Kanal- und Verknüpfungsparameter unter Umständen nicht änderbar sind. Sollte das bei Dir der Fall sein, dann brauchst Du die aktuelle dev-Version. Siehe auch hier:
http://forum.fhem.de/index.php/topic,10607.msg364510.html#msg364510 (http://forum.fhem.de/index.php/topic,10607.msg364510.html#msg364510)
Gruß,
Thorsten
Hallo Thorsten,
vielen Dank für Deine Rückmeldung.
Ich habe das gestern mal auf die Schnelle getestet - Dein Tipp sieht ganz gut aus.
Ich habe die Verzögerung bei mir auf 0,30 hochgestellt - darunter kam es bei mir noch zu falschen STATEs.
Seit dem hatte ich bei meinen ersten Tests zuverlässige Ergebnisse.
Eine Sache ist mir noch aufgefallen:
Ich arbeite seit Längerem mit einem DOIF, das die Leuchte 3 ausschaltet, wenn Leuchte 1,2 und 4 aus sind.
Bis vor ca. 2 Monaten funktionierte dies auch. Ich habe seitdem - bis auf deine Firmwares - nichts verändert.
Manchmal geht die Leuchte 3 aber sofort nach dem Einschalten der Leuchten 1 und 2 direkt wieder aus.
Gestern ist mir wahrscheinlich auch aufgefallen warum:
Der STATE beider Ausgänge ist ON aber das Reading des State in der DOIF ist off.
Kann das sein- oder bin ich auf einer falschen Fährte ? Könntest Du Dir das bitte einmal anschauen ??
Lieben Gruß
Sprudelverduenner
Hi,
mit dem DOIF kenne ich micht nicht aus. Mir ist das Teil etwas suspekt und ich verwende es nicht.
Da müsstest Du vielleicht mal einen anderen Thread aufmachen, so dass sich das mal jemand anschaut, der sich mit DOIF auskennt.
Gruß,
Thorsten
OK, dass heisst die dort erscheinenden Readings von dem STATE der Wired Komponente hat nix mit Deiner Programmierung zu tun ... !?
Ich werde das mal mit 2-3 notifys aufbauen und testen.
Ich denke ich bin jetzt nicht mehr weit von einer vernünftig funktionierenden Lösung entfernt ;-):
Gruß Sprudelverduenner
Zitat von: sprudelverduenner am 26 November 2015, 16:29:38
OK, dass heisst die dort erscheinenden Readings von dem STATE der Wired Komponente hat nix mit Deiner Programmierung zu tun ... !?
Naja, zumindest nicht direkt. Ich weiß nicht, wie das DOIF auf Readings oder anderes zugreift. (Außerdem: Auf STATE greift es hoffentlich gar nicht zu, das ist nämlich ein Internal. Es müsste das Reading state sein.)
Ich wundere mich auch darüber, dass es im DOIF überhaupt ein Reading on/off gibt. Ist ein DOIF nicht nur ein Helper-Modul? Oder setzt Du den Status (also das Reading state) im DOIF selbst?
Eigentlich wollte ich mich mit dem DOIF nicht auseinandersetzen, aber Du kannst es ja mal hier posten. Vielleicht fällt mir was auf.
Gruß,
Thorsten