Hi
irgendwie verstehe ich das nicht.
Im log wird jede Minute disconnected gelogged, aber nicht connected.
Das logging bei connected ist ja richtig das gewünschte, verstehe aber nicht warum die states unterschiedlich geloggt werden.
defmod cul_wohn_ser2net_rpi CUL 192.168.0.95:2022 3841
attr cul_wohn_ser2net_rpi addvaltrigger 1
attr cul_wohn_ser2net_rpi event-on-change-reading state
attr cul_wohn_ser2net_rpi hmId AABBCC
attr cul_wohn_ser2net_rpi hmProtocolEvents 2_dumpFull
attr cul_wohn_ser2net_rpi icon cul_868
attr cul_wohn_ser2net_rpi model nanoCUL
attr cul_wohn_ser2net_rpi rfmode HomeMatic
2018-02-22_07:26:46 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_07:27:49 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_07:28:52 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_07:29:55 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_07:30:55 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_07:31:55 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_07:32:55 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_07:33:58 cul_wohn_ser2net_rpi Initialized
2018-02-22_07:33:58 cul_wohn_ser2net_rpi CONNECTED
2018-02-22_16:47:06 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_16:48:11 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_16:49:11 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_16:50:11 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_16:51:14 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_16:52:17 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_16:53:17 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_16:54:17 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_16:55:18 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_16:56:19 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_16:57:19 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_16:58:20 cul_wohn_ser2net_rpi DISCONNECTED
2018-02-22_16:58:33 cul_wohn_ser2net_rpi Initialized
Jemand ne Idee wieso hier unterschiedlich gelogged wird?
Danke für die Hilfe
Ich würde eher vermuten, dass nicht "inkonsistent" gelogt wird, sondern eben das, was an Events auftaucht.
Scheint so zu sein, dass der CUL alle Minute angepingt wird (Standardverhalten bei Neztwerk?) und dann eben ein Disconneced festgestellt und als Event ausgeworfen wird.
Erfahrungsgemäß würde ich bei der Fehlersuche erst mal nach zwei Sachen schauen:
- Stromversorgung an dem remote-Pi
- Testpin am nanoCUL (wenn es ein FTDI-Nano ist, siehe wiki: Arduino)
Ansonsten kommt das evtl. aus der Netzwerkecke, da müßten dann aber andere helfen zur Analyse für Disconnects.
Gruß, Beta-User
Hallo Beta_user,
danke für die Hilfe.
Der disconnet ist durch das Nichtererkennen des CULs nach dem RPI boot.
Da muss ich immer ab- und wieder anstecken. Daran arbeite ich noch.
Habe aber das Attribut:
attr cul_wohn_ser2net_rpi event-on-change-reading state
extra gesetzt, so dass nicht laufend die event getriggert werden.
Für mich ist immer noch unklar, wieso für disconnected ständig ein Event und auch ein Logeintrag kommt, aber nicht für connected.?
An- und Abstecken...
Klingt nach Test-Pin ;)
Also besser: keine Workarounds an den Symptomen, sondern löten...
Zitat von: Beta-User am 22 Februar 2018, 17:40:28
An- und Abstecken...
Klingt nach Test-Pin ;)
Also besser: keine Workarounds an den Symptomen, sondern löten...
Ja den Testpin habe ich schon verlötet, aber irgendwie klappt das trotzdem nicht. Habe auch noch OSMC dort drauf laufen. Hatte auch einen anderen RPI 3 ausprobiert, da geht es . Scheint auch noch Softwareabhängigkeiten zu geben.
Kurz, da mobil:
Netzteil ausreichend? Teste ggf. mal mit einem aktiven Hub
Zitat von: Beta-User am 23 Februar 2018, 08:17:32
Kurz, da mobil:
Netzteil ausreichend? Teste ggf. mal mit einem aktiven Hub
Hi, ja netzteil ist ok.
Es klappt auch einwandfrei an einem RPI 1 B mit Stretch, nicht mit OSMC. Werde dort nochmal im Forum fragen.
Aber trotzdem verstehe ich nicht, warum - der Cul ist aktuell nicht dran - dauerhaft ein neuer Event erzeugt wird : - disconnected.
Dachte mit dem Attribut Event-on-change-reading wird eben nur der change als Event erzeugt und auch geloggt.
Zitat von: riker1 am 23 Februar 2018, 11:26:54
Dachte mit dem Attribut Event-on-change-reading wird eben nur der change als Event erzeugt und auch geloggt.
Das sollte eigentlich so sein.
Spekulation: die Disconnect-Meldung hat ein andere Prio bei den Logleveln (2, nicht 3 wie ein normales Event) und wird deshalb trotzdem ausgegeben?
Wenn er abgestöpselt ist, kannst du ihn einstweilen ja auf inaktiv setzen.