unknown_69 und kein Ende

[Prof. Dr. Peter A. Henning]

Liebe Gruppe,

ich habe vor einigen Tagen den Wechsel auf eine Fritzbox 7390 vollzogen und darauf FHEM 5.1 im Einsatz. Nachdem FHEM seit April problemlos auf der FB 7270 gelaufen ist, habe ich natürlich meine Konfigurationsdatei einfach übernommen. Passt, alle FS20-Geräte werden wie gewohnt bedient. Auch mein spezielles Modul zur Abfrage meines solaren Wechselrichters läuft problemlos. Jetzt das ABER:

Nicht seit dem Wechsel, sondern ein paar Tage danach (und inzwischen bei allen FHT80-Reglern im Haus) tritt das wohlbekannte "actuator unknown_69: 69%"-Problem auf: Temperaturen werden nicht mehr gelesen und geloggt, sondern stattdessen gibt es diese Meldung im FileLog.

Die Suche danach in dieser Gruppe, im FHEM-Wiki und an allen möglichen Orten brachte dann eine Vielzahl von teilweise widersprüchlichen Lösungen zu Tage.

- Es läge daran, dass die FHTs nicht mit dem CUL gepaart seien => Selbstverständlich habe ich das sofort gemacht - ohne Erfolg
- Es läge an den Batterien der Stellantriebe => Nein, kann es auch nicht sein
- Es läge daran, dass der CUL nicht mehr richtig mit den FHTs kommunizieren kann, weil er im Echo-Mode sei => Nein, kann m.E. auch nicht ganz stimmen, das funktioniert auch nach einem harten Reset des CUL nicht richtig

Für einen Tipp, wo man die _richtige_ Lösung findet (bzw. was die Ursache wirklich ist ...) wäre ich dankbar.

LG

Peter Henning

[Rudolf Koenig]

> F�r einen Tipp, wo man die _richtige_ L�sung findet (bzw. was die Ursache
> wirklich ist ...) w�re ich dankbar.

Dafuer waere ich auch dankbar :)

Sonst:

- bis ein Gegenbeweis eintrifft wuerde ich "actuator unknown_69" nicht mit dem
Problem der schweigsamen FHT's gleichsetzen. Es waere eh gut zu wissen, was
dieser Code 69 (bzw. .9) bedeutet, von dem moeglichen 16 sind fhem 9 bekannt.
Siehe 11_FHT.pm, Abschnitt nach "m/^actuator/"

- Bei einem schweigsamen FHT80b wuerde ich auf dem CUL mit X67 das Melden der
FHT Protokoll-Telegramme einschalten, und mit "inform timer" in einem telnet
die FHT- bzw. CUL-Telegramme anschauen. Wie es auszusehen hat, steht im
fhemwiki.

[Prof. Dr. Peter A. Henning]

Hm, ich bin ein Anhänger von Occam's Razor: Simplicity first.

Und da beide Probleme wirklich simultan aufgetreten sind, nehme ich einen solchen Zusammenhang zunächst einmal an.

Gruß

pah

[Prof. Dr. Peter A. Henning]

Es wird immer wirrer.

1. Zustand bis heute 17:00: FHEM 5.1 vom FB7390-image. Probleme mit allen FHTs, die weder durch Bandbreitenerweiterung, noch durch neues Paaren gelöst werden.

2. Dann mal spaßeshalber in der Web-Oberfläche das Kommando updatefhem ausgeführt. Dieses installiert einige neue Files und bricht dann ab mit der Fehlermeldung:

File size for HOWTO.html does not correspond to filetimes.txt entry

FHEM läuft dann immer noch, aber 01_FHEMWweb.pm wird deaktiviert - offenbar hat das "halbe Update" einen 
inkonsistenten Zustand erzeugt. Als habe ich mich per telnet auf die FB eingeloggt. Und, oh Mirakel: 
die FHTs waren zu sehen, ließen sich stellen und brachten schön brav ihren Report. Vor allem war das dumme
"acuator unknown_69" nicht mehr da !

3.Wer will schon einen inkosistenten Systemzustand ? Also wieder die Version 5.1 eingespielt. Gleiche Konfigurationsdatei 
- und plötzlich wieder: Keine Reaktion der FHTs, dafür aber massenhaft unknown_69...

Fazit also derzeit: In der Version 5.1 steckt irgendetwa, das diese Kommunikation stört. 

[fhem-hm-knecht]

ich hab ja auch die7390 und updatefhem hat immer tadellos
funktioniert.

unter dem link ist das aktuelle cvs

http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz

und dann per ftp von hand updaten

gruß

On 13 Dez., 20:54, "Prof. Dr. Peter A. Henning" <pe...@henning-

[Zrrronggg!]

Ich habe auch eine unknown_69, und zwar von einem Aktuator den es
nicht gibt.

An einem FHT80b ist nur eine Ventilsteller gepairt, er meldet aber die
Daten von ZWEIEN, einer normal also tatsächlich Werte, der andere
unknown_69.

Ich habe mich noch nicht damit befasst, viel mir nur vor paar Tagen
auf. (mit FHEM 4.9 übrigens)

[Prof. Dr. Peter A. Henning]

@fhem-hm-knecht: Leider Thema verfehlt, hier geht es nicht um das Systemupdate und die eventuellen Fehler darin.

[Prof. Dr. Peter A. Henning]

Aha, endlich mal ein reproduzierbares Resultat in dieser Sache.

Ausgangssituation: Mehrere FHTs an einem fhem 5.1 auf einer Fritzbox. Teilweise "nur" stumm, also lediglich mit "actuator x%" Meldungen, teilweise zusätzlich etwa jede zweite Meldung "actuator unknown_69 y%. Und zwar erst seit wenigen Tagen (Umstellung auf 5.1, vorher war eine CVS-Version vom Juni 2011 im Einsatz, bei der alles Bestens lief).

Vorgehensweise: 1. In der fhem.cfg den define-Eintrag für diesen FHT auskommentieren (autocreate ist "on"), sichern.
                          2. Am FHT im Menü PROG/CENT auf "nA" stellen, sodass eine neue Paarung eingeleitet wird.
                          3. In der nach dem erfolgten autocreate entstehenden Log-Datei nachsehen, warten, bis der angeblich neu entdeckte FHT das erste Mal seinen Status sendet.
                          4. Wieder die fhem.cfg editieren, darin den "neu entdeckten" FHT löschen und die oben erfolgte Auskommentierung wieder rückgängig machen.

Ergebnis: Der so neu entdeckte FHT sendet wieder seine Daten (ist also nicht mehr "stumm") und es kommen auch keine "unknown_69" mehr.

Varianten: Schritt 1 alleine reicht nicht aus.

Ausblick: Abzuwarten bleibt, ob dies so stabil ist. Nach den Postings hier in der Gruppe kann es sein, dass nach 2-3 Tagen alles wieder auf "stumm" und "unknown_69" steht.

Hypothese: Ein solches Verhalten erscheint denkbar, wenn der FHT nach dem Senden seiner Daten auf eine Bestätigung wartet, diese aber nicht bekommt. Nach einiger Zeit geht er in den "stummen" Zustand über - und wenn dieser eine Zeitlang angehalten hat, geht er in einen weiteren Zustand über, bei dem regelmäßig ein "unknown_69" geschickt wird.

[UliM]

Hi,
nun hat's mich auch erwischt...
Gibt's hierzu neue Erkenntnisse? 
Die "Peter-Methode" hat bei mir leider nicht zum gewünschten Erfolg geführt, auch nicht 8 Stunden stromlos machen oder neue Batterien einsetzen.

Ich betreibe meinen FHT an einem CUL ohne FHT8v. Wäre doch interessant mal zu testen, was passiert, wenn man diesen streikenden FHT nun an eine FHZ pairt:
- erledigt sich das Problem dann?
- welche Kommunikation findet zwischen den Geräten statt (verbose 5 oder was muss man da tun?), v.a. was sendet FHZ an FHT?
Wenn es irgendjemand in München gibt, der fhem mit einer FHZ betreibt, könnte ich mit meinem FHT mal vorbeikommen, um das auszutesten. Oder bin ich auf dem Holzweg?

Gruß, Uli

[Prof. Dr. Peter A. Henning]

Ich habe das anscheinend beseitigt - aber nicht im Griff, denn verstanden habe ich es bisher nicht.

Jeden morgen um 4:00 wird folgendes Skript mit einem "at *04:00:00 trigger r_FHT" ausgelöst:

r_FHT { 
  my @@fhts=devspec2array("TYPE=FHT"); 
  foreach(@@fhts) { 
    my $state=ReadingsVal($_, "mode", "nA"); 
    if ( $state eq "nA" ) { fhem "set $_ report2 7"; } 
  } 
}

Bei den vermeintlich "toten" FHT's einfach ein paar Tage Geduld - dann gibt sich das von alleine. Das deutet m.E. darauf hin, dass 
irgendwelche Puffer zu voll sind und erst im Verlauf von Tagen geleert werden.

Derzeit habe ich nur noch mit einem FHT Probleme - und das, weil er zu dicht am Repeater-CUL steht

LG

pah

[UliM]

Hi,
bei meinem FHT isses mal wieder so weit - unknown_69 und kein Ende (ich hatte den täglichen refresh mit report2 7 nicht drin - sollte ich den FHT jemals wieder zur Zusammenarbeit bewegen können, richte ich das auf jeden Fall ein).
Diesmal hat sich das Gerät widerspenstig. Das o.g. Rezept von pah hab ich schon mehrfach angewandt. Im März hat's noch geholfen - diesmal nix zu machen - seit mehreren Tagen keine Meldungen mehr außer unknown_69, manchmal nur actuator: 0%, meist beide Meldungen hintereinander (erst actuator: 0%, immer eine Sekunde später actuator: unknown_69: 67%)
Verbose 5 zeigt mir außerdem, dass CUL auf jeden Sendeversuch an den FHT ein EOB zurückgibt:

2012.05.08 12:13:46 5: Cmd: >set FHT_5151 report2 7<
2012.05.08 12:13:46 5: CUL sending T51516607
2012.05.08 12:13:46 5: SW: T51516607
2012.05.08 12:13:46 2: FHT set FHT_5151 report2 7
2012.05.08 12:13:46 5: Triggering FHT_5151 (1 changes)
2012.05.08 12:13:46 5: FHT_5151 trigger: Checking ..... (checkt alle notifies)
2012.05.08 12:13:46 5: CUL/RAW: /EOB
2012.05.08 12:13:46 5: CUL: EOB
2012.05.08 12:13:46 2: CUL: unknown message EOB

Habe hier im Forum gesucht und gefunden, dass EOB für eine vollen FHT-Schreibpuffer steht.
Wie kann ich diesen zurücksetzen/löschen, um wieder versuchen zu können, etwas an den FHT zu senden?

Genervte Grüße,
Uli

[Rudolf Koenig]

> Wie kann ich diesen zur�cksetzen/l�schen, um wieder versuchen zu k�nnen,

> etwas an den FHT zu senden?

CUL raus und wieder reinstecken.

Oder aus fhem:
set CUL raw T01<CUL_FHTCODE>
Siehe auch http://culfw.de/commandref.html#cmd_T

[Zrrronggg!]

> Habe hier im Forum gesucht und gefunden, dass EOB für eine vollen
> FHT-Schreibpuffer steht.

Dabei haben wir so eine schönes Wiki. Im Artikel über das FHT80b steht
drin was EOB ist.

Mittlerweile hat das Wiki doch wirklich brauchbare Ausmasse angenommen
finde ich.

Ich schreibe aber gleich noch einen Artikel "EOB" und mögliche
Gegenmassnahmen zusammen.

[UliM]

Hi,

> Dabei haben wir so eine schönes Wiki.

Stimmt. Da hab ich dieser Tage erst einen Hinweis auf unknown_69 mit Link auf diesen fred eingebaut :)

Interessant: Nachdem ich eben ein

set CUL raw T01<CUL_FHTCODE>

abgesetzt habe, gefolgt von

set FHT_5151 desired-temp 23.0

funktioniert das FHT jetzt wieder wie neu *jubel*
Eben kam der erste reguläre FHT-Statusbericht seit ner knappen Woche :)
Nun kann ich endlich Schritt 4 aus pah's Rezept ausführen und das tägliche report2 7 -refresh einbauen.
Heute ist ein schöner Tag :)
Gruß + danke für die Unterstützung,
Uli