FHEM und die FS20TFK Eintagsfliege...
Axel
Ich habe ein (möglicherweise triviales Verständnis-)Problem mit meinem
FHEM 4.8 System und einem FS20 TFK (Tür-Fenster-Kontakt). Sender/
Empfänger ist ein FHZ1000PC.
Wenn ich den TFK frisch meinem bestehendem System hinzufüge, klappt
alles wie erwartet, d.h. zunächst "meckert" FHEM im Logfile:
2010.08.29 09:43:33 3: FS20 Unknown device xxxx (HAUSCODE), Button 28
(1331) Cod
e 11 (on), please define it
Dann definiere ich brav "define tuer1 FS20 HAUSCODE 1331", der
Schönheit halber noch ein "attr tuer1 model fs20tfk" hinterher und
"safe" das Ganze.
Test, test, 1,2,3…:
2010.08.29 09:45:25 2: FS20 tuer1 off
2010.08.29 09:45:31 2: FS20 tuer1 on
2010.08.29 09:45:54 2: FS20 tuer1 off
2010.08.29 09:45:55 2: FS20 tuer1 on
2010.08.29 09:46:03 2: FS20 tuer1 off
2010.08.29 09:52:37 2: FS20 tuer1 on
Wunderbar, alles Bestens.
Nun ist der Tag vorbei, der Server fährt müde runter, FHEM hat alles
im Statefile.
Am nächsten morgen fährt der Server brav wieder hoch, bedient
erfolgreich div. FS20 Empfänger und ließt demnach auch das Statefile
ein.
Leider wird aber ab dann der TFK hartnäckig ignoriert. Nichts im
Logfile. "tuer1" bleibt auf "off" egal wie oft ich den reed-Kontakt
(oder die Tasten 1 & 2 im TFK Gehäuse) bediene.
Ein Löschen und Neuanlagen von "tuer1" in FHEM bringt leider auch nix.
Sollte der TFK seine Konfiguration über Nacht vergessen, müsste er
doch aber beim Auslösen im FHEM logfile als Unknown device erscheinen,
oder?
Wo ist mein Denk/Config-Fehler?
Freue mich auf jede Lösungsidee,
Viele Grüße, Axel
revolin
hast du vieleicht mehr als ein CUL/CUN an deinem FHEM angeschlossen?
Ich hatte auch schon 'mal das Problem, dass im fhem.cfg immer das
zuletzt definierte CUL als IODev verwendet wird, und das war bei mir
ein CUL433. Ich habe dann ueber 'attr TFK IODev myCUL' eine
explizite Zuordung gemacht und alles war OK.
Im statefile wird nur der letzte Zustand gespeichert, wenn ich dass
richtig
verstanden habe, und nicht die Definition der FS20-Geraete und deren
IODev Zuordnung, die immer ueber das fhem.cfg kommt. Ich denke
der Fehler koennte die Reihenfolge der Definitionen im fhem.cfg sein.
schoene Gruesse,
Gerald
Axel
On 1 Sep., 20:23, revolin <petri...@gmx.at> wrote:
> hast du vieleicht mehr als ein CUL/CUN an deinem FHEM angeschlossen?
Nicht the-latest-and-greatest aber es tut seinen Job - bis
Mitternacht ;-)
Eine Idee hätte ich noch:
Ich frage in FHEM den Zustand des TFK ab, und zwar so:
*23:00:00 { fhem("set roll2 off") if($value{tuer1} eq "off") }
Könnte das in irgendeiner Form 'tuer1' für alle Zeiten von einer
"variablen" in eine "static" wandeln?
Langsam wird man ja echt paranoid ;-)
Weiterhin vielen Dank für's mitknobeln,
Axel
Rudolf Koenig
Bevor das wirklich eintritt, koennte man auch einen aktuellen fhem oder
das hochdrehen des loglevels versuchen :)
Axel
Ok, schon das Hochdrehen des Loglevels brachte einiges an Erleuchtung:
2010.09.04 09:14:30 4: FHZ/RAW: 880101a00105af2000810b (Unparsed:
810b)
2010.09.04 09:14:30 4: Bad CRC message, skipping it (Bogus message
follows)
2010.09.04 09:14:30 5: Bogus message received, skipping to start
character
Das erklärt, warum der TFK (und mittlerweile ein hinzugekommener PIRI)
mit deren Signalen nicht durchkommen.
Ein Bißchen Googlen bringt dann auch die Beinahe-Lösung:
Ein 'strangetty' in der fhem.cfg an die define-zeile der FHZ1000
gehängt, rereadcfg und schon tut's...
...bis zum nächsten Kaltstart :-(
Hier bringt ein 'rereadcfg' auch schon Linderung. Das 2.
Initialisieren macht also kurzfristig wieder alles Gut.
Die config per 'stty' aus der FAQ (Punkt 17) bringt leider auch nichts
- es wird nur gemault, daß 'iutf8' nicht unterstützt sei.
Rudolf, bevor ich jetzt die große Back-Up Aktion mit Weihwasser und
Voodoo-zauber mache: Behandelt FHEM 4.9/5.0 irgendwie das Thema
"widerspenstige Serielle"?
Viele optimistische Grüße & Danke für die Tipps,
Axel
Rudolf Koenig
> Voodoo-zauber mache: Behandelt FHEM 4.9/5.0 irgendwie das Thema
> "widerspenstige Serielle"?
Nicht anders bzw. besser als 4.8. Laut cvs diff wurde einiges geaendert, ich
meine es waren hauptsaechlich "kosmetische" Aenderungen.
Axel
On 6 Sep., 10:16, Rudolf Koenig <inf...@koeniglich.de> wrote:
> Nicht anders bzw. besser als 4.8. Laut cvs diff wurde einiges geaendert, ich
> meine es waren hauptsaechlich "kosmetische" Aenderungen.
FHEM an einem Synology NAS betreiben und ähnliche Probleme mit FS20
Sendern haben solten:
Q: Mein FS20 Sender (z.B. FTK, PIRI, etc.) scheint nur direkt nach der
Anmeldung im FS20 System (Eingabe Hauscode etc.) zu funktionieren.
Nach einem Neustart kommen keine Meldungen mehr an.
A: Es kann sein, daß FHEM die serielle (USB-)Schnittstelle via
ftdi_sio.so Kernel-Modul nicht immer richtig initialisieren kann.
Folgende Schritte sind zum Eingrenzen des Problems nötig:
1) Loglevel auf 5 hochsetzen mit 'setdefaultattr loglevel 5' oder via
Webinterface
2) FS20 Sender auslösen
3) Finden sich im Logfile Zeilen wie diese:
"Bad CRC message, skipping it (Bogus message follows)" oder "Bogus
(Byte(s) werden beim Empfang verschluckt).
Lösung:
Ein re-initialisieren der Schnittstelle behebt das Problem bis zum
nächsten Reboot.
Fügen Sie also in ihr Startscript, z.B. in /usr/local/etc/rc.d nach
dem Start von FHEM den Befehl zum Neu-Einlesen der Config-Datei ein.
So könnte das dann aussehen:
# Starte FHEM
if test -r /pfad/zur/config/datei/fhem.cfg -a -x /pfad/zum/FHEM/code/
fhem.pl ; then
echo "Starte FHEM"
/opt/bin/perl /pfad/zum/FHEM/code/fhem.pl /pfad/zur/config/datei/
fhem.cfg
# Ein wenig Zeit zum Berappeln geben
sleep 2
# Re-Init durch neu-einlesen der Config-Datei
/pfad/zum/FHEM/code/fhem.pl 7072 rereadcfg
fi
Olaf Droegehorn
also, �hnliche Probleme hatte ich auf einer NAS Linkstation LS2 mit
ftdi_sio und einer FHZ1300.
Die L�sung war vor dem Start von FHEM folgendes Kommando um die
Parameter f�r ttyUBS0 richtig zu setzen:
stty -icrnl -ixon -opost -isig -icanon -iexten -echo < /dev/ttyUSB0
Danach hat es bei mir nie Aussetzer gegeben.
Das Kommando nutze ich heute noch, allerdings mit usbserial und CUL.
Gru�,
Olaf
Axel schrieb:
> Hallo Rudolf et al.
>
> On 6 Sep., 10:16, Rudolf Koenig <inf...@koeniglich.de> wrote:
>> Nicht anders bzw. besser als 4.8. Laut cvs diff wurde einiges geaendert, ich
>> meine es waren hauptsaechlich "kosmetische" Aenderungen.
>
> Ok, dann fasse ich mal FAQ-m��ig zusammen, f�r all diejenigen, die
> FHEM an einem Synology NAS betreiben und �hnliche Probleme mit FS20
> Sendern haben solten:
>
> Q: Mein FS20 Sender (z.B. FTK, PIRI, etc.) scheint nur direkt nach der
> Anmeldung im FS20 System (Eingabe Hauscode etc.) zu funktionieren.
> Nach einem Neustart kommen keine Meldungen mehr an.
>
> A: Es kann sein, da� FHEM die serielle (USB-)Schnittstelle via
> ftdi_sio.so Kernel-Modul nicht immer richtig initialisieren kann.
>
> Folgende Schritte sind zum Eingrenzen des Problems n�tig:
>
> 1) Loglevel auf 5 hochsetzen mit 'setdefaultattr loglevel 5' oder via
> Webinterface
> 2) FS20 Sender ausl�sen
> 3) Finden sich im Logfile Zeilen wie diese:
> "Bad CRC message, skipping it (Bogus message follows)" oder "Bogus
> message received, skipping to start character "
> gibt es Probleme mit der Initialisierung der USB-Schnittstelle
> (Byte(s) werden beim Empfang verschluckt).
>
> L�sung:
>
> Ein re-initialisieren der Schnittstelle behebt das Problem bis zum
> n�chsten Reboot.
> F�gen Sie also in ihr Startscript, z.B. in /usr/local/etc/rc.d nach
> dem Start von FHEM den Befehl zum Neu-Einlesen der Config-Datei ein.
> So k�nnte das dann aussehen:
>
> # Starte FHEM
> if test -r /pfad/zur/config/datei/fhem.cfg -a -x /pfad/zum/FHEM/code/
> fhem.pl ; then
> echo "Starte FHEM"
> /opt/bin/perl /pfad/zum/FHEM/code/fhem.pl /pfad/zur/config/datei/
> fhem.cfg
>
> # Ein wenig Zeit zum Berappeln geben
> sleep 2
>
> # Re-Init durch neu-einlesen der Config-Datei
> /pfad/zum/FHEM/code/fhem.pl 7072 rereadcfg
>
> fi
>
--
------------------------------------------------------------------------
Dr. Olaf Droegehorn
General Manager Tel. : +49-561-82020-410
DHS - Computertechnik GmbH Fax. : +49-561-82020-399
Carlsdorfer Stra�e 3 E-Mail: O.Droe...@dhs-computertechnik.de
WEB: www.dhs-computertechnik.de
D-34128 Kassel
------------------------------------------------------------------------