Fehler im autocreate?

[Mitch]

Hallo Zusammen,

habe seit ein paar Tagen wieder das autocreate an, weil ich gerade am um- und aufbauen bin.

Leider häufen sich die Meldungen über neue Devices, die autocreate nicht anlegen kann, weil der Syntax bzw. der Hauscode nicht stimmt.

Code Auswählen Erweitern

2015.04.08 12:50:57 1: ERROR: wrong syntax: define <name> CUL_HOERMANN 10-digit-hex-code
2015.04.08 12:50:57 1: define CUL_HOERMANN_CHDE520094 CUL_HOERMANN_CHDE520094 CUL_HOERMANN CHDE520094: wrong syntax: define <name> CUL_HOERMANN 10-digit-hex-code
2015.04.08 12:50:57 2: autocreate: define CUL_HOERMANN_CHDE520094 CUL_HOERMANN CHDE520094
2015.04.08 12:41:26 1: ERROR: Define FHT_atcb: wrong CODE format: specify a 4 digit hex value
2015.04.08 12:41:26 1: define FHT_atcb FHT_atcb FHT atcb: Define FHT_atcb: wrong CODE format: specify a 4 digit hex value
2015.04.08 12:41:26 2: autocreate: define FHT_atcb FHT atcb
2015.04.08 12:37:23 1: ERROR: Define FHT_cta7: wrong CODE format: specify a 4 digit hex value
2015.04.08 12:37:23 1: define FHT_cta7 FHT_cta7 FHT cta7: Define FHT_cta7: wrong CODE format: specify a 4 digit hex value
2015.04.08 12:37:23 2: autocreate: define FHT_cta7 FHT cta7
2015.04.08 12:24:39 1: ERROR: Define FHT_ct49: wrong CODE format: specify a 4 digit hex value
2015.04.08 12:24:39 1: define FHT_ct49 FHT_ct49 FHT ct49: Define FHT_ct49: wrong CODE format: specify a 4 digit hex value
2015.04.08 12:24:39 2: autocreate: define FHT_ct49 FHT ct49

Was ist denn z.B. ct49 für ein komischer Code?

[rudolfkoenig]

Der Fehler ist sicher nicht im autocreate.

Vielleicht ein Bug im culfw code, indem es Zeilen mit R oder T am Anfang liefert, die aber kein HOERMANN/FHT-Telegramme sind. Verwendest du einen der Alternativ-culfw-Firmwares? In welchem rfMode laeuft dein CUL?

[Mitch]

Nein, habe die offizielle V 1.61 CUNO868 (erst vor einer Woche neu upgedatet).
rfmode = SlowRF

Hab aber parallel auch noch eine FHZ1300 dran. Kann das zu Problemen führer?
Hatte früher nie solche Themen?

Edit: gerade kam wieder dein Schwung rein:

Code Auswählen Erweitern

2015.04.08 13:31:26 1: ERROR: Define FHT_ctcb: wrong CODE format: specify a 4 digit hex value
2015.04.08 13:31:26 1: define FHT_ctcb FHT_ctcb FHT ctcb: Define FHT_ctcb: wrong CODE format: specify a 4 digit hex value
2015.04.08 13:31:26 2: autocreate: define FHT_ctcb FHT ctcb
2015.04.08 13:31:17 1: ERROR: Define FHT_atc5: wrong CODE format: specify a 4 digit hex value
2015.04.08 13:31:17 1: define FHT_atc5 FHT_atc5 FHT atc5: Define FHT_atc5: wrong CODE format: specify a 4 digit hex value
2015.04.08 13:31:17 2: autocreate: define FHT_atc5 FHT atc5
2015.04.08 13:28:16 1: ERROR: Define FHT_ctc0: wrong CODE format: specify a 4 digit hex value
2015.04.08 13:28:16 1: define FHT_ctc0 FHT_ctc0 FHT ctc0: Define FHT_ctc0: wrong CODE format: specify a 4 digit hex value
2015.04.08 13:28:16 2: autocreate: define FHT_ctc0 FHT ctc0
2015.04.08 13:26:01 1: ERROR: wrong syntax: define <name> CUL_HOERMANN 10-digit-hex-code
2015.04.08 13:26:01 1: define CUL_HOERMANN_CH60EA0006 CUL_HOERMANN_CH60EA0006 CUL_HOERMANN CH60EA0006: wrong syntax: define <name> CUL_HOERMANN 10-digit-hex-code
2015.04.08 13:26:01 2: autocreate: define CUL_HOERMANN_CH60EA0006 CUL_HOERMANN CH60EA0006
2015.04.08 13:23:18 1: ERROR: Define FHT_at49: wrong CODE format: specify a 4 digit hex value
2015.04.08 13:23:18 1: define FHT_at49 FHT_at49 FHT at49: Define FHT_at49: wrong CODE format: specify a 4 digit hex value
2015.04.08 13:23:18 2: autocreate: define FHT_at49 FHT at49

[rudolfkoenig]

Ich habe von sowas noch nie gehoert.
Falls ein reboot des CULs (set CUL raw B00) nicht hilft, dann bitte "attr CUL verbose 5" einschalten.

[Mitch]

Hier ein Auszug mit verbose 5:

Code Auswählen Erweitern

2015.04.08 15:48:52 1: ERROR: Define FHT_ct57: wrong CODE format: specify a 4 digit hex value
2015.04.08 15:48:52 1: define FHT_ct57 FHT_ct57 FHT ct57: Define FHT_ct57: wrong CODE format: specify a 4 digit hex value
2015.04.08 15:48:52 2: autocreate: define FHT_ct57 FHT ct57
2015.04.08 15:48:52 3: FHT Unknown device ct57, please define it
2015.04.08 15:48:52 5: CUNO dispatch 810d04xx0909a001ct574100cc82c8
2015.04.08 15:48:52 4: CUL_Parse: CUNO TCT5741CC82C8

2015.04.08 15:48:52 5: CUL/RAW: TC/T5741CC82C8

[rudolfkoenig]

Ok, ich sehe es, habe aber keine Ahnung, wie culfw auf die Idee kommt, TCT5741CC82C8 zu melden.

Das sind gleich zwei Auffaelligkeiten:
- in einer Zeile zweimel T
- T5741CC82C8 ist auch komisch, weil CC82C8 kein FHT Kommando ist (soweit ich es sehe).

[Mitch]

Was kann ich dagegen unternehmen?

[Puschel74]

autocreate abschalten? und warten bis Rudi eine Lösung hat.
Oder du programmierst die culfw um.

[rudolfkoenig]

Ich wuerde mit culfw debugging anfangen (im screen X67, bzw. siehe culfw commandref).

@Puschel74: da ich keine Idee habe, woran es liegen koennte, ist die Strategie "auf Rudi warten" nicht sehr effizient.

[bjoernh]

Ich habe mir das auch eben angesehen, aber so einen richtigen Grund im Code erkenne ich auch nicht.
Da hilft wohl nur vor Ort debuggen.

[Puschel74]

@Puschel74: da ich keine Idee habe, woran es liegen koennte, ist die Strategie "auf Rudi warten" nicht sehr effizient.

Das geb ich dir recht.
Es ist aber sehr selten das dir die Ideen ausgehen 

[Elektrolurch]

Hallo,

seit dem letzten Update von Autocreate hat sich wohl wieder ein Fehler eingeschlichen:

Während fhem noch hochfährt und noch nicht alle Definitionen gelesen hat, erkennt autocreate schon fht und cul_ftk - devices und legt diese an, welches dann natürlich zu einem ziemlichen Chaos führt, da diese ja auch in der fhem.cfg mit andern Namen aber gleichen Hardware-ID stehen.
Und dann gab es noch was merkwürdiges:
Ein Teil der Definitionen sind aus der fhem.cfg verschwunden, und zwar alles, was hinter der letzten include - Anweisung stand.
Eines der include - Dateien war komplet leer, ineinem anderen waren nur noch die Kommentare vorhanden.
Das ganze konnte ich zweimal reproduzieren.
Danach hatte ich die Nase erst einmal voll und habe die
attr autocreate disable 1
gesetzt und die Definition in der fhem.cfg ganz ans Ende geschoben.

Jetzt verschwinden wenigstens keine Daten mehr und es werden auch keine fhts und cul_ftks angelegt.

Allerdings muss sich durch das Update noch ein weiterer Fehler eingeschlichen haben, denn fhem auf der FB startet ohne weitere Fehlermeldung in unregelmäßigen Abständen neu (zwischen 1 und 6 Stunden).

Werde mal systematisch die älteren Versionen einspielen und das versuchen zu lokalisieren.

Elektrolurch

[rudolfkoenig]

Eigentlich unmoeglich, da:
- autocreate af UNDEFINED Events reagiert
- UNDEFINED Events werden aus dem ParseFn getriggert
- ParseFn wird von ReadFn ueber Dispatch getriggert.
- ReadFn wird vom select aufgerufen, das nach dem vollstaendigen Einlesen der fhem.cfg und fhem.state erst drankommt.

Die Aussagen haette ich deswegen gerne mit einem Log (attr global verbose 5) bewiesen.

[Elektrolurch]

Hallo Rudi,

ich muss mal sehen, ob ich das log noch habe, aber da stand es in folgender Reihenfolge drin:

include fhem.cfg
# Darin werden autocreate, global und die drei BULs definiert.
und sofort steht da auch, dass da fhts und cul_tfks gefunden wurden....

Dann kommen die include - Anweisungen, in denen die Definitionen etwas sortiert abgelegt wurden.


Aber noch eine andere Idee:
Was mich gewundert hatte, ist dass da relativ viele fhts und cul_tfk auf einmal angelegt wurden.
Für mich sah das so aus,  als wären die Funksignale noch im Puffer der CULs gespeichert.
Ich hatte fhem heruntergefahren und manuell über telnet wieder gestartet. Es stand also für ca. 5 Minuten.
DA die config kaputt war, habe ich fhem wieder heruntergefahren und es stand dann für 10 Minuten, bis ich die backup-Daten von der fhem.cfg und den include-Dateien wieder eingespielt hatte.
Neustart: Wieder wurden devices sofort angelegt und die Konfiuration war erneut in TEilen unvollständig.
Dann autocreate auf disable gesetzt, intakte Konfig erneut eingespielt und derzeit läuft es wieder.
Bei dem CUL-Modul gab es ja auch vor kurzem ein Update, da ging es genau um den Puffer des CULs. Die CULs gingen nämlich aus unerfindlichen Gründen nach dem Neustart mit falschen Initialisierungen in Betrieb.  Das sollte eigentlich insofern gefixed worden sein, dass der CUL-Puffer beim Initialisieren jetzt zuerst gelöscht wird. Vielleicht stimmt da noch was nicht.

Jedenfalls sind die Meldungen, dass per autocreate neue devices angelegt wurden, noch vor den Ausgaben der "include" Anweisungen in der fhem.cfg.
Ich kann mir darauf auch keinen Reim machen, ist aber so.

Elektrolurch

[rudolfkoenig]

Nach etwas Code-Analysieren ist deine Geschichte gar nicht mehr so unwahrscheinlich: CUL_Init fuert ein Clear durch, was Readanswer aufruft, was wiederum neuerdings alle unpassenden Daten per Dispatch verteilt. Ich habe den Dispatch Aufruf waehrend der Initialisierung unterbunden und die Aenderungen eingecheckt.