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
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 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...
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
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
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.
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)?
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. ;D
Ganz abgesehen davon, ist der CUL kein guter Homematic IO -> https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale
Gruß Otto
@Otto:
Danke, besser hätte ich das auch nicht sagen können :D .
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.
Zitat von: Beta-User am 01 Februar 2018, 09:29:07
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 ;D
Zitat von: Otto123 am 01 Februar 2018, 09:52:05
Darauf verweist indirekt mein Link ;D
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?
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 :o(
Bzgl. der Kabel ist alles 'meisterlich' installiert.
attr <> hmId sollte es geben, dort bitte die hmId eintragen.
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.
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:
Zitat von: Beta-User am 01 Februar 2018, 10:09:52
Zurück zum Thema: was sagt ccconf?
So, und jetzt bin ich hier raus >:( .
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 :o(
myCUL ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
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 ;) .
wollte nun die neue Firmeware auf den cul flashen allerdings kennt fhem den Befehl TSCULflash der in der Doku steht nicht. Und direkt im Terminal mit sudo ausgeführt erhalte ich auch nur dfu-programmer: no device present. Aber das habe ich derzeit noch erfolglos im anderen Beitrag gepostet.
Da du einen Nano hast (?): avrdude verwenden, damit sollte es gehen (fhem darf nicht gleichzeitig auf das Gerät zugreifen wollen).
Ich verwende aber einen original Busware CULv3 868Mhz.
Ok, sorry, dann paßt das mit dfu...
Hast du den Reset-Knopf beim Einstecken gedrückt gehalten?
Soweit ich verstanden habe muss man den nicht drücken wenn der cul einfach nur geupdated werden soll.
Mich wundert auch warum der Befehl TSCULflash in fhem zum flashen nicht funktioniert, obwohl die Doku hier davon spricht.
Der ATMega32U muß in einen anderen Modus. Das kann uU. von FHEM aus angestoßen werden, der Weg zu Fuß ist die Taste. Wäre doch einen Test wert, oder?
Die speziellen TS-Sachen kenne ich nicht (hatte mit fw 1.61 nie Probleme, die ist immer noch drauf; jetzt + HMUART@VCCU), aber im Hintergrund läuft m.E. immer dasselbe ab. Es sollte daher immer gehen, wenn man den "Fußweg" nimmt und den Hinweisschildern folgt.
Und "no device present" ist m.E. jedenfalls der deutliche Hinweis, dass kein ATMega32U im bootloader-Modus im USB-System angemeldet ist...
dass kein ATMega32U im bootloader-Modus im USB-System angemeldet ist.
Bekomm ich dann wohl über die Tase am cul ?
...das war die Botschaft...
Bevor ich aber alles flashe und auch eine neue hmid vergebe, muss ich dann ja alle hm komponenten neu pairen. Bei den Rollos und Türen kein Ding aber die 2fach Aktoren für die Fussbodenheizung musste ich beim pairen extra mit einem Schalter versehen. Das wollte ich mir jetzt aber klemmen. Reicht es daher wenn ich einfach im coding die hmid anpasse bzw mit dem pairserial Befehl arbeite ?
Jetzt hat er es gerafft...
Bootloader fehlte doch noch...
pi@raspberrypi:/opt/fhem/FHEM/firmware $ sudo dfu-programmer atmega32u4 erase
pi@raspberrypi:/opt/fhem/FHEM/firmware $ sudo dfu-programmer atmega32u4 flash TSCUL_V3.hex
Validating...
28632 bytes used (99.86%)
pi@raspberrypi:/opt/fhem/FHEM/firmware $ sudo dfu-programmer atmega32u4 reset
Jetzt sagt er mir in fhem bei myCUL initialized und disconnect im Wechsel. Vermutlich weil ich nun erstmal den Cul mit define CUL_868 TSCUL /dev/CUL868_0@12000000 1234 neu definieren muss.
Warum ist in dem Beispiel aber @12000000 ? Ich habe im alten @38400 stehn. Gibt es da jetzt einen Unterschied ?
Wie wäre es mit trial+error?
38400 klingt für mich wie eine sonnige Wahl der Baudrate...
Das Delfine würde ich noch auf /dev/serial/by-id/... umstellen. Wiki, Tipp der Woche.
Also jetzt habe ich den CUL erfolgreich mit der Firmware 0.21 geflashed und er blickt jetzt zwar gleichmässig, aber die HM Komponenten arbeiten mit ihm. Ich habe erstmal nicht neu gepaired sondern werde erstmal mit der alten Id arbeiten.
define myCUL TSCUL /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5.4:1.0@38400 1034
attr myCUL group Hardware
attr myCUL hmId F11034
attr myCUL hmLanQlen 1_min
attr myCUL icon cul_868
attr myCUL rfmode HomeMatic
attr myCUL room System
Ich kann für den moment zumindest aber sagen, dass die Jalousien ohne Missing ack oder resnderror arbeiten und der Haustürkontakt auch schnell grün anzeigt statt bisher orange.
Haben sich durch die Firmware auch die rssi Werte verbessert ? Hat zumindest den Anschein.
Raspi steht im DG und im EG die Jalousie hat RSSI -87. Dazwischen liegt noch OG mit RSSI -78.5.
myCUL ccconf => freq:868.300MHz freqOffs:-20.630kHz bWidth:101kHz freqIF:152.34kHz rAmpl:33dB sens:8dB dRate:9.993kBit/s
agcPrio:1 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0
CCAmode:3 csRelThr:10dB csAbsThr:7dB
Ich werde beobachten und berichten. DANKE an Eure Geduld.
Frage noch, wenn ich die ID ändern will musss ich ja alles neu pairen. Kann ich das auch über hmserails... machen ? Denn gerade bei den Stellmotoren der FH müsste ich die Verkabelung ändern und sonst nen Taster anbringen.
Dann sei erstmal froh, dass es funktioniert. Das mit der hmId finde ich nachrangig.
Es geht prinzipiell auch mit der Seriennummer, aber es gibt bei manchen Geräten damit Schwierigkeiten. Also sei erstmal zurückhaltend.
Vielleicht hat dazu noch jemand eine Idee.
Gruß Otto
Mmhhh... eine Fehlermeldung hab ich von einer Jalousie jetzt doch erhalten, die ich noch nie hatte IOerr. Allerdings hat sie dann trotzdem zu gefahren.