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

blue55 · 20 Mai 2021, 20:51:52

Hallo Ansgar,

danke dir die Antworten und das raussuchen der Threads.
Ich update mal den Bootloader und schaue mal ob sich dann die Erreichbarkeit des nanoCULs verbessert.

Viele Grüße,
Fabian

noansi · 30 Mai 2021, 14:33:08

Hallo Zusammen,

hier https://forum.fhem.de/index.php/topic,24436.msg853733.html#msg853733 ist der patch für das flash-ota tool aktualisiert, damit es auch mit VTS 0.34+ klappt. Außerdem ist es damit möglich, mit einem gestapelten CUL einen ota flash auszuführen.

Gruß, Ansgar.

Adimarantis · 22 Juli 2021, 22:32:36

Hallo,

mich würde interessieren, ob man diese Fernbedienung (wohl eine Art Garagentorsender) über nanoCUL ansteuern kann. Ich befürchte ja die sind verschlüsselt, wobei es diese Fernbedienungen generisch zu kaufen gibt und man sie ja auch anlernen kann (anscheinend sogar Fernbedienung zu Fernbedienung).
Meine NanoCUL 868 empfängt denke ich mit SlowRF etwas, ich kann die messages jetzt aber nicht exakt zuordnen da entweder auch gesendet wird, wenn man nichts auf der Fernbedienung drückt oder andere Sender in der Nachbarschaft reinfunken (oder triggert Homematic auch etwas auf SlowRF?)

Anbei mal Fotos von Fernbedienung und Packung sowie ein Ausschnitt aus meinem FHEM Log der TSCUL mit verbose=5
Wäre halt echt Klasse wenn sich das "knacken" liesse. Mein Ziel ist Sprachsteuerung über Google anstatt ewig die Fernbedienung zu drücken (die hat nämlich auch noch eine "Totmannschaltung", man muss den Knopf also ewig gedrückt halten.)

Gruß,
Jörg

noansi · 23 Juli 2021, 22:24:47

Hallo Jörg,

zuallererst, Dir ist aufgefallen, dass Deine Geragentorfernbedienung eine Totmannfunktion mittels Drücken der Taste bis Abschluss der Torbewegung hat.
Damit ist sicherlich verbunden, dass die Torbedinungsautomatik keine sonstigen ausreichenden Sicherheitseinrichtungen bezüglich Auffahrt auf ein Hindernis, z.B. ein Lebewesen hat! Das bedeutet, Du bist die einzige und verantwortliche Sicherheitseinrichtung, um in einem solchen Fall die Torbewegung durch Loslassen der Taste zu stoppen! Bei einem normalen Garagentor mit Kippmechanik kommen an den Armen durch Hebelwirkung auch erheblich höhere Kräfte zusammen, als es auf den ersten Blick den Anschein haben mag!
Es ist keine gute Idee, so eine Sicherheitseinrichtung zu umgehen, um die Bequemlichkeit zu erhöhen.

Bezüglich Funkprotkoll, ich kenne die Fernbedienung nicht.
Zunächst wäre zu klären, ob das Ding pulsmoduliert oder frequenzmoduliert sendet.
Mit dem CUL auf SlowRf kann nur pulsmoduliert empfangen werden.
Mit X39 und verbose 4 würdest Du im Log High/Low Zeiten im µs und Empfangsstatus Infos zu sehen bekommen. Das müsstest Du erst mal einstellen und dann gezielt Senden und Loggen.
In Deinem Log war nur 2 mal was mit TX3 protokollähnlichem. Also bisher nichts verwertbares. Ein mehrstündiges Protokoll würde wohl auch niemand freiwillig nach zufälligen Empfangsdaten eines irgendwann mal sendenden, unbekannten Gerätes durchsuchen wollen.

Edit: Du kannst auch noch Native1, Native2 und Native3 ausprobieren, ob da was kommt. Das wäre dann frequenzmoduliert.

Gruß, Ansgar.

noansi · 25 Juli 2021, 21:32:44

Hallo Testwillige,

Hier geht es zur nächsten Version: https://forum.fhem.de/index.php?msg=1297324

hier eine neue Version 0.39 der Timestamp Firmware und der dazu benötigten FHEM Module.

Die Version 0.39 bietet einige Timingänderungen für HM. Außerdem ist das Commandref überarbeit. Bei TSCUL werden sets und gets nun abhängig von rfmode und unterstützten Firmwarebefehlen angeboten.

Die Version 0.38 verhindert repeats für TC und TH Messages, was für virtuelle TC und TH Sensoren sinnvoll ist.
Auszug aus de Changed:
- ASKSIN repeats for TC and TH messages set to 0
- ASKSIN Ag command added, allow setting ASKSIN non FUP AGCCTRL2 value in EEPROM
Außerdem Verbesserungen in Modulen, insbesondere für virtuelle TCs und TH Sensoren.
Beim Reboot nach dem Flashen werden alle EEPROM Einstellungen auf Default gesetzt. Also alle am CUL vorgenommenen Einstellungen notieren, um sie wieder einstellen zu können.

In Version 0.37 ist der Readout des Tranceiver RX Fifos insbesondere für ASKSIN verändert. Beim Reboot nach dem Flashen werden alle EEPROM Einstellungen auf Default gesetzt. Also alle am CUL vorgenommenen Einstellungen notieren, um sie wieder einstellen zu können.
RF_Router und fast_rf sind verändert und nicht kompatibel zu vorherigen Versionen.

Version 0.36 behebt ein Überlaufproblem des RX-FIFOs des Transceivers, der zum Empfangsausfall führen konnte (fiel nur beim reinen Empfangsbetrieb ohne regelmäßiges Senden auf). Danke Stefan für den Hinweis.

Auszug aus der Changed:
- little correction in rf_native, if slowrf monitoring is active
- lacrosse emu reworked
- SlowRf reception adapted for better ESA reception with still well E and HMS reception
- generic Manchester raw send added with Gm command
- ESA send added with 'S' command
- HMS send added with 'Q' command
- IT reception corrected
- RfRouter with repeat in FastRF packet, better send timing and reduced receive timeout
- for pure USB CULs blinking while waiting on watchdog reboot and during boot/bootloader reboot with different frequencies
- message finalization with \n on PIM receive buffer full
- ASKSIN, fastRF, RF-Router, moritz, rwe, RX-FIFO Overflow detection improved

Noch als Hinweis, für HMS und ESA scheint sens 12 eine ungünstige Einstellung für den Empfang dieser Protokolle zu sein.

Diese Version bietet wakup support und keep awake Support. Für CULs mit wenig Speicher kann dies mit dem Attribut "hmForceLzyCfg" aktiviert werden, siehe auch der Hinweis zum EEPROM Verschleiß weiter unten.

Das RF-Router Ping Timing ist geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw und auch nicht zur Version 0.32.
Ergänzt ist SlowRf Empfang von Pearl NC7427 Temperatur/Luftfeuchte Sensoren. Entsprechend Kanalwahlschalter können 3 Stück empfangen werden. Zum Anlernen mittels autocreate muss der TEST Taster am Sensor gedrückt werden.

Das EEPROM Layout ist geändert und daher werden nach dem Flashen alle Einstellungen auf default zurück gestellt. Also vor dem Flashen individuelle Einstellungen, z.B. Frequenzoffsets, notieren und nacher neu einstellen.

Auszug aus der Changed:
- FULL_PA_RAMPING bugs corrected
- CCA CS thresholds setable for ASKSIN, MORITZ, HAS_RWE, RFNATIVE and MBUS with XTxy, x=CARRIER_SENSE_REL_THR, y=CARRIER_SENSE_ABS_THR as in AGCCTRL1
- SlowRf receive timing limits corrected
- SlowRf lower filter switched off by define in rf_receive_timing.h
- RFR timing/timeout shortened, FastRF CCA disabled
- auto Ci interrupt counter messages
- XP command extended to switch on auto Ci messages, AP removed as all PLL messages switchable by XP
- improvement and corrections for CUNX RS485 PIG support
- CUNX: PIG RTS controllable by USB Host for serial foward and RS485 serial forward
- CUNX: DMX interupts changed to HI priority and CC1101 interrupts to MED priority
- CUNX: USB interrupts to LO priority
- GPIOR1 used for USB USB_DeviceState
- GPIOR1 used for SERIAL STACKING stacking_ST_state

Ein Peakfilter für SlowRF Empfang ist ergänzt und mit "peakfilter" einstellbar.
In dem Zusammenhang ist auch das RF-Router Ping Timing geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw.
Außerdem kann das Senden von RF-Router Daten nach deren Empfang einstellbar verzögert werden (RfRdelay).

CCAMode wirkt nun auch auf IT-Senden und SOMY-Senden, sowie auf das Senden des RF-Router Pings. Mit fRfCCAMode kann auch das CCA Verhalten für RF-Router Senden und FastRF geändert werden.

Auszug aus der Changed:
- IT and SOMYFY use SlowRF EEPROM CCA setting now for sending
- changes in SlowRF reception for reset and sync start. IT V1 reception tested succsessfully.
- SlowRF filter and match adaption
- SlowRF spike filter improved, max. peak lenght settable with Xpxx, xx hex time in 8us units
- IR receive/transmit pause during send of SlowRF changed to not globally switching off all interrupts
- periodic RF-Router ping RSSI display as "Cuxx\r\n" with xx = RSSI Hex
- RF-Router ping timing changed for better distinguish from other protocols
- RF-Router pre silence before send settable with uRxx, xx hex time in 4ms units
- Xrrt commands bits:
rr:
report known protocol data Bit 0
report repeated data Bit 1
report received bits Bit 2
report 'r' (rising) or 'f' (falling) edge, '.' (collect) or '?' (sync) timeout Bit 3
report edges, bit times and timeouts Bit 4
report S300 data with valid checksum only Bit 5
report FHT Bit 6
report 'l' RSSI decimal data continuosly Bit 7
t:
report recorded SlowRF timing Bit 0
- corrections in interrupt flag clearing
- correction in delay function
- fastRF bug corrected, untested
- EEPROM layout changed for the new parameters

TSCUNX kann mit entsprechendem RS485 Modul nun auch DMX.
Auch HM485 ist für TXCUNX angepasst.
In dem Zuge ist auch die DMX Funktionalität bei CUNO2 etwas erweitert.
IR läuft nun auch richtig mit TSCONO2.
Außerdem läuft RF-Router auf der tsculfw, allerdings mit einer Änderung. Das 'U' ist durch '~' ersetzt. 'U' kollidierte mit dem Uniroll Senden.

Kurzer Auszug aus der CHANGED:
- IO optimizations CUNX, especially to/from PIM and Ethernet
- CUNX DHCP non blocking operation
- IO optimizations
- HM485 support for CUNX (like CUNO2) with RS485 PIM.
HM485 switch off with Hx for CUNX. With CUNX after Hx RS485 PIM again accessible via PIM USB or Ethernet Interface
- CUNX support for DMX and HM485 with RS485 PIM (to be tested), a Dwxxxxyy switches to DMX via CUNX Interface, a Hsxxxxxxxxxxxxxxxxxx switches to HM485 via CUNX Interface
- DMX switch off with Dx. With CUNX after Dx RS485 PIM is again accessible via PIM USB- or Ethernet Interface
DMX flexible channel usage. Channels are sent out upto the highest channel set (0 sent as default for unset channels). With switching off with Dx the highest channel is reset.
DMX changed in timing and resting behaviour. Rests on IDLE if less then 24 device, only, to keep 1204µs min. BREAK to BREAK (to be tested)
DMX Dt command to set/view timing of MarkAfterBreak and BREAK
DMX less disturbed while sending SlowRF
- W function gives feedback after writing EEPROM
- clock timer unburdened, may impact onewire and fht (to be tested)
- corrections for IRTX
- IR base timings changed to 12500Hz or 20000Hz
- RF-Router working, but 'U' changed to '~' (definable in board.h, but 'U' disables HAS_UNIROLL)

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit