Zuverlässigkeit IOBROKER
-
du hast 3 hm-rpc Instanzen angelegt, deaktivere mal 0 und 1 davon... irgendwas beisst sich da, laut deiner Fehlerbeschreibung.
Sicher dass dein iobroker Internetzugang hat?
@ilovegym Internetzugang? Wie soll ich den denn gesperrt haben? 🤔 das läuft doch alles intern
-
@ilovegym Internetzugang? Wie soll ich den denn gesperrt haben? 🤔 das läuft doch alles intern
@michaelxhoffmann nee, du hast u.a. den iot-adapter installiert, der will natuerlich raus.. deshalb steht der auf Fehler..
-
kannst du mal das ganze log vom iobroker anhängen? /opt/iobroker/log
-
hast du mal gecheckt, ob in der fritzbox irgend welche fehlermeldungen sind
-
auf dem terminal
cat /var/log/messages | grep "TCP" | more
vielleicht kommt dann was interessantes
-
Ich verzweifele und habe zwischenzeitlich auch keinen Bock mehr. Niegelnagelneu aufgesetzt, von der Picke auf und alles was ich bisher erreicht habe ist ein unzuverlässiges System das nur Fehler produziert
Dabei habe ich noch nicht mal viele Adapter. Aber selbst die wenigen funktionieren nicht mal ansatzweise zuverlässig. Jetzt meine Frage: Ich glaube nicht dass beide meiner MiniPC defekt sind, auch bezweifele ich dass es irgendetwas mit den Netzteilen zu tun hat., die wurden zwischenzeitlich mehrfach getauscht. Mit ist auch nicht klar weshalb der Homematicadapter rumspinnt. Was bedeutet das Econnreset und diese zahllosen timeouts? Die folgenden Adapter habe ich installiert
Wo kann ich noch ansetzen?@michaelxhoffmann sagte in Zuverlässigkeit IOBROKER:
alles was ich bisher erreicht habe ist ein unzuverlässiges System das nur Fehler produziert
Das zieht sich jetzt leider durch mehrere Threads.
Wie können wir dir noch helfen?Die beiden aktuell Helfenden sind dir schon mal sehr empfohlen ;-)
Wärst du nochmal bereit ganz langsam ganz von vorne zu beginnen - damit wir den Wurm endlich finden?
Gruß
Rainer -
hast du mal gecheckt, ob in der fritzbox irgend welche fehlermeldungen sind
-
@michaelxhoffmann sagte in Zuverlässigkeit IOBROKER:
alles was ich bisher erreicht habe ist ein unzuverlässiges System das nur Fehler produziert
Das zieht sich jetzt leider durch mehrere Threads.
Wie können wir dir noch helfen?Die beiden aktuell Helfenden sind dir schon mal sehr empfohlen ;-)
Wärst du nochmal bereit ganz langsam ganz von vorne zu beginnen - damit wir den Wurm endlich finden?
Gruß
Rainer@Homoran Naja ich habe ja ganz am anfang angefangen. Ich komme ja noch nicht mal aus dem Startblock raus .... Zum Glück bin ich zur Zeit im Krankenstand, sonbst hätte ich schon längst alles wieder verworfen.
-
auf dem terminal
cat /var/log/messages | grep "TCP" | more
vielleicht kommt dann was interessantes
@liv-in-sky sagte in Zuverlässigkeit IOBROKER:
cat /var/log/messages | grep "TCP" | more
Feb 26 14:17:04 localhost kernel: [ 1.602100] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
Feb 26 14:17:04 localhost kernel: [ 1.602347] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
Feb 26 14:17:04 localhost kernel: [ 1.603118] TCP: Hash tables configured (established 16384 bind 16384)
Feb 26 14:39:20 localhost kernel: [ 1.610033] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
Feb 26 14:39:20 localhost kernel: [ 1.610281] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
Feb 26 14:39:20 localhost kernel: [ 1.611061] TCP: Hash tables configured (established 16384 bind 16384)
Feb 26 14:51:21 localhost kernel: [ 1.605956] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
Feb 26 14:51:21 localhost kernel: [ 1.606203] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
Feb 26 14:51:21 localhost kernel: [ 1.606980] TCP: Hash tables configured (established 16384 bind 16384)
Feb 26 17:46:37 localhost kernel: [ 1.610180] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
Feb 26 17:46:37 localhost kernel: [ 1.610427] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
Feb 26 17:46:37 localhost kernel: [ 1.611203] TCP: Hash tables configured (established 16384 bind 16384)
Feb 26 20:54:31 localhost kernel: [ 1.602162] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
Feb 26 20:54:31 localhost kernel: [ 1.602409] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
Feb 26 20:54:31 localhost kernel: [ 1.603191] TCP: Hash tables configured (established 16384 bind 16384)
Feb 26 20:57:02 localhost kernel: [ 1.610000] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
Feb 26 20:57:02 localhost kernel: [ 1.610247] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
Feb 26 20:57:02 localhost kernel: [ 1.611026] TCP: Hash tables configured (established 16384 bind 16384)
Feb 27 15:41:38 localhost kernel: [ 1.602138] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
Feb 27 15:41:38 localhost kernel: [ 1.602385] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
Feb 27 15:41:38 localhost kernel: [ 1.603165] TCP: Hash tables configured (established 16384 bind 16384)
root@rock64:/opt/iobroker/log# -
@Homoran Naja ich habe ja ganz am anfang angefangen. Ich komme ja noch nicht mal aus dem Startblock raus .... Zum Glück bin ich zur Zeit im Krankenstand, sonbst hätte ich schon längst alles wieder verworfen.
@michaelxhoffmann
Ich tippe da auch auf das Netzwerk - bin da aber nicht so fit.Ich würde jetzt ALLE Adapter, bis auf admin, hm-rega und den hm-rpc für rfd deaktivieren (also auch cuxD und HM-IP!)
dann sehen wir uns die Konfig der beiden hm-Adapter und die Konfig der CCU (welche genau?) an.
-
@michaelxhoffmann
Ich tippe da auch auf das Netzwerk - bin da aber nicht so fit.Ich würde jetzt ALLE Adapter, bis auf admin, hm-rega und den hm-rpc für rfd deaktivieren (also auch cuxD und HM-IP!)
dann sehen wir uns die Konfig der beiden hm-Adapter und die Konfig der CCU (welche genau?) an.
-
find idee gut von homoran - adapter aus und somit einkreisen ob iobroker sonst läuft
-
@Homoran ich habe die ccu2
@michaelxhoffmann sagte in Zuverlässigkeit IOBROKER:
@Homoran ich habe die ccu2
Gottseidank, dann sind die möglichen Probleme der CCU3 ja schon mal wenigstens vom Tisch
Tschakka, das schaffen wir
EDIT: Nur zur Sicherheit: Du hast einen Rock64 keinen Rockpro?
-
@michaelxhoffmann sagte in Zuverlässigkeit IOBROKER:
@Homoran ich habe die ccu2
Gottseidank, dann sind die möglichen Probleme der CCU3 ja schon mal wenigstens vom Tisch
Tschakka, das schaffen wir
EDIT: Nur zur Sicherheit: Du hast einen Rock64 keinen Rockpro?
@Homoran Tja nun denn Nun habe ich alle Adapter mit Ausnahme des Admin der beiden HM deaktiviert. Gut so weit, aber ich habe ja die Probleme auch mit den Adaptern die jetzt abgeschaltet sind.
Homematic CCU2 - Raspberry Pi 4 - IOS (siri) - Amazon Echo 3rd Gen.
-
@Homoran Tja nun denn Nun habe ich alle Adapter mit Ausnahme des Admin der beiden HM deaktiviert. Gut so weit, aber ich habe ja die Probleme auch mit den Adaptern die jetzt abgeschaltet sind.
@michaelxhoffmann
eins nach dem andern!Das wird schon!
-
Das Log von dem Pi sieht noch viel schlimmer aus als das vom Rock
-
wir müssen irgendwie einkreisen - wenn du das iobroker log anschaust - was kommt da jetzt so - ohne adapter
der pi läuft auch? - aber mit anderer ip adresse oder?
-
es sollten nicht beide geräte (pi und rock ) auf die ccu zugreifen - nur eines im moment
-
es sollten nicht beide geräte (pi und rock ) auf die ccu zugreifen - nur eines im moment
@liv-in-sky nein es greift ja nur der rock drauf zu. Auf dem Pi läuft nur der SQL Adapter und der Szenenadapter
-
also master slave system ?
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register LoginSupport us
561
Online32.7k
Users82.6k
Topics1.3m
Posts