"Structure" überlastet CUL

cyablo · 07 Dezember 2016, 10:14:02

Moin,

ich habe vor kurzem ein paar Intertechno Dosen in einem Structure zusammengefasst. In Verbindung mit einem miniCUL gibt es da wohl Probleme mit der Kommunikation zum CUL.

Siehe:
https://forum.fhem.de/index.php/topic,35064.msg534685.html#msg534685
https://forum.fhem.de/index.php/topic,35064.msg534710.html#msg534710

Sidey hat dort angemerkt dass das Problem beim Signalduino mit einer Warteschlange im Modul gelöst wurde. Ich bin mir jetzt nicht sicher ob die Lösung eher im Structure Modul oder im CUL Modul zu finden ist, möchte jetzt aber auch nicht Crossposten. Da Structures ja auch für andere Dinge genutzt werden, ist die Anfrage hier wahrscheinlich besser aufgehoben.

justme1968 · 07 Dezember 2016, 10:17:45

mit async_delay kannst du pausen zwischen den einzelnen geräten der structure einbauen.

probier mal ob das hilft.

gruss
andre

cyablo · 07 Dezember 2016, 10:26:27

Hatten wir im aculfw Thread auch schon besprochen, hilft zwar, aber: 1. Ausführung dauert dadurch unnötig lange, ein User musste dort schon 10 Sekunden einstellen damit es nicht zu Fehlern kam. 2. FHEM blockiert dadurch laut User sidey in der Zeit. Ist also mehr ein Workaround als eine Lösung.

rudolfkoenig · 07 Dezember 2016, 11:05:51

IT (insb. die Nachrichtenlaenge) kenne ich nicht.
00_CUL.pm ist auf FS20 geeicht, und wartet im slowRf 0.3s nach jedem Sendevorgang.
Falls man mehrere Sender hat, dann sollte man sich sendpool anschauen.

Zitat1. Ausführung dauert dadurch unnötig lange, ein User musste dort schon 10 Sekunden einstellen damit es nicht zu Fehlern kam

Kannst du bitte erklaeren, warum 10s notwendig sind? Also mit Nachrichtenlaufzeit, Antwort, Repeater, etc.

Zitat2. FHEM blockiert dadurch laut User sidey in der Zeit.

Das halte ich (nach kurzen Blick ins 98_structure.pm) fuer eine unwahre Behauptung. Gibt es Beweise dafuer?

cyablo · 07 Dezember 2016, 12:34:21

Aktuell kann ich nur sagen das sich die Intertechno Dosen direkt über FHEM nahezu beliebig schnell ein und aus schalten lassen, sobald diese aber in einem Structure vereint sind, kommt es beim Schalten des Structures zu folgenden Log Einträgen:

Code Auswählen

2016.12.06 13:25:05 2: cul_og IT_set: Lampe_Flur_OG off
2016.12.06 13:25:06 2: cul_eg IT_set: LichterketteKueche off
2016.12.06 13:25:06 2: IT IODev device didn't answer is command correctly:   raw => i40455419
2016.12.06 13:25:06 2: cul_og IT_set: Salzlampe off
2016.12.06 13:25:06 2: cul_eg IT_set: Stehlampe_Flur off
2016.12.06 13:25:06 2: IT IODev device didn't answer is command correctly:   raw => isF000FFFF0FF0
2016.12.06 13:25:06 3: cul_og IT: Stehlampe_Flur off->off
2016.12.06 13:25:06 3: cul_eg IT: message "isf000fff0fff0" (14) too short!
2016.12.06 13:25:06 3: cul_eg IT: message "isf000fff0fff0" (14) too short!
2016.12.06 13:25:06 3: cul_eg: Unknown code isf000fff0fff0, help me!

async_delay von 5 Sekunden hat das Problem bei mir jedenfalls behoben, ist aber unschön da die Ausführungszeit nur unnötig verlängert wird. Die Aussage über das Blocking-Verhalten habe ich nur 1zu1 so weiter geben und noch nicht selbst getestet.

Durchaus möglich das 0,3 Sekunden bei IT zu knapp sind. Ich werde mir das ganze mal die Tage mit meinem SDR etwas genauer anschauen.

Edit1: Sendpool hilft dabei leider nicht, der ist bei mir bereits definiert und jede Dose einem IODev zugewiesen.
Edit2: async_delay von 1-2 Sekunden reicht nicht um 4 Dosen in einem Structure zuverlässig zu schalten. Oft reagiert dann eine Dose nicht.

cyablo · 19 Januar 2017, 13:01:49

Sorry das ich das Tema noch mal wieder ausgrabe: Mir ist jetzt mal aufgefallen dass das nicht am struct selbst liegt. Wenn ich z.B. mehre Dosen nach Sonnenaufgang schalten lassen, klappt das auch nur wenn mehre Sekunden Verzögerung mit einbaue (sunrise(), sunrise(+5), sunrise(+10)...)

Tedious · 19 Januar 2017, 13:59:13

Ist bei mir ähnlich. Den Delay musst Du testen, bei mir sind 2 Sekunden ideal. Ich schalte große Strukturen aber auch nur selten (ins Bett alles aus, keiner da alles aus....).

cyablo · 19 Januar 2017, 15:17:41

Ich bin aktuell bei 5 Sekunden und selbst das klappt nur zu 98%, hin und wieder bleibt dann doch mal eine Lampe AN/AUS. Grade jetzt über die vergangenen Feiertage ist das schon nervig wenn die Lichterkette am Haus die ganze Nacht durch strahlt

rudolfkoenig · 19 Januar 2017, 16:02:31

Wenn es mehr als 0.5s ist, dann sind vmtl. andere Effekte im Spiel, wie Antwort von den Geraeten, irgendwelche notify/DOIF die auf Events reagieren und auch Funknachrichten generieren oder RFR, der die Nachrichten per "echo" zurueckschickt.

Apropos RFR: in der 1.67-er Version von culfw kann man mit sowas wie "ufKERV" die weitergeleitete Nachrichten Filtern (in diesem Fall wird nur das, was mit K,E,R und V anfaengt, gefunkt, also S300, EM*, Hoermann und Antwort auf die Version abfrage). D.h. vom Basis ausgesendete FS20 und FHT Telegramme werden nicht automatisch zurueckgeschickt. Das RFR kann aber weiterhin zum Schalten von FS20 oder FHT verwendet werden.
Leider wird das noch nicht im EEPROM verewigt, d.h. es muss nach jedem RFR Neustart gesetzt werden.

Tedious · 19 Januar 2017, 16:07:10

Und noch ein Gedankengang - das kann evtl. auch an der Hardware liegen. Ich habs jetzt bei den Structures nicht mehr getestet - aber im Flur hängt bei mir ein IT-Bewegungssensor, wenn der triggert schaltet er die Deckenlampe mit einem HUE Leuchtmittel mit einem 60 Sekunden-Timer an. Auf dem Raspi dauerten die Schaltzeiten gerne mal 1-2 Sekunden, je nach aktueller Auslastung. Auf dem aktuellen Brix geht das verzögerungsfrei - wenn der Schalter kurz aufblitzt geht sofort das Licht an.

cyablo · 19 Januar 2017, 16:25:30

@Tedious
FHEM Läuft auf einem Server mit Core i5 der 4ten Generation... an fehlender Leistung dürfte es nicht liegen

Manuell kann ich die einzielen Dosen im Webinterface ja auch super schnell schalten.

@rudolfkoenig
Da sind keine notifys oder doifs involviert, Intertechno Funksteckdosen senden auch keine Rückantwort. Ganz simples Structure aus ein paar Brennenstuhl Funksteckdosen, angesteuert über miniCUL mit aCUL Firmware, das ich manuell schalte. Bis auf die Funksteckdosen habe ich keine 433 MHz Komponenten, der Rest ist Homematic.

Tedious · 19 Januar 2017, 17:10:27

nu, denn ist das definitiv nicht das Problem

Ging mir nur durch den Kopf. Denn kommt wohl der CUL nicht hinterher

cyablo · 19 Januar 2017, 17:27:27

Naja, kommt er ja wohl, manuell geht es ja beliebig oft und nahezu instant

Ich kann im Webinterface wild rum klicken und Dosen ein und aus schalten, kein Problem. Sobald aber FHEM die Dosen in einem Struture oder auch einzeln per sunrise()/sunset() antriggert kommt es zu Problemen. Ich seh' schon ich muss hier Wireshark und mein Software-defined-Radio ansetzen