HM-CC-RT-DN

[betateilchen]

die Kommunikation funktioniert nur unzuverlässig. Manchmal geht's, manchmal nicht. Einigermaßen sicher ist die Kommunikation nur, wenn ich die Anlerntaste drücke.

Hast Du denn auch lange genug gewartet? Die Änderung nach einem set desired-temp wird ja ohne burst eben nicht sofort übertragen. Das kann schonmal ein paar Minuten dauern und solange bleibt der Befehl als CMD_pending. Mit dem Drücken der Anlerntaste unterbrichst Du quasi nur die Wartezeit bis zum nächsten Datenaustausch zwischen fhem und dem device.

[BuRi]

Hallo,

woran es liegt weiß ich nicht, aber jetzt habe ich ein neues Problem, das auch reproduzierbar ist. Ich habe im WZ zwei solcher Thermostate, die nur über fhem gepairt sind. Nun habe ich mir eine Funktion geschrieben die die Temperaturen für die verschiedenen Wochentage setzt. Beim ersten Aufruf wurden in jedem Thermostat nur die ersten 5 Tage (Montag bis Freitag) gesetzt. Beim zweiten Thermostat konnte ich die beiden fehlenden Tage problemlos manuell setzen.
Beim ersten Thermostat gibt es allerdings das folgende Problem: Setze ich Samstag, so wird Sontag auf die Default-Einstellung gesetzt. Setze ich Sonntag wird Samstag auf Default-Einstellung gesetzt. Alle Bemühungen halfen bisher nicht. Außerdem wurde die desired-Temperatur mal zwischendrin auf 12 Grad gesetzt. Irgendetwas funzt da nicht richtig. Hat einer eine Idee?

Gruß

BuRi

[betateilchen]

Ist denn die tempList softwareseitig in den RT überhaupt schon implementiert?

@martin: Könntest Du mal kurz einen aktuellen Status geben, was bisher schon funktionieren sollte? Sich das hier aus den verschiedenen Threads zusammenzuklauben ist sehr mühsam.

[BuRi]

Hallo,

wie geschrieben, es funktioniert bei einem Device und bei dem anderen gibt es diese Merkwürdigkeiten.
Scheinbar ist es also implementiert. Man kann ja im Kanal 4 unter set nachschauen,
was alles geht. Es gibt ja nun auch desired-temp.

Gruß

BuRi

[martinp876]

so einmal zusammenfassen
Version 3948 gerade abgegeben. Bitte file 10_CUL_HM UND HMConfig holen. ggf auch 98_HMinfo

- das setzen der Register sollte funktionieren (auch templist)
- das setzen desired-temp funktioniert auch mit 12 (ohne komma). hat schon immer. komma zahlen haben eh einen '.', kein ','
- conditional-burst funktioniert. man kann also das Register burstRX setzen, ab dann reagiert das Device "sofort". Natürlich wird das regSet burstRx noch im alten mode ausgeführt. bis es dann soweit ist kann es die üblichen 3 min dauern
- bei devices die conditional burst unterstützen wird der "burstability-state" in protCondBurst dargestellt
- conditional-burst wirs automatisch erkannt
- supported wird es von rt, tc und verschiedenen wds devices

Die testphase ist noch nicht lang gewesen - ganz zufrieden bin ich selbst noch nicht.

Fragen:
- nutzt einer heating-control? geht dies?

Gruss Martin

[rabe]

Hallo,
vielen Dank, Martin für die neue Version 3948 !
Ich habe diese gerade mal getestet. Die Kommunikation im noBurst mode und im Burst Mode sind viel
stabiler geworden. Im Burst Mode habe ich keine Fehlkommunikationen mehr.
Jedoch ist mir eine Sache aufgefallen:
Ich habe vom Burstmode mit XX regSet burstRx off wieder zurückgeschaltet (was auch wie erwartet
funktioniert hat), jedoch war ich dann nicht mehr in der Lage mit XX regSet burstRx on den Burst
Modus wieder einzuschalten. Ich bekomme dann reproduzierbare Übertragungsfehler und das Attribut wird nicht auf on gesetzt. Habe das mehrfach versucht. Dann habe ich fhem neu gestartet und XX regSet burstRx on hat auf Anhieb funktioniert.
Gruß Ralph

[BuRi]

Hallo,
mal ne ganz dumme Frage, wo bekomme ich denn die neuste Version her?
Ich mach Updates normalerweise direkt in Fhem, aber dort liegt die neuste Version noch nicht vor.

Danke schon mal für die Info.

Burchard

[rabe]

Hallo,
die aktuellen Versionen sind auf SourceForge. Siehe
http://sourceforge.net/p/fhem/code/HEAD/tree/
Im trunk findest Du Martins aktuelle Versionen.
Gruß Ralph

[martinp876]

Hallo Ralph,

der Parameter protCondBurst hat einen Fehler. Das Register setzen hat bei mir funktioniert.

protCondBurst ist ein 'empirisch' ermittelter Wert. wird immer beim Senden ermittelt und ist zur Info.
R_burstRx ist der Wert aus dem Device gelesen.
FHEM verknüpft die werte nicht.

Frage: hat das aendern von burstRx versagt oder war protCondBurst falsch?

Gruss Martin

[rabe]

Hallo Martin,
dass protCondBurst zwischen on und off hin und her springt habe ich auch bemerkt.
Irritiert hat mich, dass es auch nach dem Sendestart auf on steht, obwohl der Burstmode (also ich meine
den Wert von burstRx) auf off steht.

Zu Deiner Frage: was ich meine ist dass das Ändern von burstRx versagt hat. Ich habe mehrfach versucht das
Attribut zu setzen, das hat aber nicht geklappt (auch nach erneuten auslesen mit getconfig blieb es off).
Von den 3 cmds die beim Setzen dieses Attributes ausgelöst wurden, ist eines immer fehlgeschlagen.
Ich kann nicht sagen welches, da ich mich noch nicht systematisch durch die Logs gewühlt habe.

Gruß Ralph

[rabe]

Hi noch eine Frage,
gibt es schon eine Chance über den Browser (FhemWeb) die Änderung der desired-temp über das Pull-down Menü vorzunehmen, so wie das
bei HM-CC-TC auch funktioniert. Oder ist das noch Future Work?
Ich habe das mit "attr XX webCmd desired-temp" probiert, aber das Menü zur Temperatureinstellung wird nicht angezeigt.

Gruß Ralph

[RedOne]

hallo konnte mir jemand sagen wie ich die Datei installiere bin noch relativ neu in der Sache.
MFG
RedOne

[martinp876]

hallo Ralph,

es gibt V 3950.
da sollte protoCondBurst korrekt stehen.
ausserdem hat jedes kommando mit einem Parameter ein pull-down menue (falls es kein frei wählbarer Wert ist)

falls du vom Problem einfach die rohmessages schicken kannst...
ich habe am tc probiert, konnte hin und her schalten. rt muss ich noch...

Gruss Martin

[betateilchen]

Code Auswählen Erweitern

R-decalcTime 660.660660660661 min

sieht lustig aus :)

Vorhin hab ich schonmal die  ganzen Register im Device gesehen, auch R-burstRx. Aber ändern konnte ich das mit regSet nicht.
Jetzt sehe ich nichtmal mehr die Register. Irgendwie verweigert der RT grade die Kommunikation - obwohl gepairt und kein Missing Ack.

[Stefan M.]

Hallo zusammen
hier auch noch eine kurze frage von mir

was bedeutet das genau und was kann (muss) ich dagegen tun.
Im ersten Moment schaut es so aus als würde alles funktionieren.


configCheck done:
 incomplete register set
    CUL_HM_HM_CC_RT_DN_21B9FE_ClimRT_tr:.RegL_07:
    CUL_HM_HM_CC_RT_DN_235EA6_ClimRT_tr:.RegL_01:
    CUL_HM_HM_CC_RT_DN_235EA6_ClimaTeam:.RegL_01:
    CUL_HM_HM_CC_RT_DN_235EA6_Climate:.RegL_01:
    CUL_HM_HM_CC_RT_DN_235EA6_Weather:.RegL_01:
    CUL_HM_HM_CC_RT_DN_235EA6_remote:.RegL_01:


empty list
    empty: CUL_HM_HM_CC_RT_DN_21B9FE_ClimRT_tr
    empty: CUL_HM_HM_CC_RT_DN_235EA6_ClimRT_tr
    empty: CUL_HM_HM_CC_RT_DN_235EA6_ClimaTeam
    empty: CUL_HM_HM_CC_RT_DN_235EA6_Climate
    empty: CUL_HM_HM_CC_RT_DN_235EA6_Weather
    empty: CUL_HM_HM_CC_RT_DN_235EA6_WindowRec
    empty: CUL_HM_HM_CC_RT_DN_235EA6_remote


lg
Stefan