CUL änderungen für HM

[martinp876]

Hallo Rudi,

ich denke CUL hier ist der richtige Platz für CUL Angelegenheiten?

bezogen auf deinen Einwand des aktiven Wartens habe ich hier einen Vorschlag mit passivem Warten.
Funktioniert so weit bei mir.
Neben dem ändern des Wartens hätte ich noch Änderungen bezuglich der Logs (auch im Anhang)
- für HM werden die message header mit space sinnvoll getrennt. Macht das Lesen erheblich einfacher.
- verbose 4 wird genutzt um "rohmessages" zu loggen. Aktuell geht das mit verbose 5 - da kommt aber jede message 2 mal beim senden und 3mal beim empfangen. Wer das braucht kann weiterhin verbose 5 verwenden.
- der den Vorspann der logs habe ich geändert. "SW:" ist nicht hinreichend (kein $name dabei). Angelehnt an HMLAN halte ich "CUL_Send:  $name" und "CUL_Parse: $name" für sinnvoll. Die zwei space bei Send sind Absicht um die Länge mit Parse gleich zu ziehen.

Ich denke, es ist klar, worauf ich beim Loggen hinaus will. Vorschlag im Anhang.
Lass mich wissen was du davon einbauen wirst.

Gruss Martin

ps noch ein Punkt: Bei der CUL ist es verboten, den rfMode auf  HomeMatic zu setzen, bevor nicht die Version der CUL gelesen ist. Den Grund verstehe ich schon. Es ist aber dennoch lässtig wenn man die CUL einmal herauszieht immer alles neu setzen zu müssen. Mir würde eine andere Handhabung besser gefallen - dass man alle Parameter wie immer voreinstellen kann. sollte dann die CUL den Attribute nicht genügen muss es einen Alarm (reading, evtl Status 'mismtach') geben und die CUL geht nicht in Betrieb.

[martinp876]

Hallo Rudi,

neben der oben erwähnten Änderung (ich teste noch weiter...) hätte ich noch ein paar weitere Veränderungen vorzuschlagen.
- es gibt Probleme (manchmal) dass die IOs sich nicht mehr melden. Der Grund ist mir vollig unklar - muss noch forschen. In jedem Fall halte ich eine Alive-Überwachung wie sie bei HMLAN/IO genutzt wird für sinnvoll (eigentlich unbedingt notwendig).
Die Konsequenzen/Gefahren sind mir klar - bei HMLAN hatten wir gelegentlich Probleme mit schlechter Latenz des Systems. Dennoch können wir uns eigentlich nicht leisten die Kommunikation zum IO device zu verlieren und keiner merkt es.
Aktuell konnte was Problem mit einem Restart von FHEM behoben werden. Die CUL-FW kenne ich nicht so weit, es wäre geboten einen CUL/CUN restart provozieren zu können

- ein Zeitstempel der messages aus der CUL/CUN (wieder wie aus HM-IOs) wäre angebracht. Ich habe mit Messungen begonnen und gesehen, dass eine CUNO 200ms nach einem HMLAN die message empfangen hat. Die Gründe dafür können vielfältig sein und ich werden weiter suchen. Auch HMLAN kann einmal langsam sein. Aber bei HMLAN bekomme ich einen Zeitstempel, wann die Mesage aus der Luft gefangen wurde - und das ist der Maßstab, timings zu errechnen. Das host-system sowie die Übertragung (USB oder viel schlimmer Ethernet) erzeigen Delays, die nicht ausgeglichen werden können.
Nur mit einem Zeitstempel aus dem IO device wird sich weitgehend stabiles ein timing erstellen lassen
Dies Bedarf natürlich einer Änderung der FW - klar. Soweit bin ich aber noch nicht - falls es hier einen freiwilligen gibt...

Gruss Martin

[rudolfkoenig]

Hallo Martin,

ich habe deine Aenderungswuensche aus den Anhang komplett uebernommen. Ich habe lange gehadert mit der Aenderung der Logging, da mAn sowas nicht ins CUL Module gehoert, aber zum Schluss habe ich beschlossen es trotzdem zu nehmen, nach dem Motto: was solls, wir sind nicht in der Schule.

Bei der CUL ist es verboten, den rfMode auf  HomeMatic zu setzen, bevor nicht die Version der CUL gelesen ist.

Habs fuer nicht angeschlossene Geraete erlaubt das Attribut zu setzen. Zum debuggen ohne CUL konnte man auch bisher als Geraet "none" angeben, damit wird dummy automatisch gesetzt, und das Setzen des Attributes funktionierte auch bisher.
Gruss,
  Rudi

[martinp876]

Hallo Rudi,

danke,

Ich sehe deinen Punkt. Dennoch kann ich nicht zustimmen. 00_CUL ist bei weitem nicht Application-independant. Da wird jede Menge unterschieden.
Klar könnte ich die Aufbereitung 'postum' machen - addiert sich aber zu einiger Arbeit für mich. Debuggen für den User sollte auf CUL_HM level und mit dessen outputs möglich sein - für die Entwicklung der CUL_xxx level SW muss man zwingend an IO-device loggen. Ich würde für alle Familien den Header 'splitten' - wegen der Lesbarkeit. Aber die Brauchen es evtl nicht..?

Eine bessere Struktur hätten wir sicher, wenn es einen sauberen, einstell-und kontrollierbaren "family-layer" geben würde. Den habe ich schon einige Male vermisst - und ein paar funktionen in HMInfo realisiert. Die IO-devices sollten dann ihr "family-dependant"-provisiong aus diesem layer beziehen - das wäre schulmässig und deutlich sauberer.
CUL_Parse ist ein schönes Beispiel, dass 00_CUL nicht generisch ist.

Noch einmal danke für HM
Gruss Martin

[martinp876]

Hallo Rudi,

ich teste gerade mit mehrere verschiedenen IO devices. Es gibt Probleme, das notwendige timing zu errechnen. CUL (wenn nur eine, und keine race-condition) ist schnell und liefert einen zuverlässigen Zeitstempel. HMLAN liefert immer einen zuverlässigen Zeitstempel, da IM HMLAN erzeugt. Eine CUNO kann dies nicht.

Da alle IO devices ggf die gleich  message an CUL_HM liefern beantwortet CUL die des ersten melders (CUL bei mir). Die Antwort wird von HMLAN gesendet. Da 00_HMLAN aber noch nicht empfangen hat kann diese das delay nicht intern errechnen. Also werde ich das Delay nicht in HMLAN device oder CUL device ablegen sondern im CUL_HM device (vom IO device abgelegt).

Nur eine CUNO darf sich nicht einmischen. Deren timing ist aktuell viel zu langsam.

als 00_CUL maintainer - wie willst du das handhaben
1) CUNO für HM sperren bis das timing korrigiert ist. Timing der IO devices 'austauschen' über CUL_HM
2) CUNO zulassen und hoffen, der User nutzt es nicht.  Timing der IO devices 'austauschen' über CUL_HM
3) alles lassen wie es ist => CUL und HMLAN dürfen nicht gleichzeitig HM bedienen - User muss dies selbst beachten
4) dedizierte IO devices einführen: nicht nur senden, auch empfangen nur über das IO device. Timing-austausch ist nicht mehr notwendig.

Generell ist die CUL deutlich besser als eine CUNO, aber auch hier ist ein HM-like timestamp hilfreich,  da sonst bei Last nichts zu retten ist.

den Timng-austausch habe ich am Laufen, löst mein Problem, wenn CUL und HMLAN operationell sind. ggf schicke ich dir den Code für 00_CUL.

Gruß Martin

[rudolfkoenig]

Das CUNO ist mAn aus mehreren Gruenden problematisch:
- ich hatte mit dem Ethernet-Chip-Initialisierung auf dem CUN sehr viele Probleme, ich bezweifle, dass culfw den Rest (Senden/Empfangen) optimal bedient.
- das verwendete TCP-Stack ist extrem abgespeckt damit es in dem Speicher passt, man muesste vermutlich etwas experimentieren, um die delays wegzukriegen. Delays waren fuer mich nie ein Thema, allerdings habe ich es fuer mich auch nur bis zum Proof-of-Concept gebaut, und nie optimiert.
- es gibt niemanden, der den Firmware fuer das CUNO als Verantwortlicher pflegt, und solche Probleme loest.

Ich wuerde aber dafuer keine Workarounds auf FHEM-Ebene einbauen, eher dokumentieren, dass ein CUNO fuer HM im Moment nicht taugt, und man sollte auf das HMLAN ausweichen.

Bzgl. CUL+HMLAN: ich haette kein Problem zu dokumentieren, dass man sie fuer HM nicht mischen darf, andererseits verstehe das Problem nicht: wenn HMLAN das IODevice ist, dann beantwortet es die Anfragen selber. Wenn nicht, dann will man auch nicht darueber senden.

[martinp876]

Das mit der CUNO ist ok - dokumentation sollte reichen solange sie nicht 'beschleunigt' wird.

Zum Timing:
bei HM sind Zeiten einzuhalten zwischen senden und empfangen eines HM-Devices (nicht IO!)
Aktuell verarbeitet CUL_HM die messages aller IO-devices, die etwas melden, egal wie IODev steht.
Im Test ist die CUL nicht das IO-device, aber immer schneller als HMLAN (wegen ethernet?)

Antworten sendet immer das IO-device (also HMLAN in diesem Fall).
HMLAN sendet also die Antwort auf die Message, die CUL empfangen hat. HMLAN hat aber (noch) nicht den zeitstempel der incomming-message, die beantwortet werden soll.

Lösungen gibt es mehrere:
1) incomming-messages werden verworfen, wenn sie nicht vom IODev kommen
2) die Zeitstempel werden nicht im IODev hinterlegt sondern im empfangenden device.

zu 1) strikter Ansatz, saubere Zuordnung. Wenn HMLAN assigned ist wird auch dessen bessere timing-kalkulation genutzt. Bei USB hat man die von Haus aus höhere Geschwindigkeit - aber man hat keine Mischung mehr.
Darstellen der RSSI werte wäre immer noch gut - aber den kompletten Satz an standart-infos sollte man sich verkneifen - es würde suggerieren, dass die messages verarbeitet würden. Details würde ich mir noch ansehen.
2) läuft gerade im meinem Test erfolgreich (so lange ich die CUNO abschalte).
2a) das IO device greift direkt auf die Daten im "empfänger" zu
2b) In einer 'ordentlichen' Architektur sollten natürlich die Zeitstempel von IO device über die Message an die Applikation (hier CUL_HM) übergeben werden und beim Senden entsprechend ein gewünschter Sendezeitpunkt. Aber wenn ich es richtig sehe (korrigiere mich...) wird in FHEM eher direkt zugegriffen.

Und wichtig: Eine Lösung brauch ich nicht nur bei Mischbetrieb, das tritt immer bei Nutztung mehrer IO-devices auf, auch der gleichen Bauart

Was ich nicht abschätzen kann ist, ob andere devices auch ein entsprechendes timing brauchen und wie sie dies machen - im code habe ich nichts bemerkt (es müsste ja im IO device sichtbar sein, alles andere ist schon viel zu verwässert).

Wenn von dir keine Einwände/Ideen kommen werden ich 2a realisieren, da 2b dir wahrscheinlich zuviel Aufwand ist.

Zu CUL/CUNO: unabhängig von Verbesserungen am CUNO ethernet handling/IP-stack - ein Zeitstempel, wann eine message aus der Luft gefischt wurde ist immer sinnvoll. Verzögerungen können an vielen Stellen auftreten - und nur ein Zeitstempel ermöglicht ein korrektes sichers timing. Bei HMLAN funktioniert meine rückrechnung problemlos und präzise

Gruss Martin

[martinp876]

Hallo Rudi,

2 Änderungen für 00_CUL

1) multi-IOdevice
nachdem du keine Präferenz hast hab ich 2a) realisiert. Ist in der Version im Anhang dabei. in 00_HMLAN läuft es auch schon - ist also kompatible. timing mit multi-io devices würde mir somit passen

2) timing
wie Anfangs befürchtet ist das timing von FHEM insbesondere mit internal-timer einfach zu instabil. Du hast mir zwar schon mehrfach mitgeteilt, dass du keine timing-Probleme kennst, aber HM braucht definitiv genaueres. Das passive warten funktioniert wie eingebaut. Es passiert aber, was passieren musste: Tasks des User verlängern den Delay von 85ms auf 210ms. Dann ist aber schon alles vorbei. Je mehr Funktionen der User hat desto schlechter wird es. Wenn der User wenig tasks hat ist aktives Warten auch ok (select blockiert ja nur 'unseren' Prozess)
In der Version im Anhang habe ich es erst einmal einstellbar gemacht. Mit dem Attribut "waitPassiv" kann man einstellen, dass passiv gewartet wird, der default ist auf aktivem Warten.
=>? teile mir bitte mit, wie du es haben willst - optional oder aktives warten immer. Die Einstellbarkeit wird wohl eher theoretisch sein, da man es kaum bemerken wird und die meisten es eh nicht abschätzen können.

mittelfristig kann man über passives Warten nachdenken - da muss FHEM aber deutlich an prioritäten, preemption, max task-duration und hintergrundprocessing für fronten-tasks arbeiten.

3) off-topic - apptime
die Funktion wird (nicht nur in diesem Zusammenhang) doch immer wieder einmal genutzt, wenn user wissen wollen, wo ihre Applikation die Zeit verbummelt. Ich denke, ich sollte es einchecken - kannst du mir einen Platz anraten? Contribute evtl? Damit ich das Filesystem nicht zumülle

Gruss Martin

[rudolfkoenig]

Hallo Martin,

2a) war meine Praeferenz, da ich hoffte, dass ich in 00_CUL.pm nichts aendern muss. An dem Diff stoert mich, dass damit 00_CUL.pm in die Datenstrukturen von 10_CUL_HM reingreift, habe aber keine einfache Loesung: ich werde die Aenderungen annehmen.

Timing: das direkte Warten in CUL_XmitDlyHM loest nur das Problem der notifies, die sich zwischen dem write-Versuch und dem write stattfinden. Alles was vor dem write-Versuch kommt, bleibt bestehen. Die richtige Loesung waere sowas entweder in einem separaten Thread zu machen, oder direkt in Firmware. Das Attribut ist nur Augenwischerei (insb. das default aus ist), und werde es  nicht einbauen.

Falls Du damit einverstanden bist, dann werde ich die Aenderungen wie beschrieben hinzufuegen.

[martinp876]

Hallo Rudi,

hm - muss wohl an meinem Ausdruck arbeiten. zu 2a) hatte ich genau dies beschrieben. Absolut korrekt, in einem sauberen System würde ich dies nicht zulassen. Der Weg wäre 2b).
Dass etwas zu ändern ist - in jeden Fall - war nicht klar?

Timing: das direkte Warten in CUL_XmitDlyHM loest nur das Problem der notifies, die sich zwischen dem write-Versuch und dem write stattfinden. Alles was vor dem write-Versuch kommt, bleibt bestehen.

Teilweise: Es löst nicht alles, aber erheblich mehr als du sagt. Jede Menge ACK werden direkt nach dem Parsen in CUL_HM getriggert. da kommt quasi nichts dazwischen. Das hat feste Abhängigkeiten.
Die ACKs in FW ist sicher gut - wirklich gutes timing ist immer besser in FW, da FHEM kein Echtzeit - insbesondere in dieser Auflösung - kann.

Beim Attribut sind wir auch einer Meinung.
Demnach bin ich einverstanden den Code "passiv warten" stillzulegen oder zu eliminieren.

Mittelfristig kann man an einer anderen Lösung arbeiten
Ein extra threat ist prima. Aber nicht jedes mal forken - das braucht allein schon 30ms bei einem kleinen System, da können wir gleich aktiv warten (abgesehen von der Zeit, die das OS im geforkten task verbraucht, die kommt noch oben drauf.
Gibt es in FHEM schon Beispiele für echte threats (die den Namen auch wert sind) - incl sauberer Überwachung und inter-threat kommunikation? Also einmal forken und dann zusammenarbeiten mit den mein threat?

Gruss Martin

[rudolfkoenig]

habs eingecheckt (bis auf das Attribut), bitte pruefen.
Eine gute Loesung fuer einen separaten Thread bzw. Prozess gibt es noch nicht.
BlockingCall ist fuer sowas nicht gedacht.

[martinp876]

Hallo Rudi,

sieht gut aus für mich.

Anmerkungen:
die Queue braucht es für HM so lange nicht, bis wir 'passiv' warten - schadet aber auch nicht wirklich. Auch der Timer sollte nicht notwendig sein, da in der Q eigentlich nichts drin sein kann.
aus der CUL ein HM-io zu machen - mit auto-ack ist reizvoll... löst viele, aber nicht alle Probleme. Im wakeup mode muss man genauso schnell sein - das kann aber die FW nicht, das ist dann eine CCU.

plannst du, threats zu implementieren? Ich hatte einmal angefangen - hatte aber mit der Socket kommunikation Probleme beim Löschen des child threats - das hat der mainthreat nicht sauber erkannt. Werde evtl noch einmal probieren.
Blocking funktioniert nur in einigen Fällen und ist recht 'teuer' performancemässig.

Bleibt noch die Frage nach dem Lagerort für apptime.pm.  Gibt es eine struktur für Files an der ich mich orientieren kann?

Danke, Gruss Martin

[rudolfkoenig]

Code Auswählen Erweitern

plannst du, threats zu implementieren?

Threads nicht (dazu muesste jeder auf den Thread-Faehigen perl wechseln, und das ist illusorisch), es war mal aber die Rede von einem BlockingCall aehnlichen Funktion fuer Server, der mit fork realisiert ist, aber nur einmal startet und am Leben bleibt. Ist aber nicht hoch auf meiner Prio-Liste, da ich zunaechst mal eigene Wuensche/Plaene realisieren moechte.

Bleibt noch die Frage nach dem Lagerort für apptime.pm.

Contrib ist nicht optimal, da es per update nicht ausgeliefert wird.
Kannst du mir zeigen, wo ich es finde, die Forum-Suche und Google haben es nicht gefunden.

[martinp876]

ein bisschen versteckt
http://forum.fhem.de/index.php?action=dlattach;topic=16103.0;attach=9055

[rudolfkoenig]

ein bisschen versteckt

Stimmt. Kannst Du mir noch die dazugehoerige Diskussion nennen?

Die Datei gehoert doch als 98_apptime.pm nach fhem/FHEM _NACHDEM_ sie dokumentiert ist.
Stoert keinen, wenn man apptime nicht aufruft, und wenn man es braucht, muss man nur apptime aufrufen.
In der Doku sollte erwaehnt werden, dass nach dem Gebrauch ein "shutdown restart" von FHEM empfohlen wird.

Wenn Du kein Bock auf Doku hast, dann nach contrib.