[gefixed] ack trotz unreach

starfish · January 20, 2016, 11:06am

habe hier iobroker mit homegear im Test. Dabei ist mir aufgefallen, dass bei stromlosem Zwischenstecker dennoch eine Bestätigung des Schaltvorgangs von homegear gemeldet wird. Dadurch hat man trotz bidcos keine Ahnung, ob der Schaltbefehl nun wirklich ausgeführt wurde oder nicht.

Siehe dazu die debug-logs von iobroker, einmal mit CCU (lxccu), einmal mit HOMEGEAR
mit den Schaltvorgängen jeweils mit stromlosem Aktor / eingestecktem Aktor.

[code]HOMEGEAR RPC Zwischenstecker Aktor Schaltvorgang bei ausgesteckt(stromlos)/eingesteckt

hm-rpc.0 2016-01-20 11:31:37 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
hm-rpc.0 2016-01-20 11:31:37 debug hm-rpc.0 xmlrpc <- event [“hm-rpc.0”,“IEQ0074994:1”,“STATE”,true]
hm-rpc.0 2016-01-20 11:31:37 debug hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,STATE,true
hm-rpc.0 2016-01-20 11:31:37 info hm-rpc.0 setValue [“IEQ0074994:1”,“STATE”,true] BOOL
hm-rpc.0 2016-01-20 11:31:37 debug hm-rpc.0 xmlrpc -> setValue 1 STATE: true
hm-rpc.0 2016-01-20 11:31:37 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
on ausgesteckt

hm-rpc.0 2016-01-20 11:19:05 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.0.STICKY_UNREACH
hm-rpc.0 2016-01-20 11:19:05 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.0.UNREACH
hm-rpc.0 2016-01-20 11:19:05 debug hm-rpc.0 xmlrpc <- event [“hm-rpc.0”,“IEQ0074994:0”,“STICKY_UNREACH”,true]
hm-rpc.0 2016-01-20 11:19:05 debug hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:0,STICKY_UNREACH,true
hm-rpc.0 2016-01-20 11:19:05 debug hm-rpc.0 xmlrpc <- event [“hm-rpc.0”,“IEQ0074994:0”,“UNREACH”,true]
hm-rpc.0 2016-01-20 11:19:05 debug hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:0,UNREACH,true
hm-rpc.0 2016-01-20 11:18:59 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
hm-rpc.0 2016-01-20 11:18:59 debug hm-rpc.0 xmlrpc <- event [“hm-rpc.0”,“IEQ0074994:1”,“STATE”,true]
hm-rpc.0 2016-01-20 11:18:59 debug hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,STATE,true
hm-rpc.0 2016-01-20 11:18:59 info hm-rpc.0 setValue [“IEQ0074994:1”,“STATE”,true] BOOL
hm-rpc.0 2016-01-20 11:18:59 debug hm-rpc.0 xmlrpc -> setValue 1 STATE: true
hm-rpc.0 2016-01-20 11:18:59 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
on ausgesteckt

hm-rpc.0 2016-01-20 11:18:57 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
hm-rpc.0 2016-01-20 11:18:57 debug hm-rpc.0 xmlrpc <- event [“hm-rpc.0”,“IEQ0074994:1”,“STATE”,false]
hm-rpc.0 2016-01-20 11:18:57 debug hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,STATE,false
hm-rpc.0 2016-01-20 11:18:57 info hm-rpc.0 setValue [“IEQ0074994:1”,“STATE”,false] BOOL
hm-rpc.0 2016-01-20 11:18:57 debug hm-rpc.0 xmlrpc -> setValue 1 STATE: false
hm-rpc.0 2016-01-20 11:18:57 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
off ausgesteckt

hm-rpc.0 2016-01-20 11:37:45 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.WORKING
hm-rpc.0 2016-01-20 11:37:45 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
hm-rpc.0 2016-01-20 11:37:45 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
hm-rpc.0 2016-01-20 11:37:45 debug hm-rpc.0 xmlrpc <- event [“hm-rpc.0”,“IEQ0074994:1”,“WORKING”,false]
hm-rpc.0 2016-01-20 11:37:45 debug hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,WORKING,false
hm-rpc.0 2016-01-20 11:37:45 debug hm-rpc.0 xmlrpc <- event [“hm-rpc.0”,“IEQ0074994:1”,“STATE”,true]
hm-rpc.0 2016-01-20 11:37:45 debug hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,STATE,true
hm-rpc.0 2016-01-20 11:37:45 debug hm-rpc.0 xmlrpc <- event [“hm-rpc.0”,“IEQ0074994:1”,“STATE”,true]
hm-rpc.0 2016-01-20 11:37:45 debug hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,STATE,true
hm-rpc.0 2016-01-20 11:37:45 info hm-rpc.0 setValue [“IEQ0074994:1”,“STATE”,true] BOOL
hm-rpc.0 2016-01-20 11:37:45 debug hm-rpc.0 xmlrpc -> setValue 1 STATE: true
hm-rpc.0 2016-01-20 11:37:45 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
eingesteckt on

hm-rpc.0 2016-01-20 11:37:42 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.WORKING
hm-rpc.0 2016-01-20 11:37:42 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
hm-rpc.0 2016-01-20 11:37:42 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.0.RSSI_DEVICE
hm-rpc.0 2016-01-20 11:37:42 debug hm-rpc.0 xmlrpc <- event [“hm-rpc.0”,“IEQ0074994:1”,“WORKING”,false]
hm-rpc.0 2016-01-20 11:37:42 debug hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,WORKING,false
hm-rpc.0 2016-01-20 11:37:42 debug hm-rpc.0 xmlrpc <- event [“hm-rpc.0”,“IEQ0074994:1”,“STATE”,false]
hm-rpc.0 2016-01-20 11:37:42 debug hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,STATE,false
hm-rpc.0 2016-01-20 11:37:42 debug hm-rpc.0 xmlrpc <- event [“hm-rpc.0”,“IEQ0074994:0”,“RSSI_DEVICE”,-36]
hm-rpc.0 2016-01-20 11:37:42 debug hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:0,RSSI_DEVICE,-36
hm-rpc.0 2016-01-20 11:37:42 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
hm-rpc.0 2016-01-20 11:37:42 debug hm-rpc.0 xmlrpc <- event [“hm-rpc.0”,“IEQ0074994:1”,“STATE”,false]
hm-rpc.0 2016-01-20 11:37:42 debug hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,STATE,false
hm-rpc.0 2016-01-20 11:37:42 info hm-rpc.0 setValue [“IEQ0074994:1”,“STATE”,false] BOOL
hm-rpc.0 2016-01-20 11:37:42 debug hm-rpc.0 xmlrpc -> setValue 1 STATE: false
hm-rpc.0 2016-01-20 11:37:42 debug inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
eingesteckt off

[/code]

[code]LXCCU RPC Zwischenstecker Aktor Schaltvorgang bei ausgesteckt(stromlos)/eingesteckt

hm-rpc.1 2016-01-20 10:45:44 debug inMem message hm-rpc.1.* hm-rpc.1.IEQ0379063.0.STICKY_UNREACH
hm-rpc.1 2016-01-20 10:45:44 debug inMem message hm-rpc.1.* hm-rpc.1.IEQ0379063.0.UNREACH
hm-rpc.1 2016-01-20 10:45:44 debug hm-rpc.1 xmlrpc <- event [“hm-rpc.1”,“IEQ0379063:0”,“STICKY_UNREACH”,true]
hm-rpc.1 2016-01-20 10:45:44 debug hm-rpc.1 xml multicall : hm-rpc.1,IEQ0379063:0,STICKY_UNREACH,true
hm-rpc.1 2016-01-20 10:45:44 error hm-rpc.1 Error: XML-RPC fault: Failure
hm-rpc.1 2016-01-20 10:45:44 error hm-rpc.1 xmlrpc -> setValue [“1”,“STATE”,true] BOOL
hm-rpc.1 2016-01-20 10:45:44 debug hm-rpc.1 xmlrpc <- event [“hm-rpc.1”,“IEQ0379063:0”,“UNREACH”,true]
hm-rpc.1 2016-01-20 10:45:44 debug hm-rpc.1 xml multicall : hm-rpc.1,IEQ0379063:0,UNREACH,true
hm-rpc.1 2016-01-20 10:45:43 info hm-rpc.1 setValue [“IEQ0379063:1”,“STATE”,true] BOOL
hm-rpc.1 2016-01-20 10:45:43 debug hm-rpc.1 xmlrpc -> setValue 1 STATE: true
on

hm-rpc.1 2016-01-20 10:45:40 debug inMem message hm-rpc.1.* hm-rpc.1.IEQ0379063.0.STICKY_UNREACH
hm-rpc.1 2016-01-20 10:45:40 debug inMem message hm-rpc.1.* hm-rpc.1.IEQ0379063.0.UNREACH
hhm-rpc.1 2016-01-20 10:45:40 debug hm-rpc.1 xmlrpc <- event [“hm-rpc.1”,“IEQ0379063:0”,“STICKY_UNREACH”,true]
hm-rpc.1 2016-01-20 10:45:40 debug hm-rpc.1 xml multicall : hm-rpc.1,IEQ0379063:0,STICKY_UNREACH,true
hm-rpc.1 2016-01-20 10:45:40 error hm-rpc.1 Error: XML-RPC fault: Failure
hm-rpc.1 2016-01-20 10:45:40 error hm-rpc.1 xmlrpc -> setValue [“1”,“STATE”,false] BOOL
hm-rpc.1 2016-01-20 10:45:40 debug hm-rpc.1 xmlrpc <- event [“hm-rpc.1”,“IEQ0379063:0”,“UNREACH”,true]
hm-rpc.1 2016-01-20 10:45:40 debug hm-rpc.1 xml multicall : hm-rpc.1,IEQ0379063:0,UNREACH,true
hm-rpc.1 2016-01-20 10:45:39 info hm-rpc.1 setValue [“IEQ0379063:1”,“STATE”,false] BOOL
hm-rpc.1 2016-01-20 10:45:39 debug hm-rpc.1 xmlrpc -> setValue 1 STATE: false
off

Stecker gezogen

hm-rpc.1 2016-01-20 10:20:51 debug inMem message hm-rpc.1.* hm-rpc.1.IEQ0379063.1.WORKING
hm-rpc.1 2016-01-20 10:20:51 debug inMem message hm-rpc.1.* hm-rpc.1.IEQ0379063.1.STATE
hm-rpc.1 2016-01-20 10:20:51 debug hm-rpc.1 xmlrpc <- event [“hm-rpc.1”,“IEQ0379063:1”,“WORKING”,false]
hm-rpc.1 2016-01-20 10:20:51 debug hm-rpc.1 xml multicall : hm-rpc.1,IEQ0379063:1,WORKING,false
hm-rpc.1 2016-01-20 10:20:51 debug hm-rpc.1 xmlrpc <- event [“hm-rpc.1”,“IEQ0379063:1”,“STATE”,true]
hm-rpc.1 2016-01-20 10:20:51 debug hm-rpc.1 xml multicall : hm-rpc.1,IEQ0379063:1,STATE,true
hm-rpc.1 2016-01-20 10:20:50 info hm-rpc.1 setValue [“IEQ0379063:1”,“STATE”,true] BOOL
hm-rpc.1 2016-01-20 10:20:50 debug hm-rpc.1 xmlrpc -> setValue 1 STATE: true

eingesteckt on

hm-rpc.1 2016-01-20 10:20:47 debug inMem message hm-rpc.1.* hm-rpc.1.IEQ0379063.1.WORKING
hm-rpc.1 2016-01-20 10:20:47 debug inMem message hm-rpc.1.* hm-rpc.1.IEQ0379063.1.STATE
hm-rpc.1 2016-01-20 10:20:46 debug hm-rpc.1 xmlrpc <- event [“hm-rpc.1”,“IEQ0379063:1”,“WORKING”,false]
hm-rpc.1 2016-01-20 10:20:46 debug hm-rpc.1 xml multicall : hm-rpc.1,IEQ0379063:1,WORKING,false
hm-rpc.1 2016-01-20 10:20:46 debug hm-rpc.1 xmlrpc <- event [“hm-rpc.1”,“IEQ0379063:1”,“STATE”,false]
hm-rpc.1 2016-01-20 10:20:46 debug hm-rpc.1 xml multicall : hm-rpc.1,IEQ0379063:1,STATE,false
hm-rpc.1 2016-01-20 10:20:46 info hm-rpc.1 setValue [“IEQ0379063:1”,“STATE”,false] BOOL
hm-rpc.1 2016-01-20 10:20:46 debug hm-rpc.1 xmlrpc -> setValue 1 STATE: false

eingesteckt off[/code]

starfish · January 21, 2016, 2:26pm

taucht dieses Problem nur mit CC1101 auf oder auch mit anderen homematic-transceivern?

sathya · January 22, 2016, 11:32am

Hey starfish,

bisher war es tatsächlich so, dass setValue für HomeMatic BidCoS ohne Fehler ausgeführt wurde, selbst wenn ein Gerät nicht erreichbar war. Ich habe nur UNREACH gesetzt. Das Paket wurde dann gesendet, sobald das Gerät wieder ein Lebenszeichen von sich gegeben hat. Das Verhaltung von setValue habe ich jetzt mal entsprechend geändert. Es ist sinnvoll zu warten, ob das Paket tatsächlich gesendet wurde. Jetzt wird bei Nicht-Erreichbarkeit des Gerätes der RPC-Fehler -100 zurückgegeben. Für das alte Verhalten habe ich den Parameter “wait” zur RPC-Methode hinzugefügt, so dass setValue bei Bedarf ohne zu blockieren aufgerufen werden kann.

Die neue Funktion ist im nächsten Nightly-Build enthalten. Bin gespannt auf deine Rückmeldung.

Viele Grüße

Sathya

mikesch · January 22, 2016, 2:10pm

Hallo,

das erklärt vielleicht ein etwas beunruhigendes Verhalten, das ich gestern beobachtet habe.

Ich habe in Openhab eine rule definiert, die auf Druck einer Fernbedienungstaste unsere Haustür mittels Keymatic öffnet. Gestern funktionierte dies nicht. Ich stand also auf, ging zur Tür und öffnete manuell. Soweit so gut. Als ich schon wieder im Wohnzimmer saß, öffnete die Keymatic plötzlich doch noch die Tür. In der Zwischenzeit waren mehrere Minuten vergangen. Gar nicht gut, hätten wir in das Haus bereits verlassen gehabt.

Steht dieser Sachverhalt in Zusammenhang mit der bisherigen Funktionsweise homegears? Ist dies nach der Änderung noch möglich?

Gruß
Ralf

sathya · January 22, 2016, 2:33pm

Hallo Ralf,

Ja. Wenn ein Gerät wieder erreichbar ist, wird der zuletzt mit setValue gesetzte Wert an das Gerät gesendet. Normalerweise ist das gewolltes Verhalten, damit der Stand des Gerätes dem Stand in Homegear entspricht. Beim Abschließen über eine Fernbedienung erwartest du ja auch, dass die KeyMatic auch tatsächlich schließst. Das bedeutet aber auch, wenn die letzte mit setValue gesetzte Aktion ein Abschließen des Hauses ist, wird sich die KeyMatic nicht einfach wieder aufschließen. Bei der KeyMatic und WinMatic habe ich jetzt aber eingebaut, dass die Queue bei Nicht-Erreichbarkeit gelöscht wird, wenn “STATE” auf “true” gesetzt wurde. Damit hast du jetzt ein sicheres Abschließen und ein sicheres Aufschließen.

Viele Grüße

Sathya

mikesch · January 22, 2016, 2:37pm

Danke sathya.

Gruß
Ralf

starfish · January 22, 2016, 4:45pm

ja, ich bin auch gespannt. zum anderen bin ich froh, dass Du das Verhalten bestätigst. Meine Zweifel kamen, als ich die Funktionalität von iobroker verglich mit der von Home Control Suite. Dort zeigen die Taster in der GUI mit verschiedenen Farben an, ob der Befehl abgeschickt, bzw. tatsächlich angekommen ist. (ein vermutet= hellgelb/ ein bestätigt = dunkelgelb bzw. aus vermutet = hellgrau / aus bestätigt = dunkelgrau) Zudem wird unreach durch ausgrauen des Tasters in der GUI angezeigt. So lernt man alte Software schätzen. In iobroker muss ich erst herausfinden, ob diese Funktionalität auch möglich ist (sollte eigentlich, glaube mit Zahnrad im icon).
Da hab ich grad noch eine Frage: wie funktioniert das Signal “working”? ich stelle fest, dass im log immer nur “false” gemeldet wird. Wird da einfach angenommen, dass bei “state”-änderung anfangs automatisch working = true ist? (und manuell gesetzt werden muss?)

starfish · January 23, 2016, 1:24pm

so, jetzt habe ich die neuste Version 0.6.0-1181 getestet - iobroker zeigt jetzt richtig an “no ack” wenn der aktor ausgesteckt ist - beim Wiedereinstecken bleibt der Aktor in der GUI auf no ack, bis erneut ein Schaltbefehl abgesetzt wird. Erst dann merkt homegear bzw. iobroker, dass der Aktor wieder erreichbar ist.

hm-rpc.0	2016-01-23 13:58:32	debug	inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.0.STICKY_UNREACH
hm-rpc.0	2016-01-23 13:58:32	debug	inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.0.UNREACH
hm-rpc.0	2016-01-23 13:58:32	debug	hm-rpc.0 xmlrpc <- event ["hm-rpc.0","IEQ0074994:0","STICKY_UNREACH",true]
hm-rpc.0	2016-01-23 13:58:32	debug	hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:0,STICKY_UNREACH,true
hm-rpc.0	2016-01-23 13:58:32	debug	hm-rpc.0 xmlrpc <- event ["hm-rpc.0","IEQ0074994:0","UNREACH",true]
hm-rpc.0	2016-01-23 13:58:32	debug	hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:0,UNREACH,true
hm-rpc.0	2016-01-23 13:58:25	error	hm-rpc.0 Error: XML-RPC fault: No answer from device.
hm-rpc.0	2016-01-23 13:58:25	error	hm-rpc.0 xmlrpc -> setValue ["1","STATE",true] BOOL
hm-rpc.0	2016-01-23 13:58:23	info	hm-rpc.0 setValue ["IEQ0074994:1","STATE",true] BOOL
hm-rpc.0	2016-01-23 13:58:23	debug	hm-rpc.0 xmlrpc -> setValue 1 STATE: true
hm-rpc.0	2016-01-23 13:58:23	debug	inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
-------------------on aktor ausgesteckt -----------------------
hm-rpc.0	2016-01-23 13:55:15	error	hm-rpc.0 Error: XML-RPC fault: : Requested method not found.
hm-rpc.0	2016-01-23 13:55:15	debug	hm-rpc.0 Send PING...
hm-rpc.0	2016-01-23 13:55:04	debug	inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
hm-rpc.0	2016-01-23 13:55:04	debug	inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.WORKING
hm-rpc.0	2016-01-23 13:55:04	debug	inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
hm-rpc.0	2016-01-23 13:55:04	debug	hm-rpc.0 xmlrpc <- event ["hm-rpc.0","IEQ0074994:1","STATE",true]
hm-rpc.0	2016-01-23 13:55:04	debug	hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,STATE,true
hm-rpc.0	2016-01-23 13:55:04	debug	hm-rpc.0 xmlrpc <- event ["hm-rpc.0","IEQ0074994:1","WORKING",false]
hm-rpc.0	2016-01-23 13:55:04	debug	hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,WORKING,false
hm-rpc.0	2016-01-23 13:55:04	debug	hm-rpc.0 xmlrpc <- event ["hm-rpc.0","IEQ0074994:1","STATE",true]
hm-rpc.0	2016-01-23 13:55:04	debug	hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,STATE,true
hm-rpc.0	2016-01-23 13:55:04	info	hm-rpc.0 setValue ["IEQ0074994:1","STATE",true] BOOL
hm-rpc.0	2016-01-23 13:55:04	debug	hm-rpc.0 xmlrpc -> setValue 1 STATE: true
------------------ on  aktor eingesteckt ---------------------------
hm-rpc.0	2016-01-23 13:49:02	debug	inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
hm-rpc.0	2016-01-23 13:49:02	debug	inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.WORKING
hm-rpc.0	2016-01-23 13:49:02	debug	inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
hm-rpc.0	2016-01-23 13:49:02	debug	hm-rpc.0 xmlrpc <- event ["hm-rpc.0","IEQ0074994:1","STATE",false]
hm-rpc.0	2016-01-23 13:49:02	debug	hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,STATE,false
hm-rpc.0	2016-01-23 13:49:02	debug	hm-rpc.0 xmlrpc <- event ["hm-rpc.0","IEQ0074994:1","WORKING",false]
hm-rpc.0	2016-01-23 13:49:02	debug	hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,WORKING,false
hm-rpc.0	2016-01-23 13:49:02	debug	hm-rpc.0 xmlrpc <- event ["hm-rpc.0","IEQ0074994:1","STATE",false]
hm-rpc.0	2016-01-23 13:49:02	debug	hm-rpc.0 xml multicall : hm-rpc.0,IEQ0074994:1,STATE,false
hm-rpc.0	2016-01-23 13:49:02	info	hm-rpc.0 setValue ["IEQ0074994:1","STATE",false] BOOL
hm-rpc.0	2016-01-23 13:49:02	debug	hm-rpc.0 xmlrpc -> setValue 1 STATE: false
hm-rpc.0	2016-01-23 13:49:02	debug	inMem message hm-rpc.0.* hm-rpc.0.IEQ0074994.1.STATE
-------------------off aktor eingesteckt --------------------

ich denke jetzt läufts OK - vielen Dank für die rasche Reaktion
Beat

p.s. noch eine Frage: wielange wird gewartet, bis “XML-RPC fault: No answer from device.” generiert wird?

sathya · January 29, 2016, 9:43am

Das hängt von der Gerätefamilie ab. Bei HomeMatic BidCoS wird 2,5 Sekunden gewartet.