nanoCUL steigt nach dem Triggern von structure aus

[HeavyKid]

Hallo Leute,

auf der Suche nach einer Steuerunmöglichkeit für meine Somfy-Rolläden bin ich auf FHEM gestoßen. Kurzer Hand den Server auf einem Cubietruck aufgesetzt und mir ein 433-nanoCUL aus einem Arduino nano (ch340) und einem cc1101 zusammengebaut. Die Freude war groß nachdem ich meine Rollläden einzeln steuern konnte!

Damit ich nicht jeden Rollladen einzeln steuern muss (sind insgesamt 14 Stück) habe ich mir structures definiert um diese auf einen Schlag anzusteuern. Un da fingen die Probleme an! Nach dem Triggern einer Funktion (egal was auf zu oder my-pos) wurde die Funktion nur bei einem Teil der Rolläden ausgelöst und der nanoCUL hat sich dann verabschiedet. Die LED blinkt dann ganz  schnell, FHEM nimmt Befehle entgegen es tut sich aber nichts mehr. Der Status vom CUL ist auf Initialized. Nach dem Resetten des nanoCUL ist wieder alles normal und ich kann wieder die Rollläden einzeln zu und auf machen.

Hat jemand einen Rat für mich?

[BlackStone]

hm, ich vermute mal das du die leistung von dem nano überlastest. zuviele aufträge gleichzeitig.
oder aber die sende frames, ausgelastet. so das der ne stunde pause will.
hm, könntest du mit notifys probieren, wenn eine unten/oben ist die nächste per notify fahren lassen usw.
schaut von aussen auch so aus als wenn einer von a nach b rennt. ^^

[HeavyKid]

Danke für die Antwort!
Wie meinst Du das mit dem Überlasten? Also structures sind auf 5 Motoren eingestellt, so dass theoretisch nur 5 Telegramme verschickt werden müssen.
Mit notifys habe ich es ebenfalls probiert. Das Ergebnis ist ähnlich nach dem 3 Rolladen steigt der CUL aus. Es scheint tatsächlich so zu sein, dass der CUL mit den Delays zwischen dem Versenden der Nachrichten nicht klar kommt. Die Frage ist, was die Ursache dafür sein kann? Falsche Konfiguration? Falsche Schaltung?

[BlackStone]

nun, mit überlasten meinte ich die datendichte, 5 telegramme selbst ist ja nicht die welt, jedoch wie groß sind die jeweiligen. denn der cul muss diese ja auch buffern und evtl. antworten von den aktoren empfangen können. und wenn da etwas zugleich reinrauscht, hast du das sagen wir mal gejammer. einer ruft mach hü beim andern kommt mach ho an und meldet das da was nicht passt und möchte eine bestätigung. so das wieder gesendet werden muss.
wenn man da pech hat kann es passieren das alles durcheinanderquasselt (funkt) und du hast den perfekten jam.
evlt, kannst ja im notify mal versuchen, mit einer zeit prüfung zu arbeiten. z.b. rollaktor 1 runterfahren rückmeldung (falls es so etwas gibt) abwarten und den zweiten notify erst loslegen lassen wenn nach dem setzen vom 1. 10 sekunden vergangen sind.
also einfach per hand verzögern.

[justme1968]

schau dir das async_delay attribut an. damit kannst du eine verzôgerung in dir structure einbauen.

gruss
  andre

[HeavyKid]

Super! Danke für den Tipp! Es scheint tatsächlich zu funktionieren.

[viegener]

Das Problem tritt wohl im Zusammenhang mit Somfy-Rolläden und Nanocul auf.

Ich habe mal eine test-firmware für den nanocul erstellt, die das Problem des Abstürzens nicht mehr hat.

Siehe dazu auch hier http://forum.fhem.de/index.php/topic,24158.msg359928.html#msg359928

[australien]

Hallo Viegener

ich habe mir deinen verlinkten Threat angesehen, habe die gleichen Probleme.

es dürfte in die aktuelle FW VERSION V 1.67 nanoCUL433 noch nicht eingearbeitet sein.
Wo kann ich deine korrigierte FW finden? downloaden?

danke!

Robert

[viegener]

Hallo Viegener

ich habe mir deinen verlinkten Threat angesehen, habe die gleichen Probleme.

es dürfte in die aktuelle FW VERSION V 1.67 nanoCUL433 noch nicht eingearbeitet sein.
Wo kann ich deine korrigierte FW finden? downloaden?

danke!

Robert

Ich habe das als test-firmware an den oben verlinkten Beitrag angehängt. Allerdings ist in dem Thread auch zu sehen, dass das Problem damit nicht vollständig gelöst ist. Es bleibt das grundsätzliche Problem, dass SOmfy-Befehle sehr lange dauern)