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

juergs

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

Grüße,
Jürgen

weini

Zitat2017.04.22 19:12:18 2: nanoCUL: unknown message 20

Bei mir kommt kein Fehler im Log...

Tedious

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

popy

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








KölnSolar

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

popy

Zitat von: KölnSolar am 08 November 2017, 22:12:47
hier ?

Danke, habe ich auch schon gefunden. Wollte mir nur das selbst kompilieren ersparen  ::)
Werde ich morgen mal machen.

pOpY

popy