Probleme beim Schalten mehrerer HM-Aktoren

[oelidoc]

Hallo Martin,

wo finde ich denn die Vers. 4257?

Gruß

oelidoc

[LuckyDay]

http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/

[oelidoc]

Danke,

aber wie bekomme ich das in fhem rein?

Gruß

oelidoc

[martinp876]

heute mit update (immer am nächsten Tag)
ansonsten das file herunterladen, in dein system kopieren (du kannst all diese files finden in ./fhem/FHEM deines Installationspfads).
und schließlich ein shutdown restart

[oelidoc]

ok danke,

hatte es dummerweise mit update thirdparty versucht....

Gruß

oelidoc

[smirnov]

hallo,

mit Freude habe ich die Änderungen bzgl. homematic-resend gelesen, und dann gleich ausprobiert, da ich schon immer Probleme mit meinen Thermostaten + COC habe. Leider hat es keine Änderung gebracht. Wenn ich ein set desired-temp an mehrerer DN's schicke, kommt es mitunter vor, dass einer oder mehrere nicht gesetzt werden, und auf "MISSING ACK" gehen, ohne dass von FHME ein resend-Versuch unternommen wird.
Hier ein log-Auszug von so einem set desired-temp:

Code Auswählen Erweitern

2013.11.26 12:38:25.316 5: CUL/RAW: /A0FC986102288990000000AA0D81000582B
2013.11.26 12:38:25.318 5: COC: A0FC986102288990000000AA0D8100058 -52.5
2013.11.26 12:38:25.320 5: COC dispatch A0FC986102288990000000AA0D8100058::-52.5:COC
2013.11.26 12:38:25.326 4: RCV L:0F N:C9 F:86 CMD:10 SRC:HeizK_AZ_Erker DST:broadcast 0AA0D8100058 (INFO_TEMP SET:0xA0D8 ACT:0xA0D8 ERR:0x10 VALVE:0x10 MODE:0x10) (,WAKEMEUP,CFG,RPTEN)
2013.11.26 12:38:25.330 5: COC sending As092FA112F11234228899
2013.11.26 12:38:25.412 5: SW: As092FA112F11234228899
2013.11.26 12:38:25.428 4: SND L:09 N:2F F:A1 CMD:12 SRC:F11234 DST:HeizK_AZ_Erker  (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2013.11.26 12:38:33.009 5: CUL/RAW: /A0CBB86702066DD00000000DC2002
2013.11.26 12:38:33.012 5: COC: A0CBB86702066DD00000000DC20 -73
2013.11.26 12:38:33.014 5: COC dispatch A0CBB86702066DD00000000DC20::-73:COC
2013.11.26 12:38:33.020 4: RCV L:0C N:BB F:86 CMD:70 SRC:temp_Bad DST:broadcast 00DC20 (WeatherEvent TEMP:0x00DC HUM:0x20) (,WAKEMEUP,CFG,RPTEN)
2013.11.26 12:38:33.900 5: CUL/RAW: /A0FE6861
2013.11.26 12:38:33.904 5: CUL/RAW: A0FE6861/0236D7E0000000AA
2013.11.26 12:38:33.908 5: CUL/RAW: A0FE68610236D7E0000000AA/0D80E00585B
2013.11.26 12:38:33.910 5: COC: A0FE68610236D7E0000000AA0D80E0058 -28.5
2013.11.26 12:38:33.913 5: COC dispatch A0FE68610236D7E0000000AA0D80E0058::-28.5:COC
2013.11.26 12:38:33.918 4: RCV L:0F N:E6 F:86 CMD:10 SRC:HeizK_AZ_Fenster DST:broadcast 0AA0D80E0058 (INFO_TEMP SET:0xA0D8 ACT:0xA0D8 ERR:0x0E VALVE:0x0E MODE:0x0E) (,WAKEMEUP,CFG,RPTEN)
2013.11.26 12:38:33.922 5: COC sending As0930A112F11234236D7E
2013.11.26 12:38:34.005 5: SW: As0930A112F11234236D7E
2013.11.26 12:38:34.020 4: SND L:09 N:30 F:A1 CMD:12 SRC:F11234 DST:HeizK_AZ_Fenster  (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2013.11.26 12:38:34.430 5: CUL/RAW: /A0A308002236D7EF11234005A
2013.11.26 12:38:34.432 5: COC: A0A308002236D7EF1123400 -29
2013.11.26 12:38:34.435 5: COC dispatch A0A308002236D7EF1123400::-29:COC
2013.11.26 12:38:34.440 4: RCV L:0A N:30 F:80 CMD:02 SRC:HeizK_AZ_Fenster DST:F11234 00 (ACK) (,RPTEN)
2013.11.26 12:38:34.445 5: COC sending As0C31A011F11234236D7E86042B
2013.11.26 12:38:34.527 5: SW: As0C31A011F11234236D7E86042B
2013.11.26 12:38:34.543 4: SND L:0C N:31 F:A0 CMD:11 SRC:F11234 DST:HeizK_AZ_Fenster 86042B (,BIDI,RPTEN)
2013.11.26 12:38:34.694 5: CUL/RAW: /A0A31800
2013.11.26 12:38:34.698 5: CUL/RAW: A0A31800/2236D7EF11234005
2013.11.26 12:38:34.702 5: CUL/RAW: A0A318002236D7EF11234005/A
2013.11.26 12:38:34.704 5: COC: A0A318002236D7EF1123400 -29
2013.11.26 12:38:34.706 5: COC dispatch A0A318002236D7EF1123400::-29:COC
2013.11.26 12:38:34.711 4: RCV L:0A N:31 F:80 CMD:02 SRC:HeizK_AZ_Fenster DST:F11234 00 (ACK) (,RPTEN)


HeizK_AZ_Fenster wurde richtig gesetzt, HeizK_AZ_Erker ging auf MISSING ACK.
Mit scheint es so, als hätte der Empfang der Temperatur-Daten von temp_Bad das ACK des DN überdeckt. Eigentlich sollte da ja ein resend kommen, da die Übertragung nicht ordnungsgemäß stattgefunden hat.

Wie kann ich helfen, soll ich noch mehr (andere) logs produzieren?

vielen Dank für die harte Arbeit,
Tom

[martinp876]

in deinem Log gibt es keine Überdeckung - wenn du nichts gefiltert hast. Die Entscheidenden Zeilen sind

25.316  CUL/RAW: /A0FC9 8610 228899 000000 0AA0D8100058 2B
25.412  SW: As092F A112 F11234 228899
HeizK_AZ_Erker wacht auf, 100ms danach sendet FHEM das "habeDaten" signal. Es kommt keine Antwort.


so ist es ok:
33.908  CUL/RAW: A0FE6 8610 236D7E 000000 0AA0D80E0058 5B
34.005  SW: As0930 A112 F11234 236D7E
34.430  CUL/RAW: /A0A30 8002 236D7E F11234 00
34.527  SW: As0C31 A011 F11234 236D7E 86042B
34.702  CUL/RAW: A0A31 8002 236D7E F1123 400

HeizK_AZ_Fenster sendet temp-werte, 100ms danach sendet FHEM "habeDaten". Es kommt ein ACK und dann geht es los.
Beide Aktionen sind 8sec auseinander. 

Mögliche Fehler sind:
CUL verzögert senden oder Empfangen, so dass die 100ms nicht eingehalten werden. Bei HMLAN erhalte ich einen Zeitstempel AUS DEM IODEV. Der ist erheblich genauer - und ich versuche, diesen zur Berechnung zu verwenden. CUL sendet keinen solchen stempel, ich kann keine Aussage machen, wie genau gesendet wird.

der Pegel (RSSI) stimmt nicht.


Der generelle Ablauf ist in beiden Fällen korrekt, dennoch fehlt die Antwort.

Ein wiederholen ist bei wakeup sinnlos, zumindest in diesem "aufwach-zyklus". Das device schläft mit sicherheit, bevor FHEM wiederholen kann. Das wiederholen bezieht sich also auf devices mir "normal" oder burst mode.

Du kannst überlegen, die Devices auf burst umzustellen - könnte besser gehen, das Timing ist in diesem Fall "gedreht" - FHEM gibt vor.
Gruss Martin

[smirnov]

Also "resend" ist nicht so zu verstehen, dass FHEM das ganze beim nächsten wakeup wieder versucht?

[martinp876]

nein - jedenfalls jetzt noch nicht. Könnte man machen...

resend ist ein sofortiges noch-einmal senden (mit einer Wartezeit aus FHEM gesteuert von bis zu 4 sec).

bei einem wakeup device muss man mehr machen, wenn man ein resend will:
- auf das Device warten
- multi message kommandos komplett wiederholen (register schreiben)
- wiederhol- zähler anpassen.

es ist eine andere Steuerung - vielleicht passe ich die einmal an. Man muss dann aber entsprechend lange warten...

Aktuell wird bei wakeup nur vom HMLAN wiederholt, 3 mal schnell.

Gruss Martin

[Eniac]

Hallo zusammen,

sorry für die späte Antwort, aber bei funktioniert nun nach dem Update wieder alles!
Vielen Dank an Martin für die Korrektur!!

Für meine Jalousien bedeutet dies:
Es wird zwar nicht wie früher alle Aktoren gleichzeitig geschaltet, aber immerhin werden die Aktoren, die beim ersten Mal nicht reagiert haben, beim Resend aktiv.
Das ist für mich völlig in Ordnung, im Ergebnis gehen dann alle Aktoren (leicht zeitversetzt).

Viele Grüße und vielen Dank an das Forum und insbesondere an Martin.

Eniac

[martinp876]

@ tomballarino

das wiederholen sollte jetzt (version 4305) auch bei wakeup funktionieren.
msgRepeat wird jetzt strikt geparst, beim Eingeben:
"nur-config" devices wiederholen nicht (sehe ich keinen Sinn) man kann msgRepeat nur auf 1 setzen (einmal senden).
wakeup wiederholt - man muss aber auf das nächste aufwachen warten.

Hier noch einmal ein Hinweis/Tip, dass man hie und da den Zustand der Übertragung zu prüfen. HMInfo mit "protoEvents" und/oder die Zusammenfassung mittels "update" sollte man im Auge behalten. Besonders, wenn die Übertragung entsprechend verzögert werden kann

Bitte testen - es gibt eine Menge Kombinationen, die Übertragung anzustoßen

Gruss Martin

[smirnov]

@martin: ich habe das die Version 4305 gerade mit meinem COC getestet, funktioniert einwandfrei, ich habe es nicht geschafft, die Datenübertragung zu sabotieren (z.B. durch hohe Last am Raspberry, wo das Problem absolut reproduzierbar aufgetreten ist), das resnd funktioniert super!

Vielen Dank für deine Arbeit,

lg
Tom

[Eniac]

Hallo zusammen,

habe gestern ein Update gemacht und irgendwie scheint das Problem wieder zu existieren.
Ich habe mal in die Logs geschaut, von meiner Struktur mit den 3 Jalousieaktoren wird bei Schalten der Struktur auch nur einer ausgelöst (der Aktor, der als letztes in der Struktur steht).
Die anderen zwei Aktoren erhalten keinen Schaltbefehl, ist hier ggf. beim Parsen der Struktur ein Bug eingeschlichen?

Hat sonst noch jemand das Problem? Ist bei mir bei allen definierten Strukturen das gleiche Problem und auch nachvollziehbar.

Viele Grüße
Eniac77

[ph1959de]

@Eniac: wenn Dein Problem so ähnlich ist wie das hier: http://forum.fhem.de/index.php/topic,17351.0.html (für mich klingt das so), dann müsstest Du noch mal ein Update machen (siehe hier: http://forum.fhem.de/index.php/topic,17351.msg113657.html#msg113657).

Gruß, Peter

[Eniac]

Hallo zusammen,

nach dem heutigen Update funktioniert es wieder wie gewünscht.

Viele Grüße
Eniac