Autor Thema: neue Versionen von 10_MAX und 14_CUL_MAX ab 02.05.2020  (Gelesen 4829 mal)

Online Wzut

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 3841
neue Versionen von 10_MAX und 14_CUL_MAX ab 02.05.2020
« am: 12 Dezember 2019, 19:26:20 »
10_MAX

neues Set Kommando : attrTemplate (svn : 21446 2020-03-18 18:07:50Z)

Fix : kein autocreate für neue Geräte vom Typ Eco Taster (PushButton)
Fix : vorhandene Geräte konnten nicht mittels defmod editiert werden (svn : 21446 2020-03-18 18:07:50Z)
Fix : bei set desiredTemperatur xy until Datum Zeit (Partymodus) wurde zwar sehr streng geprüft ob alle Werte zwei bzw. vierstellig sind,
es fand allerdings keinerlei Prüfung statt ob das Ende überhaupt sinnvoll ist  (in der Zukunft liegt). Die Eingaben müssen nun weniger streng sein,
zb ist jetzt auch möglich  set desiredTemperatur 19 until 1.12.20  8:0 , die Minuten dürfen allerdings wie bisher nur 0 oder 30 sein 

neues Attribut : dummy (0,1) -> default 0  (svn : 21446 2020-03-18 18:07:50Z)
Das Attribut ist quasi ein halbes ignore , d.h. es können dann für das Device keine set Kommandos mehr abgesetzt werden und es wird auch keine Zeit Telegramme mehr bekommen, aber dennoch werden alle Readings aktualisiert. Vorteil für MAX Geräte die eigentlich für diese Instanz "fremd" sind oder wenn man massive Credit Probleme hat und man versucht Ruhe ins System zu bekommen ohne die Geräte gleich zu löschen oder auf ignore zu setzen.
 
neues Attribut : mode -> wird intern beim Start gesetzt und enthält den Gerätetyp. Die FHEM Statistiken werten dieses Attribut aus  (svn : 21446 2020-03-18 18:07:50Z)
neues  Attribut : debug -> erzeugt zusätzliche Readings die im Fehlerfall nützlich sein können
neues Attribut : CULdev -> kommt nur zum Einsatz wenn CUL_MAX mehr als einen CUL hat.
neues Attribut : actCycle -> default 0 , mögliche Werte sind als Stunden:Minuten einzutragen (hh:mm) Durch das Attribut wird wie bei Homematic ein Zeitraum definiert in dem überwacht wird ob vom Gerät ein Telegramm durch 14_CUL_MAX empfangen wurde. Ist diese Zeitspanne überschritten wird im Gerät das neue Reading Actifity auf dead gesetzt und kann durch andere FHEM Geräte (notify/DOIF) weiter verarbeitet werden. Die Überprüfung findet alle 5 Minuten durch CUL_MAX statt.     

Logging bei verbose 5 erweitert.

neue Set Funktion : deviceRename
Vllt. wird so der eine oder andere User doch noch ermutigt seinen MAX Geräten einen anderen Namen als den von autocreate erzeugtem MAX_112233 Namen zu geben. Im Unterschied zum FHEM rename Konsole Kommando werden hier eventuell betroffene FileLogs gleich mit geändert.

neues Attribut : externalSensor (device:reading:fakeWT)
Wenn in einem Raum kein Wandthermostat vorhanden ist aber die Raumtemperatur zusätlich mit einem externen Sensor in FHEM erfasst wird (z.B. LaCrosse)
kann dessen aktueller Temperatur Wert zur Berechnung des Readings deviation benutzt werden statt des eigenen Readings temperature
Der dritte optionale Parameter (fakeWT -> 0/1) legt fest ob mit jedem Event Sensor Device dieser zum MAX Device durchgereicht wird und ausserdem über das CULMAX Device der Befehl fakeWT abgesetzt werden soll. D.h. man spart sich das im Wiki beschriebene notify und den Code Teil in der 99_myUtils 
WICHTIG : Wenn die automatische fakeWT Funktion aktiviert wird muß man unbedingt dafür sorgen das vom Temperatur Device die Temperatur Events nicht zu oft kommen, da sonst recht schnell die Credits aufgebraucht werden. Bsp LaCrosse Sensoren senden alle paar Sekunden ihre Werte, die Events können leicht beschränkt werden mit dem Attribut event-onchange-reading .* und ggf attr event-min-interval temperature:600

neue Readings : peerList und peerIDs  (Name analog zur HomeMatic Welt)
Schon oft im Forum angefragt : Wie lese ich aus einem MAX Device die anderen Geräte aus die mit diesem assoziiert sind (peers) ?
Einfache Antwort : gar nicht , bzw. bis heute ist kein Befehl bekannt der irgendetwas von einem MAX Gerät auslesen kann.
Die jetzt eingebaute einfache Lösung überwacht den Datenaustausch zwischen zwei Geräten und sammelt diese Daten in den beiden Readings.
So kann man z.B. recht leicht herausfinden ob ein Fensterkontakt wirklich mit seinem HT / WT assoziiert ist oder ob er seinen Status lediglich als Broadcast Nachricht verschickt.

neues Reading : peers  (default nicht vorhanden) Komma getrennte Liste aller MAX Devices für die ein set associate ausgeführt wurde.
Wichtig : diese Liste kann leider nicht direkt vom Device abgerufen werden, das Modul sammelt hier die ausgeführten set associate Kommandos und entfernt auch wieder Geräte für die ein deassociate durchgeführt wurde.

neue Set Kommandos : saveConfig , restoreReadings , restoreDevice
Man kann die MAX Readings in zwei Gruppen einteilen : wichtige und unwichtige Readings.
Zu den unwichtigen Readings gehören jene die durch Nachrichten vom Device zu FHEM ständig verändert/aktualisiert werden.
Die wichtigen Readings (HT & WT) sind eigentlich in Wahrheit gespeicherte config Werte die nicht wieder vom Device durch ein Kommando zurück gelesen werden können.
Leider sind diese Werte auch noch in Gruppen zusammen gefasst und können auch nicht einzeln gesetzt werden, sondern nur zusammen mit gültigen Werten ihrer Gruppenmitglieder.
Beispiel  : die fünf Readings / config Werte  decalcification, boostDuration, boostValveposition, maxValveSetting und valveOffset bilden so eine Gruppe.
Möchte man eines davon mittels eines Set Kommandos ändern müssen auch die Werte der anderen vier mit übertragen werden ! Liegen diese aber nicht vor so werden vom MAX Modul default Werte gesetzt, diese müssen aber nicht zwangsläufig mit den aktuellen Werten im Device übereinstimmen.
Daher ist es sehr wichtig immer die aktuellen Config Werte in den wichtigen Readings zu haben, FHEM speichert i.d.R alle Readings in der Datei fhem.save und schreibt sie bei einem Neustart auch wieder zurück. Es gibt aber Fälle (Absturz, defekte SD Karte , Tausch eines MAX Geräts) wo diese Readings nicht zur Verfügung stehen.
Das saveConfig Kommando speichert alle wichtigen Readings in einer eigenen Datei default <name>.max im Verzeichniss ./log/ (Attribut global -> logpath) . Das restoreReadings stellt sie wieder her ohne dabei die Werte zum Thermostat erneut zu übertragen ! 
Bei beiden Kommandos kann optional ein andere Name verwendet werden. Diese neuen Kommandos sollen die ältere externe 99_myUtils Lösung MAX_Backup und MAX_Restore ersetzen.
Tipp: um jetzt nicht jedes Device einzeln auswählen und das set saveConfig Kommando auszuführen kann man in einem beliebigen Device als Ziel Namen saveAll
eingeben, damit werden in einem Rutsch alle Dateien erzeugt.  Alternativ über die Kommandozeile in FHEMWEB:
{ MAX_Save('all') }restoreDevice : führt zuerst ein restoreReadings durch und überträgt danach alle wichtigen Werte erneut zum MAX Device.
ACHTUNG : das vollständige Wiedeherstellen der Device Werte verbraucht mehr als 600 Credits !!!
Zu diesen neuen Set Befehlen gehört noch das ebenfalls neue Attribut autosaveConfig.
Ist es auf 1 gesetzt wird jedesmal bei einer Änderung automatisch saveConfig aufgerufen.

neues Set Kommando : exportWeekprofile <weekprofile name>
Wer das Modul weekprofle noch nicht kennt sollte es sich unbedingt einmal anschauen, es vereinfacht das Handling mit Wochenprofilen erheblich.
Um nun das aktuelle Wochenprogramm an ein neu erstelltes weekprofile Device zu übergeben, kann export Weekprofile benutzt werden.
Das weekprofile Device unterstützt auch seit dieser Woche einen Import Befehl, d.h. der User kann nun entweder vom MAX Device zum weekprofile exportieren oder am weekprofile Device das gewünschte MAX Device importieren. 

neues Device : virtualShutterContact
Der virtualShutterContact ist wie der Name schon sagt kein "echtes"  Gerät sondern ein virtuelles und muß vom User von Hand angelegt werden.
Sinn und Zweck ist die Ablösung des bisherigen Device fakeSC und die Beseitigung der damit verbunden Probleme beim Einsatz von mehr als einer Gruppe.
Anwendung :
1. zuerst legt man sich ein neues MAX Device an , Bsp :
define vFK_1 MAX virtualShutterContact 987654wobei der Name und die sechstellige MaxID natürlich frei gewählt werden dürfen , sie müssen halt nur eindeutig sein. Wichtig ist nur der neue Typ "virtualShutterContact" da nur dieser die entsprechenden Funktionen mitbringt.
2. mit dem set Kommando "set VFK_1 groupid X" dem Device eine GroupID geben die zu den Geräten (HT / WT) passt die er später steuern soll.
3. ggf bei den HTs/WTs die GroupID ebenfalls anpassen. Die GroupID ist in der Original ELV Firmware auf dem Cube der Raum und daher extrem wichtig das Geräte die zusammen gehören auch die gleiche GroupID haben !
4. Nun jedem betroffenem HT / WT der Gruppe mit set associate den viruellen Kontakt bekannt machen ( er sollte in der DropDown nun zur Verfügung stehen )
Das Ganze ist einseitig , d.h. am virtuellen Kontakt wird nichts assoziiert, denn er "kennt" seine Partner.

5. am virtuellenShutterContact ggf. das Attribut sendMode ändern. (default : Broadcast)

6. Jetzt kann direkt am virtuellen Kontakt mit set open / close der neue Status verschickt werden.

WICHTIG :
Diese Version bringt zwei neue Attribute mit :
sendMode : peers,group,Broadcast (default Broadcast) -> bestimmt wie der virtuelle Fensterkontakt mit den HTs/WTs "spricht"
Mode Broadcast : der vFK sendet nur ein Telegramm mit Ziel alle ohne auf eine Rückmeldungen zu warten.
Vorteil : verbraucht wenig Credits wenn mehr als ein HT/WT im gleichen Raum ist
Nachteill : wenn eines der Geräte das Telegramm nicht empfängt erfolgt keine Reaktion / Meldung

Mode group : sendet an jedes Mitglied seiner Gruppe ein eigenes Telegramm
Vorteil : erfolgt vom Ziel Gerät kein ACK wird das Telegramm bis zu zweimal wiederholt.
Nachteil : verbraucht mehr Credits als Broadcast, ggf. unnötige Wiederholungen falls nicht alle Mitglieder der Gruppe assoziert sind.

Mode peers : sendet nur an "bekannte" Geräte, d.h. Komma getrennte Liste der Zieladressen am neuen Attribut peers
Vorteil : Flexibler als Mode group z.B. senden nur an WT in der Gruppe
Nachteil :  verbraucht mehr Credits als Broadcast

Wenn nur ein Partner HT oder WT vorhanden ist sind die beiden Modes peers & group in ihrem Verhalten identisch und der Verbrauch an Creadits ist auch nicht größer als beim Mode Broadcast. ( Falls keine Telegramme wiederholt werden müssen)

Das Device benötigt im Gegensatz zum fakeSC kein extra notify/DOIF sondern unterstützt wie die Thermostate das Attribut externalSensor direkt.
attr <name>  externalSensor <name des echten Fenster Kontakts>:<Reading das open/close signalisiert>:<RegEx für Fenster offen>:<RegEx für Fenster geschlossen>
Bsp :
attr vFK1 externalSensor HM_FensterBad:state:open:closed
attr vFK1 externalSensor HM_FensterBad:state:(open.*|til.*|offen):(close.*|zu)
attr vFK1 externalSensor China_FK:isopen:1:0

neues Attribut : dTempCheck -> (default 0) Überwacht im Abstand von 5 Minuten ob das Reading desiredTemperatur der Soll Temperatur im aktuellen Wochenprofil entspricht. (nur für Geräte vom Typ HT oder WT) Das Ergebniss steht als Abweichung im Reading dTempCheck, d.h. 0 = keine Abweichung. Die Überwachung ist nur aktiv wenn die Soll Temperatur ungleich der Window Open Temperatur ist.

neues Attribut : windowOpenCheck ->  Überwacht im Abstand von 5 Minuten ob bei Geräten vom Typ ShutterContact das Reading onoff den Wert 1 hat (Fenster offen , default 1) oder bei Geräten vom Typ HT/WT ob die Soll Temperatur gleich der Window Open Temperatur ist (default 0). Das Ergebniss steht im Reading windowOpen, Format hh:mm
Damit werden Nachrichten über offene Fenster (bsp Mail,Telegramm) etwas einfacher, da die Dauer direkt aus dem Reading windowOpen gelesen werden kann und nicht mehr selbst errechnet werden muss. Wenn der Zähler immer wieder bei 00:00 anfängt obwohl das Fenster noch offen ist setzt das Attribut timestamp-on-change-reading mindestens auf desiredTemperatur beim HT & WT, beim Fensterkontakt auf isopen oder gleich auf .*
« Letzte Änderung: 01 Mai 2020, 14:19:28 von Wzut »
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher
Gefällt mir Gefällt mir x 14 Liste anzeigen

Online Wzut

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 3841
Antw:neue Beta Versionen von 10_MAX und 14_CUL_MAX
« Antwort #1 am: 11 März 2020, 12:57:59 »
 
14_CUL_MAX

Fix : wenn das CUL_MAX Device vor dem CUL Device in der fhem.cfg steht, kann es beim Start den InitString des CULs nicht richtig setzen.
Durch den Fix wird beim Start die Bearbeitung des CUL_MAX Device verzögert um sicher zustellen das das CUL Device vorhanden ist.
 
neues Set Kommando : deleteSendQueue
Für den Fehler / Problemfall , damit lässt sich die SendQueue des CUL_MAX Device löschen ohne FHEM neu starten zu müssen.

set fakeSC und fakeWT als DropDown Feld Auswahl

Logging bei verbose 5 erweitert 

neues  Attribut : debug -> erzeugt zusätzliche Readings die im Fehlerfall nützlich sein können
neues Attribut : broadcastTimeDiff , default 10  -> Es gibt hier mehr als einen Thread in dem sich User darüber beklagen ihre WTs fordern viel zu oft die aktuelle Zeit beim CUL_MAX Device an. Das kann so schlimm werden das immer zuwenig Credits zur Verfügung stehen. Der Wert legt fest wie groß der Zeitunterschied in Sekunden zwischen der internen Uhr und FHEM sein muß damit ein Zeittelegramm verschickt wird. Achtung wird das Zeit Telegramm so unterdrückt blinkt einige Zeit das Radio Symbol am Gerät und im Status erscheint auch ein rf error. 

Unterstützung für mehr als ein IO Device im gleichen System :
Neues Attribut : IOgrp -> Komma getrennte Liste der vorhanden CULs. Beispiel : CUL1,nanoCUL usw.
Wenn IOgrp gesetzt ist kann an jedem MAX Device mit dem Attribut CULdev ausgewählt werden welches CUL Device dieses Gerät beim senden benutzen soll.
Eine automatische Umschaltung wie bei Homematic ist noch nicht möglich. D.h. ihr müsst jetzt noch selbst auswählen welchen Weg jedes Gerät beim senden gehen soll. 
 
Wichtig : IOgrp und CULdev sind nur für das Senden des Gerätes wichtig, der Empfang läuft immer über alle IOs (CULs) gleichzeitig !!
Es "gewinnt" immer das Telegramm das zuerst in FHEM eintrifft (das muß aber nicht das "Beste" sein !) , doppelte Nachrichten verwirft FHEM automatisch.

neues Kommando : get <name> showSendQueue
es wurde hier im Forum mehrfach schon der Wunsch laut das man sich gern anschauen möchte was denn noch so in der SendQueue festhängt, diese Befehl macht es nun möglich.
Hier mal eine Beispiel Ausgabe eines wartenden Telegramms für einen Fensterkontakt:
Zitat
        Time        | Destination | Command        | CUL
--------------------+-------------+----------------+----
2020-01-10 19:43:20 | Test_FK     | AddLinkPartner | CUL
--------------------+-------------+----------------+----


ACHTUNG : Nutzer von CUL_MAX sollten immer beide Dateien austauschen, da 14_CUL_MAX sehr stark von 10_Max abhängig ist

« Letzte Änderung: 01 Mai 2020, 14:04:07 von Wzut »
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher
Gefällt mir Gefällt mir x 5 Liste anzeigen