Fehlermeldung CUNO

[mcfly71]

Hat jemand eine Idee, was das bedeutet:

CUNO: Unknown code E9E82021C48E11DE88E010100003E, help me!

Ich würde ja gerne helfen....

Konfiguration: CUNO, HOMEMATIC devices

[martinp876]

Hallo mcfly

das 'E' zu Beginn bedeuted, dass CUNO im mode CUL_EM/native laeuft. Bei HM sollte es mit 'A' beginnen.

FHEM hat allen parsern die Message zum Dekodieren angeboten, keiner wollte es.
Kontrolliere deinen CUNO mode

Gruss Martin

[mcfly71]

Hallo Martin,

hmmm,

in der cfg steht:

define CUNO CUL 192.168.x.yyy:2323 1234
attr CUNO model CUN
attr CUNO rfmode HomeMatic

was ist daran falsch ?

Müsste doch so funktionieren ?!

[mcfly71]

Ok, habe das attr model CUNO rausgenommen. Seit dem ( 1 1/2 Std. ) kam diese Meldung nicht mehr.
Ich hatte nachgelesen, dass dieses Attribut nicht für manuelles Setzen geeignet ist. War das vielleicht der Grund ?

VG
mcfly

[martinp876]

model sollte besser immer gesetzt sein.
Was es in CUL bewirkt habe ich nicht nachgesehen.
Jedenfalls war es eine fehlkonfig der CUNO

[mcfly71]

Hallo Martin,

nach erneutem flashen mit der neusten BURST Mode firmware V 1.55 CUNO868
konnte ich dieses Problem beseitigen. Jedoch hört der CUNO irgendwann (jetzt bereits 2 mal in der Nacht passiert auf.)

2013.07.24 02:46:34 1: 192.168.2.170:2323 disconnected, waiting to reappear
2013.07.24 02:46:34 1: 192.168.2.170:2323 reappeared (STEUERUNG_HM)
2013.07.24 02:46:34 1: 192.168.2.170:2323 disconnected, waiting to reappear
2013.07.24 02:46:34 1: Cannot init 192.168.2.170:2323, ignoring it

Fhem läuft weiter, aber der CUNO ist tot. Ich habe das HMLan ersetzt durch einen CUNO, damit diese disconnects aufhören, diese passieren ab und zu (weniger als beim HMLan) aber trotzdem noch. Soweit so gut, aber dieses ignoring it ist natürlich der Obergau, danach ist die Heimautomatisierung natürlich tot)
Schwierige Frage (ich weiss kann man nicht mit den paar Daten beantworten) warum passiert das ?
Und : Kann ich das irgendwie abfragen, und wenn es passiert ein reboot machen, solange, bis alles wieder da ist ??

Ich verzweifle so langsam an dieser Sache....

VG
mcfly

[mcfly71]

Achso: Nach dem flashen habe ich auch alles korrekt im CUNO gesetzt:
DHCP aus, Adresse gesetzt, DNS gesetzt, Subnetmaske, und GMT+02 und NTP Server.

[martinp876]

Hallo mcfly

generell ist dir sicher klar, dass der Mechanismuss bei CUNO nichts mit dem den HMLAN zu tun hat.
Ich habe noch nicht nachgesehen, denke mich aber zu erinnern, dass hier ein Disconnect kommt, wenn der Socket abgebaut wird, sprich die unterliegende ethernet/TCP/IP connection verstirbt.
Der Mechanismus des Socket läuft in einem anderen Thread, ist also eine ganz andere Geschichte.

Es ist also die Frage ob etwas am Interface passiert.
Was interessant waere ist, was eigentlich passiert. Also CUNO disconnected, kommt wieder und ist sofort wieder weg. Und danach? Kommt es nicht mehr?

Eigentlich solltest du es im state sehen und darauf triggern koennen.

Gruss Martin

[mcfly71]

Ich schaue mal, was ich mit verbose 5 so alles finde.....
In welchem Forum soll ich es denn dann fragen / analysieren ?

P.S.
Vielleicht waren dann (einige/alle) meine HMLan disconnects auch dieser Art und es hatte garnichts
mit deinem Code zu tun..... ?!!!

[martinp876]

Hi,

ich kann schon einmal versuchen.
Ich denke Rudi hat den Teil mit sockets erstellt. Man könnte in CUL_development nach fragen.

Was ich machen würde waere, den wireshark bemühen. Hier ist auch die socket-kommunikation sichtbar. Schlecht, wenn du eine Fritzbox hast. Da kannst du auch mitloggen, musst aber anders filtern. Alle Daten mitschreiben ist selbstmord, ein guter Filter will genutzt werden.

Hängt also von System ab

Gruss Martin