98_MSwitch - Support

Begonnen von Byte09, 25 März 2018, 12:19:58

Vorheriges Thema - Nächstes Thema

Byte09

Bechreibung im FhemWiki:
https://wiki.fhem.de/wiki/MSwitch



V2.08
Version_Datenstruktur V2.00

- neu  ATTR MSwitch_Read_Log (0/1)

diese Funktion ermöglicht den Zugriff auf das Logfile , um darauf zu reagieren , wenn das ATTR auf 1 gesetzt ist. Da dieses schnell sehr systemlastig werden kann sollte es nur in Ausnahmefällen eingesetzt werden.
Es gibt 3 Funktionsvarianten , abhängig von den Einstellungen:

1. bei gesetztem ATTR gibt es in dem Feld 'Trigger device: ' eine neue Option 'Logfile'. Wird dieses gewählt reagiert das MSwitch auf alle Einträge in dem Log , und generiert hieraus ein internes EVENT.

2. wird in dem Feld 'Trigger device: ' die Option 'GLOBAL' gewählt , reagiert MSwitch auf alle EVENTS - in Abhängigkeit der 'Whitelist' -und alle Logeinträge (bitte nur bei unvermeidlichem Bedarf einsetzen) .

3. bei gesetztem ATTR und der Auswahl eines Devices im Feld 'Trigger device: ' reagiert MSwitch auf alle EVENTS des angegebenen Devices und auf alle ( vermeintlichen ) Logeinträge dieses Devices.

'Vermeintlich' daher bedingt, das ich keine Möglichkeit habe ( zumindest habe ich bisher keine gefunden ) zu ermitteln, welches Device denn wirklich einen Logeintrag erzeugt hat ( hierfür müssste die fhem.pl angepasst werden ) . Als 'Notlösung' wird auf das Vorkommen des Namens des Devices in dem Logeintrag gefiltert und die Annahme vorausgesetzt , das bei Vorhandensein des Namens , der Eintrag von diesem Devive erzeugt wurde. Leider bedeutet das im Umkehrschluss, das ein Logeintrag ohne Vorkommen des Names nicht berücksichtigt wird !

Eine Auswertung 'eigener' Logeinträge ist nicht möglich , da dieses fast unweigerlich in einer Endlosschleife enden würde. Daher bleiben eigene Logeinträge unberücksichtigt und lösen keine Reaktion des MSwitches aus.
er noch eine Änderung machen , die ein aktivieren dieser Option generell nur in einem MSwitch pro Installation zulässt .

update auf die Testversion im GIT  ( Achtung dieses ist immer eine aktuelle Entwicklerversion ohne Anspruch auf Fehlerfreiheit ):
update all https://raw.githubusercontent.com/Byte009/FHEM-MSwitch/master/controls_mswitch.txt

eine Rückkehr von der Testversion zur SVN-Version ist in der Regl problemlos möglich . Im Einzelfall ( je nach Stand der Entwicklungsversion) kann es aber zu Kompatibilitätsproblemen kommen, insbesondere dann , wenn sich die Version_Datenstruktur unterscheidet. In diesem Fall bei Bedarf bitte kurz Anfragen.


gruss Byte09

Byte09

@det.

hi det. ,

wie schaut es denn bei dir mit den perlwarnings aus seit dem letzten Update ? Habe da einiges gemacht und hoffe das das gröbste raus ist ?

gruss Byte09

det.

 :) ist bedeutend besser geworden, seit dem letzten update !!!
LG
det.

Byte09

#3
Die Modulbeschreibung ist ab sofort hier zu finden:

https://wiki.fhem.de/wiki/MSwitch.pm


gruss Byte09

Byte09

Für eine zukünftige Änderung ist es Notwendig geworden , die Struktur der gespeicherten Daten aller MSwitchdevices zu ändern. Dieses geschieht automatisch mit dem Update, das ich eben abgelegt habe.

Nach Fhemneustart werden entsprechende Daten geändert , die interne Prüfziffer 'V_Check' wird von V 0.2 auf V 0.3 geändert. Nach dem Update ist ein Fhemneustart zwingend erforderlich .

Backupdateien, die vor diesem Update gemacht wurden sind danach nicht mehr verwendbar, d.H es sollte dann dringend die Funktion 'backup_mswitch' ausgeführt werden.

gruss Byte09




Byte09

kommendes update:

mit kommendem Update , was ab morgen früh verfügbar sein wird , gibt es folgende Änderungen:

- deutliche entschlackung des codes
- vollständeige Überarbeitung aller "conditions" betreffender Programmteile und deren RegEx , somit sind u.A. vollständige Sunset - Angaben möglich (z.B. [{sunset(0,"17:00","20:00")}]
- zusätliche Anzeige der "Klar" Schaltzeiten bei allen "Check Condition" funktionen zur besseren Kontrolle

Nötige Änderunge der Datenstruktur wurden bereits mit dem letzten Update vorgenommen , ansonsten wird die Änderung mit diesem Update durchgeführt.

Das Modul läuft mittlerweile ohne gravierende Fehler und kann meines Erachtens daher auch von weniger erfahrenen Usern genutzt werden, da es durchaus eine Alternative für User darstellen kann , die sich mit diversen anderen ( sehr guten ) Hilfsmodulen schwer tun.

Gruss Byte09

Byte09

ich habe das angekündigte update eben im git abgelegt.

Da ich hier leider gar keine Resonanz bekomme frage ich einfach mal in die Runde ob denn mal jemand das Modul getestet hat ?

Gruss Byte09

misux

Ich bin fast mit meiner Konfig fertig... Danach werde ich mich mit dem Modul beschäftigen, aber vorweg eine Frage:

Die schon erstellten DOIFs/ats etc... die man Manuell erstellt hat, werden diese ins Modul übernommen? oder muss man diese im Modul neu erstellen wenn man nur auf das Modul umsteigen möchte?

Gruß und vielen Dank für deine Mühe!

Byte09

#8
Zitat von: misux am 04 April 2018, 12:43:40
Ich bin fast mit meiner Konfig fertig... Danach werde ich mich mit dem Modul beschäftigen, aber vorweg eine Frage:

Die schon erstellten DOIFs/ats etc... die man Manuell erstellt hat, werden diese ins Modul übernommen? oder muss man diese im Modul neu erstellen wenn man nur auf das Modul umsteigen möchte?

Gruß und vielen Dank für deine Mühe!

Hi Misux,

eine "übernahme" von doifs, notifys etc. ist nicht möglich. Ich hatte das mal angedacht , rudimentär war die Funktion auch schon vorhanden. Ich habe das aber mit dem Update vom 23.03.18 "remove function 'absorb'" rausgenommen da es zum ersten das Modul unnötig aufgebläht hat und ich es aus mehrfacher Hinsicht als ... naja ... , sagen wir mal "doof" befunden habe.

Doifs, Notifys, at etc. - vergleichbare Funktionen sind aber schnell eingerichtet , auch komplexere , wenn man sich mal reingefunden hat .

Nur noch zur Info, da dieine Frage ein Missverständniss vermuten lässt . MSwitch ist kein Gerüst um bestehende Doifs etc. herum , sondern ein komplett eigenständiges Modul , was alles benötigte selber mitbringt - ich habe mein System im Dezember komplett umgestellt und komme seit dem mit MSwitch 'only' aus (Bildanhang).

Gruss Byte09.


misux

Okay, dann kommt noch ganz schön Arbeit auf mich zu... und man sollte auf jeden Fall das DOIF was man im Modul erstellt hat löschen bzw. deaktivieren nehme ich an...

Byte09

Zitat von: misux am 04 April 2018, 13:51:22
Okay, dann kommt noch ganz schön Arbeit auf mich zu... und man sollte auf jeden Fall das DOIF was man im Modul erstellt hat löschen bzw. deaktivieren nehme ich an...

richtig, sonst reagieren ggf. beide module , was eher unerwünscht ist .

gruss Byte09

Esjay

Donnerwetter, wusste gar nicht, dass es so etwas gibt. Sobald ich etwas Luft habe, werde ich mir das Ganze genauer Anschauen. Schonmal vorweg, danke für das Modul!

Grüße

Byte09

#12
update vom 05.04.18

die Ansicht im 'MSwitch Inforoom' wurde geändert :

- es wird jetzt zusätzliuch der aktuelle state des devices inc. datum und zeit dargestellt (aktualisierung bei änderung)
- falls das device 'disabled' ist wird das entsprechend dargestellt
- falls weder trigger noch schaltzeiten eingestellt sind wird das device als 'Multiswitch only' deklariert

gruss Byte09

mark79

Hallo,

ich habe das Modul auch mal installiert und etwas damit rumgespielt.
Ich finde die Übersicht sehr gut, besser als die ganzen DOIF und Notifys wo ich manchmal den Überblick darüber verliere.

Da ich auch einige Dashbuttons habe und damit schalte, habe ich eine Frage bzgl. des Toggles. Im Grunde suche ich nach einer Möglichkeit, das ganze zu vereinfachen...

Bisher habe ich das über ein Notify gelöst:

defmod Dash_AfriCola notify DashButton:68-37-e9-61-39-xx..short { if (ReadingsVal("WZ_TV","state","") eq "ON") { fhem("set WZ_Kodi off;; sleep 20;; set WZ_TV off") } else { fhem("set WZ_TV on") } }
Wenn der Dash Button gedrückt wird, schaut das notify erstmal ob der TV an ist, wenn ja fährt er Kodi herunter und schaltet nach 20 Sekunden den TV bzw. die Steckdosenleiste aus.
Sofern der TV aus ist, wird nur der TV bzw. die Steckdosenleiste eingeschaltet.

Wie würde das mit MSwitch funktionieren? Im Wiki habe ich gesehen, das du ein Toggle im Device (CUL_HM_HM_LC_Dim1TPBU_FM_3387C3) drin hast. Wie hast du das umgesetzt? Bei mir gibt es nur "on" und "off".

Ich habe einige Sonoff Geräte per Tasmota angebunden und WZ_TV ist eine davon.

Würde es gehen, wenn ich unter "device actions" - "on condition" und "off condition" die MAC Adresse des DashButton eintrage, um so ein Toggle umzusetzen?
Wahrscheinlich nicht, oder? :D


Grüße
Mark
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Byte09

#14
Hi Mark


lege für das device "wz_tv" einfach eine zweite aktion an mit dem button "add action for wz_tv".

mit der ersten aktin schaltest du 'ON' , mit der zweiten 'OFF' ( beides im gleichen zweig - z.B 'MSwitch on cmd').

in den Conditions jeweils :

im ersten ( on condition: ) : [WZ_TV :state] eq "OFF"
im zweiten ( on condition: ) : [WZ_TV :state] eq "ON"

dann nutz er immer nur die aktion , die gerade zutrifft.
habe dir zur verdeutlichung mal ein bilder angehangen , bei denen ich ein sonoff entsprechend schalte.

die Schaltung erfolgt wenn ein Trigger den ON-Zweig auslöst .

ich hoffe es ist verständlich , ansonsten gib nochmal bescheid.

gruss Byte09


nachtrag : nochmal zwei sceens aus meiner entsprechenden Dashbutton Steuerung :