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.
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?
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?
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:
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
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.
Hier ein Auszug mit verbose 5:
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
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).
Was kann ich dagegen unternehmen?
autocreate abschalten? und warten bis Rudi eine Lösung hat.
Oder du programmierst die culfw um.
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.
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.
Zitat von: rudolfkoenig am 09 April 2015, 10:38:03
@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 ;)
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
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.
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
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.
Hallo
hier der log
2015.06.10 09:16:16 1: Including fhem.cfg
2015.06.10 09:16:28 1: FHTTK Unknown device b53492, please define it
2015.06.10 09:16:28 1: FHTTK Unknown device b53492, please define it
2015.06.10 09:16:28 1: Including ./FHEM/00_utils_EG.cfg
2015.06.10 09:16:35 1: Including ./FHEM/00_utils_OG1.cfg
2015.06.10 09:16:37 1: Including ./FHEM/00_utils_OG2.cfg
2015.06.10 09:16:39 1: Including ./FHEM/00_utils_Teststeckdose.cfg
2015.06.10 09:16:39 1: FBAHA DECT200 registered with handle: 00000003
2015.06.10 09:16:40 1: Including ./FHEM/00_utils_Wetter.cfg
2015.06.10 09:16:43 1: Including ./FHEM/00_utils_Telefon.cfg
2015.06.10 09:16:46 1: Including ./FHEM/00_utils_Solar.cfg
2015.06.10 09:16:46 1: HzAnlage: no I/O device
2015.06.10 09:16:48 1: Including ./FHEM/00_utils_Automation.cfg
2015.06.10 09:16:50 1: Including ./FHEM/00_utils_Rolladen.cfg
2015.06.10 09:16:52 1: Including ./FHEM/00_utils_TV.cfg
2015.06.10 09:16:57 1: Including ./log/fhem.save
2015.06.10 09:17:08 2: EMONITOR_InitSingle: Warning device Hb_Media rd energy energy 95269 !
2015.06.10 09:17:08 2: EMONITOR_InitSingle: Warning device Trockner rd energy energy 38441 !
2015.06.10 09:17:08 2: EMONITOR_InitSingle: Warning device Waschmaschine rd energy energy 39996 !
2015.06.10 09:17:21 1:
2015.06.10 09:17:24 0: Server started with 317 defined entities (version $Id: fhem.pl 8690 2015-06-04 16:47:20Z rudolfkoenig $, os linux, user root, pid 8029)
2015.06.10 09:17:25 2: WetterUmgebung: http request failed: connect to http://api.netatmo.net:80 timed out
2015.06.10 09:17:39 1: Wcmcom_Read HzAnlage: http request failed: read from http://192.168.1.19:80 timed out
2015.06.10 09:17:39 2: netatmo_P70:ee:50:03:52:d0: http request failed: read from http://api.netatmo.net:80 timed out
Wie man sieht, wird schon in der zweiten Zeile nach der CUL_Definition und VOR dem Abschluss des Lesens des fhem.cfg - Files vom Parser (?) autocreate aufgerufen.
Die Definition von autocreate hatte ich ans Ende der fhem.cfg geschoben. Durch das save wird wohl aber die Reihenfolge geändert.
Es scheint sich wohl um während der Downtime von fhem im CUL gespeicherte (empfangene) Signale zu handeln. Ist womöglich also ein Fehler in der letzten Version der 00_cul.pm. ?
Anmerkung (hat nichts zum Thema zu tun): Alle nonblocking Aufrufe bringen beim ersten Mal einen http - fail.
Elektrolurch
Bitte melden, falls das Problem mit 00_CUL.pm version 8726 auch auftritt.
Hallo,
zunächst nach ein paar Tagen Test: Das beim Hochfahren von fhem fht - devices angelegt wurden, war wohl ein Problem mit der CUL-Software, ist aber jetzt wohl beseitigt.
Eine Warnung bekomme ich gelegentlich allerdings noch:
2015.06.16 18:25:27 1: FHTTK Unknown device 540f4b, please define it
2015.06.16 18:25:27 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/98_autocreate.pm line 180.
Wer das ist, weiß ich nicht (Nachbar?) :D
Zeile 180:
($min_count, $interval) = split( ':', $fp->{$k}{autocreateThreshold} );
fp->{$k}{autocreateThreshold} Was ist das?
Gruß
Elektrolurch
Zitat2015.06.16 18:25:27 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/98_autocreate.pm line 180.
Danke fuer den Hinweis, habs gefixt.
Zitatfp->{$k}{autocreateThreshold} Was ist das?
Neumodisches Zeug fuer unsichere Module. Siehe http://fhem.de/commandref.html#autocreateThreshold (http://fhem.de/commandref.html#autocreateThreshold)
Herllich! Jetzt lag ich unterm Tisch...!
Zitat:
Neumodisches Zeug fuer unsichere Module. Siehe http://fhem.de/commandref.html#autocreateThreshold