HM-CC-RT-DN

[nephdrasil]

Wie kann ich die Register setzen?

set  <Name> regset brustRx on

Edit: die Änderungen kann ich jedoch am stellrad vornehmen und sie werden übernommen.

Besteht da problem mit den Fehelenden Registern immer noch. Es funktioniert doch augenscheinlich alles.

Wie sehe ich das die Register nicht richtig gesetzt sind.

[martinp876]

Hi,

Die Register sind bei deinen 3 RTs wohl gesetzt. Die wachen ja auf und beantworten die Änderung.

Der Log war vom funktionierenden Ablauf - oder muss ich einen Fehler suche?

An stellrad kann  am immer ändern - nur beim aufwecken über die Luft, also den peer - das ist ein Problem

Gruss Martin

[nephdrasil]

Nein du musst keinen Fehler suchen.

Die ursprüngliche Frage war. Wieso das peering über FHEM per peerchan nicht funktioniert. Aber manuel geht es.

DIe Log mit dem jetzigen durchlauf hänge ich nocheinmal an, DU wolltest ja das Logging für das manuelle Peering direkt nur mit den Thermostaten.

Sorry für die falsche Datei.

Danke für deine Mühen

[martinp876]

Hi,

ganz bin ich nicht  hinter das team-pairen gekommen.
Ich kann meine pairen - die Übertragung geht aber immer nur von A nach B, aber nicht von B nach A.
Der eine will seine Daten einfach nicht senden.

Gruss Martin

[CQuadrat]

Hallo Zusammen,

ich habe in der Vergangenheit schon mehrmals beobachten müssen, dass das Senden eines Befehls an einen RT zum "Aufhänger" führt:
"CMDs_pending" geht in "CMDs_processing..." und anschließend wieder in "CMDs_pending". Das ganze wiederholt sich endlos (zumindest mehrere Stunden).

Löschen der "hängenden" Befehle

Code Auswählen Erweitern

set <device> clear msgEvents nutzt nichts. Beim nächsten Befehl tritt das Problem dann an diesem RT wieder auf.
Das einzige was dann hilft ist: Batterien am RT raus. Danach funktioniert er wieder.

Aktuell habe ich wieder einen "hängenden" RT. Der "Hänger" tritt aktuell wieder seit 04:37 auf, wo ich per at mit

Code Auswählen Erweitern

set Hzkp_.* regSet btnLock lock alle RTs sperre. Bei allen, bis auf einem, hat das auch funktioniert. Und dieser eine RT hat in der Vergangenheit hier auch noch keine Probleme gemacht.

Ich habe mal ein Log beigefügt. Der betroffene RT hat die ID 21CDC5.

Da diese Problem schon öfters, bei verschiedenen RTs bei jeweils verschiedenen Befehlen aufgetreten ist, wäre es nett, die Ursache zu fixen.


Viele Grüße

Christoph

[martinp876]

Hi Christoph,

ich denke in der neusten Version sollte es nicht mehr passieren. sollte in den letzten Tagen gefixt worden sein.
Melde dich, wenn es noch einmal auftritt.

Grund war zumindest eine fehlgeschlagene message. Die kann immer auftreten - hängt evtl von deinem System ab

Gruss Martin

[nephdrasil]

Hallo Martin,

vielleicht hilft dieser hinweis. Bei dem peering der Kanäle musste ich das für jeden einzelnes Thermostat machen ansonsten wollten diese nicht zusammenarbeiten.

Also Thermostat 1 zu 2
        Thermostat 2 zu 1
        Thermostat 3 zu 2
        Thermostat 2 zu 3
        Thermostat 3 zu 1
        Thermostat 1 zu 3

Leider kann ich dir nicht wirklich weiterhelfen bin noch ein Noob.

Mfg nepg

[martinp876]

Hi nepg,

schon klar, dass jeder mit jedem gepeert werden muss. Zum einen muss er auf die Kameraden hören, wenn etwas kommt und zum anderen muss er an alle senden, wenn er etwas weiss.

Vielen Dank für den Hinweis.

Dass ich den Unterschied nicht finde ist ärgerlich. Aber ich werden weiter mit dem notify arbeiten, da es sowieso kompletter ist. das team syncht 'nur' das Drehen des Handrades - kein Wochenprogramm, kein stellen der Zentrale, keine mode Verstellung

Gruss Martin

[noice]

Irgendwie fehlt mir beim letzten Thermostat die Einstellung der Temperatur.
Woran kanns liegen?

[martinp876]

schau dir die Attribute des CLIMA_TR an - fehlen da welche?
machen ein
set <dev>Clima_tr ?
kommen bei allen die gleichen Optionen?

[CQuadrat]

Hallo Martin,

ich habe wieder einen Hänger: CMD_pending -> CMD_processing... -> CMD_pending -> usw.

Der Fehler ist wie folgt nachstellbar:

1) alle RTs sind gesperrt und alle Register sind vollständig gelesen
2) ich entsperre (mind.) einen RT per "set Hzkp_Kueche regSet btnLock unlock" oder manuell direkt am Gerät
3) ich sperre alle RTs mit "set Hzkp_.* regSet btnLock lock"
4) der Befehl bleibt wie dann oben beschrieben hängen; dies betrifft dann alle vorher entsperrten Geräte; am jeweiligen Gerät sieht man, dass der Befehl angekommen ist; die Bestätigung kommt hier aber in FHEM nie an -> Hänger

Sperre ich aber nur gezielt einen RT mit "set Hzkp_Kueche regSet btnLock lock" geht der Befehl durch.


Ist das ein Software- oder ein Firmware-Bug?


Viele Grüße

Christoph


Nachtrag: Mit "set Hzkp_.* regSet btnLock lock" geht der Befehl ja auch an alle Channels. Vielleicht verschluckt sich hier der RT.

[martinp876]

Hallo Christoph,

ich denke, was passiert ist folgendes:
- du sendest ein Kommando - kommt in den Stack
Der RT wacht auf, FHEM sendet => CMDs processing
der RT antwortet nicht - etwas an der Message oder Übertragung ist faul. Kommando wird wieder zurückgehängt, damit es wiederhohlt werden kann. => CMDs pending
der RH wacht wieder auf.......

das Kommando wird 3 mal wiederholt - das dauert demnach ~7-10 min - je kommando.

Sieht es so aus? Nimmt die Anzahl der pending commands langsam ab?

Du kannst das Attribut msgRepeat auf '0' setzen, dann wird eine Message nur einmal gesendet. Es ist das Dilemma des wiederholens - macht es sinn

Eine 2. Frage ist, warum wiederholt werden muss. Kannstu du mitloggen und erklären, was du sendest - ggf das zugehörige setting/peering

Gruss Martin

[noice]

schau dir die Attribute des CLIMA_TR an - fehlen da welche?
machen ein
set <dev>Clima_tr ?
kommen bei allen die gleichen Optionen?

finde irgendwie keinen Fehler.
Kann ich das Device noch mal löschen und neu einlesen?

[CQuadrat]

das Kommando wird 3 mal wiederholt - das dauert demnach ~7-10 min - je kommando.

Sieht es so aus? Nimmt die Anzahl der pending commands langsam ab?

Das ist definitiv nicht der Fall. In meinem beschriebenem Fall nehmen die Pendings nicht ab. Ich muss die Messages dann irgendwann händisch löschen. Die längste Zeitspanne, wo ich den beschriebenen Hänger beobachtet hatte (Zeit zwischen erst- und einmaligem Abschicken des Befehls und finalem manuellen Löschen), waren ca. 18 Stunden.

[martinp876]

zeige doch einmal was gesendet werden soll. machen ein "list" auf das device und schicken die daten (speziell den kommandstack)