Kommunkation mit IO Devices

[rudolfkoenig]

Setzt mal fuer die unterschiedlichen SCCs auch unterschiedliche FHTIDs, und versuch diese abzufragen (get SCC raw T01) oder version, uptime, etc, um zu wissen, ob die Nachrichten korrekt weitergereicht werden.
Man koennte sich mit "screen /dev/ttyAMA0" direkt mit der untersten SCC verbinden, und die Kommandos V, *V, T01, *T01, C99, *C99, t, *t, usw durchprobieren.

[Talkabout]

Setzt mal fuer die unterschiedlichen SCCs auch unterschiedliche FHTIDs, und versuch diese abzufragen (get SCC raw T01) oder version, uptime, etc, um zu wissen, ob die Nachrichten korrekt weitergereicht werden.
Man koennte sich mit "screen /dev/ttyAMA0" direkt mit der untersten SCC verbinden, und die Kommandos V, *V, T01, *T01, C99, *C99, t, *t, usw durchprobieren.

Hallo Rudi,

die FHTIDs konnte ich nicht setzen, da es diesen Parameter für die STACKABLE_CCs nicht gibt (nur für CUL). Führe ich aber "version" auf allen aus, kommt die korrekt Firmware-Version zurück:

SCCMAX version => V 1.61 CSM868
SCCIT version => V 1.10.02 a-culfw Build: 171 (2015-10-29_21-49-43) CSM433 (F-Band: 433MHz)
SCCHomeMatic version => V 1.60 CSM868
SCC868SlowRf version => V 1.61 CSM868

Demnach scheinen die Nachrichten korrekt weitergeleitet zu werden.

Mir ist diese Logik mit den "*" noch nicht ganz klar. Ich verstehe, dass wenn eine Nachricht an ein SCC gehen soll, für jedes darunter liegende SCC ein weiteres "*" an den Anfang gestellt wird. Aber an welcher Stelle wird diese Logik dann aufgelöst, in der Firmware oder in FHEM? Da sowohl mein SCC für HomeMatic wie SlowRf die Nachrichten korrekt sendet/empfängt, vermute ich ein Problem sowohl bei der MAX-Implementierung wie auch bei Intertechno. Ich weiss halt bloß nicht, ob das Problem in FHEM oder in der Firmware liegt. Vielleicht wird es etwas klarer, wenn ich die Logik mit den "*" verstehe.

Danke!

Gruss

[Talkabout]

Meine Vermutung ist, dass die Firmware für Intertechno die vorangestellten "*" nicht korrekt auflöst, und deswegen nichts geschaltet wird, wenn der SCC nicht ganz unten liegt (was dazu führen würde, dass keine "*" vorangestellt werden). Um das zu verifizieren müsste ich aber genau wissen, ob diese Auflösung in der Firmware oder doch in FHEM stattfindet.

Gruss

[rudolfkoenig]

die FHTIDs konnte ich nicht setzen, da es diesen Parameter für die STACKABLE_CCs nicht gibt (nur für CUL).

set SCC1 raw T011234

SCCIT version => V 1.10.02 a-culfw Build: 171 (2015-10-29_21-49-43) CSM433 (F-Band: 433MHz)

Aeh: das hast du bisher verschwiegen, oder ich hatte Tomaten auf den Augen.
Bitte mit Bjoern/etc weiter debuggen, ich bin raus.

diese Auflösung in der Firmware oder doch in FHEM stattfindet.

Beides. Alle SCCs sind ueber eine bzw. die gleiche Leitung angebunden. Wenn ein SCC ein * sieht, weiss, dass die Nachricht nicht fuer ihn ist, nimmt ein * weg, und sendet es eins weiter (bzw. "hoeher"). Wenn eine Nachricht von "oben" kommt, dann wird ein * davogepackt, und nach unten weitergereicht.

Vermutlich hat Bjoern/a-culfw noch nie von einem SCC gehoert, und derjenenige, der a-culf auf SCC portiert hat, das Konzept nicht verstanden.

[Talkabout]

set SCC1 raw T011234
Aeh: das hast du bisher verschwiegen, oder ich hatte Tomaten auf den Augen.
Bitte mit Bjoern/etc weiter debuggen, ich bin raus.
Beides. Alle SCCs sind ueber eine bzw. die gleiche Leitung angebunden. Wenn ein SCC ein * sieht, weiss, dass die Nachricht nicht fuer ihn ist, nimmt ein * weg, und sendet es eins weiter (bzw. "hoeher"). Wenn eine Nachricht von "oben" kommt, dann wird ein * davogepackt, und nach unten weitergereicht.

Vermutlich hat Bjoern/a-culfw noch nie von einem SCC gehoert, und derjenenige, der a-culf auf SCC portiert hat, das Konzept nicht verstanden.

Hallo Rudi,

zuerst einmal entschuldige, ich wollte da keine Informationen zurück halten. Ich hatte das mit der alternativen Firmware in einem anderen Bereich erwähnt, in der Diskussion mit Dir nicht, sorry!

Aber wie Du hier lesen kannst:

http://forum.fhem.de/index.php/topic,35064.msg366074.html#msg366074

habe ich das Verhalten mit der Standard Firmware ebenfalls nachvollziehen können. Ich vermute daher, dass es nicht an der alternativen Firmware liegt, sondern ein grundsätzliches Problem ist.

Kannst Du mir einen Tipp geben, in welcher Datei der Firmware diese Logik abgebildet wird? Dann schaue ich da mal rein.

Danke!

Gruss

[rudolfkoenig]

Ist einfach zu finden: in culfw/Devices/SCC/SCC.c verweist '*' auf stacking_func, was in clib/stacking.c zu finden ist. Ist mWn von busware direkt, ich habe sie jetzt zum ersten mal gesehen.

[Talkabout]

Hallo Rudi,

danke für den Tip.

Ich habe jetzt mal etwas in der Firmware gegraben und dabei auch mal andere Versionen probiert. Mit der culfw in der Version 1.60

http://sourceforge.net/p/culfw/code/HEAD/tree/tags/CUL_VER_160/

funktioniert das Schalten noch problemlos. Flashe ich dann die Version 1.61

http://sourceforge.net/p/culfw/code/HEAD/tree/tags/CUL_VER_161/

schaltet nichts mehr. Ich habe dann mal nach den Unterschieden gesucht und festgestellt, dass ab der Version 1.61 die Konstante "HAS_IT" definiert ist, welche dann wiederum unter anderem in der Datei "clib/rf_receive.c" in Zeile 809 abgefragt wird. Nach dem Einfügen des Codes

reset_input();

in Zeile 824 (vor dem "return") dieser Datei geht das Schalten dann wieder. Allerdings weiss ich nicht was damit dann kaputt geht und andererseits funktioniert diese Änderung in der aktuellen culfw 1.65 nicht mehr, da die Datei ganz anders aussieht. Da ich mich in der Firmware so überhaupt nicht auskenne wäre die Frage, wer mir da weiterhelfen kann um das Problem weiter einzugrenzen und/oder zu lösen. Es scheint auf jeden Fall etwas mit der Firmware zu tun zu haben, das ist die Schlussfolgerung, die ich aus meinen Debugging-Sessions der letzten Tage ziehen konnte. Weiterhin ist damit auch die alternative Firmware ausgeschlossen, da ich hier mit der original Dateien aus dem Repository gearbeitet habe. Vielleicht fällt Dir ja noch etwas ein, was an Änderungen damals gemacht wurde, die zu meinem Problem führen könnten.

Danke!

Gruss

[rudolfkoenig]

Nach dem Einfügen des Codes
reset_input();
in Zeile 824 (vor dem "return") dieser Datei geht das Schalten dann wieder.

Schwer zu glauben. rf_receive.c ist nur fuer den Empfang zustaendig (nicht senden), und durch einfuegen dieser Zeile hast du nur den IT-Empfang unmoeglich gemacht: Falls IT erkannt wurde, dann setzt reset_input den Status wieder auf RESET, und der Automat faengt damit wieder von vorne an, und verpasst damit die Sync-Bits.

Ich kann rf_receive.c seit dem Einbau von ESA, TCM97001, REVOLT und IT leider kaum mehr verstehen: kann sein, dass ich was uebersehe.

Ist inzwischen sicher, dass * ordentlich weitergeleitet wird?

[Talkabout]

Schwer zu glauben. rf_receive.c ist nur fuer den Empfang zustaendig (nicht senden), und durch einfuegen dieser Zeile hast du nur den IT-Empfang unmoeglich gemacht: Falls IT erkannt wurde, dann setzt reset_input den Status wieder auf RESET, und der Automat faengt damit wieder von vorne an, und verpasst damit die Sync-Bits.

Ich kann rf_receive.c seit dem Einbau von ESA, TCM97001, REVOLT und IT leider kaum mehr verstehen: kann sein, dass ich was uebersehe.

Ist inzwischen sicher, dass * ordentlich weitergeleitet wird?

Hallo Rudi,

ich denke meine Änderung hat einfach irgend einen Teil, der IT-spezifisch ist, deaktiviert, und deswegen funktionierte es. Mir kam es auch komisch vor, aber so viele Änderungen gab es nicht zwischen 1.60 und 1.61.

Das "*" wird korrekt weiter geleitet. Das, was in der "CUL_SimpleWrite" raus geht, hat genau 1 "*" vorangestellt bei mir, was richtig ist.

Mein Problem ist nun, dass ich nicht weiss, wie ich weiter machen kann. Ich würde auch mein System zur Verfügung stellen zum Debugging, falls erforderlich. Entweder über VPN oder Teamviewer, allerdings weiss ich nicht, wer das weiter debuggen könnte...

Gruss

Gruss

[Talkabout]

Hallo Rudi,

ich vermute, dass Du bei dem Problem ebenfalls ratlos bist. Aktuell verwende ich einen 868 SCC zum Senden der 433 Befehle, den 433 SCC nur zum Empfang. Trotzdem ist das natürlich nicht das, was ich erreichen wollte. Falls Dir noch was einfällt, sag bitte bescheid.

Gruss

[rudolfkoenig]

Ich kann dir keine schnelle Loesung bieten.
Ich wuerde debug-Ausgbauen im Firmware einbauen, und mit einem direkten Zugang (z.Bsp. screen) versuchen das Problem zu lokalisieren. Ist sicher keine triviale Angelegenheit.