NEWS
States von CCU2 werden nicht mehr empfangen
-
@dslraser Und gar nichts im Log gewesen, evtl mal ein Verbindungsabbrruch oder so -- wobei er ja verbunden ist, wenn man steuern kann. Eigentlich werden die Event Änderungen von der CCU aktiv an uns gesendet, so lange die Verbindung steht.
-
@foxriver76
Deswegen vermute ich die Ursache auf der CCU -
-
@foxriver76 sagte in States von CCU2 werden nicht mehr empfangen:
Und gar nichts im Log gewesen, evtl mal ein Verbindungsabbrruch oder so
Da die Logs ja aktuell nicht automatisch gelöscht werden, müsste ich noch so einige haben. Ich schau nochmal in Ruhe da rein, wenn ich zu Hause bin.
-
@foxriver76
Bei mir auch eine Raspberrymatic mit Tinkerboard -
@foxriver76 sagte in States von CCU2 werden nicht mehr empfangen:
Hast du das Problem auch?
Nein!
ich benutze piVCCU (uralt = 2.45.7)Aber wenn die CCU nicht mehr pusht, hilft meistens ein reboot
-
@dslraser bei mir klassisch CCU2
-
@Homoran reboot wurde schon mehrfach durchgeführt.
iwann werden die States dann aber nicht mehr gepushed
-
@Kuddel sagte in States von CCU2 werden nicht mehr empfangen:
iwann werden die States dann aber nicht mehr gepushed
AHA!!
Nach einem Reboot klappt es also?
Dann bleibt es später wieder hängen? -
@Homoran muss ich nachher mal beobachten.
Heute morgen ging noch alles, da wurde aber auch vom ioBroker aus geschaltet.
Ich werde jetzt nochmal einen Reboot machen und dann prüfen wenn ich zu Hause bin, ob die States sauber gepushed werden
UPDATE:
CCU2 ist neugestartet.
Lichtschalter ist aktiv.
State im ioBroker: falseWird also nicht gepushed
-
@Kuddel leider werden die States immer noch nicht gepushed
-
@Kuddel dann zeig mal die erweiterten Einstellungen der Instanzen bitte
-
-
@Kuddel
bitte IP des ioBrokers in die Callback-Adresse eingeben.BTW wo läuft ioBroker bei dir?
-
@Homoran ist eingetragen...
ioBroker läuft auf einer Ubuntu 18.04 VM
-
@Kuddel sagte in States von CCU2 werden nicht mehr empfangen:
VM
dann ist diese Callback-Adresse notwendig
-
@Homoran dann wundert mich aber, dass die Probleme jetzt erst auftreten.
Betreibe ioBroker schon über 1 Jahr als VM im Verbindung mit HM und hatte nie solche Probleme
-
@Kuddel
sind die Probleme denn jetzt erledigt? -
-
habe das Loglevel vom Adapter mal auf Info gestellt:
hm-rpc.0 2019-11-28 17:24:26.959 info (12834) xmlrpc -> 230 devices hm-rpc.0 2019-11-28 17:24:26.914 info (12834) xmlrpc <- listDevices ["hm-rpc.0"] hm-rpc.0 2019-11-28 17:24:26.910 info (12834) xmlrpc <- system.listMethods ["hm-rpc.0"] hm-rpc.0 2019-11-28 17:24:26.393 info (12834) xmlrpc -> 230 devices hm-rpc.0 2019-11-28 17:24:26.352 info (12834) xmlrpc <- listDevices ["hm-rpc.0"] hm-rpc.0 2019-11-28 17:24:26.348 info (12834) xmlrpc <- system.listMethods ["hm-rpc.0"] hm-rpc.0 2019-11-28 17:24:16.785 info (12834) Connected hm-rpc.0 2019-11-28 17:24:16.469 info (12834) xmlrpc -> 230 devices hm-rpc.0 2019-11-28 17:24:16.400 info (12834) xmlrpc <- listDevices ["hm-rpc.0"] hm-rpc.0 2019-11-28 17:24:16.395 info (12834) xmlrpc <- system.listMethods ["hm-rpc.0"] hm-rpc.0 2019-11-28 17:24:16.384 info (12834) xmlrpc client is trying to connect to 192.168.4.5:2001/ with ["http://192.168.4.30:2001","hm-rpc.0"] hm-rpc.0 2019-11-28 17:24:16.384 info (12834) xmlrpc server is trying to listen on 192.168.4.30:2001 hm-rpc.0 2019-11-28 17:24:16.162 info (12834) [META] Meta data updated hm-rpc.0 2019-11-28 17:24:16.136 info (12834) starting. Version 1.10.3 in /opt/iobroker/node_modules/iobroker.hm-rpc, node: v10.17.0