Firmware v2.31.23 online

[semml]

Danke Jens, es funktiert leider nicht.
Das Display bleibt weis, wenn ich es direkt in den Browser eingebe klappt alles.

[anli]

Probiere es wie von Jens vorgeschlagen doch einmal per SSH auf der CCU2-Konsole. Ich schlage folgendes vor (am Ende sind zwei einzelne Anführungszeichen '):

Code: Alles auswählen

wget 'http://192.190.164.48:50000/?showframe=\'http://192.190.164.37:8083/cgi-bin/CGIStream.cgi?cmd=GetMJStream&usr=xxxx&pwd=xxxx\''

Wenn das geht, kannst Du es entsprechend in Dein Skript einbauen.

[semml]

Vielen Dank, geht leider auch

LG semml

[DerLockjaw]

It‘s not a bug, it‘s a feature Da shell redirections (>) und pipes (|) jetzt von system.Exec() unterstützt werden, müssen Sonderzeichen die in einer unix shell für andere dinge verwendet werden zwingend escaped werden.

Code: Alles auswählen

system.Exec("wget '" # url # "' &");

Bitte hierbei beachten das ich am schluss explizit ein & zeichen angefügt habe damit die ReGa für den Zeitraum der Ausführung des wget nicht blockiert wird da du ohnehin keine Ausgaben davon weiter verarbeiten brauchst und daher ist auch kein stdin/stderr parameter am Schluss notwendig.

Hallo Janus,

vielen Dank für Deine Hilfe. Es hat geklappt. Allerdings lese ich die Ausgabe der Webseite im weiteren Verlauf des Programms aus. Falls jemand das gleiche Problem hat und etwas auslesen muss, dann funktioniert bei mir der Code:

Code: Alles auswählen

 system.Exec("wget -q -O -  '" # url # "'", &stdout, &stderr);

Deinen letzten Satz mit dem blockierten ReGa (?) habe ich nicht verstanden. War aber jetzt ja auch egal.

[jmaus]

Deinen letzten Satz mit dem blockierten ReGa (?) habe ich nicht verstanden. War aber jetzt ja auch egal.

Dann versuche ich das am besten gleich mal aufzuklären: da die Skriptengine der ReGaHss (die Logikschicht der CCU) single-threaded implementiert ist ist es so, das während der Abarbeitung eines ReGa-Skriptes auch die gesamte Eventloop mehr oder weniger für den Zeitraum der Abarbeitung des Skriptes stillgelegt ist. Und das bedeutet, dass während dieser Zeit andere Programme oder CCU gesteuerte Geräteschaltungen warten müssen bis das momentan abzuarbeitetende Skript fertig ist. Und da der system.Exec() Befehl ja ein externes unix Programm aufruft (in dem Falle 'wget') von dem man nicht weiss wie lange der Aufruf dauert, wird der Rest der CCU eben für den Zeitraum des wget Aufrufes blockiert. Wenn man jedoch nur an der Abarbeitung des externen Befehles interessiert ist und den Returnwert oder die stdout/stderr Ausgabe des externen Befehles nicht benötigt, so kann man am Ende des system.Exec() Aufrufes ein einzelnes " &" stellen. Das weist die aufzurufende Unix Shell dann an den jeweiligen Befehl (das 'wget') zu forken, d.h. die Abarbeitung asynchron durchzuführen. Das führt dann wiederum dazu, dass der system.Exec() Aufruf nicht blockierend ist und sofort zurückkehrt und somit die ReGa ohne Unterbrechung weiterarbeitet - was in jedem Falle wünschenswert sein sollte damit z.b. Geräteschaltungen nicht verzögert verarbeitet werden.

[schlichi]

Hallo Jens,

als "Sonntags- und Schönwetter-User" möchte ich Dir für deinen Beitrag danken, der zwar in der "Fliegersprache" gehalten, auch einem Newcomer erklärt, was "Sache" ist. Ich wünschte mir, daß ein paar der " ´elitären´ Spezi´s" sich daran ein Beispiel nehmen.

Beste Grüße
schlichi

[dtp]

Und da der system.Exec() Befehl ja ein externes unix Programm aufruft (in dem Falle 'wget') von dem man nicht weiss wie lange der Aufruf dauert, wird der Rest der CCU eben für den Zeitraum des wget Aufrufes blockiert.

Sprich, bei Verwendung des CUxD-Äquivalents von system.Exec hat man diese Probleme grundsätzlich nicht, weil die CCU hier immer direkt weiter arbeiten kann, oder?

[jmaus]

Und da der system.Exec() Befehl ja ein externes unix Programm aufruft (in dem Falle 'wget') von dem man nicht weiss wie lange der Aufruf dauert, wird der Rest der CCU eben für den Zeitraum des wget Aufrufes blockiert.

Sprich, bei Verwendung des CUxD-Äquivalents von system.Exec hat man diese Probleme grundsätzlich nicht, weil die CCU hier immer direkt weiter arbeiten kann, oder?

Nicht wirklich. Wenn du bei CUxD an den Ausgaben des aufgerufenen Befehles interessiert bist muss CUxD ja auch die ReGa blockieren lassen bis der Befehl abgearbeitet ist, sonst kannst du ihn ja nicht gleich abholen. Und wenn du nicht an den Ausgaben des Befehls auf stdout/stderr interessiert bist hängst du eben einfach ein " &" hinten an den Befehl an und system.Exec() blockiert dann auch nicht und kehrt sofort zurück. Im Zweifel würde ich daher immer system.Exec() inzwischen bevorzugen denn das läuft inzwischen sehr rund und stabil (zumindest sind mir keine Probleme damit mehr bekannt) und man braucht dann eben CUxD nicht zwingend. Für dein zPNP würde ich mir ein Umstieg auf reines system.Exec() z.B. daher auch wünschen

[Graschi]

Wenn ich sie neu angelernt habe, kann ich zudem keine Einstellungen vornehmen. Die Oberfläche meldet, es gäbe keine Parameter. Das war vorher anders.

Gibt es dafür eine Lösung?
Mein Problem ist auch: Damit sind alle Programme, die diese Geräte referenzieren, natürlich unbrauchbar.

Das Problem kenne ich. Habe jedes Mal Werkreset gemacht und neu angelernt.

Beim letzten Mal aber habe ich einfach gewartet: Update/Neustart (da trat das bei mir auch auf...) Abends um 2300 und am nächsten Morgen erst reingeschaut: Voila, alles wieder da.

Vielleicht mal so probieren... schont Nerven... ich war schon drauf und dran die CCU2 aus dem Fenster zu ballern und sämtliches Zubehör ins Klo zu spülen...

Das Warten hat leider nichts gebracht. Mittlerweile habe ich es mit einem Downgrade auf die 2.29.22 versucht. Leider keine Änderung. Bin ebenfalls kurz davor den ganzen Kram rauszuwerfen.
Anlernen kann ich die IP Geräte nach deren Werksreset, aber einstellen kann ich nichts. Keine Parameter verfügbar.
Wenn ich die CCU2 neu starte kommt hiermit sogar folgende Meldung beim Versuch den Aktor einzustellen:

Das Gerät mit der Seriennummer '00085709A3E924' vom Interface 'HmIP-RF' konnte nicht abgefragt werden!

Starte ich die CCU2 dann erneut neu ist der Aktor wieder verschwunden...

Weiteres Problem: Cloudmatic funktioniert nicht mehr. Erst gab es angeblich keine Verbindung mehr zur CCU2, dann dachte ich ich versuche es mit dem Löschen und neu Laden der Views, seitdem ist nichts mehr verfügbar. Ich kann auch keine Geräte mehr anzeigen.

Muss ich ein Werksreset der CCU2 machen und komplett von vorne starten, also auch die Geräte neu anlernen, die jetzt eigentlich noch funktionieren?

Verzweifelte Grüße...

Edit: Nach einem erneuten Update auf die 2.31.23 kann ich nur noch ein IP Gerät neu anlernen. Das zweite klappt nie. Nach einem Neustart der CCU2 sind beide Geräte wieder weg und ich kann eines der beiden wieder anlernen.



Hab jetzt auch mal eq3 geschrieben. Ich weiß nicht was ich noch machen soll.

Im logfile sehe ich einige Fehler. Z.B.:

Jan 15 21:08:11 de.eq3.cbcs.server.core.persistence.AbstractPersistency ERROR [vert.x-worker-thread-3] Could not do command: PERSISTENCE_COMMAND_ADD_DEVICE
com.esotericsoftware.kryo.KryoException: java.lang.ClassCastException: de.eq3.cbcs.server.core.persistence.PersistentDeviceLinkConfiguration cannot be cast to de.eq3.cbcs.devicemanagement.LinkPartner


Logfile im Anhang. Kann jemand was damit anfangen?

[NickHM]

Guten Abend

auf den eq-3 Server wird beim Anlernen nur zugegriffen, wenn Anlernen über Internet ausgewählt wurde.

Hast Du mal die lokale Methode probiert und die beiden Zahlen von beiliegenden Aufkleber eingetippt? Dann braucht die CCU2 den eq-3 Server nicht.

"normal" klingt das alles allerdings nicht