Hi, ausgründen der Redundanz sowie der Funkbelastung möchte ich 2 CUL an einem device betreiben.
Wenn ich 2 CUL anschliesse bekomme ich nur eine Serial-ID angezeigt. Diese muss ich in der Definition des Device angeben.
Ein Serial by-path allerdings zeigt beide.
Wie also muss das DEF aussehen?
ZitatDiese muss ich in der Definition des Device angeben.
In der CUL Definition gibt man die FHT-ID an, das ist fuer alles ausser FHT80b- oder FHT8v-Bedienung irrelevant.
Rudi war schneller und er hat die Frage anders als ich verstanden:
geht nur mit /dev/serial/by-path/.........
Musst Du Dir dann den Platz merken. Immer noch besser als /dev/tty......
Hängst Du die per Kabel mit gutem Abstand auf ? Sonst hätte ich Bedenken.
Entweder bei beiden auf die by-path-Links verweisen, wie KölnSolar schon angemerkt hatte, oder bei der firmware-complierung vom einen eine andere als die automatische id einstellen (wenn es ATMega-mcus mit eigenen serial-Schnittstellen -ohne ftdi, z.b. - sind).
Vielen Dankeuch allen.
Aber noch einmal für die Langsamen
1) ich nutze sie für Homematic (und suche nebenbei noch die passende FW. Die aktuellen tut es, aber ich bin nicht sicher wie die aktuelle in Sachen Timestamps arbeitet - hatte noch keine Zeit...
2) ich hatte nicht vor, eine eigeen FW zu nutzen - hoffen auf Plug and Play
==>ok, die FHTID wird nicht benötigt, verstanden.
3) natürlich sollen sie zur besseren Abdeckung getrennt aufgestellt werden. Leider habe ich keine CUN(O) mehr gefunden, das hätte das Leben vereinfacht. Aktuell sind sie erst einmal an Schreibtisch. Ich habe eine "USB Verlängerung" über CAT6 Kabel - aber das wird erst später probiert.
soweit die Fakten. Als Langsamdenker erwarte ich zwar, dass ich die beiden Devices separat ansprechen kann, habe aber noch keinen Tip herauslesen können, wie ich sie in der Konfiguration unterscheiden kann (also faktisch die Adresse oder vergleichbar).
a) der "DeviceName" ist "/dev/serial/by-id/usb-busware.de_CUL868-if00@38400"
b) ls /dev/serial geht nicht mehr, gibt nur noch /dev/serial0 - unklar seit wann.
Also - stelle ich mich zu dumm an (ehrliche Antwort) oder kann man eine CUL nur betreiben und verstehen, wenn man den Code studiert - FHEM + CUL + Linux Treiber oder etwas dazwischen? So wie es jetzt aussieht fühle ich mich alles andere als sicher, dass ich bei einem Crash eine CUL wieder zum Laufen bekommen könnte - sieht mehr nach Glück aus. Das kann ich mir beim IO als Herzstück der Kommunikation nicht leisten.
Oder aber ich habe einen Beschreibung übersehen, welche mich in die Lage versetzt, die CUL wirklich sauber einzurichten.
Wie gesagt ehrliche Antworten sind am hilfreichsten
ich muss mich korrigieren, alles einmal rebootet, jetzt geht es wieder wir vor. Hm - ein boot tut gut.
Ist es also so einfach, dass ich beim define auch "by-path" nutzen kann mit der Einschränkung, dass sich der Name ändert, wenn ich ein anderes USB-port nutze?
ZitatIst es also so einfach, dass ich beim define auch "by-path" nutzen kann mit der Einschränkung, dass sich der Name ändert, wenn ich ein anderes USB-port nutze?
Genau.
Wenn du nicht die tscul-firmware verwendest und beide für Moritz zuständig sind, und dann noch keine weiteren ttyACMx dran sind, kannst du die auch einfach via dieser Kennung ansprechen. Kann halt etwas dauern, bis die vccu dann wieder auf der Spur ist...
danke euch allen.
ich werde sicher die Timestamp nutzen (müssen).
nun, da ich wieder CUL übe muss ich mich daran gewöhnen. Erst einmal ist alles deutlich langsamer (hätte USB schneller eingeschätzt als LAN). Daraus folgt, dass schon einefasche Funktionen wie Scene nicht korrekt arbeiten. Ein Übertragen von Konfigurationen zu einem Device habe ich mich noch nicht getraut - da brauche ich etwas mehr Zeit und Ruhe (zum Glück steht es erst einmal bis zur Sommerumstellung.
Dann werde ich noch am Status der CUL arbeiten. "Initialized" ist definitiv umpassend - das ist nicht "open" oder "run" oder "ok" oder "online"... das sagrt mir "ich könnte starten, wenn es gewünscht wird".
Bei Redundanz sollte ich hier unterscheiden.
@Beta-User - wo finde ich die aktuelle TSCUL? Ohne diese kann Homematic nicht funktionieren - und ich entnehme, Rudi hat die Timestamps in die "normale" CUL eingebaut.
Und schon hat man wieder etwas zu tun.... bis man es wieder stabil bekommt
Zitat"Initialized" ist definitiv umpassend - das ist nicht "open" oder "run" oder "ok" oder "online"... das sagrt mir "ich könnte starten, wenn es gewünscht wird".
Initialized soll heissen: die Schnittstelle wuerde geoeffnet, und erfolgreich initialisiert, d.h. RF-Mode eingestellt, usw.
Zitat von: martinp876 am 24 März 2026, 19:41:213) natürlich sollen sie zur besseren Abdeckung getrennt aufgestellt werden. Leider habe ich keine CUN(O) mehr gefunden, das hätte das Leben vereinfacht. Aktuell sind sie erst einmal an Schreibtisch. Ich habe eine "USB Verlängerung" über CAT6 Kabel - aber das wird erst später probiert.
Warum für HomeMatic Culs?
Das HM-MOD-RPI-PCB Funkmodul sollte doch für HomeMatic die bessere Wahl sein?
Das HM-MOD-RPI-PCB funktioniert auch per Lan
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Betrieb_mit_einem_LAN-TTL-Wandler
Zitat von: Beta-User am 24 März 2026, 21:41:43und beide für Moritz zuständig
Moritz ist Max
Zitat von: martinp876 am 26 März 2026, 17:52:08@Beta-User - wo finde ich die aktuelle TSCUL?
Sollte hier zu finden sein: https://forum.fhem.de/index.php?msg=1321390
"An sich" funktioniert das schon mit CUL, ich habe hier "seit Ewigkeiten" auch einen MapleCUN (mit a-culfw) für HM (mit) im Einsatz. Der hat (wie die "normale" culfw) keine Timestamps, wenn ich das richtig im Kopf habe.
Eine ganze Zeitlang war hier auch noch ein busware-CUL mit noansi's Modulen am werkeln, und "eigentlich" wollte ich schon länger mal als backup ein HM-Mod-RPi-Modul statt des MapleCUN-Transceivers in Betrieb nehmen, da ist aber irgendwas an dem Maple-Board schräg, so dass ich sicherheitshalber eigentlich einen anderen (der hier schon rumliegt) mal dafür konfigurieren wollte - oder eben den SignalDuinoAdv auf dem pico-PI, https://forum.fhem.de/index.php?topic=143942.0. Komme grade aber wegen anderer Dinge nicht so recht dazu, meinen Zoo neu zu sortieren...
Zitat von: Ralf9 am 26 März 2026, 21:48:18Moritz ist Max
Thx für die Klarstellung, hatte das vor Jahren mal so (falsch) als Schluss aus einem Blick in den Quellcode gezogen.
Wie dem auch sei: Wäre es denn schwierig, das BidCoS-Protokoll auch noch in SignalduinoAdv einzubauen? Optimalerweise (nur) in der TS-Variante von noansi? Die "CUL-Probleme" sind nach meinem Verständnis v.a. solche, die daraus resultieren, dass die normale Firmware auch für's Bestätigen von Messages Infos aus FHEM (zeitnah) braucht. Auch in den Originalen Geräten sind/waren doch CC110x verbaut, oder?
Dann hätte man auch künftig die Wahl, und eventuell könnte man auch noansi motivieren, seine Module (bzw. den erforderlichen Teil) ins svn zu packen, so dass man als User nicht raten muss, was mit was zusammenpaßt oder eben auch nicht.
Soweit ich mich entsinne, hatte ich "damals" nicht alle seine Module mit installiert (müßte suchen...).
ZitatAuch in den Originalen Geräten sind/waren doch CC110x verbaut, oder?
CC1101