[GELÖST] - CUNO2 im rfmode HomeMatic

Begonnen von eckhard scholz, 17 Oktober 2021, 10:17:58

Vorheriges Thema - Nächstes Thema

frank

ZitatAber Vorsicht, Mischbetrieb von TSCUL-fw und 'normalem' CUL_HM ist nicht vorgesehen afaik.
das ist so nicht korrekt.
nicht getestet sollte eher passen.
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

rudolfkoenig

ZitatWas mir jetzt aus Interesse noch fehlt, ist wie ich mit SVN-Client die FW-Versionen sehen/finden kann. Da muß ich mir wohl auch noch einiges anlesen/lernen.

Ich wollte es hier gerade detailliert beschreiben, dabei habe ich entdeckt, dass doch ein einfaches HTML Frontend gibt :)
https://sourceforge.net/p/culfw/code/HEAD/tree/tags/

yersinia

Zitat von: Beta-User am 20 Oktober 2021, 14:48:39(So finde ich das eine fürchterliche "wall of text", die mich bisher auch abgehalten hat, irgendwas an meiner (prinzipiell ja funktionierenden) Installation umzustellen).
Ja, hat mich auch erst abgeschreckt aber wenn man sich die Zeit nimmt und sich da ran setzt, ist dies eine gut erklärte Schritt-für-Schritt Anleitung, wie man von CUL_HM auf TSCUL_HM umsteigt.
(mich haben bootloader Probleme bei den nanoCULs genervt und dann zum Umstieg bewogen - vorher lief aculfw drauf; dabei aber relativ unproblematisch imho)
Man muss sich aber auf Mehrarbeit, teilweise auf OS-console, einstellen - bequemes Update via fhem update gibt es hier nicht.

Ob es einen wesentlichen Mehrwert im Vergleich zu CUL_HM und zB aculfw gibt, kann ich so nicht sagen (ich sehe aber auch nicht direkt, ob das EEPROM wirklich geschont wird). Meine HMclassic Umgebung läuft stabil und gar recht gut.

Zitat von: frank am 20 Oktober 2021, 14:56:34das ist so nicht korrekt.
nicht getestet sollte eher passen.
Danke für die Korrektur, deswegen schrieb ich auch afaik. Aus dem Text liest sich für mich aber heraus, dass es schon empfehlenswert ist. Letztendlich läuft es aufs gleiche hinaus: nur wie dort beschrieben (inkl ersetzen der Dateien) ist es getestet, alles andere auf eigenem Risiko.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

Beta-User

Allgemeine Anmerkung zum gesamten Themenkomplex, da zumindest einer hier dabei ist, der ggf. in der Lage wäre, das anzuschieben ;) :

Als User finde ich diese ganzen firmware- und Modul-Varianten -(Kombinationen) ziemlich grausam (das gilt in ähnlicher Form für Signalduino) und würde mir wünschen, dass
- die TS-Modifikationen ggf. Eingang finden in die reguläre CUL-FW (bei aktiviertem HM-Protokoll, ggf. kann man ja Varianten mit und ohne HM anbieten, aber HM eben immer mit TS, und ja, ich habe noch im Ohr, dass noansi's patch riesig war) (und im Anschluss dann auch nach a-culfw kommen);
- das IO-Modul (CUL) auch mit der TS-Variante umgehen kann (da gilt für den patch vermutlich dasselbe, dto. für "STACKABLE")
- eventuelle Probleme in CUL_HM die damit zusammenhängen dann ggf. auch ausgemerzt werden (ich kann - falls es ein entsprechendes Projekt gibt - gerne mal versuchen, die Differenzen rauszufieseln, und evtl. finden sich dann grade vor dem aktuellen Hintergrund einige Leute, die bereit wären, das mit zu testen, und noansi wäre vermutlich im Hinblick auf Supportleistungen auch nicht unfroh, wenn es keine Sonderlocke mehr gäbe).

just my2ct.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

Zitatwürde mir wünschen
sehr, sehr lange vorher haben die engländer sicherlich den euro eingeführt.  ;)
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

eckhard scholz

Nun ist ja eine tolle Diskussion über die Firmware entbrannt aber abschließend möchte ich noch ein paar Erkenntnisse zu meinem Problem schreiben.

Die neuse Firmware V1.67 läuft auf meinem CUNO2.1b, Homematic Devices laufen auch alle und Fhem ist auf den neusten Stand.
Was ich bei den Logfile-Einträgen nicht beachtet bzw. unterschätzt habe sind Störungen von Außen.
Bei den ganzen Versuchen, die ja ab und zu auch schief gingen, hatte ich den CUNO2 auch mal einen anderen Platz im Haus zugeordnet und siehe da die Störungen waren weg.
Der CUNO2 ist jetzt direkt an der FB am Netzwerk angeschlossen und elektrische Leitungen (230V ac) rel. weit vom CUNO2 entfernt.
Wer also ähnliche Probleme hat, möglichst NW-Switches o.ä. weg lassen und auf gute Entfernung von Stromleitungen achten.
Selbst wenn die Entfernung zu den HM-Devices größer wurde, bis jetzt ist die Kommunikation einwandfrei.

An Rudolf noch einmal Danke für den Link, das war´s was ich gesucht habe.

Grüße an alle die mir mit Rat und Tat geholfen haben.
Eckhard
F!B,RPi-Fhem,RaspberryMatic,Cuno,Cul,S7-300,LOGO,HMIP,HM,FS20,