[PATCH] CUL: Beim senden automatisch rfmode wechseln

[Matthias Gehre]

Hallo,

mein CUL läuft normalerweise im rfmode MAX, da ich Nachrichten empfangen möchte. Nun habe ich jedoch eine FS20 Dimmersteckdose,
die geschaltete werden will.

Der Patch im Anhang wechselt nun automatisch in den SlowRf Modus bevor die FS20 cmds gesendet werden, und direkt danach wieder in den vorherigen Modus.

Das ist wahrscheinlich noch nicht commit-würdig, da es nur für FS20 Befehle implementiert ist, aber ich würde gerne eure Meinung hören.

Insbesondere, ob das der richtige Platz im Code für dieses Feature ist
und was ich tun müsste, damit es commit-würdig wird.

Viele Grüße,
Matthias

[Hausautomat]

Da der CUL automatisch auf den für das jeweilige Sendeprotokoll
umschaltet (gesteuert durch den jeweiligen Sendbefehl), ist das
vorherige Umschalten doch nicht nötig.

Ob der CUL hinterher in den entsprechenden (vorherigen) Lauschmodus
wechselt, habe ich noch nicht probiert.

Gruß
Hausautomat

> --
> Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe
> FHEM developers beigetreten sind.
> Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine
> E-Mail an fhem-de...@googlegroups.com.
> Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail
> an fhem-develope...@googlegroups.com.
> Besuchen Sie die Gruppe unter
> http://groups.google.com/group/fhem-developers?hl=de, um weitere
> Optionen zu erhalten.

[Rudolf Koenig]

> Das ist wahrscheinlich noch nicht commit-w�rdig, da es nur f�r FS20 Befehle
> implementiert ist, aber ich w�rde gerne eure Meinung h�ren.

Meine Meinung: Ich bin nicht begeistert von solchen Kombi-Loesungen, da
- es den Code verkompliziert,
- Empfang damit nicht moeglich ist, damit haben extern betaetigte Schalter in
fhem den falschen Status.
- FHT "nur" setzen geht so prinzipiell nicht.
- manche MAX Nachrichten waehrend des Sendens werden verloren gehen, das muss
man beim Support rausfinden.

Ich will nicht den Umsatz fuer busware hochtreiben, sondern fhem einfach und
unser Support-Aufwand niedrig halten :)

[Matthias Gehre]

Meine Meinung: Ich bin nicht begeistert von solchen Kombi-Loesungen, da
- es den Code verkompliziert,

Das stimmt. Andererseits bringen Features immmer "mehr" Code mit sich.

- manche MAX Nachrichten waehrend des Sendens werden verloren gehen, das muss
  man beim Support rausfinden.

Da es im MAX Protokol ein Ack gibt, sollte das kein Problem sein. Verlorenes wird nochmal gesendet.

Bei dem Rest stimme ich dir zu, für FHT oder manuelle Schalter wird
das Problem nicht gelöst.


Die Frage ist nun, ob ich den Patch nur bei mir lokal drin lasse,
oder ob noch andere daran interessiert sind. Dann könnten wir uns hier um eine
bessere Lösung bemühen.

Im IT Modul ist das ja auch schon implementiert, siehe attr switch_rfmode 1,
wobei er dann immer zurück in den HomeMatic Modus wechselt. Man könnte das so modifizieren,
dass er wieder in den vorherigen Modus wechselt.

Und das gleiche könnte man ins FS20 Modul einbauen. Dann hätte man nur den Code doppelt.
Daher dachte ich, man verschiebt das eine Ebene tiefer ins CUL Modul.

[Rudolf Koenig]

> Das stimmt. Andererseits bringen Features immmer "mehr" Code mit sich.

Stimmt, ich habe aber kein Problem auf Features zu verzichten.
Das Problem mit den Features ist, dass man die eigentlich immer in allen
Kombinationen testen muesste, und sie beeinflussen damit auch kuenftige
Features. Das sehen die "Feature-Vorschlagenden" haeufig nicht.

> Die Frage ist nun, ob ich den Patch nur bei mir lokal drin lasse, oder ob
> noch andere daran interessiert sind.

Andere wird es immer interessieren. Die, die damit ein Problem haben, melden
sich erst spaeter. Erinnert mich an dem Vorschlag, den Adressraum der S300
durch RSSI-Werte zu erweitern: Ich bin froh, dass ich das nicht eingebaut habe.


> Und das gleiche k�nnte man ins FS20 Modul einbauen. Dann h�tte man nur den

> Code doppelt. Daher dachte ich, man verschiebt das eine Ebene tiefer ins CUL
> Modul.

Hier muss man auch bedenken, dass das herumschalten in die einzelne Modi im
culfw nicht gut geloest ist:
SlowRF an: X21
SlowRF->HM: Ar
Hm->SlowRF: Ax,X21
und ich nicht sicher bin, dass es narrensicher funktioniert.

Wenn Du es aber generisch hinkriegst, und es gut testen kannst...

[Matthias Gehre]

Dann lass ich es erstmal nur bei mir lokal drin. Falls jemand anders das braucht, dann findet er den Patch ja hier im Thread.

Am 22. November 2012 18:09 schrieb Rudolf Koenig <inf...@koeniglich.de>:

> Das stimmt. Andererseits bringen Features immmer "mehr" Code mit sich.

Stimmt, ich habe aber kein Problem auf Features zu verzichten.
Das Problem mit den Features ist, dass man die eigentlich immer in allen
Kombinationen testen muesste, und sie beeinflussen damit auch kuenftige
Features. Das sehen die "Feature-Vorschlagenden" haeufig nicht.

> Die Frage ist nun, ob ich den Patch nur bei mir lokal drin lasse, oder ob
> noch andere daran interessiert sind.

Andere wird es immer interessieren. Die, die damit ein Problem haben, melden
sich erst spaeter. Erinnert mich an dem Vorschlag, den Adressraum der S300
durch RSSI-Werte zu erweitern: Ich bin froh, dass ich das nicht eingebaut habe.

> Und das gleiche könnte man ins FS20 Modul einbauen. Dann hätte man nur den

> Code doppelt.  Daher dachte ich, man verschiebt das eine Ebene tiefer ins CUL
> Modul.

Hier muss man auch bedenken, dass das herumschalten in die einzelne Modi im
culfw nicht gut geloest ist:
  SlowRF an: X21
  SlowRF->HM: Ar
  Hm->SlowRF: Ax,X21
und ich nicht sicher bin, dass es narrensicher funktioniert.

Wenn Du es aber generisch hinkriegst, und es gut testen kannst...

[Hausautomat]

Imho ist das umschalten nicht nötig. Mit dem jeweiligen send-Befehl schaltet der CUL selbst auf die gewählte sendeart um. Ob er danach wieder in Max empfängt, weiss ich nicht.

Gruss
Hausautomat

Brauchst du noch pair-logs von fensterkontakten und thermostaten via air Schnittstelle?

Matthias Gehre <gehre.m...@gmail.com> schrieb:

[Matthias Gehre]

Hey, das ist nicht nötig. Thermostate und Fensterkontakte habe ich auch, danke.

Komisch:
Ab und zu flutet mir mein CUL jedoch das Log mit komplett zerstörten MAX Nachrichten.
Dann lässt sich fhem nur noch per "kill" beenden, und den CUL muss ich per Hand einmal aus
der USB Buchse ziehen. Vielleicht hängt das mit den Wechseln zusammen.

Ob er nach dem Moduswechsel wieder horcht, muss ich mal beobachten.

--

[Matthias Gehre]

Habs nochmal im CUL code nachgeguckt:
Wenn man IT sendet, dann wechselt er automatisch in IT Modus.
Danach wechselt er in AskSin zurück, falls das vorher aktiv war.
In den MAX Modus wechselt er nie zurück.

Und wenn man FS20 sendet, dann wechselt er in keinen Modus zurück.

[Matthias Gehre]

Die Patches für culfw hab ich hier
https://groups.google.com/forum/#!topic/cul-fans/kVvZXqzLgWQ
gepostet.

[Hausautomat]

Von wo hast Du den geguckt?

Bestimmte Kommandos werden ja auf passenden rfMode geprüft (hmPairforSec, ampl,bwith...), der Rest wird "einfach gesendet" (raw - CUL_Set/Get).
Oder stehe ich nur auf'm Schlauch?

[Matthias Gehre]

Siehe culfw code, clib/intertechno.c, Funktion it_send. In den asksin Modus wird wieder zurück gewechselt, falls der vorher aktiv war.
Gleiches machen meine Patches für culfw (siehe Link aus meinem letzten Post) für MAX.

[Hausautomat]

Ja, da war mein Fehler. In die culfw bin ich nicht eingestiegen :-)
Danke & Danke für Deinen Patch.