[GELÖST] - CUNO2 im rfmode HomeMatic

[eckhard scholz]

Hallo Fhem-Gemeinde,

ich habe seit einigen Tagen ein Problem.
1. CUNO meldet sich schon seit längerer Zeit immer mal ab und wieder an. Ist das normal?
2. seit kurzem ist die Meldung "Setting CUNO fhtid ..." dazu gekommen, Dies könnte seit dem letzten Fhem-Update gekommen sein.
Ich habe überall gesucht und nix dazu gefunden. Was ist der Code "A00xxx"?
3. Was bedeutet "CUNO: Unknown code ...". Was für ein Code soll unbekannt sein?

Alle HomeMatic Devices und auch der CUNO arbeiten ansonst einwandfrei.
Ich bitte um eine kleine Hilfestellung.

Gruß
Eckhard


Auszug aus log-file

2021.10.17 06:14:57 1: 192.168.178.xxx:2323 disconnected, waiting to reappear (CUNO)
2021.10.17 06:14:58 3: CUNO: Possible commands: mBCFiAIGMRTVWXOefyyyyyyy
2021.10.17 06:14:58 2: Setting CUNO fhtid from A00BE to 0000
2021.10.17 06:14:58 1: 192.168.178.xxx:2323 reappeared (CUNO)
2021.10.17 06:21:31 3: CUNO: Unknown code 0000, help me!

2021.10.17 07:09:42 1: 192.168.178.xxx:2323 disconnected, waiting to reappear (CUNO)
2021.10.17 07:09:42 3: CUNO: Possible commands: mBCFiAIGMRTVWXOefyyyyyyy
2021.10.17 07:09:42 1: 192.168.178.xxx:2323 reappeared (CUNO)

2021.10.17 07:21:15 1: 192.168.178.xxx:2323 disconnected, waiting to reappear (CUNO)
2021.10.17 07:21:15 3: CUNO: Possible commands: mBCFiAIGMRTVWXOefyyyyyyy
2021.10.17 07:21:15 2: Setting CUNO fhtid from A0085 to 0000
2021.10.17 07:21:15 1: 192.168.178.xxx:2323 reappeared (CUNO)
2021.10.17 07:45:00 3: CUNO: Unknown code 0000, help me!


Auszug aus fhem.cfg

define CUNO CUL 192.168.178.xxx:2323 0000
setuuid CUNO 60f11850-f33f-0f9b-eada-f820f30864fyyyyyyy
attr CUNO hmId 5zzzz9
attr CUNO icon cul_868
attr CUNO rfmode HomeMatic
attr CUNO room 09.01_System

[Beta-User]

Seit einigen Tagen bedeutet? Interessant wäre v.a. die "version CUL_HM" - da gab es vor wenigen Tagen das letzte wichtige update. Wenn das nicht aktuell ist, wäre das das erste, was zu ändern wäre.

Ansonsten: bitte Code-Tags nutzen (der #-Button), und keine cfg-Auszüge, sondern "list" oder "list -r".

"unknowncode" ist ziemlich "beliebt", du solltest auf alle Fälle eine VCCU definieren (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU).

[eckhard scholz]

OK ich bin nicht so oft im Forum, bis jetzt habe ich fast alle meine Probleme und Fragen im Forum oder anders wo finden können.

Die Version von CUL_HM könnte noch eine ältere sein, wenn sie nicht mit Fhem-Update aktualisiert wird.

VCCU ist definiert

[Beta-User]

Sie wird mit FHEM-update aktualisiert. Das Problem könnte nur sein, dass bis vor ein paar Tagen eine Version im Umlauf war, die manche Wackler enthielt. Also: ist das 25059 oder höher, was "version CUL_HM" liefert, oder was kommt da raus?

[eckhard scholz]

also es ist die Version
CUL_HM.pm      25059 2021-10-10

[eckhard scholz]

Habe gerade noch mal ein Update gemacht:

00_CUL.pm             24815 2021-08-01 16:14:02
10_CUL_HM.pm       25078 2021-10-16 10:31:26
14_CUL_WS.pm       20918 2020-01-08 19:20:38

Mal sehen ob das hilft.
Und wenn nicht

[Beta-User]

OK, CUL 24815.
Dazu hat bisher keiner Probleme gemeldet, aber CUNO sind vermutlich auch nicht mehr so viele im Umlauf. Vielleicht kannst du noch die firmware version liefern?

An sich glaube ich auch nicht, dass es was mit 00_CUL.pm zu tun hat, sondern eher mit der geänderten IO-Initialisierung in CUL_HM.

@frank hatte da noch einen Vorschlag, der (eher vielleicht) helfen könnte, ist hier eingearbeitet: https://forum.fhem.de/index.php/topic,123473.0.html.

Sonst habe ich grade keine Idee, wo was fünfstelliges herkommen könnte, das paßt nicht zu CUL_HM-Hauptgeräten...

[eckhard scholz]

Also die CUNO Version ist V1.44 CUNO868.
Auch das heutige Update von CUL_HM.pm 25078 2021-10-16 hat nix gebracht, die Meldung tritt immer noch auf.
Das Gute ist erstmal, das trotzdem alle Devices einwandfrei arbeiten.
Na mal sehen was ich noch finde und ev. machen kann.
Was ist eigentlich der Nachfolger von dem CUNO? Ich hab das Teil bestimmt schon 6-7 Jahre.

Danke erstmal
Gruß
Eckhard

[Beta-User]

Bin kein CUNO-Experte, aber bei CUL ist die firmware firmwareversion irgendwo bei um die 1.6. Vielleicht reicht ein update der firmware?

(Wobei es eine Variante mit "timestamp" gibt, die für Homematic eigentlich zu empfehlen wäre (braucht ein anders (TS-) CUL-Modul).

"Nachfolger" ist schwierig, weil BidCoS (das alte HomeMatic-Protokoll) an sich ein Auslaufmodell ist und man vermutlich damit heute gar nicht mehr einsteigen würde. Direkter "Enkel" des CUNO dürfe MapleCUN sein (gibt's einen Wiki-Artikel zu), aber für Homematic ist ein "natives" Interface besser, für BidCoS "solo" mAn. dann also das HM-Mod-RPI-PCB, das man auch via Netzwerk einbinden kann (auch dazu gibt es einen Wiki-Artikel).

Würde erst mal nachsehen, ob eine aktuellere firmware bereit Abhilfe schafft.

[eckhard scholz]

Danke erstmal Betta-User,

ich werde das mit der 1.6 Firmware mal probieren. Das CUNO-Modul ist sonst i.o. hatte bis jetzt auch keine Probleme damit. Das Teil hatte für mich den Vorteil das ich es recht Zentral im Haus an das Netzwerk anschließen konnte.
Deine Vorschläge für den CUNO-Nachfolger werde ich mir mal ansehen.  Das HM-Mod-RPI-PCB ist bestimmt die beste Wahl, leider eben nur direkt am Rpi betreibbar. MapleCUN kenne ich nicht, werde also mal Wiki studieren.
Mit "timestamp" und  (TS-) CUL-Modul kann ich nichts anfangen, kannst Du mir da vielleicht noch auf die Sprünge helfen?
Es eilt ja nicht, da ja ansonsten alles Funktioniert.

Erstmal vielen Dank
Gruß
Eckhard

[MadMax-FHEM]

Das HM-Mod-RPI-PCB ist bestimmt die beste Wahl, leider eben nur direkt am Rpi betreibbar.

Hatte Beta-User doch schon geschrieben: geht auch per Netzwerk!
Siehe: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi

(PI ser2net o.ä. LAN-Adapter [WLAN mittels ESP])

Gruß, Joachim

[Beta-User]

ich werde das mit der 1.6 Firmware mal probieren. Das CUNO-Modul ist sonst i.o. hatte bis jetzt auch keine Probleme damit. Das Teil hatte für mich den Vorteil das ich es recht Zentral im Haus an das Netzwerk anschließen konnte.

Dann mal viel Erfolg. Falls du fertige firmware suchst, kannst du ggf. auch "aculfw" verwenden: https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices/CUNO (bzw. unter https://github.com/heliflieger/a-culfw gibt's einen Link).

Deine Vorschläge für den CUNO-Nachfolger werde ich mir mal ansehen.  Das HM-Mod-RPI-PCB ist bestimmt die beste Wahl, leider eben nur direkt am Rpi betreibbar.

Das mit dem Wiki hätte geklärt, dass es auch ohne Pi geht. Meines hängt z.B. an einem USB-seriell-Wandler, weitere Beispiele sind da auch zu finden, z.B. https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Betrieb_mit_einem_LAN-TTL-Wandler.
(Mit einem MapleCUN müßte auch OneWire gehen).

Mit "timestamp" und  (TS-) CUL-Modul kann ich nichts anfangen, kannst Du mir da vielleicht noch auf die Sprünge helfen?

https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796

[rudolfkoenig]

Vor dem Flashen bitte pruefen, ob es ein CUNO (ab 2010-11) oder ein CUNO2 (ab 2011-09) ist.

[eckhard scholz]

An Rudolf,

danke für den Tipp !!!
Ich werde vorher auf die Leiterplatte schauen.

[eckhard scholz]

Hallo Rudolf,

ich noch mal.
Was ist zu beachten beim flashen des CUNO2 ?
In culfw ist kein Unterschied beschrieben und es sieht so aus als ob ich die firmware 1.67 flashen kann.
Aktuell habe ich ein CUNO V2.1b mit FW V1.4

Gruß
Eckhard

[rudolfkoenig]

Keine Ahnung, ich hatte sowas nie gesehen, nur fuer den Vorgaenger CUN Firmware gebaut.
Aber ich habe gesehen, dass im culfw/Devices Verzeichnis jeweils ein CUNO und CUNO2 Unterverzeichnis gibt

Nachtrag: Ich wollte nur darauf hinweisen, dass man die Firmware aus dem richtigen Verzeichnis nimmt. Ich gehe davon aus, dass CUNO v2.1 ein CUNO2 ist.

[eckhard scholz]

Aha ok,
Ja ich denke auch das der Cuno2 ein 2.1b ist, das war der letzte der in dieser Art angeboten wurde.

Danke noch mal.
Gruß
Eckhard

[eckhard scholz]

Hallo ich noch mal.

mir ist es nicht gelungen die neuste Firmware 1.67 auf den CUNO zu flashen.
Wo bekomme ich die vorherigen Versionen ab culfw-1.44.tar.gz her?
Eine Historie über die Versionen habe ich gefunden aber nix zum download.
Ein link wäre gut.

Gruß
Eckhard

[rudolfkoenig]

SVN fuer culfw.de hat kein HTTP Frontend (wie trac bei FHEM, was Markus dazugebaut hat), d.h. man muss einen SVN Client verwenden.

[Beta-User]

Wenn grundsätzlich beim Flashen was schief geht, ist das Risiko groß, dass es auch mit historischen Versionen nicht klappt, oder?

Würde eher versuchen, eine fertige Binary zu flashen und dann ggf. genauer darzustellen, was du genau gemacht hast und wie das Ergebnis aussieht.
Den Thread-Titel auf CUNO2 anzupassen schadet vermutlich auch nicht (ersten Post editieren), falls jemand zufällig mitliest, der auch einen CUNO2 hat.

[eckhard scholz]

Ja ginge auch aber wo finde ich den die Binary Codes. Auch die finde ich nicht von älteren Versionen.

[Beta-User]

Warum denn ältere Versionen? Zumindest für die aculfw hatte ich einen Link zum Link für die aktuelle schon geliefert - funktional sollte das bzgl. Homematic keinen Unterschied zur regulären culfw machen.

[rudolfkoenig]

Ja ginge auch aber wo finde ich den die Binary Codes. Auch die finde ich nicht von älteren Versionen.

Ich will nochmal bescheiden auf meinen letzten Beitrag verweisen.

[frank]

oder noch besser gleich die passende tsculfw flashen (für homematic eigentlich das optimalste).
im zip habe ich sogar ein TSCUNO2.hex gesehen. 

https://forum.fhem.de/index.php/topic,24436.0.html

[eckhard scholz]

OK danke noch mal, an euch, für den Hinweise.
Ich schaue es mir an.

[eckhard scholz]

Abschließend von meiner Seite,
sei gesagt das ich es nun geschafft habe den CUNO2 mit FW V1.67 zu flashen. 
CUNO2 läuft mit V1.67 bis jetzt auch ohne Netzwerkaussetzer
Scheinbar hat es schon vorher mal geklappt aber ich hatte Problem mit den Terminalprogrammen. Ich kam immer nicht an den Cuno2 zum parametrieren ran und habe gedacht es ist eine falsch FW, mit TeraTerm hat es nun geklappt.

Ich habe wieder mal gemerkt, dass ich trotz der vielen Jahre mit Fhem noch einiges dazu lernen muß, zumal ich so was auch nicht alle Tage mache.
Aber das Forum hilft ! So auch weshalb AVRDUDE nicht gleich im Win7 arbeiten will (fehlende libusb0.dll) wäre ich nie drauf gekommen. Nochmals Danke an alle !!!

Was 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.

Gruß
Eckhard

[Beta-User]

Was 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.

Das lasse ich mal mangel eigener Kenntnisse unbeantwortet, will aber aus anderem Anlass darauf hinweisen, dass die aktuellen CUL_HM (etc.-) Module an der einen oder anderen Stelle noch wackelig sind und du  uU. durch die Zwischenversionen auch Attribute bzw. Inhalte verloren haben könntest. Aktuell vermutlich empfehlenswerter sind die Fassungen von hier: https://forum.fhem.de/index.php/topic,123436.0.html - und dann bitte mal die Attribute aus einem Backup von vor August 21 mit dem heutigen Stand vergleichen.

Für das weitere Vorgehen bietet es sich mAn. an, erst mal für Redundanz bei den IO's zu sorgen (das Pi-PCB in der einen oder anderen Form?), dann eine VCCU einzurichten (falls noch nicht vorhanden), und dann ggf. den CUNO2 nochmal mit franks Hilfe auf TSCUL-fw umzustellen.

[eckhard scholz]

OK und Danke !!! 

[yersinia]

Für das weitere Vorgehen bietet es sich mAn. an, erst mal für Redundanz bei den IO's zu sorgen (das Pi-PCB in der einen oder anderen Form?), dann eine VCCU einzurichten (falls noch nicht vorhanden), und dann ggf. den CUNO2 nochmal mit franks Hilfe auf TSCUL-fw umzustellen.

Aber Vorsicht, Mischbetrieb von TSCUL-fw und 'normalem' CUL_HM ist nicht vorgesehen afaik.

In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.
[...]
Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert. Nur diese Version bietet derzeit vollständige TSCUL/tsculfw Unterstützung. Zur Einsparung redundanter Events werden teilweise Readings (actuator, desired-temp, measured-temp) nicht mehr zusätzlich im HM-device, sondern nur noch in den jeweiligen Channels aktualisiert.
HMConfig.pm             -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm           -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
98_HMtemplate.pm   -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden.
Die 4 Dateien entsprechen einem Stand von Anfang 09/2020. Derzeit sollten diese verwendet werden.

Dabei sind die Dateien aber deutlich aktueller als 09/2020:

Code Auswählen Erweitern

# $Id: 10_CUL_HM.pm 24374o 2021-07-28 18:16:52Z noansi $
# $Id: 98_HMinfo.pm 24321g 2021-05-25 20:00:00Z noansi $
# $Id: HMConfig.pm 24773a 2021-07-19 20:00:00Z noansi $
die Revisionsnummer entspricht in etwa der Basis aus dem SVN ergänzt durch patches von noansi.

[Beta-User]

Aber Vorsicht, Mischbetrieb von TSCUL-fw und 'normalem' CUL_HM ist nicht vorgesehen afaik.

Ich bin da auch immer wieder verwirrt, was denn jetzt aktuell warum wohin ausgetauscht werden müßte. Daher hatte ich geschrieben: mit anderer Leute Hilfe...

Da ich aber grade ziemlich intensiv im Code von CUL_HM unterwegs war, _glaube_ ich, dass die gepatchte Version (und die aktuellen svn-Revisionen) eigentlich für den Betrieb mit einem TSCUL-Gerät ausgelegt sind und man daher nur das passende IO-Modul (und ggf. die angepaßte STACKABLETS, falls es ein Multi-IO ist) benötigt. Vielleicht sollte man das mal klären, das würde vielleicht dem einen oder anderen den Umstieg erleichtern...
(So finde ich das eine fürchterliche "wall of text", die mich bisher auch abgehalten hat, irgendwas an meiner (prinzipiell ja funktionierenden) Installation umzustellen).

[frank]

Aber Vorsicht, Mischbetrieb von TSCUL-fw und 'normalem' CUL_HM ist nicht vorgesehen afaik.

das ist so nicht korrekt.
nicht getestet sollte eher passen.

[rudolfkoenig]

Was 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]

(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.

das 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.

[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.

[frank]

würde mir wünschen

sehr, sehr lange vorher haben die engländer sicherlich den euro eingeführt. 

[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