Neue Beta Test Runde für alle MAX Module

[Wzut]

Wie ich bereits in einem anderen Thread schrieb :
Ich habe die letzten Monate alle drei MAX Module intern stark umgebaut. Viel Neues ist dabei für euch User leider nicht enstanden, aber bevor ich diese Versionen auf die breite Masse via update loslasse würde ich mich wieder über leidensfähige Tester freuen

ich habe zwar bei mir viel getestet und nutze diese Versionen auch selbst auf meinem Live System, aber .....
Wenn möglich möchte ich auch an den bisherigen SVN Versionen keine Änderungen / Erweiterungen mehr vornehmen sondern diese hier als zukünftige Basis nehmen.


Versionen:
00_MAXLAN.pm -> ??.??.?
10_MAX.pm -> 14.01.2024
14_CUL_MAX.pm -> 16.11.2024

[dirk.k]

Installiert.
Bisher keine Auffälligkeiten.

Danke

[thburkhart]

ebenfalls installiert
keine Probleme

[Wzut]

Bei diese Gelegenheit noch eine Bitte : schaut mal nach dem set saveConfig Kommando, ich habe hier das Problem in einem anderen Thread das sich FHEM bendet mit der Fehlermeldung das main::Logdir nicht gefunden wurde. Erklären kann ich es mir noch nicht da Logdir() eine interne Funktion von fhem.pl ist.

[Jam2]

Kann jemand Deassociate fakeWT probieren?
Im Log bekomme ich:

2020.10.18 19:08:44.386 1: UG_BU_Thermostat, invalid command/argument 81190018
2020.10.18 19:09:08.634 1: UG_KU_Thermostat, invalid command/argument 8119572C
2020.10.18 19:09:35.868 1: UG_SZ_Thermostat, invalid command/argument 81194B2C
2020.10.18 19:09:48.796 1: UG_WZ_Thermostat, invalid command/argument 81190018

Beim Associate von HT zu fakeWT kommt im Log:

2020.10.18 14:40:19.673 3: cm, target device 111111 has no name !
2020.10.18 14:40:19.673 3: CM_Parse, unhandled message WakeUp from UG_KU_Thermostat to MAX_111111, groupid : 0 , payload : 03 - ignoring !

[Wzut]

THX4Info, werd ich mir im Laufe der Woche nochmal genau anschauen

[Jam2]

Bei diese Gelegenheit noch eine Bitte : schaut mal nach dem set saveConfig Kommando, ich habe hier das Problem in einem anderen Thread das sich FHEM bendet mit der Fehlermeldung das main::Logdir nicht gefunden wurde. Erklären kann ich es mir noch nicht da Logdir() eine interne Funktion von fhem.pl ist.

Save all:
2020.10.18 19:56:23.027 1: ERROR evaluating { MAX_Save('all') }: Undefined subroutine &main::MAX_Save called at (eval 39018) line 1.

set UG_WZ_Thermostat saveConfig:
2020.10.18 19:57:43.528 3: UG_WZ_Thermostat, configSaved to ./log/UG_WZ_Thermostat.max

set UG_WZ_Thermostat saveConfig test:
2020.10.18 19:55:41.743 3: UG_WZ_Thermostat, configSaved to ./log/test.max


main::Logdir  kann ich daher nicht bestätigen

[Wzut]

ERROR evaluating { MAX_Save('all') }

ja da hat sich inzwischen die Syntax geändert :

Code Auswählen Erweitern

{ FHEM::MAX::MAX_Save() }
und das Thema Logdir() ist inzwischen auch geklärt : Die Funktion kam erst im Frühjahr in fhem.pl.

[thburkhart]

überschreibt eigentlich ein update von FHEM die Beta?

[Wzut]

na klar, wenn man es verhindern will -> attr global exlude_from_update

[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]

Kann jemand Deassociate fakeWT probieren?

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]

Ich habe aktuell ein komisches Phänomen

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.