Neue Beta Test Runde für alle MAX Module

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

Vorheriges Thema - Nächstes Thema

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

dirk.k

Installiert.
Bisher keine Auffälligkeiten.

Danke

thburkhart

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

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

Jam2

Kann jemand Deassociate fakeWT probieren?
Im Log bekomme ich:
Zitat2020.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:
Zitat2020.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 !
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

THX4Info, werd ich mir im Laufe der Woche nochmal genau anschauen
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Jam2

Zitat von: Wzut am 18 Oktober 2020, 13:06:04
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
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

#7
Zitat von: Jam2 am 18 Oktober 2020, 20:01:22
ERROR evaluating { MAX_Save('all') }
ja da hat sich inzwischen die Syntax geändert :
{ FHEM::MAX::MAX_Save() }
und das Thema Logdir() ist inzwischen auch geklärt : Die Funktion kam erst im Frühjahr in fhem.pl.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

thburkhart

überschreibt eigentlich ein update von FHEM die Beta?
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

na klar, wenn man es verhindern will -> attr global exlude_from_update
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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

Wzut

Zitat von: Jam2 am 18 Oktober 2020, 19:18:42
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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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.
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 25 Oktober 2020, 21:52:25
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 ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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