Nach Anschluss von neuem Cul missing ack

[xeenon]

Hallo Zusammen,

Ich habe gerade einen zweiten cul zusammen gelötet. Es lief bereits einer für die Homematic Aktoren. Der zweite sollte für Fs20 Wechselschalter sein.

Ich habe alles nach meiner Vorlage nachgelötet, im Prinzip wie der erste.

Zum Testen habe ich den Arduino aus dem Sockel vom ersten Cul genommen und in den neuen gesetzt. (bei beiden ist der Baugleiche cc1101 verbaut). An den selben Port angeschlossen (in FHEM ist der Pfad definiert, nicht per Seriennummer da meine Arduinos keinen ftdi haben).

Erwartet habe ich das ich mei Hm Rollo ganz normal fahren kann. Aber nichts passiert. Fhem sagt mir missing ack.

Naja, dachte ich mir, hab ich wohl irgend wo nen Fehler drinnen. Hab den Arduino in den ursprünglichen Cul zurück gesteckt, wieder an seinen Port angeschlossen und.... Missing ack.

Ich habe den raspi neu gestartet, fhem neu gestartet, versucht das Rollo anzulernen, aber nichts hilft.

Ich habe den Arduino und den cc1101 aufs Breadboard gepackt, und immer noch nichts. Ich bin echt ratlos. Kann mir jemand weiterhelfen?

List sagt:

CUL: nanoCUL_433 (Initialized) nanoCUL_868 (Initialized)

(Initialized) CUL_HM: WZ.Rollo.Terrasse (MISSING ACK)


Grüße

Kurzer Auszug aus dem log:
2017-03-23_15:05:41 WZ.Rollo.Terrasse set_100 2017-03-23_15:05:44 WZ.Rollo.Terrasse ResndFail 2017-03-23_15:05:44 WZ.Rollo.Terrasse MISSING ACK

[Beta-User]

Als erstes solltest Du mal den Rollo-Aktor mit einem clear all versorgen und es dann nochmal versuchen.

Klappt das nicht, liefere doch bitte mal jeweils in Code-Tags ein vollständiges list aller Devices (cul433, cul868, Rollo-Aktor) sowie die Ausgaben von

Code Auswählen Erweitern

ls -l /dev/serial/by-id
ls -l /dev/serial/by-path

Vermutung: Den neuen HM-Cul mußt Du evtl. erst mal initialisieren, also erst mal die Register usw. setzen. Wenn FHEM meint, das sei bereits erledigt, passiert das nicht und der CUL kann nichts mit den Befehlen anfangen, die er erhält. FHEM glaubt aber, es fehle (nur) noch eine Rückmeldung und sendet beim Wechsel der IOs nichts mehr...

[en-trust]

Ich bekomme seit Tagen auch jeweils ein ResndFail mit anschließendem Missing ACK geliefert, obwohl die Rollläden runter/rauf fahren.
GePaired sind sie. Woran könnte das liegen ?

hier al ein list

Code Auswählen Erweitern

Internals: CFGFN ./FHEM/fhem_activeactors.cfg DEF 49DA45 IODev myCUL NAME SZ.Jalousie.Rechts NOTIFYDEV global NR 195 STATE MISSING ACK TYPE CUL_HM protCmdDel 1 protResnd 3 last_at:2018-01-25 08:04:36 protResndFail 1 last_at:2018-01-25 08:04:40 protSnd 1 last_at:2018-01-25 08:04:23 protState CMDs_done_Errors:1 READINGS: 2018-01-24 08:05:29 CommandAccepted yes 2017-07-14 13:26:41 D-firmware 2.8 2017-07-14 13:26:41 D-serialNr NEQ0076387 2017-09-09 22:45:09 PairedTo 0xF11034 2017-09-09 22:45:10 R-driveDown 23.1 s 2017-07-21 07:44:37 R-driveTurn 0.5 s 2017-09-09 22:45:10 R-driveUp 24 s 2017-07-21 07:44:36 R-pairCentral 0xF11034 2017-07-21 07:44:37 R-powerUpAction off 2017-07-21 07:44:37 R-sign off 2018-01-10 23:59:55 RegL_00. 2018-01-24 08:05:57 deviceMsg on (to myVCCU) 2018-01-25 08:04:23 level set_100 2018-01-24 08:05:57 motor stop:on 2018-01-24 08:05:57 pct 100 2018-01-04 19:16:26 powerOn 2018-01-04 19:16:26 2018-01-24 08:05:57 recentStateType info 2018-01-25 08:04:40 state MISSING ACK 2018-01-25 08:04:40 statePosition 0 2018-01-24 08:05:57 timedOn off helper: HM_CMDNR 188 cSnd ,11F1103449DA450201C8 dlvlCmd ++A011F1103449DA450201C8 mId 006A regLst ,0,1,3p rxType 1 expert: def 1 det 0 raw 1 tpl 0 io: newChn +49DA45,00,00,00 rxt 0 vccu myVCCU p: 49DA45 00 00 00 prefIO: myCUL mRssi: mNo io: prt: bErr 0 sProc 0 q: qReqConf 00 qReqStat 00 role: chn 1 dev 1 prs 1 tmpl: Attributes: IODev myCUL IOgrp myVCCU:myCUL autoReadReg 4_reqStatus comment 1-fach Schaltaktor fuer Schlafzimmer-Jalousie (Rechts) devStateIcon auf:fts_shutter_10 zu:fts_shutter_100 *:fts_shutter_50 event-on-change-reading state eventMap on:hoch off:runter stop:stop expert 2_raw firmware 2.8 group Aktoren icon fts_shutter_automatic model HM-LC-Bl1PBU-FM peerIDs 00000000, room CUL_HM,Schlafzimmer serialNr NEQ0076387 subType blindActuator userReadings statePosition {if(ReadingsVal($name,"state","0") eq "up" or ReadingsVal($name,"state","0") eq "down" or ReadingsVal($name,"state","0") eq "closed" or ReadingsVal($name,"state","0") eq "open_ack") {ReadingsVal($name,"state",0)} else {ReadingsVal($name,"position",0)};} webCmd statusRequest:toggleDir:pct:on:off:up:down:stop


[Beta-User]

puh, alter Thread, ob das daselbe Problem ist?...

Im Kern scheint hier ein größeres Funkproblem vorzuliegen, dein list ist leider schlecht zu lesen, da alles nebeneinander steht.
Jedenfalls: Es wird gar kein RSSI-Wert ausgespuckt, es sollten aber zwei vorhanden sein (Sende- und Empfangsseitig). Ist das das bisher einzige HM-Gerät? (Dann besser auch nochmal ein unpair machen und dann die HM-ID "F11034" in irgendwas sinnvolles ändern, es geht praktisch jeder beliebige Hex-Wert mit 6 Stellen (außer "000000" und "FFFFFF")).

Wenn andere vorhanden sind: da mal nachsehen, wie das ausschaut. Sieht mir nach einer wackeligen Verkabelung aus (Glaskugel...), oder die Entfernung ist abartig bzw. die funktechnischen Rahmenbedingungen.

[en-trust]

Dann besser auch nochmal ein unpair machen und dann die HM-ID "F11034" in irgendwas sinnvolles ändern.

Warum ist F11034 keine sinnvolle ID ? Was könnte ich sonst nehmen (sowas AxF077)?

[Otto123]

Weil diese hmId vom Cul automatisch aus dem Hauscode 1034 erzeugt wird. Da dieser Hauscode in irgendeinem Beispiel steht, teilen sich wahrscheinlich 90 % aller Cul Nutzer die IDs F11234 F11034 F10000.
Außerhalb der CUL Szene ist auch 123456 sehr beliebt.
AxF077 ist jetzt leider keine gültige ID weil es keine Hex Zahl ist. Diese darf 0-9 und A-F enthalten. 

Ganz abgesehen davon, ist der CUL kein guter Homematic IO -> https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale

Gruß Otto

[Beta-User]

@Otto:
Danke, besser hätte ich das auch nicht sagen können .

Als Ergänzung: Da ein HM-Device (jedenfalls, solange es nicht AES haben will) jedes Kommando akzeptiert, das von einer Zentrale (oder allg. einem anderen Device) kommt, die/das die "richtige" ID hat, ist jeder Nachbar, der "zufällig" dieselben Anleitung hatte, davon überzeugt, dass er auch deine Devices in seine Steuerung einbauen kann und darf .

Die "F11034" entsteht übrigens aus dem Hauscode im Einsteiger-pdf, die "F10000" daraus, dass man als Hauscode mangels FHT-Devices wie empfohlen die "0000" vergibt und "A9F077" wäre ok...

Ansonsten, wenn dein CUL an sich ok sein sollte (wonach es _nicht_ aussieht): Für HM gibt es eine spezielle firmware und Module (TS_CUL), damit scheinen sich viele Probleme vermeiden zu lassen.

[Otto123]

Ansonsten, wenn dein CUL an sich ok sein sollte (wonach es _nicht_ aussieht): Für HM gibt es eine spezielle firmware und Module (TS_CUL), damit scheinen sich viele Probleme vermeiden zu lassen.

Darauf verweist indirekt mein Link 

[Beta-User]

Darauf verweist indirekt mein Link 

Schon klar, wir hatten den part ja eingehend diskutiert . Aber da er den (vermutlich nicht funktionierenden) CUL schon hat, wollte ich ihn nochmal ausdrücklich in die Richtung schubsen.

Aber den Hinweis, dass er sich die Verkabelung nochmal ansehen sollte, hat @en-trust vermutlich übersehen in der Verwunderung darüber, dass das nicht der Weisheit letzter Schluß ist, was er aus offiziellen Anleitungen entnommen hat...

Zurück zum Thema: was sagt ccconf?

[en-trust]

Also werde ich erstmal die neue Firmware (https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585) aufspielen. Die besagten pm module sind aber dann vermutlich alle über update installierbar ?

Beim Cul dann nicht 1034 in die cfg sondern F077 (A9F077) als id eingeben und dann nochmal alles pairen (

Bzgl. der Kabel ist alles 'meisterlich' installiert.

[Otto123]

attr <> hmId sollte es geben, dort bitte die hmId eintragen.

[en-trust]

Einfach über fhem mit TSCULflash MeinCulDevice TSCUL_V3 flashen und in fhem nochmal ein update mit restart machen, dann sollten alle pm Module von den usern die zu der Firmeware gehören mit drin sein ?!

So wie ich es gelesen habe wurden hier Probleme mit den TimeOuts, die zu den Missing ack führen behoben, was ja scheinbar auch mein Problem ist.

[Beta-User]

Die Infos, wie TSCUL zu installieren ist, sind im ersten post dazu von ansgar enthalten bzw. es gibt dazu einen Wiki-Thread von Joachim (?). Das flashen des CUL ist jedenfalls nur die halbe Wahrheit, und ich habe auch nicht die Neigung, hier eine Anleitung draus zu machen, die ja woanders schon zu finden ist.

Da die Verkabelung "meisterlich" ist:

Zurück zum Thema: was sagt ccconf?

So, und jetzt bin ich hier raus .

[en-trust]

Meine Frage ob die pm Module mit update installiert werden wurde leider auch nicht beantwortet. Mittlerweile bin ich auch zu Hause und kann lokal nachsehen.

00_TSCUL.pm wurde in meiner fhem Installation nicht gefunden, muss wohl alles manuell hinzugefügt werden. Gibt es eine Liste ?

Jetzt jkann ich auch das ccconf liefern... Immer diese Ungeduld (

Code Auswählen Erweitern

myCUL ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB

[Beta-User]

Nein, in dem zip aus dem Thread sind auch die erforderlichen Module zu entnehmen (und dann nicht mehr per update zu erneuern...).
Diese _ersetzen_ teilweise die vorhandenen, soweit ich das verstanden habe.

Was ccconf angeht: die Kommunikation scheint ja zu klappen, von daher könnte die Verkabelung tatsächlich "meisterlich" sein .