HM-CC-TC Temperatur einstellen

[Guest]

Originally posted by: <email address deleted>

Gleich mal eine Frage - wenn du einen Registerwert aenderst - antwortet
>> dann TC automatisch und schickt die neue Regliste zurueck? Kann ich mal
>> einen Log sehen, wenn du einen Wert aenderst?
>>
>
> Reicht dir das?
>

ja danke.
 

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

[Guest]

Originally posted by: <email address deleted>

Hallo!

Nach updatefhem sehe ich, dass sich einiges getan hat. Sieht interessant
aus. Endlich kann ich meine TCs auch als climate-control definieren.

Allerdings habe ich den Eindruck, dass jetzt gar keine Befehle mehr an die
TCs gesendet werden. Sowohl nach set desired-temp als auch nach templistxxx
sehe ich kein SND (weder Wakeup noch der eigentliche Befehl) im
Eventmonitor. Die Temperatur am Gerät ändert sich auch nicht. Muss ich da
noch was anpassen?

Gruß

Carsten

Am Sonntag, 30. September 2012 08:43:28 UTC+2 schrieb Martin:
>
>
>
> Gleich mal eine Frage - wenn du einen Registerwert aenderst - antwortet
>>> dann TC automatisch und schickt die neue Regliste zurueck? Kann ich mal
>>> einen Log sehen, wenn du einen Wert aenderst?
>>>
>>
>> Reicht dir das?
>>
>
> ja danke.
>  
>

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

[Guest]

Originally posted by: <email address deleted>

Carsten

zum einen muss die Zeile
  my $isSender = ($class eq "sender" || $md eq "HM-CC-TC");
geaendert werden in
  my $isSender = ($class eq "sender");

Damit wird der command stack dann wie bei allen devices ueber die HMclass
gesteuert. Sollte aber noch kein Problemdarstellen, da es schon immer so
war.

Wenn du einen trace einbaust musst du pruefen, ob es den Wert auch gibt.
Ob commands im Stack haengen kann man ueber protCmdPend sehen (protocol -
command pending). Hier staht die Anzahl. Die Variable ist immer im device
(bei TC warscheinlich nur eines).

Die Abfrage nach dem Stack ist schon ok. Der Stack selbst funktioniert auch
einwandfrei. Wenn du eine Fernbedienung hast, kannst du es sehr schoen
verfolgen - Kommandos werden gestackt und bei Anlernen ausgegeben.

Das Problem sollte also nur TC betreffen.

Wenn du einen trace eibaust dann in
sub
CUL_HM_PushCmdStack($$)
als letzte zeile
Log 1,"CmdStack Entries:".$entries." for:".$hash->{NAME};


und einen 2. beim leeren des Stack:

CUL_HM_ProcessCmdStack($)
# vor dem return
Log 1,"CmdStack ".(($hash->{cmdStack})?"empty":"avaliable ")."
for:".$hash->{NAME};

btw: hmClass steht doch jetzt sender - oder?

Martin

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

[Guest]

Originally posted by: <email address deleted>

Carsten

 auf die schnelle empfehle ich die folgende Zeile einzubauen, s.u.
Ich gehe davon aus, dass die "8670" immer noch alle 5 min von TC kommt und
verarbeitet wird - korrekt?

    $sendAck = ""; #todo why is this special?
    *CUL_HM_ProcessCmdStack($shash);*
  }
  elsif($model eq "HM-CC-VD") { ###################

Bitte Ergebnisse und Traces

Danke
Martin

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

[Guest]

Originally posted by: <email address deleted>

Hallo,

danke erstmal für Deinen Einsatz!

Da ich heute und morgen erst relativ spät zu Hause sein werde, weiß ich
noch nicht, wann ich zum Testen komme. Im Moment läuft übergangsweise
wieder die alte Version.

Fernbedienung habe ich bisher keine. Zur Zeit nur die TCs, VDs und ein
Relais. Das Relais funktioniert auch weiterhin problemlos.

Ich hatte gestern noch gesehen, dass er bei den TCs scheinbar nie in das
ProcessCmdStack läuft, sondern scheinbar nur bei den -VDs, für die der
Stack natürlich leer ist.
Daraufhin habe ich ans Ende der parseCommon-Funktion noch ein elsif($msgType
eq "70" ) eingefügt und darin ein ProcessCmdStack getriggert um auf die
8670 - Meldungen zu reagieren. Die kommen alle ~2 Minuten.

Daraufhin wurden dann auch wieder Telegramme an die TCs gesendet, von denen
allerdings kein einziges verarbeitet wurde. Aufgrund der fortgeschrittenen
Stunde habe ich das Testen dann erstmal eingestellt, aber die Telegramme
kamen mir teilweise "seltsam" vor. Mit seltsam meine ich, dass vor lauter
Log-Messages mein Log zu dem Zeitpunkt nur noch schwer lesbar war, ich aber
meine, dass zwischendurch trotz Ack des -TCs mit der Meldung Missing-Ack
abgebrochen wurde.

Es wurden auch Resend-Versuche geloggt, die in der alten Version für den
HMLAN ausgeklammert waren, weil laut Rudi der LAN-Adapter selbst schon
Resends vornimmt.

Ich hoffe, dass ich heute Abend vielleicht doch noch ein Stündchen zum
Weitertesten finde, denn ansonsten sieht die neue Version gut aus.

Gruß

Carsten

Am Montag, 1. Oktober 2012 09:36:35 UTC+2 schrieb Martin:
>
> Carsten
>
>  auf die schnelle empfehle ich die folgende Zeile einzubauen, s.u.
> Ich gehe davon aus, dass die "8670" immer noch alle 5 min von TC kommt und
> verarbeitet wird - korrekt?
>
>     $sendAck = ""; #todo why is this special?
>     *CUL_HM_ProcessCmdStack($shash);*
>   }
>   elsif($model eq "HM-CC-VD") { ###################
>
> Bitte Ergebnisse und Traces
>
> Danke
> Martin
>

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

[Guest]

Originally posted by: <email address deleted>

Hallo,



> Da ich heute und morgen erst relativ spät zu Hause sein werde, weiß ich
> noch nicht, wann ich zum Testen komme. Im Moment läuft übergangsweise
> wieder die alte Version.
>

klar - sorry

>
>
> Ich hatte gestern noch gesehen, dass er bei den TCs scheinbar nie in das
> ProcessCmdStack läuft, sondern scheinbar nur bei den -VDs, für die der
> Stack natürlich leer ist.
>

Kommandos gehen bis auf ACKs alle in den Stack - alle devices. Nur
ausnahmen (Acks..) duerfen ueberholen.

Daraufhin habe ich ans Ende der parseCommon-Funktion noch ein elsif($msgType
> eq "70" ) eingefügt und darin ein ProcessCmdStack getriggert um auf die
> 8670 - Meldungen zu reagieren. Die kommen alle ~2 Minuten.
>

2 min ist schnell. Ich habe einen trace erhalten mit 5 min. Das passt zu
den Info, die ich habe (600sec). Noch habe ich nicht gesehen, dass es
einstellbar ist. => welche FW hat dein TC?

>
> Daraufhin wurden dann auch wieder Telegramme an die TCs gesendet, von
> denen allerdings kein einziges verarbeitet wurde. Aufgrund der
> fortgeschrittenen Stunde habe ich das Testen dann erstmal eingestellt, aber
> die Telegramme kamen mir teilweise "seltsam" vor. Mit seltsam meine ich,
> dass vor lauter Log-Messages mein Log zu dem Zeitpunkt nur noch schwer
> lesbar war, ich aber meine, dass zwischendurch trotz Ack des -TCs mit der
> Meldung Missing-Ack abgebrochen wurde.
>

missing-ACK loescht den Stack, dann ist Schluss.
Dass der Einbau des processCmdStack zum senden der Messages gefuehrt hat
beseutet, dass der TC den Stack benutzt  - muss ja...
Der passende Platz zum Einbau waere dann aber im parse TC nach cmd eq
'8670'.


> Es wurden auch Resend-Versuche geloggt, die in der alten Version für den
> HMLAN ausgeklammert waren, weil laut Rudi der LAN-Adapter selbst schon
> Resends vornimmt.
>

Moeglich, dass es auch einen resend im LAN adapter gibt, kann ich nicht
sehen (und in den HMlan habe ich mich nicht eingearbgeitet).
Sicher ist, dass in meinem Setup das resend mit unter zum Erfolg fuehrt. Es
sollte unbedingt an sein - ueber Timer und Anzahl der Wiederhohlungen kann
man diskutieren

Evtl bekomme ich ein leih-TC  - dann wird es mit dem Testen einfacher fuer
mich

Nebenbei: bei welchen devices welche Kommandos 'postponed' werden muessen
und wann das Senden starten sollte ist noch in Untersuchung. Da ist noch
ein RC19 und andere devices nicht fertig getestet.

Gruss
Martin

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

[Guest]

Originally posted by: <email address deleted>

Am Montag, 1. Oktober 2012 12:19:15 UTC+2 schrieb Martin:
>
> Hallo,
>
>
>
>> Da ich heute und morgen erst relativ spät zu Hause sein werde, weiß ich
>> noch nicht, wann ich zum Testen komme. Im Moment läuft übergangsweise
>> wieder die alte Version.
>>
>
> klar - sorry
>

Sorry? Weils noch nicht läuft? Kein Grund. Ich bin mehr als froh, dass sich
jemand mit Plan der Sache annimmt.
 

>
>>
>> Ich hatte gestern noch gesehen, dass er bei den TCs scheinbar nie in das
>> ProcessCmdStack läuft, sondern scheinbar nur bei den -VDs, für die der
>> Stack natürlich leer ist.
>>
>
> Kommandos gehen bis auf ACKs alle in den Stack - alle devices. Nur
> ausnahmen (Acks..) duerfen ueberholen.
>

Ja, aber an die Stellantriebe sendet fhem (bei mir) keine Kommandos. Das
übernimmt der TC. Daher ist der Stack für die VDs immer leer.
 

>
> Daraufhin habe ich ans Ende der parseCommon-Funktion noch ein elsif(
>> $msgType eq "70" ) eingefügt und darin ein ProcessCmdStack getriggert um
>> auf die 8670 - Meldungen zu reagieren. Die kommen alle ~2 Minuten.
>>
>
> 2 min ist schnell. Ich habe einen trace erhalten mit 5 min. Das passt zu
> den Info, die ich habe (600sec). Noch habe ich nicht gesehen, dass es
> einstellbar ist. => welche FW hat dein TC?
>

Laut fhem ist die FW 2.1. Bei Inbetriebnahme habe ich nur drauf geachtet,
dass Sie > 2 sind, wegen des Bugs. Ich hab irgendwas von 120 - 180 Sekunden
in Erinnerung. Ich hab gerade mal mit dem Handy zugeschaut. 2:53 Minuten
zwischen zwei 8670er-Meldungen im Badezimmer. Im fhemwiki steht auch 2
Minuten. Eingestellt habe ich da aktiv nichts.


>> Es wurden auch Resend-Versuche geloggt, die in der alten Version für den
>> HMLAN ausgeklammert waren, weil laut Rudi der LAN-Adapter selbst schon
>> Resends vornimmt.
>>
>
> Moeglich, dass es auch einen resend im LAN adapter gibt, kann ich nicht
> sehen (und in den HMlan habe ich mich nicht eingearbgeitet).
> Sicher ist, dass in meinem Setup das resend mit unter zum Erfolg fuehrt.
> Es sollte unbedingt an sein - ueber Timer und Anzahl der Wiederhohlungen
> kann man diskutieren
>

Wie gesagt, ich habe mal irgendwo (u.a. auch im alten Source des CUL_HM )
gelesen, dass der LAN-Adapter ( also das Hardwareteil ) selbst 1-3 Retrys
macht, ohne auf LAN-Seite darüber Feedback zu geben. Außerdem werden wohl
Resends von fhem ignoriert, wenn sie identisch mit dem vorherigen cmd sind.
Also Dublettenprüfung.

 

>
> Evtl bekomme ich ein leih-TC  - dann wird es mit dem Testen einfacher fuer
> mich
>

Ist das eine Info oder eine Anfrage?

Ich könnte mal mit meiner Schatzmeisterin darüber reden, einen der noch
fehlenden TCs schon jetzt zu ordern und per Umweg über dich laufen zu
lassen. Bzw. wo bist du denn wohnhaft?
 
Gruß

Carsten

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

[Guest]

Originally posted by: <email address deleted>

Am Montag, 1. Oktober 2012 09:36:35 UTC+2 schrieb Martin:
>
> Carsten
>
>  auf die schnelle empfehle ich die folgende Zeile einzubauen, s.u.
> Ich gehe davon aus, dass die "8670" immer noch alle 5 min von TC kommt und
> verarbeitet wird - korrekt?
>
>     $sendAck = ""; #todo why is this special?
>     *CUL_HM_ProcessCmdStack($shash);*
>   }
>   elsif($model eq "HM-CC-VD") { ###################
>
> Bitte Ergebnisse und Traces
>
> Danke
> Martin
>

Hallo nochmal,

kurze Rückmeldung:

Habe die vorgeschlagene Änderung vorgenommen und gerade nochmal ein bißchen
rumgetestet. Da die cmds erfahrungsgemäß aber nur nach einem 8670-Event
angenommen werden, habe ich das ProcessCmdStack in eben diesen Zweig
verschoben.

Jetzt funktioniert die Kommunikation wieder ungefähr so zuverlässig ( ca.
50:50 ) wie vorher.

Nach meinen Beobachtungen hat bei mir bisher noch kein Resend funktioniert.
Bisher kam entweder das erste cmd an oder es folgten Resend Nr 2, Resend
Nr.3 und dann Missing_Ack.

An einigen Stellen verhält sich das System unerwartet.

Es kam z.B. vor, dass der Stack für ein TC irgendwie gar nicht mehr
abgearbeitet wurde, während der andere funktionierte. Nach shutdown restart
lief es wieder. Als ob sich der cmdstack aufgehängt hätte.

Außerdem wundert mich sowas hier:

2012-10-02 00:48:43 HMLAN HMLAN1 RCV L:0C N:F1 F:86 CMD:70 SRC:wz_Heizung
DST:broadcast 00CE3D (WeatherEvent TEMP:20.6 HUM:61) (,WAKEMEUP,BCAST,RPTEN)
2012-10-02 00:48:43 HMLAN HMLAN1 SND L:09 N:1B F:A1 CMD:12 SRC:CB0906
DST:wz_Heizung (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2012-10-02 00:48:43 CUL_HM wz_Heizung T: 20.6 H: 61
2012-10-02 00:48:43 CUL_HM wz_Heizung measured-temp: 20.6
2012-10-02 00:48:43 CUL_HM wz_Heizung temperature: 20.6
2012-10-02 00:48:43 CUL_HM wz_Heizung humidity: 61
2012-10-02 00:48:45 CUL_HM wz_Heizung resend nr 2
2012-10-02 00:48:47 HMLAN HMLAN1 SND L:10 N:1C F:A0 CMD:01 SRC:CB0906
DST:wz_Heizung 02050000000005 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000
PEER_CHANNEL:00 PARAM_LIST:05) (,BIDI,RPTEN)
2012-10-02 00:48:47 CUL_HM wz_Heizung MISSING ACK
2012-10-02 00:49:03 HMLAN HMLAN1 RCV L:0B N:F1 F:A2 CMD:58 SRC:wz_Heizung
DST:wz_Stellantrieb 0000 (ClimateEvent CMD:00 ValvePos:0)
(,WAKEMEUP,BIDI,RPTEN)
2012-10-02 00:49:03 CUL_HM wz_Heizung actuator: 0 %
2012-10-02 00:49:03 HMLAN HMLAN1 RCV L:0E N:F1 F:82 CMD:02
SRC:wz_Stellantrieb DST:wz_Heizung 0101000034 (ACK_STATUS CHANNEL:01
STATUS:00 UP:0 DOWN:0 LOWBAT:0 RSSI:-52) (,WAKEMEUP,RPTEN)

fhem sendet ein wakeup, versucht es noch ein zweites Mal und ohne, dass ein
Ack vom TC auftaucht, wird versucht, das Cmd abzusetzen. Danach dann ein
Missing Ack, von dem ich nicht weiß ob er zum Wakeup oder zum Wert gehört.

Das muss ich mir aber nochmal mit mehr Zeit in Ruhe anschauen. Jedenfalls
funktioniert die neue Version bei mir jetzt mindestens so gut wie die alte
und darf darum jetzt live bleiben.

Vielen Dank für Deine Unterstützung!

Gruß

Carsten

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

[Guest]

Originally posted by: <email address deleted>

Hallo Carsten,

habe inzwischen gelernt welche rx_modes es bei HM gibt
TC reagiert auf config und auf wakeup.

Config und wakeup glaube ich mittlerweile zu verstehen und kann es einbauen
(reparieren)
Ausserdem werde ich einen entsprechenden Parameter einfuehren - TC ist da
ja kein Einzelfall. Die Steuerung wird demnach voraussichtlich in den
common Bereich wandern.


Dann gibt es noch "burst" - z.B. bei winmatic, keymatic und smoke detector.
Wie burst funktioniert weiss ich noch nicht.... tips?

Gruss
Martin

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

[Guest]

Originally posted by: <email address deleted>

Hallo,

habe inzwischen gelernt welche rx_modes es bei HM gibt
> TC reagiert auf config und auf wakeup.
>
> Config und wakeup glaube ich mittlerweile zu verstehen und kann es
> einbauen (reparieren)
> Ausserdem werde ich einen entsprechenden Parameter einfuehren - TC ist da
> ja kein Einzelfall. Die Steuerung wird demnach voraussichtlich in den
> common Bereich wandern.
>

Das klingt vielversprechend! Wenn ich irgendwie hilfreich sein kann, sag
Bescheid.
 

>
> Dann gibt es noch "burst" - z.B. bei winmatic, keymatic und smoke
> detector. Wie burst funktioniert weiss ich noch nicht.... tips?
>
>
Habe bisher keins dieser Geräte. Rauchmelder sollen irgendwann mal kommen.

Das einzige, was ich dazu kenne ist dieser Eintrag in den ELV-FAQs:
http://www.elv.de/controller.aspx?cid=824&detail=10&detail2=3516

Aber ich nehme an, da bist du schon weiter.

Gruß

Carsten

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

[Guest]

Originally posted by: <email address deleted>

Hallo!

Seit update fhem gestern(was ich nie wieder tun werde) was ja viele
Änderungen in Sachen Fhem und HM-CC-TC  gebracht hatte, nimmt mein HM-CC-TC
keine befehle entgegen und reagiert nicht mehr auf befehle von Fhem:-(.
Vor dem Update lief wirklich alles super und jetzt leider gar nichts mehr,
habe schon ein Reset durchgeführt und neu gepairt, wird auch gefunden und
das wars dann:-(
Habe mal ein Bild vom HM-CC-TC angehängt nach dem update, vielleicht hat ja
jemand eine Ahnung warum es jetzt so verrückt spielt???
Mfg Steffen

<https://lh4.googleusercontent.com/-GvqFIHYecjs/UGsxIHXI8PI/AAAAAAAAABE/a4cEKP3HoJ0/s1600/Hm-cc-tc.JPG>

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

[Guest]

Originally posted by: <email address deleted>

...updatefhem sollte doch ein Backup angelegt haben.

Spiel das doch einfach wieder ein

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

[Guest]

Originally posted by: <email address deleted>

danke, so habe ich es gemacht und schon ist wieder alles in Ordnung...

nie wieder updatefhem;-)

Am Dienstag, 2. Oktober 2012 20:37:41 UTC+2 schrieb dou...@m1n1.de:
>
> ...updatefhem sollte doch ein Backup angelegt haben.
>
> Spiel das doch einfach wieder ein
>

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

[Guest]

Originally posted by: <email address deleted>

Hallo Carsten,

anbei eine neue Version - kannst du sie mal testen?
Bei meinem leih-TC funktioniert es mit Anlernen sehr gut - aber mit wakeup
schlecht. Auch die alten Versionen gehe nicht gut - und selbst HM windows
SW hat viele Probleme
Wenn du den "normalzustand" abnehmen kannst, versuche ich darauf aufzubauen

Gruß
Martin

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

[Guest]

Originally posted by: <email address deleted>

Die vielen Wiederholungen sind nur zum test, die bleiben nicht!

Am Mittwoch, 3. Oktober 2012 19:45:33 UTC+2 schrieb Martin:
>
> Hallo Carsten,
>
> anbei eine neue Version - kannst du sie mal testen?
> Bei meinem leih-TC funktioniert es mit Anlernen sehr gut - aber mit wakeup
> schlecht. Auch die alten Versionen gehe nicht gut - und selbst HM windows
> SW hat viele Probleme
> Wenn du den "normalzustand" abnehmen kannst, versuche ich darauf aufzubauen
>
> Gruß
> Martin
>

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