[jetzt im svn] [CUL_HM] patches Oktober 2021

[Beta-User]

Hallo zusammen,
hallo Martin,

nachdem die Tage dann auch noch das Zusammenspiel zwischen CUL_HM und HMinfo beim FHEM-Start ein Thema war, erscheint es mir sinnvoll, zum ganzen Mal einen neuen thread anzufangen...

Hier jetzt also die "gesammelten Werke", die die diversen Dinge aus neues cul_hm schreibt ein paar warnings ... enthält, eine bzgl. "id" und der wechselseitigen Referenzierungen überarbeitete commandref enthält und über den Code verteilt noch einige Modifikationen enthält, die zum einen zum Ziel haben, CUL_HM möglichst früh initialisiert zu haben (also insbesondere auch, bevor irgendwelche "at" anlaufen, die ggf. dann schon Funktionalität von virtuellen entities brauchen, die noch gar nicht wissen, was sie damit anfangen sollen.

Das ganze ist noch nicht 100% fertig, insbesondere scheint #417 nicht das zu tun, was erhofft wird, aber m.E. müßte die CUL_HM-Initialisierung dann einigermaßen konsistent sein, wenn wir das auch noch in den Griff bekommen.

Leider konnte ich bisher (zu den ganz neuen Teilen, die den Startablauf betreffen) nicht wesentlich mehr machen als das kurz anzutesten, aber das sieht zumindest in meinem Hauptsystem ok aus, und mir fehlt heute auch die Zeit, das nochmal intensiver anzusehen und zu verlinken, wo eigentlich was herkommt, daher v.a. auch in Richtung frank hier erst mal sowas wie eine gemeinsame Ausgangsbasis für die weiteren Analysen.

Wer testen will: Unbedingt alle beiden Module tauschen!

Grüße,

Beta-User

EDIT: Anhänge gelöscht, da gelöst/im svn.

[KlaGho]

Hallo Beta-User,
ich habe deine Versionen aktiviert.
Nach einem Restart liefert HMinfo auf ConfigCheck templist mismatches für alle Thermostate.
Nach manuellem getConfig sind die templists ok, nur peerNeedsBurst für die Fenstersensoren werden noch "bemängelt".

Danke für deine Bemühungen und Gruß
klagho

configCheck done:

peerNeedsBurst cannot be determined
    AZ_Fenster:   AZ_R_WindowRec
    BZ_Fenster:   BZ_R_WindowRec
    GZ_Fenster:   GZ_R_WindowRec
    KU_Fenster:   KU_R_WindowRec
    SZ_Fenster:   SZ_R_WindowRec
    WC_Fenster:   WC_R_WindowRec
    WZ_Fenster:   WZ_R_WindowRec
    WZ_Fenster:   WZ_T_WindowRec

templist mismatch
    AZ_R_Clima: failed Entries:
     AZ_R_Clima: R_0_tempListSat mismatch 06:30 15.0 09:00 21.0 17:00 21.0 22:00 21.0 24:00 15.0 ne 07:00 09.5 09:00 10.0 17:00 10.0 22:00 10.0 24:00 09.5 ##
     AZ_R_Clima: R_1_tempListSun mismatch 06:30 15.0 09:00 21.0 17:00 21.0 22:00 21.0 24:00 15.0 ne 07:00 09.5 09:00 10.0 17:00 10.0 22:00 10.0 24:00 09.5 ##
     AZ_R_Clima: R_2_tempListMon mismatch 06:30 15.0 09:00 21.0 17:00 21.0 22:00 21.0 24:00 15.0 ne 07:00 09.5 09:00 10.0 17:00 10.0 22:00 10.0 24:00 09.5 ##
     AZ_R_Clima: R_3_tempListTue mismatch 06:30 15.0 09:00 21.0 17:00 21.0 22:00 21.0 24:00 15.0 ne 07:00 09.5 09:00 10.0 17:00 10.0 22:00 10.0 24:00 09.5 ##
     AZ_R_Clima: R_4_tempListWed mismatch 06:30 15.0 09:00 21.0 17:00 21.0 22:00 21.0 24:00 15.0 ne 07:00 09.5 09:00 10.0 17:00 10.0 22:00 10.0 24:00 09.5 ##
     AZ_R_Clima: R_5_tempListThu mismatch 06:30 15.0 09:00 21.0 17:00 21.0 22:00 21.0 24:00 15.0 ne 07:00 09.5 09:00 10.0 17:00 10.0 22:00 10.0 24:00 09.5 ##
     AZ_R_Clima: R_6_tempListFri mismatch 06:30 15.0 09:00 21.0 17:00 21.0 22:00 21.0 24:00 15.0 ne 07:00 09.5 09:00 10.0 17:00 10.0 22:00 10.0 24:00 09.5 ##
...

[Violinux]

Hallo Beta-User,
verfolge das Thema auch seit Beginn.
Auch ich habe die beiden Patches eingespielt.
Alle HM´s incl. Thermostate laufen bisher einwandfrei ohne Fehler.
Hab noch eine Frage, warum erscheinen die Rauchmelder noch im LOGfile?
Es sind die alten HM-SEC-SD .
Logeintrag: CUL_HM set RM_xxx statusRequest noArg
habe ich im Forum etwas überlesen oder ist das so gewollt?
Beste Grüße und Danke für die tolle Arbeit.

[frank]

hallo KlaGho,
welche versionen hattest du vorher?

peerneedsburst passt zu den "fehlenden registern", da sie nur in gepeerten sensoren existieren. https://forum.fhem.de/index.php/topic,123139.0.html
als workaround hilft dann vermutluch ein getconfig im sensor.

die templist meldungen passen zu https://forum.fhem.de/index.php/topic,123152.0.html.
da kommen die automatischen configcheck immer noch zu früh.


@Violinux
je nach einstellung von attr autoreadreg ist der automatische statusrequest von dir so bestellt, also normal.

[Violinux]

Hallo Frank,
autoReadReg auf 0 und nun sind diese Meldungen weg.Aber wieso ist das nur bei den HM-SEC-SD Rauchmeldern ?
Alle anderen ca 40 Geräten haben auch "autoReadReg 4_reqStatus"
oder haben die RM einen besonderen internen Status ?

[Beta-User]

Kurz: Einen Denkfehler glaube ich entdeckt zu haben...

Selbstredend _darf_ CUL_HM Funktionen aus HMinfo auch sehr früh aufrufen, wenn sie verfügbar sind; ich hatte nur aus der völlig überflüssigen Masse den Schluss gezogen, dass das so nicht gedacht sein kann und das komplett in Timer verlagert.

Falls mir jemand folgen kann: M.E. sollte man das jetzt so umbauen, dass die initialen Aufrufe für HMinfo-Funktionen nur für den Hauptkanal erfolgen, und zwar aus der INITIALIZED-Eventloop heraus. Will sagen: für alle, die nicht 6-stellige ID's haben: Timerbasiert, wenn innerhalb der ersten 30 Sekunden nach Start, für die Hauptkanäle gleich den unmittelbaren Aufruf; Bausteine sind alle da...

PS: Danke für das nette feedback!

[KlaGho]

Hallo Beta-User,
ich habe nochmal getestet:
1. getConfig für alle Fenstersensoren mit anschließendem manuellen ButtonPress vor Ort: Fehler "Peer needs burst" behoben
2. getConfig für alle Termostate
3. check via HMinfo getConfig: ok

4. Nach restart FHEM: wieder Fehler mit "Peer needs burst" UND "tempList mismatch"

hier meine aktuelle Konfiguratio :
aktive Versionen:
# CUL HomeMatic handler
# $Id: 10_CUL_HM.pm 24961 2021-09-30 + various Beta-User-Patches + sort II + new initialisation + allow more set commands in startup phase$
# $Id: 98_HMinfo.pm 24960 2021-09-12 + cref + other Beta-User $

und die Vorgänger Versionen:
# CUL HomeMatic handler
# $Id: 10_CUL_HM.pm 24961 2021-09-12 06:46:07Z martinp876 $
# $Id: 98_HMinfo.pm 24960 2021-09-12 06:43:51Z martinp876 $

Gruß klagho

PS: ich habe auch deinen letzten Eintrag gelesen und warte auf den Umbau

[frank]

Hallo Frank,
autoReadReg auf 0 und nun sind diese Meldungen weg.Aber wieso ist das nur bei den HM-SEC-SD Rauchmeldern ?
Alle anderen ca 40 Geräten haben auch "autoReadReg 4_reqStatus"
oder haben die RM einen besonderen internen Status ?

eigentlich müsste ggf für jede entity, die den cmd statusrequest bereitstellt, dieser auch im log zu sehen sein.
je nach credits (40%) könnten weitere cmds auch erst sehr viel später erscheinen.

[Beta-User]

M.E. sollte man das jetzt so umbauen, dass die initialen Aufrufe für HMinfo-Funktionen nur für den Hauptkanal erfolgen, [...]

Das ist vertrackter als vermutet, da der Aufruf leider grade immer mit dem Hauptkanal erfolgt und die Unterscheidung anhand der Länge an diesem Ort also gar nichts bringt...

[@tango]

Hi,
ich habe beide Module übernommen und mir angeschaut wie sich die AES Kommunikation der HMUARTs jetzt verhält.
Das hatte nach update Mitte August zu Problemen geführt.
Die beiden aktuellen patches sind auf den ersten Blick bzgl. AES nun OK.
Allerdings ist zusätzlich seit damals das HMLAN rausgeflogen, das sich plötzlich alle 5 Minuten disconnectete.
Ersetzt wurde es duch ein 2. HMUART.
In Summe scheint alles aktuell zu funktionieren.

[Beta-User]

Danke für die Rückmeldung.

Kannst du bitte die "alte Anleitung" löschen, ich werde ggf. aktualisierte Stände hier dann im ersten Post anhängen (oder notfalls unter contrib einchecken?) und muss sonst aufpassen, dass auf github alles 100% paßt (was nicht zu meiner "Verwendungsart" des git-Repos paßt... )
Sonst kann es vorkommen, dass man versehentlich eine ungetestete Zwischenversion erwischt ...

Generell würde ich mir wünschen, dass martinp876 sich mal meldet, denn ehrlich gesagt fühle ich mich mit der aktuellen Situation nicht sehr wohl - ich wollte eigentlich nur für ein paar recht einfach zu fixende Problemchen Vorarbeit leisten. so tief in den Code einzutauchen, war nie der Plan , zumal ich eigentlich bisher auch eher einfacher Anwender der Module war und mir viele Stichworte, die hier aufgetaucht sind eher wenig sagen . Meine Methode bisher war eher formal und hatte wenig mit den diversen "Sonderlocken" zu tun (was ja gelegentlich für Irritationen gesorgt hatte, wenn ich die Zwischentöne richtig gedeutet habe ).
Da mir jetzt aber einige "Merkwürdigkeiten" aufgefallen sind, wäre die Frage, ob es nicht sinnvoll wäre, an der einen oder anderen Stelle ein refactoring zu diskutieren, v.a. um aus dem Startprozess die letzten Unklarheiten rauszubekommen. Dazu bräuchte es aber vorab ein OK von Martins Seite, und es müßten ein paar Leute bereit sein, weiter mitzutesten. An letztere gerichtet gleich eine Warnung: Das dürfte dann interimsweise leider auch hin und wieder mit deutlichen Rückschlägen verbunden sein, "first time right"-Fixes traue ich mir nicht zu, denn:

Nach meinem jetzigen Kenntnisstand scheint es mir so, dass man relativ viele "Kleinigkeiten" anfassen muss, um das Zusammenspiel zwischen HMinfo und CUL_HM im zeitlichen Ablauf noch zu optimieren und/oder ggf. neue subType-Attribut-Werte (fest) vorgeben müßte, damit man nicht nach dem eigentlichen CUL_HM-Start noch "nachbessern" muss. Ohne das _glaube_ ich im Moment z.B. nicht daran, dass wir die "automatischen Starts" für den virtuellen TC in den Griff bekommen (kann aber auch sein, dass es für Martin (oder noansi) einfach ist, weil er den richtigen Knopf kennt, der vorab noch gedrückt werden müßte).

Ich kann im Moment auch mit dem bisher erreichten Provisorium leben und denke, es wäre sinnvoll, den (möglicherweise durchaus noch verbesserungswürdigen) Zwischenstand erst mal ins svn zu schieben (weil er jedenfalls nach heutigem Kenntnisstand jedenfalls weniger Probleme  generiert wie die aktuelle svn-Fassung).

In jedem Fall wäre ich euch jeweils für Rückmeldungen sehr verbunden, wie die Stimmungslage ist...

[Beta-User]

So. Nachdem während des Schreibens von meinem Beitrag hier dann gleich wieder was neues aufgetaucht ist ("Unknown argument displayWM") habe ich mir doch den Startvorgang nochmal angesehen. Auch wenn weiter manches unklar ist, scheint es zumindest bei mir keine zusätzlichen Probleme verursacht zu haben, von daher hänge ich die hier auch mal an - wer mag, kann ja testen...
Patch dazu ist im ersten Post.

[KlaGho]

Hallo Beta-User,
nun habe ich auch deine neuesten Version aktiviert. Alles funktioniert.

Insbesondere bemerken die Thermostate Fenster offen/geschlossen und schalten entsprechend, obwohl die Warnungen "peerNeedsBurst nach jedem Restart wieder auftauchen (manuelles getconfig + ButtonPress vor Ort lässt sie bis zum Restart verschwinden

Die virtuellen Temperatursensoren funktionieren auch.

Der Effekt mit dem fehlerhaften Temperaturprofilen hatte vielleicht mit den Attributen
autoLoadArchive on
autoArchive on
autoread on

zu tun: ich benutze zum Saisonwechsel Sommer/Winter ein notify mit dem Kommando "set hminfo templistG restore"
Nach dem Löschen der og. Attribute hat die Umstellung wieder funktioniert und überlebt auch einen Restart.

Ich kann damit sehr gut leben

Vielen Dank und Gruß
klagho

[Beta-User]

Danke erst mal für die Rückmeldung.

Ich habe das mit den virtuellen Raum-Sensoren so gelöst, dass es je ein (virtuelles) "Hauptdevice" gibt, das dann als Channel-Devices je einen Temp-Sensor und einen Fake-Kontakt hat. Komischerweise habe ich die "peerNeedsBurst"-Warnung nicht im Log (kann aber sein, dass die auf verbose 2 stehen, muss wohl einen zum Testen mal umstellen...)

Wenn jedesmal neuerliche getConfig erforderlich sind, stimmt noch was mit der Initialisierung nicht. Gerade dieses Problem mit dem Finden der passenden Kommandos für die virtuellen Kanäle beschäftigt mich ja schon länger, aber bisher habe ich leider noch keine bessere Stelle bzw. keinen besseren Kommand gefunden, um zu reparieren, was vorher scheinbar nicht geklappt hat - wie schon geschrieben sind die wechselseitigen Abhängigkeiten teils rätselhaft und ich bin eigentlich schon sehr erleichtert, dass es jetzt wenigstens "definiert" abläuft.

Bin mal gespannt, wann sich einer der "Wissenden" meldet - irgendwie werde ich den Verdacht nicht los, dass des Rätsels abschließende Lösung einfacher ist als ich das bisher vermutet hätte?

Falls jemand Ideen hat: her damit! Es scheint ja doch einige zu geben, die grade fleißig mittesten, vielleicht bekommen wir das auch vollends gelöst .

[@tango]

Hi,

aus meiner Sicht tritt mein ursprüngliche AES Problem mit den neuen Patches nicht auf.

Allerdings sehe ich jetzt ein HM-SWI-3-FM auf aesCommToDev fail.

Muss aber nicht an diesem Patch liegen. Der hat lange nicht ausgelöst.
Muss ich weiter analysieren.