HM-CC-RT-DN

[betateilchen]

Die deutsche Commandref wird vermutlich nicht gepflegt.

Die commandref wird weder in deutsch noch in englisch explizit gepflegt, sondern aus dem Dokumentationsteil innerhalb eines Modules automatisch generiert. Für die Einbindung eines Moduls in fhem ist der englischsprachige Teil dieser Doku Pflicht, der deutsche ist optional. Deshalb gibt es für manche Modul eben nur eine englischsprachige Dokumentation. Aber zumindest diese englische Variante müsste für JEDES Modul vorhanden sein.

[martinp876]

Wozu hat Homematic ein bidirektionales Protokoll, wenn ich nach jedem Befehl erstmal das Device fragen soll, ob es auch das getan hat, was ich ihm gesagt habe? Wenn ich ein Kommando abschicke und das Device die Nachricht bestätigt, muss ich davon ausgehen können, dass alles ok ist. DAS erwarte ich von einem bidirektionalen Protokoll. Alles andere macht für mich keinen Sinn.

guter Gedanke -leider nicht real. Mann kann ganze Blöcke von Kommandos absetzen - und wenn einer schief geht, was dann? wieder alles rückwärts rechnen?
auch Stati gehen mit unter verloren - HM devices senden per default 3mal - und das reicht nicht immer.

Aber richtig ist: wenn das Ack incl status kommt wird das set_ entfernt. wenn es nicht kommt ist der Zustand unklar - kam das Kommando nicht am device an oder das ACK nicht bei FHEM?
Bei registern - welche wohl nur selten in notifies verwendet werden - sollte ein set_ sowieso nicht stören sondern helfen. Insbesondere da "prep" vorhanden ist.
Bei wakeup-device gibt es m.E. sowieso keine Diskussion. Der Zustand "set_", also "change in progress" hat hier quasi immer eine längere Lebensdauer.

[CQuadrat]

Ich bin hier langsam am verzweifeln:

• Fensterkontakt nochmal in den Anfangszustand zurückversetzt
  
• Neu gepairt -> Statusänderungen können in Fhem nachverfolgt werden
• gepeert mit _WindowRec-> auch das sehe ich in Fhem

aber: keine Reaktion am Thermostat

[peterk_de]

@CQuadrat kannst du eigentlich am betroffenen Thermostaten die desiredTemp per fhem so setzen, dass er sie umsetzt? (Also im Display anzeigt)?

[martinp876]

was du alles sehen solltest:
- fenster ist gepeert, RT_windowRec ist gepeert
- fenster hat "peerneedsburst" gesetzt (sonst wacht der RT nicht auf)
- fenster sendet beim öffnen einen trigger an den RT - notify und readings sind in FHEM zu sehen.

peerneedsburst sollte automatisch gesetzt werden... wenn nicht, lass es mich wissen

Man sollte das Fenster-symbol im RT sehen

Gruss Martin

[CQuadrat]

@CQuadrat kannst du eigentlich am betroffenen Thermostaten die desiredTemp per fhem so setzen, dass er sie umsetzt? (Also im Display anzeigt)?

Ja. Aber das dauert heute sehr lange (an allen Thermostaten). Ich kenne das eigentlich nur so, dass die Änderung fast sofort erfolgt.

[martinp876]

das automatisch senden durch burst ist per default aus. du kannst es freigeben (attr burstAccess) oder durch das Kommando set burstXmit triggern.

[rtv]

@CQuadrat
Probier' doch die bewährte Methode:
- Geräte in FHEM auskommentieren / entfernen
- HMLAN stromlos machen (wichtig!)
- Geräte per Taster resetten.
- TFK nur mit RT peeren
- HMLAN wieder anschalten
- Am HMLAN hmPairForSec setzen und am RT Boost gedrückt halten zum pairen.

Danach geht's eigentlich generell...

[peterk_de]

Hat eigentlich sich schoneinmal jemand mit dem Feintuning mit des Teils etwas intensiver befasst?

Ich hab heute mal mitgeplottet. Umstände: Außentemperatur 9-14 Grad, Altbau, Zimmer ca. 30m², mit der zusätzlichen Regelungs-Schwierigkeit einer unverschlossenen Treppe in ein darüberliegendes Zimmer (Maisonette, dort läuft der gleiche Thermostat mit identischem Programm)

Das oben ist die Kurve vom HM-CC-RT-DN mit Programmtabelle und Lüftungsknick morgens. Der läuft jetzt eine Woche und ist noch komplett "default" was die Regelung angeht, Offset ist 0,0K. Das unten ist ein HM-WDS10-TH-I mitten im Raum in ca. 1,5m Höhe.

LG Peter

[CQuadrat]

- fenster hat "peerneedsburst" gesetzt (sonst wacht der RT nicht auf)

peerneedsburst sollte automatisch gesetzt werden... wenn nicht, lass es mich wissen

Da scheint es irgendwie zu hängen. Ich sehe:

R-Hzkp_Bad_WindowRec-peerNeedsBurst     set_on     2013-10-17 21:37:51

Und das bleibt auch so.

[martinp876]

@CQuadrat
also das sollte sich ändern - und mit getConfig sollte das set_ verschwinden.
nach getConfig ist der Hzkp_Bad_WindowRec in der peerList - korrekt?

wenn nicht bitte expert auf 2 setzen und ein "list" posten

@Peter,

meiner schwingt auch etwa in der Form  - mit unter sogar, wenn das Ventil NICHT aufmacht.
man sollte es über die P und I werte glätten können. Ich denke I zu Verkleinern sollte die schwinger niedriger machen...
ob das zusammen mit auto-einstellung der Regelung funktionert... keine Erfahrung

[CQuadrat]

@CQuadrat
Probier' doch die bewährte Methode:
- Geräte in FHEM auskommentieren / entfernen
- HMLAN stromlos machen (wichtig!)
- Geräte per Taster resetten.
- TFK nur mit RT peeren
- HMLAN wieder anschalten
- Am HMLAN hmPairForSec setzen und am RT Boost gedrückt halten zum pairen.

Danach geht's eigentlich generell...

So, jetzt hatte ich die Faxen digge und es genau so gemacht, wie es rtv vorgeschlagen hat.


Und jetzt funzt es

Nachtrag:
Nur
winOpnTemp
scheint nicht am Thermostat übernommen zu werden. Dort bleiben immer 12.0 °C stehen, wenn das Fenster geöffnet wird.

[martinp876]

Frage:

ist das Register gesetzt und mit getConfig verifiziert? und trotzdem klappt es nicht?
nur das sich es probieren kann. Setzen hat gerade funktioniert

[CQuadrat]

Frage:

ist das Register gesetzt und mit getConfig verifiziert? und trotzdem klappt es nicht?
nur das sich es probieren kann. Setzen hat gerade funktioniert

Ja, Register ist gesetzt und per getConfig auch verifiziert.

Am Thermostat bleibt aber die 12°C-Voreinstellung stehen.

[martinp876]

Hi,

habe es gerade ausprobiert - da hast du recht. Parameter stimmen aber alle, ich kann keinen Fehler erkennen.
schade...

Gruss Martin