Rollo fährt gelegentlich nicht hoch, HM-Aktor ignoriert Befehl
1,502 views
Skip to first unread message
kossmann
Dec 13, 2012, 4:11:44 AM12/13/12
to fhem-...@googlegroups.com
Hallo zusammen,
nach knapp 2 Wochen Betrieb eines HM-LC-BI1PBU-FM Rollladenaktors in Verbindung mit FHEM auf einem Debian-Server und CUL, habe ich festgestellt, dass der Aktor die Befehle gelegentlich nicht ausführt... und ich frage mich warum.
Eine halbe Stunde vor Sonnenuntergang soll das Rollo nach unten fahren, was gestern auch wunderbar funktioniert hat:
Wenn ich dies richtig interpretiere, erhält der Aktor den Befehl "set unten", er akzeptiert dies, meldet dass er momentan "oben" ist, setzten den Motor in Richtung "down" in Betrieb, meldet nochmals, dass er "oben" ist, meldet 25 Sekunden später, dass er "unten" ist, der Motor "stoppt" und dann, dass er endgültig "unten" ist.
Heute früh sollte er um 07:15 Uhr nach oben fahren:
Der Aktor bekommt den Befehl "set oben" und akzeptiert dies auch. Er meldet, dass er unten ist, gibt dann aber kein "motor up", folglich kein "stop". Die endgültige Position wird mit "unten" statt "oben" angegeben.
Nachdem man sich dann aus dem Bett bewegt, das Problem vor sich sieht und den Aktor manuell betätigt um das Rollo nach oben zu fahren, funktioniert es:
Die Frage, die sich mir nun stellt... Warum hat die Automatik nicht funktioniert?
Definiert ist der Aktor und die Automatik wie folgt:
Danke!
nach knapp 2 Wochen Betrieb eines HM-LC-BI1PBU-FM Rollladenaktors in Verbindung mit FHEM auf einem Debian-Server und CUL, habe ich festgestellt, dass der Aktor die Befehle gelegentlich nicht ausführt... und ich frage mich warum.
Eine halbe Stunde vor Sonnenuntergang soll das Rollo nach unten fahren, was gestern auch wunderbar funktioniert hat:
2012-12-12_16:37:05 Schlafzimmer_Rollo set_unten
2012-12-12_16:37:05 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-12_16:37:05 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-12_16:37:05 Schlafzimmer_Rollo motor: down:oben
2012-12-12_16:37:05 Schlafzimmer_Rollo oben
2012-12-12_16:37:30 Schlafzimmer_Rollo deviceMsg: unten (to MyCUL)
2012-12-12_16:37:30 Schlafzimmer_Rollo motor: stop:unten
2012-12-12_16:37:30 Schlafzimmer_Rollo unten
2012-12-12_16:37:05 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-12_16:37:05 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-12_16:37:05 Schlafzimmer_Rollo motor: down:oben
2012-12-12_16:37:05 Schlafzimmer_Rollo oben
2012-12-12_16:37:30 Schlafzimmer_Rollo deviceMsg: unten (to MyCUL)
2012-12-12_16:37:30 Schlafzimmer_Rollo motor: stop:unten
2012-12-12_16:37:30 Schlafzimmer_Rollo unten
Wenn ich dies richtig interpretiere, erhält der Aktor den Befehl "set unten", er akzeptiert dies, meldet dass er momentan "oben" ist, setzten den Motor in Richtung "down" in Betrieb, meldet nochmals, dass er "oben" ist, meldet 25 Sekunden später, dass er "unten" ist, der Motor "stoppt" und dann, dass er endgültig "unten" ist.
Heute früh sollte er um 07:15 Uhr nach oben fahren:
2012-12-13_07:15:00 Schlafzimmer_Rollo set_oben
2012-12-13_07:15:02 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-13_07:15:02 Schlafzimmer_Rollo deviceMsg: unten (to MyCUL)
2012-12-13_07:15:02 Schlafzimmer_Rollo motor: stop:unten
2012-12-13_07:15:02 Schlafzimmer_Rollo unten
2012-12-13_07:15:02 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-13_07:15:02 Schlafzimmer_Rollo deviceMsg: unten (to MyCUL)
2012-12-13_07:15:02 Schlafzimmer_Rollo motor: stop:unten
2012-12-13_07:15:02 Schlafzimmer_Rollo unten
Der Aktor bekommt den Befehl "set oben" und akzeptiert dies auch. Er meldet, dass er unten ist, gibt dann aber kein "motor up", folglich kein "stop". Die endgültige Position wird mit "unten" statt "oben" angegeben.
Nachdem man sich dann aus dem Bett bewegt, das Problem vor sich sieht und den Aktor manuell betätigt um das Rollo nach oben zu fahren, funktioniert es:
2012-12-13_07:26:08 Schlafzimmer_Rollo deviceMsg: 10.5 % (to MyCUL)
2012-12-13_07:26:08 Schlafzimmer_Rollo motor: up:10.5 %
2012-12-13_07:26:08 Schlafzimmer_Rollo 10.5 %
2012-12-13_07:26:34 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-13_07:26:34 Schlafzimmer_Rollo motor: stop:oben
2012-12-13_07:26:34 Schlafzimmer_Rollo oben
2012-12-13_07:26:08 Schlafzimmer_Rollo motor: up:10.5 %
2012-12-13_07:26:08 Schlafzimmer_Rollo 10.5 %
2012-12-13_07:26:34 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-13_07:26:34 Schlafzimmer_Rollo motor: stop:oben
2012-12-13_07:26:34 Schlafzimmer_Rollo oben
Die Frage, die sich mir nun stellt... Warum hat die Automatik nicht funktioniert?
Definiert ist der Aktor und die Automatik wie folgt:
define Schlafzimmer_Rollo CUL_HM 1BCD29
attr Schlafzimmer_Rollo devInfo 010100
attr Schlafzimmer_Rollo eventMap on:oben off:unten
attr Schlafzimmer_Rollo firmware 2.1
attr Schlafzimmer_Rollo hmClass receiver
attr Schlafzimmer_Rollo model HM-LC-Bl1PBU-FM
attr Schlafzimmer_Rollo room Schlafzimmer
attr Schlafzimmer_Rollo serialNr JEQ011xxxx
attr Schlafzimmer_Rollo subType blindActuator
define Schlafzimmer_Rollo_FileLog FileLog ./log/Schlafzimmer_Rollo.log Schlafzimmer_Rollo
attr Schlafzimmer_Rollo_FileLog logtype text
attr Schlafzimmer_Rollo_FileLog room Logfiles
define Schlafzimmer_Rollo_hoch at *07:15 { if (!($we)) { fhem("set Schlafzimmer_Rollo oben");; } }
attr Schlafzimmer_Rollo_hoch room Schlafzimmer
define Schlafzimmer_Rollo_runter at *{sunset(-1800,"16:30","21:00")} set Schlafzimmer_Rollo unten
attr Schlafzimmer_Rollo_runter room Schlafzimmer
Hat einer von euch eine Idee? Gestern hat das Hochfahren beispielsweise problemlos funktioniert, was mich noch weiter verwirrt:attr Schlafzimmer_Rollo devInfo 010100
attr Schlafzimmer_Rollo eventMap on:oben off:unten
attr Schlafzimmer_Rollo firmware 2.1
attr Schlafzimmer_Rollo hmClass receiver
attr Schlafzimmer_Rollo model HM-LC-Bl1PBU-FM
attr Schlafzimmer_Rollo room Schlafzimmer
attr Schlafzimmer_Rollo serialNr JEQ011xxxx
attr Schlafzimmer_Rollo subType blindActuator
define Schlafzimmer_Rollo_FileLog FileLog ./log/Schlafzimmer_Rollo.log Schlafzimmer_Rollo
attr Schlafzimmer_Rollo_FileLog logtype text
attr Schlafzimmer_Rollo_FileLog room Logfiles
define Schlafzimmer_Rollo_hoch at *07:15 { if (!($we)) { fhem("set Schlafzimmer_Rollo oben");; } }
attr Schlafzimmer_Rollo_hoch room Schlafzimmer
define Schlafzimmer_Rollo_runter at *{sunset(-1800,"16:30","21:00")} set Schlafzimmer_Rollo unten
attr Schlafzimmer_Rollo_runter room Schlafzimmer
2012-12-12_07:15:00 Schlafzimmer_Rollo set_oben
2012-12-12_07:15:00 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-12_07:15:00 Schlafzimmer_Rollo deviceMsg: unten (to MyCUL)
2012-12-12_07:15:00 Schlafzimmer_Rollo motor: up:unten
2012-12-12_07:15:00 Schlafzimmer_Rollo unten
2012-12-12_07:15:29 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-12_07:15:29 Schlafzimmer_Rollo motor: stop:oben
2012-12-12_07:15:29 Schlafzimmer_Rollo oben
2012-12-12_07:15:00 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-12_07:15:00 Schlafzimmer_Rollo deviceMsg: unten (to MyCUL)
2012-12-12_07:15:00 Schlafzimmer_Rollo motor: up:unten
2012-12-12_07:15:00 Schlafzimmer_Rollo unten
2012-12-12_07:15:29 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-12_07:15:29 Schlafzimmer_Rollo motor: stop:oben
2012-12-12_07:15:29 Schlafzimmer_Rollo oben
Danke!
Martin
Dec 13, 2012, 4:16:05 PM12/13/12
to fhem-...@googlegroups.com
Hallo kossmann
der Ablauf ist:
FHEM sendet das kommando
der Aktor schick ein ACK mit statusInfo. ACKs gehen immer zum Auftraggebner (hier fhem) Zu diesem zeitpunkt ist der Motor in fahrt und der Rollo noch open
Nachdem ruhe eingekehrt ist (hier Rollo Unten) wird an die Zentrale eine InfoStatus gesendet (also auch an FHEM).
Aufbau und inhalt der beiden Messages ist faktisch identisch - ziel und grund sind unterschiedlich Daher kommen alle events 2 mal.
Zu den events:
die events ohne 'Namen' gehören zum 'State' - state wird unterdrückt (FHEM basics). set_... bedeuted, dass ein Kommando abgesendt wurde, aber eben noch nicht bestätigt wurde.
mit dem ACK wird dann auch die deviceMsg gesetzt. Inhalt ist das gleiche wir in state, also eigentlich doppelt. Einige User hatten Probleme mit state, da dies nicht im event angezeigt wird und somit das Parsen schwierig ist. Ich hatte es schon einmal entfernt - musste es aber wieder einbauen.
Der 3. Event beschreibt die Aktivitaet des Motor. In einer Info_Status sollte er immer stop sein, da normal nur ruhezustaende gemeldet werden. Du kannst in der Ersten erkennen, dass das Rollo oben, aber der Motor in fahrt ist. nach 25 sec stoppt der Motor (oder genauer: der Aktor treibt ihn nicht mehr an - mit der endstellung hat es nur indirekt zu tun).
Wie haeufig hast du das Problem? Kommt es immer oder nur manchmal?
Kannst du einmal ein paar tests machen mit set oben, set unten und die messages aufzeichnen?
Messages mit
attr global verbose 1
attr global mseclog 1
attr <hmlan> loglevel 1
Evtl kannst du dies auch ueber nacht machen und die Logs posten - falls de Fehler auftritt
Gruss
Martin
Eine halbe Stunde vor Sonnenuntergang soll das Rollo nach unten fahren, was gestern auch wunderbar funktioniert hat:2012-12-12_16:37:05 Schlafzimmer_Rollo set_unten
2012-12-12_16:37:05 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-12_16:37:05 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-12_16:37:05 Schlafzimmer_Rollo motor: down:oben
2012-12-12_16:37:05 Schlafzimmer_Rollo oben
2012-12-12_16:37:30 Schlafzimmer_Rollo deviceMsg: unten (to MyCUL)
2012-12-12_16:37:30 Schlafzimmer_Rollo motor: stop:unten
2012-12-12_16:37:30 Schlafzimmer_Rollo unten
Wenn ich dies richtig interpretiere, erhält der Aktor den Befehl "set unten", er akzeptiert dies, meldet dass er momentan "oben" ist, setzten den Motor in Richtung "down" in Betrieb, meldet nochmals, dass er "oben" ist, meldet 25 Sekunden später, dass er "unten" ist, der Motor "stoppt" und dann, dass er endgültig "unten" ist.
der Ablauf ist:
FHEM sendet das kommando
der Aktor schick ein ACK mit statusInfo. ACKs gehen immer zum Auftraggebner (hier fhem) Zu diesem zeitpunkt ist der Motor in fahrt und der Rollo noch open
Nachdem ruhe eingekehrt ist (hier Rollo Unten) wird an die Zentrale eine InfoStatus gesendet (also auch an FHEM).
Aufbau und inhalt der beiden Messages ist faktisch identisch - ziel und grund sind unterschiedlich Daher kommen alle events 2 mal.
Zu den events:
die events ohne 'Namen' gehören zum 'State' - state wird unterdrückt (FHEM basics). set_... bedeuted, dass ein Kommando abgesendt wurde, aber eben noch nicht bestätigt wurde.
mit dem ACK wird dann auch die deviceMsg gesetzt. Inhalt ist das gleiche wir in state, also eigentlich doppelt. Einige User hatten Probleme mit state, da dies nicht im event angezeigt wird und somit das Parsen schwierig ist. Ich hatte es schon einmal entfernt - musste es aber wieder einbauen.
Der 3. Event beschreibt die Aktivitaet des Motor. In einer Info_Status sollte er immer stop sein, da normal nur ruhezustaende gemeldet werden. Du kannst in der Ersten erkennen, dass das Rollo oben, aber der Motor in fahrt ist. nach 25 sec stoppt der Motor (oder genauer: der Aktor treibt ihn nicht mehr an - mit der endstellung hat es nur indirekt zu tun).
Heute früh sollte er um 07:15 Uhr nach oben fahren:2012-12-13_07:15:00 Schlafzimmer_Rollo set_oben
2012-12-13_07:15:02 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-13_07:15:02 Schlafzimmer_Rollo deviceMsg: unten (to MyCUL)
2012-12-13_07:15:02 Schlafzimmer_Rollo motor: stop:unten
2012-12-13_07:15:02 Schlafzimmer_Rollo unten
Der Aktor bekommt den Befehl "set oben" und akzeptiert dies auch. Er meldet, dass er unten ist, gibt dann aber kein "motor up", folglich kein "stop". Die endgültige Position wird mit "unten" statt "oben" angegeben.
das verstehe ich nicht. dazu haette ich gerne logs gesehen - siehe unten
Nachdem man sich dann aus dem Bett bewegt, das Problem vor sich sieht und den Aktor manuell betätigt um das Rollo nach oben zu fahren, funktioniert es:2012-12-13_07:26:08 Schlafzimmer_Rollo deviceMsg: 10.5 % (to MyCUL)
2012-12-13_07:26:08 Schlafzimmer_Rollo motor: up:10.5 %
2012-12-13_07:26:08 Schlafzimmer_Rollo 10.5 %
2012-12-13_07:26:34 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-13_07:26:34 Schlafzimmer_Rollo motor: stop:oben
2012-12-13_07:26:34 Schlafzimmer_Rollo oben
Die Frage, die sich mir nun stellt... Warum hat die Automatik nicht funktioniert?
interessant, dass der Motor auf 10.5% ist und nicht unten. War das so? Sieht aus, als ob der Motor on for 2,5sec war. Das sind etwa 10% und stimmt auch mit der Verzögerung ueberein.
Hat einer von euch eine Idee? Gestern hat das Hochfahren beispielsweise problemlos funktioniert, was mich noch weiter verwirrt:2012-12-12_07:15:00 Schlafzimmer_Rollo set_oben
2012-12-12_07:15:00 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-12_07:15:00 Schlafzimmer_Rollo deviceMsg: unten (to MyCUL)
2012-12-12_07:15:00 Schlafzimmer_Rollo motor: up:unten
2012-12-12_07:15:00 Schlafzimmer_Rollo unten
2012-12-12_07:15:29 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-12_07:15:29 Schlafzimmer_Rollo motor: stop:oben
2012-12-12_07:15:29 Schlafzimmer_Rollo oben
Wie haeufig hast du das Problem? Kommt es immer oder nur manchmal?
Kannst du einmal ein paar tests machen mit set oben, set unten und die messages aufzeichnen?
Messages mit
attr global verbose 1
attr global mseclog 1
attr <hmlan> loglevel 1
Evtl kannst du dies auch ueber nacht machen und die Logs posten - falls de Fehler auftritt
Gruss
Martin
kossmann
Dec 14, 2012, 4:11:19 AM12/14/12
to fhem-...@googlegroups.com
Wie oft das Problem auftritt, kann ich noch nicht wirklich sagen. Das ganze System existiert ja erst seit knapp 2 Wochen und währenddessen spiele ich natürlich viel an der Konfiguration herum (Intertechno-Schalter, Floorplan, ...), wobei "Schlafzimmer_Rollo" unangetastet bleibt. FHEM wird dabei allerdings mehrmals am Tag neu gestartet.
Heute früh trat das Problem wieder auf, eben über die Weboberfläche lief es mehrmals problemlos. Dann habe ich die Loglevel mal gesetzt und über die Weboberfläche ein "set unten" abgegeben - und es schlug (laut Logfile - kann es live nicht sehen) fehl:
Ein zweiter Versuch funktioniert dann:
Ein weiteres hoch, runter, hoch funktioniert dann problemlos.
Ich habe momentan den Verdacht, dass die FHEM-Neustarts ggf. ein Problem sein könnten, wobei in der fhem.save viele Parameter brav gespeichert werden und diese beim Start auch eingelesen wird.
Heute früh trat das Problem wieder auf, eben über die Weboberfläche lief es mehrmals problemlos. Dann habe ich die Loglevel mal gesetzt und über die Weboberfläche ein "set unten" abgegeben - und es schlug (laut Logfile - kann es live nicht sehen) fehl:
--- fhem.log ---
2012.12.14 09:58:34.841 1: CUL_HM set Schlafzimmer_Rollo off rxt:1
2012.12.14 09:58:34.842 1: SW: As0E01A0112033171BCD290201000000
2012.12.14 09:58:34.992 1: MyCUL: A0E0180021BCD292033170101C80033 -55.5
--- Schlafzimmer_Rollo.log ---
2012-12-14_09:58:34 Schlafzimmer_Rollo set_unten
2012-12-14_09:58:34 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-14_09:58:35 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-14_09:58:35 Schlafzimmer_Rollo motor: stop:oben
2012-12-14_09:58:35 Schlafzimmer_Rollo oben
2012.12.14 09:58:34.841 1: CUL_HM set Schlafzimmer_Rollo off rxt:1
2012.12.14 09:58:34.842 1: SW: As0E01A0112033171BCD290201000000
2012.12.14 09:58:34.992 1: MyCUL: A0E0180021BCD292033170101C80033 -55.5
--- Schlafzimmer_Rollo.log ---
2012-12-14_09:58:34 Schlafzimmer_Rollo set_unten
2012-12-14_09:58:34 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-14_09:58:35 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-14_09:58:35 Schlafzimmer_Rollo motor: stop:oben
2012-12-14_09:58:35 Schlafzimmer_Rollo oben
Ein zweiter Versuch funktioniert dann:
--- fhem.log ---
2012.12.14 10:03:58.437 1: CUL_HM set Schlafzimmer_Rollo off rxt:1
2012.12.14 10:03:58.437 1: SW: As0E02A0112033171BCD290201000000
2012.12.14 10:03:58.591 1: MyCUL: A0E0280021BCD292033170101C82034 -57.5
2012.12.14 10:04:23.603 1: MyCUL: A0D03A4101BCD2920331706010000 -55.5
2012.12.14 10:04:23.698 1: SW: As0A0380022033171BCD2900
--- Schlafzimmer_Rollo.log ---
2012-12-14_10:03:58 Schlafzimmer_Rollo set_unten
2012-12-14_10:03:58 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-14_10:03:58 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-14_10:03:58 Schlafzimmer_Rollo motor: down:oben
2012-12-14_10:03:58 Schlafzimmer_Rollo oben
2012-12-14_10:04:23 Schlafzimmer_Rollo deviceMsg: unten (to MyCUL)
2012-12-14_10:04:23 Schlafzimmer_Rollo motor: stop:unten
2012-12-14_10:04:23 Schlafzimmer_Rollo unten
2012.12.14 10:03:58.437 1: CUL_HM set Schlafzimmer_Rollo off rxt:1
2012.12.14 10:03:58.437 1: SW: As0E02A0112033171BCD290201000000
2012.12.14 10:03:58.591 1: MyCUL: A0E0280021BCD292033170101C82034 -57.5
2012.12.14 10:04:23.603 1: MyCUL: A0D03A4101BCD2920331706010000 -55.5
2012.12.14 10:04:23.698 1: SW: As0A0380022033171BCD2900
--- Schlafzimmer_Rollo.log ---
2012-12-14_10:03:58 Schlafzimmer_Rollo set_unten
2012-12-14_10:03:58 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-14_10:03:58 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-14_10:03:58 Schlafzimmer_Rollo motor: down:oben
2012-12-14_10:03:58 Schlafzimmer_Rollo oben
2012-12-14_10:04:23 Schlafzimmer_Rollo deviceMsg: unten (to MyCUL)
2012-12-14_10:04:23 Schlafzimmer_Rollo motor: stop:unten
2012-12-14_10:04:23 Schlafzimmer_Rollo unten
Ein weiteres hoch, runter, hoch funktioniert dann problemlos.
Ich habe momentan den Verdacht, dass die FHEM-Neustarts ggf. ein Problem sein könnten, wobei in der fhem.save viele Parameter brav gespeichert werden und diese beim Start auch eingelesen wird.
Martin
Dec 14, 2012, 10:12:45 AM12/14/12
to fhem-...@googlegroups.com
Hallo kossmann,
die messages sind komplett und korrekt. Aus irgendwelchen Gruenden fuehrt der Motor nicht, daher kommt auch keine 2. Message, das sich der Status nicht geaendert hat.
Ich werde einmal eine Version liefern in der ein unbenutzter Parameter nicht mehr uebertragen wird - evtl hat es etwas damit zu tun.
Ansonsten - willst du die register auslesen? Voher die Internal Keys visible setzen, dann lesen und mir schicken
Gruss
Martin
die messages sind komplett und korrekt. Aus irgendwelchen Gruenden fuehrt der Motor nicht, daher kommt auch keine 2. Message, das sich der Status nicht geaendert hat.
Ich werde einmal eine Version liefern in der ein unbenutzter Parameter nicht mehr uebertragen wird - evtl hat es etwas damit zu tun.
Ansonsten - willst du die register auslesen? Voher die Internal Keys visible setzen, dann lesen und mir schicken
Gruss
Martin
kossmann
Dec 14, 2012, 10:17:09 AM12/14/12
to fhem-...@googlegroups.com
Hallo Martin,
ich mache alles, was der Sache und dem Projekt dienlich ist - und sich von mir realisieren lässt ;-)
Wenn die Register helfen, lese ich sie gerne aus und poste sie hier. Du müsstest mir nur kurz erklären, was ich machen muss.
Ich habe im Aktor nur Werte für driveUp (24), driveDown (22.5) und driveTurn (0) gesetzt.
Gruß
kossmann
ich mache alles, was der Sache und dem Projekt dienlich ist - und sich von mir realisieren lässt ;-)
Wenn die Register helfen, lese ich sie gerne aus und poste sie hier. Du müsstest mir nur kurz erklären, was ich machen muss.
Ich habe im Aktor nur Werte für driveUp (24), driveDown (22.5) und driveTurn (0) gesetzt.
Gruß
kossmann
Martin
Dec 15, 2012, 5:19:41 AM12/15/12
to fhem-...@googlegroups.com
1) lesen der register
1a) sichtbar machen der internen Schalterlinks
set <actor> regSet intKeyVisib 1
1b) auslesen
set <actor> getConfig
1c) infos posten
- entweder die Messages aufzeichnen oder die daten mit list <aktor> auslesen und posten
2) kommando veraendern - ramp time ignorieren
a) ersetze dein Kommando off gegen
set <actor> raw ++A0112033171BCD29020100
b) ersetze dein Kommando on gegen
set <actor> raw ++A0112033171BCD290201C8
Wenn dies klappt werden ich den überflüssigen Parameter entfernen. Ich kann es aktuell nur schlecht, da ich nicht weiss, wer den eingebaut hat, warum und ob es devices gibt,die es brauchen
Ansonsten koennen wir noch mit ontime experimentieren... und mit virtuellen schaltern. Also wenn es nicht klappt gibt es noch mindestens 2 optionen. Und 3. noch das 'tunen' der Statemachine...
aber erst einmal langsam anfangen
Gruss
Martin
1a) sichtbar machen der internen Schalterlinks
set <actor> regSet intKeyVisib 1
1b) auslesen
set <actor> getConfig
1c) infos posten
- entweder die Messages aufzeichnen oder die daten mit list <aktor> auslesen und posten
2) kommando veraendern - ramp time ignorieren
a) ersetze dein Kommando off gegen
set <actor> raw ++A0112033171BCD29020100
b) ersetze dein Kommando on gegen
set <actor> raw ++A0112033171BCD290201C8
Wenn dies klappt werden ich den überflüssigen Parameter entfernen. Ich kann es aktuell nur schlecht, da ich nicht weiss, wer den eingebaut hat, warum und ob es devices gibt,die es brauchen
Ansonsten koennen wir noch mit ontime experimentieren... und mit virtuellen schaltern. Also wenn es nicht klappt gibt es noch mindestens 2 optionen. Und 3. noch das 'tunen' der Statemachine...
aber erst einmal langsam anfangen
Gruss
Martin
kossmann
Dec 15, 2012, 10:49:14 AM12/15/12
to fhem-...@googlegroups.com
Hallo Martin,
ich habe gewartet, bis das Rollo eben automatisch herunter gefahren ist. Am ersten Punkt scheint allerdings schon etwas nicht zu stimmen:
Ich habe es dann einfach mal mit visib probiert:
Danach ging´s wie folgt weiter:
eventMap on:oben off:unten
Reicht das oder fehlen noch Infos (da set Schlafzimmer_Rollo regSet visib 1 nicht ausreichend war)?
Mit Punkt 2 meinst du den at-Job, in dem ich morgens hoch und abends runter fahre, oder?
Was meinst du die ganze Zeit mit "überflüssige/ungenutzte Parameter"?
Ich Danke dir auf jeden Fall für die Unterstützung!
ich habe gewartet, bis das Rollo eben automatisch herunter gefahren ist. Am ersten Punkt scheint allerdings schon etwas nicht zu stimmen:
set Schlafzimmer_Rollo regSet intKeyVisib 1
invalid value. use:visib,invisib
invalid value. use:visib,invisib
Ich habe es dann einfach mal mit visib probiert:
set Schlafzimmer_Rollo regSet visib 1
supported register are LgBlJtDlyOff LgBlJtDlyOn LgBlJtOff LgBlJtOn LgBlJtRampOff LgBlJtRampOn LgBlJtRefOff LgBlJtRefOn LgCtDlyOff LgCtDlyOn LgCtOff LgCtOn LgCtRampOff LgCtRampOn LgOffDly LgOffLevel LgOffTime LgOffTimeMode LgOnDly LgOnLevel LgOnTime LgOnTimeMode LgactionType LgdriveMode LgmaxTimeF ShBlJtDlyOff ShBlJtDlyOn ShBlJtOff ShBlJtOn ShBlJtRampOff ShBlJtRampOn ShBlJtRefOff ShBlJtRefOn ShCtDlyOff ShCtDlyOn ShCtOff ShCtOn ShCtRampOff ShCtRampOn ShOffDly ShOffLevel ShOffTime ShOffTimeMode ShOnDly ShOnLevel ShOnTime ShOnTimeMode ShactionType ShdriveMode ShmaxTimeF driveDown driveTurn driveUp intKeyVisib pairCentral
supported register are LgBlJtDlyOff LgBlJtDlyOn LgBlJtOff LgBlJtOn LgBlJtRampOff LgBlJtRampOn LgBlJtRefOff LgBlJtRefOn LgCtDlyOff LgCtDlyOn LgCtOff LgCtOn LgCtRampOff LgCtRampOn LgOffDly LgOffLevel LgOffTime LgOffTimeMode LgOnDly LgOnLevel LgOnTime LgOnTimeMode LgactionType LgdriveMode LgmaxTimeF ShBlJtDlyOff ShBlJtDlyOn ShBlJtOff ShBlJtOn ShBlJtRampOff ShBlJtRampOn ShBlJtRefOff ShBlJtRefOn ShCtDlyOff ShCtDlyOn ShCtOff ShCtOn ShCtRampOff ShCtRampOn ShOffDly ShOffLevel ShOffTime ShOffTimeMode ShOnDly ShOnLevel ShOnTime ShOnTimeMode ShactionType ShdriveMode ShmaxTimeF driveDown driveTurn driveUp intKeyVisib pairCentral
Danach ging´s wie folgt weiter:
set Schlafzimmer_Rollo getConfig
list Schlafzimmer_Rollo
Internals:
CFGFN user_schlafzimmer.cfg
DEF 1BCD29
IODev MyCUL
LASTIODev MyCUL
MSGCNT 22
MyCUL_MSGCNT 22
MyCUL_RAWMSG A0E17A0101BCD29203317010000000027
MyCUL_RSSI -54.5
MyCUL_TIME 2012-12-15 16:41:39
NAME Schlafzimmer_Rollo
NR 86
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:17 - t:10 s:1BCD29 d:203317 0100000000
protLastRcv 2012-12-15 16:41:39
protResnd 1 last_at:2012-12-15 16:37:38
protSnd 10 last_at:2012-12-15 16:41:39
protState CMDs_done_events:1
protToutResp 1 last_at:2012-12-15 16:41:41
Readings:
2012-12-15 16:37:38 CommandAccepted yes
2012-12-15 16:41:39 PairedTo 0x203317
2012-12-15 16:41:39 RegL_00: 02:01 0A:20 0B:33 0C:17 15:FF 00:00
2012-12-15 16:38:02 deviceMsg off (to MyCUL)
2012-12-15 16:38:02 motor stop:off
2012-12-10 09:06:27 peerList
2012-12-15 16:41:41 state RESPONSE TIMEOUT:RegisterRead
Regl_01::
VAL
Helper:
addVal 0
burstEvtCnt 2
mId 006A
rxType 1
Shadowreg:
Attributes:
devInfo 010100
list Schlafzimmer_Rollo
Internals:
CFGFN user_schlafzimmer.cfg
DEF 1BCD29
IODev MyCUL
LASTIODev MyCUL
MSGCNT 22
MyCUL_MSGCNT 22
MyCUL_RAWMSG A0E17A0101BCD29203317010000000027
MyCUL_RSSI -54.5
MyCUL_TIME 2012-12-15 16:41:39
NAME Schlafzimmer_Rollo
NR 86
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:17 - t:10 s:1BCD29 d:203317 0100000000
protLastRcv 2012-12-15 16:41:39
protResnd 1 last_at:2012-12-15 16:37:38
protSnd 10 last_at:2012-12-15 16:41:39
protState CMDs_done_events:1
protToutResp 1 last_at:2012-12-15 16:41:41
Readings:
2012-12-15 16:37:38 CommandAccepted yes
2012-12-15 16:41:39 PairedTo 0x203317
2012-12-15 16:41:39 RegL_00: 02:01 0A:20 0B:33 0C:17 15:FF 00:00
2012-12-15 16:38:02 deviceMsg off (to MyCUL)
2012-12-15 16:38:02 motor stop:off
2012-12-10 09:06:27 peerList
2012-12-15 16:41:41 state RESPONSE TIMEOUT:RegisterRead
Regl_01::
VAL
Helper:
addVal 0
burstEvtCnt 2
mId 006A
rxType 1
Shadowreg:
Attributes:
devInfo 010100
eventMap on:oben off:unten
firmware 2.1
fp_Grundriss 562,517,0
hmClass receiver
loglevel 1
model HM-LC-Bl1PBU-FM
peerIDs
room Schlafzimmer
serialNr JEQ0116690
subType blindActuator
fp_Grundriss 562,517,0
hmClass receiver
loglevel 1
model HM-LC-Bl1PBU-FM
peerIDs
room Schlafzimmer
serialNr JEQ0116690
subType blindActuator
Reicht das oder fehlen noch Infos (da set Schlafzimmer_Rollo regSet visib 1 nicht ausreichend war)?
Mit Punkt 2 meinst du den at-Job, in dem ich morgens hoch und abends runter fahre, oder?
Was meinst du die ganze Zeit mit "überflüssige/ungenutzte Parameter"?
Ich Danke dir auf jeden Fall für die Unterstützung!
Martin
Dec 15, 2012, 6:58:30 PM12/15/12
to fhem-...@googlegroups.com
Am Samstag, 15. Dezember 2012 16:49:14 UTC+1 schrieb kossmann:
Hallo Martin,
ich habe gewartet, bis das Rollo eben automatisch herunter gefahren ist. Am ersten Punkt scheint allerdings schon etwas nicht zu stimmen:set Schlafzimmer_Rollo regSet intKeyVisib 1
invalid value. use:visib,invisib
Ich habe es dann einfach mal mit visib probiert:set Schlafzimmer_Rollo regSet visib 1
sorry - mein fehler - habe ja die liternal eingebaut:
set Schlafzimmer_Rollo regSet intKeyVisib visib
==> der value ist visib/invisib. Das Registerien intKeyVisib
danach noch einmal ein getConfig.
es hat etwas nicht funktioniert - in den "prot..." kannst du ein timeout sehen. Die Register List1 sind nicht gelesen worden.
Mit Punkt 2 meinst du den at-Job, in dem ich morgens hoch und abends runter fahre, oder?
korrekt
Was meinst du die ganze Zeit mit "überflüssige/ungenutzte Parameter"?
es wird immer die ramp-time uebermittelt - ein parameter eigentlich für dimmer. Den brauchen Rollos nicht.
kossmann
Dec 16, 2012, 3:15:36 AM12/16/12
to fhem-...@googlegroups.com
Guten Morgen,
ja, jetzt sieht man schon mehr...
DEF 1BCD29
IODev MyCUL
LASTIODev MyCUL
NAME Schlafzimmer_Rollo
NR 86
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
protResnd 1 last_at:2012-12-15 16:37:38
mId 006A
rxType 1
Shadowreg:
Attributes:
devInfo 010100
room Schlafzimmer
serialNr JEQ0116690
subType blindActuator
Das Rollo wurde vorhin (ist ja Wochenende) manuell hoch gefahren. Ich warte jetzt mal den morgigen Tag ab und starte FHEM bis dahin auch nicht neu. Ich muss jetzt gleich weg, daher wird´s heute sowieso nichts mehr mit weiter Testen.
ja, jetzt sieht man schon mehr...
Internals:
CFGFN user_schlafzimmer.cfg
CHANGED
CFGFN user_schlafzimmer.cfg
CHANGED
DEF 1BCD29
IODev MyCUL
LASTIODev MyCUL
MSGCNT 41
MyCUL_MSGCNT 41
MyCUL_RAWMSG A0C2BA0101BCD2920331703000022
MyCUL_RSSI -57
MyCUL_TIME 2012-12-16 09:13:40
MyCUL_MSGCNT 41
MyCUL_RAWMSG A0C2BA0101BCD2920331703000022
MyCUL_RSSI -57
MyCUL_TIME 2012-12-16 09:13:40
NAME Schlafzimmer_Rollo
NR 86
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:2B - t:10 s:1BCD29 d:203317 030000
protLastRcv 2012-12-16 09:13:40
protLastRcv 2012-12-16 09:13:40
protResnd 1 last_at:2012-12-15 16:37:38
protSnd 21 last_at:2012-12-16 09:13:38
protState CMDs_done_events:1
protToutResp 2 last_at:2012-12-16 09:13:38
Readings:
2012-12-16 09:13:17 CommandAccepted yes
2012-12-16 09:13:35 PairedTo 0x203317
2012-12-16 09:13:36 R-driveDown 20.7 s
2012-12-16 09:13:36 R-driveTurn 0 s
2012-12-16 09:13:36 R-driveUp 24 s
2012-12-16 09:13:40 R-self02-LgOffLevel 0 %
2012-12-16 09:13:40 R-self02-LgOnLevel 100 %
2012-12-16 09:13:40 R-self02-ShOffLevel 0 %
2012-12-16 09:13:40 R-self02-ShOnLevel 100 %
2012-12-16 09:13:35 RegL_00: 02:80 0A:20 0B:33 0C:17 15:FF 00:00
2012-12-16 09:13:36 RegL_01: 08:00 09:00 0A:00 0B:00 0C:CF 0D:00 0E:F0 0F:00 10:00 00:00
2012-12-16 09:13:40 RegL_03:self02 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:68 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:11 8C:12 8D:68 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:04 9E:68 9F:00 00:00
2012-12-16 08:45:54 deviceMsg on (to MyCUL)
2012-12-16 08:45:54 motor stop:on
2012-12-16 09:13:35 peerList self01,self02,
2012-12-16 09:13:38 state RESPONSE TIMEOUT:RegisterRead
Regl_03:self01:
VAL
Helper:
addVal 0
burstEvtCnt 1
protState CMDs_done_events:1
protToutResp 2 last_at:2012-12-16 09:13:38
Readings:
2012-12-16 09:13:17 CommandAccepted yes
2012-12-16 09:13:35 PairedTo 0x203317
2012-12-16 09:13:36 R-driveDown 20.7 s
2012-12-16 09:13:36 R-driveTurn 0 s
2012-12-16 09:13:36 R-driveUp 24 s
2012-12-16 09:13:40 R-self02-LgOffLevel 0 %
2012-12-16 09:13:40 R-self02-LgOnLevel 100 %
2012-12-16 09:13:40 R-self02-ShOffLevel 0 %
2012-12-16 09:13:40 R-self02-ShOnLevel 100 %
2012-12-16 09:13:35 RegL_00: 02:80 0A:20 0B:33 0C:17 15:FF 00:00
2012-12-16 09:13:36 RegL_01: 08:00 09:00 0A:00 0B:00 0C:CF 0D:00 0E:F0 0F:00 10:00 00:00
2012-12-16 09:13:40 RegL_03:self02 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:68 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:11 8C:12 8D:68 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:04 9E:68 9F:00 00:00
2012-12-16 08:45:54 deviceMsg on (to MyCUL)
2012-12-16 08:45:54 motor stop:on
2012-12-16 09:13:35 peerList self01,self02,
2012-12-16 09:13:38 state RESPONSE TIMEOUT:RegisterRead
Regl_03:self01:
VAL
Helper:
addVal 0
burstEvtCnt 1
mId 006A
rxType 1
Shadowreg:
Attributes:
devInfo 010100
eventMap on:oben off:unten
firmware 2.1
fp_Grundriss 562,517,0
hmClass receiver
loglevel 1
model HM-LC-Bl1PBU-FM
fp_Grundriss 562,517,0
hmClass receiver
loglevel 1
model HM-LC-Bl1PBU-FM
peerIDs 1BCD2901,1BCD2902,
room Schlafzimmer
serialNr JEQ0116690
subType blindActuator
Das Rollo wurde vorhin (ist ja Wochenende) manuell hoch gefahren. Ich warte jetzt mal den morgigen Tag ab und starte FHEM bis dahin auch nicht neu. Ich muss jetzt gleich weg, daher wird´s heute sowieso nichts mehr mit weiter Testen.
Martin
Dec 16, 2012, 2:16:14 PM12/16/12
to fhem-...@googlegroups.com
Sieht fast gut aus. Es fehlt noch eine List 3 fuer den "internen channel" 01 - also self01. Es hat ja auch einen tiemout gegeben.
Evtl noch einmal das getConfig wiederholen.
Das intkeyvisib bleibt im device bis du es auf invisib setzt
Gruss
Martin
Evtl noch einmal das getConfig wiederholen.
Das intkeyvisib bleibt im device bis du es auf invisib setzt
Gruss
Martin
kossmann
Dec 16, 2012, 4:21:15 PM12/16/12
to fhem-...@googlegroups.com
Den Timeout habe ich natürlich übersehen, da ich hier zum Großteil nur Bahnhof verstehe. Momenten steht das Rollo auf "unten" und wartet sehnsüchtig auf morgen früh, 07:15 Uhr ;-) Hier die aktuellen Daten ohne Timeout:
protResnd 1 last_at:2012-12-15 16:37:38
protToutResp 2 last_at:2012-12-16 09:13:38
Readings:
2012-12-16 09:13:36 R-driveDown 20.7 s
2012-12-16 09:13:36 R-driveTurn 0 s
2012-12-16 09:13:36 R-driveUp 24 s
2012-12-16 09:13:40 R-self02-LgOffLevel 0 %
2012-12-16 09:13:40 R-self02-LgOnLevel 100 %
2012-12-16 09:13:40 R-self02-ShOffLevel 0 %
2012-12-16 09:13:40 R-self02-ShOnLevel 100 %
Internals:
CFGFN user_schlafzimmer.cfg
CHANGED
DEF 1BCD29
IODev MyCUL
LASTIODev MyCUL
CFGFN user_schlafzimmer.cfg
CHANGED
DEF 1BCD29
IODev MyCUL
LASTIODev MyCUL
MSGCNT 61
MyCUL_MSGCNT 61
MyCUL_RAWMSG A0C3FA0101BCD2920331703000025
MyCUL_RSSI -55.5
MyCUL_TIME 2012-12-16 22:18:52
NAME Schlafzimmer_Rollo
NR 86
STATE unten
TYPE CUL_HM
lastMsg No:3F - t:10 s:1BCD29 d:203317 030000
protLastRcv 2012-12-16 22:18:52
MyCUL_MSGCNT 61
MyCUL_RAWMSG A0C3FA0101BCD2920331703000025
MyCUL_RSSI -55.5
MyCUL_TIME 2012-12-16 22:18:52
NAME Schlafzimmer_Rollo
NR 86
STATE unten
TYPE CUL_HM
lastMsg No:3F - t:10 s:1BCD29 d:203317 030000
protLastRcv 2012-12-16 22:18:52
protResnd 1 last_at:2012-12-15 16:37:38
protSnd 28 last_at:2012-12-16 22:18:50
protState CMDs_done
protState CMDs_done
protToutResp 2 last_at:2012-12-16 09:13:38
Readings:
2012-12-16 16:37:51 CommandAccepted yes
2012-12-16 22:18:48 PairedTo 0x203317
2012-12-16 22:18:48 PairedTo 0x203317
2012-12-16 09:13:36 R-driveDown 20.7 s
2012-12-16 09:13:36 R-driveTurn 0 s
2012-12-16 09:13:36 R-driveUp 24 s
2012-12-16 22:18:50 R-self01-LgOffLevel 0 %
2012-12-16 22:18:50 R-self01-LgOnLevel 100 %
2012-12-16 22:18:50 R-self01-ShOffLevel 0 %
2012-12-16 22:18:50 R-self01-ShOnLevel 100 %
2012-12-16 22:18:50 R-self01-LgOnLevel 100 %
2012-12-16 22:18:50 R-self01-ShOffLevel 0 %
2012-12-16 22:18:50 R-self01-ShOnLevel 100 %
2012-12-16 09:13:40 R-self02-LgOffLevel 0 %
2012-12-16 09:13:40 R-self02-LgOnLevel 100 %
2012-12-16 09:13:40 R-self02-ShOffLevel 0 %
2012-12-16 09:13:40 R-self02-ShOnLevel 100 %
2012-12-16 22:18:48 RegL_00: 02:80 0A:20 0B:33 0C:17 15:FF 00:00
2012-12-16 22:18:49 RegL_01: 08:00 09:00 0A:00 0B:00 0C:CF 0D:00 0E:F0 0F:00 10:00 00:00
2012-12-16 22:18:50 RegL_03:self01 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:44 0C:54 0D:93 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:93 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:44 8C:54 8D:93 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:04 9E:93 9F:00 00:00
2012-12-16 22:18:52 RegL_03:self02 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:68 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:11 8C:12 8D:68 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:04 9E:68 9F:00 00:00
2012-12-16 16:38:16 deviceMsg off (to MyCUL)
2012-12-16 16:38:16 motor stop:off
2012-12-16 22:18:48 peerList self01,self02,
2012-12-16 16:38:16 state unten
Helper:
addVal 0
2012-12-16 22:18:49 RegL_01: 08:00 09:00 0A:00 0B:00 0C:CF 0D:00 0E:F0 0F:00 10:00 00:00
2012-12-16 22:18:50 RegL_03:self01 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:44 0C:54 0D:93 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:93 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:44 8C:54 8D:93 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:04 9E:93 9F:00 00:00
2012-12-16 22:18:52 RegL_03:self02 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:68 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:11 8C:12 8D:68 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:04 9E:68 9F:00 00:00
2012-12-16 16:38:16 deviceMsg off (to MyCUL)
2012-12-16 16:38:16 motor stop:off
2012-12-16 22:18:48 peerList self01,self02,
2012-12-16 16:38:16 state unten
Helper:
addVal 0
kossmann
Dec 17, 2012, 5:36:50 AM12/17/12
to fhem-...@googlegroups.com
Heute früh ist er natürlich einwandfrei automatisch nach oben gefahren - Murphy sei Dank ;-) Ich werde nachher mal gucken, ob ich den Fehler nochmal manuell provozieren kann und lese danach die Register nochmal aus.
Martin
Dec 17, 2012, 9:50:57 AM12/17/12
to fhem-...@googlegroups.com
ok - die register sind vollstaendig.
kannst du noch (wenn gelesen ist) ein get <name> reg all machen? Dann muss ich nicht so viel denken.
Was wir wissen ist, dass der Rollo manchmal nicht hoch bzw runter faehrt. Wenn wir das Problem nicht in den Griff bekommen koennen kannst du als alternative auch einen virtuellen Schalter definieren und mit deinem Rollo peeren - oder mit allen. also schematisch:
define vs xxx #virtual schalter
set vs virtual 2 # 2 buttons
rename... # falls du willst
set vs_Btn1 devicepair 0 <rollo1> dual set
set vs_Btn1 devicepair 0 <rollo2> dual set
...
set vs_Btn1 devicepair 0 <rollox> dual set
set vs_Btn1 press # zum hochfahren dann
set vs_Btn2 press # und runter (oder umgekehrt, keine Ahnung)
es sollten jeweils alle Rollos auf einmal fahren, nur ein Kommando.
kannst du noch (wenn gelesen ist) ein get <name> reg all machen? Dann muss ich nicht so viel denken.
Was wir wissen ist, dass der Rollo manchmal nicht hoch bzw runter faehrt. Wenn wir das Problem nicht in den Griff bekommen koennen kannst du als alternative auch einen virtuellen Schalter definieren und mit deinem Rollo peeren - oder mit allen. also schematisch:
define vs xxx #virtual schalter
set vs virtual 2 # 2 buttons
rename... # falls du willst
set vs_Btn1 devicepair 0 <rollo1> dual set
set vs_Btn1 devicepair 0 <rollo2> dual set
...
set vs_Btn1 devicepair 0 <rollox> dual set
set vs_Btn1 press # zum hochfahren dann
set vs_Btn2 press # und runter (oder umgekehrt, keine Ahnung)
es sollten jeweils alle Rollos auf einmal fahren, nur ein Kommando.
kossmann
Dec 17, 2012, 10:08:43 AM12/17/12
to fhem-...@googlegroups.com
Momentan habe ich nur den einen Aktor, weitere wollte ich eben bestellen, sind momentan aber für den gewünschten Preis (~43,- Euro) nicht lieferbar. Habe schon eine Angebote angefordert.
Hier die aktuellen Daten (Rollo steht oben, heute Mittag per Klick in der FHEM-Weboberfläche hoch gefahren (insgesamt 10 mal, ohne Fehler)):
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
2012-12-16 09:13:36 R-driveDown 20.7 s
2012-12-16 09:13:36 R-driveTurn 0 s
2012-12-16 09:13:36 R-driveUp 24 s
2012-12-16 22:18:50 R-self01-LgOffLevel 0 %
2012-12-16 22:18:50 R-self01-LgOnLevel 100 %
2012-12-16 22:18:50 R-self01-ShOffLevel 0 %
2012-12-16 22:18:50 R-self01-ShOnLevel 100 %
2012-12-16 09:13:40 R-self02-LgOffLevel 0 %
2012-12-16 09:13:40 R-self02-LgOnLevel 100 %
2012-12-16 09:13:40 R-self02-ShOffLevel 0 %
2012-12-16 09:13:40 R-self02-ShOnLevel 100 %
mId 006A
rxType 1
Shadowreg:
Attributes:
devInfo 010100
Hier die aktuellen Daten (Rollo steht oben, heute Mittag per Klick in der FHEM-Weboberfläche hoch gefahren (insgesamt 10 mal, ohne Fehler)):
set Schlafzimmer_Rollo getConfig
list Schlafzimmer_Rollo
list Schlafzimmer_Rollo
Internals:
CFGFN user_schlafzimmer.cfg
CHANGED
DEF 1BCD29
IODev MyCUL
LASTIODev MyCUL
CFGFN user_schlafzimmer.cfg
CHANGED
DEF 1BCD29
IODev MyCUL
LASTIODev MyCUL
MSGCNT 16
MyCUL_MSGCNT 16
MyCUL_RAWMSG A0C11A0101BCD2920331703000025
MyCUL_RSSI -55.5
MyCUL_TIME 2012-12-17 16:05:19
NAME Schlafzimmer_Rollo
NR 86
MyCUL_MSGCNT 16
MyCUL_RAWMSG A0C11A0101BCD2920331703000025
MyCUL_RSSI -55.5
MyCUL_TIME 2012-12-17 16:05:19
NAME Schlafzimmer_Rollo
NR 86
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:11 - t:10 s:1BCD29 d:203317 030000
protLastRcv 2012-12-17 16:05:19
protSnd 6 last_at:2012-12-17 16:05:17
protState CMDs_done_events:1
protToutResp 1 last_at:2012-12-17 16:05:16
Readings:
2012-12-17 13:13:37 CommandAccepted yes
2012-12-17 16:05:14 PairedTo 0x203317
protLastRcv 2012-12-17 16:05:19
protSnd 6 last_at:2012-12-17 16:05:17
protState CMDs_done_events:1
protToutResp 1 last_at:2012-12-17 16:05:16
Readings:
2012-12-17 13:13:37 CommandAccepted yes
2012-12-17 16:05:14 PairedTo 0x203317
2012-12-16 09:13:36 R-driveDown 20.7 s
2012-12-16 09:13:36 R-driveTurn 0 s
2012-12-16 09:13:36 R-driveUp 24 s
2012-12-16 22:18:50 R-self01-LgOffLevel 0 %
2012-12-16 22:18:50 R-self01-LgOnLevel 100 %
2012-12-16 22:18:50 R-self01-ShOffLevel 0 %
2012-12-16 22:18:50 R-self01-ShOnLevel 100 %
2012-12-16 09:13:40 R-self02-LgOffLevel 0 %
2012-12-16 09:13:40 R-self02-LgOnLevel 100 %
2012-12-16 09:13:40 R-self02-ShOffLevel 0 %
2012-12-16 09:13:40 R-self02-ShOnLevel 100 %
2012-12-17 16:05:14 RegL_00: 02:80 0A:20 0B:33 0C:17 15:FF 00:00
2012-12-17 16:05:17 RegL_03:self01 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:44 0C:54 0D:93 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:93 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:44 8C:54 8D:93 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:04 9E:93 9F:00 00:00
2012-12-17 16:05:19 RegL_03:self02 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:68 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:11 8C:12 8D:68 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:04 9E:68 9F:00 00:00
2012-12-17 13:14:07 deviceMsg on (to MyCUL)
2012-12-17 13:14:07 motor stop:on
2012-12-17 16:05:14 peerList self01,self02,
2012-12-17 16:05:16 state RESPONSE TIMEOUT:RegisterRead
Regl_01::
VAL
Helper:
burstEvtCnt 1
2012-12-17 16:05:17 RegL_03:self01 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:44 0C:54 0D:93 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:93 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:44 8C:54 8D:93 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:04 9E:93 9F:00 00:00
2012-12-17 16:05:19 RegL_03:self02 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:68 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:11 8C:12 8D:68 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:04 9E:68 9F:00 00:00
2012-12-17 13:14:07 deviceMsg on (to MyCUL)
2012-12-17 13:14:07 motor stop:on
2012-12-17 16:05:14 peerList self01,self02,
2012-12-17 16:05:16 state RESPONSE TIMEOUT:RegisterRead
Regl_01::
VAL
Helper:
burstEvtCnt 1
mId 006A
rxType 1
Shadowreg:
Attributes:
devInfo 010100
eventMap on:oben off:unten
firmware 2.1
fp_Grundriss 562,517,0
hmClass receiver
fp_Grundriss 562,517,0
hmClass receiver
model HM-LC-Bl1PBU-FM
peerIDs 1BCD2901,1BCD2902,
room Schlafzimmer
serialNr JEQ0116690
subType blindActuator
peerIDs 1BCD2901,1BCD2902,
room Schlafzimmer
serialNr JEQ0116690
subType blindActuator
get Schlafzimmer_Rollo reg all
Schlafzimmer_Rollo type:blindActuator -
list:peer register :value
0: intKeyVisib :visib
0: pairCentral :0x203317
3:self01 LgBlJtDlyOff :refOff
3:self01 LgBlJtDlyOn :dlyOff
3:self01 LgBlJtOff :dlyOff
3:self01 LgBlJtOn :dlyOff
3:self01 LgBlJtRampOff :rampOff
3:self01 LgBlJtRampOn :on
3:self01 LgBlJtRefOff :no
3:self01 LgBlJtRefOn :no
3:self01 LgCtDlyOff :geLo
3:self01 LgCtDlyOn :geLo
3:self01 LgCtOff :geLo
3:self01 LgCtOn :geLo
3:self01 LgCtRampOff :geLo
3:self01 LgCtRampOn :geLo
3:self01 LgOffDly :0 s
3:self01 LgOffLevel :0 %
3:self01 LgOffTime :111600 s
3:self01 LgOffTimeMode :absolut
3:self01 LgOnDly :0 s
3:self01 LgOnLevel :100 %
3:self01 LgOnTime :111600 s
3:self01 LgOnTimeMode :minimal
3:self01 LgactionType :jmpToTarget
3:self01 LgdriveMode :direct
3:self01 LgmaxTimeF :0.4 s
3:self01 ShBlJtDlyOff :refOff
3:self01 ShBlJtDlyOn :dlyOff
3:self01 ShBlJtOff :dlyOff
3:self01 ShBlJtOn :dlyOff
3:self01 ShBlJtRampOff :rampOff
3:self01 ShBlJtRampOn :on
3:self01 ShBlJtRefOff :no
3:self01 ShBlJtRefOn :no
3:self01 ShCtDlyOff :geLo
3:self01 ShCtDlyOn :geLo
3:self01 ShCtOff :geLo
3:self01 ShCtOn :geLo
3:self01 ShCtRampOff :geLo
3:self01 ShCtRampOn :geLo
3:self01 ShOffDly :0 s
3:self01 ShOffLevel :0 %
3:self01 ShOffTime :111600 s
3:self01 ShOffTimeMode :absolut
3:self01 ShOnDly :0 s
3:self01 ShOnLevel :100 %
3:self01 ShOnTime :111600 s
3:self01 ShOnTimeMode :minimal
3:self01 ShactionType :jmpToTarget
3:self01 ShdriveMode :direct
3:self01 ShmaxTimeF :25.5 s
3:self02 LgBlJtDlyOff :onDly
3:self02 LgBlJtDlyOn :refOn
3:self02 LgBlJtOff :onDly
3:self02 LgBlJtOn :onDly
3:self02 LgBlJtRampOff :off
3:self02 LgBlJtRampOn :rampOn
3:self02 LgBlJtRefOff :no
3:self02 LgBlJtRefOn :no
3:self02 LgCtDlyOff :geLo
3:self02 LgCtDlyOn :geLo
3:self02 LgCtOff :geLo
3:self02 LgCtOn :geLo
3:self02 LgCtRampOff :geLo
3:self02 LgCtRampOn :geLo
3:self02 LgOffDly :0 s
3:self02 LgOffLevel :0 %
3:self02 LgOffTime :111600 s
3:self02 LgOffTimeMode :absolut
3:self02 LgOnDly :0 s
3:self02 LgOnLevel :100 %
3:self02 LgOnTime :111600 s
3:self02 LgOnTimeMode :minimal
3:self02 LgactionType :jmpToTarget
3:self02 LgdriveMode :direct
3:self02 LgmaxTimeF :0.4 s
3:self02 ShBlJtDlyOff :onDly
3:self02 ShBlJtDlyOn :refOn
3:self02 ShBlJtOff :onDly
3:self02 ShBlJtOn :onDly
3:self02 ShBlJtRampOff :off
3:self02 ShBlJtRampOn :rampOn
3:self02 ShBlJtRefOff :no
3:self02 ShBlJtRefOn :no
3:self02 ShCtDlyOff :geLo
3:self02 ShCtDlyOn :geLo
3:self02 ShCtOff :geLo
3:self02 ShCtOn :geLo
3:self02 ShCtRampOff :geLo
3:self02 ShCtRampOn :geLo
3:self02 ShOffDly :0 s
3:self02 ShOffLevel :0 %
3:self02 ShOffTime :111600 s
3:self02 ShOffTimeMode :absolut
3:self02 ShOnDly :0 s
3:self02 ShOnLevel :100 %
3:self02 ShOnTime :111600 s
3:self02 ShOnTimeMode :minimal
3:self02 ShactionType :jmpToTarget
3:self02 ShdriveMode :direct
3:self02 ShmaxTimeF :25.5 s
Schlafzimmer_Rollo type:blindActuator -
list:peer register :value
0: intKeyVisib :visib
0: pairCentral :0x203317
3:self01 LgBlJtDlyOff :refOff
3:self01 LgBlJtDlyOn :dlyOff
3:self01 LgBlJtOff :dlyOff
3:self01 LgBlJtOn :dlyOff
3:self01 LgBlJtRampOff :rampOff
3:self01 LgBlJtRampOn :on
3:self01 LgBlJtRefOff :no
3:self01 LgBlJtRefOn :no
3:self01 LgCtDlyOff :geLo
3:self01 LgCtDlyOn :geLo
3:self01 LgCtOff :geLo
3:self01 LgCtOn :geLo
3:self01 LgCtRampOff :geLo
3:self01 LgCtRampOn :geLo
3:self01 LgOffDly :0 s
3:self01 LgOffLevel :0 %
3:self01 LgOffTime :111600 s
3:self01 LgOffTimeMode :absolut
3:self01 LgOnDly :0 s
3:self01 LgOnLevel :100 %
3:self01 LgOnTime :111600 s
3:self01 LgOnTimeMode :minimal
3:self01 LgactionType :jmpToTarget
3:self01 LgdriveMode :direct
3:self01 LgmaxTimeF :0.4 s
3:self01 ShBlJtDlyOff :refOff
3:self01 ShBlJtDlyOn :dlyOff
3:self01 ShBlJtOff :dlyOff
3:self01 ShBlJtOn :dlyOff
3:self01 ShBlJtRampOff :rampOff
3:self01 ShBlJtRampOn :on
3:self01 ShBlJtRefOff :no
3:self01 ShBlJtRefOn :no
3:self01 ShCtDlyOff :geLo
3:self01 ShCtDlyOn :geLo
3:self01 ShCtOff :geLo
3:self01 ShCtOn :geLo
3:self01 ShCtRampOff :geLo
3:self01 ShCtRampOn :geLo
3:self01 ShOffDly :0 s
3:self01 ShOffLevel :0 %
3:self01 ShOffTime :111600 s
3:self01 ShOffTimeMode :absolut
3:self01 ShOnDly :0 s
3:self01 ShOnLevel :100 %
3:self01 ShOnTime :111600 s
3:self01 ShOnTimeMode :minimal
3:self01 ShactionType :jmpToTarget
3:self01 ShdriveMode :direct
3:self01 ShmaxTimeF :25.5 s
3:self02 LgBlJtDlyOff :onDly
3:self02 LgBlJtDlyOn :refOn
3:self02 LgBlJtOff :onDly
3:self02 LgBlJtOn :onDly
3:self02 LgBlJtRampOff :off
3:self02 LgBlJtRampOn :rampOn
3:self02 LgBlJtRefOff :no
3:self02 LgBlJtRefOn :no
3:self02 LgCtDlyOff :geLo
3:self02 LgCtDlyOn :geLo
3:self02 LgCtOff :geLo
3:self02 LgCtOn :geLo
3:self02 LgCtRampOff :geLo
3:self02 LgCtRampOn :geLo
3:self02 LgOffDly :0 s
3:self02 LgOffLevel :0 %
3:self02 LgOffTime :111600 s
3:self02 LgOffTimeMode :absolut
3:self02 LgOnDly :0 s
3:self02 LgOnLevel :100 %
3:self02 LgOnTime :111600 s
3:self02 LgOnTimeMode :minimal
3:self02 LgactionType :jmpToTarget
3:self02 LgdriveMode :direct
3:self02 LgmaxTimeF :0.4 s
3:self02 ShBlJtDlyOff :onDly
3:self02 ShBlJtDlyOn :refOn
3:self02 ShBlJtOff :onDly
3:self02 ShBlJtOn :onDly
3:self02 ShBlJtRampOff :off
3:self02 ShBlJtRampOn :rampOn
3:self02 ShBlJtRefOff :no
3:self02 ShBlJtRefOn :no
3:self02 ShCtDlyOff :geLo
3:self02 ShCtDlyOn :geLo
3:self02 ShCtOff :geLo
3:self02 ShCtOn :geLo
3:self02 ShCtRampOff :geLo
3:self02 ShCtRampOn :geLo
3:self02 ShOffDly :0 s
3:self02 ShOffLevel :0 %
3:self02 ShOffTime :111600 s
3:self02 ShOffTimeMode :absolut
3:self02 ShOnDly :0 s
3:self02 ShOnLevel :100 %
3:self02 ShOnTime :111600 s
3:self02 ShOnTimeMode :minimal
3:self02 ShactionType :jmpToTarget
3:self02 ShdriveMode :direct
3:self02 ShmaxTimeF :25.5 s
kossmann
Dec 17, 2012, 10:15:32 AM12/17/12
to fhem-...@googlegroups.com
Und wo ich es gerade poste, sehe ich, dass wieder ein "Timout" drin war. Mehrere getConfig hintereinander haben nichts daran geändert. Sicherheitshalber FHEM neu gestartet und danach wollte ich einmal runter und wieder hoch fahren, um danach neu zu lesen... dann der Fehler:
NAME Schlafzimmer_Rollo
NR 86
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
2012-12-16 09:13:36 R-driveDown 20.7 s
2012-12-16 09:13:36 R-driveTurn 0 s
2012-12-16 09:13:36 R-driveUp 24 s
2012-12-16 22:18:50 R-self01-LgOffLevel 0 %
2012-12-16 22:18:50 R-self01-LgOnLevel 100 %
2012-12-16 22:18:50 R-self01-ShOffLevel 0 %
2012-12-16 22:18:50 R-self01-ShOnLevel 100 %
2012-12-16 09:13:40 R-self02-LgOffLevel 0 %
2012-12-16 09:13:40 R-self02-LgOnLevel 100 %
2012-12-16 09:13:40 R-self02-ShOffLevel 0 %
2012-12-16 09:13:40 R-self02-ShOnLevel 100 %
2012-12-17_16:11:12 Schlafzimmer_Rollo set_unten
2012-12-17_16:11:13 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-17_16:11:13 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-17_16:11:13 Schlafzimmer_Rollo motor: stop:oben
2012-12-17_16:11:13 Schlafzimmer_Rollo oben
Ich bekomme nun zwar weiterhin einen Timout, aber vielleicht sieht mal hier ja mehr:2012-12-17_16:11:13 Schlafzimmer_Rollo CommandAccepted: yes
2012-12-17_16:11:13 Schlafzimmer_Rollo deviceMsg: oben (to MyCUL)
2012-12-17_16:11:13 Schlafzimmer_Rollo motor: stop:oben
2012-12-17_16:11:13 Schlafzimmer_Rollo oben
list Schlafzimmer_Rollo
Internals:
CFGFN user_schlafzimmer.cfg
Internals:
CFGFN user_schlafzimmer.cfg
DEF 1BCD29
IODev MyCUL
LASTIODev MyCUL
IODev MyCUL
LASTIODev MyCUL
MSGCNT 11
MyCUL_MSGCNT 11
MyCUL_RAWMSG A1A0BA0101BCD292033170301000000326400FF00FF01111268000024
MyCUL_RSSI -56
MyCUL_TIME 2012-12-17 16:14:07
MyCUL_MSGCNT 11
MyCUL_RAWMSG A1A0BA0101BCD292033170301000000326400FF00FF01111268000024
MyCUL_RSSI -56
MyCUL_TIME 2012-12-17 16:14:07
NAME Schlafzimmer_Rollo
NR 86
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:0B - t:10 s:1BCD29 d:203317 0301000000326400FF00FF011112680000
protLastRcv 2012-12-17 16:14:07
protSnd 6 last_at:2012-12-17 16:14:06
protState CMDs_done_events:1
protToutResp 2 last_at:2012-12-17 16:14:08
Readings:
2012-12-17 16:11:13 CommandAccepted yes
2012-12-17 16:10:42 PairedTo 0x203317
protLastRcv 2012-12-17 16:14:07
protSnd 6 last_at:2012-12-17 16:14:06
protState CMDs_done_events:1
protToutResp 2 last_at:2012-12-17 16:14:08
Readings:
2012-12-17 16:11:13 CommandAccepted yes
2012-12-17 16:10:42 PairedTo 0x203317
2012-12-16 09:13:36 R-driveDown 20.7 s
2012-12-16 09:13:36 R-driveTurn 0 s
2012-12-16 09:13:36 R-driveUp 24 s
2012-12-16 22:18:50 R-self01-LgOffLevel 0 %
2012-12-16 22:18:50 R-self01-LgOnLevel 100 %
2012-12-16 22:18:50 R-self01-ShOffLevel 0 %
2012-12-16 22:18:50 R-self01-ShOnLevel 100 %
2012-12-16 09:13:40 R-self02-LgOffLevel 0 %
2012-12-16 09:13:40 R-self02-LgOnLevel 100 %
2012-12-16 09:13:40 R-self02-ShOffLevel 0 %
2012-12-16 09:13:40 R-self02-ShOnLevel 100 %
2012-12-17 16:14:03 RegL_00: 02:80 0A:20 0B:33 0C:17 15:FF
2012-12-17 16:14:05 RegL_01: 08:00 09:00 0A:00 0B:00 0C:CF 0D:00 0E:F0 0F:00 10:00 00:00
2012-12-17 16:14:06 RegL_03:self01 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:44 0C:54 0D:93 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:93 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:44 8C:54 8D:93 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:04 9E:93 9F:00 00:00
2012-12-17 16:14:07 RegL_03:self02 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0E:00 0F:00
2012-12-17 16:11:13 deviceMsg on (to MyCUL)
2012-12-17 16:11:13 motor stop:on
2012-12-17 16:14:04 peerList self01,self02,
2012-12-17 16:14:08 state RESPONSE TIMEOUT:RegisterRead
Helper:
burstEvtCnt 2
2012-12-17 16:14:05 RegL_01: 08:00 09:00 0A:00 0B:00 0C:CF 0D:00 0E:F0 0F:00 10:00 00:00
2012-12-17 16:14:06 RegL_03:self01 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:44 0C:54 0D:93 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:93 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:44 8C:54 8D:93 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:04 9E:93 9F:00 00:00
2012-12-17 16:14:07 RegL_03:self02 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0E:00 0F:00
2012-12-17 16:11:13 deviceMsg on (to MyCUL)
2012-12-17 16:11:13 motor stop:on
2012-12-17 16:14:04 peerList self01,self02,
2012-12-17 16:14:08 state RESPONSE TIMEOUT:RegisterRead
Helper:
burstEvtCnt 2
Martin
Dec 18, 2012, 10:36:46 AM12/18/12
to fhem-...@googlegroups.com
Ich sehe ein Problem. Die Message ist zu lang - offensichtlich sind hier 2 messages zusammengewachsen
Das war eigentlich kein timeout, aber das Ende wurde einfach nicht erkannt.
Kann ich aendern... dass das Ende erkannt wird
Was unklar ist: wer hat die messages nicht sauber getrennt - muss ich suchen.
Und - was mache ich mit der 'ueberschuessigen' info?
Hast du HM devices mit HMID wie
111112, ff00ff oder solche kombinationen?
Gruss
Martin
Das war eigentlich kein timeout, aber das Ende wurde einfach nicht erkannt.
Kann ich aendern... dass das Ende erkannt wird
Was unklar ist: wer hat die messages nicht sauber getrennt - muss ich suchen.
Und - was mache ich mit der 'ueberschuessigen' info?
Hast du HM devices mit HMID wie
111112, ff00ff oder solche kombinationen?
Gruss
Martin
kossmann
Dec 18, 2012, 10:46:47 AM12/18/12
to fhem-...@googlegroups.com
Die Fragen (bis auf die letzte) stellst du dir bzw. Allgemeinheit, nicht mir, oder?
Ich habe nur FHEM mit "MyCUL" und "Schlafzimmer_Rollo" als HomeMatic-Geräte, ansonsten sind noch 3 Intertechnodosen und ein paar Dummies definiert. Weitere 7 Rollladenaktoren erwarte ich morgen per DHL, ich weiß nur nicht, wann ich zum Einbau komme.
Ich habe nur FHEM mit "MyCUL" und "Schlafzimmer_Rollo" als HomeMatic-Geräte, ansonsten sind noch 3 Intertechnodosen und ein paar Dummies definiert. Weitere 7 Rollladenaktoren erwarte ich morgen per DHL, ich weiß nur nicht, wann ich zum Einbau komme.
Martin
Dec 19, 2012, 7:42:09 AM12/19/12
to fhem-...@googlegroups.com
Am Dienstag, 18. Dezember 2012 16:46:47 UTC+1 schrieb kossmann:
Die Fragen (bis auf die letzte) stellst du dir bzw. Allgemeinheit, nicht mir, oder?
schon dir. War nur ein Versuch. Erklaerung:
Ich sehen dass die letzte message eine :
MyCUL_RAWMSG A1A0BA0101BCD29203317030100000
Ich sehen dass die letzte message eine :
MyCUL_RAWMSG A1A0BA0101BCD29203317030100000
0326400FF00FF01111268000024
lastMsg No:0B - t:10 s:1BCD29 d:203317 0301000000326400FF00FF01111268
0000
war.
Korrekte messate ist:
s:1BCD29 d:203317 0301000000
das Ende sind Daten, di e ich nicht zuordnen kann:
326400FF00FF011112680000
Der Timeout kommt, weil das Korrekte Ende der Sequenz 'read' nicht erkannt wird und es daher zu einem timeout kommt.
Interessant ist, wo diese Daten herkommen, wer sie generiert und wie man sie parsen kann
Gruss
Martin
war.
Korrekte messate ist:
s:1BCD29 d:203317 0301000000
das Ende sind Daten, di e ich nicht zuordnen kann:
326400FF00FF011112680000
Der Timeout kommt, weil das Korrekte Ende der Sequenz 'read' nicht erkannt wird und es daher zu einem timeout kommt.
Interessant ist, wo diese Daten herkommen, wer sie generiert und wie man sie parsen kann
Gruss
Martin
kossmann
Dec 19, 2012, 7:52:52 AM12/19/12
to fhem-...@googlegroups.com
Mit den HEX/RAW-Blöcken kann ich allgemein nichts anfangen, da ich leider keine Ahnung habe, was das CUL dem HM-Device da sagen möchte.
In dem dir unbekannten Block kann ich leider auch nichts identifizieren. Meine 3 Intertechnodosen haben den Hausecode 0F0F, was dort nicht zu sehen ist - und mich auch wundern würde, wenn es dort (in er HM-Kommunikation) auftauchen würde.
Habe die Messages nicht immer eine feste Länge? Die HMid ist doch beispielsweise immer 6stellig. Gilt dies für den Rest auch?
In dem dir unbekannten Block kann ich leider auch nichts identifizieren. Meine 3 Intertechnodosen haben den Hausecode 0F0F, was dort nicht zu sehen ist - und mich auch wundern würde, wenn es dort (in er HM-Kommunikation) auftauchen würde.
Habe die Messages nicht immer eine feste Länge? Die HMid ist doch beispielsweise immer 6stellig. Gilt dies für den Rest auch?
Martin
Dec 20, 2012, 4:35:03 AM12/20/12
to fhem-...@googlegroups.com
Habe die Messages nicht immer eine feste Länge? Die HMid ist doch beispielsweise immer 6stellig. Gilt dies für den Rest auch?
nein - absolut nicht.
Die gegebene Message kann ich noch parsen - aber generell koennte es ein Problem werden.
Zu diener Installation - auf der Frequenz funken also HM und die 3 Intertechno dosen.
Nach kenntnissstand kann der Fehler aus vielen Quellen kommen... Mal sehen ob mir etwas einfaellt
Gruss
Martin
Die gegebene Message kann ich noch parsen - aber generell koennte es ein Problem werden.
Zu diener Installation - auf der Frequenz funken also HM und die 3 Intertechno dosen.
Nach kenntnissstand kann der Fehler aus vielen Quellen kommen... Mal sehen ob mir etwas einfaellt
Gruss
Martin
kossmann
Dec 20, 2012, 4:49:31 AM12/20/12
to fhem-...@googlegroups.com
Die IT-Dosen funken auf 433MHz, die HM-Devices auf 868MHz. Außer dem einen Rollladenaktor ist nichts weiteres vorhanden, was dazwischen funken könnte.
Martin
Dec 20, 2012, 5:23:32 AM12/20/12
to fhem-...@googlegroups.com
ok - mal sehen, ob man da fehler isolieren kann. Falls so etwas auftritt, dass message die falsche laenge haben passiert im Augenblick nichts - es wird nur zufaellig bemerkt. Es ist also moeglich, dass so etwas haeufiger auftirtt - auch bei anderen Usern.
Um es einzugrenzen werde ich als erstes Versuchen fehlerhafte message-laengen zu erkennen und entsprechend einen Logeintrag zu generieren - sonst weiter nichts bis wir mehr Daten haben. Kommt in zukunft.
Aber das ist nicht dein eigentliches Problem - wir sind abgewandert.
Wie steht es denn mit deinen Rollos? Bist du an der Loesung mit virtual switches interresiert?
Gruss
Martin
Um es einzugrenzen werde ich als erstes Versuchen fehlerhafte message-laengen zu erkennen und entsprechend einen Logeintrag zu generieren - sonst weiter nichts bis wir mehr Daten haben. Kommt in zukunft.
Aber das ist nicht dein eigentliches Problem - wir sind abgewandert.
Wie steht es denn mit deinen Rollos? Bist du an der Loesung mit virtual switches interresiert?
Gruss
Martin
kossmann
Dec 20, 2012, 5:28:08 AM12/20/12
to fhem-...@googlegroups.com
Diese Woche lief bis jetzt alles problemlos - ich habe FHEM allerdings auch halbwegs in Ruhe gelassen (ganz selten ein Neustart).
Ich warte eigentlich auf 7 weitere Aktoren, aber DHL lässt sich diese Woche extrem viel Zeit. Dann hätte ich zumindest ein paar Testkandidaten mehr.
Wenn ich dich richtig verstanden habe, macht der virtual switch nur mit mehreren Rollos Sinn, oder?
Ich warte eigentlich auf 7 weitere Aktoren, aber DHL lässt sich diese Woche extrem viel Zeit. Dann hätte ich zumindest ein paar Testkandidaten mehr.
Wenn ich dich richtig verstanden habe, macht der virtual switch nur mit mehreren Rollos Sinn, oder?
Martin
Dec 20, 2012, 6:32:56 AM12/20/12
to fhem-...@googlegroups.com
Wenn ich dich richtig verstanden habe, macht der virtual switch nur mit mehreren Rollos Sinn, oder?
Die Idee ist in deinem Fall die Anforderung, eine feste Gruppe von Rollos gemeinsam zu steuern. Damit kannst du quasi eine Funktion definieren, per tastendruck. Ist etwas aufwand... hat besonderheiten. Kurzum - aus dem Kopf... wuerde ich es so bauen
# 2 virtuelle Taster, einer hochfahren, einer Runter
define virtDev CUL_HM 100001
set virtDev virtual 2 # du kannst natuerlich viel mehr kanaele in dem deivce definieren
# rename - weil es schoener ist
rename virtDev_Btn1 setRolloHoch
rename virtDev_Btn1 setRolloRunter
# angenommen: 5 Rollos in der Gruppe - r1...r5 (muss ich nicht so viel tippen...;-))
set setRolloHoch devicepair 0 r1 # da dual default ist werden Hoch und Runter in einem definiert
set setRolloHoch devicepair 0 r2 # und die defaults im Aktor sind korrekt
set setRolloHoch devicepair 0 r3
set setRolloHoch devicepair 0 r4
set setRolloHoch devicepair 0 r5
# Es ist moeglich, dass hoch und runter vertauscht sind - das musst du testen....
set setRolloHoch press # alle rollos fliegen hoch;-) . eine message, alle fahren .
# Stausmeldungen kommen von allen einzeln
set setRolloRunter press # alle rollos runter
# soweit er einfache Teil - sollte bei dir schon genuegen. Die Gruppe ist erweiterbar, klar. Auch mit anderen Aktoren kombinierbar (licht,... )
weitere Optionen - fuer Fortgeschrittene:
- Die aktion nach dem 'press' kannst du in jeden Aktor festlegen- also an fuer eine bestimmte Zeit, fahren bis zu eine bestimmten hellikkeit (dimmer)...
- du kannst einen Aktor auch mit mehreren virtuellen und/oder realen buttons pairen und somit entweder verschieden Gruppen definieren oder verschiedene Modi fahren. Also ein Knopf setRollo50 - alle Rollos fahren nach 50%
set setRolloHoch press long
#Hier faehrt der Rollo per default nur so 0,5 sec, glaube ich. Aber du kannst es in den Rollos umprogrammieren
Gruss
Martin
Reply all
Reply to author
Forward
0 new messages