xxAPI² Loader

[NilsS]

Das war LEDIGLICH für TBBW ) bestimmt für jeden anderen ist die Konfiguration so wie dort genannt völlig falsch.

Empfohlene Konfiguration für alle die die Daten NICHT händisch von github kopieren wollen, sondern den Baustein verwenden möchten (Was ich eigentlich jedem raten würde).

EN[1]: mit IKO "xxAPI Update laden" verbinden und nur bei Bedarf triggern
EN[2]: gewünschtest Verzeichniss (xxapi oder xxapi2) wie auch immer
EN[3]: "master" (es sei denn: man hat auf die aktuellste git version geupdated und hat Probleme auf seiner produktiven Visu nach dem Update, dann sollte man den Hash der zuletzt funktionierenden git Version dort eintragen und den Fehler melden / ein Triggern von EN[1] ist danach nicht nötig / wenn der Fehler behoben ist wieder zurück auf "master")
EN[4]: AUF KEINEN FALL remanent=0 eintragen, das verhindert, das die geladene github version über einen Neustart des HS hinweg erhalten bleibt. Eigentlich muss hier nichts eingetragen werden
EN[5]: Den Namen der Designs dessen Bilder man mit in den appcache laden will (Dadurch wird der erste Start bei neuen Versionen oder Veränderungen am HS Projekt einmalig sehr lang, da alle Bilder geladen werden (so wie beim HSClient). Danach ist der Start und auch das laden der Seiten schneller da alle Bilder aus dem Cache kommen)

[NilsS]

knxhans
eigentlich hat sich da nichts geändert, im Gegenteil mit commit https://github.com/knxuf/xxAPI2/comm...c1a95ec6d1f1c7 habe ich ein preload auf der xxAPI-INIT Seite ermöglicht.

@all
Man kann die XXMODUL auf der INIT Seite bereits mit dem Namen registrieren (jeder Modulname ist ja eine Client Instanz die auch durch das Login muss) am besten läd man dort eine leere Seite in das Modul um nicht unnötige Dinge zu laden.

Als Beispiel wenn ihr das Modul mit Namen QTR habt, dann packt ihr auf die INIT Seite ein XXMODUL*QTR mit funktion Seite aufrufen -> leere Seite (nichtmal ein rücksprung ist nötig). Dadurch wird das Login bereits durchgeführt und beim anzeigen der eigentlichen Startseite auf der die Module aufgerufen werden muss nur die Seite (ohne Login) geladen werden.

[TirochH]

e

... . .

Empfohlene Konfiguration für alle die die Daten NICHT händisch von github kopieren wollen, sondern den Baustein verwenden möchten (Was ich eigentlich jedem raten würde).

EN[1]: mit IKO "xxAPI Update laden" verbinden und nur bei Bedarf triggern

Was ist das allererste Mal. wenn ich in App nur durch setzen von en1 triggere, muß das System -- wenn gar nichts da ist - irgendetwas machen um überhaupt laufen zu können.


Hans

[NilsS]

Also,

der Baustein ersetzt ja die xxAPI² im hsupload Ordner zu speichern und auf den HS hochzuladen.
Der Baustein an sich enthält nichts von der xxAPI sondern lediglich einen http Client, der sich mit github verbindet und von dort die unter EN[3] eingestellte branch/commit vom repo KNXUF/xxapi2 zu laden und im Homeserver unter /opt/(EN[2]) zum Abruf bereitzustellen.
Version < 0.17 konnten sich das heruntergeladene nicht merken und mussten so nach jedem Neustart neu mit der xxAPI befüllt werden.
Seit Version 0.17 muss nun nicht mehr bei jedem Start die xxAPI geladen werden, sondern die zuletzt geladene Version wird im Remanentspeicher des HS komprimiert gespeichert und nach dem Neustart des HS auch wieder unter /opt zur Verfügung gestellt.
Daher muss der Baustein natürlich einmalig (Infos dazu sind auch auf der Debugseite unter xxAPI2 einsehbar) befüllt werden.
Man kann nun den Baustein einfach so belassen und es wird sich von alleine nichts ändern. Wenn nun ein Update der xxAPI gewünscht ist, kann dieses über EN[1]=1 getriggert werden welches dann auch wieder im Homeserver gespeichert bleibt.

[knxhans]

NilsS Kannst du den 0.17 Baustein nochmal im Download einfügen lassen, dort ist noch die 0.16. Dein Link zur 0.17 geht leider immer noch nicht und lädt nur einen fetch.html. Oder einen Link zum Download bereit stellen? Danke dir!

[TirochH]

Also,

der Baustein ersetzt ja die xxAPI² im hsupload Ordner zu speichern und auf den HS hochzuladen.
....
Wenn nun ein Update der xxAPI gewünscht ist, kann dieses über EN[1]=1 getriggert werden welches dann auch wieder im Homeserver gespeichert bleibt.

Hab ich jetzt umgebaut, läuft jetzt schnell.

Gruß

Hans

[TBBW]

Nils, Hans

Found it......

Made the inputs as you stated.
no changes, then I realized...

I was making the wrong call

called http://1X2.1X8.2.2X0/opt/xxapi2/xstart.htm

in stead of:

http://1X2.1X8.2.2X0/opt/xxapi2/start.htm

everything is back to normal.

the settings you suggested, are those the standard settings for a stand alone operation.
So no upload from the git-hub?

Grusse,

Ger

[aNoThEr]

Leider finde ich die 0.17 nirgendwo zum download.

Könnte die bitte nochmal hochgelegen werden.

Vielen Dank!

[TirochH]

Leider finde ich die 0.17 nirgendwo zum download.

Könnte die bitte nochmal hochgelegen werden.

Vielen Dank!

[maxxmobile]

Hallo - 1.17 weiterhin im Einsatz - bei mir sind folgende Probleme noch aktuell, habe schon viel gelesen und getestet...
HS4.4
Die GUI funktioniert soweit nur im XXAPI Log sehe ich das der Download offensichtlich nicht funktioniert. Bleibt im Status "CREATE APPCACHE" hängen, neuerliche Auslösung durch 1 ändert den Status dann auf "DOWNLOAD COMMITS" ohne Änderung bis weiterer manuelle Auslösung durch 1 "Download Started" schließlich LogikError -> URLError: [urlopen error [Errno 110] Connection timed out]
hsav gh-pages

werde meine Firewall nocheinmal überprüfen, denke aber das es das nicht ist...

Bei der Nutzung der wichtigsten Teile keine Probleme, lediglich der Aufruf z.B. XXCLICK**XXEXECUTE*playVLC(?vlc?,?http://httpmedia.radiobremen.de/bremenvier.m3u?) funktioniert nicht mehr.

Und auch die USZU Popups sind bei mir unter xxapi2 noch nicht verfügbar....sollte das schon funktionieren?
Wie gesagt schon viel getestet, habe auch nocheinmal alles neu gemacht mit xxapi2, gleiches Ergebnis wie beschrieben...

Freue mich über Tipps...
Vielen Dank und super das die Entwicklung immer noch weiter geht

maxxmobile

[maxxmobile]

FYI Nils - zu XXAPI2 - war tatsächlich ein Firewall Thema - bezüglich reibungslosen parallel Betrieb xxapi2 und xxapi1 habe ich es jetzt auch über ein 2. hsupload Verzeichnis (hsav, hsav_mob) gelöst, da über ursprünglich primäres hsupload (hsav) Verzeichnis - jede Referenz auf start.htm immer die xstart.htm aufruft und ich so nicht mehr in die xxapi1 konnte, - wenn ich die start.htm auf start_mob.htm umbenannte funktionierte die xxapi1 nur manchmal, mit 2 "hsupload" Verzeichnissen, bis jetzt keine Probleme, werde weiter testen....eine Lösung betreffend USZU wäre auch cool...

Vielen Dank
maxxmobile

[sx3]

Hi guys,

I'm interested in trying to make a visu using the xxAPI, but I have no clue how to "install" it.
I think I have figured out that I have to download the logic node HSLZ file, but when I try to import it in HS Experte 4.4 I only get errors.
I have tried importing it in existing project, but also in new project. they are the same.

I tried to open the demo project, but it didn't look so good in experte, do I have to install something to make it look more like the actual visu page?
Or is like this it will look in experte, even though the logic node isnät installed.

[TirochH]

Also,

der Baustein ersetzt ja die xxAPI² im hsupload Ordner zu speichern und auf den HS hochzuladen.
.....
Seit Version 0.17 muss nun nicht mehr bei jedem Start die xxAPI geladen werden, sondern die zuletzt geladene Version wird im Remanentspeicher des HS komprimiert gespeichert und nach dem Neustart des HS auch wieder unter /opt zur Verfügung gestellt.
Daher muss der Baustein natürlich einmalig (Infos dazu sind auch auf der Debugseite unter xxAPI2 einsehbar) befüllt werden.
Man kann nun den Baustein einfach so belassen und es wird sich von alleine nichts ändern. Wenn nun ein Update der xxAPI gewünscht ist, kann dieses über EN[1]=1 getriggert werden welches dann auch wieder im Homeserver gespeichert bleibt.

Ich hab ne aktualisierte Version vom xxAPI Loader, die kannst du mal testen und Rückmeldung geben ob es damit besser ist. Die hatte ich noch nicht veröffentlicht, weil da ab und an Fehler beim Starten auftreten.

.......
Nochmals eine Zusammenfassung der festgestellten Probleme und die derzeitigen Umgehungslösungen:

Habe Baustein 12280 in Version 1.017 und 1.020.

Egel welcher Baustein im Einsatz: Änderungen im "custom.js" werden nicht durchgeführt.
Umgehungslösung: man ladet vorher im GIRA Experten die 12280er Version, die nicht geladen ist.
Das heißt: wenn im HS 1.017 enthalten --> dann 1.020 laden oder umgekehrt.

Nach dem Neuladen ist unbedingt vor Aufruf von ../xxapi/start.htm ein Aufruf von ../xxapi/xstart.htm durchzuführen.

Wenn nicht diese Reihenfolge eingehalten wird, läuft das System nicht.

Tritt nur dann auf wenn Änderungen in "custom.js" durchgeführt werde (richtig formuliert: ist nur dann Problem).

Problem ist nicht am Client, Sondern beim Homeserver. Problem tritt immer auf allen Clients auf. Wenn behoben dann bei keinen CLIENT.

Problem ist ziemlich lästig .........

Hans

Da das Problem doch ziemlich stört habe ich als "Interimlösung" einen neuen Baustein 12280 gebastelt der das Problem weitgehend umschifft.

Das einzige nach Neueinsatz einer geänderten "custom.js": unbedingt .../xxapi/xstart.htm vor ../xxapi/start.htm aufrufen.

Bei keiner geänderten "custom.js" läuft meine "Interimslösung" ohne Einschränkungen.

Wenn nämlich Baustein 12280 V1.020 im Einsatz ist, ist ../xxapi/start.htm nicht möglich.

Beiliegend der adaptierte Baustein 12280.

Hans

Nochmals die Probleme zusammengefasst. Treten nur nach Änderungen in der "custom.js" auf.

Hans

[TirochH]

Nochmals die Probleme zusammengefasst. Treten nur nach Änderungen in der "custom.js" auf.

Hans

Siehe auch neuestes Posting unter https://knx-user-forum.de/forum/play...56#post1086856

[TirochH]

Fehlerursache gefunden:

Beschreibung des Problems:

Update der Programmierlogik in der Datei "custom.js" wird beim Übertragen des Homeserver-Experten nicht durchgeführt.

Ursache des Problems:

Homeserver Experte führt Update nur durch, wenn Änderung in der Logik des Experten durchgeführt wird.
Dazu gehört auch die Änderung von Kommentaren, Einspielen von Logikbausteinen, usw.
Nicht dazu gehört die Änderung in der custom.js Datei.
Und das ist die eigentliche Ursache des Problems.

Behebung des Problems:

Änderung in der Logik des HS-Experten. Könnte auch die minimalste Änderung in einen Dummy-Baustein sein bzw. Einspielen von Logikbausteinen.
Ob eine Behebung via des Logikbausteins 12280_xxAPI²_Loader.hslz möglich ist wird geprüft.

Also bei Änderungen die nur in der "custon.js" durchgeführt werden, Minimallogik im Experten ändern sodaß Änderung vom Homeserver erkannt wird.

Hans