Hallo,
nachdme ich mich da jetzt 4 Tage damit herumgespielt habe und auf keinen grünen Zweig komme, bite nicht schlagen für eine vielleicht einfache Frage:
Ich habe einen RPI mit RaspberryMatic bespielt, da ich Homematic IP Komponenten (da gibt es doch einige nette Geräte die es als Homematic nicht gibt) in mein bestehendes FHEM (mit vielen Homematic Classic Komponenten) einbinden möchte.
Der RaspberryMatic läuft soweit brav und die ersten beiden Homematic IP Komponenten sind erfolgreich angelernt und bringen auch Statuswechsel.
Sweot so gut.
Mit der Integration in FHEM klemmt es noch etwas. Ich habe in HMCCU Device angelegt:
Internals:
CCUNum 1
Clients :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
DEF 192.168.0.15
NAME HMIP_RPCCU
NOTIFYDEV global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
NR 442
NTFY_ORDER 50-HMIP_RPCCU
RPCState inactive
STATE inactive/Error
TYPE HMCCU
ccuchannels 6
ccudevices 3
ccuinterfaces BidCos-RF,HmIP-RF,VirtualDevices
ccuip 192.168.0.15
ccustate active
ccutype CCU2/3
host 192.168.0.15
version 4.3.008
READINGS:
2018-12-29 20:41:57 count_channels 6
2018-12-29 20:41:57 count_devices 3
2018-12-29 20:41:57 count_groups 0
2018-12-29 20:41:57 count_interfaces 2
2018-12-29 20:41:57 count_programs 0
2018-12-29 16:04:06 rpcstate inactive
2018-12-29 20:42:21 state Error
hmccu:
evtime 0
evtimeout 0
rpccount 0
rpcports 2010
updatetime 1546112517.65776
adr:
HmIP-SRH 0007D8A9954E9A:
address 0007D8A9954E9A
addtype dev
valid 1
HmIP-SRH 0007D8A9954E9A:0:
address 0007D8A9954E9A:0
addtype chn
valid 1
HmIP-SRH 0007D8A9954E9A:1:
address 0007D8A9954E9A:1
addtype chn
valid 1
HmIP-SRH 0007D8A9954EB0:
address 0007D8A9954EB0
addtype dev
valid 1
HmIP-SRH 0007D8A9954EB0:0:
address 0007D8A9954EB0:0
addtype chn
valid 1
HmIP-SRH 0007D8A9954EB0:1:
address 0007D8A9954EB0:1
addtype chn
valid 1
VIR-HUE-GTW HU-Philips hue:
address HU-Philips hue
addtype dev
valid 1
VIR-HUE-GTW HU-Philips hue:0:
address HU-Philips hue:0
addtype chn
valid 1
VIR-HUE-GTW HU-Philips hue:1:
address HU-Philips hue:1
addtype chn
valid 1
ccu:
chncount 6
delay 180
delayed 0
devcount 3
gcount 0
ifcount 2
prgcount 0
timeout 1
dev:
0007D8A9954E9A:
addtype dev
channels 2
chndir 0
interface HmIP-RF
name HmIP-SRH 0007D8A9954E9A
type HmIP-SRH
valid 1
0007D8A9954E9A:0:
addtype chn
channels 1
chndir 0
name HmIP-SRH 0007D8A9954E9A:0
valid 1
0007D8A9954E9A:1:
addtype chn
channels 1
chndir 1
name HmIP-SRH 0007D8A9954E9A:1
valid 1
0007D8A9954EB0:
addtype dev
channels 2
chndir 0
interface HmIP-RF
name HmIP-SRH 0007D8A9954EB0
type HmIP-SRH
valid 1
0007D8A9954EB0:0:
addtype chn
channels 1
chndir 0
name HmIP-SRH 0007D8A9954EB0:0
valid 1
0007D8A9954EB0:1:
addtype chn
channels 1
chndir 1
name HmIP-SRH 0007D8A9954EB0:1
valid 1
HU-Philips hue:
addtype dev
channels 2
chndir 0
interface VirtualDevices
name VIR-HUE-GTW HU-Philips hue
type VIR-HUE-GTW
valid 1
HU-Philips hue:0:
addtype chn
channels 1
chndir 0
name VIR-HUE-GTW HU-Philips hue:0
valid 1
HU-Philips hue:1:
addtype chn
channels 1
chndir 0
name VIR-HUE-GTW HU-Philips hue:1
valid 1
dp:
HmIP-SRH:
ch:
0:
CONFIG_PENDING:
oper 5
type 2
DUTY_CYCLE:
oper 5
type 2
ERROR_CODE:
oper 5
type 8
INSTALL_TEST:
oper 3
type 2
LOW_BAT:
oper 5
type 2
OPERATING_VOLTAGE:
oper 5
type 4
OPERATING_VOLTAGE_STATUS:
oper 5
type 16
RSSI_DEVICE:
oper 5
type 8
RSSI_PEER:
oper 5
type 8
SABOTAGE:
oper 5
type 2
UNREACH:
oper 5
type 2
UPDATE_PENDING:
oper 5
type 2
1:
STATE:
oper 5
type 16
cnt:
CONFIG_PENDING 1
DUTY_CYCLE 1
ERROR_CODE 1
INSTALL_TEST 1
LOW_BAT 1
OPERATING_VOLTAGE 1
OPERATING_VOLTAGE_STATUS 1
RSSI_DEVICE 1
RSSI_PEER 1
SABOTAGE 1
STATE 1
UNREACH 1
UPDATE_PENDING 1
VIR-HUE-GTW:
ch:
1:
LEVEL:
oper 3
type 4
cnt:
LEVEL 1
spc:
level 1.LEVEL
grp:
ifports:
2010 HmIP-RF
9292 VirtualDevices
interfaces:
BidCos-RF:
HmIP-RF:
device d_rpcHmIP_RF
flags _
host 192.168.0.15
manager null
port 2010
prot http
state inactive
type A
url http://192.168.0.15:2010
VirtualDevices:
flags _
host 192.168.0.15
manager null
port 9292
prot http
state inactive
type A
url http://192.168.0.15:9292/groups
prg:
rpc:
Attributes:
ccudef-readingfilter ^(LOW_?BAT|UNREACH)$
ccudef-readingname ^(.+\.)?LOW_?BAT$:battery;^(.+\.)?UNREACH$:activity
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
eventMap /rpcserver on:on/rpcserver off:off/
rpcinterfaces HmIP-RF
rpcport 2010
rpcserver on
stateFormat rpcstate/state
verbose 5
Lesen scheint soweit zu funktionieren da er Geräte findet. Er kann aber den RPC Server nicht starten.
Trotz verbose level 5 liefert das log nur:
2018.12.29 20:44:24 0: HMCCU: [HMIP_RPCCU] Definition of some RPC devices failed
2018.12.29 20:44:24 1: HMCCU: [HMIP_RPCCU] HMCCU: HMIP_RPCCU Start of RPC server failed
Das hilft leider nicht allzuviel.
Hat jemand einen Tip was man machen könnte?
danke und lG
Mike
Hallo,
hast Du diese Info https://wiki.fhem.de/wiki/HMCCU_Best_Practice (https://wiki.fhem.de/wiki/HMCCU_Best_Practice) gelesen? Damit habe ich alles ohne Probleme installiert.
Viele Grüße
Jürgen
Hallo,
ja daher kommen fast alle der Settings die schon existieren....
Mag trotzdem nicht :-(
LG
Mike
UNd alle Module sind korrekt installiert?
Viele Grüße
Jürgen
Hi,
ja soweit ich es schon mehrfach angesehen habe sollte alles da sein.
Vorausgesetzte packages :
root@FHEM-LXC:/opt/fhem# sudo apt-get install -y librpc-xml-perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
librpc-xml-perl is already the newest version (0.80-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@FHEM-LXC:/opt/fhem#
Was mich ein wenig verwundert ist, dass man manche Befehle nicht verwenden kann.
Beispiel:
HMCCU: Unknown argument rpcrpcregister, choose one of var delete execute hmscript cleardefaults defaults importdefaults rpcrpcregister rpcserver ackmessages
wenn man versucht rpcrpcregister all aufzurufen ....
Ein getdevicelst z.B. funktioniert aber --> "Read 3 devices with 6 channels from CCU"
Nur der RPC server will nicht starten und das log ist hier sehr wenig aussagekräftig.
Gibt es eine Möglichkeit da noch aussagekräftigere Logs zu bekommen?
Danke
Mike
Da ist leider ein Schreibfehler im Befehl. Das muss rpcregister heißen. Wenn Du das in der Eingabezeile eingibst, wird es vermutlich funktionieren. Korrigiere ich in der nächsten Version. Hat aber nichts mit dem anderen Problem zu tun.
Wurden denn Devices vom Typ HMCCURPCPROC angelegt und hast Du die Config nach dem ersten Startversuch gespeichert?
Setze das Attribut rpcinterfaces mal auf BidCos-RF,HmIP-RF
Hi,
danke für die Tips :-)
Ja, ich habe gespeichert und auch mehrfach schon FHEM neu gestartet, hat alles nicht wirklich genutzt.
Wenn ich zusätzlich zum HmIP-RF auch BidCos-RF aktiviere, kommt sofort diese Meldung:
HMCCU: Illegal RPC interface BidCos-RF
Es wurde ein Device angelegt "CCU RPC HmIP-RF" das auf "initialized" steht.
Und ja, mit rpcregister gehts, er sagt dann halt dass der RPC Server nicht läuft.
lG
Mike
Da scheint irgendwas extrem verbogen zu sein, vielleicht sogar auf der CCU.
Starte mal die CCU neu. Wenn die CCU wieder da ist (ggf. testen ob WebUI antwortet), FHEM neu starten.
Danach prüfen, ob während dem Start von FHEM irgendwelche HMCCU Meldungen im Log auftauchen.
Und danach am besten nochmal ein List vom HMCCU Device machen. Hier interessieren v.a. die Internals sowie der Teil ab "Interfaces:"
Hi,
folgendes ausgeführt:
CCU (RaspberryMatic) neu gestartet. Läuft wider ganz normal, findet alle angelernten Homematic IP Geräte und kann diese steuern, sieht also soweit OK aus.
FHEM neu gestartet. Folgendes im log gefunden:
2018.12.31 15:14:35 1: HMCCU: [HMIP_RPCCU] Initialized version 4.3.008
2018.12.31 15:14:35 1: HMCCU: [HMIP_RPCCU] HMCCU: Initializing device
2018.12.31 15:14:36 1: HMCCU: [HMIP_RPCCU] HMCCU: Read 3 devices with 6 channels from CCU 192.168.0.15
2018.12.31 15:14:36 1: HMCCU: [HMIP_RPCCU] HMCCU: Read 2 interfaces from CCU 192.168.0.15
2018.12.31 15:14:36 1: HMCCU: [HMIP_RPCCU] HMCCU: Read 0 programs from CCU 192.168.0.15
2018.12.31 15:14:36 1: HMCCU: [HMIP_RPCCU] HMCCU: Read 0 virtual groups from CCU 192.168.0.15
2018.12.31 15:14:36 1: HMCCURPCPROC: [d_rpcHmIP_RF] Initialized version 1.3 for interface HmIP-RF with I/O device HMIP_RPCCU
2018.12.31 15:14:36 1: PERL WARNING: Use of uninitialized value $st in exists at ./FHEM/88_HMCCU.pm line 2604, <$fh> line 2761.
2018.12.31 15:14:36 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/88_HMCCU.pm line 2605, <$fh> line 2761.
2018.12.31 15:14:36 1: PERL WARNING: FUIP::getViewClassesSingle() called too early to check prototype at ./FHEM/42_FUIP.pm line 365, <$fh> line 2766.
2018.12.31 15:14:36 1: PERL WARNING: FUIP::_getWhereUsedList() called too early to check prototype at ./FHEM/42_FUIP.pm line 2697, <$fh> line 2766.
2018.12.31 15:14:36 1: PERL WARNING: Subroutine dimensions redefined at ./FHEM/lib/FUIP/View/Title.pm line 29, <$fh> line 2766.
Startversuch des RPS Servers liefert bekannte Fehlermeldung.
List der Devices:
Internals:
CCUNum 1
Clients :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
DEF 192.168.0.15
NAME HMIP_RPCCU
NOTIFYDEV global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
NR 442
NTFY_ORDER 50-HMIP_RPCCU
RPCState inactive
STATE inactive/Error
TYPE HMCCU
ccuchannels 6
ccudevices 3
ccuinterfaces VirtualDevices,HmIP-RF
ccuip 192.168.0.15
ccustate active
ccutype CCU2/3
host 192.168.0.15
version 4.3.008
READINGS:
2018-12-31 15:14:36 count_channels 6
2018-12-31 15:14:36 count_devices 3
2018-12-31 15:14:36 count_groups 0
2018-12-31 15:14:36 count_interfaces 2
2018-12-31 15:14:36 count_programs 0
2018-12-31 15:14:36 rpcstate inactive
2018-12-31 15:15:32 state Error
hmccu:
evtime 0
evtimeout 0
rpccount 0
rpcports 2010,9292
updatetime 0
adr:
HmIP-SRH 0007D8A9954E9A:
address 0007D8A9954E9A
addtype dev
valid 1
HmIP-SRH 0007D8A9954E9A:0:
address 0007D8A9954E9A:0
addtype chn
valid 1
HmIP-SRH 0007D8A9954E9A:1:
address 0007D8A9954E9A:1
addtype chn
valid 1
HmIP-SRH 0007D8A9954EB0:
address 0007D8A9954EB0
addtype dev
valid 1
HmIP-SRH 0007D8A9954EB0:0:
address 0007D8A9954EB0:0
addtype chn
valid 1
HmIP-SRH 0007D8A9954EB0:1:
address 0007D8A9954EB0:1
addtype chn
valid 1
VIR-HUE-GTW HU-Philips hue:
address HU-Philips hue
addtype dev
valid 1
VIR-HUE-GTW HU-Philips hue:0:
address HU-Philips hue:0
addtype chn
valid 1
VIR-HUE-GTW HU-Philips hue:1:
address HU-Philips hue:1
addtype chn
valid 1
ccu:
chncount 6
delay 180
delayed 0
devcount 3
gcount 0
ifcount 2
prgcount 0
timeout 1
dev:
0007D8A9954E9A:
addtype dev
channels 2
chndir 0
interface HmIP-RF
name HmIP-SRH 0007D8A9954E9A
type HmIP-SRH
valid 1
0007D8A9954E9A:0:
addtype chn
channels 1
chndir 0
name HmIP-SRH 0007D8A9954E9A:0
valid 1
0007D8A9954E9A:1:
addtype chn
channels 1
chndir 1
name HmIP-SRH 0007D8A9954E9A:1
valid 1
0007D8A9954EB0:
addtype dev
channels 2
chndir 0
interface HmIP-RF
name HmIP-SRH 0007D8A9954EB0
type HmIP-SRH
valid 1
0007D8A9954EB0:0:
addtype chn
channels 1
chndir 0
name HmIP-SRH 0007D8A9954EB0:0
valid 1
0007D8A9954EB0:1:
addtype chn
channels 1
chndir 1
name HmIP-SRH 0007D8A9954EB0:1
valid 1
HU-Philips hue:
addtype dev
channels 2
chndir 0
interface VirtualDevices
name VIR-HUE-GTW HU-Philips hue
type VIR-HUE-GTW
valid 1
HU-Philips hue:0:
addtype chn
channels 1
chndir 0
name VIR-HUE-GTW HU-Philips hue:0
valid 1
HU-Philips hue:1:
addtype chn
channels 1
chndir 0
name VIR-HUE-GTW HU-Philips hue:1
valid 1
dp:
HmIP-SRH:
ch:
0:
CONFIG_PENDING:
oper 5
type 2
DUTY_CYCLE:
oper 5
type 2
ERROR_CODE:
oper 5
type 8
INSTALL_TEST:
oper 3
type 2
LOW_BAT:
oper 5
type 2
OPERATING_VOLTAGE:
oper 5
type 4
OPERATING_VOLTAGE_STATUS:
oper 5
type 16
RSSI_DEVICE:
oper 5
type 8
RSSI_PEER:
oper 5
type 8
SABOTAGE:
oper 5
type 2
UNREACH:
oper 5
type 2
UPDATE_PENDING:
oper 5
type 2
1:
STATE:
oper 5
type 16
cnt:
CONFIG_PENDING 1
DUTY_CYCLE 1
ERROR_CODE 1
INSTALL_TEST 1
LOW_BAT 1
OPERATING_VOLTAGE 1
OPERATING_VOLTAGE_STATUS 1
RSSI_DEVICE 1
RSSI_PEER 1
SABOTAGE 1
STATE 1
UNREACH 1
UPDATE_PENDING 1
VIR-HUE-GTW:
ch:
1:
LEVEL:
oper 3
type 4
cnt:
LEVEL 1
spc:
level 1.LEVEL
grp:
ifports:
2010 HmIP-RF
9292 VirtualDevices
interfaces:
BidCos-RF:
HmIP-RF:
device d_rpcHmIP_RF
flags _
host 192.168.0.15
manager null
port 2010
prot http
state inactive
type A
url http://192.168.0.15:2010
VirtualDevices:
device d_rpcVirtualDevices
flags _
host 192.168.0.15
manager null
port 9292
prot http
state inactive
type A
url http://192.168.0.15:9292/groups
prg:
rpc:
Attributes:
ccudef-readingfilter ^(LOW_?BAT|UNREACH)$
ccudef-readingname ^(.+\.)?LOW_?BAT$:battery;^(.+\.)?UNREACH$:activity
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
eventMap /rpcserver on:on/rpcserver off:off/
rpcinterfaces HmIP-RF,VirtualDevices
rpcport 2010,9292
rpcserver on
stateFormat rpcstate/state
verbose 5
Hallo nochmals,
ich habe im Code ein paar mehr Logs eingebaut. Offenbar geht da beim initialisieren der Devices etwas gröber schief.
Er nimmt immer nur eines der beiden Devices (weil er eines annimmt, das nicht exisitiert), kommt dann auf eine falsche Anzahl und meint deshalb er kann nicht weiter.
Folgendes kann ich beisteuern:
2019.01.02 07:13:46 0: HMCCU: [HMIP_RPCCU] Iterating Interfaces...
2019.01.02 07:13:46 0: HMCCU: [HMIP_RPCCU] Interface BidCos-RF has RPC device , save is 0.
2019.01.02 07:13:46 0: HMCCU: [HMIP_RPCCU] Interface HmIP-RF has RPC device d_rpcHmIP_RF, save is 0.
2019.01.02 07:13:46 0: HMCCU: [HMIP_RPCCU] Interface defined BidCos-RF HmIP-RF, we think the number is 1.
2019.01.02 07:13:46 0: HMCCU: [HMIP_RPCCU] Definition of some RPC devices failed
Er hat 2 Devices, kann aber zum BidCos-RF kein RPC device finden, hat danach dann nur den Zähler auf 1 und steigt aus.
Interessant ist auch, dass er irgendwo glaubt er müsse immer BidCos-RF machen, obwohl es nicht definiert ist.
Im oberen Fall habe ich nur das HmIP-RF definiert, er versucht trotzdem das BidCos-RF zu instanzieren, was aber nicht geht, da die angeschlossene RaspberryMatic kein solches Interface hat, siehe reading:
ccuinterfaces VirtualDevices,HmIP-RF
Vielleicht hilft das weiter. Ansonsten würde ich den Code weiter mit Logs pflastern und versuchen dem Problem näherzukommen.
lG
Mike
Hi nochmal,
so, es ist gelöst.
Es handelt sich um ein Problem im Modul.
Das Modul nimmt an, dass es IMMER ein BidCos-RF gibt, was aber so nicht ist (zumindest nicht wenn man eine RaspberryMatic mit nur einem Homematic-IP Interface verwendet so wie in meinem vorliegenden Fall).
Folgende Codeänderung ist nötig, damit es funktioniert:
sub HMCCU_GetRPCInterfaceList ($)
{
my ($hash) = @_;
my $name = $hash->{NAME};
# my @interfaces = ($HMCCU_RPC_INTERFACE_DEFAULT); --> hier keinen default annehmen, leer initialisieren
my @interfaces;
my $ccuflags = HMCCU_GetFlags ($name);
if (defined ($hash->{hmccu}{rpcports})) {
foreach my $p (split (',', $hash->{hmccu}{rpcports})) {
my $ifname = HMCCU_GetRPCServerInfo ($hash, $p, 'name');
next if (!defined ($ifname));
my $iftype = HMCCU_GetRPCServerInfo ($hash, $ifname, 'type');
# next if ($ifname eq $HMCCU_RPC_INTERFACE_DEFAULT || --> hier auch BidCos-RF aufnehmen wenn vorhanden
next if (($iftype eq 'B' && $ccuflags !~ /(extrpc|procrpc)/) ||
!exists ($hash->{hmccu}{interfaces}{$ifname}));
push (@interfaces, $ifname);
}
}
return @interfaces;
}
Die Änderung sollte auch greifen, wenn BidCos-RF existiert, dann wird es aufgenommen, wenn es wie bei mir nicht exisitert, dann ist es nicht als Leiche per Default vorhanden.
Bitte um Review der Änderung und ggf. Aufnahme in den Produktivcode.
danke und lG
Mike
oh, das ist sehr interessant. Bisher war es immer so, dass die CCU selbst immer BidCos-RF verwendet hat. Daher versucht HMCCU immer, BidCos zu initialisieren. Da muss ich was ändern. Workaround kann ich dir momentan nicht anbieten. Werde ich fixen. Wie lange das dauert, kann ich nicht genau sagen. Mindestens bis zum Wochenende.
Update: du warst schneller. Allerdings ist das nicht die einzige notwendige Änderung. Wenn es für dich momentan funktioniert, nimmt das erst al etwas Druck vom Kessel ;)
Hi,
Druck gibt es generell sowieso keinen.
Da es sich um meine Hausanlage handelt, kann die Einbindung der neuen HM-IP Geräte auch noch warten :-)
Bislang habe ich noch nix gemerkt, dass etwas nicht geht.
Ich habe aber auch nur 2 Fenstergriffsensoren in FHEM übernommen, die brav die Statusänderungen open/tilted/closed schicken.
Ob es sonst Einschränkungen gibt kann ich nicht sagen, aber wenn du da noch weiteren Änderungsbedarf siehst dann wird es schon so sein.
Wenn ich behilflich sein kann (Hinweise wo das noch Auswirkungen haben könnte vorausgesetzt), kann ich da gerne noch weiter reinsehen, ich hab' noch Urlaub diese Woche :-)
LG
Mike
1) Kannst Du mir bitte sagen, welche Werte einige Internals des I/O Device bei Dir haben? Konkret geht es um
- ccuaddr
- ccuif
- ccuname
Oder existieren die nicht?
2 ) In Deinem ersten Post schreibst Du:
ccuinterfaces BidCos-RF,HmIP-RF,VirtualDevices
Später dann
ccuinterfaces HmIP-RF,VirtualDevices
Was ist dazwischen passiert?
3) Außerdem wäre der Inhalt der Datei /etc/config/InterfacesList.xml auf der CCU hilfreich.
Hi,
hier die gewünschten Infos:
zu 1.)
- ccuaddr
- ccuif
- ccuname
existieren alle nicht.
zu 2.)
Dazwischen ist ein komplettes Neuaufsetzen der RaspberryMatic passiert weil ich vermutet hatte dass ich irgendwo einen Blödsinn gemacht habe. Ich wüsste aber nicht was ich anders gemacht hätte als beim ersten mal.
Die RaspberryMatic funktioniert aber jetzt so wie vorher, die Devices sind nach dem Minimalpatch im FHEM und es kommen auch brav Änderungen (getestet mit Fesntersensoren).
zu 3.)
here it is:
# cat /etc/config/InterfacesList.xml
<?xml version="1.0" encoding="utf-8" ?>
<interfaces v="1.0">
<ipc>
<name>VirtualDevices</name>
<url>xmlrpc://127.0.0.1:39292/groups</url>
<info>Virtual Devices</info>
</ipc>
<ipc>
<name>HmIP-RF</name>
<url>xmlrpc://127.0.0.1:32010</url>
<info>HmIP-RF</info>
</ipc>
</interfaces>
#
Ok, danke! Ich frage mich nur, ob dann auch die virtuellen Taster der CCU über HmIP laufen oder ob die weggefallen sind.
Den Usecase muss ich erst mal genauer analysieren
wenn ich helfen kann lass es mich wissen :-)
Ja, nehme ich gerne an. Rufe mal bitte das CCU WebUI auf und wähle aus dem Menü "Einstellungen" > "Geräte".
Gibt es da ein Gerät "CCU"? Wenn ja, wie sieht das aus? Mich interessieren folgende Spalten der Tabelle:
Typenbezeichnung
Seriennummer
Interface/Kategorie
Bei meiner CCU3 sieht das so aus:
Typenbezeichnung = HM-RCV-50
Seriennummer = BidCoS-RF
Interface/Kategorie = BidCos-RF
Man beachte den kleinen, aber feinen Unterschied in der Schreibweise bei Seriennummer und Interface.
Darf ich mich dazu einhängen?
Habe das gleiche Thema seit dem Update von piVCCU auf 2.41.5-40. Seitdem starten die RPC Server nicht mehr. Das Log ist wenig hilfreich. Die Bezeichnungen sind bei mir so wie bei zap beschrieben (mit dem kleinen Unterschied).
Nach dem Löschen der RPC Server werden diese dann auch wieder neu angelegt. Sie starten jedoch nicht.
Mein RaspBian und FHEM sind auf dem Stand von heute Nachmittag.
Den Codepatch von oben habe ich noch nicht versucht.
Wie kann ich helfen? Welche Infos werden benötigt? Soll ich den Patch mal versuchen?
Du hast vermutlich einen anderen Fehler. Insofern würden mich die Logs beim Start der RPC Server schon interessieren
Hallo zap,
hier die Logfileeinträge nach set HomeMatic rpcserver on:
2019.01.09 22:50:44 2: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server process started for interface BidCos-RF with PID=1246
2019.01.09 22:50:44 2: CCURPC: [d_rpcBidCos_RF] Initializing RPC server CB2001237050 for interface BidCos-RF
2019.01.09 22:50:44 4: HMCCURPCPROC: [d_rpcBidCos_RF] Set state to busy
2019.01.09 22:50:44 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server starting
2019.01.09 22:50:44 4: HMCCURPCPROC: [d_rpcBidCos_RF] Set rpcstate to starting
2019.01.09 22:50:44 2: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server process started for interface HmIP-RF with PID=1247
2019.01.09 22:50:44 1: HMCCURPCPROC: [d_rpcBidCos_RF] Can't create RPC callback server CB2001237050 on port 7411. Port in use?
2019.01.09 22:50:44 1: CCURPC: [d_rpcBidCos_RF] Can't initialize RPC server CB2001237050 for interface BidCos-RF
2019.01.09 22:50:44 2: CCURPC: [d_rpcHmIP_RF] Initializing RPC server CB2010237050 for interface HmIP-RF
2019.01.09 22:50:44 4: HMCCURPCPROC: [d_rpcHmIP_RF] Set state to busy
2019.01.09 22:50:44 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server starting
2019.01.09 22:50:44 4: HMCCURPCPROC: [d_rpcHmIP_RF] Set rpcstate to starting
2019.01.09 22:50:44 2: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server process started for interface VirtualDevices with PID=1248
2019.01.09 22:50:44 1: HMCCURPCPROC: [d_rpcHmIP_RF] Can't create RPC callback server CB2010237050 on port 7420. Port in use?
2019.01.09 22:50:44 1: CCURPC: [d_rpcHmIP_RF] Can't initialize RPC server CB2010237050 for interface HmIP-RF
2019.01.09 22:50:44 2: CCURPC: [d_rpcVirtualDevices] Initializing RPC server CB9292237050 for interface VirtualDevices
2019.01.09 22:50:44 4: HMCCURPCPROC: [d_rpcVirtualDevices] Set state to busy
2019.01.09 22:50:44 1: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server starting
2019.01.09 22:50:44 4: HMCCURPCPROC: [d_rpcVirtualDevices] Set rpcstate to starting
2019.01.09 22:50:44 1: HMCCURPCPROC: [d_rpcVirtualDevices] Can't create RPC callback server CB9292237050 on port 14702. Port in use?
2019.01.09 22:50:44 1: CCURPC: [d_rpcVirtualDevices] Can't initialize RPC server CB9292237050 for interface VirtualDevices
2019.01.09 22:51:09 2: HMCCURPCPROC: [d_rpcBidCos_RF] Checking if RPC server process is running
2019.01.09 22:51:09 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server process not running. Cleaning up
2019.01.09 22:51:09 1: HMCCURPCPROC: [d_rpcBidCos_RF] Housekeeping called. Cleaning up RPC environment
2019.01.09 22:51:09 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server process CB2001237050 not runnning
2019.01.09 22:51:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Set rpcstate to inactive
2019.01.09 22:51:09 2: HMCCURPCPROC: [d_rpcBidCos_RF] Stop I/O handling
2019.01.09 22:51:09 3: HMCCURPCPROC: [d_rpcBidCos_RF] Close child socket
2019.01.09 22:51:09 3: HMCCURPCPROC: [d_rpcBidCos_RF] Close parent socket
2019.01.09 22:51:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Reset RPC state
2019.01.09 22:51:09 4: HMCCURPCPROC: [d_rpcBidCos_RF] Set state to OK
2019.01.09 22:51:09 2: HMCCURPCPROC: [d_rpcHmIP_RF] Checking if RPC server process is running
2019.01.09 22:51:09 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server process not running. Cleaning up
2019.01.09 22:51:09 1: HMCCURPCPROC: [d_rpcHmIP_RF] Housekeeping called. Cleaning up RPC environment
2019.01.09 22:51:09 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server process CB2010237050 not runnning
2019.01.09 22:51:09 4: HMCCURPCPROC: [d_rpcHmIP_RF] Set rpcstate to inactive
2019.01.09 22:51:09 2: HMCCURPCPROC: [d_rpcHmIP_RF] Stop I/O handling
2019.01.09 22:51:09 3: HMCCURPCPROC: [d_rpcHmIP_RF] Close child socket
2019.01.09 22:51:09 3: HMCCURPCPROC: [d_rpcHmIP_RF] Close parent socket
2019.01.09 22:51:09 4: HMCCURPCPROC: [d_rpcHmIP_RF] Reset RPC state
2019.01.09 22:51:09 4: HMCCURPCPROC: [d_rpcHmIP_RF] Set state to OK
2019.01.09 22:51:09 2: HMCCURPCPROC: [d_rpcVirtualDevices] Checking if RPC server process is running
2019.01.09 22:51:09 1: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server process not running. Cleaning up
2019.01.09 22:51:09 1: HMCCURPCPROC: [d_rpcVirtualDevices] Housekeeping called. Cleaning up RPC environment
2019.01.09 22:51:09 1: HMCCURPCPROC: [d_rpcVirtualDevices] RPC server process CB9292237050 not runnning
2019.01.09 22:51:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Set rpcstate to inactive
2019.01.09 22:51:09 2: HMCCURPCPROC: [d_rpcVirtualDevices] Stop I/O handling
2019.01.09 22:51:09 3: HMCCURPCPROC: [d_rpcVirtualDevices] Close child socket
2019.01.09 22:51:09 3: HMCCURPCPROC: [d_rpcVirtualDevices] Close parent socket
2019.01.09 22:51:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Reset RPC state
2019.01.09 22:51:09 4: HMCCURPCPROC: [d_rpcVirtualDevices] Set state to OK
Die Einträge in fhem.cfg:
#######################################################################################
## Homematic piVCCU
define HomeMatic HMCCU 192.168.237.52
attr HomeMatic ccuflags procrpc,nonBlocking
attr HomeMatic event-on-change-reading .*
attr HomeMatic group HM
attr HomeMatic room zzConfig
attr HomeMatic rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
attr HomeMatic rpcinterval 5
attr HomeMatic rpcport 2001,2010,9292
attr HomeMatic rpcqueue /opt/fhem/ccuTemp
attr HomeMatic rpcserver on
attr HomeMatic rpcserveraddr 192.168.237.50
attr HomeMatic stateFormat rpcstate/state
define HomeMaticRPC HMCCURPC 192.168.237.52
attr HomeMaticRPC group HM
attr HomeMaticRPC room zzConfig
attr HomeMaticRPC rpcServerAddr 192.168.237.50
attr HomeMaticRPC stateFormat rpcstate/state
attr HomeMaticRPC verbose 5
define d_rpcBidCos_RF HMCCURPCPROC 192.168.237.52 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 HM
attr d_rpcBidCos_RF room zzConfig
attr d_rpcBidCos_RF rpcServerAddr 192.168.237.50
attr d_rpcBidCos_RF stateFormat rpcstate/state
attr d_rpcBidCos_RF verbose 5
define d_rpcHmIP_RF HMCCURPCPROC 192.168.237.52 HmIP-RF
attr d_rpcHmIP_RF alias CCU RPC HmIP-RF
attr d_rpcHmIP_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpcHmIP_RF group HM
attr d_rpcHmIP_RF room zzConfig
attr d_rpcHmIP_RF rpcServerAddr 192.168.237.50
attr d_rpcHmIP_RF stateFormat rpcstate/state
attr d_rpcHmIP_RF verbose 5
define d_rpcVirtualDevices HMCCURPCPROC 192.168.237.52 VirtualDevices
attr d_rpcVirtualDevices alias CCU RPC VirtualDevices
attr d_rpcVirtualDevices eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpcVirtualDevices group HM
attr d_rpcVirtualDevices room zzConfig
attr d_rpcVirtualDevices rpcServerAddr 192.168.237.50
attr d_rpcVirtualDevices stateFormat rpcstate/state
attr d_rpcVirtualDevices verbose 5
define ActionDetector CUL_HM 000000
attr ActionDetector .mId 1
attr ActionDetector event-on-change-reading .*
attr ActionDetector group HM
attr ActionDetector model ActionDetector
attr ActionDetector room zzConfig
attr ActionDetector subType 1
attr ActionDetector verbose 5
Die Firewall der CCU ist auf "Vollzugriff".
Stehe für weitere Hilfe / Infos gerne zur Verfügung.
Das Problem ist, dass die RPC Server auf der FHEM Seite sich nicht an die Ports binden können ("port in use" im Log). Hat also eher nicbts mit der CCU zu tun.
Da du piVCCU und damit einen Container verwendest, hat es vermutlich mit der Netzwerkkonfiguration zu tun.
Um andere Ursachen auszuschliessen, kannst Du mal folgendes machen:
netstat -an | grep 7411 | grep -i listen
Und das gleiche nochmal mit 7420 statt 7411.
wenn alles ok ist, sollten beide Befehle keine Ausgabe liefern
Doch, die liefern folgende Ausgabe:
root@fhemserver:~# netstat -an | grep 7411 | grep -i listen
tcp 0 0 0.0.0.0:7411 0.0.0.0:* LISTEN
root@fhemserver:~# netstat -an | grep 7420 | grep -i listen
tcp 0 0 0.0.0.0:7420 0.0.0.0:* LISTEN
Nun hat mich interessiert, welcher Prozess das sein könnte:
root@fhemserver:~# netstat -tulpn | grep :7411
tcp 0 0 0.0.0.0:7411 0.0.0.0:* LISTEN 8392/perl
root@fhemserver:~# netstat -tulpn | grep :7420
tcp 0 0 0.0.0.0:7420 0.0.0.0:* LISTEN 8393/perl
Das sieht nach FHEM selbst aus, aber welches Modul hat diese Ports bereits in Benutzung? Kann man das auch herausfinden?
ich denke mal, da läuft noch eine Leiche eines HMCCU rpc servers. FHEM stoppen und alle noch lebenden fhem perl Prozesse killen
Der RPi wurde gestern mehrfach neu gestartet. Habe ihn soeben nochmal komplett durchgebootet. Hat leider nicht geholfen. Die Ports bleiben weiterhin von Perl belegt.
Noch irgendeine andere Idee?
Lass Dir mit netstat nochmal die PIDs der Prozesse anzeigen, die die Ports blockieren.
Dann mache mal folgendes im FHEM Log Verzeichnis:
grep HMCCURPCPROC Logfile | grep PID
und vergleiche die angezeigten PIDS mit denen aus dem netstat.
Falls alles nichts hilft, kannst Du mal versuchen, in den HMCCURPCPROC Devices jeweils das Attribut rpcServerPort auf einen Wert != 5400 zu setzen, z.B. auf 5900. Dieser Wert ist die Berechnunsgrundlage für den Zielport:
Zielport = rpcServerPort + CCU-Interface-Port + CCUNumber*10
Hallo zap,
es gab ein Kernel Update für die piVCCU Module. Das habe ich installiert und nun funktioniert es. Macht für mich keinen Sinn, außer piVCCU verwendet auch Perl.
Auf jeden Fall kann man dieses Problem nun schließen.
Ganz herzlichen Dank für die schnelle Hilfe.
Beste Grüße
Familienpapi
Hallo,
Zitat von: zap am 05 Januar 2019, 19:07:19
Ja, nehme ich gerne an. Rufe mal bitte das CCU WebUI auf und wähle aus dem Menü "Einstellungen" > "Geräte".
Gibt es da ein Gerät "CCU"? Wenn ja, wie sieht das aus? Mich interessieren folgende Spalten der Tabelle:
Nein, das gibt es bei der RaspberryMatic nicht.
Es werden nur die beiden Fenstersensoren angezeigt, die ich bereits angelernt habe.
LG
Mike
Hallo,
gibt es dazu schon News? Möchte am Wochenende mal wieder FHEM updaten und wollte wissen ob ich dann wieder patchen muss :-)
LG
Mike
Nein, Du musst nicht patchen. Seit dem letzten Update sollte das jetzt auch mit HmIP als Default funktionieren.
Ich denke aber trotzdem, dass bei Deiner CCU irgendwas verbogen ist. Ich habe gestern endlich meine "Charly" CCU3 mit der aktuellen RasperryMatic in Betrieb genommen. Wie erwartet war direkt nach dem ersten Booten das virtuelle BidCos-RF Gerät "HM-RCV-50 BidCoS-RF" mit den 50 Tasterkanälen verfügbar und damit auch das BidCos Interface.
Warum das bei Dir fehlt, ist mir ein Rätsel.
Hmmmm...
Update durchgeführt, kommt wieder die Fehlermeldung "HMCCU: HMIP_RPCCU Start of RPC server failed"
und im log:
2019.01.27 10:48:20 0: HMCCU: [HMIP_RPCCU] Definition of some RPC devices failed
2019.01.27 10:48:20 1: HMCCU: [HMIP_RPCCU] HMCCU: HMIP_RPCCU Start of RPC server failed
Ich weiß langsam nicht mehr was ich tun soll.
Ich habe die RaspberryMatic jetzt schon zum dritten mal völlig ohne Übernahme von Einstellungen etc. davor neu aufgesetzt. Da ich derzeit ohnehin nur 2 Sensoren dran habe die ich (noch) nicht produktiv nutze ist das auch kein Problem.
Sieht jedesmal gleich aus :-(
Eventuell liegt es daran dass ich nur einen HmIP Stick dran habe?
Installiert habe ich das Ganze nach dieser Anleitung:
https://homematic-forum.de/forum/viewtopic.php?t=26917
auf einem Raspberry Pi 2
Ich werde mal wieder ein paar loggings einbauen und sehen woran es diesmal liegt.
lG
Mike
Hi,
der Bugfix war nicht 100% ok, bei mir findet er immer noch das BidCos-RF als Interface obwohl es nicht exisitert....
Habe mal die Anzahl und die Interfaces ausgeben lassen:
2019.01.27 11:02:03 0: HMCCU: [HMIP_RPCCU] 3 RPC devices: BidCos-RF HmIP-RF VirtualDevices
Das Default Interface wird als BidCos-RF gefunden obwohl es nicht exisitiert:
2019.01.27 11:28:18 1: HMCCU: [HMIP_RPCCU] Default Interface: BidCos-RF:2001
Ausgabe in der Methode HMCCU_GetDefaultInterface
Anlegen tut er aber keines korrekterweise. Da habe ich nur wie vorher hmIP und VirtualDevices.
LG
Mike
Kannst Du für das I/O Device mal bitte folgenden Befehl ausführen:
set devName hmscript !GetInterfaceList dump
devName durch den Namen des I/O Device ersetzen.
Liefert das:
VirtualDevices;Virtual Devices;xmlrpc://127.0.0.1:39292/groups
HmIP-RF;HmIP-RF;xmlrpc://127.0.0.1:32010
lG
Mike
Und im list vom I/O Device steht unter "Interfaces:" was?
Internals:
CCUNum 1
Clients :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
DEF 192.168.0.15
FUUID 5c42d5d9-f33f-ef20-6959-e3dde57b6c743562
NAME HMIP_RPCCU
NOTIFYDEV global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
NR 443
NTFY_ORDER 50-HMIP_RPCCU
RPCState inactive
STATE inactive/Error
TYPE HMCCU
ccuchannels 4
ccudevices 2
[b] ccuinterfaces HmIP-RF,BidCos-RF,VirtualDevices[/b]
ccuip 192.168.0.15
ccustate active
ccutype CCU2/3
host 192.168.0.15
version 4.3.010
/code]
Nein, das meine ich nicht. Mach ein list vom I/O Device und suche in der Ausgabe nach dem Text "Interfaces:" (ohne Anführungszeichen, aber mit Doppelpunkt). Bei mir sieht das so aus:
interfaces:
BidCos-RF:
device d_rpcBidCos_RF
flags forceASCII
host 192.168.1.21
manager HMCCU
port 2001
prot http
state running
type A
url http://192.168.1.21:2001
CUxD:
device d_rpcCUxD
flags forceInit
host 192.168.1.21
manager HMCCU
port 8701
prot xmlrpc_bin
state running
type B
url xmlrpc_bin://192.168.1.21:8701
HmIP-RF:
device d_rpcHmIP_RF
flags _
host 192.168.1.21
manager HMCCU
port 2010
prot http
state running
type A
url http://192.168.1.21:2010
VirtualDevices:
device d_rpcVirtualDevices
flags _
host 192.168.1.21
manager HMCCU
port 9292
prot http
state running
type A
url http://192.168.1.21:9292/groups
Ich glaube, so langsam nähere ich mich dem Problem. Hast Du ein HMCCURPCPROC Device definiert für BidCos-RF? Wenn ja, dann folgendes Versuchen:
- Stoppe alle RPC Server, sofern welche laufen
- Lösche das BidCos-RF HMCCURPCPROC Device
- Lösche BidCos-RF aus dem Attribut rpcinterfaces
- Lösche 2001 aus dem Attribut rpcports
- Speichere die FHEM Config
- Starte FHEM neu
Wenn das funktioniert (kein BidCos-RF mehr nach Neustart), ist das nur ein Workaround. Ich muss in HMCCU noch einiges korrigieren.
Sorry,
hier ist der richtige Part...
interfaces:
BidCos-RF:
HmIP-RF:
device d_rpcHmIP_RF
flags _
host 192.168.0.15
manager null
port 2010
prot http
state inactive
type A
url http://192.168.0.15:2010
VirtualDevices:
device d_rpcVirtualDevices
flags _
host 192.168.0.15
manager null
port 9292
prot http
state inactive
type A
url http://192.168.0.15:9292/groups
Und nein, er legt kein HMCCURPCPROC Device an für BidCos-RF, nur für die beiden korrekterweise existierenden.
lG
Mike