Setzen der CUL Frequenz, Bandbreite, Empfindlichkeit ?

[Puschel74]

Hallo,

schon klar.

Im SlowRf oder slowrf oder wie auch immer sollte der CUL bzw. FHEM die Befehle nicht verweigern - da geb ich Dir recht.

Grüße

[justme1968]

Jaaa, da hatte ich auch dran gedacht, aber - den Vorwurf darf ich euch nicht ersparen - das ist zu kurz gedacht.

Nämlüsch:

1. behauptet Ralph, der Eintrag sei so von Fhem vorgenommen worden (Hab ich aber gar nicht weiter gefragt, weil unrelevant, denn:)

ich würde mal sagen das ist von hand gemacht. weil fhem über die web oberfläche nur SlowRF anbietet.

2. WENN das falsch ist, was macht Fhem dann? Da er das CUL ja nutzen konnte, fällt es also bei unsinnigem rfmode Eintrag den Defaultmode zurück, der zufällig auch SlowRF ist

ja. genau das macht fhem. leider schreibt es den falschen wert aber trozdem ins attribut.

Und wenn er das macht, warum gehen die Befehle dann nicht?

weil trozdem der falsche wert im attribut landet und an der stelle wo die kommandos geprüft werden nur nach SlowRF mit grossem S geprüft wird.

Mit anderen Worten: Das ist so oder so ein Bug

es ist auf jeden fall dumm gelaufen. ob man das unvollstänige abfangen einer fehleingabe aber als bug klassifiziert ist durchaus diskussionswürdig.

Die Befehle bzw. deren Ablehnung ("not in this mode") sind irgendwie nicht davon abhängig, in was für einem Mode das CUL/CUNO tatsächlich ist, sondern was im attr rfmode steht, was - wenn ihr recht habt - nicht mit dem Mode übereinstimmen muss.

ja.

Man könnte das ganze testen, indem man
1. attr CUL_0 rfmode s23flunztueten
 verwendet um zu sehen was dann passiert (Eurer Theorie nach geht das CUL dann in den SlowRF Mode und macht auch alles, ausser das die fraglichen Befehle NICHT gehen)

ja. und es ist keine theorie. ich hab nachgeschaut :)

2. attr CUL_0 rfmode slowRF
einträgt um sehen ob's dann geht

Eventuell ist's aber einfach der Entwickler äussert sich, wenn er zufällig noch im Kopf hat, was er da genau gemacht hat.

man kann einfach nachschauen was er gemacht hat. was er gedacht hat leider nicht.

gruss
  andre

[Puschel74]

Hallo,

so gesehen

es ist auf jeden fall dumm gelaufen. ob man das unvollstänige abfangen einer fehleingabe aber als bug klassifiziert ist durchaus diskussionswürdig.

kann man es in dieser Hinsicht nicht als Bug bezeichnen.
Es ist aber auch nicht (für Normal-Anwender) durchschaubar.
Wenn es nicht zu große Umstände macht sollte mann das evtl. versuchen ab zu fangen.
Da ich leider aber eine totale Null bin was das anbelangt ziehe ich mich jetzt wieder dezent zurück.

Grüße

[Zrrronggg!]

es ist auf jeden fall dumm gelaufen. ob man das unvollstänige abfangen einer fehleingabe aber als bug klassifiziert ist durchaus diskussionswürdig.

kann man es in dieser Hinsicht nicht als Bug bezeichnen.

Ich muss das nur umformulieren und dann ist's ein Bug:
"Obwohl das CUL im SlowRF Mode betrieben wird, werden in SlowRF Mode durchführbare Befehle als ungültig abglehnt"

Das ist ein Bug.

In Anbetracht der Gesamtsituation bin ich mit dem Begriff "diskussionswürdig" aber einverstanden.   ;-)
So oder so: Ich das sollten wir bei Gelegenheit mal ändern, den Anfänger wird's verwirren.

"Wir" heisst natürlich der Maintainer des Codes wo das passiert, ich hab nicht mal ne Ahnung wer das ist, ob Rudi oder jemand anders.

[Ralph]

Unter vorgenannten Aspekten fand ich auch diese Antwort nicht so schön:
Link

[Zrrronggg!]

Ja, das musst du aber auch verstehen:

Eine wirklich grosse Anzahl von Leuten liest vorher nicht, stellt die Fragen ungenau (das beliebte "geht nicht"), und macht nicht was die Helfer vorschlagen.

Es ist oft wirklich eine Qual, nur wenigstens rauszukriegen, was der Fragesteller überhaupt will. (Puschel74 und ich hatten da gerade wieder einen thread mit jemand, da gings alleine 10x hin und her, bis klar war was genau das Problem ist)

Leute wie Rudi, die ECHTE Probleme zu lösen haben, sind daher auch ein bisschen darauf angewiesen, dass der Fragesteller mitarbeitet... und das ihm die Anfänger von Leuten wie mir "vom Hals gehalten" werden.

Im Vergleich zu Rudi bin ich selber Anfänger und kann nix. Aber es reicht, z.B.: mit dir zu einer Lösung zu kommen. Und damit die Spezialisten wie Rudi freie Zeit zu schaffen für den echt schweren Kram.

[Puschel74]

Ja, das musst du aber auch verstehen:

Eine wirklich grosse Anzahl von Leuten liest vorher nicht, stellt die Fragen ungenau (das beliebte "geht nicht"), und macht nicht was die Helfer vorschlagen.

Es ist oft wirklich eine Qual, nur wenigstens rauszukriegen, was der Fragesteller überhaupt will. (Puschel74 und ich hatten da gerade wieder einen thread mit jemand, da gings alleine 10x hin und her, bis klar war was genau das Problem ist)

Leute wie Rudi, die ECHTE Probleme zu lösen haben, sind daher auch ein bisschen darauf angewiesen, dass der Fragesteller mitarbeitet... und das ihm die Anfänger von Leuten wie mir "vom Hals gehalten" werden.

Im Vergleich zu Rudi bin ich selber Anfänger und kann nix. Aber es reicht, z.B.: mit dir zu einer Lösung zu kommen. Und damit die Spezialisten wie Rudi freie Zeit zu schaffen für den echt schweren Kram.

Hallo,

Full Ack - ich hab noch überlegt wie ich das formulieren kann.
Danke Zrrronggg!

Grüße

Edith: Ich kann mirs nicht verkneifen.
Rudi hat dieses Projekt ins Leben gerufen! (Das sollte man, denke ich, nicht vergessen).
Alle hier "arbeiten" ausnahmslos in Ihrer Freizeit daran mit.
Arbeiten in "" weil nur wirklich wenige daran arbeiten! Der Grossteil schlägt sich durchs FHEM-Leben und schaut das alles funktioniert.
Einige wenige versuchen ihr spärliches Wissen mit Anfängern zu teilen (wobei auch ich mich noch zu den Anfängern zähle und das auch noch länger sein werde).
Da darf man wohl zwischendurch etwas knappe Hinweise vom Chef (den wirklichen Arbeitern an diesem Projekt) nicht in den falschen Hals bekommen.
FHEM ist gratis und wird in der Freizeit einiger weniger weiter entwickelt.
In dieser Hinsicht dürften hinreichende LogFile-Auszüge und (wie Zrrronggg! schon schrieb) die Mitarbeit der Fragesteller angebracht sein.
Mitarbeit indem der Beitrag und die Hilfestellungen abgearbeitet und die Fragen beantwortet werden.
m2cents - aber es steht ja jedem frei zu helfen (oder auch nicht)

[Br_Ö_sel]

Ich knüpfe hier mal an....

Da ich es in 2 Jahren nicht geschafft hatte meinen FS20  Piri anzulernen, habe ich ihn irgendwann in den Mülleimer geworfen. Dachte er wäre defekt. Nun hatte ich mir für eine neue Klinkel einen FS20 Klingeltaster gekauft. Jedoch wollte auch dieser nicht. Alles hundertmal durchgelesen und probiert, leider ohne Erfolg. Fragen hier im Forum wollte ich diesbezüglich auch nicht, da ja Fragen zu Basiswissen eher verpönt ist.
Letztendlich bin ich dann doch der Ursache auf den Grund gekommen... es lag an den Cul-Parametern, die ich mit den hier geposteten überschrieben habe. Nun ist es endlich möglich FS20 zu empfangen.

Soweit alles gut, allerdings habe ich nun das Problem das meine MAX Fensterkontakte nicht mehr empfangen werden.

Warum?! Meine Cul ist/war so definiert

Code Auswählen Erweitern

   
#---------------------------------CUL----------------------------------#
define CUL_0 CUL /dev/ttyACM0@9600 0000
attr CUL_0 rfmode MAX
define cm CUL_MAX 123456   

So konnte ich aber die Cul-Parameter nicht ändern, also habe ich den rtfmode raus genommen.

Code Auswählen Erweitern

   #---------------------------------CUL----------------------------------#
define CUL_0 CUL /dev/ttyACM0@9600 0000
#attr CUL_0 rfmode MAX#
define cm CUL_MAX 123456   

So funktionieren natürlich nicht die MAX Komponenten. Setzte ich das wieder ein, sind meine vorher veränderten Cul-Parameter im ursprünglichen Zustand und ich kann wieder keine FS20 Komponenten empfangen.

Wäre ja schön, wenn beides gleichzeitig funktionieren würde. Vielleicht hat ja jemand eine Lösung.

Ach... den Piri Bewegungsmeldern habe ich noch kurz vor der Reise zur Müllkippe aus dem gr. Müllsack retten können :-D

[Br_Ö_sel]

In den von dir zitierten Äusserungen Rudis steht ausserdem:
Jedes Absetzen dieser Kommandos werden die EEPROM Einstellungen geändert und der Sender/Empfänger Baustein des CULs neu initialisiert.

Da EEPROMs mit solchen Einstellungen altern, sollte man das nicht zu oft machen...  also sagen wir mal: ein paar Hundert mal ist kein Problem, aber jeden Tag automatisch neu setzen ist vielleicht keine gute Idee.

Bezieht sich das mit dem Altern auch auf das Wechseln der Sendefrequenz des Culs, wenn man mit einem 868 Cul die 433 Steckdosen schaltet? Da wird er doch jedesmal neu geflashed

[KölnSolar]

Hallo Br_Ö_sel,
meinst Du nicht es wäre besser gewesen einen neuen Thread zu eröffnen, anstatt einen vor 3,5 Jahren geendeten zu kapern ?
Ich versteh ja irgendwie Deinen Unmut, nur: warum willst Du zwischen 2 verschiedenen Funktechniken wechseln ? Du kannst doch eh immer nur eine empfangen ! Entweder MAX oder SlowRF(FS20).
Als Krücke könntest Du Dir einen dummy anlegen und ein notify dazu. bei on machst Du im notify ein attr CUL rfmode MAX und bei off attr CUL rfmode SlowRF; set CUL raw.....; set CUL raw.....; set .......

Bezieht sich das mit dem Altern auch auf das Wechseln der Sendefrequenz des Culs, wenn man mit einem 868 Cul die 433 Steckdosen schaltet?

Meines Wissens, ja, da sich das altern auf das wiederholte beschreiben der EEPROMs bezieht.
Grüße Markus

[Zrrronggg!]

Dafür hätte ich auch einen neuen Thread aufgemacht.

Aber gut. Zur Sache selbst:

Die RFmodes sind exclusiv. ENTWEDER
SlowRF (im wesentlichen FS20, FHT, S300)
oder
MAX (MAX!)
oder HM (HM)

Die einzige einigermaßen offizielle Ausnahme ist, dass man im SlowRF Mode auch IT Kommandos absetzen kann, dazu unten mehr.

D.H. MAX! und FS2 *zugleich* mit nur einem CUL geht nicht.  Ich finde der Umstand ist aus den einschlägigen Wikiartikeln sichtbar. Da heisst es zumindest:
"Ebenso gibt es ein Modul zur Ansteuerung der MAX! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z. B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich nicht angeraten."
(ich finde das auch bereits zu schwach fomuliert, denn eigentlich geht es wirklich nur mit erheblichen Klimmzügen und Nachteilen). Das du für dieses fehlende Basiswissen / Wikiartikel nicht gelesen einen FS20 PIRI weggeworfen hast schmerzt. 

Bezieht sich das mit dem Altern auch auf das Wechseln der Sendefrequenz des Culs, wenn man mit einem 868 Cul die 433 Steckdosen schaltet?

Meines Wissens, ja, da sich das altern auf das wiederholte beschreiben der EEPROMs bezieht.

Ja und nein. Der IT Code der in der Standard culfw mit drin ist, schaltet die Frequenz nur für den jeweiligen Befehl kurz um und schreibt die Frequenz nicht ins EEPROM (Wie genau der das macht weiss ich nicht). Daher macht der einerseits die EEPROMS nicht kaputt, aber ermöglich andererseits keinen IT-*Empfang*.
Sowas hier:

Als Krücke könntest Du Dir einen dummy anlegen und ein notify dazu. bei on machst Du im notify ein attr CUL rfmode MAX und bei off attr CUL rfmode SlowRF; set CUL raw.....; set CUL raw.....; set .......

schreibt aber die geänderte Frequenz ins EEPROM und ist daher eher nicht für den Dauerbetrieb geeignet.

Ich selber betreibe IT mit einem eigenen 433 CUL und habe daher dieses Thema nicht weiter verfolgt.