CUL 433 / Intertechno

Begonnen von oeiber, 26 Oktober 2016, 08:58:20

Vorheriges Thema - Nächstes Thema

oeiber

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!

Tedious

Ich habe das direkt in die 10_IP.pm eingetragen...
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

oeiber

Dann wird sie aber vom Updater überschrieben.
Die 10_IT.pm schreibt ja auch nur den Parameter in die Firmware....

Tedious

Ich habe sie vom Update exkludiert...
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

oeiber

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!

Tedious

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....
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

oeiber

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

Tedious

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 Repetitions

Woher 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?!?
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

oeiber

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

bjoernh

#9
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  ;)

oeiber

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.

SofB

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.
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

Tedious

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.
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

weini

Also ich habe das bei mir so gelöst:


attr nanoCUL433 connectCommand isr12

rien-ne-va-plus

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 20

Ich bin also nicht so zuversichtlich, dass das tatsächlich irgendetwas bewirkt...

Viele Grüße,
rien