RaspberryMatic 3.57.5.20210424 – Neue Version

[jmaus]

Code: Alles auswählen

May  4 07:02:01 Homematic-CCU user.err kernel: [752701.982444] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 34, required space = 39
May  4 07:02:02 Homematic-CCU user.info kernel: [752701.982472] eq3loop: eq3loop_write_master() return error: -14

Jemand eine Idee was das genau ist?

Ja, irgendwas ballert dein Funkmodul mit Events zu. D.h. irgendeine externe Anwendung oder ein Programm ist der Meinung es muss in kurzem Abstand hunderte Events raussenden und das überlädt die buffer im Kernel modul. Konkrete Ursache kann eine externe Anwendung wie ioBroker oder ähnliches sein oder ein WebUI Programm das schlecht programmiert ist, das eben durchdreht. Lösug: Zukessives abschalten externer Programme, etc. inkl. der internen Programme bis sich die Situation beruhigt.

[mbhomie007]

Vielen Dank für die schnelle Antwort.

Da ich in letzter Zeit keine Programmen verändert habe und vorher alles lief, muss es bei mir der ioBroker sein.
Werde mich mal auf die Suche machen.

[deimos]

Hi,

Code: Alles auswählen

May  4 07:02:01 Homematic-CCU user.err kernel: [752701.982444] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 34, required space = 39
May  4 07:02:02 Homematic-CCU user.info kernel: [752701.982472] eq3loop: eq3loop_write_master() return error: -14

Jemand eine Idee was das genau ist?

Ja, irgendwas ballert dein Funkmodul mit Events zu. D.h. irgendeine externe Anwendung oder ein Programm ist der Meinung es muss in kurzem Abstand hunderte Events raussenden und das überlädt die buffer im Kernel modul. Konkrete Ursache kann eine externe Anwendung wie ioBroker oder ähnliches sein oder ein WebUI Programm das schlecht programmiert ist, das eben durchdreht. Lösug: Zukessives abschalten externer Programme, etc. inkl. der internen Programme bis sich die Situation beruhigt.

Ich dachte, wir hätten geklärt, dass das nicht die Ursache ist, weil es um die Richtung FunkmodulKernel Modul zum HmIP Server geht? Das hatten wir doch unter viewtopic.php?f=26&t=65523&start=20#p648924 durchdiskutiert?

Viele Grüße
Alex

[jmaus]

Code: Alles auswählen

May  4 07:02:01 Homematic-CCU user.err kernel: [752701.982444] eq3loop: eq3loop_write_master() mmd_hmip: not enough space in buffers. free space = 34, required space = 39
May  4 07:02:02 Homematic-CCU user.info kernel: [752701.982472] eq3loop: eq3loop_write_master() return error: -14

Jemand eine Idee was das genau ist?

Ja, irgendwas ballert dein Funkmodul mit Events zu. D.h. irgendeine externe Anwendung oder ein Programm ist der Meinung es muss in kurzem Abstand hunderte Events raussenden und das überlädt die buffer im Kernel modul. Konkrete Ursache kann eine externe Anwendung wie ioBroker oder ähnliches sein oder ein WebUI Programm das schlecht programmiert ist, das eben durchdreht. Lösug: Zukessives abschalten externer Programme, etc. inkl. der internen Programme bis sich die Situation beruhigt.

Ich dachte, wir hätten geklärt, dass das nicht die Ursache ist, weil es um die Richtung FunkmodulKernel Modul zum HmIP Server geht? Das hatten wir doch unter viewtopic.php?f=26&t=65523&start=20#p648924 durchdiskutiert?

Das stimmt, das hattest du mal angesprochen und auch die vermutung das es an der nrjavaserial im HmIPServer liegt. So ganz dran glauben kann ich jedoch noch nicht. Würde mich aber natürlich freuen wenn es in der Tat "nur" daran liegt. Ich werde also nochmal meine eQ3 Kontakte anhauen damit die NRJava im HmIPServer entsprechend aktualisiert wird und dann werden wir ja sehen ob es in der Tat daran liegt oder doch einfach ein event-flooding (vielleicht ja auch nur über den HmIP weg) ist wie ich immer noch teilweise vermute.

[deimos]

Hi,

es liegt auf jeden Fall irgendwo im HmIPServer. Rein von der Fehlermeldung her ist es eindeutig, dass es um Nachrichten vom Funkmodul in Richtung HmIPServer bzw. rfd geht. Und da in allen mir bekannten Meldungen von Nutzern immer der HmIPServer betroffen ist und nicht ein einziges Mal der rfd, ist das recht eindeutig.

Ob es zwingend ein Problem der uralten nrjavaserial ist, keine Ahnung, aber es ist gut möglich. Genauso könnte es natürlich auch irgendwas im internen Threading sein oder die Garbage Collection von Java. Schaden dürfte ekn Update der nrjavaserial aber in keinem Fall, in den mehr als 5 Jahren zwischen der aktuellen Version und der Version aus dem HmIPServer sind genug Bugfixes drin, die das rechtfertigen dürften.

Viele Grüße
Alex

[deimos]

Hi,

und zwecks Event Flooding: Wie gesagt, wir reden von den Daten, die vom Funkmodul kommen, rein von der Hardware her können das maximal 115200 Baud sein, wenn das über einen solch langen Zeitraum ein Event Flooding verursacht, dann ist kann ich mir das nicht wirklich vorstellen.
Hätte ich Zugriff auf den Source, würde ich ja mal durchdebuggen, aber das scheint von eQ-3 ja nicht gewünscht zu sein.

Viele Grüße
Alex

[jmaus]

und zwecks Event Flooding: Wie gesagt, wir reden von den Daten, die vom Funkmodul kommen…

Ok, wenn die natürlich VOM Modul zum HmIPServer unterwegs sind ist es in der Tat schwer vorstellbar das es zu dem problem kommt. Das würde ja bedeuten der HmIPServer holt die ne längere zeit nicht ab. Dachte bisher immer es ist der andere Weg ZUM Funkmodul. Ok. Dann warten wir mal ab was eine aktualisierte NRjavaSerial bringt sobald eQ3 die eingebaut hat.

Hätte ich Zugriff auf den Source, würde ich ja mal durchdebuggen, aber das scheint von eQ-3 ja nicht gewünscht zu sein.

Nun, auch ich hab keinen Quellcode Zugriff auf den HmIPServer und das ist teilweise verständlich wenn man weiss, das da komponenten drinstecken die auch in dee Cloud verwendung finden und nicht wie rfd oder multimacd legacy bzw teilweise obsolete dinge sind. Muss man halt melden und warten was da kommt. So ist das eben.

[ElServo]

Ich habe das getestet und was anderes festgestellt. Siehe Link
Kannst du grob sagen wie lange der erfolgreiche Updatevorgang dauerte?

via recovery-mode ca. 10 Minuten

[widder17]

Das Problem mit der Cloudmatic besteht ja nun weiterhin beim Tinkerboard S.

Ich habe nun die Möglichkeit das Tinkerboard zurück zu geben. Nun stellt sich mir die Frage, ob ich mir ein neues Tinkerboard holen soll, oder doch lieber wieder auf einen Raspberry umschwenke. Alternativ gibt es ja seit neustem die Möglichkeit mit Odroid.

Da es anscheinend nur wenige User betrifft weiß ich nicht wie groß das Interesse ist sich diesem Problem anzunehmen.
Bitte nicht falsch verstehen. Finde die Arbeit und die gesamte Raspberrymatic weiterhin Top!!!

VG

[jmaus]

Das Problem mit der Cloudmatic besteht ja nun weiterhin beim Tinkerboard S.

Ich habe nun die Möglichkeit das Tinkerboard zurück zu geben. Nun stellt sich mir die Frage, ob ich mir ein neues Tinkerboard holen soll, oder doch lieber wieder auf einen Raspberry umschwenke. Alternativ gibt es ja seit neustem die Möglichkeit mit Odroid.

Also ich habe die Diskussion dazu jetzt nicht verfolgt, aber warum genau sollte CloudMatic auf einer anderen Hardware besser laufen wenn es auf einem Tinkerboard nicht läuft?!? Das erscheint mir keine sinnige Schlussfolgerung zu sein, das man auf einen RaspberryPi oder ODROID oder anderes Tinkerboard wechseln sollte wenn CloudMatic Probleme macht.