HM-CC-TC: desired-temp Problem im controlMode: auto

[Billy]

Hallo zusammen,

ich habe ca. 1mal die Woche ein Fehlverhalten im Zusammenhang mit den HM-CC-TC im Control-Mode auto..

Folgende Ausgangssituation:

- Ich betreibe 8 HM-CC-TC mit 12 HM-CC-VD über 1 HMLAN gepairt mit FHEM.
- 6 HM-CC-TC werden im Mode-auto und 2 im Modus central betrieben
- die 6 HM-CC-TC spulen ihre (desired-temp) tempList Mo - So im Normalfall problemlos ab (auto-mode)
  und stellen die HK-Ventile autonom!
- FHEM lauscht über den HMLAN (nach meinem Verständnis) nur mit, übernimmt die Werte und erstellt die Plots.

- Ab und zu tritt jedoch folgendes Problem auf:
  Obwohl der HM-CC-TC eine geänderte "desired-temp" absetzt ( erkennbar an der zeitgerechten Änderung der
  Ventilstellung) wird diese neue "desired-temp" in FHEM nicht erkannt!
  d.h. der entsprechende Log-Eintrag fehlt!!!
  Dieses Verhalten wechselt von TC zu TC.
Im Anlagen Dokument habe ich versucht das zu verdeutlichen.

Meine Frage hier: Ist das auch bei anderen Usern so?
                  Kann es sein, dass sich der HMLAN verschluckt wenn mehrere HM-CC-TC gleicdhzeitig
                  eine neue "desired-temp" absetzten.

Die Situation ist insofern ärgerlich, da ich das Modul HCS Waermebedarf einsetze, das auf den "desired-temp"
aufsetzt.

Hat einer von euch das auch und evtl. schon eleganter gelöst? (Die desired-temp aus der TempList sind FHEM ja bekannt!)


Vielen Dank

Gruß
Billy

[Rohan]

Hallo Billy,

... Hat einer von euch das auch ...

Zur Problemeingrenzung: Nein. Ich setze aber (bisher) auch noch kein HCS ein (weil ich meine Therme noch nicht direkt steuern kann [Buderus GB112W]).

Gruß
Thomas

[martinp876]

Hallo Billy,

es ist möglich, dass messages verloren gehen - wie wahrscheinlich dies ist kann ich nicht sagen.
Die einzige Möglichkeit dies herauszufinden ist, die Messages zu monitoren. Der Plot bringt hier keinen weiter.

Du solltest die messages aus HMLAN roh monitoren - dann koennen wir versuchen festzustellen ob diese gemeldet wurden und wie der zeitliche zusammenhang ist.

Wenn ein wert fehlt kannst musst du die Zeit angeben, wann es ist - dann kann man das log prüfen

Gruss
Martin

[Rohan]

Hallo Martin,

es ist möglich, dass messages verloren gehen -

Wie äußert sich das? Durch MISSING ACKs?

Die einzige Möglichkeit dies herauszufinden ist, die Messages zu monitoren.

Wie geht das, was muss man dafür tun, einstellen?

Du solltest die messages aus HMLAN roh monitoren

Wie macht man das: "roh monitoren"?

Und bitte! Nicht von Programmierer zu Programmierer, sondern von Anwender zu Anwender.

Also bitte vollständige Beispiele/Befehle und nicht Sequenzen, denn das ist für mich ein häufiges Problem. Die commandref ist eine Referenz, nicht weniger, aber auch nicht mehr, vor allem kein Lernbuch.

Danke!

Gruß
Thomas

[Billy]

Hallo Martin, hallo Thomas danke für die Antworten.

@ Martin:

es ist möglich, dass messages verloren gehen - wie wahrscheinlich dies ist kann ich nicht sagen.
Die einzige Möglichkeit dies herauszufinden ist, die Messages zu monitoren. Der Plot bringt hier keinen weiter.

Ich wollte mit dem Plot nur das Problem aufzeigen!

Du solltest die messages aus HMLAN roh monitoren - dann koennen wir versuchen festzustellen ob diese gemeldet wurden und wie der zeitliche zusammenhang ist.

Hier geht es mir wie Thomas? Wie macht man das: "roh monitoren"?

@ Thomas

martinp876 schrieb am Mo, 21 Januar 2013 22:00
es ist möglich, dass messages verloren gehen -
Wie äußert sich das? Durch MISSING ACKs?

Glaube ich in diesem Fall nicht, da der HMLAN ja nur mithört, aber vielleicht weis Martin da mehr?

Man könnte die Problematik für die Weiterverarbeitung in HCS ja auch umgehen indem man die "desired-temp" bei Abweichung
zur vorhandenen TempList aus dieser übernimmt. Anregung für Martin Fischer?

Gruss
Billy

[martinp876]

Hier geht es mir wie Thomas? Wie macht man das: "roh monitoren"?

attr global verbose 1
attr global mseclog 1
attr <hmlan> loglevel 1

logs stehen dann im zentralen logfile

@ Thomas

martinp876 schrieb am Mo, 21 Januar 2013 22:00
es ist möglich, dass messages verloren gehen -
Wie äußert sich das? Durch MISSING ACKs?

Glaube ich in diesem Fall nicht, da der HMLAN ja nur mithört, aber vielleicht weis Martin da mehr?

das werden die Logs zeigen


Gruss
Martin

[Billy]

Danke Martin

Hier geht es mir wie Thomas? Wie macht man das: "roh monitoren"?

attr global verbose 1
attr global mseclog 1
attr <hmlan> loglevel 1

logs stehen dann im zentralen logfile

Habe die o.a. attr eingestellt.
Werde mich melden wenn der Fehler sich zeigt. Wie gesagt im Schnitt nur 1-2 mal pro Woche.

Gruss Billy

[Billy]

Hallo Martin,

es ist soweit, heute um 15:00 ist wieder der beschriebene Fehler aufgetreten.

Hier die Device Daten!

model   HM-CC-TC
NAME    OG_KU
DEF   1A7D0F
desired-temp Ist 19.5
desired-temp SOLL 20.0  --> ab 15:00 wurde nicht übernommen, VD hat jedoch reagiert!
TempList (Auszug) OG_KU_Climate 15:00 19.5 22:00 20.0 24:00 18.0

Das zugehörige Log ist in der Anlage.

Die übrigen Devices 1CE600 EG_BU 1A7985 EG_SZ 1D94AE OG_BA 1A7AC1 OG_WZ_Climate
haben zur selben Zeit problemlos ihre neue "desired Temp" in FHEM übernommen.
Falls noch was fehlt bitte melden.

Danke
Billy

[martinp876]

Hallo Billy,

dein OG_KU hat keine Meldung ueber eine geaenderte Temp and die Zentrale gesendet - jedenfalls wurde keine empfangen. Ganz im Gegensatz zu
19E3E7 (hast du nicht erwaehnt) und OG_WZ.

Das stellen des VD ist eine Aktion, das Reporten der geaenderten desired-temp eine völlig andere.
Der VD weiss nichts über temperaturen - nur über stellwerte. Daher kannst du nur indirekt auf temperaturen schliessen. Der Stellwert wird sich auch aendern, wenn du das Fenster aufnachst und es kalt wird... ist eben eine Regelung.

Sorry, da kann ich nichts machen - wenn nichts kommt kann ich nichts auswerten.

Gruss
Martin

[Billy]

Danke Martin für deine Antwort!

Hallo Billy,

dein OG_KU hat keine Meldung ueber eine geaenderte Temp and die Zentrale gesendet - jedenfalls wurde keine empfangen. Ganz im Gegensatz zu
19E3E7 (hast du nicht erwaehnt) und OG_WZ.

19E3E7 habe ich nicht erwaehnt, da er nicht um 15:00 sendet, sondern um 15:10!
Die anderen und auch OG_WZ senden um 15:00!!!

Das stellen des VD ist eine Aktion, das Reporten der geaenderten desired-temp eine völlig andere.

Ist mir klar. Nach dem aber um 15:00 keine Temperaturänderung im Raum war, der VD aber sprunghaft geöffnet wurde,
gehe ich davon aus, dass der TC zwar gesendet hat, aber der HMLAN nicht empfangen!
Der Effekt tritt ja nur auf, wenn mehrere TC's zur gleichen Zeit eine neue "desired-temp" anfordern.
Bei mir um 15:00 sind es gleichzeitig 5 TC's. Könnte also so was wie ein Überlagerungseffekt sein,
der den HMLAN Empfang stört? --> Seitdem ich den 19E3E7 vor einer Woche auf 15:10 gestellt habe hat er übrigens immer funktioniert!

Sorry, da kann ich nichts machen - wenn nichts kommt kann ich nichts auswerten.
Gruss Martin

Trotzdem nochmals vielen Dank für deine Mühe.
Vielleicht hilfts ja mal auch anderen bei der Fehlersuche.

Gruss Billy

[martinp876]

Ist mir klar. Nach dem aber um 15:00 keine Temperaturänderung im Raum war, der VD aber sprunghaft geöffnet wurde,
gehe ich davon aus, dass der TC zwar gesendet hat, aber der HMLAN nicht empfangen!
Der Effekt tritt ja nur auf, wenn mehrere TC's zur gleichen Zeit eine neue "desired-temp" anfordern.
Bei mir um 15:00 sind es gleichzeitig 5 TC's. Könnte also so was wie ein Überlagerungseffekt sein,

moeglich dass alle die temp aendern. Zu sehen ist aber nur von einem TC etwas, 10 min vom 2.  
Dass es ein Bug im HMLAN ist kann ich nicht ausschließen - aber eine verwertbare Spur ist nicht zu sehen, kein Abbruch oder Fehler ....
Leider sind auch keine parameter zur Anzahl der Wiederholungen des TC bekannt. Bei anderen kann man die Wiederholungen einstellen, keine Ahnung ob diese message überhaupt wiederholt wird.

Gruss
Martin