Die MAX Module heute und die Aussichten für 2020

[Wzut]

Auch wenn es um die MAX Module scheinbar ruhig geworden ist : Ich habe die Corona Kurzarbeitszeit nicht verschlafen sondern wirklich viel programmiert.
Das betrifft alle Module die von mir betreut werden, da wir im Frühjahr hier einigen Wirbel hatten zum Thema Perl Programmierung und unsere Module im FHEM Umfeld.
Anyway, der User merkt davon nichts, aber intern hat sich der Code doch stark verändert. Dabei besteht natürlich immer die Gefahr das Funktionen die vorher einwandfrei liefen nun plötzlich neue Macken zeigen wo bisher keine waren. Ich denke es wird wieder Zeit für eine neue Beta Runde bevor ich das alles wieder via Update auf euch loslasse ( bei mir laufen sie schon seit Juni auf dem Live System )

Das Thema virtuelles Wandthermostat habe ich dabei nicht so intensiv weiter verfolgt, u.a. war ich mir halt auch unsicher ob es wirklich Bedraf dafür gibt.
Aber mal Hand aufs Herz : Was versprichst du dir vom Einsatz eines vWT ? Nur damit die FKs Unicast Telegramme verschicken ? Ich sehe da keinen wirklichen Vorteil, denn autark sind sie damit ja immer noch nicht sondern nach wie vor von einem laufendem FHEM abhängig. Die eigentliche Idee für ein vWT war aber etwas komplexer, aber deine einfache Anforderung solle das was ich bis jetzt habe erfüllen. 

[joras]

Hallo Wzut,

das sind ja super Neuigkeiten

Ich habe immer wieder aber nicht extrem häufig das Problem, dass die Broadcast-Telegramme "nicht ankommen". Die RSSI bei korrekt empfangenen Nachrichten ist okay, vermutlich handelt es sich also um kurzzeitige Störungen auf dem Funkkanal. Mit einem SDR-Empfänger habe ich gelegentlich mal ein breitbandiges Signal gesehen, vielleicht hat also ein Nachbar einen alten Funkkopfhörer...

Mein Ziel für das associate sind also retries bei ausbleibendem Ack von FHEM und/oder zumindest die stündliche Wiederholung des Status. Letzteres könnte ich auch mit einem "im Schrank liegenden" WT schaffen, aber ersteres geht nur, wenn ich den FK mit FHEM verbinden kann. Die ganzen zusätzlichen Funktionen eines echten, virtuellen Thermostats würde ich also nicht nutzen wollen.

[Heuberg]

Mahlzeit,

schön zu hören, daß Du hier die Weiterentwicklung vorantreibst  Gerne bin ich mit dabei beim Testen.

Viele Grüße Rainer

[Jam2]

 Beim Beta-Testen bin ich auch dabei.
Meine Heizperiode fängt langsam aber bereits an.

[Dr. Ulfi]

Bin gerade dabei den virtualShutterContact für meine Secusignal Fenstergriffe einzurichten. Eins klappt schon, beim zweiten habe ich noch ein Problem mit dem Attribut für den externen Sensor. Ich kann doch mehrere externe Sensoren verwenden? Da muss ich noch mal Testen...

Meine Frage bezieht sich aber auf die Möglichkeit einer Reaktionsverzögerung bei Fenster offen. Es macht einfach keinen Sinn, dass das Thermostat sofort losrennt, wenn man den Griff betätigt, insbesondere bei Terrassen- oder Balkontüren. Da lässt sich doch sicher eine Verzögerung bei der Statusübernahme einbauen...

Ich glaube nicht, dass nur mich das stört... und ein Dummy dazwischenschalten ist vielleicht ein Workaround, aber  nicht sehr elegant.

Danke

[Wzut]

Ich kann doch mehrere externe Sensoren verwenden?

IMHO nein, das müsste ich intern etwas ändern damit das mit den durchgreichten Events funktioniert, habe das aber jetzt nicht probiert.

Das Thema mit der Zeitverzögerung kommt auch immer wieder mal hoch, jetzt nicht explizit bei MAX sondern generell bei der Kombi FK und HT.
Bei direkt gepeerten Geräten (MAX, HM) hat man da aus Modul Sicht gar keine Chance bremsend einzugreifen.
Sicher bei dem viruellen könnte man Vor und Nachlaufzeiten einbauen.
Allerdings muss man das auch irgendwie anzeigen, z.B. beim state -> open / open wait / close / close wait oder gleich als Countdown ala close 0:10
D.h. für den User muss ersichtlich sein ob die offen Meldung da ist und ob sie bereits weitergegeben wurde.

Meinugen / Vorschläge zur Umsetzung ?

[Dr. Ulfi]

Theoretisch kann man auch die MAX-FKs ja auch als virtuelle FKs definieren. Dann sollte man eine wait_time_open und eine wait_time_close definieren können. Ein Countdown ist m.M. nicht notwendig, aber ein Status  'open / close wait  xx sek.' wäre sicher von Vorteil.

[Wzut]

Ich kann doch mehrere externe Sensoren verwenden? Da muss ich noch mal Testen...
---snipp ---
Da lässt sich doch sicher eine Verzögerung bei der Statusübernahme einbauen...

a. ich habe da eine Zeitlang hin und her überlegt und werde keine Unterstützung für mehrere externe Sensoren gleichzeitig einbauen.
Grund : wenn mehr als ein externer Sensor vorhanden ist muß auch eine und/oder Logik eingebaut werden wie diese auszuwerten sind.
Das möchte ich mir ersparen und empfehle in so einem Fall die externen Kontakte in eine Structure zu packen und dort die Logik zu definieren.
Die Structure kann dann der  der externe Sensor für den vSC sein.

b. Das habe ich jetzt mit zwei neuen Attributen delay_open und delay_close umgesetzt die nur der vSC hat.
Verzögerungszeit ist in Sekunden anzugeben (default 0)

Die neue Version des 10_MAX Moduls werde ich heute Abend im Thread    
Neue Beta Test Runde für alle MAX Module -> https://forum.fhem.de/index.php/topic,115018.0.html zur Verfügung stellen.

[Dr. Ulfi]

Top !

a) macht Sinn, eine 1 zu 1 Beziehung ist immer das unkomplizierteste.

b) dann werde ich das ab morgen mal testen.

Danke

[Dr. Ulfi]

Listing:

Code Auswählen Erweitern


   Internals:
   DEF        virtualShutterContact abc111
   FUUID      5f8c4aec-f33f-8ee8-462d-b5cefbe88505d711
   IODev      CULMAX
   NAME       vTuerkontakt_MAX_abc111
   NOTIFYDEV  Terasse_Tuergriff
   NR         358
   NTFY_ORDER 50-vTuerkontakt_MAX_abc111
   STATE      closed
   SVN        BETA
   TYPE       MAX
   addr       abc111
   devtype    6
   type       virtualShutterContact
   READINGS:
     2020-10-24 19:56:09   error           invalid or missing value  for READING groupid
     2020-10-24 19:56:09   groupid         0
     2020-10-24 20:31:56   msgcnt          102
     2020-10-24 20:31:56   onoff           0
     2020-10-24 20:31:56   state           closed
     2020-10-24 20:33:33   windowOpen      0
Attributes:
   IODev      CULMAX
   comment    Configured using template MAX_ShutterContact_dark
   debug      1
   delay_close 40
   delay_open 20
   devStateIcon closed:fts_door_right opened:fts_door_right_open
   event-on-change-reading .*
   externalSensor Terasse_Tuergriff:state:(open.*|til.*|offen):(close.*|zu)
   icon       hm-sec-win
   model      virtualShutterContact
   room       MAX
   userattr   delay_close delay_open

und log:

2020-10-24 20:29:53 at at_open_vTuerkontakt_MAX_abc111 Next: 20:30:33
2020-10-24 20:29:53 Global global DEFINED at_open_vTuerkontakt_MAX_abc111
2020-10-24 20:30:33 MAX vTuerkontakt_MAX_abc111 onoff: 1
2020-10-24 20:30:33 MAX vTuerkontakt_MAX_abc111 opened
2020-10-24 20:30:33 MAX vTuerkontakt_MAX_abc111 windowOpen: 00:00
2020-10-24 20:31:16 at at_close_vTuerkontakt_MAX_abc111 Next: 20:31:56
2020-10-24 20:31:16 Global global DEFINED at_close_vTuerkontakt_MAX_abc111
2020-10-24 20:31:33 MAX vTuerkontakt_MAX_abc111 windowOpen: 00:01
2020-10-24 20:31:56 MAX vTuerkontakt_MAX_abc111 onoff: 0
2020-10-24 20:31:56 MAX vTuerkontakt_MAX_abc111 closed
2020-10-24 20:31:56 MAX vTuerkontakt_MAX_abc111 windowOpen: 0

Eigentlich hatte ich unterschiedliche delay-Zeiten eingestellt und erwartet, es hat aber bei open und close immer eine Verzögerung von 40 sek. gegeben.

[Wzut]

ja saublöder copy & paste Fehler. Ich tausche heute Abend die Datei aus.
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.
Bei deiner Def ist mir noch aufgefallen : (open.*|til.*|offen):(close.*|zu)
Welche Events erzeugt denn Terasse_Tuergriff nun wirklich ?
Ggf. mal den vSC auf verbose 5 stellen.

[Dr. Ulfi]

Dann werde ich morgen die Dateien herunterladen und testen

Meine MAX Fensterkontakte liefern "closed" und "opened" und die Türgriffe selbst
"closed", "open", "tilted" und "open_from_tilted"

[Wzut]

dan wäre doch  (open.*|til.*):close.* völlig ausreichend wenn die deutschen Bezeichnungen nicht im Event vorkommen.

[Dr. Ulfi]

Ich werde diese Optimierung einbauen, Danke

(sind historisch gewachsene Altlasten über die man sich keine Gedanken macht, so lange es funktioniert)

[Dr. Ulfi]

Jetzt klappt es mit den Verzögerungszeiten     prima