On 05/02/2011 08:10 PM, ronny_b wrote:
> ich versuche gerade, einige Heizzeiten zu meinen 5 FHTs zu schicken.
> Einer der 5 will die Befehle einfach nicht haben.
hast Du den fünften schonmal neu gepaart?
> fhem.pl 7072 "set Heizung_Kueche sun-to2 21:30 mon-from1 07:00 mon-to1
> 24:00 mon-from2 24:00 mon-to2 21:30 tue-from1 07:00 tue-to1 24:00"
>
> Fhem versucht auch zu senden:
Nein, tut er nicht. Der lazy mode stellt fest, daß der neue Zustand der
gleiche ist wie derjenige, den fhem sich gemerkt hat. fhem weiß ja
nicht, daß der FHT nichts mitbekommen hat, Schalte mal den lazy mode aus.
> Ich muß erst das CUL-Modul abziehen, damit der Puffer gelöscht wird
> (gibt's dafür eigentlich auch einen Befehl?), ansonsten kommen vom
> besagten FHT nur noch die actuator-Meldungen.
set CUL raw T01 <HOUSECODE>
Grüße,
Boris
Ein Datensatz wird erst dann aus dem CUL FHT-Puffer geloescht, nachdem die letzte
Bestaetigung von der FHT Empfangen wurde. In diesem Log sieht man, dass
immerhin einige Nachrichten bestaetigt wurden (sonst wuerde culfw die naechste
Nachricht nicht losschicken), aber wohl nicht das letzte, da der Puffer nicht
geloescht ist. In diesem Fall koennte man versuchen die Kommandos als
separate Datensaetze zu senden (separate "set Heizung_Kueche" Kommandos in
fhem). Insgesamt scheint aber die Verbindung gestoert zu sein.
hast Du den fünften schonmal neu gepaart?
> Fhem versucht auch zu senden:
Nein, tut er nicht. Der lazy mode stellt fest, daß der neue Zustand der
gleiche ist wie derjenige, den fhem sich gemerkt hat. fhem weiß ja
nicht, daß der FHT nichts mitbekommen hat, Schalte mal den lazy mode aus.
set CUL raw T01 <HOUSECODE>
Rudi, das Problem hat Ähnlichkeit mit meiner Beobachtung, daß ab einer
gewissen Anzahl von gleichzeitig abgesetzten time/date-Kommandos der CUN
abstürzt (CUN DISCONNECTED, Problem in culfw 1.39 und 1.40 nachweisbar).
Könnte es sich um ein Firmwareproblem handeln?
Viele Grüße
Boris
Richtigstellung: :)
- Also ich bin nicht ganz sicher, ob dein Fall mit dem hier was gemeinsam hat,
ich vermute hier eher ein Problem bei dem FHT bzw. regelmaessige
Funkstoerungen. Aber vermuten ist lange noch nicht wissen.
- Weiterhin konnte ich bisher leider Dein Fall auch nicht nachstellen (habs
aber auch nicht sehr lange probiert, und liegt auf der TODO Liste).
> K�nnte es sich um ein Firmwareproblem handeln?
Sicher doch. :)
Funktioniert 5 Zuverlaessig?
Wenn ja, waere das als workaround akzeptabel?
Ich rede schon wie einer der das Zeug verkauft :)
habe es jetzt auf CUN mit culfw 1.39 versucht nachzustellen:
get CUN version
CUN version => V 1.39 CUN
get CUN uptime
CUN uptime => 2 20:23:16
get CUN raw T02
CUN raw => N/A
set .*hzg date
Ab hier tot, keine Antwort mehr auf get-Kommandos.
Reset durch Stromentzug.
Neuer Versuch:
get CUN uptime
CUN uptime => 0 00:01:17
set .*hzg date
get CUN uptime
CUN uptime => 0 00:02:34 (Nanu, geht dieses mal?)
get CUN uptime
CUN uptime => 0 00:02:37
get CUN raw T02
CUN raw => 1453:600B,6105,6204 4007:600B,6105,6204 3745:600B,6105,6204
5F4A:600B,6105,6204 4362:600B,6105,6204 3225:600B,6105,6204
5415:600B,6105,6204 0B24:600B,6105,6204 4755:600B,6105,6204
set .*hzg time
get CUN uptime
CUN uptime => 0 00:03:14 (Hoppla, noch am Leben!)
get CUN uptime
CUN uptime => 0 00:03:40 (immer noch)
get CUN raw T02
CUN raw => No answer (peng, hier DISCONNECT)
get CUN uptime (hier wieder CONNECT)
CUN uptime => 0 00:04:07 (kein Neustart!)
Eine Weile später:
get CUN raw T02
CUN raw => 0B24:600B,6105,6204 4755:600B,6105,6204 4362:6312,640D
0B24:6312,640D 4755:6312,640D
get CUN uptime
CUN uptime => 0 00:10:53
Habe mir fht80b_print in fht.c angesehen, aber mir ist nichts
aufgefallen :-|
Viele Grüße,
Boris
Rudi, das Problem hat Ähnlichkeit mit meiner Beobachtung, daß ab einer
gewissen Anzahl von gleichzeitig abgesetzten time/date-Kommandos der CUN
abstürzt (CUN DISCONNECTED, Problem in culfw 1.39 und 1.40 nachweisbar).
Ja, schalte das weiterleiten der FHT-Protokollnachrichten ein mit
"set CUL raw X61" oder gar "set CUL raw X63", und versuche es nochmal.
Man sieht, dass:
- das FHT nicht immer auf die Afforderung (FHZ:can-xmit) reagiert.
- relativ schwerhoerig ist, da oefters wiederholt werden muss.
- es kann aber auch sein, dass das CUL die acks nicht hoert...
Wenn Du Lust und Energie hast, koenntest in culfw/clib/fht.c in fht80b_timer()
mit fht80b_timeout experimentieren, oder mit dem delay in fht80b_sendpacket
Noch 'ne Idee: Wie schaut es mit dem Protokoll von einem "set FHT refreshvalues" aus?
Jetzt wissen wir:
- CUL kann sich mit diesem FHT auch laenger unterhalten, und dabei mindestens
25 Telegramm-Paerchen ohne Unterbrechung austauschen.
- Prinzipiell kann CUL anderen FHT's bis zu 8 Befehle schicken, bei diesem ist
nach dem 5.-ten Schluss.
Theorien:
- Das CUL haelt sich nicht an irgendwelche Timing-Vorgaben, und dieses FHT
stoert sich daran.
- Dieses FHT hat keine Lust so viele Werte hintereinander zu merken
(meine lieblings Theorie).
Wenn ich das so genau wuesste, haette ich das schon eingestellt :|