Ich schalte einen Dummy über F2F da ich aber nicht den state sondern den status brauch geht das ohne notify nicht oder?
Und irgendwas funzt da net so wie ich will.
PC_Control {
if ("$EVENT" ne "Start") {
fhem("set PC_Control status1 on")
}
if ("$EVENT" ne "Stop") {
fhem("set PC_Control status2 on")
}
if ("$EVENT" ne "Restart") {
fhem("set PC_Control status3 on")
}
}
Bitte deine Frage präzisieren, und ein "list PC_Control" auch zeigen. Was willst Du machen, was geht nicht?
Ich schalte über deinen Dummy auf Fhem1 den status Start,Stop,Restart; Über Fhem2Fhem frage ich den status auf Fhem2 ab.
Fhem2 sollte dan vom befehl "PC_Control Start" am (MYSENSORS) "set PC_Control status1 on" ausführen.
Mit einem befehl geht es auch aber wie bekomme ich 3 Befehle in einem Notify?
Save config
F2F
GPIO4
Server
Unsorted
Wasser
ÖlHeizung
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
UpdateCheck
Update
Restart
FHEM
Internals:
DEF 200
IODev MSG
NAME PC_Control
NR 43
STATE Stop
TYPE MYSENSORS_DEVICE
ack 0
protocol 2.1.1
radioId 200
repeater 1
READINGS:
2018-01-25 21:27:53 PC_Control Error evaluating PC_Control userReading PC_Control: syntax error at (eval 17685) line 1, at EOF
2018-01-24 20:30:46 SKETCH_NAME PC_Control
2018-01-24 20:30:46 SKETCH_VERSION 1.0
2018-01-24 20:30:46 parentId 103
2018-01-19 20:53:07 power1 1
2018-01-28 11:20:43 state Stop
2018-01-29 09:58:35 status1 on
2018-01-29 09:58:35 status2 off
2018-01-29 09:58:35 status3 off
readingMappings:
1:
17:
name power1
2:
name status1
2:
17:
name power2
2:
name status2
3:
17:
name power3
2:
name status3
sensorMappings:
0:
receives:
sends:
16
15
1:
receives:
sends:
16
15
10:
receives:
sends:
6
7
11:
receives:
sends:
11
12:
receives:
sends:
12
14
13:
receives:
24
sends:
17
18
54
55
56
24
14:
receives:
sends:
45
21
0
2
15:
receives:
sends:
13
43
16:
receives:
sends:
23
37
17:
receives:
sends:
18:
receives:
sends:
19:
receives:
36
sends:
36
2:
receives:
sends:
16
15
20:
receives:
32
sends:
33
50
32
21:
receives:
24
sends:
34
35
24
22:
receives:
sends:
37
43
23:
receives:
24
25
26
27
28
sends:
24
25
26
27
28
24:
receives:
sends:
37
43
25:
receives:
sends:
19
20
26:
receives:
40
17
sends:
40
17
27:
receives:
41
17
sends:
41
17
28:
receives:
40
sends:
40
29:
receives:
sends:
2
0
45
44
21
46
22
3:
receives:
2
17
sends:
2
17
30:
receives:
sends:
38
39
14
31:
receives:
sends:
2
16
32:
receives:
sends:
16
15
33:
receives:
sends:
37
16
15
34:
receives:
sends:
37
16
15
35:
receives:
sends:
37
16
15
36:
receives:
47
sends:
47
37:
receives:
sends:
34
35
38:
receives:
sends:
49
39:
receives:
sends:
0
51
52
53
2
4:
receives:
2
3
17
sends:
2
3
17
5:
receives:
29
30
31
3
sends:
29
30
31
3
6:
receives:
sends:
0
42
7:
receives:
sends:
1
8:
receives:
sends:
4
5
9:
receives:
sends:
8
9
10
sets:
power1 1
power2 1
power3 1
reboot
status1 on,off
status2 on,off
status3 on,off
time
typeMappings:
0:
type temperature
1:
type humidity
10:
type direction
11:
type uv
12:
type weight
13:
type distance
14:
type impedance
15:
type armed
val:
0 off
1 on
16:
type tripped
val:
0 off
1 on
17:
type power
18:
type energy
19:
type button_on
2:
type status
val:
0 off
1 on
20:
type button_off
21:
type hvacflowstate
22:
type hvacspeed
23:
type brightness
range:
max 100
min 0
step 1
24:
type value1
25:
type value2
26:
type value3
27:
type value4
28:
type value5
29:
type up
3:
type percentage
range:
max 100
min 0
step 1
30:
type down
31:
type stop
32:
type ir_send
33:
type ir_receive
34:
type flow
35:
type volume
36:
type lockstatus
val:
0 off
1 on
37:
type level
38:
type voltage
39:
type current
4:
type pressure
40:
type rgb
41:
type rgbw
42:
type id
43:
type unitprefix
44:
type hvacsetpointcool
45:
type hvacsetpointheat
46:
type hvacflowmode
47:
type text
48:
type custom
49:
type position
5:
type forecast
val:
0 stable
1 sunny
2 cloudy
3 unstable
4 thunderstorm
5 unknown
50:
type ir_record
51:
type ph
52:
type orp
53:
type ec
54:
type value
55:
type va
56:
type power_factor
6:
type rain
7:
type rainrate
8:
type wind
9:
type gust
Attributes:
IODev MSG
mapReading_power1 1 power
mapReading_power2 2 power
mapReading_power3 3 power
mapReading_status1 1 status
mapReading_status2 2 status
mapReading_status3 3 status
mode repeater
room Server
setReading_power1 1
setReading_power2 1
setReading_power3 1
setReading_status1 on,off
setReading_status2 on,off
setReading_status3 on,off
version 2.1.1
Ich verstehe die Frage nicht.
Wenn ich mir das aber so ansehe, dann frage ich mich ob Du auch elsif und else kennst?
ZitatFhem2 sollte dan vom befehl "PC_Control Start" am (MYSENSORS) "set PC_Control status1 on" ausführen.
Aber status1 ist ein Reading.
Wenn Du "set PC_Control Start" führst, schaltet "state" von PC_Control auf "Start". Ein EVENT "Start" wird generiert. Laut deinem notify, startet er dann ein "set PC_Control status1 on".
Dann springt "state" von PC_Control auf "status1 on" (und status1 bleibt unverändert!). Ein EVENT "status1 on" wird generiert. Laut deinem notify, startet er dann sukzessiv "set PC_control status1 on", "set PC_control status2 on", usw. Ich weiss nicht, wo die endlose Schleife von fhem Schutzmechanismus unterdrückt wird, aber das macht keinen Sinn.
Wenn Du willst, dass das Reading "status1" auf "on" springt, musst Du "
setreading PC_Control status1 on" einsetzen. Aber wiederum wird ein Event generiert. Es muss von deinem notify nicht interpretiert werden!
Der Schaltbefehl an sich dürfte ok sein (es handelt sich um ein MySensors-Device, da sieht das etwas anders aus als üblich).
Aber um die ganze Konstruktion zu verstehen bräuchte man vermutlich mehr als nur ein paar Bruchstücke...
Klingt für mich nach einem ReadingsProxy, allerdings verwende ich das nicht in Verbindung mit F2F. Könnte etwa so aussehen:
define PC_Control_RP readingsProxy MYSENSOR_200:status1
attr PC_Control_RP setList status1:on,off
Was allerdings die anderen beiden Children (status2 und status3) damit zu tun haben? Da benötigst du ggf. noch weitere notify und solltest beschreiben, was du eigentlich willst.