SOLVED Zuverlässigkeit IOBROKER

liv-in-sky

auf dem terminal

cat /var/log/messages | grep "TCP" | more

vielleicht kommt dann was interessantes

Homoran

@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

michaelxhoffmann

@liv-in-sky

Darf nicht mehr in die Message reinschreiben Aber das ist das komplette log

michaelxhoffmann

@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

@liv-in-sky sagte in Zuverlässigkeit IOBROKER:

cat /var/log/messages | grep "TCP" | more

Feb 26 14:17:04 localhost kernel: [ Feb 26 14:17:04 localhost kernel: [ Feb 26 14:17:04 localhost kernel: [ Feb 26 14:39:20 localhost kernel: [ Feb 26 14:39:20 localhost kernel: [ Feb 26 14:39:20 localhost kernel: [ Feb 26 14:51:21 localhost kernel: [ Feb 26 14:51:21 localhost kernel: [ Feb 26 14:51:21 localhost kernel: [ Feb 26 17:46:37 localhost kernel: [ Feb 26 17:46:37 localhost kernel: [ Feb 26 17:46:37 localhost kernel: [ Feb 26 20:54:31 localhost kernel: [ Feb 26 20:54:31 localhost kernel: [ Feb 26 20:54:31 localhost kernel: [ Feb 26 20:57:02 localhost kernel: [ Feb 26 20:57:02 localhost kernel: [ Feb 26 20:57:02 localhost kernel: [ Feb 27 15:41:38 localhost kernel: [ Feb 27 15:41:38 localhost kernel: [ Feb 27 15:41:38 localhost kernel: [ root@rock64:/opt/iobroker/log# 1.602100] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
1.602347] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
1.603118] TCP: Hash tables configured (established 16384 bind 16384)
1.610033] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
1.610281] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
1.611061] TCP: Hash tables configured (established 16384 bind 16384)
1.605956] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
1.606203] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
1.606980] TCP: Hash tables configured (established 16384 bind 16384)
1.610180] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
1.610427] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
1.611203] TCP: Hash tables configured (established 16384 bind 16384)
1.602162] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
1.602409] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
1.603191] TCP: Hash tables configured (established 16384 bind 16384)
1.610000] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
1.610247] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
1.611026] TCP: Hash tables configured (established 16384 bind 16384)
1.602138] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
1.602385] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
1.603165] TCP: Hash tables configured (established 16384 bind 16384)

Homoran

@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

@Homoran ich habe die ccu2

liv-in-sky

find idee gut von homoran - adapter aus und somit einkreisen ob iobroker sonst läuft

Homoran

@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

@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.

Homoran

@michaelxhoffmann
eins nach dem andern!

Das wird schon!

michaelxhoffmann

Das Log von dem Pi sieht noch viel schlimmer aus als das vom Rock

liv-in-sky

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?

liv-in-sky

es sollten nicht beide geräte (pi und rock ) auf die ccu zugreifen - nur eines im moment

michaelxhoffmann

@liv-in-sky nein es greift ja nur der rock drauf zu. Auf dem Pi läuft nur der SQL Adapter und der Szenenadapter

liv-in-sky

also master slave system ?

michaelxhoffmann

@liv-in-sky Ja der Pi hat ne andere ipadresse. Jetzt kommen zumindest keine Warnhinweise oder Fehler. Ja der rock ist der Master, der pi der slave.

liv-in-sky

es laufen ja noch ein paar adapter - kannst du irgendwas ausprobieren um zu sehen , ob alles richtig kommuniziert und immer schön ins log kucken

schaltet der broadlink
alexa2 - kommen die befehle durch

michaelxhoffmann

@liv-in-sky habe den IOT adapter zugeschaltet nun kommt dieser Fehler:
Cannot report device state: null
Aber ich glaube das ist der den man ignorieren kann? Weil der überarbeitet wird?

liv-in-sky

bei gelegenheit - zeigtauch mal das pi log

NEWS

SOLVED Zuverlässigkeit IOBROKER

Support us

1.5k
Online

30.2k
Users

76.3k
Topics

1.2m
Posts

NEWS

SOLVED Zuverlässigkeit IOBROKER

Support us

1.5kOnline

30.2kUsers

76.3kTopics

1.2mPosts

1.5k
Online

30.2k
Users

76.3k
Topics

1.2m
Posts