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

RaspiLED

Spoiler:

Im MC nutzt man * um alle Dateien zu markieren ;-)

Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

noansi

Hallo Testwillige,

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

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
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR

AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_34_FHEM_Modules_00_47.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3 , TSCUL_V3_RFR, TSCUNO2, TSCOC und TSSCC. (TSCUL_V3_RFR ist ohne HM Unterstützung, also nur SlowRF)

Die tsculfw Firmware kann für TSCUL_V3, TSCUL_V3_RFR (via USB), TSCUNO2, TSCOC, TSSCC, TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden. Bei CUNO2 und SCC muss die Bootloadertaste gedrückt werden, bis der Flashvorgang anläuft.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann z.B. TSCUL_V3.
Beispiel:
TSCULflash MeinCulV3Device TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: Nach dem flashen von TSCUL kann es sein, dass das Betriebssystem TSCUL eine neue Schnittstelle zuweist und ggf. auch anderen USB devices. Auf Linux mit "dmesg" heraus zu lesen.
Auch beim Neustart des Systems kann sich die Reihenfolge ändern. Bei meinem Raspi sogar abhängig von der Startart Reboot oder Einschalten.
Für CULs mit nativer USB Schnittstelle (z.B. CUL V3.x oder CUN) kann die \Firmware\tsculfw-code-459-trunk_lufa_00_08\culfw\Devices\99-usb-serial.rules nach /etc/udev/rules.d/99-usb-serial.rules kopiert werden. Dann wird CUL stets der Schnittstelle /dev/CUL868_0 (oder /dev/CUL433_0 bei 433.9MHz Version) zugewiesen und er kann mit
define CUL_868 TSCUL /dev/CUL868_0@12000000 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX
define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000
die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

Das geht leider nicht bei nicht nativen USB CULs wie z.B. nanoCUL oder CUNO2. Hier muss eine 99-usb-serial.rules nach den Daten in der dmesg Ausgabe erstellt oder modifiziert werden, um den gleichen Effekt zu erzielen, sofern der USB-Seriell Interfacebaustein eine eindeutige Seriennummer liefert.
Ansonsten kann es noch mit der USB-Schnittstelle probiert werden, an der CUL eingesteckt ist ("lsusb" Ausgabe), was an meinem RasPi aber nicht funktioniert hat, da dieser abhängig von Warmstart oder Kaltstart andere USB-Portnummern vergibt.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000

Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:
define CUL_868 TSCUL 192.168.178.111:2323 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000
beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:
define CUNO2_868 TSCUL 192.168.178.110:2323 0000

Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp respektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

00_TSCUL.pm         -> statt der 00_CUL.pm, aus CUL devices werden damit TSCUL devices in der fhem.cfg (händisch anzupassen)
DevIoTS.pm            -> verbesserte Version von DevIo.pm für die TS Module
16_TSCUL_RFR.pm -> der 16_CUL_RFR.pm, aus CUL_RFR devices werden damit TSCUL_RFR devices in der fhem.cfg (händisch anzupassen)
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)
97_timerTS.pm           -> Austausch-Timerroutinen und fhemFork()

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL IO-devices zu verwenden, aus UNIRoll wird dann UNIRoll_TS  in der fhem.cfg (händisch anzupassen)
13_TSKS300.pm     -> statt der 13_KS300.pm, mit TSCUL IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL IO-devices zu verwenden, aus CUL_TX wird dann TSCUL_TX  in der fhem.cfg (händisch anzupassen)
14_TSCUL_WS.pm   -> statt der 14_CUL_WS.pm, mit TSCUL IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
14_TSCUL_NC7427.pm  -> NC7427 Unterstützung
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
ReadingUtil.pm          -> Hilfsroutinen für Readings

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

98_fhemdebug.pm     -> fhemdebug zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details
10_IT.pm                   -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert. Nur diese Version bietet derzeit vollständige TSCUL/tsculfw Unterstützung.
HMConfig.pm             -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm           -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
98_HMtemplate.pm   -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden.
Die 4 Dateien entsprechen einem Stand von Mitte 02/2020. Derzeit sollten diese verwendet werden.

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

98_autocreate.pm       -> autocreate mit TSCUL Unterstützung

98_Cumulate               -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm         -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.


Wie immer, vor Austausch und Veränderungen der Module und fhem.cfg, erst Backup dann Ändern!

Mit folgendem Eintrag (oder Ergänzung des attributs) in der fhem.cfg kann man das fhem Update am ungewollten Austausch der angepassten Module hindern:
attr global exclude_from_update 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 14_TSCUL_NC7427.pm ReadingUtil.pm 97_timerTS.pm 98_TSCULflash.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm 98_HMtemplate.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.pm 98_fhemdebug.pm

Hier https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057 noch Rudolfs Tip zur Aktualisierung des Commandref  nach dem Kopieren/Austausch der Dateien so dass dann auch Doku zur Nutzung zu lesen ist.
fhem> { `perl contrib/commandref_join.pl` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.34 ab. Eine ältere Version wird also nicht unterstützt!

Frequenzoffset: Für HM ist ein Frequenzoffset von -20.6kHz im EEPROM als default in der tsculfw hinterlegt (das ist ein individuelles Optimum für meinen COC). Dieser Frequenzoffset kann mit set hmFreqOffs umgestellt werden. 0 ist default in der Standard-culfw.
Wenn also keine Antwort von angesprochenen HM devices kommt, dann hmFreqOffs von 0 ausgehend verstellen. CUNX z.B. geht eher in Richtung + mit dem Offset.
Wer das Frequenzspektrum sichtbar machen kann, kann sich die optimale Mitte aller devices ermitteln und mit dem Offset sein CUL dazu passend einstellen.

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.
Mit dem Attribut "hmForceLzyCfg" kann wakeup und keep awake support bei solchen CULs aktiviert werden. Das erhöht den EEPROM Verschleiß beim Lesen oder Verändern von Registerwerten bei wakup und lazy config devices.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Hier geht es zur vorherigen Version https://forum.fhem.de/index.php/topic,24436.msg1013844.html#msg1013844.

Gruß, Ansgar.

EDIT: zip nochmal aktualisiert, da mir noch ein Fehler bei wakeup aufgefallen ist.
EDIT2: zip nochmal aktualisiert. Kleinere Änderungen an den FHEM Modulen.
EDIT3: zip nochmal aktualisiert. Änderungen an den FHEM Modulen.
EDIT4: zip nochmal aktualisiert. Änderungen an den FHEM Modulen. 97_timerTS.pm ist jetzt erforderlich zu nutzen, da damit fhemFork() ersetzt wird. timerTS, apptime, apptm aktualisiert. fhemdebug ergänzt.
EDIT5: zip nochmal aktualisiert. Änderungen an den FHEM Modulen.
EDIT6: zip nochmal aktualisiert. Änderungen an den FHEM Modulen.

noansi

Hallo zusammen,

ich habe das obige zip nochmal aktualisiert auf TSCUL_fwcode_00_34_FHEM_Modules_00_45_1.zip, weil mir noch ein Fehler in der Firmware beim wakup aufgefallen ist.

Gruß, Ansgar.

fredje

Hallo,
Ich benutze einen CUL mit der original Firmware V1.66 und habe immer wieder Verbindungsprobleme.
Nun habe ich von  Beta-User erfahren das es für den CUL eine alternative Firmware gibt die das
beheben könnte.

Meine Fragen.
1.) Kann ich die hier beschrieben Firmware in meinen CUL Stick installieren.
2.) Muss ich nach der Installation alle HM Devices neu anlernen.
3.) Gibt es eine Installationsbeschreibung
4.) Wo kann ich die älteren Versionen dieser Firmware Downloaden, möchte nicht gerne auf eine ganz neue Firmware wechseln

Vielen Dank

Internals:
   CMDS       BbCFiAZNkGMKUYRTVWXefmLltux
   CUL_0_MSGCNT 38807
   CUL_0_TIME 2020-02-13 06:19:46
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM0@9600 1034
   DeviceName /dev/ttyACM0@9600
   FD         11
   FHTID      1034
   FUUID      5c9374e9-f33f-2f85-c01f-aab9dd0c79d66a67
   NAME       CUL_0
   NR         55
   NR_CMD_LAST_H 7
   PARTIAL   
   RAWMSG     A0D9180414E71F146AE070732008004
   RSSI       -72
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.66 CUL868
   initString X21
Ar
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2020-02-07 15:31:40   cmds             B b C F i A Z N k G M K U Y R T V W X e f m L l t u x
     2016-11-01 14:26:06   raw             V 1.66 CUL868
     2020-02-13 06:19:46   state           Initialized
   XMIT_TIME:
     1581567609.75294
     1581567746.65337
     1581567911.04719
     1581568297.22579
     1581568422.47627
     1581568568.127
     1581569225.17211
   helper:
     000000:
       QUEUE:
     410247:
       QUEUE:
     46AE07:
       QUEUE:
     48C747:
       QUEUE:
     4AB3E0:
       QUEUE:
     4DA3E0:
       QUEUE:
     4DB039:
       QUEUE:
     4DE7DA:
       QUEUE:
     4E4901:
       QUEUE:
     4E71F1:
       QUEUE:
     5E5701:
       QUEUE:
     5E6553:
       QUEUE:
     5F7EB8:
       QUEUE:
     5F7ECE:
       QUEUE:
     609DB7:
       QUEUE:
     609DBE:
       QUEUE:
     60A7CD:
       QUEUE:
     63E118:
       QUEUE:
     669C1F:
       QUEUE:
     669C21:
       QUEUE:
     669C42:
       QUEUE:
     669C9F:
       QUEUE:
     669CB4:
       QUEUE:
Attributes:
   group      CUL,
   rfmode     HomeMatic
   room       System
   verbose    2



MadMax-FHEM

#949
1) sollte gehen (bzw. müsstest du genauer schreiben was für ein CUL: Controller)

2) wenn du es nach Anleitung machst, also "bestehenden" CUL "abändern" (und du eine HMID vergeben hast/diese kennst): nein!!!

EDIT: ok keine HMID gesetzt, sollte sich aber durch die FW nicht ändern. Besser wäre eine gesetzt zu haben (falls du den CUL mal tauschen musst). Und auch besser eine vccu zu haben (wurde aber glaub ich im andern Thread auch schon erwähnt)...

3) im ersten Post sollte alles stehen...

4) weiß nicht, ob wo ältere sind. Aber: wozu!!!?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

RaspiLED

#950
Hi,

OT: hier ist die Source für die a-culfw

https://github.com/heliflieger/a-culfw

Hier die Firmware als Download:

https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw

Nimm die neueste! Haben wir zu Hunderten hier Forum ;-)

EDIT: Ich war im falschen Thread! Sorry. Die TS CUL FW ist viel besser für Homematic! Also vergesst die Links von mir, die sind nur bei Themen wie IT oder anderen Sonderwünschen, aber nicht für Homematic! Danke noansi für Deine coole Arbeit!

Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

noansi

Hallo Arnd,

wärst Du so nett, wenn Du schon links auf die a-culfw in diesen Thread verteilst, darauf aufmerksam zu machen, dass die keinesfalls was mit der tsculfw zu tun hat und für HM ebenso ungünstig, wie die culfw ist. Danke!
Darauf aufmerksam machen, das erst Lesen und dann möglichst konkret Fragen die bessere Methode ist, um im FHEM Forum Antworten zu bekommen, bitte nicht mit solchen Fehlleitungen bitte auch nicht mit solchen versehentlichen Fehlleitungen.

@fredje: Wenn Du ein bischen nach oben scrollst, dann findest Du auch den link auf die Vorgängerversion der tsculfw und der zugehörigen FHEM Module, wenn Du was älteres willst. Zu Deinem CUL, scheint per USB angebunden zu sein und vermutlich ein CUL V3 zu sein? Was Du hast, kannst Du auf der CUL Platine ablesen, wenn sie von Busware stammt. Das wäre das erste, was Du sicher raus bekommen musst, bevor Du ans Flashen der Firmware denkst (und fragst, wie Du die Firmware wohl flashen könntest). Wie im Zweifel ein zur Hardware passendes Firmware .hex file auf die jeweilige Busware Hardware zu flashen ist, findest Du auf der Busware Seite.

Gruß, Ansgar.

Thargor

Leider konnte ich die Info nicht finden.
Auf einem (Max) Cube ist die Firmware nicht einsetzbar. Ist das korrekt?
Vielen Dank!

noansi

Hallo Thargor,

ZitatAuf einem (Max) Cube ist die Firmware nicht einsetzbar. Ist das korrekt?
Das ist im derzeitigen Stand korrekt.

Gruß, Ansgar.

noansi

Hallo Zusammen,

ich habe oben https://forum.fhem.de/index.php/topic,24436.msg1022651.html#msg1022651 nochmal die zip Datei aktualisiert, weil sich FHEM Module (nicht die Firmware) darin geändert haben.

Gruß, Ansgar.

noansi

Hallo Zusammen,

ich habe oben https://forum.fhem.de/index.php/topic,24436.msg1022651.html#msg1022651 nochmal die zip Datei aktualisiert, weil sich FHEM Module (nicht die Firmware) darin geändert haben.

In DevIoTS.pm sind die Hinweise aus https://forum.fhem.de/index.php/topic,110125.msg1041356.html#msg1041356 eingeflossen, inklusive der Behebung der darin im Verlauf aufgefallenen Probleme, insbesondere auch mit strict "refs".

97_timerTS.pm enthält jetzt auch einen Ersatz für fhemFork() und ist damit nicht mehr optional, sondern erforderlich zu nutzen.
fhemFork() hat DevIoTS beim Schließen geöffneter Verbindungen nicht berücksichtigt. Das habe ich ergänzt. Bei mir haben sich damit keine Veränderungen im Verhalten ergeben, aber vielleicht macht es in anderen Betriebssystemumgebungen einen Unterschied, weshalb ich es ergänzt habe.

Gruß, Ansgar.

pantau

Hallo Ansgar,
ich habe jetzt mit der neusten Version der FHEM Module einen Nebeneffekt der vorher nicht auftrat. Aus Reichweitegründen betreibe ich noch einen CUBe mit a-culfw. Selbstverständlich mit der jeweiligen passenden Definition. Bisher wurden die WS und EM Sensoren sowohl von den TSCUL Devices als auch vom CUBe empfangen. Jetzt nur noch vom TSCUL. Als erstes ist mir das bei dem KS300 aufgefallen, scheint aber bei allen WS und EM so zu sein.
Ist das ein von Dir gewünschtes Verhalten?

Gruß

Peter
P.S: Es sieht so aus, als ob auch keine HMS Sensoren mehr empfangen werden, z.B. auch nicht meine (alten) RM100 Rauchmelder.

noansi

Hallo Peter,

die Lists von den CULs und den Sensoren würden jetzt helfen.

Es hängt davon ab, wie sie jeweils definiert sind.

Bei den KS300, WS und EM (und TX, NC7427) gibt es inzwischen das Attribut "dupTimeout", was per default 10 Sekunden ist.
Damit wird Mehrfachempfang der gleichen Nachricht weggefiltert.
Wenn die Sensoren nun nur jeweils einmal ohne Attribut IODev definiert sind, dann "gewinnt" die erste Nachricht und folgende gleiche (von anderen IOs) werden verworfen. Wenn TSCUL immer empfängt und schneller ist, dann siehst Du nicht, falls auch was vom CUBe kommt. Oder nur ab und zu mal was vom CUBe, wenn CUL nicht empfängt.
Du kannst das Attribut beim Sensor auf 0 setzen und damit die Filterung abschalten, dann solltest Du wieder sehen, von welchen IOs der Sensor empfangen wird.
Bringt halt nur nichts, da redundante Sensordaten, die auch verarbeitet werden müssen.

Du kannst auch zu einem Sensor zwei Sensordevices anlegen und bei denen jeweils ein anderes IODev via Attribut einstellen. Dann kommt am jeweiligen Sensordevice nur die Nachricht von seinem IODev an. Das ist aber eigentlich dafür Gedacht in zwei nicht überlappenden Empfangsbereichen unter den gleichen Sensoradressen verschiedene Sensoren (also mehr, als die eigentlich möglichen) nutzen zu können.

ZitatEs sieht so aus, als ob auch keine HMS Sensoren mehr empfangen werden, z.B. auch nicht meine (alten) RM100 Rauchmelder.
Via tsculfw? Hat das mal funktioniert? Mit welcher Firmwareversion? (Ich habe selbst keine HMS Testkandidaten)
Via CUBe aber über TSCUL definiert?

Mehr Details für die Glaskugel bitte. Bewußt habe ich HMS jedenfalls nicht den Hahn abgedreht.

Gruß, Ansgar.

pantau

Zitat von: noansi am 19 April 2020, 00:24:21
Mehr Details für die Glaskugel bitte. Bewußt habe ich HMS jedenfalls nicht den Hahn abgedreht.
Danke für die ausführliche Antwort und die Bestätigung das sich für HMS nichts geändert hat. Hatte ich zwar beim Versionsvergleich auch schon vermutet, aber nach dem Einspielen der letzten Version hatte ich das beschriebene Verhalten.
Nun habe ich den Server noch einmal neu gestartet und alles geht wieder wie zuvor. Anscheinend hatte sich der CUBe "verschluckt".
Was mir jetzt auffällt: Alle HMS (ca. 10 Stück) werden nur vom CUBe empfangen (LASTInputDev CUBe868SL).
Ich habe pro Sensor ein IODev definiert, welches dem Sensor am nächsten liegt. Da sind auch TSCUL dabei. Aber außer dem CUBe empfängt keines der TSCUL HMS Sensoren. WS und EM werden dagegen empfangen.
Zusammen mit der Tatsache das bei "verschlucktem" CUBe gar nichts empfangen wurde, vermute ich jetzt mal das die TSCUL keine HMS Sensoren empfangen, vor allem nicht meine Rauchmelder, aber auch die HMS 100T /TF nicht.
Das ist doch nicht das erwartete Verhalten?
Was kann ich probieren / testen?

Gruß

Peter 

noansi

Hallo Peter,

ZitatWas kann ich probieren / testen?

Du kannst mir erst mal verraten, mit welchem Versionstand Du meinst noch HMS mit tsculfw und TSCUL empfangen zu haben. Gerne auch nochmal im Versionsstand zurück gehen, um das auch zu verifizieren.

Hast Du den CUBe als TSCUL oder als CUL definiert?

Die Lists, um die ich gebeten hatte, stehen noch aus.

Gruß, Ansgar.