Log: Anlernen HM-CC-TC mit 2 HM-CC-VDs und einem HM-Sec-Sc

[rudolfkoenig]

                                                   

> da du WOR angesprochen hast - weisst du, wie man HMLAN dazu bringen kann,
> es zu senden?

Natuerlich nicht, sonst haette ich das im culfw schon nachgebaut.

Ich bin nicht mal sicher, ob es verwendet wird, es ist nur die plausibelste
Theorie.

Btw. ich meine WOR (oder was vergleichbares) ist bei dem VD nicht oder nicht
immer aktiviert: ich habe am TC die Temperatur auf OFF gestellt, und es hat
etliche Minuten gedauert, bis das Ventil in Bewegung kam. Evtl. wird WOR im VD
nur dann aktiviert, falls ein Fenstermelder im Spiel ist.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Samstag, 24. November 2012 10:44:47 UTC+1 schrieb Rudolf Koenig:
>
> > da du WOR angesprochen hast - weisst du, wie man HMLAN dazu bringen
> kann,
> > es zu senden?
>
> Natuerlich nicht, sonst haette ich das im culfw schon nachgebaut.
>
schade - da du erwaehnt hast, das es mit HMLAN funktionieren koennte.
Immerhin gibt es hier noch die ominoesen Kommandos, die ich nicht deuten
kann.


> Ich bin nicht mal sicher, ob es verwendet wird, es ist nur die
> plausibelste
> Theorie.
>
Moeglich. Fakt ist, dass mein TC sich in einem Toleranzband von 2-3min mit
dem VD unterhaelt.  
Sicher (und merkwuerdig) ist auch, dass mein VD meine einstellugn
angenommen hat, Dann noch eine Aenderung nach 10 min. Danach hat er nicht
mehr auf die Trigger geantwortet. ABER: er ist nicht in error gegangen -
ueber Stunden. => die Kommandos sind angekommen.
Nach der Aenderung der VD einstellung hat de VD nach ~5-10 min aufgegeben
und ist in die error-position gelaufen.
Die gesendeten Kommandos entsprechen denen des TC, jedenfalls alles was
sichtbar ist 'hinter' hmlan und CUL.
Der VirtualTC leauft wie ein Uhrwerk - praeziser als der HW-TC
Gestern konnte ich auch die Einstellung mehrfach aendern - ist aber nicht
stabil. Da hatte ich mich zu frueh gefreut.

Mit der CUL habe ich noch nicht getestet. HMLAN denkt wieder einmal zu viel
mit hier - erkennt dieses Spezielle ACK nicht und schickt zuhaeufig...
Vielleicht geht es da besser?

Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Gerne stelle ich mich ale Beta-Tester mit COC am Rpi zur Verfügung


Am 24. November 2012 16:55 schrieb Martin :

>
> Am Samstag, 24. November 2012 10:44:47 UTC+1 schrieb Rudolf Koenig:
>>
>> > da du WOR angesprochen hast - weisst du, wie man HMLAN dazu bringen
>> kann,
>> > es zu senden?
>>
>> Natuerlich nicht, sonst haette ich das im culfw schon nachgebaut.
>>
> schade - da du erwaehnt hast, das es mit HMLAN funktionieren koennte.
> Immerhin gibt es hier noch die ominoesen Kommandos, die ich nicht deuten
> kann.
>
>
>> Ich bin nicht mal sicher, ob es verwendet wird, es ist nur die
>> plausibelste
>> Theorie.
>>
> Moeglich. Fakt ist, dass mein TC sich in einem Toleranzband von 2-3min mit
> dem VD unterhaelt.
> Sicher (und merkwuerdig) ist auch, dass mein VD meine einstellugn
> angenommen hat, Dann noch eine Aenderung nach 10 min. Danach hat er nicht
> mehr auf die Trigger geantwortet. ABER: er ist nicht in error gegangen -
> ueber Stunden. => die Kommandos sind angekommen.
> Nach der Aenderung der VD einstellung hat de VD nach ~5-10 min aufgegeben
> und ist in die error-position gelaufen.
> Die gesendeten Kommandos entsprechen denen des TC, jedenfalls alles was
> sichtbar ist 'hinter' hmlan und CUL.
> Der VirtualTC leauft wie ein Uhrwerk - praeziser als der HW-TC
> Gestern konnte ich auch die Einstellung mehrfach aendern - ist aber nicht
> stabil. Da hatte ich mich zu frueh gefreut.
>
> Mit der CUL habe ich noch nicht getestet. HMLAN denkt wieder einmal zu
> viel mit hier - erkennt dieses Spezielle ACK nicht und schickt zuhaeufig...
> Vielleicht geht es da besser?
>
> Gruss
> Martin
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Dirk,

in der Version von gestern ist eine Variante - versuchsweise - drin.
Undokumentiert, da nicht "released".
Vorab: Mit HMLAN gab es Probleme - und evtl kann es nicht gehen...

Deshalb hier eine Beschreibung, falls du dennoch probieren willst:
a) einrichten eines virtuellen TC
+ define virtTC CUL_HM 123456 # nummer nach gusto
+ set virtTC virtual 1 #ein virtual channel sollte reichen
b) deinen VD solltest du eingerichtet habe wie gewohnt
c) Loeschen des Peers des VD, falls einer eingerichtet ist
+ VD koennte resetet werden, dann sollte der Peer weg sein
+ ansonsten nachsehen, ob ein Peer eingetragen ist mit
=> set vd getConfig
=> anlernen 3sec druecken, damit gelesen werden kann
=> nachsehen, peerIDs und peerList muss leer sein
d) peeren
+ set virtTC_Btn1 devicepair 0 vd single set # virtual wird gleich gepeert,
der VD muss auf 'config' warten
+ set vd getConfig                                     # gleich das
Kommando hinterher, damit man nur einmal cnfig druecken muss
+ anlernen am VD druecken
+ in peerList des vd sollte virtTC_Btn1, stehen
+ Der vd ist in den naechsten Minuten aufnahmebereit und sollte
Einstellungen verarbeiten. Nicht zuuu lange warten
e) einstellen:
set virtTC_Btn1 valvePos 30  # eine Position, die sich von der error-pos
unterscheidet
=> der virtTC_Btn1 startet seinen timer und updated den VD alle 150sec.
=> aenderungen des VD dauern also immer 2:30min, schneller geht nicht
++> bisher funktioniert hat
1) nach "config" uebernimmt der VD die einstellung. Man kann auch eine Zeit
lang aendern
2) der VD bleibt stunden auf der einstellung, ohne auf error zu gehen
3) wenn man den virt TC ausschaltet (mit set virtTC_Btn1 valvePos off) geht
der VD nach einigen Minuten auf errorPos.
4) nach einiger Zeit kann man die einstellung nicht mehr aendern, der VD
wird, wenn man aendert, auf errorpos gehen
5) wenn man konifg drueckt wird der VD die aktuelle einstellung uebernehmen
(natuerlich warten , bis der virtTC sendet)

Gruss und viel Erfolg,

Martin

ps.: Wenn du traces machst bitte
attr gloval verbose 1
attr global mseclog 1
attr loglevel 1
attr hmProtocolEvents 0

Und evtl ein paar kommentare

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Danke!
werde es gleich heute Abend mal testen!
Dirk



Am 26. November 2012 11:54 schrieb Martin :

> Dirk,
>
> in der Version von gestern ist eine Variante - versuchsweise - drin.
> Undokumentiert, da nicht "released".
> Vorab: Mit HMLAN gab es Probleme - und evtl kann es nicht gehen...
>
> Deshalb hier eine Beschreibung, falls du dennoch probieren willst:
> a) einrichten eines virtuellen TC
> + define virtTC CUL_HM 123456 # nummer nach gusto
> + set virtTC virtual 1 #ein virtual channel sollte reichen
> b) deinen VD solltest du eingerichtet habe wie gewohnt
> c) Loeschen des Peers des VD, falls einer eingerichtet ist
> + VD koennte resetet werden, dann sollte der Peer weg sein
> + ansonsten nachsehen, ob ein Peer eingetragen ist mit
> => set vd getConfig
> => anlernen 3sec druecken, damit gelesen werden kann
> => nachsehen, peerIDs und peerList muss leer sein
> d) peeren
> + set virtTC_Btn1 devicepair 0 vd single set # virtual wird gleich
> gepeert, der VD muss auf 'config' warten
> + set vd getConfig                                     # gleich das
> Kommando hinterher, damit man nur einmal cnfig druecken muss
> + anlernen am VD druecken
> + in peerList des vd sollte virtTC_Btn1, stehen
> + Der vd ist in den naechsten Minuten aufnahmebereit und sollte
> Einstellungen verarbeiten. Nicht zuuu lange warten
> e) einstellen:
> set virtTC_Btn1 valvePos 30  # eine Position, die sich von der error-pos
> unterscheidet
> => der virtTC_Btn1 startet seinen timer und updated den VD alle 150sec.
> => aenderungen des VD dauern also immer 2:30min, schneller geht nicht
> ++> bisher funktioniert hat
> 1) nach "config" uebernimmt der VD die einstellung. Man kann auch eine
> Zeit lang aendern
> 2) der VD bleibt stunden auf der einstellung, ohne auf error zu gehen
> 3) wenn man den virt TC ausschaltet (mit set virtTC_Btn1 valvePos off)
> geht der VD nach einigen Minuten auf errorPos.
> 4) nach einiger Zeit kann man die einstellung nicht mehr aendern, der VD
> wird, wenn man aendert, auf errorpos gehen
> 5) wenn man konifg drueckt wird der VD die aktuelle einstellung
> uebernehmen (natuerlich warten , bis der virtTC sendet)
>
> Gruss und viel Erfolg,
>
> Martin
>
> ps.: Wenn du traces machst bitte
> attr gloval verbose 1
> attr global mseclog 1
> attr loglevel 1
> attr hmProtocolEvents 0
>
> Und evtl ein paar kommentare
>
>  --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi Martin,

cool! Ich konnte heute Nacht leider nur einen sehr sehr kurzen Test machen,
und da hat es funktioniert. Mal sehen, ob es heute Abend noch läuft, wenn
ich nach Hause komme

Ausführlicher Test heute Abend und dann mehr Feedback.

Ciao,
Dirk



Am 26. November 2012 11:54 schrieb Martin :

> Dirk,
>
> in der Version von gestern ist eine Variante - versuchsweise - drin.
> Undokumentiert, da nicht "released".
> Vorab: Mit HMLAN gab es Probleme - und evtl kann es nicht gehen...
>
> Deshalb hier eine Beschreibung, falls du dennoch probieren willst:
> a) einrichten eines virtuellen TC
> + define virtTC CUL_HM 123456 # nummer nach gusto
> + set virtTC virtual 1 #ein virtual channel sollte reichen
> b) deinen VD solltest du eingerichtet habe wie gewohnt
> c) Loeschen des Peers des VD, falls einer eingerichtet ist
> + VD koennte resetet werden, dann sollte der Peer weg sein
> + ansonsten nachsehen, ob ein Peer eingetragen ist mit
> => set vd getConfig
> => anlernen 3sec druecken, damit gelesen werden kann
> => nachsehen, peerIDs und peerList muss leer sein
> d) peeren
> + set virtTC_Btn1 devicepair 0 vd single set # virtual wird gleich
> gepeert, der VD muss auf 'config' warten
> + set vd getConfig                                     # gleich das
> Kommando hinterher, damit man nur einmal cnfig druecken muss
> + anlernen am VD druecken
> + in peerList des vd sollte virtTC_Btn1, stehen
> + Der vd ist in den naechsten Minuten aufnahmebereit und sollte
> Einstellungen verarbeiten. Nicht zuuu lange warten
> e) einstellen:
> set virtTC_Btn1 valvePos 30  # eine Position, die sich von der error-pos
> unterscheidet
> => der virtTC_Btn1 startet seinen timer und updated den VD alle 150sec.
> => aenderungen des VD dauern also immer 2:30min, schneller geht nicht
> ++> bisher funktioniert hat
> 1) nach "config" uebernimmt der VD die einstellung. Man kann auch eine
> Zeit lang aendern
> 2) der VD bleibt stunden auf der einstellung, ohne auf error zu gehen
> 3) wenn man den virt TC ausschaltet (mit set virtTC_Btn1 valvePos off)
> geht der VD nach einigen Minuten auf errorPos.
> 4) nach einiger Zeit kann man die einstellung nicht mehr aendern, der VD
> wird, wenn man aendert, auf errorpos gehen
> 5) wenn man konifg drueckt wird der VD die aktuelle einstellung
> uebernehmen (natuerlich warten , bis der virtTC sendet)
>
> Gruss und viel Erfolg,
>
> Martin
>
> ps.: Wenn du traces machst bitte
> attr gloval verbose 1
> attr global mseclog 1
> attr loglevel 1
> attr hmProtocolEvents 0
>
> Und evtl ein paar kommentare
>
>  --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich kann im Moment nur per Fernwartung auf die Logs zugreifen, aber nach
ca. 1 1/2 Stunden ist der VD wieder in den Error Mode "gefahren":

2012-11-27_09:11:56 vd CommandAccepted: yes
2012-11-27_09:12:13 vd CommandAccepted: yes
2012-11-27_09:12:13 vd ValvePosition: 15%
2012-11-27_09:12:13 vd 15%
2012-11-27_09:12:13 vd motor: stop
2012-11-27_09:12:13 vd ValveErrorPosition: 15%
2012-11-27_09:12:13 vd ValveOffset: 0%
2012-11-27_09:14:43 vd CommandAccepted: yes
2012-11-27_09:14:43 vd ValvePosition: 40%
2012-11-27_09:14:43 vd 40%
2012-11-27_09:14:43 vd motor: stop
2012-11-27_09:29:46 vd CommandAccepted: yes
2012-11-27_09:29:46 vd ValvePosition: 40%
2012-11-27_09:29:46 vd 40%
2012-11-27_09:29:46 vd motor: stop
2012-11-27_10:47:14 vd CommandAccepted: yes
2012-11-27_10:47:14 vd ValvePosition: 15%
2012-11-27_10:47:14 vd 15%
2012-11-27_10:47:14 vd motor: stop
2012-11-27_12:04:44 vd CommandAccepted: yes
2012-11-27_12:04:44 vd ValvePosition: 15%
2012-11-27_12:04:44 vd 15%
2012-11-27_12:04:44 vd motor: stop


Am Dienstag, 27. November 2012 10:29:35 UTC+1 schrieb Dirk:
>
> Hi Martin,
>
> cool! Ich konnte heute Nacht leider nur einen sehr sehr kurzen Test
> machen, und da hat es funktioniert. Mal sehen, ob es heute Abend noch
> läuft, wenn ich nach Hause komme
>
> Ausführlicher Test heute Abend und dann mehr Feedback.
>
> Ciao,
> Dirk
>
>
>
> Am 26. November 2012 11:54 schrieb Martin
>
>> Dirk,
>>
>> in der Version von gestern ist eine Variante - versuchsweise - drin.
>> Undokumentiert, da nicht "released".
>> Vorab: Mit HMLAN gab es Probleme - und evtl kann es nicht gehen...
>>
>> Deshalb hier eine Beschreibung, falls du dennoch probieren willst:
>> a) einrichten eines virtuellen TC
>> + define virtTC CUL_HM 123456 # nummer nach gusto
>> + set virtTC virtual 1 #ein virtual channel sollte reichen
>> b) deinen VD solltest du eingerichtet habe wie gewohnt
>> c) Loeschen des Peers des VD, falls einer eingerichtet ist
>> + VD koennte resetet werden, dann sollte der Peer weg sein
>> + ansonsten nachsehen, ob ein Peer eingetragen ist mit
>> => set vd getConfig
>> => anlernen 3sec druecken, damit gelesen werden kann
>> => nachsehen, peerIDs und peerList muss leer sein
>> d) peeren
>> + set virtTC_Btn1 devicepair 0 vd single set # virtual wird gleich
>> gepeert, der VD muss auf 'config' warten
>> + set vd getConfig                                     # gleich das
>> Kommando hinterher, damit man nur einmal cnfig druecken muss
>> + anlernen am VD druecken
>> + in peerList des vd sollte virtTC_Btn1, stehen
>> + Der vd ist in den naechsten Minuten aufnahmebereit und sollte
>> Einstellungen verarbeiten. Nicht zuuu lange warten
>> e) einstellen:
>> set virtTC_Btn1 valvePos 30  # eine Position, die sich von der error-pos
>> unterscheidet
>> => der virtTC_Btn1 startet seinen timer und updated den VD alle 150sec.
>> => aenderungen des VD dauern also immer 2:30min, schneller geht nicht
>> ++> bisher funktioniert hat
>> 1) nach "config" uebernimmt der VD die einstellung. Man kann auch eine
>> Zeit lang aendern
>> 2) der VD bleibt stunden auf der einstellung, ohne auf error zu gehen
>> 3) wenn man den virt TC ausschaltet (mit set virtTC_Btn1 valvePos off)
>> geht der VD nach einigen Minuten auf errorPos.
>> 4) nach einiger Zeit kann man die einstellung nicht mehr aendern, der VD
>> wird, wenn man aendert, auf errorpos gehen
>> 5) wenn man konifg drueckt wird der VD die aktuelle einstellung
>> uebernehmen (natuerlich warten , bis der virtTC sendet)
>>
>> Gruss und viel Erfolg,
>>
>> Martin
>>
>> ps.: Wenn du traces machst bitte
>> attr gloval verbose 1
>> attr global mseclog 1
>> attr loglevel 1
>> attr hmProtocolEvents 0
>>
>> Und evtl ein paar kommentare
>>
>>  --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi Martin,

nochmal ich, nach einem ausführlichen Testabend:

Heute Abend habe ich den VD noch mal reseted und neu angelernt. Das Pairen
mit dem virtTC hat nicht auf Anhieb geklappt. Irgendwie hatte ich das
Gefühl, dass man schon da das richtige Zeitfenster finden muss. Jedenfalls
ist in der Peerlist des VD nur der "virtTC_Btn1,".

Danach kann ich den VD über den virtTC gut steuern. Alles so, wie es sein
sollte.

Dann geht aber nach ca. 1/2 Stunde der VD in den 15% Error Mode und die
Antenne blinkt. Erst wenn ich den Taster am ganz VD kurz drücke hört die
Antenne auf zu blinken und ich kann z.B. mit "set virtTC_Btn1 valvePos 30"
den VD wieder "zum Leben" erwecken.

Der VD scheint also irgendwie die Verbindung zum COC/virtTC zu verlieren...
Müssten man den irgendwie wach halten/triggern?

Wo wäre denn mal ein guter Punkt zum "debuggen".

BTW: ich habe ja keinen richtigen TC....

VG & Gute Nacht,
Dirk





Am Dienstag, 27. November 2012 13:23:33 UTC+1 schrieb Dirk:
>
> Ich kann im Moment nur per Fernwartung auf die Logs zugreifen, aber nach
> ca. 1 1/2 Stunden ist der VD wieder in den Error Mode "gefahren":
>
> 2012-11-27_09:11:56 vd CommandAccepted: yes
> 2012-11-27_09:12:13 vd CommandAccepted: yes
> 2012-11-27_09:12:13 vd ValvePosition: 15%
> 2012-11-27_09:12:13 vd 15%
> 2012-11-27_09:12:13 vd motor: stop
> 2012-11-27_09:12:13 vd ValveErrorPosition: 15%
> 2012-11-27_09:12:13 vd ValveOffset: 0%
> 2012-11-27_09:14:43 vd CommandAccepted: yes
> 2012-11-27_09:14:43 vd ValvePosition: 40%
> 2012-11-27_09:14:43 vd 40%
> 2012-11-27_09:14:43 vd motor: stop
> 2012-11-27_09:29:46 vd CommandAccepted: yes
> 2012-11-27_09:29:46 vd ValvePosition: 40%
> 2012-11-27_09:29:46 vd 40%
> 2012-11-27_09:29:46 vd motor: stop
> 2012-11-27_10:47:14 vd CommandAccepted: yes
> 2012-11-27_10:47:14 vd ValvePosition: 15%
> 2012-11-27_10:47:14 vd 15%
> 2012-11-27_10:47:14 vd motor: stop
> 2012-11-27_12:04:44 vd CommandAccepted: yes
> 2012-11-27_12:04:44 vd ValvePosition: 15%
> 2012-11-27_12:04:44 vd 15%
> 2012-11-27_12:04:44 vd motor: stop
>
>
> Am Dienstag, 27. November 2012 10:29:35 UTC+1 schrieb Dirk:
>>
>> Hi Martin,
>>
>> cool! Ich konnte heute Nacht leider nur einen sehr sehr kurzen Test
>> machen, und da hat es funktioniert. Mal sehen, ob es heute Abend noch
>> läuft, wenn ich nach Hause komme
>>
>> Ausführlicher Test heute Abend und dann mehr Feedback.
>>
>> Ciao,
>> Dirk
>>
>>
>>
>> Am 26. November 2012 11:54 schrieb Martin
>>
>>> Dirk,
>>>
>>> in der Version von gestern ist eine Variante - versuchsweise - drin.
>>> Undokumentiert, da nicht "released".
>>> Vorab: Mit HMLAN gab es Probleme - und evtl kann es nicht gehen...
>>>
>>> Deshalb hier eine Beschreibung, falls du dennoch probieren willst:
>>> a) einrichten eines virtuellen TC
>>> + define virtTC CUL_HM 123456 # nummer nach gusto
>>> + set virtTC virtual 1 #ein virtual channel sollte reichen
>>> b) deinen VD solltest du eingerichtet habe wie gewohnt
>>> c) Loeschen des Peers des VD, falls einer eingerichtet ist
>>> + VD koennte resetet werden, dann sollte der Peer weg sein
>>> + ansonsten nachsehen, ob ein Peer eingetragen ist mit
>>> => set vd getConfig
>>> => anlernen 3sec druecken, damit gelesen werden kann
>>> => nachsehen, peerIDs und peerList muss leer sein
>>> d) peeren
>>> + set virtTC_Btn1 devicepair 0 vd single set # virtual wird gleich
>>> gepeert, der VD muss auf 'config' warten
>>> + set vd getConfig                                     # gleich das
>>> Kommando hinterher, damit man nur einmal cnfig druecken muss
>>> + anlernen am VD druecken
>>> + in peerList des vd sollte virtTC_Btn1, stehen
>>> + Der vd ist in den naechsten Minuten aufnahmebereit und sollte
>>> Einstellungen verarbeiten. Nicht zuuu lange warten
>>> e) einstellen:
>>> set virtTC_Btn1 valvePos 30  # eine Position, die sich von der error-pos
>>> unterscheidet
>>> => der virtTC_Btn1 startet seinen timer und updated den VD alle 150sec.
>>> => aenderungen des VD dauern also immer 2:30min, schneller geht nicht
>>> ++> bisher funktioniert hat
>>> 1) nach "config" uebernimmt der VD die einstellung. Man kann auch eine
>>> Zeit lang aendern
>>> 2) der VD bleibt stunden auf der einstellung, ohne auf error zu gehen
>>> 3) wenn man den virt TC ausschaltet (mit set virtTC_Btn1 valvePos off)
>>> geht der VD nach einigen Minuten auf errorPos.
>>> 4) nach einiger Zeit kann man die einstellung nicht mehr aendern, der VD
>>> wird, wenn man aendert, auf errorpos gehen
>>> 5) wenn man konifg drueckt wird der VD die aktuelle einstellung
>>> uebernehmen (natuerlich warten , bis der virtTC sendet)
>>>
>>> Gruss und viel Erfolg,
>>>
>>> Martin
>>>
>>> ps.: Wenn du traces machst bitte
>>> attr gloval verbose 1
>>> attr global mseclog 1
>>> attr loglevel 1
>>> attr hmProtocolEvents 0
>>>
>>> Und evtl ein paar kommentare
>>>
>>>  --
>>> To unsubscribe from this group, send email to
>>> fhem-users+unsubscribe@googlegroups.com
>>>
>>
>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Dienstag, 27. November 2012 23:40:18 UTC+1 schrieb Dirk:
>
> Hi Martin,
>
> nochmal ich, nach einem ausführlichen Testabend:
>
> Heute Abend habe ich den VD noch mal reseted und neu angelernt. Das Pairen
> mit dem virtTC hat nicht auf Anhieb geklappt.
>
 

> Irgendwie hatte ich das Gefühl, dass man schon da das richtige Zeitfenster
> finden muss.
>
korrekt. Das gilt fuer alles. Anlernen oder auf das Fenster warten.

> Jedenfalls ist in der Peerlist des VD nur der "virtTC_Btn1,".
>
verstehe ich nicht. Sieht doch korrekt aus. Der VD kann nur einen Peer.
Falls einer eingetragen ist musst du den erst loeschen, dann neu eintragen.

>
> Danach kann ich den VD über den virtTC gut steuern. Alles so, wie es sein
> sollte.
>
cool

>
> Dann geht aber nach ca. 1/2 Stunde der VD in den 15% Error Mode und die
> Antenne blinkt.
>
heisst er erhaelt keinen regelmaessigen trigger. Du hast sicher 15% als
error-value eingestellt (ist der default, ist einstellbar)
 

> Erst wenn ich den Taster am ganz VD kurz drücke hört die Antenne auf zu
> blinken und ich kann z.B. mit "set virtTC_Btn1 valvePos 30" den VD wieder
> "zum Leben" erwecken.
>
> Der VD scheint also irgendwie die Verbindung zum COC/virtTC zu
> verlieren... Müssten man den irgendwie wach halten/triggern?
>
Es sollten alle 150sec messags an den VD gehen, die solltest du  im Log
sehen koennen, wenn du  in CUL den loglevel auf 1 setzt.  

>
> Wo wäre denn mal ein guter Punkt zum "debuggen".
>
gute Frage. Das 'sichtbare' protokoll ist komplett nachgebaut - ich denke
das hat auch Rudi schon vor mir probiert. Das Problem ist herauszubekommen,
was man dem VD schicken muss, damit dieser aufwacht. Alles was nach FHEM
durchgereicht wird ist schon bearbeitet.

Interessant waere es, eine CUL in einen Komplett transparenten Mode zu
versetzen - rein zum Monitoren. Dann versuchen zu erfassen, was ein TC
alles sendet. Ich habe mich nicht mit den  moeglichkeiten des CUL
beschaefftigt. Im HMLAN mode ist dies nicht moeglich.
Wenn jemand weiss, wie man CUL "transparent" bekommt ist, bitte posten.

Gruss
Martin


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Das Problem ist herauszubekommen, was man dem VD schicken muss, damit dieser
> aufwacht.

Ich sehe das anders: das VD wacht in einem bestimmten unregelmaessigen
Intervall auf, und wir wissen nicht, wie man den naechsten Aufwach-Zeitpunkt
berechnet. Achtung, das ist nur eine Theorie

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Mittwoch, 28. November 2012 10:45:31 UTC+1 schrieb Rudolf Koenig:
>
> > Das Problem ist herauszubekommen, was man dem VD schicken muss, damit
> dieser
> > aufwacht.
>
> Ich sehe das anders: das VD wacht in einem bestimmten unregelmaessigen
> Intervall auf, und wir wissen nicht, wie man den naechsten
> Aufwach-Zeitpunkt
> berechnet. Achtung, das ist nur eine Theorie
>
 
hmm - kann ich nicht wiederlegen, glaube ich aber nicht. Nach Messages
kommt der Trigger vom TC, und der VD antwortet, nicht umgekehrt. Also muss
der TC wissen, wann es so weit ist. nachdem ich in den Messages keinen
Hinweis auf ein 'next awake' gefunden habe halte ich diese Theorie fuer
nicht stichhaltig.
Moerglich ist, dass entweder der VD eine nachricht schickt oder der TC -
jedenfalls ist es eine Nachricht, die weder durch die CUL noch durch HMLAN
geht - im aktuellen Mode.

Aber wo du gerade da bist (bist du ja immer)...
wie kann man eine CUL in einen transparenten Mode versetzen? Zum monitoren?
gerne auch Binaer. Der HM mode verarbeitet ha nur, was er kennt. Ich will
aber sehen, ob sonst noch etwas kommt. Senden will ich in diesem Fall
nicht.
Evtl hast du so etwas ja parat?


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich verwende auf meinem Rpi:

screen /dev/ttyAMA0 38400

Raus kommst Du da mit "Ctrl-a", ":", "quit"



Am 28. November 2012 11:27 schrieb Martin :

>
>
> Am Mittwoch, 28. November 2012 10:45:31 UTC+1 schrieb Rudolf Koenig:
>>
>> > Das Problem ist herauszubekommen, was man dem VD schicken muss, damit
>> dieser
>> > aufwacht.
>>
>> Ich sehe das anders: das VD wacht in einem bestimmten unregelmaessigen
>> Intervall auf, und wir wissen nicht, wie man den naechsten
>> Aufwach-Zeitpunkt
>> berechnet. Achtung, das ist nur eine Theorie
>>
>
> hmm - kann ich nicht wiederlegen, glaube ich aber nicht. Nach Messages
> kommt der Trigger vom TC, und der VD antwortet, nicht umgekehrt. Also muss
> der TC wissen, wann es so weit ist. nachdem ich in den Messages keinen
> Hinweis auf ein 'next awake' gefunden habe halte ich diese Theorie fuer
> nicht stichhaltig.
> Moerglich ist, dass entweder der VD eine nachricht schickt oder der TC -
> jedenfalls ist es eine Nachricht, die weder durch die CUL noch durch HMLAN
> geht - im aktuellen Mode.
>
> Aber wo du gerade da bist (bist du ja immer)...
> wie kann man eine CUL in einen transparenten Mode versetzen? Zum
> monitoren? gerne auch Binaer. Der HM mode verarbeitet ha nur, was er kennt.
> Ich will aber sehen, ob sonst noch etwas kommt. Senden will ich in diesem
> Fall nicht.
> Evtl hast du so etwas ja parat?
>
>
>  --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Achso, oder alternativ mit:

"./asksin-dumper.pl /dev/ttyAMA0"

Das Script findest Du bei den CULFW-Tools


Am Mittwoch, 28. November 2012 12:11:43 UTC+1 schrieb Dirk:
>
> Ich verwende auf meinem Rpi:
>
> screen /dev/ttyAMA0 38400
>
> Raus kommst Du da mit "Ctrl-a", ":", "quit"
>
>
>
> Am 28. November 2012 11:27 schrieb Martin
>
>>
>>
>> Am Mittwoch, 28. November 2012 10:45:31 UTC+1 schrieb Rudolf Koenig:
>>>
>>> > Das Problem ist herauszubekommen, was man dem VD schicken muss, damit
>>> dieser
>>> > aufwacht.
>>>
>>> Ich sehe das anders: das VD wacht in einem bestimmten unregelmaessigen
>>> Intervall auf, und wir wissen nicht, wie man den naechsten
>>> Aufwach-Zeitpunkt
>>> berechnet. Achtung, das ist nur eine Theorie
>>>
>>  
>> hmm - kann ich nicht wiederlegen, glaube ich aber nicht. Nach Messages
>> kommt der Trigger vom TC, und der VD antwortet, nicht umgekehrt. Also muss
>> der TC wissen, wann es so weit ist. nachdem ich in den Messages keinen
>> Hinweis auf ein 'next awake' gefunden habe halte ich diese Theorie fuer
>> nicht stichhaltig.
>> Moerglich ist, dass entweder der VD eine nachricht schickt oder der TC -
>> jedenfalls ist es eine Nachricht, die weder durch die CUL noch durch HMLAN
>> geht - im aktuellen Mode.
>>
>> Aber wo du gerade da bist (bist du ja immer)...
>> wie kann man eine CUL in einen transparenten Mode versetzen? Zum
>> monitoren? gerne auch Binaer. Der HM mode verarbeitet ha nur, was er kennt.
>> Ich will aber sehen, ob sonst noch etwas kommt. Senden will ich in diesem
>> Fall nicht.
>> Evtl hast du so etwas ja parat?
>>
>>
>>  --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Aber wo du gerade da bist (bist du ja immer)...

Wenn ich mich wg. dem Subject nicht zustaendig fuehle, lese ich es nicht mehr
durch... Aber der Raetsel mit der VD wurmt mich



> wie kann man eine CUL in einen transparenten Mode versetzen? Zum monitoren?
> gerne auch Binaer.

Was auch immer Du mit binaer meinst

SlowRF wird vom MCU (Atmel) auf dem CUL durch culfw decodiert, d.h. das CC1101
(von TI) meldet die empfangenen Flanken (Zustandswechsel von an/aus, usw) per
Interrupt. Daten so zu dekodieren geht gut bis ca 1-2kBaud, bei schnelleren
Protokollen sind die Timings (wann die Flanke vom CC1101 gemeldet wird) so
ungenau, dass es mAn sinnlos wird.  Fuer diese Methode kann man culfw so
einstellen, dass es die Flanken per USB weitersendet.

HM sendet mit 20kBaud, und hier verlassen wir uns auf dem bequemen Paketmode
des CC1101 (diesen kann man bis auf 500kBaud konfigurieren): man programmiert
das CC1101 (Frequenz, Datenrate, Modulation, etc), und man bekommt ein
Interrupt samt allen dekodierten Bytes, CRC auch schon geprueft.

Das bedeutet:

- Es gibt keinen Weg im culfw in HM-Mode mehr zu sehen, im gegenteil zu
  SlowRF, wo man sogar die Flanken ausgeben kann.

- Ich glaube auch nicht, dass irgendetwas (bis auf WOR) in HM gesendet wird,
  was culfw nicht sehen kann, aber die anderen HM Komponenten. Diese verwenden
  schliesslich auch das CC1101 in Paketmode, es waere verrueckt daneben was
  anderes (SlowRF/Frequenzwechsel/etc) zu programmieren.

Aber das zu bestaetigen waeren Hardware-Yogis gefragt, um die Konfiguration der
CC1101 der VD oder TC per SPI auszulesen, oder mit besseren Hardware die
Flanken auch bei 20kHz darstellen zu koennen.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Sicher scheint zu sein, dass nach Anlernen ein Befehl akzeptiert wird.....
> ich teste weiter..

Beruhingend (oder auch nicht , das habe ich naemlich auch hingekriegt.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com