FHEM Forum

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!

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.

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.

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

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:
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.

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

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  ;D

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!  8)

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:
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:
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

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.

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 (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:
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

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

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.

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:

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):

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 :-)

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.

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

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:

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:

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").

Wahrscheinlich lag es an der strengen Pruefung de moeglichen Befehle in 00_CUL.pm (such nach cmds).
Ich habe die erlaubte Menge erweitert, und (damit ich ohne SCC testen kann) auch 16_STACKABLE_CC.pm etwas angepasst.

Die Tücken stecken doch immer im Detail ;-)
Ich denke, so passt es, zumindest bei mir funktioniert es.

Folgende Anpassung ist dafür noch in 16_STACKABLE_CC.pm in der Funktion STACKABLE_CC_Write() nötig:

-  IOWrite($hash, "", "*$fn$msg"); # No more translations
+  if($hash->{TCM}) {
+  IOWrite($hash, "", "%$fn$msg"); # No more translations
+  } else {
+    IOWrite($hash, "", "*$fn$msg"); # No more translations
+  }


Ich konnte die ganze Sache nur mit einem Stackable CC testen, in wieweit das mit mehreren gestackten CCs funktioniert ist noch unklar.

Auch in der culfw ist noch eine Frage bezüglich der TTY_BUFSIZE offen, und auch die "SYNC-Statemachine" muss ich noch vollständig testen (komme wohl erst nächstes Wochenende dazu).

Habe die Aenderungen eingecheckt.

Habe ein paar Tests mit der Statemachine in stacking.c gemacht, und sie scheint so zu funktionieren, wie ich es mir vorgestellt habe :-)

Wenn die Vergrößerung der TTY_BUFFSIZE (in board.h) von 128 auf 512 in Ordnung geht, dann wäre die Anpassung der culfw aus meiner Sicht abgeschlossen.

Ich betreibe immer noch etliche CUL_V2 mit der at90usb162 und 512Byte(!) RAM. Nachdem ich dein Plan gelesen habe, bin ich erstmal ohnmaechtig umgefallen :) Die atmega1284p der SCC scheint aber unfassbare 16kB RAM zu haben, das sollte fuer TTY_BUFSIZE 512 reichen. Und irgendwer hat auch ringbuffer.h gepatcht (uint8_t vs. uint16_t), also wurde das scheinbar auch getestet.

Nee nee, ich wollte niemandem einen Herzkasper zufügen, weshalb ich mir vorher das Datenblatt des ATmega1284P angeschaut habe. Ich hab früher diverse 8051-Derivate (anfänlich mit üppigen 128 Byte RAM) programmiert, deshalb war ich mir möglicher Einschränkungen bewusst ;-)

Zur Not hätte man die 512 Byte nur definieren können, wenn HAS_STACK_ENOCEAN definiert ist, denn normalerweise würden 256 Byte (sizeof(mycmd)) ja genügen.

Deshalb noch die (hoffentlich letzte Frage: ist eine Größe von 256 Byte für mycmd[] (in stacking.c) ausreichend? Das EnOcean-Protokoll lässt deutlich mehr Payload zu (theoretisch bis 64 kByte).

Und abschließend:
Soll ich von den Commits  d834ff0, 39b5a07 und 4a75818 aus https://github.com/HermiU/culfw/commits/EnOcean als Patch zur Verfügung stellen?

Zitatist eine Größe von 256 Byte für mycmd[] (in stacking.c) ausreichend?

Keine Ahunng, muss ein EnOcean Kenner beantworten.

ZitatSoll ich ... als Patch zur Verfügung stellen?

Gerne.

Ich habe eben mal das Dokument "EnOcean_Equipment_Profiles_EEP_v2.6.5_public.pdf" (http://www.enocean-alliance.org/eep/) überflogen, und wie es aussieht werden im Moment maximal 14 Byte im Datenbereich des Pakets übertragen. So gesehen sollten die 256 Byte locker reichen. (Ein EnOcean-Kenner möge mich korrigieren, wenn ich groben Unfug erzähle :-) )

Im Anhang die Patches.

Danke, habs eingecheckt.

@hermi: koenntest Du bitte dein TCM mit dem neuen 16_STACKABLE.pm Modul testen?

Ich sehe dieses Modul als den Nachfolger von 16_STACKABLE_CC, da es generischer ist. Es sollte in deinem Fall keine Nachteile haben, aber die DISCONNECT / CONNECT Meldungen an das TCM Modul zwecks Reinitialisierung weiterreichen.

Ich gehe davon aus, dass Du folgende Deifnition benutzen kannst:

define CUL_1 CUL /dev/ttyAMA0@38400 1034
define TCM_CC STACKABLE CUL_1
attr TCM_CC binary
define TCM_0 TCM 310 FHEM:DEVIO:TCM_CC:57600

Ja, kann ich machen, allerdings erst am Wochenende, hab im Moment recht viel um die Ohren.
Melde mich, wenn ich Ergebnisse vorweisen kann.

Hallo Rudolf,

ich kam leider erst jetzt dazu.

Habe FHEM aktualisiert (Update) und dann meine TCM-Konfiguration mit STACKABLE_CC durch die neue ersetzt. Hier der Auszug aus dem Logfile:

2017.04.02 17:08:13 1: Including /opt/fhem/mycfg/01_scc.cfg
2017.04.02 17:08:13 2: Switched SCC_0 rfmode to MAX
2017.04.02 17:08:14 1: Including /opt/fhem/mycfg/01_tcm.cfg
2017.04.02 17:08:14 1: CUL_1: Cannot define multiple CULs with identical first two digits (10)
2017.04.02 17:08:14 1: define CUL_1 CUL /dev/ttyAMA0@38400 1034: CUL_1: Cannot define multiple CULs with identical first two digits (10)
2017.04.02 17:08:14 1: define TCM_CC STACKABLE CUL_1: CUL_1 is not a valid device


Zitatmeine TCM-Konfiguration mit STACKABLE_CC durch die neue ersetzt.

Ich mag das auch falsch interpretieren, aber die Aenderung ist nicht  "STACKABLE_CC durch STACKABLE zu ersetzen", sondern
"STACKABLE_CC durch STACKABLE+CUL oder STACKABLE+TCM ersetzen"

ZitatCUL_1: Cannot define multiple CULs with identical first two digits (10)

Eigentlich ist die Fehlermeldung richtig, man sollte sowas nicht machen :) Es sei denn, die beiden Ziffer sind 00.


Kannst du mir bitte alle CUL, STACKABLE und TCM Definitionen (samt Attributen) in der neuen Variante zeigen?

Öhmm, ja... manchmal sollte man vielleicht auch ein wenig nachdenken und nicht einfach Copy&Paste machen. Zwei mal /dev/ttyAMA0@38400 in der Konfiguration hätte einen stutzig machen können  ;-)

Allerdings muss ich zugeben, dass ich in diesen Konfigurationsdingen nicht wirklich fit bin (und ich mir bislang nicht die Mühe gemacht habe, tiefer einzusteigen  :-[ ).

Die falsche Konfiguration sah so aus:

# 01_scc.cfg:
define SCC_0 CUL /dev/ttyAMA0@38400 1034
attr SCC_0 group CUL
attr SCC_0 model CUL
attr SCC_0 rfmode MAX
attr SCC_0 verbose 2

define cm CUL_MAX 123456
attr cm IODev SCC_0
attr cm verbose 2

# 01_tcm.cfg:
# with 16_STACKABLE_CC.pm
#
#define TCM_CC STACKABLE_CC SCC_0 TCM
#attr TCM_CC verbose 2
#define TCM_0 TCM 310 FHEM:DEVIO:TCM_CC:57600
#attr TCM_0 sendInterval 0
#attr TCM_0 smartAckMailboxMax 0
#attr TCM_0 verbose 2

# with 16_STACKABLE.pm
#
define CUL_1 CUL /dev/ttyAMA0@38400 1034
define TCM_CC STACKABLE CUL_1
attr TCM_CC binary
define TCM_0 TCM 310 FHEM:DEVIO:TCM_CC:57600
attr TCM_0 sendInterval 0
attr TCM_0 smartAckMailboxMax 0
attr TCM_0 verbose 2


Ich habe versucht, es richtig zu machen:

# 01_scc.cfg:
define CUL_1 CUL /dev/ttyAMA0@38400 1034

define SCC_0 STACKABLE CUL_1
attr SCC_0 group CUL
attr SCC_0 model CUL
attr SCC_0 rfmode MAX
attr SCC_0 verbose 2

define cm CUL_MAX 123456
attr cm IODev SCC_0
attr cm verbose 2

# 01_tcm.cfg:
# with 16_STACKABLE.pm
#
define TCM_CC STACKABLE CUL_1
attr TCM_CC binary
define TCM_0 TCM 310 FHEM:DEVIO:TCM_CC:57600
attr TCM_0 sendInterval 0
attr TCM_0 smartAckMailboxMax 0
attr TCM_0 verbose 2


Es ist aber beim Versuch geblieben (das Log sieht nur etwas ander aus):

2017.04.03 20:00:17 1: Including /opt/fhem/mycfg/00_config.cfg
2017.04.03 20:00:17 1: Including /opt/fhem/mycfg/01_scc.cfg
2017.04.03 20:00:17 1: cm: did not find suitable IODev (CUL etc. in rfmode MAX)! You may want to execute 'attr cm IODev SomeCUL'
2017.04.03 20:00:17 1: Including /opt/fhem/mycfg/01_tcm.cfg
2017.04.03 20:00:17 1: define TCM_CC STACKABLE CUL_1: CUL_1 already has a stacked device: SCC_0
2017.04.03 20:00:17 1: Including /opt/fhem/mycfg/01_hue.cfg
2017.04.03 20:00:18 2: EnOcean Cryptographic functions are not available.
2017.04.03 20:00:18 1: Including /opt/fhem/mycfg/50_Pioneer.cfg
2017.04.03 20:01:00 1: Including ./log/fhem.save
2017.04.03 20:01:00 1: configfile: SCC_0: unknown attribute model. Type 'attr SCC_0 ?' for a detailed list.
SCC_0: unknown attribute rfmode. Type 'attr SCC_0 ?' for a detailed list.
CUL_1 already has a stacked device: SCC_0

2017.04.03 20:01:05 2: TCM TCM_0 not initialized


Nach dem Sport hab ich mich noch mal an den Rechner gesetzt, anscheinen war der Kopf jetzt etwas freier :-)

Meine letzte Nachricht einfach mal ignorieren, mit dieser Konfiguration funktioniert es schon besser:

define CUL_1 CUL /dev/ttyAMA0@38400 1034
attr CUL_1 rfmode MAX
attr CUL_1 group CUL
attr CUL_1 model CUL
attr CUL_1 verbose 2

define cm CUL_MAX 123456
attr cm IODev CUL_1
attr cm verbose 2


define TCM_CC STACKABLE CUL_1
attr TCM_CC binary

define TCM_0 TCM 310 FHEM:DEVIO:TCM_CC:57600
attr TCM_0 sendInterval 0
attr TCM_0 smartAckMailboxMax 0
attr TCM_0 verbose 2


Allerdings hab noch folgend Log-Einträge:

2017.04.03 23:49:03 2: TCM TCM_0 set reset: Bogus answer received: 0C1004420311FB1622DC0024D31C30E1002021622DC0311FB0001190024150
2017.04.03 23:49:05 2: TCM TCM_0 Timeout reading response for get baseID
2017.04.03 23:49:07 2: TCM TCM_0 Timeout reading response for get version
2017.04.03 23:49:09 2: TCM TCM_0 Timeout reading response for set mode
2017.04.03 23:49:11 2: TCM TCM_0 Timeout reading response for set smartAckMailboxMax
2017.04.03 23:49:11 2: TCM TCM_0 smartAckMailboxMax 0 restored
2017.04.03 23:49:13 2: TCM TCM_0 Timeout reading response for set repeater
2017.04.03 23:49:15 2: TCM TCM_0 Timeout reading response for set maturity
2017.04.03 23:49:15 2: TCM TCM_0 initialized


So sahen die alten (korrekten) Log-Einträge aus:

2017.04.01 20:17:36 2: TCM TCM_0 RESPONSE: OK
2017.04.01 20:17:36 2: TCM TCM_0 RESPONSE: BaseID: FFA27300 RemainingWriteCycles: 0A
2017.04.01 20:17:36 2: TCM TCM_0 RESPONSE: APIVersion: 02050000 APPVersion: 020A0000 ChipID: 019944E6 ChipVersion: 454F0103 Desc: GATEWAYCTRL
2017.04.01 20:17:36 2: TCM TCM_0 RESPONSE: OK
2017.04.01 20:17:36 2: TCM TCM_0 repeater 0000 restored
2017.04.01 20:17:36 2: TCM TCM_0 RESPONSE: OK
2017.04.01 20:17:36 2: TCM TCM_0 maturity 01 restored
2017.04.01 20:17:36 2: TCM TCM_0 RESPONSE: NOT_SUPPORTED
2017.04.01 20:17:36 2: TCM TCM_0 RESPONSE: OK
2017.04.01 20:17:36 2: TCM TCM_0 smartAckMailboxMax 0 restored
2017.04.01 20:17:36 2: TCM TCM_0 initialized


Kannst du mir bitte in den beiden Faellen einen Log-Mitschnitt mit "attr CUL_1 verbose 5" erstellen?

Hier das Log beim Start (habe TCM_CC und TCM_0 auch auf "verbose 5" gestellt):

2017.04.04 20:05:50 3: TCM set TCM_0 reset
2017.04.04 20:05:50 5: TCM TCM_0 sent ESP: 550001000570020E
2017.04.04 20:05:50 5: SW: 550001000570020E
2017.04.04 20:05:50 5: CUL_1 sending *550001000570020e
2017.04.04 20:05:50 5: SW: *550001000570020e
2017.04.04 20:05:50 5: TCM TCM_0 received ESP: 0C7F04421590541622A4002ADEFC30E7F02021622A4159054000119002A010
2017.04.04 20:05:50 2: TCM TCM_0 set reset: Bogus answer received: 0C7F04421590541622A4002ADEFC30E7F02021622A4159054000119002A010
2017.04.04 20:05:51 3: TCM get TCM_0 baseID
2017.04.04 20:05:51 5: TCM TCM_0 sent ESP: 5500010005700838
2017.04.04 20:05:51 5: SW: 5500010005700838
2017.04.04 20:05:51 5: CUL_1 sending *5500010005700838
2017.04.04 20:05:51 5: SW: *5500010005700838
2017.04.04 20:05:53 2: TCM TCM_0 Timeout reading response for get baseID
2017.04.04 20:05:53 3: TCM get TCM_0 version
2017.04.04 20:05:53 5: TCM TCM_0 sent ESP: 5500010005700309
2017.04.04 20:05:53 5: SW: 5500010005700309
2017.04.04 20:05:53 5: CUL_1 sending *5500010005700309
2017.04.04 20:05:53 5: SW: *5500010005700309
2017.04.04 20:05:55 2: TCM TCM_0 Timeout reading response for get version
2017.04.04 20:05:55 3: TCM set TCM_0 maturity 01
2017.04.04 20:05:55 5: TCM TCM_0 sent ESP: 5500020005CD100150
2017.04.04 20:05:55 5: SW: 5500020005CD100150
2017.04.04 20:05:55 5: CUL_1 sending *5500020005cd100150
2017.04.04 20:05:55 5: SW: *5500020005cd100150
2017.04.04 20:05:57 2: TCM TCM_0 Timeout reading response for set maturity
2017.04.04 20:05:57 3: TCM set TCM_0 repeater 0000
2017.04.04 20:05:57 5: TCM TCM_0 sent ESP: 5500030005A60900003A
2017.04.04 20:05:57 5: SW: 5500030005A60900003A
2017.04.04 20:05:57 5: CUL_1 sending *5500030005a60900003a
2017.04.04 20:05:57 5: SW: *5500030005a60900003a
2017.04.04 20:05:59 2: TCM TCM_0 Timeout reading response for set repeater
2017.04.04 20:05:59 3: TCM set TCM_0 smartAckMailboxMax 0
2017.04.04 20:05:59 5: TCM TCM_0 sent ESP: 5500020006C40800A8
2017.04.04 20:05:59 5: SW: 5500020006C40800A8
2017.04.04 20:05:59 5: CUL_1 sending *5500020006c40800a8
2017.04.04 20:05:59 5: SW: *5500020006c40800a8
2017.04.04 20:06:01 2: TCM TCM_0 Timeout reading response for set smartAckMailboxMax
2017.04.04 20:06:01 2: TCM TCM_0 smartAckMailboxMax 0 restored
2017.04.04 20:06:01 3: TCM set TCM_0 mode 00
2017.04.04 20:06:01 5: TCM TCM_0 sent ESP: 5500020005CD1C00AB
2017.04.04 20:06:01 5: SW: 5500020005CD1C00AB
2017.04.04 20:06:01 5: CUL_1 sending *5500020005cd1c00ab
2017.04.04 20:06:01 5: SW: *5500020005cd1c00ab
2017.04.04 20:06:03 2: TCM TCM_0 Timeout reading response for set mode
2017.04.04 20:06:03 2: TCM TCM_0 initialized


Interessanterweise funktionieren meine EnOcean Taster.
Das Log zeigt ein Drücken eines Tasters:

2017.04.04 20:08:48 5: CUL/RAW: /*5500070
2017.04.04 20:08:48 5: CUL/RAW: *5500070/7017AF61
2017.04.04 20:08:48 5: CUL/RAW: *55000707017AF61/0002CCF7
2017.04.04 20:08:48 5: CUL/RAW: *55000707017AF610002CCF7/D3003FFF
2017.04.04 20:08:48 5: CUL/RAW: *55000707017AF610002CCF7D3003FFF/FFFFF3C0
2017.04.04 20:08:48 5: CUL/RAW: *55000707017AF610002CCF7D3003FFFFFFFF3C0/0F9

2017.04.04 20:08:48 4: CUL_Parse: CUL_1 *55000707017AF610002CCF7D3003FFFFFFFF3C00F9
2017.04.04 20:08:48 5: CUL_1: dispatch *55000707017AF610002CCF7D3003FFFFFFFF3C00F9
2017.04.04 20:08:48 5: TCM TCM_0 received ESP: 55000707017AF610002CCF7D3003FFFFFFFF3C00F9
2017.04.04 20:08:48 5: TCM_0: dispatch EnOcean:1:F6:10:002CCF7D:30:03FFFFFFFF3C00
2017.04.04 20:08:48 4: EnOcean received via TCM_0: EnOcean:1:F6:10:002CCF7D:30:03FFFFFFFF3C00
2017.04.04 20:08:48 5: CUL/RAW: /*5500070
2017.04.04 20:08:48 5: CUL/RAW: *5500070/7017AF60
2017.04.04 20:08:48 5: CUL/RAW: *55000707017AF60/0002CCF7
2017.04.04 20:08:48 5: CUL/RAW: *55000707017AF600002CCF7/D2003FFF
2017.04.04 20:08:48 5: CUL/RAW: *55000707017AF600002CCF7D2003FFF/FFFFF370
2017.04.04 20:08:48 5: CUL/RAW: *55000707017AF600002CCF7D2003FFFFFFFF370/026

2017.04.04 20:08:48 4: CUL_Parse: CUL_1 *55000707017AF600002CCF7D2003FFFFFFFF370026
2017.04.04 20:08:48 5: CUL_1: dispatch *55000707017AF600002CCF7D2003FFFFFFFF370026
2017.04.04 20:08:48 5: TCM TCM_0 received ESP: 55000707017AF600002CCF7D2003FFFFFFFF370026
2017.04.04 20:08:48 5: TCM_0: dispatch EnOcean:1:F6:00:002CCF7D:20:03FFFFFFFF3700
2017.04.04 20:08:48 4: EnOcean received via TCM_0: EnOcean:1:F6:00:002CCF7D:20:03FFFFFFFF3700


------------------------------------------
Hier das Log mit meiner ursprünglichen Konfiguration mit STACKABLE_CC:

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


Die Konfiguration dazu war:

define SCC_0 CUL /dev/ttyAMA0@38400 1034
attr SCC_0 group CUL
attr SCC_0 model CUL
attr SCC_0 rfmode MAX
attr SCC_0 verbose 5

define cm CUL_MAX 123456
attr cm IODev SCC_0
attr cm verbose 2

define TCM_CC STACKABLE_CC SCC_0 TCM
attr TCM_CC verbose 2
define TCM_0 TCM 310 FHEM:DEVIO:TCM_CC:57600
attr TCM_0 sendInterval 0
attr TCM_0 smartAckMailboxMax 0
attr TCM_0 verbose 2


Sorry, habs vergessen, dass Du auch noch ein
attr TCM_CC writePrefix %
brauchst.

ZitatInteressanterweise funktionieren meine EnOcean Taster.

Ich gehe davon aus, dass Lesen klappt, aber Schreiben nicht, s.o. Ich verstehe noch nicht, wieso beim Reset-Sequenz die vom CUL empfangenen Daten nicht gezeigt werden (CUL/RAW), nur beim spontanen Empfang.

Ja, das mit dem writePrefix hat es gebracht, es funktioniert wie gewohnt :-)

Zitat
Ich gehe davon aus, dass Lesen klappt, aber Schreiben nicht, s.o. Ich verstehe noch nicht, wieso beim Reset-Sequenz die vom CUL empfangenen Daten nicht gezeigt werden (CUL/RAW), nur beim spontanen Empfang.

Hmmm, dazu stecke ich zu wenig im Thema, als dass ich da einen intelligenten Beitrag zu leisten könnte.
Vielleicht komme ich am Wochenende ja mal dazu etwas tiefer einzusteigen und ein paar zusätzliche Debug-Loggings einzubauen. Das kann ich aber nicht 100%ig versprechen.

Muss nicht sein, hab nur "laut" nachgedacht.

Freut mich, dass es funktioniert, dann kann ich es abhaken. Danke fuer die Tests!