HM-LC-Dim1T-CV UNREACH ändert sich nicht

Hi,

entschuldingt meinen Doppelpost, aber ich denke das das Thema hier besser aufgehoben ist:

Wenn ich meinen Homematic Dimmer HM-LC-Dim1T-CV vom Strom nehme ändert sich der UNREACH Datenpunkt leider nicht. Ich kann somit nicht erkennen ob er tatsächlich verfügbar ist oder nicht.

Ich weiß nicht genau wie ich das Problem weiter eingrenzen kann. Mag mir jemand dabei helfen?

Grüße
Lemy

Sers,

UNREACH ändert sich nicht sofort. Das wird meines wissens nach nur zyklisch abgefragt.

so long,
p

Siehe dazu auch die Erklärung (Max! vs Homematic) in diesem Post:

das hört sich in meinen Ohren aber nach einem Design/Sfotwarefehler der Geräte an. Wenn ich das Datenblatt und die Implementation Specs so lese sollte das reine Wake Up nicht länger als 15ms dauern bis Daten übermittelt werden können.

Nach Einsicht in den Code sehe ich woher die 1 Sekunde kommt.
Aber die ist mehr oder minder nur ein blankes Wartefenster, die aktuell übertragenen Daten werden garnicht berücksichtigt, ist es denn wirklich notwendig dann die volle Sekunde zu warten und danach volle Wartezeit für diese Sekunde zu warten?

Da muss @sathya sicher was zu sagen. Normalerweise baut er eine Wartezeit nicht ohne Grund ein :wink:

Gelöst durch POWERUP_ACTION bei HM-LC-Dim1T-CV

Hallo @mindforger,

Das ist definitiv nicht korrekt. schau dir das Datenblatt des TI CC1101 an. Daraus geht hervor, was übliche Zeiten sind. Standard sind 360 ms (welches z. B. von HomeMatic genutzt wird). Aus meiner Sicht ist die Verwendung von WoR generell ein Implementierungsfehler.

Ja, es ist notwendig, eine Sekunde zu warten. Das ist kein blankes Wartefenster. Es wird ein Preamble-Signal gesendet, welches dafür sorgt, dass der empfangende Chip wach bleibt (siehe CC1101-Datenblatt). Eine Sekunde ist bei MAX! notwendig, um sicherzustellen, dass der Chip auch wirklich wach ist. Erst im Anschluss können Daten gesendet werden. Die Zeit lässt sich reduzieren, aber damit erhöht sich linear die Wahrscheinlichkeit des Nichtempfangs.

Viele Grüße

Sathya

1 Like

Klar, verständlich … dann hatte ich das Preamble-Signal falsch verstanden, da es zumindest in der Doku so rüberkam, dass es nur ein Puls ist und dann einer Fallbackregel (monostabiles Flop) folgt und nicht ein permanentes Funksignal ist. Eigentlich eine selten dämliche Erfindung dann, aber ohne Wake kann man halt nur schwerlich genug Strom sparen, so ein deep sleep spart schon einiges an Strom.

Ich kann mir witzigerweise auch schon vorstellen wo man da am Controller gespart hat dass man so lange für das Wakeup braucht, sehr traurig aber okay dafür sind die Thermostate halt billiger.

Danke für die Aufklärung

1 Like

Sehe ich auch so.

Es gibt noch die Variante, dass das Gerät ein Wake-up-Paket mit Statusinformationen sendet, auf welches die Zentrale dann antworten und neue Daten senden kann. Das spart noch mehr Strom und es wachen auch nicht alle WoR-Geräte auf, wenn die Zentrale Daten an ein Gerät sendet. Nur dauert es dann bis zu der Aufwachintervalldauer, bis das Gerät reagiert. Vermutlich dachte sich eQ-3, die Nutzer erwarten eine sofortige Reaktion…

Viele Grüße

Sathya

Um nochmal auf meinen ursprünglichen Post zurückzukommen:
Warum wird STICKY_UNREACH beim Gerätestart von Homematic nicht auf true gesetzt? Wenn das Gerät neustartet war es ja offensichtlich nicht erreichbar zuvor.

Detektiert werden könnte das über das Paket INFO_POWERON bei dem ich mir allerdings nicht sicher bin ob es überhaupt ausgewertet wird. Nachdem mein Dimmer jetzt beim Start autonom sein LEVEL auf 80% setzt, kommt diese Änderung in Homegear erst einige Minuten später an…

Grüße
Lemy

Hallo @Lemy,

Das stimmt zwar, dafür ist UNREACH aber nicht gedacht. Die Variable wird gesetzt, wenn ein Gerät entweder nicht auf Pakete reagiert hat oder über eine längere, geräteabhängige Zeit keine Pakete gesendet hat. Sie soll also Geräte identifizieren, die nicht funktionsfähig sind. Ein kurzer Geräteneustart soll also nicht gleich ein UNREACH auslösen. Bei längerem Trennen vom Netz werden die meisten Geräte nach einer Weile auf UNREACH gesetzt. Dann ist auch STICKY_UNREACH true.

Viele Grüße

Sathya

Hi,

Was für einen Weg würdest du denn vorschlagen um etwas beim Gerätestart zu tun?

Danke im voraus
Lemy

Man könnte eine Variable “BOOT” einbauen. Zum Teil gibt es diese bereits, sie ist aber nicht funktionsfähig.

Viele Grüße

Sathya