Ausreden nehmen sie gerne, manchmal hilft stärkeres nachbohren, leider nicht immer.kaiserschmarrn hat geschrieben: ↑19.08.2020, 17:29... Das hatte ich gemacht, wurde aber abgewiesen, ...
Danke für den Lösungsweg und Deine Rückmeldung.
Moderator: Co-Administratoren
Ausreden nehmen sie gerne, manchmal hilft stärkeres nachbohren, leider nicht immer.kaiserschmarrn hat geschrieben: ↑19.08.2020, 17:29... Das hatte ich gemacht, wurde aber abgewiesen, ...
Ich behaupte mal das Gegenteil. Du hast Direktverknüpfungen angelegt. Das funktioniert dann so. Das Thermostat sagt auf Kanal 7 "Entscheidungswert XXX" und die Aktorkanäle müssten diesen Empfang quittieren und führen die in der Verknüpfung hinterlegte Aktion selbsttätig aus. Hier kann es nun je nachdem was in Deinem Funkbereich so los ist, zu einem Timing-Problem kommen, da der Aktor auf allen verknüpften Kanälen "gleichzeitig" den Empfang quittieren will und auch noch Statusinfos an die CCU senden will. Wobei da in den Zeitstempeln schon eine zeitliche Staffelung um fünf Sekunden erkennbar ist. Es ist durchaus möglich, dass es dort zu temporären Funkstörungen kommt. Vielleicht ist die Verbindung Thermostat - Aktor auch grenzwertig? Das hat jetzt nicht unbedingt direkt was mit der Verbindung der jeweiligen Geräte zur CCU zu tun. Unter "https://<IP-DEINER-CCU>/tools/devconfig.cgi?sid=<SID>" gibt es auch den Menüpunkt RSSI. In diesem kannst Du die kommunizierten RSSI-Werte der Geräte untereinander ablesen.real intruder hat geschrieben: ↑29.09.2020, 16:07das kann ja aus technischer Sicht schon nicht stimmen!
Wenn der Standard DC schon bei 20-40% liegt, ist nicht wirklich viel Luft da. Dann ist das "Grundrauschen" schon relativ hoch. Da bleibt schon nicht mehr viel Luft für die Übertragung von Firmwareupdates. Und dann muss man sich nicht wundern, dass die dann mehrere Tage benötigen.real intruder hat geschrieben: ↑05.10.2020, 15:09Mein Duty Cycle liegt zwischen 20 und 40 %... also ist da noch Luft.