Ursprünglichen Empfangsmode nach Umschalten auf neues Protokoll wiederherstellen

[RaspII]

Hallo Freunde,
ich habe gerade erfolgreich meine Kopp Firmware für den CUL (bei mir das CCD Modul für den Raspberry Pi) via FHEM erfolgreich in Betrieb genommen.

Jetzt habe ich folgedes Problem:
In meinem System befinden sich auch Rauchmelder die über das Homematic Protokoll kommunizieren.
Sobald ich einen Kopp Befehl abschicke empfängt FHEM keine Botschaften mehr von den Rauchmeldern und zwar bis zum neu Abspeichern der Config Datei (also vermutlich neu Initialisierung des Homematic Protokolls).

Ist eigentlich auch logisch (und verwundert mich nicht wirklich), dass nachdem ich den CUL umkonfiguriert habe das alte Protokoll nicht mehr funzt. (Habe halt gehofft, dass das Betriebssystem den alten Zustand automatisch wiederherstellt).

Jetzt zur eigentliche Frage:
Stellt die culfw irgendwelche Funktionaliät (Routinen) zur Verfügung die mir dabei helfen den alten Zustand abzuspeichern und mit deren Hilfe ich nach dem Abarbeiten meiner "Kopp" Befehle den alten Zustand wiederherstellen kann?

Wär super wenn mir hier jemand einen Tipp geben kann, ansonsten muss ich mir das selbst aus den Fingern saugen (vermutlich haben Andere aber sicher auch schon umgesetzt) 

Ich freu mich über jede Antwort
Gruß
Claus

[rudolfkoenig]

Eigentlich bin ich gegen einem "Mehrfach-Protokoll" Betrieb, da es Probleme beim Entwickler verursacht (dessen Zeit ja hier im Forum kostenlos ist), um ein paar Euro wegen einem weiteren CUL beim Anwender zu sparen.

Sonst:
- nein, es gibt kein Framework zum sichern.
- wenn man weiss, welches Protokoll vorher aktiv war, kann man das auch vom FHEM-Modul aus machen, leider nicht sehr elegant, wie man das im 00_CUL.pm/CUL_Attr sieht.
- es waere praktisch culfw so umzubauen, dass es einen globale Protokollvariable bzw. einheitliche Aktivierer/Deaktivierer gibt, das wuerde den Code in CUL.pm vereinfachen. Ich habe wg. meinen oben erwaehnten Bedenken dafuer aber keine Energie investiert.

[RaspII]

Hallo Rudolf,
tja, kann ich nachvollziehen.
Werde für mich trotzdem mal versuchen ob ichs hinbekomme.
Würde mich auch bereiterklären, bei einer Überarbeitung der culfw mitzuarbeiten, falls das doch noch angegangen wird.

Vielleicht kannst Du mir noch folgende Fragen beantworten, das würde mir die nächste Schritte erleichtern:
(vielleicht gibts ja bereits Antworten auf meine Fragen und ich kann das irgendwo nachlesen)

• in der culfw gibt es ja je Device eine Initialisierungsroutine, bei mir "kopp_fc_init(void)"
  wann genau wird diese Routine angesprungen? Beim Booten der culfw oder zu einem bestimmten Zeitpunkt während dem die FHEM.CFG abgearbeitet wird?
• Wenn ich den "alten Zustand" wiederherstellen möchte macht es vermutlich keinen Sinn das ich den CC1101 in der Initroutine umkonfiguriere (da diese vermulich nur 1x angesprungen wird) sonder ich sollte das besser in der Main task (bei mir "kopp_fc_func(char *in)" erledigen und danach den Urzustand wiederherstellen?
• Gibt es bestimmte Funktionaliäten die unbeding in der Initroutine abgearbeitet werden müssen
• Denkst Du es reicht aus, wenn ich alle Register des CC1101 die ich initialisiere vorher abspeicher und nach dem Ausführen meiner "Kopp Main Task" wiederherstelle oder muss man noch dafür sorgen, dass weitere Parameter etc. neu konfiguriert werden?
• Ich muss für manche Aktionen den Watchdog bedienen (Kopp Sender senden manche Botschaften 26x hintereinander). Den Watchdog in einer Main Task bedienen ist eigentlich keine ideale Lösung. Garantiert die culfw den Devices eine bestimmte Ausführungszeit bevor der Watchdog zuschlägt (d.h. wird der Watchdog voher zu einem bestimmten Zeitpunkt getriggert?)?
• Dann noch eine letzte Frage.  Gibt es bei Euch so was wie ein Code review bevor man die Pearl Scipte oder culfw modifiziert (mein Kopp Modul steht z.B. im Branch, mein PM-Modul kann ich leider mangels Zugriffsrechten nicht ins "contribut" Verzeichnis einstellen (habe die Rechte aber schon mal angefragt)

Viele Fragen, freue mich schon auf die Antwort
Gruß
Claus

[rudolfkoenig]

- init: das steckt in Devices/CUL/CUL.c. Ist aber nicht Pflicht und manche (SlowRF) haben sowas gar nicht.
- alter Zustand: hier weiss ich den Kontext nicht, bzw. nicht, wann eine Restaurierung sinnvoll ist.
- CC1101 speichern und wiederherstellen reicht sicher nicht. Es gibt ja auch andere Module, die je nach "enabled" Flag meinen, was machen zu muessen, z.Bsp. mit der CC1101 direkt reden.
- culfw garantiert gar nix, sondern ruft in eine schleife (siehe CUL.c) eine Liste von Funktionen auf. Wenn die auf die Idee kommen, selbst eine schleife zu programmieren, oder laengere Berechnungen anstellen, dann kommt der Watchdog. Es sei denn, man hat den vorher abgestellt.
- Code-Review wird zwar gewuenscht (siehe die HM-Patches von Ansgar), ist aber sehr viel Aufwand, und es ist eine undankbare Aufgabe. Ich will lieber weas Neues  programmieren, Ideen habe ich schliesslich auch welche. Ich habe meist kein Problem damit, wenn jemand sein eigenes "Modul" dazupackt, insb. wenn das per #ifdef konfigurierbar ist. Allergisch werde ich dann, wenn bereits vorhandene (und lange getestete) Funktionen umgebaut werden, warum auch immer.

[RaspII]

ok,
Danke, das reicht mir fürs erste.
Ich melde mich wieder sobald ich mir was überlegt habe

[RaspII]

Hallo Rudolf,
eine Bitte noch,
kannst Du mir Zugriff auf das contib Verzeichnis geben?
http://svn.code.sf.net/p/fhem/code/trunk/fhem/contrib
Ich möchte mein Modul "10_KOPP_FC.pm" dort einstellen.

Hatte schonman jemanden angeschrieben, aber keine Antwort bekommen.

Gruß
Claus

[rudolfkoenig]

Sende mir per email dein sourceforge-login