Originally posted by: <email address deleted>
Hallo,
ich habe bei mir fhem auf einer Fritzbox 7390 mit einem EnOcean TCM310 USB
Stick von Busware laufen
fhem.cfg: define TCM310 TCM 310 /dev/ttyACM0@57600
Primär betreibe ich Rolladen-Aktoren von Eltako und einigen Schaltern.
Grundsätzlich funktioniert das ganze. Wenn ich versuche mehrere Kommandos
(set ...) im kürzeren zeitlichen Abstand zu senden werden diese machmal
nicht ausgeführt. Betätige ich irgendeinen anderen Enocean Schalter
(teilweise mehrfach) dann werden irgendwann diese Kommandos nachgeholt. Es
sieht so aus als ob hier irgendein Puffer befüllt wird. Ich kann leider
nicht sagen ob dieser innerhalb von fhem liegt oder eher Richtung TCM310 zu
suchen ist.
Hat jemand eine Idee wie man dem Problem auf die Schliche kommen kann? Ich
habe versucht mit inform on/raw mitzulesen, konnte aber noch nicht im
Detail nachvollziehen ob das Problem auf der Sende- oder Empfangsseite
besteht.
Grüße
Thomas
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Wenn ich versuche mehrere Kommandos (set ...) im kürzeren zeitlichen Abstand
> zu senden werden diese machmal nicht ausgeführt.
Vor ein paar Tagen wurde deswegen ein Patch eingespielt. Treten diese Probleme
auch nach einem update auf?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Rudolf,
ich habe den 10_EnOcean patch mit 0,2sec Verzögerung getestet.
Es werden 11 Aktoren ohne Probleme geschaltet.
Hilft vielleicht bei der Fehlereingrenzung.
On Wednesday, August 1, 2012 8:52:17 AM UTC+2, Rudolf Koenig wrote:
>
> > Wenn ich versuche mehrere Kommandos (set ...) im k�rzeren zeitlichen
> Abstand
> > zu senden werden diese machmal nicht ausgef�hrt.
>
> Vor ein paar Tagen wurde deswegen ein Patch eingespielt. Treten diese
> Probleme
> auch nach einem update auf?
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Was passiert denn wenn Du die "se"t Kommandos mit structure gruppierst und
dann ausführst?
Hat das die gleichen Fehler zu Folge?
Joerg
On Tuesday, July 31, 2012 10:44:35 PM UTC+2, Thomas Otto wrote:
>
> Hallo,
>
> ich habe bei mir fhem auf einer Fritzbox 7390 mit einem EnOcean TCM310 USB
> Stick von Busware laufen
> fhem.cfg: define TCM310 TCM 310 /dev/ttyACM0@57600
>
> Primär betreibe ich Rolladen-Aktoren von Eltako und einigen Schaltern.
>
> Grundsätzlich funktioniert das ganze. Wenn ich versuche mehrere Kommandos
> (set ...) im kürzeren zeitlichen Abstand zu senden werden diese machmal
> nicht ausgeführt. Betätige ich irgendeinen anderen Enocean Schalter
> (teilweise mehrfach) dann werden irgendwann diese Kommandos nachgeholt. Es
> sieht so aus als ob hier irgendein Puffer befüllt wird. Ich kann leider
> nicht sagen ob dieser innerhalb von fhem liegt oder eher Richtung TCM310 zu
> suchen ist.
>
> Hat jemand eine Idee wie man dem Problem auf die Schliche kommen kann? Ich
> habe versucht mit inform on/raw mitzulesen, konnte aber noch nicht im
> Detail nachvollziehen ob das Problem auf der Sende- oder Empfangsseite
> besteht.
>
> Grüße
> Thomas
>
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Rudolf,
das mit dem Patch habe ich gelesen, haben den Wert testweise auf 0.3
gesetzt. Das Problem ist allerdings dass die Kommandos nicht weg sind (wie
im dortigen Fall beschrieben), sondern dass sie zu einem späteren Zeitpunkt
ausgeführt werden (ausgelöst durch was auch immer).
Am Mittwoch, 1. August 2012 08:52:17 UTC+2 schrieb Rudolf Koenig:
>
> > Wenn ich versuche mehrere Kommandos (set ...) im k�rzeren zeitlichen
> Abstand
> > zu senden werden diese machmal nicht ausgef�hrt.
>
> Vor ein paar Tagen wurde deswegen ein Patch eingespielt. Treten diese
> Probleme
> auch nach einem update auf?
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Joerg,
mit structure habe ich gestartet. Weil das nicht sauber ging habe ich die
Kommandos einzeln mit einem sleep 1 dazwischen ausgeführt. Damit wurde es
besser. Das ganze passiert aber auch wenn ich nur einen Schalter benutzt.
Kleines Beispiel:
1.
Ich betätigen einen Zentraltaster der über notify folgendes ausführen soll:
define Beschattung_Sued_SW notify Rollo_zentral:A0 trigger Beschattung_Sued
define Beschattung_Sued notify Beschattung_Sued set Rollo_Ku_S BI;;sleep
13;;set Rollo_Ku_S BI
2.
inform on meldet:
EnOcean Rollo_Ku_SW buttons: released (dieser Schalter wurde 5min vorher
bedient)
EnOcean Rollo_WZ_1_stat unten (Status vom Rolladenaktor, ebenfalls 5 min
vorher)
3. ich betätigen einen Schalter den fhem kennt aber nicht benutzt
inform on meldet:
EnOcean Rollo_WZ_2_stat unten
EnOcean Rollo_Ku_W_stat unten
EnOcean Rollo_Ku_S_stat unten
4. nach 20sec meldet inform on (hier hat meine Frau glaube ich gerade ein
anderes nicht benutztes Funktelegram erzeugt)
EnOcean Rollo_Bad_El_stat unten
EnOcean Rollo_Ku_S on
notify Beschattung_Sued
*EnOcean Rollo_zentral A0
EnOcean Rollo_zentral buttons: released* Das ist die Betätigung die unter
1. stattgefunden hat, also kein direkter Zusammenhang!
EnOcean Rollo_Ku_S on
EnOcean Rollo_Ku_SW AI
EnOcean Rollo_Ku_S_stat buttons: released
Vielleicht hilft das Beispiel mein Problem zu verstehen...
Grüße
Thomas
Am Mittwoch, 1. August 2012 11:14:02 UTC+2 schrieb joerg:
>
> Was passiert denn wenn Du die "se"t Kommandos mit structure gruppierst und
> dann ausführst?
>
> Hat das die gleichen Fehler zu Folge?
>
> Joerg
>
>
> On Tuesday, July 31, 2012 10:44:35 PM UTC+2, Thomas Otto wrote:
>>
>> Hallo,
>>
>> ich habe bei mir fhem auf einer Fritzbox 7390 mit einem EnOcean TCM310
>> USB Stick von Busware laufen
>> fhem.cfg: define TCM310 TCM 310 /dev/ttyACM0@57600
>>
>> Primär betreibe ich Rolladen-Aktoren von Eltako und einigen Schaltern.
>>
>> Grundsätzlich funktioniert das ganze. Wenn ich versuche mehrere Kommandos
>> (set ...) im kürzeren zeitlichen Abstand zu senden werden diese machmal
>> nicht ausgeführt. Betätige ich irgendeinen anderen Enocean Schalter
>> (teilweise mehrfach) dann werden irgendwann diese Kommandos nachgeholt. Es
>> sieht so aus als ob hier irgendein Puffer befüllt wird. Ich kann leider
>> nicht sagen ob dieser innerhalb von fhem liegt oder eher Richtung TCM310 zu
>> suchen ist.
>>
>> Hat jemand eine Idee wie man dem Problem auf die Schliche kommen kann?
>> Ich habe versucht mit inform on/raw mitzulesen, konnte aber noch nicht im
>> Detail nachvollziehen ob das Problem auf der Sende- oder Empfangsseite
>> besteht.
>>
>> Grüße
>> Thomas
>>
>>
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi,
Nochmal ein paar Fragen...
Was steht denn im log?
Jeder Schalter / Aktor für sich funktioniert einwandfrei?
Was genau hat denn bei structure nicht funktioniert?
" mit structure habe ich gestartet. Weil das nicht sauber ging ...." war
die Funktionalität nicht für Deinen Zweck zu nutzen oder waren es
technische Hürden?
Wie sieht die Hardware und Umgebung. Also: Lebt Ihr in einem
Stahbetonbunker mit viel Funkverkehr oder in einem Fachwerkhaus in der
Abgeschiedenheit der Natur? (Stichwort Abschattung, Störungen)
Gruß
joerg
On Wednesday, August 1, 2012 10:37:42 PM UTC+2, Thomas Otto wrote:
>
> Hallo Joerg,
>
> mit structure habe ich gestartet. Weil das nicht sauber ging habe ich die
> Kommandos einzeln mit einem sleep 1 dazwischen ausgeführt. Damit wurde es
> besser. Das ganze passiert aber auch wenn ich nur einen Schalter benutzt.
> Kleines Beispiel:
> 1.
> Ich betätigen einen Zentraltaster der über notify folgendes ausführen soll:
> define Beschattung_Sued_SW notify Rollo_zentral:A0 trigger Beschattung_Sued
> define Beschattung_Sued notify Beschattung_Sued set Rollo_Ku_S BI;;sleep
> 13;;set Rollo_Ku_S BI
> 2.
> inform on meldet:
> EnOcean Rollo_Ku_SW buttons: released (dieser Schalter wurde 5min vorher
> bedient)
> EnOcean Rollo_WZ_1_stat unten (Status vom Rolladenaktor, ebenfalls 5 min
> vorher)
>
> 3. ich betätigen einen Schalter den fhem kennt aber nicht benutzt
> inform on meldet:
> EnOcean Rollo_WZ_2_stat unten
> EnOcean Rollo_Ku_W_stat unten
> EnOcean Rollo_Ku_S_stat unten
>
> 4. nach 20sec meldet inform on (hier hat meine Frau glaube ich gerade ein
> anderes nicht benutztes Funktelegram erzeugt)
> EnOcean Rollo_Bad_El_stat unten
> EnOcean Rollo_Ku_S on
> notify Beschattung_Sued
> *EnOcean Rollo_zentral A0
> EnOcean Rollo_zentral buttons: released* Das ist die Betätigung die unter
> 1. stattgefunden hat, also kein direkter Zusammenhang!
> EnOcean Rollo_Ku_S on
> EnOcean Rollo_Ku_SW AI
> EnOcean Rollo_Ku_S_stat buttons: released
>
> Vielleicht hilft das Beispiel mein Problem zu verstehen...
> Grüße
> Thomas
>
>
> Am Mittwoch, 1. August 2012 11:14:02 UTC+2 schrieb joerg:
>>
>> Was passiert denn wenn Du die "se"t Kommandos mit structure gruppierst
>> und dann ausführst?
>>
>> Hat das die gleichen Fehler zu Folge?
>>
>> Joerg
>>
>>
>> On Tuesday, July 31, 2012 10:44:35 PM UTC+2, Thomas Otto wrote:
>>>
>>> Hallo,
>>>
>>> ich habe bei mir fhem auf einer Fritzbox 7390 mit einem EnOcean TCM310
>>> USB Stick von Busware laufen
>>> fhem.cfg: define TCM310 TCM 310 /dev/ttyACM0@57600
>>>
>>> Primär betreibe ich Rolladen-Aktoren von Eltako und einigen Schaltern.
>>>
>>> Grundsätzlich funktioniert das ganze. Wenn ich versuche mehrere
>>> Kommandos (set ...) im kürzeren zeitlichen Abstand zu senden werden diese
>>> machmal nicht ausgeführt. Betätige ich irgendeinen anderen Enocean Schalter
>>> (teilweise mehrfach) dann werden irgendwann diese Kommandos nachgeholt. Es
>>> sieht so aus als ob hier irgendein Puffer befüllt wird. Ich kann leider
>>> nicht sagen ob dieser innerhalb von fhem liegt oder eher Richtung TCM310 zu
>>> suchen ist.
>>>
>>> Hat jemand eine Idee wie man dem Problem auf die Schliche kommen kann?
>>> Ich habe versucht mit inform on/raw mitzulesen, konnte aber noch nicht im
>>> Detail nachvollziehen ob das Problem auf der Sende- oder Empfangsseite
>>> besteht.
>>>
>>> Grüße
>>> Thomas
>>>
>>>
>>>
>>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hab versucht es nachzustellen, ohne Erfolg.
Setup:
- fb7390, EUL, fhem (aktuell)
- fhem.cfg:
define TCM310_0 TCM 310 /dev/ttyACM0@57600
define remote EnOcean 0015BA05
attr remote subType switch
define switch EnOcean FF876580
define n notify remote:A0 set switch AI;; sleep 13;; set switch A0
- switch ist mit dem CUL, AI/A0 gepaart.
- Telnet, inform timer, nachdem ich auf der Fernbedienung A0 gedrueckt habe:
2012-08-02 11:45:38.832 EnOcean switch AI
2012-08-02 11:45:38.836 EnOcean remote A0
2012-08-02 11:45:38.868 EnOcean remote buttons: released
2012-08-02 11:45:52.064 EnOcean switch A0
Rolladenschalter habe ich nicht, kann also auch nicht testen, sollte aber
diesbezueglich keinen Unterschied machen.
Etwas merkwuerdig, dass fhem erst das notify (samt schalten) ausfuehrt, und
dann erst das Event der Fernbedienung meldet, das ist aber kein Bug :)
An alle Bug-/Problem-melder:
Man kriegt am ehesten Hilfe, wenn man dem Support es leicht macht, das Problem
nachzustellen. In unserem Fall heisst das, dass man ein fhem.cfg bastelt, was
einerseits keine ueberfluessigen Zeilen enthaelt, andererseits das Problem
reproduziert, und moeglichst keine "ausgefallenen" Geraete verwendet. Sonst
muss derjenige, der helfen will raten, und es wird unnoetig Zeit vergeudet.
Klar ist das "abspecken" Arbeit, aber im Zweifel muss das vom Support auch
durchgefuehrt werden, und das ist einerseits nicht fair, andererseits bleibt
das Problem einfach liegen. Und viele Probleme findet man durch das Abspecken
einfach selber.
Gruss,
Rudi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Danke für den Ratschlag. Hab meine fhem.cfg abgespeckt (siehe Anhang).
Hab das ganze mit shutdown restart neu gestartet.
inform timer:
2012-08-02 22:50:59 EnOcean Rollo_Ku_S BI
2012-08-02 22:50:59 EnOcean Rollo_zentral A0
2012-08-02 22:50:59 EnOcean Rollo_Ku_S BI
2012-08-02 22:51:12 EnOcean Rollo_Ku_S BI
2012-08-02 22:51:12 EnOcean Rollo_zentral buttons: released
2012-08-02 22:51:12 EnOcean Rollo_Ku_S_stat buttons: released
Was micht stark wundert ist dass ich den Rollo_zentral Taster nur kurz
betätige, aber das Telegram buttons: released erst 13sek später gemeldet
wird. Da der Schalter batterielos ist kann das nicht sein. buttons:
released kommt sofort beim loslassen.
Hinweis: eine "Eigenheit" der Rollo-Schalter in der neuesten Version ist
das sie ihren Status mitteilen ca. 500ms nach Betätigung (siehe _stat). Das
sollte aber keinen negativen Einfluss haben.
Ich glaube das mit der config nachzustellen ist schwer. Vielleicht gibt es
noch einen Tipp wo ich beim Debugen hinschauen kann um das Problem
einzugrenzen.
Danke
Grüße
Thomas
Am Donnerstag, 2. August 2012 12:02:51 UTC+2 schrieb Rudolf Koenig:
>
> Hab versucht es nachzustellen, ohne Erfolg.
>
> Setup:
>
> - fb7390, EUL, fhem (aktuell)
>
> - fhem.cfg:
> define TCM310_0 TCM 310 /dev/ttyACM0@57600
> define remote EnOcean 0015BA05
> attr remote subType switch
> define switch EnOcean FF876580
> define n notify remote:A0 set switch AI;; sleep 13;; set switch A0
>
> - switch ist mit dem CUL, AI/A0 gepaart.
>
> - Telnet, inform timer, nachdem ich auf der Fernbedienung A0 gedrueckt
> habe:
> 2012-08-02 11:45:38.832 EnOcean switch AI
> 2012-08-02 11:45:38.836 EnOcean remote A0
> 2012-08-02 11:45:38.868 EnOcean remote buttons: released
> 2012-08-02 11:45:52.064 EnOcean switch A0
>
> Rolladenschalter habe ich nicht, kann also auch nicht testen, sollte aber
> diesbezueglich keinen Unterschied machen.
>
> Etwas merkwuerdig, dass fhem erst das notify (samt schalten) ausfuehrt,
> und
> dann erst das Event der Fernbedienung meldet, das ist aber kein Bug :)
>
>
> An alle Bug-/Problem-melder:
>
> Man kriegt am ehesten Hilfe, wenn man dem Support es leicht macht, das
> Problem
> nachzustellen. In unserem Fall heisst das, dass man ein fhem.cfg bastelt,
> was
> einerseits keine ueberfluessigen Zeilen enthaelt, andererseits das Problem
> reproduziert, und moeglichst keine "ausgefallenen" Geraete verwendet.
> Sonst
> muss derjenige, der helfen will raten, und es wird unnoetig Zeit
> vergeudet.
>
> Klar ist das "abspecken" Arbeit, aber im Zweifel muss das vom Support auch
> durchgefuehrt werden, und das ist einerseits nicht fair, andererseits
> bleibt
> das Problem einfach liegen. Und viele Probleme findet man durch das
> Abspecken
> einfach selber.
>
> Gruss,
> Rudi
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Ich glaube das mit der config nachzustellen ist schwer.
Stimmt, es ist entweder eine Besonderheit der Rolladensteuerung, oder Dein EUL
ist komisch. Oder was anderes :)
> Vielleicht gibt es noch einen Tipp wo ich beim Debugen hinschauen kann um das
> Problem einzugrenzen.
- wie schaut das fhem-log aus mit "attr TCM310 loglevel 2" ?
- kommt release sofort, wenn man Beschattung_Sued deaktiviert (disable)?
- wie schaut ein Mitschnitt aus, wenn man Rollo_Ku_SW drueckt?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
hab mal loglevel auf 2 gesetzt und versucht den Fehler wieder herzubekommen:
inform timer zeigt:
2012-08-03 13:34:48 EnOcean Rollo_Ku_SW AI
2012-08-03 13:34:49 EnOcean Rollo_Ku_SW buttons: released (hier i.O.)
2012-08-03 13:34:51 EnOcean Rollo_Ku_SW AI
2012-08-03 13:34:51 EnOcean Rollo_Ku_SW buttons: released (hier i.O.)
2012-08-03 13:35:12 EnOcean Rollo_Ku_SW AI
2012-08-03 13:35:12 EnOcean Rollo_Ku_SW buttons: released (hier i.O.)
2012-08-03 13:35:13 EnOcean Rollo_Ku_SW AI
2012-08-03 13:35:13 EnOcean Rollo_Ku_SW buttons: released (hier i.O.)
2012-08-03 13:37:22 EnOcean Rollo_Ku_S BI
2012-08-03 13:37:22 EnOcean Rollo_zentral A0 hier geht es mit dem Fehler
los, buttons:released kommt über 2 min später
2012-08-03 13:37:35 EnOcean Rollo_Ku_S BI
2012-08-03 13:37:35 EnOcean Rollo_Ku_S BI
2012-08-03 13:39:31 EnOcean Rollo_zentral buttons: released
2012-08-03 13:39:31 EnOcean Rollo_Ku_S BI
2012-08-03 13:39:58 EnOcean Rollo_Ku_S BI
2012-08-03 13:39:58 EnOcean Rollo_zentral A0
2012-08-03 13:39:58 EnOcean Rollo_zentral buttons: released
Das passende Logfile habe ich angehängt. Ich denke der Fehler startet:
2012.08.03 13:37:22 2: TCM310/RAW:
550001000265000055000707017AF650FFF6C9863101FFFFFFFF55007555000707017AF6000025149D2001FFFFFFFF520046
Hier sind in einem RAW-String zwei Kommandos.
Kommt das so direkt vom EUL oder soll das im fhem auseinandergeschnitten
werden?
Ich habe vom EUL übrigens die aktuelle Firmware vom 17.04.2012 laufen (r70).
- kommt release sofort, wenn man Beschattung_Sued deaktiviert (disable)?
>
ist im Logfile ab 2012.08.03 13:57:20 zu sehen. Hier sehen die Raw-Daten
besser aus und der Effekt bleibt aus.
Vielleicht hilft das weiter.
Danke
Grüße
Thomas
Am Freitag, 3. August 2012 08:08:29 UTC+2 schrieb Rudolf Koenig:
>
> > Ich glaube das mit der config nachzustellen ist schwer.
>
> Stimmt, es ist entweder eine Besonderheit der Rolladensteuerung, oder Dein
> EUL
> ist komisch. Oder was anderes :)
>
>
> > Vielleicht gibt es noch einen Tipp wo ich beim Debugen hinschauen kann
> um das
> > Problem einzugrenzen.
>
> - wie schaut das fhem-log aus mit "attr TCM310 loglevel 2" ?
> - kommt release sofort, wenn man Beschattung_Sued deaktiviert (disable)?
> - wie schaut ein Mitschnitt aus, wenn man Rollo_Ku_SW drueckt?
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Thomas,
> Ich denke der Fehler startet:
...
Korrekt, Anfaengerfehler. Falls der Stick die Daten schneller liefert, als fhem
sie verarbeiten kann, dann kommt genau das zustande.
Habs fuer TCM310 und TCM120 gefixed, kurz getestet und eingecheckt. Ist per
updatefhem verfuegbar. Kannst Du es bitte testen? Das eigentliche Problem
konnte ich ja bisher nicht reproduzieren.
Gruss,
Rudi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Rudi,
sieht sehr gut aus. Mein unsprüngliches Problem scheint damit im Kurztest
auch weg zu sein. Werde mal übers Wochenende weiter testen und melde mich
nochmal.
Vielen Dank!
Grüße
Thomas
Am Samstag, 4. August 2012 10:17:30 UTC+2 schrieb Rudolf Koenig:
>
> Hallo Thomas,
>
> > Ich denke der Fehler startet:
> ...
>
> Korrekt, Anfaengerfehler. Falls der Stick die Daten schneller liefert, als
> fhem
> sie verarbeiten kann, dann kommt genau das zustande.
>
> Habs fuer TCM310 und TCM120 gefixed, kurz getestet und eingecheckt. Ist
> per
> updatefhem verfuegbar. Kannst Du es bitte testen? Das eigentliche Problem
> konnte ich ja bisher nicht reproduzieren.
>
> Gruss,
> Rudi
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
nach längerem Test kann ich den Bufix bestätigen. Habe keine weiteren
Auffälligkeiten mehr gehabt.
Grüße
Thomas
Am Samstag, 4. August 2012 13:53:32 UTC+2 schrieb Thomas Otto:
>
> Hallo Rudi,
>
> sieht sehr gut aus. Mein unsprüngliches Problem scheint damit im Kurztest
> auch weg zu sein. Werde mal übers Wochenende weiter testen und melde mich
> nochmal.
>
> Vielen Dank!
>
> Grüße
> Thomas
>
>
>
> Am Samstag, 4. August 2012 10:17:30 UTC+2 schrieb Rudolf Koenig:
>>
>> Hallo Thomas,
>>
>> > Ich denke der Fehler startet:
>> ...
>>
>> Korrekt, Anfaengerfehler. Falls der Stick die Daten schneller liefert,
>> als fhem
>> sie verarbeiten kann, dann kommt genau das zustande.
>>
>> Habs fuer TCM310 und TCM120 gefixed, kurz getestet und eingecheckt. Ist
>> per
>> updatefhem verfuegbar. Kannst Du es bitte testen? Das eigentliche
>> Problem
>> konnte ich ja bisher nicht reproduzieren.
>>
>> Gruss,
>> Rudi
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com