Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

Begonnen von noansi, 09 Juni 2014, 19:16:01

Vorheriges Thema - Nächstes Thema

Bastel-Frank

Hallo Ansgar,

wieder Mal vielen herzlichen Dank für deine tolle unermüdliche Arbeit  :)!

Soll ich in meinem Szenario nun die Dummy-Funktion nutzen, um dem Problem(-chen) mit der Fernbedienung auf die Spur zu kommen?

Viele Grüße
Frank

noansi

Hallo Frank,

Zitatich halte alle CULs auf dem gleichen Versionsstand. Ich könne die anderen CULs mal fürs anlernen mit Dummy=1 stilllegen und mit verbose 4 mitschneiden. Würde das für die Analyse helfen?
mit der Version 0.29 und den zugehörigen Modulen kannst Du nun auch mal den Test mit dummy=1 für andere CULs machen.

Wenn Du mit dummy fertig bist, dann mußt Du das Attribut dummy mit delete entfernen! dummy=0 hebt den dummy Zustand nicht auf!

Gruß, Ansgar.

MartiAn

Hallo,

ich habe gerade erst begonnen mich mit TSCUL zu beschäftigen.

Hierzu habe ich die Version V0.29 heruntergeladen und TSnanoCUL.hex auf meinen Selbstbau nanoCUL geflasht, kurz im Terminal mit einer Homematic-Fernbedienung getestet und gesehen, dass der nanoCUL die Meldungen ausgibt.

Die zusätzlichen Module wurden ins FHEM-Verzeichnis kopiert, jedoch scheitert das Einbinden des nanoCULs:
2018.08.11 20:23:32 0: CUL868HM version 0.27 is not version VTS 0.28 to 0.30, please update

Eine Überprüfung im Terminal hat gezeit, dass der nanoCUL tatsächlich unter V0.27 läuft. Dann ist mir aufgefallen, dass die TSnanoCUL.hex aus dem März ist.

Im nächsten Schritt, wollte ich TSCUL für meinen nanoCUL selbst kompilieren, so wie ich es von der normalen culfw kenne. Hier scheitert es beim Linken:
/usr/bin/avr-ld: --relax and -r may not be used together

Kurze Überprüfung mit: make SHELL="/bin/bash -x"
+ echo Linking: TSnanoCUL.elf
Linking: TSnanoCUL.elf
+ avr-gcc -mmcu=atmega328p -I. -DnanoCUL -gdwarf-2 -DF_CPU=8000000UL -Os -flto -Wall -Wundef -Wmain -Wstrict-prototypes -funsigned-char -funsigned-bitfields -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -finline-limit=20 -fomit-frame-pointer -fauto-inc-dec -fcompare-elim -frename-registers -fconserve-stack -fshrink-wrap -ftree-dce -ftree-dse -ftree-ter -mcall-prologues -maccumulate-args -mstrict-X -mrelax -Wa,-adhlns=../../clib/ir.o -I../.. -I../../clib -std=gnu99 -MMD -MP -MF .dep/TSnanoCUL.elf.d ../../clib/ir.o ../../clib/irmp.o ../../clib/irsnd.o ../../clib/serial.o ../../clib/tsculfw_ARCH_AVR8.o ../../clib/memory.o ../../clib/display.o ../../clib/ringbuffer.o ../../clib/ttydata.o ../../clib/fht.o ../../clib/rf_receive.o ../../clib/rf_router.o ../../clib/rf_send.o ../../clib/rf_credits.o ../../clib/clock.o ../../clib/delay.o ../../clib/aes_ecb.o ../../clib/rf_asksin.o ../../clib/cc1101_pllcheck.o ../../clib/spi.o ../../clib/cc1101.o ../../clib/fncollection.o ../../clib/stringfunc.o ../../clib/rf_moritz.o ../../clib/rf_rwe.o ../../clib/fastrf.o ../../clib/intertechno.o ../../clib/somfy_rts.o ../../clib/rf_mbus.o ../../clib/mbus/manchester.o ../../clib/mbus/3outof6.o ../../clib/mbus/mbus_packet.o ../../clib/mbus/crc.o ../../clib/rf_native.o ../../clib/lacrosse.o ../../clib/registry.o --output TSnanoCUL.elf -Wl,-Map=TSnanoCUL.map,--cref -Wl,--relax -Wl,--gc-sections -Os -flto -lm
/usr/bin/avr-ld: --relax and -r may not be used together

Zum einen wundert mich die Definition -DF_CPU=8000000UL, weiterhin sehe ich kein -r.

Weiß jemand Rat.

Vielen Dank und Gruß,

Martin


noansi

#738
Hallo MartiAn,

ZitatCUL868HM version 0.27
ups, sorry, da hab ich noch die älteren .hex Dateien im zip gehabt. Danke für den Hinweis!

Bitte lad das aktualiserte zip aus https://forum.fhem.de/index.php/topic,24436.msg825473.html#msg825473 nochmal runter und flashe nochmal.

ZitatHier scheitert es beim Linken
Mag an der Version liegen. Ich nutze avr-gcc 4.9.2

Zitatwundert mich die Definition -DF_CPU=8000000UL
Im Code wird ein 16MHz nano per Prescaler auf 8MHz runter geteilt, damit es mit dem Timing problemlos klappt. Das ist also richtig. Siehe auch board.h, da wird es definiert.

Gruß, Ansgar.

MartiAn

Hallo Ansgar,

ZitatBitte lad das aktualiserte zip aus https://forum.fhem.de/index.php/topic,24436.msg825473.html#msg825473 nochmal runter und flashe nochmal.
Jetzt hat es funktioniert, vielen Dank für die schnelle Reaktion.

ZitatMag an der Version liegen. Ich nutze avr-gcc 4.9.2
Ups, da liegen wohl Generation dazwischen. Mein Compiler sagt: 8.2.0.

Zitat
Im Code wird ein 16MHz nano per Prescaler auf 8MHz runter geteilt, damit es mit dem Timing problemlos klappt. Das ist also richtig. Siehe auch board.h, da wird es definiert.
Alles klar.

Gruß,

Martin

noansi

Hallo Frank,

ZitatSoll ich in meinem Szenario nun die Dummy-Funktion nutzen, um dem Problem(-chen) mit der Fernbedienung auf die Spur zu kommen?

Hast Du mal einen Test gemacht?

Gruß, Ansgar.

Bastel-Frank

Zitat von: noansi am 18 August 2018, 11:36:55
Hallo Frank,

Hast Du mal einen Test gemacht?

Gruß, Ansgar.

Hallo Ansgar,

ich habe leider noch keine Zeit gehabt. Bin im Moment beruflich viel unterwegs. Ich habe das Thema aber im Auge ...

Viele Grüße
Frank

Bastel-Frank

Hallo Ansgar,

ich habe jetzt endlich Zeit gefunden ...  ;D

Ich habe meine CULs auf die aktuelle Version gehoben und habe sie alle aktive gelassen (kein Dummy). Dann habe ich meine "Problem"-Fernbedienung zurückgesetzt und neu gepaired.

Ergebnis: Das Pairing lief jetzt durch. Aber ich muss mit der Fernbedienung einen Abstand von jetzt mind. 2 Metern (vorher waren es 5m) einhalten, damit der Austausch der CMD's funktioniert. Bei den anderen HM-Device ist der Abstand egal.

Läuft soweit ... und was bleibt mir jetzt nur noch bleibt, ist Dir für deine Super Arbeit und deine tolle Firmware zu danken!

Viele Grüße
Frank


noansi

Hallo Frank,

ZitatErgebnis: Das Pairing lief jetzt durch. Aber ich muss mit der Fernbedienung einen Abstand von jetzt mind. 2 Metern (vorher waren es 5m) einhalten, damit der Austausch der CMD's funktioniert. Bei den anderen HM-Device ist der Abstand egal.
Interessant, ich bin mir keiner Änderung bewusst, die dazu hätte beitragen können oder sollen?!
Der dummy ist dazu gekommen und Änderungen an SlowRf. Bei HM eher "Kosmetik".
Und der dummy, damit Du mal testen kannst, ob nur ein aktiver CUL in Funkreichweite zu einer Besserung bei Deinem Pairing Problem führt.
Aber vielleicht ist es jetzt auch der Batteriestand der Fernbedienung, der zu einer Verbesserung durch geringere Reichweite führt?

Hast Du alle Module genutzt oder HMInfo, CUL_HM und HMConfig nach aktuellem Stand von Martin?
Seine letzte große Änderungswelle habe ich noch nicht nachgepflegt. Der Wechsel des IOs nach RSSI ist und war unterschiedlich. Daher ist das relevant.

Gruß, Ansgar.

Bastel-Frank

Hallo Ansgar,

Ich habe seit ca. einem Monat kein Update mehr gemacht.

Die Fernbedienung hat noch die gleiche Batterie wie vorher. Den Unterschied meine ich schon auszumachen :D. Als ich den vorherigen Firmwarestand drauf hatte, hat die FB keine CMD's ausgetauscht, wenn ich in der Nähe zu meinem Haupt-CUL (mit langer Antenne) war. Mit der aktuellen Firmware klappt der Austausch der CMD's sporadisch, wenn ich in der Nähe bin. Gehe ich 2m weg (mehrfach getestet), dann kommt die Verbindung zuverlässig zustande.

Was hat sich bei Martin geändert? Was ist der Hintergrund?

Viele Grüße
Frank

noansi

Hallo Frank,

ZitatMit der aktuellen Firmware klappt der Austausch der CMD's sporadisch, wenn ich in der Nähe bin. Gehe ich 2m weg (mehrfach getestet), dann kommt die Verbindung zuverlässig zustande.
Hmm, wie schon geschrieben, derzeit unverständlich, was die Firmware oder Module damit zu tun haben sollen.
Hast Du eventuell noch das EEPROM nach dem Update zurück gesetzt? Damit hättest Du dann den Frequenzoffset zurück gesetzt, was eine Änderung hätte bewirken können, wenn der vorher nicht auf default war.

ZitatWas hat sich bei Martin geändert? Was ist der Hintergrund?
SVN sagt:
Zitatchanges for WD100 - with respect to peer handling
Und das war umfangreich. Details must Du im Forum suchen. Danach kamen noch Fixes dazu und noch ein paar Änderungen.
ZitatHMConfig:add clear msgError
Zitat98_HMInfo:improve update function - update actiondetector and vccu ...

Gruß, Ansgar.

Bastel-Frank

Hallo Ansgar,

ein Frage: Wie kann man mit deiner Firmware Firmware-Updated auf HM-Devices OTA übertragen?

Mit dem OTA-flasher kommt die Fehlermeldung "This version does _not_ support firmware upgrade mode, you need at least 1.58!"

Viele Grüße
Frank

noansi

Hallo Frank,

das sollte direkt aus FHEM raus gehen.
Beim entsprechenden HM-device set fwUpdate mit dem Namen der Firmwaredatei, die sich im FHEM\firmware Verzeichnis befinden sollte (also vorher hineinkopieren).

Gruß, Ansgar.

Bastel-Frank

Hallo Ansgar,

vielen Dank für den Tipp :-). In diesem Fall geht es darum, dass das FW-Update über fhem schiefgegangen ist und das Device keine Befehle mehr annimmt (die LED blinkt dabei sehr schnell). Dann kann man mit dem OTA-Tool eine neue Firmware mit der Angabe der Seriennummer direkt auf's Device pushen. Das Tool fragt aber fhem nach dem Versionsstand ab und erwartet eine Version >= 1.58. Da jetzt 0.29 zurückgemeldet wird, beendet sich das Tool.
Was kann man jetzt machen?

Viele Grüße
Frank

noansi

Hallo Frank,

Variante 2: Du flashst Dein CUL temporär mit der Standard Firmware und versuchst es damit.

Du hast in jedem Fall ein altes hmcfgusb Paket als Basis im Einsatz. Der letzte Stand sollte die Meldung nicht bringen.
Aber auch das aktuelle hmcfgusb ist nicht auf dem Stand für die aktuelle tsculfw. Da sind noch einige Anpassungen nötig, damit es damit klappen kann, da sich das Protokoll firmwareseits seit den letzten Anpassungen geändert/erweitert hat.
Wie lange kannst Du mit dem Zustand des ungeflashten devices leben?

Gruß, Ansgar.