unknown_69 und kein Ende

[Guest]

Originally posted by: <email address deleted>

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

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

[rudolfkoenig]

                                                   

> 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.

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

[Guest]

Originally posted by: <email address deleted>

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

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

[Guest]

Originally posted by: <email address deleted>

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.

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

[LuckyDay]

                                         

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" weingarten.de> wrote:
> 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.

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

[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)






On 14 Dez., 00:10, fhem-hm-knecht wrote:
> 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" >
>
>
>
>
>
>
> weingarten.de> wrote:
> > 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.

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

[Guest]

Originally posted by: <email address deleted>

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

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

[Guest]

Originally posted by: <email address deleted>

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.



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

[Guest]

Originally posted by: <email address deleted>

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

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

[Guest]

Originally posted by: <email address deleted>

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


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

[Guest]

Originally posted by: <email address deleted>

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

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

[rudolfkoenig]

                                                   

> 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
Siehe auch http://culfw.de/commandref.html#cmd_T

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

[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.

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

[Guest]

Originally posted by: <email address deleted>

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
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

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