Neue Beta Test Runde für alle MAX Module

[HeikoGr]

Kein Einzelfall

Ich hab dort 78x "cul868:ok" stehen. Wobei cul868 der Name meines IO Devices ist.

Mein Setup besteht aus einem Cul (Cube umgeflasht), 4x HT UND 1x SC

[Wzut]

OK, danke für die Rückmeldung, dann muss ich hier unbedingt nachbessern und heute Abend eine geänderte Version bereitstellen !

[Wzut]

Ich habe gestern Abend die 14_CUL_MAX im ersten Beitrag ausgetauscht,
bitte unbedingt nachziehen die CHANGED Einträge im cm Device wachsen sonst ewig ...

[Wzut]

Ich habe mich die letzten Tage wieder mal mit dem Thema IO Gruppe und bester CUL für das Device beschäftigt.
Um die Entscheidung welcher CUL aus der IO Gruppe des cm der "bessere" ist leichter zu machen habe ich intern eine mini Statistik eingebaut die die letzten 10 RSSI Werte berücksichtigt. Anzeige mit zwei neuen Readings , Bsp :

Code Auswählen Erweitern

2020-11-04 19:18:02   CUL1st  CUL -43
2020-11-04 19:18:02   CUL2nd  CUL2 -83
Bedeutet : Bei mir ist der CUL mit einem Durchschnitt von -43 besser als CUL2 mit -83 im Durchschnitt.
Also sollte ich CULdev an diesem Device auf CUL setzen, das nimmt mir jetzt das Modul ab und ändert selbst das Attribut.
Aber nur dann wenn der "Bessere" mindest 2db im Schnitt besser ist um ein ständiges hin und her zu vermeiden falls beide in etwa gleich gut/schlecht sind.
Wer diesen Automatismus nicht haben möchte kann ihn mit dem neuen Attribut autoselectCUL = 0 abschalten.
Die Berechnung der Readings CUL1st & CUL2nd ist davon nicht betroffen. 
Bis die neuen Readings sichbar werden dauert es etwas, da zuerst mindestens 5 Werte vorliegen müssen.   

[Jam2]

edit:
Mir ist heute ein 1/3 CUL ausgefallen (Netzteil Raspberry defekt). Nicht nur der ausgefallene CUL hat nicht mehr funktioniert, kein CUL hat mehr etwas gesendet oder empfangen.
Ist das gewollt?

edit2:
Mit der neuen Beta hatte ich gerade bei allen Nachrichten und allen Thermostaten missingack (autoselectCUL = 0).
Ich teste morgen nochmals

[Wzut]

Natürlich darf in einer Gruppe mal ein Teilnehmer ausfallen, die anderen können davon nichts wissen.
Wenn du überall missings ACKs hast dann ist IMHO dein erstes Problem noch aktuell -> kein CUL Empfang
Allerdings sehe ich da keinen Zusammenhang mit den MAX Modulen, egal ob alt oder Beta Version.

[Jam2]

Sorry, meine Nachricht war anscheinend nicht verständlich.
Zum ersten Thema: Hier haben die anderen CUL keine weiteren Telegrame mehr versendet und die Queue ist gewachsen. Ich hatte bisher kein sendpool definiert - ggf. lag es an dem.

Zum zweiten Thema:
Komischerweise hatte ich sobald ich auf die neue Beta gewechselt habe eine massive Zunahme von missingack. Was natürlich wenig Sinn macht - das hat sich heute wieder bestätigt.
Trotzdem lag es natürlich an etwas anderem - ein Wandthermostat mit leeren Batterien (https://www.youtube.com/watch?v=ZR2VQ460duk)


Die neue Beta läuft soweit gut. Fakewt assoc funktioniert wie erwartet.

[Wzut]

Ich hatte bisher kein sendpool definiert
--snipp ---
ein Wandthermostat mit leeren Batterien (https://www.youtube.com/watch?v=ZR2VQ460duk)

a. einen sendpool brauchst du nicht, viel wichtiger wäre eine Antwort auf meine Fragen vom 26 Oktober 2020, 06:58:27 gewesen.
Multi IO ist nicht trivial , läuft aber bei mir sehr gut wenn man alles richtig macht.

b. ahhh ein Babbling Idiot -> https://de.wikipedia.org/wiki/Babbling_idiot
HomeMatic hat da auch so seine Probleme -> https://asksinpp.de/Grundlagen/FAQ/babbling_idiot.html
Ich selbst habe da mal zwei Tage mit meiner LaCrosse Welt gekämpft wo ein defekter Sensor alles lahm gelegt hat.
Also kann man MAX da mit einreihen und sollte das Problem im Hinterkopf behalten.
Wäre halt ein Traum wenn das tolle HM Teil auch MAX könnte -> https://github.com/jp112sdl/AskSinAnalyzer/wiki

[Dr. Ulfi]

Gibt es schon einen Plan, wann das Beta freigegeben werden soll?

[Wzut]

wenn keine dicken Brocken mehr dazukommen : nach dem 10. Dezember 2020 , da habe ich wieder mehr Zeit.

[fhem@supergut]

ich installiere dann mal die Beta, Rückmeldung folgt

[Parador]

wollte einfach mal schnell Danke für die Integration von delay_open und delay_close sagen! Einfach SPITZE! Habe gerade die Beta installiert funktioniert 1A!

[Parador]

Hallo Zusammen,

kann nun doch noch ein komisches Verhalten feststellen. Habe eine Türe mit einem delay_open = 15 ausgestattet.
Wenn ich nun die Türe öffne und innerhalb der 15 Sekunden wieder schließe. Passiert der Reihe nach folgendes:

Türe auf: Sensor merkt Tür auf - vSC geht erst auf opened dann auf opened (waiting)
Türe zu: Sensor merkt Türe zu - vSC geht auf closed
dann 15 Sekunden nach Türe auf, geht der vSC auf opened und bleibt dort, der Sensor bleibt closed, der Thermostat schaltet auf Fenster offen und bleibt dort.

damit wird also das at ausgeführt und bleibt erhalten, obwohl die Türe ja schon wieder zu ist... sollte da das at nicht gelöscht werden? oder der vSC anhand des Sensors merken, dass schon wieder zu ist?

[Wzut]

Ich hatte da am 25 Oktober nachgebessert :

Bei der Gelegenheit habe ich auch die ats gegeneinander verriegelt, d.h. falls ein at_close angelegt wird und es noch ein at_open gibt wird dieses gelöscht und vice versa.

leg doch mal ein close_delay von 1 Sekunde an und schaue ob das at dann gelöscht wird ( ich kann im Moment nicht testen )

[Parador]

Ja, wenn ich ein delay_close = 1 dazu aktiviere klappt's, das delay_open at wird gelöscht.
Wieder zurück bei delay_close = 0  gehts wieder nicht... das delay_open at wird ausgeführt.