Alternative culfw

[stefanru]

Hi cyablo,

ja ich benutze Structures um meine SOMFY Rolläden zu steuern.
Ich habe damit auch probleme. Wenn ich alle auf einmal schalte, fängt mein nanoCUL nachdem er 1 ein paar geschaltet hat offline. Die LED blinkt wie blöd.
Ich muss ihn dann neu initializieren.
Ich will das demnächst mal etwas genauer untersuchen.

Das ganze will ich demnächst mal untersuchen.
Ob das nun das selbe Problem bei dir ist weiß ich nicht.

Mein Workaround, den du auch probieren könntest ist bei der Structure den Wert async_delay auf z.B. 5 sekunden zu setzen.

Gruß,
Stefan

[cyablo]

Der Tipp war gut. Funktioniert so jedenfalls wesentlich besser. Interessanterweise lassen sich die Dosen aber über die FHEM Oberfläche einzeln extrem schnell ein und aus schalten.

Hast du das CUL auch per SER2NET durchgereicht oder direkt am USB Port? Ich muss mir das am WE auch mal genauer ansehen.

[adn77]

Das alles und noch viel mehr passt in einen Maple Mini.
https://forum.fhem.de/index.php/topic,60458.0.html

Ich wundere mich, warum die Frage noch nicht direkt gestellt wurde, aber nach deiner wunderbaren @arm Portierung:

Spricht etwas gegen eine Portierung auf den ESP8266(-07/12)? Da gibt es bis zu 4MByte!!! Flash und 40 bzw. 80MHz Systemtakt.
(Ja ich weiß, zusammen mit einem Arduino gibt's das längst, aber warum sollte man sich derart einschränken.)

Aus Erfahrung mit Ambilight-Portierungen, weiss ich, dass man sich nicht so sehr auf die Interrupts verlassen sollte, wenn zeitgleich starker WLAN-Verkehr stattfindet, aber das sollte ja Aufgabe des CC1101 sein. Die SPI-Kommunikation sollte nicht so Timing-kritisch sein. Gibt es andere technische Gründe?

Ich habe bisher nur mit der Arduino IDE gearbeitet, dort gibt es ja bereits eine Anpassungsschicht und eine entsprechende Compiler-Einbindung.

Gibt es einen groben "Fahrplan" was man neben der board.h und einem auf den Compiler angepasstes Makefile erstellen muss, um den Code zu portieren?

Danke an alle Beteiligten, für dieses geniale Projekt!

[stefanru]

Hi cyablo,

interessant das es bei dir bei IT auch was bringt. Ich bin bei meinen somfys mitlerweile sogar bei 10 sekunden, da läufts dann sehr gut, aber es dauert halt 8 Rollos zu steuern, ist aber ok für mich.
Was den Fehler verursacht ist mir noch nicht klar.

Ja mein nanoCUL ist per USB angebunden.

Steigt dein CUL dann auch aus?

Gruß,
Stefan

[Sidey]

Das Problem mit dem Struct ist, dass die Daten sequentiell an den CUL übergeben werden.
Der kann das dann nicht verarbeiten und es kommt zu Datensalat.

Im Signalduino wurde das gelöst indem die Befehle in eine Warteschlange gelegt werden.

Grüße Sidey

[kadettilac89]

Das Problem mit dem Struct ist, dass die Daten sequentiell an den CUL übergeben werden.
Der kann das dann nicht verarbeiten und es kommt zu Datensalat.

Im Signalduino wurde das gelöst indem die Befehle in eine Warteschlange gelegt werden.

Grüße Sidey

Ich habe auch mehrere it in einem struct die problemlos schalten.  Es gibt die Möglichkeit bei it Definition ein repeat attribut zu setzen. Das hat bei mir viel verbessert. Musst mal im forum suchen
wie es genau heisst. Komme aktuell nicht auf mein fhem.

[cyablo]

@stefanru
Also ich seh im FHEM Log nicht das der CUL disconnected, nur die von mir genannten Meldungen im Log. Müsste mal drauf achten was die LEDs dann machen.

@sidey
Danke für die Info, da muss ich dann wohl durch. Nochmal wechsel ich das Sendesystem nicht

Vielleicht wird der Workaround ja mal in die culfw portiert, oder ist die Warteschlange im Signalduino FHEM Modul implementiert?

[KölnSolar]

Komme aktuell nicht auf mein fhem

Hoffentlich nur eine Frage der räumlichen Distanz 

it Definition ein repeat attribut

Das Attribut schimpft sich ITrepetition

[Sidey]

Vielleicht wird der Workaround ja mal in die culfw portiert, oder ist die Warteschlange im Signalduino FHEM Modul implementiert?

Hauptsächlich ist die Warteschlange im FHEM implementiert.
Das war im Signalduino recht einfach zu implementieren, da dieser schon seit einiger Zeit nonblocking arbeitet.

Das Erhöhen der IT Repetition verschlimmert den Fehlerfall nur.
Das wird einem klar, wenn man versteht, was passiert.

Der Ablauf ist in etwa so:

1.Fhem sendet ein Kommando an das IO Device.
2. Das IO Device wertet den Befehl aus und fängt an das Signal zu senden.
3. Fhem weiss nicht, wann das IO Device fertig ist und sendet einfach mal das 2. Kommando.
4. Das IO Device wertet den Befehl jetzt wieder aus, war aber höchstwahrscheinlich mit dem 1. Kommando noch nicht fertig.

Erhöht man die Anzahl der Wiederholungen, dann braucht das IO Device länger um den Befehl abzuarbeiten. Dabei kommt es dann zu einer Kollision, wenn der Folgende Befehl empfangen wird.

Daher funktioniert es meist bei dem Ersten und letzten Gerät in einem Struct Recht meist, aber bei denen dazwischen eher nicht.
Eine einfache pause zwischen den Kommandos behebt dieses Problem auch, führt dann aber zu einem Blockieren von Fhem.

Grüße Sidey

[kadettilac89]

Hoffentlich nur eine Frage der räumlichen Distanz 

Ja, ein paar hundert km  ... über VPN käme ich auch drauf wenn nötig. Nur nicht mit dem Handy im Zug

[cyablo]

Ich setzt setzt das Problem mal bei SlowRF rein, rudolfkoenig  ist ja eh Maintainer von beiden Modulen (CUL und Strctures). Scheint mir aber mehr in Richtung CUL Modul für den Lösungsansatz zu gehen.

Edit: Falls sich sonst noch jemand zu dem Structure / CUL Problem melden möchte: https://forum.fhem.de/index.php/topic,62101.0.html

[Telekatz]

Ich wundere mich, warum die Frage noch nicht direkt gestellt wurde, aber nach deiner wunderbaren @arm Portierung:

Spricht etwas gegen eine Portierung auf den ESP8266(-07/12)? Da gibt es bis zu 4MByte!!! Flash und 40 bzw. 80MHz Systemtakt.
(Ja ich weiß, zusammen mit einem Arduino gibt's das längst, aber warum sollte man sich derart einschränken.)

Ich hab zwar noch nie etwas mit einem ESP8266 gemacht, denke aber nicht, dass da etwas dagegen spricht.

Aus Erfahrung mit Ambilight-Portierungen, weiss ich, dass man sich nicht so sehr auf die Interrupts verlassen sollte, wenn zeitgleich starker WLAN-Verkehr stattfindet, aber das sollte ja Aufgabe des CC1101 sein. Die SPI-Kommunikation sollte nicht so Timing-kritisch sein. Gibt es andere technische Gründe?

Für die FastRF Protokolle mag das stimmen. Dort übernimmt der CC1101 den korrekten Empfang der Pakete und die SPI-Kommunikation mit dem CC1101 ist nicht zeitkritisch.

Bei den SlowRF Protokollen ist der CC1101 jedoch nur ein einfacher Empfänger, der das demodulierte Signal kontinuierlich an einem Pin ausgibt. Die Decodierung des Signals wird allein vom Controller erledigt. Dafür werden dann auch Interrupts benötigt. Das ist dann schon zeitkritischer.

Gibt es einen groben "Fahrplan" was man neben der board.h und einem auf den Compiler angepasstes Makefile erstellen muss, um den Code zu portieren?

Man muss noch sämtliche Funktionen anpassen, die auf die Hardware zugreifen. Im einzelnen wäre das:

• Timer inklusive Timerinterrupts
• GPIOs (LED, CC1101)
• Pin Change Interrupt für SlowRF
• SPI
• Watchdog
• EEPROM Emulation
• Delay Funktionen
• Speicherzugriff (pgmspace)
• Ein/Ausgabefunktion, z.B UART, USB, Netzwerk

[thymjan]

Zum Thema flackern:

Das flackern liegt an der Empfindlichkeit des CC1101, der Rauschen im slowRF Mode empfängt. In rf_receive.c wird dann versucht das zu decodieren. Das löst dann das toggeln der LED aus.
Abhilfe schafft da, die Empfindlichkeit des CC1101 herunterzusetzen.

https://forum.fhem.de/index.php/topic,60458.msg529465.html#msg529465

Habe die Empfindlichkeit meines CULs von 4dB auf 16dB mal runtergeschraubt.

Code Auswählen Erweitern

set CUL sens 16 Und tatsächlich: das Flackern wird weniger.

Aber es stimmt schon: Vor den 22er Versionen war wesentlich mehr Ruhe. Da hat mein CUL eigentlich nur geblinkt wenn ich die Fernbedienung meiner IT-Steckdosen gedrückt habe.

[lonzo]

Hallo,

hatte zum Testen mal die aktuelle a-culfw auf meinem CUL V3, kann es sein das damit die Kommnikation zu meinen FHT 80b nicht mehr ordentlich funktioniert? Er kann zwar den Stellbefehl für die Ventilantriebe mitlauschen, bekommt aber von den Steuereinheiten die aktuelle Temperatur nicht und das setzen einer Temeratur aus FHEM heraus funktioniert auch nicht mehr.

Zurück auf Rudolfs "Original" klappt es wieder.

Überseh ich was? Mus mann evtl. noch was umstellen?


Danke und Gruß
Timo

[bjoernh]

Hallo,

hatte zum Testen mal die aktuelle a-culfw auf meinem CUL V3, kann es sein das damit die Kommnikation zu meinen FHT 80b nicht mehr ordentlich funktioniert? Er kann zwar den Stellbefehl für die Ventilantriebe mitlauschen, bekommt aber von den Steuereinheiten die aktuelle Temperatur nicht und das setzen einer Temeratur aus FHEM heraus funktioniert auch nicht mehr.

Zurück auf Rudolfs "Original" klappt es wieder.

Überseh ich was? Mus mann evtl. noch was umstellen?


Danke und Gruß
Timo

Kurz und knapp,  nimm die Original für FHT.  Da hat sich im Code sowieso nichts geändert.
Ansonsten sollte es natürlich gehen.