FHEM Forum

Hallo, ich betreibe meinen CUL_0 im Mode slowRF mit FS20-Teilen
und würde gern Freq, Bandbreite und Empfindlichkeit mal versuchweise minimal ändern.
Im Modus slowRF ist mir das nicht erlaubt.
Gelesen habe ich

Zitat von: rudolfkoenig schrieb am Mo, 06 Mai 2013 12:01> Weiß jemand, was ich tun muss, damit der CUL die Befehle annimmt?
...
Das CC1101 wird mit einem Parametersatz auf die entsprechende Modi programmiert. Bei HomeMatic und MAX ist dieser Parametersatz im (read-only) Programmspeicher, bei SlowRF wird es aus dem Programmspeicher erst ins EEPROM kopiert (wenn der in EEPROM abgelegte culfw Versionnummer nicht dem im Programm abgelegtem entspricht, also ueblicherweise nach flashen mit neuem firmware), und von EEPROM ins CC1101 geladen. Mit sens/freq/etc aendert man die EEPROM Einstellungen, und Initialisiert den CC1101 neu.

, aber verstanden habe ich das nicht, weil ich einen so hohen Wissensstand eben nicht habe.

Also was bitte muss ich genau tun, damit ich die Parameter ändern kann ?
Erbitte ein Kochrezept.
Vielleicht erbarmt sich ja hier ein netter Jemand meiner ?

ZitatIm Modus slowRF ist mir das nicht erlaubt.

Doch, das geht, und zwar NUR im SlowRF Modus . In HM Modus  und MAX Modus gehts hingegen nicht.
(was sich unter anderem aus Rudolfs von dir zitierten Äusserungen ergibt. In Rudolfs Äusserung steht übrigens tatsächlich nicht WIE man die Werte ändert, du bist also quasi nicht zu unwissend das nur nicht zu erkennen)

ZitatVielleicht erbarmt sich ja hier ein netter Jemand meiner ?

Das glaube ich kaum, anstelle dessen kann ich es ja mal versuchen (har har har)

Du musst an das CUL Befehle senden, z.b. diese

set CUL_0 freq 868.35
set CUL_0 bWidth 464
set CUL_0 sens 05
set CUL_0 rAmpl 42

Die in meinem Beispiel genannten Werte sind auch die, die ich als Startpunkt für gut halte.  bWidth 464 verbessert insbesondere den Empfang von FS20 PIRAs, die mit dem Defaultwert gerne mal rumzicken.

Sie SET Commandos gibts du entweder übers Webfrontend ab oder - besser- über eine Telenetsitzung auf FHEM.
Das Ergebniss kann man sich dann gleich mit

get CUL_0 ccconf
anzeigen lassen.

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.

Moin,
Danke für Deine Antwort,
ich muss mich nach neuerlichen Test wiederholen
1. es ist slowRF eingestellt
2. ich habe versucht die von Dir genannten Befehle einzugeben
3. Ich erhielt wieder die Meldung:
... not in this mode
4. wir sind nun in einer endless loop

GN8

Deine definition des CULs hier posten bitte.

Bitte schön:

define CUL_0 CUL /dev/ttyACM0@9600 3352
attr CUL_0 rfmode slowRf

Hallo,

das slowrf ist doch für fs20 oder?

Ich frag nur so blöd weil ich das bei meinen CUNOs nicht eingetragen hab und trotzdem alles schalten und abfragen kann.
Ich hatte das aber auch bei meinem CUL nie eingetragen.
Ich hab aber auch nur FS20.


Grüße

> das slowrf ist doch für fs20 ?
JA
Habe nur FS20, hatte ich aber oben bereits gesagt.

Das ist noch original so, wie es seinerzeit von FHEM selbst angelegt wurde.

Hallo,

ZitatDas ist noch original so, wie es seinerzeit von FHEM selbst angelegt wurde.

Das muss dann aber schon länger her sein ;-)
Ich benutze Fhem seit Jänner 2012 und habe so einen Eintrag nie gesehen bei meinem CUL.

Grüße

Habe an der Stelle nie nicht was gefummelt :-)

Aber ich nehme das gesenkten Hauptes hin,
habe schon öfter die unangenehme Erfahrung gemacht,
das etwas gehen sollte und bei anderen auch funzt,
was genau bei mir eben nicht geht, wie dieses hier.
War aber bei mir schon immer so.

attr CUL_0 rfmode slowRf

Entfernen und noch mal versuchen bitte

(slowRF ist default)

Zitat von: Zrrronggg! schrieb am Mi, 29 Mai 2013 21:23

ZitatVielleicht erbarmt sich ja hier ein netter Jemand meiner ?

Das glaube ich kaum, anstelle dessen kann ich es ja mal versuchen (har har har)

Ob Du es nun willst oder nicht:
Du bekommst hiermit von mir den
"NetterJemandGeduldigUndImmerHilfsbereitOrden"
verliehen und umgehängt.

Zitat von: Zrrronggg! schrieb am Do, 30 Mai 2013 20:28

Code Auswählen Erweitern

attr CUL_0 rfmode slowRfEntfernen und noch mal versuchen bitte
(slowRF ist default)

Danke, eben genau DAS war es, nun tut es.
Wer hätte gedacht, dass die zusätzliche Definition eines Default-Wertes zum Versagen führt *kopfschüttel*

Danke, Du bekommst zu obigen auch noch das "am Bande" verliehen.

Danke für den Orden am Bande, und die Erkenntnis, das es einen Unterschied macht ob man SlowRF einstellt oder nur per default so lässt.
Das war mir auch neu, ich hatte quasi nur "geraten".

Im Grunde würde ich das als Bug bezeichnen.

(Rudi:
attr CUL_0 rfmode slowRf

ergibt bei Befehlen wie:
set CUL_0 freq
set CUL_0 bWidth
set CUL_0 sens
set CUL_0 rAmpl

Fehlermeldung
"not in this mode"

obwohl die Befehle in SlowRF gehen müssten und auch gehen, wenn man rfmode-Einstellung weg lässt)

das liegt vieleicht daran das es SlowRf heissen muss. nicht slowRf ....

gruss
  andre

Hallo,

und wieder mal Case sensitiv ;-)

Grüße

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:)
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
Und wenn er das macht, warum gehen die Befehle dann nicht?

Mit anderen Worten: Das ist so oder so ein Bug

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.

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)


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.  

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

Zitat von: Zrrronggg! schrieb am Fr, 31 Mai 2013 19:58Jaaa, 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.

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

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

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

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

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

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

Hallo,

so gesehen

Zitates 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

Zitat

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

Unter vorgenannten Aspekten fand ich auch diese Antwort nicht so schön:
Link (http://forum.fhem.de/index.php?topic=11678.msg79701#msg79701)

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.

Zitat von: Zrrronggg! schrieb am Fr, 31 Mai 2013 22:19Ja, 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)

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

Zitat von: Zrrronggg! am 29 Mai 2013, 21:23:15
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

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

ZitatBezieht 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

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.  :'(

Zitat

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

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