Hallo,
ich habe gerade die Version 4.2 eingecheckt.
Neu:Mit dem Modul
88_HMCCURPCPROC steht nun ein Sub-Prozess basierter RPC Server zur Verfügung. Alle User, die aufgrund der Inkompatibilität von JSON mit Perl-Threads bzw. HMCCURPC Probleme haben, sollten auf HMCCURPCPROC umstellen. HMCCURPCPROC arbeitet problemlos mit JSON::XS zusammen. Zur Umstellung bitte so vorgehen:
- RPC Server stoppen
- Im Attribut ccuflags im I/O Device procrpc auswählen und extrpc/intrpc abwählen
- FHEM neu starten
- RPC Server aus dem I/O Device starten, sofern nicht Autostart eingestellt ist
Beim ersten Start des RPC Servers wird für jede im Attribut
rpcinterfaces festgelegte Schnittstelle ein Device vom Typ HMCCURPCPROC definiert. Dabei werden die Attribute room und group des I/O Device übernommen. Ggf. bitte nach dem Start einmal die FHEM Config speichern.
Der neue RPC Server ist mindestens genauso schnell wie der bisherige externe (Reaktionszeit < 0,02 Sekunden). Es werden außer RPC::XML::Server/Client keine weiteren Module benötigt (ein niedrigerer Speicherverbrauch durch die Verwendung von fork() anstelle von Threads ist übrigens nicht feststellbar).
HMCCURPCPROC wird mit der nächsten Version sowohl den externen (HMCCURPC) als auch den internen RPC-Server ersetzen! Also bitte testen und Feedback geben, wenn Probleme auftreten!
Weitere Neuerungen Version 4.2:
- Unterstützung von Homematic Virtual Layer (Interface HVL), siehe auch https://homematic-forum.de/forum/viewtopic.php?f=44&t=33848
- Automatische Ermittlung der verfügbaren RPC Interfaces der CCU2
- Neuer Befehl set ackmessages zum Bestätigen von unreachable Meldungen in der CCU2
- Event Timeouts können mit dem Attribut rpcEventTimeout = 0 deaktiviert werden
- Der Befehl set datapoint erlaubt das Setzen mehrere Datenpunkte in einem Aufruf: dp1 value1 dp2 value2 ...
- Das Flag ackState im Attribut ccuflags ersetzt das Attribut ccuackstate
- Das Flag noReadings im Attribut ccuflags ersetzt das Attribut ccureadings im I/O Device
Folgende Fehler wurden behoben:
- Fehler beim Parsen von Adressen korrigiert
- Fehler bei Fehlerausgabe und Fehlerstatus korrigiert
- Fehler bei der Verarbeitung von RPC Events mit String Value korrigiert
- Fehler bei der Deregistrierung eines RPC Servers korrigiert
- Fehler bei einigen ccureadingfilter Parametern korrigiert
Hallo zap,
habe eben von extrpc auf procrpc umgestellt (war nicht betroffen von JSON Problematik), alles läuft bestens, keine Probleme bei der Funktion feststellbar, Geschwindigkeit so wie gewohnt Pfeilschnell.
Ein Schönheitsfehler ist mir jedoch noch aufgefallen, bei mir steht das HMCCU Device ständig auf "running/Initialized" ich denke beim extrpc war es "running/OK".
Woran kann dies liegen, wo muss ich da noch etwas einstellen, oder was passt bei mir nicht?
defmod CCU2 HMCCU 192.168.1.32 waitforccu=300
attr CCU2 DbLogExclude .*
attr CCU2 ccuflags procrpc
attr CCU2 cmdIcon on:general_an off:general_aus
attr CCU2 eventMap /rpcserver on:on/rpcserver off:off/
attr CCU2 icon hm_ccu
attr CCU2 room Homematic
attr CCU2 rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
attr CCU2 rpcport 2001,2010,9292
attr CCU2 rpcqueue /tmp/ccuqueue
attr CCU2 rpcserver on
attr CCU2 stateFormat rpcstate/state
setstate CCU2 running/Initialized
setstate CCU2 2018-01-30 20:39:45 Watchdog 0
setstate CCU2 2018-01-06 15:20:03 battery_count 56
setstate CCU2 2018-01-06 15:20:03 battery_list Batterien OK
setstate CCU2 2018-01-06 15:20:03 battery_match 0
setstate CCU2 2018-01-06 15:20:03 battery_state ok
setstate CCU2 2018-01-30 20:34:09 rpcstate running
setstate CCU2 2018-01-30 20:33:42 state Initialized
Alle 3 HMCCURPCPROC Device (CCU RPC BidCos-RF, CCU RPC HmIP-RF, CCU RPC VirtualDevices) wurden bei mir angelegt, diese stehen alle auf "running/OK"
Im Log steht nur eine, für mich auffällige Meldung:
2018.01.30 21:31:47 2: HMCCURPCPROC: [d_rpcVirtualDevices] Received no events from interface CB9292 for 600.038018941879 seconds
Auch ein Nestart von Fhem ändert an dem state Initialized nichts.
Nachtrag von Mittwoch 16:30 Uhr:
Wurde am pollen der CCU2 Systemvariablen etwas geändert?
Ich verwende eine CCU2 Systemvariable als Watchdog zur Kommunikationsüberwachung zu einer WAGO Steuerung (Modbus).
Die Variable wird in der HMCCU bei den Readings korrekt angezeigt und diese wechselt auch brav regelmäßig ihren Zustand, nur es wird kein Trigger mehr erzeugt (auch im Event Monitor nicht zu sehen). Hab schon mit event-on.... experimentiert, löst aber das Problem mit den fehlenden Trigger nicht.
Versuche ich die CCU2 Systemvariable über die Fhem Kommandozeile mit:
get CCU2 vars Watchdog
von der CCU2 zu lesen, erhalte ich ein kleines leeres Fenster ohne jeden Inhalt aber auch keine Fehlermeldung.
Wenn nötig gerne mehr Infos von meiner Seite, wenn das Problem nicht nachvollziebar ist.
Danke für deine großartige Arbeit für die Homematic Fraktion!
Gruß Reinhard
Ja, das habe ich auch. Ich habe von intrpc auf procrpc umgestellt, (war betroffen von JSON Problematik weil ich SONOS benutze, konnte also den extrpc nicht benutzen). Läuft prima bisher, gefühlt stabiler. Auch bei mir steht nach der Umstellung das HMCCU jetzt immer auf 'Initialized' (das 'running/Initialized' kommt vom stateformat (attr CCU2 stateFormat rpcstate/state)).
Aber ich denke das ist vielleicht nur ein Schönheitsfehler, weil die HMCCURPCPROC jetzt auf 'running/OK' stehen? Aber wäre eindeutiger wenn der HMCCU state auch 'OK' wäre wie vorher. Danke für die Arbeit, beste Grüsse!!
Hallo Zap,
gerade upgedatet und von ext auf proc umgestellt.
Läuft tadellos!
Superschnell und endlich ist auch mein Disconnect der Fhem-Webseite nach Veränderung eines HmIP-Devices weg.
Im Log ist alles sauber.
Klasse - wie immer!
Viele Grüße
Christian
Da bin ich aber froh, dass es grundsätzlich läuft. Habe ziemlich viel umgebaut in der 4.2 und konnte leider nicht alles durchtesten.
Der Status running/initialized ist mir auch aufgefallen. Konnte es auf die schnelle nicht beheben. Werde es mir aber nochmal anschauen.
Events bei Systemvariablen: Das ist ein Bug. Korrektur ist in Arbeit.
Die Version 4.2.001 behebt folgende Probleme:
- Kein Event nach Aktualisierung von CCU Systemvariablen mit dem Befehl "get vars"
- state des I/O Device bleibt auf "Initialized" stehen
Morgen per FHEM Update verfügbar.
Hallo zap,
da freu ich mich ja auf Morgen, wenn mein Watchdog über die CCU2 wieder läuft. War aber nicht so eilig, da die Fenster im Gewächshaus derzeit eh nicht geöffnet werden.
Eines ist mir noch aufgefallen:
Wenn ich den RPCSERVER des HMCCU Device mit "set CCU2 rpcserver off" beenden will, bekomme ich auf der Fhem Oberfläche die Meldung "HMCCU: CCU2 Usage: set CCU2 rpcserver {'on'|'off'|'restart'}" angezeigt. Die gleiche Meldung kommt auch beim Start.
Hab auch mal "set CCU2 rpcserver {'on'}" versucht, klappt aber auch nicht.
Nur das starten und beenden über die "cmdIcons" klappt bei mir Problemlos.
Feature oder Schönheitsfehler?
HMCCURPCPROC schnurrt bei mir, mit Ausnahme der beschriebenen Abweichungen, wie ein Kätzchen!
Ich bin immer noch über die sehr schnellen Reaktionszeiten begeistert (war ja bereits seit extrpc so).
Gruß Reinhard
Das Problem mit "set rpcserver on/off" kann ich bestätigen. Das liegt am Attribut eventMap. Das macht aus einem
set rpcserver on
ein
set rpcserver rpcserver on
Die Ersetzung bei eventMap funktioniert also in beide Richtungen. Das wusste ich nicht. Mal sehen, wie ich das behebe.
Update: Fehler behoben. Kann es aber erst morgen einchecken. Bis dahin
set on
set off
oder cmdIcons
Hallo zap,
die Anzeige vom Status des Device "HMCCU" passt nun, es wird "running/OK" (state OK) angezeigt.
Auch das get vars klappt wieder so wie es sein soll.
Leider klappt der start/stopp des rpcservers bei mir nicht über "set CCU2 rpcserver on", "set CCU2 on" und auch nicht über die Auswahlfelder neben dem set Befehl über die Oberfläche des Device.
Start/Stop ist bei mir (derzeit) nur über die Buttons "eventMap" und "cmdIcon" möglich.
Sollten die Änderungen hierzu schon in 4.2.001 enthalten sein?
Klär mich doch bitte mal auf, weshalb im Log (Verbose 3) bei mir alle 10 Minuten die Meldungen kommen:
2018.02.02 16:52:15 2: HMCCURPCPROC: [d_rpcVirtualDevices] Received no events from interface CB9292 for 600.123554944992 seconds
Wurden die Meldungen in der Version vor HMCCURPCPROC nicht angezeigt, denn ich habe unter rpcport, gegenüber früher nichts geändert. So wie ich es sehe, kann ich bei mir den rpcport 9292 komplett löschen, wenn ich keine virtuellen Devices in der CCU2 verwende.
Sehe ich das richtig oder bringe ich da etwas durcheinander?
Grundsätzlich läuft aber alles andere sehr stabil.
Gruß Reinhard
In der 4.2.001 ist das set rpcserver on/off noch nicht gefixt. Es ist auch nicht wirklich ein Bug sondern liegt am Attribut eventMap. Wenn du das löschst, gehen zwar die CmdIcons nicht mehr, dafür aber der set rpcserver Befehl.
Aber wie gesagt, mit 4.2.002 wird beides gehen. Habe aber noch einen anderen Bug gefunden. Den fixe ich erst, bevor ich es einchecke.
Die Fehlermeldung im Log kannst Du vermeiden, indem du das Attribut rpcEventTimeout auf 0 setzt (im entsprechenden HMCCURPCPROC Device). Oder du setzt das Attribut auf einen entsprechend hohen Wert. Default ist 600.
Hintergrund: wenn für die angegebene Zeitspanne kein Event kommt und ccuflags auf reconnect steht, registriert sich der RPC Server automatisch neu. Damit kann ein Verbindungsabbruch zur CCU zB bei einem Restart der CCU automatisch behoben werden.
Hallo zap,
hast du das Attribut jetzt pro RPC-Server implementiert? Das wäre sinnvoll.
hab heute nach einem FHEM-Restart folgendes in der Motd stehen:
configfile: d_ccu: unknown attribute ccureadings
@Ralli: ja, die RPC Server Attribute sind für die HMCCURPCPROC Devices auch direkt am Device angelegt. Die mehr oder weniger gleichnamigen Attribute in HMCCU gelten nur für den internen RPC Server. Der wird aber demnächst sowieso aus dem Modul verschwinden.
@kjmEjfu: das Attribut ccureadings gibt es nicht mehr im HMCCU Device. Da war der Default sowieso 1 (Readings schreiben). Wenn man im IO Device keine Readings haben möchte, setzt man im Attribut ccuflags die Option ,,noReadings". Sorry, hatte ich im Changelog vergessen zu erwähnen.
Nach dem Starten einmal FHEM Config speichern, dann ist das Attribut raus aus der Config.
Moin zap,
ich nutze bisher den externen RPC.
Muss ich auf den neuen RPC umstellen?
Vielen Dank.
Grüße Mave
Zitat von: Mave am 04 Februar 2018, 11:05:15
Moin zap,
ich nutze bisher den externen RPC.
Muss ich auf den neuen RPC umstellen?
Wenn du keine Probleme mit Modulen hast, die JSON verwenden, erst mal nicht. Mit der nächsten HMCCU Version passiert die Umstellung automatisch, d.h. beim ersten Start wird HMCCU dann HMCCURPCPROC Devices anlegen. So der Plan. Wahrscheinlich aber erst irgendwann im März.
Hallo zap,
Update durchgeführt.
Bisher sehe ich keine Probleme im Log.
Danke für die Arbeit!
Gruss Gerd
Hallo zap,
auch bei mir sehen die ersten Tests sehr gut an. Auch das Zusammenspiel zwischen yowsup und hmccu funktioniert nun bei mir.
Wenn mir noch Fehler auffallen, dann werde ich es berichten.
Viele Grüße
Marc
Zitat von: zap am 04 Februar 2018, 11:49:04
Wenn du keine Probleme mit Modulen hast, die JSON verwenden, erst mal nicht. Mit der nächsten HMCCU Version passiert die Umstellung automatisch, d.h. beim ersten Start wird HMCCU dann HMCCURPCPROC Devices anlegen. So der Plan. Wahrscheinlich aber erst irgendwann im März.
Okay, verstanden.
Vielen Dank.
Was will mir denn diese Meldung im Log sagen:
CCURPC: I/O error during data processing (Select found no reader)
Vielen Dank.
Grüße Mave
Wenn die Meldung nicht oft kommt, kannst Du das ignorieren. Besagt eigentlich nur, dass der RPC Server Daten an FHEM übergeben wollte, FHEM aber zu beschäftigt war, um diese anzunehmen.
Die Daten werden in dem Fall zwischengespeichert und nach kurzer Zeit nochmal übertragen, d.h. es gehen keine Infos verloren.
Hey zap,
vielen Dank.
Die Meldung kommt immer beim Neustart von FHEM.
Grüße Mave
Die Version 4.2.002 ist eingecheckt und steht morgen per Update zur Verfügung. Für Nutzer von CUxD auf der CCU ist dieses Update dringend empfohlen!
Behobene Fehler:
- Fehler bei der Übertragung von Fließkommawerten aus CUxD behoben
- Befehl "set rpcserver" funktioniert nun auch, wenn per eventMap die Befehle "on" und "off" definiert wurden
- Fehler beim Setzen des RPC Server Status im I/O Device behoben
Hallo zap,
hab gerade den Update durchgeführt.
Funktioniert alles einwandfrei, der RPC-Server ist sehr, sehr schnell und keinerlei Fehlermeldungen im Log.
Danke !!!
Gruss Rolf
Moin @all,
seit der Umstellung bekomme ich keine Temperaturdaten mehr.
Also zur Randinformation. Ich habe über fhem meine Oregon Sensoren laufen und hatte die Werte dann an den CuxD schicken lassen. Jetzt bekomme ich aber immer die Meldung
set Oregon_Sensor_6_bad datapoint 1.SET_HUMIDITY 50 comma C off on off : HMCCUDEV: Oregon_Sensor_6_bad Invalid datapoint
2018.02.21 04:41:15 3: nOregon_Sensor_6_bad_luft return value: HMCCUDEV: Oregon_Sensor_6_bad Invalid datapoint
So sah es bisher in fhem.cfg aus
define myccu HMCCU 192.168.178.4
attr myccu ccuflags procrpc
attr myccu rpcserver on
attr myccu stateFormat rpcstate/state
define Oregon_Sensor_1_flur HMCCUDEV CUX9002001
attr Oregon_Sensor_1_flur IODev myccu
define Oregon_Sensor_2_azimmer HMCCUDEV CUX9002002
attr Oregon_Sensor_2_azimmer IODev myccu
define Oregon_Sensor_3_maurice HMCCUDEV CUX9002003
attr Oregon_Sensor_3_maurice IODev myccu
define Oregon_Sensor_4_lene HMCCUDEV CUX9002004
attr Oregon_Sensor_4_lene IODev myccu
define Oregon_Sensor_5_kueche HMCCUDEV CUX9002005
attr Oregon_Sensor_5_kueche IODev myccu
define Oregon_Sensor_6_bad HMCCUDEV CUX9002009
attr Oregon_Sensor_6_bad IODev myccu
define nOregon_Sensor_1_flur notify Oregon_Sensor_1_flur|THGR228N_b3_4:temperature:.* {\
my $temperature = ReadingsNum("THGR228N_b3_4","temperature",10);;\
fhem "set Oregon_Sensor_1_flur datapoint 1.SET_TEMPERATURE $temperature comma C off on off";;}
Nun meine Frage. Was muß ich ich ändern, das es wieder Funktioniert ?
LG
Gentoo79
Mach mal bitte ein
get Oregon_Sensor6_bad deviceinfo
und poste hier die Ausgabe.
Tritt das nur bei diesem Sensor auf?
Du willst also den Datenpunkt 1.SET_HUMIDITY auf den Wert "50 comma C off on off" setzen? Wenn ja, musst du den Wert in doppelte Anführungszeichen setzen.
Hintergrund: Seit 4.2 unterstützt HMCCU das Schreiben in mehrere Datenpunkte mit einem Set Befehl. Daher werden in deinem Fall comma, off und off als Datenpunkte interpretiert. Dh musst nur aufpassen, da du im Notify auch doppelte Anführungszeicbdn verwendest. ggf funktionieren auch einfache.
nabend,
bei Befehl von get Oregon_Sensor_6_bad deviceinfo kommt.
HMCCUDEV: Oregon_Sensor_6_bad Execution of CCU script or command failed
es ist bei allen 6 Sensoren so?
Wie muss das denn aussehen mit den doppelten Anführungszeichen
etwa so
define nOregon_Sensor_1_flur notify Oregon_Sensor_1_flur|THGR228N_b3_4:temperature:.* {\
my $temperature = ReadingsNum("THGR228N_b3_4","temperature",10);;\
fhem ""set Oregon_Sensor_1_flur datapoint 1.SET_TEMPERATURE $temperature comma C off on off"";;}
define nOregon_Sensor_1_flur_luft notify Oregon_Sensor_1_flur|THGR228N_b3_4:humidity:.* {\
my $humidity = ReadingsNum("THGR228N_b3_4","humidity",10);;\
fhem ""set Oregon_Sensor_1_flur datapoint 1.SET_HUMIDITY $humidity comma C off on off"";;}
Vieelleicht so:
define nOregon_Sensor_1_flur notify Oregon_Sensor_1_flur|THGR228N_b3_4:temperature:.* {\
my $temperature = ReadingsNum("THGR228N_b3_4","temperature",10);;\
fhem "set Oregon_Sensor_1_flur datapoint 1.SET_TEMPERATURE \"$temperature comma C off on off\"";;}
oder so: (einfache Anführungszeichen vor $temperature und nach off)
define nOregon_Sensor_1_flur notify Oregon_Sensor_1_flur|THGR228N_b3_4:temperature:.* {\
my $temperature = ReadingsNum("THGR228N_b3_4","temperature",10);;\
fhem "set Oregon_Sensor_1_flur datapoint 1.SET_TEMPERATURE '$temperature comma C off on off'";;}
Warum allerdings get deviceinfo nicht funktioniert ist mir ein Rätsel
nabend,
also irgendwie funktioniert das auch nicht.
Als Beispiel habe ich jetzt mal den Senso9r im Flur genommen.
Bei "get Oregon_Sensor_1_flur deviceinfo kam jetzt das
CHN CUX9002001:0 Flur unten:0
DPT {b} CUxD.CUX9002001:0.UNREACH = false [RE]
CHN CUX9002001:1 Flur unten:1
DPT {f} CUxD.CUX9002001:1.TEMPERATURE = 19.100000 [RE]
DPT {i} CUxD.CUX9002001:1.HUMIDITY = 54 [RE]
DPT {f} CUxD.CUX9002001:1.HUMIDITYF = 54.000000 [RE]
DPT {f} CUxD.CUX9002001:1.DEW_POINT = 9.580000 [RE]
DPT {f} CUxD.CUX9002001:1.ABS_HUMIDITY = 8.850000 [RE]
DPT {f} CUxD.CUX9002001:1.TEMP_MIN_24H = 0.000000 [RE]
DPT {f} CUxD.CUX9002001:1.TEMP_MAX_24H = 0.000000 [RE]
DPT {f} CUxD.CUX9002001:1.HUM_MIN_24H = 0.000000 [RE]
DPT {f} CUxD.CUX9002001:1.HUM_MAX_24H = 0.000000 [RE]
DPT {f} CUxD.CUX9002001:1.SET_TEMPERATURE = [W]
DPT {f} CUxD.CUX9002001:1.SET_HUMIDITY = [W]
DPT {b} CUxD.CUX9002001:1.INSTALL_TEST = false [RW]
CHN CUX9002001:2 Flur unten:2
DPT {f} CUxD.CUX9002001:2.SETPOINT = 20.000000 [RWE]
DPT {b} CUxD.CUX9002001:2.STATE = false [RE]
DPT {f} CUxD.CUX9002001:2.LEVEL = 0.000000 [RE]
DPT {b} CUxD.CUX9002001:2.SET_INVERT = false [RWE]
DPT {b} CUxD.CUX9002001:2.INSTALL_TEST = false [RW]
CHN CUX9002001:3 Flur unten:3
DPT {b} CUxD.CUX9002001:3.STATE = false [RE]
DPT {b} CUxD.CUX9002001:3.INSTALL_TEST = false [RW]
in der fhem.cfg habe ich folgendes stehen
define myccu HMCCU 192.168.178.4
attr myccu ccuflags procrpc
attr myccu rpcinterfaces BidCos-RF,CUxD,HmIP-RF,VirtualDevices
attr myccu rpcport 2001,8701,2010,9292
attr myccu rpcserver on
attr myccu stateFormat rpcstate/state
define Oregon_Sensor_1_flur HMCCUDEV CUX9002001
attr Oregon_Sensor_1_flur IODev myccu
define nOregon_Sensor_1_flur notify Oregon_Sensor_1_flur|THGR228N_b3_4:temperature:.* {\
my $temperature = ReadingsNum("THGR228N_b3_4","temperature",10);;\
fhem "set Oregon_Sensor_1_flur datapoint 1.SET_TEMPERATURE $temperature comma C off on off"";;}
define nOregon_Sensor_1_flur_luft notify Oregon_Sensor_1_flur|THGR228N_b3_4:humidity:.* {\
my $humidity = ReadingsNum("THGR228N_b3_4","humidity",10);;\
fhem "set Oregon_Sensor_1_flur datapoint 1.SET_HUMIDITY $humidity comma C off on off"";;}
aber denoch werden die Daten nicht an den Wrapper (90) von CuxD übertragen.
in der CCU wird nix geändert.
Im log steht dieses
2018.02.22 21:20:43 1: PERL WARNING: String found where operator expected at (eval 101) line 3, at end of line
2018.02.22 21:20:43 3: eval: my $EVTPART0='humidity:';my $EVENT='humidity: 54';my $EVTPART1='54';my $NAME='THGR228N_b3_4';my $SELF='nOregon_Sensor_1_flur_luft';my $TYPE='OREGON';{
my $humidity = ReadingsNum("THGR228N_b3_4","humidity",10);
fhem "set Oregon_Sensor_1_flur datapoint 1.SET_HUMIDITY $humidity comma C off on off"";}
2018.02.22 21:20:43 1: ERROR evaluating my $EVTPART0='humidity:';my $EVENT='humidity: 54';my $EVTPART1='54';my $NAME='THGR228N_b3_4';my $SELF='nOregon_Sensor_1_flur_luft';my $TYPE='OREGON';{
my $humidity = ReadingsNum("THGR228N_b3_4","humidity",10);
fhem "set Oregon_Sensor_1_flur datapoint 1.SET_HUMIDITY $humidity comma C off on off"";}: Can't find string terminator '"' anywhere before EOF at (eval 101) line 3.
2018.02.22 21:20:43 3: nOregon_Sensor_1_flur_luft return value: Can't find string terminator '"' anywhere before EOF at (eval 101) line 3.
Get deviceinfo sieht gut aus.
Warum hast du im notify den fhem() Call nicht so angegeben, wie ich es in meinem vorherigen Post vorgeschlagen habe? So wie es jetzt ist, kann es nicht funktionieren, da du zu viele doppelte Anführungszeichen drin hast. Das meckert fhem auch an.
Du kannst auch mal versuchen, den ,, set datapoint" Befehl direkt abzusetzen. Nur um sicher zu gehen, dass zumindest das richtig funktioniert:
set xyz datapoint 1.SET_TEMPERATURE ,,20 comma C off on off"
Moin,
also beim absetzten des befehls "set xyz datapoint 1.SET_TEMPERATURE ,,20 comma C off on off"
kommt
HMCCUDEV: Oregon_Sensor_1_flur Invalid datapoint
beim einfügen dieses define nOregon_Sensor_1_flur notify Oregon_Sensor_1_flur|THGR228N_b3_4:temperature:.* {\
my $temperature = ReadingsNum("THGR228N_b3_4","temperature",10);;\
fhem "set Oregon_Sensor_1_flur datapoint 1.SET_TEMPERATURE '$temperature comma C off on off'";;}
kommt auch nix an.
auch bei
define nOregon_Sensor_1_flur notify Oregon_Sensor_1_flur|THGR228N_b3_4:temperature:.* {\
my $temperature = ReadingsNum("THGR228N_b3_4","temperature",10);;\
fhem "set Oregon_Sensor_1_flur datapoint 1.SET_TEMPERATURE \"$temperature comma C off on off\"";;}
kommt nix.
Komisch finde ich auch das bei HMCCU der Status auf inactive/ OK steht.
LG
gentoo79
Ich versuche, das mal bei einem CUxD Device nachzustellen. Das Problem könnte sein, dass der Datenpunkt SET_TEMPERATURE vom Typ Float ist, du aber einen String übergibst.
Ist denn die neue HMCCU soviel anders, als die alter Version ?.
Denn mit dem vorigen hat es super geklappt alles.
LG
gentoo79
Set datapoint ist anders.
Aber ich kapier immer noch nicht, wie du einen Text in einen nummerischen Datenpunkt in der CCU schreiben willst. Und dann auch noch in SET_TEMPERATURE, das write only ist. Das kannst du nicht mal in der CCU auslesen
Zitat von: zap am 24 Februar 2018, 17:20:19
Set datapoint ist anders.
Aber ich kapier immer noch nicht, wie du einen Text in einen nummerischen Datenpunkt in der CCU schreiben willst. Und dann auch noch in SET_TEMPERATURE, das write only ist. Das kannst du nicht mal in der CCU auslesen
Ich will ja keinen Text Schreiben sondern einfach die Temperaturen ( Grad Celsius ) von meinen Oregon Sensoren die über fhem laufen in die ccu (90) Wrapper Device schreiben. So als wenn ich einen homematic Temperatursensor habe.
Gesendet von iPhone mit Tapatalk
Den Use Case kann ich nachvollziehen, den Weg dahin nicht. Warum
set datapoint 1.SET_TEMPERATURE "$temperature comma C off on off"
und nicht
set datapoint 1.SET_TEMPERATURE $temperature
Wozu "comma C off on off"? Den Teil kann man in einem numerischen Datenpunkt nicht ablegen. Vielleicht ist das die neue Version auch etwas genauer.
UPDATE:
Ich habe das bei mir jetzt mal getestet mit einem solchen CUxD Device:
set mydev datapoint 1.SET_TEMPERATURE 23.0
führt dazu, dass sofort der Datenpunkt 1.TEMPERATURE auf 23.0 gesetzt wird. Also funktioniert alles wie erwartet.
ACHTUNG! Wichtig ist, dass in den Geräteeinstellungen des Wrapper Device in der CCU der Haken bei HMAdapt weg ist, sonst kann kein Datenpunkt manuell gesetzt werden.
Hallo zap,
ich habe sporadisch, seit einiger Zeit Probleme mit Befehlen zu einigen HmIP Geräten. Ich verwende eine CCU2 (neueste Firmware, ohne eigene Programme) als Kommunikationsweg CCU2 zu Fhem verwende ich HMCCURPCPROC Fhem neuester Stand.
Im Log stehen häufig folgende Fehler (Befehle werden von einem doif gesendet):
2018.02.25 08:25:46 1: HMCCUDEV: HM_OG_RT1_Schlafzimmer Execution of CCU script or command failed
2018.02.25 08:25:46 3: set HM_OG_RT1_Schlafzimmer datapoint 1.SET_POINT_TEMPERATURE 17.0 : HMCCUDEV: HM_OG_RT1_Schlafzimmer Execution of CCU script or command failed
2018.02.25 08:25:46 2: di_Schlafzimmer_Lueften_Heizung_normal: { {if (ReadingsVal("HM_OG_RT1_Schlafzimmer","1.ACTIVE_PROFILE",0) == 2) {fhem("set HM_OG_RT1_Schlafzimmer datapoint 1.SET_POINT_TEMPERATURE 17.0")} } }: HMCCUDEV: HM_OG_RT1_Schlafzimmer Execution of CCU script or command failed
Setze ich den gleichen Befehl "set HM_OG_RT1_Schlafzimmer datapoint 1.SET_POINT_TEMPERATURE 17.0" über die Fhem Eingabezeile ab, wird dieser teilweise mit Fehler quittiert oder einfach angenommen und ausgeführt.
Als Fehler taucht dann folgendes im Log auf, wird der Befehl ausgeführt, steht natürlich nichts im Log:
2018.02.25 10:07:08 1: HMCCUDEV: HM_OG_RT1_Schlafzimmer Execution of CCU script or command failed
Hast du oder habt ihr für mich einige Tipps, in welche Richtung ich da den Fehler suchen kann?
Kann das ein Zeitproblem sein, weil Fhem oder die CCU2 anderweitig beschäftigt ist, da es sporadisch funktioniert?
Komisch ist nur, dass es manchmal funktioniert und manches Mal wieder nicht.
Gerne liefere ich noch weitere Infos nach, will aber nicht das gesamte Forum mit Anhängen zumüllen.
Gruß Reinhard
Setze mal bitte folgendes Attribut:
attr HM_OG_RT1_Schlafzimmer ccuflags trace
Das solltest Du dann so lange eingeschaltet werden, bis der Fehler auftritt. Dann hätte ich gerne die entsprechenden Einträge im FHEM-Log.
Aber Achtung! Das Tracing wird ziemlich viele Logeinträge generieren. Verbose muss >= 2 sein.
Hallo Zap,
der Befehl "get CCU firmware" liefert derzeit nicht den aktuellen Stand.
Beispiel: HmIP-WTH2
Auf dem EQ3-Server liegt die 1.8.0, über den Befehl bekomme ich die 1.4.4 angeboten. Siehe Screenshot.
Hat EQ3 da etwas verändert?
Viele Grüße
Christian
vermutlich. Leider gibt es keine offizielle API für die Abfrage. Wenn EQ3 die Webseite ändert, muss ich das in HMCCU auch anpassen.
@Rewe2000
Bin scheinbar ebenfalls von deinem / dem Problem betroffen. HMCCUDEV: <HMIP-Device> Execution of CCU script or command failed
Aktuell im Aktueller Status nur nach get Update-Thread am Schreiben mit zap darüber...
Hallo,
@Xervek, das scheint in der Tat etwas ähnliches wie bei mir zu sein, mit der einzigen Ausnahme, bei mir kommt dies absolut selten, ist aber dennoch nicht OK.
@zap, leider konnte ich heute den Fehler mit trace nicht "erwischen", bleibe aber dran.
Einige Punkte sind mir aber aufgefallen, welche ich mal hier in die Runde werfen will.
- Ich beobachte diese Fehler nur, wenn längere Zeit nichts zu den Devices gesendet wird. Versuche ich den Fehler "auf biegen und brechen" zu provozieren gelingt mir dies (bisher) nicht.
- Den Fehler beobachte ich auch häufiger an einem HM-Dis-EP-WM55 Homematic (ohne IP) E-Paper Display und an 2 HmIP-WTH-2 Wandthermostaten.
Einige Fragen/Überlegungen hierzu:
- Kann es etwas damit zu tun haben, wenn auf ein Device, zur gleichen Zeit (von verschiedenen anderen Devices, über Direktverknüpfungen) und der CCU2 unterschiedliche Befehle gesendet werden? Ich habe meine HmIP-WTH-2 (Wandthermostate) mit den HmIP-eTRV (Heizkörperthermostaten) und HMIP-SWDO (Fensterkontakten) direkt verknüpft, und die Fenster - Auf Temperatur liegt bei 5.0°C.
- In diesem Zusammenhang fällt mir derzeit ein anderes seltsames Verhalten auf, glaube aber nicht, dass es etwas mit dem ursprünglichen Problem zu tun hat. Bei einem Fensterkontakt blinkt teilweise die LED sporadisch bis zu 30x bevor diese mit grün beendet. Häufig passt der Fensterzustand im Heizkörper und Wandthermostat, aber in der CCU2 ist das Fenster noch geöffnet obwohl es aktuell geschlossen ist. Bei einem bestätigten Funk-Tranfer sollte meines Erachtens dies nicht vorkommen, oder es müsste zumindest ein Fehler in der CCU2 angezeigt werden.
- Da es ja unterschiedliche HM und HmIP Geräte betrifft, kann es ja nicht an der neuen Firmware (Vers. 1.8) in den HmIP-WTH-2 Wandthermostaten liegen, welche ich erst vor einigen Tagen installiert habe.
Gruß Reinhard
Es scheinen Timing-Probleme zu sein. Wird der Befehl auch bei einer Fehlermeldung trotzdem ausgeführt, ggf. verzögert?
Hintergrund: HMCCU schickt den Befehl per FHEM Funktion GetFileFromURL() an die CCU. Diese Funktion hat einen Timeout von 4 Sekunden, was genau zu dem Effekt passt, den Xervek festgestellt hat.
Ich könnte den Timeout höher setzen oder konfigurierbar machen. Das löst aber das Problem nicht. Schließlich möchte man nicht 4 Sekunden oder länger auf die Ausführung eines Befehls warten.
Ich kann dir momentan auch nur den Tipp geben, die CCU mal durchzustarten.
Du könntest auch probehalber für eines der Devices das Attribut ccuget auf "Value" setzen. Hintergrund: Damit wartet die CCU nicht, bis ein Wert wirklich beim Device angekommen ist. Das könnte verhindern, dass sich Set Befehle von Direktverknüpfungen mit manuell abgesetzten in die Quere kommen.
@Rewe2000
Das mit dem "längere Zeit nichts gesendet" hatte ich zunächst auch in Vermutung, scheint sich bei mir aber nicht zu bewahrheiten. Bei mir lässt sich das Problem am Thermostat offenbar mit kurzem Testen reproduzieren indem ich immer wieder die Temperatur ändere. Oftmals geht es problemlos, vereinzelt dauert es dann länger, der Fehler kommt ehe es weiter geht.
Mein Thermostat ist lediglich mit einem Türkontakt verbunden der aber offenbar zum Fehlerzeitpunkt keine Aktualisierung durchführt und auch nicht manuell "bedient" wird.
@zap
Habe das mit dem "ccuget auf Value" mal schnell mit meinem Thermostat versucht, ohne Erfolg. Der Fehler tritt weiterhin unverändert auf.
Wie im anderen Thread geschrieben hat es bei mir nicht geholfen die CCU2 und FHEM neu zu starten. Wir können das Ganze der Übersicht halber auch gerne zusammenführen und das hier im Thread besprechen / schreiben.
Könnte auch sein, dass das Sendelimit für das 868 MHZ Band für das Gerät bei zu häufigem Senden überschritten wird.
Danke für den Hinweis, das ist mir bewusst. In den Fällen aktuell aber noch nicht eingetreten. Normalerweise ändere ich eher wenig bis sehr wenig und nur aktuell so viel zum Testen. Das Limit wurde aktuell scheinbar noch nicht überschritten da die letzte Änderung der Temperatur auf den Ursprungswert noch akzeptiert und sauber eingestellt wurde.
Laut dem trace von nach dem Neustart ist es ja leider weiterhin das Problem mit dem Timeout... und im schlimmsten Fall ändere ich die Temperatur für eine Stunde manuell am Thermostat ;D
Da fällt mir nur noch ein, von GetFileFromURL() auf NonblockingGet() umzustellen. Das wird aber nicht so einfach und der Effekt wird nicht für jeden User logisch erscheinen. Muss ich mal drüber nachdenken ....
Hallo,
@zap:
ZitatEs scheinen Timing-Probleme zu sein. Wird der Befehl auch bei einer Fehlermeldung trotzdem ausgeführt, ggf. verzögert?
Bei mir wurde der Befehl (nach der Fehlermeldung in Fhem am 25.02.) definitiv
nicht an das Wandthermostat weitergegeben. Da ich die 1.SET_POINT_TEMPERATURE im Chart habe, kann ich dies noch genau sehen.
Habe eben nochmals versucht, die Fehler mit trace zu provozieren, derzeit keine Change, bleibe aber dran.
Gruß Reinhard
@Rewe2000
Du schreibst weiter oben, dass Du Thermostat, Fenstersensor und Wandthermostat verknüpft hast. Wie hast Du das gemacht, über eine virtuelle Gruppe in der CCU oder in Handarbeit? Ich weiß nicht, ob die CCU virtuelle Gruppen mit HmIP Devices unterstützt. Aber wenn sie es tut, solltest Du das auch so verknüpfen. Dann bindest du das virtuelle Gruppendevice in FHEM ein und setzt die Datenpunkte im virtuellen Gruppendevice und NICHT direkt am Wand- oder Heizkörperthermostat!
Es gibt also aktuell keine möglichen Ansätze (neben dem Umbau von von GetFileFromURL() auf NonblockingGet()) mehr das Problem zu beheben? Ist denn abzusehen, dass es mit NonblockingGet() nicht mehr auftreten wird?
In dem Fall würde ich dich dann darum bitten, den Timeout bis dahin eventuell höher zu setzen und / oder konfigurierbar zu machen, wie du es angesprochen hast. So wie ich das sehe müssen wir ja ohnehin > 4 Sekunden warten ehe die Befehle im Timeout-Fall korrekt verarbeitet werden und ansonsten geht das ja ohnehin weit schneller als 4 Sekunden. Aktuell umgehen wir mit einem Timeout > 4 Sekunden ja die ausgegebene Fehlermeldung / Weiterleitung / Blockierung von FHEM oder übersehe ich etwas?
Edit:
Ich habe übrigens meinen Türkontakt in der CCU2 unter "Startseite > Programme und Verknüpfungen > Direkte Verknüpfungen" miteinander verknüpft und keine virtuelle Gruppe erstellt, jedenfalls nicht, dass ich wüsste. Wobei das ja für mich, wenn ich recht informiert bin ohnehin nicht notwendig ist, da die virtuellen Gruppen für HomeMatic gedacht sind...
Zitat von: Xervek am 27 Februar 2018, 11:02:28
Es gibt also aktuell keine möglichen Ansätze (neben dem Umbau von von GetFileFromURL() auf NonblockingGet()) mehr das Problem zu beheben? Ist denn abzusehen, dass es mit NonblockingGet() nicht mehr auftreten wird?
Wenn die Anfrage an die CCU tatsächlich in den 4 Sekunden Timeout läuft, dürfte NonblockingGet() zumindest die Fehlermeldung verhindern. Das Schalten an sich wird dadurch natürlich nicht beschleunigt.
Zitat
In dem Fall würde ich dich dann darum bitten, den Timeout bis dahin eventuell höher zu setzen und / oder konfigurierbar zu machen, wie du es angesprochen hast. So wie ich das sehe müssen wir ja ohnehin > 4 Sekunden warten ehe die Befehle im Timeout-Fall korrekt verarbeitet werden und ansonsten geht das ja ohnehin weit schneller als 4 Sekunden. Aktuell umgehen wir mit einem Timeout > 4 Sekunden ja die ausgegebene Fehlermeldung / Weiterleitung / Blockierung von FHEM oder übersehe ich etwas?
Ja, aber: FHEM blockiert natürlich so lange, bis der Timeout abgelaufen ist.
Danke für die Aufklärung und deine Bemühungen, dann habe ich es nun hoffentlich verstanden. Das ist ja echt übel, gerade weil es vollkommen unberechenbar passiert. Heute Nacht erneut zum Schlafen gehen einfach mit
2018.02.27 00:40:34 1: HMCCUDEV: HMIP_Radiator_Thermostat_Livingroom Execution of CCU script or command failed
2018.02.27 00:40:34 3: set HMIP_Radiator_Thermostat_Livingroom control 17.0 : HMCCUDEV: HMIP_Radiator_Thermostat_Livingroom Execution of CCU script or command failed
aus heiterem Himmel ausgelöst.
Wenn du etwas brauchst oder ich irgendwie noch weiter helfen kann, lass es mich bitte einfach wissen.
Mein Problem bei der Sache ist, dass Du und Rewe2000 bisher die einzigen seid, die diesen Fehler haben.
Vielleicht tritt der Fehler auch nur auf der Software-CCU auf, und die alte CCU ist davon nicht betroffen. Vielleicht tritt es auch nur bei HmIP auf. Alles nur Vermutungen.
Ich habe fast 80 HM-Devices in FHEM definiert. Ich habe die Logs seit 1.1.2018 durchsucht. Ich hatte den Fehler in dieser Zeit nicht.
Hallo,
@zap
Ich habe die HmIP Geräte als Direktverknüpfungen direkt in der CCU2 (keine Software) angelegt, denn ich will bei komplettem Ausfall der Software (Raspi, Fhem oder CCU2 selbst) meine Raumheizung zumindest noch (normal) bedienen können.
anbei ein Bild der CCU2 Direktverknüpfungen:
Ich triggere mein doif mit öffnen oder schließen des Fensters, aber zur gleichen Zeit jagt ja auch noch der Fensterkontakt (vermutlich intern) an den gleichen Datenpunkt vom Wandthermostaten auch noch die Temperatur, welche vorher eingestellt war. Beim öffnen der Fenster stelle ich immer 5°C ein.
Was passiert eigentlich in der CCU2, wenn zur gleichen Zeit (von unterschiedlichen Stellen) der gleiche Datenpunkt "1.SET_POINT_TEMPERATURE" beschrieben wird?
Wird das sequentiell nach Reihenfolge des Eingangs abgearbeitet, oder bleibt der schwächste oder langsamste Sender auf der Strecke.
Wenn du etwas davon hältst, könnte ich den set Befehl an die CCU2 um einige Sekunden im doif verzögern, um die gleichzeitigen Sendungen auf den gleichen Datenpunkt auszuschließen.
Ich habe den Fehler wirklich nicht häufig, ca. 15 Mal seit 1. Januar, bei 3 unterschiedlichen HM und HmIP Geräten. Was mir noch auffällt, Zeitgleich kommt immer ein Perfmon-Hänger mit, Dauer ca. 3-5 Sekunden (bei mir) mit.
2018.01.22 20:13:02 1: HMCCUDEV: HM_OG_RT1_Schlafzimmer Execution of CCU script or command failed
2018.01.22 20:13:02 1: Perfmon: possible freeze starting at 20:12:59, delay is 3.141
@Xervek
Hast du Perfmon oder etwas ähnliches bei dir auf dem System, um "Hänger" zu erkennen, nicht dass diese die Fehler erst verursachen.
Gruß Reinhard
Eine virtuelle Gruppe macht erst mal auch nichts anderes, als eine direkte Verknüpfung zwischen den Geräten herzustellen. Der Vorteil ist: du brauchst kein Doif. Das Absenken der Temp passiert automatisch, wenn der Sensor Fenster auf meldet.
Ich glaube, es sind 2 unterschiedliche Probleme. Bei dir kommen sich vermutlich zwei set Befehle ins Gehege. Bei xervek ist die CCU mit irgendwas beschäftigt und daher läuft das Set in einen Timeout.
@zap
Das ist alles auch gar nicht wild und verständlich. Ich wollte nicht wirken als sollte jetzt alles umgebaut werden wegen dem Fehler um ihn zu eliminieren. Irgendwie habe ich den Wald aber auch vor lauter Bäumen nicht mehr gesehen, was den Puls beschleunigt hat, ... Ich habe eines meiner beiden Probleme mittlerweile aber gelöst was den Fehler betrifft. Es bleibt bei mir aktuell weiterhin nur die Weiterleitung wenn der Fehler auftritt, die vor dem Update auf 4.2 nicht stattgefunden hat... Ich wollte lediglich sagen, dass ich etwas verwirrt bin durch die Unberechenbarkeit die das Handhaben erschwert...
@Rewe2000
Ich habe bisher quasi ein nacktes RaspMatic (genau: 2.29.23.20171216) ohne Plugins und FHEM auf der anderen Seite, ohne eigene Überwachung der Auslastung. Ich bin ehrlich: Ich befinde mich aktuell noch immer in der Einfindungsphase, dem Durcharbeiten des "Erste Schritte" PDF und habe unter anderem deshalb so lange gebraucht mich hier zu melden und das Problem anzusprechen, einfach um eigene möglicherweise offensichtliche Fehler ausschließen zu können.
@zap zum Zweiten
Ich wüsste nicht womit sie beschäftigt sein könnte... Ich habe lediglich 3 HomeMatic IP und 1 HomeMatic Türkontakt(e), eine HomeMatic IP Schaltsteckdose und mein HomeMatic IP Heizkörperthermostat Thermostat. RaspMatic ist nackt, ohne Plugins, ohne sonstige großen Änderungen am System. Alles was ich wirklich "anfasse" läuft über FHEM. Die "messages" der CCU2 sind wie im anderen Thread geschrieben leider ebenfalls leer und zeigen keinen Fehler an...
Hallo Xervek,
dann guck dir doch mal Perfmon https://wiki.fhem.de/wiki/Perfmon (https://wiki.fhem.de/wiki/Perfmon) an ob das nicht etwas für dich sein könnte. Du brauchst es nicht unter Fhem installieren, wenn es im Verzeichnis der Module ist, so tut es zuverlässig seinen Dienst, wenn du es nicht mehr brauchst, so löscht du es einfach wieder, nach einem shutdown restart ist es vom System verschwunden.
Es schreibt zuverlässig "Hänger" ab 1 Sekunde ins Log und du bist in jeden Fall im Bild, wenn's irgend wo klemmt.
Zitat... Ich habe eines meiner beiden Probleme mittlerweile aber gelöst was den Fehler betrifft.
An was war es denn bei dir gelegen?
Gruß Reinhard
HMCCU liegt nun in der Version 4.2.003 im SVN.
Bugfixes:
- Ersetzung von Datenpunkt-Variablen in einigen Befehlen / Attributen funktionierte nicht richtig
- Das Attribut 'peer' in Devices vom Typ HMCCUCHN und HMCCUDEV sollte nun korrekt funktionieren
Neu:
- Mit dem neuen Attribut ccuReqTimeout kann der Timeout für CCU HTTP Requests festgelegt werden. Default ist 4 Sekunden. Dieser Wert wirkt sich auf die Befehle "set datapoint", "set var", "get datapoint" und "get var" aus. Achtung! Wenn der Timeout greift, blockiert FHEM während dieser Zeit.
Ich werde zeitnah im Wiki ein Beispiel für die sinnvolle Nutzung von 'peer' beschreiben (Steuerung eines Somfy-Rollladens in FHEM aus der CCU heraus mit Hilfe eines CUxD Wrapper Device).
Hallo zap,
Danke für deine Mühe, das hast du ja schnell umgesetzt.
Ich werde die neue Version bei mir testen und gebe dir Bescheid wenn etwas nicht läuft (wie immer).
Habe eben die Version 4.2.003 installiert, sieht bisher sehr gut aus.
Bei mir ist der Fehler nun seit einigen Tagen nicht mehr aufgetreten, deshalb werde ich die Standardeinstellung für ccuReqTimeout erstmal so lassen.
Auf dein Beispiel im Wiki zu peer bin ich gespannt, bisher habe ich alle Direktverknüpfungen immer in der CCU2 programmiert.
Noch eine Frage an Dich:
Ist es möglich mit Fhem gepeerte Kanäle von Devices, in Fhem protokollieren (Verbose X, trace) zu lassen. Oder sieht man hier genau soviel als wenn diese mit der CCU2 gepeert werden, nämlich nichts, da die Kommunikation ja direkt von Device zu Device geht.
Gruß Reinhard
Zitat von: Rewe2000 am 01 März 2018, 18:10:04
Auf dein Beispiel im Wiki zu peer bin ich gespannt, bisher habe ich alle Direktverknüpfungen immer in der CCU2 programmiert.
Das solltest Du auch weiter so machen für Homematic Komponenten. Das geht zwar auch mit dem Attribut "peer", jedoch ist die CCU interne Variante deutlich schneller. Das Attribut "peer" ist eher dafür gedacht, in FHEM Homematic Devices mit Nicht-Homematic Devices zu verknüpfen. Also quasi eine Art Abkürzung bzw. Ersatz für Notify und DOIF.
Zitat
Noch eine Frage an Dich:
Ist es möglich mit Fhem gepeerte Kanäle von Devices, in Fhem protokollieren (Verbose X, trace) zu lassen. Oder sieht man hier genau soviel als wenn diese mit der CCU2 gepeert werden, nämlich nichts, da die Kommunikation ja direkt von Device zu Device geht.
Mit ccuflags = trace und verbose >= 2 sollten bei Devices mit Attribut peer einige Meldungen ausgegeben werden, wenn das Peering greift.
@Rewe2000
Danke für den Link, ich werde mir das die Tage mal anschauen und gucken ob es eventuell auch bei mir irgendwo hängt.
Was das Beheben eines meiner beiden Probleme betrifft, entschuldige, ich habe mich missverständlich ausgedrückt. Ein Problem ist, dass offenbar was die CCU2 betrifft, FHEM nahezu vollständig bei mir blockiert wenn es einen Timeout gibt. Das bedeutet, dass das Abschicken eines Befehls, beispielsweise die Temperaturänderung, gefolgt von einem update auf einen Datapoint keine geänderte Rückgabe bringt, egal wie lange ich warte. Gibt es jedoch keinen Timeout, funktioniert das direkt folgende Update sauber. Das hat mir massiv kopfzerbrechen bereitet, bis ich es in ein separates notify ausgelagert habe.
Ich habe leider weiterhin die Timeouts zu unmöglichen Zeiten und in unmöglichen Situationen, aber einen Weg gefunden, damit umgehen zu können.
@zap
Vielen Dank für die extrem schnelle Umsetzung! Ich werde das Update im Laufe des Tages installieren und mich in den kommenden Tagen wieder melden. Ich werde testhalber so weit den Timeout erhöhen bis der Fehler nicht mehr auftritt, zumindest kenne ich dann die Dimensionen von denen wir hier schreiben.
hallo,
habe hmccu neu eingerichtet
ich habe unter d_ccu mehre readings
Anwesenheit true 2018-03-06 15:06:21
luftfeuchte_max_gestern 83.000000 2018-03-06 15:06:21
luftfeuchte_max_heute 93.000000 2018-03-06 15:06:21
luftfeuchte_min_gestern 53.000000 2018-03-06 15:06:21
luftfeuchte_min_heute 62.000000 2018-03-06 15:06:21
regen_gestern 2.360000 2018-03-06 15:06:21
regen_heute 0.000000 2018-03-06 15:06:21
rpcstate running 2018-03-07 17:21:56
sonnenminuten_heute168.000000 2018-03-06 15:06:21
sonnenstunden_gestern 0.750000 2018-03-06 15:06:21
sonnenstunden_heute 2.800000 2018-03-06 15:06:21
state OK 2018-03-07 17:21:56
temp_max_gestern 11.300000 2018-03-06 15:06:21
temp_max_heute 5.8000002018-03-06 15:06:21
temp_min_gestern -6.400000 2018-03-06 15:06:21
temp_min_heute -4.900000 2018-03-06 15:06:21
wind_max_gestern 12.100000 2018-03-06 15:06:21
wind_max_heute 6.100000 2018-03-06 15:06:21
die werte ändern sich nicht ausser rpcstate und state
hm kompunenten laufen wunderbar.
woran kann das liegen?
fini
Ich nehme an, die Readings entsprechen Systemvariablen in der CCU. Die hast Du mal mit "get vars" abgeholt. Leider bietet die CCU keine automatische Aktualisierung für Systemvariablen an. Das gibt es nur für Geräte. Du musst also ein AT Device anlegen und die Variablen regelmäßig mit "get vars" abholen, wenn Du das synchron haben willst.
ok, danke.
so geht es:
define d_ccu_vars at *23:59:00 get d_ccu vars regen_gestern|luftfeuchte_max_gestern|luftfeuchte_min_gestern|sonnenstunden_gestern|temp_max_gestern|temp_min_gestern|wind_max_gestern
Hallo Zap,
das Suchen nach neuer Firmware erzeugt aktuell einige Logeinträge:
2018.03.11 11:19:16 1: PERL WARNING: Use of uninitialized value $rest in pattern match (m//) at ./FHEM/88_HMCCU.pm line 3568.
2018.03.11 11:19:16 1: PERL WARNING: Use of uninitialized value $fw in substitution (s///) at ./FHEM/88_HMCCU.pm line 3576.
2018.03.11 11:19:16 1: PERL WARNING: Use of uninitialized value $fw in substitution (s///) at ./FHEM/88_HMCCU.pm line 3577.
Das Ergebnis ist ebenfalls immer noch fehlerhaft.
Viele Grüße
Christian
Hätte mich auch gewundert, habe nämlich noch nichts daran geändert ;)
Aber Spaß beiseite, ich habe es auf der Todo-Liste. Bin nur noch nicht dazu gekommen ...
Ab morgen gibt es ein kleines Update im SVN:
Neues Flag "nonBlocking" im Attribut ccuflags im I/O Device. Wenn dieses Flag gesetzt ist, wird der Befehl "set datapoint" bei Devices vom Typ HMCCUCHN und HMCCUDEV asynchron ausgeführt, d.h. FHEM blockiert während dieser Zeit nicht.
Wer Probleme mit Timeouts beim Befehl "set datapoint" hat (Befehl wird einfach nicht ausgeführt), sollte dieses Flag setzen und zusätzlich das Attribut ccuReqTimeout auf einen Wert >4 (Default) setzen.
Außerdem sollte der Befehl get firmware wieder funktionieren. Der Befehl kann nun optional mit einem Gerätetyp als Parameter aufgerufen werden. Eine weitere mögliche Option ist "full". Dann werden alle verfügbaren Firmware Versionen angezeigt, unabhängig davon, ob ein entsprechendes Device in FHEM existiert.
Mit der Option "full" sieht die Ausgabe zB so aus (abgeschnitten):
Found 45 firmware downloads. Click on the new version number for download
Type Available Date
-----------------------------------------
HMIP-MIOB 1.6.000 22.02.2017
HMIP-SPI 1.2.4 06.10.2017
HMIP-PDT-UK 1.4.8 04.08.2017
HM-CC-RT-DN 1.4.001 20.10.2014
HMIP-PSM 2.6.2 04.05.2017
HMIP-FDT 1.4.8 25.07.2017
Hallo Zap,
habe eben mal upgedatet.
Die neue Non-Blocking-Funktion funktioniert prima.
Ich hatte ab und an mal TimeOuts im Log, wobei die Kommandos immer ausgelöst wurden.
Das ist nun weg, ich muss dazu aber den ccuReqTimeout auf 8 setzen.
Auch die Firmwareupdates werden wieder sauber angezeigt - da wartet Arbeit auf mich. ;-)
Einzig die Devicefunktion funktionert nicht bzw es wird zu viel angezeigt.
get CCU firmware HMIP-WTH-2
Der Output zeigt aber alle meine Devices.
Danke für die neue Version!
Viele Grüße
Christian
Timeouts im Log? Wie sahen die Meldungen genau aus? Bei Request Timeouts kamen nie Meldungen. Der Befehl wurde einfach nicht ausgeführt. Das Attribut ccuReqTimeout funktioniert auch ohne nonBlocking. Nur blockiert FHEM dann ggf. 8 Sekunden.
Hi,
so ist das bei 4:
2018.03.28 21:24:58 2: HMCCUDEV: [HM_Thermostat_Benni] Error during CCU request. read from http://192.168.100.65:8181 timed out
VG
Christian
Wird Zeit, dass die CCU3 kommt. Wegen Performance und so ...
Hi Zap,
heute ist im Log folgender Eintrag erfolgt:
2018.03.30 16:15:49 1: PERL WARNING: Use of uninitialized value $host in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 5283.
2018.03.30 16:15:49 2: HMCCU: HMScript failed. 500 No Host option provided
Muss ich noch etwas anpassen?
VG
Christian
oh! Nach welcher Aktion kommt die Meldung?
nach einem Stop und Start des Services:
2018.03.30 16:15:33 2: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server process started for interface HmIP-RF with PID=26152
2018.03.30 16:15:33 2: CCURPC: [d_rpcHmIP_RF] Initializing RPC server CB2010 for interface HmIP-RF
2018.03.30 16:15:33 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server starting
2018.03.30 16:15:34 2: HMCCURPCPROC: [d_rpcHmIP_RF] Callback server CB2010 created. Listening on port 7420
2018.03.30 16:15:34 2: CCURPC: [d_rpcHmIP_RF] CB2010 accepting connections. PID=26152
2018.03.30 16:15:34 2: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server CB2010 enters server loop
2018.03.30 16:15:34 2: HMCCURPCPROC: [d_rpcHmIP_RF] Registering callback http://192.168.100.35:7420/fh2010 of type A with ID CB2010 at http://192.168.100.65:2010
2018.03.30 16:15:34 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server CB2010 running
2018.03.30 16:15:37 2: CCURPC: [d_rpcHmIP_RF] CB2010 NewDevice received 146 device and channel specifications
2018.03.30 16:15:49 1: PERL WARNING: Use of uninitialized value $host in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 5283.
2018.03.30 16:15:49 2: HMCCU: HMScript failed. 500 No Host option provided
auch habe ich alle paar Stunden diesen Eintrag:
2018.03.31 10:12:06 2: HMCCU: HMScript failed. 500 No Host option provided
Aktionen sind zu diesem Zeitpunkt nicht gelaufen.
Der Fehler ist schwer zu finden. Lässt Du regelmäßig / zeitgesteuert irgendwas ausführen (z.B. Variablen von der CCU abholen oder setzen oder auch Systemmeldungen der CCU bestätigen?
Ansonsten werde ich mal etwas Debug Code einbauen. Andere Möglichkeit sehe ich nicht, dem Phänomen auf die Spur zu kommen.
Überhaupt nix.
Update: Ich habe Fhem mal neu gestartet, seit dem habe ich keine Einträge mehr gehabt.
Ich hatte, als der Fehler anfing, den Service gestoppt und einige Firmwareupdates auf den HM-IP-Devices eingespielt, ab- und wieder neu angelernt. Und dann den Service neu gestartet. Kann der fehlende Host-Eintrag daher kommen? Ich werde das weiter beobachten....
VG
Christian
Hallo zap,
vielen lieben Dank für deine ganze Arbeit hier!
Ich konnte meine Fehlermeldungen mittlerweile scheinbar mit einem Timeout von 6 Sekunden in den Griff bekommen. Es wurde merklich weniger bei 5, mit 6 habe ich nun seit knapp zwei Wochen keinen Timeout mehr gesehen. Zusätzlich habe ich dann jetzt das "nonBlocking" gesetzt, mal schauen wie es damit dann jetzt weiter geht. So ist das alles schon mal sehr gut.
Vielen Dank noch einmal!
Liebe Grüße
Morgen steht die Version 4.2.005 von HMCCU per Update zur Verfügung.
Änderungen:
- Befehl "get firmware" geändert
- Der externe RPC Server HMCCURPCPROC unterstützt nun mehrere FHEM Instanzen, die sich mit der gleichen CCU verbinden
- Anzahl Events bei Verwendung des Attributs ccuaggregate reduziert
- Auf Homematic Script basierende Befehle (z.B. Setzen von Datenpunkten) optimiert
Hallo Zap,
eben mal upgedatet und soweit läuft es wie gewohnt.
Beim Start kommt allerdings ein Eintrag im Log:
...
2018.04.20 19:41:26 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/88_HMCCURPCPROC.pm line 1354.
2018.04.20 19:41:26 2: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server process started for interface HmIP-RF with PID=969
...
Viele Grüße
Christian
Hallo,
nach Umstellung habe ich im Log Seitenweise folgende Einträge:
2018.04.22 23:36:58 0: HMCCURPCPROC: [d_rpcHmIP_RF] Received SL event for unknown RPC server CB201006210
2018.04.22 23:36:58 0: HMCCURPCPROC: [d_rpcHmIP_RF] Received SL event for unknown RPC server CB201006210
2018.04.22 23:36:58 0: HMCCURPCPROC: [d_rpcHmIP_RF] Received SL event for unknown RPC server CB201006210
Kann jemand helfen?
Es laufen 3 Server:
HMCCURPCPROC
CCU RPC BidCos-RF running/OK
CCU RPC HmIP-RF running/OK
CCU RPC VirtualDevices running/OK
sonst irgendwelche Fehlermeldungen speziell beim Start der RPC Server? Kannst du mal die Logmeldungen posten, die während dem Start des RPC Servers geschrieben werden? dazu bei den RPC Devices und beim IO Device verbose mindestens auf 2 setzen.
Hallo ZAP,
hier der LOG-Auszug nach RPC-Serverstart:
2018.04.23 08:04:23 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server starting
2018.04.23 08:04:23 2: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server process started for interface HmIP-RF with PID=5835
2018.04.23 08:04:23 2: CCURPC: [d_rpcHmIP_RF] Initializing RPC server CB201006203 for interface HmIP-RF
2018.04.23 08:04:23 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server starting
2018.04.23 08:04:23 1: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server starting
2018.04.23 08:04:23 2: HMCCURPCPROC: [d_rpcHmIP_RF] Callback server CB201006203 created. Listening on port 7420
2018.04.23 08:04:23 2: CCURPC: [d_rpcHmIP_RF] CB201006203 accepting connections. PID=5835
2018.04.23 08:04:23 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB200106221 running
2018.04.23 08:04:23 2: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server CB201006203 enters server loop
2018.04.23 08:04:23 2: HMCCURPCPROC: [d_rpcHmIP_RF] Registering callback http://192.168.178.62:7420/fh2010 of type A with ID CB201006203 at http://192.168.178.78:2010
2018.04.23 08:04:23 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server CB201006203 running
2018.04.23 08:04:24 2: CCURPC: [d_rpcHmIP_RF] CB201006203 NewDevice received 74 device and channel specifications
2018.04.23 08:04:33 1: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server CB929206233 running
2018.04.23 08:04:33 1: HMCCU: [d_ccu] All RPC servers running
2018.04.23 08:04:34 2: HMCCU: [d_ccu] Updated devices. Success=11 Failed=0
2018.04.23 08:04:34 2: HMCCU: Duplicate name for device/channel HM-Thermostat-Kueche address=000A97099CEA34:1 in CCU.
2018.04.23 08:04:34 2: HMCCU: Duplicate name for device/channel HM-Thermostat-Kueche address=000A97099CEA34 in CCU.
Habe den Thermostat Küche in der CCU und Fhem entfernt und neu angelegt.
Diesen Fehler im Log bin ich los.
HMCCURPCPROC: [d_rpcHmIP_RF] Received SL event for unknown RPC server CB201006210
laufen weiter.
Ich vermute, dass da noch ein RPC Prozess im Hintergrund lief. Die IDs unterscheiden sich:
Beim Starten = CB201006203
Bei der Meldung = CB201006210
Im Zweifel mal FHEM stoppen, dann prüfen, ob noch weitere Prozesse mit Owner = fhem laufen und die manuell killen.
@Chris8888: Das Problem mit der Meldung bei Dir habe ich gefunden. Wird behoben.
Hallo Zap,
wie bei user weldel60, bekomme ich jetzt auch seit 2 Tagen folgende Fehlermeldungen zuhauf:
HMCCURPCPROC: [d_rpcHmIP_RF] Received SL event for unknown RPC server CB201001571
Bei mir läuft FHEM unter root.
Ich habe dann ein grep auf einen rpc process gemachtpi@jessie:/opt/fhem $ ps -auxw | grep rpc
root 40 0.0 0.0 0 0 ? I< Apr23 0:00 [rpciod]
pi 31801 0.0 0.0 4372 548 pts/0 S+ 19:32 0:00 grep --color=auto rpc
Ich kann den prozess aber gar nicht 'killen', bei 'sudo kill -9 40' passiert gar nichts.
Die Fehlermeldung bleibt. Was kann ich tun?
Bitte den Prozess nicht killen!! Das ist der Linux RPC Daemon. Der HMCCU RPC Server ist nichts anderes als ein fhem.pl Prozess.
Also
ps -ef | grep fhem
Die PID des Prozesses wird beim Starten in das FHEM Log geschrieben
Nochmals ein Auszug des Log.
Ist es nun der rpcBidCos 2001?
2018.04.24 10:55:47 1: HMCCU: Device d_ccu. Initialized version 4.2.005
2018.04.24 10:55:49 1: HMCCU: Read 12 devices with 123 channels from CCU 192.168.178.78
2018.04.24 10:55:49 1: HMCCU: Read 3 interfaces from CCU 192.168.178.78
2018.04.24 10:55:49 1: HMCCURPCPROC: [d_rpcBidCos_RF] Initialized version 1.0.003 for interface BidCos-RF
2018.04.24 10:55:49 1: HMCCURPCPROC: [d_rpcHmIP_RF] Initialized version 1.0.003 for interface HmIP-RF
2018.04.24 10:55:49 1: HMCCURPCPROC: [d_rpcVirtualDevices] Initialized version 1.0.003 for interface VirtualDevices
2018.04.24 10:55:49 1: Including ./log/fhem.save
2018.04.24 10:55:51 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2018.04.24 10:55:58 0: Featurelevel: 5.8
2018.04.24 10:55:58 0: Server started with 216 defined entities (fhem.pl:16609/2018-04-13 perl:5.024001 os:linux user:fhem pid:587)
2018.04.24 10:56:03 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/88_HMCCURPCPROC.pm line 1354.
2018.04.24 10:56:03 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server starting
2018.04.24 10:56:03 2: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server process started for interface HmIP-RF with PID=976
2018.04.24 10:56:03 2: CCURPC: [d_rpcHmIP_RF] Initializing RPC server CB201006223 for interface HmIP-RF
2018.04.24 10:56:03 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server starting
2018.04.24 10:56:03 1: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server starting
2018.04.24 10:56:03 2: HMCCURPCPROC: [d_rpcHmIP_RF] Callback server CB201006223 created. Listening on port 7420
2018.04.24 10:56:03 2: CCURPC: [d_rpcHmIP_RF] CB201006223 accepting connections. PID=976
2018.04.24 10:56:03 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB200106223 running
2018.04.24 10:56:03 2: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server CB201006223 enters server loop
2018.04.24 10:56:03 2: HMCCURPCPROC: [d_rpcHmIP_RF] Registering callback http://192.168.178.62:7420/fh2010 of type A with ID CB201006223 at http://192.168.178.78:2010
2018.04.24 10:56:03 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server CB201006223 running
2018.04.24 10:56:04 2: CCURPC: [d_rpcHmIP_RF] CB201006223 NewDevice received 74 device and channel specifications
2018.04.24 10:57:40 1: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server CB929206231 running
2018.04.24 10:57:40 4: HMCCU: [d_ccu] Set rpcstate to running
2018.04.24 10:57:40 1: HMCCU: [d_ccu] All RPC servers running
2018.04.24 10:57:47 2: HMCCU: [d_ccu] Updated devices. Success=11 Failed=0
2018.04.24 23:05:41 0: HMCCURPCPROC: [d_rpcBidCos_RF] Received SL event for unknown RPC server CB200106264
2018.04.24 23:05:41 0: HMCCURPCPROC: [d_rpcBidCos_RF] Received SL event for unknown RPC server CB200106264
2018.04.24 23:05:41 0: HMCCURPCPROC: [d_rpcBidCos_RF] Received SL event for unknown RPC server CB200106264
2018.04.24 23:12:29 0: HMCCURPCPROC: [d_rpcBidCos_RF] Received SL event for unknown RPC server CB200106264
2018.04.24 23:12:29 0: HMCCURPCPROC: [d_rpcBidCos_RF] Received SL event for unknown RPC server CB200106264
2018.04.24 23:12:29 0: HMCCURPCPROC: [d_rpcBidCos_RF] Received SL event for unknown RPC server CB200106264
2018.04.24 23:13:03 0: HMCCURPCPROC: [d_rpcBidCos_RF] Received SL event for unknown RPC server CB200106264
2018.04.24 23:13:03 0: HMCCURPCPROC: [d_rpcBidCos_RF] Received SL event for unknown RPC server CB200106264
2018.04.24 23:13:03 0: HMCCURPCPROC: [d_rpcBidCos_RF] Received SL event for unknown RPC server CB200106264
Ja scheint so. Kannst du mal bitte folgendes aus dem Log extrahieren:
grep CB200106264 logfile | grep -v Received
So.......
2018.04.24 10:50:47 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB200106264 running
2018.04.24 10:56:51 1: HMCCURPCPROC: [d_rpcBidCos_RF] Stopping RPC server CB200106264
2018.04.24 10:56:51 1: HMCCURPCPROC: [d_rpcBidCos_RF] Deregistering RPC server http://192.168.178.62:7411/fh2001 with ID CB200106264 at http://192.168.178.78:2001
2018.04.24 10:56:51 1: HMCCURPCPROC: [d_rpcBidCos_RF] Failed to deregister RPC server CB200106264
2018.04.24 10:56:51 1: CCURPC: [d_rpcBidCos_RF] RPC server CB200106264 stopped handling connections. PID=1107
2018.04.24 10:56:54 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server process CB200106264 not runnning
Hallo zusammen
Ich hatte auch die " Received SL event for unknown RPC server" Meldungen.
auch direkt nach kompletten Rechner reboot.
Ein Neustart der CCU war dann die Lösung.
Danach hatte ich keine Meldungen mehr
Gruss Brause
Hallo Brause,
das ist mir auch aufgefallen.
CCU - Neustart und dann RPI - Neustart, dann war erst mal Ruhe.
Einen halben Tag später, starteten die Fehlermeldungen jedoch wieder.
ich hatte die Reihenfolge andersrum.
-> FHEM-Rechner gestartet
-> FHEM lief mit Fehlermeldung
-> CCU neu gestartet
-> Fhem direkt ohne Fehlermeldungen ( seit nun mehr 2 Tagen )
Zitat von: weldel60 am 25 April 2018, 09:36:38
So.......
2018.04.24 10:50:47 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB200106264 running
2018.04.24 10:56:51 1: HMCCURPCPROC: [d_rpcBidCos_RF] Stopping RPC server CB200106264
2018.04.24 10:56:51 1: HMCCURPCPROC: [d_rpcBidCos_RF] Deregistering RPC server http://192.168.178.62:7411/fh2001 with ID CB200106264 at http://192.168.178.78:2001
2018.04.24 10:56:51 1: HMCCURPCPROC: [d_rpcBidCos_RF] Failed to deregister RPC server CB200106264
2018.04.24 10:56:51 1: CCURPC: [d_rpcBidCos_RF] RPC server CB200106264 stopped handling connections. PID=1107
2018.04.24 10:56:54 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server process CB200106264 not runnning
ok, alles klar. Seit der letzten Version verwendet HMCCURPCPROC Callback-IDs mit einem zufälligen Anteil (letzte beiden Ziffern). Wenn nun wie in Deinem Fall die Deregistrierung bei der CCU fehl schlägt, schickt die CCU weiterhin Events an FHEM. FHEM kann damit aber nichts mehr anfangen, da der RPC Server in der Zwischenzeit mit einer anderen ID gestartet wurde.
Vorher gab es dieses Problem nicht, weil bei einem Neustart des RPC Servers die gleiche ID verwendet wurde. Da kann man wieder einmal sehen, dass kleine Änderungen große Auswirkungen haben können.
Fix ist in Arbeit.
Die gerade eingecheckte Version beinhaltet Updates für 88_HMCCU und 88_HMCCURPCPROC. Folgende Änderungen gibt es:
- Zufälliger Anteil in RPC Callback ID wurde entfernt. Dadurch sollten Fehlermeldungen im FHEM-Log zu unbekannter RPC ID verschwinden.
- Deregistrierung des RPC Servers wird nun 2x versucht, bevor eine Fehlermeldung ausgegeben wird.
- Ermittlung der RPC Callback ID erfolgt nun in Define(). Dadurch werden PERL Warnings beim Starten vermieden.
- Fehler behoben, der den Start des RPC Servers verhinderte, wenn die CCU nicht gleichzeitig auch RPC Endpunkt war (z.B. bei HVL / Homematic Virtual Layer).
Morgen per Update verfügbar.
DANKE!
Moin zap,
ich bekomme bei get config diese Meldung, obwohl meine RaspiMatic CCU2 heißt.
HMCCUDEV: kf_Rauchmelder No response from CCU. CCU returned no data
Vielen Dank.
,,CCU" steht hier nicht für den Devicename sondern allgemein für die CCU.
Wenn get config keine Daten zurück gibt, kann es daran liegen, dass für das Gerät oder den Kanal keine Parameter verfügbar sind. Im Zweifel mal die einzelnen Kanäle durchprobieren, etwa so
get config 0
Get config 1
usw
Super, vielen Dank.
zap,
kann man ccu2_rpc löschen?
Vielen Dank.
Grüße Mave
kommt darauf an, ob es noch benutzt wird. Welcher FHEM Devtype ist das und welchen RPC Server verwendest du (ccuflags im IO Device)
Es stand nach dem automatischen Update auf inactive...
Wenn Du auf den neuen externen RPC Server vom Typ HMCCURPCPROC umgestellt hast, kannst Du das alte Device vom Typ HMCCURPC löschen.
Super, vielen Dank.
Hallo zusammen, ich habe noch ein Frage zum peeren. Gibt es auch eine Möglichkeit zwei Bedingungen, die beide erfüllt sein müssen unterzubringen, oder ist hierfür ein DOIF o.ä. notwendig?
Im Moment habe ich folgendes Peer-Attribut gesetzt:
1.PRESENCE_DETECTION_STATE:'$1.PRESENCE_DETECTION_STATE' eq 'yes':fhem:set BZ1.Lampe_Spiegel on-for-timer 60
Nun würde ich darin aber gerne noch die 1.ILLUMINATION abfragen, sodass diese einen bestimmten Wert unterschreitet. Erst wenn beide Werte erfüllt sind, soll der Befehl an FHEM abgesetzt werden.
Die Bedingung kann ein beliebiger Perl Ausdruck sein, d.h. Du kannst auch and und or verwenden. Versuch mal folgendes:
1.PRESENCE_DETECTION_STATE:'$1.PRESENCE_DETECTION_STATE' eq 'yes' and $1.ILLUMINATION < 100:fhem:set BZ1.Lampe_Spiegel on-for-timer 60
Statt 100 natürlich der gewünschte Wert.
Hi Denis,
nur als meine 2Cent-Gedanken: Ich steuere Licht niemals über FHEM...sowohl wegen Ausfall(Abhängigkeit desselben, als auch wegen der - wenn auch kurzen - Verzögerung.
Du kannst das gewünschte Ergebnis auch prima direkt in den Aktoren erzeugen - inkl Helligkeitsschwelle. Und alles komplett unabhängig.
Einzig müsstest du dazu einen HmIP-Lichtschalter haben...
Viele Grüße
Christian
Da kann ich chris nur zustimmen. Das peer Attribut ist eigentlich nur für Dinge gedacht, die sich mit Homematic Bordmitteln nicht lösen lassen. Ich ziehe direkte Verknüpfungen bzw. Konfigurationen in den Aktoren immer script oder FHEM basierten Lösungen vor. Dann funktioniert das Ganze auch noch, wenn CCU oder FHEM ausfallen.
Es gitb dazu einen passenden Biologischen Vergleich:
"Reflexe" werden nicht im Hirn verarbeitet
Nur Höhere Aufgaben werden dort verarbeitet
Also "Licht" an sollte immer von der Hardware direkt verarbeitet werden, d.h. Schalter -> Lampe.
Dagegen das "Einschalten Fernseher und automatisch Raum verdunkeln, Stimmungs Licht einschalten" ist eine Aufgabe von FHEM.
Ihr habt recht und mich überzeugt ;). Ich habe gerade einen HM-IP Lichtschalter bestellt und werde das verproben :).
@Chris8888 oder die anderen: Habt ihr ggf. ein paar Infos wie ich die beiden Komponenten am besten direkt miteinander verknüpfen kann? Ich weiß noch, dass das bei meinen nicht HM-IP Komponenten relativ komplex war.
Vielen Dank,
Dennis
Hi,
das ist nicht so schwer.
Die Tasten (1 &2) sind intern mit dem Kanal 4 (je nach Schalter) des Actors verknüpft.
Ich habe daher die "Treppenhauslicht"-Logik zwischen SPI und Schalter Kanal 5 verknüpft (im Anhang).
Zusätzlich habe ich Taster "aus" (1 oder 2) ebenfalls mit Kanal 5 als "aus" verküpft, um "Licht an" durch den SPI auch vorzeitig beenden zu können.
Damit komme ich wunderbar zurecht.
Viel Erfolg!
Viele Grüße
Christian
Hallo zap,
ich habe eben auf HMCCURPCPROC umgestellt und das Problem, dass das Attribut rpcServerAddr ignoriert wird.
Ich habe FHEM in einem Dockercontainer laufen.
Obwohl rpcServerAddr auf die Docker-Host-Adresse gesetzt ist, wird das Callback-Interface auf die Ip des Docker-Containers (localaddress) registriert und nicht auf der IP des Hosts. Da kommt die CCU so halt nicht ran.
Ich könnte jetzt im Router den Dockerhost als Gateway für das private Container-Netz definieren,
schöner wäre es, wenn rpcServerAddr funktionieren würde :)
Irgendeine Idee, woran es liegen könnte?
Viele Grüße
Jürgen
welchen RPC Server hast Du vorher verwendet, den internen oder den externen (HMCCURPC)?
Irgendwie scheine ich das im letzten Update ausgebaut zu haben. Keiner der RPC Server scheint das Attribut noch zu berücksichtigen. Muss ich mir anschauen.
Mit dem externen (HMCCURPC) hat es vorher funktioniert.
Da ich gerade meine Docker-Umgebung umbaue und den FHEM-Container ein paar mal neu gemacht habe,
bin ich aber gerade nicht sicher, welche Version da lief.
Als workaround bau ich halt solange ein Gateway mit entspr. Route in meinen Router ein :)
Ich beobachte dann hier im Thread, ob es neues dazu gibt.
Danke und Gruß
Jürgen
Eigentlich müsste das doch funktionieren. Es gibt 2 Möglichkeiten (unterschiedliche Schreibweise beachten):
1. Du definierst rpcserveraddr im I/O Device (das gilt dann für alle HMCCURPCPROC Devices ohne eigenes rpcServerAddr Attribut)
2. Du definierst rpcServerAddr im jeweiligen HMCCURPCPROC Device (ein Device je genutztes CCU Protokoll !)
Beim Start der RPC Server kannst Du mal auf folgende Meldungen im Log achten (verbose muss >= 2 sein):
"Registering callback ..."
Noch ein Hinweis: Der bzw. die RPC-Server müssen nach dem Setzen des Attributs neu gestartet werden. Am besten FHEM neu starten.
Bei mir nicht :(
In beiden Fällen steht im Log "Registering callback http://172.19.0.4:7411/fh2001"
und das ist die Container-IP im Docker-Netz und nicht die Host-IP
Was bei einem docker-Container insofern logisch ist, da er die Host-IP nicht sieht (sehen kann)
Muss ich mir nochmal anschauen. Normalerweise sollte die IP registiert werden, die in dem Attribut angegeben ist. Leider etwas schwierig zu testen. Muss erst mal auf meinem Raspi ein virtuelles Netzwerk Interface definieren.
Zitat von: Wernieman am 13 Juni 2018, 21:27:39
Was bei einem docker-Container insofern logisch ist, da er die Host-IP nicht sieht (sehen kann)
Deswegen gibt es ja die Möglichkeit, die IP mit rpcserveraddr bzw. rpcServerAddr zu überschreiben :)
Was aber halt nicht wie gedacht funktioniert.
Vielleicht habe ich am Wochenende auch nochmal Zeit, etwas länger zu testen.
Mit entspr. Gateway/route im Router funktioniert es ja auch erstmal so.
Viele Grüße
Jürgen
ok, nachvollziehbar. Bei mir wird das Attribut auch ignoriert. Ich kümmere mich ...
Bugfix für rpcServerAddr ist im SVN eingecheckt. Morgen per FHEM Update verfügbar.
Außerdem neu in dieser Version: v.a. bei HMIP Devices werden vermehrt Systemvariablen mit Kanälen verknüpft, um zB Counter zu speichern. Bisher war es in HMCCU nicht möglich, diese Variablen/Datenpunkte zu aktualisieren. Mit dieser Version ist eine Aktualisierung mit dem Befehl "get update" möglich.
Was nach wie vor nicht geht:
- Aktualisierung solcher Datenpunkte mit "get datapoint"
- Automatische Aktualisierung per RPC Server (die CCU schickt hier leider keine Infos)
Hallo,
ich habe eben mal todesmutig die neue Firmware der CCU2 eingespielt: 2.35.15
Völlig problemlos...HMCCU scheibt bisher auch einwandfrei zu funktionieren.
Wenn ich das ChangeLog richtig verstehe, so werden jetzt auch HmIP-Heizungsgruppen unterstützt.
Damit werde ich mich mal am Wochenende beschäftigen.
VG
Christian
Klingt gut. Möglicherweise wird dafür ein separater RPC Port verwendet. Aber probiere es einfach mal aus und berichte, ob die automatische Aktualisierung funktioniert.
Ergänzung: die neue Firmware unterstützt auch einige neue HMIP Geräte wie zB den kommenden Wassermelder, der im Gegensatz zum klobigen alten geradezu niedlich ist.
Hi,
ich habe mal eine Gruppe angelegt. Leider wird mein Fussbodenheizung (FAL230) nicht angezeigt, daher besteht die Gruppe nur aus dem Thermostat und dem Fensterkontakt.
Leider kann ich das virtuelle Device nicht anlegen: get devicelist create Gruppenname
Fehlermeldung: HMCCUDEV: No devices in group
Selbst auf Verbose 5 kommt nicht mehr.
Mache ich etwas bei der Anlage falsch? Ich habe mich noch nie mit Gruppen beschäftigt.
Viele Grüße
Christian
Das funktioniert nicht per get devicelist create, da ich es noch nicht geschafft habe, eine Gruppendefinition aus der CCU zu übernehmen.
Schau mal in die Commandref zu HMCCUDEV. Da gibt es bei define ein Beispiel. Du musst noch die Gruppenmitglieder explizit angeben. Das get devicelist (ohne create)vorher ist erforderlich, damit HMCCU das Gruppendevice lernt.
Dann zB
define myGroup HMCCUDEV myCCUGroup group=Fenster1,Thermo1,HKThermo1
Das mit der Fußbodenheizung ist ja blöd. Vielleicht wird das mit dem nächsten Update noch eingebaut. Ich finde die Gruppen sehr praktisch. Man spart sich bei vielen Geräten in einem Raum die Peering Orgie. In unserem größten Zimmer habe ich 3 Fenstersensoren, 1 Wandthermostat und 2 Heizkörperthermostate einfach in eine Gruppe gepackt und die CCu hat alle Verknüpfungen angelegt. Statt 6 Devices dann einfach nur das Gruppendevice in FHEM angelegt. Thats it
so, per define klappt es wunderbar:
Internals:
CFGFN
DEF HM_Heizung-Sz group=HM_Fensterkontakt_SZ,Thermostat-Schlafzimmer
IODev ccu
NAME Heizung_SZ
NR 96042
STATE 0
TYPE HMCCUDEV
ccuaddr INT0000001
ccudevstate active
ccugroup 0000D7099A4D9A,000E9569A2410C
ccuif VirtualDevices
ccuname HM_Heizung-Sz
ccutype HmIP-HEATING
channels 6
statevals devstate
READINGS:
2018-06-30 14:04:35 0.ACTUAL_TEMPERATURE_STATUS 0
2018-06-30 14:04:35 0.CONFIG_PENDING false
2018-06-30 14:04:35 0.DUTY_CYCLE false
2018-06-30 14:04:35 0.ERROR_CODE 0
2018-06-30 14:04:35 0.ERROR_OVERHEAT false
2018-06-30 14:04:35 0.INSTALL_TEST false
2018-06-30 14:04:35 0.LOW_BAT false
2018-06-30 14:04:35 0.OPERATING_VOLTAGE 2.600000
2018-06-30 14:04:35 0.OPERATING_VOLTAGE_STATUS 0
2018-06-30 14:04:35 0.RSSI_DEVICE 216
2018-06-30 14:04:35 0.RSSI_PEER 217
2018-06-30 14:04:35 0.SABOTAGE false
2018-06-30 14:04:35 0.UPDATE_PENDING false
2018-06-30 14:04:35 1.ACTIVE_PROFILE 1
2018-06-30 14:04:35 1.ACTUAL_TEMPERATURE 27.000000
2018-06-30 14:04:35 1.ACTUAL_TEMPERATURE_STATUS 0
2018-06-30 14:02:11 1.BOOST_MODE 0
2018-06-30 14:04:35 1.BOOST_TIME 0
2018-06-30 14:04:35 1.FROST_PROTECTION false
2018-06-30 14:04:35 1.HEATING_COOLING 0
2018-06-30 14:04:35 1.HUMIDITY 43
2018-06-30 14:04:35 1.HUMIDITY_STATUS 0
2018-06-30 14:04:35 1.LEVEL 0.000000
2018-06-30 14:04:35 1.LEVEL_STATUS 0
2018-06-30 14:04:35 1.PARTY_MODE false
2018-06-30 14:04:35 1.PARTY_SET_POINT_TEMPERATU 0.000000
2018-06-30 14:04:35 1.PARTY_SET_POINT_TEMPERATURE 4.500000
2018-06-30 14:04:35 1.PARTY_TIME_END
2018-06-30 14:04:35 1.PARTY_TIME_START
2018-06-30 14:04:35 1.QUICK_VETO_TIME 0
2018-06-30 14:04:35 1.SET_POINT_MODE 1
2018-06-30 14:04:35 1.SET_POINT_TEMPERATURE 12.000000
2018-06-30 14:04:35 1.STATE 0
2018-06-30 14:04:35 1.SWITCH_POINT_OCCURED false
2018-06-30 14:04:35 1.VALVE_ADAPTION false
2018-06-30 14:04:35 1.VALVE_STATE 0
2018-06-30 14:04:35 1.WINDOW_STATE 0
2018-06-30 14:04:35 3.STATE 0
2018-06-30 14:04:35 4.PROCESS 0
2018-06-30 14:04:35 4.SECTION 0
2018-06-30 14:04:35 4.SECTION_STATUS 0
2018-06-30 14:04:35 4.STATE false
2018-06-30 14:04:35 activity false
2018-06-30 14:04:35 battery false
2018-06-30 14:04:35 control 0
2018-06-30 14:04:35 desired-temp 12.000000
2018-06-30 14:04:35 hmstate 0
2018-06-30 14:04:35 state 0
hmccu:
dp:
0.ACTUAL_TEMPERATURE_STATUS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.CONFIG_PENDING:
OSVAL false
OVAL false
SVAL false
VAL false
0.DUTY_CYCLE:
OSVAL false
OVAL false
SVAL false
VAL false
0.ERROR_CODE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.ERROR_OVERHEAT:
OSVAL false
OVAL false
SVAL false
VAL false
0.INSTALL_TEST:
OSVAL false
OVAL false
SVAL false
VAL false
0.LOW_BAT:
OSVAL false
OVAL false
SVAL false
VAL false
0.OPERATING_VOLTAGE:
OSVAL 1.200000
OVAL 1.200000
SVAL 2.600000
VAL 2.600000
0.OPERATING_VOLTAGE_STATUS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.RSSI_DEVICE:
OSVAL 206
OVAL 206
SVAL 216
VAL 216
0.RSSI_PEER:
OSVAL 0
OVAL 0
SVAL 217
VAL 217
0.SABOTAGE:
OSVAL false
OVAL false
SVAL false
VAL false
0.UNREACH:
OSVAL false
OVAL false
SVAL false
VAL false
0.UPDATE_PENDING:
OSVAL false
OVAL false
SVAL false
VAL false
1.ACTIVE_PROFILE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.ACTUAL_TEMPERATURE:
OSVAL 27.000000
OVAL 27.000000
SVAL 27.000000
VAL 27.000000
1.ACTUAL_TEMPERATURE_STATUS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.BOOST_TIME:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.FROST_PROTECTION:
OSVAL false
OVAL false
SVAL false
VAL false
1.HEATING_COOLING:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.HUMIDITY:
OSVAL 43
OVAL 43
SVAL 43
VAL 43
1.HUMIDITY_STATUS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.LEVEL:
OSVAL 0.000000
OVAL 0.000000
SVAL 0.000000
VAL 0.000000
1.LEVEL_STATUS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.PARTY_MODE:
OSVAL false
OVAL false
SVAL false
VAL false
1.PARTY_SET_POINT_TEMPERATU:
OSVAL 0.000000
OVAL 0.000000
SVAL 0.000000
VAL 0.000000
1.PARTY_SET_POINT_TEMPERATURE:
OSVAL 4.500000
OVAL 4.500000
SVAL 4.500000
VAL 4.500000
1.PARTY_TIME_END:
OSVAL 2000_01_01 00:00
OVAL 2000_01_01 00:00
SVAL
VAL
1.PARTY_TIME_START:
OSVAL 2000_01_01 00:00
OVAL 2000_01_01 00:00
SVAL
VAL
1.QUICK_VETO_TIME:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.SET_POINT_MODE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.SET_POINT_TEMPERATURE:
OSVAL 12.000000
OVAL 12.000000
SVAL 12.000000
VAL 12.000000
1.STATE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.SWITCH_POINT_OCCURED:
OSVAL false
OVAL false
SVAL false
VAL false
1.VALVE_ADAPTION:
OSVAL false
OVAL false
SVAL false
VAL false
1.VALVE_STATE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.WINDOW_STATE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
3.STATE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.PROCESS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.SECTION:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.SECTION_STATUS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.STATE:
OSVAL false
OVAL false
SVAL false
VAL false
Attributes:
IODev ccu
ccureadingformat datapoint
ccureadingname 0.(LOWBAT|LOW_BAT):+battery;1.SET_POINT_TEMPERATURE:+desired-temp
Die Konfiguration auf der CCU ist sicherlich viel einfacher.
Die Darstellung im FHEM ist mir persönlich als einzelne Device viel lieber.
Als Gruppe ist zB das Homebridgemapping und damit eine Einbindung in Alexa, Home, etc fast unmöglich.
Aber wer das alles nicht braucht....einfacher ist es so allemal.
VG
Christian
Hallo,
ich wage gerade meine ersten Schritte mit HMCCU und habe eine Frage zu dem Attribut "ccuscaleval <[!]datapoint>:<min>:<max>:<minn>:<maxn>[,...] "
Ich habe in der CCU eine Philips HUE mit einem Dimmer device angelegt. Die Deviceinfo sieht so aus:
CHN CUX2802002:1 HK Tischlampe:1
DPT {b} CUxD.CUX2802002:1.STATE = false [WE]
DPT {b} CUxD.CUX2802002:1.HOLD = [W]
DPT {s} CUxD.CUX2802002:1.SUBMIT = [W]
DPT {b} CUxD.CUX2802002:1.INSTALL_TEST = false [RW]
CHN CUX2802002:2 HK Tischlampe:2
DPT {a} CUxD.CUX2802002:2.LEVEL = 0.000000 [RWE]
DPT {b} CUxD.CUX2802002:2.OLD_LEVEL = [W]
DPT {f} CUxD.CUX2802002:2.SET_STATE = [W]
DPT {b} CUxD.CUX2802002:2.INSTALL_TEST = false [RW]
CHN CUX2802002:3 HK Tischlampe:3
DPT {a} CUxD.CUX2802002:3.LEVEL = 0.320000 [RWE]
DPT {b} CUxD.CUX2802002:3.OLD_LEVEL = [W]
DPT {f} CUxD.CUX2802002:3.SET_STATE = [W]
DPT {b} CUxD.CUX2802002:3.INSTALL_TEST = false [RW]
CHN CUX2802002:4 HK Tischlampe:4
DPT {a} CUxD.CUX2802002:4.LEVEL = 0.260000 [RWE]
DPT {b} CUxD.CUX2802002:4.OLD_LEVEL = [W]
DPT {f} CUxD.CUX2802002:4.SET_STATE = [W]
DPT {b} CUxD.CUX2802002:4.INSTALL_TEST = false [RW]
CHN CUX2802002:5 HK Tischlampe:5
DPT {b} CUxD.CUX2802002:5.INSTALL_TEST = false [RW]
DPT {a} CUxD.CUX2802002:5.LEVEL = 0.098000 [RWE]
DPT {b} CUxD.CUX2802002:5.OLD_LEVEL = [W]
DPT {f} CUxD.CUX2802002:5.SET_STATE = [W]
CHN CUX2802002:6 HK Tischlampe:6
DPT {b} CUxD.CUX2802002:6.INSTALL_TEST = false [RW]
CHN CUX2802002:7 HK Tischlampe:7
DPT {b} CUxD.CUX2802002:7.INSTALL_TEST = false [RW]
CHN CUX2802002:8 HK Tischlampe:8
DPT {b} CUxD.CUX2802002:8.INSTALL_TEST = false [RW]
CHN CUX2802002:9 HK Tischlampe:9
DPT {b} CUxD.CUX2802002:9.INSTALL_TEST = false [RW]
CHN CUX2802002:10 HK Tischlampe:10
DPT {b} CUxD.CUX2802002:10.INSTALL_TEST = false [RW]
CHN CUX2802002:11 HK Tischlampe:11
DPT {b} CUxD.CUX2802002:11.INSTALL_TEST = false [RW]
CHN CUX2802002:12 HK Tischlampe:12
DPT {b} CUxD.CUX2802002:12.INSTALL_TEST = false [RW]
CHN CUX2802002:13 HK Tischlampe:13
DPT {b} CUxD.CUX2802002:13.INSTALL_TEST = false [RW]
CHN CUX2802002:14 HK Tischlampe:14
DPT {b} CUxD.CUX2802002:14.INSTALL_TEST = false [RW]
CHN CUX2802002:15 HK Tischlampe:15
DPT {b} CUxD.CUX2802002:15.INSTALL_TEST = false [RW]
CHN CUX2802002:16 HK Tischlampe:16
DPT {b} CUxD.CUX2802002:16.INSTALL_TEST = false [RW]
CHN CUX2802002:17 HK Tischlampe:17
DPT {b} CUxD.CUX2802002:17.INSTALL_TEST = false [RW]
Die Kanäle 2-5 sind relevant und haben folgende Bedeutung:
Ch.2 (brightness): DIMMER|MAX_VAL: 254
Ch.3 (color temperature): DIMMER|MAX_VAL: 347
Ch.4 (hue): DIMMER|MAX_VAL: 65535
Ch.5 (saturation): DIMMER|MAX_VAL: 254
Leider hat jeder einzelne Kanal eine andere Skalierung aber jedes Mal den gleichen Namen "LEVEL". Nun wollte ich mit dem Attribut "ccuscaleval" jeden einzelnen Kanal unterschiedlich skalieren. Dies hat leider nicht geklappt, da man vor dem Datenpunkt den Kanalnamen nicht angeben kann. Ich habe dazu diesen Beitrag gefunden:
Zitathttps://forum.fhem.de/index.php/topic,40189.msg478292.html#msg478292
Nun meine Frage: Wäre es möglich ccuscaleval doch noch derart anzupassen, dass der Kanalname angeben werden kann? Ich würde dies in dieser Anwendung für sinnvoll halten.
Falls nein, gibt es noch irgendeine Möglichkeit eine Skalierung auf anderem Wege hinzubekommen ohne, dass ich eine HUE Lampe in mehere HMCCUCHN's zerteilen muss?
Danke und Gruß, Bruece-Lee
Wieso läuft das über CUXD? Die CCU unterstützt doch mittlerweile Hue Lampen out of the box.
Getestet habe ich das allerdings noch nicht, da meine Hue Lampen direkt in FHEM integriert sind. Warum willst Du die in der CCU haben?
Mit dem HUE Addon wird auch der Status der HUE's zurückgemeldet. Das soll angeblich mit dem integrierten Modul nicht funktionieren. Ich möchte HMCCU nutzen, um meine Homematic Komponenten autark durch die CCU steuern zu lassen. FHEM übernimmt dann übergeordnete Logiken und die Visualisierung mit TabletUI. Die HUE's möchte ich in der CCU haben, um noch ein Stück unabhängiger von FHEM zu werden. Wenn der Server nicht läuft sollen die Basisfunktionen wie Licht, Heizung etc. trotzdem noch über die CCU funktionieren....so der Plan.
Wenn das ccuscaleval für mehrere gleich benannte Datenpunkte funktionieren würde, dann könnte ich mir eine komplette Lampe mit HMCCUDEV in FHEM nachbauen.
ok, das mit ccuscaleval schaue ich mir an. Trotzdem wundert mich, dass das in der CcU über CUxD läuft. Ich dachte, die Adressen für die HUE Devices würden anders aussehen. Muss ich vielleicht bei mir auch mal so einbinden.
@ZAP: Ich nutze für die HUE's das HUE Addon von hier: https://github.com/j-a-n/homematic-addon-hue (https://github.com/j-a-n/homematic-addon-hue). Dort ist ein Weg beschrieben, wie eine Lampe mittels CUXD device eingebunden wird.
Danke, dass Du Dir das ccuscaleval anschaust.
du könntesg es nagürlich mal mit dem offiziellen Addon probieren. Vielleicht sind da die Datenpunkte unterschiedlich benannt.
Zwei Gründe sprechen für mich dagegen: 1. Soll der Status der Lampen mit dem offiziellen Addon nicht automatisch von der bridge synchronisiert werden und 2. habe ich gelesen, dass das erst ab Bridge 2.0 funktioniert, die ich leider nicht habe.
Ok, die Erweiterung für ccuscaleval ist in Arbeit. Wird aber wohl nächste Woche werden, da ich bei der Codeanalyse gleich noch einen Fehler gefunden habe.
Super, ich freue mich drauf. Aber keine Eile, ich stehe noch ganz am Anfang mit HMCCU und habe viele Baustellen (...auf die ich mich freue :-) ).
Zitat von: zap am 14 Juni 2018, 10:45:10
Bugfix für rpcServerAddr ist im SVN eingecheckt. Morgen per FHEM Update verfügbar.
Prima, funktioniert.
Hatte endlich mal Zeit zu testen.
Danke und Gruß
Jürgen
Ich habe gerade die Version 4.2.008 eingecheckt. Morgen dann per FHEM update verfügbar.
Änderungen:
- Das Attribut ccuscaleval unterstützt nun die optionale Angabe einer Kanalnummer vor dem Datenpunkt. Damit kann die Skalierung von Werten bei mehreren gleichlautenden Datenpunkten in einem HMCCUDEV Device auf einen bestimmten Kanal eingeschränkt werden. Die Kanalnummer wird dem Datenpunkt durch einen Punkt getrennt vorangestellt. Beispiel Skalierung von LEVEL in Kanal 3 auf Prozentwerte 0-100: 3.LEVEL:0:1:0:100
Bugfixes:
- Fehler bei Prüfung auf gültiges CCU Device / gültigen CCU Kanal behoben
Hallo zap!
Danke für die Erweiterung bei ccuscaleval! Funktioniert prima!
:)
Gruß, Bruece-Lee
Ein Hinweis an alle, die noch den externen RPC Server vom Typ HMCCURPC benutzen: Dieser wird mit der nächsten Version von HMCCU (voraussichtlich Ende nächster Woche) deaktiviert.
Beim Neustart von FHEM wird das Device vom Typ HMCCURPC deaktiviert und durch Devices vom Typ HMCCURPCPROC ersetzt.
Wer noch HMCCURPC nutzt (ccuflags im IO-Device = extrpc), kann das vorab schon auf HMCCURPCPROC umstellen, indem er das Attribut ccuflags im IO-Device auf procrpc setzt. Beim nächsten Start des RPC Servers werden dann die RPC Server Devices automatisch angelegt. Danach kann das alte HMCCURPC Device gelöscht werden.
Der interne RPC Server wird noch eine Weile unterstützt, da ich nicht zu viel auf einmal ändern möchte.
Hallo zap,
ich versuche gerade, den RPC Server von extprc auf procprc umzustellen. Die 2 neuen Devices für BidCos-RF und VirtualDevices wurden angelegt und das alte Device habe ich gelöscht.
Während BidCos-RF nun running/OK anzeigt, zeigt VirtualDevices inactive/OK an und ich habe im Log Fehler gefunden.
Was mache ich falsch?
...
2018.07.16 18:15:53 1: HMCCU: Device HM_HomeMatic__Zentrale2__HMCCU. Initialized version 4.2.008
2018.07.16 18:15:53 1: HMCCU: Read 41 devices with 232 channels from CCU 192.168.1.38
2018.07.16 18:15:53 1: HMCCU: Read 3 interfaces from CCU 192.168.1.38
...
2018.07.16 18:15:56 1: HMCCURPCPROC: [d_rpcBidCos_RF] Initialized version 1.0.006 for interface BidCos-RF with I/O device HM_HomeMatic__Zentrale2__HMCCU
2018.07.16 18:15:56 1: HMCCURPCPROC: [d_rpcVirtualDevices] Initialized version 1.0.006 for interface VirtualDevices with I/O device HM_HomeMatic__Zentrale2__HMCCU
2018.07.16 18:15:56 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4326, <$fh> line 40.
2018.07.16 18:15:56 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/88_HMCCU.pm line 2247, <$fh> line 40.
2018.07.16 18:15:56 1: ERROR: empty name in readingsBeginUpdate
2018.07.16 18:15:56 1: stacktrace:
2018.07.16 18:15:56 1: main::readingsBeginUpdate called by fhem.pl (4711)
2018.07.16 18:15:56 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.16 18:15:56 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.16 18:15:56 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (667)
2018.07.16 18:15:56 1: main::HMCCURPCPROC_ResetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (307)
2018.07.16 18:15:56 1: main::HMCCURPCPROC_Define called by fhem.pl (3584)
2018.07.16 18:15:56 1: main::CallFn called by fhem.pl (1974)
2018.07.16 18:15:56 1: main::CommandDefine called by fhem.pl (1209)
2018.07.16 18:15:56 1: main::AnalyzeCommand called by fhem.pl (1059)
2018.07.16 18:15:56 1: main::AnalyzeCommandChain called by fhem.pl (1347)
2018.07.16 18:15:56 1: main::CommandInclude called by fhem.pl (577)
2018.07.16 18:15:56 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 4566, <$fh> line 40.
2018.07.16 18:15:56 1: readingsUpdate(,rpcstate,inactive) missed to call readingsBeginUpdate first.
2018.07.16 18:15:56 1: stacktrace:
2018.07.16 18:15:56 1: main::readingsBulkUpdate called by fhem.pl (4712)
2018.07.16 18:15:56 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.16 18:15:56 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.16 18:15:56 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (667)
2018.07.16 18:15:56 1: main::HMCCURPCPROC_ResetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (307)
2018.07.16 18:15:56 1: main::HMCCURPCPROC_Define called by fhem.pl (3584)
2018.07.16 18:15:56 1: main::CallFn called by fhem.pl (1974)
2018.07.16 18:15:56 1: main::CommandDefine called by fhem.pl (1209)
2018.07.16 18:15:56 1: main::AnalyzeCommand called by fhem.pl (1059)
2018.07.16 18:15:56 1: main::AnalyzeCommandChain called by fhem.pl (1347)
2018.07.16 18:15:56 1: main::CommandInclude called by fhem.pl (577)
2018.07.16 18:15:56 1: PERL WARNING: Use of uninitialized value $type in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 2162, <$fh> line 40.
2018.07.16 18:15:56 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 2162, <$fh> line 40.
2018.07.16 18:15:56 1: : [] All RPC servers inactive
2018.07.16 18:15:56 1: PERL WARNING: Use of uninitialized value $dev in hash element at fhem.pl line 3456, <$fh> line 40.
2018.07.16 18:15:56 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 2220, <$fh> line 40.
...
2018.07.16 18:15:57 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
...
2018.07.16 18:15:59 0: Featurelevel: 5.8
2018.07.16 18:15:59 0: Server started with 365 defined entities (fhem.pl:16866/2018-06-14 perl:5.024001 os:linux user:fhem pid:27815)
2018.07.16 18:15:59 1: PERL WARNING: Argument ".*" isn't numeric in numeric lt (<) at fhem.pl line 4610.
...
2018.07.16 18:16:09 2: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server process started for interface BidCos-RF with PID=27828
2018.07.16 18:16:09 2: CCURPC: [d_rpcBidCos_RF] Initializing RPC server CB2001001024 for interface BidCos-RF
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Set state to busy
2018.07.16 18:16:09 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server starting
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Set rpcstate to starting
2018.07.16 18:16:09 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4326.
2018.07.16 18:16:09 1: PERL WARNING: Use of uninitialized value $interface in concatenation (.) or string at ./FHEM/88_HMCCURPCPROC.pm line 1206.
2018.07.16 18:16:09 2: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server process started for interface with PID=27829
2018.07.16 18:16:09 1: PERL WARNING: Use of uninitialized value $iface in concatenation (.) or string at ./FHEM/88_HMCCURPCPROC.pm line 1626.
2018.07.16 18:16:09 2: CCURPC: [d_rpcVirtualDevices] Initializing RPC server CB9292001024 for interface
2018.07.16 18:16:09 1: PERL WARNING: Use of uninitialized value $prot in string eq at ./FHEM/88_HMCCURPCPROC.pm line 1031.
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Set state to busy
2018.07.16 18:16:09 1: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server starting
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Set rpcstate to starting
2018.07.16 18:16:09 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/88_HMCCU.pm line 2247.
2018.07.16 18:16:09 1: ERROR: empty name in readingsBeginUpdate
2018.07.16 18:16:09 1: stacktrace:
2018.07.16 18:16:09 1: main::readingsBeginUpdate called by fhem.pl (4711)
2018.07.16 18:16:09 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.16 18:16:09 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (1228)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_StartRPCServer called by ./FHEM/88_HMCCU.pm (3190)
2018.07.16 18:16:09 1: main::HMCCU_StartExtRPCServer called by fhem.pl (3127)
2018.07.16 18:16:09 1: main::HandleTimeout called by fhem.pl (646)
2018.07.16 18:16:09 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 4566.
2018.07.16 18:16:09 1: readingsUpdate(,rpcstate,starting) missed to call readingsBeginUpdate first.
2018.07.16 18:16:09 1: stacktrace:
2018.07.16 18:16:09 1: main::readingsBulkUpdate called by fhem.pl (4712)
2018.07.16 18:16:09 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.16 18:16:09 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (1228)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_StartRPCServer called by ./FHEM/88_HMCCU.pm (3190)
2018.07.16 18:16:09 1: main::HMCCU_StartExtRPCServer called by fhem.pl (3127)
2018.07.16 18:16:09 1: main::HandleTimeout called by fhem.pl (646)
2018.07.16 18:16:09 1: PERL WARNING: Use of uninitialized value $dev in hash element at fhem.pl line 3456.
2018.07.16 18:16:09 1: PERL WARNING: Use of uninitialized value $type in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 2162.
2018.07.16 18:16:09 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 2162.
2018.07.16 18:16:09 1: : [] All RPC servers starting
2018.07.16 18:16:09 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 2220.
2018.07.16 18:16:09 2: HMCCURPCPROC: [d_rpcBidCos_RF] Callback server CB2001001024 created. Listening on port 7411
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Adding callback for events for server CB2001001024
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Adding callback for new devices for server CB2001001024
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Adding callback for deleted devices for server CB2001001024
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Adding callback for modified devices for server CB2001001024
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Adding callback for replaced devices for server CB2001001024
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Adding callback for readded devices for server CB2001001024
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Adding callback for list devices for server CB2001001024
2018.07.16 18:16:09 2: CCURPC: [d_rpcBidCos_RF] CB2001001024 accepting connections. PID=27828
2018.07.16 18:16:09 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:09 2: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB2001001024 enters server loop
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Set rpcstate to working
2018.07.16 18:16:09 2: HMCCURPCPROC: [d_rpcBidCos_RF] Registering callback http://192.168.1.24:7411/fh2001 of type A with ID CB2001001024 at http://192.168.1.38:2001
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Send ASCII RPC request init to http://192.168.1.38:2001
2018.07.16 18:16:09 2: HMCCURPCPROC: [d_rpcVirtualDevices] Callback server CB9292001024 created. Listening on port 14702
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Adding callback for events for server CB9292001024
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Adding callback for new devices for server CB9292001024
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Adding callback for deleted devices for server CB9292001024
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Adding callback for modified devices for server CB9292001024
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Adding callback for replaced devices for server CB9292001024
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Adding callback for readded devices for server CB9292001024
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Adding callback for list devices for server CB9292001024
2018.07.16 18:16:09 2: CCURPC: [d_rpcVirtualDevices] CB9292001024 accepting connections. PID=27829
2018.07.16 18:16:09 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:09 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 processing request
2018.07.16 18:16:09 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:09 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 processing request
2018.07.16 18:16:09 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:09 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 processing request
2018.07.16 18:16:09 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB2001001024 running
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Set rpcstate to running
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Set state to OK
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 1 events read: no data
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Read called
2018.07.16 18:16:09 2: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server CB9292001024 enters server loop
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Set rpcstate to working
2018.07.16 18:16:09 1: ERROR: empty name in readingsBeginUpdate
2018.07.16 18:16:09 1: stacktrace:
2018.07.16 18:16:09 1: main::readingsBeginUpdate called by fhem.pl (4711)
2018.07.16 18:16:09 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.16 18:16:09 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (773)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_ProcessEvent called by ./FHEM/88_HMCCURPCPROC.pm (531)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_Read called by fhem.pl (3584)
2018.07.16 18:16:09 1: main::CallFn called by fhem.pl (723)
2018.07.16 18:16:09 1: readingsUpdate(,rpcstate,working) missed to call readingsBeginUpdate first.
2018.07.16 18:16:09 1: stacktrace:
2018.07.16 18:16:09 1: main::readingsBulkUpdate called by fhem.pl (4712)
2018.07.16 18:16:09 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.16 18:16:09 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (773)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_ProcessEvent called by ./FHEM/88_HMCCURPCPROC.pm (531)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_Read called by fhem.pl (3584)
2018.07.16 18:16:09 1: main::CallFn called by fhem.pl (723)
2018.07.16 18:16:09 1: : [] All RPC servers working
2018.07.16 18:16:09 1: HMCCURPCPROC: [d_rpcVirtualDevices] Can't get RPC parameters for ID CB9292001024
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Set rpcstate to error
2018.07.16 18:16:09 1: ERROR: empty name in readingsBeginUpdate
2018.07.16 18:16:09 1: stacktrace:
2018.07.16 18:16:09 1: main::readingsBeginUpdate called by fhem.pl (4711)
2018.07.16 18:16:09 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.16 18:16:09 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (776)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_ProcessEvent called by ./FHEM/88_HMCCURPCPROC.pm (531)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_Read called by fhem.pl (3584)
2018.07.16 18:16:09 1: main::CallFn called by fhem.pl (723)
2018.07.16 18:16:09 1: readingsUpdate(,rpcstate,error) missed to call readingsBeginUpdate first.
2018.07.16 18:16:09 1: stacktrace:
2018.07.16 18:16:09 1: main::readingsBulkUpdate called by fhem.pl (4712)
2018.07.16 18:16:09 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.16 18:16:09 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (776)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_ProcessEvent called by ./FHEM/88_HMCCURPCPROC.pm (531)
2018.07.16 18:16:09 1: main::HMCCURPCPROC_Read called by fhem.pl (3584)
2018.07.16 18:16:09 1: main::CallFn called by fhem.pl (723)
2018.07.16 18:16:09 1: : [] All RPC servers error
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Read stopped after 1 events read: no data
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Read finished
2018.07.16 18:16:09 2: CCURPC: [d_rpcBidCos_RF] CB2001001024 NewDevice received 233 device and channel specifications
2018.07.16 18:16:09 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 sending data to FHEM
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:09 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:09 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 processing request
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 70 events read: no data
2018.07.16 18:16:09 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 sending data to FHEM
2018.07.16 18:16:09 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 79 events read: no data
2018.07.16 18:16:10 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:10 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:10 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 sending data to FHEM
2018.07.16 18:16:10 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:10 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:10 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 70 events read: no data
2018.07.16 18:16:10 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:11 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:11 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 sending data to FHEM
2018.07.16 18:16:11 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:11 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:11 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 23 events read: no data
2018.07.16 18:16:11 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:12 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:12 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:13 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:13 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:14 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:14 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:15 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:15 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:16 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:16 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:17 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:17 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:18 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:18 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:18 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 processing request
2018.07.16 18:16:18 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:19 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 2 events read: no data
2018.07.16 18:16:19 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:19 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:19 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 14 events read: no data
2018.07.16 18:16:19 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:19 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:20 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:20 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:21 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:21 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:21 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 processing request
2018.07.16 18:16:21 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:21 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 1 events read: no data
2018.07.16 18:16:21 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:21 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:21 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 15 events read: no data
2018.07.16 18:16:21 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:22 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:22 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:23 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:23 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:24 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:24 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:25 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 processing request
2018.07.16 18:16:25 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:25 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 1 events read: no data
2018.07.16 18:16:25 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:25 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:25 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 15 events read: no data
2018.07.16 18:16:25 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:25 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:26 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:26 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:27 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:27 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 processing request
2018.07.16 18:16:27 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:27 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 4 events read: no data
2018.07.16 18:16:27 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:27 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:27 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 2 events read: no data
2018.07.16 18:16:27 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:27 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:28 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:28 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:29 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:29 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:30 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:30 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:30 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 processing request
2018.07.16 18:16:30 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:30 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 6 events read: no data
2018.07.16 18:16:30 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
2018.07.16 18:16:31 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:31 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:32 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:32 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:33 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:33 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:34 2: HMCCURPCPROC: [d_rpcVirtualDevices] Checking if RPC server process is running
2018.07.16 18:16:34 1: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server process not running. Cleaning up
2018.07.16 18:16:34 1: HMCCURPCPROC: [d_rpcVirtualDevices] Housekeeping called. Cleaning up RPC environment
2018.07.16 18:16:34 5: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 accepting connections
2018.07.16 18:16:34 2: HMCCURPCPROC: [d_rpcVirtualDevices] Sending signal INT to RPC server process CB9292001024 with PID=27829
2018.07.16 18:16:34 4: HMCCURPCPROC: [d_rpcVirtualDevices] Set rpcstate to stopping
2018.07.16 18:16:34 1: ERROR: empty name in readingsBeginUpdate
2018.07.16 18:16:34 1: stacktrace:
2018.07.16 18:16:34 1: main::readingsBeginUpdate called by fhem.pl (4711)
2018.07.16 18:16:34 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.16 18:16:34 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.16 18:16:34 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (1328)
2018.07.16 18:16:34 1: main::HMCCURPCPROC_TerminateProcess called by ./FHEM/88_HMCCURPCPROC.pm (1433)
2018.07.16 18:16:34 1: main::HMCCURPCPROC_Housekeeping called by ./FHEM/88_HMCCURPCPROC.pm (1410)
2018.07.16 18:16:34 1: main::HMCCURPCPROC_IsRPCServerRunning called by fhem.pl (3127)
2018.07.16 18:16:34 1: main::HandleTimeout called by fhem.pl (646)
2018.07.16 18:16:34 1: readingsUpdate(,rpcstate,stopping) missed to call readingsBeginUpdate first.
2018.07.16 18:16:34 1: stacktrace:
2018.07.16 18:16:34 1: main::readingsBulkUpdate called by fhem.pl (4712)
2018.07.16 18:16:34 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.16 18:16:34 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.16 18:16:34 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (1328)
2018.07.16 18:16:34 1: main::HMCCURPCPROC_TerminateProcess called by ./FHEM/88_HMCCURPCPROC.pm (1433)
2018.07.16 18:16:34 1: main::HMCCURPCPROC_Housekeeping called by ./FHEM/88_HMCCURPCPROC.pm (1410)
2018.07.16 18:16:34 1: main::HMCCURPCPROC_IsRPCServerRunning called by fhem.pl (3127)
2018.07.16 18:16:34 1: main::HandleTimeout called by fhem.pl (646)
2018.07.16 18:16:34 1: : [] All RPC servers stopping
2018.07.16 18:16:34 2: CCURPC: [d_rpcVirtualDevices] CB9292001024 received signal INT
2018.07.16 18:16:34 1: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 stopped handling connections. PID=27829
2018.07.16 18:16:34 1: PERL WARNING: Use of uninitialized value $prot in string eq at ./FHEM/88_HMCCURPCPROC.pm line 1709.
2018.07.16 18:16:34 4: CCURPC: [d_rpcVirtualDevices] Event statistics = 1|0|0|0|0|0|0|0|0|1|0
2018.07.16 18:16:34 4: CCURPC: [d_rpcVirtualDevices] CB9292001024 event type = EV: 0
2018.07.16 18:16:34 4: CCURPC: [d_rpcVirtualDevices] CB9292001024 event type = ND: 0
2018.07.16 18:16:34 4: CCURPC: [d_rpcVirtualDevices] CB9292001024 event type = DD: 0
2018.07.16 18:16:34 4: CCURPC: [d_rpcVirtualDevices] CB9292001024 event type = RD: 0
2018.07.16 18:16:34 4: CCURPC: [d_rpcVirtualDevices] CB9292001024 event type = RA: 0
2018.07.16 18:16:34 4: CCURPC: [d_rpcVirtualDevices] CB9292001024 event type = UD: 0
2018.07.16 18:16:34 4: CCURPC: [d_rpcVirtualDevices] CB9292001024 event type = IN: 0
2018.07.16 18:16:34 4: CCURPC: [d_rpcVirtualDevices] CB9292001024 event type = EX: 1
2018.07.16 18:16:34 4: CCURPC: [d_rpcVirtualDevices] CB9292001024 event type = SL: 1
2018.07.16 18:16:34 4: CCURPC: [d_rpcVirtualDevices] CB9292001024 event type = TO: 0
2018.07.16 18:16:34 2: CCURPC: [d_rpcVirtualDevices] Number of I/O errors = 0
2018.07.16 18:16:34 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:34 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 processing request
2018.07.16 18:16:35 5: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 accepting connections
2018.07.16 18:16:36 4: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001024 processing request
2018.07.16 18:16:36 2: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server process CB9292001024 deleted
2018.07.16 18:16:36 4: HMCCURPCPROC: [d_rpcVirtualDevices] Set rpcstate to inactive
2018.07.16 18:16:36 1: ERROR: empty name in readingsBeginUpdate
2018.07.16 18:16:36 1: stacktrace:
2018.07.16 18:16:36 1: main::readingsBeginUpdate called by fhem.pl (4711)
2018.07.16 18:16:36 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.16 18:16:36 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.16 18:16:36 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (1363)
2018.07.16 18:16:36 1: main::HMCCURPCPROC_CleanupProcess called by ./FHEM/88_HMCCURPCPROC.pm (1276)
2018.07.16 18:16:36 1: main::HMCCURPCPROC_RPCServerStopped called by ./FHEM/88_HMCCURPCPROC.pm (1436)
2018.07.16 18:16:36 1: main::HMCCURPCPROC_Housekeeping called by ./FHEM/88_HMCCURPCPROC.pm (1410)
2018.07.16 18:16:36 1: main::HMCCURPCPROC_IsRPCServerRunning called by fhem.pl (3127)
2018.07.16 18:16:36 1: main::HandleTimeout called by fhem.pl (646)
2018.07.16 18:16:36 1: readingsUpdate(,rpcstate,inactive) missed to call readingsBeginUpdate first.
2018.07.16 18:16:36 1: stacktrace:
2018.07.16 18:16:36 1: main::readingsBulkUpdate called by fhem.pl (4712)
2018.07.16 18:16:36 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.16 18:16:36 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.16 18:16:36 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (1363)
2018.07.16 18:16:36 1: main::HMCCURPCPROC_CleanupProcess called by ./FHEM/88_HMCCURPCPROC.pm (1276)
2018.07.16 18:16:36 1: main::HMCCURPCPROC_RPCServerStopped called by ./FHEM/88_HMCCURPCPROC.pm (1436)
2018.07.16 18:16:36 1: main::HMCCURPCPROC_Housekeeping called by ./FHEM/88_HMCCURPCPROC.pm (1410)
2018.07.16 18:16:36 1: main::HMCCURPCPROC_IsRPCServerRunning called by fhem.pl (3127)
2018.07.16 18:16:36 1: main::HandleTimeout called by fhem.pl (646)
2018.07.16 18:16:36 1: : [] All RPC servers inactive
2018.07.16 18:16:36 2: HMCCURPCPROC: [d_rpcVirtualDevices] Stop I/O handling
2018.07.16 18:16:36 3: HMCCURPCPROC: [d_rpcVirtualDevices] Close child socket
2018.07.16 18:16:36 3: HMCCURPCPROC: [d_rpcVirtualDevices] Close parent socket
2018.07.16 18:16:36 4: HMCCURPCPROC: [d_rpcVirtualDevices] Reset RPC state
2018.07.16 18:16:36 4: HMCCURPCPROC: [d_rpcVirtualDevices] Set state to OK
2018.07.16 18:16:36 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read called
2018.07.16 18:16:36 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read stopped after 9 events read: no data
2018.07.16 18:16:36 4: HMCCURPCPROC: [d_rpcBidCos_RF] Read finished
...
Vielen Dank für Deine Hilfe im Voraus und Grüße
Christian
Hast Du die Config mal gespeichert und FHEM neu gestartet? Irgendwie scheint da ein Device nicht korrekt initialisiert / definiert zu sein. Der Fehler kommt daher, dass wohl $hash->{TYPE} nicht definiert ist. Das müsste es aber sein bei korrekt definierten Devices.
Wichtig ist, dass in der fhem.cfg das IO Device (HMCCU) vor den beiden HMCCURPCPROC Devices steht. Das sollte so sein, wenn man das einmal speichert und die fhem.cfg nicht manuell editiert.
Config habe ich gespeichert und FHEM neu gestartet.
Welche Devices meinst Du mit "nicht korrekt initialisiert / definiert"? Die IO und RPCPROC Devices?
Ehrlich gesagt, keine Ahnung was da schief läuft.
Du kannst mal folgendes versuchen:
- Bei gestopptem RPC Server die beiden HMCCURPCPROC Devices löschen
- Im IO Device das Attribut rpcserver auf "off" (Autostart RPC Server aus)
- Dann die Config speichern
- FHEM neu starten
- RPC Server manuell starten (im IO device set rpcserver on) => HMCCURPCPROC Devices werden neu angelegt.
- Config speichern
- FHEM neu starten
- RPC Server starten
- Wenn alles gut geht, kannst Du rpcserver wieder auf on setzen
Hallo zap,
ich habe jetzt alles noch einmal durchprobiert, einschließlich alte cfg zurück kopieren und noch einmal von vorne anfangen - leider ohne Erfolg. Die Reihenfolge der Devices in der cfg stimmt auch.
Bei allen Versuchen läuft und funktioniert der BidCos-RF RPC immer und der VirtualDevices RPC eben nicht.
Das einzige was mir noch Einfällt, ist, dass ich anstelle einer echten CCU2 eine virtuelle piVCCU auf dem Raspberry laufen habe. Die hat aber mit dem extrpc die ganze Zeit problemlos funktioniert.
Ich bleibe jetzt erst einmal beim extrpc. Vielleicht fällt Dir ja doch noch etwas ein. Gib einfach Bescheid, dann probiere ich es aus.
Viele Grüße
Christian
Hast du denn in der CCU eine oder mehrere virtuelle Gruppen definiert?
Ich habe mehrere Gruppen definiert.
Hast Du mehrere HMCCU Devices definiert? Das Device für den RPC Server (Virtual) scheint kein I/O Device zu haben. Daher das Problem.
Hallo zap,
ich habe nur ein HMCCU Device. Was meinst Du mit "I/O Device"? Ist das ein Attribut?
Vor der Umstellung mit extrpc:
define HM_HomeMatic__Zentrale2__HMCCU HMCCU 192.168.1.38
attr HM_HomeMatic__Zentrale2__HMCCU alias HM HomeMatic
attr HM_HomeMatic__Zentrale2__HMCCU ccudef-readingformat name
attr HM_HomeMatic__Zentrale2__HMCCU ccuflags extrpc,nohmstate
attr HM_HomeMatic__Zentrale2__HMCCU event-on-change-reading rpcstate
attr HM_HomeMatic__Zentrale2__HMCCU group - Zentrale
attr HM_HomeMatic__Zentrale2__HMCCU room HM HomeMatic
attr HM_HomeMatic__Zentrale2__HMCCU rpcinterfaces BidCos-RF,VirtualDevices
attr HM_HomeMatic__Zentrale2__HMCCU rpcport 2001,9292
attr HM_HomeMatic__Zentrale2__HMCCU rpcqueue /tmp/ccuqueue
attr HM_HomeMatic__Zentrale2__HMCCU rpcserver on
attr HM_HomeMatic__Zentrale2__HMCCU stateFormat rpcstate
define HM_HomeMatic__Zentrale2__HMCCU_rpc HMCCURPC 192.168.1.38
attr HM_HomeMatic__Zentrale2__HMCCU_rpc alias HM HomeMatic RPC
attr HM_HomeMatic__Zentrale2__HMCCU_rpc event-on-change-reading rpcstate
attr HM_HomeMatic__Zentrale2__HMCCU_rpc group - Zentrale
attr HM_HomeMatic__Zentrale2__HMCCU_rpc room HM HomeMatic
attr HM_HomeMatic__Zentrale2__HMCCU_rpc stateFormat rpcstate
attr HM_HomeMatic__Zentrale2__HMCCU_rpc verbose 2
Und nach der Umstellung auf procrpc:
define HM_HomeMatic__Zentrale2__HMCCU HMCCU 192.168.1.38
attr HM_HomeMatic__Zentrale2__HMCCU alias HM HomeMatic
attr HM_HomeMatic__Zentrale2__HMCCU ccudef-readingformat name
attr HM_HomeMatic__Zentrale2__HMCCU ccuflags procrpc,nohmstate
attr HM_HomeMatic__Zentrale2__HMCCU event-on-change-reading rpcstate
attr HM_HomeMatic__Zentrale2__HMCCU group - Zentrale
attr HM_HomeMatic__Zentrale2__HMCCU room HM HomeMatic
attr HM_HomeMatic__Zentrale2__HMCCU rpcinterfaces BidCos-RF,VirtualDevices
attr HM_HomeMatic__Zentrale2__HMCCU rpcport 2001,9292
attr HM_HomeMatic__Zentrale2__HMCCU rpcqueue /tmp/ccuqueue
attr HM_HomeMatic__Zentrale2__HMCCU rpcserver on
attr HM_HomeMatic__Zentrale2__HMCCU stateFormat rpcstate
define d_rpcBidCos_RF HMCCURPCPROC 192.168.1.38 BidCos-RF
attr d_rpcBidCos_RF alias CCU RPC BidCos-RF
attr d_rpcBidCos_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpcBidCos_RF group - Zentrale
attr d_rpcBidCos_RF room HM HomeMatic
attr d_rpcBidCos_RF stateFormat rpcstate/state
attr d_rpcBidCos_RF verbose 2
define d_rpcVirtualDevices HMCCURPCPROC 192.168.1.38 VirtualDevices
attr d_rpcVirtualDevices alias CCU RPC VirtualDevices
attr d_rpcVirtualDevices eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpcVirtualDevices group - Zentrale
attr d_rpcVirtualDevices room HM HomeMatic
attr d_rpcVirtualDevices stateFormat rpcstate/state
attr d_rpcVirtualDevices verbose 2
Viele Grüße
Christian
Interessant wäre ein
list d_rpcVirtualDevices
Internals:
CCUNum 1
CFGFN ./myconfig/cfg/HM_HomeMatic.cfg
DEF 192.168.1.38 VirtualDevices
NAME d_rpcVirtualDevices
NR 795
RPCPID 0
RPCState inactive
STATE inactive/OK
TYPE HMCCURPCPROC
ccuip 192.168.1.38
ccustate active
ccutype CCU2
host 192.168.1.38
rpcid 001024
rpcinterface VirtualDevices
rpcip 192.168.1.38
rpcport 9292
version 1.0.006
READINGS:
2018-07-17 22:12:30 rpcstate inactive
2018-07-17 22:12:30 state OK
hmccu:
defaultaddr 192.168.1.24
evtime 0
localaddr 192.168.1.24
rpcstarttime 0
rpc:
cbport 14702
clkey
evtime 1531858323
pid
state inactive
sumdelay 0
rec:
DD 0
EV 0
EX 0
IN 0
ND 0
RA 0
RD 0
SL 1
TO 0
UD 0
snd:
DD 0
EV 0
EX 0
IN 0
ND 0
RA 0
RD 0
SL 0
TO 0
UD 0
Attributes:
alias CCU RPC VirtualDevices
eventMap /rpcserver on:on/rpcserver off:off/
group - Zentrale
room HM HomeMatic
stateFormat rpcstate/state
verbose 2
Und so müsste es aussehen, damit es funktioniert:
Internals:
CCUNum 1
CFGFN ./myconfig/cfg/HM_HomeMatic.cfg
DEF 192.168.1.38 VirtualDevices
IODev HM_HomeMatic__Zentrale2__HMCCU
NAME d_rpcVirtualDevices
...
Wie vermutet, fehlt IODev. Jetzt muss ich nur noch rausfinden warum.
Ich nehme an, beim Rpc für BidCos ist IODev beim list vorhanden?
Vermutlich wird es nach einer kleinen Änderung der Devicedefinition funktionieren (als Workaround):
define d_rpcVirtualDevices HMCCURPCPROC iodev=HM_HomeMatic__Zentrale2__HMCCU VirtualDevices
Wenn ich Dein Workarount define ... absetzte bekomme ich aber folgendes:
Internals:
CCUNum 1
DEF iodev=HM_HomeMatic__Zentrale2__HMCCU VirtualDevices
NAME d_rpcVirtualDevices
NR 2193
RPCPID 0
RPCState inactive
STATE inactive/OK
TYPE HMCCURPCPROC
ccuip 192.168.1.38
ccustate active
ccutype CCU2
host 192.168.1.38
rpcid 001024
rpcinterface VirtualDevices
rpcip 192.168.1.38
rpcport 9292
version 1.0.006
READINGS:
2018-07-18 09:24:08 rpcstate inactive
2018-07-18 09:24:08 state OK
hmccu:
defaultaddr 192.168.1.24
evtime 0
localaddr 192.168.1.24
rpcstarttime 0
rpc:
cbport 14702
clkey
evtime 1531898622
pid
state inactive
sumdelay 0
rec:
DD 0
EV 0
EX 0
IN 0
ND 0
RA 0
RD 0
SL 1
TO 0
UD 0
snd:
DD 0
EV 0
EX 0
IN 0
ND 0
RA 0
RD 0
SL 0
TO 0
UD 0
Attributes:
group - Zentrale
room HM HomeMatic
stateFormat rpcstate/state
verbose 2
Führe mal bitte im FHEM Eingabefenster folgendes aus:
{IsDisabled("HM_HomeMatic__Zentrale2__HMCCU")}
Da müsste eine Zahl von 0-3 ausgegeben werden.
3
Zitat von: cho am 18 Juli 2018, 11:09:43
3
Das ist das Problem. Bei der Zuordnung des IO Device prüft FHEM, ob das IO Device disabled ist. Das ist nicht nur dann der Fall, wenn disabled=1 ist, sondern auch, wenn der STATE oder das Reading state auf "inactive" steht (müsste bei dir so sein). Leider nutzt HMCCU inactive als Status des RPC Servers. Je nachdem, welchen Status HM_HomeMatic__Zentrale2__HMCCU gerade hat, funktioniert die Definition des VirtualDevice oder nicht.
Was mich wundert: im d_rpcVirtualDevice müsste entweder das Internal IODevMissing auf 1 stehen oder im Logfile müsste es eine Meldung geben "No I/O device found for ..."
stimmt, das I/O Device ist inactive:
Internals:
CCUNum 1
CFGFN ./myconfig/cfg/HM_HomeMatic.cfg
CHANGED
Clients :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
DEF 192.168.1.38
NAME HM_HomeMatic__Zentrale2__HMCCU
NOTIFYDEV global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
NR 789
NTFY_ORDER 50-HM_HomeMatic__Zentrale2__HMCCU
RPCState inactive
STATE inactive
TYPE HMCCU
ccuaddr BidCoS-RF
ccuchannels 232
ccudevices 41
ccuif BidCos-RF
ccuinterfaces VirtualDevices,BidCos-RF,HmIP-RF
ccuip 192.168.1.38
ccuname HM-RCV-50_BidCoS-RF
ccustate active
ccutype CCU2
host 192.168.1.38
version 4.2.008
READINGS:
2018-07-18 09:23:25 rpcstate inactive
2018-07-18 09:23:42 state OK
hmccu:
evtime 0
evtimeout 0
rpccount 0
rpcports 2001,9292
updatetime 0
adr:
...
INT0000001:
addtype dev
channels 3
chndir 0
interface VirtualDevices
name HM-CC-VG-1_INT0000001
type HM-CC-VG-1
valid 1
INT0000001:0:
addtype chn
channels 1
chndir 0
name HM-CC-VG-1_INT0000001:0
valid 1
INT0000001:1:
addtype chn
channels 1
chndir 0
name HM-CC-VG-1_INT0000001:1
valid 1
...
ifports:
2001 BidCos-RF
2010 HmIP-RF
9292 VirtualDevices
interfaces:
BidCos-RF:
device HM_HomeMatic__rpcBidCos_RF__HMCCURPCPROC
flags forceASCII
host 192.168.1.38
manager HMCCU
port 2001
prot http
state running
type A
url http://192.168.1.38:2001
HmIP-RF:
flags _
host 192.168.1.38
manager null
port 2010
prot http
state inactive
type A
url http://192.168.1.38:2010
VirtualDevices:
device d_rpcVirtualDevices
flags _
host 192.168.1.38
manager HMCCU
port 9292
prot http
state inactive
type A
url http://192.168.1.38:9292/groups
rpc:
Attributes:
alias HM HomeMatic
ccudef-readingformat name
ccuflags procrpc,nohmstate
event-on-change-reading rpcstate
group - Zentrale
room HM HomeMatic
rpcinterfaces BidCos-RF,VirtualDevices
rpcport 2001,9292
rpcqueue /tmp/ccuqueue
rpcserver on
stateFormat rpcstate
im d_rpcVirtualDevices gibt es kein Internal IODevMissing:
Internals:
CCUNum 1
DEF iodev=HM_HomeMatic__Zentrale2__HMCCU VirtualDevices
NAME d_rpcVirtualDevices
NR 2193
RPCPID 0
RPCState inactive
STATE inactive/OK
TYPE HMCCURPCPROC
ccuip 192.168.1.38
ccustate active
ccutype CCU2
host 192.168.1.38
rpcid 001024
rpcinterface VirtualDevices
rpcip 192.168.1.38
rpcport 9292
version 1.0.006
READINGS:
2018-07-18 09:24:08 rpcstate inactive
2018-07-18 09:24:08 state OK
hmccu:
defaultaddr 192.168.1.24
evtime 0
localaddr 192.168.1.24
rpcstarttime 0
rpc:
cbport 14702
clkey
evtime 1531898622
pid
state inactive
sumdelay 0
rec:
DD 0
EV 0
EX 0
IN 0
ND 0
RA 0
RD 0
SL 1
TO 0
UD 0
snd:
DD 0
EV 0
EX 0
IN 0
ND 0
RA 0
RD 0
SL 0
TO 0
UD 0
Attributes:
group - Zentrale
room HM HomeMatic
stateFormat rpcstate/state
verbose 2
und im Logfile gibt es keine Meldung "No I/O device found for ..."
2018.07.18 09:23:21 1: Including fhem.cfg
...
2018.07.18 09:23:25 1: HMCCU: Device HM_HomeMatic__Zentrale2__HMCCU. Initialized version 4.2.008
2018.07.18 09:23:25 1: HMCCU: Read 41 devices with 232 channels from CCU 192.168.1.38
2018.07.18 09:23:25 1: HMCCU: Read 3 interfaces from CCU 192.168.1.38
2018.07.18 09:23:25 1: HMCCURPCPROC: [HM_HomeMatic__rpcBidCos_RF__HMCCURPCPROC] Initialized version 1.0.006 for interface BidCos-RF with I/O device HM_HomeMatic__Zentrale2__HMCCU
...
2018.07.18 09:23:28 1: HMCCURPCPROC: [d_rpcVirtualDevices] Initialized version 1.0.006 for interface VirtualDevices with I/O device HM_HomeMatic__Zentrale2__HMCCU
2018.07.18 09:23:28 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4326, <$fh> line 40.
2018.07.18 09:23:28 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/88_HMCCU.pm line 2247, <$fh> line 40.
2018.07.18 09:23:28 1: ERROR: empty name in readingsBeginUpdate
2018.07.18 09:23:28 1: stacktrace:
2018.07.18 09:23:28 1: main::readingsBeginUpdate called by fhem.pl (4711)
2018.07.18 09:23:28 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.18 09:23:28 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.18 09:23:28 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (667)
2018.07.18 09:23:28 1: main::HMCCURPCPROC_ResetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (307)
2018.07.18 09:23:28 1: main::HMCCURPCPROC_Define called by fhem.pl (3584)
2018.07.18 09:23:28 1: main::CallFn called by fhem.pl (1974)
2018.07.18 09:23:28 1: main::CommandDefine called by fhem.pl (1209)
2018.07.18 09:23:28 1: main::AnalyzeCommand called by fhem.pl (1059)
2018.07.18 09:23:28 1: main::AnalyzeCommandChain called by fhem.pl (1347)
2018.07.18 09:23:28 1: main::CommandInclude called by fhem.pl (577)
2018.07.18 09:23:28 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 4566, <$fh> line 40.
2018.07.18 09:23:28 1: readingsUpdate(,rpcstate,inactive) missed to call readingsBeginUpdate first.
2018.07.18 09:23:28 1: stacktrace:
2018.07.18 09:23:28 1: main::readingsBulkUpdate called by fhem.pl (4712)
2018.07.18 09:23:28 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.18 09:23:28 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.18 09:23:28 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (667)
2018.07.18 09:23:28 1: main::HMCCURPCPROC_ResetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (307)
2018.07.18 09:23:28 1: main::HMCCURPCPROC_Define called by fhem.pl (3584)
2018.07.18 09:23:28 1: main::CallFn called by fhem.pl (1974)
2018.07.18 09:23:28 1: main::CommandDefine called by fhem.pl (1209)
2018.07.18 09:23:28 1: main::AnalyzeCommand called by fhem.pl (1059)
2018.07.18 09:23:28 1: main::AnalyzeCommandChain called by fhem.pl (1347)
2018.07.18 09:23:28 1: main::CommandInclude called by fhem.pl (577)
2018.07.18 09:23:28 1: PERL WARNING: Use of uninitialized value $type in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 2162, <$fh> line 40.
2018.07.18 09:23:28 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 2162, <$fh> line 40.
2018.07.18 09:23:28 1: : [] All RPC servers inactive
2018.07.18 09:23:28 1: PERL WARNING: Use of uninitialized value $dev in hash element at fhem.pl line 3456, <$fh> line 40.
2018.07.18 09:23:28 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 2220, <$fh> line 40.
...
2018.07.18 09:23:29 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
...
2018.07.18 09:23:31 0: Featurelevel: 5.8
2018.07.18 09:23:31 0: Server started with 365 defined entities (fhem.pl:16866/2018-06-14 perl:5.024001 os:linux user:fhem pid:13550)
2018.07.18 09:23:32 1: PERL WARNING: Argument ".*" isn't numeric in numeric lt (<) at fhem.pl line 4610.
...
2018.07.18 09:23:41 2: HMCCURPCPROC: [HM_HomeMatic__rpcBidCos_RF__HMCCURPCPROC] RPC server process started for interface BidCos-RF with PID=13563
2018.07.18 09:23:41 2: CCURPC: [HM_HomeMatic__rpcBidCos_RF__HMCCURPCPROC] Initializing RPC server CB2001001024 for interface BidCos-RF
2018.07.18 09:23:41 1: HMCCURPCPROC: [HM_HomeMatic__rpcBidCos_RF__HMCCURPCPROC] RPC server starting
2018.07.18 09:23:41 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4326.
2018.07.18 09:23:41 1: PERL WARNING: Use of uninitialized value $interface in concatenation (.) or string at ./FHEM/88_HMCCURPCPROC.pm line 1206.
2018.07.18 09:23:41 2: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server process started for interface with PID=13564
2018.07.18 09:23:41 1: PERL WARNING: Use of uninitialized value $iface in concatenation (.) or string at ./FHEM/88_HMCCURPCPROC.pm line 1626.
2018.07.18 09:23:41 2: CCURPC: [d_rpcVirtualDevices] Initializing RPC server CB9292001024 for interface
2018.07.18 09:23:41 1: PERL WARNING: Use of uninitialized value $prot in string eq at ./FHEM/88_HMCCURPCPROC.pm line 1031.
2018.07.18 09:23:41 1: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server starting
2018.07.18 09:23:41 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/88_HMCCU.pm line 2247.
2018.07.18 09:23:41 1: ERROR: empty name in readingsBeginUpdate
2018.07.18 09:23:41 1: stacktrace:
2018.07.18 09:23:41 1: main::readingsBeginUpdate called by fhem.pl (4711)
2018.07.18 09:23:41 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.18 09:23:41 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.18 09:23:41 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (1228)
2018.07.18 09:23:41 1: main::HMCCURPCPROC_StartRPCServer called by ./FHEM/88_HMCCU.pm (3190)
2018.07.18 09:23:41 1: main::HMCCU_StartExtRPCServer called by fhem.pl (3127)
2018.07.18 09:23:41 1: main::HandleTimeout called by fhem.pl (646)
2018.07.18 09:23:41 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 4566.
2018.07.18 09:23:41 1: readingsUpdate(,rpcstate,starting) missed to call readingsBeginUpdate first.
2018.07.18 09:23:41 1: stacktrace:
2018.07.18 09:23:41 1: main::readingsBulkUpdate called by fhem.pl (4712)
2018.07.18 09:23:41 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.18 09:23:41 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.18 09:23:41 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (1228)
2018.07.18 09:23:41 1: main::HMCCURPCPROC_StartRPCServer called by ./FHEM/88_HMCCU.pm (3190)
2018.07.18 09:23:41 1: main::HMCCU_StartExtRPCServer called by fhem.pl (3127)
2018.07.18 09:23:41 1: main::HandleTimeout called by fhem.pl (646)
2018.07.18 09:23:41 1: PERL WARNING: Use of uninitialized value $dev in hash element at fhem.pl line 3456.
2018.07.18 09:23:41 1: PERL WARNING: Use of uninitialized value $type in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 2162.
2018.07.18 09:23:41 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 2162.
2018.07.18 09:23:41 1: : [] All RPC servers starting
2018.07.18 09:23:41 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 2220.
2018.07.18 09:23:41 2: HMCCURPCPROC: [HM_HomeMatic__rpcBidCos_RF__HMCCURPCPROC] Callback server CB2001001024 created. Listening on port 7411
2018.07.18 09:23:41 2: CCURPC: [HM_HomeMatic__rpcBidCos_RF__HMCCURPCPROC] CB2001001024 accepting connections. PID=13563
2018.07.18 09:23:41 2: HMCCURPCPROC: [d_rpcVirtualDevices] Callback server CB9292001024 created. Listening on port 14702
2018.07.18 09:23:41 2: CCURPC: [d_rpcVirtualDevices] CB9292001024 accepting connections. PID=13564
2018.07.18 09:23:42 2: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server CB9292001024 enters server loop
2018.07.18 09:23:42 1: ERROR: empty name in readingsBeginUpdate
2018.07.18 09:23:42 1: stacktrace:
2018.07.18 09:23:42 1: main::readingsBeginUpdate called by fhem.pl (4711)
2018.07.18 09:23:42 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.18 09:23:42 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.18 09:23:42 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (773)
2018.07.18 09:23:42 1: main::HMCCURPCPROC_ProcessEvent called by ./FHEM/88_HMCCURPCPROC.pm (531)
2018.07.18 09:23:42 1: main::HMCCURPCPROC_Read called by fhem.pl (3584)
2018.07.18 09:23:42 1: main::CallFn called by fhem.pl (723)
2018.07.18 09:23:42 1: readingsUpdate(,rpcstate,working) missed to call readingsBeginUpdate first.
2018.07.18 09:23:42 1: stacktrace:
2018.07.18 09:23:42 1: main::readingsBulkUpdate called by fhem.pl (4712)
2018.07.18 09:23:42 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.18 09:23:42 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.18 09:23:42 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (773)
2018.07.18 09:23:42 1: main::HMCCURPCPROC_ProcessEvent called by ./FHEM/88_HMCCURPCPROC.pm (531)
2018.07.18 09:23:42 1: main::HMCCURPCPROC_Read called by fhem.pl (3584)
2018.07.18 09:23:42 1: main::CallFn called by fhem.pl (723)
2018.07.18 09:23:42 1: : [] All RPC servers working
2018.07.18 09:23:42 1: HMCCURPCPROC: [d_rpcVirtualDevices] Can't get RPC parameters for ID CB9292001024
2018.07.18 09:23:42 1: ERROR: empty name in readingsBeginUpdate
2018.07.18 09:23:42 1: stacktrace:
2018.07.18 09:23:42 1: main::readingsBeginUpdate called by fhem.pl (4711)
2018.07.18 09:23:42 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.18 09:23:42 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.18 09:23:42 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (776)
2018.07.18 09:23:42 1: main::HMCCURPCPROC_ProcessEvent called by ./FHEM/88_HMCCURPCPROC.pm (531)
2018.07.18 09:23:42 1: main::HMCCURPCPROC_Read called by fhem.pl (3584)
2018.07.18 09:23:42 1: main::CallFn called by fhem.pl (723)
2018.07.18 09:23:42 1: readingsUpdate(,rpcstate,error) missed to call readingsBeginUpdate first.
2018.07.18 09:23:42 1: stacktrace:
2018.07.18 09:23:42 1: main::readingsBulkUpdate called by fhem.pl (4712)
2018.07.18 09:23:42 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.18 09:23:42 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.18 09:23:42 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (776)
2018.07.18 09:23:42 1: main::HMCCURPCPROC_ProcessEvent called by ./FHEM/88_HMCCURPCPROC.pm (531)
2018.07.18 09:23:42 1: main::HMCCURPCPROC_Read called by fhem.pl (3584)
2018.07.18 09:23:42 1: main::CallFn called by fhem.pl (723)
2018.07.18 09:23:42 1: : [] All RPC servers error
2018.07.18 09:23:42 2: HMCCURPCPROC: [HM_HomeMatic__rpcBidCos_RF__HMCCURPCPROC] RPC server CB2001001024 enters server loop
2018.07.18 09:23:42 2: HMCCURPCPROC: [HM_HomeMatic__rpcBidCos_RF__HMCCURPCPROC] Registering callback http://192.168.1.24:7411/fh2001 of type A with ID CB2001001024 at http://192.168.1.38:2001
2018.07.18 09:23:42 1: HMCCURPCPROC: [HM_HomeMatic__rpcBidCos_RF__HMCCURPCPROC] RPC server CB2001001024 running
2018.07.18 09:23:43 2: CCURPC: [HM_HomeMatic__rpcBidCos_RF__HMCCURPCPROC] CB2001001024 NewDevice received 233 device and channel specifications
2018.07.18 09:24:06 2: HMCCURPCPROC: [d_rpcVirtualDevices] Checking if RPC server process is running
2018.07.18 09:24:06 1: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server process not running. Cleaning up
2018.07.18 09:24:06 1: HMCCURPCPROC: [d_rpcVirtualDevices] Housekeeping called. Cleaning up RPC environment
2018.07.18 09:24:06 2: HMCCURPCPROC: [d_rpcVirtualDevices] Sending signal INT to RPC server process CB9292001024 with PID=13564
2018.07.18 09:24:06 1: ERROR: empty name in readingsBeginUpdate
2018.07.18 09:24:06 1: stacktrace:
2018.07.18 09:24:06 1: main::readingsBeginUpdate called by fhem.pl (4711)
2018.07.18 09:24:06 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.18 09:24:06 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.18 09:24:06 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (1328)
2018.07.18 09:24:06 1: main::HMCCURPCPROC_TerminateProcess called by ./FHEM/88_HMCCURPCPROC.pm (1433)
2018.07.18 09:24:06 1: main::HMCCURPCPROC_Housekeeping called by ./FHEM/88_HMCCURPCPROC.pm (1410)
2018.07.18 09:24:06 1: main::HMCCURPCPROC_IsRPCServerRunning called by fhem.pl (3127)
2018.07.18 09:24:06 1: main::HandleTimeout called by fhem.pl (646)
2018.07.18 09:24:06 1: readingsUpdate(,rpcstate,stopping) missed to call readingsBeginUpdate first.
2018.07.18 09:24:06 1: stacktrace:
2018.07.18 09:24:06 1: main::readingsBulkUpdate called by fhem.pl (4712)
2018.07.18 09:24:06 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.18 09:24:06 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.18 09:24:06 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (1328)
2018.07.18 09:24:06 1: main::HMCCURPCPROC_TerminateProcess called by ./FHEM/88_HMCCURPCPROC.pm (1433)
2018.07.18 09:24:06 1: main::HMCCURPCPROC_Housekeeping called by ./FHEM/88_HMCCURPCPROC.pm (1410)
2018.07.18 09:24:06 1: main::HMCCURPCPROC_IsRPCServerRunning called by fhem.pl (3127)
2018.07.18 09:24:06 1: main::HandleTimeout called by fhem.pl (646)
2018.07.18 09:24:06 1: : [] All RPC servers stopping
2018.07.18 09:24:06 2: CCURPC: [d_rpcVirtualDevices] CB9292001024 received signal INT
2018.07.18 09:24:06 1: CCURPC: [d_rpcVirtualDevices] RPC server CB9292001024 stopped handling connections. PID=13564
2018.07.18 09:24:06 1: PERL WARNING: Use of uninitialized value $prot in string eq at ./FHEM/88_HMCCURPCPROC.pm line 1709.
2018.07.18 09:24:06 2: CCURPC: [d_rpcVirtualDevices] Number of I/O errors = 0
2018.07.18 09:24:08 2: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server process CB9292001024 deleted
2018.07.18 09:24:08 1: ERROR: empty name in readingsBeginUpdate
2018.07.18 09:24:08 1: stacktrace:
2018.07.18 09:24:08 1: main::readingsBeginUpdate called by fhem.pl (4711)
2018.07.18 09:24:08 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.18 09:24:08 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.18 09:24:08 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (1363)
2018.07.18 09:24:08 1: main::HMCCURPCPROC_CleanupProcess called by ./FHEM/88_HMCCURPCPROC.pm (1276)
2018.07.18 09:24:08 1: main::HMCCURPCPROC_RPCServerStopped called by ./FHEM/88_HMCCURPCPROC.pm (1436)
2018.07.18 09:24:08 1: main::HMCCURPCPROC_Housekeeping called by ./FHEM/88_HMCCURPCPROC.pm (1410)
2018.07.18 09:24:08 1: main::HMCCURPCPROC_IsRPCServerRunning called by fhem.pl (3127)
2018.07.18 09:24:08 1: main::HandleTimeout called by fhem.pl (646)
2018.07.18 09:24:08 1: readingsUpdate(,rpcstate,inactive) missed to call readingsBeginUpdate first.
2018.07.18 09:24:08 1: stacktrace:
2018.07.18 09:24:08 1: main::readingsBulkUpdate called by fhem.pl (4712)
2018.07.18 09:24:08 1: main::readingsSingleUpdate called by ./FHEM/88_HMCCU.pm (2249)
2018.07.18 09:24:08 1: main::HMCCU_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (645)
2018.07.18 09:24:08 1: main::HMCCURPCPROC_SetRPCState called by ./FHEM/88_HMCCURPCPROC.pm (1363)
2018.07.18 09:24:08 1: main::HMCCURPCPROC_CleanupProcess called by ./FHEM/88_HMCCURPCPROC.pm (1276)
2018.07.18 09:24:08 1: main::HMCCURPCPROC_RPCServerStopped called by ./FHEM/88_HMCCURPCPROC.pm (1436)
2018.07.18 09:24:08 1: main::HMCCURPCPROC_Housekeeping called by ./FHEM/88_HMCCURPCPROC.pm (1410)
2018.07.18 09:24:08 1: main::HMCCURPCPROC_IsRPCServerRunning called by fhem.pl (3127)
2018.07.18 09:24:08 1: main::HandleTimeout called by fhem.pl (646)
2018.07.18 09:24:08 1: : [] All RPC servers inactive
2018.07.18 09:24:08 2: HMCCURPCPROC: [d_rpcVirtualDevices] Stop I/O handling
Abhilfe wird vermutlich schaffen, wenn Du das Attribut stateFormate im IO Device auf "rpcstate/state" setzt.
Oder du wartest auf das nächste Update. Ich muss mir aber erst mal einen einigermaßen schlauen Weg überlegen, wie ich FHEM hier austricksen kann.
Die Fehlermeldung "No I/O device" kommt nur bei Verbose >= 3. Daher siehst Du die nicht.
Ich habe das Attribut stateFormate jetzt auf "rpcstate/state" gesetzt und damit funktioniert es.
Vielen Dank noch einmal für Deine Hilfe!!!
übrigens funktioniert es so auch mit
define ... HMCCURPCPROC 192.168.1.38 VirtualDevices
also ohne iodev= Parameter
In fhem.pl wurde inzwischen die entsprechende Funktion angepasst. Nach dem nächsten FHEM Update sollte also auch Deine bisherige stateFormat Angabe funktionieren.
Hallo zusammen,
ich habe heute versucht einen neuen HmIP-SLO (Lichtsensor) in Betrieb zu nehmen. Die CCU2 erkennt ihn und ich kann ihn ganz normal anlernen, konfigurieren etc.
Über HMCCU will sich das Gerät nicht anlegen lassen.
Ein get devicelist create HM_Lichtsensor f=HmIP-Lichtsensor
führt zu einem:
Read 30 devices with 220 channels from CCU
Created 0 client devices
Das Gerät gibt es nicht...selbst mit duplicates wird nichts angelegt.
Das Gerät kann ich mir aber per DeviceInfo anzeigen lassen:
CHN 000D58A98FACC8:0 HmIP-Lichtsensor:0
DPT {b} HmIP-RF.000D58A98FACC8:0.CONFIG_PENDING = false [RE]
DPT {b} HmIP-RF.000D58A98FACC8:0.DUTY_CYCLE = false [RE]
DPT {b} HmIP-RF.000D58A98FACC8:0.INSTALL_TEST = false [RW]
DPT {b} HmIP-RF.000D58A98FACC8:0.LOW_BAT = false [RE]
DPT {f} HmIP-RF.000D58A98FACC8:0.OPERATING_VOLTAGE = 3.100000 [RE]
DPT {i} HmIP-RF.000D58A98FACC8:0.OPERATING_VOLTAGE_STATUS = 0 [RE]
DPT {n} HmIP-RF.000D58A98FACC8:0.RSSI_DEVICE = 203 [RE]
DPT {n} HmIP-RF.000D58A98FACC8:0.RSSI_PEER = 0 [RE]
DPT {b} HmIP-RF.000D58A98FACC8:0.UNREACH = false [RE]
DPT {b} HmIP-RF.000D58A98FACC8:0.UPDATE_PENDING = false [RE]
CHN 000D58A98FACC8:1 HmIP-SLO 000D58A98FACC8:1
DPT {f} HmIP-RF.000D58A98FACC8:1.AVERAGE_ILLUMINATION = 0.280000 [RE]
DPT {i} HmIP-RF.000D58A98FACC8:1.AVERAGE_ILLUMINATION_STATUS = 0 [RE]
DPT {f} HmIP-RF.000D58A98FACC8:1.CURRENT_ILLUMINATION = 0.280000 [RE]
DPT {i} HmIP-RF.000D58A98FACC8:1.CURRENT_ILLUMINATION_STATUS = 0 [RE]
DPT {f} HmIP-RF.000D58A98FACC8:1.HIGHEST_ILLUMINATION = 0.290000 [RE]
DPT {i} HmIP-RF.000D58A98FACC8:1.HIGHEST_ILLUMINATION_STATUS = 0 [RE]
DPT {f} HmIP-RF.000D58A98FACC8:1.LOWEST_ILLUMINATION = 0.280000 [RE]
DPT {i} HmIP-RF.000D58A98FACC8:1.LOWEST_ILLUMINATION_STATUS = 0 [RE]
Im Log ist nichts ....
Wo ist mein Denkfehler? Liegt es am Device? An HMCCU (4.2.008)? An mir?
Danke für einen Schubser!
Viele Grüße
Christian
Der heißt tatsächlich HmIP-Lichtsensor in der CCU? Aus der Deviceinfo kann ich nur die Namen der Kanäle entnehmen.
Funktioniert ein
define HM_Lichtsensor HMCCUDEV HmIP-Lichtsensor
?
Guten Morgen,
ja, so heißt er. Sieht man auch immer am Namen von Kanal 0: CHN 000D58A98FACC8:0 HmIP-Lichtsensor:0
Sehr seltsam. Per Define hat es sofort geklappt.
Muss ich das verstehen?
Und noch 2 Fragen:
Ich dachte immer "Stripnumber 0" schneidet alle Nachkommastellen ab.
Aktuell werden - zumindest bei diesem Sensor - alle 5 Nachkommastellen angezeigt.
Bei "Stripnumber 1" wird korrekterweise genau 1 Stelle angezeigt.
Als CCUREADINGFILTER "^AVERAGE_ILLUMINATION" zeigt beide Readings (1.AVERAGE_ILLUMINATION und 1.AVERAGE_ILLUMINATION_STATUS). Soweit korrekt.
Als CCUREADINGFILTER "1.AVERAGE_ILLUMINATION" werden aber beide Readings rausgefiltert..jetzt bin ich verwirrt.
Ist bei mir ein Geist eingezogen? ???
Zitat von: Chris8888 am 26 Juli 2018, 09:15:10
Ich dachte immer "Stripnumber 0" schneidet alle Nachkommastellen ab.
Aktuell werden - zumindest bei diesem Sensor - alle 5 Nachkommastellen angezeigt.
Bei "Stripnumber 1" wird korrekterweise genau 1 Stelle angezeigt.
0 bedeutet: Lass alles so wie es ist.
Mit -0 wird auf 0 Nachkommastellen gerundet.
Ich werde das aber anpassen:
0 = Schneide alle Nachkommastellen ab
-0 = Runde auf 0 Nachkommastellen
wieder was gelernt. Danke!
Hast du zu dem Rest eine Idee?
VG
Christian
Hallo Zap,
ich habe aktuell ein paar seltsame Anzeigen über HMCCU und dem neuen IP-Lichtsensor.
ccureadingsname mit "1.CURRENT_ILLUMINATION:+luminosity" erzeugt doch ein zusätzliches Reading "luminosity" mit dem gleichen Inhalt wie 1.CURRENT_ILLUMINATION?
Aus dem Eventmonitor:
2018-07-27 14:04:02 HMCCUDEV HM_Lichtsensor 1.CURRENT_ILLUMINATION: 37370
2018-07-27 14:04:02 HMCCUDEV HM_Lichtsensor luminosity: 37370
2018-07-27 14:04:02 HMCCUDEV HM_Lichtsensor control: 37370
2018-07-27 14:04:02 HMCCUDEV HM_Lichtsensor 37370
2018-07-27 14:04:02 HMCCUDEV HM_Lichtsensor luminosity: 0
2018-07-27 14:04:02 HMCCUDEV HM_Lichtsensor hmstate: 37370
Bei jedem 2-3 Event ist das Reading luminosity aber "0", anstatt (wie hier) 37370.
2 Minuten später:
2018-07-27 14:06:52 HMCCUDEV HM_Lichtsensor 1.CURRENT_ILLUMINATION: 37830
2018-07-27 14:06:52 HMCCUDEV HM_Lichtsensor luminosity: 37830
2018-07-27 14:06:52 HMCCUDEV HM_Lichtsensor control: 37830
2018-07-27 14:06:52 HMCCUDEV HM_Lichtsensor 37830
2018-07-27 14:06:52 HMCCUDEV HM_Lichtsensor hmstate: 37830
Alles richtig.
Das verstehe ich nicht.
Weiterhin bekomme ich den Readingfilter nicht hin.
Als CCUREADINGFILTER "^AVERAGE_ILLUMINATION" zeigt beide Readings (1.AVERAGE_ILLUMINATION und 1.AVERAGE_ILLUMINATION_STATUS). Soweit korrekt.
Als CCUREADINGFILTER "1.AVERAGE_ILLUMINATION" werden aber beide Readings rausgefiltert....
Ich möchte gerne das Reading "1.AVERAGE_ILLUMINATION" anzeigen, das Reading "1.AVERAGE_ILLUMINATION_STATUS" rausfiltern.
Wo liegt mein Fehler?
Ist mir zur zu warm? :-)
Danke vorab für einen Tipp!
Viele Grüße
Christian
Mir ist auch warm ;-)
Möglicherweise gibts einen Bug wenn man die Kanalnummer im Readingfilter angibt.
Workaround im konkreten Fall: ^AVERAGE_ILLUMINATION$
Muss das mal testen mit der Kanalnummer. Bin gerade von ner Radtour gekommen bei gefühlt 50 Grad und kaum in der Lage, das Tablet zu halten geschweige denn am PC irgendwas auszuprobieren :-\
Hallo zusammen,
ich habe mal eine Frage zu der Aktualisierungsgeschwindigkeit.
Und zwar dauert es bei mir gute 3-5 Sekunden bis sich der Status eines Lichtschalters ändert.
Heisst - ich schalte das Licht manuell am Schalter und nach 3-5 Sekunden bekommt es FHEM auch mit.
Nach dem was ich hier so lese ist das nicht normal oder? Hat jemand einen Tipp, was ich tun kann?
Benutze HMCCURPCPROC.
Attributes:
ccudef-readingfilter ^(LOW_?BAT|UNREACH)\$
ccudef-readingformat datapoint
ccudef-readingname ^(.+\.)?AES_KEY\$:sign;^(.+\.)?LOW_?BAT\$:battery;^(.+\.)?BATTERY_STATE\$:batteryLevel;^(.+\.)?UNREACH\$:Activity;^(.+\.)?TEMPERATURE\$:+temperature;^(.+\.)?SET_TEMPERATURE\$:+desired-temp;^(.+\.)?HUMIDITY\$:+humidity;^(.+\.)?LEVEL\$:+pct;^(.+\.)?CONTROL_MODE\$:+controlMode
ccudef-substitute AES_KEY!(0|false):off,(1|true):on;LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;UNREACH!(0|false):alive,(1|true):dead;MOTION!(0|false):noMotion,(1|true):motion;DIRECTION!0:stop,1:up,2:down,3:undefined;WORKING!0:false,1:true;INHIBIT!(0|false):unlocked,(1|true):locked
ccuflags procrpc
cmdIcon on:general_an off:general_aus
event-on-change-reading .*
eventMap /rpcserver on:on/rpcserver off:off/
room Steuerung
rpcinterfaces HmIP-RF
rpcinterval 5
rpcport 2010
rpcqueue /tmp/ccuqueue
rpcserver on
stateFormat rpcstate/state
stripnumber 1
Vielen Dank.
Normal für den HMCCUPROC PC sind bei mir deutlich kleiner 1 Sekunde.
Betrifft das nur Schalter oder auch andere Geräte? Wenn Du zum Beispiel die Temperatur eines Thermostaten änderst, wie schnell kommt dann die geänderte Temp im Reading an?
Kann auch an der CCU liegen. Vielleicht mal neu starten
Ich habe bisher nur einen IP-Schalter, sonst nix.
An der CCU liegt es IMHO nicht.
Sind die Attribute ok (siehe oben) ? Oder fehlt was bzw. ist falsch?
Rpcinterval und rpcqueue brauchst du bei procrpc nicht.
Mach mal ein list von dem Schalter Device.
Da würde ich auch gerne mal nachhaken.
Bei mir dauert es auch ca. 5 sekunden, bis das FTUI die Aktualisierung anzeigt bzw. das Reading in fhem
aktualisiert wird.
Getestet habe ich das mit den Schalt-Mess-Steckdosen HMIP-PSM (hab da ne Lampe dran hängen)
und einem Wandthermostaten HmIP-WTH-2.
Das ist zwar nicht sonderlich schlimm, aber wenn es anders geht, warum nicht?
Ich nutze Fhem auf dem Pi 3 mit dem HM-MOD-RPI-PCB und yahm.
Hier mal ein List vom WTH
Internals:
DEF WTH.Wohnzimmer
IODev CCU2
NAME WTH.Wohnzimmer
NR 148
STATE 22.7
TYPE HMCCUDEV
ccuaddr 000A9709AAC591
ccudevstate active
ccuif HmIP-RF
ccuname WTH.Wohnzimmer
ccutype HmIP-WTH-2
channels 8
firmware 1.8.0
statevals devstate
READINGS:
2018-09-01 22:34:05 0.CONFIG_PENDING 0
2018-09-01 22:34:05 0.DUTY_CYCLE 0
2018-09-01 00:45:34 0.INSTALL_TEST true
2018-09-01 22:34:05 0.LOW_BAT 0
2018-09-01 22:34:05 0.OPERATING_VOLTAGE 2.8
2018-09-01 22:34:05 0.OPERATING_VOLTAGE_STATUS 0
2018-09-01 22:34:05 0.RSSI_DEVICE -66
2018-09-01 22:16:30 0.RSSI_PEER -66
2018-09-01 22:34:05 0.UNREACH 0
2018-09-01 00:45:34 0.UPDATE_PENDING false
2018-09-01 22:34:05 1.ACTIVE_PROFILE 1
2018-09-01 22:34:05 1.ACTUAL_TEMPERATURE 22.7
2018-09-01 22:34:05 1.ACTUAL_TEMPERATURE_STATUS 0
2018-09-01 22:34:05 1.BOOST_MODE 0
2018-09-01 22:34:05 1.BOOST_TIME 0
2018-09-01 22:34:05 1.FROST_PROTECTION 0
2018-09-01 22:34:05 1.HEATING_COOLING 0
2018-09-01 22:34:05 1.HUMIDITY 49
2018-09-01 22:34:05 1.HUMIDITY_STATUS 0
2018-09-01 22:34:05 1.PARTY_MODE 0
2018-09-01 00:45:34 1.PARTY_SET_POINT_TEMPERATURE 0.0
2018-09-01 00:45:34 1.PARTY_TIME_END
2018-09-01 00:45:34 1.PARTY_TIME_START
2018-09-01 22:34:05 1.QUICK_VETO_TIME 0
2018-09-01 22:34:05 1.SET_POINT_MODE 1
2018-09-01 22:34:05 1.SET_POINT_TEMPERATURE off
2018-09-01 22:34:05 1.SWITCH_POINT_OCCURED 0
2018-09-01 22:34:05 1.WINDOW_STATE closed
2018-09-01 10:31:46 color ffffff
2018-09-01 22:34:05 control 4.5
2018-09-01 22:34:05 hmstate off
2018-09-01 22:34:05 state off
hmccu:
dp:
0.CONFIG_PENDING:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.DUTY_CYCLE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.INSTALL_TEST:
OSVAL true
OVAL true
SVAL true
VAL true
0.LOW_BAT:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.OPERATING_VOLTAGE:
OSVAL 2.8
OVAL 2.8
SVAL 2.8
VAL 2.8
0.OPERATING_VOLTAGE_STATUS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.RSSI_DEVICE:
OSVAL -63
OVAL -63
SVAL -66
VAL -66
0.RSSI_PEER:
OSVAL -66
OVAL -66
SVAL -66
VAL -66
0.UNREACH:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
0.UPDATE_PENDING:
OSVAL false
OVAL false
SVAL false
VAL false
1.ACTIVE_PROFILE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.ACTUAL_TEMPERATURE:
OSVAL 22.5
OVAL 22.5
SVAL 22.7
VAL 22.7
1.ACTUAL_TEMPERATURE_STATUS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.BOOST_MODE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.BOOST_TIME:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.FROST_PROTECTION:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.HEATING_COOLING:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.HUMIDITY:
OSVAL 52
OVAL 52
SVAL 49
VAL 49
1.HUMIDITY_STATUS:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.PARTY_MODE:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.PARTY_SET_POINT_TEMPERATURE:
OSVAL 0.0
OVAL 0.000000
SVAL 0.0
VAL 0.000000
1.PARTY_TIME_END:
OSVAL
OVAL
SVAL
VAL
1.PARTY_TIME_START:
OSVAL
OVAL
SVAL
VAL
1.QUICK_VETO_TIME:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.SET_POINT_MODE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.SET_POINT_TEMPERATURE:
OSVAL off
OVAL 4.5
SVAL off
VAL 4.5
1.SWITCH_POINT_OCCURED:
OSVAL 0
OVAL 0
SVAL 0
VAL 0
1.WINDOW_STATE:
OSVAL closed
OVAL 0
SVAL closed
VAL 0
Attributes:
IODev CCU2
controldatapoint 1.SET_POINT_TEMPERATURE
eventMap /datapoint 1.BOOST_MODE true:Boost/datapoint 1.CONTROL_MODE 0:Auto/datapoint 1.CONTROL_MODE 1:Manual/datapoint 1.CONTROL_MODE 2:Holiday/datapoint 1.SET_POINT_TEMPERATURE 4.5:off/datapoint 1.SET_POINT_TEMPERATURE 30.5:on/
genericDeviceType thermostat
group Heizung
room Homematic
stateFormat 1.ACTUAL_TEMPERATURE
statedatapoint 1.SET_POINT_TEMPERATURE
stripnumber 1
substexcl control
substitute SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open
webCmd control:Boost:Auto:Manual:Holiday:on:off
widgetOverride control:slider,4.5,0.5,30.5,1
Hat jemand einen Rat?
Gruß
Vaddi
Was hast Du im Attribut ccuflags im Device CCU2 eingestellt?
Ich habe das gerade mit meinen 3 HMIP-PSM getestet. Dazu bin ich wie folgt vorgegangen:
- Den FHEM Event Monitor aufgerufen
- Den Event Filter auf die Namen der Devices gesetzt
- Zunächst an der Steckdose den Ein-/Aus-Knopf gedrückt
- Später nochmal per CCU Webinterface geschaltet
In beiden Fällen kommen die Events quasi sofort ohne merkliche Verzögerung in FHEM an. Vielleicht liegt es ja an einer verspäteten Aktualisierung des FHEM Webinterface. Der Event-Monitor und damit entsprechende Notifies oder DOIFs reagieren in quasi Echtzeit.
Du kannst auch mal folgenden Befehl ausführen
get CCU2 rpcevents
Das gibt eine Event-Statistik aus. Interessant ist dabei der Wert "Average Event Delay". Der liegt bei mir im Bereich 1-2 Millisekunden. Das ist schon recht schnell ...
Hey, danke für die Antwort.
ccuflags steht auf procrpc
Hier mal ein list des CCU2 Devices (hab einen teil des textes entfernt, da es sonst zu lang geworden wäre)
Internals:
CCUNum 1
Clients :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
DEF 192.168.10.2 waitforccu=180
NAME CCU2
NOTIFYDEV global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
NR 86
NTFY_ORDER 50-CCU2
RPCState running
STATE running/OK
TYPE HMCCU
ccuaddr BidCoS-RF
ccuchannels 126
ccudevices 13
ccuif BidCos-RF
ccuinterfaces HmIP-RF,BidCos-RF,VirtualDevices
ccuip 192.168.10.2
ccuname HM-RCV-50 BidCoS-RF
ccustate active
ccutype CCU2
host 192.168.10.2
version 4.2.008
READINGS:
2018-02-03 13:00:44 iface_addr_1 OEQ2300662
2018-02-03 13:00:44 iface_addr_2 3014F711A061A7D709AC82F6
2018-02-03 13:00:44 iface_conn_1 1
2018-02-03 13:00:44 iface_conn_2 1
2018-02-03 13:00:44 iface_ducy_1 9
2018-02-03 13:00:44 iface_ducy_2 9
2018-02-03 13:00:44 iface_type_1 CCU2
2018-02-03 13:00:44 iface_type_2 HMIP_CCU2
2018-09-01 23:12:30 rpcstate running
2018-09-01 23:12:32 state OK
hmccu:
evtime 0
evtimeout 0
rpccount 0
rpcports 2001,2010
updatetime 0
adr:
<Großteil entfernt, da es sonst zu lang geworden wäre>
cnt:
ACTIVE_PROFILE 1
ACTUAL_TEMPERATURE 1
ACTUAL_TEMPERATURE_STATUS 1
BOOST_MODE 1
BOOST_TIME 1
CONFIG_PENDING 1
CONTROL_DIFFERENTIAL_TEMPERATURE 1
CONTROL_MODE 1
DURATION_UNIT 1
DURATION_VALUE 1
DUTY_CYCLE 1
FROST_PROTECTION 1
INSTALL_TEST 1
LEVEL 1
LEVEL_STATUS 1
LOW_BAT 1
OPERATING_VOLTAGE 1
OPERATING_VOLTAGE_STATUS 1
PARTY_MODE 1
PARTY_SET_POINT_TEMPERATURE 1
PARTY_TIME_END 1
PARTY_TIME_START 1
QUICK_VETO_TIME 1
RSSI_DEVICE 1
RSSI_PEER 1
SET_POINT_MODE 1
SET_POINT_TEMPERATURE 1
SWITCH_POINT_OCCURED 1
UNREACH 1
UPDATE_PENDING 1
VALVE_ADAPTION 1
VALVE_STATE 1
WINDOW_STATE 1
spc:
level 1.LEVEL
ifports:
2001 BidCos-RF
2010 HmIP-RF
9292 VirtualDevices
interfaces:
BidCos-RF:
device d_rpcBidCos_RF
flags forceASCII
host 192.168.10.2
manager HMCCU
port 2001
prot http
state running
type A
url http://192.168.10.2:2001
HmIP-RF:
device d_rpcHmIP_RF
flags _
host 192.168.10.2
manager HMCCU
port 2010
prot http
state running
type A
url http://192.168.10.2:2010
VirtualDevices:
flags _
host 192.168.10.2
manager null
port 9292
prot http
state inactive
type A
url http://192.168.10.2:9292/groups
rpc:
Attributes:
ccuflags procrpc
cmdIcon on:general_an off:general_aus
eventMap /rpcserver on:on/rpcserver off:off/
icon hm_ccu
room Homematic
rpcinterfaces BidCos-RF,HmIP-RF
rpcinterval 5
rpcport 2001,2010
rpcserver on
stateFormat rpcstate/state
Bin so vorgegangen, wie du es beschrieben hast, aber auch im Eventmonitor dauert es 3-5 Sekunden,
bis was ankommt. Das ganze passiert allerdings nur, wenn ich direkt an der Hardware schalte.
Schalte ich in FHEM, FTUI oder in der CCU2 Weboberfläche, ist die Ausführung und Anzeige im
Eventmonitor direkt und ohne nennenswerte Verzögerung.
Get CCU2 rpcevents liefert
Event statistics for server CB2001010001
Average event delay = 0.0343642611683849
========================================
ET Sent by RPC server Received by FHEM
----------------------------------------
EV 435 582
ND 64 64
DD 0 0
RD 0 0
RA 0 0
UD 0 0
IN 0 0
EX 0 0
SL 1 1
TO 0 0
Event statistics for server CB2010010001
Average event delay = 0.0462580348943985
========================================
ET Sent by RPC server Received by FHEM
----------------------------------------
EV 8406 8712
ND 75 75
DD 0 0
RD 0 0
RA 0 0
UD 0 0
IN 0 0
EX 0 0
SL 1 1
TO 18 18
Im CCU Webinterface unter Einstellungen / Geräte kann man einiges für die Steckdosen einstellen. Hier meine Parameter:
Anzahl auszulassender Statusmeldungen = 1
Verbrauchs-/Leistungsmessungen (hier kommt es aufgrund der Werte zur verzögerten Übertragung an die CCU und damit auch an FHEM):
Eventverzögerung = 3
Zufallsanteil = 1
Mindestabstand = 30
Ich glaube aber ehrlich gesagt nicht, dass die o.g. Werte Schuld an dem Verhalten haben.
Update: Ich kann das Verhalten bestätigen. Ich hatte das manuelle Schalten an der Steckdose nur mit einer von dreien ausprobiert und wohl gerade mal Glück gehabt.
Das manuelle Einschalten wird tatsächlich (manchmal) erst nach 3-5 Sekunden in der CCU signalisiert (und damit auch in FHEM). Die Steckdose scheint das erst verzögert an die CCU zu schicken. Bei mehreren Versuchen hatte ich jetzt wieder einen mit 1 Sekunde, dann aber wieder welche mit 5 Sekunden.
Bei Schaltern ist das definitiv nicht so. Ich schalte z.B. einen SONOS Lautsprecher per Homematic Wandschalter. Das reagiert sofort.
Ich habe das jetzt mal mit einer Homematic Classic Steckdose vom Typ HM-ES-PMSw1-Pl probiert. Der reagiert deutlich schneller, ich würde sagen in 1-2 Sekunden
Hallo, nach einigen weiteren Tests konnte ich folgendes verzeichnen:
Nicht Verbrauchs-/Leistungsmessungen verursachen die Verzögerungen, sondern
Channel 2 Statusmitteilung Relais, hier lediglich die Evetverzögerung (default 3 Sek)
runter schrauben.
Ich möchte hier gerne noch ein weiteres Problem ansprechen, welches mir immer erst in den Sinn kommt,
wenn ich den RPi neu starte und erst mit dem neuen RPC Server bei mir anfing.
So sieht mein Log nach einem Neustart aus
2018.09.04 17:42:18 1: HMCCU: Device CCU2. Initialized version 4.2.008
2018.09.04 17:42:18 2: HMCCU: HMScript failed. 500 Internal Server Error
2018.09.04 17:42:18 1: HMCCU: No devices read from CCU 192.168.10.2
2018.09.04 17:42:18 1: HMCCU: No RPC interfaces found on CCU 192.168.10.2
2018.09.04 17:42:18 3: Illegal RPC interface BidCos-RF
2018.09.04 17:42:18 3: HMCCU: Illegal RPC port 2001
2018.09.04 17:42:19 2: FBH.Badezimmer: Unknown sensor device WTH.Badezimmer specified
2018.09.04 17:42:19 2: FBH.Badezimmer: Unknown sensor device WTH.Badezimmer specified
2018.09.04 17:42:19 2: FBH.Kinderzimmer: Unknown sensor device WTH.Kinderzimmer specified
2018.09.04 17:42:19 2: FBH.Kinderzimmer: Unknown sensor device WTH.Kinderzimmer specified
2018.09.04 17:42:19 2: FBH.Wohnzimmer: Unknown sensor device WTH.Wohnzimmer specified
2018.09.04 17:42:19 2: FBH.Wohnzimmer: Unknown sensor device WTH.Wohnzimmer specified
2018.09.04 17:42:19 2: T_TempUeberwachung.WZ: Unknown sensor device WTH.Wohnzimmer specified
2018.09.04 17:42:19 2: T_TempUeberwachung.WZ: Unknown sensor device WTH.Wohnzimmer specified
2018.09.04 17:42:19 2: T_TempUeberwachung.KZ: Unknown sensor device WTH.Kinderzimmer specified
2018.09.04 17:42:19 2: T_TempUeberwachung.KZ: Unknown sensor device WTH.Kinderzimmer specified
2018.09.04 17:42:19 2: T_TempUeberwachung.BZ: Unknown sensor device WTH.Badezimmer specified
2018.09.04 17:42:19 2: T_TempUeberwachung.BZ: Unknown sensor device WTH.Badezimmer specified
2018.09.04 17:42:20 3: Opening Pilight device localhost:5000
2018.09.04 17:42:20 3: Pilight device opened
2018.09.04 17:42:20 1: define d_rpcBidCos_RF HMCCURPCPROC 192.168.10.2 BidCos-RF: Can't find HMCCU I/O device
2018.09.04 17:42:20 1: define d_rpcHmIP_RF HMCCURPCPROC 192.168.10.2 HmIP-RF: Can't find HMCCU I/O device
2018.09.04 17:42:21 1: define HM.SD.WZ.TV HMCCUDEV HM.SD.WZ.TV: Cannot detect IO device
2018.09.04 17:42:21 1: define HM.SD.K.WM HMCCUDEV HM.SD.K.WM: Cannot detect IO device
2018.09.04 17:42:21 1: define WTH.Kinderzimmer HMCCUDEV WTH.Kinderzimmer: Cannot detect IO device
2018.09.04 17:42:21 1: define WTH.Badezimmer HMCCUDEV WTH.Badezimmer: Cannot detect IO device
2018.09.04 17:42:21 1: define HM.Bewegungsmelder HMCCUDEV Einfahrt: Cannot detect IO device
2018.09.04 17:42:21 1: define TH.Badezimmer HMCCUDEV TH.Badezimmer: Cannot detect IO device
2018.09.04 17:42:21 1: define A.Bewegungsmelder HMCCUDEV Schaltaktor: Cannot detect IO device
2018.09.04 17:42:21 1: define A.FBH.Wohnzimmer HMCCUCHN NEQ1484377:1: Cannot detect IO device
2018.09.04 17:42:21 1: define A.FBH.Badezimmer HMCCUCHN NEQ1484377:2: Cannot detect IO device
2018.09.04 17:42:21 1: define A.FBH.Kinderzimmer HMCCUCHN NEQ1484377:3: Cannot detect IO device
2018.09.04 17:42:21 1: define A.FBH.Kinderzimmer2 HMCCUCHN NEQ1484377:4: Cannot detect IO device
2018.09.04 17:42:21 1: define HM.Aussentemperatur HMCCUDEV Sensor_Aussentemperatur: Cannot detect IO device
2018.09.04 17:42:21 1: define WTH.Wohnzimmer HMCCUDEV WTH.Wohnzimmer: Cannot detect IO device
2018.09.04 17:42:21 1: define WTH.Kinderzimmer2 HMCCUDEV WTH.Kinderzimmer2: Cannot detect IO device
2018.09.04 17:42:21 2: FBH.Kinderzimmer2: Unknown sensor device WTH.Kinderzimmer2 specified
2018.09.04 17:42:21 2: FBH.Kinderzimmer2: Unknown sensor device WTH.Kinderzimmer2 specified
2018.09.04 17:42:21 2: T_TempUeberwachung.KZ2: Unknown sensor device WTH.Kinderzimmer2 specified
2018.09.04 17:42:21 2: T_TempUeberwachung.KZ2: Unknown sensor device WTH.Kinderzimmer2 specified
2018.09.04 17:42:21 3: TESTUI: new ext defined infix:ftui_test/: dir:./www/testumgebung:
2018.09.04 17:42:21 3: Registering HTTPSRV TESTUI for URL /ftui_test and assigned link ftui_test/ ...
2018.09.04 17:42:21 1: Including ./log/fhem.save
2018.09.04 17:42:22 1: configfile: Illegal RPC interface BidCos-RF
HMCCU: Illegal RPC port 2001
Can't find HMCCU I/O device
Can't find HMCCU I/O device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
Cannot detect IO device
./log/fhem.save: Please define A.Bewegungsmelder first
Please define A.Bewegungsmelder first
Please define A.Bewegungsmelder first
Please define A.Bewegungsmelder first
Please define A.Bewegungsmelder first
Please define A.FBH.Badezimmer first
Please define A.FBH.Badezimmer first
Please define A.FBH.Badezimmer first
Please define A.FBH.Badezimmer first
Please define A.FBH.Badezimmer first
...
gefolgt von allen weiteren HM Aktoren.
Nach einem Neustart von fhem sind alle Fehler verschwunden und alles funktioniert wie es soll.
Jemand eine Idee?
Gruß
Vaddi
Separate CCU oder auf dem gleichen Raspj wie FHEM installiert?
Falls letzteres: Die CCU ist beim FHEM Start noch nicht verfügbar. Das passiert auch nach einem Stromausfall bei einer separaten CCU. Dadurch kann sich HMCCU nicht die Geräte und Schnittstellen holen und es kommt zu diesen Fehlern.
Eventuell schafft die kommende Version Abhilfe. Bkn ich gerade am testen.
Guten morgen.
Jup, läuft alles auf dem gleichen RPi.
Danke für die Auskunft, dann werde ich mir
vorerst ein workaround basteln.
Hallo,
ich habe ein Problem mit meiner Heizungssteuerung: Wenn ich dem Wandthermostat per fhem set Befehl auf Boost schalte, reagiert das Heizkörperthermostat darauf nicht. Gibt es dafür einen Trick? Im Homematic GUI erscheint ebenfalls, dass das Wandthermostat im Boost-Modus ist.
Ich hoffe ihr könnt mir helfen, weil leider die Boost-Funktion aus FHEM heraus recht nutzlos ist.
Viele Grüße
bastelf(r)eak
Der Wandthermostat ist mit dem HK Thermostat verknüpft bzw. in einer virtuellen Gruppe?
Ja, genau so. Ich habe sowhl die Variante mit direkter Verknüpfung als auch als Gruppe. Bei beiden habe ich das gleiche Verhalten.
Homematic normal oder HmIP?
Hallo,
ein ähnliches Verhalten kann ich auch bestätigen.
In CCU2 nur Direktverknüpfungen (ohne CCU2 Programmierung), die Daten kommen über HMCCURPCPROC nach Fhem.
HmIP-WTH-2 mit HmIP-RF direktverknüpft:
Kanal 5:2
Kanal 1:6
Kanal 3:3
HmIP-SWDO mit HmIP-WTH-2 und HmIP-RF zusätzlich noch direktverknüpft:
jeweils Kanal 1:4
Wenn ich Boost am HmIP-WTH-2 "von Hand" drücke zählt die Zeit in Minuten am Display abwärts und das Boost kommt am HmIP-RF Zeitnah an. Ein erneuter Druck auf das Handrad beendet den Boost Zeitnah wieder.
Steuere ich in Fhem set <Device> datapoint 1.BOOST_MODE 1 , läuft hier die Zeit in Minuten am Display abwärts, in Fhem ändert sich das Reading 1.BOOST_TIME von 0 auf 18000 (30 Minuten), auf dem HmIP-RF kommt aber nichts an.
Die Readings 1.BOOST_MODE und 1.BOOST_TIME am HmIP-RF ändern sich nicht.
Der Eventmonitor zeigt auch nur Events 1.BOOST... bei Handbetätigung und keine Events bei senden über Fhem.
Es sollte schon korrekt sein, den Boost Befehl an den Wandthermostat zu senden und dieser sollte über Direktverknüpfung den Heizkörperthermostat informieren. Sende ich den Boost Befehl von Fhem direkt zum Heizkörperthermostat kommt das Boost an, nur der Wandthermostat bekommt davon nichts mit.
Irgendwie scheint mir das ein Problem der Geräte selbst zu sein, die tauschen sich nur über Direktverknüpfung aus, wenn der Befehl vom Gerät selbst kommt, Fhem wird hier irgendwie ignoriert.
@zap: Ich denke da kannst du über HMCCU / HMCCURPCPROC nicht viel machen, oder?
Hinweis:
Habe eben gesehen, es gibt eine neue Firmware Vers. 2.0.2 für den HmIP-WTH-2, eventuell hat sich ja da etwas geändert. Leider gibt es bei eq-3 noch keine Beschreibung dazu, welche Änderungen es zur Vorgängerversion gibt. Freiwillige vor :)
Gruß Reinhard
Ich habe sowohl eine Gruppe als auch Direktverknüpfungen. Das Verhalten mit den HM Komponenten (ohne IP) entspricht exakt dem von @Rewe2000.
Die Erklärung kann ich allerdings nicht ganz gelten lassen. Wenn man über das Webinterface von Homematic den Boost startet, funktioniert es ohne Probleme.
Hallo,
habs eben bei mir probiert, in der WEBUI der CCU2 beim HmIP-WTH-2 den Boost Button betätigt, jetzt über 10 Mituten hat aber der HmIP-RF noch nichts mitbekommen. Bei mir geht es definitiv nur durch reinen Handbetrieb (drücken der Taste).
Es ist hier genau wie unter Fhem, wenn ich den Boost Befehl an den HmIP-RF sende, geht das Ventil auf, aber der HmIP-WTH-2 bekommt davon nichts mit, zumindest bei mir.
Gruß Reinhard
Legt doch mal für die virtuelle Gruppe ein HMCCUDEV Device an und setzt bei diesem Device Boost. Also nicht beim Wandthermostat
Habe es bei mir getestet: Wenn ich das Device der virtuellen Gruppe auf BOOST setze, wird das im Wandthermostat UND im Heizkörperthermostat mitgezogen.
Hallo zap,
ist bei mir genauso.
Hatte bisher die Gruppen in der CCU2 nicht verwendet, werde aber im Zuge des neuen Firmwareupdate für die Raumthermostate alle Räume auch auf Gruppen umstellen. Ich erhoffe mir dadurch eine erhebliche Erleichterung beim An/Ablernen der Geräte.
Stellst du dann auch die komplette Ansteuerung von Geräten (Temperaturen, Heizprofile etc.), auch auf die entsprechenden Gruppen um?
Funktionieren würde ja beides, mit Ausnahme Boost.
Gruß Reinhard
Ja, ich mache alles über die Gruppen. Die Verknüpfungsorgie übernimmt die CCU, im Extremfall bei mir in einem Raum 3 Fensterkontakte, 2 Heizkörper, 1 Wandthermostat. Manuell ein Alptraum.
Netterweise speichert HMCCUDEV auch die Readings der Gruppenmitglieder im Gruppendevice. So genügt das als einziges Device.
Und Defaults gibt es auch für Gruppen (nur noch nicht für IP)