xyzaxyz
commented
4 years ago Eventuell liegt es an dem CharStream/StreamReader Verbund? UTF-8 klingt ja erst mal gut und korrekt...
Aus src\main\java\net\b07z\sepia\server\core\tools\Connectors.java
Closed xyzaxyz closed 4 years ago
xyzaxyz
commented
4 years ago Eventuell liegt es an dem CharStream/StreamReader Verbund? UTF-8 klingt ja erst mal gut und korrekt...
Aus src\main\java\net\b07z\sepia\server\core\tools\Connectors.java
sepia-assistant
commented
4 years ago Hi :-)
Über den Stolperstein, dass mein am FHEM-Server befindliches mit eigener CA gesignetes Zertifikat nicht im Truststore der JVM war, bin ich mit folgenden Commands schon selbstständig gekommen
Ah wie nervig, das Problem hatte ich in ähnlicher Weise auch mal mit dem lokal installierten Java (~/SEPIA/java). Ist das Zertifikat im systemweiten Store? Falls ja sollte das package ca-certificates-java eigentlich dafür sorgen, dass es in den Java Truststore kopiert wird.
sepia-assist-server/log.out zeigt folgende Fehlermeldung: [...] Das darüber geloggte JSON zeigt in VS Code eingefügt etliche invalide Stellen, man sieht, dass Umlaute falsch dargestellt werden:
Ich muss mir das Morgen mal genauer angucken aber es KÖNNTE sein, dass die Umlaute lediglich ein Problem der log.out sind (die ist nicht zwangsläufig UTF-8 kodiert, wobei das unter Linux komisch wäre) und der Fehler woanders herkommt. Selber hatte ich mit FHEM bisher keine Probleme mit Umlauten, egal auf welchem System (RPi, Windows, Debian, etc.), vielleicht stört ihn ein anderes Zeichen. Gibt es noch mehr Infos im Stack-Trace die den genauen Ort des Fehlers angeben? (manchmal steht da was von 'invalid token at ...').
Könntest du mal versuchen den JSON-String in UTF-8 umzuwandeln und dann im Browser zu parsen mit JSON.parse(...) oder vielleicht den ganzen Teil aus der log.out hier posten, falls möglich?
xyzaxyz
commented
4 years ago Hey,
Danke für die schnelle Rückmeldung!
Zu den Zertifikaten: Ich habe die genauen Commands nicht mehr da, die habe ich, weil sie nicht das gewünschte Ergebnis gebracht haben, aus meinen Notizen entfernt und nur die oben beschriebene Methode bei mir vermerkt - so umständlich ist es ja nicht :)
Die log.out hat bei mir im Urzustand (habe sie heute vor dem Start der SEPIA-Dienste noch mal komplett gelöscht, damit alte Outputs entfernt werden) das UTF-8 Format:
Ja, meine FHEM-Instanz hat ein evtl. etwas ungewöhnliches Setup, da habe ich aber jede Stelle in der Infrastruktur überprüft, durch die manuellen Calls auf den Endpunkt via Chrome und auch via Postman habe ich allerdings Umlaute und alle JSON-Steuerzeichen korrekt wiedergegeben bekommen, bezweifle somit dass es am Webserver liegt.
Die FHEM-Instanz liegt bei mir in einem Docker-Container, mittels eines nginx-reverse-proxy aus einem anderen Container wird hierdurch die Domäne "home.vx" angelegt - die Container laufen auf einer virtuellen Debian Maschine auf einem ESXi Host. Aber wie gesagt, da manuelle Calls ein valides JSON liefern, bezweifle ich, dass die Infrastruktur schuld ist.
Mein FHEM ist dafür schon sehr alt und gewachsen, weiß nicht ob das Volumen aus dem jsonlist2-Call etwas ausmacht. Das resultierende JSON auf der log.out ist 15773 Zeilen lang mit einer totalResultsReturned von 370.
Aber auch hier wieder - im manuellen Call kommt ein valides JSON raus.
Das JSON lässt sich in der DevTools-Konsole des Browsers nicht parsen - das aus manuellen Calls schon:
Die komplette log.out würde ich ungern teilen, es fällt mir schwer, den Überblick zu behalten, was da alles privates drin steckt. Da ich aber recht fit mit JSON bin, würde ich den Großteil (valide Array-Objekte) aus dem Array entfernen und ein paar valide und invalide Kandidaten in ein manipuliertes Output-Array für das Issue hier einstellen:
Noch kurz zur Frage mit dem StackTrace:
Da gibt es leider keinen - muss ich irgendwo ein verbose-Flag setzen, um das LogLevel zu erhöhen?
Hier der Beginn und das Ende des Loggings auf dem getDevices-Event:
Danke Dir soweit! 🚀
sepia-assistant
commented
4 years ago Ja, meine FHEM-Instanz hat ein evtl. etwas ungewöhnliches Setup, da habe ich aber jede Stelle in der Infrastruktur überprüft, durch die manuellen Calls auf den Endpunkt via Chrome und auch via Postman habe ich allerdings Umlaute und alle JSON-Steuerzeichen korrekt wiedergegeben bekommen, bezweifle somit dass es am Webserver liegt.
Ich glaube eigentlich auch nicht, dass die Kodierung irgendwo auf dem Weg kaputt geht, aus den Gründen die du ja schon genannt hast und weil eh alles Linux ist :thinking:
Die komplette log.out würde ich ungern teilen, es fällt mir schwer, den Überblick zu behalten, was da alles privates drin steckt.
Verstehe ich.
Teile des JSON-Ergebnisses (Suche nach Frühlingsblüten bzw 'hlingsbl' und im ersten Objekt das Property TYPE) - VS Code visualisiert den Fehler schön
Das ist wirklich ziemlich verwirrend, wie kann denn ein Anführungszeichen verschwinden :confused: :stuck_out_tongue_closed_eyes:
Wie sieht diese Stelle im korrekten JSON aus? "TYPE": 1" ?
Gibt es noch mehr Stellen die man genau ausmachen kann? Z.B. wenn du diese Stelle entfernst und dann guckst wo der nächste Fehler auftritt?
Da gibt es leider keinen - muss ich irgendwo ein verbose-Flag setzen, um das LogLevel zu erhöhen?
Wenn nichts angezeigt wird gibt es wohl leider keine zusätzlichen Infos, schade aber zu erwarten ^^.
Kannst du bei Gelegenheit vielleicht auch mal testen, ob der FHEM Demo der neusten FHEM Version bei dir ohne Probleme läuft?
xyzaxyz
commented
4 years ago Ich glaube eigentlich auch nicht, dass die Kodierung irgendwo auf dem Weg kaputt geht, aus den Gründen die du ja schon genannt hast und weil eh alles Linux ist 🤔
Sollte sie nicht 😄 da kam mir das mit dem Chunk-weisen lesen/schreiben ins Auge, bin damit nicht so erfahren, aber es gibt ja Leute die SEPIA bereits erfolgreich an FHEM anbinden konnten, insofern sollte das Problem eigentlich nicht wirklich in der Methode liegen.
Das ist wirklich ziemlich verwirrend, wie kann denn ein Anführungszeichen verschwinden 😕 😝
Da steh ich auch auf dem Schlauch ^^ irgendwas läuft sich doch da über die eigenen Füße...
Wie sieht diese Stelle im korrekten JSON aus?
"TYPE": 1"?
Du wirst lachen, ich bin auch sehr verwirrt: Da wird eine ganze Zeile geschluckt, der Wert "1" gehört zu dem nächsten Property chanNo, dessen Name gar nicht im invaliden JSON erscheint (und dort ist der Wert 01):
Wenn nichts angezeigt wird gibt es wohl leider keine zusätzlichen Infos, schade aber zu erwarten ^^.
Hmm, jo, schade :| Aber wie der log sagt, der Fehler tritt beim Parsen auf - weil das JSON invalide ist :/
Kannst du bei Gelegenheit vielleicht auch mal testen, ob der FHEM Demo der neusten FHEM Version bei dir ohne Probleme läuft?
Gern! Kannst du mir eine kleine Richtungsweisung geben? Ich nutze FHEM in Docker, https://hub.docker.com/r/fhem/fhem/tags - Demo gibt es als solches nicht zur Auswahl.
Ich habe tatsächlich schon länger nicht das neueste Image gezogen sondern nur innerhalb FHEM die Updates gefahren. Da die Dockerfile ellenlang ist mit lauter Dependencies die ich fürs Home brauche, dauert der Build entsprechend lang - da ich das bisher manuell mache, hab ich perfekt prokrastiniert ^^ aber es ist ja Freitag 🤣
xyzaxyz
commented
4 years ago Eine der nachfolgenden invaliden Stellen ist zB bei meinem FHEM Device CALVIEW, das Kalenderdaten parst:
{ "Value":"0", " fehlt also komplett, in dem Schnipsel
xyzaxyz
commented
4 years ago Ich habe meine FHEM-Instanz mal auf dem neuesten Image von fhem/fhem-amd64_linux aufgezogen, das Fehlerbild ist leider ähnlich wie zuvor: Es werden Bestandteile des JSONs 'vergessen':
sepia-assistant
commented
4 years ago Gern! Kannst du mir eine kleine Richtungsweisung geben? Ich nutze FHEM in Docker, https://hub.docker.com/r/fhem/fhem/tags - Demo gibt es als solches nicht zur Auswahl.
Ich nutze zum Testen immer die Version von hier: https://fhem.de/#Download
Da gibt es eine demo config, die man mit perl fhem.pl fhem.cfg.demo starten kann. Könnte mir vorstellen, dass es die auch im Docker Container gibt :thinking:
Du wirst lachen, ich bin auch sehr verwirrt: Da wird eine ganze Zeile geschluckt, der Wert "1" gehört zu dem nächsten Property chanNo, dessen Name gar nicht im invaliden JSON erscheint (und dort ist der Wert 01)
Interessant :sweat_smile: :see_no_evil: Diese Fehler sind so unsystematisch, dass ich glaube es kommt nicht von Problemen mit der Kodierung sondern von irgendwelchen "unsichtbaren" Bytes in dem Objekt (Steuerungsbytes, Line-Break, Tab, etc.). Warum der Postman- und VSCode-Parser damit klar kommen, der in JAVA aber nicht bleibt dabei erstmal ungeklärt, so wie die Frage warum die überhaupt da drin sein sollten. Letzteres kann aber durchaus schon mal vorkommen wenn die Daten per Input Feld eingegeben wurden oder irgendwie komisch importiert.
Um diese Theorie zu bestätigen oder zu widerlegen hilft uns leider der Output des Loggers nicht, denn der hat die Bytes ja offensichtlich schon verschluckt. Könntest du eventuell ein betroffenes Element getrennt über die FHEM API abrufen und via wget oder curl direkt in eine Datei schreiben lassen?
Ich experimentiere mal etwas mit dem Parser so lange.
xyzaxyz
commented
4 years ago Huiui, also mit curl komme ich zu einem ähnlichen Ergebnis.
curl -k -X GET -H 'Authorization: Basic BLUB64==' "https://home.vx/fhem?cmd=jsonlist2%20Bad_FensterSensor&XHR=1" >> 1.json
curl -k -X GET -H 'Authorization: Basic BLUB64==' "https://home.vx/fhem?cmd=jsonlist2&XHR=1" >> 2.jsonSind allerdings immer ähnliche Stellen/Devices an denen es kracht, nicht allzu willkürlich.
Besagter Fenstersensor, den ich alleine abgefragt und in 1.json geloggt habe, hat allerdings keine Fehler 🤒
sepia-assistant
commented
4 years ago Huch, habe ich das jetzt richtig verstanden, das selbe Item macht in der Gesamtliste Probleme aber in der einzelnen Abfrage nicht? :astonished:
xyzaxyz
commented
4 years ago Exakt... Super strange bisher 😣 Ich analysiere jetzt doch noch mal die Infrastruktur. Bekomme gzip am Webserver leider grad nicht deaktiviert, da ich das ein bisschen verdächtige - das komprimiert ja, sobald ein Response lohnenswert groß ist - wundert mich aber auch in dem Fall, dass manche Clients dann erfolgreich die Ressource abrufen können.
Leider taucht mein curl-Request nicht im Fiddler auf, sonst könnte man schöner vergleichen... Evtl fehlt ja auch ein gewisser Request-Header wie "Accept" oder ähnliches, allerdings würde dann ja auch der Postman-Call krachen...
xyzaxyz
commented
4 years ago Und das andere abartige Gerät, das CALVIEW, in dem der Müllabfuhrplan drin steht, das auch jedes mal in der Gesamtübersicht kracht, geht als einzelner curl-body auch super klar - private Daten geschwärzt:
curl -k -X GET -H 'Authorization: Basic B64==' "https://home.vx/fhem?cmd=jsonlist2%20CalViewKalenderNuernbergAbfall&XHR=1" > 4.json
sepia-assistant
commented
4 years ago GZIP habe ich auch gerade auf dem Schirm :male_detective: Postman ist irgendwie immer super tolerant, ich glaube der macht intern diverse Fehlerkorrekturen.
Kannst du CURL mal mit dem gzip Header nutzen: curl -H "Accept-Encoding: gzip" ...
xyzaxyz
commented
4 years ago Öhhh...
curl -k -X GET -H "Accept-Encoding: gzip" -H 'Authorization: Basic ASD==' "https://home.vx/fhem?cmd=jsonlist2" > 5.json
sepia-assistant
commented
4 years ago uups :sweat_smile: ... das sind scheinbar die komprimierten Daten, bin mir gerade nicht sicher wie man das richtig nutzt :see_no_evil:
xyzaxyz
commented
4 years ago Sorry, ich hab &XHR=1 vergessen, aber auch dann tuts nicht.. :|
curl -k -X GET -H "Accept-Encoding: gzip" -H 'Authorization: Basic asd==' "https://home.vx/fhem?cmd=jsonlist2&XHR=1" > 7.json
verdächtig klein:
xyzaxyz
commented
4 years ago Alles gut, solang wir beide was lernen und Spaß haben ^^
sepia-assistant
commented
4 years ago Man munkelt so müsste es automatisch GZIP anfordern und decompressen: curl --compressed http://example.com
xyzaxyz
commented
4 years ago Ooh: mit --compressed kommt ein absolut valides JSON mit Umlauten 😍
curl -k -X GET --compressed -H 'Authorization: Basic Asd==' "https://home.vx/fhem?cmd=jsonlist2&XHR=1" > 8.json
sepia-assistant
commented
4 years ago :dart: :sunglasses: ... jetzt muss ich nur noch rausfinden was ich in Java daraus mache :grin:
[EDIT] abgesehen davon scheint mir das aber doch ein genereller FHEM Bug zu sein
xyzaxyz
commented
4 years ago Hehe, ja, das dachte ich mir leider auch am Ende... Jetzt stehen wir ungefähr am Anfang, haben aber bisschen was gesehen :D Kann ich irgendwie unterstützen, gewisse Java Snippets ausführen? Meld dich jederzeit, gib mir Aufgaben ^^
[EDIT] abgesehen davon scheint mir das aber doch ein genereller FHEM Bug zu sein
Hmm, oder halt doch was mit meinem System, idk :| Bei vielen anderen gehts ja wunderbar, weiß nur nicht ob das dann so ein verschachteltes Etwas wie bei mir ist, oder direkt mit nem apache/nginx auf dem RPi läuft..
sepia-assistant
commented
4 years ago Hmm, oder halt doch was mit meinem System
Vielleicht doch weder System noch FHEM, sondern ich muss in JAVA den Response Header auslesen und irgendwie darauf reagieren :thinking:
Ich vermute bisher ist das nie aufgetreten, weil die meisten Leute nicht so viele Daten haben ^^ [EDIT] Bleibt die Frage warum er nicht konsequent die gleichen Fehler ausspuckt
xyzaxyz
commented
4 years ago Klingt plausibel - dann aber trotzdem komisch, dass es nur an den bestimmten Stellen oben im ganzen Array bricht :/
sepia-assistant
commented
4 years ago Ja irgendwie komisch. Ich muss ja dann beim Request explizit sagen, dass ich "Gzip" will sonst geht es nicht und das kann ich nicht einfach allgemein annehmen. Offensichtlich ist die Antwort ohne "GZIP" im Request Header ja nicht komprimiert sondern einfach nur kaputt :-| ... Postman rafft es aber irgendwie ...
[EDIT] Kannst du in Postman sehen ob der GZIP Header automatisch gesetzt wurde?
xyzaxyz
commented
4 years ago Postman zeigt folgende Request Header - über Fiddler gelauscht:
Bei Chrome sind es folgende Header:
xyzaxyz
commented
4 years ago Curl kann ich nun auch belauschen, da muss man mit -x 127.0.0.1:8888 den Request durch Fiddler proxyen:
Ohne --compressed - invalid wie wir es kennen
Mit --compressed - valides JSON:
sepia-assistant
commented
4 years ago Ok das erklärt scheinbar warum der Fehler im Browser und in Postman nicht auftritt :+1: Ich verstehe zwar immer noch nicht warum das Ergebnis ohne expliziten GZIP Request Header kaputt ist aber eventuell ergibt sich wenigstens ein Weg den Fehler zu unterdrücken ^^.
Kannst du mal CURL machen mit dem Header -H "Accept-Encoding: identity" in der Hoffnung dass GZIP dann deaktiviert ist und vielleicht auch der Fehler ^^
xyzaxyz
commented
4 years ago Mit der gunzip Pipe erhalte ich durch manuelles setzen des Accept-Encoding auch wieder valides JSON.
curl -k -X GET -H 'Accept-Encoding: gzip' -H 'Authorization: Basic ...==' "https://home.vx/fhem?cmd=jsonlist2&XHR=1" | gunzip - > 16.json
xyzaxyz
commented
4 years ago Leider wieder das Ergebnis, wie ohne Header:
curl -k -X GET -H 'Accept-Encoding: identity' -H 'Authorization: Basic ...==' "https://home.vx/fhem?cmd=jsonlist2&XHR=1" > 17.json
Allerdings sendet der Server keinen gzip Header mehr und der Content-Type ist anders:
Vorher
Nachher
sepia-assistant
commented
4 years ago Ah vielleicht muss man noch explizit content-type "application/json" anfordern?
xyzaxyz
commented
4 years ago curl -x 127.0.0.1:8888 -k -X GET -H "Accept-Encoding: identity" -H 'Accept: application/json' -H 'Authorization: Basic ==' "https://home.vx/fhem?cmd=jsonlist2&XHR=1" > 19.json
Leider nicht :/
JSON kommt, aber kein valides 😢
sepia-assistant
commented
4 years ago Schade, wäre ja auch zu schön gewesen ^^. Ich guck mal ob ich das Problem reproduzieren kann bei mir mit FHEM und nem Proxy der GZIP unterstützt. Falls nicht teste ich mal was passiert wenn ich generell GZIP als accepted encoding einbaue in die Java Klasse. Ist vielleicht eh ganz nützlich :grin:
[EDIT] Bleibt die Frage an welcher Stelle jetzt eigentlich das JSON kaputt geht.
xyzaxyz
commented
4 years ago Man muss probieren ^^ Cool, ich danke Dir schon jetzt vielmals! Wie gesagt, wenn ich lokal was nachstellen kann - melde dich, ich kann gern Java Snippets ausführen und bisschen mit debuggen und testen 😸 Sicher nicht verkehrt, wenns drin ist :D
xyzaxyz
commented
4 years ago Hab mal bisschen an der httpGet aus https://github.com/SEPIA-Framework/sepia-core-tools-java/blob/557cc037514a14ce262990486d619bd37d05f65f/src/main/java/net/b07z/sepia/server/core/tools/Connectors.java#L322-L380 rumgeschnipselt, bei mir kommt der content schon verkehrt wie zuvor, also muss es beim Call irgendwo auftreten:
xyzaxyz
commented
4 years ago Ich hab eine vermeintlich nicht weiter invasive, absolut funktionierende Möglichkeit gefunden 😍
Ich habe es nicht gegen einen nicht-gzip Server getestet - was ich gesehen habe war aber wie in unserem Verlauf der curl-Requests:
Der Server schickt den Header Content-Encoding nur mit, wenn man ihn mittels Request-Header Accept-Encoding: gzip anfordert - andernfalls erhalte ich das immer wieder gesehene invalide JSON.
Es wäre zu prüfen, um bestehende Funktionen nicht einzuschränken/Bugs zu produzieren, ob beim Call gegen einen nicht-gzip Server der Header eben nicht kommt und in dem unten gezeigten Code dann dementsprechend der Weg ohne GZIPInputStream eingeschlagen wird.
sepia-assistant
commented
4 years ago Ich teste gerade eine ähnliche Anpassung :grin: , der request header würde allerdings vorläufig in der Fhem.java Klasse landen, da ich nicht weiß wie viel Auswirkungen es hat auf alle anderen Klassen die den selben Call nutzen ^^
String content = getStreamContentAsString(con, con.getInputStream());
JSONObject result = build(content, success_str);
return result;Und weiter unten die neuen Funktionen:
private static boolean isGzipResponse(HttpURLConnection con){
String encodingHeader = con.getHeaderField("Content-Encoding");
return (encodingHeader != null && encodingHeader.toLowerCase().contains("gzip"));
}
private static String getStreamContentAsString(HttpURLConnection con, InputStream is) throws IOException{
if (isGzipResponse(con)){
InputStreamReader isr = new InputStreamReader(new GZIPInputStream(is), Charsets.UTF_8);
return CharStreams.toString(isr);
}else{
InputStreamReader isr = new InputStreamReader(is, Charsets.UTF_8);
return CharStreams.toString(isr);
}
}[EDIT] Ich versuche gleich eine komplette Test-Version zu bauen. Allerdings basiert die dann auf dem Dev Branch ... da könntest du gleich noch mehr neue Funktionen für FHEM testen ^^
[EDIT 2] Es wäre auf jeden Fall spannend zu sehen, wie die sich verhalten bei deiner großen Menge an Items :-)
xyzaxyz
commented
4 years ago Ach, der Austausch hier mit Dir ist besser als Weihnachten 🏆😄 Wie geil!
Auf jeden Fall sinnvoll, das so vorsichtig wie möglich einzubinden, ich sehe, du weißt auf jeden Fall gut, wo du hinzugreifen hast :)
Scheint so als wäre das fast schon am Weg auf den dev-Branch ^-^ Gern teste ich gleich neue Features! :) Ich muss mir allerdings auch allgemein erst mal noch einen Überblick verschaffen - ich guck mir das System immer erst an, binde vllt ein Licht an und nach und nach zieht es sich auf, da werden dann im Laufe auch viel die docs gecrawled :3 Aber sehr gern test ich die mit! 😄
Musst mich dann instruieren, wenn es soweit ist, wie ich den Codestand vom dev-Branch auf meinem RPi4-Setup ausführbar mache (Kein Docker, da hast du leider kein arm-image für den Pi (Nur für linux/amd64 unter https://hub.docker.com/r/sepia/home/tags) - Früher oder später wird das aber eh auf eine potentere Maschine bei mir wandern, zumindest das Brain - schöne verteilte Softwarearchitektur 😄 ❤️
EDIT: Wie manchen log.out's von mir schon zu entnehmen war, hab ich momentan noch Snips angebunden - das hat lange ganz ok seinen Dienst getan, da aber das Ende von Snips für die Maker-Welt eingetreten ist, suche ich nach einer guten Alternative - da soll dann auf jeden Fall in jedem Raum ein Smart-Speaker/Satellit für das Voice-System sein 👍
sepia-assistant
commented
4 years ago Haha ja das war ne spaßige und effektive Session, danke auch für die schnellen Infos und Tests :sunglasses: :+1:
Die Änderungen sind im Dev-Branch und ich baue gerade eine Test-Version. Mit meinem normalen FHEM (ohne Gzip) läuft es wie immer und mit meinem Gzip Test-Setup auch, allerdings hab ich da ein komisches Problem, ich kann immer nur einen erfolgreichen Call machen gefolgt von einem mit Timeout oO. Ich denke das liegt an meinem hastig zusammengebauten Nginx GZIP Proxy :sweat_smile: aber das sehen wir dann hoffentlich bei deinem Test ^^.
Musst mich dann instruieren, wenn es soweit ist, wie ich den Codestand vom dev-Branch auf meinem RPi4-Setup ausführbar mache
Theoretisch ist der build Prozess super einfach: mini doc ... allerdings hab ich das Script noch nicht auf einem RPi4 getestet.
Damit es schneller geht schicke ich gleich nen Download Link :-)
EDIT: Wie manchen log.out's von mir schon zu entnehmen war, hab ich momentan noch Snips angebunden - das hat lange ganz ok seinen Dienst getan, da aber das Ende von Snips für die Maker-Welt eingetreten ist, suche ich nach einer guten Alternative - da soll dann auf jeden Fall in jedem Raum ein Smart-Speaker/Satellit für das Voice-System sein +1
Das mit den Smart-Speaker/Satellit Geräten klappt schon ganz gut :-) Die Snips Leute scheinen viel mit MQTT zu machen, da erweitere ich gerade noch die Funktionen ^^. Schade eigentlich, dass die so einen harten Schnitt gemacht haben.
sepia-assistant
commented
4 years ago So, hier die Test-Version: SEPIA-Home v2.5.0 alpha01.
Ich empfehle den alten Ordner ~/SEPIA umzubenennen und dann die neue Zip einfach nach ~/SEPIA zu entpacken. Danach noch einmal setup.sh und einen neuen User anlegen. Alternativ ein Backup erstellen aus dem aktuellen SEPIA Ordner raus (backup-sepia.sh) und dann die Backup ZIP in den neuen Ordner entpacken dann sparst du dir das Setup ;-)
Achtung: diese Version ist ziemlich ungetestet =)
xyzaxyz
commented
4 years ago Hey, ja, bei dem schnellen Zyklus macht es echt Spaß ^^
Ich hab die Version ausprobiert:
backup-sepia.sh ausgeführtrestart-sepia.shLeider gibt es dieses mal gar keine Logs in der sepia-assist-server/log.out:
Log file - first entry officially left blank ;-)Ich hab den assist-server mal abgeschossen und manuell gestartet, weiß nicht ob dieser Test was bringt:
java -jar -Xms200m -Xmx200m ~/SEPIA/sepia-assist-server/sepia-assist-v2.4.2.jar
xyzaxyz
commented
4 years ago Innerhalb loadSettings.. ich mach mal ein blankes Setup anstatt über das eingespielte Backup
sepia-assistant
commented
4 years ago Hm komisch :sweat_smile: . ja sieht so aus als wäre irgendwas mit den .properties files aus dem Backup nicht ok. Vielleicht wurden die beim Entpacken des Backups nicht überschrieben?
xyzaxyz
commented
4 years ago Sollte größtenteils gepasst haben, oder? Settings waren zumindest die mir bekannten weiterhin drin:
sepia-assistant
commented
4 years ago Wenn die Daten da sind müsste der Rest eigentlich auch da sein, ja :thinking:
Ich hatte die Version einmal frisch auf meinem Windows PC getestet, da gingen zumindest die Basics ... vielleicht ist aber irgendwo anders der Wurm drin.
xyzaxyz
commented
4 years ago Scheinbar hat das mit dem Backup nicht ganz geklappt, jo.. das können wir gesondert mal betrachten...
Es hat funktioniert, yeey!! 🚀 Tausend Dank bis hierhin! Jetzt muss ich erst mal bisschen damit rumspielen ^^ Wir hören uns noch! :)
sepia-assistant
commented
4 years ago Sehr gut :+1: dann schon mal viel Erfolg beim Rumspielen :-D Was mich bei deiner Konfiguration vor allem interessieren würde ist wie das ganze performed bei so vielen Geräten :-) cu und schönen Abend noch ;-)
xyzaxyz
commented
4 years ago Genau, das werden wir mal beobachten, ich berichte bald 👍 Danke, dir auch noch einen schönen Abend! 😄
fquirin
commented
4 years ago Die GZIP Änderungen und weiter Fixes sind nun online :-)
Hi Florian, danke für ein bislang sehr vielversprechend aussehendes, gut strukturiertes System.
Ich baue das ganze gerade auf einem RPi4 lokal nach und möchte es an meine FHEM Instanz anbinden.
Über den Stolperstein, dass mein am FHEM-Server befindliches mit eigener CA gesignetes Zertifikat nicht im Truststore der JVM war, bin ich mit folgenden Commands schon selbstständig gekommen -evtl gibts hier aber auch die Möglichkeit für ein ignore-flag, allerdings tun mir die 2 Commands nicht weiter weh:
SEPIA client and server versions
sepia-assist-v2.4.1&sepia-core-tools-v2.2.5To Reproduce Leider nun ein Problem, das ich glaube ich nicht selbst fixen oder umgehen kann: Nach der Registration von Sepia an FHEM hole ich die Geräteliste über die UI:
Screenshot
sepia-assist-server/log.outzeigt folgende Fehlermeldung:2020-03-19 18:51:47 ERROR - FHEM - getDevices FAILED with msg.: {"code":"500","error":"result could not be parsed","HTTP_REST_SUCCESS":false}Das darüber geloggte JSON zeigt in VS Code eingefügt etliche invalide Stellen, man sieht, dass Umlaute falsch dargestellt werden:
Screenshot
Andere Stellen bringe ich nicht mit dem Encoding in Verbindung, verstehe es aber einfach nicht, warum plötzlich mitten im JSON wichtige Steuerzeichen fehlen würden.
Screenshot
Manuelle Aufrufe, selbst ohne Content-Type Header via Postman abgesendet, bilden alle ein valides JSON ab.
Screenshot
Expected behavior Ich würde erwarten, dass
public Map<String, SmartHomeDevice> getDevices()beim Aufruf vonJSONObject result = httpGET(url);ein valides, parsbares JSON-Array erhält, identisch zur Response, wenn ich "zu Fuß" im Browser oder via Postman den selben Endpunkt von FHEM aufrufe ( https://home.vx/fhem?cmd=jsonlist2&XHR=1 )