98_MSwitch - Support

[Byte09]

Hi Thomas,

FHEM zeigt auf den Raumseiten als Überschrift bei der Gruppierung immer den Namen aus dem Atrribut Group bzw. wenn das Attribut Group nicht vorhanden ist, dann den Inhalt von TYPE bzw. den Inhalt des Attributes subType. Dann liegt mein Problemchen  an der Textzeite "MSwitch Inforoom: Anzeige der Deviceinformationen, Änderungen sind nur in den Details möglich."

Du setzt in deinem Programm

Code Auswählen Erweitern


\$( \".devType\" ).text( \"MSwitch Inforoom: Anzeige der Deviceinformationen, Änderungen sind nur in den Details möglich.\" );


Dadurch wird deine Infozeile angezeigt. Setzt du keinen "devtype", zeigt FHEM den Groupnamen bzw. den TYPE an. Finde ich hilfreiche als die reine Infozeile. S. angeh. Bilder.

Vlg
Karlheinz

ok , jetzt habe ich es verstanden. Ich ändere es.

gruss thomas

[khk123]

...wie immer ein prompter Service.  Ich danke dir.

[Byte09]

...wie immer ein prompter Service.  Ich danke dir.

in der aktuellen GIT_Version ist es geändert.

gruss Thomas

[khk123]

Hi Thomas,

im Log erscheint bei der Ausführung von "configdb dump" über MSwitch folgende Fehlermeldung:

Code Auswählen Erweitern


2019.12.27 02:10:00 3: ConfigDb_Sicherung MSwitch_Restartcm: Befehlsausfuehrung ->   configdb dump 7805
2019.12.27 02:10:10 1: ConfigDb_Sicherung Absent_Exec_Notif on: ERROR FreeCmd-AbsCmd1: configDB dumped 4208740 bytes
from: /opt/fhem/configDB.db
  to: ./log/configDB_2019-12-27_02-10-00.dump.gz -> Comand:   configdb dump


Der Befehl wurde korrekt ausgeführt und configdb liefert generell als Rückmeldung folgendes:

Code Auswählen Erweitern


configDB dumped 4208783 bytes
from: /opt/fhem/configDB.db
  to: ./log/configDB_2019-12-27_11-27-01.dump.gz


Das gleiche Verhalten auch bei folgendem Befehl auf:

Code Auswählen Erweitern


2019.12.25 02:10:00 3: ZWave_Sicherung MSwitch_Restartcm: Befehlsausfuehrung -> set ZWave backupCreate 256k 7805
2019.12.25 02:10:02 3: ZWave backupCreate at 16384 bytes
2019.12.25 02:10:05 3: ZWave backupCreate at 32768 bytes
2019.12.25 02:10:08 3: ZWave backupCreate at 49152 bytes
2019.12.25 02:10:11 3: ZWave backupCreate at 65536 bytes
2019.12.25 02:10:14 3: ZWave backupCreate at 81920 bytes
2019.12.25 02:10:16 3: ZWave backupCreate at 98304 bytes
2019.12.25 02:10:19 3: ZWave backupCreate at 114688 bytes
2019.12.25 02:10:22 3: ZWave backupCreate at 131072 bytes
2019.12.25 02:10:25 3: ZWave backupCreate at 147456 bytes
2019.12.25 02:10:28 3: ZWave backupCreate at 163840 bytes
2019.12.25 02:10:30 3: ZWave backupCreate at 180224 bytes
2019.12.25 02:10:33 3: ZWave backupCreate at 196608 bytes
2019.12.25 02:10:36 3: ZWave backupCreate at 212992 bytes
2019.12.25 02:10:39 3: ZWave backupCreate at 229376 bytes
2019.12.25 02:10:42 3: ZWave backupCreate at 245760 bytes
2019.12.25 02:10:44 3: ZWave backupCreate at 262144 bytes
2019.12.25 02:10:44 1: ZWave_Sicherung Absent_Exec_Notif on: ERROR ZWave-AbsCmd1: Wrote 262144 bytes to ./ZWave.bin -> Comand: set ZWave backupCreate 256k


Hab nicht ins Programm geschaut, aber ich nehme an, dass immer wenn die Rückmeldung des auszuführenden Befehls nicht "OK" lautet, eine Fehlermeldung produziert wird.

Viele Grüße
Karlheinz

[Byte09]

Hi Thomas,

im Log erscheint bei der Ausführung von "configdb dump" über MSwitch folgende Fehlermeldung:

Code Auswählen Erweitern


2019.12.27 02:10:00 3: ConfigDb_Sicherung MSwitch_Restartcm: Befehlsausfuehrung ->   configdb dump 7805
2019.12.27 02:10:10 1: ConfigDb_Sicherung Absent_Exec_Notif on: ERROR FreeCmd-AbsCmd1: configDB dumped 4208740 bytes
from: /opt/fhem/configDB.db
  to: ./log/configDB_2019-12-27_02-10-00.dump.gz -> Comand:   configdb dump


Der Befehl wurde korrekt ausgeführt und configdb liefert generell als Rückmeldung folgendes:

Code Auswählen Erweitern


configDB dumped 4208783 bytes
from: /opt/fhem/configDB.db
  to: ./log/configDB_2019-12-27_11-27-01.dump.gz


Das gleiche Verhalten auch bei folgendem Befehl auf:

Code Auswählen Erweitern


2019.12.25 02:10:00 3: ZWave_Sicherung MSwitch_Restartcm: Befehlsausfuehrung -> set ZWave backupCreate 256k 7805
2019.12.25 02:10:02 3: ZWave backupCreate at 16384 bytes
2019.12.25 02:10:05 3: ZWave backupCreate at 32768 bytes
2019.12.25 02:10:08 3: ZWave backupCreate at 49152 bytes
2019.12.25 02:10:11 3: ZWave backupCreate at 65536 bytes
2019.12.25 02:10:14 3: ZWave backupCreate at 81920 bytes
2019.12.25 02:10:16 3: ZWave backupCreate at 98304 bytes
2019.12.25 02:10:19 3: ZWave backupCreate at 114688 bytes
2019.12.25 02:10:22 3: ZWave backupCreate at 131072 bytes
2019.12.25 02:10:25 3: ZWave backupCreate at 147456 bytes
2019.12.25 02:10:28 3: ZWave backupCreate at 163840 bytes
2019.12.25 02:10:30 3: ZWave backupCreate at 180224 bytes
2019.12.25 02:10:33 3: ZWave backupCreate at 196608 bytes
2019.12.25 02:10:36 3: ZWave backupCreate at 212992 bytes
2019.12.25 02:10:39 3: ZWave backupCreate at 229376 bytes
2019.12.25 02:10:42 3: ZWave backupCreate at 245760 bytes
2019.12.25 02:10:44 3: ZWave backupCreate at 262144 bytes
2019.12.25 02:10:44 1: ZWave_Sicherung Absent_Exec_Notif on: ERROR ZWave-AbsCmd1: Wrote 262144 bytes to ./ZWave.bin -> Comand: set ZWave backupCreate 256k


Hab nicht ins Programm geschaut, aber ich nehme an, dass immer wenn die Rückmeldung des auszuführenden Befehls nicht "OK" lautet, eine Fehlermeldung produziert wird.

Viele Grüße
Karlheinz

ja, ich habe jetzt auch noch nicht nachgesehen, wird aber etwas derartiges sein.
Ich schaue mir das an.

Ich habe gerade mal reingeschaut und es ist so wie du vermutet hast:

Code Auswählen Erweitern

...
if ( defined($errors) and $errors ne "OK" ) {
                                MSwitch_LOG( $name, 1....

da ich auf die schnelle keine Idee habe , wie ich hier eine gewollte Meldung von einer echten Fehlermeldung unterscheiden kann werde ich diese Meldung erstmal komplett abschalten , bzw. nur im Debugmodus aktivieren ( zumindest bis mir was besseres einfällt )

ich werde das morgen im Laufe des Tages erstmal mit der GIT-Version aktualisieren.

gruss Thomas

[Byte09]

Ich habe gerade eine aktuelle Version in das GIT gestellt.

Ab dieser Version wird eine zusätzliche Javascrip-Datei benötigt. Diese wird beim Update ebenfalls installiert.

gruss Byte09

[Panik]

Hallo Byte09,

ich habe mehrer Schalter, bei denen die Verzögerung nicht mehr wie vorher reagiert. Exemplarisch unten ein Schalter

Das ist ein MSwitch-Notify-Schalter, der zu einer bestimmten Zeit mit mehreren zeitverzögerten Aktionen loslegt.
Gleichzeitig hatte ich den so gestaltet, daß ein Druck in der Webansicht auf den Schalter auch die Befehlskette aktiviert.
Den Schalter hab ich nach 2s wieder zurückgestellt, da ich der Ansicht war, dass die Befehlskette trotzdem abgearbeitet wird.
Das geht nun seit ein paar Tagen nicht mehr. Ich müsste den MSwitch-Notify-Schalter als letztes zurückstellen, was aber
wahrscheinlich bei diversen Reset-Befehlen ungünstig ist ...
Hast du da was "umgeschraubt" ?

Gruß, Panik

Code Auswählen Erweitern


Modulversion: 2.93
Datenstruktur: V2.00

----- Devicename -----
MSW_Raspi_USB_Reset

----- Attribute -----
Attribut MSwitch_Extensions: 1
Attribut webCmd: on:off
Attribut devStateIcon: off:general_aus@red on:general_an@green active:control_home@magenta
Attribut MSwitch_Include_MSwitchcmds: 1
Attribut MSwitch_Include_Webcmds: 1
Attribut MSwitch_Include_Devicecmds: 1
Attribut MSwitch_Mode: Notify
Attribut MSwitch_Lock_Quickedit: 1
Attribut group: MSwitch
Attribut verbose: 0
Attribut room: Aktoren,MSwitch
Attribut MSwitch_Expert: 1
Attribut disable: 0
Attribut MSwitch_Help: 1
Attribut MSwitch_Condition_Time: 1
Attribut MSwitch_Debug: 1
Attribut setList: on off
Attribut MSwitch_Delete_Delays: 1
Attribut icon: time_clock@yellow
Attribut MSwitch_Inforoom: MSwitch
Attribut cmdIcon: off:general_aus on:general_an
Attribut MSwitch_Ignore_Types: notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul

----- Trigger -----
Trigger device:  MSwitch_Self
Trigger time: on off ononly[02:01|5] offonly onoffonly
Trigger condition: [urlaubsstatus:state] eq "null"
Trigger Device Global Whitelist: undef

----- Trigger Details -----
Trigger cmd1: no_trigger
Trigger cmd2: no_trigger
Trigger cmd3: no_trigger
Trigger cmd4: no_trigger

----- Device Actions -----

Device: FreeCmd-AbsCmd1
cmd1: undefined {
system("ls -l /dev/serial/by-id/");
system("lsusb");
fhem("set LED_Band text 5_9_1; sleep 3; set LED_Band text 5_9_0 ");
}

cmd2: cmd
cmd1 condition:
cmd2 condition:
cmd1 delay: 00:00:10
cmd2 delay: 00:00:00
repeats: 0
repeats delay: 0
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd2
cmd1: undefined {WriteStatefile();
Log 1, "Zustandsinfo: Statefile gespeichert (MSW_Raspi_USB_Reset).";}
cmd2: cmd
cmd1 condition:
cmd2 condition:
cmd1 delay: 00:00:00
cmd2 delay: 00:00:00
repeats: 0
repeats delay: 0
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd3
cmd1: undefined {Log 1, "USB-Reset über MSW ... ";
fhem("set MyPushover msg title='USB-Reset' USB-Reset beginnt gleich device=aquarisx");
speak("USB Reset beginnt in wenigen Sekunden", 0);}
cmd2: cmd
cmd1 condition:
cmd2 condition:
cmd1 delay: 00:00:05
cmd2 delay: 00:00:00
repeats: 0
repeats delay: 0
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: MSwitch_Self-AbsCmd1
cmd1: off
cmd2: no_action
cmd1 condition:
cmd2 condition:
cmd1 delay: 00:00:02
cmd2 delay: 00:00:00
repeats: 0
repeats delay: 0
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0



[Byte09]

Hallo Byte09,

ich habe mehrer Schalter, bei denen die Verzögerung nicht mehr wie vorher reagiert. Exemplarisch unten ein Schalter

Das ist ein MSwitch-Notify-Schalter, der zu einer bestimmten Zeit mit mehreren zeitverzögerten Aktionen loslegt.
Gleichzeitig hatte ich den so gestaltet, daß ein Druck in der Webansicht auf den Schalter auch die Befehlskette aktiviert.
Den Schalter hab ich nach 2s wieder zurückgestellt, da ich der Ansicht war, dass die Befehlskette trotzdem abgearbeitet wird.
Das geht nun seit ein paar Tagen nicht mehr. Ich müsste den MSwitch-Notify-Schalter als letztes zurückstellen, was aber
wahrscheinlich bei diversen Reset-Befehlen ungünstig ist ...
Hast du da was "umgeschraubt" ?

Gruß, Panik

Code Auswählen Erweitern


Modulversion: 2.93
Datenstruktur: V2.00

----- Devicename -----
MSW_Raspi_USB_Reset

----- Attribute -----
Attribut MSwitch_Extensions: 1
Attribut webCmd: on:off
Attribut devStateIcon: off:general_aus@red on:general_an@green active:control_home@magenta
Attribut MSwitch_Include_MSwitchcmds: 1
Attribut MSwitch_Include_Webcmds: 1
Attribut MSwitch_Include_Devicecmds: 1
Attribut MSwitch_Mode: Notify
Attribut MSwitch_Lock_Quickedit: 1
Attribut group: MSwitch
Attribut verbose: 0
Attribut room: Aktoren,MSwitch
Attribut MSwitch_Expert: 1
Attribut disable: 0
Attribut MSwitch_Help: 1
Attribut MSwitch_Condition_Time: 1
Attribut MSwitch_Debug: 1
Attribut setList: on off
Attribut MSwitch_Delete_Delays: 1
Attribut icon: time_clock@yellow
Attribut MSwitch_Inforoom: MSwitch
Attribut cmdIcon: off:general_aus on:general_an
Attribut MSwitch_Ignore_Types: notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul

----- Trigger -----
Trigger device:  MSwitch_Self
Trigger time: on off ononly[02:01|5] offonly onoffonly
Trigger condition: [urlaubsstatus:state] eq "null"
Trigger Device Global Whitelist: undef

----- Trigger Details -----
Trigger cmd1: no_trigger
Trigger cmd2: no_trigger
Trigger cmd3: no_trigger
Trigger cmd4: no_trigger

----- Device Actions -----

Device: FreeCmd-AbsCmd1
cmd1: undefined {
system("ls -l /dev/serial/by-id/");
system("lsusb");
fhem("set LED_Band text 5_9_1; sleep 3; set LED_Band text 5_9_0 ");
}

cmd2: cmd
cmd1 condition:
cmd2 condition:
cmd1 delay: 00:00:10
cmd2 delay: 00:00:00
repeats: 0
repeats delay: 0
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd2
cmd1: undefined {WriteStatefile();
Log 1, "Zustandsinfo: Statefile gespeichert (MSW_Raspi_USB_Reset).";}
cmd2: cmd
cmd1 condition:
cmd2 condition:
cmd1 delay: 00:00:00
cmd2 delay: 00:00:00
repeats: 0
repeats delay: 0
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: FreeCmd-AbsCmd3
cmd1: undefined {Log 1, "USB-Reset über MSW ... ";
fhem("set MyPushover msg title='USB-Reset' USB-Reset beginnt gleich device=aquarisx");
speak("USB Reset beginnt in wenigen Sekunden", 0);}
cmd2: cmd
cmd1 condition:
cmd2 condition:
cmd1 delay: 00:00:05
cmd2 delay: 00:00:00
repeats: 0
repeats delay: 0
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0

Device: MSwitch_Self-AbsCmd1
cmd1: off
cmd2: no_action
cmd1 condition:
cmd2 condition:
cmd1 delay: 00:00:02
cmd2 delay: 00:00:00
repeats: 0
repeats delay: 0
priority: 1
id: 0
comment:
cmd1 exit: 0
cmd2 exit: 0



kannst du mir bitte die rawdefinition von dem device geben ?  ... schaue ich mir dann direkt an .

gruss thomas

[Panik]

Code Auswählen Erweitern


defmod MSW_Raspi_USB_Reset MSwitch MSW_Raspi_USB_Reset   # FreeCmd MSwitch_Self
attr MSW_Raspi_USB_Reset MSwitch_Condition_Time 1
attr MSW_Raspi_USB_Reset MSwitch_Debug 1
attr MSW_Raspi_USB_Reset MSwitch_Delete_Delays 1
attr MSW_Raspi_USB_Reset MSwitch_Expert 1
attr MSW_Raspi_USB_Reset MSwitch_Extensions 1
attr MSW_Raspi_USB_Reset MSwitch_Help 1
attr MSW_Raspi_USB_Reset MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
attr MSW_Raspi_USB_Reset MSwitch_Include_Devicecmds 1
attr MSW_Raspi_USB_Reset MSwitch_Include_MSwitchcmds 1
attr MSW_Raspi_USB_Reset MSwitch_Include_Webcmds 1
attr MSW_Raspi_USB_Reset MSwitch_Inforoom MSwitch
attr MSW_Raspi_USB_Reset MSwitch_Lock_Quickedit 1
attr MSW_Raspi_USB_Reset MSwitch_Mode Notify
attr MSW_Raspi_USB_Reset cmdIcon off:general_aus on:general_an
attr MSW_Raspi_USB_Reset devStateIcon off:general_aus@red on:general_an@green active:control_home@magenta
attr MSW_Raspi_USB_Reset disable 0
attr MSW_Raspi_USB_Reset group MSwitch
attr MSW_Raspi_USB_Reset icon time_clock@yellow
attr MSW_Raspi_USB_Reset room Aktoren,MSwitch
attr MSW_Raspi_USB_Reset setList on off
attr MSW_Raspi_USB_Reset verbose 0
attr MSW_Raspi_USB_Reset webCmd on:off

setstate MSW_Raspi_USB_Reset active
setstate MSW_Raspi_USB_Reset 2019-12-28 08:30:06 .Device_Affected FreeCmd-AbsCmd1,FreeCmd-AbsCmd2,FreeCmd-AbsCmd3,MSwitch_Self-AbsCmd1
setstate MSW_Raspi_USB_Reset 2019-12-28 08:34:43 .Device_Affected_Details FreeCmd-AbsCmd1#[NF]undefined#[NF]cmd#[NF]{#[nl]system("ls#[sp]-l#[sp]/dev/serial/by-id/")#[se]#[sp]#[nl]system("lsusb")#[se]#[sp]#[nl]fhem("set#[sp]LED_Band#[sp]text#[sp]5_9_1#[se]#[sp]sleep#[sp]3#[se]#[sp]set#[sp]LED_Band#[sp]text#[sp]5_9_0#[sp]")#[se]#[nl]}#[nl]#[NF]#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]10#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]3#[NF]0#[ND]FreeCmd-AbsCmd2#[NF]undefined#[NF]cmd#[NF]{WriteStatefile()#[se]#[nl]Log#[sp]1#[ko]#[sp]"Zustandsinfo#[dp]#[sp]Statefile#[sp]gespeichert#[sp](MSW_Raspi_USB_Reset)."#[se]}#[NF]#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[ND]FreeCmd-AbsCmd3#[NF]undefined#[NF]cmd#[NF]{Log#[sp]1#[ko]#[sp]"USB-Reset#[sp]über#[sp]MSW#[sp]...#[sp]"#[se]#[nl]fhem("set#[sp]MyPushover#[sp]msg#[sp]title='USB-Reset'#[sp]USB-Reset#[sp]beginnt#[sp]gleich#[sp]device=aquarisx")#[se]#[nl]speak("USB#[sp]Reset#[sp]beginnt#[sp]in#[sp]wenigen#[sp]Sekunden"#[ko]#[sp]0)#[se]}#[NF]#[NF]delay0#[NF]delay1#[NF]00#[dp]00#[dp]05#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]2#[NF]0#[ND]MSwitch_Self-AbsCmd1#[NF]off#[NF]no_action#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]02#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]4#[NF]0
setstate MSW_Raspi_USB_Reset 2019-11-20 18:13:41 .Device_Events no_trigger
setstate MSW_Raspi_USB_Reset 2019-11-20 18:13:41 .First_init done


[Byte09]

es wundert mich ein wenig.mit den letzten beiden updates am 14 und 20 dezember habe ich im grunde keine funktionsänderung vorgenommen , sondern (fast) nur am webinterface 'geschraubt' .

seit wann geht es denn nicht mehr ?

gruss thomas

edit: gib mir ein paar minuten mir das anzuschauen

[Byte09]

Code Auswählen Erweitern


defmod MSW_Raspi_USB_Reset MSwitch MSW_Raspi_USB_Reset   # FreeCmd MSwitch_Self
attr MSW_Raspi_USB_Reset MSwitch_Condition_Time 1
attr MSW_Raspi_USB_Reset MSwitch_Debug 1
attr MSW_Raspi_USB_Reset MSwitch_Delete_Delays 1
attr MSW_Raspi_USB_Reset MSwitch_Expert 1
attr MSW_Raspi_USB_Reset MSwitch_Extensions 1
attr MSW_Raspi_USB_Reset MSwitch_Help 1
attr MSW_Raspi_USB_Reset MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
attr MSW_Raspi_USB_Reset MSwitch_Include_Devicecmds 1
attr MSW_Raspi_USB_Reset MSwitch_Include_MSwitchcmds 1
attr MSW_Raspi_USB_Reset MSwitch_Include_Webcmds 1
attr MSW_Raspi_USB_Reset MSwitch_Inforoom MSwitch
attr MSW_Raspi_USB_Reset MSwitch_Lock_Quickedit 1
attr MSW_Raspi_USB_Reset MSwitch_Mode Notify
attr MSW_Raspi_USB_Reset cmdIcon off:general_aus on:general_an
attr MSW_Raspi_USB_Reset devStateIcon off:general_aus@red on:general_an@green active:control_home@magenta
attr MSW_Raspi_USB_Reset disable 0
attr MSW_Raspi_USB_Reset group MSwitch
attr MSW_Raspi_USB_Reset icon time_clock@yellow
attr MSW_Raspi_USB_Reset room Aktoren,MSwitch
attr MSW_Raspi_USB_Reset setList on off
attr MSW_Raspi_USB_Reset verbose 0
attr MSW_Raspi_USB_Reset webCmd on:off

setstate MSW_Raspi_USB_Reset active
setstate MSW_Raspi_USB_Reset 2019-12-28 08:30:06 .Device_Affected FreeCmd-AbsCmd1,FreeCmd-AbsCmd2,FreeCmd-AbsCmd3,MSwitch_Self-AbsCmd1
setstate MSW_Raspi_USB_Reset 2019-12-28 08:34:43 .Device_Affected_Details FreeCmd-AbsCmd1#[NF]undefined#[NF]cmd#[NF]{#[nl]system("ls#[sp]-l#[sp]/dev/serial/by-id/")#[se]#[sp]#[nl]system("lsusb")#[se]#[sp]#[nl]fhem("set#[sp]LED_Band#[sp]text#[sp]5_9_1#[se]#[sp]sleep#[sp]3#[se]#[sp]set#[sp]LED_Band#[sp]text#[sp]5_9_0#[sp]")#[se]#[nl]}#[nl]#[NF]#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]10#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]3#[NF]0#[ND]FreeCmd-AbsCmd2#[NF]undefined#[NF]cmd#[NF]{WriteStatefile()#[se]#[nl]Log#[sp]1#[ko]#[sp]"Zustandsinfo#[dp]#[sp]Statefile#[sp]gespeichert#[sp](MSW_Raspi_USB_Reset)."#[se]}#[NF]#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[ND]FreeCmd-AbsCmd3#[NF]undefined#[NF]cmd#[NF]{Log#[sp]1#[ko]#[sp]"USB-Reset#[sp]über#[sp]MSW#[sp]...#[sp]"#[se]#[nl]fhem("set#[sp]MyPushover#[sp]msg#[sp]title='USB-Reset'#[sp]USB-Reset#[sp]beginnt#[sp]gleich#[sp]device=aquarisx")#[se]#[nl]speak("USB#[sp]Reset#[sp]beginnt#[sp]in#[sp]wenigen#[sp]Sekunden"#[ko]#[sp]0)#[se]}#[NF]#[NF]delay0#[NF]delay1#[NF]00#[dp]00#[dp]05#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]2#[NF]0#[ND]MSwitch_Self-AbsCmd1#[NF]off#[NF]no_action#[NF]#[NF]#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]02#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]4#[NF]0
setstate MSW_Raspi_USB_Reset 2019-11-20 18:13:41 .Device_Events no_trigger
setstate MSW_Raspi_USB_Reset 2019-11-20 18:13:41 .First_init done


ich habe mir das angeschaut und kann nachvollziehen was du meinst.
Was mich wundert, ist das es bisher so ging da jetziges verhalten im grunde richtig ist .

nach 2 sekunden schaltet das device auf off ( wenn ich ein device auf off schalte - sollte erwartungsgemäss nichts mehr passieren - daher werden alle delays gelöscht ) Das ist das Standartverhalten - warum das verhalten sich geändert hat ist mir nocht nicht klar, aber das vorherige war dann definitiv falsch .

wenn du dieses verhalten ändern willst schalte das attribut 'MSwitch_Delete_Delays' bitte mal auf 0 . Damit werden bei schalten des devices vorhandene , verzögerte befehle nicht gelöscht und dann sollte das device sich (wieder) wie gewünscht verhalten.

Sei doch bitte so gut und gib mir kurz bescheid ob es dann passt .

gruss thomas

PS: mit einer der kommenden Versionen werde ich die rawdefinition gleich zusammen mit der Support-info ausliefern , so dass alle relevanten daten zusammen sind.

[Panik]

Hallo Byte09,

Ich habe es jetzt Mal so eingestellt wie von dir vorgeschlagen und es klappt wieder. Also ich schalte den Schalter ab und durch das besagte Attribut wird die Befehlskette trotzdem voll abgearbeitet.

Dankeschön!

Panik

[Panik]

Hallo Byte09,

bekomme ich es bei einem FreeCMD hin, einen Wert zu formatieren?

z.B bekomme ich die Rückmeldung bei Befehl testen:


augeführter Befehl: {fhem("set ECHO_G2A0P30883770DRP speak Die Temperatur im Schlafzimmer beträgt [THGR122NX_1_SZ:temperature:d] Grad bei einer Luftfeuchtigkeit von [THGR122NX_1_SZ:humidity] Prozent")}


Der fett markierte Teil enthält eine Temperatur 20.4 und wird so vorgelesen: ... zwanzigster vier Grad ...

Wenn ich den Wert [THGR122NX_1_SZ:temperature:d] per RegEx in einen Wert mit Komma wandeln könnte, wär es glaub ich gegessen ...

Wie ginge dies?

[Byte09]

Hallo Byte09,

bekomme ich es bei einem FreeCMD hin, einen Wert zu formatieren?

z.B bekomme ich die Rückmeldung bei Befehl testen:


augeführter Befehl: {fhem("set ECHO_G2A0P30883770DRP speak Die Temperatur im Schlafzimmer beträgt [THGR122NX_1_SZ:temperature:d] Grad bei einer Luftfeuchtigkeit von [THGR122NX_1_SZ:humidity] Prozent")}


Der fett markierte Teil enthält eine Temperatur 20.4 und wird so vorgelesen: ... zwanzigster vier Grad ...

Wenn ich den Wert [THGR122NX_1_SZ:temperature:d] per RegEx in einen Wert mit Komma wandeln könnte, wär es glaub ich gegessen ...

Wie ginge dies?

das geht sicher , aber da es egal ist wo du letztendlich die umrechnung / unformatierung machst ist hier m.E der bessere weg, dieses direkt im temperatsensor per userreading zu erledigen und sich dieses vorlesen zu lassen. So mache ich es jedenfalls mit meinen sensoren .

Code Auswählen Erweitern

formattemp:.* {my @test = split (/\./,ReadingsVal( $name, 'Temperatur', '00.00' ));return $test[0]." komma ".$test[1];},

natürlich könntest du diese 'umrechnung' auch im freecmd als erstes erledigen und sich dann das ergebniss vorlesen lassen, hale ich aber für die Lösung zweiter wahl.

gruss thomas

[Panik]

Hallo Byte09,

ja so klappt es. Habe den Sensoren ein extra Reading verpasst.

Danke und guten Rutsch!

Panik