Die MAX Module heute und die Aussichten für 2020

[birdy]

Hallo Wzut

Habe gerade die vermutliche Lösung ausprobiert und 10_MAX.pm angepasst.

Code Auswählen Erweitern

# Build state READING
my $state = ReadingsVal($name, 'state', 'waiting for data');

Das Verhalten hat sich wie folgt geändert.

Jetzt generiert jeder Poll ..
-   Für jeden Fensterkontakt ein ein opened und ein closed Event
-   Für jedes andere MAX Device (Radiator, Thermometer) einen opened Event

Meine Notfys werden pausenlos aufgerufen. Ich habe den Change wieder Rückgängig gemacht.

[Wzut]

sorry , da war ich geistig bei meiner aktuellen Test Version !
richtig wäre bei euch :

Code Auswählen Erweitern

my $state = ReadingsVal($shash->{NAME}, 'state', 'waiting for data');

ich check das heute ein, es ist dann morgen ab 8:00 Uhr via update verfügbar.
Bitte auch die 14_CUL_MAX updaten, da habe ich auch noch einen Tippfehler gefunden.

[birdy]

Ok, werde updaten sobald verfügbar.

[birdy]

Update funktioniert ausgezeichnet

[jhohmann]

Bei mir sieht es nach dem Update auch gut aus.
Wobei ich jetzt meine Notifys und Prüfungen auf onoff stehen lasse.
Wenn das state ein Mischzustand ist (teilweise kommt da manchmal auch ein rf error mit dran), scheint mir das der bessere Weg zu sein.
Auch das mit den ReadingsNum("Wohn_Fenster", "onoff", undef) habe ich auf einen sinnvollen Default Wert korrigiert.
Mein CULMAX Device habe ich gelöscht und mit meiner MAXLAN Adresse neu definiert. Nur das ohne das Update der Module hatte aber nicht gereicht.
Jetzt werde ich mein System weiter beobachten und prüfen, ob ich irgendwann mal auf mein MAXLAN ganz verzichten kann/will.

Vielen Dank für die Unterstützung 

[Wzut]

beim testen gestern mit MAXLAN und CUL_MAX Tandem ist mir noch eine Besonderheit aufgefallen :
Wenn die CUL_MAX Adresse (bsp 123456) ungleich der MAXLAN Adresse ist erkennt CUL_MAX die Telegramme des CUBE als normales MAX Device.
Das ist u.A. der Grund warum komische Readings im MAXLAN Device auftauchen können und man kein Dummy MAX Device mit der Adresse anlegen kann.
Hier werde ich nochmal nacharbeiten müssen, damit CUL_MAX den Cube als Bruder des CUL erkennt.

[birdy]

Hallo jhohmann

Basieren Deine Notify's auf den onoff Events. Wie hast Du diese definiert?
Ich habe es gestern versucht, aber nicht hinbekommen 
Gruss, birdy

[Wzut]

dann zeig doch mal was du gemacht hast und event-on-change-reading hast auch angepasst ?

[jhohmann]

Auf die schnelle, bin gerade nicht am Rechner.

Code Auswählen Erweitern

defmod ntArbeitFenster notify Arbeit_Fenster:onoff:..* {
my $state=ReadingsNum("Arbeit_Fenster", "onoff", 0);
}
Geht bestimmt auch eleganter, aber für mich hat es gereicht 

[birdy]

dann zeig doch mal was du gemacht hast und event-on-change-reading hast auch angepasst ?

event-on-change-reading habe ich beim ShutterContact mit .* definiert

Die notify's hatte ich wie vorgeschlagen defniert :

Code Auswählen Erweitern


DEFMOD <name> notify   .*:onoff:1 {winOpenStart($NAME)}
DEFMOD <name> notify   .*:onoff:0 {winOpenStop($NAME)}


[Wzut]

onoff:.1 bzw. onoff:.0 , der Punkt vor der Zahl macht den Unterschied

[birdy]

onoff:.1 bzw. onoff:.0 , der Punkt vor der Zahl macht den Unterschied

Ja so funktioniert es. Ein kleiner aber feiner Unterschied.

Wzut was ist nun Deine Empfehlung. Auf was soll der Notify idealerweise  reagieren   onoff oder  opened / cosed?

Vielen Dafür Deine Unterstützung.

Gruss, birdy

[Wzut]

ich dachte eigentlich das sei klar : onoff kann nur 1 oder 0 sein, state dagegen kann noch Zusätze haben wie den rferror.
D.h. um state sauber zu verarbeiten musst du wesentlich mehr Aufwand treiben wie das simple 0/1 beim onoff.

[birdy]

ich dachte eigentlich das sei klar : onoff kann nur 1 oder 0 sein, state dagegen kann noch Zusätze haben wie den rferror.
D.h. um state sauber zu verarbeiten musst du wesentlich mehr Aufwand treiben wie das simple 0/1 beim onoff.

Falls der State einen rferror enthält, kann man dann trotzdem davon ausgehen, dass bei onoff ein zuverlässiger Wert geliefert wird?

[joras]

Hallo Wzut,
vielen Dank für die viele Arbeit an den MAX-Modulen. Du hattest vor einiger Zeit mal ein "virtualThermostat" erwähnt, das wohl noch nicht ganz reif war.
Gibt's da schon etwas neues? Ich würde liebend gerne meine FKs mit einem virtuellem Thermostat koppeln (associate), damit sie ihre Meldung nicht nur einmalig als Broadcast schicken. Bisher habe ich dafür noch keine Lösung gefunden. Die Meldung der FKs geht bei mir nicht 1:1 an die Thermostate, so dass ich die nicht direkt koppeln kann.