OWTHERM blockiert FHEM

[dan1180]

Zu Erstens habe ich keine Ahnung. Mein DS9097 wurde nicht erkannt und musste deshalb FHEM vorgestellt werden (http://forum.fhem.de/index.php/topic,17684.msg117110.html#msg117110). Kann schon da die Ursache liegen, dass die Zeiten übermäßig lange sind und deshalb HM aussteigt?

Zweitens habe ich so nie behauptet! Bitte nicht in allem einen Angriff auf OWX sehen. Nichts läge mir ferner als mit meinem Kenntnisstand Module zu kritisieren. Verursacher war wohl ein Fehler bei der manuellen Installation der Asynchron Module oder die Tatsache, wie det geschrieben hat, dass die im Moment nicht funktionieren. Whatever...nachdem ich meinen alten FHEM Ordner wieder drübergespielt habe hab ich wieder die alten Verzögerungen < 2Min.

An Drittens bin ich dran.

[det.]

Hallo dan1180,
Ich habe von Homematic nur diese neuen Heizkörper Stellventile und Fensterkontakte im Einsatz. Hier im Forum hat mal ein kluger Mensch diesen Link gepostet [size=78%]https://blog.chanoa.de/category/heimautomatisierung/fhem-performance[/size]
Setz mal so viel wie möglich von den Vorschlägen dort um, bei mir hat das prima geholfen.

[Prof. Dr. Peter Henning]

@det: Guter Beitrag - den sollte man mal ins Wiki übernehmen.

@dan1180:

Nochmal zu dem ersten Punkt: Wenn man selbst kein Verständnis von der Sache hat, sollte man sich nicht auf un-autorisierte Änderungen des Programmcodes einlassen, die von Autoren stammen, die ebenfalls nach eigenem Bekunden nicht programmieren können.

Nochmal zum zweiten Punkt: Mitnichten sehe ich darin einen "Angriff auf OWX", sondern ich habe ganz sachlich geschrieben, dass die Verzögerungen in diesem Falle nicht von OWX stammen können.

Allerdings sehe ich auch keinerlei Veranlassung, mich mit den Problemen von Leuten zu befassen, die Posts von mir als "kindisch" bezeichnen. Der einzige Rat, den ich gebe: Ein anständiges Interface mit Busmaster kaufen. Kostet um die 20 Euro und ist innerhalb von wenigen Tagen geliefert.

pah

[dan1180]

@pah

Allerdings sehe ich auch keinerlei Veranlassung, mich mit den Problemen von Leuten zu befassen, die Posts von mir als "kindisch" bezeichnen.

Nichts für ungut. Ich habe nicht deinen Post als kindisch bezeichnet sondern EUREN Streit über die Definition eines Fehlers/Problems/Veraltetseins/Wieauchimmer eines Moduls. Es finden sich mehr als 10 Beiträge, die weder etwas mit der Analyse, noch mit der Lösung meines Problems (und ich dachte dazu sei ein Forum da) zu tun haben.Erwachsen finde ich das nicht. Übrigens auch nicht jetzt beleidigt zu sein nachdem ich dich in keiner Weise angegriffen habe. Wenn du nicht zur Lösung beitragen möchtest oder meine Meinung zu eurem Disput nicht akzeptierst dann schreib einfach nichts mehr zu diesem Beitrag aber fang jetzt nicht mit mir eine ähnliche Diskussion an wie mit Joachim. Dazu habe ich weder Zeit noch Lust und für mich ist das Thema somit auch erledigt.

@det
Vielen Dank. Ich habe den Artikel durchgearbeitet. Neue Hardware scheint ja, wenn wie bei mir nur FHEM darauf läuft, nicht notwendig zu sein. Die Abfragen meiner Sensoren habe ich alle auf event-on-change-reading gestellt. Was ich nicht ganz verstehe ist das Verhindern von Logs. Geht es darum die Logs aus dem fhem.log raus zu lassen oder bei einem selbsterstellten Log einzelne Events raus zu lassen?
Mittels apptime wurde seiner Zeit ermittelt, dass OWTHERM teilweise länger als 11 Sek. FHEM blockiert, was mich zu diesem Beitrag geführt hat. Das Modul 99_perfmon.pm habe ich nun installiert. Lass das jetzt mal ne Weile rennen und meld mich, wenn ich was zum angucken hab.

[det.]

Was ich nicht ganz verstehe ist das Verhindern von Logs. Geht es darum die Logs aus dem fhem.log raus zu lassen oder bei einem selbsterstellten Log einzelne Events raus zu lassen?

Es geht grundsätzlich darum, z.B. in den individuellen Filelogs Deiner Geräte nur das zu loggen, was Du wirklich brauchst. Jedes unnütze Event verbraucht Resourcen. Mach mal den Event Monitor an und schau was da alles kommt. Eliminiere alles, was Du da siehst und nicht zu irgendeiner Schalt/Anzeige oder sonst was Aufgabe benötigst.
Besonders eifrig sind da die Homematic Stellantriebe, als Beispiel mal einer aus einem der Gästezimmer:

Code Auswählen Erweitern

define CUL_HM_HM_CC_RT_DN_24897F CUL_HM 24897F
attr CUL_HM_HM_CC_RT_DN_24897F IODev HMLAN1
attr CUL_HM_HM_CC_RT_DN_24897F actCycle 000:10
attr CUL_HM_HM_CC_RT_DN_24897F actStatus alive
attr CUL_HM_HM_CC_RT_DN_24897F autoReadReg 4_reqStatus
attr CUL_HM_HM_CC_RT_DN_24897F do_not_notify 1
attr CUL_HM_HM_CC_RT_DN_24897F expert 2_full
attr CUL_HM_HM_CC_RT_DN_24897F firmware 1.1
attr CUL_HM_HM_CC_RT_DN_24897F model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F peerIDs
attr CUL_HM_HM_CC_RT_DN_24897F room Unsorted
attr CUL_HM_HM_CC_RT_DN_24897F serialNr KEQ0959714
attr CUL_HM_HM_CC_RT_DN_24897F subType thermostat
attr CUL_HM_HM_CC_RT_DN_24897F webCmd getConfig:clear msgEvents:burstXmit
define CUL_HM_HM_CC_RT_DN_24897F_Weather CUL_HM 24897F01
attr CUL_HM_HM_CC_RT_DN_24897F_Weather do_not_notify 1
attr CUL_HM_HM_CC_RT_DN_24897F_Weather model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F_Weather peerIDs 00000000,
define CUL_HM_HM_CC_RT_DN_24897F_Climate CUL_HM 24897F02
attr CUL_HM_HM_CC_RT_DN_24897F_Climate do_not_notify 1
attr CUL_HM_HM_CC_RT_DN_24897F_Climate model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F_Climate peerIDs 00000000,
define CUL_HM_HM_CC_RT_DN_24897F_WindowRec CUL_HM 24897F03
attr CUL_HM_HM_CC_RT_DN_24897F_WindowRec do_not_notify 1
attr CUL_HM_HM_CC_RT_DN_24897F_WindowRec model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F_WindowRec peerIDs 00000000,
attr CUL_HM_HM_CC_RT_DN_24897F_WindowRec stateFormat last:trigLast
define CUL_HM_HM_CC_RT_DN_24897F_Clima CUL_HM 24897F04
attr CUL_HM_HM_CC_RT_DN_24897F_Clima alias hz_RON
attr CUL_HM_HM_CC_RT_DN_24897F_Clima event-on-change-reading state
attr CUL_HM_HM_CC_RT_DN_24897F_Clima group Raumheizung
attr CUL_HM_HM_CC_RT_DN_24897F_Clima model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F_Clima peerIDs 00000000,
attr CUL_HM_HM_CC_RT_DN_24897F_Clima room Residents
attr CUL_HM_HM_CC_RT_DN_24897F_Clima stateFormat measured-temp °C | Ventil: ValvePosition |
define CUL_HM_HM_CC_RT_DN_24897F_ClimaTeam CUL_HM 24897F05
attr CUL_HM_HM_CC_RT_DN_24897F_ClimaTeam do_not_notify 1
attr CUL_HM_HM_CC_RT_DN_24897F_ClimaTeam model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F_ClimaTeam peerIDs 00000000,
define CUL_HM_HM_CC_RT_DN_24897F_remote CUL_HM 24897F06
attr CUL_HM_HM_CC_RT_DN_24897F_remote do_not_notify 1
attr CUL_HM_HM_CC_RT_DN_24897F_remote model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F_remote peerIDs 00000000,
Da habe ich 6 (für meinen Fall) unnütze Events mit do not notify 1 verhindert. Das spart bei der Menge der eingesetzten Stellantriebe im FHEM echt viel Resourcen.

[Joachim]

Moin pah,

Nochmal zu dem ersten Punkt: Wenn man selbst kein Verständnis von der Sache hat, sollte man sich nicht auf un-autorisierte Änderungen des Programmcodes einlassen, die von Autoren stammen, die ebenfalls nach eigenem Bekunden nicht programmieren können.

Der Haken an der Sache ist, dass der Eigenbau danach erkannt wurde, und funktioniert hat. natürlich mit den Latenzen, die dem Eigenbau geschuldet sind.
Und zum finden von Problemen muss man nicht unbedingt programmieren können, logischer Menschenverstand und analytisches Denken reicht dafür oftmals aus.
Ich versuche wenigstens zu helfen, und behaupte nicht nur es geht, ohne Beweise zu liefern.

@ dan1180,
an Deiner Stelle würde ich mal meinen Lösungsweg

Variante 3, das FHEM mit 1-Wire als seperaten Prozess entweder auf der selben Hardware, oder einer abgesetzten Hardware laufen lassen, mittels FHEM2FHEM und cloneDevice die Sensoren auf das Hauptsystem clonen.

ausprobieren, das geht auch auf der gleichen Hardware, indem man die beiden FHEM Prozesse separat laufen lässt.
Einfach den fhem Ordner, den Du unter /opt findest, mit neuem Namen kopieren (z.B. fhem2), an die Berechtigungen denken, fhem.cfg anpassen (telnetport und Weboberflächenport ändern), HM-Einträge und sonstige Sachen, die mit OWX nichts zu tun haben, entfernen.
das 2. FHEM auf der Komandozeile im Verzeichnis /opt/fhem2 mit

Code Auswählen Erweitern

perl fhem.pl fhem.cfg
starten.
Auf dem originalen fhem natürlich vorhel alles, was mit OWX zu tun hat entfernen, danach FHEM2FHEM  und cloneDummy installieren, FHEM neu starten.
Dann mit apptime und Perfmon nachsehen wie die Latenzen sind.
Mich störte es allerding nicht, dass Du das Verhalten von mir und pah als kindisch bezeichnet hast, aber es hat Spass gemacht.

Gruß Joachim

[dan1180]

Dann werd ich mir die Events nochmal genauer anschauen. Der PerformanceMonitor gab in den ersten 5 Minuten schon mehrere freezes >105 Sekunden aus! (Log im Anhang)

Außerdem noch die aktuelle Ausgabe von apptime:

Code Auswählen Erweitern

name             function    max  count    total  average maxDly
               tmr-OWTHERM_GetValues      HASH(0x1beb9e0)   7167      1     7167  7167.00      4 HASH(0x1beb9e0)
               tmr-OWTHERM_GetValues      HASH(0x1b6fa48)   7156      1     7156  7156.00      3 HASH(0x1b6fa48)
               tmr-OWTHERM_GetValues      HASH(0x1bec270)   7148      1     7148  7148.00      4 HASH(0x1bec270)
               tmr-OWTHERM_GetValues      HASH(0x1beb170)   7144      1     7144  7144.00      4 HASH(0x1beb170)
               tmr-OWTHERM_GetValues      HASH(0x1bb38b0)   7139      1     7139  7139.00      4 HASH(0x1bb38b0)
               tmr-OWTHERM_GetValues      HASH(0x1beb5a8)   7121      1     7121  7121.00      5 HASH(0x1beb5a8)
               tmr-OWTHERM_GetValues      HASH(0x1bec6a8)   7121      1     7121  7121.00      5 HASH(0x1bec6a8)
               tmr-OWTHERM_GetValues      HASH(0x1bebe18)   7117      1     7117  7117.00      5 HASH(0x1bebe18)
               tmr-OWTHERM_GetValues      HASH(0x1be8e48)   7114      1     7114  7114.00      4 HASH(0x1be8e48)
         FHEMWEB:192.168.2.103:49980              FW_Read   2304      6     2356   392.67      0 HASH(0x1ee8800)
                              HMLAN1           HMLAN_Read    185     13      585    45.00      0 HASH(0x1614e40)
                              HMLAN1          HMLAN_Ready     88     46      109     2.37      0 HASH(0x1614e40)
                        tmr-OWX_Kick      HASH(0x1597230)     38      1       38    38.00      4 HASH(0x1597230)
              tmr-FW_closeOldClients                          20      3       24     8.00   4279
                          eventTypes    eventTypes_Notify     11     16      112     7.00      0 HASH(0x1592750); HASH(0x1b56640)
                 tmr-HMLAN_KeepAlive     keepAlive:HMLAN1      8      5       24     4.80   7162 keepAlive:HMLAN1
                             SSP_LOG          FileLog_Log      7     16       38     2.38      0 HASH(0x1becae0); HASH(0x1c93d80)
         FHEMWEB:192.168.2.103:49981              FW_Read      6      4       21     5.25      0 HASH(0x1d17698)
         FHEMWEB:192.168.2.103:49982              FW_Read      6      2       11     5.50      0 HASH(0x1f262a8)
         FHEMWEB:192.168.2.103:49983              FW_Read      6      2       12     6.00      0 HASH(0x1f07ed8)
                              HMLAN1         HMLAN_Notify      6     16        6     0.38      0 HASH(0x1614e40); HASH(0x1614e40)


Das ist doch nicht normal...Muss wohl jetzt auf das aktive Interface mit Spannungsversorgung warten. Ansonsten macht wohl alle weitere Analyse keinen Sinn
Sollte noch jemand einen Tipp haben, gerne her damit. Ansonsten wür ich mich melden, wenn ich das neue Teil angeschlossen habe.

@Joachim
Werd die Variante mal, solange ich auf meinen BUS warte, testen. Du hast ziemlich am Anfang mal geschrieben, dass unter Umständen trotzdem ein Fehler auftreten kann. Ich hab etwas Angst, dass ich mich dann auf FHEM verlasse, weil es ein paar Tage lang fuunktioniert, und dann verlassen werde...

[det.]

@det: Den hier meinst Du ? http://www.legacy.com/obituaries/pressconnects/obituary.aspx?pid=169499088
LG
pah

@ pah,
Diesen Bosnick kannte ich noch nicht, allerdings wenn ich das English richtig verstanden habe war er nicht halb so sarkastisch wie pah, det. und weitere hier im Forum. Seit Harald Schmidt nicht mehr gen Mitternacht über andere Leute herzieht, ist das Forum hier dafür ein sehr vergnüglicher Ersatz - Technik mit viel Unterhaltungswert.

[Joachim]

@ dan1180,

Du hast ziemlich am Anfang mal geschrieben, dass unter Umständen trotzdem ein Fehler auftreten kann

Das ist richtig allerdings hatte ich nie gesucht, wo der Fehler herkam, da mit der FHEM2FHEM Variante mein HM un MAX zufriedenstellen lief, und es für mich keinen Grund gab, hier weiter zu suchen. Im Anhang mal Apptime von einem Testsystem, das mittel FHEM2FHEM an das "OWX" System angebunden ist.

Gruß Joachim

PS:Wie man in Deinem angehängten Log hervorragend sieht, ist es OXW, dass Dein System die 105 Sekunden anhält.
habe da jetzt keine Lust zu suchen, warum. Nicht dass ich wieder einen Designfehler finde, und pah damit angreife.

[dan1180]

OK. Also vernachlässigbar.  Ich versuchs einfach mal. Falls du doch Lust bekommst und nach der Ursache suchst kannst du es ja z.B, D-Fehler nennen. Mur ist es nämlich, wie schon geschrieben,  sch...egal wie das Problem heißt. Ich bin aber brennend an einer Lösung interessiert.

Danke mal wieder!

[Joachim]

Moin dan1180,
viel Glück, wenn es Probleme beim Installieren gibt, bescheid sagen.

Dass es Dir als Endanwender sch...egal ist, wie das ganze genannt wird, ist mir volkommen klar und verständlich.
Wenn man dann tiefer in die Analyse der Programmierung einsteigt, dann ändert sich das.
Denn dann muß man da durchaus trennen, welcher Art das Problem ist, um dem Programmierer nicht unrecht zu tun.

Gruß Joachim

PS.: Ich habe das "böse Wort" weggelassen.

[Prof. Dr. Peter Henning]

@det.:Auch das lustige Programmzeilenraten hier ist eigentlich ganz interessant. Nach dem Inifinite-Monkey-Theorem wird das zu einer stark verbesserten Ausgabe von FHEM im Allgemeinen und OWX im speziellen führen. Bin gespannt.

pah

[Joachim]

Mensch pah,
Du entwickelst Dich immer mehr zum Foren-Troll.

Als Troll bezeichnet man im Netzjargon eine Person, welche die Kommunikation im Internet fortwährend und auf destruktive Weise dadurch behindert, dass sie Beiträge verfasst, die sich auf die Provokation anderer Gesprächsteilnehmer beschränken und keinen sachbezogenen und konstruktiven Beitrag zur Diskussion darstellen. In darauf bezogenen Bildern wird oft auf den aus der Mythologie bekannten Troll verwiesen. Ein gelegentlich gebrauchtes Synonym ist Twit (engl: Dummkopf).

Quelle:
http://de.wikipedia.org/wiki/Troll_%28Netzkultur%29
hast Du das wirklich nötig?

Gruß Joachim

[dan1180]

Hallo Joachim,

FHEM ist kopiert, fhem.cfg editiert und auch der Start der zweiten Instanz scheint funktioniert zu haben (kein Meckern beim Startbefehl). Nun jedoch folgenden Probleme:

1. Muss ich nach dem "define ... FHEM2FEHM..." irgendwelche Attribute setzen?
2. Startet die 2. Instanz von FHEM auch immer automatisch bei einem Reboot des RasPi?
3. Kannst du mir bitte den clonedummy erklären? Was muss ich da machen? Finde zwar dummy in der Commandref aber keine Erklärung für den clone...

Danke!

[Joachim]

Moin dan1180,
Als erstes ausprobieren, ob Du auf Deine neue FHEM Instanz über einen Browser heraufkommst, also:
localhost:8073/fhem
localhost ist glaube ich klar, und die 8073 mit dem Port ersetzen, den Du in der fhem.cfg angegeben hast, nicht 8083, 8084 oder 8085, die sind ja schon von Deinem Hauptfhem belegt.

1. Muss ich nach dem "define ... FHEM2FEHM..." irgendwelche Attribute setzen?

z.B.:
define meinOWX FHEM2FHEM localhost:7072 LOG:.*
naürlich auf Deinem HauptFHEM, wobei auch hier der Port anzupassen ist, und natürlich nicht mit dem telnetport Deines Hauptfhems übereinstimmen sollte. Also wie oben schon beschrieben den telnetport Deines OWXFHEMs in der cfg ändern, und diese Änderung dann im def eintragen.

2. Startet die 2. Instanz von FHEM auch immer automatisch bei einem Reboot des RasPi?

Nein, das war jetzt nur ein direkter Start von FHEM, wenn das nachher automatisch gehen soll, dann muß in init.d noch etwas angepasst werden.

3. Kannst du mir bitte den clonedummy erklären? Was muss ich da machen? Finde zwar dummy in der Commandref aber keine Erklärung für den clone...

Musst Du noch üben, mit dem Suchen.

cloneDummy

    Definiert einen Clon eines Devices oder von FHEM2FHEM im Logmodus uebergebenen Devices und uebernimmt dessen Readings. Sinnvoll um entfernte FHEM-Installationen lesend einzubinden, zum Testen oder Programmieren.

    Define
        define <name> cloneDummy <Quelldevice> [reading]

        Aktiviert den cloneDummy, der dann an das Device <Quelldevice> gebunden ist. Mit dem optionalen Parameter reading wird bestimmt, welches reading im STATE angezeigt wird, stateFormat ist auch weiterhin möglich.
            Beispiel: Der cloneDummy wird lesend an den Sensor OWX_26_09FF26010000 gebunden und zeigt im State temperature an.
            define Feuchte cloneDummy OWX_26_09FF26010000 temperature

    Set
        N/A
    Get
        N/A
    Attributes
        clonIgnore
        Eine durch Kommata getrennte Liste der readings, die cloneDummy nicht in eigene readings umwandelt

        readingFnAttributes

    Wichtig: Es müssen unterschiedliche Namen für <name> und <Quelldevice> verwendet werden!

Gruß Joachim