NEWS
UNSOLVED HM-RPC Verschieben auf Multihost schlägt fehl
-
Systemdata Bitte Ausfüllen Hardwaresystem: Pi4B (Hostmaster), Pi3B, 3B+ als Hostslaves Arbeitsspeicher: 3,7GB (Master) / 926MB (Slave) Festplattenart: SD-Karte/SSD (QNAP-NAS singuläres SSD-LW, mount als iobroker/log, iobroker/backups, JS-Mirror, separater Baum je Pi) Betriebssystem: Debian (Raspi) Node-Version: 12.19.0 Nodejs-Version: 12.19.0 NPM-Version: 6.16.8 Installationsart: Manuell Image genutzt: Nein Ort/Name der Imagedatei: Link HM-RPC-Instanz lässt sich nicht auf anderen HOST als den Hostmaster selbst verschieben / fehlerfrei starten. HM-RPC: 1.14.23, HM-REGA: 2.6.23
Konfiguration:
Raspi 4B als Hostmaster
Raspi 3B (auch probiert: 3B+) als SlaveHomematic / CCUs, (jeweils 1x HM-Rega):
- IP-Netz 1:
1x Raspmatic auf 3B+ (HM-RF, wired, CUx, HM-IP)
temporär 1x Raspmatic auf 3B+ mit HM-RPC: CUx für Tests bzw. Fallback-Reserve - IP-Netz 2, per Fritzbox/VPN verbunden mit Pflegewohnung der Eltern (statisches IPV4):
1x CCU2 (HM-RF, HM-IP),
Installation/Update der Iobroker-Instalaltionen (Stand 18.10.2020) lt. https://www.modius-techblog.de/smart-home/iobroker-auf-dem-raspberry-pi-installieren-und-konfigurieren/?cookie-state-change=1603050965335
Problem:
- Alle auf dem Hostmaster, laufen die RPC-Instanzen bestens.
- Auf anderen Host verschoben laufen sie nicht an / generieren Fehler im Log / beenden sich sofort wieder (zyklisch)
- Zurückgeschoben auf Hostmaster laufen sie wieder i.O.
Gegentests:
- Andere Instanzen lassen sich problemlos auf eben diese Slave-Hosts verschieben und betreiben
- Fehler ist unverändert, auch ohne Mounting für Log und Backup-Verz. auf SSD im NAS
- "Früher ging das Verschieben auf Raspi-Hosts schon mal" (ca. vor 2 Jahren, Hostmaster damals noch Win-2016 Essential Server)
- Ein Verschieben der HM-REGA-Instanzen funktioniert dagegen (zunächst) und ist auch betreibbar, allerdings schlägt dann der nächste bedarfsweise Abgleich der Objektnamen etc. fehl wg. "keine RPC-Instanz auf dem Host gefunden" (klingt logisch, solange RPC-Instanz noch auf Hostmaster hockt.)
Die konkreten Fehlerbilder sind z.T. unterschiedlich, je nach Betreibertyp der HM-RPC-Instanz:
- HM-RF, HM-IP, CUx
(HM-wired unter diesen Bedingungen noch nicht getestet, da vitaldatenrelevant / Vermeidung relevanter Fehlalarme etc.):
host.HAL-SL-03-IO-02 2020-10-26 12:27:10.681 info Restart adapter system.adapter.hm-rpc.5 because enabled host.HAL-SL-03-IO-02 2020-10-26 12:27:10.680 info instance system.adapter.hm-rpc.5 terminated with code 0 (NO_ERROR) hm-rpc.5 2020-10-26 12:27:08.920 info (26772) Terminated (NO_ERROR): Without reason hm-rpc.5 2020-10-26 12:27:08.918 info (26772) terminating hm-rpc.5 2020-10-26 12:27:08.752 error (26772) TypeError: adapter.objects.getObject is not a function at handleValueParamSetDescriptions (/opt/iobroker/node_modules/iobroker.hm-rpc/hm-rpc.js:667:25) at /opt/iobroker/node_modules/io hm-rpc.5 2020-10-26 12:27:08.748 error (26772) uncaught exception: adapter.objects.getObject is not a function hm-rpc.5 2020-10-26 12:27:08.333 warn (26772) adapter.objects.getObjectView is deprecated, and will be removed in the future. Please use adapter.getObjectView/Async. Report this to Developer! hm-rpc.5 2020-10-26 12:27:08.330 warn (26772) adapter.objects.getObjectView is deprecated, and will be removed in the future. Please use adapter.getObjectView/Async. Report this to Developer!
- auf CUx-Instanz
(nicht konstant nachvollziehbar, aber mehrfach aufgetreten, darum kein Screenshot):
Fehlermeldung im Log, dass die HM-RPC-Instanz keine Verbindung zu <(IP-Addr):8701 aufnehmen kann,
ABER: <IP-Addr> ist nicht etwa wie erwartet die der CCU/Raspmatic, sondern die des HOSTMASTERs !?!Trivias / Überlegungen zur Fehlereingrenzung:
- Firefall-Regel-Probleme etc. schliesse ich aus, da die CCU/Raspmatic seit mehreren Jahren unverändert (außer updates) laufen. Instanz nur auf Hostmaster läuft ebenfalls korrekt. Lediglich der Iobroker wurde von Win-2016 Essential Server neu auf Raspi4B aufgesetzt
- Die Raspi-Slaves wurden nach o.g. Link neu aufgesetzt / geupdatet und arbeiten mit anderen Instanzen ebenfalls korrekt
- der VPN-Tunnel ist mit beidseits 50mbit seit ebenfalls ca. 3 Jahren äußerst stabil, Latenz wenn überhaupt bemerkbar, bei <1sek. (so offenbar neuer Verbindungsaufbau / Routing) - Der Fehler tritt auch ohne VPN-Nutzung (nur im lokalen Netzdegment des Hostmasters) auf!
Ich würde gern den Hostmaster durch Clusterung / Dezentralisierung von Aufgaben entlasten, da er noch weitere dringende Aufgaben synchronisieren soll!
Wenn ich durch Tests o.ä. zur Fehlerbeseitigung beitragen kann, geren! Alledings kann ich berufsbedingt nicht jeden Tag hier mitlesen oder auf das System zugreifen!
Danke für die Hilfe!
PS: Auch die Info: "Multihost bei HM-Instanzen künftig nicht mehr vorgesehen" wäre zwar schade, aber hilfreich, um dann Aufwand nicht mehr in tote Wege zu investieren!
- IP-Netz 1:
-
@bb61 Ich habe nur quergelesen und nicht alles auf Anhieb nachvollziehen können.
Was mir in die Augen sprang ist:
- IP-Netz 1
- IP-Netz 2
Leider keinerlei Screenshots von irgendwelchen Konfigurationen.
Hast du die Callback-Adressen korrekt eingefügt?
@bb61 sagte in HM-RPC Verschieben auf Multihost schlägt fehl:
Multihost bei HM-Instanzen künftig nicht mehr vorgesehen" wäre zwar schade, aber hilfreich
Warum sollte das nicht laufen, das Problem muss an deiner Umgebung liegen
-
@Homoran
sicher.- es läuft seit Jahren
- es läuft, solange Instanz auf Hostmaster konfiguriert ist
- Fehler tritt auch auf, wenn es nur um Geräte im Netz 1 geht (wo der Hostmaster und eine der raspmatic/CCUs ist)
Ich werde es dennoch nochmal kontrollieren, sobald ich wieder vor Ort bin
-
Warum sollte das nicht laufen, das Problem muss an deiner Umgebung liegen
ich sehe aber Fehlermeldungen bzgl. des Instanzen-Scripts. Ds hat mit der Umgebung sicher eher wenig zu tun, oder?
hm-rpc.5 2020-10-26 12:27:08.752 error (26772) TypeError: adapter.objects.getObject is not a function at handleValueParamSetDescriptions (/opt/iobroker/node_modules/iobroker.hm-rpc/hm-rpc.js:667:25) at /opt/iobroker/node_modules/io hm-rpc.5 2020-10-26 12:27:08.748 error (26772) uncaught exception: adapter.objects.getObject is not a function
-
@bb61 sagte in HM-RPC Verschieben auf Multihost schlägt fehl:
Fehler tritt auch auf, wenn es nur um Geräte im Netz 1 geht
klar wenn keine Callback-Adresse drin ist
-
@Homoran
???? Die Konfiguration der Instanz ist doch unverändert (Admin-GUI), wieso geht es dann auf Hostmaster laufend? -
@bb61 sagte in HM-RPC Verschieben auf Multihost schlägt fehl:
Die Konfiguration der Instanz ist doch unverändert
das ist doch genau das Problem
Mag sein dass ich mich irre, aber wenn die CCU an die IP des Masters schickt, der Adapter aber auf dem Slave ist....
-
@Homoran
ok, klingt zielführend....Callback-Adresse: Da also die Adresse des jeweiligen Slaves eintragen?
-
@bb61 sagte in HM-RPC Verschieben auf Multihost schlägt fehl:
@Homoran
ok, klingt zielführend....Callback-Adresse: Da also die Adresse des jeweiligen Slaves eintragen?
Jetzt bin ich selber total irritiert
Hätte ich gemacht - mach es bitte wenigstens mal zum Testen.
Andererseits soll ja alles über den Master verwaltet werden. Aber warum sollte man dann die Instanz verschieben
EDIT:
Nach kurzer Überlegung:Steht denn da überhaupt etwas drin?
sonst muss da vielleicht die IP des Masters rein weil es sonst eben genau zum slave geht und der damit nichts anfangen kann -
@Homoran
...genau das überlegte ich ja auch (bisher)klar, ich werd es probieren, sobald ich Zugriff habe. Wenns klappt heute abend schon.
Danke erstmal für den Tipp!
-
@bb61 habe eben noch mal meine Gedanken gesammelt und editiert!
@foxriver76
gibt es für hm-rpc in verschiedenen Netzen oder Master / Slave überhaupt eine Vorschrift? -
@Homoran
ich sah es...Vorschrift.... bisher keine gefunden dazu.... wäre ja toll, wenn das so einfach lösbar wäre
-
@bb61 habe den Thread nicht gelesen der Fehler oben deutet daraufhin, dass da uralter Code ausgeführt wird. Evtl ist auf dem Host auf den du die Instanzen verschoben hast eine veraltetet Version installiert.
-
@foxriver76
Slave komplett neu installiert / updated vorher wie folgt:
und alle Adapter aktuell natürlich.
HM-RPC: 1.14.23, HM-REGA: 2.6.23
Stand: 2020-10-18apt-get update
apt-get dist-upgradecurl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash -
apt install -y nodejs
curl -sL https://iobroker.net/install.sh | bash - -
hm-rpc.5 2020-10-26 12:27:08.748 error (26772) uncaught exception: adapter.objects.getObject is not a function hm-rpc.5 2020-10-26 12:27:08.333 warn (26772) adapter.objects.getObjectView is deprecated, and will be removed in the future. Please use adapter.getObjectView/Async. Report this to Developer! hm-rpc.5 2020-10-26 12:27:08.330 warn (26772) adapter.objects.getObjectView is deprecated, and will be removed in the future. Please use adapter.getObjectView/Async. Report this to Developer!
Keiner dieser Zeilen ist in einer Version > 1.12.0 drin.
-
@foxriver76
hmmm....
wie lange gibt es Raspi 4?meinen gekauft im Frühjahr,
Grundinstallation im Sommer
IO-Broker und Update wie oben im Herbst (September?)HM-Instanz installiert ebenfalls da (die in Sep 2020 aktuelle!)
im Oktober dann verschoben auf Slave-Host (vorher ebenfalls wie oben beschrieben neu gemacht)WO KOMMT DAS DANN HER??
Und: mindestens auf 2 Slaves identischer Fehler?
-
@bb61 Naja, es ist durchaus möglich, alte Versionen zu installieren. Zeig mal den Inhalt der package.json, also auf dem Slave wo der Fehler auftritt
cat /opt/iobroker/node_modules/iobroker.hm-rpc/package.json | grep version\":
-
Du hast Recht:
Hostmaster (ist ok):
root@HAL-9002:/home/pi# cat /opt/iobroker/node_modules/iobroker.hm-rpc/package.json | grep version\ > "type": "version", "version": "1.14.23" root@HAL-9002:/home/pi#
aber der Slave!!!:
root@HAL-SL-02-IO-01:/home/pi# cat /opt/iobroker/node_modules/iobroker.hm-rpc/package.json | grep version "version": "1.9.6"
Überbleibsel trotz neuinstallation???
Habe
- den Adapter deinstalliert: "iobroker del hm-rega" (lt. screen erfolgreich!)
- Slave rebootet
- danach Instanz wieder auf den Slave verschoben:
--> unverändert - Fehler noch da
- immernoch / wieder(??!) die alte Version des HM-Rega
--> Ist das evtl. ein Problem beim Nachinstallieren auf dem Slave beim Verschieben per Multihost, dass dann die alte Version genommen wird???
EDIT:
Sorry, Sehe grad, dass ich das am HM-Rega gemacht habe, statt am HM-RPC....Ich probiere es grad nochmal
-
@bb61 sagte in HM-RPC Verschieben auf Multihost schlägt fehl:
root@HAL-SL-02-IO-01
-
jetzt hat Neuinstalaltion geklappt.
Zwischendurch auch nochmal abgefragt bzgl. version: Kein Verzeichnis gefunden
Ebenso im Log zusehen konnte, dass er neu installiertABER:
nun in der tat bei Install (getriggert durch Verschiebung auf Slave) ANDERE Version als Host-Master installiert wordenroot@HAL-SL-02-IO-01:/home/pi# cat /opt/iobroker/node_modules/iobroker.hm-rpc/package.json | grep version "type": "version", "version": "1.14.15" root@HAL-SL-02-IO-01:/home/pi#
Und: Neue andere Fehler
(liegen die nun an der Callback-Adresse?)host.HAL-SL-02-IO-01 2020-10-26 14:38:57.417 error instance system.adapter.hm-rpc.6 terminated with code 1 (JS_CONTROLLER_STOPPED) host.HAL-SL-02-IO-01 2020-10-26 14:38:57.416 error Caught by controller[0]: at processTicksAndRejections (internal/process/task_queues.js:85:21) host.HAL-SL-02-IO-01 2020-10-26 14:38:57.416 error Caught by controller[0]: at doListen (net.js:1502:7) host.HAL-SL-02-IO-01 2020-10-26 14:38:57.415 error Caught by controller[0]: at listenInCluster (net.js:1365:12) host.HAL-SL-02-IO-01 2020-10-26 14:38:57.415 error Caught by controller[0]: at Server.setupListenHandle [as _listen2] (net.js:1300:21) host.HAL-SL-02-IO-01 2020-10-26 14:38:57.414 error Caught by controller[0]: Error: listen EADDRNOTAVAIL: address not available 192.168.1.210:8701 hm-rpc.6 2020-10-26 14:38:57.198 info (1440) binrpc -> 192.168.1.212:8701/ init ["xmlrpc_bin://192.168.1.210:8701",""] hm-rpc.6 2020-10-26 14:38:57.196 error (1440) Error: listen EADDRNOTAVAIL: address not available 192.168.1.210:8701 at Server.setupListenHandle [as _listen2] (net.js:1300:21) at listenInCluster (net.js:1365:12) at doListen (net hm-rpc.6 2020-10-26 14:38:57.195 error (1440) uncaught exception: listen EADDRNOTAVAIL: address not available 192.168.1.210:8701
Die Adresse des HOSTmasters eingetragen:
--> connected!