Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Mic]

Hi @BBTown

seltsam, hab grad noch mal die Github-Version getestet und geht bei mir:

[BBTown]

Ich habe den Link im ersten Betrag heruntergeladen, damit gieht es nciht.
Die Version von gestern/vorgestern lief problemlos ... ich werde sie noch einmal direkt von Github holen

[Glasfaser]

@BBTown sagte in Test: Adapter Log Parser v0.x.x GitHub:

Ich habe den Link im ersten Betrag heruntergeladen,

Wo ist der denn ??

[Mic]

@BBTown
Würde mich auch interessieren...

Am besten so herunterladen:

[BBTown]

@Mic @Glasfaser
sorry, da habe ich mich blöd ausgedrückt.
Im ersten Beitrag ist bie der VIS der Link "Hier die Beschreibung" und dort im ersten Absatz ist ein Link den ich per rechten Mausklick und "Ziel speichern unter ..." heruntergeladen habe.

[Glasfaser]

@BBTown

Das ist nur ein Link .... keine Zip Datei !!!

@Mic
Stimmt ... im ersten Augenblick denkt man, das soll man runterladen !

[BBTown]

@Glasfaser Das Downloadergebnis ist eine Zip-Datei ... wohl nur ohne den korrekten Inhalt
@Mic der Import direkt von der Github-Version hat dann auch auf anhieb geklappt ...

[Glasfaser]

@BBTown

ja ... weil das ende mit .zip ist
Ich denke mal @Mic wird das ändern ....

[BBTown]

@Glasfaser auch der Dateiname entspricht dem erwarteten ;-)

Danke euch für Tipp in die richtige Richtung!! :+1:

[Glasfaser]

@BBTown sagte in Test: Adapter Log Parser v0.x.x GitHub:

Danke euch für Tipp in die richtige Richtung!!

Ich denke mal eher von dir ... kann jedem passieren :+1:

Ahh .. eine zip Datei ...ich lade die mal runter :sunglasses:

[Mic]

@BBTown @Glasfaser

Danke euch beiden, echt verwirrend.
Hab gerade einen Direktlink bei Github hinterlegt, aber Github verweist dann immer auf die Download-Seite statt die zip. Werde das in der Doku ändern, ein Link mit .zip impliziert ja wirklich, dass das die Datei sein muss :-)

[Glasfaser]

@BBTown

Das waren die versteckten Ostereier :sunglasses:
Sehr gut gemacht :joy:

[BBTown]

@Glasfaser @Mic
Man kann ja auch nicht auf jede bekloppte Idee, jene welche eine Anwender hat, im Voraus selbst kommen :blush:

[BBTown]

@Mic
Mir ist gerade aufgefallen, dass ich folgende "warn"-Meldungen nach dem Löschen von Logs über die von dir zur Verfügung gestellte VIS erhalte.

logparser.0	2020-04-13 15:39:43.848	warn	(4090) This value will not be set in future versions. Please report this to the developer.
logparser.0	2020-04-13 15:39:43.847	warn	(4090) State value to set is invalid for logparser.0.visualization.table0.emptyJson: The state is missing the required property val!

Anmerkung: Ich habe die Beta v3.0.7 des js-controllers im Einsatz, falls relevant

[Mic]

@BBTown

Danke fürs berichten. Hatte eigentlich schon korrigiert, aber noch einen Datenpunkt vergessen. Ist jetzt aktualisiert auf Github.

[BBTown]

@Mic es wird allerdings nach wie vor die v0.46 nach der aktualisierten Installation angezeigt?!

[Mic]

@BBTown

Ist bereits auf Github, aber ohne Versionsanpassung.

Man soll als Adapter-Entwickler wohl nicht jede "Kleinigkeit" hoch-versionieren, schon mehrfach gelesen, zuletzt hier:

@e-s sagte in Vorschlag zu: "Richtlinien für Kategorie Tester":

Für jeden push ein versionsupdate finde ich besonders am Anfang sehr ungünstig.
Lieber wirklich dann wenn eine Funktion so läuft wie gewünscht.

Das ist leider als Anwender verwirrend, für mich selbst als Anwender von anderen Adaptern auch.
Ich würde mir wünschen, jeder Push (also jedes Update auf Github) muss in der Version ersichtlich sein, außer vielleicht Tippfehler (editorial changes), Doku-Anpassungen, leichte optische Anpassungen im ioBroker Admin.
Aber ich arbeite erst seit kurzem an der Adapter-Entwicklung, daher halte ich mich noch mit Änderungsvorschlägen etwas zurück und sammle noch etwas Erfahrung :sunglasses:
So richtig vorgegeben per Regeln ist das ganze auch noch nicht, aber wäre wohl gut. Ich bleibe da dran. (die Regel ist aber klar Semantic Versioning)

[Mic]

Neue Version 0.4.9

Ich habe ein paar Updates gemacht, siehe auch Changelog.

Unter anderem neue Option:

Außerdem habe ich die Dokumentation erweitert und das Alexa-History-Script integriert.

Die Installation wie gewohnt noch über Aus eigener URL installieren.

[Mic]

Noch ein Feedback zum Enhancement-Request bezüglich Hinzufügen eines Logs für die gesprochenen Kommandos, die der Alexa-Adapter im History-Datenpunkt vorhält. (Link)

After looking into this request, it looks like this is too individual, and would cause an additional complexity to the adapter resulting in additional maintenance without focussing on the core. Therefore, I have decided to keep it simple.
Since this Log Parser adapter provides the functionality of Manipulation of the JSON column contents by log, a user specific JavaScript (JS Adapter) will do the job greatly.
Therefore, I have added an example for Alexa: See in documentation (German, English will follow)

Ihr könnt weiterhin das ganze mit einem einfachen JavaScript umsetzen.
Siehe hier: Script-Beispiel (für JavaScript-Adapter): Alexa History - alle Sprach-Kommandos im VIS ausgeben

[sigi234]

@Mic sagte in Test: Adapter Log Parser v0.x.x GitHub:

Außerdem habe ich die Dokumentation erweitert und das Alexa-History-Script integriert.

Leider kommt in der Vis nix an, im Log schon?

javascript.0	2020-04-26 20:29:52.966	info	(10600) script.js.Alexa.Log_Mic_Alexa: [Alexa-Log-Script] ##{"message":"Wie Spät Ist Es", "from":"Dot Esszimmer"}##