Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

Begonnen von noansi, 09 Juni 2014, 19:16:01

Vorheriges Thema - Nächstes Thema

noansi

#90
Hallo Martin und Testwillige,

ich habe nochmal für ASKSIN TimeStamp umgebaut.

Die Sendetimestamp von der Firmware bezieht sich nun auf den Start des Sendens der Präambel. (War bisher das Ende des Sendens)
Damit ist die Zeitaussage näher (fast gleich) an nextSend, wie es bei HMLAN verwendet wird (104ms ist das Optimierungsziel in 00_CUL.pm, ist durch 8 teilbar, wegen der Tick Auflösung).
Somit sollte es weniger problematisch sein, HMLAN und CUL in einem System Empfangen und Senden lassen zu können, das gemeinsam genutzte nextSend nun gleichen Wertebereich und (hoffentlich) auch gleiche Bedeutung hat.

Außerdem wird die Verzögerung nun für den Aa Befehl und Aw Befehl getrennt optimiert. Das macht Sinn wegen der unterschiedlichen Interface Anbindungen der verschiedenen CUL Varianten.
Diese Optimierung und Verwendung dieser Befehle setzt aber erst nach einigen Minuten ein, bis ein einigermaßen sinnvoller Scewfaktor für die beiden Uhrzeiten HOST-CUL ermittelt ist.

Das bedeutet auch, dass nicht nur die Firmware, sondern auch die .pm Dateien in FHEM ausgetauscht werden müssen (wie immer, erst Backup machen!)

Gruß, Ansgar.

Fritz R.

@noansi :

Sorry, Antwort übersehen. Ja ich empfange Sensoren aber komischerweise nicht alle. Es sieht so aus, dass die mit V1.1 scheinbar nicht alle auftauchen.

Der Sensor der folgende Fehlermeldung liefert, ist auch ein alter. Hier scheint es probleme mit der Luftfeuchtigkeit zu geben, die Temperatur wird sauber empfangen.

CUL_WS_1 Error: temp/hum Cannot decode K01AA0A00 (sanitycheck). Malformed

Ein anderer Innensensor mit Luftdruck (WS2000ID) taucht leider überhaupt nicht auf.

Ich hatte Probleme, dass mein nanoCul immer nach 1-2 Tagen auf disconnected gewechselt hat und nur durch abstecken und neu einstecken wieder lief. Jetzt habe ich festgestellt, dass der Test-Pin des USB Chips nicht wie vorgesehen auf Masse gelegt war. Seit ich das geändert habe scheint das behoben zu sein.

Wie würdest Du herangehen, um die fehlenden Sensoren zu empfangen? Senden tun sie, das sehe ich an der originalen Anzeige.

Werde nachher mal Deine neue Version draufspielen.

noansi

#92
Hallo Fritz und Testwillige,

erst mal eine Aktualisierung 00_CUL.pm, da mir für ASKSIN Timestamp noch ein Rundungsproblem störend aufgefallen ist. Das führte je nach Gangunterschid der Uhren CUL/HOST dazu, dass die Timing Optimierung nicht zum Ziel kommen konnte.


ZitatDer Sensor der folgende Fehlermeldung liefert, ist auch ein alter

Zeigt der Sensor denn auch mal sinnvolle Werte?
Ist der nah dran oder weiter weg? Fals nicht probiert, dann ändere mal die Position, sprich erst mal in den gleichen Raum, wie CUL.

ZitatEin anderer Innensensor mit Luftdruck (WS2000ID) taucht leider überhaupt nicht auf.
Der kommt auf Code 8 rein, falls Du nicht die Adresse verstellt hast.
Richte den mal von Hand in der fhem.cfg ein. Automatische Erkennung und Einrichtung habe ich noch nicht getestet, respektive wegen anderem Müll, der reinkommt auch deaktiviert, um nicht laufend komische neue Sensoren wieder rauswerfen zu müssen.

ZitatWie würdest Du herangehen, um die fehlenden Sensoren zu empfangen? Senden tun sie, das sehe ich an der originalen Anzeige.
Richte auch die mal händisch in der fhem.cfg ein und schau was dann kommt.

Und erst mal mit guten Empfangsvorraussetzungen starten, also gleicher Raum, aber nicht direkt am CUL dran.
Dann wirst Du wohl die Empfangsparameter noch optimieren müssen, denke ich. Laufen sollte es auch noch mit V1.1 Protokoll, wenn ich es nicht irgendwie inzwischen vermukst haben sollte. Aber an dem Code war ich nicht mehr dran und in der board.h für nanoCUL ist es auch nicht abgeschaltet.

Wenn dass nicht hilft, müsstest Du mit verbose 4 bei dem nanoCUL die Rohdaten mal ins log schreiben. Dann können wir eventuell sehen, ob da noch was auf bit Ebnen schief geht.
Die 00_CUL.pm und 14_CUL_WS.pm von mir benutzt Du auch in aktueller Form?!?

Gruss, Ansgar.

EDIT1: Ich habe Firmware und 00_CUL.pm aktualisiert. Bei CUNO2 habe ich einen Fehler bei der Kommunikation über USB behoben. Das gleiche dürfte auch für CUNO gelten, auch wenn ich es nicht testen kann.
Ich habe die Ready Meldung nach Reboot für die seriell Varianten noch etwas abgewandelt und in 00_CUL.pm wird diese nun ausgewertet, so dass nach einem Watchdog Reset auch initialisiert wird.
Ausserdem ist die Optimierung des Aw Timings geändert.
Bei STACKABLE_CC funktionieren nun auch die Notifies, so dass sich auch bei diesen die Ints_per_Sec aufzeichnen lassen.

EDIT2: Für SlowRF habe ich eine Empfangs Timeout Reaktion ergänzt.

EDIT3: Bei ASKSIN habe ich den 360ms Burst auf 8ms abrundend umgestellt. Also 352-360ms
            Bei SlowRF ist der Sync Start verbessert und auch das BitTiming logging verbessert.
            CUN, CUNO und CCD habe ich mal angepasst, ist aber mangels Hardware noch gänzlich ungetestet.

Edit: Anhang gelöscht, da update siehe unten.

Fritz R.

Hallo,

vielen Dank für die Rückmeldung.
Ich habe jetzt die Version aus dem letzten Post drauf und die 3 Dateien in FHEM getauscht (hatte ich vorher auch gemacht)

Ich hab jeztz den Sensor der die Fehlermeldung liefert 0,5m vom nanoCul platziert. Komischerweise kamen die Temperaturwerte immer an, aber die Feuchtigkeitswerte lösten wohl die Fehlermeldung aus. Nur ganz am Anfang sehe ich im Log beide Werte, dann nur noch die Temperatur. Auch in STATE steht nur die Temperatur. Mal sehen wie es sich jetzt entwickelt.

ZitatRichte auch die mal händisch in der fhem.cfg ein und schau was dann kommt.
Das war ein Top Hinweis, funktioniert, wird als WS7000 angezeigt, Werte sind plausibel. Automatische Einrichtung scheint hier nicht zu erfolgen.

noansi

Hallo Fritz,

Zitattemp/hum Cannot decode K01AA0A00 (sanitycheck). Malformed
Zur Erläuterung, stören tut sich 14_CUL_WS.pm an den "A"s in der Message. Denn da dürfern nur dezimal Ziffern bei einem Temp/Hum Sensorkommen. Der Sensor hat die Adresse 0, also den Code 1 (sofern da nicht schon das Bit Drama seinen Lauf genommen hat.

Wenn Du noch schreiben kannst, was der Sensor eigentlich liefern sollte, z.B. ein zuvor/danach richtig empfangenes Wertepaar, könnte man eventuell daraus etwas ableiten, was bei dem Sensor an falschen Bits empfangen wird. Mehr Infos liefert aber das Rohdaten Log.

Was wird denn beim NanoCUL bei den Readings "Ints_per_sec" und "TO_Ints_per_sec" so angezeigt?

Gruß, Ansgar.

noansi

Hallo Fritz und Testwillige,

die Software in der letzten Nachricht http://forum.fhem.de/index.php/topic,24436.msg288122.html#msg288122 ist aktualisiert.

freq:868.300MHz bWidth:232kHz rAmpl:38dB sens:12dB drate:3.273kBit/s agcprio:0 agcwait:32 agchyst:2 dcBlockingoff:0
bzw.
freq:433.870MHz bWidth:232kHz rAmpl:38dB sens:12dB drate:3.273kBit/s agcprio:0 agcwait:32 agchyst:2 dcBlockingoff:0

scheint eine brauchbare Einstellung für die Wetterstationssensoren zu sein. Damit wird das Timing der empfangenen Signale besser aufgelöst.
Mit Verringerung der Bandbreite macht sich bei mir eine Absenkung der Frequenz um 50kHz (von der Sensorsendefrequenz) positiv bemerkbar. Die Sensoren streuen anscheinend, so dass eine stärkere Verringerung der Bandbreite wieder zu Empfangsverlust einzelner Sensoren führt.

Gruß, Ansgar.

phantom

Hallo,

auch ich verwende einen CUL433 mit CUL_WS (modified) und diversen WS2000-Wettersensoren. Leider ist der Empfang verglichen mit der ELV-WS2000PC-Wetterstation recht unzuverlässig, da viele Telegramme der Sensoren nicht empfangen werden.

Könnte die Spezial-Firmware helfen, dieses Probleme in den Griff zu bekommen, oder sind es eher die CUL-Parameter bWidth, etc. ... ?

Zudem kommen immer mal wieder diese Meldungen im Log vor:
2015.05.30 01:46:50 5: CUL/RAW: /K001F
2015.05.30 01:46:50 4: CUL_Parse: CUL433 K001F -58.5
2015.05.30 01:46:50 2: CUL433: unknown message K00

Da komme ich als Newbie im Moment nicht weiter...

An den kommenden Feiertagen werde ich mal die Firmware CUL_V3_99_75_14 testen, evtl. kommt dann auch der alte Sensor mit V1.1-Protokoll an (dies ist nicht die K00-message).

DIRK

noansi

Hallo Dirk,

Zitatoder sind es eher die CUL-Parameter bWidth, etc. ... ?
Ich würde sagen es beginnt mit der Antenne, geht über die Einstell-Parameter und setzt sich fort über die Firmware.  ;)

So habe ich mich jedenfalls vorgetastet.

Bei den Parametern wirst Du wohl mit der Standardfirmware mit sens = 8 (oder 12) gegenüber sens = 4 eine Verbesserung feststellen.
Ich habe noch Parameter ergänzt, weil noch mehr Parameter Einfluss auf den Empfang haben, was es aber auch nicht einfacher macht, gute zu finden.

Die Standardfirmware vesteht kein V1.1 Protokoll und beim V1.2 Protokoll hängt es an der Anzahl der Nibbles (gerade oder ungerade), ob Sie verstanden werden können oder nicht (oder es zufällig trotzdem passt).

ZitatZudem kommen immer mal wieder diese Meldungen im Log vor
Das ist mehr oder minder normal. Die Datentelegramme sind vom Protokoll her schon so schwach mit Checksumme abgesichert, dass Mehrfachbitfehler (oder verkrüppelte Telegramme) noch eine zu große Chance haben, um durchzukommen.
CUL und CUL_WS versuchen mit weiteren Prüfungen da noch was Unsinniges raus zu filtern.

Versuchs halt mal, aber sicher Dir vorher die Dateien, die Du austauschst.

Die zusätzliche Anzeige der Interrupts/s hat sich bei mir als Indikator für zu hohe rampl Werte gezeigt. Wenn die deutlich 3-Stellig oder 4-Stellig sind, dann ist rampl zu hoch (oder auch sens zu gering) und es wird auf viel Rauschen schon ein Empfangsversuch unternommen. rampl Schritt für Schritt senken (und mind. 2 Minuten warten, um den Effekt auch in den Interrupts zu sehen). Wenn die Interrupts gerade 2-Stellig oder niedrig 2-Stellig sind, dann passt dieser Parameter schon gut.

Die rampl=42 in der Standardfirmware scheinen die AGC Regelung nach oben hin zu begrenzen und dadurch etwas zu stabilisieren. Optimal ist es deswegen aber noch nicht zwingend.

Die Datenrate mit drate höher zu wählen, als die Bitrate des Senders, macht sich ebenfalls positiv bemerkbar. Die 1.5kbit der Standard Firmware scheinen noch zu niedrig zu sein.

Gruß, Ansgar.

Bastel-Frank

Wie geht es in dem Thema weiter? Ist es geplant, dass die Entwicklung in den Haupt-Zweig einfließen wird?

rudolfkoenig

Ich hab das z.Zt. nicht vor, da die Aenderungen gross sind. Vom culfw gibts mWn auch 2 weitere forks: a-culfw mit Unterstuetzung diverser 433MHz Protokolle, und eine ARM Variante.

bjoernh

Zitat von: rudolfkoenig am 16 September 2015, 20:23:18
Ich hab das z.Zt. nicht vor, da die Aenderungen gross sind. Vom culfw gibts mWn auch 2 weitere forks: a-culfw mit Unterstuetzung diverser 433MHz Protokolle, und eine ARM Variante.
Die ARM Variante ist inzwischen in der a-culfw enthalten. Es gibt also so wie ich es sehen nur diese zwei Varianten.
Zitat von: Bastel-Frank am 16 September 2015, 20:04:25
Wie geht es in dem Thema weiter? Ist es geplant, dass die Entwicklung in den Haupt-Zweig einfließen wird?
Wenn Du möchtest kannst Du oder jemand anderes gerne bei der a-culfw mithelfen.

noansi

#101
Hallo Martin,

hier eine neue Version zum Testen des HM Updates, da sich in der letzten Version mit dem Umbau der RF-Modus Umschaltung ein Bug bei der FUP Umschaltung eingeschlichen hat, so das bei aktivem ASKSIN mit AR nicht auf die hohe Datenrate umgeschaltet wurde.
Erst mal nur das HEX File für CUL_V3 im zip. Für Source und Co. muss ich etwas weiter ausholen.

Gruß, Ansgar,

Edit: Anhang gelöscht, da update siehe unten.

noansi

#102
Hallo Martin und Testwillige,

anbei eine neue Version der Firmware und angepasster Module zum testen.

Da ich schon länger kein FHEM update mehr fahren kann, beruhen die Moduländerungen in FHEM module changed.zip auf einem Stand von Ende 2014. Also unbedingt erst ein Backup der alten Datein machen bevor sie ersetzt werden!
Außerdem natürlich den letzten offiziellen Stand der Firmware bereit halten, falls es unerwünscht läuft.

In der Firmware ist ASKSIN geringfügig geändert, dafür mehr in 00_CUL.pm, da ich das Messen des ScewFaktors Systemuhr zu CUL Uhr noch verbessert habe und der gemessene scF jetzt auch als Reading einen Neustart "überlebt".

Stacking ist optimiert. Daten, die zum nächsten aufgesteckten Stacking Modul weiter geschickt werden müssen, werden sofort beim Zeichen Empfang weiter geschickt, statt erst komplett empfangen zu werden, um dann erst weiter geschickt zu werden. Für HM hat das den Vorteil einer geringeren Sendeverzögerung bei weiter oben aufgestecktem Modul. Jedes Modul mehr sollte so in der Regel nur mit zwei Zeichen mehr Übertragungsverzögerung zu Buche schlagen.
Rückwärts geht das leider nicht, so dass beim Empfang weiterhin die Übertragungszeit von Modul zu Modul bis zum Raspi voll zu schlägt. Bei einer z.B. 32 Byte Nachricht sind das ca. 7,5ms pro Modul, also nicht zu vernachlässigen bezüglich sensiblem Timing.

Den 'e' Befehl habe ich besser abgesichert, damit nicht ein "einfalscherBefehl\r\n" die EEPROM Werte wieder zurück setzt, wie das bei der Timestamp Versionserkennung gelegentlich passiert ist, vermutlich wegen Pufferüberlauf.
Die Timestamp Versionserkennung habe ich auch überarbeitet, da der Löschversuch des Empfangspuffers nicht immer ausreichte. Gerade Empfangene Daten eines noch aktiven Empfangsmodus konnten da stören.

Da ich in der Firmware SlowRF auf 8us und damit auch den Timer1 auf 8us durchlaufend umgestellt habe, haben sich neue Wartefunktionen ergeben, die den Timerwert abfragen.

Mit X251 werden bei SlowRf nun auch Bit-Timing Daten mit Empfangsdaten übertragen, angehängt als _+HEX Werte. 00_CUL.pm nimmt das dann wieder auseinander. Zusammen mit dem WS, TX und KS300 Modul werden damit BitTiming Statistiken bei CUL und den Sensoren geführt (abschaltbar über Atrribut DontShowRawTiming = 1). Mit list CUL_NAME bzw. list Sensor_NAME kann man sich das dann ansehen, insbesondere Histogrammwerte für Bitlänge, Highzeit und Lowzeit.
Das ist interessant, wenn man an der Datenrate dreht, um den Empfang zu optimieren.

SlowRf läuft auf einem geänderten Match basiertem Algorithmus für den Ähnlichkeitsvergleich der Bits. Ich habe mit drate >1500, sens 12, agcwait 16 - 32, bessere Erfahrungen machen können, als mit den default Einstellungen.
Wenn die Interrupts/s hoch sind, weil vermutlich das Grundrauschen als Pegelwechsel interpretiert wird, scheint es ganz gut zu sein, AgcMaxDVGA zu erhöhen. Jeder Empfänger verhält sich da etwas anders. Das Reading Ints_per_sec zeigt es an.

Das Reading IntCalcStat zeigt die Rechenzeit der SlowRf Interrupt Routine in µs an. Die darf nicht länger, als das kürzest auszuwertende Bittiming sein und ist daher für die Programmierung interessant.

Ausserdem habe ich mit dem 'J' Befehl noch ein TX3 Senden eingebaut, z.B. "JA07E723720".

EDIT: Noch eine wesentliche Ergänzung. Bei CUL_V3 (USB Atmel) lässt sich nun eine USB-Seriennummer in der board.h konfigurieren. Damit kann man die CULs unter Linux unterscheiden. Mein Raspi hat die blöde Eigenschaft, die USB-Ports meines 10-fach USB-Hubs bei Warmstart in umgekehrter Reihenfolge zu erkennen, wie beim Kaltstart. Damit werden die beiden angeschlossenen CULs vertauscht. 433MHz und 868MHz sind nun mal sehr unterschiedlich, daher fällt das extrem störend auf. Ebenso, wenn man 2 gleiche Betreibt und deren Aufstellort empfangsoptimiert ist.
In der "99-usb-serial.rules" ist dann ein Beispiel, wie man das mit der Seriennummer für das immer gleiche Verlinken zu gleiche Portnamen nutzen kann. Die gehört nach /etc/udev/rules.d. Ein Blick da hinein offenbart die Portnamen, denen die jeweilgen CUL Seriennumern zugeordnet werden.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

noansi

#103
Hallo Martin und Testwillige,

anbei eine neue Version der Firmware und angepasster Module zum testen.

Da ich schon länger kein FHEM Update mehr fahren kann, beruhen die Moduländerungen in FHEM_module_changed.zip auf einem Stand von Ende 2014. Also unbedingt erst ein Backup der alten Dateien machen bevor sie ersetzt werden!
Außerdem natürlich den letzten offiziellen Stand der Firmware bereit halten, falls es unerwünscht läuft!

Insbesondere habe ich den SPI Zugriff etwas beschleunigt und eine kleine SPI-API gebaut. Das hat dann auch für CC1101 zu neuen internen Funktionen zur Programmierung der Register geführt.

Für die Netzwerk Varianten habe ich den Ethersex Treiber und UIP überarbeitet. Das hat noch etwas mehr Geschwindigkeit gebracht (deutlich verringerte Ping Zeiten) und vor allem Stabilität der Netzwerkverbindung, da ich dabei auch auf diverse Merkwürdigkeiten und Bugs gestoßen bin. CUNO2, CUNO und CUN sind auf Ethersex ein-/umgestellt.
Der ENC28J60 Treiber hat(te) auch zumindest einen Bug beim Phy Register Zugriff. Ist auch überarbeitet, jedoch völlig ungetestet.

Um dem Compiler weniger Chancen für Quatsch zu lassen (auch wenn der gcc schon ganz guten Code baut), habe ich insbesondere einige SPI Rountinen in Assembler Funktionen/Defines gebaut. Somit ist derzeit eine Begrenzung auf die AVR Mega Familie gegeben.

Die Tabelle mit Befehlen ist nach ttydata.c gewandert, wo sie sinngemäß hingehört, wie ich meine und wird über die board.h defines jeweils angepasst. So passiert eine Doppelbelegung mit gleichem Buchstaben ('E') nicht so leicht.
Damit SPI devices keinen Startblödsinn abbekommen, ist am Anfang von main.c eine Initialisierung aller SPI CS Signale eingebaut.

Getestet habe ich mit CUL V3, COC, SCC, CUNO2 (hex File in culfw-code-459-trunk_lufa_rf_cr_sd_75_58.zip enthalten) und meiner beigefügten Änderungen an alten FHEM CUL Modulen. Ohne die Moduländerungen geht es nicht. Es gilt das, was ich in vorherigen Beiträgen schon geschrieben habe.

EDIT: Um etwas Flash-Speicheplatz zu sparen, habe ich mal die Funktionsroutionen ein klein wenig angepasst. Bisher ist bei Kommandos immer der Zeiger auf das komplette Kommando an das Funktionmodul übergebn worden. Das ist aber ungünstig, weil erstens redundant (das Modul "weiss" ja, was es ist) und zweitens damit unötige Zeigeradditionen nötig werden, die nur zum Teil durch den ld Befehl des Prozessors abgefangen werden können. Das steckt in culfw-code-459-trunk_lufa_rf_cr_sd_75_63.zip neben weiteren kleinen Korrekturen drin.
Schade, dass in den Modulen nicht so eine schöne Systematik, wie bei den Hauptkommandos umgesetzt wurde. Sonst könnte man uint8_t callfn(char *buf) aus ttydata.c um einen Tabellenzeiger ergänzen und dann auch in den Modulen mit Sprungtabellen arbeiten. Das könnte noch weiteren Speicherplatz bringen, blöderweise aber auch eine Absage and die Kompatibilität zu bisherigen CUL Befehlen.
Ich kann mangels Hardware nicht alle Befehle testen. Daher ist es möglich, das es dabei mit dieser Version noch Problme bei der Kommandointerpretation gibt.
Die culfw-code-459-trunk_lufa_rf_cr_sd_75_58.zip arbeitet aber noch nach dem alten Strickmuster.
EDIT2: Immehin habe ich mit Funktionseinschränkungen CUL_V2, CUL_V2_HM und CUL_V2_MAX wieder bezüglich Speicher compilierbar bekommen, mangels Hardware natürlich ungestestet.

Edit: Anhang gelöscht, da update siehe unten.

Gruß und ein frohes Fest, Ansgar.

PS: Ich habe noch ein paar Module anderer Art in das FHEM_module_changed.zip gepackt.

25_IPIO88_Telnet.pm  spricht ELV IPIO88 per Telnet an.
88_IPWE_Telnet.pm     spricht ELV IPWE 1 per Telnet an.
70_USBWX.pm              ist verbessert und spricht ELV USB-WX an.
98_IntervalTimer.pm     erlaubt die Einrichtung von Interval Timern. Nett zum Senden von Testpacketen an CUL.

ambiman

Halo zusammen,

habe die Firmware auf Empfehlung von Martin wegen diesem Problem hier
http://forum.fhem.de/index.php/topic,43675.msg382258.html installiert.
Kann man mit dieser Firmware kein IT-send mehr durchführen?

Folgendes findet sich nach dem IT-Schaltversuch im Log:


015.12.31 13:16:53 2: IT set Schalter_Teich_LED on
2015.12.31 13:16:58 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2015.12.31 13:16:58 2: IT IODev device didn't answer is command correctly:   raw => No answer
2015.12.31 13:16:58 3: Setting CUL_0 baudrate to 9600
2015.12.31 13:16:58 1: /dev/ttyACM0 reappeared (CUL_0)
2015.12.31 13:16:59 1: CUL_0 is VERSION_TS, V 99.75 CUL868, CUL_V3.4
2015.12.31 13:16:59 3: CUL_0: Possible commands: ABCEFGJKMRTUVWXYZbefilmtux
2015.12.31 13:16:59 2: IT set Schalter_Teich_LED on
2015.12.31 13:17:02 2: IT IODev device didn't answer is command correctly:   raw => AFF0100043AC9000C13867030E294000000006E4AFE
2015.12.31 13:17:05 2: IT set Schalter_Teich_LED off
2015.12.31 13:17:10 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2015.12.31 13:17:10 2: IT IODev device didn't answer is command correctly:   raw => No answer
2015.12.31 13:17:10 2: IT set Schalter_Teich_LED off
2015.12.31 13:17:10 2: IT IODev device didn't answer is command correctly:   raw => No answer
2015.12.31 13:17:11 3: Setting CUL_0 baudrate to 9600
2015.12.31 13:17:11 1: /dev/ttyACM0 reappeared (CUL_0)
2015.12.31 13:17:11 1: CUL_0 is VERSION_TS, V 99.75 CUL868, CUL_V3.4
2015.12.31 13:17:11 3: CUL_0: Possible commands: ABCEFGJKMRTUVWXYZbefilmtux


Darüber hinaus hatte ich noch folgende FM:


015.12.31 13:02:34 3: CUL_send:  CUL_0  id:311A51 dDly:80
2015.12.31 13:02:34 3: CUL_ParseTsHM: CUL_0  id:311A51 dhmSt:96
2015.12.31 13:10:46 3: CUL_send:  CUL_0  id:311A51 dDly:77
2015.12.31 13:10:46 3: CUL_ParseTsHM: CUL_0  id:311A51 dhmSt:104
2015.12.31 13:11:29 3: CUL_0: Unknown code ERR:ASKSINSFRX, help me!
2015.12.31 13:11:29 3: CUL_0: Unknown code ERR:ASKSINIDLERX, help me!
2015.12.31 13:15:48 3: CUL_send:  CUL_0  id:311A51 dDly:85
2015.12.31 13:15:48 3: CUL_ParseTsHM: CUL_0  id:311A51 dhmSt:104