richtige Vorgehensweise? --> zwei HZ, zwei FK, MAX-Scanner

Begonnen von wg25, 16 Oktober 2020, 09:29:25

Vorheriges Thema - Nächstes Thema

wg25

Moin zusammen!

Ich verzweifel bald an meiner Wohnzimmer-Config bzgl. MAX. Eine Weile geht's immer gut, aber irgendwann meinen die HZ die verbundenen FKs "falsch" interpretieren zu müssen. Es läuft immer so ab, dass wenn ein Fenster geöffnet wird, beide HZ in "Window open" Modus gehen. Soweit so gut. Nur wenn jetzt das Fenster nach einer Weile wieder geschlossen wird, gehen die HZ erst wieder in den "normalen" Auto-Modus, um dann nach wenigen Sekunden wieder in den Window open Modus zu wechseln. Und dabei ist egal, welches Fenster geöffnet war. Die HZ kommen da auch nicht wieder raus, erst nach einem factory reset. Anbei mein "Schaltplan" nur für's Wohnzimmer mit den beiden HZ und FK.

Irgendwelche Ideen?

Gruß Arne

Dr. Ulfi

Hallo,

ich bin zwar nicht DER Experte, aber mir sind das einfach zu viele Verbindungen. Da redet ja jeder mit jedem und der CuBe/CuL ist auch noch mit dabei, und wenn dann alle durcheinander reden....
Vielleicht funktioniert es auch,  aber es gibt immer wieder unerklärliche Phänomene und Störungen im Funkverkehr, auch von außerhalb.

1. Bist du dir sicher, das die Geräte deine vielen Verbindungen auch alle verstanden und bestätigt haben? Da gibt es wohl immer wieder Probleme.

2. Ich würde die Anzahl der Verbindungen auf das minimal Notwendigste reduzieren.
    Bsp. Ein Fensterkontakt sendet jetzt an 3 Geräte ich bin offen und er wartet auch auf 3 Antworten. Parallel unterhalten sich auch noch die beiden HTs

Entweder du definierst nur ein HT als Master, dass die FKs abhört und das andere koppelst du nur mit diesem HT. Das sollte eigentlich möglich sein (nicht getestet). Ich habe einen WT als Master der gibt seine Befehle an die HTs. Auf die Rückkopplung der HTs zu den FKs kann man meiner Meinung nach verzichten.

Oder du definierst den CuBe/CuL als Master und er sendet die Befehle bei Fenster offen/geschlossen an die HTs. Funktioniert dann aber nur wenn FHEM aktiv ist.

Weiß jemand, wie das bei der Originalsoftware funktioniert? Regeln die HTs auch herunter, wenn der CuBe aus ist ? Das habe ich noch nie getestet. Aber wie gesagt ich habe ein WT.

Gruß
Raspi
CUBE/CUNO a-culfw, Signalduino 433Mhz, Sonoff/Tasmota, EnOceanPI, Meross Smart Plug (IFTTT), ESP8266 Projekte,
MAX!-Heizungssteuerung, Intertechno IT-1500-Steckdosen, Velux KLF200 mit Somfy io

thburkhart

@wg25

drücke doch bei allen Geräten mal länger die Boost-Taste bis es von 30 runterzählt bzw. Connect-Taste am FK

Dann müsstest du in den readings die peers sehen können.

Hast du beim Pairen der FKs auch die Reset-Taste am FK gedrückt?

beobachte das Ganze im Eventmonitor; damit du mitbekommst, ob die Credits ausreichen ..
du kannst mit 30 min je Device rechnen
1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

Wzut

@wg25 , stell mal das cm Device auf verbose 5  und bei allen Geräten debug auf 1.
Wenn du nun dein nettes Spiel runterspielst sieht man Log wer wirklich mit wem und wann redet.
So richtig interessant ist zu erfahren wer für dieses erneute Window open der Verursacher ist.

Zitat von: Dr. Ulfi am 16 Oktober 2020, 11:42:53
Weiß jemand, wie das bei der Originalsoftware funktioniert?
Klar weiß ich das, habe mich ja lange genug damit beschäftigt und bin immer bestrebt den Leuten klar zu machen wie bei all ihren Freiheiten die ELV Software das machen würde.

Der aktuelle Fall mit ELV Software :
HT1 und HT2 wären gepeerd und synchronisieren sich gegenseitig, d.h. man verstellt einen und der andere zieht kurz darauf nach.
Bei den zwei FKs wäre vermutlich jeder FK mit jedem HT gepeered.

Wäre es meine Installation :
HT1 und HT2 miteinander gepeered , HT1 mit FK1 & FK2 und HT2 mit FK1 & FK2
FK1 und FK2 aber mit keinem Device peeren, dadurch versenden sie Broadcast Telegramme.
Bei den Broadcast reicht es nun aus wenn mindestens ein HT die Nachricht sieht da er ja seinen Bruder synchronisiert.

und noch ein Tipp : den Scanner abschalten !
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

wg25

Zitat von: Wzut am 16 Oktober 2020, 14:06:52
HT1 und HT2 miteinander gepeered , HT1 mit FK1 & FK2 und HT2 mit FK1 & FK2
FK1 und FK2 aber mit keinem Device peeren, dadurch versenden sie Broadcast Telegramme.
Bei den Broadcast reicht es nun aus wenn mindestens ein HT die Nachricht sieht da er ja seinen Bruder synchronisiert.

HT1 und HT2 in beide Richtungen --> leuchtet mir ein
HT1 mit FK1 & FK2 bzw. HT2 mit FK1 & FK2 --> nur aus Richtung des HT zu den FK? Ich dachte immer, es muss in beide Richtungen "gepeered" werden...

Warum den Scanner aus? Credits habe ich nicht zu wenig, wenn dass die Idee dahinter ist.

Wzut

wenn ich wetten würde : 90% der User glauben sie hätten ihren FK mit dem HT gepeered, die Wahrheit sieht aber vermutlich anderes aus.
Grund : Ohne Cube ist das verdammt schwer das Peering am FK hinzubekommen, das Zeitfenster wo der FK wach ist ist verdammt klein.
Ist aber kein Beinbruch, ohne Partner HT/WT schickt der FK seine open/close Nachrichten an die Adresse 000000 und erwartet auch keine Rückmeldung.
Die HTs/WTs die diese Broadcast Nachricht "sehen" reagieren darauf wenn sie mit dem FK assoziert sind. Die Gefahr dabei ist halt das es ein einzelenes Gerät nicht mitbekommt, aber wenn noch ein anderes HT oder ein WT vorhanden ist klappt das i.d.R. recht gut. 

Den Scanner würde ich deaktivieren damit bei der Aufzeichnung nicht noch mehr los ist und um einfach eine zusätzliche Fehlerquelle auszuschliessen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher