Hallo zusammen,
ich habe das Problem, das mein nanoCUL433 (Chinaversion) bei dem folgenden Befehl sich verabschiedet und die "L-LED" dauerhaft schnell blinkt.
([07:30|8] and [Wg.Rolladen.timer] eq "on") (set Sz.Rolladen open, sleep 1; set Az.Rolladen open, sleep 1; set Wz.Rolladen.Tuer open, sleep 1; set Wz.Rolladen.Fenster open, sleep 1;set Kc.Rolladen.Tuer open, sleep 1; set Kc.Rolladen.Fenster open)
Hab dem CUL auf "Verbose 5" gesetzt, dazu hier das Log:
2015.08.03 07:30:00 3: SOMFY_set: handled command off --> move :off: newState :90:
2015.08.03 07:30:00 5: nanoCUL433 sending YsA1200061000003
2015.08.03 07:30:00 5: SW: YsA1200061000003
2015.08.03 07:30:00 5: CUL/RAW: /Y
2015.08.03 07:30:00 5: CUL/RAW: Y/sA12D0
2015.08.03 07:30:00 5: CUL/RAW: YsA12D0/061030
2015.08.03 07:30:00 5: CUL/RAW: YsA12D0061030/000
2015.08.03 07:30:00 4: CUL_Parse: nanoCUL433 YsA12D0061030000
2015.08.03 07:30:00 5: nanoCUL433 dispatch YsA12D0061030000
2015.08.03 07:30:01 3: SOMFY_set: handled command off --> move :off: newState :80:
2015.08.03 07:30:01 5: nanoCUL433 sending YsA82000A8000002
2015.08.03 07:30:01 5: SW: YsA82000A8000002
2015.08.03 07:30:01 3: SOMFY_set: handled command off --> move :off: newState :90:
2015.08.03 07:30:01 5: nanoCUL433 sending YsAB20009B000004
2015.08.03 07:30:01 5: SW: YsAB20009B000004
2015.08.03 07:30:01 3: SOMFY_set: handled command off --> move :off: newState :90:
2015.08.03 07:30:01 5: nanoCUL433 sending YsA6200086000005
2015.08.03 07:30:01 5: SW: YsA6200086000005
2015.08.03 07:30:01 3: SOMFY_set: handled command off --> move :off: newState :90:
2015.08.03 07:30:01 5: nanoCUL433 sending YsAA20005A000006
2015.08.03 07:30:01 5: SW: YsAA20005A000006
2015.08.03 07:30:01 3: SOMFY_set: handled command off --> move :off: newState :90:
2015.08.03 07:30:01 5: nanoCUL433 sending YsAA20004A000007
2015.08.03 07:30:01 5: SW: YsAA20004A000007
2015.08.03 07:50:51 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 disconnected, waiting to reappear (nanoCUL433)
2015.08.03 07:50:58 3: Setting nanoCUL433 serial parameters to 38400,8,N,1
2015.08.03 07:50:58 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 reappeared (nanoCUL433)
2015.08.03 07:50:58 5: SW: V
2015.08.03 07:51:01 5: SW: V
2015.08.03 07:51:01 5: CUL/RAW (ReadAnswer): V 1.65 nanoCUL433
2015.08.03 07:51:01 5: SW: ?
2015.08.03 07:51:01 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B
2015.08.03 07:51:01 5: CUL/RAW (ReadAnswer): C F i
2015.08.03 07:51:01 5: CUL/RAW (ReadAnswer): A Z
2015.08.03 07:51:01 5: CUL/RAW (ReadAnswer): E k G
2015.08.03 07:51:01 5: CUL/RAW (ReadAnswer): M K U
2015.08.03 07:51:01 5: CUL/RAW (ReadAnswer): Y R T
2015.08.03 07:51:01 5: CUL/RAW (ReadAnswer): V W
2015.08.03 07:51:01 5: CUL/RAW (ReadAnswer): X e f
2015.08.03 07:51:01 5: CUL/RAW (ReadAnswer): l t x
2015.08.03 07:51:01 5: CUL/RAW (ReadAnswer):
2015.08.03 07:51:01 5: CUL/RAW (ReadAnswer):
2015.08.03 07:51:01 3: nanoCUL433: Possible commands: BCFiAZEkGMKUYRTVWXefltx
2015.08.03 07:51:01 5: SW: X21
2015.08.03 07:51:01 5: SW: T01
2015.08.03 07:51:01 5: CUL/RAW (ReadAnswer): 1034
2015.08.03 07:51:01 5: GOT CUL fhtid: 1034
Hier hilft wirklich nur den nanoCUL vom USB zu trennen und neu anzuschließen.
Dachte erst, es sei die Structure schuld, deshalb habe ich alle Rolladen einzeln geschaltet.
Ist es ein Hardware- oder eher ein Modulproblem?
Bin für jeden Tipp dankbar!
Hallo Flexstarr,
generell ist es erstaunlich, dass beim ersten Kommando:
2015.08.03 07:30:00 3: SOMFY_set: handled command off --> move :off: newState :90:
das Absenden über den CUL (und auch den Empfang des Raw-Results) im Log sichtbar ist. Während bei den nachfolgenden Kommandos nur das Absenden
2015.08.03 07:30:01 5: nanoCUL433 sending YsA82000A8000002
sichtbar ist. Während aus dem SOmfy-Modul die Verarbeitung korrekt erscheint.
Sichtbar ist, dass der disconnect des nanocul erst 20 min NACH den Kommandos im Log sichtbar ist:
2015.08.03 07:50:51 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 disconnected, waiting to reappear (nanoCUL433)
Mir ist nicht klar, ob das auch erst 20 min später passiert, oder ob Du das Verhalten (dauerhaftes blinken) direkt eintritt?
Aus dem log ist aber auch ersichtlich, dass die eingestreuten sleep-Befehle nicht wie vermutlich gewünscht die Befehle in entsprechendem Abstand absetzen / verzögern. Denn bis auf den ersten werden alle Befehle in derselben Sekunde abgesetzt:
2015.08.03 07:30:01
Vielleicht löst es Dein Problem erstmal, wenn Du entsprechend die Verzögerungen umbaust, so dass wirklich Pausen entstehen?
Um 7:50:51 laut Log habe ich den CUL von USB getrennt und daraufhin wieder angeschlossen.
Das Blinken der LED setzt sofort ein, es lässt sich dann gar nichts mehr schalten.
Mit dem sleep hast Du Recht. Wie sollte ich es am besten umbauen?
Hatte den gleichen Befehl mit sleep 1, (Komma):
2015.08.02 08:30:00 3: SOMFY_set: handled command off --> move :off: newState :90:
2015.08.02 08:30:00 1: WARNING: sleep without additional commands is deprecated and blocks FHEM
2015.08.02 08:30:01 3: SOMFY_set: handled command off --> move :off: newState :90:
2015.08.02 08:30:01 1: WARNING: sleep without additional commands is deprecated and blocks FHEM
2015.08.02 08:30:02 3: SOMFY_set: handled command off --> move :off: newState :80:
2015.08.02 08:30:02 1: WARNING: sleep without additional commands is deprecated and blocks FHEM
2015.08.02 08:30:03 3: SOMFY_set: handled command off --> move :off: newState :90:
2015.08.02 08:30:03 1: WARNING: sleep without additional commands is deprecated and blocks FHEM
2015.08.02 08:30:04 3: SOMFY_set: handled command off --> move :off: newState :80:
Zumindest die Verzögerung hat funktioniert.
Zitat von: Flexstarr am 03 August 2015, 15:50:16
Mit dem sleep hast Du Recht. Wie sollte ich es am besten umbauen?
Ich bin jetzt kein Experte dafür, aber ich würde mich an den Beispielen zum Kommando sleep orientieren (in der fhem commandref). Die doppelten ;; sind dabei wichtig.
Hmm.. sollte man sleep, at oder am besten wait für Verzögerungen innerhalb eines DOIF verwenden?
siehe commandref zu DOIF - Damian hat diese extra auch auf deutsch verfasst.
Das passende Attribut wäre dann wohl wait.
Du darfst aber gerne auch at oder sleep verwenden - zu sleep vielleicht erstmal die Suche anwerfen.
Es kommen immer wieder die selben Fragen zu sleep und diese dürften sich nun langsam über die Suche beantworten lassen.
Fragen und/oder Beiträge zu DOIF sollten aber in den Bereich Automatisierung.
Warum?
Weil sich Damian echt Mühe macht um jedem zu helfen also darf auch jeder hergehen und Damian die Suche nach Fragebeiträgen abnehmen indem im richtigen Bereich gepostet (gesucht) wird.
Jep, da hast Du Recht.
Allerdings ist die Verzögerung nur eine Umgehung des eigentlichen Problems und keine direkte Lösung.
Die Ursprungsfrage ist weiterhin, warum sich der CUL beim Senden der Befehle aufhängt und wie man das weiter debuggen kann.
Aufhängen sollte er sich nicht, das ist richtig. Es gab wohl auch für einen "normalen" CUL einen Thread, der sich mit Problemen bei mehreren Befehlen hintereinander befasst hat (habe den Link jetzt auf die Schnelle nicht gefunden). Es gibt aber leider noch keine Lösung. Ich habe mich bisher mit der CULfw nicht wirklich befasst aber kenne mich recht gut im Somfy-Modul aus.
Das die Probleme nicht nur beim Starten der Rolladen, sondern auch am Ende der exakten Positionierung auftreten können (stop befehl bei erreichen der gewünschten Position) wäre es schön, dass in der culfw oder dem Somfy-Modul zu lösen und nicht über sleep/wait etc.
Ich hatte schonmal angeboten, im Somfymodul sicherzustellen, dass es nur alle x Sekunden ein Kommando absetzt. Leider wäre der Seiteneffekt, dass Positionierungen in diesem Fall inkorrekt ausgeführt würden (Also statt pos 90 anzufahren würde der Rolladen u.U. erst bei 100 stoppen). Deshalb ist das ebenfalls keine wirkliche Lösung.
Also bist Du der Meinung, das es definitiv ein Modul- und kein Hardwareproblem zu sein scheint.
Das Schalten mehrerer IT Funksteckdosen innerhalb einer Sekunden führt zumindest bei mir nicht zum gleichen Fehlverhalten.
Die genaue Position ist natürlich im SOMFY Modul essenziell wichtig.
Der CUL bleibt bei mir sofort hängen, sodass das STOP cmd gar nicht mehr gesendet werden kann.
(Wird morgens auch nicht benötigt, da die Rolladen komplett hochfahren.)
Zitat von: Flexstarr am 05 August 2015, 15:46:09
Also bist Du der Meinung, das es definitiv ein Modul- und kein Hardwareproblem zu sein scheint.
Das Schalten mehrerer IT Funksteckdosen innerhalb einer Sekunden führt zumindest bei mir nicht zum gleichen Fehlverhalten.
Die genaue Position ist natürlich im SOMFY Modul essenziell wichtig.
Der CUL bleibt bei mir sofort hängen, sodass das STOP cmd gar nicht mehr gesendet werden kann.
(Wird morgens auch nicht benötigt, da die Rolladen komplett hochfahren.)
Hallo Flexstarr,
soweit bin ich noch nicht. Es ist aus meiner Sicht eine Möglichkeit, allerdings nehme ich an, dass die meisten Leute bei Somfy mehr als einen Rolladen zugleich steuern (das klassische morgen-/abend-/wind-/Sonnen-Szenario).
Eine Pause zwischen den Kommandos ist aber auf jeden Fall nötig, da ein einzelner Befehl bei Somfy standardmässig 6 mal wiederholt wird und damit insgesamt mehr als eine halbe Sekunde "on air" ist, ohne zusätzliche Vor- und Nachverarbeitung in fhem oder cul.
Gruss,
Johannes
Bei mir verhält es sich genauso. :-\
Ich habe lange Zeit über ne Structure ein Gruppe von 4 Rolladen erfolgreich über einen Orginal Busware CUL und ziemlich alter FW (1.02) gefahren. Nun habe ich gestern einen NanoCUL 868 mit aktueller FW 1.65 im SlowRF Mode darauf angesetzt, und beim ersten fahren der Structure hängt sich das Ding weg. (schnelles blinken der Led)
Dann geht bei mir auch nix mehr bis man den NanoCUL neu ansteckt.
Wenn ich die Rolladen einzeln fahre, ist alles gut.
Ich habe das Problem auch schon vorher mit einem NanoCUL und alternativ FW 1.05 gehabt. Nun habe ich gehofft das es an der a-fw liegt und hab deshalb mal die orginal FW 1.65 geflasht. Aber leider stürzt der Nano wie gesagt dabei ab.
Nun habe ich der structure mal einen asyc_delay von 10 verpasst, und nun scheit es zu gehen.
Frage also, ob nun die FW oder der Chinal CUL ein Problem mit dem gleichzeitigen versenden von Somfy Befehlen hat.
Ich werde morgen mal die alte Orginal FW 1.02 flashen und das ausprobieren. Der Busware CUL konnte ja mit dieser FW ohne delay die structure fahren. Wenn der Nano das dann mit der selben FW nicht tut, liegt es irgendwie am Nano.
Aber wenn, frage ich micht warum ???
Hallo,
ich habe das gleiche Problem... mit nanoCUL433. Gibt es hierzu mittlerweile schon eine Lösung?
Den Workaround mit async_delay finde ich eigentlich nicht so toll...
Gruß
Luke
Gerade hatte ich das leidige Problem wieder.
Wenn ich Somfy Befehle in zu schneller Folge absende, hängt sich der Nano mit a-culfw wieder auf (Flackernde LED)
Das geht sogar wenn ich am Tablet über Tablet_UI zu schnell hintereinander den selben Befehl absetzte. Eben war ich mir nicht sicher ob ich den Button richtig getroffen habe, und habe deshalb in schneller Folge wohl so 3 mal drau getippt, Nix geht mehr.
Nur Nano neu anstecken hilft dann.
Hat denn keiner ne Idee ? Liegt es eher an der Hardware oder der a-culfw.
Ließt der Autor der a-culfw hier mit ? Oder wo kann ich mein Problem mal an Ihn Posten. Vielleicht kann er ja an der Firmware was schrauben.
Der einzige Stick der Problemlos mit den Rolladen arbeitet ist der Orginal Busware.
---Skusi
Zitat von: Skusi am 15 November 2015, 19:27:39
Gerade hatte ich das leidige Problem wieder.
Wenn ich Somfy Befehle in zu schneller Folge absende, hängt sich der Nano mit a-culfw wieder auf (Flackernde LED)
Hat denn keiner ne Idee ? Liegt es eher an der Hardware oder der a-culfw.
Ließt der Autor der a-culfw hier mit ? Oder wo kann ich mein Problem mal an Ihn Posten. Vielleicht kann er ja an der Firmware was schrauben.
Der einzige Stick der Problemlos mit den Rolladen arbeitet ist der Orginal Busware.
Sorry das kann ich nicht nachvollziehen, meines Wissens ist der nanocul der einzige bei dem bekannt ist das er nicht funktioniert (SCC und CUL haben das Problem wohl nicht).
Vielleicht will es ja jemand mal ausprobieren, ich habe eine test-firmware für den Nanocul (16Mhz / Nano / 433Mhz) gebaut, die zumindest nicht abstürzt.
Siehe dazu hier: http://forum.fhem.de/index.php/topic,24158.msg359928.html#msg359928 (http://forum.fhem.de/index.php/topic,24158.msg359928.html#msg359928)