Hallo zusammen,
gibt es eine Möglichkeit die ITRepetition direkt auf dem CUL zu hinterlegen (RAW-Kommando)? Derzeit verwende ich den ITRepetition Parameter pro Gerät. Ich habe aber gelesen, dass dies pro Schaltvorgang 3 Schreibzyklen auf dem CUL auslöst.
Danke!
Ich habe das direkt in die 10_IP.pm eingetragen...
Dann wird sie aber vom Updater überschrieben.
Die 10_IT.pm schreibt ja auch nur den Parameter in die Firmware....
Ich habe sie vom Update exkludiert...
Wenn ich mit set CUL raw isr12 die ITRepetion auf 12 setze, scheint dies nur im RAM des CUL gespeichert zu werden, da er nach einem Reset scheinbar zum ursprünglichen Wert zurückkehrt. Zur 10_IT.pm: Das Ändern des Werts bringt alleine bringt aus meiner Sicht nichts, da beim Durchlauf des Scripts scheinbar nicht der momentane Wert vom CUL abgefragt wird, sondern lediglich ob beim Device das Attribut ITRepetition hinterlegt ist. Ein Workaround wäre: Zuerst den Wert in der 10_IT.pm anzupassen, bei einem Device das Attribut ITRepetition zu setzen, ein Event auszulösen und dann das Attribut wieder vom Device zu entfernen.
Ansonsten würde aus meiner Sicht der isr-Parameter am CUL nicht verändert werden.
Dieser Workaround müsste aber nach meinem derzeitigen Kentnisstand nach jedem Reboot wiederholt werden.
Könnt ihr das bestätigen, oder bin ich auf dem Holzweg? :-)
DANKE!
Der Grund warum ich die 10_IT.pm modifiziert habe ist recht einfach - wenn ich den Paramater im Device selektiv setze funkt er gar nicht mehr. Sprich, setze ich den Parameter für ein spezifisches Device schaltet er alle nicht mehr. Da bin ich hier nicht der einzige, wurde schon mehrfach diskutiert.
Ich kann Dir bei deiner Begründung auch definitiv nicht folgen. Der Code besagt (bei mir):
my $it_defrepetition = 12; ## Default number of InterTechno Repetitions
Hier wird ein Default-Wert gesetzt, und kein Vergleichswert oder sonstwas. Du *kannst* das overrulen indem Du einen Devicespezifischen Wert definierst.Das wird denn abgegelichen, eben ob der Default genommen werden soll oder ein spezifischer:
## Do we need to change ITrepetition ??
if(defined($attr{$name}) && defined($attr{$name}{"ITrepetition"})) {
$message = "isr".$attr{$name}{"ITrepetition"};
CallFn($io->{NAME}, "GetFn", $io, (" ", "raw", $message));
Log GetLogLevel($name,4), "IT set ITrepetition: $message for $io->{NAME}";
Das wird denn anschließend zurückgesetzt:
## Do we need to change ITrepetition back??
if(defined($attr{$name}) && defined($attr{$name}{"ITrepetition"})) {
$message = "isr".$it_defrepetition;
CallFn($io->{NAME}, "GetFn", $io, (" ", "raw", $message));
Log GetLogLevel($name,4), "IT set ITrepetition back: $message for $io->{NAME}";
Zumindest verstehe ich den Code so, lasse mich aber gerne belehren. Setze ich hier auf 12 und gebe keine separaten Werte an läuft der als Default mit 12 durch. In meinen Augen bringt das sehr wohl was....
Kann ich so echt nicht bestätigen. Hab mir grad die Mühe gemacht und eine "RF-Sniffer gebastelt". Es tritt genau der beschriebene Effekt auf:
Die Änderung von $it_defrepetition bewirkt erstmal nichts. Es sei denn man schickt an den CUL "set CUL raw isr12".
Nach dem Neustart des CUL ist die Einstellung allerdings weg.
Ich muss dazusagen, dass ich wegen dem IT-Empfang die Alternative CUL-FW verwende.
## Do we need to change ITrepetition ??
if(defined($attr{$name}) && defined($attr{$name}{"ITrepetition"})) {
$message = "isr".$attr{$name}{"ITrepetition"};
CallFn($io->{NAME}, "GetFn", $io, (" ", "raw", $message));
Log GetLogLevel($name,4), "IT set ITrepetition: $message for $io->{NAME}";
Das sagt aus meiner Sicht aus, dass die ITrepetition nur geändert wird, wenn dem device das Attribut "ITrepetition" mitgegeben wird....
Ganz ehrlich - so funktionierts bei mir. Dosen die sonst nicht geschaltet haben schalten wenn ich den Wert in der 10_IT.pm erhöhe. Man braucht bei Gruppen denn halt ein async_delay. Such mal im Forum nach ITrepetition, da gabs mal nen Bug - keine Ahnung ob der inzwischen gefixt ist
Und wie Du unten schreibst:
ZitatDas sagt aus meiner Sicht aus, dass die ITrepetition nur geändert wird, wenn dem device das Attribut "ITrepetition" mitgegeben wird....
Genau das ist ja der Sinn. Deswegen wird ja weiter oben ein Default definiert.
my $it_defrepetition = 12; ## Default number of InterTechno RepetitionsWoher wüsste er sonst wie oft er senden soll? Und somit zurück zu deinem Problem: lösch alle ITRepetitions der Devices und erhöhe die zentral in der 10_IT.pm. Denn funken die alle per Default X mal?!?
Zitat
lösch alle ITRepetitions der Devices und erhöhe die zentral in der 10_IT.pm. Denn funken die alle per Default X mal?!?
Genau das habe ich getan. Er sendet nur 6x obgleich in der 10_IT.pm 12x eingetragen ist.
Aber das Verhalten ist ja nicht anders zu erwarten, wenn man sich die 10_IT.pm anschaut :-P
Zitat von: oeiber am 27 Oktober 2016, 15:49:21
Genau das habe ich getan. Er sendet nur 6x obgleich in der 10_IT.pm 12x eingetragen ist.
Aber das Verhalten ist ja nicht anders zu erwarten, wenn man sich die 10_IT.pm anschaut :-P
Na dann mach konkrete Vorschläge wie man den alten Code verbessern kann ;)
Ich denke, dass eine Option für de Repition in der CUL-FW bzw. A-CUL-FW besser aufgehoben wäre, dann könnte diese Option global gesetzt werden.
Ich habe nur Bedenken, wenn man die ITRepetition pro Sendevorgang verändert und wieder zurückstellt, dass dies den Flash des CUL-Sticks auf Dauer schadet.
Gibt es zu dem Thema neue Erkenntnisse?
Ist es immernoch der korrekte Weg 12 bei den Repititions zu setzen?
Wird sonst tatsächlich schon 6x das Signal gesendet?
Ich nutze die nanoCUL mit aculfw.
6 ist Default. Musst Du testen, ich würde sagen so viel als nötig und so wenig wie möglich, man muss ja nicht unbedingt ein Funkfeuer initiieren. Ich habe im Moment - glaube ich, müsste ich nachschauen - 10 definiert, damit schaltet alles sauber. Setz das stufenweise hoch und teste es aus.
Also ich habe das bei mir so gelöst:
attr nanoCUL433 connectCommand isr12
Zitat von: weini am 02 Februar 2017, 18:37:31
Also ich habe das bei mir so gelöst:
attr nanoCUL433 connectCommand isr12
Heyho weini,
sag mal bist du sicher, dass das Commando so angenommen wird? Bei mir erscheint im Log bei Nutzung dieses Attributs
2017.04.22 19:12:18 2: nanoCUL: unknown message 20Ich bin also nicht so zuversichtlich, dass das tatsächlich irgendetwas bewirkt...
Viele Grüße,
rien
Warum beharrt Ihr so auf den IT-Repetitions als Lösung für ein Nicht-Schalten?
Ist die Ursache dafür nicht etwas ganz anderes ?
Wenn der Empfänger nach 3 Telegrammen nichts mitbekommt, dann durch Zufall nach 12?
Es dürfte doch eher ein Problem der richtigen Abstimmung der ITFrequency zum Empfänger sein ....
https://forum.fhem.de/index.php/topic,58396.60.html (https://forum.fhem.de/index.php/topic,58396.60.html)
Grüße,
Jürgen
Zitat2017.04.22 19:12:18 2: nanoCUL: unknown message 20
Bei mir kommt kein Fehler im Log...
Zitat von: juergs am 22 April 2017, 22:30:51
Warum beharrt Ihr so auf den IT-Repetitions als Lösung für ein Nicht-Schalten?
Ist die Ursache dafür nicht etwas ganz anderes ?
Wenn der Empfänger nach 3 Telegrammen nichts mitbekommt, dann durch Zufall nach 12?
Naja... wenn ich mit dem Standardwert trotz Feinabstimmung eine Dose nicht zuverlässig schalten kann und es nach Modifikation der 10_IT.pm zuverlässig funktioniert - denn sehe ich da schon einen kausalen Zusammenhang! Zumal die Dosen unterschiedlich "zickig" sind - gleicher Standort, gleiche Settings, anderer Zwischenstecker - und schon funktioniert es problemlos was zuvor klemmte....
Hallo.
Hatte im Log immer Ausgaben die ich nicht verstanden habe:
2017.11.07 21:06:25 2: IT IODev device didn't answer is command correctly: raw => 5
2017.11.07 21:06:26 2: IT IODev device didn't answer is command correctly: raw => 5
2017.11.07 21:06:27 2: IT IODev device didn't answer is command correctly: raw => 5
Kam davon dass ich bei ITrepetition bei jedem Gerät gesetzt hatte.
Wusste nicht dass 6 standard in der FW ist und noch schlimmer, nicht dass bei jedem Schaltbefehl gleich 3 Cmds an den CUl gesendet werden (1x isr5, 1x Schaltbefehl & isr6)
Habe diese ITrepetition attr nun bei allen meinen Geräten entfernt und mittels:
attr nanoCUL433 connectCommand isr12
beim starten von FHEM den ISR im RAM der FW auf 12 gestellt.
Wie bereits erwähnt hält der CUL diese Option aber im RAM.
Sollte er neustarten (Watchdog usw.) ist die Einstellung weg bis zum nächsten FHEM Start.
Gibt es hier mittlerweile eine andere, Dauerhaftere Lösung?
Da schon mehrere danach fragen, sollte das Thema meines Erachtens in der culfw bzw. a-culfw gelöst werden.
Sprich man kann einen Setting ins eeprom schreiben und dieser wird behalten.
Update: Habe mal den Code der a-culfw geforked und so abgeändert dass die it_repetition behalten werden.
Muss aber noch testen, da ich leider noch keine aufgesetzte ToolChain habe um die FW zu compilieren und zu testen.
Hier der branch: https://github.com/popy2k14/a-culfw/tree/store_it_repetition_in_eeprom
Falls von euch jemand eine funktionierende Toolchain hat wäre es toll wenn ich hier Unterstützung bekommen könnte.
Danke
pOpY
hier ? (http://culfw.de/commandref.html#flashing)
Zitat von: KölnSolar am 08 November 2017, 22:12:47
hier ? (http://culfw.de/commandref.html#flashing)
Danke, habe ich auch schon gefunden. Wollte mir nur das selbst kompilieren ersparen ::)
Werde ich morgen mal machen.
pOpY
Meine modifizierte Firmware gibt es hier: https://forum.fhem.de/index.php/topic,79285.0.html