Autor Thema: Modifizierte a-culfw 1.26.01 wo ITrepetition im EEPROM gespeichert wird  (Gelesen 359 mal)

Offline popy

  • Jr. Member
  • **
  • Beiträge: 62
Hallo.

Hatte schon selbst im Forum öfters gelesen dass manche Versuchen für alle IT Geräte eine ITrepetition (Anzahl Intertechno Codes Wiederholungen) zu setzen.
Standardwert in der a-culfw ist 6, auch so im IT Modul.
Es ist oft ganz gut, die Wiederholungen zu erhöhen um z.B.: weit entfernte Geräte besser zu erreichen und sicher zu schalten.

Es gab versch. Ansätze das zu lösen (nur was ich so gelesen habe):

  • ITrepetition bei jedem Gerät setzen -> Problem dass das IT Modul vor jedem Schaltbefehl die IT repetition auf das gewünschte setzte (im RAM des CUL), den Schalt Befehl absetzte, und dann noch einen Befehl zum zurücksetzen auf 6 (warum dass kann ich mir nicht erklären, ev. hat da ein Entwickler vom IT Modul eine Antwort). Problem hierbei ist jedenfalls dass dies manchmal dem CUL zuviel ist und im Log versch. Meldungen zu finden sind (z.B.: IT IODev device didn't answer is command correctly:   raw => 9, bei 9 ITrepetitions)
  • Den default Wert im IT Modul umschreiben -> hilft Meiner Meinung nach nichts, da der neue isr nur gesendet wird wenn das attr ITrepetition vorhanden ist (Wenn ich den Code richtige verstanden habe).
  • Hardware Lösungen wie andere/bessere Antennen usw.
  • ...

Ich möchte euch hier eine andere Lösung anbieten.
Einen Patch für die a-culfw, damit kann man mittels neuem Befehl isrd den Standard Wert im EEPROM speichern.
Vorteile:

  • Kein unnötiger Traffic zum CUL, dadurch weniger Fehlermeldungen
  • Es muss bei keinem Gerät mehr das attr ITrepetition gesetzt werden

Ich habe mir die a-culfw auf github geforkt und die Änderungen bereits in meinen Branch eingecheckt: https://github.com/popy2k14/a-culfw/tree/default_it_repetition_in_eeprom
Es handelt sich um eine Testversion! Meine Tests verliefen erfolgreich.
Wenn gewünscht, werde ich einen Pull request absetzten, damit dass ev. (abhängig von @ bjoernh) in die originale a-culfw eingepflegt wird.

Zum Flashen des nanoCUL wie folgt vorgehen:

  • Angehängte Dateien auf den RPI downloaden (z.B.: mit wget oder WinSCP übertragen)
  • fhem stoppen ("sudo /etc/init.d/fhem stop" oder mit systemctl: "sudo systemctl stop fhem")
  • zip datei enpacken mit unzip
  • Flashen wie bisher: ./flash.sh und Anweisungen folgen...
  • fhem wieder starten ("sudo /etc/init.d/fhem start" oder mit systemctl: "sudo systemctl start fhem")

Nach erfolgreichem Flashen sollte im fhem der Versionsstring so lauten:

V 1.26.01 a-culfw Build: ITrepetition Test2 (12.11.2017) nanoCUL433 (F-Band: 433MHz)
Wichtig ist: es sollte die fhem.cfg nach "ITrepetition" durchsucht und alle Einträge entfernt werden.
Ansonsten wird jeder Befehl mit dem letzten attr ITrepetition abgesetzt.


Zu guter letzt wird der gewünschte isrd (ITrepetition default/STandard) Wert EINMAL gesetzt, dieser gilt dann für ALLE IT Schalt Befehle.
Dieser "überlebt" dann ein Stromlosmachen, Reset (WDT, BOR oder anders) des nanoCUL  8)
Gesetzt werden kann der Wert, einmalig mit:

set CUL433 raw isrd9Derzeit meine Einstellung.

Freue mich auf Eure Meinung und Testergebnisse
Viel Spaß
pOpY

« Letzte Änderung: 15 November 2017, 20:32:44 von popy »

Offline bjoernh

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 731
Hallo,

ich bin mir nicht sicher ob das der richtige Weg ist. Im IT Modul ist, wenn ich es richtig weiß immer bei einem anderen Wert das Setzten, sowie zurücksetzten des Wertes eingebaut. Wenn also jemand dies im Fhem so eingerichtet hat, dann würde in Zukunft immer immer das EPROM beschrieben, was ja auf Dauer nicht so gut ist.
Gerne können wir mal darüber diskutieren.

Gruß
Björn

Offline popy

  • Jr. Member
  • **
  • Beiträge: 62
Hallo Björn.

Das stimmt, bin zwar kein Perl Experte, aber genau so lese ich den Code auch   :)
Ich verstehe zwar nicht warum das so implementiert ist, da dies ja ziemlich viel unnötigen Traffic erzeugt.

Du hast voll kommend recht, wenn das jemand so eingerichtet hat würde das für jeden Schaltbefehl 2x EEPROM Schreibzyklen bedeuten -> nicht gut.
Drum habe ich bei meiner Anleitung oben dazu geschrieben, dass für die Testversion die ITrepetition aus der Config entfernt werden müssen.
lt. Datenblatt hält es "100,000" Schreibzyklen aus.

Natürlich wäre es besser einen neuen Befehl als "isr" einzuführen um den default Wert von 6 ändern zu können, welcher dann im EEPROM abgespeichert wird.
So wären wir abwärts kompatibel zum jetzigen isr Befehl (mir dauerndem Ändern vom FHEM her), es wäre aber sehr schnell möglich auf den neuen "Default Wert" zu wechseln.
(Alle ITrepetition aus der fhme.cfg löschen und einmal den neuen Befehl mit dem gewünschten Wert eingeben).

Was sagst du dazu?

Bin Gerne Bereit meinen Patch dahingehend zu ändern.
Wäre natürlich toll wenn das Feature in deine offizielle Version (trunk) mit einfließen könnte, da ich schon einige Anfrage hier nach so einem Feature gesehen habe.

lg
pOpY

« Letzte Änderung: 12 November 2017, 17:32:25 von popy »

Offline popy

  • Jr. Member
  • **
  • Beiträge: 62
Hallo,

Habe einen neuen Branch/Code erstellt: https://github.com/popy2k14/a-culfw/tree/default_it_repetition_in_eeprom
Habe ein neues Kommando implementiert: "isrdXXX" (XXX = 1-253), dieser Wert wird als default ITrepetition value im EEPROM gespeichert.
Es wird geladen wenn ein ITsend Cmd ausgeführt wird (= Schaltbefehl) ohne dass vorher ein isr cmd empfangen wurde.
So sind wir nun Abwärts kompatibel, sprich:

Jemand der wie bisher ITrepetition bei einzelnen oder mehreren Geräten eingetragen hat, da funktioniert es wie bisher.
Vor dem Schaltbefehl sendet FHEM den gewünschten isr, dann den Schaltbefehl und dann den default isr von 6.

Bei jemanden der das neue default feature benutzen möchte, der löscht einfach alle attr "ITrepetition" seiner Geräte, sendet einmal einen default Wert mit "isrd", und fertig  8)

Ich werde morgen die neue Firmware compilieren, testen und mich wieder melden.

@Björn: Würde mich über deine Meinung und ev. einen Review des Codes vor dem pull request freuen  ::)

cu
pOpY

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1797
Ich finde dies ist nicht der sauberste Weg.
Da gibt es bessere Möglichkeiten.

a: den Signalduino verwenden

b: Alle Kommandos mit einem IOWrite an den 00_CUL übergeben. z.B: isr12#isxxxx#isr6
In der 00_CUL müssten dann die Kommandos wieder gesplittet und dann mit einer Sendewarteschlange an den CUL gesendet werden

c: das "is" Kommando erweitern, daß die ITrepetition hinten angehängt werden kann. z.B: isxxxx;r12. Das IT-Modul müsste dann mit $io->{VERSION} die CUL-Version ermitteln ob das erweiterte is Kommando unterstützt wird

d: die Signalduino Senderoutinen in den CUL einbauen und dann den CUL in die 00_Signalduino einbinden. Damit könnte dann der CUL alle vom Signalduino unterstützten Protokolle senden.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module
SIGNALduino

Offline popy

  • Jr. Member
  • **
  • Beiträge: 62
Ich finde dies ist nicht der sauberste Weg.
Da gibt es bessere Möglichkeiten.

a: den Signalduino verwenden

b: Alle Kommandos mit einem IOWrite an den 00_CUL übergeben. z.B: isr12#isxxxx#isr6
In der 00_CUL müssten dann die Kommandos wieder gesplittet und dann mit einer Sendewarteschlange an den CUL gesendet werden

c: das "is" Kommando erweitern, daß die ITrepetition hinten angehängt werden kann. z.B: isxxxx;r12. Das IT-Modul müsste dann mit $io->{VERSION} die CUL-Version ermitteln ob das erweiterte is Kommando unterstützt wird

d: die Signalduino Senderoutinen in den CUL einbauen und dann den CUL in die 00_Signalduino einbinden. Damit könnte dann der CUL alle vom Signalduino unterstützten Protokolle senden.

Gruß Ralf

Hallo Ralf.

Danke für deine Statements.
Hier meine Antworten dazu:

a: Hab doch meinen nanoCUL433 und möchte nicht wieder in Hardware investieren  ::)

b: Das veringert ja nicht die Anzahl der CMDs zum CUL (was manhcmal Probleme macht)

c, d: Das wären sicher Gute Möglichkeit, leider fehlt mir aber die Zeit mich intensiver damit zu beschäftigen.

Für meinen Teil würde ein setzen des "globalen" default Werts reichen. Werde meine neue Version mal am Abend testen.
Mit dieser "kleinen" Änderungen wäre es möglich wie bisher zu arbeiten und wer möchte kann "umsteigen".
Außerdem wir im neuesten branch/code auch das EEPROM nicht überstrapaziert, falls jemand noch ITrepetition attr's eingetragen hat.

Melde mich nach meinen Tests.

pOpY


Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1797
Zitat
a: Hab doch meinen nanoCUL433 und möchte nicht wieder in Hardware investieren
Einen nanoCUL kannst Du recht einfach in einen Signalduino umflashen

Zitat
c, d: Das wären sicher Gute Möglichkeit, leider fehlt mir aber die Zeit mich intensiver damit zu beschäftigen.
Die einfachste Variante dürfte (nach a) c sein.
Ich habe mir mal die intertechno.c angeschaut, ist noch einfacher als ich dachte. Ist auch nicht aufwändiger als Deine Variante.
Wenn man es in it_send () einbaut, wird es recht einfach. Als Trennzeichen müsste auch r reichen. z.B: isxxxxr12

Einfach in der Zeichenkette in von hinten nach r suchen
So könnte es ungefähr aussehen:
uint8_t it_repeat = it_repetition
wenn "r" gefunden dann
  sizeOfPackage = gefundene Postion
  it_repeat = Wert hinter r

for(i = 0; i < it_repeat; i++) {
 ..

Die notwendigen Anpassungen im IT-Modul sind auch nur minimal.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module
SIGNALduino

Offline popy

  • Jr. Member
  • **
  • Beiträge: 62
Hallo Ralf.

Danke für deine Erklärung.
Ich sehe aber nicht ganz den Vorteil Gegenüber Meiner Lösung in Anbetracht auf Traffic.
So müsste bei jedem Schaltbefehl der rXXX mitgegeben werden.
Das ersparen wir uns bzw. dem CUL mit meiner Lösung.
Mir ist klar das es bei meiner Lösung keine seperaten repetitions für einzelne Geräte gibt (Wozu auch?).

@bjoernh: Würde mich auch über deinen Kommentar freuen.

PS: OP update mit neuer, getesteter Version. Da gibt es nun nicht mehr das Problem dass das EEPROM Schaden tragen könnte.

thx
pOpY


Offline popy

  • Jr. Member
  • **
  • Beiträge: 62
Hab mal einen pull request abgesetzt: https://github.com/heliflieger/a-culfw/pull/15

pOpY