FHEM - Hausautomations-Systeme > MAX

Neue Beta Test Runde für alle MAX Module

<< < (3/25) > >>

Wzut:
Wie im anderen Thread bereits angekündigt habe ich das 10_MAX Modul im ersten Beitrag ausgetauscht.
Neu : beim Typ virtualShutterContact gibt es zwei neue Attribute : delay_open & delay_close , Wert ist in Sekunden anzugeben, default 0
Sind die Attribute gesetzt wird nach Empfang des externen Sensors die Information nicht direkt zum HT weitergegeben sondern um den jeweiligen Wert verzögert.
Im state Reading steht dann zusätzlich zum aktuellen Status (waiting)
Die Wartezeit läuft nicht im Modul intern sondern über ein temporäres at das im gleichen Raum wie der vSC liegt.

14_CUL_MAX habe ich auch ausgetauscht, da durch die delays auch eine Änderung nötig war.   

Wzut:

--- Zitat von: Jam2 am 18 Oktober 2020, 19:18:42 ---Kann jemand Deassociate fakeWT probieren?

--- Ende Zitat ---
Wurde bei mir in der aktuellen Beta mit FHEM Stop quittiert :(
Habe das jetzt gefixt und habe mehrfach das fakeWT assoziert und deassoziert , klappt jedesmal ohne Fehler.
Versuche ich allerdings ein deassociate obwohl der fakeWT gar nicht mehr als Peer im HT hinterlegt ist quttiert das HT das mit einem NACK.
Da allerdings intern das NACK wie ein ACK behandelt wird erzeugt das die Meldungen mit invalid command/argument 81xxxxx
Ich muss mal schauen da ich jetzt ja diese NACKs gewollt erzeugen kann an der Stelle das Logging noch etwas klarer zu gestalten,
betrifft aber jetzt wirklich nur den Text im Logfile nicht die eigentliche Funktion.

Jam2:
Ich teste es nächste Woche gleich mal.

Ich warte aktuell noch auf einen zusätzlichen CUL... Ich habe aktuell ein komisches Phänomen, welches meine Credits frisst.
CUL0 ist im EG - "weit entfernt" von UG-HTs
CUL1 ist im UG - direkt an UG-HTs

CUL1 bekommt aber von den UG-HTs keine(bzw. sehr wenige) ACK - diese werden mit Glück teilweise noch von CUL0 empfangen.

CUL1/CUL0 tauschen hat nicht geholfen. Ich prüfe mal direkt am CUL ob die ACK doch kommen und nicht an FHEM weitergeleitet werden.

Wzut:

--- Zitat von: Jam2 am 25 Oktober 2020, 21:52:25 ---Ich habe aktuell ein komisches Phänomen

--- Ende Zitat ---

Bei Multi IOs Lösungen muss man genauer hinschauen. maxid an beiden CULs gesetzt ?
Beide CULs als IOgrp am cm Device eingetragen ?
am UG-HTs das Attribut CULdev auf den CUL mit den besten RSSI Werten gesetzt ?
 

Wzut:
eine Bitte an alle die das Beta 14_CUL_MAX Modul nutzen :
Lasst euch mal in FHEMWEB ein list von eurem CUL_MAX Device ausgeben und schaut ob es bei den Internals einen Abschnit CHANGED gibt.
Bei mir steht da über 20 Mal der state des Gerätes. Bevor ich mir nun anderweitig Hilfe hole möchte ich sicherstellen das dies bei mir kein Einzelfall ist.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln