Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

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

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

Vorheriges Thema - Nächstes Thema

noansi

Hallo Byte,

was auch schon mal einfach so aufgetreten ist, dass einem CUL eine Störquelle zu Seite gestellt wurde und er damit devices nicht mehr sauber empfangen konnte oder nicht mehr gesendet wurde, da Kanalbelegung detektiert wurde.

Gruß, Ansgar.

frank

falls der hmlan öfter disconnected hat (wird ja nicht selten von einigen usern berichtet), hätte die vccu ggf doch das io gewechselt, trotz konfiguration als prefered io.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Flanders

Danke für die Info, das habe ich aber ein notify drauf. Da kam nichts an...
Ich denke, im Ergebnis ist mir die cul Geschichte zu fehlerangällig. Ich werde das wohl ausbauen...
Auf aes möchte ich nicht verzichten.

Bastel-Frank

Hallo Ansgar,

da ich schon seit langem sehr zufrieden mit deiner Firmware war/bin, bin ich auf dem Stand V0.29 stehengeblieben  :-[. Nun stellt sich heraus, dass es Probleme mit dem Modul 97_timerTS gibt, siehe https://forum.fhem.de/index.php/topic,128858.0.html.

Frage: Haben sich seit "damals" Änderungen im timerTS-Modul ergeben, die mir helfen könnten?

Viele Grüße
Frank

noansi

Hallo Frank,

Du bist mit einem alten 97_timerTS.pm unterwegs. Darin ist es noch nicht abgefangen, dass ein undefinierter Funktionsaufruf in der PrioQueues zu so einem Absturz führen kann.

In der aktuellen ist es abgefangen. Steig auf die aktuelle Version um.

Vermutlich würde es erst mal reichen, nur die 97_timerTS.pm auszutauschen, um Dein aktuelles Problem zu lösen, vermutlich.

Gruß, Ansgar.

Bastel-Frank

Zitat von: noansi am 23 August 2022, 10:37:56
Hallo Frank,

Du bist mit einem alten 97_timerTS.pm unterwegs. Darin ist es noch nicht abgefangen, dass ein undefinierter Funktionsaufruf in der PrioQueues zu so einem Absturz führen kann.

In der aktuellen ist es abgefangen. Steig auf die aktuelle Version um.

Vermutlich würde es erst mal reichen, nur die 97_timerTS.pm auszutauschen, um Dein aktuelles Problem zu lösen, vermutlich.

Gruß, Ansgar.

Ich habe das Modul aktualisiert, wie von Dir beschrieben und läuft  :). Ich danke Dir mal wieder für deinen Support.

exocet01

Zitat von: noansi am 29 April 2022, 20:05:54
Hallo exocet01,

Somfy hat bisher offenbar noch niemand getestet. Daher danke für das Feedback zu einem Bug in der Firmware bezüglich Somfy Frame Gap Länge der bisher nicht aufgefallen ist.

Im Anhang neue (HEXes) zum Testen. Ich habe diverse HEX files für unterschiedliche CUL Hardware angehangen, falls noch jemand mit testen möchte.
Bitte gib Feedback, ob es damit funktioniert. Ich habe leider selbst keine Somfy Hardware, um es testen zu können.

Nebenbei bietet diese Version auch die Möglichkeit, für Somfy einen +/- Sendefrequenzoffset (nicht remanent) mittels YoXX am CUL einzustellen. XX ist dabei eine zweistellige HEX Zahl für den Offset entsprechend cc1101 Doku nutzbar.

Gruß, Ansgar.

Hallo Ansgar, sorry für die verspätete (5 Monate  ::) ) Rückmeldung:
Habe es heute getestet. Leider funktiniert es immer noch nicht. Im Log finde ich nichts auffälliges:
2022.09.05 15:31:59 5: TSCUL_Read CUL_0: /Ci000900000000C7D3000330D200007A8D0000F3A900000256390905

2022.09.05 15:32:31 5: TSCUL/RAW CUL_0 ReadAnswer: /C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF
2022.09.05 15:32:31 5: TSCUL/RAW CUL_0 ReadAnswer: C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF /15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=2B 25=1A 26=1F 27=41 28=00 29=59 2A
2022.09.05 15:32:31 5: TSCUL/RAW CUL_0 ReadAnswer: C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=2B 25=1A 26=1F 27=41 28=00 29=59 2A/=7F 2B=3F 2C=81 2D=35 2E=09 2F=00 30=00 31=17 32=00 33=80 34=CB 35=0D 36=00 37=00 38=B4 39=FD 3A=00 3B=00 3C=00 3D=00

2022.09.05 15:32:31 2: TSCUL_ReceiveDelayed: CUL_0 No data received for long time: C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=2B 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=3F 2C=81 2D=35 2E=09 2F=00 30=00 31=17 32=00 33=80 34=CB 35=0D 36=00 37=00 38=B4 39=FD 3A=00 3B=00 3C=00 3D=00
2022.09.05 15:35:12 5: TSCUL_Read CUL_0: /Ci000DA73500011FC00004B6390000BB790001587000000591390E05

2022.09.05 15:38:27 5: TSCUL_Read CUL_0: /Ci0013000000017579000660CF0001056B0001C70800000A77390905

2022.09.05 15:39:00 5: /dev/ttyACM0 closed by CUL_0
2022.09.05 15:39:00 2: TSCUL_condUpdateHM: CUL_0 new condition disconnected
2022.09.05 15:39:00 3: Opening CUL_0 device /dev/ttyACM0
2022.09.05 15:39:00 3: Setting CUL_0 serial parameters to 9600,8,N,1
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 ReadAnswer: /VTS 0.40 CUL433

2022.09.05 15:39:00 5: dummy V CUL_0 VTS 0.40 CUL433
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l t x

2022.09.05 15:39:00 5: CUL_0: Possible commands: ABCFGJKRUVWXYeiltx
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 ReadAnswer: /CUL_V3.4_0017

2022.09.05 15:39:00 5: VH CUL_0 CUL_V3.4_0017
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 ReadAnswer: /A?At1

2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 ReadAnswer: /AF1020006DFE80004TiMeStAmP80

2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 ReadAnswer: /AL

2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 ReadAnswer: /AS00/D1

2022.09.05 15:39:01 5: TSCUL_DoInit CUL_0 {ids} built
2022.09.05 15:39:01 1: CUL_0 is VERSION_TS, VTS 0.40 CUL433, CUL_V3.4_0017
2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 ReadAnswer: /A?At0

2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 ReadAnswer: /AF1020006E0800004TiMeStAmP80

2022.09.05 15:39:01 2: TSCUL_condUpdateHM: CUL_0 new condition non-HM
2022.09.05 15:39:02 5: TSCUL/RAW CUL_0 ReadAnswer: /AHF11034

2022.09.05 15:39:02 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:02 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:02 3: CUL_0 device opened


noansi

Hallo exocet01,

in Deinem Log Auszug ist außer der Initialisierung des CUL kein Sendebefehl zu sehen.
Ein Y Kommando sollte auftauchen, ohne wird auf jeden Fall nichts gesendet.

Gruß, Ansgar.

hackepeter

Hallo,

welche der unterstützten Hardware-Module kann denn für einen Selbstbau-cul empfolen werden? 
Gibts auch was mit LAN unterstützung? Ansonsten USB.

Von wo kann man aktuell einen funktionierenden CC1101 beziehen?

Ich nutzte die letzten Jahre einen Nano, allerdings habe ich mir den soeben zerschossen - incl CC1101.

noansi

Hallo Hackepeter,

wenn Du die TSCUL Firmware und HM nutzen möchtest, ist viel SRAM sinnvoll, da dann nicht das EEPROM als Listenspeicher herhalten muss, wie beim nano.

Was ATMEGA1284P basiertes passt also gut. Und dazu habe ich bisher nur das megaCUL Projekt gesichtet https://github.com/damianmelson/megaCUL-868MHz.
Für HM würde ich WLAN aber gleich weg lassen, um gar nicht erst in die Versuchung zu geraten, in WLAN Delay bedingte Probleme/Enttäuschung zu geraten. Damit also nur USB.

Die Bastelausstattung muss so weit reichen, auch den Bootloader auf den ATMEGA flashen zu können, nebst richtigem setzen der FUSE Bits.
Und in der dort vorgestellten kleinen Bauform mit SMD Bestückung natürlich auch entsprechendes Lötwerkzeug und eine ruhige Hand und gute Augen vorrausgesetzt.  ;)

Eine Device Config für megaCUL hatte ich mal im Source integriert, aber es gibt bisher kein Feedback dazu. Meinerseits ist sie ungetestet (bis auf kompilieren).

Mit mehr Hirnschmalz anhand des Schaltplans sicherlich auch in Lochraster realisierbar. Dann könnte man mit einem ENC28J60 basiertem Ethernet Modul auch eine LAN Schnitstelle dazu basteln, wie es bei CUNO2 genutzt wird. Somit also softwareseitig mit etwas Zusatzkonfigurationsaufwand und Hirnschmalz in der board.h auch LAN möglich wäre.

SCC auf RPi ist für deutlich weniger Bastelleidenschaft auch noch möglich (am besten mit abgesetzter Antenne), aber das hat dann nichts mit USB zu tun.

Für Quick, billigst und Dirty (und langweilig  ;) ) landest Du vermutlich wieder bei einem nanoCUL.

Gruß, Ansgar.

presskopf

Zitat von: noansi am 13 September 2022, 22:14:56

Für HM würde ich WLAN aber gleich weg lassen, um gar nicht erst in die Versuchung zu geraten, in WLAN Delay bedingte Probleme/Enttäuschung zu geraten. Damit also nur USB.


Hi Ansgar,
hältst Du die Kombination aus TSCUL und WLAN wirklich für so kritisch?
Ich habe z.B. einen Rasperry per WLAN im Netzwerk, welcher über ser2net einen nanoTScul bereitstellt. Der funktioniert eigentlich ganz gut.
Nur ab und zu verliert er den Kontakt. Ein Reopen fixt es dann in der Regel. Wobei der Empfang aber auch solala ist.

Mein Gedankengang war aktuell auch mal eine Bereitstellung des nanoTScul per esp8266 (Wemos D1 Mini) aufzusetzen. Da gibt es ja bereits einige gute Erfolge (z.B. minicul, Signalduino-Wemos).
(https://forum.fhem.de/index.php/topic,42998.msg349938.html#msg349938
https://forum.fhem.de/index.php/topic,69042.msg1017164.html#msg1017164)

LG
Matthias

MadMax-FHEM

Homematic ist halt sehr kritisch bzgl. Timing, deshalb ja diese spezielle FW inkl. fhem-Module, um das so gut wie möglich auszugleichen (v.a. Laufzeiten in fhem, wenn ich das richtig verstanden habe).

Wenn dann noch Netzwerk-/WLAN-Latenzen dazu kommen, wird es nicht besser (bzw. weiß ich nicht, ob das die TSCUL-FW/Module ausgleichen können)...

Es gibt auch ESP mit dem HMOD-PCB ("Original-Homematic-Funkplatine", die ja schon einiges macht, z.B. autom. ACKs, soweit ich weiß) wo es sogar damit manchmal hakt.

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)

frank

hallo ansgar,

in deiner cul_hm ab zeile 3465:
      if ($mh{md} =~ m/^(HM-SEC-SC.*|ROTO_ZEL-STG-RM-FFK)$/s){# SCs - depending on FW version - do not accept ACK only. Especially if peered
        if (DOTRIGGERSTATEACK) {
          push @ack,$mh{shash},$mh{mNo}.'8002'.$ioId.$mh{src}.'0101'.((hex($mI[0])&1)?'C8':'00').'00';
        }
      }


damit wird das "zusätzliche" ack immer mit status 0xC8 gesendet, wenn der channel ungerade ist!!!
also immer falsch (da es 1-channel devices sind), wenn der status eigentlich 0x00 ist.
was soll hier dieser bit vergleich? was hab ich übersehen?

ich habe bei mir jetzt einfach
push @ack,$mh{shash},$mh{mNo}.'8002'.$ioId.$mh{src}.'0101'.$mI[2].'00';
gesetzt und die folgende log meldung ebenfalls angepasst
      Log3 $mh{devN},5,'CUL_HM '.$mh{devN}.' prep ACK for '.$mI[2];
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

noansi

Hallo Frank,

ich habe mal in meiner "Historie" geschaut.

Zitatpush @ack,$mh{shash},$mh{mNo}.'8002'.$ioId.$mh{src}.'0101'.((hex($mI[0])&1)?'C8':'00').'00';
stammte in Semantik nicht von mir.
Ursprünglich lautete die Zeile:
        push @ack,$mh{shash},$mh{mNo}."8002".$mh{dst}.$mh{src}."0101".((hex($mI[0])&1)?"C8":"00")."00";

Ich habe nur den Hashzugriff ein bischen optimiert. Ansonsten zu dem Zeitpunkt nicht über Sinn oder Unsinn der Bit 0 Unterscheidung nachgedacht, zumal ich es nicht testen konnte und dem Kommentar bezüglich Version nach auch nicht kann.
Ich weiss auch nicht, ob die betroffenen devices/FW Versionen was gesendet haben/senden, was diese Unterscheidung sinnvoll erscheinen ließ. Da müsstest Du bei Martin nachfragen.

Nach Deiner Begründung erscheint es merkwürdig???
Du kannst ansonsten wohl nur beobachten, ob Deine Änderung in der Usermasse auf Probleme stößt und dann ggf. mit Logging Beobachtungsdaten untersuchen.

Gruß, Ansgar.

noansi

Hallo Matthias,

mit WLAN fügst Du dem Zufallsprozess HM Empfang den weiteren Zufallsprozess WLAN Empfang hinzu.

Die tsculfw kann (ebenso wie auch andere HM IOs) nur begrenzt automatisch Antworten an devices senden, um von sich aus "in time" bleiben. Antworten von FHEM müssen auch rechtzeitig gesendet werden. Insbesondere Batterie betriebene devices schlafen sonst (zu) schnell wieder ein.

Wenn es nur darum geht, den Status von Sensoren, wie Temperatursensoren, zu empfangen und an FHEM zu schicken, mag die WLAN Lösung zufriedenstellend arbeiten.
Wenn es um Schalten oder Config geht, zeigen sich erst WLAN bedingte Verzögerungsprobleme auf dem Weg vom/zum IO.

Ich habe nichts dagegen, wenn Du mit Deiner WLAN-Anbindung für Dich zufriedenstellende Ergebnisse erzielst. (Für mich persönlich wären schon die von Dir genannten gelegentlichen Verbindungsverluste ein No Go.)

Supporten möchte ich es aber nicht, da der rechtzeitige Versand von HM Paketen ans IO nochmals problematischer wird. Die Info, dass WLAN im Spiel ist, kommt vom User dann ebenfalls zufällig. Und zu erwarten nach Analyse von Timingdaten nicht durch den User, nebst sinnlosen Grübeln, welchen Fehler denn der Programmierer gemacht haben könnte. Denn auch FHEM selbst kann Quelle von Timing Problemen sein.

Gruß, Ansgar.