- √ - Wiregate spinnt seit PL30

[StefanW]

Guten Morgen Sascha,

Trotzdem hängt das Problem mit den 1w Sensoren und dem mpg123 zusammen, da der mpg123 trotz vernünftiger Lautstärke immer dann nicht lief, wenn die Sensoren keine Werte auf den Bus geliefert haben.

Makki hatte oben bemerkt "...der "sleep;" tut in einem Plugin nichts anderes als für immer schlafen und damit den kompletten daemon mit einem Timeout ermorden..."

Hast Du einen 'sleep' in Deinen Plugins? Damit würde auch der Dämon angehalten und dann gibt es auch keine Werte auf dem Bus.

lg

Stefan

[haegar80]

Hast Du einen 'sleep' in Deinen Plugins?

Nur dieser Sleep, der aus dem Plugin kommt, das Makki ins SVN geladen hat:
SourceForge.net Repository - [openautomation] Contents of /wiregate/plugin/generic/mpg123_start

Jetzt ist der Sleep raus und ich beobachte...

Danke
Sascha

[StefanW]

Im Plugin im SVN ist dies als 'sleep 1;' definiert, also für eine Sekunde, was ok ist.

Insofern 'sleep ;' angegeben war (also ohne '1' als Parameter, wie von makki oben beschrieben), würde das "für immer" bedeuten, wäre also schon interessant zu wissen, ob die '1' dazu stand oder nicht...

lg

Stefan

[Chris M.]

Nur dieser Sleep, der aus dem Plugin kommt, das Makki ins SVN geladen hat:
SourceForge.net Repository - [openautomation] Contents of /wiregate/plugin/generic/mpg123_start

Das Plugin ist von mir (vgl. https://knx-user-forum.de/wiregate-b...p3-player.html) und schon etwas alt...
D.h. vermutlich könnte man das geschickter ohne sleep realisieren. Oder mit mpd statt mpg123.

Übrigens: zu dem im Plugin beschriebenen Bug sollte es inzwischen einen Bugifx upstream geben. Habe aber noch nicht testen können...

[Bodo]

...schon etwas alt...
D.h. vermutlich könnte man das ... mit mpd statt mpg123 ... realisieren

Hoi Chris

Ich frage mal ganz blauäugig: Wo liegt denn da der Unterschied / Vorteil.

[haegar80]

Insofern 'sleep ;' angegeben war (also ohne '1' als Parameter, wie von makki oben beschrieben), würde das "für immer" bedeuten, wäre also schon interessant zu wissen, ob die '1' dazu stand oder nicht...

Da war sleep 1 dringestanden, das ist mir beim kopieren verloren gegangen.
Daß ein Dauersleep tödlich ist, ist mir schon klar.

Gruß Sascha

P.S. Bis jetzt läuft alles seit 24h.

[Chris M.]

Wo liegt denn da der Unterschied / Vorteil.

Ui, frag mich nicht. Hier bin ich noch nicht in's Detail eingestiegen - ich hatte bisher nur Radio im Bad gebraucht und das per mpg123+altem HiFi-Verstärker am vorbereiteten Multiroom realisiert. Und jetzt mit C3 nutze ich das eingebaute Radio, d.h. nicht mal mehr den mpg123...

Viel mehr Infos etc. steht wohl u.a. in:
https://knx-user-forum.de/code-schni...-sammlung.html

[haegar80]

@haegar: Nun das heisst im Klartext, das ich stark vermute das der 1-Wire physikalisch ziemlich im Eimer ist (das evtl. jetzt nur stärker auffällt, solle zwar trotzdem möglichst still recovern aber..)
Also so das übliche, schlechte Kontakte, ungeschirmte Leitungen quer durchn Verteiler, geschlossene Ringe, leitende WLP bei Lötsensoren, VDD "in der Luft gelassen", irgend sowas..

Was bedeutet das jetzt für mich?
Ich habe meine Sensoren über die freien Adern im KNX Kabel angeschlossen und hatte damit bisher nie praktische Probleme.

Letzte Nacht sind wieder alle Sensoren ausgestiegen. Ich kann doch wegen dem PL30 jetzt nicht alles neu verkabeln. Die Hütte steht und wird seit einem Jahr bewohnt...
Lasst ihr mich jetzt hängen?

Gruß
Sascha

[vento66]

Aktuell hab ich auch keine Werte im RRD, aber die Werte sind im Webmin und auf dem Bus. Es scheint also das "nur" die RRD aussteigen.

[Pontius Pilatus]

Lücken in den RRDs

Hallo zusammen,
ich hänge mich mal hier ganz frech dran. Seit meinem Update auf PL30 beobachte ich regelmäßig alle 8h Aufzeichnungslücken von 2h Länge.

Im Langzeitchart sieht man sehr schön, wann es angefangen hat.

Die Installation ist eine Testinstallation mit ca. 2m 1Wirebus, zwei Temperatursensoren und einem Multisensor. Verändert wurde seit Monaten nichts, außer dem Softwareupdate neulich. Gestern habe ich noch das kleinere Upgrade gemacht und neu gestartet. Das hat aber nichts gebracht.

Ciao, PP

[makki]

So, ich denke ich hab was gefunden und soeben PL31 released. Ohne nun ins Detail zu gehen, es hat primär was mit Speicherlecks (anderes Thema, bekannt) durch Plugins zu tun..
Die zweite Sache ist, das je nach Ausgangslage nach PL30 ein reboot erforderlich ist, was PL31 nun anzeigt (aber nicht automatisch durchführt!)
Ob das final alles war, wird sich die nächsten Tage zeigen müssen..

Makki

P.S.: Der ein oder andere wackelige 1-Wire hat erstmal auf die völlig falsche Spur geführt

[Pontius Pilatus]

WOW, was für Reaktionszeiten

Ich habe PL31 installiert. Will ich wissen, woran es lag?

PP

[makki]

Naja, suchen tue ich nun schon etwas länger Man muss nur erstmal den Angriffspunkt finden, warum das auf allen Testsystemen wunderbar tut aber bei dem ein oder anderen eben nicht.

Es sind wie so oft mehrere Faktoren:
Das eine ist der (unerfindliche), notwendige Reboot bei gefühlt 5-10%
das nächste das entspanntere handling von 1w-Fehlern, was 1) jedoch potenziert.
Und dann noch massiv aufgedrehte Speicher-Limits; ich vermute 99,9% das das Problem z.B. bei vento und haegar auch vorher schon da war aber nicht auffiel, weil dem wiregated sowieso alle paar Minuten wegen memleaks(*) der Stecker gezogen wurde

Makki

*) was es dann als nächstes zu lokalisieren gilt, ist in der Praxis aber eigentlich nicht so dramatisch, weil es eh abgefangen wird..

[ZeitlerW]

Auch auf community-gate gelöst

Hallo zusammen,

erst mal Vielen Dank an makki für die unermütlichen Einsatz!

nur der Vollständigkeit halber habe ich auch mein Problem gelöst (PL31):

Ich habe wie schon oben angemerkt den wiregated auf Fremdhardware (PC Engines WRAP + voyage-linux) laufen. Ich konnte mein Problem damit lösen, indem ich im wiregated die Wartezeit nach owfs-server Neustart von 2 sec. auf 5 sec. erhöht habe. Außerdem probiere ich jetzt öfter bevor ich aufgebe. Das WRAP - Board ist halt ein wenig schwach auf der Brust.
Hier noch die Änderung, falls es jemand nachvollziehen will:
In der /usr/sbin/wiregated.pl ab Zeile 1403

  if (!@ds9490 and $ds9490_retrys < [COLOR=Red]50[/COLOR]) { # No adapter-Id's in cache -> fill
  # This is to avoid disconnected adapters owserver looses - not perfect..
    $ds9490_retrys++;
    my $dummy = `/etc/init.d/owfs-server restart` unless (-e '/etc/wiregate/owserver.static');
    [COLOR=Red]sleep (5);[/COLOR]
    INFO("No DS9490 found - owserver restart and fill cache..");
...

vG
Wolfgang

[makki]

Möglich das es mit 50/5 erheblich seltener auftritt aber:

Das Problem liegt woanders, es ist mal wieder so ein schönes, wirres "Perl-Feature" das bei 5% ohen erkennbaren Grund zuschlägt; dank vento & Chris bin ich dem nun hoffentlich auf den Grund gekommen.
Ist umgeschrieben, Perl "threads" werden einfach abgeschafft, zwei daemons (weil es keine Threads, sondern die schlechte Emulation von Posix-prozessen unter Windows ist)
Wollte ich eigentlich schon mit PL30 machen, habe ich leider nicht. Aber das ist recht massiv-> muss noch ein bisschen getestet werden..

Makki