98_MSwitch - Support

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

Vorheriges Thema - Nächstes Thema

outhouse

Hallo

Die Möglichkeiten dieses Moduls gefallen mir sehr. Herzlichen Dank für die Bereitstellung!

Seit dem heutigen Update erhalte ich - nach erfolgter Schaltung - folgende Fehlermeldung:
PERL WARNING: Use of uninitialized value $args[0] in concatenation (.) or string at ./FHEM/98_MSwitch.pm line 558

Zusätzlich gelingt es mir aktuell nicht, eine Device anhand von Readings UND Zeit zu schalten:

Beispiel:

Das Device "Lamp" soll wie folgt einschalten wenn:

a) der Dämmerungsschalter zwischen 16:30 und 22:00 einschaltet per sofort
b) der Dämmerungsschalter vor 16:30 auf "on" schaltet, erst ab 16:30

Punkt a) erreiche ich mit "on condition" [16:30-22:00], wie kann ich Punkt b) umsetzen?

Gruss

Chris
Raspberry 4 B mit Raspberry Pi OS und FHEM-Image 6.3 von fhem.de
Cul CC 1101 V4 als CUL_HM
Cul V3.4 + V3.4 als RFR
enocean-pi

Byte09

Zitat von: mark79 am 08 Mai 2018, 22:15:20
Ich blick bei den Events auch noch nicht wirklich durch, besonders bei dem Dash Button Bespiel. :o Da würde ich mir mehr Bespiele wünschen, am besten erstmal einfache Dinge. :) Sonst bin ich echt zufrieden damit.
Maista, also Gerd hat mich gefragt, ob du nicht mal ein Bespiel für eine IT Fernbedienung posten könntest? :) Die z.B. ein Sonoff Device oder ähnliches über ein Event schaltet.


ich habe entsprechendes Beispiel im Wiki zugefügt , hoffe es ist verständlich ( bei einem eigenen Modul tritt schnell eine gewisse Betriebsblindheit auf )

https://wiki.fhem.de/wiki/MSwitch_Konfigurationsbeispiele#MSwitch_IT_to_Sonoff

gruss Byte09

Byte09

Zitat von: outhouse am 10 Mai 2018, 08:25:49
Hallo

Die Möglichkeiten dieses Moduls gefallen mir sehr. Herzlichen Dank für die Bereitstellung!

Seit dem heutigen Update erhalte ich - nach erfolgter Schaltung - folgende Fehlermeldung:
PERL WARNING: Use of uninitialized value $args[0] in concatenation (.) or string at ./FHEM/98_MSwitch.pm line 558

Zusätzlich gelingt es mir aktuell nicht, eine Device anhand von Readings UND Zeit zu schalten:

Beispiel:

Das Device "Lamp" soll wie folgt einschalten wenn:

a) der Dämmerungsschalter zwischen 16:30 und 22:00 einschaltet per sofort
b) der Dämmerungsschalter vor 16:30 auf "on" schaltet, erst ab 16:30

Punkt a) erreiche ich mit "on condition" [16:30-22:00], wie kann ich Punkt b) umsetzen?

Gruss

Chris

Hi Chris

es handelt sich erstmal "nur" um eine Warnung , somit unschön aber kein Problem. Ich schaue mir das Heute an und behebe es.

zu b:  das ist wohl konfigurierbar, aber etwas "von hinten durch die Brust ins Auge" und wahrscheinlich nur für jemanden, der das Modul aus dem FF kennt ( reduziert das ganze dann wohl auf mich  ::) ). Ich werde eine entsprechende Anpassung des Moduls vornehmen, so das dieses einfacher zu bewerkstelligen ist , wird aber wohl bis morgen dauern.

gruss Byte09

outhouse

ZitatIch werde eine entsprechende Anpassung des Moduls vornehmen, so das dieses einfacher zu bewerkstelligen ist , wird aber wohl bis morgen dauern.

Byte09

Besten Dank für die rasche Antwort. Nur nicht hetzen mit der Anpassung des Moduls. Habe noch genug anderes zu entdecken!!

Danke
Raspberry 4 B mit Raspberry Pi OS und FHEM-Image 6.3 von fhem.de
Cul CC 1101 V4 als CUL_HM
Cul V3.4 + V3.4 als RFR
enocean-pi

Byte09

#49
Zitat von: outhouse am 10 Mai 2018, 08:51:34
Byte09

Besten Dank für die rasche Antwort. Nur nicht hetzen mit der Anpassung des Moduls. Habe noch genug anderes zu entdecken!!

Danke

habe mir kurz gedanken gemacht, letztendlich fehlt dem Modul eine Funktion äquivalent zur at-funktion :

d.H wenn dieses oder jenes eintrifft ( in deinem Fall ein Event des Sensors vor 16:00 uhr, dann schalte dieses oder jenes , aber erst um 16:00 uhr.

Im grunde ähnlich eines "delays" ( Verzögerung des Befehles ) , nur so nicht Nutzbar, da du die Zeitverzögerung  die gebraucht würde um 16:00 Uhr zu erreichen nicht so einfach berechnen kannst.

d.H ich werde weitere Felder einbauen ,  (ggf. nur im" Expertmodus" ) die dann ähnlich der delays "on at" und "off at" heissen. Damit sollte es dann relativ einfach realisierbar sein.

gruss Byte09

edit: das ganze wird dann wohl wie auf dem Bild im Anhang aussehen .

Byte09

#50
Zitat von: outhouse am 10 Mai 2018, 08:25:49

Zusätzlich gelingt es mir aktuell nicht, eine Device anhand von Readings UND Zeit zu schalten:

Beispiel:

Das Device "Lamp" soll wie folgt einschalten wenn:

a) der Dämmerungsschalter zwischen 16:30 und 22:00 einschaltet per sofort
b) der Dämmerungsschalter vor 16:30 auf "on" schaltet, erst ab 16:30

Punkt a) erreiche ich mit "on condition" [16:30-22:00], wie kann ich Punkt b) umsetzen?

Gruss

Chris

mir ist gerade noch ein weiterer Lösungsweg eingefallen:

wahrscheinlich hast du ja bei  'trigger device/time:   ' einen Trigger angegeben , der die schaltung auslöst - vermutlich 'Dämmerungsschalter'.

trage in dem Feld 'execute 'on' commands only at :' zusätzlich
[16:30]
ein und erweitere deine "on condition" von  [16:30-22:00] auf:
[16:30-22:00] AND [Dämmerungsschalter:state] eq "on"

eine OR Verknüpfung sollte in diesem Fall ebenfalls funktionieren

[16:30-22:00] OR [Dämmerungsschalter:state] eq "on"

Dämmerungsschalter:state muss natütlich deinem Namen und dem reading entsprechen , den der Dämmerungsschalte angenommen hat , ich nehme an das ist 'state'.

damit wird ( zusätlich zur vorhandenen Konfiguration ) um 16:30 Uhr geprüft ob es zwischen 16:30 und 22:00 uhr ist ( logisch , ist es ) und ob der state des Dämmerungsschalters 'on' ist . wenn es zutrifft wird die Schaltung ausgelöst.

sollte Funktionieren - ungeprüft .

der zusätzliche Auslöser um 16:30 ersetzt dann im Grunde nur das Event des Dämmerungschalter, das ja nicht kommt , da der Dämmerungsschalter schon zu einem vorherigen Zeitpunkt 'ausgelöst' hat .

kannst mir ja mal Bescheid geben , ob es klappt , ich möchte das jetzt bei mirt nicht alles anlegen.

gruss Byte09

outhouse

Hallo Byte09

Also. Habe das Ganze mal getestet.

Die Anweisung mit OR funktioniert nicht, da ja die zweite Bedingung immer zutrifft. Heisst, sobald der Dämmerungsschalter auf on geht, schaltet das Licht ein.

Und jetzt wird es komisch. Nach dem Modifizieren von "on condition" erhalte ich bei "check condition"
If Anweisung Perl Klarzeiten:
if ((14:40 < 15:36 && 15:36 < 22:00) && ReadingsVal('WZ_Daemmerung', 'state', 'undef') eq "on"){$answer = 'true';} else {$answer = 'false';}

Bedingung ist nicht Wahr und wird nicht ausgeführt


Setze ich den Dämmerungsschalter nun manuell auf "on", schaltet das Licht ebenfalls sofort ein. "check condition" ergibt:
If Anweisung Perl Klarzeiten:
if ((14:40 < 15:36 && 15:36 < 22:00) && ReadingsVal('WZ_Daemmerung', 'state', 'undef') eq "on"){$answer = 'true';} else {$answer = 'false';}

Bedingung ist Wahr und wird ausgeführt


Schalte ich jetzt das Licht manuell aus (nicht den Dämmerungsschalter), funktioniert der (automatische) Einschaltbefehl punkt 14:40 Uhr.

Noch klappte es also nicht ganz.

Gruss Chris
Raspberry 4 B mit Raspberry Pi OS und FHEM-Image 6.3 von fhem.de
Cul CC 1101 V4 als CUL_HM
Cul V3.4 + V3.4 als RFR
enocean-pi

Byte09

#52
ok , so etwas schwierig.

drück im device bitte mal "get DEVICE get_config" und poste mal das conffile hier.


mit der OR-Verknüpfung hast du natürlich recht !

habe es eben mal in meinem System konfiguriert, es geht mit der UND Verknüfung. Macht von der Logik auch Sinn.

'WZ_Daemmerung' habe ich dazu durch einen Dummy ersetzt , der den state 'on' oder 'off' annimmt, geschaltet wird ein weiterer dummy.

nur das wir nicht aneinander vorbei reden :

folgendes passiert nun bei mir :

wenn der 'WZ_Daemmerung' im definierten Zeitraum auf 'on' geht wird geschaltet
wenn der Zeitpunkt 16:30 erreicht ist UND der state des 'WZ_Daemmerung' bereits auf 'ON' steht wird geschaltet.
wenn der Zeitpunkt 16:30 erreicht ist UND der state des 'WZ_Daemmerung' NICHT auf 'ON' steht wird NICHT geschaltet sonder erst dann , wenn der 'WZ_Daemmerung' das nächste mal auf 'on' geht

d.H schaltet der 'WZ_Daemmerung' vor dem definierten Zeitraum auf 'on' , dann aber wieder auf 'off' wird nicht geschaltet. ( geschaltet wird nur , wenn er auch auf 'on' stehen bleibt , bzw zu dem Zeitpunkt 16:30 auf 'on' steht )

Macht ja nur so sinn, da ja davon auszugehen ist , das das Licht wieder ausreichend ist, wenn der 'WZ_Daemmerung' um 16:30 wieder auf 'off' steht 

...... es sei denn , der 'WZ_Daemmerung' sendet quasi nur einen 'on' - impuls und schaltet dann wieder auf off, egal wie das licht ist , um nach x min wieder einen Impuls zu schicken ?!?

poste mir bitte zusätlich mal ein List und ein raw-definition deines 'WZ_Daemmerung'.

gruss Byte09

Byte09

#53
Update auf V1.3

Im laufe des Tages werde ich das Update auf die Version 1.3 bereit stellen, diese läuft im Moment bei mir zur Probe.

Dieses Update bringt eine gravierende Änderung mit sich , die das Verhalten bei der Konfiguration von verzögerten Befehlen (delays) betrifft.

Das bisherige verhalten bei einem delays war so, das eine Prüfung der 'on' oder 'off' Conditionen (falls angegeben) nicht bei Eintreffen des triggernden Events , sondern erst nach der Verzögerung, und somit erst unmittelbar vor der Befehlsausführung stattfand.

Neues Verhalten:

die Überprüfung der Conditionen findet jetzt in jedem Fall sofort mit eintreffen des Events statt !
weiterhin wurde die Option 'delays' durch Dropdownfelder ergänzt und es können folgende Einstellungen gewählt werden:

Die zweite Prüfung kann notwendig sein , um das Verhalten eines Watchdogs bieten zu können, ist in anderen Fälen aber ggf. unerwünscht.

delay with Cond-check: +
delay without Cond-check: +
at without Cond-check:
at with Cond-check:


delay with Cond-check: +
Diese Einstellung entsprich weitestgehend der bekannten Funktion und es dürften sich keine Unterschiede zu bisherigem Verhalten ergeben.
Es findet eine erneute Prüfung der Conditionen unmittelbar vor Befehlsausführung statt

delay without Cond-check: +
Es findet keine erneute Prüfung der Conditionen vor Befehlsausführung statt

at without Cond-check:
Es erfolgt keine Angabe einer Verzögerungszeit , sondern ein konkreter Zeitpunkt zur Befehlsausführung. Ist dieser Zeitpunkt am laufenden Tag überschritten , wird dieser Zeitpunkt des kommenden Tages angenommen.
Es findet keine erneute Prüfung der Conditionen unmittelbarvor Befehlsausführung statt

at with Cond-check:
Es erfolgt keine Angabe einer Verzögerungszeit , sondern ein konkreter Zeitpunkt zur Befehlsausführung. Ist dieser Zeitpunkt am laufenden Tag überschritten , wird dieser Zeitpunkt des kommenden Tages angenommen.
Es findet eine erneute Prüfung der Conditionen unmittelbar vor Befehlsausführung statt

Bei bisherigen Konfigurationen wird automatisch diese Option gesetzt : delay with Cond-check: + .
Somit entspricht das Verhalten ohne Eingriff dem bisherigen Verhalten.
Zur sofortigen Befehlsausführung ist diese Option mit der Angabe 00:00:00 zu wählen , diese Entspricht ebenfalls den bisherigen Vorgaben.

sonstige Änderungen: Fix Perl Warnings

allgemeine Info:
da diese Frage einige male aufkam: Wenn in dem Modul bei den triggernden Events Schaltzeitpunkte gesetzt sind, werden diese bei der Ausführung von "get active timer_show" angezeigt.
Das allerdings nur dann , wenn diese Timer noch am aktuellen Tag (bis 24:00) greifen.
Alle Timer, die erst am Folgetag greifen würden werden nicht angezeigt. Bedingt ist das daher, das das Modul aus verschiedenen Gründen nur Timer bis 24:00 Uhr berechnet (eine Ausnahme bilden hier Timer aus delays oder at) . Um 00:01 erfolgt grundsätzlich eine Neuberechnung für den dann aktuellen Tag.

Eine Neuberechnung findet ebenfalls bei Modifikationen der Konfiguration, dem manuellem Löschen aller Timer und einem Modul(Fhem) Neustart statt.

gruss Byte09

Maista

Hallo Byte09,

danke für das Sonoff-Beispiel.
Bin nun aber erst einmal unterwegs. Hoffe das dann am Abend probieren zu können!

;D

Gruss Gerd

outhouse

Byte09

ok , so etwas schwierig.

drück im device bitte mal "get DEVICE get_config" und poste mal das conffile hier.


Komme frühestens heute Abend dazu. Aber wie es scheint, ändert sich das mit dem V1.3 eh.....

Chris
Raspberry 4 B mit Raspberry Pi OS und FHEM-Image 6.3 von fhem.de
Cul CC 1101 V4 als CUL_HM
Cul V3.4 + V3.4 als RFR
enocean-pi

Byte09

Ich habe soeben die Version 1.3 im git abgelegt. Ich empfehle dringend, vor dem Update ein Backupfile der gesamten MSwitch-Konfigurationsdatei zu machen:

in irgend einem MSwitch-Device:

set DEVICE backup_Mswitch all_devices

gruss Byte09

mark79

#57
Hi Byte09,

danke dir auch für das IT-Beispiel. :)

Habe heute und gestern damit rumgespielt und bei mir musste ich das ein wenig abändern. Weil der Funk Taster bei mir on und off sendet und das IT Device sich dabei nicht verändert. Das funktioniert soweit, siehe Screenshot 1.
Es ist ein Smartwares Doppelwandschalter, 2-Kanal, SH5-TSW-B der einen Sonoff Lichtschalter mit ESPeasy schaltet.

Die neue 1.3 Version läuft bei mir gut. Die alten Timer mit "delay with Cond-check" wurden korrekt übernommen. :)


Wo ich aber noch Probleme habe ist z.B. das mit dem Toggle.

Ich habe ein Xiaomi Taster, der sendet ein "click" und damit würde ich z.B. ein Sonoff WZ_Lichtschalter toggeln, also on und off schalten mit nur einem Event.
Das kriege ich aber irgendwie nicht gebacken. :(  Wie müsste ich das konfigurieren?
Bei dem DashButton Beispiel blicke ich noch nicht durch.. hatte das auch mal versucht nachzustellen, aber das hat nicht geklappt. :(

Das Event für den Xiaomi Taster sieht so aus:
2018-05-11 22:33:53 XiaomiSmartHome_Device Xiaomi_Taster click

Wenn ich MSwitch on cmd: auf Set on setze geht es, aber wie schalte ich es dann aus?

Setze ich es so, dann passiert nichts:
MSwitch on cmd: Set MSwitchtoogle [WZ_Lichtschalter:0]
MSwitch off cmd: Set MSwitchtoogle [WZ_Lichtschalter:1]


So schaltet er nur ein, aber nicht off. (Off mit einem delay von 2 Sekunden.)
MSwitch on cmd: Set 1 [WZ_Lichtschalter:0]
MSwitch off cmd: Set 0 [WZ_Lichtschalter:1]


Habe davon ein einen zweiten Screenshot angehangen...


Viele 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

#58
ich werde nachher noch ein Beispiel für SOnoff mit toggle im Wiki schreiben.



aber auf die schnelle:

da dein Taster nur ein Event gereriert musst du auch nur einen Kanal belegen, d.H setze 'execute 'off' commands only' auf 'no_trigger'.
'execute 'on' commands only' lass wie es ist.

in den 'Device Actions' setzt du:

'MSwitch on cmd: Set MSwitch_toggle 1/0'   .... wenn ich davon ausgehe das die Schaltbefehle 'set WZ_Lichtschalter 1' und 'set WZ_Lichschalter 0' lauten.

'MSwitch off cmd: Set no_action'
damit sollte es gehen.

was anderes , was für einen Style nutzt du ? das sieht im Feld 'Device Actions' so merkwürdig verrissen aus ?

gruss Byte09

mark79

Hallo, danke dir das funktioniert nun auch. :) Ich hatte das mit 1 0 probiert, anstatt mit 1/0.  ::)

Gibt es noch eine Möglichkeit das Icon bzw. den State vom MSwitch Device mit ändern zu lassen?
Jetzt steht immer nur "on" und das Icon wird als eingeschaltet angezeigt, auch wenn der toggle für "off" ausgeführt wurde.

Der blaue Style heißt "f18", der ist ziemlich neu bei Fhem mit dabei und ist mit Javascript.
https://forum.fhem.de/index.php?topic=82351.0


Viele 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