Neue Beta Test Runde für alle MAX Module

Begonnen von Wzut, 14 Oktober 2020, 17:41:04

Vorheriges Thema - Nächstes Thema

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 !
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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 ...
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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 :
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.   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Jam2

#19
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
FHEM / Intel NUC / 8xMAX Fensterkontakte + 16xMAX Thermostate + fakewt + CUL / 20x Technoline TX29 / Hue Bridge / duefern / fbdect / mysensors / homekit
RasPi ser2net CUL
FHEM / RasPi PI / buderus logamatic / temperatursensoren

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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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.
FHEM / Intel NUC / 8xMAX Fensterkontakte + 16xMAX Thermostate + fakewt + CUL / 20x Technoline TX29 / Hue Bridge / duefern / fbdect / mysensors / homekit
RasPi ser2net CUL
FHEM / RasPi PI / buderus logamatic / temperatursensoren

Wzut

Zitat von: Jam2 am 07 November 2020, 17:24:04
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
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Dr. Ulfi

Gibt es schon einen Plan, wann das Beta freigegeben werden soll?
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

Wzut

wenn keine dicken Brocken mehr dazukommen : nach dem 10. Dezember 2020 , da habe ich wieder mehr Zeit.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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

#27
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 :
Zitat von: Wzut am 25 Oktober 2020, 08:21:19
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 )
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Parador

#29
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.