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

noansi · 15 Januar 2020, 21:15:58

Hallo Rudolf,

ich würde gerne die Version 0.33 der TS Firmware hier einstellen und habe auch schon die alte 0.31 und 0.32 gelöscht.
Leider erlaubt mit das Forum nicht, die neue zip mit 9541585 Bytes anzuhängen, ohne Fehlerhinweis. Es erscheint nur die Seite für ein neues Thema.
Ein neues Thema hilft auch nicht, die Dateigröße wird nicht akzeptiert.
Ist das ein Bug beim Server?

Gruß und Danke, Ansgar.

frank · 15 Januar 2020, 21:22:17

hallo ansgar,

schon damals bei der einführung der vccu musste attr iodev aus "kompatibilitätsgründen" mit fhem existieren.
bis heute gibt es "attr sparfüchse", die durch weglassen des attributes nachweislich in probleme geraten. https://forum.fhem.de/index.php/topic,100911.0.html

ich finde es kontraproduktiv, wenn du hier etwas anderes propagierst. gerade weil die vccu nicht nur für cul derivate mit deiner firmware und deiner angepassten und "veralteten" cul_hm version angeblich funktioniert.

ebenso gibt es probleme im vccu betrieb bei devices, die kein zusätzliches attr iogrp benutzen. also mit vccu immer beide attribute nutzen.

gruss frank

noansi · 15 Januar 2020, 22:56:43

Hallo Frank,

Hier der code zu IOWrite aus der aktuellen fhem.pl:

Code Auswählen

#####################################
sub
IOWrite($@)
{
  my ($hash, @a) = @_;

  my $dev = $hash->{NAME};
  return if(IsDummy($dev) || IsIgnored($dev));
  my $iohash = $hash->{IODev};
  if(!$iohash ||
     !$iohash->{TYPE} ||
     !$modules{$iohash->{TYPE}} ||
     !$modules{$iohash->{TYPE}}{WriteFn}) {
    Log 5, "No IO device or WriteFn found for $dev";
    return;
  }

  return if(IsDummy($iohash->{NAME}));

  no strict "refs";
  my $ret = &{$modules{$iohash->{TYPE}}{WriteFn}}($iohash, @a);
  use strict "refs";
  return $ret;
}

Da sehe ich $hash->{IODev} und nicht das Attribut. Schreiben an das IO geht also über $hash->{IODev}. Der Weg des IODev in $hash->{IODev} führt allerdings normalerweise über das Attribut IODev bei FHEM-Start. Und bei neuen devices in der Regel auch über AssignIOPort(), wie Rudolf schon geschrieben hat. Bei CUL_HM gibt es aber Abweichungen von der Regel, weil es da auch noch die RSSI abhängige IO Zuweisung gibt.

Zitatdeiner firmware und deiner angepassten und "veralteten" cul_hm version angeblich funktioniert.

Nun, ich habe hier ein SCC und ein CUNX auf tsculfw an einer VCCU laufen und habe extra nochmal getestet (mit Taste an HM-Dis-EP-WM55), ob geht, was ich geschrieben habe. Und es funktioniert, sogar mit automatischem IO Wechsel nach RSSI. Allerdings ohne HMLAN oder HMUARTLGW und mit der veralteten, angepassten 10_CUL_HM Version. Dazu hatte ich aber auch was geschrieben.

Und wenn ich in meine Änderungen am 10_CUL_HM Code schaue, dann habe ich an diversen Stellen auch eine Abfrage auf die VTS Firmware eingebaut. U.a. auch an der Stelle mit AES. Mit Mischbetrieb mit HMLAN oder HMUARTLGW kann es also durchaus zu Problemen kommen, wenn das Attribut fehlt. Ich kann es nicht testen und hatte wohl damals für andere IOs als TSCULs Kompatibilität zum "Standard" zu halten versucht. Insbesondere in der Hoffnung, dass Martin es übernimmt. Dazu ist es aber leider nicht gekommen.

Gruß, Ansgar.

noansi · 16 Januar 2020, 19:57:47

Hallo Testwillige,

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

Diese Version bietet einige Verbesserungen für SlowRF Empfang und RF-Router.
In dem Zusammenhang ist auch das RF-Router Ping Timing 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

Code Auswählen

TSCULflash <nanodevicename> TSnanoCUL
bzw.

Code Auswählen

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

Code Auswählen

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_33_FHEM_Modules_00_44_2.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:

Code Auswählen

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:

Code Auswählen

#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

Code Auswählen

define CUL_868 TSCUL /dev/CUL868_0@12000000 1234
bzw.

Code Auswählen

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

Code Auswählen

define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000
oder für PIGATOR an CUNX

Code Auswählen

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:

Code Auswählen

define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.

Code Auswählen

define CUL_433 TSCUL /dev/CUL433@38400 0000

Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:

Code Auswählen

define CUL_868 TSCUL 192.168.178.111:2323 0000
oder für PIGATOR an CUNX

Code Auswählen

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:

Code Auswählen

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)

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.

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.
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.
Die 3 Dateien entsprechen einem Stand von Mitte 12/2019. Seither gab es viele Änderungen, so dass entweder diese 3 verwendet werden müssen oder die 3 aus aktuellem Update (meinerseits nicht getestet und der EEPROM-Verschleißhinweis unten ist zu beachten).

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

97_timerTS.pm -> optional, Austausch-Timerroutinen. Wenn es nicht genutzt werden soll, dann löschen oder umbennen.
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

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:

Code Auswählen

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 97_timerTS.pm 98_TSCULflash.pm 97_timerTS.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.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.

Code Auswählen

fhem> { `perl contrib/commandref_join.pl` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.33 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

Code Auswählen

attr HMdeviceName IOgrp VCCU
setzen, sondern

Code Auswählen

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.

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

Code Auswählen


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:

Code Auswählen


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.msg984185.html#msg984185.

Gruß, Ansgar.

~~Edit: Sourcen im nächsten Beitrag.~~
Edit: Bug in 14_TCUL_WS.pm bezüglich Regenoffset oder Sonnenscheinoffset behoben.
Edit: hex files für ungetestete CUL-Typen ergänzt, Feedback erwünscht

noansi · 16 Januar 2020, 20:00:53

~~Und die Sourcen kommen später, wenn mich das Forum wieder reguläre Dateigrößen hochladen läßt...~~
Im Anhang, das, was ich an Sourcen hochladen kann.
~~Im Wizchip Code für CUNX fehlt noch eine iolibrary.chm Hilfe Datei, die leider sehr groß ist und daher nicht in eine kleinere zip passt.~~
Ok, die Sourcen sind nun auch komplett.

Gruß, Ansgar.
Yeah, geht wieder.

noansi · 18 Januar 2020, 12:05:05

Hallo Testwillige,

ich habe noch einen Bug in 14_TCUL_WS.pm bezüglich Regenoffset oder Sonnenscheinoffset behoben.
Daher oben neue Version der zip.

Gruß, Ansgar.

pantau · 18 Januar 2020, 19:20:28

Hallo Ansgar,

lieferst Du die "fehlenden" HEX Files noch nach, wie z.B. rpiaddon, CUL_V4 etc?

Gruß

Peter

noansi · 18 Januar 2020, 19:48:48

Hallo Peter,

welche konkret?

Bisher gab es null Feedback zu anderen aus "untested", daher habe ich sie als hex weg gelassen.
Ein "hallo geht" würde die Motivation schon steigern.

Compilieren kann sie ohnehin mit dem Quellcode, wer mag. CULV4 ist z.B. ein Fall mit wenig RAM und von daher besser in Wunschfunktionskonfiguration (so weit umsetzbar) zu kompilieren.

Gruß, Ansgar.

pantau · 18 Januar 2020, 20:52:26

Zitat von: noansi am 18 Januar 2020, 19:48:48
Hallo Peter,

Bisher gab es null Feedback zu anderen aus "untested", daher habe ich sie als hex weg gelassen

Na das Weglassen hat doch schon ein Feedback bewirkt, oder ?

Aber ich habe noch andere Baustellen und kann erst mal keine neue Firmware in anderen CULs testen.
Apropos Baustelle:
Ich hatte mich wirklich gefreut:
KS300 original:
T: 1.7 H: 71 W: 0.0 R: 709.2 IR: no Wi: 0 D: -3.0
KS300 mit TSCUL_WS:
T: 1.7 H: 71 W: 0 R: 0 IR: no Wi: 0 D: -3.0
=> Endlich mal ein STATE der gleich ist und ich muss meine ganzen Skripte nicht anpassen! .. Pustekuchen ... $:-\$
In R: wird nicht mehr die Gesamtmenge geschrieben und IR: wird nicht von den Kontakten genommen, sondern aus der Count-Differenz berechnet....Zumindest interpretiere ich so den Code.
Muss das den sein? Die Idee von ELV zu IR war, das das bei Erkennung sofort gesendet wird und nicht erst wenn die Wippe voll ist.... Ich weiß das das nicht besonders zuverlässig ist, aber dann hätte es auch ein ODER aus Wippe und Count getan?
Bei mir steht dann im Log:
2020-01-09_10:08:08 TSCUL_WS_CUL_0_223 T: 9 H: 83 W: 0 R: 0 IR: no Wi: 0 D: 6.3
2020-01-09_10:10:40 TSCUL_WS_CUL_0_223 T: 9 H: 82 W: 0.2 R: 7 IR: yes Wi: 0 D: 6.1
2020-01-09_10:10:41 TSCUL_WS_CUL_0_223 T: 9 H: 82 W: 0.2 R: 0 IR: no Wi: 0 D: 6.1
R:7 ist die Count-Differenz, aber seit wann? Und eine Sekunde später ist R: 0? Wie ist denn ein R Wert zu interpretieren?

Und dann mal was Positives:
1.) HM ist bei mir stabiler geworden, vor allem ein CUNX (mit Pigator, als HM und SlowRF) hat viel weniger Netzwerk Reconnects. Auch mein RFR läuft deutlich stabiler.
2.) Ich kann Dir jetzt erklären, warum Du wenige SlowRF Tester hast

Gruß

Peter

noansi · 18 Januar 2020, 22:00:21

Hallo Peter,

ZitatIn R: wird nicht mehr die Gesamtmenge geschrieben

Stimmt, die steht in rainTotal.
R: ist "momentane" Regenmenge in l/h, also Zählerstandsänderung

ZitatIR: wird nicht von den Kontakten genommen, sondern aus der Count-Differenz berechnet....

Du hast wohl beim Regensensor Typ 2 geschaut.
KS300 wird so ausgewertet (Zeile 314):

Code Auswählen

my $israining = (($totalCnt!=$lastTotCnt) || ($addrnib & 0x2))?"yes":"no";
Also sowohl, als auch. Die Regensignalisierung im KS300 ist nicht 100% zuverlässig (Schmutz, schräge Aufstellung etc.). Deswegen wird sowohl eine Zählerstandsänderung, als auch eine direkte Regenerkennung als Regen in IR: signalisiert.
Sieht korrekt aus, was Du da geloggt hast, bis auf das D:, das kommt nicht vom TSCUL_WS Code.

ZitatR:7 ist die Count-Differenz, aber seit wann?

Seit ich dieses Modul so geschrieben habe, weil ich es so für sinnvoller hielt.

Du kannst den KS300 auch als TSKS300 definieren. Außerdem muss beim CUL, das ihn empfangen soll, das Attribut "KS300redirect" gesetzt sein.
Dann hast Du den alten Stand in state.

Zitatvor allem ein CUNX (mit Pigator, als HM und SlowRF) hat viel weniger Netzwerk Reconnects

Kannst Du das bitte präzisieren?
Ich kenne nur den Zustand "kein Reconnect". Oder arbeitet CUNX als RF-Router? Nur da gibt es eine mir bewusste Quelle für einen Reconnect, falls eine RF-Router Nachricht wegen erkannter Dauerbelegung des Kanals nicht abgesetzt werden kann, und das auch nur, wenn der Puffer voll ist.
Nebenbei ist CUNX + PIGATOR beide in 868MHz Variante wegen maximaler gegenseitiger Störung nicht unbedingt die beste Kombination. Ich hoffe, Du nutzt wenigstens abgesetzte Antennen mit größerem Abstand.

Gruß, Ansgar.

noansi · 21 Januar 2020, 21:38:55

Hallo Testwillige,

ich habe mal die aktuelle 10_CUL_HM.pm und die damit verbundenen Module auf TSCUL V0.33 angepasst.

Wer testen mag, im Anhang die zip Datei dazu. Alle 4 Dateien gehören ins FHEM Verzeichnis.

Wichtiger Hinweis vor einem Test (mit Feedback bitte), erst Backup von FHEM erstellen, damit der Rückweg kein Problem darstellt!!!

Da Martin seit meiner letzten Anpassung Modelaliassing eingeführt hat und in dem Zug auch Modelnammen auf Großbuchstaben umgestellt hat, ist der nächste wichtige Hinweis: Keinesfalls das Attribut "model" bei HM-devices händisch ändern!

Um sicher zu gehen, dass die Kleinbuchstaben keinen Ärger machen, habe ich das in FHEM (nach dem ersten Neustart mit neuen Modulen) durch Setzen des Attributs modelForce bei jedem HM device gemacht. Bei modelForce wird eine Auswahlliste der Modelle zur Auswahl geboten, in der das richtige Model in Großbuchstaben auszuwählen ist.
Danach dann ein Save config und FHEM Neustart, damit die damit verbundenen Änderungen auch alle durchlaufen und gesichert werden.
Anschließend habe ich die modelForce Attribute alle wieder gelöscht, wieder abgeschlossen mit Save config und FHEM Neustart.
Bei meiner eingeschränkten Testlandschaft (nur tsculfw mit VCCU und nur eine kleine Auswahl an HM-Devices) habe ich damit bisher keine unangenehmen Nebenwirkungen feststellen können.

Gruß, Ansgar.

Hotte1195 · 08 Februar 2020, 19:42:29

Hallo zusammen,

ich wollte hier mal mit testen und meine Homematic Geräte wieder in FHEM einbinden, da mir vor einiger Zeit mein HM-MOD-RPI-PCB verstorben ist

Jetzt brauche ich bitte mal Eure Hilfe:

Ich habe einen Nano V3 mit Pegelwandler und CC1101 zusammengefügt und aus dem Beitrag
https://forum.fhem.de/index.php/topic,24436.msg1013844.html#msg1013844
die TSnanoCUL.hex auf den Arduino gespielt. Baue ich jetzt unter meinem Ubuntu mir 38400B8N1 eine Verbindung auf und sende ein großes <V>
erhalte ich als Antwort <VTS 0.33 CSM868\r\n>. Soweit sollte alles funktioniert haben. Dann habe ich noch mit dem Tool von FTDI dem FT232 eine
Seriennummer vergeben. Als nächstes die Moduldateien aus dem Softwarepaket nach /opt/fhem/FHEM auf den Raspi gespielt. Rechte stehen auf 644 wie bei den anderen Modulen, Eigentümer ist fhem mit Gruppe dialout. Ein cat /opt/fhem/FHEM/00_TSCUL.pm funktioniert. Jetzt kommt der Punkt wo ich nicht weiter weiß:
ein <define nanoCUL_868 TSCUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_47110815-if00-port0@38400 1234> wird mit
<Cannot load module TSCUL> quittiert. Ein <define nanoCUL_868 CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_47110815-if00-port0@38400 1234> legt ein Device an, unter Clients wird aber nix mit *HM gelistet und ein <get nanoCUL_868 version> funktioniert auch nicht (no Answer).

Könntet Ihr mir kurz den Weg erläutern, wie ich meine Homematic Sensoren mit dem nanoTSCUL wieder in Fhem bringe?

Ich sage schon mal DANKE! im voraus!

Gruß Hotte

noansi · 08 Februar 2020, 20:13:34

Hallo Hotte,

Zitatich wollte hier mal mit testen und meine Homematic Geräte wieder in FHEM einbinden,

Sind sie noch eingebunden und vermissen nur ein IO?

ZitatAls nächstes die Moduldateien aus dem Softwarepaket nach /opt/fhem/FHEM auf den Raspi gespielt.

Eventuell musst Du dann mal FHEM neu starten, um die Modulliste zu aktualisieren.

Zitatein <define nanoCUL_868 TSCUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_47110815-if00-port0@38400 1234> wird mit

Du kannst es so versuchen, abschließend musst Du aber sicher stellen, dass der nano vor allen HM devices und VCCU in der fhem.cfg definiert wird. Außerdem Attribut rfmode HomeMatic nicht vergessen.
Wenn Du alle HM devices neu anlernen willst/musst, dann sollte es vermutlich auch so gehen. Und wenn Du schon alles neu machst, dann gleich mit VCCU.

Gruß, Ansgar.

Hotte1195 · 09 Februar 2020, 00:09:39

Hallo Ansgar,

Danke, daß Du versuchst mir zu helfen! Die HM Geräte sind noch da, IO ist natürlich weg weil kaputt.
Fhem Service ist angehalten, Dateien neu nach /opt/fhem/FHEM/ kopiert, Eigentümer gesetzt und Service danach neu gestartet.
Ich hab auch extra nochmal das Paket runtergeladen und neu entpackt, falls da was schief gelaufen ist.
Nun stehe ich vor dem gleichen Problem:ein

<define nanoCUL_868 TSCUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_47110815-if00-port0@38400 1234>

wird mit

<Cannot load module TSCUL>

quittiert. Verwende ich anstatt TSCUL nur das Modul CUL wird ein Device angelegt das IMHO nicht richtig funktioniert und auch die HM Vorteile vom tsculfw nicht nutzen kann. Oder sehe ich da was falsch? Ich bin völlig ratlos!

BG Hotte

Hotte1195 · 09 Februar 2020, 00:30:51

Och nö. Ich könnte vor Scham im Boden versinken. Warum bin ich nicht auf die Idee gekommen das fhem-2020-02.log anzuschauen? Beim Kopieren muss die Datei ReadingUtil.pm verloren gegangen sein. Ist ein blöder Bedienfehler. Ich hab zum Kopieren den MC auf dem Raspi benutzt. ReadingUtil ist die letzte Datei und die wurde immer nicht mit markiert.

Jetzt kann ich ein TSCUL anlegen und es antwortet auch

BG Hotte

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

Hotte1195

Hotte1195

Hotte1195