HM-CC-RT-DN

[jensus11]

Ok. Nur wie mach das jetzt am besten?
Habe gestern soviel gemacht und jedesmal wenn ich so gut wie fertig war hat der TFK nur noch rot geleuchtet und das RT wurde nicht mehr angesteuert. Reicht es wenn ich die gespeicherten Textzeilen vom TFK in die FHEM.cfg einfüge? Mit meine anderen Teilen hat das Super geklappt. Denk schon das da ein eventueller Defekt vorliegen könnte.

[martinp876]

Also pairen geht "wie immer"
- hmPairForSec 300
- anlernen drücken

ggf. werden gleich alle reigster gelesen. Wenn nicht noch einmal getConfig und anlerenn noch einmal drücken.

Das sollte nichts an der LED ändern.

Wenn du eine rote LED bekommst, kontrollieren die Peers.
Wenns nicht klappt zeichne die Rohmessages auf und schicke die Konfiguration der Devices ("list")

Gruss Martin

[rufus999]

@martinp

Hallo martin,

habe wie gewünscht einen neuen Beitrag eröffnet. http://forum.fhem.de/index.php/topic,17281.0.html
Wäre schön wenn du da ein Auge trauf werfen könntest.

Vielen Dank im Voraus,

rufus999

[strauch]

Ich hoffe ich habe nichts übersehen, ich habe das Problem, das in meinen Schaltzeiten manchmal vorne in set_ steht. Als Beispiel ich hab heute die Schaltzeiten geändert und in FHEM steht jetzt fogendes:

tempListFri 05:45 16.0 07:00 20.0 13:30 16.0 23:00 20.0 24:00 16.0 2013-12-11 17:39:08
tempListMon 05:45 16.0 07:00 20.0 19:00 16.0 23:00 20.0 24:00 16.0 2013-12-11 17:39:08
tempListSat 09:00 16.0 24:00 20.0 2013-12-11 17:39:08
tempListSun 10:00 16.0 23:00 20.0 24:00 16.0 2013-12-11 17:39:08
tempListThu 05:45 16.0 07:00 20.0 18:00 16.0 23:00 20.0 24:00 16.0 2013-12-11 17:39:08
tempListTue 05:45 16.0 07:00 20.0 14:30 16.0 18:00 20.0 24:00 16.0 2013-12-11 17:39:08
tempListWed set_ 13:30 16.0 23:00 20.0 24:00 16.0 2013-12-11 17:39:08

Starte ich ein getconfig, ist es anschließend weg. Der Thermostat funktioniert auch ganz normal, nur andFHEM hat das nicht gefallen. Nach dem letzten Update dachte ich erst es wäre weg. Wie kommt es dazu, ich konnte mit google nichts finden, auch so nicht im commandref das es irgendwie einen Grund dafür gibt.

Danke

[Mr. P]

Ich hoffe ich habe nichts übersehen, ich habe das Problem, das in meinen Schaltzeiten manchmal vorne in set_ steht. Als Beispiel ich hab heute die Schaltzeiten geändert

Das ist ein Zeichen dafür, dass zumindest FHEM noch keine Bestätigung vom RT erhalten hat, dass die Daten auch am Thermostat angekommen sind.

Starte ich ein getconfig, ist es anschließend weg.

Dann gibt es wohl Übertragungsschwierigkeiten am Rückweg vom RT zum HMLAN. Denn durch das getConfig wird der RT nochmals abgefragt und dann klappt es wohl mit der Verbindung. Was hast du denn für Verbindungswerte am RT-Device? Poste einfach ein 'list <RT>' und dann poste hier die Rssi-Abschnitt aus dem Ergebnis.

[martinp876]

Weitere Tips:

mit "regSet" oder verwanten Kommandos (auch templist) werden die geänderten Readings auf "set_" gesetzt - also "unbestätigt"

nach getConfig werden alle "set_" der Register gelöscht und die Werte aus dem Device eingetragen. Es wird NICHT geprüft, ob der "set_" Wert auch der aktuelle ist.

Frage:
- waren die Werte schon geschrieben? War protoState auf CMDs_done?
- gab es Fehler bei der übertragung (proto... variablen)

Gruss Martin

[strauch]

Danke für die Antworten, jetzt verstehe ich was da passiert. Ich werde das noch mal checken um die Fragen zu beantworten. Jetzt gerade kann ich den Fehler nicht nachvollziehen.

Die Sendequalität sieht so aus:
avg:-51.55 min:-79 max:-46 lst:-73 cnt:3711
avg:-63.63 min:-86 max:-53 lst:-66 cnt:3755

Ich verwende ein CUL für die Homeamtic Komponenten. Ich hatte durchaus schonmal "Empfangsfehler" die ich nicht verstanden habe.

Danke für Eure Hilfe.

[Mr. P]

Die Sendequalität sieht so aus:
avg:-51.55 min:-79 max:-46 lst:-73 cnt:3711
avg:-63.63 min:-86 max:-53 lst:-66 cnt:3755

Sieht eigentlich ganz normal aus.

Noch eine Sache aus eigener Erfahrung:
Ich wollte meine RTs ursprünglich möglichst funklastarm betreiben, bis ich zwei Dinge feststelle:
a) es gibt ständig Übertragungsprobleme und
b) ich ohnehin die Konfiguration für meinen SC noch anpassen muss.

Daraufhin hab ich im RT den Register burstRx auf 'on' gestellt, damit dieser auch zwischen den üblichen 2,5 Minuten aufgeweckt werden kann und anschließend beim Übermitteln der Wochenprogramme immer ein 'burstXmit' nachgeschmissen. Dadurch wird der RT zum Einen sofort geweckt und zum Anderen scheint er auch nicht wieder so schnell schlafen zu gehen, was eine gute Übertragung ermöglicht. Kehrseite der Medaille, wenn du mit 'burstXmit' arbeitest, ist der erhöhte Funktraffic und der erhöhte Strombedarf vom Thermostat.
Versuch es einmal damit... ich bin seither sehr zufrieden damit.

[strauch]

Danke für den Tipp dann hab ich mal ein bisschen zum testen

Gesendet von meinem Nexus 4 mit Tapatalk

[laurine]

Moin,

wie kann ich das HM-CC-RT-DN denn via FHEM sperren? Da gibt es doch eine Tastenkombination um das Gerät vor Bedienung zu "schützen" und das nur noch via Funk zuzulassen. Wie kann ich das via FHEM einschalten ohne am Gerät die Tasten drücken zu müssen? Ich weiß, dass es diese Funktion in der HM-Software gibt. In FHEM auch?

Danke, Laurine

[martinp876]

zum Burst noch eine Kommentar: ein burst verbraucht Batterie in ALLEN devices, die burst unterstützen, egal wer an wen sendet!
- wenn du also burstXmit oder das Attribut burstAccess nutzt geht es auf die Batterie ALLER devices in funkreichweite (auch die des Nachbarn)
- wenn im device burstRx = on gesetzt wird verbraucht sich demnach die batterie schneller - und zwar inbesondere im Masse, wie bursts in Funkreichweite angestossen werden.

Im konkreten Fall sehe ich aber kein Problem. Beim RT burst einzuschalten ist bei der Nutzung von Fensterkontakten sowieso notwendig. Das gelegentliche Übertragen von templisten sehe ich auch nicht als wirkliche Belastung - je nachdem wir oft man es startet.

@Laurine
inhibit war nicht eingebaut - kommt in der nächsten Version.
ausserdem gibt es die Register für manu und party mode
modePrioManu    |     literal      | allow tempChange for manual only by... options:CCU,RT_TC_CCU_SELF,self,RT_TC_SC_SELF,all
modePrioParty    |     literal      | allow tempChange for party only by... options:CCU,RT_TC_CCU_SELF,self,RT_TC_SC_SELF,all

Gruss Martin

[chrisdash]

Ich habe vor drei Wochen meine Heizungen mit HM-CC-RT-DN ausgestattet. Dazu einen HM-CFG-USB-2, der über hmland an meinen Debian Heimserver angeschlossen ist. Dazu ein einzelnes HM-WDS10-TH-O.

Ich hatte wochenlang -- die HM-CC-RT-DN waren im "wakeup" Modus -- das Problem dass ich keinerlei Befehle an meine Heizungen senden konnte, obwohl die HM-CC-RT-DN an den HM-CFG-USB-2 gepaired waren. Keine desired-temp, keine Wochenzeiten, nichts. Das ging immer nur dann, wenn ich den HM-CC-RT-DN manuell über fünf Sekunden Burstknopf geweckt habe. Alles andere führte zu ewig langem CMDs_pending und später MISSING ACK. An allen Geräten.

Die einzige Abhilfe war für mich, die ganze Kommunikation von "wakeup" auf "burst" umzustellen. Dazu musste ich:

1. Bei den HM-CC-RT-DNs jeweils den burst mode aktivieren:

Code Auswählen Erweitern

set CUL_HM_HM_CC_RT_DN_123456 regSet burstRx on
und dann schnell rüber laufen und fünf Sek drücken, sonst nimmt er es nicht!

2. Danach fhem sagen, dass es über burst senden darf. Dazu in der fhem.cfg einen Eintrag für jedes HM-CC-RT-DN ergänzen, der etwa so aussieht:

Code Auswählen Erweitern

attr CUL_HM_HM_CC_RT_DN_123456 burstAccess 1_auto
und anschließendes rereadcfg

Nun ließen sich schlagartig sämtliche Funktionalitäten im web-interface auch endlich nutzen, wie getConfig, set desired-temp... endlich geht die Grundfunktionalität!

Ich wollte das hier einfach mal posten, da es mich extrem viel Zeit gekostet hat und man hier im Thread (habe alles gelesen) auch recht viel zusammenpuzzeln muss, damit man als Anfänger darauf kommt, dass der wakeup-Modus möglicherweise nicht so recht gut will wie der burst-Modus.
Wie gesagt, ohne diese Änderung nur CMDs_pending und später MISSING ACK an allen Geräten. Ich habe auch fhem seit ca. Mitte November immer mal wieder aktualisiert, keine Abhilfe. Und ja, die HM-CC-RT-DN sind gepaired, das war das Erste. Die Zentrale ist im pairedTo-Register und in dem anderen Register (Bezeichner vergessen) eingetragen und das Antennensymbol auf den HM-CC-RT-DN leuchtet jetzt dauerhaft. Vorher fing es immer wieder mal an zu blinken und ich hatte dann auch motorErr: communicationErr.

Bin froh, dass es jetzt läuft, gehe in wenigen Tagen in den Weihnachtsurlaub und will die Heizungen dann remote steuern.....
Jetzt nur noch eben VPN einrichten... 
Viele Grüße, ich hoffe es hilft jemandem,
Christian

[Mr. P]

@Christian: Da bist du nicht der Erste und wohl auch nicht der Letzte mit dem Problem.
Das Timing scheint bei den RTs sehr knifflig zu sein und durch den burstMode und dem burstAccess werden sie scheinbar toleranter (wenn auch auf Kosten der Batterie und Sendezeit).

[martinp876]

Hallo Christian,

das Attribut burstAccess ist möglich - empfehle ich aber nicht. Es gibt die Variante des Kommandos
set <rt-device> burstXmit

beim Attribut sendet fhem automatisch einen "halloWach" an den RT - danach die messages, die vorliegen.
mit dem Kommando hast du in der Hand, wann "halloWach" gesendet werden soll. Du kannst zum einen Warten, bis der RT aufwacht.
Du kannst mehrere Kommandos in die queue stellen, und dann erst burstXmit senden.

Zu beachten ist dabei, dass "halloWach" den HMLAN 'belasten'. Mehr als 100 sendet er nicht, je Stunde - abzüglich aller anderen messages! Wenn er wiederholen muss nur ein Drittel.

Was mich interessieren würden ist, warum es beim wakeup nicht klappt, also ohne burst. Falls du einen log rohmessages aufnehmen kannst, werde ich es durchsehen. (burstAccess natürlich ausgeschaltet)

Gruss Martin

[Mr. P]

das Attribut burstAccess ist möglich - empfehle ich aber nicht. Es gibt die Variante des Kommandos
set <rt-device> burstXmit

Hej Martin,

Christian hat wohl das selbe Problem wie auch ich es habe. Und wenn >95% aller Befehle mittels Wakeup-Methode im Sand verlaufen, dann wird burstXmit recht uninteressant und man nutzt burstAccess stattdessen.