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
Zitat von: Beta-User am 26 März 2026, 22:32:27Wie dem auch sei: Wäre es denn schwierig, das BidCoS-Protokoll auch noch in SignalduinoAdv einzubauen? Optimalerweise (nur) in der TS-Variante von noansi?
Habe mir mal kurz den Code grob angeschaut, das ist mir zu komplex und aufwändig.
Zitat von: Ralf9 am 28 März 2026, 11:32:15Habe mir mal kurz den Code grob angeschaut, das ist mir zu komplex und aufwändig.
Schade, aber trotzdem Danke!
sorry, bin wie immer etwas langsam.
Status "initialized" halte ich für unpassend, wenn wir (on-air) sind. Ich habe aber keine Ambitionen, zu diskutieren, warum man den Begriff oder den Status heute so, hier aber anders herum und dann wieder neu defiert. Die Semantk ist für mich schlicht irritierend. Und ok, dies zu ändern ist sowieso spät, zu lange in betrieb. Der Fehler (meine Auffassung) wurde vor langer Zeit begangen...
Homematic IOs
- HMLAN war super - gibt es nicht mehr. HM-LGW dito.
- CUN(O) ist ganz ok, weil über LAN einfach physisch verteilbar - aich tot
- ein HM-MOD-RPI-PCB habe ich noch rumfliegen Funktioniert nicht an meinem PI400. Wenn man die Installation debuggen muss ist sehr viel wissen notwendig. Ich würden gerne mit Putty das Interface prüfen o.ä. Könnte ich wieder in Angriff nehmen - in der Hoffnung auch Anleitungen zu finden, die nicht nur sunny-day aufzeigen sondern auch debug Hilfe.
Nachteil ist, dass das Modul nur einmal eingesetzt werden kann (keine Redundanz) und dann auch nur lokal am Raspi. Und der steht nicht Zentral - was zu reichweitenproblemen führt
==> ich nehmen gerne Hilfe und Tips an!
- CUL kann ich per USB absetzen (begrenzt) habe aber eine Option, USB über CAT6 Kabel abzusetzen. Nicht einfach, neues Kabel - aber wenigstens möglich.
@Betateilchen - danke für den Link
==>wo kann ich die firmware finden? Muss noch einmal gründlich suchen. Wäre cool, diese in CUL zu verlinken
IO Module
- ich bin nun an Sortieren der CUL Module -da dun sich Fragezeichen auf
- 00_CUL ist das standars modul - muss mir in erinnerung rufen, ob es so passt (passend war) zu lange herum
- TSCUL muss ich suchen udn prüfen
- STACKABLE_CC / STACKABLE - vollkommen unklar. Commandref besagt, dass hier mehrere CUL betrieben werden können. Wie, warum,...? Redundanz? Automatische Zurodnung der IOs? Lastverteilung? Eine Anleitung ist scheinbar in MapleCUM zu finden -
==> Wünschenswert wäre eine einfache Anleitung wie eine CUL für welchen einsatzfall einzurichten ist. Für HM ist es sicher, dass die Timestamps genutzt werden müssen. Meine Installation läuft aktuell auf einer CUL mit 00_CUL - und wie erwartet hackt es ständig. Eben unzuverlässig. ==>wenn man CUL-HW für HM anbietet ist es schlicht unlauter, die normale installation (FW / IO-Modul) zu propagieren
Zum Timing: grundsätzlich benötigt HM ein Timing mit einer genauigkeit im 10mS Bereich, Toleranz etwa -+25ms. CUL_HM versucht, dies einzuhalten, kann jedoch ohne Timestamp das OS und die Interface-treiber nicht herausrechnen. Einfache Schlatbefehle gehen schon, aber schon das Ack kann zu Problemen und unnötigen Wiederholungen führen. Richtign Probleme gab es bei mehr-message-komamndos welche bei der Konfiguration gang und gäbe sind. Praktisch kann ich sagen, dass schon meine "Scene" kommandos mit der CUL "out of the box" schlicht nicht stabil funktionieren.
Wenn jemand hier keine Probleme hat, Glückwunsch. Bei so einer Aussage erwarte ich aber, dass auch Konfiguration und multi-kommandos abgedeckt sind (ein Device mit 8 Outouts, 8mal schalten in einem Schritt, keine Wiederholungen der Messages). Sonst ist es nicht stabil und nicht mein Einsatzfall.
==>für mich immer noch unklar, ob das 2. CUL nun stackable sein sollte oder einfach ein 2. Device - also wozu brauche ich stackable?
Zitat von: martinp876 am 06 April 2026, 12:42:58ein HM-MOD-RPI-PCB habe ich noch rumfliegen Funktioniert nicht an meinem PI400.
Nachteil ist, dass das Modul nur einmal eingesetzt werden kann (keine Redundanz)
Was spricht dagegen den HM-MOD-RPI-PCB an einen LAN-TTL-Wandler anzuschliessen?
Kann das Modul auch nur einmal eingesetzt werden, wenn es über Lan betrieben wird?
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Betrieb_mit_einem_LAN-TTL-Wandler
Zitat- STACKABLE_CC / STACKABLE - vollkommen unklar. Commandref besagt, dass hier mehrere CUL betrieben werden können.
Busware hat mal Geraete mit dem Namen SCC verkauft (https://busware.de/tiki-index.php?page=scc), wo man auf dem Raspberry PI CC1101 "Hats" draufstecken konnte.
Da man mehr als einen draufstecken kann, musste eine Loesung zum Adressieren her.
Wenn einer im Stack die Daten vom Oberen bekommen hat, dann hat culfw die mit einem Praefix (*) weitergeschickt.
STACKABLE_CC fieselt diese Daten auseinander, und schickt sie an die richtige CUL Instanz weiter.
STACKABLE (ohne _CC) ist eine generalisierte Version von STACKABLE_CC, es kann im Prinzip beliebige Module bedienen, wenn die Verbindung ueber so ein Praefix laeuft.
MapleCUN benoetigt auf der FHEM-Seite die gleiche Technologie, wenn mehr als ein Funkmodul eingebaut ist.
Zitat von: martinp876 am 06 April 2026, 12:42:58- ein HM-MOD-RPI-PCB habe ich noch rumfliegen Funktioniert nicht an meinem PI400. Wenn man die Installation debuggen muss ist sehr viel wissen notwendig. Ich würden gerne mit Putty das Interface prüfen o.ä. Könnte ich wieder in Angriff nehmen - in der Hoffnung auch Anleitungen zu finden, die nicht nur sunny-day aufzeigen sondern auch debug Hilfe.
Nachteil ist, dass das Modul nur einmal eingesetzt werden kann (keine Redundanz) und dann auch nur lokal am Raspi. Und der steht nicht Zentral - was zu reichweitenproblemen führt
==> ich nehmen gerne Hilfe und Tips an!
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Du kannst soviele einsetzen wie Du willst, nur an einem GPIO, an einem PI - eben nur Einen. ;)
Der Betrieb am PI400 kann schwierig sein, der ist mW speziell. Aber im verlinkten Artikel sind jede Menge Alternativen, nur Wlan ist nicht zu empfehlen. Am einfachsten (falls es andere Linux Geräte im Netzwerk an günstiger Stelle gibt) mit USB Adapter und ser2net. Ich betreibe das so an OpenWrt Routern und alten Raspberrys. Ein Pi1 oder Pi2 mit einem solchen Modul ist doch nicht viel anders als ein LAN Adapter?! Gebrauchte Himbeeren gibt es zu hauf...
Mit einem aktuellen Raspberry OS ist die Einrichtung eigentlich ohne Stolperfallen https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
Wahrscheinlich geht die Beschreibung dort für den Pi5 interaktiv bei allen Exemplaren.
Sorry Ralf9 war jetzt schneller ... :)
Zitat von: Ralf9 am 06 April 2026, 12:58:44Kann das Modul auch nur einmal eingesetzt werden, wenn es über Lan betrieben wird?
Nein :) ich habe drei entfernte Module am laufen, irgendwo habe ich was von 10 oder so im Einsatz gelesen... Wüsste nicht, dass es beschränkt ist.
1) HM-MOD-RPI-PCB über LAN<-> RS232 zu betreiben könnte funktionieren. Es ist ein HM module und könnte das Timing selbst machen. Sollte ich einmal test. Sollte das nicht stimmen sehe ich bei der Mehfach Wandlung Problerme mit dem Timing. Aber: einen Versuch ist es wert. Etwas Aufwand bspw mit Gebäuse.
2) Danke für die Stackable Erklärung. Da ich keine entsprechenden Multi-IO Unit betreibe ist es für mich also irrelevant
3) HM-MOD-RPI-PCB wieder in Angriff nehmen kann ich noch einmal versuchen. Ja, auf einfach hatte ich gehofft. Wenn man ein Problem hat ist es (für mich zumindest) schwer, die Fehlstelle zu isolieren. Wenn alles geht ist es of einfach. Ich denke daher zuerst an die LAN/RS232 Lösung - da liegen debug optionen auf dem Tisch
Da ich aktuell komplett überlastet bin wird alles dauern - andere Prios. Dei Installation läuft also mit CUL(ohne TS) wir erwartet. Einfaches schalten geht. Komplexe übertragungen schwierig. Das ausschalten von ~10 Schaltstellen "gute-Nacht-Schalter" +über Scene scheitert so gut wie immer - es werden nur einzelne Lichter gelöscht... muss ich von Hand "nachschalten"
Danke für die Tips