Visu reagiert nicht mehr

[mfd]

Ich habe gerade ein größeres Problem mit der CV.
Im Einsatz ist die Release-Version.
Das Wiregate selbst (auf eigener HW) reagiert soweit normal. Temperaturwerte werden auf den Bus gesendet. GAs aus Plugins auch.


Der XML-Config-Check bringt lediglich Fehler dieser Art:

[B]Warning[/B]:  DOMDocument::schemaValidate() [[URL="http://192.168.1.22/visu/domdocument.schemavalidate"]domdocument.schemavalidate[/URL]]: Element 'multitrigger', attribute 'align': The attribute 'align' is not allowed. in [B]/var/www/visu/check_config.php[/B] on line [B]18[/B]

[B]Warning[/B]:  DOMDocument::schemaValidate() [[URL="http://192.168.1.22/visu/domdocument.schemavalidate"]domdocument.schemavalidate[/URL]]: Element 'diagram_popup': Element content is not allowed, because the content type is a simple type definition. in [B]/var/www/visu/check_config.php[/B] on line [B]18[/B]
config [B]visu_config is NOT [/B] valid XML

In der Visu werden keine Info-Werte ausgegeben und auch keinerlei Zustände angezeigt. Betätigen von Schaltflächen löst keinerlei Reaktion aus (es werden keine GAs auf den Bus gesendet - Gruppenmonitor in der ETS zeigt keine Telegramme von der Visu kommend).
Bis gestern war soweit erkennbar noch alles in Ordnung.
Seitdem wurden keine größeren Änderungen an der Visu vorgenommen. Eine Schaltfläche "switch" wurde lediglich hinzugefügt.
Ich habe bereits kontrolliert, dass keine "leeren" GA-Zuweisungen im Editor vorhanden sind - was sich normalerweise aber auch als Fehler im check-config abzeichnet.

Gibt es die Möglichkeit am WG zu überprüfen an welcher Stelle die Kommunikation "hängen bleibt"?
Wäre für Lösungs-Ansätze sehr dankbar.

Ich habe soeben noch eine ältere Version meiner Config ausprbiert, damit bekomme ich ebenfalls keinerlei Reaktion.
Es muss also wohl etwas Schwerwiegenderes sein...
Ich habe auf dem WG schon versucht aus den Log-Dateien schlau zu werden, allerdings finde ich da nichts was mir direkt weiterhilft.

[mfd]

Vorerst gelöst

Hmmm,
nachdem ich jetzt das WG zum Zweiten Mal neu gestartet habe...
...habe ich im Gruppenmonitor gesehen wie alle Werte nach dem Reboot brav eingelesen wurden....
... und es scheint alles wieder in Butter
Zumindest reagiert alles so wie es soll, Werte sind da, und Steuerung funktioniert.

So richtig beruhigend finde ich das jetzt allerdings trotzdem nicht.
Da das WG bzw. die CV bei mir eine Zentrale Steuereinheit ist/werden soll* würde ich solchen Schluckauf gerne in den Griff bekommen.
Kann ich da irgendwie Ursachenforschung betreiben?

*Ich weiß, ich sollte mir dazu früher oder später das "Original" kaufen. Wobei hier leider finanztechnisch andere Gerätschaften Vorrang haben -> WAF nicht zu vergessen

[netsrac]

Willst Du mal Deine Config zum drüberschauen schicken. Mein Problem sind meist irgendwelche vergessenen "/".

Gruß, Netsrac

[netsrac]

Okay...da haben sich unsere Antworten überschnitten.

Normalerweise würde ich bei einem Fall wie bei Dir mal ins Logfile des Webbrowsers schauen ob dort irgendwas merkwürdiges auffällt.

Ansonsten ist der böseste Feind der CV der Browser Cache. Der treibt mich manchmal noch in den Wahnsinn. Vorallem auf Tablets, wo es oft keine Optionen zum löschen gibt...

Gruß, Netsrac

[mfd]

Das kann ich gerne tun, allerdings verwende ich ja immer den eingebauten Editor (Release-Version!) der sollte da doch hoffentlich nichts vergessen...?

[mfd]

Ansonsten ist der böseste Feind der CV der Browser Cache. Der treibt mich manchmal noch in den Wahnsinn. Vorallem auf Tablets, wo es oft keine Optionen zum löschen gibt...

Das Problem ist mir bekannt, das äußert sich aber dann anders.

Es hat wohl wirklich irgendwo "eine Stufe tiefer" gehangen.
Ich hatte ja verschiedene, ältere configs, getestet und bei keiner eine Reaktion.

[netsrac]

In der Visu werden keine Info-Werte ausgegeben und auch keinerlei Zustände angezeigt. Betätigen von Schaltflächen löst keinerlei Reaktion aus (es werden keine GAs auf den Bus gesendet - Gruppenmonitor in der ETS zeigt keine Telegramme von der Visu kommend).

Okay...das passiert bei mir immer dann, wenn der eibd neu gestartet wird/wurde. Denn aus irgendwelchen unerklärlichen Gründen werden dann die Rechte des Kommunikations-Sockets (per default /tmp/eib) so gesetzt, dass der Webserver (über die cgi's) nicht darauf zugreifen kann.

Sollte also das Problem nochmal auftreten, dann schaue mal nach dieser Datei und mache notfalls ein

chmod 666 /tmp/eib

und gucke, ob sich das Problem damit behebt.

Korrekt müsste man eine eigene Gruppe für die eib-Kommunikation erstellen, den webserver-Prozess zugriff auf diese Grupper erlauben und nur mit Owner und Group-Schreibrechten arbeiten.

Gruß, Netsrac

[mfd]

Dem Hinweis werde ich mal nachgehen, das hört sich an als würde es in die richtige Richtung gehen.

[netsrac]

Dem Hinweis werde ich mal nachgehen, das hört sich an als würde es in die richtige Richtung gehen.

Ich vermute mal, dass das "echte" Wiregate das richtig setzt. Bei mir läuft ja auch alles (und noch viel mehr) auf einer Linux Box...

Gruß, Netsrac

[Chris M.]

Insb. wenn man meint, dass es "tiefer" hängt, kommt der meist entscheidende Wissensgewinn dadruch, dass man schaut, was Browser und Server austauschen.
=> Firebug oder (bei Chrome[ium]) Strg+Shift+I und dort auf den Netzwerk-Transfer gehen

Alle CV-Antworten sollten schon mal HTTP Status 200 haben (sonst GoTo Server). Und falls ja: mal in die Antworten selbst hinein schauen, insb. bei "r".

[makki]

Jow, ohne Details kann die Glaskugel nichts sagen, insbesondere interessant (parallel):

- vbusmonitor1time local:/tmp/eib
- /var/log/eib.log
- Browser (Firebug F12 oder strg-shift-i im Chrome)

Ich tippe eher auf ein Problem im Webserver oder so, weil ich benutz das seit jahren jeden Tag tausendfach..

Makki

[Robert_Mini]

Nur zur Sicherheit:
Die Werte werden auch nicht mehr aktualisiert, wenn im Editor eine GA hinzugefügt wird, dann aber keine GA eingetragen wird.
Das lässt sich am einfachsten durch editieren der XML feststellen, wenn

<address transform="DPT:1.001" variant=""[B]><[/B]/address>

ohne Eintrag zw. >< zu finden ist (DPT beliebig).
lg
Robert

[makki]

Hmm, das ist im Prinzip ein illegaler Eintrag im XML - sollte abgefangen werden aber momentan würde ich die Prio und spärlichen Ressourcen lieber auf ein neues Release legen als Sachen zu beheben die zwar technisch blöd aber im Endeffekt auch Bedienfehler sind

Makki

[mfd]

@ Robert_Mini
Die "illegale GA" hatte ich schon ausgeschlossen (siehe Posting ganz am Anfang).

@makki
Falls es jemals wieder auftritt werde ich nach o.g. Muster vorgehen und berichten.