Hallo,
ich habe gerade damit begonnen Zuhause mittels Raspi und 433MHz Sender/Empfänger ein paar Dinge zu automatisieren (Hatte "kürzlich" einen Artikel in der c't gelesen). Ich würde den Raspi gerne auch für 868MHz Protokolle nutzen. Erste Idee war ein Homematic Funkmodul zu kaufen. Dann bin ich auf die Eigenbau nanoCULs gestoßen. Preislich tun sich die beiden Lösungen nichts.
Nun zu meiner Frage: Kann das Homaticmodul auch für andere Protokolle genutzt werden? Oder ist Homematic "fest eingebrannt". Hat es weitere Vorteile einen nanoCUL selbst zu bauen? Sind mit einer nanoCUL unterschiedliche Protokolle möglich?
Danke und VG
Homematic ist fest in der FW verankert.
Ob man umflashen kann weiß ich nicht und was dann damit geht auch nicht...
ABER: wenn du Homematic willst dann lass besser die Finger von einem CUL!!
Nimm ein "originales" HM-IODev, z.B. eben den erwähnten Adapter.
Preislich kein Unterschied...
...Vorteil funktioniert mit HM ohne Probleme auch bzgl. Timing etc.
..."Nachteil": geht halt nur für Homematic...
Wenn du dich doch/trotzdem für einen CUL entscheidest, dann eher gleich hierfür als FW (zumindest bei Nutzung von Homematic):
https://forum.fhem.de/index.php/topic,24436.0.html (https://forum.fhem.de/index.php/topic,24436.0.html)
Gruß, Joachim
Ich würde auch für HomeMatic das originale UART Modul benutzen.
Bei Bedarf kann man auch noch weitere CULs für kleines Geld selber bauen und zusätzlich mit einbinden.
Habe bei meinen Eltern neben dem HM Modul noch einen 433CUL zu laufen, ohne Probleme!
Gruß
Dan
ZitatNimm ein "originales" HM-IODev, z.B. eben den erwähnten Adapter.
Preislich kein Unterschied...
...Vorteil funktioniert mit HM ohne Probleme auch bzgl. Timing etc.
ZitatIch würde auch für HomeMatic das originale UART Modul benutzen.
Ich finde, der Hinweis, daß ein CUL für Homematic nicht die beste Wahl ist, gehört auch ins Homematic Wiki.
Soll ich dazu was unter "Allgemeine Informationen - Wiki" schreiben oder ist mein Wunsch hier ausreichend?
Gruß Ralf
Zitat von: Ralf9 am 01 März 2017, 09:25:20
Ich finde, der Hinweis, daß ein CUL für Homematic nicht die beste Wahl ist, gehört auch ins Homematic Wiki.
Soll ich dazu was unter "Allgemeine Informationen - Wiki" schreiben oder ist mein Wunsch hier ausreichend?
Gruß Ralf
Hallo Ralf,
naja ich habe vor einiger Zeit schon mal diesen Punkt (https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale) etwas "erneuert" aktualisiert und neu geordnet. Ich wollte niemandem auf den Schlips treten und habe keine Wertung hinterlassen.
Ich habe auch an allen möglichen Stellen im Wiki vorsichtig drauf hingewiesen, das original HM IOs dem Cul zu bevorzugen sind. Eigentlich sollte das auch irgendwie klar sein.
Uli baut an einem neuen Einsteigerdokument.
Am Ende wird eh "die Empfehlung aus dem Internet" von 2013 genommen und die Leute kaufen einen Cul, weil überall steht damit geht es. Und weil alle eine Eierlegendewollmilchsau haben wollen.
Gruß Otto
ZitatIch wollte niemandem auf den Schlips treten und habe keine Wertung hinterlassen.
Ich fände eine vorsichtige Wertung sinnvoll. Ich habe den Eindruck, daß bei vielen nicht klar ist, daß original HM IOs dem Cul zu bevorzugen sind.
ZitatVorteil funktioniert mit HM ohne Probleme auch bzgl. Timing etc.
Ist mit denTiming Problemen dies gemeint?
Zitat von: noansi am 27 November 2016, 18:19:57
TSCUL versucht nun Befehle an ein device 3 mal abzusetzen, bis eine Antwort kommt.
Wenn ein device ein AES Signing anfordert, so führt dies TSCUL mit den verfügbaren Keys aus. Der Default Key ist natürlich auch in der Firmware hinterlegt.
Dies ist im Gegensatz zu HMLAN etc. auch das einzige automatische ACK seitens TSCUL, d.h. 10_CUL_HM.pm muss die sonstigen ACKS/NACKS weiterhin senden (rechtzeitig an TSCUL schicken).
Damit sind die Timing Probleme weiter entschärft, da Kommunikation von TSCUL zum device bezüglich Timing im Wesentlichen behandelt wirdt.
Bei Kommunikation eines devices zu TSCUL muss weiterhin FHEM via 10_CUL_HM.pm schnell genug eine Antwort liefern.
Je nach CUL Hardware werden bis zu 8 Sendepuffer verwaltet (einer wird stets für AES Signing genutzt). Mittels eines Flags wird stets eine "Unterhaltung"ssequenz zu einem device abgeschlossen, bevor Puffer mit Daten für andere Devices abgearbeitet werden. Aus diesen Sendedaten wird auch die eigene HMID "gelernt".
Bei Empfang eines unaufgefordeten Datenpakets von einem device an diese gelernte HMID mit Antwortanforderung wird von TSCUL ebenfalls eine "Unterhaltung" für ca. 400ms gesetzt, so dass eine Antwort von 10_CUL_HM.pm direkt entsprechend Antworttiming gesendet wird und so lange nichts an ein anderes device gesendet wird.
Ich sehe beim CUL nur Nachteile. Hat der CUL gegenüber den original HM IOs auch Vorteile?
Da es beim CUL keine Keepalive Routine gibt, kann es bei remote Anbindung des CUL z.B. mit socat, ser2net oder WLAN zu timeouts der LAN-Anbindung kommen. Oder habe ich da was übersehen?
Gruß Ralf
Zitat von: Ralf9 am 01 März 2017, 20:05:32Ich sehe beim CUL nur Nachteile. Hat der CUL gegenüber den original HM IOs auch Vorteile?
Ich glaube, dass manche es als Vorteil sehen, dass man mit einem CUL auch noch andere Protokolle sprechen kann. Dass das dann in der Praxis Blödsinn ist, sehen viele Anfänger erst einmal nicht.
Hier: https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale
...wird aber überhaupt keine Empfehlung gegeben.
Ich sehe auch gerade, dass hier für Wired nur HMW-LGW-O-DR-GS-EU steht. Das werde ich auch mal ändern. Hier ist nämlich die Empfehlung genau anders herum. Die Original eq3-Teile gehen anscheinend dauernd kaputt oder funktionieren erst gar nicht.
Gruß,
Thorsten
Hallo Thorsten,
ja, ich habe jede Bewertung weggelassen, ich habe in dem Abschnitt nur ergänzt und eine Reihenfolge angelegt.
Vorher war es auf einem Stand von 2013 :-[
Ich habe keine CUL ich habe nur RPI/HMUART und HMLAN. Ich scheue mich dort Dinge reinzuschreiben die ich nur von Anderen erfahre.
Gruß Otto
Da es sich anscheinend noch nicht herumgesprochen hat, daß man den CUL nicht für Homematic nehmen sollte, möchte ich das Thema nochmals hochholen.
Zitat von: Ranseyer am 06 Mai 2017, 12:21:32
ZitatDer HM-MOD-RPI-PCB kann nur Homematic Funk, dafür aber richtig.
Was genau verstehst Du darunter ? (Außer die AES Signierung zusätzlich ?)
Da ich dies mangels CUL nicht so richtig beantworten kann, gebe ich die Frage hier weiter.
Wie wirken sich die Timing Probleme des CULs in der Praxis aus?
Welche Einschränkungen hat der CUL beim AES?
Eine weitere Einschränkung vom CUL könnte sein:
ZitatDa es beim CUL keine Keepalive Routine gibt, kann es bei remote Anbindung des CUL z.B. mit socat, ser2net oder WLAN zu timeouts der LAN-Anbindung kommen.
Hat der CUL gegenüber dem HM-MOD-RPI-PCB noch weitere Nachteile?
Gruß Ralf
ZitatTiming Probleme des CULs in der Praxis aus?
der Cul arbeitet nach wie vor transparent, also das timing macht Fhem. mit der ts Software werden Zeitstempel mitgeschickt
etwas genauer, leider ist Fhem selber nicht Zeitgenau (single)
Hm device erledigen das selber Hmlan Hmuart, usw...
Nachdem insbesondere ACK und AES antworten zeitkritisch sind ist es von. Vorteil, dass hmios dies intern erledigen. Das Timing ist SEHR präzise.
Bei cul macht dies fhem. Ohne Zeitstempel ist dies nicht zu leisten, da die Varianz der Verzögerung auf dem Übertragungsweg (lan und USB gleichermaßen) deutlich zu schlecht ist.
Mit dem seitstempel kann man gegen Rechnung.
Die Berechnungen sich neben ACK und AES auch für weitere Messages notwendig. Hmios liefern auch Zeitstempel welche von fhem ausgewertet werden .
Hm passt besser für hm. Cul ist auch ok - und kann Universal eingesetzt werden. Allerdings nicht zeitgleich.
Zitat von: fhem-hm-knecht am 07 Mai 2017, 02:25:14
der Cul arbeitet nach wie vor transparent, also das timing macht Fhem. mit der ts Software werden Zeitstempel mitgeschickt
etwas genauer, leider ist Fhem selber nicht Zeitgenau (single)
Könnte man das nicht mit einem separaten Server-Programm erledigen, wie auch bei HM-Wired?
Gruß,
Thorsten
Dann kann man auch gleich OCCU nehmen, oder? Das wäre ja ein separater Prozess.
Das timingproblem liegt an den Verzögerungen der Schnittstellen. Hinreichend genaue Zeitstempel kann nur das io in fw erzeugen.
Unabhängig von fhem addiert ein nicht-echtzeitfaehigen OS unbekannte Verzögerungen. Ein separater Prozess würde den Einfluss von fhem selbst eliminieren, allerdings nicht die des OS und aller anderen Prozesse. Besser aber nicht wasserdicht.
Es reicht nicht, den io Treiber auszulagern, da einige Antworten von fhem generiert werden, anhand der zu Verfügung stehenden Daten.
Der Aufwand wäre erheblich die Kommunikation umzustellen. Aktuell funktioniert es eigentlich gut -so der nutzen die TS Version einer cul einsetzt. Weiter werden ALLE Protokollprobleme ausgegeben. Der User muss sich diese ansehen, was auch nach einer Umstellung der Fall wäre. Das macht sogar die ccu von hm so.
Was also rechtfertigt den Aufwand, das Risiko einer Umstellung und die Komplexität (welche in fhem nicht gut unterstützt wird)?
Zitat von: Ralf9 am 07 Mai 2017, 01:22:11
Da es sich anscheinend noch nicht herumgesprochen hat, daß man den CUL nicht für Homematic nehmen sollte, möchte ich das Thema nochmals hochholen.
...
Hat der CUL gegenüber dem HM-MOD-RPI-PCB noch weitere Nachteile?
Moin,
sollten wir jetzt hier jeden Tag einmal sagen, das EierlegendeWollmilchsäue nicht die erste Wahl sind? :D Ich habe den Eindruck, dass jeder der mit Homematic beginnt, der Meinung ist einen CUL einsetzen zu müssen. Geht es dabei um ein paar Euro um sich dann mit Komponenten mit einem Wert von vielen Hundert Euro nur rumzuärgern?
Auf alle Fälle habe ich mit der Erklärung von Martin verstanden warum offenbar bei einigen HM mit CUL gut läuft und ansonsten viele Probleme auftauchen.
Schnelles System, wenig Last von FHEM, "einfache" HM Komponenten -> CUL geht gut.
Stark belastetet FHEM System, komplexe HM Komponenten (z.B. HM-PB-4DIS-WM) + AES -> mit CUL geht es wahrscheinlich gar nicht.
Dazwischen ist sicher jede Variante möglich.
Die TS Firmware (https://forum.fhem.de/index.php/topic,31421.0.html) ist eigentlich Pflicht, auch das weiß so gut wie niemand von den CUL Anfängern.
Ist es aus eurer Sicht legitim, als Standard Antwort bei Pairing Problemen mit CUL die Empfehlung auf einen HM IO zu geben? Bzw.auch mal zu sagen CUL geht eben nicht?
Gruß Otto
Zitat von: martinp876 am 07 Mai 2017, 09:49:24
Was also rechtfertigt den Aufwand, das Risiko einer Umstellung und die Komplexität (welche in fhem nicht gut unterstützt wird)?
Meine Frage war ja nur eine Frage. Bei HM-Wired kommt es auf ein paar Millisekunden nicht an, aber wenn man das innerhalb der "FHEM-Hauptschleife" macht, dann kommt es i.d.R. zu größeren Verzögerungen.
Wenn es tatsächlich so ist, dass HM-Funk bezüglich des Timings kritischer ist, dann bringt es wahrscheinlich wirklich nichts, das ganze in einen eigenen Betriebssystem-Prozess auszulagern. Das wundert mich zwar ein wenig, aber ich vertraue hier mal dem Experten.
Zitat von: Otto123 am 07 Mai 2017, 10:01:04Ist es aus eurer Sicht legitim, als Standard Antwort bei Pairing Problemen mit CUL die Empfehlung auf einen HM IO zu geben? Bzw.auch mal zu sagen CUL geht eben nicht?
Meiner Meinung nach ist das schon legitim. Warum auch nicht, wenn es die Sache einfacher macht? Soweit ich verstanden habe, geht es ansonsten nur darum, ein paar € zu sparen, die aber verglichen mit der Gesamtinstallation normalerweise nicht ins Gewicht fallen.
Gruß,
Thorsten
Nachdem ich vor ca. anderthalb Jahren mit FHEM angefangen und inzwischen in der Praxis durch die Themen RFXCOM, nanoCUL, JeeLink, SignalDuino und Homematic durch bin, wollte ich auch mal meine Gedanken dazu loswerden.
Auf diesen Thread bin ich beim Umschauen gestossen, nachdem Otto123 erwähnt hatte, ich solle mir mal den Homematic-Eintrag im Wiki anschauen, dass ein CUL für Homematic nicht empfehlenswert sei...
Das Problem, weshalb viele zum CUL greifen, ist dass er billig ist und schnell selbst gemacht.
Der Gedanke - zumindest bei mir - ist, dass ich Kontrolle über die Software und über die Hardware habe, sowie das Ganze leicht ersetzen kann.
Es gehen ja inzwischen die ersten Diskussionen im Forum los, ob und wann eq3 Homematic Classic abkündigt. Vor ein Paar Tagen waren auch die Homematic IP-Server ausgefallen und das Katastrophenmanagement von eq3 nicht vorhanden und die Krisenkommunikation äusserst stümperhaft. Soetwas kann einer Firma schnell das Genick brechen.
Einen Kondensator/Relais/Sicherung im Aktor kann ich wechseln oder den Aktor begrenzt auf Vorrat legen für "schlimmere" Fälle.
Was mache ich aber in 5-8 Jahren, wenn mir die CCU2 stirbt und es keine mehr gibt? Das halbe Haus aufreissen und Homematic gegen was anderes tauschen?
Da man mit FHEM viele viele Hersteller und deren Systeme verknüpfen kann und das auch fleissig gemacht wird, hat man dieses Problem aber sehr schnell multiplikativ.
Hier möchte ich nicht alle Jahre ein System komplett wechseln müssen.
Da erscheint der CUL und hier insbesondere der nanoCUL attraktiv, da man den schnell wieder zur Hand hat und größere Vorräte kostengünstig anlegen kann.
Leider ist es nun so, dass der nanoCUL vieles kann, aber nichts von dem richtig gut, was man als Anfänger in Tutorials auf diversen Seiten in Zusammenhang mit FHEM liest...
- LaCrosse geht recht unzuverlässig
- Intertechno geht nur zum Senden
- ConradRSL braucht SignalDuino
- Homematic geht nicht gleichzeitig mit den anderen Modi
usw. usf.
So sitzt man am Ende mit zig spezialisierten nanoCULs herum und dann funktioniert es trotzdem meist nicht richtig.
Zudem hat man noch Ärger mit China-Clones beim Nano und falsch gelabelten Funkmodulen 868/433.
Irgendwann reicht es dann, da das Ganze endlich vernünftig laufen soll und man greift dann doch noch zu RFXCOM, JeeLink und CCU2.
Trotzdem hoffe ich, dass die CUL-Software oder Alternativen wie SignalDuino usw. noch die Kurve kriegen und das Ganze stabil hinbekommen. Denn der Tag an dem es keinen RFXCOM oder CCU2 als Ersatzteil mehr gibt und man mit defektem Gerät dasitzt und das halbe Haus stillsteht, wird ein echt ärgerlicher sein, wenn es keine Alternativen gibt...
Zitat- Homematic geht nicht gleichzeitig mit den anderen Modi
Mir ist keine Alternative bekannt, die sowas kann.
ZitatTrotzdem hoffe ich, dass die CUL-Software oder Alternativen wie SignalDuino usw. noch die Kurve kriegen und das Ganze stabil hinbekommen.
Ich habe mit HomeMatic in culfw angefangen, weil ich an dem Protokoll interessiert war, und wissen wollte, was bei mir zuhause gefunkt wird. Aus aehnlichen Gruenden gibt es eine ZWave Implementation in culfw. Ich habe aber nicht die Motivation, eine fehlerfrei funktionierende Loesung jahrzentelang konstenlos _alleine_ Weiterzuentwickeln. Die meisten Anwender verlieren in dem Moment die Interesse an CUL/culfw, wenn die Alternative ein Euro billiger ist, oder irgendetwas noch Probleme bereitet.
Hoffen ist die falsche Strategie, mitmachen ist die richtige. Und keine doofen Ausreden wie "ich kann das nicht". Ich konnte das auch nicht, und musste dutzende Stunden Freizeit investieren, bis ich das Zeug gebaut habe. Dann lieber ehrlich sein, und zugeben, dass einem das nicht Wert ist.
ausserdem gibt es speziell für homematic die ts_culfw, die aber seltsamer weise "gemieden" wird. nach dem motto: "nur was vom chef kommt, kann gut sein".
rudi, vielleicht solltest du sie mal empfehlen.
Ich mache das immer wieder, wenn die Frage aufkommt.
Nicht proaktiv, weil ich dafuer die Vorteile genau kennen muesste.
Ich weiss aber, dass noansi mit seinem ts_culfw sich um Homematic kuemmert. Leider hat er so viel umgebaut, dass ich keine Zeit habe die Aenderungen auf alle Nebenwirkungen zu testen und sie mit dem von mir betreuten Hardware kompatibel zu machen. Ist sehe diesen Fork aber nicht als Problem, wer CUL fuer Homematic verwendet, kann sowieso nur Homematic bedienen.
Also günstig und schnell zusammengebaut bzgl. Homematic:
HM-Aufsteckmodul für PI (20€)
Liegt ja (fast) schon im Bereich selbstbau nanoCUL
Und ist deutlich problemloser!
Und geht auch per WLAN, LAN und USB...
Bei Nutzung/Umstieg auf HM IP einfach auf dem oder weiteren PI "CCU2-Clone" drauf und per HMCCU in fhem integrieren...
Damit sollte auch die Zukunft kein Problem sein...
TS_CUL-FW hab ich auch (Testsystem) und läuft aber produktiv setze ich lieber auf HMOD-PCB bzw. HM-CFG-USB...
Kurz (und knapp), da nur Handy...
Gruß, Joachim
@MadMax-FHEM
Das ist alles schon richtig, allerdings wäre es nicht das erste Mal, dass ein "ofizielles" Hersteller-IO aus dem Programm genommen würde (gab hier jüngst mal jemanden, der das mit FS20 erlebt hat).
Der Hinweis auf die TS-Firmware für den CUL ist gut, es ist immer gut, Alternativen zu haben.
Tatsache ist aber, dass viele Einsteiger irgendwie verschreckt reagieren, wenn man das vorschlägt. Auch ich habe das als "damaliger Beginner" zwar wahrgenommen, dass es auch noch diesen Fork gibt, ich habe es damals aber ebenfalls nicht eingesetzt. Es war mir irgendwie zu sehr "versteckt", alle Infos sind (jedenfalls waren es vermutlich) nur in diesem Mammut-Thread zu finden und man braucht andere Module.
Das macht es vor allem für Anfänger schwierig, das einfach mal zu testen - zumal man ja auch Geräte braucht und dann nahe am bzw. mit dem Produktivsystem arbeitet.
Vielleicht findet sich ja jemand mit TS-firmware-Erfahrung, der in den CUL-Wiki-Bereich die entsprechenden Hinweise aufnimmt?
Gruß, Beta-User
Zitat von: Beta-User am 20 Dezember 2017, 11:19:31
@MadMax-FHEM
Das ist alles schon richtig, allerdings wäre es nicht das erste Mal, dass ein "ofizielles" Hersteller-IO aus dem Programm genommen würde (gab hier jüngst mal jemanden, der das mit FS20 erlebt hat).
Der Hinweis auf die TS-Firmware für den CUL ist gut, es ist immer gut, Alternativen zu haben.
Tatsache ist aber, dass viele Einsteiger irgendwie verschreckt reagieren, wenn man das vorschlägt. Auch ich habe das als "damaliger Beginner" zwar wahrgenommen, dass es auch noch diesen Fork gibt, ich habe es damals aber ebenfalls nicht eingesetzt. Es war mir irgendwie zu sehr "versteckt", alle Infos sind (jedenfalls waren es vermutlich) nur in diesem Mammut-Thread zu finden und man braucht andere Module.
Das macht es vor allem für Anfänger schwierig, das einfach mal zu testen - zumal man ja auch Geräte braucht und dann nahe am bzw. mit dem Produktivsystem arbeitet.
Vielleicht findet sich ja jemand mit TS-firmware-Erfahrung, der in den CUL-Wiki-Bereich die entsprechenden Hinweise aufnimmt?
Gruß, Beta-User
Ja, stimmt schon.
Ist leider nicht ganz einfach die Einbindung der "Spezial-FW", da ja auch noch einige (aber es werden weniger) Module ersetzt werden müssen...
Es gibt zwar immer wieder Versuche von Ansgar (und Nachfragen von Usern) das "offiziell" zu machen aber bislang noch kein Erfolg... :-|
Aktuell habe ich die Verwendung von CUL eingestellt.
War eine der geplanten Aktionen für Weihnachten... ;)
(Also eigentlich Testsysteme "eindampfen")
Aber vielleicht finde ich über Weihnachten oder so Zeit mir einen Wiki-Zugang zuzulegen und schaue mal was ich tun kann...
...oder war die Anmerkung anders gedacht ;)
Werde den Wiki-Eintrag aber halt langfrisitg nicht aktuell halten können, da ich wie gesagt die CUL-Nutzung eingestellt habe...
Gruß und Frosch Fescht, Joachim
Thx, scheinbar ist der Hinweis auf das wiki an der richtigen Adresse angekommen :) .
Das mit der Aktualität ist zwar ein Thema, aber andererseits wird die Welt da nicht alle paar Monate neu erfunden, und wenn es irgendwann falsch geworden sein sollte, wird sich schon jemand finden, der das dann wieder rausnimmt.
Frohes Fest allseits,
Beta-User
Zugang beantragt... ;)
Gruß, Joachim
Hallo Zusammen,
ich kann nur zur CUL Nutzung und zur tsculfw Firmware und TS Modulen Erfahrungen beisteuern, da ich kein anderes sendendes Funkinterface besitze oder einsetze.
Der Anfang mit CUL war mit dem "Standard" ebenfalls schwierig und auch holprig, da man auch dazu schon Infos suchen muss und dabei auf viele Fehlinformationen stößt. -> TSCUL
ein Thread
ok, ist was größer aber schon am Anfang der link zu aktuellsten Version. ;) Der a-culfw Thread ist noch größer.
Zunächst hat mich USB (CUL V3 Stick) genervt, weil das nicht vernünftig stabil lief. Mit einigen Änderungen und Erweiterungen in der Firmware war das zu verbessern (viel Lesen in Datenblättern inklusive). Aber zu viel, das Rudolf es hätte verstehend übernehmen können. Auch in der a-culfw steckt noch der alte USB Code für CUL Vx Sticks drin.
Und für Anfänger ganz deutlich, diese Verbesserung hat nichts mit nanoCULs zu tun, da die nicht nativ an USB angebunden sind, sondern über einen USB-seriell Interface.
Bei SlowRF wollte ich meine Wetterstationssensoren sauber empfangen. Es gab aber unerklärliche Empfangsfehler ud Aussetzer. Also auch da angesetzt und es war noch was raus zu holen.
Wieder zu viele Änderungen als das Rudolf es hätte verstehend übernehmen können. Insbesondere auch bezüglich Timing und Timern.
SlowRF Senden ist ebenfalls verbessert (aus meiner Sicht).
Wer bei SlowRF aber auf eine große Sensorunterstützungsvielfalt aus ist, der ist mit der a-culfw vermutlich besser bedient https://forum.fhem.de/index.php/topic,35064.0.html (https://forum.fhem.de/index.php/topic,35064.0.html).
Da ich meine CUL Farm mit SCC und COC erweitert hatte, habe ich auch dort beim IO Interface Bechleunigungen erzielen können, was für HM relevant ist.
Über dem dachte ich mal mit HM zu schauen, ob das besser funktioniert. CUL war schon da, also CUL auch als IO genutzt. Erst nur mit Temperatur-Sensoren, das war etwas holprig beim Pairing aber ging dann, weil die eh nur zyklisch senden und keine Antwort erwarten, was mir aber zu dem Zeitpunkt noch nicht bewußt war.
Dann mit HM-Aktoren und damit habe ich viel zum Timing lernen dürfen. Anfangs noch auf 00_CUL.pm Ebenene und dann auch in der Firmware mit zunehmender Verlagerung des Timings auf die Firmware. Zu guterletzt auch noch AES Firmwareunterstützung.
Und für Anfänger ganz deutlich, nur Classic HM, nicht IP!
Für CUL Einsatz mit Classic HM gibt es wohl derzeit keine bessere alternative CUL Firmware als tsculfw nebst Modulen.
Meine Motivation ist stabiler Betrieb und danach kommen dann Funktionserweiterungen.
Die tsculfw Firmware und die TS Module wären jetzt längst noch nicht da, wo sie sind, wenn ich den Weg des Standards stur hätte beschreiten wollen. Die Unabhängigkeit ist da ein Vorteil, was Entwicklungsgeschwindigkeit und Flexibilität angeht. Wenn ein Modul nicht passt, wird es passend gemacht.
Die tsculfw und Modul Tester haben in letzter Zeit entweder keine Probleme oder melden sich nicht.
Ich kann nur was verbessern, wenn auch Feedback kommt. Meine eigene Geräteauswahl ist nun mal überschaubar und wird auch nur dem Bedarf angepasst.
ZitatDas mit der Aktualität ist zwar ein Thema, aber andererseits wird die Welt da nicht alle paar Monate neu erfunden
Da wär ich mir bei mir nicht so sicher. ;)
ZitatIst leider nicht ganz einfach die Einbindung der "Spezial-FW", da ja auch noch einige (aber es werden weniger) Module ersetzt werden müssen...
Manchmal ist es etwas schwieriger. Erst sichern und dann ersetzen von ein paar Dateien doch wohl nicht.
Anschließend fhem.cfg anpassen und fhem neu starten. Klar, die Firmware flashen ist oftmals noch was schwieriger, bis alle Systemhürden überwunden sind.
Wenn das zu schwierig ist, dann ist von der FHEM Nutzung eher abzuraten.
Es geht halt nicht so bequem, wie über update.
Dafür bietet quelloffenes FHEM und eine quelloffene Firmware die Möglichkeit was zu ändern, was nicht funktioniert. Oder mit dem Wandel der Zeit was anzupassen.
Zitatund dann nahe am bzw. mit dem Produktivsystem arbeitet
Und es ist eine unglaubliche Motivation, es hin zu bekommen, wenn es kälter und kälter wird und man vorher das Backup vergessen hat. ;D
Eine Grundsystemfunktionalität gehört ohnehin vorher dazu geschaffen, schon allein für den Fall des FHEM Serverausfalls.
ZitatAktuell habe ich die Verwendung von CUL eingestellt.
@Joachim: Womit hast Du noch Probleme? Hast Du den letzten Stand getestet oder wo bist Du stehen geblieben?
ZitatZugang beantragt...
Super, Danke!
Ob Standard oder nicht, so lange die CULs und die devices laufen, mach ich damit weiter und stelle es zur Verfügung, so wie es auch habe bekommen dürfen.
Frohes Fest,
Gruß, Ansgar.
Hallo Ansgar,
nein nein, keine Probleme!
Und vielen Dank für deine Mühen!
Allerdings hatte ich von Anfang an eigentlich HM-USB-CFG...
...der "Ausflug" zu CUL war mehr das Interesse mal wieder was mit Microcontrollern zu machen... ;)
Hatte den neben einem mySensors-Gateway (selber Grund) an meinem Testsystem und bis zum Klingelsensor auch zufrieden ;)
Dann eben der Umstieg auf Spezial-FW mit noch so enigen Modulen, die man ersetzen musste (aber auf dem Testsystem ja kein Problem / dazu ist es ja da ;) ) bishin zur Einführung von TS_CUL mit deutlich wenigeren Modulen die zu tauschen sind :)
Habe dann noch einige Zeit getestet, um TS_CUL usw. besser/stabiler zu kriegen (quasi "Sparringspartner" für deine unermüdliche Entwicklung)...
Nachdem sich aber dann wieder verstärkt andere Tester (gerade bzgl. AES) gefunden haben...
...und ich mal meinen Flohzirkus etwas eindämmen wollte habe ich mal meine Testsysteme (waren dann doch schon 3 Stück) etwas eingedampft...
...somit werden/wurden wieder einige PIs für andere "Experimente" frei.
Daher dann die Entscheidung den CUL (erst mal) raus zu nehmen...
...hing eh nur noch der Klingelsensor dran.
Alle anderen Geräte haben es ins Hauptsystem geschafft (Klingelsensor war dann wohl eine Fehlinvestition).
mySensors hat bei mir auch (erst mal) keine Zukunft (mehr)...
Wenn allerdings wieder Bedarf an einem Tester ist (aber wie geschrieben die Test-HW ist deutlich eingeschränkt ;) ), dann baue ich wieder ein Testsystem auf :)
Ansonsten weise ich in jedem Beitrag wo es um (mir bekannte) Probleme mit CUL und HM geht auf die TS_CUL hin...
Vielen Dank noch mal!
Frosch Fescht und guten Rutsch, Joachim
@Ansgar
Danke für deine Rückmeldung hier und auch die viele Mühe, die in den Code von TS_CUL etc. reingeflossen ist. Es ist richtig schade, dass das nicht bekannter ist!
Bis vor einigen Wochen hatte ich gar nicht auf dem Schirm, wie viel besser TS_CUL für den HM-Betrieb zu sein scheint, vor allem in der Kommunikation mit batteriebetriebenen Geräten. Scheint jedenfalls bei den virtuellen Kanälen (bitte keine Fachdiskussion dazu hier) sogar besser zu sein als CUL_HM mit Original-IO! WOW!!!
Eigentlich wäre es das wert, auch Eingang in die Maple-Geschichten zu finden, aber da hat die a-culfw die Nase klar vorn (obwohl vermutlich ausreichend Speicher da wäre, das alternativ zu implementieren). Ist aber verständlich, da da der Schwerpunkt bei den Maples ja auf anderen Protokollen liegt und HM ja "an sich" auch mit dem dort enthaltenen "Standard-CUL-Code" funktioniert.
Es wäre also super, wenn die Welt sich da schneller drehen würde als ich das einfach mal so unterstellt habe...
Und das mit der gesteigerten Motivation, das Hauptsystem wieder an's Laufen zu bekommen, stimmt zwar, es ist aber dann nicht lustig, wenn es erst tut und mit dem rumzicken erst nach einigen Tagen und gerade dann anfängt, wenn man sich zum Skifahren verabschiedet hatte... (Ist mir zwar nicht mit TS_CUL passiert, war aber trotzdem alles andere als lustig :( ).
@Joachim: Super, das du das mit dem Wiki angehst!
Jedenfalls, bei "Wenn's nicht mehr paßt, wird sich jemand finden..." hat Ansgar ja nicht widersprochen ;) .
Hallo noch mal ;)
Bevor ich nun loslege habe ich mal (um das hier nicht zu sprengen) einen Thread erstellt:
https://forum.fhem.de/index.php?topic=81718.msg737816#msg737816
Wäre schön, wenn ihr, v.a. Ansgar, eure Meinung kund tun würdet...
Jede Hilfe ist willkommen :)
Gruß, Joachim
Ich bin jetzt seit ca. 2 Jahren mit FHEM am tun.
Im Forum findet man sehr viele hilfreichen Input, aber da es teilweise verstreut oder auch mal obsolet sein kann, habe ich mich vorwiegend an das Wiki gehalten.
Als ich mich bzgl des Selbstbau-CUL einlas, habe ich die Unzulänglichkeiten des CUL nicht erkannt. Das ist für den Anfänger kaum zu identifizieren. Bestimmt bin ich irgendwann mal auf die TSCUL gestoßen und es war mir vermutlich zu komplex. Und so wurde es verworfen und im Abseits geparkt.
Ich denke, da wird es vielen nicht anders gegangen sein.
Jetzt aber, probiere ich es aus!
Ein herzlichen Dank an den Entwickler @noansi und die ganzen unermüdlichen Vortester!