Enocean Pi und Stackable CC

[rudolfkoenig]

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.

[hermi]

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:

Code Auswählen Erweitern


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

[rudolfkoenig]

Habe die Aenderungen eingecheckt.

[hermi]

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.

[rudolfkoenig]

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.

[hermi]

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?

[rudolfkoenig]

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

Keine Ahunng, muss ein EnOcean Kenner beantworten.

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

Gerne.

[hermi]

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.

[rudolfkoenig]

Danke, habs eingecheckt.

[rudolfkoenig]

@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

[hermi]

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

[hermi]

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:

Code Auswählen Erweitern


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


[rudolfkoenig]

meine 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"

CUL_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?

[hermi]

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

Code Auswählen Erweitern


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

Code Auswählen Erweitern


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

Code Auswählen Erweitern


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


[hermi]

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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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