Beim Absetzen von Befehlen an HM disconnected CUNO

[locodriver]

                                                         

Hallo Miteinander.

Ich schlage mich seit geraumer Zeit mit dem Problem herum, dass der CUNO2
beim Absenden von Befehlen (in diesem Fall "set desired temp" an den TC)
sich verabschiedet. Siehe Log:

2012.12.08 14:43:25 1: Including fhem.cfg
2012.12.08 14:43:26 3: telnetPort: port 7072 opened
2012.12.08 14:43:26 1: Including
/var/InternerSpeicher/fhem/FHEM/00_Webinterface.cfg
2012.12.08 14:43:27 3: WEB: port 8083 opened
2012.12.08 14:43:27 3: WEBphone: port 8084 opened
2012.12.08 14:43:27 3: WEBtablet: port 8085 opened
2012.12.08 14:43:27 1: Including
/var/InternerSpeicher/fhem/FHEM/02_Autocreate.cfg
2012.12.08 14:43:27 1: Including
/var/InternerSpeicher/fhem/FHEM/04_Funkinterface.cfg
2012.12.08 14:43:27 3: Opening CUNO2 device 192.168.178.100:2323
2012.12.08 14:43:27 3: CUNO2 device opened
2012.12.08 14:43:27 3: CUNO2: Possible commands: mBCFiAIGMRTVWXOefltuxEcq
2012.12.08 14:43:27 2: Switched CUNO2 rfmode to HomeMatic
2012.12.08 14:43:27 2: Switched IRDEV irReceive to ON_NR
2012.12.08 14:43:27 1: Including
/var/InternerSpeicher/fhem/FHEM/06_Devices.cfg
2012.12.08 14:43:29 1: Including
/var/InternerSpeicher/fhem/FHEM/08_Floorplan.cfg
2012.12.08 14:43:29 1: Including
/var/InternerSpeicher/fhem/FHEM/10_Wetter.cfg
2012.12.08 14:43:30 1: Including
/var/InternerSpeicher/fhem/FHEM/12_Raumklima.cfg
2012.12.08 14:43:30 1: Including /var/InternerSpeicher/fhem/FHEM/14_Rola.cfg
2012.12.08 14:43:30 1: Including
/var/InternerSpeicher/fhem/FHEM/16_Heizung.cfg
2012.12.08 14:43:30 1: Including /var/InternerSpeicher/fhem/FHEM/99_Test.cfg
2012.12.08 14:43:30 1: Including ./log/fhem.save
2012.12.08 14:43:30 1: usb create starting
2012.12.08 14:43:31 1: usb create end
2012.12.08 14:43:31 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no
basicAuth attribute. telnetPort has no password/globalpassword attribute.  
Restart fhem for a new check if the problem is fixed, or set the global
attribute motd to none to supress this message.
2012.12.08 14:43:31 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id:
fhem.pl 2246 2012-12-01 20:00:04Z borisneubert $, pid 2809)
2012.12.08 14:43:48 2: CUL_HM set WZ_Rolali on rxt:1
2012.12.08 14:43:51 2: CUL_HM set WZ_Rolare on rxt:1
2012.12.08 14:43:57 2: CUL_HM set Rolaautomatik on rxt:1
2012.12.08 14:46:15 2: CUL_HM set WZ_Regler_Climate desired-temp 19.0 rxt:12
2012.12.08 14:48:34 2: CUL_HM set WZ_Regler desired-temp 19.0 rxt:12
2012.12.08 14:50:16 1: Including fhem.cfg
2012.12.08 14:50:16 3: telnetPort: port 7072 opened
2012.12.08 14:50:16 1: Including
/var/InternerSpeicher/fhem/FHEM/00_Webinterface.cfg
2012.12.08 14:50:16 3: WEB: port 8083 opened
2012.12.08 14:50:16 3: WEBphone: port 8084 opened
2012.12.08 14:50:16 3: WEBtablet: port 8085 opened
2012.12.08 14:50:16 1: Including
/var/InternerSpeicher/fhem/FHEM/02_Autocreate.cfg
2012.12.08 14:50:16 1: Including
/var/InternerSpeicher/fhem/FHEM/04_Funkinterface.cfg
2012.12.08 14:50:16 3: Opening CUNO2 device 192.168.178.100:2323
2012.12.08 14:53:24 3: Can't connect to 192.168.178.100:2323: Connection
timed out
2012.12.08 14:53:24 2: CUNO2: Mode HomeMatic not supported
2012.12.08 14:53:24 3: CUNO2: Mode HomeMatic not supported
2012.12.08 14:53:24 2: Switched IRDEV irReceive to NoAnswer
2012.12.08 14:53:24 1: Including
/var/InternerSpeicher/fhem/FHEM/06_Devices.cfg
2012.12.08 14:53:24 1: define: HMid DEF already used by ActionDetector
2012.12.08 14:53:24 3: Please define ActionDetector first
2012.12.08 14:53:24 3: Please define ActionDetector first
2012.12.08 14:53:24 3: Please define ActionDetector first
2012.12.08 14:53:24 1: define: HMid DEF already used by WZ_Rolali
2012.12.08 14:53:24 3: Please define WZ_Rolali first
2012.12.08 14:53:24 3: Please define WZ_Rolali first
...usw

Um 14:48 schickte ich den Befehl heraus (nicht über Eingabefeld) und dann
folgte ohne weitere Eingabe von Befehlen ein Neueinlesen der cfg und der
CUNO2 fand keine HM-Geräte mehr. Hat noch jemand mit dem Problem zu tun?
Ich habe den CUNO2 seit einigen Wochen mit der FW 1.46 laufen, ich kann
aber momentan nicht sagen, ob das Problem mit der alten FW (1.44) aus so
bestand. Kann es sein, dass bei den letzten großen Änderungen bezüglich
HM-Funktionen (insbesondere die TC - VD - Thematik) irgendwelche
"Seiteneffekte" entstanden sind?
Ein Neustart der FB 7390 bzw. ein shutdown und restart bzw. ein Start mit
Hilfe von Putty bringt meist auch keine Verbesserung (und ist ja auch nicht
die Lösung). Leider bin ich oft nicht zu Hause und greife mit VPN auf die
FB zu - zum Fehlereingrenzen ist das dann leider auch nicht ideal.
Ist es in diesem Zusammenhang möglich, die Timeoutzeit (momentan ca. 3
Min.) runterzusetzen, um in diesen Fällen schneller auf fhem zugreifen zu
können?
Ich habe seit Sommer meine cfg in mehrere Teile gesplittet, das hat auch
lange funktioniert - daran liegt es meiner Meinung nach nicht. Die ersten
Includefiles sind nur die entsprechenden Teile er Originalcfg (00_ , 02_
und 04_).

Danke für Eure Hinweise, Uwe

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[locodriver]

                                                         

Das ist ja schade, vielleicht werde ich, wenn ich wieder zu Hause bin, die
FW nochmal auf 1.44 downgraden und beobachten, ob der CUNO2 dann wieder
stabiler läuft.
Schönen Sonntag.

Am Samstag, 8. Dezember 2012 17:50:00 UTC+1 schrieb Prof. Dr. Peter A.
Henning:
>
> Das Problem habe ich ebenfalls, sowie schon mit Dirk Tostmann darüber
> diskutiert - bisher keine Lösung gefunden. Abschalten von IR vor der
> Compilierung hift etwas, aber nicht vollständig.
>
> Das Ding ist mit dieser Firmware so ausgelastet, dass es im 00_CUL.pm
> regelmäßig einen Timeout gibt.
>
> LG
>
> pah
>
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Das Problem habe ich ebenfalls, sowie schon mit Dirk Tostmann darüber
diskutiert - bisher keine Lösung gefunden. Abschalten von IR vor der
Compilierung hift etwas, aber nicht vollständig.

Das Ding ist mit dieser Firmware so ausgelastet, dass es im 00_CUL.pm
regelmäßig einen Timeout gibt.

LG

pah


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[locodriver]

                                                         

Habe jetzt nochmal auf FW 1.44 downgegradet. CUNO lief eine Weile und hat
sich dann wieder verabschiedet (Timeout). Ich habe das Verhalten mal kurz
Herr Tostmann geschildert - er vermutet ein Netzwerktimingproblem. Der CUNO
hat nur einen 10 Mbit-Chip und könnte sozusagen bei zu viel/zu schnellem
Traffic im Netzwerk "aus dem Tritt" kommen. Meine NW-Architektur habe ich
aber nicht verändert und der CUNO lief monatelang ohne diese Probleme. Mein
NW sieht so aus: FB 7390 mit fhem 5.3 daran ext. Festplatte und Verbindung
mit Cat6-Kabel zur 2. FB 7150. Daran Sat-Receiver, CUNO2 und Notebook. Alle
Geräte habe eine feste IP-Adresse (CUNO die 192.168.178.100).

Hat noch jemand dieses Problem bzw. einen Lösungsansatz?

Danke Uwe.

Am Sonntag, 9. Dezember 2012 13:35:54 UTC+1 schrieb Uwe:
>
> Das ist ja schade, vielleicht werde ich, wenn ich wieder zu Hause bin, die
> FW nochmal auf 1.44 downgraden und beobachten, ob der CUNO2 dann wieder
> stabiler läuft.
> Schönen Sonntag.
>
> Am Samstag, 8. Dezember 2012 17:50:00 UTC+1 schrieb Prof. Dr. Peter A.
> Henning:
>>
>> Das Problem habe ich ebenfalls, sowie schon mit Dirk Tostmann darüber
>> diskutiert - bisher keine Lösung gefunden. Abschalten von IR vor der
>> Compilierung hift etwas, aber nicht vollständig.
>>
>> Das Ding ist mit dieser Firmware so ausgelastet, dass es im 00_CUL.pm
>> regelmäßig einen Timeout gibt.
>>
>> LG
>>
>> pah
>>
>>
>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[locodriver]

                                                         

Ergänzung: an der 7390 hängt natürlich noch der Win7 Tower über Gigabit-LAN
und die 2.FB ist eine 7170 nicht 7150. Und alle Geräte haben max. einen 100
Mbit LAN-Anschluss.
Ich habe jetzt mal den CUNO an die 7390 gehängt und fhem neu gestartet -
jetzt funzt erst mal alles wieder - mal sehen, wie lange!

Am Dienstag, 18. Dezember 2012 11:30:08 UTC+1 schrieb Uwe:
>
> Habe jetzt nochmal auf FW 1.44 downgegradet. CUNO lief eine Weile und hat
> sich dann wieder verabschiedet (Timeout). Ich habe das Verhalten mal kurz
> Herr Tostmann geschildert - er vermutet ein Netzwerktimingproblem. Der CUNO
> hat nur einen 10 Mbit-Chip und könnte sozusagen bei zu viel/zu schnellem
> Traffic im Netzwerk "aus dem Tritt" kommen. Meine NW-Architektur habe ich
> aber nicht verändert und der CUNO lief monatelang ohne diese Probleme. Mein
> NW sieht so aus: FB 7390 mit fhem 5.3 daran ext. Festplatte und Verbindung
> mit Cat6-Kabel zur 2. FB 7150. Daran Sat-Receiver, CUNO2 und Notebook. Alle
> Geräte habe eine feste IP-Adresse (CUNO die 192.168.178.100).
>
> Hat noch jemand dieses Problem bzw. einen Lösungsansatz?
>
> Danke Uwe.
>
> Am Sonntag, 9. Dezember 2012 13:35:54 UTC+1 schrieb Uwe:
>>
>> Das ist ja schade, vielleicht werde ich, wenn ich wieder zu Hause bin,
>> die FW nochmal auf 1.44 downgraden und beobachten, ob der CUNO2 dann wieder
>> stabiler läuft.
>> Schönen Sonntag.
>>
>> Am Samstag, 8. Dezember 2012 17:50:00 UTC+1 schrieb Prof. Dr. Peter A.
>> Henning:
>>>
>>> Das Problem habe ich ebenfalls, sowie schon mit Dirk Tostmann darüber
>>> diskutiert - bisher keine Lösung gefunden. Abschalten von IR vor der
>>> Compilierung hift etwas, aber nicht vollständig.
>>>
>>> Das Ding ist mit dieser Firmware so ausgelastet, dass es im 00_CUL.pm
>>> regelmäßig einen Timeout gibt.
>>>
>>> LG
>>>
>>> pah
>>>
>>>
>>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

nur ein Schuss ins Blaue:
braucht die CUNO irgendwelche keep-alive?
hast du WOL laufen? dann schalte es einmal ab - komplett - oder setze den
timer runter

wenn alles nicht klappt solltest du die messages zur CUNO loggen - am
besten mit verbose auf 1 und loglevel der CUNO (CUL) auf 1. mseglog  = 1
waere auch gut

Falls es am Lan liegen sollte - und fhem auf der 7390 laeuft kannst du
natuerlich auch das capture interface der 7390 nutzen - macht auch sinn bei
LAN problemen. Loggen und posten


Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[locodriver]

                                                         

Hallo Martin, WOL benutze ich nicht - habe schon gelesen, dass es Probleme
machen kann. Seit ca. 1 Std. läuft der CUNO2 an der 7390 - bis jetzt ohne
disconnect. Wie kann ich den LAN-Verkehr der FB loggen - ich kann mit
Deinem Hinweis auf Capture interface nichts anfangen?

Uwe

Am Dienstag, 18. Dezember 2012 12:31:03 UTC+1 schrieb Martin:
>
> nur ein Schuss ins Blaue:
> braucht die CUNO irgendwelche keep-alive?
> hast du WOL laufen? dann schalte es einmal ab - komplett - oder setze den
> timer runter
>
> wenn alles nicht klappt solltest du die messages zur CUNO loggen - am
> besten mit verbose auf 1 und loglevel der CUNO (CUL) auf 1. mseglog  = 1
> waere auch gut
>
> Falls es am Lan liegen sollte - und fhem auf der 7390 laeuft kannst du
> natuerlich auch das capture interface der 7390 nutzen - macht auch sinn bei
> LAN problemen. Loggen und posten
>
>
> Gruss
> Martin
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com