Enocean Pi und Stackable CC

hermi · 01 November 2016, 18:10:56

Hallo zusammen,

ich beschäftige mich seit dem Wochenende mit FHEM habe auf einem Raspberrry Pi 3 das SCC-Modul und meine MAX!-Module ans Laufen gebracht

In meinem Überschwang hatte ich mir gleichzeitig auch ein EnOcean Pi (anstelle eines USB 300) gekauft und feststellen müssen, dass es nicht zusammen mit dem SCC funktionieren kann, da beide die gleiche serielle Schnittstelle des Pi verwenden (ob noch weitere GPIOs doppelt verwendet werden, kann ich zur Zeit nicht beurteilen)

Wenn ich das beim flüchtigen Durchsehen des Codes der aktuellen culfw-Firmware richtig verstanden habe, dann wird
1. im SCC-Modul ein Kommando, welches mit einem * beginnt über eine zweite serielle Schnittstelle zum zum aufgesteckten Modul weitergeleitet (der '*' wird vorher entfernt).
2. im SCC-Modul eine Antwort vom aufgesteckten Modul mit einem '*' versehen und über die erste zum Raspberry zurück gesendet.
3. über die Anzahl der '*' die Adresse des SCC-Moduls definiert.
4. das Handling der '*' in 16_STACKABLE.pm implementiert, welches an 10_CUL.pm andockt.

Nun meine Frage:
Wäre es ein gangbarer Wege, solch ein 16_STACKABLE_ENOCEAN.pm (oder ähnlich) zu programmieren, um ein EnOcean Pi "on top" eines SCC-Moduls ansprechen zu können? Wenn ja, dann scheint nur die unterschiedliche Baudrate (38400 <-> 57600) eine Hürde zu sein.

Schönen Gruß,
Hermann

PS: noch ein Dankeschön an alle, die bei der Entwicklung von FHEM mitwirken!

rudolfkoenig · 01 November 2016, 20:24:47

Ohne Modifikation der culfw auf dem SCC wird es nicht gehen, da culfw bzw. CUL.pm von einem NL terminierten ASCII String ausgeht, d.h. man muesste die Binaerdaten nach Hex und wieder zurueckwandeln. Ob es auch weitere Probleme gibt, weiss ich nicht.
Ich kann aber gerne fuer diesen Sonderfall das STACKABLE_CC bzw. CUL Modul anpassen.

hermi · 01 November 2016, 21:58:13

Oh, dass das EnOcean-Modul Binärdaten kommuniziert, war mir nicht klar.

Demnach müsste man der culfw mitteilen, dass an dem entsprechenden SCC-Modul ein EnOcena-Modul angeschlossen ist und deshalb die Binär<->Hex-Umwandlung stattfinden muss und auch mit einer Baudrate von 57600 kommuniziert werden muss (Oder dieses SCC-Modul muss mit einer spezielle culfw programmiert sein, was aber unschön ist).

Da ich mich mit C besser auskenne als mit Perl könnte ich mich an den nötigen Anpassungen der culfw versuchen.

hermi · 06 November 2016, 14:38:52

Hallo Rudolf,

ich habe inzwischen die culfw so angepasst, dass sie die Binär<->Hex-Umwandlung vornimmt und auch den UART zum EnOcean-Board mit 57600Bd betreibt (aktuell wird nur das Weiterleiten an ein aufgestecktes EnOcean-Modul unterstützt und nicht an ein weiteres Stackable CC).

Allerdings bin ich bei der Anpassung der Perl-Dateien noch ein wenig ratlos. Wenn ich das richtig sehe, müsste man das 16_STACKABLE_CC.pm so anpassen, dass es die empfangenen Daten an TCM_Parse310() weitergeben werden? Ob am 00_TCM.pm ebenfalls etwas geändert werden muss, erschließt sich mir im Moment leider nicht.
Vielleicht kannst Du mir ein paar Hinweise geben?

Merci,
Hermann

rudolfkoenig · 06 November 2016, 19:26:07

Ich meine es reicht STACKABLE_CC und DevIo anzupassen, Klaus muss sein TCM/EnOcean nicht aendern. Ich habe die beiden Dateien geaendert und eingecheckt, konnte aber nur trocken testen, bin also unsicher, ob es funktioniert. Wenn nicht, bitte ein "attr global verbose 5" log hier anhaengen.

Definition:

Code Auswählen

define CUL_1 CUL /dev/tty*** abcd
define TCM_CC STACKABLE_CC CUL_1 TCM
define TCM_0 TCM 310 FHEM:DEVIO:TCM_CC:57600

57600 ist fake, kann beliebig anders gewaehlt werden, muss aber present sein.

hermi · 06 November 2016, 21:26:24

Ich glaube, da kann man nicht meckern, es scheint, dass die Kommunikation zustande gekommen ist und das Modul initialisiert wurde:

Code Auswählen

2016.11.06 21:06:25 3: TCM set TCM_0 reset 
2016.11.06 21:06:27 2: TCM TCM_0 Timeout reading response for set reset
2016.11.06 21:06:27 2: TCM TCM_0 Attribute sendInterval 0 initialized
2016.11.06 21:06:27 3: TCM get TCM_0 baseID
2016.11.06 21:06:27 2: TCM TCM_0 RESPONSE: BaseID: FFA27300 RemainingWriteCycles: 0A
2016.11.06 21:06:27 3: TCM get TCM_0 version
2016.11.06 21:06:27 2: TCM TCM_0 RESPONSE: APIVersion: 02050000 APPVersion: 020A0000 ChipID: 019944E6 ChipVersion: 454F0103 Desc: GATEWAYCTRL
2016.11.06 21:06:27 3: TCM set TCM_0 smartAckMailboxMax 0
2016.11.06 21:06:27 2: TCM TCM_0 RESPONSE: OK
2016.11.06 21:06:27 2: TCM TCM_0 smartAckMailboxMax 0 initialized
2016.11.06 21:06:27 3: TCM set TCM_0 repeater 0000
2016.11.06 21:06:27 2: TCM TCM_0 RESPONSE: OK
2016.11.06 21:06:27 2: TCM TCM_0 repeater 0000 restored
2016.11.06 21:06:27 3: TCM set TCM_0 mode 00
2016.11.06 21:06:29 2: TCM TCM_0 Timeout reading response for set mode
2016.11.06 21:06:29 3: TCM set TCM_0 maturity 01
2016.11.06 21:06:31 2: TCM TCM_0 Timeout reading response for set maturity
2016.11.06 21:06:31 2: TCM TCM_0 initialized

Die beiden Timeouts am Ende des Logs kann ich nicht bewerten...

Mir ist in der culfw aufgefallen, dass die TTY_BUFSIZE 128 Byte groß ist, könnte das unter Umsänden Probleme bereiten? Ich habe keine Vorstellung, wie groß die Datenpakete der EnOcean-Kommunikation im praktischen Betrieb sein können.

Für zwei aus der Hüfte geschossene Anpassungen ist das Ergebnis aber schon mal nicht schlecht

Ich werde leider erst im Laufe der Woche zwei EnOcean-Schalter bekommen, mit denen ich dann die weitere Kommunikation testen kann.

Erstmal vielen Dank für die superschnelle Reaktion!

hermi · 08 November 2016, 21:17:39

Heute kamen die PTM210-Schalter an und ich konnte etwas weiter experimentieren.

Zunächst zu den Timeouts, die ich am Sonntag noch hatte:
Die sind jetzt weg, nachdem meine Anpassung der culfw nun auch mit hex-Zahlen mit Kleinbuchstaben umgehen kann

Hier der Ablauf der Initialisierung mit einigen zusätzlichen Log-Ausgaben des STACKABLE-Moduls:

Code Auswählen

2016.11.08 20:39:05 3: TCM set TCM_0 reset 
2016.11.08 20:39:05 5: TCM TCM_0 sent ESP: 550001000570020E
2016.11.08 20:39:05 5: SW: 550001000570020E
2016.11.08 20:39:05 3: STACKABLE_IOWriteFn:   '550001000570020e'
2016.11.08 20:39:05 3: STACKABLE_CC_Write:   '*550001000570020e'
2016.11.08 20:39:05 3: STACKABLE_IOReadFn:   '*5500010002650000'
2016.11.08 20:39:05 5: TCM TCM_0 received ESP: 5500010002650000
2016.11.08 20:39:05 5: TCM_Parse 00
2016.11.08 20:39:05 2: TCM TCM_0 RESPONSE: OK
2016.11.08 20:39:06 3: TCM get TCM_0 baseID
2016.11.08 20:39:06 5: TCM TCM_0 sent ESP: 5500010005700838
2016.11.08 20:39:06 5: SW: 5500010005700838
2016.11.08 20:39:06 3: STACKABLE_IOWriteFn:   '5500010005700838'
2016.11.08 20:39:06 3: STACKABLE_CC_Write:   '*5500010005700838'
2016.11.08 20:39:06 3: STACKABLE_IOReadFn:   '*5500050102DB00FFA273000A06'
2016.11.08 20:39:06 5: TCM TCM_0 received ESP: 5500050102DB00FFA273000A06
2016.11.08 20:39:06 5: TCM_Parse 00FFA273000A
2016.11.08 20:39:06 2: TCM TCM_0 RESPONSE: BaseID: FFA27300 RemainingWriteCycles: 0A
2016.11.08 20:39:06 3: TCM get TCM_0 version
2016.11.08 20:39:06 5: TCM TCM_0 sent ESP: 5500010005700309
2016.11.08 20:39:06 5: SW: 5500010005700309
2016.11.08 20:39:06 3: STACKABLE_IOWriteFn:   '5500010005700309'
2016.11.08 20:39:06 3: STACKABLE_CC_Write:   '*5500010005700309'
2016.11.08 20:39:06 3: STACKABLE_IOReadFn:   '*55002100022600020A000002050000019944E6454F0103474154455741594354524C0000000000EB'
2016.11.08 20:39:06 5: TCM TCM_0 received ESP: 55002100022600020A000002050000019944E6454F0103474154455741594354524C0000000000EB
2016.11.08 20:39:06 5: TCM_Parse 00020A000002050000019944E6454F0103474154455741594354524C0000000000
2016.11.08 20:39:06 2: TCM TCM_0 RESPONSE: APIVersion: 02050000 APPVersion: 020A0000 ChipID: 019944E6 ChipVersion: 454F0103 Desc: GATEWAYCTRL
2016.11.08 20:39:06 3: TCM set TCM_0 mode 00
2016.11.08 20:39:06 5: TCM TCM_0 sent ESP: 5500020005CD1C00AB
2016.11.08 20:39:06 5: SW: 5500020005CD1C00AB
2016.11.08 20:39:06 3: STACKABLE_IOWriteFn:   '5500020005cd1c00ab'
2016.11.08 20:39:06 3: STACKABLE_CC_Write:   '*5500020005cd1c00ab'
2016.11.08 20:39:06 3: STACKABLE_IOReadFn:   '*550001000265020E'
2016.11.08 20:39:06 5: TCM TCM_0 received ESP: 550001000265020E
2016.11.08 20:39:06 5: TCM_Parse 02
2016.11.08 20:39:06 2: TCM TCM_0 RESPONSE: NOT_SUPPORTED
2016.11.08 20:39:06 3: TCM set TCM_0 smartAckMailboxMax 0
2016.11.08 20:39:06 5: TCM TCM_0 sent ESP: 5500020006C40800A8
2016.11.08 20:39:06 5: SW: 5500020006C40800A8
2016.11.08 20:39:06 3: STACKABLE_IOWriteFn:   '5500020006c40800a8'
2016.11.08 20:39:06 3: STACKABLE_CC_Write:   '*5500020006c40800a8'
2016.11.08 20:39:06 3: STACKABLE_IOReadFn:   '*5500010002650000'
2016.11.08 20:39:06 5: TCM TCM_0 received ESP: 5500010002650000
2016.11.08 20:39:06 5: TCM_Parse 00
2016.11.08 20:39:06 2: TCM TCM_0 RESPONSE: OK
2016.11.08 20:39:06 2: TCM TCM_0 smartAckMailboxMax 0 restored
2016.11.08 20:39:06 3: TCM set TCM_0 maturity 01
2016.11.08 20:39:06 5: TCM TCM_0 sent ESP: 5500020005CD100150
2016.11.08 20:39:06 5: SW: 5500020005CD100150
2016.11.08 20:39:06 3: STACKABLE_IOWriteFn:   '5500020005cd100150'
2016.11.08 20:39:06 3: STACKABLE_CC_Write:   '*5500020005cd100150'
2016.11.08 20:39:06 3: STACKABLE_IOReadFn:   '*5500010002650000'
2016.11.08 20:39:06 5: TCM TCM_0 received ESP: 5500010002650000
2016.11.08 20:39:06 5: TCM_Parse 00
2016.11.08 20:39:06 2: TCM TCM_0 RESPONSE: OK
2016.11.08 20:39:06 2: TCM TCM_0 maturity 01 restored
2016.11.08 20:39:06 3: TCM set TCM_0 repeater 0000
2016.11.08 20:39:06 5: TCM TCM_0 sent ESP: 5500030005A60900003A
2016.11.08 20:39:06 5: SW: 5500030005A60900003A
2016.11.08 20:39:06 3: STACKABLE_IOWriteFn:   '5500030005a60900003a'
2016.11.08 20:39:06 3: STACKABLE_CC_Write:   '*5500030005a60900003a'
2016.11.08 20:39:06 3: STACKABLE_IOReadFn:   '*5500010002650000'
2016.11.08 20:39:06 5: TCM TCM_0 received ESP: 5500010002650000
2016.11.08 20:39:06 5: TCM_Parse 00
2016.11.08 20:39:06 2: TCM TCM_0 RESPONSE: OK
2016.11.08 20:39:06 2: TCM TCM_0 repeater 0000 restored
2016.11.08 20:39:06 2: TCM TCM_0 initialized

Wenn ich jetzt allerdings auf einen der PTM210-Taster drücke, kommen folgende (global verbose 5) Log-Ausgaben:

Code Auswählen

2016.11.08 21:10:34 5: CUL/RAW: /*5500070
2016.11.08 21:10:34 5: CUL/RAW: *5500070/7017AF630002CCF513003FFF
2016.11.08 21:10:34 5: CUL/RAW: *55000707017AF630002CCF513003FFF/FFFFF500
2016.11.08 21:10:34 5: CUL/RAW: *55000707017AF630002CCF513003FFFFFFFF500/021

2016.11.08 21:10:34 5: SCC_0 dispatch *55000707017AF630002CCF513003FFFFFFFF500021
2016.11.08 21:10:34 3: STACKABLE_CC_Parse: '*55000707017AF630002CCF513003FFFFFFFF500021'
2016.11.08 21:10:34 4: CUL_Parse: TCM_CC 55000707017AF630002CCF513003FFFFFFFF500021
2016.11.08 21:10:34 5: Triggering TCM_CC (1 changes)
2016.11.08 21:10:34 5: Starting notify loop for TCM_CC, first event UNKNOWNCODE 55000707017AF630002CCF513003FFFFFFFF500021
2016.11.08 21:10:34 2: TCM_CC: unknown message 55000707017AF630002CCF513003FFFFFFFF500021
2016.11.08 21:10:35 5: CUL/RAW: /*5500070
2016.11.08 21:10:35 5: CUL/RAW: *5500070/7017AF60
2016.11.08 21:10:35 5: CUL/RAW: *55000707017AF60/0002CCF5
2016.11.08 21:10:35 5: CUL/RAW: *55000707017AF600002CCF5/12003FFF
2016.11.08 21:10:35 5: CUL/RAW: *55000707017AF600002CCF512003FFF/FFFFF500
2016.11.08 21:10:35 5: CUL/RAW: *55000707017AF600002CCF512003FFFFFFFF500/097

2016.11.08 21:10:35 5: SCC_0 dispatch *55000707017AF600002CCF512003FFFFFFFF500097
2016.11.08 21:10:35 3: STACKABLE_CC_Parse: '*55000707017AF600002CCF512003FFFFFFFF500097'
2016.11.08 21:10:35 4: CUL_Parse: TCM_CC 55000707017AF600002CCF512003FFFFFFFF500097
2016.11.08 21:10:35 5: Triggering TCM_CC (1 changes)
2016.11.08 21:10:35 5: Starting notify loop for TCM_CC, first event UNKNOWNCODE 55000707017AF600002CCF512003FFFFFFFF500097
2016.11.08 21:10:35 2: TCM_CC: unknown message 55000707017AF600002CCF512003FFFFFFFF500097

Die Daten des EnOcean-Boards werden von STACKABLE_CC_Parse() an CUL_Parse() weitergegeben, obwohl $name == "TCM_CC" ist.

Der Unterschied zur Initialisierung ist hier wohl, dass das TCM-Modul nicht auf die Daten wartet, sondern sie "unerwartet" gesendet werden.

Müsste deshalb in STACKABLE_CC_Parse() noch eine Weiche zum TCM-Modul eingebaut werden, oder gibt es hier noch ein grundsätzliches Problem?

Hermann

rudolfkoenig · 09 November 2016, 19:50:37

ZitatMüsste deshalb in STACKABLE_CC_Parse() noch eine Weiche zum TCM-Modul eingebaut werden

Ja, danke fuer den Hinweis, habs eingebaut, etwas getestet und eingecheckt.

hermi · 09 November 2016, 23:23:10

Super, jetzt klappt das auch mit dem Anlernen und Schalten, vielen Dank

Ich werde jetzt noch ein wenig testen und danach überlegen, wie ich die culfw dahingehend anpassen kann, dass sie von fhem mitgeteilt bekommen kann, ob ein weiteres SCC-Board oder ein EnOcean-Pi-Board aufgesteckt ist.

Ich habe zwar noch ein Problem, dass einer der beiden baugleichen Schalter fälschlicher Weise als "windowHandle" erkannt wird (wie auch hier schon mal beschrieben https://forum.fhem.de/index.php?topic=55445.0, allerdings ohne Lösung), aber ich vermute, das ist eher ein Problem des Schalters, weil die Daten die er sendet, diese Interpretation wohl zulassen?

Falsch erkannter Schalter:
[code2016.11.09 22:16:53 1: EnOcean Unknown device with SenderID 002CCF7D and switch telegram, please define it.
2016.11.09 22:16:53 2: autocreate: define EnO_002CCF7D EnOcean 002CCF7D EnOcean:1:F6:10:002CCF7D:20:03FFFFFFFF4F00
2016.11.09 22:16:53 2: EnOcean define EnO_002CCF7D EnOcean 002CCF7D EnOcean:1:F6:10:002CCF7D:20:03FFFFFFFF4F00
2016.11.09 22:16:53 2: EnOcean define FileLog_EnO_002CCF7D FileLog ./log/EnO_002CCF7D-%Y-%m-%d.log EnO_002CCF7D
2016.11.09 22:16:53 2: EnOcean EnO_002CCF7D teach-in EEP F6-10-00 Manufacturer: no ID
2016.11.09 22:16:53 2: EnOcean define SVG_EnO_002CCF7D SVG FileLog_EnO_002CCF7D:EnO_windowHandle:CURRENT[/code]

Korrekt erkannter Schalter:

Code Auswählen

2016.11.09 22:17:13 1: EnOcean Unknown device with SenderID 002CCF51 and switch telegram, please define it.
2016.11.09 22:17:13 2: autocreate: define EnO_002CCF51 EnOcean 002CCF51 EnOcean:1:F6:30:002CCF51:30:03FFFFFFFF4F00
2016.11.09 22:17:13 2: EnOcean define EnO_002CCF51 EnOcean 002CCF51 EnOcean:1:F6:30:002CCF51:30:03FFFFFFFF4F00
2016.11.09 22:17:13 2: EnOcean define FileLog_EnO_002CCF51 FileLog ./log/EnO_002CCF51-%Y-%m-%d.log EnO_002CCF51
2016.11.09 22:17:13 2: EnOcean EnO_002CCF51 teach-in EEP F6-02-01 Manufacturer: no ID

Hier noch mal der Unterschied in den Data-Packets der "switch telegrams" der beiden Schalter:
EnOcean:1:F6:10002CCF7D:20:03FFFFFFFF4F00 (EEP F6-10-00: WindowHandle)
EnOcean:1:F6:30002CCF51:30:03FFFFFFFF4F00 (EEP F6-02-01: Switch)

Vielleicht kann ein EnOcean-Fachmann erkennen, wo das Problem liegt?

Hermann

klaus.schauer · 10 November 2016, 06:41:42

Beim RPS teach-in kann es protokollbedingt in Einzelfällen zu Fehlern kommen. Da hilft dann nur die manuelle Umstellung der subType-Definition.

hermi · 10 November 2016, 08:14:52

Hallo Klaus, ich kann Entwarnung geben:

Dummerweise hatte ich bei dem "problematischen" Schalter die Schalterwippe nicht aufgesteckt, sondern das PTM210-Modul nackt betrieben. Das Problem war, dass die Schalterwippe (neben den vier großen Noppen für die eigentlichen Schalter) zwei kleine Noppen hat, welche die kleinen Schaltelemente auf der Oberseite des PTM210-Moduls herunterdrücken und damit die Switch-Funktion der entsprechenden Schalterseite aktivieren.
Wenn diese kleinen Schaltelemente nicht gerückt sind, sendet das PTM210-Modul das "switch telegram" mit gelöschtem NU-Flag im Status-Byte (deshalb 20 anstelle 30). Das führt dann dazu, dass aus dem Switch ein WindowHandle wird.

hermi · 19 November 2016, 18:33:53

Hallo Rudolf,

ich habe jetzt die culfw so abgeändert, dass sie sich rückwärtskompatibel zur aktuellen Version 1.66 verhalten sollte.

Dazu stelle ich bei einem TCM in 16_STACKABLE_CC.pm anstelle des '*' ein 'y' vor die zu übertragenden Daten:

Code Auswählen


sub
STACKABLE_CC_Write($$)
{
  my ($hash,$fn,$msg) = @_;

  ($fn, $msg) = CUL_WriteTranslate($hash, $fn, $msg);
  return if(!defined($fn));
  if($hash->{TCM}) {
    IOWrite($hash, "", "y$fn$msg"); # No more translations
  } else {
    IOWrite($hash, "", "*$fn$msg"); # No more translations
  }
}

Eigentlich wollte ich ein '%' oder ein anderes Sonderzeichen für diese Kennung nehmen, aber im folgenden culfw Code-Abschnitt der SCC.c funktionierten diese Sonderzeichen nicht (keine Ahnung weshalb, habe es zugegebenermaßen aber auch nur oberflächlich untersucht):

Code Auswählen


const PROGMEM t_fntab fntab[] = {
-- snip --
#ifdef HAS_FASTRF
  { 'f', fastrf_func },
#endif
#ifdef HAS_STACKING
  { '*', stacking_func },
#ifdef HAS_STACK_ENOCEAN  
  { 'y', stacking_func_eno },
#endif
#endif
  { 'l', ledfunc },
  { 't', gettime },
-- snip --
  { 0, 0 },
};

Die Funktion stacking_func_eno() stellt bei ihrem erstmaligen Aufruf die Baudrate der Schnittstelle auf 57600Bd und gibt dann die Hex-Daten als Bin-Daten an das EnOcean-Board weiter.

Meine Frage ist nun, weshalb ich für die Kennung keine Sonderzeichen nutzen kann?

Gruß,
Hermann

Ach ja: irgendjemand sollte meine Änderungen an der culfw natürlich auch mal anschauen

rudolfkoenig · 20 November 2016, 13:44:53

Hallo Hermann,

ZitatMeine Frage ist nun, weshalb ich für die Kennung keine Sonderzeichen nutzen kann?

ein % wuerde mir auch besser gefallen, und ich verstehe es nicht, wieso es nicht tut.
Ausgewertet wird fntab in clib/ttydata.c/callfn, und ich sehe da keinen Grund. Koenntest due mit etwas debugging es untesuchen?

ZitatAch ja: irgendjemand sollte meine Änderungen an der culfw natürlich auch mal anschauen

Dazu muesste man wissen, wo die sind.

hermi · 20 November 2016, 17:32:08

Zitatein % wuerde mir auch besser gefallen, und ich verstehe es nicht, wieso es nicht tut.
Ausgewertet wird fntab in clib/ttydata.c/callfn, und ich sehe da keinen Grund. Koenntest due mit etwas debugging es untesuchen?

Ich hatte gehofft, Du hättest sofort ne Idee, aber ich schaue mal, wie ich ein paar Debug-Messages zum Pi versenden und anzeigen kann...

Zitat
ZitatAch ja: irgendjemand sollte meine Änderungen an der culfw natürlich auch mal anschauen
Dazu muesste man wissen, wo die sind.

Logo, aber ich hatte zunächst ja nur nach Freiwilligen gesucht

Ich habe den Code eben auf github gepushed: https://github.com/HermiU/culfw/commit/d834ff0050944ff45da86d513129e2035df21820

hermi · 26 November 2016, 17:03:19

Ich komme mit den zusätzlichen Debug-Ausgaben, die ich eingebaut habe, leider nicht weiter.
Fakt ist, dass auch die CUL-Kommunikation klemmt, wenn ich ein Sonderzeichen in der Kommandoliste (fntab) benutze, wenn ich z.B. eine '0' benutze (oder andere alphanumerische Zeichen), dann ist alles in Ordnung.

Hier der Auszug des Log-Files, wenn ich eine '0' in die Kommandoliste (fntab) aufnehme:

Code Auswählen


2016.11.26 16:36:03 5: Cmd: >define SCC_0 CUL /dev/ttyAMA0@38400 1034<
2016.11.26 16:36:03 5: Loading ./FHEM/00_CUL.pm
2016.11.26 16:36:03 3: Opening SCC_0 device /dev/ttyAMA0
2016.11.26 16:36:03 3: Setting SCC_0 serial parameters to 38400,8,N,1
2016.11.26 16:36:03 5: SW: V
2016.11.26 16:36:03 5: CUL/RAW (ReadAnswer): V 1.67 CSM868

2016.11.26 16:36:03 5: SW: ?
2016.11.26 16:36:03 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of m B
2016.11.26 16:36:03 5: CUL/RAW (ReadAnswer): b C F i
2016.11.26 16:36:03 5: CUL/RAW (ReadAnswer): A Z G M
2016.11.26 16:36:03 5: CUL/RAW (ReadAnswer): Y R T V
2016.11.26 16:36:03 5: CUL/RAW (ReadAnswer): W X e f
2016.11.26 16:36:03 5: CUL/RAW (ReadAnswer): * 0 l t
2016.11.26 16:36:03 5: CUL/RAW (ReadAnswer): u x z

2016.11.26 16:36:03 3: SCC_0: Possible commands: mBbCFiAZGMYRTVWXef*0ltuxz
2016.11.26 16:36:03 5: SW: X21
2016.11.26 16:36:03 5: SW: T01
2016.11.26 16:36:03 5: CUL/RAW (ReadAnswer): 1034

2016.11.26 16:36:03 5: GOT CUL fhtid: 1034
2016.11.26 16:36:03 3: SCC_0 device opened
2016.11.26 16:36:03 5: Cmd: >attr SCC_0 group CUL<
2016.11.26 16:36:03 5: Cmd: >attr SCC_0 model CUL<
2016.11.26 16:36:03 5: Cmd: >attr SCC_0 rfmode MAX<
2016.11.26 16:36:03 5: SW: Ax
2016.11.26 16:36:03 5: SW: X21
2016.11.26 16:36:03 5: SW: Zr
2016.11.26 16:36:03 2: Switched SCC_0 rfmode to MAX
2016.11.26 16:36:03 5: Cmd: >attr SCC_0 room System<
2016.11.26 16:36:03 5: Cmd: >attr SCC_0 verbose 5<
2016.11.26 16:36:03 5: Cmd: >define cm CUL_MAX 123456<
2016.11.26 16:36:03 5: Loading ./FHEM/14_CUL_MAX.pm
2016.11.26 16:36:03 3: CUL_MAX_Check: Detected firmware version 167 of the CUL-compatible IODev
2016.11.26 16:36:03 5: SCC_0 sending Za123456
2016.11.26 16:36:03 5: SW: Za123456
2016.11.26 16:36:03 5: SCC_0 sending Zw111111
2016.11.26 16:36:03 5: SW: Zw111111
2016.11.26 16:36:04 5: Cmd: >attr cm IODev SCC_0<
2016.11.26 16:36:04 5: Cmd: >attr cm verbose 5<

---- snip ----

2016.11.26 16:36:34 5: CUL_MAX_Send: enqueuing 0f6504031234561622dc00101a10a4e2
2016.11.26 16:36:34 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.11.26 16:36:34 5: SW: X
2016.11.26 16:36:34 5: CUL/RAW (ReadAnswer): 21  482

2016.11.26 16:36:34 5: Triggering SCC_0 (1 changes)
2016.11.26 16:36:34 5: Starting notify loop for SCC_0, first event credit10ms: 482
2016.11.26 16:36:34 5: needPreamble: 1, necessaryCredit: 113, credit10ms: 482
2016.11.26 16:36:34 5: Updating TimeInformation payload
2016.11.26 16:36:34 5: SCC_0 sending Zs0f6504031234561622dc00101a10a4e2
2016.11.26 16:36:34 5: SW: Zs0f6504031234561622dc00101a10a4e2
2016.11.26 16:36:34 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.11.26 16:36:35 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.11.26 16:36:35 5: CUL/RAW: /Z0E65020
2016.11.26 16:36:35 5: CUL/RAW: Z0E65020/21622DC1
2016.11.26 16:36:35 5: CUL/RAW: Z0E6502021622DC1/23456000
2016.11.26 16:36:35 5: CUL/RAW: Z0E6502021622DC123456000/119002A0
2016.11.26 16:36:35 5: CUL/RAW: Z0E6502021622DC123456000119002A0/D

2016.11.26 16:36:35 4: CUL_Parse: SCC_0 Z0E6502021622DC123456000119002A0D -67.5
2016.11.26 16:36:35 5: SCC_0 dispatch Z0E6502021622DC123456000119002A
2016.11.26 16:36:35 5: CUL_MAX_Parse: len 14, msgcnt 65, msgflag 02, msgTypeRaw Ack, src 1622dc, dst 123456, groupid 0, payload 0119002A
2016.11.26 16:36:35 5: CUL_MAX_Parse: rssi: -67.5
2016.11.26 16:36:35 5: cm dispatch MAX,1,Ack,1622dc,0119002A
2016.11.26 16:36:35 5: MAX_Parse MAX,1,Ack,1622dc,0119002A
2016.11.26 16:36:35 5: MAX_Parse MAX,1,ThermostatState,1622dc,19002A
2016.11.26 16:36:35 5: battery 0, rferror 0, panel 0, langateway 1, dstsetting 1, mode 1, valveposition 0 %, desiredTemperature 21, until , curTemp
2016.11.26 16:36:35 5: Triggering MAX_1622dc (6 changes)
2016.11.26 16:36:35 5: Starting notify loop for MAX_1622dc, first event mode: manual
2016.11.26 16:36:35 5: Got matching ack
2016.11.26 16:36:35 5: CUL_MAX_SendQueueHandler: 1 items in queue

Hier der Auszug des Log-Files, wenn ich ein '+' in die Kommandoliste (fntab) aufnehme:

Code Auswählen


2016.11.26 16:34:50 5: Cmd: >define SCC_0 CUL /dev/ttyAMA0@38400 1034<
2016.11.26 16:34:50 5: Loading ./FHEM/00_CUL.pm
2016.11.26 16:34:50 3: Opening SCC_0 device /dev/ttyAMA0
2016.11.26 16:34:50 3: Setting SCC_0 serial parameters to 38400,8,N,1
2016.11.26 16:34:50 5: SW: V
2016.11.26 16:34:50 5: CUL/RAW (ReadAnswer): V 1.67 CSM868

2016.11.26 16:34:50 5: SW: ?
2016.11.26 16:34:50 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of m B
2016.11.26 16:34:50 5: CUL/RAW (ReadAnswer): b C F i
2016.11.26 16:34:50 5: CUL/RAW (ReadAnswer): A Z G M
2016.11.26 16:34:50 5: CUL/RAW (ReadAnswer): Y R T V
2016.11.26 16:34:50 5: CUL/RAW (ReadAnswer): W X e f
2016.11.26 16:34:50 5: CUL/RAW (ReadAnswer): * + l t
2016.11.26 16:34:50 5: CUL/RAW (ReadAnswer): u x z

2016.11.26 16:34:53 1: /dev/ttyAMA0 disconnected, waiting to reappear (SCC_0)
2016.11.26 16:34:53 5: Triggering SCC_0 (1 changes)
2016.11.26 16:34:53 5: Starting notify loop for SCC_0, first event DISCONNECTED
2016.11.26 16:34:53 3: SCC_0: Possible commands: Noanswer
2016.11.26 16:34:53 5: SW: X21
2016.11.26 16:34:53 5: SW: T01
2016.11.26 16:34:53 5: Cmd: >attr SCC_0 group CUL<
2016.11.26 16:34:53 5: Cmd: >attr SCC_0 model CUL<
2016.11.26 16:34:53 5: Cmd: >attr SCC_0 rfmode MAX<
2016.11.26 16:34:53 5: SW: X21
2016.11.26 16:34:53 5: SW: Zr
2016.11.26 16:34:53 2: Switched SCC_0 rfmode to MAX
2016.11.26 16:34:53 5: Cmd: >attr SCC_0 room System<
2016.11.26 16:34:53 5: Cmd: >attr SCC_0 verbose 5<
2016.11.26 16:34:53 5: Cmd: >define cm CUL_MAX 123456<
2016.11.26 16:34:53 5: Loading ./FHEM/14_CUL_MAX.pm
2016.11.26 16:34:53 3: CUL_MAX_Check: Detected firmware version 167 of the CUL-compatible IODev
2016.11.26 16:34:53 5: SCC_0 sending Za123456
2016.11.26 16:34:53 5: SW: Za123456
2016.11.26 16:34:54 5: SCC_0 sending Zw111111
2016.11.26 16:34:54 5: SW: Zw111111
2016.11.26 16:34:54 5: Cmd: >attr cm IODev SCC_0<
2016.11.26 16:34:54 5: Cmd: >attr cm verbose 5<

---- snip ----

2016.11.26 16:35:01 3: Setting SCC_0 serial parameters to 38400,8,N,1
2016.11.26 16:35:01 5: SW: V
2016.11.26 16:35:01 5: CUL/RAW (ReadAnswer): V 1.67 CSM868
                         
2016.11.26 16:35:01 5: SW: ?
2016.11.26 16:35:01 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of m B
2016.11.26 16:35:01 5: CUL/RAW (ReadAnswer): b C F i
2016.11.26 16:35:01 5: CUL/RAW (ReadAnswer): A Z G M
2016.11.26 16:35:01 5: CUL/RAW (ReadAnswer): Y R T V
2016.11.26 16:35:01 5: CUL/RAW (ReadAnswer): W X e f
2016.11.26 16:35:01 5: CUL/RAW (ReadAnswer): * + l t
2016.11.26 16:35:01 5: CUL/RAW (ReadAnswer): u x z
                      
2016.11.26 16:35:01 4: CUL_Parse: SCC_0 ? (? is unknown) Use one of m B b C F i A Z G M Y R T V W X e f * + l t u x z
2016.11.26 16:35:01 5: Triggering SCC_0 (1 changes)
2016.11.26 16:35:01 5: Starting notify loop for SCC_0, first event UNKNOWNCODE ? (? is unknown) Use one of m B b C F i A Z G M Y R T V W X e f * + l t u x
2016.11.26 16:35:01 2: SCC_0: unknown message ? (? is unknown) Use one of m B b C F i A Z G M Y R T V W X e f * + l t u x z
2016.11.26 16:35:04 1: /dev/ttyAMA0 disconnected, waiting to reappear (SCC_0)
2016.11.26 16:35:04 5: Triggering SCC_0 (1 changes)
2016.11.26 16:35:04 5: Starting notify loop for SCC_0, first event DISCONNECTED
2016.11.26 16:35:04 5: Triggering SCC_0 (1 changes)
2016.11.26 16:35:04 5: Starting notify loop for SCC_0, first event cmds: No answer
2016.11.26 16:35:04 3: SCC_0: Possible commands: Noanswer
2016.11.26 16:35:04 5: SW: X21
2016.11.26 16:35:04 5: SW: Zr
2016.11.26 16:35:04 5: SW: Za123456
2016.11.26 16:35:04 5: SW: Zw111111
2016.11.26 16:35:04 5: SW: T01

Man sieht, dass das 'V'-Kommando funktioniert, nach der Abfrage der möglichen Kommandos aber etwas klemmt.

Ich habe im Moment keine Idee, an welcher Stelle ich noch ansetzen könnte und befürchte, ohne ein Remote-Debugging (JTAG) kommt man hier nicht weiter

Nachtrag: das "EnOCean Pi"-Modul hatte ich bei der Aufnahme der Log deaktiviert (es gibt *kein* "define TCM_CC STACKABLE_CC SCC_0 TCM").